From nobody Sat Sep 1 14:42:53 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCA0130E0E for ; Sat, 1 Sep 2018 14:42:52 -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 7vLfn9uZmTzQ for ; Sat, 1 Sep 2018 14:42:50 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 99DF0127B92 for ; Sat, 1 Sep 2018 14:42:50 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id i26-v6so7018503pfo.12 for ; Sat, 01 Sep 2018 14:42:50 -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=IzHWUXNvRTOzu1Ad6gs8O9U0tZhNsknoDQMH0Zx027U=; b=e912TfegH6MPMZ2vWT8Hh1Mcx6Xl6uCi6eYzkb5utX+UroO9jUTbMm8oe+RDsfP8Oe nbIJBMkoM7t/s4VQpnyb1DGidHayCOn5EhL2YfNa519yI5ATJF0tC7vZxPEBT2iPunBN R9CNDRDUo75R3KWy9S5GT57HQrF03zzrkKRWlmvINFqdbK1V85XkOf/ME7zv7nGhU+4z 2pPqFZvu8BPH8JOZGnfGuLLd848eVYPJRyLeb98xcaYqufPhQURtIeSaHS69qzFyF8c/ BAe0/2899A98lNmZx6cTsX3F5xppOw9Z9GmWYgzyjkgLoPMkhpAnXAreP0e2JIKHOI4+ Cdzg== 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=IzHWUXNvRTOzu1Ad6gs8O9U0tZhNsknoDQMH0Zx027U=; b=Hih7fG7UUFUb+L4/01cXu/+YxPv3az5K9v8u1r+wUbwjDOalrL0191vOxeVswUBcAC M/6T+cWnS7QBRjqIpBLK+Wq3Xobry90sJahx6b0x7aFcHRQ6K5l53cedx3AoTRH5odO+ +KbLDA1ooHLVmPB4v7KDTLGRIphriNUBWtvYrgpHvH90UsztTEWpfm/dirqa66BTJOSG 7D3teOVB+OhNGDoWqPCkiCyuHabfhywxbd1td+JwRpHhm8K3iasnjwJtYHFF2i+DyHWi 275h8u8yqPwscQE6uMJZu3JrfCjASNbD1187++rVnZibcjXctXUEyeiG1wrGKFH04gVI BTbQ== X-Gm-Message-State: APzg51BbxtEmQsrjTflwy3UkqOMbnBtRgrexFL3Aw1RUFPRe/mFV/eU9 9WyPono+Tib1eRn9Qi3TSXg= X-Google-Smtp-Source: ANB0VdaAriuERIOcymTahtmUFOm+AczdVLVp8xivERm6XbkXdibj/ILvmBBVKFa9CYiCuKokia2eaQ== X-Received: by 2002:a62:1a8f:: with SMTP id a137-v6mr22310361pfa.190.1535838170149; Sat, 01 Sep 2018 14:42:50 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:c199:c7b7:d703:c730? ([2601:647:4700:1280:c199:c7b7:d703:c730]) by smtp.gmail.com with ESMTPSA id u25-v6sm20277498pfk.177.2018.09.01.14.42.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Sep 2018 14:42:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <3175991A-68AC-4B29-B1EB-6A979A87A542@juniper.net> Date: Sat, 1 Sep 2018 14:44:01 -0700 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <3175991A-68AC-4B29-B1EB-6A979A87A542@juniper.net> To: Kent Watsen X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Netconf] should onboarding information *set* the debug level? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2018 21:42:52 -0000 Hi Kent, > On Aug 28, 2018, at 12:44 PM, Kent Watsen wrote: >=20 > Hi Mahesh, all, >=20 >> It makes sense that it be an operator-decision. After all they are >> the ones in the field trying to diagnose the problem in the field. >=20 > In thinking about how to enable an operator (via a bootstrap server) = to > indicate that it would like "verbose" progress reports, I came up with > the following. >=20 > rpc get-bootstrapping-data { > input { > ... > } > output { > leaf reporting-level { > default standard; > type enumeration { > enum standard { > description > "Send just the progress reports required by RFC XXXX."; > } > enum verbose { > description > "Send additional progress reports that might help > troubleshooting an SZTP bootstrapping issue."; > } > } > description > "Specifies the reporting level for progress reports the > bootstrap server would like to receive when processing > onboarding information. Progress reports are not sent > when processing redirect information."; > } > leaf zerotouch-information {...} > leaf owner-certificate {...} > leaf ownership-voucher {...} > } >=20 >=20 > Note that it's a value, being an RPC output leaf, is outside of the=20 > standard zerotouch information artifact, which is perfect for this. >=20 > My only question is, when wouldn't a bootstrap server set it to > "verbose"? ;) My take is that operators will turn the output to =E2=80=9Cverbose=E2=80=9D= if and when they start to see failures and the device not booting. = Otherwise, by default, they would be happy to just see progress reports. >=20 > Do people like or dislike this direction? I am fine with this direction. Thanks. >=20 > Kent // contributor >=20 >=20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Sun Sep 2 20:41:33 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EF4130DF1 for ; Sun, 2 Sep 2018 20:41:31 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHRK9XMYMWGc for ; Sun, 2 Sep 2018 20:41:29 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 6C733130DC8 for ; Sun, 2 Sep 2018 20:41:29 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id s7-v6so939393pgc.0 for ; Sun, 02 Sep 2018 20:41:29 -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=xX1bbbi07uSH9MZYneQTuq12sOWK1Ki6vskl1gIOJuE=; b=StEI1uzYz6DjL7FEeWdN3cM3F+ARLweHaj4lF3C6WfDi7ieI37Kc8Ihut8ouRVs2KW y74R9IxkXNFFARiBcoqrEFbWkWKpf6twI8KiWr5kPdmDaW0uNR6WORi5/dzuoQcpMvPt 1FmoOBcWtSR8cDt0Zso+9dh4uqYwVQba+6/QRnpVOu4IhVXyi+KjJwBqZmLX6hedX16r vEG0WSJnPDq8C/F/iQ6v1OhNT+4rpMPpXkE96up5fQvaBnhqBUCS/lpHWqDMDFj8n+yI oAHhGhCDmstmGTR/Wf9u3bp3lKt0rbcUeHtJwTjsLbLfGMCJ/AevcsQHrdBHlbUECYDb mhDw== 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=xX1bbbi07uSH9MZYneQTuq12sOWK1Ki6vskl1gIOJuE=; b=KLSNIh6m+/vlwkV9NIm8aZlvUpJKRpuaQyTTdgkqu0J1A2p/8LolRqXN6KQEZ4BbQM qWdgUpNndzTwyNooUZpeCZzmBYUxq1nyoUKr0yFphLEr05TWd7IEJfGqihFXsDwQropm xfTOKssea5tJo8Ys1HAwc+JYFDLE5b1CRL6ypCSNqkR/0C0ZEKCU9DISODSh6mitnbxF 7ZEWwwkNeNkikrc1bCVIJ42D5IpMHurRF4U4SgSi3E0pEZ2Le6id4Kl6hR4CQmXZQskZ qwoFWmRKBAw2V1sXKKTUZ0CAszkklfTMuxZn9JDQe1hIxPrmgW3DlXVlVfCCroewLnPs wDIg== X-Gm-Message-State: APzg51DWpCf2aTbeQ+0JhR/QjNvYhpzeS0LSq0uBhvP8YcoHG5lGZDsr 03pECHrPjbwTjMubjCMyOxs= X-Google-Smtp-Source: ANB0Vdb9sWanbXW10+6eTLyrS7Z9iVLNYrHwbZEsFR4puKABkdCTetePDK1SV3gwSiCm392quHV1kg== X-Received: by 2002:a62:5290:: with SMTP id g138-v6mr27113487pfb.46.1535946088917; Sun, 02 Sep 2018 20:41:28 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:b908:95cf:ca37:a517? ([2601:647:4700:1280:b908:95cf:ca37:a517]) by smtp.gmail.com with ESMTPSA id u184-v6sm24055499pgd.46.2018.09.02.20.41.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Sep 2018 20:41:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <32AB6932-94CE-4FF1-965F-F7D2E65AF96B@juniper.net> Date: Sun, 2 Sep 2018 20:42:44 -0700 Cc: Netconf Content-Transfer-Encoding: quoted-printable Message-Id: <83227CCC-ED4B-47A7-BA7F-180FE2AFB068@gmail.com> References: <32AB6932-94CE-4FF1-965F-F7D2E65AF96B@juniper.net> To: Kent Watsen X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Netconf] Shepherd review of draft-ietf-netconf-zerotouch-22 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 03:41:32 -0000 Hi Kent, See responses inline. > On Aug 22, 2018, at 9:53 AM, Kent Watsen wrote: >=20 > Hi Mahesh, >=20 > Thanks for your review, comments below. >=20 > Kent // author >=20 >=20 > ----- original message ----- >=20 > Hi Kent, >=20 > I am aware that you just published another version of the document. = Most of this review was done for -22 version of the document.=20 >=20 > In Section 5.6, in paragraph 6 the document talks about initial = configuration being applied. If an error occurs, is that initial = configuration removed? If so, how? It also says that the device may not = (did you mean RFC 2119=E2=80=99s MAY NOT?) reset itself in order to wipe = out any state the preconfigure script may have left behind. That means = in case of an error not only will there be initial configuration left on = the device, but any state left behind by the preconfigured script. With = post-configured script, the device is supposed to reset itself, removing = any pre-configured state and also any initial configuration. I do not = understand why with initial configuration this exception is being made = (of not resetting the device and clearing any state left behind by the = current or previous step). >=20 > Please read Section 5.6 in -23. This section was significantly = rewritten specifically to address this issue. Ok >=20 >=20 > Section 6.3. You need to add references to the RFCs that you import or = reference in the YANG model, e.g. RFC 6991. >=20 > I think that this is already the case. Please see the 2nd = paragraph in Section 6.3. Is there a particular issue? In Section 7.3, you make a reference to RFC 6187 within the YANG module, = but the same is not referenced in the beginning of the section. >=20 >=20 > leaf-list download-uri: >=20 > I am confused by the last sentence in the description. =E2=80=9CIf a = secure scheme (e.g. https) is provided, a device may (again, did you = mean RFC 2119=E2=80=99s MAY) establish an untrusted connection to the = remote server to obtain the boot-image.=E2=80=9D Are you suggesting = that the device (client) does not need to authenticate itself to the = server?=20 >=20 > No, I mean that the device MAY blindly authenticate the server's = end-entity certificate. Also, that MAY is capitalized already, right? >=20 >=20 > Most of the draft talks about the need for the device to authenticate = itself for the server to validate the device-id of the requestor.=20 >=20 > Correct. >=20 >=20 > Also, are you suggesting that a untrusted connection is fine because = the image returned will be a signed image only?=20 >=20 > No, the text is not trying to suggest that, though it is somewhat = true. More specifically, the draft says that either signed data, of = either type (redirect or onboarding information), or (likely more) = unsigned redirect information, can be returned. >=20 >=20 > This was made somewhat clear only after seeing Appendix B diagram. >=20 > Gotcha. We can fix the description, by adding "by blindly = accepting the server's end-entity certificate". Below is the resulting = text. This text also accommodates other comments Mahesh had a couple = days ago. >=20 > leaf-list download-uri { > type inet:uri; > ordered-by user; > description > "An ordered list of URIs to where the same boot image > file may be obtained. How the URI schemes (http, ftp, > etc.) a device supports are known is vendor specific. > If a secure scheme (e.g., https) is provided, a device > MAY establish an untrusted connection to the remote > server, by blindly accepting the server's end-entity > certificate, to obtain the boot image."; > } Ok. >=20 >=20 > s/This doesn=E2=80=99t affect Security so much as Privacy/This = doesn=E2=80=99t affect security as much as privacy/ > s/the device is being directed/the device is being directed to/ > s/server tis time/server this time/ >=20 > All fixed. >=20 >=20 > Appendix C.3: >=20 > In the diagram, step 3, it says that =E2=80=9Conly if source is a = bootstrap server, send progress updates=E2=80=9D. Shouldn=E2=80=99t it = be a =E2=80=9Ctrusted bootstrap server=E2=80=9D? The description for = step 3 clarifies it. >=20 > Good catch! fixed. Thanks. Mahesh Jethanandani mjethanandani@gmail.com From nobody Mon Sep 3 01:54:44 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9DD130E09 for ; Mon, 3 Sep 2018 01:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUNYUXyljAPB for ; Mon, 3 Sep 2018 01:54:41 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 331631252B7 for ; Mon, 3 Sep 2018 01:54:41 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 8F6CA1AE0402; Mon, 3 Sep 2018 10:54:37 +0200 (CEST) Date: Mon, 03 Sep 2018 10:54:36 +0200 (CEST) Message-Id: <20180903.105436.927964486928721459.mbj@tail-f.com> To: kwatsen@juniper.net Cc: j.schoenwaelder@jacobs-university.de, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180831.112941.578054615225468495.mbj@tail-f.com> <20180831102540.ileyzgsrades5m7g@anna.jacobs.jacobs-university.de> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] netconf call home connection type X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 08:54:43 -0000 Hi, Kent Watsen wrote: > Also, it seems that, if we want YP+SN to be able to use call-home > for configured subscriptions, then we need to update the SN draft > to A) define the "activate-configured-subscription" RPC I started to write that I don't think this belongs to the SN draft, since it is NETCONF-specific. But after thinking some more about it I think it makes sense to define this operation in the SN draft. For RESTCONF (not a new HTTP protocol) this rpc could be used by augmenting a 'location' leaf to its output. It is probably useful for any protocol that does RPCs. But for a notif-specific transport like a UDP-based protocol, that doesn't do normal RPCs at all, an "activate-configured-subscription" RPC doesn't make sense. But that is ok. > and B) > define an identity off of the base "call-home-reason" identity > defined in the aforementioned I-D. This is needed before any > notif draft can define support for "configured" subscriptions, > right? Yes, but if we define this identity now in SN it would delay SN. Better to define it later either in SN-bis or directly in a separate document. /martin From nobody Mon Sep 3 03:18:31 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FEF130E2A for ; Mon, 3 Sep 2018 03:18:29 -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 jLaz0aHj6JuX for ; Mon, 3 Sep 2018 03:18: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 A0A78130E25 for ; Mon, 3 Sep 2018 03:18:27 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id C1BFD1AE0402; Mon, 3 Sep 2018 12:18:24 +0200 (CEST) Date: Mon, 03 Sep 2018 12:18:23 +0200 (CEST) Message-Id: <20180903.121823.1406711858636851159.mbj@tail-f.com> To: kwatsen@juniper.net Cc: balazs.kovacs@ericsson.com, balazs.lengyel@ericsson.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 10:18:30 -0000 Kent Watsen wrote: > > Balazs> The certificates in keystore are useless without a corresponding > > private key, so certificates of a key cannot be in the configuration > > tree once the corresponding key is removed. By the way, how would a > > private key be removed from if it does not exist in > > configuration? If you do it with an action too, how would the > > corresponding certificates be removed from the configuration? > > Good points. Yes. The lifecycle of keys are not handled fully in the current draft. But I think that if this is done properly, separating the config of keys and certificates would not change the lifecycle of how keys. So let's first discuss how we want to handle creation and removal of the hidden keys (configured keys are not a problem). With the current draft, a hidden key is created in with an action and may not be present in and . There is no way to delete such a key. We would have to create a new action to remove it. An alternative design could be to move the action "generate-asymmetric-key" into the "asymmetric-key" list (and maybe rename it to "generate-hidden-key"). A client would then first have to configure an entry in the "asymmetric-key" list, and then it can generate the hidden key. If the asymmetric-key list entry is removed from , then presumably the corresponding hidden key is removed as well. With this design, a separate "certificate" list could have normal leafref (require-instance true) into the "asymmetric-key" list. However, with this new design my original issue with how certificates are handled goes away, so having them contained in the "asymmetric-key" list works fine. > >> Martin makes a case for 'B', but he also said that my 'b' was > >> "Better" but has scaling issues in the general case. Perhaps > >> we don't worry about the general case here? > > > > Balazs> Was it so? I saw an A and B model, A containing > > must "(algorithm and public-key and private-key) > > or not (algorithm or public-key or private-key)"; > > and B containing the keys and the certificates in separate container, > > and a note "I think model B is cleaner". > > Right, but if you scroll up higher, I had previously had an (a) and (b) > [note lowercase] to which he said (b) was "better". Maybe it's moot, > since his (A) was effectively my (b). Here's the new alternative: (C) container keystore { container asymmetric-keys { list asymmetric-key { key name; leaf name { ... } leaf algorithm { mandatory true; ... } leaf public-key { ... } leaf private-key { ... } // ensure that both or none are given must "(public-key and private-key) or not (public-key or private-key)"; action generate-hidden-key { // no input params } container certificates { list certificate { ... } } } } A possible extension to this would be to add anoter action next to "generate-hidden-key": action install-hidden-key { leaf public-key { ... } leaf private-key { ... } } One case to consider is that there may exist an entry in that has been configured but no hidden key has yet been generated. Such an entry would then not exist in , and the action "generate-certificate-signing-request" would fail. /martin > My point is that the containment approach 1) does resolve the he primary > goal (configuring a cert for a key in and 2) I'm not concerned > about the general scaling problem. By "perhaps we don't worry about the > general case here?", I mean to say that I prefer keeping the containment > approach. > > > > If I got it well, model A would keep the containment and produce > > the key name after invoking the action (affecting the configuration > > tree!?) at least covering the key removal use case properly. > > Invoking the generate/load-asymmetric key actions, as thus far dscribed, > would NOT affect the config tree (i.e., ), only . > > > > Balazs> If the key generation and load only affects the > > only, I would rather vote for model A having the containment relationship > > between key and certificate(s). > > This is my preferred approach as well. > > > > Plus, I would also think about the mandatory statements in the > > configuration tree whether all 4 leaves (name, private-key, > > public-key, alg) or just name and private key needs to be configured. > > I'm think all four are needed. Only public-key is possibly not needed, > but it's trivial to ask a client to pass it, so why not? > > > > ...but why use an action at all then? Everything can be done via > > standard configuration, right? > > > > Balazs> That is actually a good question. Until the enum had the > > literal 'hardware-protected' only the configuration use case of > > the private-key was a bit unclear. Now I assume configuring the > > private-key as 'hidden' could do the same as generate-private-key, > > but in that case the operator has no means to configure the public > > key (the removal of the mandatory condition for the public key > > could solve this). Regarding 'alg', I guess if hidden private key > > is asked, then algorithm is an input, but if binary private-key > > is configured, then it is rather implicit. Would the action be > > needed then? > > There are a few things off in what you write, but the most important > thing is that there is no way to *configure* (via ) a hidden > key. Trying to do so, by passing the "hidden" enum, means that the > real private key raw data would NOT be set! > > > > Balazs> The action in this case seem to make sense only if the > > purpose of the actions is really to only affect . > > Yes, that is the intent. > > > > But based on the above, I doubt yet how affecting configuration > > can be avoided (even with alt A -> to maintain consistent composition > > of key and cert) I think this question goes back to some YANG > > principles and is beyond my YANG competence. > > I'm not following, can you say a different way? > > > Kent // contributor > > > > From nobody Mon Sep 3 05:08:51 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856F8130E2F for ; Mon, 3 Sep 2018 05:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=BS7jrk4d; dkim=pass (1024-bit key) header.d=ericsson.com header.b=j/eH/Z3T Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5HHabSvacuU for ; Mon, 3 Sep 2018 05:08:47 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A5F1277BB for ; Mon, 3 Sep 2018 05:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1535976525; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AmPZJ1PrHmatP5y8QD/i9KyzV4hhnh71MSBYRWuWaVQ=; b=BS7jrk4dUwKE+sf7dGTVwQWRAiylKLZyoF4LZcVsn2kXu44w4a7lUozvIM2RfgVq XBaUEuwBQ9JRrRcUPc65bpaYH44Z1IYed1/XjGEQ4HJCkxBqdz3XkY9bYiT0JNNo are5uk1reGYxL8sm/UC+q7UvE8uxYPO++Mv7uQ6gOy8=; X-AuditID: c1b4fb30-3cd869c0000055da-ac-5b8d244da1da Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7C.2F.21978.D442D8B5; Mon, 3 Sep 2018 14:08:45 +0200 (CEST) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 3 Sep 2018 14:08:44 +0200 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 3 Sep 2018 14:08:44 +0200 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=AmPZJ1PrHmatP5y8QD/i9KyzV4hhnh71MSBYRWuWaVQ=; b=j/eH/Z3TPoWaaXAaW2ujJQaZrzw9E/vwNWPiBkQ0lwqS3qIb5M0C+3pL5XTI8EwXCnRzMscj6dANlqDWIhqHomEpb6la/HCDWfoqcxPZp3DfazFsrj4zli6gwBMNAe/6y6UKyoggXFs7WygUhpZF8Kxm23O7FBNZInbMwYRqCpw= Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com (10.167.209.150) by VI1PR0701MB2942.eurprd07.prod.outlook.com (10.173.72.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.9; Mon, 3 Sep 2018 12:08:12 +0000 Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::bd7a:c3c7:f6f1:4e9]) by VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::bd7a:c3c7:f6f1:4e9%4]) with mapi id 15.20.1122.009; Mon, 3 Sep 2018 12:08:12 +0000 From: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= To: Kent Watsen , Martin Bjorklund , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= CC: "netconf@ietf.org" Thread-Topic: [Netconf] Mandatory local configuration in Keystore groupings Thread-Index: AQHUE4npYduSZhsf/U2Th8xceQbCUaSAzHaAgEmH34CAAG1ZgIAA+nAAgAPuH4CAA+yKAIABAxSAgAB6cACAAHFXIIAAWSCAgADMp9CAAnp9gIAFf/ZQ Date: Mon, 3 Sep 2018 12:08:11 +0000 Message-ID: References: <28C3C2C7-22BE-4425-A26C-4A777FA68A95@juniper.net> <20180827.102118.630809612057220140.mbj@tail-f.com> <20180828.090648.398453385489817261.mbj@tail-f.com> In-Reply-To: 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-microsoft-exchange-diagnostics: 1; VI1PR0701MB2942; 6:tbzAncsh5668ptCs/LsyGpYcLKNk7GhSQDZzmUCNXbETYeAB81GDS5gXlAs2cocZQlKbZvVmSZ+AoDtJPrNcBdjObtJlA0RuumyzBUJ5ePJ0wC/B8urowBL8n3R3H3dE9doHMT5kgX0GlCtlq5avpPLCCPmJhYvTKiAapKj5EEHl5QkBfRq1wvnrIALPXkiwK+JuzcTVsdGtym1kb/diOIRGQi4CXeBi/dkoSF4cUMQGtDGCPCO1GLNJMivAWNTQvhzdnvnF7Axz9AshV1y196XA7Wnhgql2xsNLBPb4DIQz7oRIe9wyyB8MJH/Z73DB5kGfpjF06BZCbDM/zzapr+ez1ybtItDpy2F3rouxxMzJ22IIV/7QzStTBNHU6XQpZnqKQ9Y3hVXPSyWbnY8CY72JuPS4WWI3yYnkHT3s79UNhI5jK5reEzMlvaKYZgIVxZOhHHCRle807gI3/dBF4g==; 5:1KTynBNEXFuOCisVhoUZttobeZEYLsPMGdWP3COQLMRp8Fhb4UjRqoW1uS4cEesGcd3G6mTt1lfCE9mYFB6axGivFV/qOSmh2D4t7T+oAG9dmrNFb0uHqT1kqXZG/x09lGeErbRvdPfuAw7DsY6Nu1QvNme7LGB7c5JwY5PoFlM=; 7:kcppMhgu8r68V1Fc8M+2T0Dv83aRGHAQexqG8euS1Cp5cokCPDeso1tXDu/rXhQHOzJLUtdLIr+SXAyGJEi6MfmlCtQu1xhoV+mrpXKozqN/3iSsOOlqtcyLTMAFlTXDDQV9Xlj1AGg5ktUeChkPzR8e4FdlVZN17bwJUIVNpolmZDsEvoNNu8V0JTA8PuAYHM3eNAndrBgGv57XYM5xPDrKpvkMMVQ3gGRv3ZR1GE35k9u5/VKUDs7Q1BBRzTUo x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(366004)(396003)(346002)(136003)(39860400002)(376002)(13464003)(199004)(189003)(4326008)(5250100002)(1941001)(74316002)(8676002)(99286004)(2900100001)(106356001)(85202003)(7696005)(68736007)(2906002)(316002)(110136005)(76176011)(8936002)(86362001)(81156014)(7736002)(305945005)(6246003)(81166006)(85182001)(256004)(14444005)(25786009)(66066001)(3846002)(6116002)(6636002)(6436002)(93886005)(229853002)(478600001)(14454004)(33656002)(11346002)(476003)(446003)(53936002)(97736004)(5660300001)(102836004)(105586002)(186003)(53546011)(6506007)(9686003)(26005)(486006)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2942; H:VI1PR0701MB2016.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-office365-filtering-correlation-id: 4aadf64b-9393-43ac-d5b1-08d61195eba1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2942; x-ms-traffictypediagnostic: VI1PR0701MB2942: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(138986009662008)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699016); SRVR:VI1PR0701MB2942; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2942; x-forefront-prvs: 0784C803FD received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4icYO14mFbdeLRGlG9jPgEANLEhn/YOrHqgJszmuHja3XqSJSSOiCxBtRXRs115NSpOHJKeofIlNdrSe328vwsXOyohM+b3nLITrpXb0uII2U4Byk6DiMynvEB9J8h4hQkw3KxUK2o5alKMsH6ZpDD/kCaNEnIda72t7rfjdYFOscsZViOeoOt++1K4eoQ2G/6xLaOru6HcftAinemJr7W/ZN77FDZE+N0fJkK3AiQV81AdB9FoZMH8WJsYB6bECOhSUwa89UhyxuG+OAtg8NuE6bbBKBCH+IS5oZRayJT8d9k0SuxzjeTB822czlz5RcSWlYNRCha80oARHe4pT6EJ0IGYVWMc26sObNp50SjE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4aadf64b-9393-43ac-d5b1-08d61195eba1 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2018 12:08:11.8963 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2942 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUyM2J7ta6vSm+0wYeFohYH5rBbdHc/Y7eY uuk2qwOzx5IlP5k8rjddZffY+GsxSwBzFJdNSmpOZllqkb5dAlfGs3V/mAumBFTMPvqXtYGx x6+LkYNDQsBEomdTeBcjF4eQwFFGiSunt7NBOF8ZJf63XmWCcBYzSRze+hHMYRGYwCxx6WIr VGYqUObQeqiex4wSN///A8pwcrAJOEucf/EYrEpEoItR4tnNuWAJZgFNibV/PzKD2MICXhK7 9t5mBLFFBLwlerr3s0A0NDFKfH+1CKyIRUBFYuOshSwgNq9AgsTO31uh1n1nlpi2ZgYbSIJT wF7i3sIJ7CA2o4CYxPdTa6C2iUvcejIfzJYQEJBYsuc8M4QtKvHy8T9WiPpYiR2v77BDxJUk Zry6xQphy0pcmt/NCLJMQuAAu8S5+f+gmg0ljq/czwyR6GKTeP5pDjMkNH0l9p0ygag5CQyM iZ4Qto7EwoUTWCDsfIkDS9dCLcuVaDrTzjSB0XAWkltnAU0ChdL6XfoQYUWJKd0P2WeB/S8o cXLmE5YFjCyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQLTycEtvw12ML587niIUYCDUYmH l/t3T7QQa2JZcWXuIUYJDmYlEd6bSr3RQrwpiZVVqUX58UWlOanFhxilOViUxHkt/DZHCQmk J5akZqemFqQWwWSZODilGhiTzi0JO8t6t3b7Kbe54Rz8a4/NPBv1+8WalAkPolc9euP1OLPi 7rOTD/dzVrV9O/T+QDxLt61w/+IvV4R7lsrIPM1acfzgA99ZEgFLTlsrpfw3KjKf4MzkmVbh 7+AS/jKl7OTSJbctmM4JyyRcibWLr9Vfm2L+OS7wl2er9parz8yEzj6U6riixFKckWioxVxU nAgAvpTc4yMDAAA= Archived-At: Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 12:08:50 -0000 SGkgS2VudCwNCg0KU2VlIGJlbG93Lg0KQnIsDQpCYWxhenMNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NCj4g U2VudDogVGh1cnNkYXksIEF1Z3VzdCAzMCwgMjAxOCAxMToxNSBQTQ0KPiBUbzogQmFsw6F6cyBL b3bDoWNzIDxiYWxhenMua292YWNzQGVyaWNzc29uLmNvbT47IE1hcnRpbiBCam9ya2x1bmQNCj4g PG1iakB0YWlsLWYuY29tPjsgQmFsw6F6cyBMZW5neWVsIDxiYWxhenMubGVuZ3llbEBlcmljc3Nv bi5jb20+DQo+IENjOiBuZXRjb25mQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0g TWFuZGF0b3J5IGxvY2FsIGNvbmZpZ3VyYXRpb24gaW4gS2V5c3RvcmUgZ3JvdXBpbmdzDQo+IA0K PiANCj4gDQo+IA0KPiA+IEJhbGF6cz4gSSBwcmVmZXJyZWQgdGhlIG9yaWdpbmFsIHNob3J0IG5h bWUgYW5kIGZvciBtZSBpdCB3YXMgY2xlYXINCj4gPiB0aGF0IHRoaXMgYWN0aW9uIHByb2R1Y2Vz IGEgJ2hpZGRlbicga2V5LiBJIGFjdHVhbGx5IGxpa2UgdGhlIGlkZWEgb2YNCj4gPiBjaGFuZ2lu ZyB0aGUgJ2hhcmR3YXJlLXByb3RlY3RlZCcgZW51bSBsaXRlcmFsIHRvICdoaWRkZW4nLg0KPiAN Cj4gb2theQ0KPiANCj4gDQo+ID4gQmFsYXpzPiBJIG15c2VsZiBqdXN0IHN0YXJ0ZWQgdG8gcmVh bGl6ZSB0aGF0IHlvdSBpbnRlbmQgdG8gbWFpbnRhaW4NCj4gPiBhbiBvcGVyYXRpb25hbCB0cmVl IHRoYXQgaXMgb3V0LW9mLXN5bmMgd2l0aCB0aGUgY29uZmlndXJhdGlvbiB0cmVlLg0KPiANCj4g dW5zdXJlIHdoYXQgeW91IG1lYW4gaGVyZS4NCj4NCg0KSSBtZWFudCB0aGUgc3RhdGUgaW4gb3Bl cmF0aW9uYWwgZGF0YXN0b3JlIGlzIG5vdCByZWZsZWN0ZWQgaW4gc29tZSB3YXkgaW4gdGhlIGNv bmZpZ3VyYXRpb24gZGF0YXN0b3JlLiBUaGlzIHdhcyBhIGNvbmZ1c2lvbiBmcm9tIG15IHNpZGUu DQoNCj4gDQo+ID4gRm9yIGV4YW1wbGUsIGEgcHVibGljIGtleSBjYW4gYmUgZGV0ZXJtaW5lZCBm cm9tIHRoZSBwcml2YXRlIGtleS4gSXQNCj4gPiBpcyBvayB0byByZXF1aXJlIGFuIGluc3RhbmNl IG9mIHB1YmxpYyBrZXkgKHdpdGggbXVzdCkgZm9yIGEgcHJpdmF0ZQ0KPiA+IGtleSwgYnV0IHdo eSBpcyBpdCBtYW5kYXRvcnkgdG8gY29uZmlndXJlIGl0Pw0KPiANCj4gSW4gbW9zdCBhc3ltbWV0 cmljYWwgY3J5cHRvIHN5c3RlbSBpbXBsZW1lbnRhdGlvbiwgdGhlIG9ubHkgZmFjdCB0aGF0DQo+ IGlzIGVuc3VyZWQgaXMgdGhhdCB5b3UgY2Fubm90IGZpbmQgdGhlIHByaXZhdGUga2V5IGZyb20g dGhlIHB1YmxpYyBrZXkuDQo+IFRoZSBvdGhlciB3YXkgYXJvdW5kLCBmaW5kaW5nIHRoZSBwdWJs aWMga2V5IGZyb20gdGhlIHByaXZhdGUga2V5IGlzDQo+IHRyaXZpYWwsIGJ1dCBub3QgZ3VhcmFu dGVlZCwgaW4gbW9zdCBjYXNlcy4NCj4gDQo+IA0KPiA+IEkgZGlkIGV4cGVjdCB0aGUgcHVibGlj IGtleSBmaWxsZWQgaW4gZWl0aGVyIGJ5IGdlbmVyYXRlLWFzeW1tZXRyaWMta2V5DQo+ID4gYWN0 aW9uLCBvciBieSBjb25maWd1cmluZyBwcml2YXRlIGtleS4NCj4gDQo+IFlvdSB3YW50IHRoZSBw dWJsaWMga2V5IHRvIGJlIGF1dG9tYXRpY2FsbHkgY29tcHV0ZWQgZnJvbSB0aGUgcHJpdmF0ZQ0K PiBrZXksIHJpZ2h0PyAgIEl0IG1pZ2h0IGJlIHBvc3NpYmxlLCBidXQgaXQncyBhbHdheXMgcG9z c2libGUgdGhhdCB0aGUNCj4gY2xpZW50IGNhbiBwYXNzIGJvdGgsIHNvIHRoZSB0aGlua2luZyBp cyBqdXN0IGRvIHRoYXQgLSBtYWtlcyBzZW5zZT8NCj4gDQoNClllcyBpdCBtYWtlcywgc2VlIGJl bG93IChhbHNvIHJlbGF0ZWQgdG8gdGhlICdoaWRkZW4nIGVudW0gZGlzY3Vzc2lvbiBiZWxvdyku DQoNCj4gPiBBbHNvIHRoZSBwcml2YXRlLWtleSwgdGhlIHB1YmxpYy1rZXksIGFuZCB0aGUgYWxn b3JpdGhtIGxlYXZlcyBuZWVkIHRvDQo+ID4gYmUgaW4gc3luYyAoYWxsIHZhbGlkIGluIHJlc3Bl Y3QgdG8gdGhlIG90aGVyKQ0KPiANCj4gVHJ1ZS4gIEkgdGhpbmsgeW91J3JlIG1ha2luZyBhIGNh c2UgZm9yIGxldHRpbmcgdGhlIHNlcnZlciBkZXJpdmUgdGhlDQo+IHB1YmxpYyBrZXksIGFzIHRo ZSBjbGllbnQgbWlnaHQgcGFzcyBhIG1pc21hdGNoZWQgc2V0LiAgRGVyaXZpbmcgdGhlDQo+IHB1 YmtleSB2cyB2ZXJpZnlpbmcgYSBwYXNzZWQgcHVia2V5OiBib3RoIG9wcyByZXF1aXJlIGNyeXB0 byBjbHVlLA0KPiBidXQgb25seSBvbmUgaXMgZ3VhcmFudGVlZCB0byBhbHdheXMgd29yay4NCj4g DQo+ID4+PiBJbiBvdXIgb3BpbmlvbiB3aXRoIEJhbGF6cyBMLiwgd2UgdGhpbmsgaXQgd291bGQg YmUgZGlzYWR2YW50YWdlb3VzIHRvDQo+ID4+PiBjaGFuZ2UgdGhlIG1vZGVsIGJ5IHJ1aW5pbmcg dGhlIGNvbnRhaW5tZW50IHJlbGF0aW9uc2hpcCBiZXR3ZWVuDQo+ID4+PiBjZXJ0aWZpY2F0ZSBh bmQgY29ycmVzcG9uZGluZyBhc3ltbWV0cmljIGtleS4NCj4gPj4NCj4gPj4gQ2FuIHlvdSBzYXkg c29tZSBtb3JlIGFib3V0IHRoaXM/ICBJcyBpdCBtb3N0bHkgdGhhdCB0aGUgY29udGFpbm1lbnQN Cj4gPj4gaXMgcmVhbGx5IGludHVpdGl2ZT8gIFRoYXQgdGhlIHJlbGF0aW9uc2hpcCBpcyBsaW5r ZWQgYm90aCB3YXlzLA0KPiA+PiB3aGVyZWFzIGEgbGVhZHJlZiBvbmx5IGdvZXMgb25lIHdheT8N Cj4gPg0KPiA+IEJhbGF6cz4gVGhlIGNlcnRpZmljYXRlcyBpbiBrZXlzdG9yZSBhcmUgdXNlbGVz cyB3aXRob3V0IGEgY29ycmVzcG9uZGluZw0KPiA+IHByaXZhdGUga2V5LCBzbyBjZXJ0aWZpY2F0 ZXMgb2YgYSBrZXkgY2Fubm90IGJlIGluIHRoZSBjb25maWd1cmF0aW9uDQo+ID4gdHJlZSBvbmNl IHRoZSBjb3JyZXNwb25kaW5nIGtleSBpcyByZW1vdmVkLiBCeSB0aGUgd2F5LCBob3cgd291bGQg YQ0KPiA+IHByaXZhdGUga2V5IGJlIHJlbW92ZWQgZnJvbSA8b3BlcmF0aW9uYWw+IGlmIGl0IGRv ZXMgbm90IGV4aXN0IGluDQo+ID4gY29uZmlndXJhdGlvbj8gSWYgeW91IGRvIGl0IHdpdGggYW4g YWN0aW9uIHRvbywgaG93IHdvdWxkIHRoZQ0KPiA+IGNvcnJlc3BvbmRpbmcgY2VydGlmaWNhdGVz IGJlIHJlbW92ZWQgZnJvbSB0aGUgY29uZmlndXJhdGlvbj8NCj4gDQo+IEdvb2QgcG9pbnRzLg0K PiANCj4gDQo+ID4+IE1hcnRpbiBtYWtlcyBhIGNhc2UgZm9yICdCJywgYnV0IGhlIGFsc28gc2Fp ZCB0aGF0IG15ICdiJyB3YXMNCj4gPj4gIkJldHRlciIgYnV0IGhhcyBzY2FsaW5nIGlzc3VlcyBp biB0aGUgZ2VuZXJhbCBjYXNlLiAgUGVyaGFwcw0KPiA+PiB3ZSBkb24ndCB3b3JyeSBhYm91dCB0 aGUgZ2VuZXJhbCBjYXNlIGhlcmU/DQo+ID4NCj4gPiBCYWxhenM+IFdhcyBpdCBzbz8gSSBzYXcg YW4gQSBhbmQgQiBtb2RlbCwgQSBjb250YWluaW5nDQo+ID4gbXVzdCAiKGFsZ29yaXRobSBhbmQg cHVibGljLWtleSBhbmQgcHJpdmF0ZS1rZXkpDQo+ID4gICAgICAgICAgICAgIG9yIG5vdCAoYWxn b3JpdGhtIG9yIHB1YmxpYy1rZXkgb3IgcHJpdmF0ZS1rZXkpIjsNCj4gPiBhbmQgQiBjb250YWlu aW5nIHRoZSBrZXlzIGFuZCB0aGUgY2VydGlmaWNhdGVzIGluIHNlcGFyYXRlIGNvbnRhaW5lciwN Cj4gPiBhbmQgYSBub3RlICJJIHRoaW5rIG1vZGVsIEIgaXMgY2xlYW5lciIuDQo+IA0KPiBSaWdo dCwgYnV0IGlmIHlvdSBzY3JvbGwgdXAgaGlnaGVyLCBJIGhhZCBwcmV2aW91c2x5IGhhZCBhbiAo YSkgYW5kIChiKQ0KPiBbbm90ZSBsb3dlcmNhc2VdIHRvIHdoaWNoIGhlIHNhaWQgKGIpIHdhcyAi YmV0dGVyIi4gIE1heWJlIGl0J3MgbW9vdCwNCj4gc2luY2UgaGlzIChBKSB3YXMgZWZmZWN0aXZl bHkgbXkgKGIpLg0KPiANCg0KT2ssIEkgZm9sbG93Lg0KDQo+IE15IHBvaW50IGlzIHRoYXQgdGhl IGNvbnRhaW5tZW50IGFwcHJvYWNoIDEpIGRvZXMgcmVzb2x2ZSB0aGUgaGUgcHJpbWFyeQ0KPiBn b2FsIChjb25maWd1cmluZyBhIGNlcnQgZm9yIGEga2V5IGluIDxvcGVyYXRpb25hbD4gYW5kIDIp IEknbSBub3QgY29uY2VybmVkDQo+IGFib3V0IHRoZSBnZW5lcmFsIHNjYWxpbmcgcHJvYmxlbS4g IEJ5ICJwZXJoYXBzIHdlIGRvbid0IHdvcnJ5IGFib3V0IHRoZQ0KPiBnZW5lcmFsIGNhc2UgaGVy ZT8iLCBJIG1lYW4gdG8gc2F5IHRoYXQgSSBwcmVmZXIga2VlcGluZyB0aGUgY29udGFpbm1lbnQN Cj4gYXBwcm9hY2guDQo+IA0KDQpXaXRoIHRoZSBjb250YWlubWVudCBhcHByb2FjaCwgZG9lcyBp dCBzdGlsbCBtZWFuIHRoYXQgdGhlIG9wZXJhdG9yIG11c3QgcmVhZCB0aGUga2V5IG5hbWVzIGlu IDxvcGVyYXRpb25hbD4gYW5kIGNyZWF0ZSBhIGtleSBhbmQgY2VydGlmaWNhdGUgaW4gdGhlIGNv bmZpZ3VyYXRpb24gZGF0YXN0b3JlLCB3aGVyZSBrZXkgbmFtZSBtdXN0IG1hdGNoIGEgcmlnaHQg a2V5IHN0b3JlZCBpbiA8b3BlcmF0aW9uYWw+PyBIb3cgY2FuIGEga2V5IGJlIHJlbW92ZWQ/DQoN Cj4gPiBJZiBJIGdvdCBpdCB3ZWxsLCBtb2RlbCBBIHdvdWxkIGtlZXAgdGhlIGNvbnRhaW5tZW50 IGFuZCBwcm9kdWNlDQo+ID4gdGhlIGtleSBuYW1lIGFmdGVyIGludm9raW5nIHRoZSBhY3Rpb24g KGFmZmVjdGluZyB0aGUgY29uZmlndXJhdGlvbg0KPiA+IHRyZWUhPykgYXQgbGVhc3QgY292ZXJp bmcgdGhlIGtleSByZW1vdmFsIHVzZSBjYXNlIHByb3Blcmx5Lg0KPiANCj4gSW52b2tpbmcgdGhl IGdlbmVyYXRlL2xvYWQtYXN5bW1ldHJpYyBrZXkgYWN0aW9ucywgYXMgdGh1cyBmYXIgZHNjcmli ZWQsDQo+IHdvdWxkIE5PVCBhZmZlY3QgdGhlIGNvbmZpZyB0cmVlIChpLmUuLCA8aW50ZW5kZWQ+ KSwgb25seSA8b3BlcmF0aW9uYWw+Lg0KPiANCj4gDQo+ID4gQmFsYXpzPiBJZiB0aGUga2V5IGdl bmVyYXRpb24gYW5kIGxvYWQgb25seSBhZmZlY3RzIHRoZSA8b3BlcmF0aW9uYWw+DQo+ID4gb25s eSwgSSB3b3VsZCByYXRoZXIgdm90ZSBmb3IgbW9kZWwgQSBoYXZpbmcgdGhlIGNvbnRhaW5tZW50 IHJlbGF0aW9uc2hpcA0KPiA+IGJldHdlZW4ga2V5IGFuZCBjZXJ0aWZpY2F0ZShzKS4NCj4gDQo+ IFRoaXMgaXMgbXkgcHJlZmVycmVkIGFwcHJvYWNoIGFzIHdlbGwuDQo+IA0KDQpPay4NCg0KPiA+ IFBsdXMsIEkgd291bGQgYWxzbyB0aGluayBhYm91dCB0aGUgbWFuZGF0b3J5IHN0YXRlbWVudHMg aW4gdGhlDQo+ID4gY29uZmlndXJhdGlvbiB0cmVlIHdoZXRoZXIgYWxsIDQgbGVhdmVzIChuYW1l LCBwcml2YXRlLWtleSwNCj4gPiBwdWJsaWMta2V5LCBhbGcpIG9yIGp1c3QgbmFtZSBhbmQgcHJp dmF0ZSBrZXkgbmVlZHMgdG8gYmUgY29uZmlndXJlZC4NCj4gDQo+IEknbSB0aGluayBhbGwgZm91 ciBhcmUgbmVlZGVkLiAgT25seSBwdWJsaWMta2V5IGlzIHBvc3NpYmx5IG5vdCBuZWVkZWQsDQo+ IGJ1dCBpdCdzIHRyaXZpYWwgdG8gYXNrIGEgY2xpZW50IHRvIHBhc3MgaXQsIHNvIHdoeSBub3Q/ DQo+IA0KDQpXZWxsLCBvaywgbGV0J3Mga2VlcCBpdCBhcyBpdCBpcyBpbiB0aGUgbmV3IG11c3Qg c3RhdGVtZW50IHlvdSBwcm9wb3NlZC4NCg0KPiA+IC4uLmJ1dCB3aHkgdXNlIGFuIGFjdGlvbiBh dCBhbGwgdGhlbj8gIEV2ZXJ5dGhpbmcgY2FuIGJlIGRvbmUgdmlhDQo+ID4gc3RhbmRhcmQgY29u ZmlndXJhdGlvbiwgcmlnaHQ/DQo+ID4NCj4gPiBCYWxhenM+IFRoYXQgaXMgYWN0dWFsbHkgYSBn b29kIHF1ZXN0aW9uLiBVbnRpbCB0aGUgZW51bSBoYWQgdGhlDQo+ID4gbGl0ZXJhbCAnaGFyZHdh cmUtcHJvdGVjdGVkJyBvbmx5IHRoZSBjb25maWd1cmF0aW9uIHVzZSBjYXNlIG9mDQo+ID4gdGhl IHByaXZhdGUta2V5IHdhcyBhIGJpdCB1bmNsZWFyLiBOb3cgSSBhc3N1bWUgY29uZmlndXJpbmcg dGhlDQo+ID4gcHJpdmF0ZS1rZXkgYXMgJ2hpZGRlbicgY291bGQgZG8gdGhlIHNhbWUgYXMgZ2Vu ZXJhdGUtcHJpdmF0ZS1rZXksDQo+ID4gYnV0IGluIHRoYXQgY2FzZSB0aGUgb3BlcmF0b3IgaGFz IG5vIG1lYW5zIHRvIGNvbmZpZ3VyZSB0aGUgcHVibGljDQo+ID4ga2V5ICh0aGUgcmVtb3ZhbCBv ZiB0aGUgbWFuZGF0b3J5IGNvbmRpdGlvbiBmb3IgdGhlIHB1YmxpYyBrZXkNCj4gPiBjb3VsZCBz b2x2ZSB0aGlzKS4gUmVnYXJkaW5nICdhbGcnLCBJIGd1ZXNzIGlmIGhpZGRlbiBwcml2YXRlIGtl eQ0KPiA+IGlzIGFza2VkLCB0aGVuIGFsZ29yaXRobSBpcyBhbiBpbnB1dCwgYnV0IGlmIGJpbmFy eSBwcml2YXRlLWtleQ0KPiA+IGlzIGNvbmZpZ3VyZWQsIHRoZW4gaXQgaXMgcmF0aGVyIGltcGxp Y2l0LiBXb3VsZCB0aGUgYWN0aW9uIGJlDQo+ID4gbmVlZGVkIHRoZW4/DQo+IA0KPiBUaGVyZSBh cmUgYSBmZXcgdGhpbmdzIG9mZiBpbiB3aGF0IHlvdSB3cml0ZSwgYnV0IHRoZSBtb3N0IGltcG9y dGFudA0KPiB0aGluZyBpcyB0aGF0IHRoZXJlIGlzIG5vIHdheSB0byAqY29uZmlndXJlKiAodmlh IDxpbnRlbmRlZD4pIGEgaGlkZGVuDQo+IGtleS4gIFRyeWluZyB0byBkbyBzbywgYnkgcGFzc2lu ZyB0aGUgImhpZGRlbiIgZW51bSwgbWVhbnMgdGhhdCB0aGUNCj4gcmVhbCBwcml2YXRlIGtleSBy YXcgZGF0YSB3b3VsZCBOT1QgYmUgc2V0IQ0KPiANCg0KSWYgaXQgaXMgJ2hpZGRlbicsIHRoZW4g aXMgdGhlcmUgYSBuZWVkIHRvIHNldCB0aGUgcmVhbCBwcml2YXRlIGtleSByYXcgZGF0YT8gSXQg Y2FuIGp1c3QgYmUgZHJhd24gYXMgaXQgd2FzIHdoZW4gaW52b2tpbmcgZ2VuZXJhdGUtYXN5bW1l dHJpYy1rZXkuICBPciB3aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gZ2VuZXJhdGUtYXN5 bW1ldHJpYy1rZXkgdnMuIHNldHRpbmcgJ2hpZGRlbicgZW51bSAocmVnYXJkbGVzcyBvZiB0aGUg dXNlciBub3QgYmVpbmcgYWJsZSB0byBwcm92aWRlIHB1YmxpYyBrZXkgaW4gJ2hpZGRlbicgY2Fz ZS0td2hpY2ggaXMgY3VycmVudGx5IGEgbXVzdCk/DQoNCj4gPiBCYWxhenM+IFRoZSBhY3Rpb24g aW4gdGhpcyBjYXNlIHNlZW0gdG8gbWFrZSBzZW5zZSBvbmx5IGlmIHRoZQ0KPiA+IHB1cnBvc2Ug b2YgdGhlIGFjdGlvbnMgaXMgcmVhbGx5IHRvIG9ubHkgYWZmZWN0IDxvcGVyYXRpb25hbD4uDQo+ IA0KPiBZZXMsIHRoYXQgaXMgdGhlIGludGVudC4NCj4gDQo+IA0KPiA+IEJ1dCBiYXNlZCBvbiB0 aGUgYWJvdmUsIEkgZG91YnQgeWV0IGhvdyBhZmZlY3RpbmcgY29uZmlndXJhdGlvbg0KPiA+IGNh biBiZSBhdm9pZGVkIChldmVuIHdpdGggYWx0IEEgLT4gdG8gbWFpbnRhaW4gY29uc2lzdGVudCBj b21wb3NpdGlvbg0KPiA+IG9mIGtleSBhbmQgY2VydCkgSSB0aGluayB0aGlzIHF1ZXN0aW9uIGdv ZXMgYmFjayB0byBzb21lIFlBTkcNCj4gPiBwcmluY2lwbGVzIGFuZCBpcyBiZXlvbmQgbXkgWUFO RyBjb21wZXRlbmNlLg0KPiANCj4gSSdtIG5vdCBmb2xsb3dpbmcsIGNhbiB5b3Ugc2F5IGEgZGlm ZmVyZW50IHdheT8NCj4gDQoNCldoYXQgaXMgdGhlIHByb2NlZHVyZSB0byByZW1vdmUgYSBrZXkg dGhhdCB3YXMgY3JlYXRlZCB2aWEgZ2VuZXJhdGUtYXN5bW1ldHJpYy1rZXk/DQoNCj4gS2VudCAv LyBjb250cmlidXRvcg0KPiANCj4gDQo+IA0KDQo= From nobody Tue Sep 4 01:34:44 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33E5130E42 for ; Tue, 4 Sep 2018 01:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 header.b=axhegOlH; dkim=pass (1024-bit key) header.d=ericsson.com header.b=lYm7FZta Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4l33t2-luLM for ; Tue, 4 Sep 2018 01:34:41 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828F3130E2D for ; Tue, 4 Sep 2018 01:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536050078; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=thjTilLa7W54OxSzLtJWfR9GTkFze+NwisP3NGrLPuo=; b=axhegOlH+Qip22ya6TKawhWqIhgVS8P4luKvDx92st/hn7smUIV4QMYbAJ2Jw+Gl 8RWHCHXNIxZSULVg5Xhmfa/QXvpfNPTIUMILwV/08H8s51GFLmGdMkqd2gOK2YJD LTI6XXQ9b/Ujf4ur8ACM5221ST86JzbLijUcE7/oz1c=; X-AuditID: c1b4fb25-8e7ff700000013ad-4e-5b8e439e6e41 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B6.44.05037.E934E8B5; Tue, 4 Sep 2018 10:34:38 +0200 (CEST) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 4 Sep 2018 10:34:38 +0200 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 4 Sep 2018 10:34:38 +0200 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=hkAv1FBcGNZ14rP+vw5pVcCZ9jd5S8eWv35KyklTtec=; b=lYm7FZtaEBHWqpg0tOCYdR0fv93kaBNoeMrIg1mOAZbSalNubhuAzTh1hgYyVtmWiaKuHKwY/812Xq9Ah7HlhSSdqc1bv4bippvrZeVCT4/h6jm67y+QBvpWFkYbioQauDqCeYhdtGMtAkR1hZHzUhMEa4bLQWzXzwy8gsrnYwA= Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com (10.167.209.150) by VI1PR0701MB2048.eurprd07.prod.outlook.com (10.167.210.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.12; Tue, 4 Sep 2018 08:34:36 +0000 Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::bd7a:c3c7:f6f1:4e9]) by VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::bd7a:c3c7:f6f1:4e9%4]) with mapi id 15.20.1122.009; Tue, 4 Sep 2018 08:34:35 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= To: Martin Bjorklund , "kwatsen@juniper.net" CC: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= , "netconf@ietf.org" Thread-Topic: [Netconf] Mandatory local configuration in Keystore groupings Thread-Index: AQHUE4npYduSZhsf/U2Th8xceQbCUaSAzHaAgEmH34CAAG1ZgIAA+nAAgAPuH4CAA+yKAIABAxSAgAB6cACAAHFXIIAAWSCAgADMp9CAAnp9gIAFkemAgAFwH/A= Date: Tue, 4 Sep 2018 08:34:35 +0000 Message-ID: References: <20180903.121823.1406711858636851159.mbj@tail-f.com> In-Reply-To: <20180903.121823.1406711858636851159.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2048; 6:EjsCApBjkR3k1HLuJFVWL5TxBbQTqH22Y8xPDioZ4pjrfzUSv+ca7Ehz+YK4fKrzEtTYrWjsqsbxj9o8w/+3ZSrg+aRPTT1aSxDPBaArBtsLH4OSxCxfUduWHvhi32Uo27uvAm2+8ulV2pFQlY5YIOItWdwA1ybay28Pl+eotvDjiRpwWe5VyZj1uH2OFjprVbEk7WfWUqvcD4XQ3X/kT44WnrmnMomKk8OmNoSy4LM/pRrINNDPrzHOC3j2/9kEZzzDbU34IrcaKdiVRb4hBxKYI2JxHa1lbV4yiNdfrFZDupNVhpJ8KG6hvsJLKtdBB3izdhbJqcgWALpVXvScd4/5FNx+h5vLjzXLPDWA4fNX96R9pqwrpp58Y6zLBxi7AqselDQ30w0+N4Sh/hreppehS+5tf96ZCXoGL+Y+RiNh6nc27UUcWTiuuUpMfZXYBUxpF2ri2igY5ImkJwjDNA==; 5:m3fQl4cPrE00tmhDYAA9i1xGNpOcBOIMgsfwWvsKmSA9Hdy1x0XPIB1WlhNX+bDuXw0CmsttzSpYqxoBwxyz9CwsyKF/0ErApPaBy/NcMY1S1B5+JdX/vQcKZe+aSsJfPcfyLHOlOAYc50MR2qyUlXGfhsLqUv6qeWG9YZOWG/w=; 7:ZAXOw7gvwAbeIjAL+EzK9cdzlyi96F7TvzVds7Jy2v4oP6KL5U1WrCvxjBvJg///VGMFwXKYYjd1I+zhT6EaG8MwydXyqkNGCvOdVoPpK2DTBQ8xE6asmSDbXfQBREhfTibaOi/SjeSGJSQtBQfiOfX/cAqGwfkYYzy3hDZK4ncy331sEFghZaj0HaVSqNe7hI6Mf3X0LP0FS4Ilbq2cdzvOqqlq8bOQuSk1+6Hwl2CqScAIt4FQjjnmLTihbHSg x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(366004)(136003)(346002)(376002)(396003)(199004)(189003)(13464003)(1941001)(102836004)(256004)(53546011)(14444005)(5250100002)(6506007)(93886005)(14454004)(2501003)(2900100001)(4326008)(7696005)(33656002)(110136005)(99286004)(316002)(54906003)(229853002)(7736002)(55016002)(305945005)(9686003)(6436002)(74316002)(8676002)(97736004)(53936002)(81156014)(186003)(26005)(11346002)(476003)(486006)(446003)(86362001)(105586002)(81166006)(5660300001)(8936002)(25786009)(68736007)(76176011)(2906002)(106356001)(6116002)(66066001)(3846002)(6246003)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2048; H:VI1PR0701MB2016.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-office365-filtering-correlation-id: e9772c43-fdb8-4f50-5595-08d612413efc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(5600074)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2048; x-ms-traffictypediagnostic: VI1PR0701MB2048: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(138986009662008)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(823301075)(3231311)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699049)(76991033); SRVR:VI1PR0701MB2048; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2048; x-forefront-prvs: 0785459C39 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: rgFnn334VIDay4HMMZg8ZJ1SjoyHZBmBwTzuT4baXPDQvFTV8d8jSnYEkJwxV/7ca3NJnJFW2FH9YmoFUoneqjet0CV9Ylw1zJGrSPF45/xsMp9fLPCRUj6IuDAGR/3vOaeUHhOsX98PEqJ+oPEIvqd1uDZW50wQ246RRzf8DZ09RRlgoik0wVgmkHgiwHdVvn1BIGhrxEtj11NXhWpgNNDcvPO5KO6YkgcJO6IGyTRvyc4IZZhGOr11zCgIbq2G7tr6w8mHA8Kwkomqe12lDuWDmEhD9cbIezBB7Leri9lP4T+hGRaOd3lEYbjQswsTmd6L1OhmOa3EeeCXBy4qvu9IiUliQ0Ne9XPa8Gnbrkk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e9772c43-fdb8-4f50-5595-08d612413efc X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2018 08:34:35.7161 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2048 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUyM2J7ue48575og3ubDCwOzGG36O5+xm4x ddNtVgdmjyVLfjJ5XG+6yu6x8ddilgDmKC6blNSczLLUIn27BK6Mnh9vmApe21bcmfGepYHx iH4XIyeHhICJxKlTr9i6GLk4hASOMkoc+HGVEcL5yijRcG0OE4SzmEni65kOVhCHRWACs8Tp I6uYITLTmCT+zz3NBjJMSOAxo8SyCUIgNpuAq8TTmT/ZQWwRgRCJroWTWEFsZoEciaZvqxlB bGEBL4lde28zQtR4S/R072cBGSoi0MUocWbveRaQBIuAisTxx1uZQWxegQSJvm8LWCA2NzJJ TFxxCKybU8BR4kL7KyYQm1FATOL7qTVMENvEJW49mc8E8aqAxJI955khbFGJl4//sULYShIz Xt2CsmUlLs3vBoeAhMABdonGW21QCUOJ4yv3M0MkGtgk1rz4wwKR8JXYsuoMG0RiO6PEqubF UCt0JB4e+g91UqzEjtd32CHi+RLTty+HqomReLP3MesERsNZSK6FsPUkbkydwgZha0ssW/ia eRY4CAQlTs58wrKAkWUVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmBKObjlt+oOxstvHA8x CnAwKvHw/jftixZiTSwrrsw9xCjBwawkwuvHDxTiTUmsrEotyo8vKs1JLT7EKM3BoiTO+9B8 c5SQQHpiSWp2ampBahFMlomDU6qBcfKr9KaWJW7xF6Oun5saOfHIfHeNN6Xb3steNAw8vthO b6LcqvWMYtvU+zh4Popvs06//L3f5YEYc+O7qPQdHy0PylY0+jO2Ou3SdKpsSWf4zTC38cPq Fj7+/N8GHV27ApTPOxwpenAw0THjUf/EAI/0CXcrxEzzVy1Y//abUrhJTfBkZYsIJZbijERD Leai4kQAn/rohSUDAAA= Archived-At: Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 08:34:43 -0000 Hi Martin, I prefer your alternative (C) with some comments. I'd keep the name of the action as 'generate-asymmetric-key'. I think the w= ord 'asymmetric' gives a hint on its intended use case, so it is important = (though it is already in an asymmetric-key list). The word 'hidden' is not = that important for me since the action in itself hints that the key in this= case is not provided by the operator, thus its binary value won't appear e= ither. If operator needs to provide it, it has to go via the 'private-key' = leaf. Or the action could be just called 'generate-key'. A question still: it is unclear to me what the difference is between callin= g the action vs just configuring the 'private-key' to enum 'hidden'. Br, Balazs > -----Original Message----- > From: Martin Bjorklund > Sent: Monday, September 3, 2018 12:18 PM > To: kwatsen@juniper.net > Cc: Bal=E1zs Kov=E1cs ; Bal=E1zs Lengyel > ; netconf@ietf.org > Subject: Re: [Netconf] Mandatory local configuration in Keystore grouping= s >=20 > Kent Watsen wrote: > > > Balazs> The certificates in keystore are useless without a > > > Balazs> corresponding > > > private key, so certificates of a key cannot be in the configuration > > > tree once the corresponding key is removed. By the way, how would a > > > private key be removed from if it does not exist in > > > configuration? If you do it with an action too, how would the > > > corresponding certificates be removed from the configuration? > > > > Good points. >=20 > Yes. The lifecycle of keys are not handled fully in the current draft. = But I > think that if this is done properly, separating the config of keys and > certificates would not change the lifecycle of how keys. So let's first = discuss > how we want to handle creation and removal of the hidden keys (configured > keys are not a problem). >=20 > With the current draft, a hidden key is created in with an ac= tion > and may not be present in and . There is no way to > delete such a key. We would have to create a new action to remove it. >=20 > An alternative design could be to move the action "generate-asymmetric- > key" into the "asymmetric-key" list (and maybe rename it to "generate- > hidden-key"). A client would then first have to configure an entry in th= e > "asymmetric-key" list, and then it can generate the hidden key. If the > asymmetric-key list entry is removed from , then presumably the > corresponding hidden key is removed as well. >=20 > With this design, a separate "certificate" list could have normal leafref > (require-instance true) into the "asymmetric-key" list. > However, with this new design my original issue with how certificates are > handled goes away, so having them contained in the "asymmetric-key" list > works fine. >=20 > > >> Martin makes a case for 'B', but he also said that my 'b' was > > >> "Better" but has scaling issues in the general case. Perhaps we > > >> don't worry about the general case here? > > > > > > Balazs> Was it so? I saw an A and B model, A containing > > > must "(algorithm and public-key and private-key) > > > or not (algorithm or public-key or private-key)"; and B > > > containing the keys and the certificates in separate container, and > > > a note "I think model B is cleaner". > > > > Right, but if you scroll up higher, I had previously had an (a) and > > (b) [note lowercase] to which he said (b) was "better". Maybe it's > > moot, since his (A) was effectively my (b). >=20 > Here's the new alternative: >=20 > (C) >=20 > container keystore { > container asymmetric-keys { > list asymmetric-key { > key name; >=20 > leaf name { ... } > leaf algorithm { mandatory true; ... } >=20 > leaf public-key { ... } > leaf private-key { ... } >=20 > // ensure that both or none are given > must "(public-key and private-key) > or not (public-key or private-key)"; >=20 > action generate-hidden-key { // no input params } >=20 > container certificates { > list certificate { ... } > } > } > } >=20 > A possible extension to this would be to add anoter action next to > "generate-hidden-key": >=20 > action install-hidden-key { > leaf public-key { ... } > leaf private-key { ... } > } >=20 >=20 > One case to consider is that there may exist an entry in that = has > been configured but no hidden key has yet been generated. > Such an entry would then not exist in , and the action > "generate-certificate-signing-request" would fail. >=20 >=20 >=20 > /martin >=20 >=20 >=20 > > My point is that the containment approach 1) does resolve the he > > primary goal (configuring a cert for a key in and 2) I'm > > not concerned about the general scaling problem. By "perhaps we don't > > worry about the general case here?", I mean to say that I prefer > > keeping the containment approach. > > > > > > > If I got it well, model A would keep the containment and produce the > > > key name after invoking the action (affecting the configuration > > > tree!?) at least covering the key removal use case properly. > > > > Invoking the generate/load-asymmetric key actions, as thus far > > dscribed, would NOT affect the config tree (i.e., ), only > . > > > > > > > Balazs> If the key generation and load only affects the > > > Balazs> > > > only, I would rather vote for model A having the containment > > > relationship between key and certificate(s). > > > > This is my preferred approach as well. > > > > > > > Plus, I would also think about the mandatory statements in the > > > configuration tree whether all 4 leaves (name, private-key, > > > public-key, alg) or just name and private key needs to be configured. > > > > I'm think all four are needed. Only public-key is possibly not > > needed, but it's trivial to ask a client to pass it, so why not? > > > > > > > ...but why use an action at all then? Everything can be done via > > > standard configuration, right? > > > > > > Balazs> That is actually a good question. Until the enum had the > > > literal 'hardware-protected' only the configuration use case of the > > > private-key was a bit unclear. Now I assume configuring the > > > private-key as 'hidden' could do the same as generate-private-key, > > > but in that case the operator has no means to configure the public > > > key (the removal of the mandatory condition for the public key could > > > solve this). Regarding 'alg', I guess if hidden private key is > > > asked, then algorithm is an input, but if binary private-key is > > > configured, then it is rather implicit. Would the action be needed > > > then? > > > > There are a few things off in what you write, but the most important > > thing is that there is no way to *configure* (via ) a hidden > > key. Trying to do so, by passing the "hidden" enum, means that the > > real private key raw data would NOT be set! > > > > > > > Balazs> The action in this case seem to make sense only if the > > > purpose of the actions is really to only affect . > > > > Yes, that is the intent. > > > > > > > But based on the above, I doubt yet how affecting configuration can > > > be avoided (even with alt A -> to maintain consistent composition of > > > key and cert) I think this question goes back to some YANG > > > principles and is beyond my YANG competence. > > > > I'm not following, can you say a different way? > > > > > > Kent // contributor > > > > > > > > From nobody Tue Sep 4 07:37:36 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39F9130EEF for ; Tue, 4 Sep 2018 07:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 v0L1GWEQctf5 for ; Tue, 4 Sep 2018 07:37:31 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF53C1277C8 for ; Tue, 4 Sep 2018 07:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14178; q=dns/txt; s=iport; t=1536071851; x=1537281451; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=HbOmZWqok5WwCvVXJcM7snwH+MIV6T9cpVGzSnRkUwQ=; b=MjCx+DJFl8DmkXjsPOl/S9AvMQPnV/8D3JPBC3HkJX09z9BHOHombY5F z5jt/KQh+0Tgt4fLgAe0131bQprVMmjGbOFXtgDnor+D0k+ZxyaZxHyNO AAgjZQWP2cwW2M/L9eQwfx3oZes1E0X5ijtW234tFyyWJf2Oj5yGJql8B w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAwDGl45b/xbLJq1aHAEBAQQBAQo?= =?us-ascii?q?BAYMfggEShBqIcY04gR2XLwuIQzgUAQIBAQIBAQJtHQuFYQ8BBVocAgkdAl8?= =?us-ascii?q?NCAEBFQKDBoICh3WMZo5lgS6EbIURgQuJZIFBP4ESJwyCKoUNEIMXglcCh3q?= =?us-ascii?q?FN44lCYkvhkQGF4FAhw6GC4g8hTqFb4FYISeBLjMaCBsVO4JtkFM+ixQBJQI?= =?us-ascii?q?BgiEBAQ?= X-IronPort-AV: E=Sophos;i="5.53,329,1531785600"; d="scan'208";a="6271505" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2018 14:37:27 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w84EbPqb018008 for ; Tue, 4 Sep 2018 14:37:26 GMT From: Robert Wilton To: "netconf@ietf.org" Message-ID: <386e425f-d250-a0a9-0927-1a484aed9042@cisco.com> Date: Tue, 4 Sep 2018 15:37:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Netconf] RGW YANG push -18 LC comments [part 1] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 14:37:34 -0000 Hi, I've reviewed the -18 YANG push draft up to section 4 so far . I've included my comments below.  I think that they are all minor/cosmetic except for the issue regarding the dampened subscriptions which has been discussed below and probably does not need to be rehashed again. In the Abstract: (1) Is "continuous" the right choice of word here.  E.g. I thought that sometimes the stream of updates is not continuous.  Possibly remove "continuous"? In the Introduction: (2) "remote visibility" in the first sentence is a bit obscure. Perhaps replace the first sentence with "Traditional approaches to monitoring management data on remote devices have been built upon polling". (3) The work isn't actually fruitless if polling is the only available option, hence perhaps change: OLD: "For applications that monitor for changes, many remote polling  cycles place ultimately fruitless load on the network, devices,  and applications." NEW:   "For applications that monitor for changes, many remote polling   cycles place unwanted load on the network, devices,   and applications, particularly if the monitored values are only changing infrequently." (4) In paragraph starting " A more effective alternative", possibly suggest changing "publisher" to "server" since the introduction is before the definitions/acronyms where "publisher" is formally referenced. In definitions: (5) Suggest tying this definition more closely to the terminology already defined in RFC 8342, hence: OLD:    o  Datastore node: An instance of management information in a       datastore.  Also known as "object". NEW:    o  Datastore node: A node in the instantiated YANG data tree associated with a datastore.  In this document, datastore nodes are often referred to as "YANG objects" or "objects" (6) "Datastore node update" definition: Does this update only contain the value, or does it also contain the path to the datastore node as well?  If this also contains the path then it would be good if that was explicit in the definition. (7) Perhaps the following definition is more precise?  Or by "updates" do you actually mean "update records"?  There are other references to "updates" in the definitions, do these all refer to "update records"? If so then I would suggest moving the definition of "update record" above "datastore subscription". OLD: "Datastore subscription: A subscription to updates regarding       contents of a datastore." NEW: "Datastore subscription: A subscription to a stream of datastore node updates." (8) Suggest removing "instantiated" from the following definition, and using descendant (which is used in 7950) instead of contained .. I also suggest moving the definition up, directly below "datastore node": OLD:    o Datastore subtree: An instantiated datastore node and the       datastore nodes that are hierarchically contained within it. NEW:    o Datastore subtree: A  datastore node and all its descendant datastore nodes." (9) Sec 3. Solution overview, last sentence.   It is not "YANG objects" that are being pushed, but surely "datastore node updates" or perhaps "update records" that are pushed, or even "Changes to YANG objects" Sec 3.1 Subscription model: (10) Perhaps change"subtrees within a datastore" to "datastore subtrees". (11) It is not obvious to me from this text what "Anchor time" is, although I suspect that it is described in more detail later in the document.  Given that the section on-change subscriptions has more detail for various parameters, I wonder whether it would be helpful to describe anchor time in more detail in this section? (12) Dampening period: The text states that "The dampening period collectively applies to the set of all datastore nodes selected by a single subscription and sent to a single receiver."  This would imply that if a single subscription had multiple receivers that they would be dampened independently, but it wasn't obvious to me that this makes sense.  I would assume that for a given subscription that all receivers would receive the same update records. (13) Rather than "No Sync on start", it might be better to refer to this as  "sync on start", which could be defined as a boolean with default true [I've not checked the YANG model] Sec 3.2. Negotiation of Subscription Policies (14) "Random guessing at" => "Random guessing of".  Although, I think that probably this first sentence, and the "Therfore, " could just be deleted.  I.e. starting the paragraph "In order to minimize ..." (15) Suggest minor rewording of 3.3. third paragraph: OLD: In that case, updates are sent only for those objects    within the scope that do support on-change updates whereas other    objects are excluded from update records, whether or not their values    actually change. NEW: In that case, updates are sent only for those objects    within the scope that do support on-change updates, whereas other    objects are excluded from update records, even if their values change. (16) Question on 3.3. fifth paragraph (below), it's unclear to me what is meant by "which are current at the time": "Values sent at the end of the    dampening period are the current values of all changed objects which    are current at the time the dampening period expires." (17) I still doubt that all implementations will strictly follow all of 3.3. paragraph 5, particularly the created and deleted within a dampening period because I perceive that it is particularly difficult to implement cleanly/efficiently.  However, this issue has been discussed previously, and I have no particular desire to slow the RFC progress down with further discussion on this. (18) Section 3.3, conceptual process, step 1 states that access control rules are checked to ensure the receiver is authorized to view all subscribed datastore nodes, but I think that this should state that the access control rules are used to filter the subscribed datastore nodes to those that the client has access rights to. (19) A related question:  When happens if there is an access control change, i.e. the receiver had access previously, but then it was revoked.  Does it see a delete?  Or does it not get any notification?  Similarly, if they didn't previously have access, but then access was granted before the end of the dampening period?  OK, I see that this is described in more detail in section 3.9, paragraph 3.  Perhaps a forward reference would be useful here. (20) Section 3.3, last paragraph, "can be created" => "must be created". (21) Section 3.4, second paragraph doesn't quite scan.  "This includes    indicating the fact that an update is incomplete as part of a push-    update respectively push-change-update notification ..." (22) Section 3.4, 3rd paragraph, "able fulfill" => "able to fulfill" (23) Section 3.5.2, 1st paragraph, "not restricted to configuration objects only" => "not only restricted to configuration objects". (24) Section 3.5.2, 2nd paragraph, possible alternative text: OLD:    A publisher will indicate a change to the effect that a value of a    datastore node has been updated by indicating a "replace" operation    (applied to the datastore node) in the patch.  When a new datastore    node was created (other than an entry in a user ordered list), a    publisher will indicate a "create" operation in the patch.  When a    datastore node was deleted, the publisher indicates this by a    "delete".  When a new entry in a user-ordered list was created, the    publisher indicates this by an "insert" operation. When an entry in    a user-ordered list was moved, the publisher indicates this by a    "move" operation. NEW:   A publisher indicates the type of change to a datastore node using the different YANG patch operations:  the "create" operation is used for newly created objects (except entries in a user-ordered list), the "delete" operation is used for deleted objects (including in user-ordered lists), the "replace" operation is used when only the object value changes, the "insert" operation is used when a new entry is inserted in a list, and the "move" operation is used when an existing entry in a user-ordered list is moved. (25) Section 3.5.2, last paragraph: If you want to allow duplicate "create" and "delete" events, then it might be cleaner to encode them as "merge" and "remove"?  I.e. it seems that you have created a slightly different encoding from vanilla YANG patch because of the way that errors are handled differently.  Ideally, it would be better if a client could just apply this as regular YANG patch, but this only works with the encoding described here if the clients copy of the datastore is in sync with the servers old copy of the datastore at the point that the patch is generated from.  This seems slightly fragile to unexpected inconsistencies between client and server (which I appreciate that you try and avoid). (26) Section 3.6, second paragraph, would it not be easier to allow the client to replace an existing filter rather than having to explicitly remove the old filter and add the new one?  Or if you mean that any new filter replaces the existing filter, then this may be more clearly indicated with the text: "An RPC request proposing a new selection filter replaces any existing filter. " (27) Section 3.6, paragraph 6, starting "XPath".  The "boolean" example is unclear to me given that a xpath filter always returns a node set so can't return a boolean result.  I also suggest changing "passes a datastore node" to  "includes a datastore node". (28) Section 3.6, paragraph 7.  I think that the text must be more explicit on when the filter is evaluated for a periodic subscription.  Am I right in thinking that it is only evaluated once when the subscription is created, or the subscription is changed? Specifically, if the nodeset evaluated during the lifetime of an Xpath subscription changes then does that affect which nodes are returned? (29) Section 3.7, paragraph 3:  Perhaps make this text conditional to dampened subscriptions.  Presumably for non dampened subscriptions all changes are reported as separate push-change-update notifications? OLD: In cases where multiple changes have occurred and the object    has not been deleted, the object's most current value is reported. NEW: In cases where multiple changes have occurred in a subscription that has dampening enabled, and the object    has not been deleted, the object's most current value is reported. (30) Section 3.7, paragraph 5, "Ethernet port" => "Ethernet interface" (31) Section 3.7, last paragraph: Why start at "1" rather than "0". On overflow, why overflow to "1" rather than "0", is that deliberate?  If you are going to force it to "1" then I would also restrict the upper bound to int32 max rather than uint32 max to make life easier in Java land ... (32) Section 3.8, tree diagrams.  I would think that another key metric regarding whether a subscription can be satisfied would be object-rate and data-rate.  E.g. a publisher implementation may be able to push 100k objects/second, so a client has a choice of either monitoring less objects, or decreasing the period.  Hence I was wondering whether rates should be provided in addition to the object-count-estimate/limit and kilobyte-estimate/limit.  Of course, a rate is also implicitly defined by including the period hint, so perhaps that is sufficient without needing to send more fields back to the client. (33) Section 3.9, 2nd paragraph, "particular each" => "particular" (34) Section 3.9, 3rd paragraph:  It was not entirely obvious to me what the 3rd paragraph text (reproduced below) actually means.  I think that this boils down to:  If, after access control has been applied, there are no objects remaining in an update record then only a single empty "push-update" notification MAY be sent and empty "push-change-update" messages MUST NOT be sent.  This is required to ensure that clients cannot surreptitiously monitor objects that they do not have access to via carefully crafted selection filters. "A publisher MUST allow for the possibility that a subscription's    selection filter references non-existent or access-protected data.    Such support permits a receiver the ability to monitor the entire    lifecyle of some datastore tree.  In this case, all "push-update"    notifications must be sent empty, and no "push-change-update"    notifications will be sent until some data becomes visible for a    receiver." (35) Section 3.10.  This text seems to be very closely related to the text in section 3.3, so perhaps section 3.10 would be better moved to become section 3.3.1? (36) Section 3.10, last paragraph.  "will be expected to" => "SHOULD"? (37) Section 3.11.1 "incomplete-update" flag.  In the YANG definition this flag is set in the header of the message (i.e. before the data), but for applications that are generating the notifications in a streamed way, it would probably be better to put the flag after data.  This potentially minimizes the requirement that a publisher has to buffer all data to be able to set the incomplete-update flag if necessary. (38) Section 3.11.1 3rd paragraph and bullet points.  With the text as currently written, it is acceptable for a publisher to do nothing even if an error is hit.  They can satisfy the first "MUST" by selecting the 2nd choice, and they can satisfy the "MAY" of the second choice by doing nothing at all.  Instead I think that the text should state that the publisher MUST set the "incomplete-update" flag, or suspend the subscription, or both. Thanks, Rob From nobody Tue Sep 4 08:22:56 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2BF130F08 for ; Tue, 4 Sep 2018 08:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.609 X-Spam-Level: X-Spam-Status: No, score=-12.609 tagged_above=-999 required=5 tests=[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, T_DKIMWL_WL_MED=-0.01, 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 po_pb5vpArrh for ; Tue, 4 Sep 2018 08:22:53 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CACCC130F06 for ; Tue, 4 Sep 2018 08:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15399; q=dns/txt; s=iport; t=1536074572; x=1537284172; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=sRmO0tmZby2889lSU45IQlIKFqe7nEblPSGFzBoM7es=; b=F4k6w0+/3dr1sbOD1h4EGdyoV42f8EBPPOF2I0aG86IdhaxEftxg6NOv CsW7BbGCDC4xBg9oGbOfZ6KzxBOhraLjQ/tbtu2HJ40JgiZty5w9UhLCg 5YftQj2cuWuGzAnF0yuF9jM4UI9l9Xtdfg6IdPos8U5af6jKhWLF4ZXys c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQAtoo5b/xbLJq1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJXSAWBD20SKIxjjV2QeoUzgXoLGAEKhANGAoNVNhYBAgE?= =?us-ascii?q?BAgEBAm0cDIU4AQEEAQErQRsLGA0hJzAGAQwGAgEBglJLAYIBD6RlH4RNhQw?= =?us-ascii?q?Fim+BQT+BOYI2NYMbAQGBO4V+Aod6IR+GKoxyCY9zBheBQIQ3gleGC4g8hTq?= =?us-ascii?q?Fb4FHATEngS4zGggbFTuCbIsVhT8+MIpkASUEgiABAQ?= X-IronPort-AV: E=Sophos;i="5.53,329,1531785600"; d="scan'208,217";a="6271169" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2018 15:22:50 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w84FMnaM015398; Tue, 4 Sep 2018 15:22:49 GMT To: "Yutianpeng (Tim)" , "netconf@ietf.org" References: <35FF0D51C8DAB54B95B0426331F984FF520433B2@lhreml523-mbs.china.huawei.com> From: Robert Wilton Message-ID: Date: Tue, 4 Sep 2018 16:22:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <35FF0D51C8DAB54B95B0426331F984FF520433B2@lhreml523-mbs.china.huawei.com> Content-Type: multipart/alternative; boundary="------------9180A539831656C87846DB61" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 15:22:55 -0000 This is a multi-part message in MIME format. --------------9180A539831656C87846DB61 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Tim, Please see comments (as a non author) inline ... On 29/08/2018 16:28, Yutianpeng (Tim) wrote: > > Hi, > > Some comments as below: > > ------------------------------ > > There is one point missing in the draft so far I think: what if the > subscriber is the initiator of the configuration changes? > > In this case, the subscriber is aware of configuration changes > initiated by itself without relying on the push mechanism. Introducing > push mechanism will dramatically impact the performance of the system > in this case. > > My suggestion is: > > 3.3. On-Change Considerations > >    5.  If the resulting patch record is non-empty, and it contains the > records not initiated by the subscriber, select these records and send > to corresponding subscriber. > > We can have further discussion on this to make it optional instead of > mandatory. > I'm not keen on this change.  This does not seem like a good separation of concerns.  Besides, I'm not convinced why this should really be a performance issue given that config changes are relatively rare compared to all the operational state in the system that may be changing. > ----------------------------- > > Both “subscriber” and “receiver” are used, bit confusing sometimes. > Shall we only use “subscriber” > They are different entities, the definitions are in draft-ietf-netconf-subscribed-notifications: Receiver: A target to which a publisher pushes subscribed event records. For dynamic subscriptions, the receiver and subscriber are the same entity. Subscriber: A client able to request and negotiate a contract for the generation and push of event records from a publisher. For dynamic subscriptions, the receiver and subscriber are the same entity. > ------------------------ > > 3.11.1. Robustness and reliability > >    Note: It is perfectly acceptable to have a series of "push-change- > >    update" notifications (and even "push update" notifications) serially > >    queued at the transport layer awaiting transmission.  It is not > >    required to merge pending update records.  I.e., the dampening period > >    applies to update record creation, not transmission. > > My suggestion is: > > The publisher should increase dampening period automatically in case > the message queue reaches a limit. > > This is to avoid notifications lost due to queue limit in case > subscriber is busy or temporarily unreachable. > I don't think that this is how the dampening that is currently defined should work, since it is expected to provide a strong guarantee that it will either deliver the notifications to the receiver, or otherwise notify to the receiver that some updates [may] have been lost. I could imagine that another, softer type of dampening, could potentially be defined in future as a separate extension/augmentation, but I don't think that should go into this document, because it would massively slow it down, and the industry already needs this standard now. > ----------------------------- > > It would be appreciated if suggestions can be given on how push shall > be used on running, startup and candidate datastores > It should work the same way as YANG push on any other datastore. The mechanism described in the draft seems to be entirely datastore agnostic.  In what way do you think it may behave differently? Although I could imagine that implementations may not support subscriptions on startup or candidate, in which case I would expect that the subscription would be rejected. Thanks, Rob > ------------------------------- > > Regards, > > Tim > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------9180A539831656C87846DB61 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Tim,

Please see comments (as a non author) inline ...


On 29/08/2018 16:28, Yutianpeng (Tim) wrote:

Hi,

Some comments as below:

 

------------------------------

There is one point missing in the draft so far I think: what if the subscriber is the initiator of the configuration changes?

In this case, the subscriber is aware of configuration changes initiated by itself without relying on the push mechanism. Introducing push mechanism will dramatically impact the performance of the system in this case.

My suggestion is:

3.3.  On-Change Considerations

   5.  If the resulting patch record is non-empty, and it contains the records not initiated by the subscriber, select these records and send to corresponding subscriber.

We can have further discussion on this to make it optional instead of mandatory.

I'm not keen on this change.  This does not seem like a good separation of concerns.  Besides, I'm not convinced why this should really be a performance issue given that config changes are relatively rare compared to all the operational state in the system that may be changing.

 

-----------------------------

Both “subscriber” and “receiver” are used, bit confusing sometimes. Shall we only use “subscriber”

They are different entities, the definitions are in draft-ietf-netconf-subscribed-notifications:

   Receiver: A target to which a publisher pushes subscribed event
   records.  For dynamic subscriptions, the receiver and subscriber are
   the same entity.

   Subscriber: A client able to request and negotiate a contract for the
   generation and push of event records from a publisher.  For dynamic
   subscriptions, the receiver and subscriber are the same entity.


 

------------------------

3.11.1.  Robustness and reliability

   Note: It is perfectly acceptable to have a series of "push-change-

   update" notifications (and even "push update" notifications) serially

   queued at the transport layer awaiting transmission.  It is not

   required to merge pending update records.  I.e., the dampening period

   applies to update record creation, not transmission.

My suggestion is:

The publisher should increase dampening period automatically in case the message queue reaches a limit.

This is to avoid notifications lost due to queue limit in case subscriber is busy or temporarily unreachable.

I don't think that this is how the dampening that is currently defined should work, since it is expected to provide a strong guarantee that it will either deliver the notifications to the receiver, or otherwise notify to the receiver that some updates [may] have been lost.

I could imagine that another, softer type of dampening, could potentially be defined in future as a separate extension/augmentation, but I don't think that should go into this document, because it would massively slow it down, and the industry already needs this standard now.

 

-----------------------------

It would be appreciated if suggestions can be given on how push shall be used on running, startup and candidate datastores

It should work the same way as YANG push on any other datastore.  The mechanism described in the draft seems to be entirely datastore agnostic.  In what way do you think it may behave differently? 

Although I could imagine that implementations may not support subscriptions on startup or candidate, in which case I would expect that the subscription would be rejected.

Thanks,
Rob


 

-------------------------------

 

Regards,

Tim



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

--------------9180A539831656C87846DB61-- From nobody Tue Sep 4 08:27:40 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C1D130F16 for ; Tue, 4 Sep 2018 08:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSsMNTqzB9pt for ; Tue, 4 Sep 2018 08:27:35 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE11F130F08 for ; Tue, 4 Sep 2018 08:27:34 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id p10-v6so3538790ljg.2 for ; Tue, 04 Sep 2018 08:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9oAdsatrk/SBbYXGHnczSHOCwIqlXl3hNz8gTNjwOh0=; b=egCvjSVycw0vjczlco2a9SsY0E+2U9GggJGnl0v+6t6MrZp1LU1cfOMKqdcO3Hlp/h XFI/DVv6PM/JW4I/Z14fFTmBTB+N/+JcYf4WyXq18NOlvE28jGggL9HY1NEYsR/7vfEw hXL4dsx92eMh9eiZ8w9wPntP1RLpHJZEkAccK25VDUEX936idQ/yoCspLuP0WA7LhF7m jWjlwHkOk1W7FRY3Rwiz/NS5HNdyV+bazypUJmJpRNWkKnXgDzpwIX5LjfGaMloayBbv Ak8kRVmfGAINUk5PUVswBDc4Vs4/cFx3ihHsQZdxKKblcuH0xFD/7nMRTPwo9Hh+9q78 /D2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9oAdsatrk/SBbYXGHnczSHOCwIqlXl3hNz8gTNjwOh0=; b=jdYeh1Wwi2DVns14k+fQ0gfcBzFAeALD6nX9rlv31pTYa+hOHnpJXy44e1eoINIMhg 7f629lLVkZzJbrUakdCsf8ghNZxUM1ubH++EN1bMX6hUOIVLv6RgM6+BelEurULE/vEk h+68NVX1l1Q+anYvh0lBasrPZLjKo4O4mSev+II5b1+Qbh8boC45wvJJeNpuOGUIH0qd hCBzNJkmkmeS8lXCooctdNRD6zTF0TsUCf4EuW25U2et5+eEITTj+WHhGofLunS8gB5y j/aX+5P5fTIEv6o/wuqNwvIrcJq9cQYo7V/jhQcyDNh50etNXYwYOVKugoUBpdHyQH38 3/qg== X-Gm-Message-State: APzg51DONWMFOqA8ubrClswZmAsh5MhYVrQYTGwlhnZXwiHqVpg2Rorl Fsk+JHvFO/Bxf1sHF4yAIHOIQ4PgYUblf5HBabicug== X-Google-Smtp-Source: ANB0VdaxklQq0D0MmaoBcRcMW9aLd1GX07coaJWKVg8yCB9WJQ6UgBSpDEXRsc9EbpZ8uLbDzflaDiQ/QnAAD3SvKcQ= X-Received: by 2002:a2e:58b:: with SMTP id 133-v6mr20172937ljf.28.1536074852615; Tue, 04 Sep 2018 08:27:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:5116:0:0:0:0:0 with HTTP; Tue, 4 Sep 2018 08:27:31 -0700 (PDT) In-Reply-To: References: <35FF0D51C8DAB54B95B0426331F984FF520433B2@lhreml523-mbs.china.huawei.com> From: Andy Bierman Date: Tue, 4 Sep 2018 08:27:31 -0700 Message-ID: To: Robert Wilton Cc: "Yutianpeng (Tim)" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f070f005750d4bc2" Archived-At: Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 15:27:38 -0000 --000000000000f070f005750d4bc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 4, 2018 at 8:22 AM, Robert Wilton < rwilton=3D40cisco.com@dmarc.ietf.org> wrote: > Hi Tim, > > Please see comments (as a non author) inline ... > > On 29/08/2018 16:28, Yutianpeng (Tim) wrote: > > Hi, > > Some comments as below: > > > > ------------------------------ > > There is one point missing in the draft so far I think: what if the > subscriber is the initiator of the configuration changes? > > In this case, the subscriber is aware of configuration changes initiated > by itself without relying on the push mechanism. Introducing push mechani= sm > will dramatically impact the performance of the system in this case. > > My suggestion is: > > 3.3. On-Change Considerations > > 5. If the resulting patch record is non-empty, and it contains the > records not initiated by the subscriber, select these records and send to > corresponding subscriber. > > We can have further discussion on this to make it optional instead of > mandatory. > > I'm not keen on this change. This does not seem like a good separation o= f > concerns. Besides, I'm not convinced why this should really be a > performance issue given that config changes are relatively rare compared = to > all the operational state in the system that may be changing. > > +1 -- this change should not be made. This is not a useful optimization. > > > ----------------------------- > > Both =E2=80=9Csubscriber=E2=80=9D and =E2=80=9Creceiver=E2=80=9D are used= , bit confusing sometimes. Shall > we only use =E2=80=9Csubscriber=E2=80=9D > > They are different entities, the definitions are in > draft-ietf-netconf-subscribed-notifications: > > Receiver: A target to which a publisher pushes subscribed event > records. For dynamic subscriptions, the receiver and subscriber are > the same entity. > > Subscriber: A client able to request and negotiate a contract for the > generation and push of event records from a publisher. For dynamic > subscriptions, the receiver and subscriber are the same entity. > > > > > > ------------------------ > > 3.11.1. Robustness and reliability > > Note: It is perfectly acceptable to have a series of "push-change- > > update" notifications (and even "push update" notifications) serially > > queued at the transport layer awaiting transmission. It is not > > required to merge pending update records. I.e., the dampening period > > applies to update record creation, not transmission. > > My suggestion is: > > The publisher should increase dampening period automatically in case the > message queue reaches a limit. > > This is to avoid notifications lost due to queue limit in case subscriber > is busy or temporarily unreachable. > > I don't think that this is how the dampening that is currently defined > should work, since it is expected to provide a strong guarantee that it > will either deliver the notifications to the receiver, or otherwise notif= y > to the receiver that some updates [may] have been lost. > > I could imagine that another, softer type of dampening, could potentially > be defined in future as a separate extension/augmentation, but I don't > think that should go into this document, because it would massively slow = it > down, and the industry already needs this standard now. > > +1 -- the server does what it is told and does not decide to change the subscription on its own > > > ----------------------------- > > It would be appreciated if suggestions can be given on how push shall be > used on running, startup and candidate datastores > > It should work the same way as YANG push on any other datastore. The > mechanism described in the draft seems to be entirely datastore agnostic. > In what way do you think it may behave differently? > > Although I could imagine that implementations may not support > subscriptions on startup or candidate, in which case I would expect that > the subscription would be rejected. > > Thanks, > Rob > > > Andy > > > ------------------------------- > > > > Regards, > > Tim > > > _______________________________________________ > Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo= /netconf > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --000000000000f070f005750d4bc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 4, 2018 at 8:22 AM, Robert Wilton <rwil= ton=3D40cisco.com@dmarc.ietf.org> wrote:
=20 =20 =20

Hi Tim,

Please see comments (as a non author) inline ...


On 29/08/2018 16:2= 8, Yutianpeng (Tim) wrote:
=20 =20 =20

Hi,<= u>

Some comments as below:

=C2= =A0

-----------= -------------------

There is on= e point missing in the draft so far I think: what if the subscriber is the initiator of the configuration changes?

In this case, the subscriber is aware of configuration changes initiated by itself without relying on the push mechanism. Introducing push mechanism will dramatically impact the performance of the system in this case.

My suggestion is:

3.3.=C2=A0 On-Change Considerations

=C2=A0=C2= =A0 5.=C2=A0 If the resulting patch record is non-empty, and it contains the records not initiated by the subscriber, select these records and send to corresponding subscriber.

We can have further discussion on this to make it optional instead of mandatory.

I'm not keen on this change.=C2=A0 This does not seem like a good separation of concerns.=C2=A0 Besides, I'm not convinced why this s= hould really be a performance issue given that config changes are relatively rare compared to all the operational state in the system that may be changing.


+1 -- this change should not= be made.
This is not a useful optimization.

=
=C2=A0

<= /u>

=C2= =A0

-----------= ------------------

Both =E2=80=9Csubscriber=E2=80=9D and =E2=80=9Creceiver=E2=80=9D are= used, bit confusing sometimes. Shall we only use =E2=80=9Csubscriber=E2=80=9D

They are different entities, the definitions are in draft-ietf-netconf-subscribed-notifications:

   Receiver: A target to whi=
ch a publisher pushes subscribed event
   records.  For dynamic subscriptions, the receiver and subscriber are
   the same entity.

   Subscriber: A client able to request and negotiate a contract for the
   generation and push of event records from a publisher.  For dynamic
   subscriptions, the receiver and subscriber are the same entity.


<= /u>

=C2= =A0

-----------= -------------

3.11.1.=C2= =A0 Robustness and reliability

=C2=A0=C2= =A0 Note: It is perfectly acceptable to have a series of "push-change-<= u>

=C2=A0=C2= =A0 update" notifications (and even "push update" notifications) serially

=C2=A0=C2= =A0 queued at the transport layer awaiting transmission.=C2=A0 It is not

=C2=A0=C2= =A0 required to merge pending update records.=C2=A0 I.e., the dampening peri= od

=C2=A0=C2= =A0 applies to update record creation, not transmission.

My suggestion is:

The publisher should increase dampening period automatically in case the message queue reaches a limit.

This is to avoid notifications lost due to queue limit in case subscriber is busy or temporarily unreachable.

I don't think that this is how the dampening that is currently defined should work, since it is expected to provide a strong guarantee that it will either deliver the notifications to the receiver, or otherwise notify to the receiver that some updates [may] have been lost.

I could imagine that another, softer type of dampening, could potentially be defined in future as a separate extension/augmentation, but I don't think that should go into this document, because it would massively slow it down, and the industry already needs this standard now.


+1 -- the server does what i= t is told and does not decide to change the subscription on its own

=C2=A0

<= /u>

=C2= =A0

-----------= ------------------

It would be appreciated if suggestions can be given on how push shall be used on running, startup and candidate datastores

It should work the same way as YANG push on any other datastore.=C2=A0 The mechanism described in the draft seems to be entirely datastore agnostic.=C2=A0 In what way do you think it may behave differently?=C2= =A0

Although I could imagine that implementations may not support subscriptions on startup or candidate, in which case I would expect that the subscription would be rejected.

Thanks,
Rob




Andy
=C2=A0

<= /u>

=C2= =A0

-----------= --------------------

=C2= =A0

Regards,=

Tim<= u>



_______________________________________________
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<= br>

--000000000000f070f005750d4bc2-- From nobody Tue Sep 4 08:33:49 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7B7130F1D for ; Tue, 4 Sep 2018 08:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 5d6k9mj4LZ8r for ; Tue, 4 Sep 2018 08:33:45 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1F51277BB for ; Tue, 4 Sep 2018 08:33:45 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 04B291AE02BE; Tue, 4 Sep 2018 17:33:43 +0200 (CEST) Date: Tue, 04 Sep 2018 17:33:43 +0200 (CEST) Message-Id: <20180904.173343.771736120417698474.mbj@tail-f.com> To: andy@yumaworks.com Cc: rwilton=40cisco.com@dmarc.ietf.org, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <35FF0D51C8DAB54B95B0426331F984FF520433B2@lhreml523-mbs.china.huawei.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 15:33:47 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBUdWUsIFNlcCA0 LCAyMDE4IGF0IDg6MjIgQU0sIFJvYmVydCBXaWx0b24gPA0KPiByd2lsdG9uPTQwY2lzY28uY29t QGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4gDQo+ID4gSGkgVGltLA0KPiA+DQo+ID4gUGxlYXNl IHNlZSBjb21tZW50cyAoYXMgYSBub24gYXV0aG9yKSBpbmxpbmUgLi4uDQo+ID4NCj4gPiBPbiAy OS8wOC8yMDE4IDE2OjI4LCBZdXRpYW5wZW5nIChUaW0pIHdyb3RlOg0KPiA+DQo+ID4gSGksDQo+ ID4NCj4gPiBTb21lIGNvbW1lbnRzIGFzIGJlbG93Og0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gVGhlcmUgaXMgb25lIHBvaW50IG1p c3NpbmcgaW4gdGhlIGRyYWZ0IHNvIGZhciBJIHRoaW5rOiB3aGF0IGlmIHRoZQ0KPiA+IHN1YnNj cmliZXIgaXMgdGhlIGluaXRpYXRvciBvZiB0aGUgY29uZmlndXJhdGlvbiBjaGFuZ2VzPw0KPiA+ DQo+ID4gSW4gdGhpcyBjYXNlLCB0aGUgc3Vic2NyaWJlciBpcyBhd2FyZSBvZiBjb25maWd1cmF0 aW9uIGNoYW5nZXMgaW5pdGlhdGVkDQo+ID4gYnkgaXRzZWxmIHdpdGhvdXQgcmVseWluZyBvbiB0 aGUgcHVzaCBtZWNoYW5pc20uIEludHJvZHVjaW5nIHB1c2ggbWVjaGFuaXNtDQo+ID4gd2lsbCBk cmFtYXRpY2FsbHkgaW1wYWN0IHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgc3lzdGVtIGluIHRoaXMg Y2FzZS4NCj4gPg0KPiA+IE15IHN1Z2dlc3Rpb24gaXM6DQo+ID4NCj4gPiAzLjMuICBPbi1DaGFu Z2UgQ29uc2lkZXJhdGlvbnMNCj4gPg0KPiA+ICAgIDUuICBJZiB0aGUgcmVzdWx0aW5nIHBhdGNo IHJlY29yZCBpcyBub24tZW1wdHksIGFuZCBpdCBjb250YWlucyB0aGUNCj4gPiByZWNvcmRzIG5v dCBpbml0aWF0ZWQgYnkgdGhlIHN1YnNjcmliZXIsIHNlbGVjdCB0aGVzZSByZWNvcmRzIGFuZCBz ZW5kIHRvDQo+ID4gY29ycmVzcG9uZGluZyBzdWJzY3JpYmVyLg0KPiA+DQo+ID4gV2UgY2FuIGhh dmUgZnVydGhlciBkaXNjdXNzaW9uIG9uIHRoaXMgdG8gbWFrZSBpdCBvcHRpb25hbCBpbnN0ZWFk IG9mDQo+ID4gbWFuZGF0b3J5Lg0KPiA+DQo+ID4gSSdtIG5vdCBrZWVuIG9uIHRoaXMgY2hhbmdl LiAgVGhpcyBkb2VzIG5vdCBzZWVtIGxpa2UgYSBnb29kIHNlcGFyYXRpb24gb2YNCj4gPiBjb25j ZXJucy4gIEJlc2lkZXMsIEknbSBub3QgY29udmluY2VkIHdoeSB0aGlzIHNob3VsZCByZWFsbHkg YmUgYQ0KPiA+IHBlcmZvcm1hbmNlIGlzc3VlIGdpdmVuIHRoYXQgY29uZmlnIGNoYW5nZXMgYXJl IHJlbGF0aXZlbHkgcmFyZSBjb21wYXJlZCB0bw0KPiA+IGFsbCB0aGUgb3BlcmF0aW9uYWwgc3Rh dGUgaW4gdGhlIHN5c3RlbSB0aGF0IG1heSBiZSBjaGFuZ2luZy4NCj4gPg0KPiA+DQo+ICsxIC0t IHRoaXMgY2hhbmdlIHNob3VsZCBub3QgYmUgbWFkZS4NCj4gVGhpcyBpcyBub3QgYSB1c2VmdWwg b3B0aW1pemF0aW9uLg0KDQorMQ0KDQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4NCj4gPiBCb3RoIOKAnHN1YnNjcmliZXLigJ0gYW5kIOKAnHJlY2VpdmVy 4oCdIGFyZSB1c2VkLCBiaXQgY29uZnVzaW5nIHNvbWV0aW1lcy4gU2hhbGwNCj4gPiB3ZSBvbmx5 IHVzZSDigJxzdWJzY3JpYmVy4oCdDQo+ID4NCj4gPiBUaGV5IGFyZSBkaWZmZXJlbnQgZW50aXRp ZXMsIHRoZSBkZWZpbml0aW9ucyBhcmUgaW4NCj4gPiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2Ny aWJlZC1ub3RpZmljYXRpb25zOg0KPiA+DQo+ID4gICAgUmVjZWl2ZXI6IEEgdGFyZ2V0IHRvIHdo aWNoIGEgcHVibGlzaGVyIHB1c2hlcyBzdWJzY3JpYmVkIGV2ZW50DQo+ID4gICAgcmVjb3Jkcy4g IEZvciBkeW5hbWljIHN1YnNjcmlwdGlvbnMsIHRoZSByZWNlaXZlciBhbmQgc3Vic2NyaWJlciBh cmUNCj4gPiAgICB0aGUgc2FtZSBlbnRpdHkuDQo+ID4NCj4gPiAgICBTdWJzY3JpYmVyOiBBIGNs aWVudCBhYmxlIHRvIHJlcXVlc3QgYW5kIG5lZ290aWF0ZSBhIGNvbnRyYWN0IGZvciB0aGUNCj4g PiAgICBnZW5lcmF0aW9uIGFuZCBwdXNoIG9mIGV2ZW50IHJlY29yZHMgZnJvbSBhIHB1Ymxpc2hl ci4gIEZvciBkeW5hbWljDQo+ID4gICAgc3Vic2NyaXB0aW9ucywgdGhlIHJlY2VpdmVyIGFuZCBz dWJzY3JpYmVyIGFyZSB0aGUgc2FtZSBlbnRpdHkuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0K PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gMy4xMS4xLiAgUm9idXN0bmVz cyBhbmQgcmVsaWFiaWxpdHkNCj4gPg0KPiA+ICAgIE5vdGU6IEl0IGlzIHBlcmZlY3RseSBhY2Nl cHRhYmxlIHRvIGhhdmUgYSBzZXJpZXMgb2YgInB1c2gtY2hhbmdlLQ0KPiA+DQo+ID4gICAgdXBk YXRlIiBub3RpZmljYXRpb25zIChhbmQgZXZlbiAicHVzaCB1cGRhdGUiIG5vdGlmaWNhdGlvbnMp IHNlcmlhbGx5DQo+ID4NCj4gPiAgICBxdWV1ZWQgYXQgdGhlIHRyYW5zcG9ydCBsYXllciBhd2Fp dGluZyB0cmFuc21pc3Npb24uICBJdCBpcyBub3QNCj4gPg0KPiA+ICAgIHJlcXVpcmVkIHRvIG1l cmdlIHBlbmRpbmcgdXBkYXRlIHJlY29yZHMuICBJLmUuLCB0aGUgZGFtcGVuaW5nIHBlcmlvZA0K PiA+DQo+ID4gICAgYXBwbGllcyB0byB1cGRhdGUgcmVjb3JkIGNyZWF0aW9uLCBub3QgdHJhbnNt aXNzaW9uLg0KPiA+DQo+ID4gTXkgc3VnZ2VzdGlvbiBpczoNCj4gPg0KPiA+IFRoZSBwdWJsaXNo ZXIgc2hvdWxkIGluY3JlYXNlIGRhbXBlbmluZyBwZXJpb2QgYXV0b21hdGljYWxseSBpbiBjYXNl IHRoZQ0KPiA+IG1lc3NhZ2UgcXVldWUgcmVhY2hlcyBhIGxpbWl0Lg0KPiA+DQo+ID4gVGhpcyBp cyB0byBhdm9pZCBub3RpZmljYXRpb25zIGxvc3QgZHVlIHRvIHF1ZXVlIGxpbWl0IGluIGNhc2Ug c3Vic2NyaWJlcg0KPiA+IGlzIGJ1c3kgb3IgdGVtcG9yYXJpbHkgdW5yZWFjaGFibGUuDQo+ID4N Cj4gPiBJIGRvbid0IHRoaW5rIHRoYXQgdGhpcyBpcyBob3cgdGhlIGRhbXBlbmluZyB0aGF0IGlz IGN1cnJlbnRseSBkZWZpbmVkDQo+ID4gc2hvdWxkIHdvcmssIHNpbmNlIGl0IGlzIGV4cGVjdGVk IHRvIHByb3ZpZGUgYSBzdHJvbmcgZ3VhcmFudGVlIHRoYXQgaXQNCj4gPiB3aWxsIGVpdGhlciBk ZWxpdmVyIHRoZSBub3RpZmljYXRpb25zIHRvIHRoZSByZWNlaXZlciwgb3Igb3RoZXJ3aXNlIG5v dGlmeQ0KPiA+IHRvIHRoZSByZWNlaXZlciB0aGF0IHNvbWUgdXBkYXRlcyBbbWF5XSBoYXZlIGJl ZW4gbG9zdC4NCj4gPg0KPiA+IEkgY291bGQgaW1hZ2luZSB0aGF0IGFub3RoZXIsIHNvZnRlciB0 eXBlIG9mIGRhbXBlbmluZywgY291bGQgcG90ZW50aWFsbHkNCj4gPiBiZSBkZWZpbmVkIGluIGZ1 dHVyZSBhcyBhIHNlcGFyYXRlIGV4dGVuc2lvbi9hdWdtZW50YXRpb24sIGJ1dCBJIGRvbid0DQo+ ID4gdGhpbmsgdGhhdCBzaG91bGQgZ28gaW50byB0aGlzIGRvY3VtZW50LCBiZWNhdXNlIGl0IHdv dWxkIG1hc3NpdmVseSBzbG93IGl0DQo+ID4gZG93biwgYW5kIHRoZSBpbmR1c3RyeSBhbHJlYWR5 IG5lZWRzIHRoaXMgc3RhbmRhcmQgbm93Lg0KPiA+DQo+ID4NCj4gKzEgLS0gdGhlIHNlcnZlciBk b2VzIHdoYXQgaXQgaXMgdG9sZCBhbmQgZG9lcyBub3QgZGVjaWRlIHRvIGNoYW5nZSB0aGUNCj4g c3Vic2NyaXB0aW9uIG9uIGl0cyBvd24NCg0KKzENCg0KDQovbWFydGluDQoNCj4gDQo+IA0KPiAN Cj4gPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+IEl0 IHdvdWxkIGJlIGFwcHJlY2lhdGVkIGlmIHN1Z2dlc3Rpb25zIGNhbiBiZSBnaXZlbiBvbiBob3cg cHVzaCBzaGFsbCBiZQ0KPiA+IHVzZWQgb24gcnVubmluZywgc3RhcnR1cCBhbmQgY2FuZGlkYXRl IGRhdGFzdG9yZXMNCj4gPg0KPiA+IEl0IHNob3VsZCB3b3JrIHRoZSBzYW1lIHdheSBhcyBZQU5H IHB1c2ggb24gYW55IG90aGVyIGRhdGFzdG9yZS4gIFRoZQ0KPiA+IG1lY2hhbmlzbSBkZXNjcmli ZWQgaW4gdGhlIGRyYWZ0IHNlZW1zIHRvIGJlIGVudGlyZWx5IGRhdGFzdG9yZSBhZ25vc3RpYy4N Cj4gPiBJbiB3aGF0IHdheSBkbyB5b3UgdGhpbmsgaXQgbWF5IGJlaGF2ZSBkaWZmZXJlbnRseT8N Cj4gPg0KPiA+IEFsdGhvdWdoIEkgY291bGQgaW1hZ2luZSB0aGF0IGltcGxlbWVudGF0aW9ucyBt YXkgbm90IHN1cHBvcnQNCj4gPiBzdWJzY3JpcHRpb25zIG9uIHN0YXJ0dXAgb3IgY2FuZGlkYXRl LCBpbiB3aGljaCBjYXNlIEkgd291bGQgZXhwZWN0IHRoYXQNCj4gPiB0aGUgc3Vic2NyaXB0aW9u IHdvdWxkIGJlIHJlamVjdGVkLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IFJvYg0KPiA+DQo+ID4N Cj4gPg0KPiANCj4gQW5keQ0KPiANCj4gDQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+DQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+DQo+ID4gVGlt DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3ROZXRjb25mQGlldGYub3JnaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ID4NCj4gPg0KPiA+DQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBOZXRj b25mIG1haWxpbmcgbGlzdA0KPiA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPg0KPiA+DQo= From nobody Tue Sep 4 09:20:25 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4BE130E4D for ; Tue, 4 Sep 2018 09:20: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN-_8Kmr7jA4 for ; Tue, 4 Sep 2018 09:20:21 -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 47E88129619 for ; Tue, 4 Sep 2018 09:20:21 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7235617A6519E; Tue, 4 Sep 2018 17:20:16 +0100 (IST) Received: from LHREML523-MBS.china.huawei.com ([169.254.9.45]) by LHREML714-CAH.china.huawei.com ([10.201.108.37]) with mapi id 14.03.0399.000; Tue, 4 Sep 2018 17:20:15 +0100 From: "Yutianpeng (Tim)" To: Martin Bjorklund , "andy@yumaworks.com" CC: "netconf@ietf.org" , "rwilton=40cisco.com@dmarc.ietf.org" Thread-Topic: [Netconf] Comments on draft-ietf-netconf-yang-push-18 Thread-Index: AdQ/rOk2O9B1aMu7RrSnvHTptxxrnQErdiaAAAAqBoAAADdugAACTR5Q Date: Tue, 4 Sep 2018 16:20:15 +0000 Message-ID: <35FF0D51C8DAB54B95B0426331F984FF52045B7E@lhreml523-mbs.china.huawei.com> References: <35FF0D51C8DAB54B95B0426331F984FF520433B2@lhreml523-mbs.china.huawei.com> <20180904.173343.771736120417698474.mbj@tail-f.com> In-Reply-To: <20180904.173343.771736120417698474.mbj@tail-f.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.203.126.98] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 16:20:24 -0000 SGksDQpUaGFua3MgZm9yIHJlcGx5Lg0KU29tZSBleHBsYW5hdGlvbnMgYXMgYmVsb3csIHBsZWFz ZSBjaGVjay4NClRpbQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTmV0Y29u ZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnRpbiBC am9ya2x1bmQNClNlbnQ6IDA0IFNlcHRlbWJlciAyMDE4IDE2OjM0DQpUbzogYW5keUB5dW1hd29y a3MuY29tDQpDYzogbmV0Y29uZkBpZXRmLm9yZzsgcndpbHRvbj00MGNpc2NvLmNvbUBkbWFyYy5p ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW5l dGNvbmYteWFuZy1wdXNoLTE4DQoNCkFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiB3 cm90ZToNCj4gT24gVHVlLCBTZXAgNCwgMjAxOCBhdCA4OjIyIEFNLCBSb2JlcnQgV2lsdG9uIDwg DQo+IHJ3aWx0b249NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiANCj4gPiBI aSBUaW0sDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGNvbW1lbnRzIChhcyBhIG5vbiBhdXRob3IpIGlu bGluZSAuLi4NCj4gPg0KPiA+IE9uIDI5LzA4LzIwMTggMTY6MjgsIFl1dGlhbnBlbmcgKFRpbSkg d3JvdGU6DQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+IFNvbWUgY29tbWVudHMgYXMgYmVsb3c6DQo+ ID4NCj4gPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4g PiBUaGVyZSBpcyBvbmUgcG9pbnQgbWlzc2luZyBpbiB0aGUgZHJhZnQgc28gZmFyIEkgdGhpbms6 IHdoYXQgaWYgdGhlIA0KPiA+IHN1YnNjcmliZXIgaXMgdGhlIGluaXRpYXRvciBvZiB0aGUgY29u ZmlndXJhdGlvbiBjaGFuZ2VzPw0KPiA+DQo+ID4gSW4gdGhpcyBjYXNlLCB0aGUgc3Vic2NyaWJl ciBpcyBhd2FyZSBvZiBjb25maWd1cmF0aW9uIGNoYW5nZXMgDQo+ID4gaW5pdGlhdGVkIGJ5IGl0 c2VsZiB3aXRob3V0IHJlbHlpbmcgb24gdGhlIHB1c2ggbWVjaGFuaXNtLiANCj4gPiBJbnRyb2R1 Y2luZyBwdXNoIG1lY2hhbmlzbSB3aWxsIGRyYW1hdGljYWxseSBpbXBhY3QgdGhlIHBlcmZvcm1h bmNlIG9mIHRoZSBzeXN0ZW0gaW4gdGhpcyBjYXNlLg0KPiA+DQo+ID4gTXkgc3VnZ2VzdGlvbiBp czoNCj4gPg0KPiA+IDMuMy4gIE9uLUNoYW5nZSBDb25zaWRlcmF0aW9ucw0KPiA+DQo+ID4gICAg NS4gIElmIHRoZSByZXN1bHRpbmcgcGF0Y2ggcmVjb3JkIGlzIG5vbi1lbXB0eSwgYW5kIGl0IGNv bnRhaW5zIA0KPiA+IHRoZSByZWNvcmRzIG5vdCBpbml0aWF0ZWQgYnkgdGhlIHN1YnNjcmliZXIs IHNlbGVjdCB0aGVzZSByZWNvcmRzIA0KPiA+IGFuZCBzZW5kIHRvIGNvcnJlc3BvbmRpbmcgc3Vi c2NyaWJlci4NCj4gPg0KPiA+IFdlIGNhbiBoYXZlIGZ1cnRoZXIgZGlzY3Vzc2lvbiBvbiB0aGlz IHRvIG1ha2UgaXQgb3B0aW9uYWwgaW5zdGVhZCANCj4gPiBvZiBtYW5kYXRvcnkuDQo+ID4NCj4g PiBJJ20gbm90IGtlZW4gb24gdGhpcyBjaGFuZ2UuICBUaGlzIGRvZXMgbm90IHNlZW0gbGlrZSBh IGdvb2QgDQo+ID4gc2VwYXJhdGlvbiBvZiBjb25jZXJucy4gIEJlc2lkZXMsIEknbSBub3QgY29u dmluY2VkIHdoeSB0aGlzIHNob3VsZCANCj4gPiByZWFsbHkgYmUgYSBwZXJmb3JtYW5jZSBpc3N1 ZSBnaXZlbiB0aGF0IGNvbmZpZyBjaGFuZ2VzIGFyZSANCj4gPiByZWxhdGl2ZWx5IHJhcmUgY29t cGFyZWQgdG8gYWxsIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBpbiB0aGUgc3lzdGVtIHRoYXQgbWF5 IGJlIGNoYW5naW5nLg0KPiA+DQo+ID4NCj4gKzEgLS0gdGhpcyBjaGFuZ2Ugc2hvdWxkIG5vdCBi ZSBtYWRlLg0KPiBUaGlzIGlzIG5vdCBhIHVzZWZ1bCBvcHRpbWl6YXRpb24uDQoNCisxDQoNCjxU aW0+DQpJIG1pZ2h0IGhhdmVuJ3QgZXhwbGFpbiB0aGUgbWFpbiBjb25jZXJucyBvbiB0aGlzIGNs ZWFybHkuDQpXaGVuIEkgc2VlIFlhbmctcHVzaCwgSSBmaW5kIGl0IHZlcnkgdXNlZnVsIGFzIGl0 IHJlYWxseSBzb2x2ZXMgcHJvYmxlbXMgYWxsIE5NUy9jb250cm9sbGVycyBhcmUgZmFjaW5nLiBC dXQgSSBkbyBoYXZlIGEgY29uY2VybiBvbiB0aGUgcG9pbnQgSSBtZW50aW9uZWQuIA0KTGV0IG1l IGdpdmUgYW4gZXhhbXBsZSB0aGF0IFlhbmctUHVzaCBjYW4gYmUgdXNlZDoNCkJlZm9yZSBZYW5n LXB1c2g6DQpOTVMgaXMgdXNpbmcgTmV0Y29uZiB5YW5nIHRvIG1hbmFnZSBhIHJvdXRlcg0KTk1T IGlzIHVzaW5nIHBvbGxpbmcgbWVjaGFuaXNtIHRvIHN5bmMgY29uZmlnDQpBbnlvbmUgbWFrZSBj aGFuZ2VzIG5vdCB0aHJvdWdoIE5NUywgZS5nLiBDTEksIE5NUyBpcyBub3QgYXdhcmUgb2YgdGhl IGNoYW5nZSBpbiB0aW1lLiANCg0KQWZ0ZXIgWWFuZy1wdXNoOg0KTk1TIGlzIHVzaW5nIE5ldGNv bmYgeWFuZyB0byBtYW5hZ2UgYSByb3V0ZXINCk5NUyBpcyB1c2luZyBZYW5nLXB1c2ggbWVjaGFu aXNtIHRvIHN5bmMgY29uZmlndXJhdGlvbi4gSW4gb3JkZXIgdG8gbWFrZSBzdXJlIGFsbCBkYXRh YmFzZSBpbiBzeW5jIHN0YXRlLCA8cnVubmluZz4gZGF0YWJhc2UgaXMgc3Vic2NyaWJlZCAgLS0t IEkgYmVsaWV2ZSB0aGlzIGNvdWxkIGJlIGEgd2lkZWx5IHVzZSBjYXNlDQpJbiBjYXNlIGFueW9u ZSBtYWtlIGNoYW5nZXMgbm90IHRocm91Z2ggdGhlIE5NUywgY2hhbmdlcyB3aWxsIGJlIG5vdGlm aWVkIHRvIE5NUyB2aWEgcHVzaCBtZWNoYW5pc20uDQpXaXRoIHlhbmcgcHVzaCBzb2x1dGlvbiwg aXQgc29sdmVzIHJlc3RyaWN0aW9uIG9mIHBvbGxpbmcgbWVjaGFuaXNtIHByZXR0eSB3ZWxsLg0K QnV0IGFzIEkgZXhwbGFpbmVkLCB5YW5nIHB1c2ggbWVjaGFuaXNtIGhhcyBhbiBvYnZpb3VzIGRy YXdiYWNrLCBlYWNoIGNvbmZpZ3VyYXRpb24gZnJvbSBOTVMgd2lsbCBoYXZlIGEgcHVzaCBtZXNz YWdlIGJhY2sgdG8gTk1TLCB3aGljaCBpcyBub3QgbmVlZGVkIGluIG1hbnkgdXNlIHNjZW5hcmlv cy4gVGhpcyBiZWhhdmlvciBhY3R1YWxseSBpbXBhY3QgcGVyZm9ybWFuY2UgYSBsb3QuDQpJZiB0 aGlzIG1zZyBjYW4gYmUgZmlsdGVyZWQgZGlyZWN0bHkgd2l0aG91dCBnb2luZyB0aHJvdWdoIGFs bCBOZXRjb25mICtTU0gvVExTICsgVENQIHByb2Nlc3MsIHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUg c3Vic2NyaWJlciB3aWxsIGltcHJvdmUgYSBsb3QgSSBiZWxpZXZlLg0KQmFzZWQgb24gbXkgdW5k ZXJzdGFuZGluZyB5YW5nLXB1c2ggaXMgdG8gc29sdmUgcG9sbGluZyBsYXRlbmN5LCBidXQgaXQg c2hvdWxkIG5vdCBoYXZlIHNpZ25pZmljYW50IHBlcmZvcm1hbmNlIGltcGFjdCBvbiBleGlzdGlu ZyBhcHBsaWNhdGlvbnMuIElmIE5NUyBjb25maWd1cmUgYSBkZXZpY2Ugd2l0aCAxMDAwIGNoYW5n ZXMgYW5kIHRoZSBkZXZpY2UgcHVzaCAxMDAwIGNoYW5nZXMgYmFjayB0byBOTVMsIEkgZG9uJ3Qg dGhpbmsgdGhpcyBpcyBhbiBlbGVnYW50IGltcGxlbWVudGF0aW9uIHdoZW4gTmV0Y29uZiBoYXMg YWxyZWFkeSBwcm92aWRlIGVub3VnaCB0cmFuc2FjdGlvbiBtZWNoYW5pc20gaXRzZWxmLiBUaGUg aW1wYWN0IG9mIHB1c2ggbWVjaGFuaXNtIGlzIGl0IGltcGFjdCBwZXJmb3JtYW5jZSBvZiA5OSUg b2Ygc2NlbmFyaW8gKG5vcm1hbCBOTVMtPmRldmljZSBjb25maWd1cmUgcHJvY2VzcykgdG8gc29s dmUgMSUgb2YgdXNlIGNhc2UgKGNvbmZpZ3VyYXRpb24gbm90IHN5bmMgaW4gdGltZSkuIA0KSSB1 bmRlcnN0YW5kIHRoZSBkaWZmaWN1bHR5IG9mIGludHJvZHVjaW5nIGJpZyBjaGFuZ2VzIGF0IHRo aXMgc3RhZ2UsIGJ1dCBJIHJlYWxseSB3aXNoIHdlIGNhbiBoYXZlIGFuIGVsZWdhbnQgcHVzaCBt ZWNoYW5pc20uIEFwcHJlY2lhdGUgYW55IGNvbW1lbnRzIG9uIHRoaXMuDQo8L1RpbT4NCg0KPiA+ DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gQm90aCDi gJxzdWJzY3JpYmVy4oCdIGFuZCDigJxyZWNlaXZlcuKAnSBhcmUgdXNlZCwgYml0IGNvbmZ1c2lu ZyBzb21ldGltZXMuIA0KPiA+IFNoYWxsIHdlIG9ubHkgdXNlIOKAnHN1YnNjcmliZXLigJ0NCj4g Pg0KPiA+IFRoZXkgYXJlIGRpZmZlcmVudCBlbnRpdGllcywgdGhlIGRlZmluaXRpb25zIGFyZSBp bg0KPiA+IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM6DQo+ID4N Cj4gPiAgICBSZWNlaXZlcjogQSB0YXJnZXQgdG8gd2hpY2ggYSBwdWJsaXNoZXIgcHVzaGVzIHN1 YnNjcmliZWQgZXZlbnQNCj4gPiAgICByZWNvcmRzLiAgRm9yIGR5bmFtaWMgc3Vic2NyaXB0aW9u cywgdGhlIHJlY2VpdmVyIGFuZCBzdWJzY3JpYmVyIGFyZQ0KPiA+ICAgIHRoZSBzYW1lIGVudGl0 eS4NCj4gPg0KPiA+ICAgIFN1YnNjcmliZXI6IEEgY2xpZW50IGFibGUgdG8gcmVxdWVzdCBhbmQg bmVnb3RpYXRlIGEgY29udHJhY3QgZm9yIHRoZQ0KPiA+ICAgIGdlbmVyYXRpb24gYW5kIHB1c2gg b2YgZXZlbnQgcmVjb3JkcyBmcm9tIGEgcHVibGlzaGVyLiAgRm9yIGR5bmFtaWMNCj4gPiAgICBz dWJzY3JpcHRpb25zLCB0aGUgcmVjZWl2ZXIgYW5kIHN1YnNjcmliZXIgYXJlIHRoZSBzYW1lIGVu dGl0eS4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4NCj4gPiAzLjExLjEuICBSb2J1c3RuZXNzIGFuZCByZWxpYWJpbGl0eQ0KPiA+DQo+ ID4gICAgTm90ZTogSXQgaXMgcGVyZmVjdGx5IGFjY2VwdGFibGUgdG8gaGF2ZSBhIHNlcmllcyBv ZiANCj4gPiAicHVzaC1jaGFuZ2UtDQo+ID4NCj4gPiAgICB1cGRhdGUiIG5vdGlmaWNhdGlvbnMg KGFuZCBldmVuICJwdXNoIHVwZGF0ZSIgbm90aWZpY2F0aW9ucykgDQo+ID4gc2VyaWFsbHkNCj4g Pg0KPiA+ICAgIHF1ZXVlZCBhdCB0aGUgdHJhbnNwb3J0IGxheWVyIGF3YWl0aW5nIHRyYW5zbWlz c2lvbi4gIEl0IGlzIG5vdA0KPiA+DQo+ID4gICAgcmVxdWlyZWQgdG8gbWVyZ2UgcGVuZGluZyB1 cGRhdGUgcmVjb3Jkcy4gIEkuZS4sIHRoZSBkYW1wZW5pbmcgDQo+ID4gcGVyaW9kDQo+ID4NCj4g PiAgICBhcHBsaWVzIHRvIHVwZGF0ZSByZWNvcmQgY3JlYXRpb24sIG5vdCB0cmFuc21pc3Npb24u DQo+ID4NCj4gPiBNeSBzdWdnZXN0aW9uIGlzOg0KPiA+DQo+ID4gVGhlIHB1Ymxpc2hlciBzaG91 bGQgaW5jcmVhc2UgZGFtcGVuaW5nIHBlcmlvZCBhdXRvbWF0aWNhbGx5IGluIGNhc2UgDQo+ID4g dGhlIG1lc3NhZ2UgcXVldWUgcmVhY2hlcyBhIGxpbWl0Lg0KPiA+DQo+ID4gVGhpcyBpcyB0byBh dm9pZCBub3RpZmljYXRpb25zIGxvc3QgZHVlIHRvIHF1ZXVlIGxpbWl0IGluIGNhc2UgDQo+ID4g c3Vic2NyaWJlciBpcyBidXN5IG9yIHRlbXBvcmFyaWx5IHVucmVhY2hhYmxlLg0KPiA+DQo+ID4g SSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXMgaG93IHRoZSBkYW1wZW5pbmcgdGhhdCBpcyBjdXJy ZW50bHkgDQo+ID4gZGVmaW5lZCBzaG91bGQgd29yaywgc2luY2UgaXQgaXMgZXhwZWN0ZWQgdG8g cHJvdmlkZSBhIHN0cm9uZyANCj4gPiBndWFyYW50ZWUgdGhhdCBpdCB3aWxsIGVpdGhlciBkZWxp dmVyIHRoZSBub3RpZmljYXRpb25zIHRvIHRoZSANCj4gPiByZWNlaXZlciwgb3Igb3RoZXJ3aXNl IG5vdGlmeSB0byB0aGUgcmVjZWl2ZXIgdGhhdCBzb21lIHVwZGF0ZXMgW21heV0gaGF2ZSBiZWVu IGxvc3QuDQo+ID4NCj4gPiBJIGNvdWxkIGltYWdpbmUgdGhhdCBhbm90aGVyLCBzb2Z0ZXIgdHlw ZSBvZiBkYW1wZW5pbmcsIGNvdWxkIA0KPiA+IHBvdGVudGlhbGx5IGJlIGRlZmluZWQgaW4gZnV0 dXJlIGFzIGEgc2VwYXJhdGUgDQo+ID4gZXh0ZW5zaW9uL2F1Z21lbnRhdGlvbiwgYnV0IEkgZG9u J3QgdGhpbmsgdGhhdCBzaG91bGQgZ28gaW50byB0aGlzIA0KPiA+IGRvY3VtZW50LCBiZWNhdXNl IGl0IHdvdWxkIG1hc3NpdmVseSBzbG93IGl0IGRvd24sIGFuZCB0aGUgaW5kdXN0cnkgYWxyZWFk eSBuZWVkcyB0aGlzIHN0YW5kYXJkIG5vdy4NCj4gPg0KPiA+DQo+ICsxIC0tIHRoZSBzZXJ2ZXIg ZG9lcyB3aGF0IGl0IGlzIHRvbGQgYW5kIGRvZXMgbm90IGRlY2lkZSB0byBjaGFuZ2UgDQo+ICt0 aGUNCj4gc3Vic2NyaXB0aW9uIG9uIGl0cyBvd24NCg0KKzENCg0KDQovbWFydGluDQoNCj4gDQo+ IA0KPiANCj4gPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0K PiA+IEl0IHdvdWxkIGJlIGFwcHJlY2lhdGVkIGlmIHN1Z2dlc3Rpb25zIGNhbiBiZSBnaXZlbiBv biBob3cgcHVzaCANCj4gPiBzaGFsbCBiZSB1c2VkIG9uIHJ1bm5pbmcsIHN0YXJ0dXAgYW5kIGNh bmRpZGF0ZSBkYXRhc3RvcmVzDQo+ID4NCj4gPiBJdCBzaG91bGQgd29yayB0aGUgc2FtZSB3YXkg YXMgWUFORyBwdXNoIG9uIGFueSBvdGhlciBkYXRhc3RvcmUuICANCj4gPiBUaGUgbWVjaGFuaXNt IGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgc2VlbXMgdG8gYmUgZW50aXJlbHkgZGF0YXN0b3JlIGFn bm9zdGljLg0KPiA+IEluIHdoYXQgd2F5IGRvIHlvdSB0aGluayBpdCBtYXkgYmVoYXZlIGRpZmZl cmVudGx5Pw0KPiA+DQo+ID4gQWx0aG91Z2ggSSBjb3VsZCBpbWFnaW5lIHRoYXQgaW1wbGVtZW50 YXRpb25zIG1heSBub3Qgc3VwcG9ydCANCj4gPiBzdWJzY3JpcHRpb25zIG9uIHN0YXJ0dXAgb3Ig Y2FuZGlkYXRlLCBpbiB3aGljaCBjYXNlIEkgd291bGQgZXhwZWN0IA0KPiA+IHRoYXQgdGhlIHN1 YnNjcmlwdGlvbiB3b3VsZCBiZSByZWplY3RlZC4NCj4gPg0KPFRpbT4NClRoYW5rcyBSb2IuDQpJ IHRoaW5rIHlvdSB1bmRlcnN0YW5kIG15IGNvbmNlcm5zLiBUaGUgd2hvbGUgeWFuZyBwdXNoIG1l Y2hhbmlzbSBpcyBkYXRhc3RvcmUgYWdub3N0aWMuIA0KQnV0IG15IHBvc2l0aW9uIGlzOiBpZiB3 ZSBmb2xsb3cgdGhpcyBkcmFmdCwgSSBhbSBwcmV0dHkgc3VyZSBpbXBsZW1lbnRhdGlvbiBvZiB5 YW5nIHB1c2ggbGF0ZXIgd2lsbCBiZSBkaWZmZXJlbnQgYWNyb3NzIGFsbCB2ZW5kb3JzLiBTb21l b25lIHdpbGwgYWNjZXB0IHN1YnNjcmlwdGlvbiBvbiBzdGFydHVwIGJ1dCBvdGhlcnMgd2lsbCBy ZWplY3QuIFNvbWUgd2lsbCBzdXBwb3J0IHB1c2hpbmcgY2hhbmdlcyBvbiBjYW5kaWRhdGUgYnV0 IG90aGVycyBub3QuDQpJIGJlbGlldmUgdGhlIG9yaWdpbmFsIGludGVudGlvbiBvZiBOZXRjb25m IHRvIHByb3ZpZGUgYSBzdGFuZGFyZGl6ZWQgbWVjaGFuaXNtIGFuZCB3ZSBhcmUgYWxsIHdvcmtp bmcgdG8gc2NhbmRhbGl6ZWQgYXMgbXVjaCBhcyBwb3NzaWJsZSB0byBhbGxvdyBkaWZmZXJlbnQg dmVuZG9ycyB0byBoYXZlIGludGVyb3BlcmFiaWxpdHkgd2l0aCBlYWNoIG90aGVyLiANCklmIElF VEYgd29ya2luZyBncm91cCBjYW4gZ2l2ZSBpbnN0cnVjdGlvbnMgb24gaG93IHB1c2ggbWVjaGFu aXNtIGNhbiBiZSBhZG9wdGVkIHRvIGRpZmZlcmVudCBkYXRhc3RvcmVzIGluc3RlYWQgb2YgbGV0 IHZlbmRvcnMgbWFrZSBkZWNpc2lvbnMgdGhlbXNlbHZlcywgSSBiZWxpZXZlIHdlIGhhdmUgYSBz b2x1dGlvbiBlYXNpZXIgZ2V0IGludGVyb3BlcmF0ZWQuIA0KPC9UaW0+DQoNCg0KPiA+IFRoYW5r cywNCj4gPiBSb2INCj4gPg0KPiA+DQo+ID4NCj4gDQo+IEFuZHkNCj4gDQo+IA0KPiA+DQo+ID4N Cj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPg0KPiA+DQo+ID4g UmVnYXJkcywNCj4gPg0KPiA+IFRpbQ0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE5ldGNvbmYgbWFpbGluZyANCj4gPiBs aXN0TmV0Y29uZkBpZXRmLm9yZ2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0Y29uZg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiBOZXRjb25m QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj b25mDQo+ID4NCj4gPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Tue Sep 4 09:42:46 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4871E130F61 for ; Tue, 4 Sep 2018 09:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKFZX6FD4NaX for ; Tue, 4 Sep 2018 09:42:36 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8603130F52 for ; Tue, 4 Sep 2018 09:42:35 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id y17-v6so3720962ljy.8 for ; Tue, 04 Sep 2018 09:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SOT12eDZWiWtOWkHGNVdkMwkiyT1QoKmDSfZIUA6ymg=; b=U5mkAkviZbhRpCx3b7aXJfiEd/hRGm5xC2K2OSHZ9Lkunok+eRr4JA2hw/hWW9lGRn Fy/EaQh/YxAW3Jss8395cAuJeEM2xLwgSaULt+XdS+0o1e1yIADi23svtDawwIoQxuM8 jLKNDub3jzoK7zXXA8zmqaAhXNHyut1KDtRCquozSge+5gWfy9le+LVNxrwKirIldB/x YiMdf5jVNCTyDK1w9JL1saStrSCB+VueUY6SjBHuC4KW3XJlrZVIi3Iy7GdvBZnOGhia NRWzXOmyLrAues65SsnyOMKXtV608SYTdmeUESlut7hvYCR28BJHNb9s4alK0gmhtPdM MI2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SOT12eDZWiWtOWkHGNVdkMwkiyT1QoKmDSfZIUA6ymg=; b=o0/l7C0DuKZ1/sV0ZdRUfcmFUz5cx7TGDkLXiZAwuqhelHooDMju0KL3m1ObL1MOt0 mAwhpxrrRqbiwMCZhgRT4h0B/gbMZ+o9e9wEAUjC08oPYrWn2A+y7NPmEPMEbIZnbDNO rDcrJUWa+kZgtvt2gpMfEyHut0sknJOpOt19ck/SB6KZ/VKbtDerC/G5FyJspkA3g0ry cHfzhvltThwWxPwz3NYQOJR62+cwPEtJGb6f6xxSMftjz7D6mUeCA7DYiyvUw8+/ZAyi URo0r9AM6MXkL5XbG6k0blwd733sq/q/jsATXwd3SjFCExz9PBTGPsn1DrDikwBLfec2 WVUg== X-Gm-Message-State: APzg51DyGuR1b19Fhz+c8m09LClNW+eQpmueot0SWd8MGQeixn4VJgYP KLSJEZ/XEuMauXLXM1SNbuBVj2FosM4fE+Rk/Du729FIXzo= X-Google-Smtp-Source: ANB0VdazetPV48exmWK7c4KiTjQId8X6+lQRjAAB9G3gEW1nkb65ihufW5HBZ/uc8YgqHK1qucMhc0/fBp/Lfi0xRrg= X-Received: by 2002:a2e:8652:: with SMTP id i18-v6mr17907732ljj.43.1536079353969; Tue, 04 Sep 2018 09:42:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:5116:0:0:0:0:0 with HTTP; Tue, 4 Sep 2018 09:42:32 -0700 (PDT) In-Reply-To: <35FF0D51C8DAB54B95B0426331F984FF52045B7E@lhreml523-mbs.china.huawei.com> References: <35FF0D51C8DAB54B95B0426331F984FF520433B2@lhreml523-mbs.china.huawei.com> <20180904.173343.771736120417698474.mbj@tail-f.com> <35FF0D51C8DAB54B95B0426331F984FF52045B7E@lhreml523-mbs.china.huawei.com> From: Andy Bierman Date: Tue, 4 Sep 2018 09:42:32 -0700 Message-ID: To: "Yutianpeng (Tim)" Cc: Martin Bjorklund , "netconf@ietf.org" , "rwilton=40cisco.com@dmarc.ietf.org" Content-Type: multipart/alternative; boundary="0000000000003dae9105750e580f" Archived-At: Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 16:42:40 -0000 --0000000000003dae9105750e580f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 4, 2018 at 9:20 AM, Yutianpeng (Tim) wrote: > Hi, > Thanks for reply. > Some explanations as below, please check. > Tim > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin > Bjorklund > Sent: 04 September 2018 16:34 > To: andy@yumaworks.com > Cc: netconf@ietf.org; rwilton=3D40cisco.com@dmarc.ietf.org > Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18 > > Andy Bierman wrote: > > On Tue, Sep 4, 2018 at 8:22 AM, Robert Wilton < > > rwilton=3D40cisco.com@dmarc.ietf.org> wrote: > > > > > Hi Tim, > > > > > > Please see comments (as a non author) inline ... > > > > > > On 29/08/2018 16:28, Yutianpeng (Tim) wrote: > > > > > > Hi, > > > > > > Some comments as below: > > > > > > > > > > > > ------------------------------ > > > > > > There is one point missing in the draft so far I think: what if the > > > subscriber is the initiator of the configuration changes? > > > > > > In this case, the subscriber is aware of configuration changes > > > initiated by itself without relying on the push mechanism. > > > Introducing push mechanism will dramatically impact the performance o= f > the system in this case. > > > > > > My suggestion is: > > > > > > 3.3. On-Change Considerations > > > > > > 5. If the resulting patch record is non-empty, and it contains > > > the records not initiated by the subscriber, select these records > > > and send to corresponding subscriber. > > > > > > We can have further discussion on this to make it optional instead > > > of mandatory. > > > > > > I'm not keen on this change. This does not seem like a good > > > separation of concerns. Besides, I'm not convinced why this should > > > really be a performance issue given that config changes are > > > relatively rare compared to all the operational state in the system > that may be changing. > > > > > > > > +1 -- this change should not be made. > > This is not a useful optimization. > > +1 > > > I might haven't explain the main concerns on this clearly. > When I see Yang-push, I find it very useful as it really solves problems > all NMS/controllers are facing. But I do have a concern on the point I > mentioned. > Let me give an example that Yang-Push can be used: > Before Yang-push: > NMS is using Netconf yang to manage a router > NMS is using polling mechanism to sync config > Anyone make changes not through NMS, e.g. CLI, NMS is not aware of the > change in time. > > After Yang-push: > NMS is using Netconf yang to manage a router > NMS is using Yang-push mechanism to sync configuration. In order to make > sure all database in sync state, database is subscribed --- I > believe this could be a widely use case > In case anyone make changes not through the NMS, changes will be notified > to NMS via push mechanism. > With yang push solution, it solves restriction of polling mechanism prett= y > well. > But as I explained, yang push mechanism has an obvious drawback, each > configuration from NMS will have a push message back to NMS, which is not > needed in many use scenarios. This behavior actually impact performance a > lot. > If this msg can be filtered directly without going through all Netconf > +SSH/TLS + TCP process, the performance of the subscriber will improve a > lot I believe. > Based on my understanding yang-push is to solve polling latency, but it > should not have significant performance impact on existing applications. = If > NMS configure a device with 1000 changes and the device push 1000 changes > back to NMS, I don't think this is an elegant implementation when Netconf > has already provide enough transaction mechanism itself. The impact of pu= sh > mechanism is it impact performance of 99% of scenario (normal NMS->device > configure process) to solve 1% of use case (configuration not sync in > time). > I understand the difficulty of introducing big changes at this stage, but > I really wish we can have an elegant push mechanism. Appreciate any > comments on this. > > > You are assuming the code that changed the configuration is also the code that implements the YP subscriber function, and there is some internal optimization to update the data maintained by the subscriber. The standard imposes no such requirement -- the subscriber code can be completely independent of all other network management -- this goes for server-side as well. Andy > > > > > > > > > ----------------------------- > > > > > > Both =E2=80=9Csubscriber=E2=80=9D and =E2=80=9Creceiver=E2=80=9D are = used, bit confusing sometimes. > > > Shall we only use =E2=80=9Csubscriber=E2=80=9D > > > > > > They are different entities, the definitions are in > > > draft-ietf-netconf-subscribed-notifications: > > > > > > Receiver: A target to which a publisher pushes subscribed event > > > records. For dynamic subscriptions, the receiver and subscriber a= re > > > the same entity. > > > > > > Subscriber: A client able to request and negotiate a contract for > the > > > generation and push of event records from a publisher. For dynami= c > > > subscriptions, the receiver and subscriber are the same entity. > > > > > > > > > > > > > > > > > > ------------------------ > > > > > > 3.11.1. Robustness and reliability > > > > > > Note: It is perfectly acceptable to have a series of > > > "push-change- > > > > > > update" notifications (and even "push update" notifications) > > > serially > > > > > > queued at the transport layer awaiting transmission. It is not > > > > > > required to merge pending update records. I.e., the dampening > > > period > > > > > > applies to update record creation, not transmission. > > > > > > My suggestion is: > > > > > > The publisher should increase dampening period automatically in case > > > the message queue reaches a limit. > > > > > > This is to avoid notifications lost due to queue limit in case > > > subscriber is busy or temporarily unreachable. > > > > > > I don't think that this is how the dampening that is currently > > > defined should work, since it is expected to provide a strong > > > guarantee that it will either deliver the notifications to the > > > receiver, or otherwise notify to the receiver that some updates [may] > have been lost. > > > > > > I could imagine that another, softer type of dampening, could > > > potentially be defined in future as a separate > > > extension/augmentation, but I don't think that should go into this > > > document, because it would massively slow it down, and the industry > already needs this standard now. > > > > > > > > +1 -- the server does what it is told and does not decide to change > > +the > > subscription on its own > > +1 > > > /martin > > > > > > > > > > > > > > > > ----------------------------- > > > > > > It would be appreciated if suggestions can be given on how push > > > shall be used on running, startup and candidate datastores > > > > > > It should work the same way as YANG push on any other datastore. > > > The mechanism described in the draft seems to be entirely datastore > agnostic. > > > In what way do you think it may behave differently? > > > > > > Although I could imagine that implementations may not support > > > subscriptions on startup or candidate, in which case I would expect > > > that the subscription would be rejected. > > > > > Thanks Rob. > I think you understand my concerns. The whole yang push mechanism is > datastore agnostic. > But my position is: if we follow this draft, I am pretty sure > implementation of yang push later will be different across all vendors. > Someone will accept subscription on startup but others will reject. Some > will support pushing changes on candidate but others not. > I believe the original intention of Netconf to provide a standardized > mechanism and we are all working to scandalized as much as possible to > allow different vendors to have interoperability with each other. > If IETF working group can give instructions on how push mechanism can be > adopted to different datastores instead of let vendors make decisions > themselves, I believe we have a solution easier get interoperated. > > > > > > Thanks, > > > Rob > > > > > > > > > > > > > Andy > > > > > > > > > > > > > ------------------------------- > > > > > > > > > > > > Regards, > > > > > > Tim > > > > > > > > > _______________________________________________ > > > Netconf mailing > > > listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --0000000000003dae9105750e580f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 4, 2018 at 9:20 AM, Yutianpeng (Tim) <yutianpeng@huawei.com> wrote:
Hi,
Thanks for reply.
Some explanations as below, please check.
Tim

-----Original Message-----
From: Netconf [mailto:netconf-b= ounces@ietf.org] On Behalf Of Martin Bjorklund
Sent: 04 September 2018 16:34
To: andy@yumaworks.com
Cc: netconf@ietf.org; rwilton=3D40cisco.com@dmarc.ietf.org<= /a>
Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18

Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Sep 4, 2018 at 8:22 AM, Robert Wilton <
> rwilton=3D40cisco.com@dm= arc.ietf.org> wrote:
>
> > Hi Tim,
> >
> > Please see comments (as a non author) inline ...
> >
> > On 29/08/2018 16:28, Yutianpeng (Tim) wrote:
> >
> > Hi,
> >
> > Some comments as below:
> >
> >
> >
> > ------------------------------
> >
> > There is one point missing in the draft so far I think: what if t= he
> > subscriber is the initiator of the configuration changes?
> >
> > In this case, the subscriber is aware of configuration changes > > initiated by itself without relying on the push mechanism.
> > Introducing push mechanism will dramatically impact the performan= ce of the system in this case.
> >
> > My suggestion is:
> >
> > 3.3.=C2=A0 On-Change Considerations
> >
> >=C2=A0 =C2=A0 5.=C2=A0 If the resulting patch record is non-empty,= and it contains
> > the records not initiated by the subscriber, select these records=
> > and send to corresponding subscriber.
> >
> > We can have further discussion on this to make it optional instea= d
> > of mandatory.
> >
> > I'm not keen on this change.=C2=A0 This does not seem like a = good
> > separation of concerns.=C2=A0 Besides, I'm not convinced why = this should
> > really be a performance issue given that config changes are
> > relatively rare compared to all the operational state in the syst= em that may be changing.
> >
> >
> +1 -- this change should not be made.
> This is not a useful optimization.

+1

<Tim>
I might haven't explain the main concerns on this clearly.
When I see Yang-push, I find it very useful as it really solves problems al= l NMS/controllers are facing. But I do have a concern on the point I mentio= ned.
Let me give an example that Yang-Push can be used:
Before Yang-push:
NMS is using Netconf yang to manage a router
NMS is using polling mechanism to sync config
Anyone make changes not through NMS, e.g. CLI, NMS is not aware of the chan= ge in time.

After Yang-push:
NMS is using Netconf yang to manage a router
NMS is using Yang-push mechanism to sync configuration. In order to make su= re all database in sync state, <running> database is subscribed=C2=A0= --- I believe this could be a widely use case
In case anyone make changes not through the NMS, changes will be notified t= o NMS via push mechanism.
With yang push solution, it solves restriction of polling mechanism pretty = well.
But as I explained, yang push mechanism has an obvious drawback, each confi= guration from NMS will have a push message back to NMS, which is not needed= in many use scenarios. This behavior actually impact performance a lot. If this msg can be filtered directly without going through all Netconf +SSH= /TLS + TCP process, the performance of the subscriber will improve a lot I = believe.
Based on my understanding yang-push is to solve polling latency, but it sho= uld not have significant performance impact on existing applications. If NM= S configure a device with 1000 changes and the device push 1000 changes bac= k to NMS, I don't think this is an elegant implementation when Netconf = has already provide enough transaction mechanism itself. The impact of push= mechanism is it impact performance of 99% of scenario (normal NMS->devi= ce configure process) to solve 1% of use case (configuration not sync in ti= me).
I understand the difficulty of introducing big changes at this stage, but I= really wish we can have an elegant push mechanism. Appreciate any comments= on this.
</Tim>



You are assuming the co= de that changed the configuration is also the code that implements
the YP subscriber function, and there is some internal optimization to up= date the data maintained
by the subscriber.

<= div>The standard imposes no such requirement -- the subscriber code can be = completely independent
of all other network management -- this go= es for server-side as well.


Andy

=C2=A0
> >
> >
> > -----------------------------
> >
> > Both =E2=80=9Csubscriber=E2=80=9D and =E2=80=9Creceiver=E2=80=9D = are used, bit confusing sometimes.
> > Shall we only use =E2=80=9Csubscriber=E2=80=9D
> >
> > They are different entities, the definitions are in
> > draft-ietf-netconf-subscribed-notifications:
> >
> >=C2=A0 =C2=A0 Receiver: A target to which a publisher pushes subsc= ribed event
> >=C2=A0 =C2=A0 records.=C2=A0 For dynamic subscriptions, the receiv= er and subscriber are
> >=C2=A0 =C2=A0 the same entity.
> >
> >=C2=A0 =C2=A0 Subscriber: A client able to request and negotiate a= contract for the
> >=C2=A0 =C2=A0 generation and push of event records from a publishe= r.=C2=A0 For dynamic
> >=C2=A0 =C2=A0 subscriptions, the receiver and subscriber are the s= ame entity.
> >
> >
> >
> >
> >
> > ------------------------
> >
> > 3.11.1.=C2=A0 Robustness and reliability
> >
> >=C2=A0 =C2=A0 Note: It is perfectly acceptable to have a series of=
> > "push-change-
> >
> >=C2=A0 =C2=A0 update" notifications (and even "push upda= te" notifications)
> > serially
> >
> >=C2=A0 =C2=A0 queued at the transport layer awaiting transmission.= =C2=A0 It is not
> >
> >=C2=A0 =C2=A0 required to merge pending update records.=C2=A0 I.e.= , the dampening
> > period
> >
> >=C2=A0 =C2=A0 applies to update record creation, not transmission.=
> >
> > My suggestion is:
> >
> > The publisher should increase dampening period automatically in c= ase
> > the message queue reaches a limit.
> >
> > This is to avoid notifications lost due to queue limit in case > > subscriber is busy or temporarily unreachable.
> >
> > I don't think that this is how the dampening that is currentl= y
> > defined should work, since it is expected to provide a strong > > guarantee that it will either deliver the notifications to the > > receiver, or otherwise notify to the receiver that some updates [= may] have been lost.
> >
> > I could imagine that another, softer type of dampening, could > > potentially be defined in future as a separate
> > extension/augmentation, but I don't think that should go into= this
> > document, because it would massively slow it down, and the indust= ry already needs this standard now.
> >
> >
> +1 -- the server does what it is told and does not decide to change > +the
> subscription on its own

+1


/martin

>
>
>
> >
> >
> > -----------------------------
> >
> > It would be appreciated if suggestions can be given on how push <= br> > > shall be used on running, startup and candidate datastores
> >
> > It should work the same way as YANG push on any other datastore.= =C2=A0
> > The mechanism described in the draft seems to be entirely datasto= re agnostic.
> > In what way do you think it may behave differently?
> >
> > Although I could imagine that implementations may not support > > subscriptions on startup or candidate, in which case I would expe= ct
> > that the subscription would be rejected.
> >
<Tim>
Thanks Rob.
I think you understand my concerns. The whole yang push mechanism is datast= ore agnostic.
But my position is: if we follow this draft, I am pretty sure implementatio= n of yang push later will be different across all vendors. Someone will acc= ept subscription on startup but others will reject. Some will support pushi= ng changes on candidate but others not.
I believe the original intention of Netconf to provide a standardized mecha= nism and we are all working to scandalized as much as possible to allow dif= ferent vendors to have interoperability with each other.
If IETF working group can give instructions on how push mechanism can be ad= opted to different datastores instead of let vendors make decisions themsel= ves, I believe we have a solution easier get interoperated.
</Tim>


> > Thanks,
> > Rob
> >
> >
> >
>
> Andy
>
>
> >
> >
> > -------------------------------
> >
> >
> >
> > Regards,
> >
> > Tim
> >
> >
> > _______________________________________________
> > Netconf mailing
> > listNetconf@ietf.orghttps://www.ietf.org/= mailman/listinfo/netconf
> >
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ne= tconf
> >
> >
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf<= br>

--0000000000003dae9105750e580f-- From nobody Tue Sep 4 09:53:55 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1C6130F63 for ; Tue, 4 Sep 2018 09:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_MED=-0.01, 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 fcaVzg91P4ns for ; Tue, 4 Sep 2018 09:53:51 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A49130F52 for ; Tue, 4 Sep 2018 09:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9618; q=dns/txt; s=iport; t=1536080031; x=1537289631; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=EXmE5bSaYsXBA5t3oGKr5myXMZ/yRXYPgcm4Hx+Ndr8=; b=Kd7cQEj81ecTk5xbl1nZhnGMhuqLWx5AKhDeLGdUDuxdVv+hVYEmjWbS mgGWq0DZ+X0RG52x2fFU/t4s8Mj8H5aco+ti5WMRgAtZSlEX0nisfd5it RTk4/QgW6/GrQEGyzuh0mVV1SxTiOEcZd4rp1mnakGGjOzhf2AWtOmDZ6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AQC6t45b/xbLJq1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMfBYEPbRIog3KIcY04JXiXLwsYC4QDRgKDWDcVAQIBAQI?= =?us-ascii?q?BAQJtHAyFNwEBAQQBASEECwEFNgYFDAQLEQQBAQECAgkaAwICJx8JCAYBDAY?= =?us-ascii?q?CAQEFEoI7SwGCAQ+jLHszhGyFFoELiWSBQT+BEicMgio1gj1TCwEBAoErDhC?= =?us-ascii?q?DF4JXAod6IR+GKoxyCYkvhkQGF4FAhDeCV4YLiDyFOoVvgVciQYEUMxoIGxU?= =?us-ascii?q?7gmwJiwyFPz4wAYpjASUEgiABAQ?= X-IronPort-AV: E=Sophos;i="5.53,329,1531785600"; d="scan'208";a="6331070" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2018 16:53:47 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w84GrjWp020444; Tue, 4 Sep 2018 16:53:46 GMT To: "Yutianpeng (Tim)" , "netconf@ietf.org" References: <35FF0D51C8DAB54B95B0426331F984FF520433B2@lhreml523-mbs.china.huawei.com> <20180904.173343.771736120417698474.mbj@tail-f.com> <35FF0D51C8DAB54B95B0426331F984FF52045B7E@lhreml523-mbs.china.huawei.com> From: Robert Wilton Message-ID: <3855125a-3b54-3fa0-1762-dea1f45d6a75@cisco.com> Date: Tue, 4 Sep 2018 17:53:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <35FF0D51C8DAB54B95B0426331F984FF52045B7E@lhreml523-mbs.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 16:53:54 -0000 Hi Tim, Please see inline ... On 04/09/2018 17:20, Yutianpeng (Tim) wrote: > Hi, > Thanks for reply. > Some explanations as below, please check. > Tim > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: 04 September 2018 16:34 > To: andy@yumaworks.com > Cc: netconf@ietf.org; rwilton=40cisco.com@dmarc.ietf.org > Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18 > > Andy Bierman wrote: >> On Tue, Sep 4, 2018 at 8:22 AM, Robert Wilton < >> rwilton=40cisco.com@dmarc.ietf.org> wrote: >> >>> Hi Tim, >>> >>> Please see comments (as a non author) inline ... >>> >>> On 29/08/2018 16:28, Yutianpeng (Tim) wrote: >>> >>> Hi, >>> >>> Some comments as below: >>> >>> >>> >>> ------------------------------ >>> >>> There is one point missing in the draft so far I think: what if the >>> subscriber is the initiator of the configuration changes? >>> >>> In this case, the subscriber is aware of configuration changes >>> initiated by itself without relying on the push mechanism. >>> Introducing push mechanism will dramatically impact the performance of the system in this case. >>> >>> My suggestion is: >>> >>> 3.3. On-Change Considerations >>> >>> 5. If the resulting patch record is non-empty, and it contains >>> the records not initiated by the subscriber, select these records >>> and send to corresponding subscriber. >>> >>> We can have further discussion on this to make it optional instead >>> of mandatory. >>> >>> I'm not keen on this change. This does not seem like a good >>> separation of concerns. Besides, I'm not convinced why this should >>> really be a performance issue given that config changes are >>> relatively rare compared to all the operational state in the system that may be changing. >>> >>> >> +1 -- this change should not be made. >> This is not a useful optimization. > +1 > > > I might haven't explain the main concerns on this clearly. > When I see Yang-push, I find it very useful as it really solves problems all NMS/controllers are facing. But I do have a concern on the point I mentioned. > Let me give an example that Yang-Push can be used: > Before Yang-push: > NMS is using Netconf yang to manage a router > NMS is using polling mechanism to sync config > Anyone make changes not through NMS, e.g. CLI, NMS is not aware of the change in time. > > After Yang-push: > NMS is using Netconf yang to manage a router > NMS is using Yang-push mechanism to sync configuration. In order to make sure all database in sync state, database is subscribed --- I believe this could be a widely use case > In case anyone make changes not through the NMS, changes will be notified to NMS via push mechanism. > With yang push solution, it solves restriction of polling mechanism pretty well. > But as I explained, yang push mechanism has an obvious drawback, each configuration from NMS will have a push message back to NMS, which is not needed in many use scenarios. This behavior actually impact performance a lot. > If this msg can be filtered directly without going through all Netconf +SSH/TLS + TCP process, the performance of the subscriber will improve a lot I believe. > Based on my understanding yang-push is to solve polling latency, but it should not have significant performance impact on existing applications. If NMS configure a device with 1000 changes and the device push 1000 changes back to NMS, I don't think this is an elegant implementation when Netconf has already provide enough transaction mechanism itself. The impact of push mechanism is it impact performance of 99% of scenario (normal NMS->device configure process) to solve 1% of use case (configuration not sync in time). > I understand the difficulty of introducing big changes at this stage, but I really wish we can have an elegant push mechanism. Appreciate any comments on this. (1) I'm not convinced that this will be a performance problem, particularly if dampening is applied to the subscription, or a periodic subscription is used instead.  I.e. I see that YANG push performance should be no worse than polling, and I anticipate that it will be significantly better. (2) The YANG push draft is already 4 years old. I think that we must just finish what we are working on now, then we can discuss extensions/future work. If we keep churning the requirements and solution then we just end up with no solution, and the market looks elsewhere (as is already happening) So, my pragmatic suggestion is:  - we collectively try not to get side-tracked discussing this in detail now,  - implement it as it is defined in the draft,  - benchmark it to see how it performs (perhaps also compare to performance if JSON, or CBOR is used as an encoding as well),  - if it really performs poorly (that is not due to implementation), then write up an ID describing the problem (including why dampening/periodic subscriptions don't help), with figures to back it up, etc,  - the WG can then evaluate whether this is really a problem that needs to be solved, and if it does then someone can write a draft proposing an appropriate solution. Does that seem reasonable? Thanks, Rob > > >>> >>> ----------------------------- >>> >>> Both “subscriber†and “receiver†are used, bit confusing sometimes. >>> Shall we only use “subscriber†>>> >>> They are different entities, the definitions are in >>> draft-ietf-netconf-subscribed-notifications: >>> >>> Receiver: A target to which a publisher pushes subscribed event >>> records. For dynamic subscriptions, the receiver and subscriber are >>> the same entity. >>> >>> Subscriber: A client able to request and negotiate a contract for the >>> generation and push of event records from a publisher. For dynamic >>> subscriptions, the receiver and subscriber are the same entity. >>> >>> >>> >>> >>> >>> ------------------------ >>> >>> 3.11.1. Robustness and reliability >>> >>> Note: It is perfectly acceptable to have a series of >>> "push-change- >>> >>> update" notifications (and even "push update" notifications) >>> serially >>> >>> queued at the transport layer awaiting transmission. It is not >>> >>> required to merge pending update records. I.e., the dampening >>> period >>> >>> applies to update record creation, not transmission. >>> >>> My suggestion is: >>> >>> The publisher should increase dampening period automatically in case >>> the message queue reaches a limit. >>> >>> This is to avoid notifications lost due to queue limit in case >>> subscriber is busy or temporarily unreachable. >>> >>> I don't think that this is how the dampening that is currently >>> defined should work, since it is expected to provide a strong >>> guarantee that it will either deliver the notifications to the >>> receiver, or otherwise notify to the receiver that some updates [may] have been lost. >>> >>> I could imagine that another, softer type of dampening, could >>> potentially be defined in future as a separate >>> extension/augmentation, but I don't think that should go into this >>> document, because it would massively slow it down, and the industry already needs this standard now. >>> >>> >> +1 -- the server does what it is told and does not decide to change >> +the >> subscription on its own > +1 > > > /martin > >> >> >>> >>> ----------------------------- >>> >>> It would be appreciated if suggestions can be given on how push >>> shall be used on running, startup and candidate datastores >>> >>> It should work the same way as YANG push on any other datastore. >>> The mechanism described in the draft seems to be entirely datastore agnostic. >>> In what way do you think it may behave differently? >>> >>> Although I could imagine that implementations may not support >>> subscriptions on startup or candidate, in which case I would expect >>> that the subscription would be rejected. >>> > > Thanks Rob. > I think you understand my concerns. The whole yang push mechanism is datastore agnostic. > But my position is: if we follow this draft, I am pretty sure implementation of yang push later will be different across all vendors. Someone will accept subscription on startup but others will reject. Some will support pushing changes on candidate but others not. > I believe the original intention of Netconf to provide a standardized mechanism and we are all working to scandalized as much as possible to allow different vendors to have interoperability with each other. > If IETF working group can give instructions on how push mechanism can be adopted to different datastores instead of let vendors make decisions themselves, I believe we have a solution easier get interoperated. > > > >>> Thanks, >>> Rob >>> >>> >>> >> Andy >> >> >>> >>> ------------------------------- >>> >>> >>> >>> Regards, >>> >>> Tim >>> >>> >>> _______________________________________________ >>> Netconf mailing >>> listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 4 10:23:00 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5890130F7C for ; Tue, 4 Sep 2018 10:22:58 -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 2m4cyRilNqSD for ; Tue, 4 Sep 2018 10:22:56 -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 10D26130F56 for ; Tue, 4 Sep 2018 10:22:56 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1F50072C3942A; Tue, 4 Sep 2018 18:22:51 +0100 (IST) Received: from LHREML523-MBS.china.huawei.com ([169.254.9.45]) by lhreml708-cah.china.huawei.com ([10.201.108.49]) with mapi id 14.03.0399.000; Tue, 4 Sep 2018 18:22:50 +0100 From: "Yutianpeng (Tim)" To: Robert Wilton , "netconf@ietf.org" Thread-Topic: [Netconf] Comments on draft-ietf-netconf-yang-push-18 Thread-Index: AdQ/rOk2O9B1aMu7RrSnvHTptxxrnQErdiaAAAAqBoAAADdugAACTR5QAAB+cIAAAwURkA== Date: Tue, 4 Sep 2018 17:22:50 +0000 Message-ID: <35FF0D51C8DAB54B95B0426331F984FF52045BDE@lhreml523-mbs.china.huawei.com> References: <35FF0D51C8DAB54B95B0426331F984FF520433B2@lhreml523-mbs.china.huawei.com> <20180904.173343.771736120417698474.mbj@tail-f.com> <35FF0D51C8DAB54B95B0426331F984FF52045B7E@lhreml523-mbs.china.huawei.com> <3855125a-3b54-3fa0-1762-dea1f45d6a75@cisco.com> In-Reply-To: <3855125a-3b54-3fa0-1762-dea1f45d6a75@cisco.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.203.126.98] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 17:22:59 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb2JlcnQgV2lsdG9uIFttYWls dG86cndpbHRvbkBjaXNjby5jb21dIA0KU2VudDogMDQgU2VwdGVtYmVyIDIwMTggMTc6NTQNClRv OiBZdXRpYW5wZW5nIChUaW0pIDx5dXRpYW5wZW5nQGh1YXdlaS5jb20+OyBuZXRjb25mQGlldGYu b3JnDQpDYzogTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+OyBhbmR5QHl1bWF3b3Jr cy5jb20NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1uZXRj b25mLXlhbmctcHVzaC0xOA0KDQpIaSBUaW0sDQoNClBsZWFzZSBzZWUgaW5saW5lIC4uLg0KDQoN Ck9uIDA0LzA5LzIwMTggMTc6MjAsIFl1dGlhbnBlbmcgKFRpbSkgd3JvdGU6DQo+IEhpLA0KPiBU aGFua3MgZm9yIHJlcGx5Lg0KPiBTb21lIGV4cGxhbmF0aW9ucyBhcyBiZWxvdywgcGxlYXNlIGNo ZWNrLg0KPiBUaW0NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTmV0 Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnRp biANCj4gQmpvcmtsdW5kDQo+IFNlbnQ6IDA0IFNlcHRlbWJlciAyMDE4IDE2OjM0DQo+IFRvOiBh bmR5QHl1bWF3b3Jrcy5jb20NCj4gQ2M6IG5ldGNvbmZAaWV0Zi5vcmc7IHJ3aWx0b249NDBjaXNj by5jb21AZG1hcmMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBDb21tZW50cyBv biBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTE4DQo+DQo+IEFuZHkgQmllcm1hbiA8YW5k eUB5dW1hd29ya3MuY29tPiB3cm90ZToNCj4+IE9uIFR1ZSwgU2VwIDQsIDIwMTggYXQgODoyMiBB TSwgUm9iZXJ0IFdpbHRvbiA8IA0KPj4gcndpbHRvbj00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9y Zz4gd3JvdGU6DQo+Pg0KPj4+IEhpIFRpbSwNCj4+Pg0KPj4+IFBsZWFzZSBzZWUgY29tbWVudHMg KGFzIGEgbm9uIGF1dGhvcikgaW5saW5lIC4uLg0KPj4+DQo+Pj4gT24gMjkvMDgvMjAxOCAxNjoy OCwgWXV0aWFucGVuZyAoVGltKSB3cm90ZToNCj4+Pg0KPj4+IEhpLA0KPj4+DQo+Pj4gU29tZSBj b21tZW50cyBhcyBiZWxvdzoNCj4+Pg0KPj4+DQo+Pj4NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+Pg0KPj4+IFRoZXJlIGlzIG9uZSBwb2ludCBtaXNzaW5nIGluIHRoZSBk cmFmdCBzbyBmYXIgSSB0aGluazogd2hhdCBpZiB0aGUgDQo+Pj4gc3Vic2NyaWJlciBpcyB0aGUg aW5pdGlhdG9yIG9mIHRoZSBjb25maWd1cmF0aW9uIGNoYW5nZXM/DQo+Pj4NCj4+PiBJbiB0aGlz IGNhc2UsIHRoZSBzdWJzY3JpYmVyIGlzIGF3YXJlIG9mIGNvbmZpZ3VyYXRpb24gY2hhbmdlcyAN Cj4+PiBpbml0aWF0ZWQgYnkgaXRzZWxmIHdpdGhvdXQgcmVseWluZyBvbiB0aGUgcHVzaCBtZWNo YW5pc20uDQo+Pj4gSW50cm9kdWNpbmcgcHVzaCBtZWNoYW5pc20gd2lsbCBkcmFtYXRpY2FsbHkg aW1wYWN0IHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgc3lzdGVtIGluIHRoaXMgY2FzZS4NCj4+Pg0K Pj4+IE15IHN1Z2dlc3Rpb24gaXM6DQo+Pj4NCj4+PiAzLjMuICBPbi1DaGFuZ2UgQ29uc2lkZXJh dGlvbnMNCj4+Pg0KPj4+ICAgICA1LiAgSWYgdGhlIHJlc3VsdGluZyBwYXRjaCByZWNvcmQgaXMg bm9uLWVtcHR5LCBhbmQgaXQgY29udGFpbnMgDQo+Pj4gdGhlIHJlY29yZHMgbm90IGluaXRpYXRl ZCBieSB0aGUgc3Vic2NyaWJlciwgc2VsZWN0IHRoZXNlIHJlY29yZHMgDQo+Pj4gYW5kIHNlbmQg dG8gY29ycmVzcG9uZGluZyBzdWJzY3JpYmVyLg0KPj4+DQo+Pj4gV2UgY2FuIGhhdmUgZnVydGhl ciBkaXNjdXNzaW9uIG9uIHRoaXMgdG8gbWFrZSBpdCBvcHRpb25hbCBpbnN0ZWFkIA0KPj4+IG9m IG1hbmRhdG9yeS4NCj4+Pg0KPj4+IEknbSBub3Qga2VlbiBvbiB0aGlzIGNoYW5nZS4gIFRoaXMg ZG9lcyBub3Qgc2VlbSBsaWtlIGEgZ29vZCANCj4+PiBzZXBhcmF0aW9uIG9mIGNvbmNlcm5zLiAg QmVzaWRlcywgSSdtIG5vdCBjb252aW5jZWQgd2h5IHRoaXMgc2hvdWxkIA0KPj4+IHJlYWxseSBi ZSBhIHBlcmZvcm1hbmNlIGlzc3VlIGdpdmVuIHRoYXQgY29uZmlnIGNoYW5nZXMgYXJlIA0KPj4+ IHJlbGF0aXZlbHkgcmFyZSBjb21wYXJlZCB0byBhbGwgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGlu IHRoZSBzeXN0ZW0gdGhhdCBtYXkgYmUgY2hhbmdpbmcuDQo+Pj4NCj4+Pg0KPj4gKzEgLS0gdGhp cyBjaGFuZ2Ugc2hvdWxkIG5vdCBiZSBtYWRlLg0KPj4gVGhpcyBpcyBub3QgYSB1c2VmdWwgb3B0 aW1pemF0aW9uLg0KPiArMQ0KPg0KPiA8VGltPg0KPiBJIG1pZ2h0IGhhdmVuJ3QgZXhwbGFpbiB0 aGUgbWFpbiBjb25jZXJucyBvbiB0aGlzIGNsZWFybHkuDQo+IFdoZW4gSSBzZWUgWWFuZy1wdXNo LCBJIGZpbmQgaXQgdmVyeSB1c2VmdWwgYXMgaXQgcmVhbGx5IHNvbHZlcyBwcm9ibGVtcyBhbGwg Tk1TL2NvbnRyb2xsZXJzIGFyZSBmYWNpbmcuIEJ1dCBJIGRvIGhhdmUgYSBjb25jZXJuIG9uIHRo ZSBwb2ludCBJIG1lbnRpb25lZC4NCj4gTGV0IG1lIGdpdmUgYW4gZXhhbXBsZSB0aGF0IFlhbmct UHVzaCBjYW4gYmUgdXNlZDoNCj4gQmVmb3JlIFlhbmctcHVzaDoNCj4gTk1TIGlzIHVzaW5nIE5l dGNvbmYgeWFuZyB0byBtYW5hZ2UgYSByb3V0ZXIgTk1TIGlzIHVzaW5nIHBvbGxpbmcgDQo+IG1l Y2hhbmlzbSB0byBzeW5jIGNvbmZpZyBBbnlvbmUgbWFrZSBjaGFuZ2VzIG5vdCB0aHJvdWdoIE5N UywgZS5nLiANCj4gQ0xJLCBOTVMgaXMgbm90IGF3YXJlIG9mIHRoZSBjaGFuZ2UgaW4gdGltZS4N Cj4NCj4gQWZ0ZXIgWWFuZy1wdXNoOg0KPiBOTVMgaXMgdXNpbmcgTmV0Y29uZiB5YW5nIHRvIG1h bmFnZSBhIHJvdXRlciBOTVMgaXMgdXNpbmcgWWFuZy1wdXNoIA0KPiBtZWNoYW5pc20gdG8gc3lu YyBjb25maWd1cmF0aW9uLiBJbiBvcmRlciB0byBtYWtlIHN1cmUgYWxsIGRhdGFiYXNlIGluIA0K PiBzeW5jIHN0YXRlLCA8cnVubmluZz4gZGF0YWJhc2UgaXMgc3Vic2NyaWJlZCAgLS0tIEkgYmVs aWV2ZSB0aGlzIGNvdWxkIGJlIGEgd2lkZWx5IHVzZSBjYXNlIEluIGNhc2UgYW55b25lIG1ha2Ug Y2hhbmdlcyBub3QgdGhyb3VnaCB0aGUgTk1TLCBjaGFuZ2VzIHdpbGwgYmUgbm90aWZpZWQgdG8g Tk1TIHZpYSBwdXNoIG1lY2hhbmlzbS4NCj4gV2l0aCB5YW5nIHB1c2ggc29sdXRpb24sIGl0IHNv bHZlcyByZXN0cmljdGlvbiBvZiBwb2xsaW5nIG1lY2hhbmlzbSBwcmV0dHkgd2VsbC4NCj4gQnV0 IGFzIEkgZXhwbGFpbmVkLCB5YW5nIHB1c2ggbWVjaGFuaXNtIGhhcyBhbiBvYnZpb3VzIGRyYXdi YWNrLCBlYWNoIGNvbmZpZ3VyYXRpb24gZnJvbSBOTVMgd2lsbCBoYXZlIGEgcHVzaCBtZXNzYWdl IGJhY2sgdG8gTk1TLCB3aGljaCBpcyBub3QgbmVlZGVkIGluIG1hbnkgdXNlIHNjZW5hcmlvcy4g VGhpcyBiZWhhdmlvciBhY3R1YWxseSBpbXBhY3QgcGVyZm9ybWFuY2UgYSBsb3QuDQo+IElmIHRo aXMgbXNnIGNhbiBiZSBmaWx0ZXJlZCBkaXJlY3RseSB3aXRob3V0IGdvaW5nIHRocm91Z2ggYWxs IE5ldGNvbmYgK1NTSC9UTFMgKyBUQ1AgcHJvY2VzcywgdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBz dWJzY3JpYmVyIHdpbGwgaW1wcm92ZSBhIGxvdCBJIGJlbGlldmUuDQo+IEJhc2VkIG9uIG15IHVu ZGVyc3RhbmRpbmcgeWFuZy1wdXNoIGlzIHRvIHNvbHZlIHBvbGxpbmcgbGF0ZW5jeSwgYnV0IGl0 IHNob3VsZCBub3QgaGF2ZSBzaWduaWZpY2FudCBwZXJmb3JtYW5jZSBpbXBhY3Qgb24gZXhpc3Rp bmcgYXBwbGljYXRpb25zLiBJZiBOTVMgY29uZmlndXJlIGEgZGV2aWNlIHdpdGggMTAwMCBjaGFu Z2VzIGFuZCB0aGUgZGV2aWNlIHB1c2ggMTAwMCBjaGFuZ2VzIGJhY2sgdG8gTk1TLCBJIGRvbid0 IHRoaW5rIHRoaXMgaXMgYW4gZWxlZ2FudCBpbXBsZW1lbnRhdGlvbiB3aGVuIE5ldGNvbmYgaGFz IGFscmVhZHkgcHJvdmlkZSBlbm91Z2ggdHJhbnNhY3Rpb24gbWVjaGFuaXNtIGl0c2VsZi4gVGhl IGltcGFjdCBvZiBwdXNoIG1lY2hhbmlzbSBpcyBpdCBpbXBhY3QgcGVyZm9ybWFuY2Ugb2YgOTkl IG9mIHNjZW5hcmlvIChub3JtYWwgTk1TLT5kZXZpY2UgY29uZmlndXJlIHByb2Nlc3MpIHRvIHNv bHZlIDElIG9mIHVzZSBjYXNlIChjb25maWd1cmF0aW9uIG5vdCBzeW5jIGluIHRpbWUpLg0KPiBJ IHVuZGVyc3RhbmQgdGhlIGRpZmZpY3VsdHkgb2YgaW50cm9kdWNpbmcgYmlnIGNoYW5nZXMgYXQg dGhpcyBzdGFnZSwgYnV0IEkgcmVhbGx5IHdpc2ggd2UgY2FuIGhhdmUgYW4gZWxlZ2FudCBwdXNo IG1lY2hhbmlzbS4gQXBwcmVjaWF0ZSBhbnkgY29tbWVudHMgb24gdGhpcy4NCg0KKDEpIEknbSBu b3QgY29udmluY2VkIHRoYXQgdGhpcyB3aWxsIGJlIGEgcGVyZm9ybWFuY2UgcHJvYmxlbSwgcGFy dGljdWxhcmx5IGlmIGRhbXBlbmluZyBpcyBhcHBsaWVkIHRvIHRoZSBzdWJzY3JpcHRpb24sIG9y IGEgcGVyaW9kaWMgc3Vic2NyaXB0aW9uIGlzIHVzZWQgaW5zdGVhZC7CoCBJLmUuIEkgc2VlIHRo YXQgWUFORyBwdXNoIHBlcmZvcm1hbmNlIHNob3VsZCBiZSBubyB3b3JzZSB0aGFuIHBvbGxpbmcs IGFuZCBJIGFudGljaXBhdGUgdGhhdCBpdCB3aWxsIGJlIHNpZ25pZmljYW50bHkgYmV0dGVyLg0K KDIpIFRoZSBZQU5HIHB1c2ggZHJhZnQgaXMgYWxyZWFkeSA0IHllYXJzIG9sZC4gSSB0aGluayB0 aGF0IHdlIG11c3QganVzdCBmaW5pc2ggd2hhdCB3ZSBhcmUgd29ya2luZyBvbiBub3csIHRoZW4g d2UgY2FuIGRpc2N1c3MgZXh0ZW5zaW9ucy9mdXR1cmUgd29yay4gSWYgd2Uga2VlcCBjaHVybmlu ZyB0aGUgcmVxdWlyZW1lbnRzIGFuZCBzb2x1dGlvbiB0aGVuIHdlIGp1c3QgZW5kIHVwIHdpdGgg bm8gc29sdXRpb24sIGFuZCB0aGUgbWFya2V0IGxvb2tzIGVsc2V3aGVyZSAoYXMgaXMgYWxyZWFk eSBoYXBwZW5pbmcpDQoNClNvLCBteSBwcmFnbWF0aWMgc3VnZ2VzdGlvbiBpczoNCiDCoC0gd2Ug Y29sbGVjdGl2ZWx5IHRyeSBub3QgdG8gZ2V0IHNpZGUtdHJhY2tlZCBkaXNjdXNzaW5nIHRoaXMg aW4gZGV0YWlsIG5vdywNCiDCoC0gaW1wbGVtZW50IGl0IGFzIGl0IGlzIGRlZmluZWQgaW4gdGhl IGRyYWZ0LA0KIMKgLSBiZW5jaG1hcmsgaXQgdG8gc2VlIGhvdyBpdCBwZXJmb3JtcyAocGVyaGFw cyBhbHNvIGNvbXBhcmUgdG8gcGVyZm9ybWFuY2UgaWYgSlNPTiwgb3IgQ0JPUiBpcyB1c2VkIGFz IGFuIGVuY29kaW5nIGFzIHdlbGwpLA0KIMKgLSBpZiBpdCByZWFsbHkgcGVyZm9ybXMgcG9vcmx5 ICh0aGF0IGlzIG5vdCBkdWUgdG8gaW1wbGVtZW50YXRpb24pLCB0aGVuIHdyaXRlIHVwIGFuIElE IGRlc2NyaWJpbmcgdGhlIHByb2JsZW0gKGluY2x1ZGluZyB3aHkgZGFtcGVuaW5nL3BlcmlvZGlj IHN1YnNjcmlwdGlvbnMgZG9uJ3QgaGVscCksIHdpdGggZmlndXJlcyB0byBiYWNrIGl0IHVwLCBl dGMsDQogwqAtIHRoZSBXRyBjYW4gdGhlbiBldmFsdWF0ZSB3aGV0aGVyIHRoaXMgaXMgcmVhbGx5 IGEgcHJvYmxlbSB0aGF0IG5lZWRzIHRvIGJlIHNvbHZlZCwgYW5kIGlmIGl0IGRvZXMgdGhlbiBz b21lb25lIGNhbiB3cml0ZSBhIGRyYWZ0IHByb3Bvc2luZyBhbiBhcHByb3ByaWF0ZSBzb2x1dGlv bi4NCg0KRG9lcyB0aGF0IHNlZW0gcmVhc29uYWJsZT8NCg0KVGhhbmtzLA0KUm9iDQoNCi8vLy9Z ZWFoLCBsZXQncyBkbyBpbiB0aGlzIHdheS4gIA0KVGhhbmtzLCANClRpbQ0KDQo+IDwvVGltPg0K Pg0KPj4+DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pg0KPj4+IEJvdGgg 4oCcc3Vic2NyaWJlcuKAnSBhbmQg4oCccmVjZWl2ZXLigJ0gYXJlIHVzZWQsIGJpdCBjb25mdXNp bmcgc29tZXRpbWVzLg0KPj4+IFNoYWxsIHdlIG9ubHkgdXNlIOKAnHN1YnNjcmliZXLigJ0NCj4+ Pg0KPj4+IFRoZXkgYXJlIGRpZmZlcmVudCBlbnRpdGllcywgdGhlIGRlZmluaXRpb25zIGFyZSBp bg0KPj4+IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM6DQo+Pj4N Cj4+PiAgICAgUmVjZWl2ZXI6IEEgdGFyZ2V0IHRvIHdoaWNoIGEgcHVibGlzaGVyIHB1c2hlcyBz dWJzY3JpYmVkIGV2ZW50DQo+Pj4gICAgIHJlY29yZHMuICBGb3IgZHluYW1pYyBzdWJzY3JpcHRp b25zLCB0aGUgcmVjZWl2ZXIgYW5kIHN1YnNjcmliZXIgYXJlDQo+Pj4gICAgIHRoZSBzYW1lIGVu dGl0eS4NCj4+Pg0KPj4+ICAgICBTdWJzY3JpYmVyOiBBIGNsaWVudCBhYmxlIHRvIHJlcXVlc3Qg YW5kIG5lZ290aWF0ZSBhIGNvbnRyYWN0IGZvciB0aGUNCj4+PiAgICAgZ2VuZXJhdGlvbiBhbmQg cHVzaCBvZiBldmVudCByZWNvcmRzIGZyb20gYSBwdWJsaXNoZXIuICBGb3IgZHluYW1pYw0KPj4+ ICAgICBzdWJzY3JpcHRpb25zLCB0aGUgcmVjZWl2ZXIgYW5kIHN1YnNjcmliZXIgYXJlIHRoZSBz YW1lIGVudGl0eS4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+Pj4NCj4+PiAzLjExLjEuICBSb2J1c3RuZXNzIGFuZCByZWxpYWJpbGl0eQ0K Pj4+DQo+Pj4gICAgIE5vdGU6IEl0IGlzIHBlcmZlY3RseSBhY2NlcHRhYmxlIHRvIGhhdmUgYSBz ZXJpZXMgb2YNCj4+PiAicHVzaC1jaGFuZ2UtDQo+Pj4NCj4+PiAgICAgdXBkYXRlIiBub3RpZmlj YXRpb25zIChhbmQgZXZlbiAicHVzaCB1cGRhdGUiIG5vdGlmaWNhdGlvbnMpIA0KPj4+IHNlcmlh bGx5DQo+Pj4NCj4+PiAgICAgcXVldWVkIGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIgYXdhaXRpbmcg dHJhbnNtaXNzaW9uLiAgSXQgaXMgbm90DQo+Pj4NCj4+PiAgICAgcmVxdWlyZWQgdG8gbWVyZ2Ug cGVuZGluZyB1cGRhdGUgcmVjb3Jkcy4gIEkuZS4sIHRoZSBkYW1wZW5pbmcgDQo+Pj4gcGVyaW9k DQo+Pj4NCj4+PiAgICAgYXBwbGllcyB0byB1cGRhdGUgcmVjb3JkIGNyZWF0aW9uLCBub3QgdHJh bnNtaXNzaW9uLg0KPj4+DQo+Pj4gTXkgc3VnZ2VzdGlvbiBpczoNCj4+Pg0KPj4+IFRoZSBwdWJs aXNoZXIgc2hvdWxkIGluY3JlYXNlIGRhbXBlbmluZyBwZXJpb2QgYXV0b21hdGljYWxseSBpbiBj YXNlIA0KPj4+IHRoZSBtZXNzYWdlIHF1ZXVlIHJlYWNoZXMgYSBsaW1pdC4NCj4+Pg0KPj4+IFRo aXMgaXMgdG8gYXZvaWQgbm90aWZpY2F0aW9ucyBsb3N0IGR1ZSB0byBxdWV1ZSBsaW1pdCBpbiBj YXNlIA0KPj4+IHN1YnNjcmliZXIgaXMgYnVzeSBvciB0ZW1wb3JhcmlseSB1bnJlYWNoYWJsZS4N Cj4+Pg0KPj4+IEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIGlzIGhvdyB0aGUgZGFtcGVuaW5nIHRo YXQgaXMgY3VycmVudGx5IA0KPj4+IGRlZmluZWQgc2hvdWxkIHdvcmssIHNpbmNlIGl0IGlzIGV4 cGVjdGVkIHRvIHByb3ZpZGUgYSBzdHJvbmcgDQo+Pj4gZ3VhcmFudGVlIHRoYXQgaXQgd2lsbCBl aXRoZXIgZGVsaXZlciB0aGUgbm90aWZpY2F0aW9ucyB0byB0aGUgDQo+Pj4gcmVjZWl2ZXIsIG9y IG90aGVyd2lzZSBub3RpZnkgdG8gdGhlIHJlY2VpdmVyIHRoYXQgc29tZSB1cGRhdGVzIFttYXld IGhhdmUgYmVlbiBsb3N0Lg0KPj4+DQo+Pj4gSSBjb3VsZCBpbWFnaW5lIHRoYXQgYW5vdGhlciwg c29mdGVyIHR5cGUgb2YgZGFtcGVuaW5nLCBjb3VsZCANCj4+PiBwb3RlbnRpYWxseSBiZSBkZWZp bmVkIGluIGZ1dHVyZSBhcyBhIHNlcGFyYXRlIA0KPj4+IGV4dGVuc2lvbi9hdWdtZW50YXRpb24s IGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgc2hvdWxkIGdvIGludG8gdGhpcyANCj4+PiBkb2N1bWVu dCwgYmVjYXVzZSBpdCB3b3VsZCBtYXNzaXZlbHkgc2xvdyBpdCBkb3duLCBhbmQgdGhlIGluZHVz dHJ5IGFscmVhZHkgbmVlZHMgdGhpcyBzdGFuZGFyZCBub3cuDQo+Pj4NCj4+Pg0KPj4gKzEgLS0g dGhlIHNlcnZlciBkb2VzIHdoYXQgaXQgaXMgdG9sZCBhbmQgZG9lcyBub3QgZGVjaWRlIHRvIGNo YW5nZSANCj4+ICt0aGUNCj4+IHN1YnNjcmlwdGlvbiBvbiBpdHMgb3duDQo+ICsxDQo+DQo+DQo+ IC9tYXJ0aW4NCj4NCj4+DQo+Pg0KPj4+DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+Pg0KPj4+IEl0IHdvdWxkIGJlIGFwcHJlY2lhdGVkIGlmIHN1Z2dlc3Rpb25zIGNhbiBi ZSBnaXZlbiBvbiBob3cgcHVzaCANCj4+PiBzaGFsbCBiZSB1c2VkIG9uIHJ1bm5pbmcsIHN0YXJ0 dXAgYW5kIGNhbmRpZGF0ZSBkYXRhc3RvcmVzDQo+Pj4NCj4+PiBJdCBzaG91bGQgd29yayB0aGUg c2FtZSB3YXkgYXMgWUFORyBwdXNoIG9uIGFueSBvdGhlciBkYXRhc3RvcmUuDQo+Pj4gVGhlIG1l Y2hhbmlzbSBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0IHNlZW1zIHRvIGJlIGVudGlyZWx5IGRhdGFz dG9yZSBhZ25vc3RpYy4NCj4+PiBJbiB3aGF0IHdheSBkbyB5b3UgdGhpbmsgaXQgbWF5IGJlaGF2 ZSBkaWZmZXJlbnRseT8NCj4+Pg0KPj4+IEFsdGhvdWdoIEkgY291bGQgaW1hZ2luZSB0aGF0IGlt cGxlbWVudGF0aW9ucyBtYXkgbm90IHN1cHBvcnQgDQo+Pj4gc3Vic2NyaXB0aW9ucyBvbiBzdGFy dHVwIG9yIGNhbmRpZGF0ZSwgaW4gd2hpY2ggY2FzZSBJIHdvdWxkIGV4cGVjdCANCj4+PiB0aGF0 IHRoZSBzdWJzY3JpcHRpb24gd291bGQgYmUgcmVqZWN0ZWQuDQo+Pj4NCj4gPFRpbT4NCj4gVGhh bmtzIFJvYi4NCj4gSSB0aGluayB5b3UgdW5kZXJzdGFuZCBteSBjb25jZXJucy4gVGhlIHdob2xl IHlhbmcgcHVzaCBtZWNoYW5pc20gaXMgZGF0YXN0b3JlIGFnbm9zdGljLg0KPiBCdXQgbXkgcG9z aXRpb24gaXM6IGlmIHdlIGZvbGxvdyB0aGlzIGRyYWZ0LCBJIGFtIHByZXR0eSBzdXJlIGltcGxl bWVudGF0aW9uIG9mIHlhbmcgcHVzaCBsYXRlciB3aWxsIGJlIGRpZmZlcmVudCBhY3Jvc3MgYWxs IHZlbmRvcnMuIFNvbWVvbmUgd2lsbCBhY2NlcHQgc3Vic2NyaXB0aW9uIG9uIHN0YXJ0dXAgYnV0 IG90aGVycyB3aWxsIHJlamVjdC4gU29tZSB3aWxsIHN1cHBvcnQgcHVzaGluZyBjaGFuZ2VzIG9u IGNhbmRpZGF0ZSBidXQgb3RoZXJzIG5vdC4NCj4gSSBiZWxpZXZlIHRoZSBvcmlnaW5hbCBpbnRl bnRpb24gb2YgTmV0Y29uZiB0byBwcm92aWRlIGEgc3RhbmRhcmRpemVkIG1lY2hhbmlzbSBhbmQg d2UgYXJlIGFsbCB3b3JraW5nIHRvIHNjYW5kYWxpemVkIGFzIG11Y2ggYXMgcG9zc2libGUgdG8g YWxsb3cgZGlmZmVyZW50IHZlbmRvcnMgdG8gaGF2ZSBpbnRlcm9wZXJhYmlsaXR5IHdpdGggZWFj aCBvdGhlci4NCj4gSWYgSUVURiB3b3JraW5nIGdyb3VwIGNhbiBnaXZlIGluc3RydWN0aW9ucyBv biBob3cgcHVzaCBtZWNoYW5pc20gY2FuIGJlIGFkb3B0ZWQgdG8gZGlmZmVyZW50IGRhdGFzdG9y ZXMgaW5zdGVhZCBvZiBsZXQgdmVuZG9ycyBtYWtlIGRlY2lzaW9ucyB0aGVtc2VsdmVzLCBJIGJl bGlldmUgd2UgaGF2ZSBhIHNvbHV0aW9uIGVhc2llciBnZXQgaW50ZXJvcGVyYXRlZC4NCj4gPC9U aW0+DQo+DQo+DQo+Pj4gVGhhbmtzLA0KPj4+IFJvYg0KPj4+DQo+Pj4NCj4+Pg0KPj4gQW5keQ0K Pj4NCj4+DQo+Pj4NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+ Pg0KPj4+DQo+Pj4gUmVnYXJkcywNCj4+Pg0KPj4+IFRpbQ0KPj4+DQo+Pj4NCj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE5ldGNvbmYgbWFp bGluZw0KPj4+IGxpc3ROZXRjb25mQGlldGYub3JnaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRjb25mDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBOZXRjb25mIG1haWxpbmcgbGlzdA0K Pj4+IE5ldGNvbmZAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldGNvbmYNCj4+Pg0KPj4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5ldGNvbmZAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoN Cg== From nobody Tue Sep 4 18:12:24 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A27130E59 for ; Tue, 4 Sep 2018 18:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mKDwG5ZyQd3f for ; Tue, 4 Sep 2018 18:12:20 -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 C0F5A130DCB for ; Tue, 4 Sep 2018 18:12:19 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CA3F2C1E71FF2 for ; Wed, 5 Sep 2018 02:12:12 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 5 Sep 2018 02:12:14 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.188]) by SJCEML703-CHM.china.huawei.com ([169.254.5.30]) with mapi id 14.03.0415.000; Tue, 4 Sep 2018 18:11:59 -0700 From: Alexander Clemm To: Rohit R Ranade , "netconf@ietf.org" Thread-Topic: [Netconf] Comments on Yang-push-18 //RE: I-D Action: draft-ietf-netconf-yang-push-18.txt Thread-Index: AdQ/VLvBsEuHunkySd2q4Mf8WxSa0AFLVWIQ Date: Wed, 5 Sep 2018 01:11:59 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5C6FA@sjceml521-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6BC192DD@dggeml530-mbs.china.huawei.com> In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BC192DD@dggeml530-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.35.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] Comments on Yang-push-18 //RE: I-D Action: draft-ietf-netconf-yang-push-18.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 01:12:22 -0000 Hi Rohit,=20 thank you for the comments! I am in the process of incorporating them into= -19, which I hope to post by Thursday. Replies to your items inline. --- Alex > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Rohit R > Ranade > Sent: Tuesday, August 28, 2018 10:01 PM > To: netconf@ietf.org > Subject: [Netconf] Comments on Yang-push-18 //RE: I-D Action: draft-ietf- > netconf-yang-push-18.txt >=20 > Hi All, >=20 >=20 > 1. In Section 3.3 > The whole para from "To avoid flooding receivers .. the last change wil= l still > be sent." looks like a repetition > of Section 3.1 , description of "Dampening period" >=20 3.1 describes the model, while 3.3 discusses the considerations behi= nd it and provides additional explanation. While the explanation may be re= dundant, we felt it is still useful to explain the rational. Hence we woul= d like to keep it. =20 > 2. Section 3.3, Point 4 > "insert into the YANG patch record the last change made for any object > which otherwise wouldn't have appeared." > I am not able to understand this statement clearly. Can this statement= be > simplified ? =20 Rephrasing it as follows: " insert into the YANG patch record the last chan= ge made, even if the new value is no different from the original value (sin= ce changes that were made in the interim were canceled out)." >=20 > 3. Section 3.5.2 > The para "A publisher will indicate a change to the effect ... this by = a > "move" operation." > This is already defined in the YANG Patch RFC right ? What is the need= to > define this again in this RFC ? The patch is generated by the publisher, not by the client. In that= sense, we use it a bit different from RFC 8072. We thought it will be use= ful in the interest of greater clarity to explain it. So, while it would b= e possible to editorially tighten, again we would like to keep it. =20 >=20 > 4. Section 3.5.2 > "To support this, it is valid to encode a YANG patch operation so that= its > application would result > in no change between the previous and current state. This indicates > that some churn has occurred on the object. An example of this would > be a patch that does a "create" operation for a datastore node where > the receiver believes one already exists, or a "replace" operation > which replaces a previous value with the same value." >=20 > Some points here need more clarification. > a. If there is no change, but only a churn then why is it important t= o send > this object in a YANG push ? What is the benefit ? It indicates the fact that churn has occurred. Basically, it allows = a client to recognize that the value has not been static/unchanged, but did= undergo some kind of oscillation. The benefits to only indicate the last = change is per the dampening period (reduce bandwidth and CPU). =20 > b. If there was a "create" and "delete" on object X, within a dampeni= ng > period, then what will be the patch record operation ? We would send a delete. (even if the object did not exist originally). We= should indicate this actually. Adding the following to the same item:=20 " In case the changes involve creating a new datastore node, then deleting = it, the YANG patch record will indicate deletion of the datastore node. Si= milarly, in case the changes involve deleting a new datastore node, then re= creating it, the YANG patch record will indicate creation of the datastore = node." > c. s/patch that does a "create" operation /patch that indicates a "cr= eate" > operation ? Patch can indicate the operation not do it. changed "does" do "indicates" /ALEX> >=20 > 5. Section 3.7 > "the counter MUST be reset to '1' the after passing a maximum value of > '4294967295'" > s/reset to '1' the after passing/reset to '1' after passing >=20 changed > 6. Section 3.7 Figure 2: Push example for on change > The "yang-patch" should be under the namespace > "urn:ietf:params:xml:ns:yang:ietf-yang-patch" >=20 changed > 7. In the ietf-yang-push, tree diagram > " > +--ro datastore-changes? > +--ro ypatch:yang-patch > +--ro patch-id string > " > There looks to be an indentation problem for "ypatch:yang-patch" >=20 changed (apparently somewhere a tab character sneaked into the .xml,= which was not rendered correctly) > 8. resynch-subscription-error > I feel "sync" is a better abbreviation than "synch" for synchronizatio= n, > because when reading this name, we may > not pronounce this correctly or read correctly. I also feel "re-sync"= is better > when compared to "resync" >=20 Hmm. This will also require to change the name of RPCs, and everywh= ere else the term "sync(h)" is used. I agree that while not a major item, = this would have been a better choice, so I am applying the change throughou= t. =20 > 9. Section 3.9. > "since the last notification message was sent to a particular each rec= eiver.". > s/sent to a particular each receiver/sent to a particular receiver >=20 changed >=20 > 10. Section 3.9 > "To accomplish this, implementations SHOULD support the > conceptual authorization model of [RFC8341], specifically section 3.2.= 4.". > The link to section 3.2.4 seems to be broken as it is taking the reade= r to the > YANG Push draft and not to NACM >=20 Yes indeed, I see it. Interestingly this is autogenerated in the .h= tml version (and only there), the XML source does not include a link. I am= not sure how to change it. Note for the RFC Editor? > 11. Section 3.9 > I think here "access-protected data", is used to indicate that the rece= iver > has "no access". I think this is misleading. > "access-protected data" means that there are NACM rules to protect the > data. Maybe we can replace it with "access-denied data" ? >=20 Rephrased the passages in question as follows: " A publisher MUST al= low for the possibility that a subscription's selection filter references n= on-existent data or data that the receiver is not allowed to access." and "= A publisher MAY choose to reject an establish-subscription request which s= elects non-existent data or data that a receiver is not allowed to access. = " > 12. Section 3.9 > "If read access into previously accessible nodes has been lost due to > a receiver permissions change, this SHOULD be reported as a patch > "delete" operation for on-change subscriptions." > I think we should not have such mechanisms. If a user does not have acc= ess, > we should not try to evaluate what was the last update sent > to such user, and how to send a subsequent patch which will stabilize t= he > user's DB due to the access-control changes. >=20 I can see your point; that said I think one can argue to keep things= as-is. When a receiver can no longer access a datastore node, the node ha= s effectively "disappeared" to the receiver. By keeping it, the receiver w= ill be under the illusion of no change even when the value does change. Th= is might cause a receiver to "not trust" a subscription any more and start = polling, which is something we would absolutely want to avoid. So, I prefe= r to keep things as they are. Alternatively, an implementation may always= delete the subscription / force subscription reestablishment. =20 --- Alex >=20 > With Regards, > Rohit R Ranade >=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 29 August 2018 06:24 > To: i-d-announce@ietf.org > Cc: netconf@ietf.org > Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-push-18.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Network Configuration WG of the IETF. >=20 > Title : YANG Datastore Subscription > Authors : Alexander Clemm > Eric Voit > Alberto Gonzalez Prieto > Ambika Prasad Tripathy > Einar Nilsen-Nygaard > Andy Bierman > Balazs Lengyel > Filename : draft-ietf-netconf-yang-push-18.txt > Pages : 57 > Date : 2018-08-28 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netconf-yang-push-18 > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push-18 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-yang-push-18 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 4 18:13:26 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D304130E59 for ; Tue, 4 Sep 2018 18:13:25 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVrSZBySUzLn for ; Tue, 4 Sep 2018 18:13: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 E2C76130DCB for ; Tue, 4 Sep 2018 18:13:23 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E72D3FA2B4808 for ; Wed, 5 Sep 2018 02:13:13 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 5 Sep 2018 02:12:14 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.188]) by SJCEML703-CHM.china.huawei.com ([169.254.5.30]) with mapi id 14.03.0415.000; Tue, 4 Sep 2018 18:11:59 -0700 From: Alexander Clemm To: Rohit R Ranade , "netconf@ietf.org" Thread-Topic: [Netconf] Comments on Yang-push-18 //RE: I-D Action: draft-ietf-netconf-yang-push-18.txt Thread-Index: AdQ/VLvBsEuHunkySd2q4Mf8WxSa0AFLVWIQ Date: Wed, 5 Sep 2018 01:11:59 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5C6FA@sjceml521-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6BC192DD@dggeml530-mbs.china.huawei.com> In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BC192DD@dggeml530-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.35.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] Comments on Yang-push-18 //RE: I-D Action: draft-ietf-netconf-yang-push-18.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 01:13:25 -0000 Hi Rohit,=20 thank you for the comments! I am in the process of incorporating them into= -19, which I hope to post by Thursday. Replies to your items inline. --- Alex > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Rohit R > Ranade > Sent: Tuesday, August 28, 2018 10:01 PM > To: netconf@ietf.org > Subject: [Netconf] Comments on Yang-push-18 //RE: I-D Action: draft-ietf- > netconf-yang-push-18.txt >=20 > Hi All, >=20 >=20 > 1. In Section 3.3 > The whole para from "To avoid flooding receivers .. the last change wil= l still > be sent." looks like a repetition > of Section 3.1 , description of "Dampening period" >=20 3.1 describes the model, while 3.3 discusses the considerations behi= nd it and provides additional explanation. While the explanation may be re= dundant, we felt it is still useful to explain the rational. Hence we woul= d like to keep it. =20 > 2. Section 3.3, Point 4 > "insert into the YANG patch record the last change made for any object > which otherwise wouldn't have appeared." > I am not able to understand this statement clearly. Can this statement= be > simplified ? =20 Rephrasing it as follows: " insert into the YANG patch record the last chan= ge made, even if the new value is no different from the original value (sin= ce changes that were made in the interim were canceled out)." >=20 > 3. Section 3.5.2 > The para "A publisher will indicate a change to the effect ... this by = a > "move" operation." > This is already defined in the YANG Patch RFC right ? What is the need= to > define this again in this RFC ? The patch is generated by the publisher, not by the client. In that= sense, we use it a bit different from RFC 8072. We thought it will be use= ful in the interest of greater clarity to explain it. So, while it would b= e possible to editorially tighten, again we would like to keep it. =20 >=20 > 4. Section 3.5.2 > "To support this, it is valid to encode a YANG patch operation so that= its > application would result > in no change between the previous and current state. This indicates > that some churn has occurred on the object. An example of this would > be a patch that does a "create" operation for a datastore node where > the receiver believes one already exists, or a "replace" operation > which replaces a previous value with the same value." >=20 > Some points here need more clarification. > a. If there is no change, but only a churn then why is it important t= o send > this object in a YANG push ? What is the benefit ? It indicates the fact that churn has occurred. Basically, it allows = a client to recognize that the value has not been static/unchanged, but did= undergo some kind of oscillation. The benefits to only indicate the last = change is per the dampening period (reduce bandwidth and CPU). =20 > b. If there was a "create" and "delete" on object X, within a dampeni= ng > period, then what will be the patch record operation ? We would send a delete. (even if the object did not exist originally). We= should indicate this actually. Adding the following to the same item:=20 " In case the changes involve creating a new datastore node, then deleting = it, the YANG patch record will indicate deletion of the datastore node. Si= milarly, in case the changes involve deleting a new datastore node, then re= creating it, the YANG patch record will indicate creation of the datastore = node." > c. s/patch that does a "create" operation /patch that indicates a "cr= eate" > operation ? Patch can indicate the operation not do it. changed "does" do "indicates" /ALEX> >=20 > 5. Section 3.7 > "the counter MUST be reset to '1' the after passing a maximum value of > '4294967295'" > s/reset to '1' the after passing/reset to '1' after passing >=20 changed > 6. Section 3.7 Figure 2: Push example for on change > The "yang-patch" should be under the namespace > "urn:ietf:params:xml:ns:yang:ietf-yang-patch" >=20 changed > 7. In the ietf-yang-push, tree diagram > " > +--ro datastore-changes? > +--ro ypatch:yang-patch > +--ro patch-id string > " > There looks to be an indentation problem for "ypatch:yang-patch" >=20 changed (apparently somewhere a tab character sneaked into the .xml,= which was not rendered correctly) > 8. resynch-subscription-error > I feel "sync" is a better abbreviation than "synch" for synchronizatio= n, > because when reading this name, we may > not pronounce this correctly or read correctly. I also feel "re-sync"= is better > when compared to "resync" >=20 Hmm. This will also require to change the name of RPCs, and everywh= ere else the term "sync(h)" is used. I agree that while not a major item, = this would have been a better choice, so I am applying the change throughou= t. =20 > 9. Section 3.9. > "since the last notification message was sent to a particular each rec= eiver.". > s/sent to a particular each receiver/sent to a particular receiver >=20 changed >=20 > 10. Section 3.9 > "To accomplish this, implementations SHOULD support the > conceptual authorization model of [RFC8341], specifically section 3.2.= 4.". > The link to section 3.2.4 seems to be broken as it is taking the reade= r to the > YANG Push draft and not to NACM >=20 Yes indeed, I see it. Interestingly this is autogenerated in the .h= tml version (and only there), the XML source does not include a link. I am= not sure how to change it. Note for the RFC Editor? > 11. Section 3.9 > I think here "access-protected data", is used to indicate that the rece= iver > has "no access". I think this is misleading. > "access-protected data" means that there are NACM rules to protect the > data. Maybe we can replace it with "access-denied data" ? >=20 Rephrased the passages in question as follows: " A publisher MUST al= low for the possibility that a subscription's selection filter references n= on-existent data or data that the receiver is not allowed to access." and "= A publisher MAY choose to reject an establish-subscription request which s= elects non-existent data or data that a receiver is not allowed to access. = " > 12. Section 3.9 > "If read access into previously accessible nodes has been lost due to > a receiver permissions change, this SHOULD be reported as a patch > "delete" operation for on-change subscriptions." > I think we should not have such mechanisms. If a user does not have acc= ess, > we should not try to evaluate what was the last update sent > to such user, and how to send a subsequent patch which will stabilize t= he > user's DB due to the access-control changes. >=20 I can see your point; that said I think one can argue to keep things= as-is. When a receiver can no longer access a datastore node, the node ha= s effectively "disappeared" to the receiver. By keeping it, the receiver w= ill be under the illusion of no change even when the value does change. Th= is might cause a receiver to "not trust" a subscription any more and start = polling, which is something we would absolutely want to avoid. So, I prefe= r to keep things as they are. Alternatively, an implementation may always= delete the subscription / force subscription reestablishment. =20 --- Alex >=20 > With Regards, > Rohit R Ranade >=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 29 August 2018 06:24 > To: i-d-announce@ietf.org > Cc: netconf@ietf.org > Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-push-18.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Network Configuration WG of the IETF. >=20 > Title : YANG Datastore Subscription > Authors : Alexander Clemm > Eric Voit > Alberto Gonzalez Prieto > Ambika Prasad Tripathy > Einar Nilsen-Nygaard > Andy Bierman > Balazs Lengyel > Filename : draft-ietf-netconf-yang-push-18.txt > Pages : 57 > Date : 2018-08-28 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netconf-yang-push-18 > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push-18 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-yang-push-18 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 4 18:34:24 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6414A128CFD for ; Tue, 4 Sep 2018 18:34:23 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqzOTrbqaaXK for ; Tue, 4 Sep 2018 18:34:22 -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 A83A4127B92 for ; Tue, 4 Sep 2018 18:34:21 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 1C5FC5B791080 for ; Wed, 5 Sep 2018 02:34:19 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 5 Sep 2018 02:34:06 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.188]) by SJCEML703-CHM.china.huawei.com ([169.254.5.30]) with mapi id 14.03.0415.000; Tue, 4 Sep 2018 18:33:50 -0700 From: Alexander Clemm To: Robert Wilton , "Yutianpeng (Tim)" , "netconf@ietf.org" Thread-Topic: [Netconf] Comments on draft-ietf-netconf-yang-push-18 Thread-Index: AdQ/rOk2O9B1aMu7RrSnvHTptxxrnQE8Oa+AAAAqBYAAADdvgAABoAqAAAErhIAAAzE9cA== Date: Wed, 5 Sep 2018 01:33:49 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5C72E@sjceml521-mbs.china.huawei.com> References: <35FF0D51C8DAB54B95B0426331F984FF520433B2@lhreml523-mbs.china.huawei.com> <20180904.173343.771736120417698474.mbj@tail-f.com> <35FF0D51C8DAB54B95B0426331F984FF52045B7E@lhreml523-mbs.china.huawei.com> <3855125a-3b54-3fa0-1762-dea1f45d6a75@cisco.com> In-Reply-To: <3855125a-3b54-3fa0-1762-dea1f45d6a75@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.35.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 01:34:23 -0000 KzEgb24gYWxsIGFjY291bnRzLiAgDQoNClRpbSwgYXMgZXhwbGFpbmVkLCBsZXQgdXMgbm90IGlu dHJvZHVjZSB0aGlzIGNoYW5nZS4gIEl0IG1ha2VzIGltcGxlbWVudGF0aW9uIG1vcmUgY29tcGxl eCBhbmQgbWF5IGV2ZW4gaW50cm9kdWNlIG90aGVyIGlzc3Vlcy4gIEVsaW1pbmF0aW5nICJkb3Vi bGUtcmVwb3J0aW5nIiBvZiBjaGFuZ2VzIHRvIGEgY2xpZW50IGFwcGxpY2F0aW9uIHRoYXQgaXMg bWFraW5nIGNoYW5nZXMgdG8gZGF0YXN0b3JlIG5vZGVzIHRvIHdob3NlIHVwZGF0ZXMgaXQgaGFz IGFsc28gc3Vic2NyaWJlZCBpcyBhIG1pbm9yIG9wdGltaXphdGlvbi4gIElmIHlvdSByZWFsbHkg aGF2ZSBhIG5lZWQgZm9yIHRoaXMgZmVhdHVyZSwgaXQgY2FuIGJlIGF1Z21lbnRlZCBpbnRvIHRo ZSBtb2RlbCBhbmQgYmUgZGVzY3JpYmVkIGluIGEgc2VwYXJhdGUgZHJhZnQuICANCg0KVGhhbmtz DQotLS0gQWxleCANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOZXRj b25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0 IFdpbHRvbg0KPiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTggOTo1NCBBTQ0KPiBU bzogWXV0aWFucGVuZyAoVGltKSA8eXV0aWFucGVuZ0BodWF3ZWkuY29tPjsgbmV0Y29uZkBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbmV0 Y29uZi15YW5nLXB1c2gtMTgNCj4gDQo+IEhpIFRpbSwNCj4gDQo+IFBsZWFzZSBzZWUgaW5saW5l IC4uLg0KPiANCj4gDQo+IE9uIDA0LzA5LzIwMTggMTc6MjAsIFl1dGlhbnBlbmcgKFRpbSkgd3Jv dGU6DQo+ID4gSGksDQo+ID4gVGhhbmtzIGZvciByZXBseS4NCj4gPiBTb21lIGV4cGxhbmF0aW9u cyBhcyBiZWxvdywgcGxlYXNlIGNoZWNrLg0KPiA+IFRpbQ0KPiA+DQo+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluDQo+ID4gQmpvcmtsdW5kDQo+ID4gU2VudDog MDQgU2VwdGVtYmVyIDIwMTggMTY6MzQNCj4gPiBUbzogYW5keUB5dW1hd29ya3MuY29tDQo+ID4g Q2M6IG5ldGNvbmZAaWV0Zi5vcmc7IHJ3aWx0b249NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmcN Cj4gPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbmV0Y29u Zi15YW5nLXB1c2gtMTgNCj4gPg0KPiA+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29t PiB3cm90ZToNCj4gPj4gT24gVHVlLCBTZXAgNCwgMjAxOCBhdCA4OjIyIEFNLCBSb2JlcnQgV2ls dG9uIDwNCj4gPj4gcndpbHRvbj00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+ ID4+DQo+ID4+PiBIaSBUaW0sDQo+ID4+Pg0KPiA+Pj4gUGxlYXNlIHNlZSBjb21tZW50cyAoYXMg YSBub24gYXV0aG9yKSBpbmxpbmUgLi4uDQo+ID4+Pg0KPiA+Pj4gT24gMjkvMDgvMjAxOCAxNjoy OCwgWXV0aWFucGVuZyAoVGltKSB3cm90ZToNCj4gPj4+DQo+ID4+PiBIaSwNCj4gPj4+DQo+ID4+ PiBTb21lIGNvbW1lbnRzIGFzIGJlbG93Og0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pg0KPiA+Pj4gVGhlcmUgaXMgb25lIHBv aW50IG1pc3NpbmcgaW4gdGhlIGRyYWZ0IHNvIGZhciBJIHRoaW5rOiB3aGF0IGlmIHRoZQ0KPiA+ Pj4gc3Vic2NyaWJlciBpcyB0aGUgaW5pdGlhdG9yIG9mIHRoZSBjb25maWd1cmF0aW9uIGNoYW5n ZXM/DQo+ID4+Pg0KPiA+Pj4gSW4gdGhpcyBjYXNlLCB0aGUgc3Vic2NyaWJlciBpcyBhd2FyZSBv ZiBjb25maWd1cmF0aW9uIGNoYW5nZXMNCj4gPj4+IGluaXRpYXRlZCBieSBpdHNlbGYgd2l0aG91 dCByZWx5aW5nIG9uIHRoZSBwdXNoIG1lY2hhbmlzbS4NCj4gPj4+IEludHJvZHVjaW5nIHB1c2gg bWVjaGFuaXNtIHdpbGwgZHJhbWF0aWNhbGx5IGltcGFjdCB0aGUgcGVyZm9ybWFuY2Ugb2YNCj4g dGhlIHN5c3RlbSBpbiB0aGlzIGNhc2UuDQo+ID4+Pg0KPiA+Pj4gTXkgc3VnZ2VzdGlvbiBpczoN Cj4gPj4+DQo+ID4+PiAzLjMuICBPbi1DaGFuZ2UgQ29uc2lkZXJhdGlvbnMNCj4gPj4+DQo+ID4+ PiAgICAgNS4gIElmIHRoZSByZXN1bHRpbmcgcGF0Y2ggcmVjb3JkIGlzIG5vbi1lbXB0eSwgYW5k IGl0IGNvbnRhaW5zDQo+ID4+PiB0aGUgcmVjb3JkcyBub3QgaW5pdGlhdGVkIGJ5IHRoZSBzdWJz Y3JpYmVyLCBzZWxlY3QgdGhlc2UgcmVjb3Jkcw0KPiA+Pj4gYW5kIHNlbmQgdG8gY29ycmVzcG9u ZGluZyBzdWJzY3JpYmVyLg0KPiA+Pj4NCj4gPj4+IFdlIGNhbiBoYXZlIGZ1cnRoZXIgZGlzY3Vz c2lvbiBvbiB0aGlzIHRvIG1ha2UgaXQgb3B0aW9uYWwgaW5zdGVhZA0KPiA+Pj4gb2YgbWFuZGF0 b3J5Lg0KPiA+Pj4NCj4gPj4+IEknbSBub3Qga2VlbiBvbiB0aGlzIGNoYW5nZS4gIFRoaXMgZG9l cyBub3Qgc2VlbSBsaWtlIGEgZ29vZA0KPiA+Pj4gc2VwYXJhdGlvbiBvZiBjb25jZXJucy4gIEJl c2lkZXMsIEknbSBub3QgY29udmluY2VkIHdoeSB0aGlzIHNob3VsZA0KPiA+Pj4gcmVhbGx5IGJl IGEgcGVyZm9ybWFuY2UgaXNzdWUgZ2l2ZW4gdGhhdCBjb25maWcgY2hhbmdlcyBhcmUNCj4gPj4+ IHJlbGF0aXZlbHkgcmFyZSBjb21wYXJlZCB0byBhbGwgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGlu IHRoZSBzeXN0ZW0gdGhhdCBtYXkNCj4gYmUgY2hhbmdpbmcuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4g KzEgLS0gdGhpcyBjaGFuZ2Ugc2hvdWxkIG5vdCBiZSBtYWRlLg0KPiA+PiBUaGlzIGlzIG5vdCBh IHVzZWZ1bCBvcHRpbWl6YXRpb24uDQo+ID4gKzENCj4gPg0KPiA+IDxUaW0+DQo+ID4gSSBtaWdo dCBoYXZlbid0IGV4cGxhaW4gdGhlIG1haW4gY29uY2VybnMgb24gdGhpcyBjbGVhcmx5Lg0KPiA+ IFdoZW4gSSBzZWUgWWFuZy1wdXNoLCBJIGZpbmQgaXQgdmVyeSB1c2VmdWwgYXMgaXQgcmVhbGx5 IHNvbHZlcyBwcm9ibGVtcyBhbGwNCj4gTk1TL2NvbnRyb2xsZXJzIGFyZSBmYWNpbmcuIEJ1dCBJ IGRvIGhhdmUgYSBjb25jZXJuIG9uIHRoZSBwb2ludCBJIG1lbnRpb25lZC4NCj4gPiBMZXQgbWUg Z2l2ZSBhbiBleGFtcGxlIHRoYXQgWWFuZy1QdXNoIGNhbiBiZSB1c2VkOg0KPiA+IEJlZm9yZSBZ YW5nLXB1c2g6DQo+ID4gTk1TIGlzIHVzaW5nIE5ldGNvbmYgeWFuZyB0byBtYW5hZ2UgYSByb3V0 ZXIgTk1TIGlzIHVzaW5nIHBvbGxpbmcNCj4gPiBtZWNoYW5pc20gdG8gc3luYyBjb25maWcgQW55 b25lIG1ha2UgY2hhbmdlcyBub3QgdGhyb3VnaCBOTVMsIGUuZy4NCj4gPiBDTEksIE5NUyBpcyBu b3QgYXdhcmUgb2YgdGhlIGNoYW5nZSBpbiB0aW1lLg0KPiA+DQo+ID4gQWZ0ZXIgWWFuZy1wdXNo Og0KPiA+IE5NUyBpcyB1c2luZyBOZXRjb25mIHlhbmcgdG8gbWFuYWdlIGEgcm91dGVyIE5NUyBp cyB1c2luZyBZYW5nLXB1c2gNCj4gPiBtZWNoYW5pc20gdG8gc3luYyBjb25maWd1cmF0aW9uLiBJ biBvcmRlciB0byBtYWtlIHN1cmUgYWxsIGRhdGFiYXNlIGluDQo+ID4gc3luYyBzdGF0ZSwgPHJ1 bm5pbmc+IGRhdGFiYXNlIGlzIHN1YnNjcmliZWQgIC0tLSBJIGJlbGlldmUgdGhpcyBjb3VsZCBi ZSBhIHdpZGVseQ0KPiB1c2UgY2FzZSBJbiBjYXNlIGFueW9uZSBtYWtlIGNoYW5nZXMgbm90IHRo cm91Z2ggdGhlIE5NUywgY2hhbmdlcyB3aWxsIGJlDQo+IG5vdGlmaWVkIHRvIE5NUyB2aWEgcHVz aCBtZWNoYW5pc20uDQo+ID4gV2l0aCB5YW5nIHB1c2ggc29sdXRpb24sIGl0IHNvbHZlcyByZXN0 cmljdGlvbiBvZiBwb2xsaW5nIG1lY2hhbmlzbSBwcmV0dHkgd2VsbC4NCj4gPiBCdXQgYXMgSSBl eHBsYWluZWQsIHlhbmcgcHVzaCBtZWNoYW5pc20gaGFzIGFuIG9idmlvdXMgZHJhd2JhY2ssIGVh Y2gNCj4gY29uZmlndXJhdGlvbiBmcm9tIE5NUyB3aWxsIGhhdmUgYSBwdXNoIG1lc3NhZ2UgYmFj ayB0byBOTVMsIHdoaWNoIGlzIG5vdA0KPiBuZWVkZWQgaW4gbWFueSB1c2Ugc2NlbmFyaW9zLiBU aGlzIGJlaGF2aW9yIGFjdHVhbGx5IGltcGFjdCBwZXJmb3JtYW5jZSBhIGxvdC4NCj4gPiBJZiB0 aGlzIG1zZyBjYW4gYmUgZmlsdGVyZWQgZGlyZWN0bHkgd2l0aG91dCBnb2luZyB0aHJvdWdoIGFs bCBOZXRjb25mICtTU0gvVExTDQo+ICsgVENQIHByb2Nlc3MsIHRoZSBwZXJmb3JtYW5jZSBvZiB0 aGUgc3Vic2NyaWJlciB3aWxsIGltcHJvdmUgYSBsb3QgSSBiZWxpZXZlLg0KPiA+IEJhc2VkIG9u IG15IHVuZGVyc3RhbmRpbmcgeWFuZy1wdXNoIGlzIHRvIHNvbHZlIHBvbGxpbmcgbGF0ZW5jeSwg YnV0IGl0IHNob3VsZA0KPiBub3QgaGF2ZSBzaWduaWZpY2FudCBwZXJmb3JtYW5jZSBpbXBhY3Qg b24gZXhpc3RpbmcgYXBwbGljYXRpb25zLiBJZiBOTVMNCj4gY29uZmlndXJlIGEgZGV2aWNlIHdp dGggMTAwMCBjaGFuZ2VzIGFuZCB0aGUgZGV2aWNlIHB1c2ggMTAwMCBjaGFuZ2VzIGJhY2sgdG8N Cj4gTk1TLCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYW4gZWxlZ2FudCBpbXBsZW1lbnRhdGlvbiB3 aGVuIE5ldGNvbmYgaGFzIGFscmVhZHkNCj4gcHJvdmlkZSBlbm91Z2ggdHJhbnNhY3Rpb24gbWVj aGFuaXNtIGl0c2VsZi4gVGhlIGltcGFjdCBvZiBwdXNoIG1lY2hhbmlzbSBpcw0KPiBpdCBpbXBh Y3QgcGVyZm9ybWFuY2Ugb2YgOTklIG9mIHNjZW5hcmlvIChub3JtYWwgTk1TLT5kZXZpY2UgY29u ZmlndXJlDQo+IHByb2Nlc3MpIHRvIHNvbHZlIDElIG9mIHVzZSBjYXNlIChjb25maWd1cmF0aW9u IG5vdCBzeW5jIGluIHRpbWUpLg0KPiA+IEkgdW5kZXJzdGFuZCB0aGUgZGlmZmljdWx0eSBvZiBp bnRyb2R1Y2luZyBiaWcgY2hhbmdlcyBhdCB0aGlzIHN0YWdlLCBidXQgSSByZWFsbHkNCj4gd2lz aCB3ZSBjYW4gaGF2ZSBhbiBlbGVnYW50IHB1c2ggbWVjaGFuaXNtLiBBcHByZWNpYXRlIGFueSBj b21tZW50cyBvbg0KPiB0aGlzLg0KPiANCj4gKDEpIEknbSBub3QgY29udmluY2VkIHRoYXQgdGhp cyB3aWxsIGJlIGEgcGVyZm9ybWFuY2UgcHJvYmxlbSwgcGFydGljdWxhcmx5IGlmDQo+IGRhbXBl bmluZyBpcyBhcHBsaWVkIHRvIHRoZSBzdWJzY3JpcHRpb24sIG9yIGEgcGVyaW9kaWMgc3Vic2Ny aXB0aW9uIGlzIHVzZWQNCj4gaW5zdGVhZC7CoCBJLmUuIEkgc2VlIHRoYXQgWUFORyBwdXNoIHBl cmZvcm1hbmNlIHNob3VsZCBiZSBubyB3b3JzZSB0aGFuIHBvbGxpbmcsDQo+IGFuZCBJIGFudGlj aXBhdGUgdGhhdCBpdCB3aWxsIGJlIHNpZ25pZmljYW50bHkgYmV0dGVyLg0KPiAoMikgVGhlIFlB TkcgcHVzaCBkcmFmdCBpcyBhbHJlYWR5IDQgeWVhcnMgb2xkLiBJIHRoaW5rIHRoYXQgd2UgbXVz dCBqdXN0IGZpbmlzaA0KPiB3aGF0IHdlIGFyZSB3b3JraW5nIG9uIG5vdywgdGhlbiB3ZSBjYW4g ZGlzY3VzcyBleHRlbnNpb25zL2Z1dHVyZSB3b3JrLiBJZiB3ZQ0KPiBrZWVwIGNodXJuaW5nIHRo ZSByZXF1aXJlbWVudHMgYW5kIHNvbHV0aW9uIHRoZW4gd2UganVzdCBlbmQgdXAgd2l0aCBubw0K PiBzb2x1dGlvbiwgYW5kIHRoZSBtYXJrZXQgbG9va3MgZWxzZXdoZXJlIChhcyBpcyBhbHJlYWR5 IGhhcHBlbmluZykNCj4gDQo+IFNvLCBteSBwcmFnbWF0aWMgc3VnZ2VzdGlvbiBpczoNCj4gIMKg LSB3ZSBjb2xsZWN0aXZlbHkgdHJ5IG5vdCB0byBnZXQgc2lkZS10cmFja2VkIGRpc2N1c3Npbmcg dGhpcyBpbiBkZXRhaWwgbm93LA0KPiAgwqAtIGltcGxlbWVudCBpdCBhcyBpdCBpcyBkZWZpbmVk IGluIHRoZSBkcmFmdCwNCj4gIMKgLSBiZW5jaG1hcmsgaXQgdG8gc2VlIGhvdyBpdCBwZXJmb3Jt cyAocGVyaGFwcyBhbHNvIGNvbXBhcmUgdG8gcGVyZm9ybWFuY2UgaWYNCj4gSlNPTiwgb3IgQ0JP UiBpcyB1c2VkIGFzIGFuIGVuY29kaW5nIGFzIHdlbGwpLA0KPiAgwqAtIGlmIGl0IHJlYWxseSBw ZXJmb3JtcyBwb29ybHkgKHRoYXQgaXMgbm90IGR1ZSB0byBpbXBsZW1lbnRhdGlvbiksIHRoZW4g d3JpdGUgdXANCj4gYW4gSUQgZGVzY3JpYmluZyB0aGUgcHJvYmxlbSAoaW5jbHVkaW5nIHdoeSBk YW1wZW5pbmcvcGVyaW9kaWMgc3Vic2NyaXB0aW9ucw0KPiBkb24ndCBoZWxwKSwgd2l0aCBmaWd1 cmVzIHRvIGJhY2sgaXQgdXAsIGV0YywNCj4gIMKgLSB0aGUgV0cgY2FuIHRoZW4gZXZhbHVhdGUg d2hldGhlciB0aGlzIGlzIHJlYWxseSBhIHByb2JsZW0gdGhhdCBuZWVkcyB0byBiZQ0KPiBzb2x2 ZWQsIGFuZCBpZiBpdCBkb2VzIHRoZW4gc29tZW9uZSBjYW4gd3JpdGUgYSBkcmFmdCBwcm9wb3Np bmcgYW4gYXBwcm9wcmlhdGUNCj4gc29sdXRpb24uDQo+IA0KPiBEb2VzIHRoYXQgc2VlbSByZWFz b25hYmxlPw0KPiANCj4gVGhhbmtzLA0KPiBSb2INCj4gDQo+IA0KPiA+IDwvVGltPg0KPiA+DQo+ ID4+Pg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+DQo+ID4+PiBC b3RoIOKAnHN1YnNjcmliZXLigJ0gYW5kIOKAnHJlY2VpdmVy4oCdIGFyZSB1c2VkLCBiaXQgY29u ZnVzaW5nIHNvbWV0aW1lcy4NCj4gPj4+IFNoYWxsIHdlIG9ubHkgdXNlIOKAnHN1YnNjcmliZXLi gJ0NCj4gPj4+DQo+ID4+PiBUaGV5IGFyZSBkaWZmZXJlbnQgZW50aXRpZXMsIHRoZSBkZWZpbml0 aW9ucyBhcmUgaW4NCj4gPj4+IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNh dGlvbnM6DQo+ID4+Pg0KPiA+Pj4gICAgIFJlY2VpdmVyOiBBIHRhcmdldCB0byB3aGljaCBhIHB1 Ymxpc2hlciBwdXNoZXMgc3Vic2NyaWJlZCBldmVudA0KPiA+Pj4gICAgIHJlY29yZHMuICBGb3Ig ZHluYW1pYyBzdWJzY3JpcHRpb25zLCB0aGUgcmVjZWl2ZXIgYW5kIHN1YnNjcmliZXIgYXJlDQo+ ID4+PiAgICAgdGhlIHNhbWUgZW50aXR5Lg0KPiA+Pj4NCj4gPj4+ICAgICBTdWJzY3JpYmVyOiBB IGNsaWVudCBhYmxlIHRvIHJlcXVlc3QgYW5kIG5lZ290aWF0ZSBhIGNvbnRyYWN0IGZvciB0aGUN Cj4gPj4+ICAgICBnZW5lcmF0aW9uIGFuZCBwdXNoIG9mIGV2ZW50IHJlY29yZHMgZnJvbSBhIHB1 Ymxpc2hlci4gIEZvciBkeW5hbWljDQo+ID4+PiAgICAgc3Vic2NyaXB0aW9ucywgdGhlIHJlY2Vp dmVyIGFuZCBzdWJzY3JpYmVyIGFyZSB0aGUgc2FtZSBlbnRpdHkuDQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4N Cj4gPj4+IDMuMTEuMS4gIFJvYnVzdG5lc3MgYW5kIHJlbGlhYmlsaXR5DQo+ID4+Pg0KPiA+Pj4g ICAgIE5vdGU6IEl0IGlzIHBlcmZlY3RseSBhY2NlcHRhYmxlIHRvIGhhdmUgYSBzZXJpZXMgb2YN Cj4gPj4+ICJwdXNoLWNoYW5nZS0NCj4gPj4+DQo+ID4+PiAgICAgdXBkYXRlIiBub3RpZmljYXRp b25zIChhbmQgZXZlbiAicHVzaCB1cGRhdGUiIG5vdGlmaWNhdGlvbnMpDQo+ID4+PiBzZXJpYWxs eQ0KPiA+Pj4NCj4gPj4+ICAgICBxdWV1ZWQgYXQgdGhlIHRyYW5zcG9ydCBsYXllciBhd2FpdGlu ZyB0cmFuc21pc3Npb24uICBJdCBpcyBub3QNCj4gPj4+DQo+ID4+PiAgICAgcmVxdWlyZWQgdG8g bWVyZ2UgcGVuZGluZyB1cGRhdGUgcmVjb3Jkcy4gIEkuZS4sIHRoZSBkYW1wZW5pbmcNCj4gPj4+ IHBlcmlvZA0KPiA+Pj4NCj4gPj4+ICAgICBhcHBsaWVzIHRvIHVwZGF0ZSByZWNvcmQgY3JlYXRp b24sIG5vdCB0cmFuc21pc3Npb24uDQo+ID4+Pg0KPiA+Pj4gTXkgc3VnZ2VzdGlvbiBpczoNCj4g Pj4+DQo+ID4+PiBUaGUgcHVibGlzaGVyIHNob3VsZCBpbmNyZWFzZSBkYW1wZW5pbmcgcGVyaW9k IGF1dG9tYXRpY2FsbHkgaW4gY2FzZQ0KPiA+Pj4gdGhlIG1lc3NhZ2UgcXVldWUgcmVhY2hlcyBh IGxpbWl0Lg0KPiA+Pj4NCj4gPj4+IFRoaXMgaXMgdG8gYXZvaWQgbm90aWZpY2F0aW9ucyBsb3N0 IGR1ZSB0byBxdWV1ZSBsaW1pdCBpbiBjYXNlDQo+ID4+PiBzdWJzY3JpYmVyIGlzIGJ1c3kgb3Ig dGVtcG9yYXJpbHkgdW5yZWFjaGFibGUuDQo+ID4+Pg0KPiA+Pj4gSSBkb24ndCB0aGluayB0aGF0 IHRoaXMgaXMgaG93IHRoZSBkYW1wZW5pbmcgdGhhdCBpcyBjdXJyZW50bHkNCj4gPj4+IGRlZmlu ZWQgc2hvdWxkIHdvcmssIHNpbmNlIGl0IGlzIGV4cGVjdGVkIHRvIHByb3ZpZGUgYSBzdHJvbmcN Cj4gPj4+IGd1YXJhbnRlZSB0aGF0IGl0IHdpbGwgZWl0aGVyIGRlbGl2ZXIgdGhlIG5vdGlmaWNh dGlvbnMgdG8gdGhlDQo+ID4+PiByZWNlaXZlciwgb3Igb3RoZXJ3aXNlIG5vdGlmeSB0byB0aGUg cmVjZWl2ZXIgdGhhdCBzb21lIHVwZGF0ZXMgW21heV0gaGF2ZQ0KPiBiZWVuIGxvc3QuDQo+ID4+ Pg0KPiA+Pj4gSSBjb3VsZCBpbWFnaW5lIHRoYXQgYW5vdGhlciwgc29mdGVyIHR5cGUgb2YgZGFt cGVuaW5nLCBjb3VsZA0KPiA+Pj4gcG90ZW50aWFsbHkgYmUgZGVmaW5lZCBpbiBmdXR1cmUgYXMg YSBzZXBhcmF0ZQ0KPiA+Pj4gZXh0ZW5zaW9uL2F1Z21lbnRhdGlvbiwgYnV0IEkgZG9uJ3QgdGhp bmsgdGhhdCBzaG91bGQgZ28gaW50byB0aGlzDQo+ID4+PiBkb2N1bWVudCwgYmVjYXVzZSBpdCB3 b3VsZCBtYXNzaXZlbHkgc2xvdyBpdCBkb3duLCBhbmQgdGhlIGluZHVzdHJ5DQo+IGFscmVhZHkg bmVlZHMgdGhpcyBzdGFuZGFyZCBub3cuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4gKzEgLS0gdGhlIHNl cnZlciBkb2VzIHdoYXQgaXQgaXMgdG9sZCBhbmQgZG9lcyBub3QgZGVjaWRlIHRvIGNoYW5nZQ0K PiA+PiArdGhlDQo+ID4+IHN1YnNjcmlwdGlvbiBvbiBpdHMgb3duDQo+ID4gKzENCj4gPg0KPiA+ DQo+ID4gL21hcnRpbg0KPiA+DQo+ID4+DQo+ID4+DQo+ID4+Pg0KPiA+Pj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+DQo+ID4+PiBJdCB3b3VsZCBiZSBhcHByZWNpYXRlZCBp ZiBzdWdnZXN0aW9ucyBjYW4gYmUgZ2l2ZW4gb24gaG93IHB1c2gNCj4gPj4+IHNoYWxsIGJlIHVz ZWQgb24gcnVubmluZywgc3RhcnR1cCBhbmQgY2FuZGlkYXRlIGRhdGFzdG9yZXMNCj4gPj4+DQo+ ID4+PiBJdCBzaG91bGQgd29yayB0aGUgc2FtZSB3YXkgYXMgWUFORyBwdXNoIG9uIGFueSBvdGhl ciBkYXRhc3RvcmUuDQo+ID4+PiBUaGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQg c2VlbXMgdG8gYmUgZW50aXJlbHkgZGF0YXN0b3JlDQo+IGFnbm9zdGljLg0KPiA+Pj4gSW4gd2hh dCB3YXkgZG8geW91IHRoaW5rIGl0IG1heSBiZWhhdmUgZGlmZmVyZW50bHk/DQo+ID4+Pg0KPiA+ Pj4gQWx0aG91Z2ggSSBjb3VsZCBpbWFnaW5lIHRoYXQgaW1wbGVtZW50YXRpb25zIG1heSBub3Qg c3VwcG9ydA0KPiA+Pj4gc3Vic2NyaXB0aW9ucyBvbiBzdGFydHVwIG9yIGNhbmRpZGF0ZSwgaW4g d2hpY2ggY2FzZSBJIHdvdWxkIGV4cGVjdA0KPiA+Pj4gdGhhdCB0aGUgc3Vic2NyaXB0aW9uIHdv dWxkIGJlIHJlamVjdGVkLg0KPiA+Pj4NCj4gPiA8VGltPg0KPiA+IFRoYW5rcyBSb2IuDQo+ID4g SSB0aGluayB5b3UgdW5kZXJzdGFuZCBteSBjb25jZXJucy4gVGhlIHdob2xlIHlhbmcgcHVzaCBt ZWNoYW5pc20gaXMNCj4gZGF0YXN0b3JlIGFnbm9zdGljLg0KPiA+IEJ1dCBteSBwb3NpdGlvbiBp czogaWYgd2UgZm9sbG93IHRoaXMgZHJhZnQsIEkgYW0gcHJldHR5IHN1cmUgaW1wbGVtZW50YXRp b24gb2YNCj4geWFuZyBwdXNoIGxhdGVyIHdpbGwgYmUgZGlmZmVyZW50IGFjcm9zcyBhbGwgdmVu ZG9ycy4gU29tZW9uZSB3aWxsIGFjY2VwdA0KPiBzdWJzY3JpcHRpb24gb24gc3RhcnR1cCBidXQg b3RoZXJzIHdpbGwgcmVqZWN0LiBTb21lIHdpbGwgc3VwcG9ydCBwdXNoaW5nIGNoYW5nZXMNCj4g b24gY2FuZGlkYXRlIGJ1dCBvdGhlcnMgbm90Lg0KPiA+IEkgYmVsaWV2ZSB0aGUgb3JpZ2luYWwg aW50ZW50aW9uIG9mIE5ldGNvbmYgdG8gcHJvdmlkZSBhIHN0YW5kYXJkaXplZA0KPiBtZWNoYW5p c20gYW5kIHdlIGFyZSBhbGwgd29ya2luZyB0byBzY2FuZGFsaXplZCBhcyBtdWNoIGFzIHBvc3Np YmxlIHRvIGFsbG93DQo+IGRpZmZlcmVudCB2ZW5kb3JzIHRvIGhhdmUgaW50ZXJvcGVyYWJpbGl0 eSB3aXRoIGVhY2ggb3RoZXIuDQo+ID4gSWYgSUVURiB3b3JraW5nIGdyb3VwIGNhbiBnaXZlIGlu c3RydWN0aW9ucyBvbiBob3cgcHVzaCBtZWNoYW5pc20gY2FuIGJlDQo+IGFkb3B0ZWQgdG8gZGlm ZmVyZW50IGRhdGFzdG9yZXMgaW5zdGVhZCBvZiBsZXQgdmVuZG9ycyBtYWtlIGRlY2lzaW9ucw0K PiB0aGVtc2VsdmVzLCBJIGJlbGlldmUgd2UgaGF2ZSBhIHNvbHV0aW9uIGVhc2llciBnZXQgaW50 ZXJvcGVyYXRlZC4NCj4gPiA8L1RpbT4NCj4gPg0KPiA+DQo+ID4+PiBUaGFua3MsDQo+ID4+PiBS b2INCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4gQW5keQ0KPiA+Pg0KPiA+Pg0KPiA+Pj4NCj4g Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4N Cj4gPj4+IFJlZ2FyZHMsDQo+ID4+Pg0KPiA+Pj4gVGltDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBOZXRj b25mIG1haWxpbmcNCj4gPj4+IGxpc3ROZXRjb25mQGlldGYub3JnaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gTmV0 Y29uZiBtYWlsaW5nIGxpc3QNCj4gPj4+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+Pj4NCj4gPj4+DQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBOZXRj b25mIG1haWxpbmcgbGlzdA0KPiA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ IE5ldGNvbmZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mDQo= From nobody Wed Sep 5 01:45:41 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB79130DC5 for ; Wed, 5 Sep 2018 01:45:39 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVk6MFxq1AwP for ; Wed, 5 Sep 2018 01:45:36 -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 B5B1F128B14 for ; Wed, 5 Sep 2018 01:45:35 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B0BB0E3960B4E; Wed, 5 Sep 2018 09:45:32 +0100 (IST) Received: from LHREML523-MBS.china.huawei.com ([169.254.9.45]) by LHREML710-CAH.china.huawei.com ([10.201.108.33]) with mapi id 14.03.0399.000; Wed, 5 Sep 2018 09:45:25 +0100 From: "Yutianpeng (Tim)" To: Alexander Clemm , Robert Wilton , "netconf@ietf.org" Thread-Topic: [Netconf] Comments on draft-ietf-netconf-yang-push-18 Thread-Index: AdQ/rOk2O9B1aMu7RrSnvHTptxxrnQErdiaAAAAqBoAAADdugAACTR5QAAB+cIAAEinCgAARH4Yw Date: Wed, 5 Sep 2018 08:45:24 +0000 Message-ID: <35FF0D51C8DAB54B95B0426331F984FF52045F77@lhreml523-mbs.china.huawei.com> References: <35FF0D51C8DAB54B95B0426331F984FF520433B2@lhreml523-mbs.china.huawei.com> <20180904.173343.771736120417698474.mbj@tail-f.com> <35FF0D51C8DAB54B95B0426331F984FF52045B7E@lhreml523-mbs.china.huawei.com> <3855125a-3b54-3fa0-1762-dea1f45d6a75@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5C72E@sjceml521-mbs.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5C72E@sjceml521-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.203.126.98] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 08:45:39 -0000 VGhhbmtzIEFsZXgNCkFncmVlLCBpdCBjb3VsZCBiZSBtaW5vci4gTGV0J3Mga2VlcCBjdXJyZW50 IHB1c2ggdW5jaGFuZ2VkLg0KVGhhbmtzDQpUaW0NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEFsZXhhbmRlciBDbGVtbSANClNlbnQ6IDA1IFNlcHRlbWJlciAyMDE4IDAyOjM0 DQpUbzogUm9iZXJ0IFdpbHRvbiA8cndpbHRvbj00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz47 IFl1dGlhbnBlbmcgKFRpbSkgPHl1dGlhbnBlbmdAaHVhd2VpLmNvbT47IG5ldGNvbmZAaWV0Zi5v cmcNClN1YmplY3Q6IFJFOiBbTmV0Y29uZl0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1uZXRjb25m LXlhbmctcHVzaC0xOA0KDQorMSBvbiBhbGwgYWNjb3VudHMuICANCg0KVGltLCBhcyBleHBsYWlu ZWQsIGxldCB1cyBub3QgaW50cm9kdWNlIHRoaXMgY2hhbmdlLiAgSXQgbWFrZXMgaW1wbGVtZW50 YXRpb24gbW9yZSBjb21wbGV4IGFuZCBtYXkgZXZlbiBpbnRyb2R1Y2Ugb3RoZXIgaXNzdWVzLiAg RWxpbWluYXRpbmcgImRvdWJsZS1yZXBvcnRpbmciIG9mIGNoYW5nZXMgdG8gYSBjbGllbnQgYXBw bGljYXRpb24gdGhhdCBpcyBtYWtpbmcgY2hhbmdlcyB0byBkYXRhc3RvcmUgbm9kZXMgdG8gd2hv c2UgdXBkYXRlcyBpdCBoYXMgYWxzbyBzdWJzY3JpYmVkIGlzIGEgbWlub3Igb3B0aW1pemF0aW9u LiAgSWYgeW91IHJlYWxseSBoYXZlIGEgbmVlZCBmb3IgdGhpcyBmZWF0dXJlLCBpdCBjYW4gYmUg YXVnbWVudGVkIGludG8gdGhlIG1vZGVsIGFuZCBiZSBkZXNjcmliZWQgaW4gYSBzZXBhcmF0ZSBk cmFmdC4gIA0KDQpUaGFua3MNCi0tLSBBbGV4IA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBSb2JlcnQgDQo+IFdpbHRvbg0KPiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIg MDQsIDIwMTggOTo1NCBBTQ0KPiBUbzogWXV0aWFucGVuZyAoVGltKSA8eXV0aWFucGVuZ0BodWF3 ZWkuY29tPjsgbmV0Y29uZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIENvbW1l bnRzIG9uIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTgNCj4gDQo+IEhpIFRpbSwNCj4g DQo+IFBsZWFzZSBzZWUgaW5saW5lIC4uLg0KPiANCj4gDQo+IE9uIDA0LzA5LzIwMTggMTc6MjAs IFl1dGlhbnBlbmcgKFRpbSkgd3JvdGU6DQo+ID4gSGksDQo+ID4gVGhhbmtzIGZvciByZXBseS4N Cj4gPiBTb21lIGV4cGxhbmF0aW9ucyBhcyBiZWxvdywgcGxlYXNlIGNoZWNrLg0KPiA+IFRpbQ0K PiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBOZXRjb25mIFtt YWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluIA0KPiA+ IEJqb3JrbHVuZA0KPiA+IFNlbnQ6IDA0IFNlcHRlbWJlciAyMDE4IDE2OjM0DQo+ID4gVG86IGFu ZHlAeXVtYXdvcmtzLmNvbQ0KPiA+IENjOiBuZXRjb25mQGlldGYub3JnOyByd2lsdG9uPTQwY2lz Y28uY29tQGRtYXJjLmlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBDb21tZW50 cyBvbiBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTE4DQo+ID4NCj4gPiBBbmR5IEJpZXJt YW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4+IE9uIFR1ZSwgU2VwIDQsIDIwMTgg YXQgODoyMiBBTSwgUm9iZXJ0IFdpbHRvbiA8IA0KPiA+PiByd2lsdG9uPTQwY2lzY28uY29tQGRt YXJjLmlldGYub3JnPiB3cm90ZToNCj4gPj4NCj4gPj4+IEhpIFRpbSwNCj4gPj4+DQo+ID4+PiBQ bGVhc2Ugc2VlIGNvbW1lbnRzIChhcyBhIG5vbiBhdXRob3IpIGlubGluZSAuLi4NCj4gPj4+DQo+ ID4+PiBPbiAyOS8wOC8yMDE4IDE2OjI4LCBZdXRpYW5wZW5nIChUaW0pIHdyb3RlOg0KPiA+Pj4N Cj4gPj4+IEhpLA0KPiA+Pj4NCj4gPj4+IFNvbWUgY29tbWVudHMgYXMgYmVsb3c6DQo+ID4+Pg0K PiA+Pj4NCj4gPj4+DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+ DQo+ID4+PiBUaGVyZSBpcyBvbmUgcG9pbnQgbWlzc2luZyBpbiB0aGUgZHJhZnQgc28gZmFyIEkg dGhpbms6IHdoYXQgaWYgDQo+ID4+PiB0aGUgc3Vic2NyaWJlciBpcyB0aGUgaW5pdGlhdG9yIG9m IHRoZSBjb25maWd1cmF0aW9uIGNoYW5nZXM/DQo+ID4+Pg0KPiA+Pj4gSW4gdGhpcyBjYXNlLCB0 aGUgc3Vic2NyaWJlciBpcyBhd2FyZSBvZiBjb25maWd1cmF0aW9uIGNoYW5nZXMgDQo+ID4+PiBp bml0aWF0ZWQgYnkgaXRzZWxmIHdpdGhvdXQgcmVseWluZyBvbiB0aGUgcHVzaCBtZWNoYW5pc20u DQo+ID4+PiBJbnRyb2R1Y2luZyBwdXNoIG1lY2hhbmlzbSB3aWxsIGRyYW1hdGljYWxseSBpbXBh Y3QgdGhlIA0KPiA+Pj4gcGVyZm9ybWFuY2Ugb2YNCj4gdGhlIHN5c3RlbSBpbiB0aGlzIGNhc2Uu DQo+ID4+Pg0KPiA+Pj4gTXkgc3VnZ2VzdGlvbiBpczoNCj4gPj4+DQo+ID4+PiAzLjMuICBPbi1D aGFuZ2UgQ29uc2lkZXJhdGlvbnMNCj4gPj4+DQo+ID4+PiAgICAgNS4gIElmIHRoZSByZXN1bHRp bmcgcGF0Y2ggcmVjb3JkIGlzIG5vbi1lbXB0eSwgYW5kIGl0IA0KPiA+Pj4gY29udGFpbnMgdGhl IHJlY29yZHMgbm90IGluaXRpYXRlZCBieSB0aGUgc3Vic2NyaWJlciwgc2VsZWN0IHRoZXNlIA0K PiA+Pj4gcmVjb3JkcyBhbmQgc2VuZCB0byBjb3JyZXNwb25kaW5nIHN1YnNjcmliZXIuDQo+ID4+ Pg0KPiA+Pj4gV2UgY2FuIGhhdmUgZnVydGhlciBkaXNjdXNzaW9uIG9uIHRoaXMgdG8gbWFrZSBp dCBvcHRpb25hbCBpbnN0ZWFkIA0KPiA+Pj4gb2YgbWFuZGF0b3J5Lg0KPiA+Pj4NCj4gPj4+IEkn bSBub3Qga2VlbiBvbiB0aGlzIGNoYW5nZS4gIFRoaXMgZG9lcyBub3Qgc2VlbSBsaWtlIGEgZ29v ZCANCj4gPj4+IHNlcGFyYXRpb24gb2YgY29uY2VybnMuICBCZXNpZGVzLCBJJ20gbm90IGNvbnZp bmNlZCB3aHkgdGhpcyANCj4gPj4+IHNob3VsZCByZWFsbHkgYmUgYSBwZXJmb3JtYW5jZSBpc3N1 ZSBnaXZlbiB0aGF0IGNvbmZpZyBjaGFuZ2VzIGFyZSANCj4gPj4+IHJlbGF0aXZlbHkgcmFyZSBj b21wYXJlZCB0byBhbGwgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGluIHRoZSANCj4gPj4+IHN5c3Rl bSB0aGF0IG1heQ0KPiBiZSBjaGFuZ2luZy4NCj4gPj4+DQo+ID4+Pg0KPiA+PiArMSAtLSB0aGlz IGNoYW5nZSBzaG91bGQgbm90IGJlIG1hZGUuDQo+ID4+IFRoaXMgaXMgbm90IGEgdXNlZnVsIG9w dGltaXphdGlvbi4NCj4gPiArMQ0KPiA+DQo+ID4gPFRpbT4NCj4gPiBJIG1pZ2h0IGhhdmVuJ3Qg ZXhwbGFpbiB0aGUgbWFpbiBjb25jZXJucyBvbiB0aGlzIGNsZWFybHkuDQo+ID4gV2hlbiBJIHNl ZSBZYW5nLXB1c2gsIEkgZmluZCBpdCB2ZXJ5IHVzZWZ1bCBhcyBpdCByZWFsbHkgc29sdmVzIA0K PiA+IHByb2JsZW1zIGFsbA0KPiBOTVMvY29udHJvbGxlcnMgYXJlIGZhY2luZy4gQnV0IEkgZG8g aGF2ZSBhIGNvbmNlcm4gb24gdGhlIHBvaW50IEkgbWVudGlvbmVkLg0KPiA+IExldCBtZSBnaXZl IGFuIGV4YW1wbGUgdGhhdCBZYW5nLVB1c2ggY2FuIGJlIHVzZWQ6DQo+ID4gQmVmb3JlIFlhbmct cHVzaDoNCj4gPiBOTVMgaXMgdXNpbmcgTmV0Y29uZiB5YW5nIHRvIG1hbmFnZSBhIHJvdXRlciBO TVMgaXMgdXNpbmcgcG9sbGluZyANCj4gPiBtZWNoYW5pc20gdG8gc3luYyBjb25maWcgQW55b25l IG1ha2UgY2hhbmdlcyBub3QgdGhyb3VnaCBOTVMsIGUuZy4NCj4gPiBDTEksIE5NUyBpcyBub3Qg YXdhcmUgb2YgdGhlIGNoYW5nZSBpbiB0aW1lLg0KPiA+DQo+ID4gQWZ0ZXIgWWFuZy1wdXNoOg0K PiA+IE5NUyBpcyB1c2luZyBOZXRjb25mIHlhbmcgdG8gbWFuYWdlIGEgcm91dGVyIE5NUyBpcyB1 c2luZyBZYW5nLXB1c2ggDQo+ID4gbWVjaGFuaXNtIHRvIHN5bmMgY29uZmlndXJhdGlvbi4gSW4g b3JkZXIgdG8gbWFrZSBzdXJlIGFsbCBkYXRhYmFzZSANCj4gPiBpbiBzeW5jIHN0YXRlLCA8cnVu bmluZz4gZGF0YWJhc2UgaXMgc3Vic2NyaWJlZCAgLS0tIEkgYmVsaWV2ZSB0aGlzIA0KPiA+IGNv dWxkIGJlIGEgd2lkZWx5DQo+IHVzZSBjYXNlIEluIGNhc2UgYW55b25lIG1ha2UgY2hhbmdlcyBu b3QgdGhyb3VnaCB0aGUgTk1TLCBjaGFuZ2VzIHdpbGwgDQo+IGJlIG5vdGlmaWVkIHRvIE5NUyB2 aWEgcHVzaCBtZWNoYW5pc20uDQo+ID4gV2l0aCB5YW5nIHB1c2ggc29sdXRpb24sIGl0IHNvbHZl cyByZXN0cmljdGlvbiBvZiBwb2xsaW5nIG1lY2hhbmlzbSBwcmV0dHkgd2VsbC4NCj4gPiBCdXQg YXMgSSBleHBsYWluZWQsIHlhbmcgcHVzaCBtZWNoYW5pc20gaGFzIGFuIG9idmlvdXMgZHJhd2Jh Y2ssIA0KPiA+IGVhY2gNCj4gY29uZmlndXJhdGlvbiBmcm9tIE5NUyB3aWxsIGhhdmUgYSBwdXNo IG1lc3NhZ2UgYmFjayB0byBOTVMsIHdoaWNoIGlzIA0KPiBub3QgbmVlZGVkIGluIG1hbnkgdXNl IHNjZW5hcmlvcy4gVGhpcyBiZWhhdmlvciBhY3R1YWxseSBpbXBhY3QgcGVyZm9ybWFuY2UgYSBs b3QuDQo+ID4gSWYgdGhpcyBtc2cgY2FuIGJlIGZpbHRlcmVkIGRpcmVjdGx5IHdpdGhvdXQgZ29p bmcgdGhyb3VnaCBhbGwgDQo+ID4gTmV0Y29uZiArU1NIL1RMUw0KPiArIFRDUCBwcm9jZXNzLCB0 aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIHN1YnNjcmliZXIgd2lsbCBpbXByb3ZlIGEgbG90IEkgYmVs aWV2ZS4NCj4gPiBCYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nIHlhbmctcHVzaCBpcyB0byBzb2x2 ZSBwb2xsaW5nIGxhdGVuY3ksIGJ1dCANCj4gPiBpdCBzaG91bGQNCj4gbm90IGhhdmUgc2lnbmlm aWNhbnQgcGVyZm9ybWFuY2UgaW1wYWN0IG9uIGV4aXN0aW5nIGFwcGxpY2F0aW9ucy4gSWYgDQo+ IE5NUyBjb25maWd1cmUgYSBkZXZpY2Ugd2l0aCAxMDAwIGNoYW5nZXMgYW5kIHRoZSBkZXZpY2Ug cHVzaCAxMDAwIA0KPiBjaGFuZ2VzIGJhY2sgdG8gTk1TLCBJIGRvbid0IHRoaW5rIHRoaXMgaXMg YW4gZWxlZ2FudCBpbXBsZW1lbnRhdGlvbiANCj4gd2hlbiBOZXRjb25mIGhhcyBhbHJlYWR5IHBy b3ZpZGUgZW5vdWdoIHRyYW5zYWN0aW9uIG1lY2hhbmlzbSBpdHNlbGYuIA0KPiBUaGUgaW1wYWN0 IG9mIHB1c2ggbWVjaGFuaXNtIGlzIGl0IGltcGFjdCBwZXJmb3JtYW5jZSBvZiA5OSUgb2YgDQo+ IHNjZW5hcmlvIChub3JtYWwgTk1TLT5kZXZpY2UgY29uZmlndXJlDQo+IHByb2Nlc3MpIHRvIHNv bHZlIDElIG9mIHVzZSBjYXNlIChjb25maWd1cmF0aW9uIG5vdCBzeW5jIGluIHRpbWUpLg0KPiA+ IEkgdW5kZXJzdGFuZCB0aGUgZGlmZmljdWx0eSBvZiBpbnRyb2R1Y2luZyBiaWcgY2hhbmdlcyBh dCB0aGlzIA0KPiA+IHN0YWdlLCBidXQgSSByZWFsbHkNCj4gd2lzaCB3ZSBjYW4gaGF2ZSBhbiBl bGVnYW50IHB1c2ggbWVjaGFuaXNtLiBBcHByZWNpYXRlIGFueSBjb21tZW50cyBvbiANCj4gdGhp cy4NCj4gDQo+ICgxKSBJJ20gbm90IGNvbnZpbmNlZCB0aGF0IHRoaXMgd2lsbCBiZSBhIHBlcmZv cm1hbmNlIHByb2JsZW0sIA0KPiBwYXJ0aWN1bGFybHkgaWYgZGFtcGVuaW5nIGlzIGFwcGxpZWQg dG8gdGhlIHN1YnNjcmlwdGlvbiwgb3IgYSANCj4gcGVyaW9kaWMgc3Vic2NyaXB0aW9uIGlzIHVz ZWQgaW5zdGVhZC7CoCBJLmUuIEkgc2VlIHRoYXQgWUFORyBwdXNoIA0KPiBwZXJmb3JtYW5jZSBz aG91bGQgYmUgbm8gd29yc2UgdGhhbiBwb2xsaW5nLCBhbmQgSSBhbnRpY2lwYXRlIHRoYXQgaXQg d2lsbCBiZSBzaWduaWZpY2FudGx5IGJldHRlci4NCj4gKDIpIFRoZSBZQU5HIHB1c2ggZHJhZnQg aXMgYWxyZWFkeSA0IHllYXJzIG9sZC4gSSB0aGluayB0aGF0IHdlIG11c3QgDQo+IGp1c3QgZmlu aXNoIHdoYXQgd2UgYXJlIHdvcmtpbmcgb24gbm93LCB0aGVuIHdlIGNhbiBkaXNjdXNzIA0KPiBl eHRlbnNpb25zL2Z1dHVyZSB3b3JrLiBJZiB3ZSBrZWVwIGNodXJuaW5nIHRoZSByZXF1aXJlbWVu dHMgYW5kIA0KPiBzb2x1dGlvbiB0aGVuIHdlIGp1c3QgZW5kIHVwIHdpdGggbm8gc29sdXRpb24s IGFuZCB0aGUgbWFya2V0IGxvb2tzIA0KPiBlbHNld2hlcmUgKGFzIGlzIGFscmVhZHkgaGFwcGVu aW5nKQ0KPiANCj4gU28sIG15IHByYWdtYXRpYyBzdWdnZXN0aW9uIGlzOg0KPiAgwqAtIHdlIGNv bGxlY3RpdmVseSB0cnkgbm90IHRvIGdldCBzaWRlLXRyYWNrZWQgZGlzY3Vzc2luZyB0aGlzIGlu IA0KPiBkZXRhaWwgbm93LA0KPiAgwqAtIGltcGxlbWVudCBpdCBhcyBpdCBpcyBkZWZpbmVkIGlu IHRoZSBkcmFmdCwNCj4gIMKgLSBiZW5jaG1hcmsgaXQgdG8gc2VlIGhvdyBpdCBwZXJmb3JtcyAo cGVyaGFwcyBhbHNvIGNvbXBhcmUgdG8gDQo+IHBlcmZvcm1hbmNlIGlmIEpTT04sIG9yIENCT1Ig aXMgdXNlZCBhcyBhbiBlbmNvZGluZyBhcyB3ZWxsKSwNCj4gIMKgLSBpZiBpdCByZWFsbHkgcGVy Zm9ybXMgcG9vcmx5ICh0aGF0IGlzIG5vdCBkdWUgdG8gaW1wbGVtZW50YXRpb24pLCANCj4gdGhl biB3cml0ZSB1cCBhbiBJRCBkZXNjcmliaW5nIHRoZSBwcm9ibGVtIChpbmNsdWRpbmcgd2h5IA0K PiBkYW1wZW5pbmcvcGVyaW9kaWMgc3Vic2NyaXB0aW9ucyBkb24ndCBoZWxwKSwgd2l0aCBmaWd1 cmVzIHRvIGJhY2sgaXQgDQo+IHVwLCBldGMsDQo+ICDCoC0gdGhlIFdHIGNhbiB0aGVuIGV2YWx1 YXRlIHdoZXRoZXIgdGhpcyBpcyByZWFsbHkgYSBwcm9ibGVtIHRoYXQgDQo+IG5lZWRzIHRvIGJl IHNvbHZlZCwgYW5kIGlmIGl0IGRvZXMgdGhlbiBzb21lb25lIGNhbiB3cml0ZSBhIGRyYWZ0IA0K PiBwcm9wb3NpbmcgYW4gYXBwcm9wcmlhdGUgc29sdXRpb24uDQo+IA0KPiBEb2VzIHRoYXQgc2Vl bSByZWFzb25hYmxlPw0KPiANCj4gVGhhbmtzLA0KPiBSb2INCj4gDQo+IA0KPiA+IDwvVGltPg0K PiA+DQo+ID4+Pg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+DQo+ ID4+PiBCb3RoIOKAnHN1YnNjcmliZXLigJ0gYW5kIOKAnHJlY2VpdmVy4oCdIGFyZSB1c2VkLCBi aXQgY29uZnVzaW5nIHNvbWV0aW1lcy4NCj4gPj4+IFNoYWxsIHdlIG9ubHkgdXNlIOKAnHN1YnNj cmliZXLigJ0NCj4gPj4+DQo+ID4+PiBUaGV5IGFyZSBkaWZmZXJlbnQgZW50aXRpZXMsIHRoZSBk ZWZpbml0aW9ucyBhcmUgaW4NCj4gPj4+IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5v dGlmaWNhdGlvbnM6DQo+ID4+Pg0KPiA+Pj4gICAgIFJlY2VpdmVyOiBBIHRhcmdldCB0byB3aGlj aCBhIHB1Ymxpc2hlciBwdXNoZXMgc3Vic2NyaWJlZCBldmVudA0KPiA+Pj4gICAgIHJlY29yZHMu ICBGb3IgZHluYW1pYyBzdWJzY3JpcHRpb25zLCB0aGUgcmVjZWl2ZXIgYW5kIHN1YnNjcmliZXIg YXJlDQo+ID4+PiAgICAgdGhlIHNhbWUgZW50aXR5Lg0KPiA+Pj4NCj4gPj4+ICAgICBTdWJzY3Jp YmVyOiBBIGNsaWVudCBhYmxlIHRvIHJlcXVlc3QgYW5kIG5lZ290aWF0ZSBhIGNvbnRyYWN0IGZv ciB0aGUNCj4gPj4+ICAgICBnZW5lcmF0aW9uIGFuZCBwdXNoIG9mIGV2ZW50IHJlY29yZHMgZnJv bSBhIHB1Ymxpc2hlci4gIEZvciBkeW5hbWljDQo+ID4+PiAgICAgc3Vic2NyaXB0aW9ucywgdGhl IHJlY2VpdmVyIGFuZCBzdWJzY3JpYmVyIGFyZSB0aGUgc2FtZSBlbnRpdHkuDQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+Pj4NCj4gPj4+IDMuMTEuMS4gIFJvYnVzdG5lc3MgYW5kIHJlbGlhYmlsaXR5DQo+ID4+Pg0K PiA+Pj4gICAgIE5vdGU6IEl0IGlzIHBlcmZlY3RseSBhY2NlcHRhYmxlIHRvIGhhdmUgYSBzZXJp ZXMgb2YNCj4gPj4+ICJwdXNoLWNoYW5nZS0NCj4gPj4+DQo+ID4+PiAgICAgdXBkYXRlIiBub3Rp ZmljYXRpb25zIChhbmQgZXZlbiAicHVzaCB1cGRhdGUiIG5vdGlmaWNhdGlvbnMpIA0KPiA+Pj4g c2VyaWFsbHkNCj4gPj4+DQo+ID4+PiAgICAgcXVldWVkIGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIg YXdhaXRpbmcgdHJhbnNtaXNzaW9uLiAgSXQgaXMgDQo+ID4+PiBub3QNCj4gPj4+DQo+ID4+PiAg ICAgcmVxdWlyZWQgdG8gbWVyZ2UgcGVuZGluZyB1cGRhdGUgcmVjb3Jkcy4gIEkuZS4sIHRoZSBk YW1wZW5pbmcgDQo+ID4+PiBwZXJpb2QNCj4gPj4+DQo+ID4+PiAgICAgYXBwbGllcyB0byB1cGRh dGUgcmVjb3JkIGNyZWF0aW9uLCBub3QgdHJhbnNtaXNzaW9uLg0KPiA+Pj4NCj4gPj4+IE15IHN1 Z2dlc3Rpb24gaXM6DQo+ID4+Pg0KPiA+Pj4gVGhlIHB1Ymxpc2hlciBzaG91bGQgaW5jcmVhc2Ug ZGFtcGVuaW5nIHBlcmlvZCBhdXRvbWF0aWNhbGx5IGluIA0KPiA+Pj4gY2FzZSB0aGUgbWVzc2Fn ZSBxdWV1ZSByZWFjaGVzIGEgbGltaXQuDQo+ID4+Pg0KPiA+Pj4gVGhpcyBpcyB0byBhdm9pZCBu b3RpZmljYXRpb25zIGxvc3QgZHVlIHRvIHF1ZXVlIGxpbWl0IGluIGNhc2UgDQo+ID4+PiBzdWJz Y3JpYmVyIGlzIGJ1c3kgb3IgdGVtcG9yYXJpbHkgdW5yZWFjaGFibGUuDQo+ID4+Pg0KPiA+Pj4g SSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXMgaG93IHRoZSBkYW1wZW5pbmcgdGhhdCBpcyBjdXJy ZW50bHkgDQo+ID4+PiBkZWZpbmVkIHNob3VsZCB3b3JrLCBzaW5jZSBpdCBpcyBleHBlY3RlZCB0 byBwcm92aWRlIGEgc3Ryb25nIA0KPiA+Pj4gZ3VhcmFudGVlIHRoYXQgaXQgd2lsbCBlaXRoZXIg ZGVsaXZlciB0aGUgbm90aWZpY2F0aW9ucyB0byB0aGUgDQo+ID4+PiByZWNlaXZlciwgb3Igb3Ro ZXJ3aXNlIG5vdGlmeSB0byB0aGUgcmVjZWl2ZXIgdGhhdCBzb21lIHVwZGF0ZXMgDQo+ID4+PiBb bWF5XSBoYXZlDQo+IGJlZW4gbG9zdC4NCj4gPj4+DQo+ID4+PiBJIGNvdWxkIGltYWdpbmUgdGhh dCBhbm90aGVyLCBzb2Z0ZXIgdHlwZSBvZiBkYW1wZW5pbmcsIGNvdWxkIA0KPiA+Pj4gcG90ZW50 aWFsbHkgYmUgZGVmaW5lZCBpbiBmdXR1cmUgYXMgYSBzZXBhcmF0ZSANCj4gPj4+IGV4dGVuc2lv bi9hdWdtZW50YXRpb24sIGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgc2hvdWxkIGdvIGludG8gdGhp cyANCj4gPj4+IGRvY3VtZW50LCBiZWNhdXNlIGl0IHdvdWxkIG1hc3NpdmVseSBzbG93IGl0IGRv d24sIGFuZCB0aGUgDQo+ID4+PiBpbmR1c3RyeQ0KPiBhbHJlYWR5IG5lZWRzIHRoaXMgc3RhbmRh cmQgbm93Lg0KPiA+Pj4NCj4gPj4+DQo+ID4+ICsxIC0tIHRoZSBzZXJ2ZXIgZG9lcyB3aGF0IGl0 IGlzIHRvbGQgYW5kIGRvZXMgbm90IGRlY2lkZSB0byBjaGFuZ2UgDQo+ID4+ICt0aGUNCj4gPj4g c3Vic2NyaXB0aW9uIG9uIGl0cyBvd24NCj4gPiArMQ0KPiA+DQo+ID4NCj4gPiAvbWFydGluDQo+ ID4NCj4gPj4NCj4gPj4NCj4gPj4+DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+Pj4NCj4gPj4+IEl0IHdvdWxkIGJlIGFwcHJlY2lhdGVkIGlmIHN1Z2dlc3Rpb25zIGNh biBiZSBnaXZlbiBvbiBob3cgcHVzaCANCj4gPj4+IHNoYWxsIGJlIHVzZWQgb24gcnVubmluZywg c3RhcnR1cCBhbmQgY2FuZGlkYXRlIGRhdGFzdG9yZXMNCj4gPj4+DQo+ID4+PiBJdCBzaG91bGQg d29yayB0aGUgc2FtZSB3YXkgYXMgWUFORyBwdXNoIG9uIGFueSBvdGhlciBkYXRhc3RvcmUuDQo+ ID4+PiBUaGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgc2VlbXMgdG8gYmUgZW50 aXJlbHkgDQo+ID4+PiBkYXRhc3RvcmUNCj4gYWdub3N0aWMuDQo+ID4+PiBJbiB3aGF0IHdheSBk byB5b3UgdGhpbmsgaXQgbWF5IGJlaGF2ZSBkaWZmZXJlbnRseT8NCj4gPj4+DQo+ID4+PiBBbHRo b3VnaCBJIGNvdWxkIGltYWdpbmUgdGhhdCBpbXBsZW1lbnRhdGlvbnMgbWF5IG5vdCBzdXBwb3J0 IA0KPiA+Pj4gc3Vic2NyaXB0aW9ucyBvbiBzdGFydHVwIG9yIGNhbmRpZGF0ZSwgaW4gd2hpY2gg Y2FzZSBJIHdvdWxkIA0KPiA+Pj4gZXhwZWN0IHRoYXQgdGhlIHN1YnNjcmlwdGlvbiB3b3VsZCBi ZSByZWplY3RlZC4NCj4gPj4+DQo+ID4gPFRpbT4NCj4gPiBUaGFua3MgUm9iLg0KPiA+IEkgdGhp bmsgeW91IHVuZGVyc3RhbmQgbXkgY29uY2VybnMuIFRoZSB3aG9sZSB5YW5nIHB1c2ggbWVjaGFu aXNtIGlzDQo+IGRhdGFzdG9yZSBhZ25vc3RpYy4NCj4gPiBCdXQgbXkgcG9zaXRpb24gaXM6IGlm IHdlIGZvbGxvdyB0aGlzIGRyYWZ0LCBJIGFtIHByZXR0eSBzdXJlIA0KPiA+IGltcGxlbWVudGF0 aW9uIG9mDQo+IHlhbmcgcHVzaCBsYXRlciB3aWxsIGJlIGRpZmZlcmVudCBhY3Jvc3MgYWxsIHZl bmRvcnMuIFNvbWVvbmUgd2lsbCANCj4gYWNjZXB0IHN1YnNjcmlwdGlvbiBvbiBzdGFydHVwIGJ1 dCBvdGhlcnMgd2lsbCByZWplY3QuIFNvbWUgd2lsbCANCj4gc3VwcG9ydCBwdXNoaW5nIGNoYW5n ZXMgb24gY2FuZGlkYXRlIGJ1dCBvdGhlcnMgbm90Lg0KPiA+IEkgYmVsaWV2ZSB0aGUgb3JpZ2lu YWwgaW50ZW50aW9uIG9mIE5ldGNvbmYgdG8gcHJvdmlkZSBhIA0KPiA+IHN0YW5kYXJkaXplZA0K PiBtZWNoYW5pc20gYW5kIHdlIGFyZSBhbGwgd29ya2luZyB0byBzY2FuZGFsaXplZCBhcyBtdWNo IGFzIHBvc3NpYmxlIHRvIA0KPiBhbGxvdyBkaWZmZXJlbnQgdmVuZG9ycyB0byBoYXZlIGludGVy b3BlcmFiaWxpdHkgd2l0aCBlYWNoIG90aGVyLg0KPiA+IElmIElFVEYgd29ya2luZyBncm91cCBj YW4gZ2l2ZSBpbnN0cnVjdGlvbnMgb24gaG93IHB1c2ggbWVjaGFuaXNtIA0KPiA+IGNhbiBiZQ0K PiBhZG9wdGVkIHRvIGRpZmZlcmVudCBkYXRhc3RvcmVzIGluc3RlYWQgb2YgbGV0IHZlbmRvcnMg bWFrZSBkZWNpc2lvbnMgDQo+IHRoZW1zZWx2ZXMsIEkgYmVsaWV2ZSB3ZSBoYXZlIGEgc29sdXRp b24gZWFzaWVyIGdldCBpbnRlcm9wZXJhdGVkLg0KPiA+IDwvVGltPg0KPiA+DQo+ID4NCj4gPj4+ IFRoYW5rcywNCj4gPj4+IFJvYg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+PiBBbmR5DQo+ID4+ DQo+ID4+DQo+ID4+Pg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gUmVnYXJkcywNCj4gPj4+DQo+ID4+PiBUaW0NCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4+IE5ldGNvbmYgbWFpbGluZw0KPiA+Pj4gbGlzdE5ldGNvbmZAaWV0Zi5vcmdo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+PiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+Pj4gTmV0Y29uZkBpZXRmLm9y Zw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ ID4+Pg0KPiA+Pj4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gTmV0Y29uZkBpZXRmLm9yZw0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0Y29u ZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Wed Sep 5 08:50:00 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934B2129385 for ; Wed, 5 Sep 2018 08:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham 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 8EkYkSJmy9hL for ; Wed, 5 Sep 2018 08:49:55 -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 C28D21252B7 for ; Wed, 5 Sep 2018 08:49:55 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w85FiRPc013673 for ; Wed, 5 Sep 2018 08:49:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=urPRqPZm3Hp7DNX1uTO2aoFW2lrNzHfJGU1aUL1kx/o=; b=TUHc5+mZl5ef0SJWuFhSkcfDAqt7VuGuwBRgCR9FbTbSfPw90Gi2CLtAO8Elpthx9iZ9 hWDV94xfpzjHWaG/FGQwIwyjg83VImVFQFiWT6BlTHZzTi7YLmaC5eLNSSYCwey9uA9U Zcl31+LFXJqO9ZF4j/m9vVYegg5akKBs4vP6K8pVysmW475R1bmbhx+oDti7+FucVYV+ 2z+10KK21BYF540Ng32JJb5HBLHTJsW6I5U2V63ytG88jS9k012nZMU6xub1iqKpHckA ypOm68VSPe3kqi4V1GQ8LK6jzClSLWg0ht5OfklbX8WYTmgzpTa5agzBSb7X5q3QIlb9 FQ== Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp0115.outbound.protection.outlook.com [216.32.180.115]) by mx0b-00273201.pphosted.com with ESMTP id 2mab378vsx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 05 Sep 2018 08:49:54 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4746.namprd05.prod.outlook.com (20.176.109.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.6; Wed, 5 Sep 2018 15:49:53 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1143.000; Wed, 5 Sep 2018 15:49:53 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] Last Call on yang-push-17 Thread-Index: AQHUM/QwQhG4fwKiUkSHvZFCs3Awe6ThtTOA Date: Wed, 5 Sep 2018 15:49:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB4746; 6:RDaF3jkjLayWXCziapAqe96x3FuVF0CMM4b8z/qoW4dgNC58qGPmACCZGgRq70qonTSDwJkxIgk9vYjaUyhPB7FlBMdbVD68kQaVxXM36OFQayMhyTqEDErLzew/tRP/7EdZiY+F4zYV4ffUy7H8MezQX1QdwS1WOD5WCCs9vtLjSow2XOKFdzIMAB0VUOlPM8aKOPAyCVJWYl4Xr8NVtGB7nwNow84qGMoNIn0pQWPE/+uTYIMglFYh/eDDjNpolbEMers7wgHj0Kd+Kyi55q3QBK32cOOfrLBVrNqvPJvAWMXVLMebVbPGUYne5acJbHLjArh8bcWR60PPl6gFUYrUCvFcshYxLM44tROiREB/l5l+DVsUjhd2m48Yq1/ujTMCRlO252vgJLTudF9S6jSlevGjfhKb6JD0CCUAPjrD+vppRYPdT4vgYST/Kr5xxSoC4OMhviiJb/2eptk99g==; 5:cUhf1uVqmeZCz9sGqrdmOwq2D6ZjdULjnfEaeKipqzImpGOwdO66UKY04ZKXFkY8MbTwKO7yMpnEztLkV1VVNgmraD9R2dGoJMhinVoocjnYFvTf/flWYe5pGsnE9+6AhuVC2MhV+lEdcGkFid5FHcjfWNT4IcczUB6jFoe3Hcc=; 7:vceffxOZGQvDurddfa9Ia9WibzZGR9/LJo9uTalxP6aiHjvFK6c6QqfukheoElxKZ8stbTZ1abL1iWVb9K6KLTL2HdzNrJhMcY65tFyLP47IhAj0VjqJuUfRndrXP/eu+H76IDRHQsxVbNgXC7MgoUT6aEFSjhKc2iPza3b6been9F8cMg8+NpYvdxuDKccPvjSXyjYNHHYJwquCE+4bu8PSsMiOIihD+w6GX8j3dx+EUoEn+NceCQOLtcbZCdk5 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 3917861d-db2d-4123-69c4-08d613473886 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4746; x-ms-traffictypediagnostic: DM6PR05MB4746: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201708071742011)(7699016); SRVR:DM6PR05MB4746; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4746; x-forefront-prvs: 078693968A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(39860400002)(366004)(396003)(13464003)(199004)(189003)(5250100002)(2501003)(82746002)(316002)(97736004)(58126008)(86362001)(575784001)(478600001)(2900100001)(14454004)(3846002)(6116002)(966005)(36756003)(6436002)(6486002)(229853002)(6306002)(6512007)(83716003)(5640700003)(1730700003)(81166006)(5660300001)(81156014)(6916009)(256004)(14444005)(33656002)(486006)(446003)(476003)(11346002)(102836004)(2616005)(53936002)(6506007)(26005)(186003)(66066001)(68736007)(6246003)(305945005)(7736002)(76176011)(99286004)(8676002)(106356001)(2906002)(25786009)(8936002)(105586002)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4746; H:DM6PR05MB4665.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-microsoft-antispam-message-info: VzzWE1m8Y6EfkmaTM81rzqhDaPrKQpc9YuLX+A6YGb7iV1osMnXJ+SEbi44pXCrdWgqCtcIKzC7LbvgIl4tuzKMTDyFOnX/ic71LTwMPlegZQaN05IPn/LZFBcJCME+lSB6+RluktgD4B7YXJgGNvfvdE6HDXQkgotXUSzHPx2wIAqtwvyxA4GJYVC0fpfb6C4R0Sx6C1RR2zXj/WUSjclTi/XDabn3CPNiWjDAfdENWZp4Yc+fYYnGqGDLYIpaWFdDsYXHeev+Uye0OWprB84fdf0GAIljgYpZtlsxNekDsgC9DSCmgkLJwnUwHumexifmHIXGla4XIBqrV75Wp19ymRj3SpTJEOFa49HYNo4M= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 3917861d-db2d-4123-69c4-08d613473886 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2018 15:49:53.0231 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4746 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-05_09:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809050163 Archived-At: Subject: Re: [Netconf] Last Call on yang-push-17 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 15:49:58 -0000 DQpUaGlzIG1lc3NhZ2Ugc3VjY2Vzc2Z1bGx5IGNvbmNsdWRlcyB0aGUgTGFzdCBDYWxsIG9uIHlh bmctcHVzaC0xNy8xOA0Kc3RhcnRlZCBvbiB0aGUgQXVnIDE0dGguDQoNCkF1dGhvcnMsIHBsZWFz ZSBiZSBzdXJlIHRvIHJldmlldyBhbmQgcmVzcG9uZCB0byBhbGwgdGhyZWFkcywgYXMgc29tZSAN CmNvbW1lbnRzIGhhdmUgbm90IGJlZW4gYWNrbm93bGVkZ2VkIHlldC4gIFBsZWFzZSBiZSBzdXJl IHRvIGNsb3NlIGFsbA0KYWN0aXZlIHRocmVhZHMsIGFuZCB0aGVuIHBvc3QgYSAtMTkgZm9yIHNo ZXBoZXJkIHJldmlldy4NCg0KQXMgc2hlcGhlcmQsIEkgZmlyc3QgYXNrIGlmIGFueW9uZSBmZWVs cyAtMTkgZG9lcyBub3QgYWRlcXVhdGVseQ0KYWRkcmVzcyBhIGNvbW1lbnQgdGhleSBtYWRlIGR1 cmluZyB0aGUgTGFzdCBDYWxsLg0KDQpQbGVhc2UgYmUgc3VyZSB0aGF0IHRoZSAtMTkgcGFzc2Vz IGFsbCB2YWxpZGF0aW9uIHRvb2xzIChpZG5pdHMsIHlhbmcNCnZhbGlkYXRvcnMsIGluc3RhbmNl IGRvY3VtZW50IHZhbGlkYXRvcnMpIGFuZCB0aGF0IHRoZSB0cmVlLWRpYWdyYW1zDQphbmQgY29y cmVjdC4gSUlSQywgdGhlIGFydHdvcmsgaW4gdGhpcyBkcmFmdCBpcyBwbGFjZWQgYnkgaGFuZCwg dGhlDQpkcmFmdCBpcyBub3QgZHluYW1pY2FsbHktZ2VuZXJhdGVkLg0KDQpUaGFua3MsDQpLZW50 IChhbmQgTWFoZXNoKQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNClRoaXMgbWVz c2FnZSBzdGFydHMgYSBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0x NzoNCg0KICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEbmV0Y29uZi0yRHlhbmctMkRw dXNoLTJEMTcmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRY Y1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPTFM TGs2UVVJa3hRQXB3VjhteGhUNldTU0ctV2FheXBpdVpVSnNsMnFiM0Umcz1EVVpwN3RDRkZLMGp5 QUpxcW14QmRIUHZ6SlRzOUp4MktLdEZtU2dIY3I0JmU9DQoNCg0KVGhpcyBtYXJrcyB0aGUgYmVn aW5uaW5nIG9mIHRoZSBsYXN0IGNhbGxzIG9uIHRoZSB5YW5nIHB1c2ggc3VpdGUgb2YgZHJhZnRz Lg0KR2l2ZW4gdGhlIHNpemUgYW5kIG51bWJlciBvZiBkb2N1bWVudHMsIHRoZSBjaGFpcnMgZGVj aWRlZCB0byBicmVhayB0aGUgDQpyZXZpZXdzIHVwIGludG8gcGllY2VzIHNvIGFzIHRvIGdldCBm b2N1cyBvbiBlYWNoIGluIHR1cm4uICBXZSBhcmUgY2hvb3NpbmcNCnRvIGdvIHRvcC1kb3duLCBz dGFydGluZyB3aXRoIHlhbmctcHVzaCBhbmQgZW5kaW5nIHdpdGggdGhlICJub3RpZiIgZHJhZnRz Lg0KV2UgcGxhbiB0byBzdWJtaXQgdGhlIGRyYWZ0cyBmb3IgcHVibGljYXRpb24gd2hlbiB0aGV5 IGFyZSByZWFkeSBhcyBhIA0KY29sbGVjdGl2ZS4gIFRoZSBnb2FsIGlzIHRvIGRvIGFsbCB0aGlz IHByaW9yIHRvIElFVEYgMTAzLg0KDQpXZSB1bmRlcnN0YW5kIHRoYXQsIGluIHJldmlld2luZyB5 YW5nLXB1c2gsIHRoZXJlIGlzIGEgbmVlZCB0byBjb25zaWRlciB0aGUNCnN1YnNjcmliZWQtbm90 aWZpY2F0aW9ucyBkcmFmdC4gIFdlIHdpbGwgbm90IGJlIHN1cnByaXNlZCBpZiwgaW4gdGhlIGNv dXJzZQ0Kb2YgdGhpbmdzLCBib3RoIGRyYWZ0cyBhcmUgdXBkYXRlZCwgZXZlbiB0aG91Z2ggdGhl IHJldmlldyBpcyBwcmltYXJpbHkgb24NCnRoZSB5YW5nLXB1c2ggZHJhZnQuDQoNCldoaWxlIGl0 J3MgYWx3YXlzIG5pY2UgdG8gcmVjZWl2ZSBtZXNzYWdlcyBvZiBzdXBwb3J0LCBhdCB0aGlzIHRp bWUsIHRoZQ0KcXVlc3Rpb24gaXNuJ3Qgc28gbXVjaCBpZiB0aGUgd29ya2luZyBncm91cCBzdXBw b3J0cyB0aGUgd29yaywgdGhhbiBpZg0KdGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIHByb2dyZXNz LiAgVGhlIGNoYWlycyBuZWVkIHRvIHNlZSByZXZpZXdzIHRoYXQNCmluZGljYXRlIHRob3JvdWdo IGVuZC10by1lbmQgcmVhZGluZyBvZiB0aGUgdGV4dC4gIE9mIGNvdXJzZSwgaWYgdGhlcmUNCmFy ZSBhbnkgb2JqZWN0aW9ucywgdGhlc2Ugc2hvdWxkIGJlIGJyb3VnaHQgZm9yd2FyZCBub3cgYXMg d2VsbC4NCg0KVGhlIGN1cnJlbnQgdmVyc2lvbiAoLTE3KSBvZiB0aGlzIGRyYWZ0IHdhcyBwdWJs aXNoZWQgb24gSnVseSAxc3QsIGp1c3QNCmJlZm9yZSB0aGUgSUVURiAxMDIgbWVldGluZy4gIFRo ZSBkYXRhdHJhY2tlciBwYWdlIGZvciB0aGUgZHJhZnQgaXMgaGVyZToNCmh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5v cmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRG5ldGNvbmYtMkR5YW5nLTJEcHVzaCZkPUR3SUNBZyZjPUhB a1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdK OUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09MUxMazZRVUlreFFBcHdWOG14aFQ2V1NT Ry1XYWF5cGl1WlVKc2wycWIzRSZzPXFDM1BrU2hBM3hpR1Z1bmhVNDhEOGlKVWV5Zk5uc1prWGpM dzFDZWtMd00mZT0uDQoNCg0KVGhhbmtzLA0KS2VudCAoYW5kIE1haGVzaCkNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5n IGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0Y29u ZiZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0km cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09MUxMazZRVUlr eFFBcHdWOG14aFQ2V1NTRy1XYWF5cGl1WlVKc2wycWIzRSZzPUMtcFh2M205aU1TOGVERkk1SUxn TDM5Z1l6c015cGpyUVcxVEJMS2hOLXMmZT0NCg0KDQo= From nobody Wed Sep 5 11:07:40 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94EF130E4A for ; Wed, 5 Sep 2018 11:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9XeTaApeSE-X for ; Wed, 5 Sep 2018 11:07:27 -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 7964A130E68 for ; Wed, 5 Sep 2018 11:07:27 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6A303E9EA0267 for ; Wed, 5 Sep 2018 19:07:22 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 5 Sep 2018 19:07:24 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.188]) by SJCEML703-CHM.china.huawei.com ([169.254.5.30]) with mapi id 14.03.0415.000; Wed, 5 Sep 2018 11:07:20 -0700 From: Alexander Clemm To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [Netconf] Last Call on yang-push-17 Thread-Index: AQHUM/QwQhG4fwKiUkSHvZFCs3Awe6ThtTOAgABoeBA= Date: Wed, 5 Sep 2018 18:07:19 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5C988@sjceml521-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.35.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] Last Call on yang-push-17 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 18:07:38 -0000 Thanks, Kent (and Mahesh), and to the WG for the review effort, discussion,= and excellent comments received!=20 We plan to close on the remaining comments and post a new revision shortly = (before end-of-week). =20 --- Alex > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Wednesday, September 05, 2018 8:50 AM > To: netconf@ietf.org > Subject: Re: [Netconf] Last Call on yang-push-17 >=20 >=20 > This message successfully concludes the Last Call on yang-push-17/18 star= ted on > the Aug 14th. >=20 > Authors, please be sure to review and respond to all threads, as some com= ments > have not been acknowledged yet. Please be sure to close all active threa= ds, and > then post a -19 for shepherd review. >=20 > As shepherd, I first ask if anyone feels -19 does not adequately address = a > comment they made during the Last Call. >=20 > Please be sure that the -19 passes all validation tools (idnits, yang val= idators, > instance document validators) and that the tree-diagrams and correct. IIR= C, the > artwork in this draft is placed by hand, the draft is not dynamically-gen= erated. >=20 > Thanks, > Kent (and Mahesh) >=20 >=20 > -----Original Message----- >=20 > This message starts a Last Call on draft-ietf-netconf-yang-push-17: >=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_draft-2Dietf-2Dnetconf-2Dyang-2Dpush- > 2D17&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D1L > Lk6QUIkxQApwV8mxhT6WSSG- > WaaypiuZUJsl2qb3E&s=3DDUZp7tCFFK0jyAJqqmxBdHPvzJTs9Jx2KKtFmSgHcr4&e=3D >=20 >=20 > This marks the beginning of the last calls on the yang push suite of draf= ts. > Given the size and number of documents, the chairs decided to break the > reviews up into pieces so as to get focus on each in turn. We are choosi= ng to go > top-down, starting with yang-push and ending with the "notif" drafts. > We plan to submit the drafts for publication when they are ready as a col= lective. > The goal is to do all this prior to IETF 103. >=20 > We understand that, in reviewing yang-push, there is a need to consider t= he > subscribed-notifications draft. We will not be surprised if, in the cour= se of > things, both drafts are updated, even though the review is primarily on t= he yang- > push draft. >=20 > While it's always nice to receive messages of support, at this time, the = question > isn't so much if the working group supports the work, than if the documen= t is > ready to progress. The chairs need to see reviews that indicate thorough= end- > to-end reading of the text. Of course, if there are any objections, thes= e should > be brought forward now as well. >=20 > The current version (-17) of this draft was published on July 1st, just b= efore the > IETF 102 meeting. The datatracker page for the draft is here: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetconf-2Dyang- > 2Dpush&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D1L > Lk6QUIkxQApwV8mxhT6WSSG- > WaaypiuZUJsl2qb3E&s=3DqC3PkShA3xiGVunhU48D8iJUeyfNnsZkXjLw1CekLwM&e > =3D. >=20 >=20 > Thanks, > Kent (and Mahesh) >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_netconf&d=3DDwICAg&c=3DHAkYuh63rsuhr6Sc > bfh0UjBXeMK- > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D1L > Lk6QUIkxQApwV8mxhT6WSSG-WaaypiuZUJsl2qb3E&s=3DC- > pXv3m9iMS8eDFI5ILgL39gYzsMypjrQW1TBLKhN-s&e=3D >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Sep 5 14:18:22 2018 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 6499B130E79; Wed, 5 Sep 2018 14:18:09 -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.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <153618228936.19716.14585255533691765268@ietfa.amsl.com> Date: Wed, 05 Sep 2018 14:18:09 -0700 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-24.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 21:18:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Zero Touch Provisioning for Networking Devices Authors : Kent Watsen Mikael Abrahamsson Ian Farrer Filename : draft-ietf-netconf-zerotouch-24.txt Pages : 88 Date : 2018-09-05 Abstract: This draft presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enables 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-24 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-zerotouch-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-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 Wed Sep 5 15:28:28 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7479127332 for ; Wed, 5 Sep 2018 15:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MPFBXTkr6-2 for ; Wed, 5 Sep 2018 15:28:23 -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 46347130E0C for ; Wed, 5 Sep 2018 15:28:23 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 7D9D0A444A6C4 for ; Wed, 5 Sep 2018 23:28:17 +0100 (IST) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 5 Sep 2018 23:28:19 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.188]) by SJCEML702-CHM.china.huawei.com ([169.254.4.168]) with mapi id 14.03.0415.000; Wed, 5 Sep 2018 15:28:17 -0700 From: Alexander Clemm To: Robert Wilton , "netconf@ietf.org" Thread-Topic: [Netconf] RGW YANG push -18 LC comments [part 1] Thread-Index: AQHURFz5mZcbfiuvOkCz4w7aa9Vnj6Th+3bA Date: Wed, 5 Sep 2018 22:28:15 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CA9A@sjceml521-mbs.china.huawei.com> References: <386e425f-d250-a0a9-0927-1a484aed9042@cisco.com> In-Reply-To: <386e425f-d250-a0a9-0927-1a484aed9042@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.35.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] RGW YANG push -18 LC comments [part 1] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 22:28:27 -0000 SGVsbG8gUm9iLA0KDQp0aGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMhICBQbGVhc2UgZmluZCBt eSByZXBsaWVzIGlubGluZSwgPEFMRVg+LCB3aXRoIGNvcnJlc3BvbmRpbmcgY2hhbmdlcyB0byBi ZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUgbmV4dCByZXZpc2lvbiAoLTE5KS4NCg0KLS0tIEFsZXgN Cg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE5ldGNvbmYgW21haWx0 bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2JlcnQgV2lsdG9uDQo+ IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxOCA3OjM3IEFNDQo+IFRvOiBuZXRjb25m QGlldGYub3JnDQo+IFN1YmplY3Q6IFtOZXRjb25mXSBSR1cgWUFORyBwdXNoIC0xOCBMQyBjb21t ZW50cyBbcGFydCAxXQ0KPiANCj4gSGksDQo+IA0KPiBJJ3ZlIHJldmlld2VkIHRoZSAtMTggWUFO RyBwdXNoIGRyYWZ0IHVwIHRvIHNlY3Rpb24gNCBzbyBmYXIgLiBJJ3ZlIGluY2x1ZGVkIG15DQo+ IGNvbW1lbnRzIGJlbG93LsKgIEkgdGhpbmsgdGhhdCB0aGV5IGFyZSBhbGwgbWlub3IvY29zbWV0 aWMgZXhjZXB0IGZvciB0aGUgaXNzdWUNCj4gcmVnYXJkaW5nIHRoZSBkYW1wZW5lZCBzdWJzY3Jp cHRpb25zIHdoaWNoIGhhcyBiZWVuIGRpc2N1c3NlZCBiZWxvdyBhbmQNCj4gcHJvYmFibHkgZG9l cyBub3QgbmVlZCB0byBiZSByZWhhc2hlZCBhZ2Fpbi4NCj4gDQo+IEluIHRoZSBBYnN0cmFjdDoN Cj4gKDEpIElzICJjb250aW51b3VzIiB0aGUgcmlnaHQgY2hvaWNlIG9mIHdvcmQgaGVyZS7CoCBF LmcuIEkgdGhvdWdodCB0aGF0IHNvbWV0aW1lcw0KPiB0aGUgc3RyZWFtIG9mIHVwZGF0ZXMgaXMg bm90IGNvbnRpbnVvdXMuwqAgUG9zc2libHkgcmVtb3ZlICJjb250aW51b3VzIj8NCj4gDQoNCjxB TEVYPldvdWxkIHByZWZlciB0byBrZWVwLCB1bmxlc3MgeW91IGZlZWwgdmVyeSBzdHJvbmdseSBh Ym91dCB0aGlzPyAgV2hhdCB3ZSB3YW50IHRvIGJyaW5nIGFjcm9zcyBpcyB0aGF0IHRoaXMgaXMg ZGlmZmVyZW50IGZyb20gYSBvbmUtdGltZSwgb24tZGVtYW5kIHR5cGUgb2YgdXBkYXRlLiAgIlN0 cmVhbSIgbWlnaHQgaW1wbHkgdGhpcyBhbHJlYWR5LCBidXQgdGhpcyB3YXkgd2Ugd291bGQgZW1w aGFzaXplIHRoaXMgYSBiaXQgZnVydGhlci4gIA0KPC9BTEVYPg0KDQo+IA0KPiBJbiB0aGUgSW50 cm9kdWN0aW9uOg0KPiAoMikgInJlbW90ZSB2aXNpYmlsaXR5IiBpbiB0aGUgZmlyc3Qgc2VudGVu Y2UgaXMgYSBiaXQgb2JzY3VyZS4gUGVyaGFwcyByZXBsYWNlIHRoZQ0KPiBmaXJzdCBzZW50ZW5j ZSB3aXRoICJUcmFkaXRpb25hbCBhcHByb2FjaGVzIHRvIG1vbml0b3JpbmcgbWFuYWdlbWVudCBk YXRhIG9uDQo+IHJlbW90ZSBkZXZpY2VzIGhhdmUgYmVlbiBidWlsdCB1cG9uIHBvbGxpbmciLg0K DQo8QUxFWD4gSG93IGFib3V0IGNoYW5naW5nIHRoaXMgdG86ICJUcmFkaXRpb25hbCBhcHByb2Fj aGVzIHRvIHByb3ZpZGluZyB2aXNpYmlsaXR5IGludG8gbWFuYWdlZCBlbnRpdGllcyBmcm9tIHJl bW90ZSBoYXZlIGJlZW4gYnVpbHQgb24gcG9sbGluZy4gIg0KW0kgdW5kZXJzdGFuZCB5b3VyIHBv aW50LCBidXQgcmVhc29uIGZvciBhbHRlcm5hdGl2ZSBwaHJhc2luZyBpcyB0aGF0IEkgZG9uJ3Qg dGhpbmsgd2Ugd2FudCB0byByZXN0cmljdCB0aGlzIHRvIG1vbml0b3JpbmcgKGJlY2F1c2UgKGEp IHlvdSBjYW4gdXNlIHRoaXMgYWxzbyB0byBtaXJyb3Igc3RhdGUgZm9yIG90aGVyIHB1cnBvc2Vz LCBlLmcuIHRvIGFzc2VzcyBzcGVjaWZpY3Mgb2Ygd2hhdCBuZWVkcyB0byBiZSBkb25lIHRvIHBy b3Zpc2lvbiBhIHNlcnZpY2Ugc3VjY2Vzc2Z1bGx5LCBmb3IgdHJvdWJsZXNob290aW5nLCBtYWlu dGVuYW5jZSwgdmFsaWRhdGlvbiwgZXRjLCBhbmQgKGIpIG1vbml0b3JpbmcgZG9lcyBpbmNsdWRl IG90aGVyIGFzcGVjdHMgc3VjaCBhcyBhbGFybSBtYW5hZ2VtZW50KS4gIExJa2V3aXNlLCBzdWdn ZXN0IHRvIHJlZmVyIHRvICJtYW5hZ2VkIGVudGl0aWVzIiAobm90ICJkZXZpY2VzIikgdG8gbm90 IHByZWNsdWRlIGFwcGxpY2F0aW9uIHRvIHRoaW5ncyB0aGF0IGFyZSBub3QgZGV2aWNlcyAoZS5n LiB2aXJ0dWFsICJ0aGluZ3MiKS4gXSANCjwvQUxFWD4gDQoNCj4gDQo+ICgzKSBUaGUgd29yayBp c24ndCBhY3R1YWxseSBmcnVpdGxlc3MgaWYgcG9sbGluZyBpcyB0aGUgb25seSBhdmFpbGFibGUg b3B0aW9uLCBoZW5jZQ0KPiBwZXJoYXBzIGNoYW5nZToNCj4gDQo+IE9MRDoNCj4gIkZvciBhcHBs aWNhdGlvbnMgdGhhdCBtb25pdG9yIGZvciBjaGFuZ2VzLCBtYW55IHJlbW90ZSBwb2xsaW5nDQo+ ICDCoGN5Y2xlcyBwbGFjZSB1bHRpbWF0ZWx5IGZydWl0bGVzcyBsb2FkIG9uIHRoZSBuZXR3b3Jr LCBkZXZpY2VzLA0KPiAgwqBhbmQgYXBwbGljYXRpb25zLiINCj4gDQo+IE5FVzoNCj4gIMKgICJG b3IgYXBwbGljYXRpb25zIHRoYXQgbW9uaXRvciBmb3IgY2hhbmdlcywgbWFueSByZW1vdGUgcG9s bGluZw0KPiAgwqAgY3ljbGVzIHBsYWNlIHVud2FudGVkIGxvYWQgb24gdGhlIG5ldHdvcmssIGRl dmljZXMsDQo+ICDCoCBhbmQgYXBwbGljYXRpb25zLCBwYXJ0aWN1bGFybHkgaWYgdGhlIG1vbml0 b3JlZCB2YWx1ZXMgYXJlIG9ubHkgY2hhbmdpbmcNCj4gaW5mcmVxdWVudGx5LiINCj4gDQoNCjxB TEVYLiBUaGUgInVsdGltYXRlbHkgZnJ1aXRsZXNzIiBhbHNvIHJlZmVycyB0byB0aGUgZmFjdCB0 aGF0IG1hbnkgcG9sbHMgd2lsbCBub3QgeWllbGQgbmV3IGluZm9ybWF0aW9uIChvdGhlciB0aGFu ICJubyBuZXcgaW5mb3JtYXRpb24iKSwgYXMgeW91IG1pZ2h0IGUuZy4gcmV0cmlldmUgYSBsb3Qg b2Ygc3R1ZmYgdG8gc2VlIGlmIGl0IGNoYW5nZWQgb25seSB0byBmaW5kIHRoYXQgaXQgZGlkbid0 LiAgDQpIb3cgYWJvdXQ6ICIgRm9yIGFwcGxpY2F0aW9ucyB0aGF0IG1vbml0b3IgZm9yIGNoYW5n ZXMsIG1hbnkgcmVtb3RlIHBvbGxpbmcgY3ljbGVzIHBsYWNlIHVud2FudGVkIGFuZCB1bHRpbWF0 ZWx5IGZydWl0bGVzcyBsb2FkIG9uIHRoZSBuZXR3b3JrLCBkZXZpY2VzLCBhbmQgYXBwbGljYXRp b25zLCBwYXJ0aWN1bGFybHkgd2hlbiBjaGFuZ2VzIG9jY3VyIG9ubHkgaW5mcmVxdWVudGx5LiAi DQo8L0FMRVg+DQoNCj4gKDQpIEluIHBhcmFncmFwaCBzdGFydGluZyAiIEEgbW9yZSBlZmZlY3Rp dmUgYWx0ZXJuYXRpdmUiLCBwb3NzaWJseSBzdWdnZXN0DQo+IGNoYW5naW5nICJwdWJsaXNoZXIi IHRvICJzZXJ2ZXIiIHNpbmNlIHRoZSBpbnRyb2R1Y3Rpb24gaXMgYmVmb3JlIHRoZQ0KPiBkZWZp bml0aW9ucy9hY3JvbnltcyB3aGVyZSAicHVibGlzaGVyIiBpcyBmb3JtYWxseSByZWZlcmVuY2Vk Lg0KPiANCjxBTEVYPiBSZXdvcmRpbmcgdG8gIi4uLiB0aGF0IGVuYWJsZXMgdGhlIHNlcnZlciAo YWxzbyByZWZlcnJlZCB0byBhcyBwdWJsaXNoZXIpIHRvIHB1c2ggIC4uLiAiIDwvQUxFWD4NCj4g DQo+IEluIGRlZmluaXRpb25zOg0KPiANCj4gKDUpIFN1Z2dlc3QgdHlpbmcgdGhpcyBkZWZpbml0 aW9uIG1vcmUgY2xvc2VseSB0byB0aGUgdGVybWlub2xvZ3kgYWxyZWFkeSBkZWZpbmVkDQo+IGlu IFJGQyA4MzQyLCBoZW5jZToNCj4gDQo+IE9MRDoNCj4gIMKgwqAgb8KgIERhdGFzdG9yZSBub2Rl OiBBbiBpbnN0YW5jZSBvZiBtYW5hZ2VtZW50IGluZm9ybWF0aW9uIGluIGENCj4gIMKgwqDCoMKg wqAgZGF0YXN0b3JlLsKgIEFsc28ga25vd24gYXMgIm9iamVjdCIuDQo+IA0KPiBORVc6DQo+ICDC oMKgIG/CoCBEYXRhc3RvcmUgbm9kZTogQSBub2RlIGluIHRoZSBpbnN0YW50aWF0ZWQgWUFORyBk YXRhIHRyZWUgYXNzb2NpYXRlZCB3aXRoDQo+IGEgZGF0YXN0b3JlLsKgIEluIHRoaXMgZG9jdW1l bnQsIGRhdGFzdG9yZSBub2RlcyBhcmUgb2Z0ZW4gcmVmZXJyZWQgdG8gYXMgIllBTkcNCj4gb2Jq ZWN0cyIgb3IgIm9iamVjdHMiDQoNCjxBTEVYPiBPSy4gIChhbmQgcmVtb3ZlZCBpbnN0YW5jZSBv ZiAiWUFORyBvYmplY3QiIGZyb20gdGhlIGRvY3VtZW50LCBhcyB0aGVyZSB3ZXJlIG9ubHkgdHdv LikgPC9BTEVYPg0KDQo+IA0KPiAoNikgIkRhdGFzdG9yZSBub2RlIHVwZGF0ZSIgZGVmaW5pdGlv bjogRG9lcyB0aGlzIHVwZGF0ZSBvbmx5IGNvbnRhaW4gdGhlIHZhbHVlLA0KPiBvciBkb2VzIGl0 IGFsc28gY29udGFpbiB0aGUgcGF0aCB0byB0aGUgZGF0YXN0b3JlIG5vZGUgYXMgd2VsbD/CoCBJ ZiB0aGlzIGFsc28NCj4gY29udGFpbnMgdGhlIHBhdGggdGhlbiBpdCB3b3VsZCBiZSBnb29kIGlm IHRoYXQgd2FzIGV4cGxpY2l0IGluIHRoZSBkZWZpbml0aW9uLg0KPiANCg0KPEFMRVg+IFVwZGF0 ZWQgYXMgZm9sbG93czogIiBBIGRhdGEgaXRlbSBjb250YWluaW5nIHRoZSBjdXJyZW50IHZhbHVl IG9mIGEgZGF0YXN0b3JlIG5vZGUgYXQgdGhlIHRpbWUgdGhlIGRhdGFzdG9yZSBub2RlIHVwZGF0 ZSB3YXMgY3JlYXRlZCwgYXMgd2VsbCBhcyB0aGUgcGF0aCB0byB0aGUgZGF0YXN0b3JlIG5vZGUu IiAgPC9BTEVYPg0KDQo+ICg3KSBQZXJoYXBzIHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbiBpcyBt b3JlIHByZWNpc2U/wqAgT3IgYnkgInVwZGF0ZXMiDQo+IGRvIHlvdSBhY3R1YWxseSBtZWFuICJ1 cGRhdGUgcmVjb3JkcyI/wqAgVGhlcmUgYXJlIG90aGVyIHJlZmVyZW5jZXMgdG8NCj4gInVwZGF0 ZXMiIGluIHRoZSBkZWZpbml0aW9ucywgZG8gdGhlc2UgYWxsIHJlZmVyIHRvICJ1cGRhdGUgcmVj b3JkcyI/IElmIHNvIHRoZW4gSQ0KPiB3b3VsZCBzdWdnZXN0IG1vdmluZyB0aGUgZGVmaW5pdGlv biBvZiAidXBkYXRlIHJlY29yZCIgYWJvdmUgImRhdGFzdG9yZQ0KPiBzdWJzY3JpcHRpb24iLg0K PiANCj4gT0xEOg0KPiANCj4gIkRhdGFzdG9yZSBzdWJzY3JpcHRpb246IEEgc3Vic2NyaXB0aW9u IHRvIHVwZGF0ZXMgcmVnYXJkaW5nDQo+ICDCoMKgwqDCoMKgIGNvbnRlbnRzIG9mIGEgZGF0YXN0 b3JlLiINCj4gDQo+IE5FVzoNCj4gDQo+ICJEYXRhc3RvcmUgc3Vic2NyaXB0aW9uOiBBIHN1YnNj cmlwdGlvbiB0byBhIHN0cmVhbSBvZiBkYXRhc3RvcmUgbm9kZSB1cGRhdGVzLiINCg0KPEFMRVg+ IG9rLCBjaGFuZ2VkIDwvQUxFWD4NCg0KPiANCj4gKDgpIFN1Z2dlc3QgcmVtb3ZpbmcgImluc3Rh bnRpYXRlZCIgZnJvbSB0aGUgZm9sbG93aW5nIGRlZmluaXRpb24sIGFuZCB1c2luZw0KPiBkZXNj ZW5kYW50ICh3aGljaCBpcyB1c2VkIGluIDc5NTApIGluc3RlYWQgb2YgY29udGFpbmVkIC4uIEkg YWxzbyBzdWdnZXN0IG1vdmluZw0KPiB0aGUgZGVmaW5pdGlvbiB1cCwgZGlyZWN0bHkgYmVsb3cg ImRhdGFzdG9yZSBub2RlIjoNCj4gDQo+IE9MRDoNCj4gDQo+ICDCoMKgIG8gRGF0YXN0b3JlIHN1 YnRyZWU6IEFuIGluc3RhbnRpYXRlZCBkYXRhc3RvcmUgbm9kZSBhbmQgdGhlDQo+ICDCoMKgwqDC oMKgIGRhdGFzdG9yZSBub2RlcyB0aGF0IGFyZSBoaWVyYXJjaGljYWxseSBjb250YWluZWQgd2l0 aGluIGl0Lg0KPiANCj4gTkVXOg0KPiANCj4gIMKgwqAgbyBEYXRhc3RvcmUgc3VidHJlZTogQcKg IGRhdGFzdG9yZSBub2RlIGFuZCBhbGwgaXRzIGRlc2NlbmRhbnQgZGF0YXN0b3JlDQo+IG5vZGVz LiINCj4gDQoNCjxBTEVYPiBjaGFuZ2VkIDwvQUxFWD4NCg0KPiANCj4gKDkpIFNlYyAzLiBTb2x1 dGlvbiBvdmVydmlldywgbGFzdCBzZW50ZW5jZS7CoMKgIEl0IGlzIG5vdCAiWUFORyBvYmplY3Rz Ig0KPiB0aGF0IGFyZSBiZWluZyBwdXNoZWQsIGJ1dCBzdXJlbHkgImRhdGFzdG9yZSBub2RlIHVw ZGF0ZXMiIG9yIHBlcmhhcHMNCj4gInVwZGF0ZSByZWNvcmRzIiB0aGF0IGFyZSBwdXNoZWQsIG9y IGV2ZW4gIkNoYW5nZXMgdG8gWUFORyBvYmplY3RzIg0KPiANCg0KPEFMRVg+IENoYW5nZWQgdG8g ImRhdGFzdG9yZSBub2RlIHVwZGF0ZXMiIDwvQUxFWD4NCj4gDQo+IFNlYyAzLjEgU3Vic2NyaXB0 aW9uIG1vZGVsOg0KPiANCj4gKDEwKSBQZXJoYXBzIGNoYW5nZSJzdWJ0cmVlcyB3aXRoaW4gYSBk YXRhc3RvcmUiIHRvICJkYXRhc3RvcmUgc3VidHJlZXMiLg0KPiANCg0KPEFMRVg+IGNoYW5nZWQg PC9BTEVYPg0KDQo+ICgxMSkgSXQgaXMgbm90IG9idmlvdXMgdG8gbWUgZnJvbSB0aGlzIHRleHQg d2hhdCAiQW5jaG9yIHRpbWUiIGlzLA0KPiBhbHRob3VnaCBJIHN1c3BlY3QgdGhhdCBpdCBpcyBk ZXNjcmliZWQgaW4gbW9yZSBkZXRhaWwgbGF0ZXIgaW4gdGhlDQo+IGRvY3VtZW50LsKgIEdpdmVu IHRoYXQgdGhlIHNlY3Rpb24gb24tY2hhbmdlIHN1YnNjcmlwdGlvbnMgaGFzIG1vcmUNCj4gZGV0 YWlsIGZvciB2YXJpb3VzIHBhcmFtZXRlcnMsIEkgd29uZGVyIHdoZXRoZXIgaXQgd291bGQgYmUg aGVscGZ1bCB0bw0KPiBkZXNjcmliZSBhbmNob3IgdGltZSBpbiBtb3JlIGRldGFpbCBpbiB0aGlz IHNlY3Rpb24/DQo+IA0KDQo8QUxFWD4gUm91Z2hseSB3aGF0IGl0IGlzIGlzIGV4cGxhaW5lZCBp biB0aGUgc2FtZSBzZW50ZW5jZSwgYnV0IGhvdyBhYm91dCBjaGFuZ2luZyBpdCBhcyBmb2xsb3dz Og0KIiBUaGVzZSBwYXJhbWV0ZXJzIGFyZSB0aGUgcGVyaW9kIGludGVydmFsIHdpdGggd2hpY2gg dG8gcmVwb3J0IHVwZGF0ZXMsIGFuZCBhbiAiYW5jaG9yIHRpbWUiLCBpLmUuIGEgcmVmZXJlbmNl IHBvaW50IGluIHRpbWUgdGhhdCBjYW4gYmUgdXNlZCB0byBjYWxjdWxhdGUgYXQgd2hpY2ggcG9p bnRzIGluIHRpbWUgcGVyaW9kaWMgdXBkYXRlcyBuZWVkIHRvIGJlIGFzc2VtYmxlZCBhbmQgc2Vu dC4gIg0KPC9BTEVYPg0KDQo+ICgxMikgRGFtcGVuaW5nIHBlcmlvZDogVGhlIHRleHQgc3RhdGVz IHRoYXQgIlRoZSBkYW1wZW5pbmcgcGVyaW9kDQo+IGNvbGxlY3RpdmVseSBhcHBsaWVzIHRvIHRo ZSBzZXQgb2YgYWxsIGRhdGFzdG9yZSBub2RlcyBzZWxlY3RlZCBieSBhDQo+IHNpbmdsZSBzdWJz Y3JpcHRpb24gYW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2ZXIuIsKgIFRoaXMgd291bGQgaW1w bHkNCj4gdGhhdCBpZiBhIHNpbmdsZSBzdWJzY3JpcHRpb24gaGFkIG11bHRpcGxlIHJlY2VpdmVy cyB0aGF0IHRoZXkgd291bGQgYmUNCj4gZGFtcGVuZWQgaW5kZXBlbmRlbnRseSwgYnV0IGl0IHdh c24ndCBvYnZpb3VzIHRvIG1lIHRoYXQgdGhpcyBtYWtlcw0KPiBzZW5zZS7CoCBJIHdvdWxkIGFz c3VtZSB0aGF0IGZvciBhIGdpdmVuIHN1YnNjcmlwdGlvbiB0aGF0IGFsbCByZWNlaXZlcnMNCj4g d291bGQgcmVjZWl2ZSB0aGUgc2FtZSB1cGRhdGUgcmVjb3Jkcy4NCg0KPEFMRVg+IFllcy4gIFJl bW92ZWQgImFuZCBzZW50IHRvIGEgc2luZ2xlIHJlY2VpdmVyIi4gIEFsc28gY2xhcmlmaWVkIGZ1 cnRoZXIgKGluIGEgc2xpZ2h0IHJld29yZGluZykgIiBUaGlzIG1lYW5zIHRoYXQgd2hlbiB0aGVy ZSBpcyBhIGNoYW5nZSB0byBvbmUgb3IgbW9yZSBzdWJzY3JpYmVkIG9iamVjdHMsIGFuIHVwZGF0 ZSByZWNvcmQgY29udGFpbmluZyB0aG9zZSBvYmplY3RzIGlzIGNyZWF0ZWQgaW1tZWRpYXRlbHkg KHdoZW4gbm8gZGFtcGVuaW5nIHBlcmlvZCBpcyBpbiBlZmZlY3QpIG9yIGF0IHRoZSBlbmQgb2Yg YSBkYW1wZW5pbmcgcGVyaW9kICh3aGVuIGEgZGFtcGVuaW5nIHBlcmlvZCBpcyBpbiBmYWN0IGlu IGVmZmVjdCkuICAiDQo8L0FMRVg+DQoNCj4gDQo+ICgxMykgUmF0aGVyIHRoYW4gIk5vIFN5bmMg b24gc3RhcnQiLCBpdCBtaWdodCBiZSBiZXR0ZXIgdG8gcmVmZXIgdG8gdGhpcw0KPiBhc8KgICJz eW5jIG9uIHN0YXJ0Iiwgd2hpY2ggY291bGQgYmUgZGVmaW5lZCBhcyBhIGJvb2xlYW4gd2l0aCBk ZWZhdWx0DQo+IHRydWUgW0kndmUgbm90IGNoZWNrZWQgdGhlIFlBTkcgbW9kZWxdDQoNCjxBTEVY PiBpdCdzIG5vdCBkZWZpbmVkIGFzIGEgYm9vbGVhbiBidXQgYXMgYSBsZWFmIG9mIHR5cGUgZW1w dHkuICAoU28sIHRoZSAiZGVmYXVsdCIgaXMgaW4gZmFjdCB0cnVlLCB1bmxlc3MgIG5vLXN5bmMt b24tc3RhcnQgaXMgcHJlc2VudCkuICBJIGRvbid0IHNlZSBhIGNvbXBlbGxpbmcgcmVhc29uIHRv IGNoYW5nZSB0aGlzIGFuZCBzdWdnZXN0IHRvIGtlZXAgdGhpcyBhcy1pcy4gIA0KPC9BTEVYPg0K PiANCj4gDQo+IFNlYyAzLjIuIE5lZ290aWF0aW9uIG9mIFN1YnNjcmlwdGlvbiBQb2xpY2llcw0K PiANCj4gKDE0KSAiUmFuZG9tIGd1ZXNzaW5nIGF0IiA9PiAiUmFuZG9tIGd1ZXNzaW5nIG9mIi7C oCBBbHRob3VnaCwgSSB0aGluaw0KPiB0aGF0IHByb2JhYmx5IHRoaXMgZmlyc3Qgc2VudGVuY2Us IGFuZCB0aGUgIlRoZXJmb3JlLCAiIGNvdWxkIGp1c3QgYmUNCj4gZGVsZXRlZC7CoCBJLmUuIHN0 YXJ0aW5nIHRoZSBwYXJhZ3JhcGggIkluIG9yZGVyIHRvIG1pbmltaXplIC4uLiINCj4gDQoNCjxB TEVYPiBDaGFuZ2VkICJhdCIgdG8gIm9mIiwgaG93ZXZlciwgcHJlZmVyIHRvIGtlZXAgdGhlIGZp cnN0IHNlbnRlbmNlIGFzIGl0IGRvZXMgcHJvdmlkZSBzb21lIGV4cGxhbmF0aW9uLiAgPC9BTEVY Pg0KDQo+ICgxNSkgU3VnZ2VzdCBtaW5vciByZXdvcmRpbmcgb2YgMy4zLiB0aGlyZCBwYXJhZ3Jh cGg6DQo+IA0KPiBPTEQ6DQo+IA0KPiBJbiB0aGF0IGNhc2UsIHVwZGF0ZXMgYXJlIHNlbnQgb25s eSBmb3IgdGhvc2Ugb2JqZWN0cw0KPiAgwqDCoCB3aXRoaW4gdGhlIHNjb3BlIHRoYXQgZG8gc3Vw cG9ydCBvbi1jaGFuZ2UgdXBkYXRlcyB3aGVyZWFzIG90aGVyDQo+ICDCoMKgIG9iamVjdHMgYXJl IGV4Y2x1ZGVkIGZyb20gdXBkYXRlIHJlY29yZHMsIHdoZXRoZXIgb3Igbm90IHRoZWlyIHZhbHVl cw0KPiAgwqDCoCBhY3R1YWxseSBjaGFuZ2UuDQo+IA0KPiBORVc6DQo+IA0KPiBJbiB0aGF0IGNh c2UsIHVwZGF0ZXMgYXJlIHNlbnQgb25seSBmb3IgdGhvc2Ugb2JqZWN0cw0KPiAgwqDCoCB3aXRo aW4gdGhlIHNjb3BlIHRoYXQgZG8gc3VwcG9ydCBvbi1jaGFuZ2UgdXBkYXRlcywgd2hlcmVhcyBv dGhlcg0KPiAgwqDCoCBvYmplY3RzIGFyZSBleGNsdWRlZCBmcm9tIHVwZGF0ZSByZWNvcmRzLCBl dmVuIGlmIHRoZWlyIHZhbHVlcyBjaGFuZ2UuDQo+IA0KPEFMRVg+IGNoYW5nZWQgPC9BTEVYPg0K DQo+IA0KPiAoMTYpIFF1ZXN0aW9uIG9uIDMuMy4gZmlmdGggcGFyYWdyYXBoIChiZWxvdyksIGl0 J3MgdW5jbGVhciB0byBtZSB3aGF0DQo+IGlzIG1lYW50IGJ5ICJ3aGljaCBhcmUgY3VycmVudCBh dCB0aGUgdGltZSI6DQo+IA0KPiAiVmFsdWVzIHNlbnQgYXQgdGhlIGVuZCBvZiB0aGUNCj4gIMKg wqAgZGFtcGVuaW5nIHBlcmlvZCBhcmUgdGhlIGN1cnJlbnQgdmFsdWVzIG9mIGFsbCBjaGFuZ2Vk IG9iamVjdHMgd2hpY2gNCj4gIMKgwqAgYXJlIGN1cnJlbnQgYXQgdGhlIHRpbWUgdGhlIGRhbXBl bmluZyBwZXJpb2QgZXhwaXJlcy4iDQoNCjxBTEVYPiBSZXBocmFzZSB0aGUgcGFyYWdyYXBoIGFz IGZvbGxvd3MsIGp1c3QgdG8gbWFrZSBpdCBjbGVhciAoaXQncyBhIGJpdCBtb3JlIHZlcmJvc2Ug dGhhbiBpdCBoYXMgdG8sIGJ1dCB3ZSB3YW50IHRvIG1ha2Ugc3VyZSB0aGVyZSBpcyBubyBxdWVz dGlvbiBhcyB0byB3aGF0IHZhbHVlIHRvIHNlbmQgLSB0aGUgdmFsdWUgb2YgdGhlIG9yaWdpbmFs IGNoYW5nZSBvciB0aGUgdmFsdWUgYXQgdGhlIHRpbWUgb2YgdXBkYXRpbmcpLiAgDQoiLi4uIC4g IFZhbHVlcyBzZW50IGF0IHRoZSBlbmQgb2YgdGhlIGRhbXBlbmluZyBwZXJpb2QgYXJlIHRoZSB2 YWx1ZXMgdGhhdCBhcmUgY3VycmVudCBhdCB0aGUgZW5kIG9mIHRoZSBkYW1wZW5pbmcgcGVyaW9k IG9mIGFsbCBjaGFuZ2VkIG9iamVjdHMuICBDaGFuZ2VkIG9iamVjdHMgaW5jbHVkZSB0aG9zZSB3 aGljaCB3ZXJlIGRlbGV0ZWQgb3IgbmV3bHkgY3JlYXRlZCBkdXJpbmcgdGhhdCBkYW1wZW5pbmcg cGVyaW9kLiAgSWYgYW4gb2JqZWN0IGhhcyByZXR1cm5lZCB0byBpdHMgb3JpZ2luYWwgdmFsdWUg KG9yIGV2ZW4gaGFzIGJlZW4gY3JlYXRlZCBhbmQgdGhlbiBkZWxldGVkKSBkdXJpbmcgdGhlIGRh bXBlbmluZy1wZXJpb2QsIHRoYXQgdmFsdWUgKGFuZCBub3QgdGhlIGludGVyaW0gY2hhbmdlKSB3 aWxsIHN0aWxsIGJlIHNlbnQuIC4uLiINCjwvQUxFWD4gDQoNCj4gDQo+ICgxNykgSSBzdGlsbCBk b3VidCB0aGF0IGFsbCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBzdHJpY3RseSBmb2xsb3cgYWxsIG9m DQo+IDMuMy4gcGFyYWdyYXBoIDUsIHBhcnRpY3VsYXJseSB0aGUgY3JlYXRlZCBhbmQgZGVsZXRl ZCB3aXRoaW4gYQ0KPiBkYW1wZW5pbmcgcGVyaW9kIGJlY2F1c2UgSSBwZXJjZWl2ZSB0aGF0IGl0 IGlzIHBhcnRpY3VsYXJseSBkaWZmaWN1bHQgdG8NCj4gaW1wbGVtZW50IGNsZWFubHkvZWZmaWNp ZW50bHkuwqAgSG93ZXZlciwgdGhpcyBpc3N1ZSBoYXMgYmVlbiBkaXNjdXNzZWQNCj4gcHJldmlv dXNseSwgYW5kIEkgaGF2ZSBubyBwYXJ0aWN1bGFyIGRlc2lyZSB0byBzbG93IHRoZSBSRkMgcHJv Z3Jlc3MNCj4gZG93biB3aXRoIGZ1cnRoZXIgZGlzY3Vzc2lvbiBvbiB0aGlzLg0KPiANCg0KPEFM RVg+IE5vIGNoYW5nZSBtYWRlIDwvQUxFWD4gDQoNCj4gKDE4KSBTZWN0aW9uIDMuMywgY29uY2Vw dHVhbCBwcm9jZXNzLCBzdGVwIDEgc3RhdGVzIHRoYXQgYWNjZXNzIGNvbnRyb2wNCj4gcnVsZXMg YXJlIGNoZWNrZWQgdG8gZW5zdXJlIHRoZSByZWNlaXZlciBpcyBhdXRob3JpemVkIHRvIHZpZXcg YWxsDQo+IHN1YnNjcmliZWQgZGF0YXN0b3JlIG5vZGVzLCBidXQgSSB0aGluayB0aGF0IHRoaXMg c2hvdWxkIHN0YXRlIHRoYXQgdGhlDQo+IGFjY2VzcyBjb250cm9sIHJ1bGVzIGFyZSB1c2VkIHRv IGZpbHRlciB0aGUgc3Vic2NyaWJlZCBkYXRhc3RvcmUgbm9kZXMNCj4gdG8gdGhvc2UgdGhhdCB0 aGUgY2xpZW50IGhhcyBhY2Nlc3MgcmlnaHRzIHRvLg0KDQo8QUxFWD4gIEkgYWRkZWQgIiAoYW5k IGZpbHRlciBvdXQgYW55IG5vZGVzIGZvciB3aGljaCB0aGlzIGlzIG5vdCB0aGUgY2FzZSkiIHRv IG1ha2UgdGhpcyBjbGVhcmVyOyB0aGlzIG5vdyByZWFkcyAiIEp1c3QgYmVmb3JlIGEgY2hhbmdl LCBvciBhdCB0aGUgc3RhcnQgb2YgYSBkYW1wZW5pbmcgcGVyaW9kLCBldmFsdWF0ZSBhbnkgZmls dGVyaW5nIGFuZCBhbnkgYWNjZXNzIGNvbnRyb2wgcnVsZXMgdG8gZW5zdXJlIHJlY2VpdmVyIGlz IGF1dGhvcml6ZWQgdG8gdmlldyBhbGwgc3Vic2NyaWJlZCBkYXRhc3RvcmUgbm9kZXMgKGFuZCBm aWx0ZXIgb3V0IGFueSBub2RlcyBmb3Igd2hpY2ggdGhpcyBpcyBub3QgdGhlIGNhc2UpLiAiDQo8 L0FMRVg+DQoNCj4gDQo+ICgxOSkgQSByZWxhdGVkIHF1ZXN0aW9uOsKgIFdoZW4gaGFwcGVucyBp ZiB0aGVyZSBpcyBhbiBhY2Nlc3MgY29udHJvbA0KPiBjaGFuZ2UsIGkuZS4gdGhlIHJlY2VpdmVy IGhhZCBhY2Nlc3MgcHJldmlvdXNseSwgYnV0IHRoZW4gaXQgd2FzDQo+IHJldm9rZWQuwqAgRG9l cyBpdCBzZWUgYSBkZWxldGU/wqAgT3IgZG9lcyBpdCBub3QgZ2V0IGFueSBub3RpZmljYXRpb24/ DQo+IFNpbWlsYXJseSwgaWYgdGhleSBkaWRuJ3QgcHJldmlvdXNseSBoYXZlIGFjY2VzcywgYnV0 IHRoZW4gYWNjZXNzIHdhcw0KPiBncmFudGVkIGJlZm9yZSB0aGUgZW5kIG9mIHRoZSBkYW1wZW5p bmcgcGVyaW9kP8KgIE9LLCBJIHNlZSB0aGF0IHRoaXMgaXMNCj4gZGVzY3JpYmVkIGluIG1vcmUg ZGV0YWlsIGluIHNlY3Rpb24gMy45LCBwYXJhZ3JhcGggMy7CoCBQZXJoYXBzIGEgZm9yd2FyZA0K PiByZWZlcmVuY2Ugd291bGQgYmUgdXNlZnVsIGhlcmUuDQoNCjxBTEVYPiBJIHRoaW5rIHRoaXMg aXMgZGVmaW5lZCBpbiBkZXRhaWwgaW4gMy45LCBhcyB5b3Ugbm90ZS4gIEkgdGhpbmsgdGhlIHNw aXJpdCBvZiB0aGUgZGVzY3JpcHRpb24gaGVyZSBpcyBjbGVhciwgYW5kIEkgZG9uJ3Qgd2FudCB0 byBvdmVybHkgYnVyZGVuIHRoZSB0ZXh0IHdpdGggY3Jvc3MtcmVmZXJlbmNlcyB3aXRoaW4gdGhl IHNhbWUgdGV4dC4gIFNvLCBJIHN1Z2dlc3Qga2VlcGluZyB0aGlzIGFzLWlzLiAgDQo8L0FMRVg+ DQo+IA0KPiAoMjApIFNlY3Rpb24gMy4zLCBsYXN0IHBhcmFncmFwaCwgImNhbiBiZSBjcmVhdGVk IiA9PiAibXVzdCBiZSBjcmVhdGVkIi4NCg0KPEFMRVg+IEFjdHVhbGx5LCBJIHRoaW5rIGl0IGlz ICJjYW4iLiAgSXQgaXMgdXAgdG8gdGhlIGRpc2NyZXRpb24gb2Ygd2hhdCB0aGUgc3Vic2NyaWJl ciB3YW50cyB0byBkby4gICBBcyBhbiBhbHRlcm5hdGl2ZSB0byB1c2luZyB0aGUgd29yZCAiY2Fu IiAobm90IHN1cmUgaWYgdGhpcyBpcyByZWFsbHkgbmVlZGVkKSwgcmVwaHJhc2luZyBpdCB0byAi IEluIGNhc2VzIHdoZXJlIGEgc3Vic2NyaWJlciB3YW50cyB0byBoYXZlIHNlcGFyYXRlIGRhbXBl bmluZyBwZXJpb2RzIGZvciBkaWZmZXJlbnQgb2JqZWN0cywgdGhlIHN1YnNjcmliZXIgaGFzIHRo ZSBvcHRpb24gdG8gY3JlYXRlIG11bHRpcGxlIHN1YnNjcmlwdGlvbnMgd2l0aCBkaWZmZXJlbnQg c2VsZWN0aW9uIGZpbHRlcnMuICIgPC9BTEVYPg0KPiANCj4gKDIxKSBTZWN0aW9uIDMuNCwgc2Vj b25kIHBhcmFncmFwaCBkb2Vzbid0IHF1aXRlIHNjYW4uwqAgIlRoaXMgaW5jbHVkZXMNCj4gIMKg wqAgaW5kaWNhdGluZyB0aGUgZmFjdCB0aGF0IGFuIHVwZGF0ZSBpcyBpbmNvbXBsZXRlIGFzIHBh cnQgb2YgYSBwdXNoLQ0KPiAgwqDCoCB1cGRhdGUgcmVzcGVjdGl2ZWx5IHB1c2gtY2hhbmdlLXVw ZGF0ZSBub3RpZmljYXRpb24gLi4uIg0KPiANCg0KPEFMRVg+IEkgdGhpbmsgaXQgZG9lcyBzY2Fu LCBidXQgdG8gbWFrZSBpdCBqdXN0IHNsaWdodGx5IG1vcmUgY2xlYXIsIGhvdyBhYm91dCB1cGRh dGluZyB0byAiIFRoaXMgaW5jbHVkZXMgaW5kaWNhdGluZyB0aGUgZmFjdCB0aGF0IGFuIHVwZGF0 ZSBpcyBpbmNvbXBsZXRlIGFzIHBhcnQgb2YgYSBwdXNoLXVwZGF0ZSAocmVzcGVjdGl2ZWx5IHB1 c2gtY2hhbmdlLXVwZGF0ZSkgbm90aWZpY2F0aW9uLCBhcyB3ZWxsIGFzIGVtaXR0aW5nIGEgc3Vi c2NyaXB0aW9uLXN1c3BlbmRlZCBub3RpZmljYXRpb24gYXMgYXBwbGljYWJsZS4gIg0KPC9BTEVY Pg0KDQo+ICgyMikgU2VjdGlvbiAzLjQsIDNyZCBwYXJhZ3JhcGgsICJhYmxlIGZ1bGZpbGwiID0+ ICJhYmxlIHRvIGZ1bGZpbGwiDQo+IA0KDQo8QUxFWD4gY2hhbmdlZCA8L0FMRVg+DQoNCj4gKDIz KSBTZWN0aW9uIDMuNS4yLCAxc3QgcGFyYWdyYXBoLCAibm90IHJlc3RyaWN0ZWQgdG8gY29uZmln dXJhdGlvbg0KPiBvYmplY3RzIG9ubHkiID0+ICJub3Qgb25seSByZXN0cmljdGVkIHRvIGNvbmZp Z3VyYXRpb24gb2JqZWN0cyIuDQo+IA0KDQo8QUxFWD4gY2hhbmdpbmcgdG8gIiBub3QgcmVzdHJp Y3RlZCB0byBvbmx5IGNvbmZpZ3VyYXRpb24gb2JqZWN0cyIgICh0aGUgIm9ubHkiIHJlZmVycyB0 byB0aGUgY29uZmlndXJhdGlvbiBvYmplY3RzLCBub3QgdG8gdGhlIGZhY3QgdGhhdCBpdCBpcyBy ZXN0cmljdGVkKSA8L0FMRVg+DQoNCj4gKDI0KSBTZWN0aW9uIDMuNS4yLCAybmQgcGFyYWdyYXBo LCBwb3NzaWJsZSBhbHRlcm5hdGl2ZSB0ZXh0Og0KPiANCj4gT0xEOg0KPiANCj4gIMKgwqAgQSBw dWJsaXNoZXIgd2lsbCBpbmRpY2F0ZSBhIGNoYW5nZSB0byB0aGUgZWZmZWN0IHRoYXQgYSB2YWx1 ZSBvZiBhDQo+ICDCoMKgIGRhdGFzdG9yZSBub2RlIGhhcyBiZWVuIHVwZGF0ZWQgYnkgaW5kaWNh dGluZyBhICJyZXBsYWNlIiBvcGVyYXRpb24NCj4gIMKgwqAgKGFwcGxpZWQgdG8gdGhlIGRhdGFz dG9yZSBub2RlKSBpbiB0aGUgcGF0Y2guwqAgV2hlbiBhIG5ldyBkYXRhc3RvcmUNCj4gIMKgwqAg bm9kZSB3YXMgY3JlYXRlZCAob3RoZXIgdGhhbiBhbiBlbnRyeSBpbiBhIHVzZXIgb3JkZXJlZCBs aXN0KSwgYQ0KPiAgwqDCoCBwdWJsaXNoZXIgd2lsbCBpbmRpY2F0ZSBhICJjcmVhdGUiIG9wZXJh dGlvbiBpbiB0aGUgcGF0Y2guwqAgV2hlbiBhDQo+ICDCoMKgIGRhdGFzdG9yZSBub2RlIHdhcyBk ZWxldGVkLCB0aGUgcHVibGlzaGVyIGluZGljYXRlcyB0aGlzIGJ5IGENCj4gIMKgwqAgImRlbGV0 ZSIuwqAgV2hlbiBhIG5ldyBlbnRyeSBpbiBhIHVzZXItb3JkZXJlZCBsaXN0IHdhcyBjcmVhdGVk LCB0aGUNCj4gIMKgwqAgcHVibGlzaGVyIGluZGljYXRlcyB0aGlzIGJ5IGFuICJpbnNlcnQiIG9w ZXJhdGlvbi4gV2hlbiBhbiBlbnRyeSBpbg0KPiAgwqDCoCBhIHVzZXItb3JkZXJlZCBsaXN0IHdh cyBtb3ZlZCwgdGhlIHB1Ymxpc2hlciBpbmRpY2F0ZXMgdGhpcyBieSBhDQo+ICDCoMKgICJtb3Zl IiBvcGVyYXRpb24uDQo+IA0KPiBORVc6DQo+IA0KPiAgwqAgQSBwdWJsaXNoZXIgaW5kaWNhdGVz IHRoZSB0eXBlIG9mIGNoYW5nZSB0byBhIGRhdGFzdG9yZSBub2RlIHVzaW5nDQo+IHRoZSBkaWZm ZXJlbnQgWUFORyBwYXRjaCBvcGVyYXRpb25zOsKgIHRoZSAiY3JlYXRlIiBvcGVyYXRpb24gaXMg dXNlZCBmb3INCj4gbmV3bHkgY3JlYXRlZCBvYmplY3RzIChleGNlcHQgZW50cmllcyBpbiBhIHVz ZXItb3JkZXJlZCBsaXN0KSwgdGhlDQo+ICJkZWxldGUiIG9wZXJhdGlvbiBpcyB1c2VkIGZvciBk ZWxldGVkIG9iamVjdHMgKGluY2x1ZGluZyBpbg0KPiB1c2VyLW9yZGVyZWQgbGlzdHMpLCB0aGUg InJlcGxhY2UiIG9wZXJhdGlvbiBpcyB1c2VkIHdoZW4gb25seSB0aGUNCj4gb2JqZWN0IHZhbHVl IGNoYW5nZXMsIHRoZSAiaW5zZXJ0IiBvcGVyYXRpb24gaXMgdXNlZCB3aGVuIGEgbmV3IGVudHJ5 IGlzDQo+IGluc2VydGVkIGluIGEgbGlzdCwgYW5kIHRoZSAibW92ZSIgb3BlcmF0aW9uIGlzIHVz ZWQgd2hlbiBhbiBleGlzdGluZw0KPiBlbnRyeSBpbiBhIHVzZXItb3JkZXJlZCBsaXN0IGlzIG1v dmVkLg0KPiANCg0KPEFMRVg+IE9LIChJIGRvbid0IGZlZWwgc3Ryb25nbHkgYWJvdXQgdGhpcykg PC9BTEVYPg0KDQo+IA0KPiAoMjUpIFNlY3Rpb24gMy41LjIsIGxhc3QgcGFyYWdyYXBoOiBJZiB5 b3Ugd2FudCB0byBhbGxvdyBkdXBsaWNhdGUNCj4gImNyZWF0ZSIgYW5kICJkZWxldGUiIGV2ZW50 cywgdGhlbiBpdCBtaWdodCBiZSBjbGVhbmVyIHRvIGVuY29kZSB0aGVtIGFzDQo+ICJtZXJnZSIg YW5kICJyZW1vdmUiP8KgIEkuZS4gaXQgc2VlbXMgdGhhdCB5b3UgaGF2ZSBjcmVhdGVkIGEgc2xp Z2h0bHkNCj4gZGlmZmVyZW50IGVuY29kaW5nIGZyb20gdmFuaWxsYSBZQU5HIHBhdGNoIGJlY2F1 c2Ugb2YgdGhlIHdheSB0aGF0DQo+IGVycm9ycyBhcmUgaGFuZGxlZCBkaWZmZXJlbnRseS7CoCBJ ZGVhbGx5LCBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgYSBjbGllbnQNCj4gY291bGQganVzdCBhcHBs eSB0aGlzIGFzIHJlZ3VsYXIgWUFORyBwYXRjaCwgYnV0IHRoaXMgb25seSB3b3JrcyB3aXRoDQo+ IHRoZSBlbmNvZGluZyBkZXNjcmliZWQgaGVyZSBpZiB0aGUgY2xpZW50cyBjb3B5IG9mIHRoZSBk YXRhc3RvcmUgaXMgaW4NCj4gc3luYyB3aXRoIHRoZSBzZXJ2ZXJzIG9sZCBjb3B5IG9mIHRoZSBk YXRhc3RvcmUgYXQgdGhlIHBvaW50IHRoYXQgdGhlDQo+IHBhdGNoIGlzIGdlbmVyYXRlZCBmcm9t LsKgIFRoaXMgc2VlbXMgc2xpZ2h0bHkgZnJhZ2lsZSB0byB1bmV4cGVjdGVkDQo+IGluY29uc2lz dGVuY2llcyBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyICh3aGljaCBJIGFwcHJlY2lhdGUgdGhh dCB5b3UNCj4gdHJ5IGFuZCBhdm9pZCkuDQo+IA0KDQo8QUxFWD4gSG1tLiAgV2hpbGUgaXQgbWF5 IGJlIHBvc3NpYmxlIHRvIHJlcGxhY2UgImRlbGV0ZSIgd2l0aCAicmVtb3ZlIiwgSSBhbSBub3Qg c28gc3VyZSBhYm91dCB0aGUgIm1lcmdlIiBwYXJ0LiAgQXQgdGhlIGVuZCBvZiB0aGUgZGF5LCB0 aGUgdXNlIGhlcmUgaXMgZGlmZmVyZW50IGZyb20gaGF2aW5nIGEgY2xpZW50IGFwcGx5IGEgcGF0 Y2ggb3BlcmF0aW9uIHRvIHRoZSBzZXJ2ZXIsIGFuZCB0aGUgc2VtYW50aWNzIG1heSBiZSBhIGxp dHRsZSBjbGVhcmVyIGJ5IGtlZXBpbmcgdGhpbmdzIGFzIHRoZXkgYXJlLCBzbyB3b3VsZCBwcmVm ZXIgdG8ga2VlcCB0aGluZ3MgYXMgZGVmaW5lZCBub3cuICANCjwvQUxFWD4gIA0KDQo+ICgyNikg U2VjdGlvbiAzLjYsIHNlY29uZCBwYXJhZ3JhcGgsIHdvdWxkIGl0IG5vdCBiZSBlYXNpZXIgdG8g YWxsb3cgdGhlDQo+IGNsaWVudCB0byByZXBsYWNlIGFuIGV4aXN0aW5nIGZpbHRlciByYXRoZXIg dGhhbiBoYXZpbmcgdG8gZXhwbGljaXRseQ0KPiByZW1vdmUgdGhlIG9sZCBmaWx0ZXIgYW5kIGFk ZCB0aGUgbmV3IG9uZT/CoCBPciBpZiB5b3UgbWVhbiB0aGF0IGFueSBuZXcNCj4gZmlsdGVyIHJl cGxhY2VzIHRoZSBleGlzdGluZyBmaWx0ZXIsIHRoZW4gdGhpcyBtYXkgYmUgbW9yZSBjbGVhcmx5 DQo+IGluZGljYXRlZCB3aXRoIHRoZSB0ZXh0OiAiQW4gUlBDIHJlcXVlc3QgcHJvcG9zaW5nIGEg bmV3IHNlbGVjdGlvbg0KPiBmaWx0ZXIgcmVwbGFjZXMgYW55IGV4aXN0aW5nIGZpbHRlci4gIg0K PiANCg0KPEFMRVg+IE9LLCBjaGFuZ2luZyBwZXIgeW91ciBzdWdnZXN0aW9uIHRvIG1ha2UgaXQg Y2xlYXIgdGhhdCB0aGUgZXhpc3RpbmcgZmlsdGVyIGlzIHJlcGxhY2VkLiAgPC9BTEVYPg0KDQo+ ICgyNykgU2VjdGlvbiAzLjYsIHBhcmFncmFwaCA2LCBzdGFydGluZyAiWFBhdGgiLsKgIFRoZSAi Ym9vbGVhbiIgZXhhbXBsZQ0KPiBpcyB1bmNsZWFyIHRvIG1lIGdpdmVuIHRoYXQgYSB4cGF0aCBm aWx0ZXIgYWx3YXlzIHJldHVybnMgYSBub2RlIHNldCBzbw0KPiBjYW4ndCByZXR1cm4gYSBib29s ZWFuIHJlc3VsdC7CoCBJIGFsc28gc3VnZ2VzdCBjaGFuZ2luZyAicGFzc2VzIGENCj4gZGF0YXN0 b3JlIG5vZGUiIHRvwqAgImluY2x1ZGVzIGEgZGF0YXN0b3JlIG5vZGUiLg0KDQo8QUxFWD4gcmVt b3ZlZCB0aGUgc2VudGVuY2UgYW5kIHNob3J0ZW5lZCB0aGUgcGFyYWdyYXBoLiAgSXQgbm93IHJl YWRzIGFzIGZvbGxvd3M6IA0KIiBYUGF0aCBpdHNlbGYgcHJvdmlkZXMgcG93ZXJmdWwgZmlsdGVy aW5nIGNvbnN0cnVjdHMgYW5kIGNhcmUgbXVzdCBiZSB1c2VkIGluIGZpbHRlciBkZWZpbml0aW9u LiBDb25zaWRlciBhbiBYUGF0aCBmaWx0ZXIgd2hpY2ggb25seSBwYXNzZXMgYSBkYXRhc3RvcmUg bm9kZSB3aGVuIGFuIGludGVyZmFjZSBpcyB1cC4gSXQgaXMgdXAgdG8gdGhlIHJlY2VpdmVyIHRv IHVuZGVyc3RhbmQgaW1wbGljYXRpb25zIG9mIHRoZSBwcmVzZW5jZSBvciBhYnNlbmNlIG9mIG9i amVjdHMgaW4gZWFjaCB1cGRhdGUuICINCjwvQUxFWD4NCg0KPiANCj4gKDI4KSBTZWN0aW9uIDMu NiwgcGFyYWdyYXBoIDcuwqAgSSB0aGluayB0aGF0IHRoZSB0ZXh0IG11c3QgYmUgbW9yZQ0KPiBl eHBsaWNpdCBvbiB3aGVuIHRoZSBmaWx0ZXIgaXMgZXZhbHVhdGVkIGZvciBhIHBlcmlvZGljIHN1 YnNjcmlwdGlvbi4NCj4gQW0gSSByaWdodCBpbiB0aGlua2luZyB0aGF0IGl0IGlzIG9ubHkgZXZh bHVhdGVkIG9uY2Ugd2hlbiB0aGUNCj4gc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQsIG9yIHRoZSBz dWJzY3JpcHRpb24gaXMgY2hhbmdlZD8gU3BlY2lmaWNhbGx5LA0KPiBpZiB0aGUgbm9kZXNldCBl dmFsdWF0ZWQgZHVyaW5nIHRoZSBsaWZldGltZSBvZiBhbiBYcGF0aCBzdWJzY3JpcHRpb24NCj4g Y2hhbmdlcyB0aGVuIGRvZXMgdGhhdCBhZmZlY3Qgd2hpY2ggbm9kZXMgYXJlIHJldHVybmVkPw0K PiANCg0KPEFMRVg+IE5vdCBzdXJlIHdoYXQgY2hhbmdlcyB5b3UgYXJlIGxvb2tpbmcgZm9yLiAg VGhlIGZpbHRlciBpcyBpbiBlZmZlY3QgdGhyb3VnaG91dCB0aGUgc3Vic2NyaXB0aW9uIHVudGls IGl0IGlzIGNoYW5nZWQuICBJdCBpcyB1cCB0byBhbiBpbXBsZW1lbnRhdGlvbiB0byBkZWNpZGUg d2hldGhlciB0byBhcHBseSBpdCBvbmNlIHdoZW4gdGhlIHN1YnNjcmlwdGlvbiBpcyBlc3RhYmxp c2hlZCB0byBkZXRlcm1pbmUgdGhlIGRhdGFzdG9yZSBub2RlcyAodHJhY2tpbmcgYW55IHN1YnRy ZWUgY2hhbmdlcyB0byBtYWtlIHN1cmUgbm9kZXMgaW4gdGhlIHN1YnRyZWVzIGFyZSBpbmNsdWRl ZCBhcyBuZWVkZWQpLCBvciB3aGV0aGVyIHRvIGFwcGx5IGl0IGF0IGVhY2ggdXBkYXRlIGFuZXcu ICAgIA0KQXMgZmFyIGFzIHJlY2VpdmVyIGF1dGhvcml6YXRpb24gaXMgY29uY2VybmVkIChpLmUu IGFjY2VzcyBjb250cm9sIGZpbHRlcnMpLCB0aGlzIGlzIGV4cGxhaW5lZCBpbiBzZWN0aW9uIDMu OS4gIEFwcGx5aW5nIG5vIHRleHQgY2hhbmdlcyBhdCB0aGlzIHBvaW50IHVubGVzcyB5b3UgY2Fu IGJlIG1vcmUgY2xlYXIgb24gd2hhdCB5b3Ugd291bGQgbGlrZSB0byBzZWU/DQo8L0FMRVg+DQoN Cj4gKDI5KSBTZWN0aW9uIDMuNywgcGFyYWdyYXBoIDM6wqAgUGVyaGFwcyBtYWtlIHRoaXMgdGV4 dCBjb25kaXRpb25hbCB0bw0KPiBkYW1wZW5lZCBzdWJzY3JpcHRpb25zLsKgIFByZXN1bWFibHkg Zm9yIG5vbiBkYW1wZW5lZCBzdWJzY3JpcHRpb25zIGFsbA0KPiBjaGFuZ2VzIGFyZSByZXBvcnRl ZCBhcyBzZXBhcmF0ZSBwdXNoLWNoYW5nZS11cGRhdGUgbm90aWZpY2F0aW9ucz8NCj4gDQo+IE9M RDoNCj4gSW4gY2FzZXMgd2hlcmUgbXVsdGlwbGUgY2hhbmdlcyBoYXZlIG9jY3VycmVkIGFuZCB0 aGUgb2JqZWN0DQo+ICDCoMKgIGhhcyBub3QgYmVlbiBkZWxldGVkLCB0aGUgb2JqZWN0J3MgbW9z dCBjdXJyZW50IHZhbHVlIGlzIHJlcG9ydGVkLg0KPiANCj4gTkVXOg0KPiBJbiBjYXNlcyB3aGVy ZSBtdWx0aXBsZSBjaGFuZ2VzIGhhdmUgb2NjdXJyZWQgaW4gYSBzdWJzY3JpcHRpb24gdGhhdCBo YXMNCj4gZGFtcGVuaW5nIGVuYWJsZWQsIGFuZCB0aGUgb2JqZWN0DQo+ICDCoMKgIGhhcyBub3Qg YmVlbiBkZWxldGVkLCB0aGUgb2JqZWN0J3MgbW9zdCBjdXJyZW50IHZhbHVlIGlzIHJlcG9ydGVk Lg0KPiANCg0KPEFMRVg+IFdlbGwsIHRoZSB0ZXh0IHN0YXRlcyBjbGVhcmx5IHRoYXQgdGhpcyBj b25jZXJucyBhbnkgY2hhbmdlcyBzaW5jZSB0aGUgbGFzdCBub3RpZmljYXRpb24gbWVzc2FnZS4g IFNvLCB0aGUgZmFjdCB0aGF0IGRhbXBlbmluZyBpcyBlbmFibGVkIGlzIGFscmVhZHkgaW1wbGll ZC4gDQpIb3cgYWJvdXQgcmVwaHJhc2luZyBzbGlnaHRseSBhcyBmb2xsb3dzOg0KIiBJbiBjYXNl cyB3aGVyZSBtdWx0aXBsZSBjaGFuZ2VzIGhhdmUgb2NjdXJyZWQgb3ZlciB0aGUgY291cnNlIG9m IGEgZGFtcGVuaW5nIHBlcmlvZCBhbmQgdGhlIG9iamVjdCBoYXMgbm90IGJlZW4gZGVsZXRlZCwg dGhlIG9iamVjdCdzIG1vc3QgY3VycmVudCB2YWx1ZSBpcyByZXBvcnRlZC4gICINCjwvQUxFWD4N Cg0KPiANCj4gKDMwKSBTZWN0aW9uIDMuNywgcGFyYWdyYXBoIDUsICJFdGhlcm5ldCBwb3J0IiA9 PiAiRXRoZXJuZXQgaW50ZXJmYWNlIg0KPiANCg0KPEFMRVg+IGNoYW5nZWQgPC9BTEVYPg0KDQo+ ICgzMSkgU2VjdGlvbiAzLjcsIGxhc3QgcGFyYWdyYXBoOiBXaHkgc3RhcnQgYXQgIjEiIHJhdGhl ciB0aGFuICIwIi4gT24NCj4gb3ZlcmZsb3csIHdoeSBvdmVyZmxvdyB0byAiMSIgcmF0aGVyIHRo YW4gIjAiLCBpcyB0aGF0IGRlbGliZXJhdGU/wqAgSWYNCj4geW91IGFyZSBnb2luZyB0byBmb3Jj ZSBpdCB0byAiMSIgdGhlbiBJIHdvdWxkIGFsc28gcmVzdHJpY3QgdGhlIHVwcGVyDQo+IGJvdW5k IHRvIGludDMyIG1heCByYXRoZXIgdGhhbiB1aW50MzIgbWF4IHRvIG1ha2UgbGlmZSBlYXNpZXIg aW4gSmF2YQ0KPiBsYW5kIC4uLg0KDQo8QUxFWD4gT0ssIGdvdCBpdC4gIFVwZGF0ZWQgdGhlIHRl eHQgdG8gcmVmbGVjdCBzdGFydCBhdCAwLiAgDQo8L0FMRVg+IA0KDQo+IA0KPiAoMzIpIFNlY3Rp b24gMy44LCB0cmVlIGRpYWdyYW1zLsKgIEkgd291bGQgdGhpbmsgdGhhdCBhbm90aGVyIGtleSBt ZXRyaWMNCj4gcmVnYXJkaW5nIHdoZXRoZXIgYSBzdWJzY3JpcHRpb24gY2FuIGJlIHNhdGlzZmll ZCB3b3VsZCBiZSBvYmplY3QtcmF0ZQ0KPiBhbmQgZGF0YS1yYXRlLsKgIEUuZy4gYSBwdWJsaXNo ZXIgaW1wbGVtZW50YXRpb24gbWF5IGJlIGFibGUgdG8gcHVzaCAxMDBrDQo+IG9iamVjdHMvc2Vj b25kLCBzbyBhIGNsaWVudCBoYXMgYSBjaG9pY2Ugb2YgZWl0aGVyIG1vbml0b3JpbmcgbGVzcw0K PiBvYmplY3RzLCBvciBkZWNyZWFzaW5nIHRoZSBwZXJpb2QuwqAgSGVuY2UgSSB3YXMgd29uZGVy aW5nIHdoZXRoZXIgcmF0ZXMNCj4gc2hvdWxkIGJlIHByb3ZpZGVkIGluIGFkZGl0aW9uIHRvIHRo ZSBvYmplY3QtY291bnQtZXN0aW1hdGUvbGltaXQgYW5kDQo+IGtpbG9ieXRlLWVzdGltYXRlL2xp bWl0LsKgIE9mIGNvdXJzZSwgYSByYXRlIGlzIGFsc28gaW1wbGljaXRseSBkZWZpbmVkDQo+IGJ5 IGluY2x1ZGluZyB0aGUgcGVyaW9kIGhpbnQsIHNvIHBlcmhhcHMgdGhhdCBpcyBzdWZmaWNpZW50 IHdpdGhvdXQNCj4gbmVlZGluZyB0byBzZW5kIG1vcmUgZmllbGRzIGJhY2sgdG8gdGhlIGNsaWVu dC4NCj4gDQoNCjxBTEVYPiBXb3VsZCBwcmVmZXIgdG8ga2VlcCB0aGlzIHRvIHRoZSBiYXNpY3Ms IGkuZS4gYXMtaXMuICBBcyBtZW50aW9uZWQsIHlvdSBjYW4gY29tcHV0ZSBhIHJhdGUgZnJvbSB0 aGlzLiAgPC9BTEVYPg0KDQo+ICgzMykgU2VjdGlvbiAzLjksIDJuZCBwYXJhZ3JhcGgsICJwYXJ0 aWN1bGFyIGVhY2giID0+ICJwYXJ0aWN1bGFyIg0KDQo8QUxFWD4gY2hhbmdlZCA8L0FMRVg+DQoN Cj4gDQo+ICgzNCkgU2VjdGlvbiAzLjksIDNyZCBwYXJhZ3JhcGg6wqAgSXQgd2FzIG5vdCBlbnRp cmVseSBvYnZpb3VzIHRvIG1lIHdoYXQNCj4gdGhlIDNyZCBwYXJhZ3JhcGggdGV4dCAocmVwcm9k dWNlZCBiZWxvdykgYWN0dWFsbHkgbWVhbnMuwqAgSSB0aGluayB0aGF0DQo+IHRoaXMgYm9pbHMg ZG93biB0bzrCoCBJZiwgYWZ0ZXIgYWNjZXNzIGNvbnRyb2wgaGFzIGJlZW4gYXBwbGllZCwgdGhl cmUNCj4gYXJlIG5vIG9iamVjdHMgcmVtYWluaW5nIGluIGFuIHVwZGF0ZSByZWNvcmQgdGhlbiBv bmx5IGEgc2luZ2xlIGVtcHR5DQo+ICJwdXNoLXVwZGF0ZSIgbm90aWZpY2F0aW9uIE1BWSBiZSBz ZW50IGFuZCBlbXB0eSAicHVzaC1jaGFuZ2UtdXBkYXRlIg0KPiBtZXNzYWdlcyBNVVNUIE5PVCBi ZSBzZW50LsKgIFRoaXMgaXMgcmVxdWlyZWQgdG8gZW5zdXJlIHRoYXQgY2xpZW50cw0KPiBjYW5u b3Qgc3VycmVwdGl0aW91c2x5IG1vbml0b3Igb2JqZWN0cyB0aGF0IHRoZXkgZG8gbm90IGhhdmUg YWNjZXNzIHRvDQo+IHZpYSBjYXJlZnVsbHkgY3JhZnRlZCBzZWxlY3Rpb24gZmlsdGVycy4NCj4g DQo+ICJBIHB1Ymxpc2hlciBNVVNUIGFsbG93IGZvciB0aGUgcG9zc2liaWxpdHkgdGhhdCBhIHN1 YnNjcmlwdGlvbidzDQo+ICDCoMKgIHNlbGVjdGlvbiBmaWx0ZXIgcmVmZXJlbmNlcyBub24tZXhp c3RlbnQgb3IgYWNjZXNzLXByb3RlY3RlZCBkYXRhLg0KPiAgwqDCoCBTdWNoIHN1cHBvcnQgcGVy bWl0cyBhIHJlY2VpdmVyIHRoZSBhYmlsaXR5IHRvIG1vbml0b3IgdGhlIGVudGlyZQ0KPiAgwqDC oCBsaWZlY3lsZSBvZiBzb21lIGRhdGFzdG9yZSB0cmVlLsKgIEluIHRoaXMgY2FzZSwgYWxsICJw dXNoLXVwZGF0ZSINCj4gIMKgwqAgbm90aWZpY2F0aW9ucyBtdXN0IGJlIHNlbnQgZW1wdHksIGFu ZCBubyAicHVzaC1jaGFuZ2UtdXBkYXRlIg0KPiAgwqDCoCBub3RpZmljYXRpb25zIHdpbGwgYmUg c2VudCB1bnRpbCBzb21lIGRhdGEgYmVjb21lcyB2aXNpYmxlIGZvciBhDQo+ICDCoMKgIHJlY2Vp dmVyLiINCj4gDQoNCjxBTEVYPiBNb2RpZmllZCB0aGUgcGFyYWdyYXBoIGFscmVhZHkgZHVlIHRv IGFub3RoZXIgY29tbWVudCBpbiBhbm90aGVyIHRocmVhZC4gIFVwZGF0ZWQgdGhpcyBmdXJ0aGVy IHBlciB5b3VyIGNvbW1lbnRzLiAgTm93IGl0IHJlYWRzIGFzIGZvbGxvd3M6DQoiIEEgcHVibGlz aGVyIE1VU1QgYWxsb3cgZm9yIHRoZSBwb3NzaWJpbGl0eSB0aGF0IGEgc3Vic2NyaXB0aW9uJ3Mg c2VsZWN0aW9uIGZpbHRlciByZWZlcmVuY2VzIG5vbi1leGlzdGVudCBkYXRhIG9yIGRhdGEgdGhh dCBhIHJlY2VpdmVyIGlzIG5vdCBhbGxvd2VkIHRvIGFjY2Vzcy4gIFN1Y2ggc3VwcG9ydCBwZXJt aXRzIGEgcmVjZWl2ZXIgdGhlIGFiaWxpdHkgdG8gbW9uaXRvciB0aGUgZW50aXJlIGxpZmVjeWxl IG9mIHNvbWUgZGF0YXN0b3JlIHRyZWUgd2l0aG91dCBuZWVkaW5nIHRvIGV4cGxpY2l0bHkgZW51 bWVyYXRlIGV2ZXJ5IGluZGl2aWR1YWwgZGF0YXN0b3JlIG5vZGUuICBJZiwgYWZ0ZXIgYWNjZXNz IGNvbnRyb2wgaGFzIGJlZW4gYXBwbGllZCwgdGhlcmUgYXJlIG5vIG9iamVjdHMgcmVtYWluaW5n IGluIGFuIHVwZGF0ZSByZWNvcmQsIHRoZW4gKGluIGNhc2Ugb2YgYSBwZXJpb2RpYyBzdWJzY3Jp cHRpb24pIG9ubHkgYSBzaW5nbGUgZW1wdHkgInB1c2gtdXBkYXRlIiBub3RpZmljYXRpb24gTUFZ IGJlIHNlbnQuIEVtcHR5ICJwdXNoLWNoYW5nZS11cGRhdGUiIG1lc3NhZ2VzIChpbiBjYXNlIG9m IGFuIG9uLWNoYW5nZSBzdWJzY3JpcHRpb24pIE1VU1QgTk9UIGJlIHNlbnQuICBUaGlzIGlzIHJl cXVpcmVkIHRvIGVuc3VyZSB0aGF0IGNsaWVudHMgY2Fubm90IHN1cnJlcHRpdGlvdXNseSBtb25p dG9yIG9iamVjdHMgdGhhdCB0aGV5IGRvIG5vdCBoYXZlIGFjY2VzcyB0byB2aWEgY2FyZWZ1bGx5 IGNyYWZ0ZWQgc2VsZWN0aW9uIGZpbHRlcnMuIg0KDQpBbHNvIGFkZGluZyB0aGUgZm9sbG93aW5n IHNlbnRlbmNlLCB0byBjbGFyaWZ5IHRoZSBlZmZlY3Qgb24gZGFtcGVuaW5nOiAiIEJ5IHRoZSBz YW1lIHRva2VuLCBjaGFuZ2VzIHRvIG9iamVjdHMgdGhhdCBhcmUgZmlsdGVyZWQgTVVTVCBOT1Qg YWZmZWN0IGFueSBkYW1wZW5pbmcgaW50ZXJ2YWxzLiINCjwvQUxFWD4NCg0KDQo+ICgzNSkgU2Vj dGlvbiAzLjEwLsKgIFRoaXMgdGV4dCBzZWVtcyB0byBiZSB2ZXJ5IGNsb3NlbHkgcmVsYXRlZCB0 byB0aGUNCj4gdGV4dCBpbiBzZWN0aW9uIDMuMywgc28gcGVyaGFwcyBzZWN0aW9uIDMuMTAgd291 bGQgYmUgYmV0dGVyIG1vdmVkIHRvDQo+IGJlY29tZSBzZWN0aW9uIDMuMy4xPw0KPiANCg0KPEFM RVg+DQpEb24ndCB3YW50IHRvIGFwcGx5IG1ham9yIGVkaXRvcmlhbCByZXN0cnVjdHVpbmcgYXQg dGhpcyBwb2ludC4NCjwvQUxFWD4NCg0KPiAoMzYpIFNlY3Rpb24gMy4xMCwgbGFzdCBwYXJhZ3Jh cGguwqAgIndpbGwgYmUgZXhwZWN0ZWQgdG8iID0+ICJTSE9VTEQiPw0KDQo8QUxFWD5Ob3Qgc3Vy ZSB3ZSB3YW50IGl0IHRvIHNvdW5kIHNvIG5vcm1hdGl2ZSwgYnV0IHN1cmUgLSBjaGFuZ2luZyBp dCB0byBTSE9VTEQuIDwvQUxFWD4NCg0KPiANCj4gKDM3KSBTZWN0aW9uIDMuMTEuMSAiaW5jb21w bGV0ZS11cGRhdGUiIGZsYWcuwqAgSW4gdGhlIFlBTkcgZGVmaW5pdGlvbg0KPiB0aGlzIGZsYWcg aXMgc2V0IGluIHRoZSBoZWFkZXIgb2YgdGhlIG1lc3NhZ2UgKGkuZS4gYmVmb3JlIHRoZSBkYXRh KSwNCj4gYnV0IGZvciBhcHBsaWNhdGlvbnMgdGhhdCBhcmUgZ2VuZXJhdGluZyB0aGUgbm90aWZp Y2F0aW9ucyBpbiBhIHN0cmVhbWVkDQo+IHdheSwgaXQgd291bGQgcHJvYmFibHkgYmUgYmV0dGVy IHRvIHB1dCB0aGUgZmxhZyBhZnRlciBkYXRhLsKgIFRoaXMNCj4gcG90ZW50aWFsbHkgbWluaW1p emVzIHRoZSByZXF1aXJlbWVudCB0aGF0IGEgcHVibGlzaGVyIGhhcyB0byBidWZmZXIgYWxsDQo+ IGRhdGEgdG8gYmUgYWJsZSB0byBzZXQgdGhlIGluY29tcGxldGUtdXBkYXRlIGZsYWcgaWYgbmVj ZXNzYXJ5Lg0KDQo8QUxFWD4gT0ssIHNvIHlvdSBhcmUgc3VnZ2VzdGluZyB0byBtb3ZlIHRoZSAi aW5jb21wbGV0ZS11cGRhdGUiIGxlYWYgYmVoaW5kIHRoZSBkYXRhc3RvcmUgY29udGVudHMgKHJl c3BlY3RpdmVseSBkYXRhc3RvcmUtY2hhbmdlcykuICAgU3VyZSwgd2lsbCBjaGFuZ2UgdGhhdC4g DQo8L0FMRVg+ICANCg0KPiANCj4gKDM4KSBTZWN0aW9uIDMuMTEuMSAzcmQgcGFyYWdyYXBoIGFu ZCBidWxsZXQgcG9pbnRzLsKgIFdpdGggdGhlIHRleHQgYXMNCj4gY3VycmVudGx5IHdyaXR0ZW4s IGl0IGlzIGFjY2VwdGFibGUgZm9yIGEgcHVibGlzaGVyIHRvIGRvIG5vdGhpbmcgZXZlbg0KPiBp ZiBhbiBlcnJvciBpcyBoaXQuwqAgVGhleSBjYW4gc2F0aXNmeSB0aGUgZmlyc3QgIk1VU1QiIGJ5 IHNlbGVjdGluZyB0aGUNCj4gMm5kIGNob2ljZSwgYW5kIHRoZXkgY2FuIHNhdGlzZnkgdGhlICJN QVkiIG9mIHRoZSBzZWNvbmQgY2hvaWNlIGJ5IGRvaW5nDQo+IG5vdGhpbmcgYXQgYWxsLsKgIElu c3RlYWQgSSB0aGluayB0aGF0IHRoZSB0ZXh0IHNob3VsZCBzdGF0ZSB0aGF0IHRoZQ0KPiBwdWJs aXNoZXIgTVVTVCBzZXQgdGhlICJpbmNvbXBsZXRlLXVwZGF0ZSIgZmxhZywgb3Igc3VzcGVuZCB0 aGUNCj4gc3Vic2NyaXB0aW9uLCBvciBib3RoLg0KPiANCg0KPEFMRVg+DQpPSywgSSB0aGluayB0 aGUgcHJvYmxlbSBpcyB3aXRoICJNVVNUIHRha2Ugb24gb3IgbW9yZSBvZiB0aGUgZm9sbG93aW5n IGFjdGlvbnMiICAoYWx0aG91Z2ggSSB0aGluayB3aGF0IGlzIG1lYW50IGlzIGNsZWFyKS4gIFJl cGhyYXNpbmcgdGhpcyBhcyBmb2xsb3dzOiAgIiBJbiB0aGlzIGNhc2UsIHRoZSBwdWJsaXNoZXIg TVVTVCBhY3QgYXMgZm9sbG93cy4iDQoNCkFsc28gYWRkaW5nIHRoZSBmb2xsb3dpbmcgdG8gdGhl IHNlY29uZCBidWxsZXQgaXRlbTogDQoiIElmIHRoZSBwdWJsaXNoZXIgZG9lcyBub3QgY3JlYXRl IGFuIHVwZGF0ZSByZWNvcmQgYXQgYWxsLCBpdCBNVVNUIHN1c3BlbmQgdGhlIHN1YnNjcmlwdGlv bi4gICIgDQogKFRoaXMgaXMgcmVhbGx5IHRoZSBvbmx5IGxvZ2ljYWwgY2hvaWNlOyB3ZSBkb24n dCB3YW50IGEgcHVibGlzaGVyIHRvIGhhdmUgdGhlIG9wdGlvbiBvZiBzdGF5aW5nIGVudGlyZWx5 IHNpbGVudC4pICANCg0KLS0tIEFsZXgNCjwvQUxFWD4NCg0KPiBUaGFua3MsDQo+IFJvYg0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0 Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Wed Sep 5 15:55:13 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F7E12D7F8 for ; Wed, 5 Sep 2018 15:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 69CELFqFHISo for ; Wed, 5 Sep 2018 15:55:09 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722EE1294D7 for ; Wed, 5 Sep 2018 15:55:09 -0700 (PDT) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 03789852222DF for ; Wed, 5 Sep 2018 23:55:05 +0100 (IST) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 5 Sep 2018 23:55:07 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.188]) by SJCEML702-CHM.china.huawei.com ([169.254.4.168]) with mapi id 14.03.0415.000; Wed, 5 Sep 2018 15:55:03 -0700 From: Alexander Clemm To: Martin Bjorklund CC: "netconf@ietf.org" , "evoit@cisco.com" Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17 Thread-Index: AQHUNImzU9I4weZMB0iH1L0LVTTudKTT9lwAgAFivoCAAJuIoIABSioAgABMJJCAANGYgIAKDGSg Date: Wed, 5 Sep 2018 22:55:01 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CABF@sjceml521-mbs.china.huawei.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5B32B@sjceml521-mbs.china.huawei.com> <20180829.150740.1323981906990283714.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5B91A@sjceml521-mbs.china.huawei.com> <20180830.081021.1805437789668143807.mbj@tail-f.com> In-Reply-To: <20180830.081021.1805437789668143807.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.35.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] mbj's WGLC review of yang-push-17 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 22:55:11 -0000 Hi Martin, please see my responses inline, , trimming the closed stuff ("Ok.") Thanks --- Alex ... >=20 > > > > > > > o 3.11.1 > > > > > > > > > > > > > > The text says: > > > > > > > > > > > > > > It is not > > > > > > > required to merge pending update messages. > > > > > > > > > > > > > > This can be read as indicating that a server MAY merge pend= ing > > > > > > > update messages. I assume that it should say that pending = update > > > > > > > messages MUST NOT be merged. > > > > > > > > > > > > Hmm. I am not sure I agree. The server is not > > > > > > required to merge pending update messages - i.e. can send > > > > > > multiple messages each with a separate update record. > > > > > > However, there is no reason to preclude that they could be > > > > > > combined. So, I don't think an update is needed here. > > > > > > > > > > > > > > > > So you say that the text means that the server MAY merge pending > > > > > update messages in this case? If so, I think you should update > > > > > the text so that this is clear. > > > > > > > > > OK, how about saying "The server MAY (but does not have to) > > merge pending update messages". >=20 > Well, the term "update message" is not defined, so it shouldn't be used. > Presumably you mean "update record". sure >=20 > But I still don't really understand how this is supposed to work. The pu= sh-code in > the publisher creates an update record A and hands it over to the transpo= rt > layer, where it is queued: >=20 > It is perfectly acceptable to have a series of "push-change- > update" notifications (and even "push update" notifications) serially > queued at the transport layer awaiting transmission. >=20 > Then the push-code in the publisher creates another update record B and h= ands > it over to the transport layer. >=20 > Are you saying that the transport layer code now can merge these two upda= te > records into a single record? So if record A had "create foo, delete bar= " and > record B had "delete foo", there would be a single record with "delete ba= r, > delete foo"? >=20 > If two records are merged, what happens to the idea of using the 'patch-i= d' as > an indication of lost records? >=20 >=20 All this is saying is that it is up to the publisher to decide how t= o "group" the updates: whether to send a single update record (in a single = notification), or whether to create multiple records (sent with multiple no= tifications). =20 To make this clear, slight updates as follows: " It is perfectly acceptable to have a series of "push-change-update" notif= ications (and even "push update" notifications) serially queued at the tran= sport layer awaiting transmission. It is not required for the publisher to= merge pending update records sent at the the same time." From nobody Wed Sep 5 16:31:40 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F6612F295 for ; Wed, 5 Sep 2018 16:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham 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 Xhn71pGlxWRi for ; Wed, 5 Sep 2018 16:31:34 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 60F9712426A for ; Wed, 5 Sep 2018 16:31:34 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w85NTJFM017433 for ; Wed, 5 Sep 2018 16:31:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=xWiD4IFP9EmjXnpAXUhccv7luNE3BNdH0+UsDW+3zv4=; b=BWV+dP/cZrbdfMvno2YB5nOWJaTnChGRD5tyn1hv2BWktYsXJZu4J0dsYNfAw82oRBNR DJvD+enQB40qb5TqcUEnNDa26v5CnYDEl0SVLcaNMS2JyecMfUOYNZ/miN3REVqmt+mp eHt3Ym9NIhWKWCPzARdZ+AHgd5XQvDrXU0O8QLKJzmRznQatrqONGxQHqFmiiUFiddNY zZIXyrvRfZD49wU67cdc525PQYdceFX7/VXUDZxzqG2FYwbqBOfoChPaxXsLpJCtmx2g 9/6eDQF29hoP8SRY9f2tE0bTmH5U9P526dVkrFv6hvL6yGINIlgFFlIdHoic5XGQRsi3 tg== Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp0112.outbound.protection.outlook.com [216.32.180.112]) by mx0a-00273201.pphosted.com with ESMTP id 2madj4sdmk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 05 Sep 2018 16:31:34 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4953.namprd05.prod.outlook.com (20.177.221.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.12; Wed, 5 Sep 2018 23:31:31 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1143.000; Wed, 5 Sep 2018 23:31:31 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: Last Call on subscribed-notifications-16 Thread-Index: AQHURXCTPStqdu9N8EO45sjCvX2XlQ== Date: Wed, 5 Sep 2018 23:31:31 +0000 Message-ID: <7AC66C1A-9E8A-42C2-B577-0B129E67568D@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB4953; 6:eCBpa8eYs8LMLgNxB5lXrgod6uTrZyNH/xOOdiMRpDnHrr0LIBCTyvW5j7CGeQTduFkAOgYE6hEz3nTcRVFIaVxPr/fyshR+wgCOrT8JihW6ZIA/e2QaF2ShzbhZgbt8DLiDJcQzhIxuMDWsNNVbVG4RxWm9dzmqr2kTjqZNBICYeotjfKBbwOhUzALxW2Pl1UYF3DZvukBHu3tDyw9qPy1DsW9nMRpgcfsoLfx+iPmqUDQKDNM3+2GHoddxRgqFe6mrKaghySvbf2qvTzjTqjPK/rUW++8vguJbibuYID3a8VOa8R6v3YA2kHYNg4QLORydUOfOnMotXU5Q0sntuUqLS/N61Pb8wkwyrZDJ7c2npvSgxLGRyAsURfx4oje7DYo8tHlqOXr7cDDjO0OARumRJt/ro8LordgeFFRpf1TAkQsXwhyY7DpEC2mtjE73zKoAZIc2Citm5W7wyUG3bw==; 5:mJGqXi4Xmh5F8XBssKOMCJ0MyRVVsNgM2wnsOzl5sgV0Qgl8oi8nM/5JrCE9LxLr0dZ/zB92ygR9bkJCcI66bZZMh8KHG69/9thZNu2rzh8GWXLqPTU7LqL+Td1rYkv8DHiJjAQhVwqqUgJzQIfdA5n8MjHGlPNE/YpBIQIWDFk=; 7:YiiFjbW05GxGkjfQodhiAsg04p4fK8dV/d95xPjxeyMYckawm2+Zlkdms0HXSmAGbtTz4PnKzlkuDblpdhGi15fdFo+4fJDw8+xh8Y2wRn/CS4jOri/jEGrMitTaOhqbH1JXt/bQq2yP/91FcQuVam0oprZcRX5yoLat9NOfncpgqTjH2YWUwOP0tODSzkRxqyjgXLrQW0D9WSeqLSDOJv8O92Nu3dyaCQv60E4fKti10W2V/KYLc7ysyZKbM4QO x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 6863609a-258b-4a0f-8a96-08d61387b620 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(5600074)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4953; x-ms-traffictypediagnostic: DM6PR05MB4953: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231344)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699049)(76991033); SRVR:DM6PR05MB4953; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4953; x-forefront-prvs: 078693968A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(396003)(136003)(366004)(376002)(39860400002)(346002)(189003)(199004)(8676002)(83716003)(82746002)(5250100002)(2900100001)(2501003)(966005)(5640700003)(486006)(7736002)(305945005)(478600001)(316002)(99286004)(36756003)(58126008)(106356001)(105586002)(2616005)(6436002)(6486002)(26005)(256004)(2351001)(476003)(102836004)(6506007)(6512007)(14454004)(86362001)(6306002)(6916009)(5660300001)(15650500001)(53936002)(2906002)(68736007)(6116002)(3846002)(97736004)(66066001)(25786009)(8936002)(186003)(81166006)(33656002)(81156014)(1730700003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4953; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: FwBhHegwIWZ/xVfk5udo1G6sLW7C9TNFeSbOZXeUgr3JkIlWCqCwFfz+gg2xXXRd1RLN+0HMWBqiIX9COlHriZM/vERp35Hta7DvsUDsmnn4v1oY3YzUH/Y+/DDiqFck6W6h9jZsRfNorp8oaXgWOnramrcFWld1hR3cfB6YGderOps58yhiWipRzkZdOWQXe/tyjbKR8Rlt3l7e7EkFRD/v2gsIzsnbdRuW7NMSji0NOxtUB6eHeiCd1Hj3P90NFg0tqLbSDzyjSZwvT2uyfuyx0XL2HQfeCiH1sj7vUrmeSQUWb/MUmVL6Al+eUE2X7ys31BfKjWgGvtFRCxVa1jqC/4EXfdng9neRiH0vcsI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 6863609a-258b-4a0f-8a96-08d61387b620 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2018 23:31:31.5801 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4953 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-05_13:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809050222 Archived-At: Subject: [Netconf] Last Call on subscribed-notifications-16 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 23:31:39 -0000 VGhpcyBtZXNzYWdlIHN0YXJ0cyBhIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vi c2NyaWJlZC1ub3RpZmljYXRpb25zLTE2Og0KDQogIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLTE2DQoNClRoaXMg bWFya3MgdGhlIHNlY29uZCBvZiB0aGUgbGFzdCBjYWxscyBvbiB0aGUgeWFuZyBwdXNoIHN1aXRl IG9mIGRyYWZ0cy4NCkFzIGV4cGxhaW5lZCBiZWZvcmUsIGdpdmVuIHRoZSBzaXplIGFuZCBudW1i ZXIgb2YgZG9jdW1lbnRzLCB0aGUgY2hhaXJzDQpkZWNpZGVkIHRvIGJyZWFrIHRoZSByZXZpZXdz IHVwIGludG8gcGllY2VzIHNvIGFzIHRvIGdldCBmb2N1cyBvbiBlYWNoDQppbiB0dXJuLiAgV2Ug YXJlIGNob29zaW5nIHRvIGdvIHRvcC1kb3duLCBzdGFydGluZyB3aXRoIHlhbmctcHVzaCBhbmQN CmVuZGluZyB3aXRoIHRoZSAibm90aWYiIGRyYWZ0cy4gIFdlIHBsYW4gdG8gc3VibWl0IHRoZSBk cmFmdHMgZm9yIA0KcHVibGljYXRpb24gd2hlbiB0aGV5IGFyZSByZWFkeSBhcyBhIGNvbGxlY3Rp dmUuICBUaGUgZ29hbCBpcyB0byBkbyANCmFsbCB0aGlzIHByaW9yIHRvIElFVEYgMTAzLg0KDQpX aGlsZSBpdCdzIGFsd2F5cyBuaWNlIHRvIHJlY2VpdmUgbWVzc2FnZXMgb2Ygc3VwcG9ydCwgYXQg dGhpcyB0aW1lLCB0aGUNCnF1ZXN0aW9uIGlzbid0IHNvIG11Y2ggaWYgdGhlIHdvcmtpbmcgZ3Jv dXAgc3VwcG9ydHMgdGhlIHdvcmsgdGhhbiBpZg0KdGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIHBy b2dyZXNzLiAgVGhlIGNoYWlycyBuZWVkIHRvIHNlZSByZXZpZXdzIHRoYXQNCmluZGljYXRlIHRo b3JvdWdoIGVuZC10by1lbmQgcmVhZGluZyBvZiB0aGUgdGV4dC4gIE9mIGNvdXJzZSwgaWYgdGhl cmUNCmFyZSBhbnkgb2JqZWN0aW9ucywgdGhlc2Ugc2hvdWxkIGJlIGJyb3VnaHQgZm9yd2FyZCBu b3cgYXMgd2VsbC4NCg0KVGhlIGN1cnJlbnQgdmVyc2lvbiAoLTE2KSBvZiB0aGlzIGRyYWZ0IHdh cyBwdWJsaXNoZWQgb24gQXVnIDE1dGgsIGFib3V0DQp0aHJlZSB3ZWVrcyBhZnRlciBJRVRGIDEw Mi4gIFRoZSBkYXRhdHJhY2tlciBwYWdlIGZvciB0aGUgZHJhZnQgaXMgaGVyZToNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5v dGlmaWNhdGlvbnMuDQoNCg0KVGhhbmtzLA0KS2VudCAoYW5kIE1haGVzaCkNCg0K From nobody Wed Sep 5 18:12:55 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A6D130E12 for ; Wed, 5 Sep 2018 18:12:53 -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 r9uQ8TfDMrrk for ; Wed, 5 Sep 2018 18:12:52 -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 5DF771274D0 for ; Wed, 5 Sep 2018 18:12:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C52D7B80E22; Wed, 5 Sep 2018 18:12:51 -0700 (PDT) To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, ibagdona@gmail.com, warren@kumari.net, kwatsen@juniper.net, mjethanandani@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: bill.wu@huawei.com, netconf@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180906011251.C52D7B80E22@rfc-editor.org> Date: Wed, 5 Sep 2018 18:12:51 -0700 (PDT) Archived-At: Subject: [Netconf] [Editorial Errata Reported] RFC8040 (5493) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 01:12:54 -0000 The following errata report has been submitted for RFC8040, "RESTCONF Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5493 -------------------------------------- Type: Editorial Reported by: Qin Wu Section: 6 Original Text ------------- Note that the YANG definitions within this module do not represent configuration data of any kind. The 'restconf-media-type' YANG extension statement provides a normative syntax for XML and JSON message-encoding purposes. Corrected Text -------------- Note that the YANG definitions within this module do not represent configuration data of any kind. The yang-data extension statement provides a normative syntax for XML and JSON message-encoding purposes. Notes ----- The 'restconf-media-type' YANG extension has been replaced by more generic yang-data extension. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- 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 Thu Sep 6 03:56:49 2018 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B728130E18 for ; Thu, 6 Sep 2018 03:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, T_DKIMWL_WL_MED=-0.01, 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 kcPPCdaw97t7 for ; Thu, 6 Sep 2018 03:56:42 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E576130DEF for ; Thu, 6 Sep 2018 03:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=73031; q=dns/txt; s=iport; t=1536231402; x=1537441002; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=kEB0TFTMFoGb3JgByX6hzFoH4UJYD8jqpmAtjuUKKiM=; b=hBifyu4DyfcttgLpua4Gl21nezBc4nrLCD7nYUyHxQo2sPBGc4hFr12c OcPa9gGnuE7qLrMGbTXQrpUyV01p2y7qBGz28DDD+qUufDW9ahvzCLuZo MRbAfytvsSzOenYaEpkckrM7/FL1bmy8GuKPeqXJnSnUbki2yrYspTdCL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DuAQAnB5Fb/xbLJq1TBxoBAQEBAQI?= =?us-ascii?q?BAQEBCAEBAQGCV0gFgQ9tEiiDcohxjV94lUuBYwMLGAEKhANGAoN4OBQBAgE?= =?us-ascii?q?BAgEBAm0cDIU4AQEBAwEBARgBCEsXBAkCEQQBAQENEwEGAwICJx8JCAYBDAY?= =?us-ascii?q?CAQEVAoMGAYF5CA+GOZtLgS4fhA8BPYUVBYp1gUE/gRIngjYHLoMbAQGBOw4?= =?us-ascii?q?CA4MUglcCh36FPgGFS4hpCYY2gnyDA4NEBheBQCCEHYJXhhOIQ4JvgliFcoF?= =?us-ascii?q?YIYFVMxoIGxU7gmyDNgECgkiFFIU/PjCLHAEBBR8CAQSCHgEB?= X-IronPort-AV: E=Sophos;i="5.53,337,1531785600"; d="scan'208,217";a="6317719" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2018 10:56:38 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w86AucOZ006309; Thu, 6 Sep 2018 10:56:38 GMT To: Alexander Clemm , "netconf@ietf.org" References: <386e425f-d250-a0a9-0927-1a484aed9042@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CA9A@sjceml521-mbs.china.huawei.com> From: Robert Wilton Message-ID: <8b2bd7da-7fd3-907d-1df0-947ce2052904@cisco.com> Date: Thu, 6 Sep 2018 11:56:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CA9A@sjceml521-mbs.china.huawei.com> Content-Type: multipart/alternative; boundary="------------1F05DECC4667D45AC3B1C3D2" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Netconf] RGW YANG push -18 LC comments [part 1] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 10:56:48 -0000 This is a multi-part message in MIME format. --------------1F05DECC4667D45AC3B1C3D2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Alex, Please see inline ... On 05/09/2018 23:28, Alexander Clemm wrote: > Hello Rob, > > thank you for your comments! Please find my replies inline, , with corresponding changes to be incorporated into the next revision (-19). > > --- Alex > > >> -----Original Message----- >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert Wilton >> Sent: Tuesday, September 04, 2018 7:37 AM >> To: netconf@ietf.org >> Subject: [Netconf] RGW YANG push -18 LC comments [part 1] >> >> Hi, >> >> I've reviewed the -18 YANG push draft up to section 4 so far . I've included my >> comments below.  I think that they are all minor/cosmetic except for the issue >> regarding the dampened subscriptions which has been discussed below and >> probably does not need to be rehashed again. >> >> In the Abstract: >> (1) Is "continuous" the right choice of word here.  E.g. I thought that sometimes >> the stream of updates is not continuous.  Possibly remove "continuous"? >> > Would prefer to keep, unless you feel very strongly about this? What we want to bring across is that this is different from a one-time, on-demand type of update. "Stream" might imply this already, but this way we would emphasize this a bit further. > Keeping is fine if that is what you prefer. > >> In the Introduction: >> (2) "remote visibility" in the first sentence is a bit obscure. Perhaps replace the >> first sentence with "Traditional approaches to monitoring management data on >> remote devices have been built upon polling". > How about changing this to: "Traditional approaches to providing visibility into managed entities from remote have been built on polling. " > [I understand your point, but reason for alternative phrasing is that I don't think we want to restrict this to monitoring (because (a) you can use this also to mirror state for other purposes, e.g. to assess specifics of what needs to be done to provision a service successfully, for troubleshooting, maintenance, validation, etc, and (b) monitoring does include other aspects such as alarm management). LIkewise, suggest to refer to "managed entities" (not "devices") to not preclude application to things that are not devices (e.g. virtual "things"). ] > Your phrasing is fine. >> (3) The work isn't actually fruitless if polling is the only available option, hence >> perhaps change: >> >> OLD: >> "For applications that monitor for changes, many remote polling >>  cycles place ultimately fruitless load on the network, devices, >>  and applications." >> >> NEW: >>   "For applications that monitor for changes, many remote polling >>   cycles place unwanted load on the network, devices, >>   and applications, particularly if the monitored values are only changing >> infrequently." >> > How about: " For applications that monitor for changes, many remote polling cycles place unwanted and ultimately fruitless load on the network, devices, and applications, particularly when changes occur only infrequently. " > My point is that if the only choice is polling then it is not fruitless load, because it serves a useful purpose, that purpose being detecting changes in the monitored data.  Hence the load is "unwanted" not "fruitless". But this is a minor consideration, so I'm OK with whatever you decide here. :-) > >> (4) In paragraph starting " A more effective alternative", possibly suggest >> changing "publisher" to "server" since the introduction is before the >> definitions/acronyms where "publisher" is formally referenced. >> > Rewording to "... that enables the server (also referred to as publisher) to push ... " OK. >> In definitions: >> >> (5) Suggest tying this definition more closely to the terminology already defined >> in RFC 8342, hence: >> >> OLD: >>    o  Datastore node: An instance of management information in a >>       datastore.  Also known as "object". >> >> NEW: >>    o  Datastore node: A node in the instantiated YANG data tree associated with >> a datastore.  In this document, datastore nodes are often referred to as "YANG >> objects" or "objects" > OK. (and removed instance of "YANG object" from the document, as there were only two.) OK. > >> (6) "Datastore node update" definition: Does this update only contain the value, >> or does it also contain the path to the datastore node as well?  If this also >> contains the path then it would be good if that was explicit in the definition. >> > Updated as follows: " A data item containing the current value of a datastore node at the time the datastore node update was created, as well as the path to the datastore node." Looks good. > >> (7) Perhaps the following definition is more precise?  Or by "updates" >> do you actually mean "update records"?  There are other references to >> "updates" in the definitions, do these all refer to "update records"? If so then I >> would suggest moving the definition of "update record" above "datastore >> subscription". >> >> OLD: >> >> "Datastore subscription: A subscription to updates regarding >>       contents of a datastore." >> >> NEW: >> >> "Datastore subscription: A subscription to a stream of datastore node updates." > ok, changed > >> (8) Suggest removing "instantiated" from the following definition, and using >> descendant (which is used in 7950) instead of contained .. I also suggest moving >> the definition up, directly below "datastore node": >> >> OLD: >> >>    o Datastore subtree: An instantiated datastore node and the >>       datastore nodes that are hierarchically contained within it. >> >> NEW: >> >>    o Datastore subtree: A  datastore node and all its descendant datastore >> nodes." >> > changed > >> (9) Sec 3. Solution overview, last sentence.   It is not "YANG objects" >> that are being pushed, but surely "datastore node updates" or perhaps >> "update records" that are pushed, or even "Changes to YANG objects" >> > Changed to "datastore node updates" >> Sec 3.1 Subscription model: >> >> (10) Perhaps change"subtrees within a datastore" to "datastore subtrees". >> > changed > >> (11) It is not obvious to me from this text what "Anchor time" is, >> although I suspect that it is described in more detail later in the >> document.  Given that the section on-change subscriptions has more >> detail for various parameters, I wonder whether it would be helpful to >> describe anchor time in more detail in this section? >> > Roughly what it is is explained in the same sentence, but how about changing it as follows: > " These parameters are the period interval with which to report updates, and an "anchor time", i.e. a reference point in time that can be used to calculate at which points in time periodic updates need to be assembled and sent." > I think I get this, but didn't find it completely clear until I had looked at the model.  I think that you updated text is OK. Although I have a slight concern (e.g. in section 4.2), * an "anchor-time"; update intervals always fall on the points in time that are a multiple of a "period" from an "anchor-time". I can see implementations will try and keep to this interval, but I suspect that the vast majority of implementations will not be able to guarantee that it is exact multiples of the given period, given that "anchor-time" seems to take an arbitrary sub-section precision, and timeticks are in hundreds of a second.  Possibly, weakening the text (e.g. as per below, but the YANG model would probably need to be updated) might be a good idea? * an "anchor-time"; update intervals always fall as close as possible to the points in time that are a multiple of a "period" from an "anchor-time". > >> (12) Dampening period: The text states that "The dampening period >> collectively applies to the set of all datastore nodes selected by a >> single subscription and sent to a single receiver."  This would imply >> that if a single subscription had multiple receivers that they would be >> dampened independently, but it wasn't obvious to me that this makes >> sense.  I would assume that for a given subscription that all receivers >> would receive the same update records. > Yes. Removed "and sent to a single receiver". Also clarified further (in a slight rewording) " This means that when there is a change to one or more subscribed objects, an update record containing those objects is created immediately (when no dampening period is in effect) or at the end of a dampening period (when a dampening period is in fact in effect). " > OK. >> (13) Rather than "No Sync on start", it might be better to refer to this >> as  "sync on start", which could be defined as a boolean with default >> true [I've not checked the YANG model] > it's not defined as a boolean but as a leaf of type empty. (So, the "default" is in fact true, unless no-sync-on-start is present). I don't see a compelling reason to change this and suggest to keep this as-is. > OK.  I think that in YANG, particularly considering NMDA, it is cleaner to model this as a boolean with default true, particularly if you do a get-data request on the operational state, since it more clearly and explicitly indicates whether sync-on-start is enabled. With the current model, on a get-data request against operation, the server returns "no-synch-on-start", it is obvious that it won't perform a sync-on-start, however, the reverse if the leaf isn't present isn't quite so clear.  If it doesn't return "no-synch-on-start" then that either means the device will perform sync-on-start, or perhaps the node the server isn't returning any information, or perhaps it has been deviated.  So, in summary, I think that flags that turn something off, are better modeled with default true, rather than as empty leafs.  Flags that turn something on can be modeled equally well either way. BTW, I also notice that is uses "synch" in various leaf name, but I would recommend the abbreviation "sync" instead.  It is shorter, and I think more commonly used. https://english.stackexchange.com/questions/681/synced-or-synched >> >> Sec 3.2. Negotiation of Subscription Policies >> >> (14) "Random guessing at" => "Random guessing of".  Although, I think >> that probably this first sentence, and the "Therfore, " could just be >> deleted.  I.e. starting the paragraph "In order to minimize ..." >> > Changed "at" to "of", however, prefer to keep the first sentence as it does provide some explanation. OK. > >> (15) Suggest minor rewording of 3.3. third paragraph: >> >> OLD: >> >> In that case, updates are sent only for those objects >>    within the scope that do support on-change updates whereas other >>    objects are excluded from update records, whether or not their values >>    actually change. >> >> NEW: >> >> In that case, updates are sent only for those objects >>    within the scope that do support on-change updates, whereas other >>    objects are excluded from update records, even if their values change. >> > changed > >> (16) Question on 3.3. fifth paragraph (below), it's unclear to me what >> is meant by "which are current at the time": >> >> "Values sent at the end of the >>    dampening period are the current values of all changed objects which >>    are current at the time the dampening period expires." > Rephrase the paragraph as follows, just to make it clear (it's a bit more verbose than it has to, but we want to make sure there is no question as to what value to send - the value of the original change or the value at the time of updating). > "... . Values sent at the end of the dampening period are the values that are current at the end of the dampening period of all changed objects. Changed objects include those which were deleted or newly created during that dampening period. If an object has returned to its original value (or even has been created and then deleted) during the dampening-period, that value (and not the interim change) will still be sent. ..." > Yes, I think that the longer and more explicit text is better. >> (17) I still doubt that all implementations will strictly follow all of >> 3.3. paragraph 5, particularly the created and deleted within a >> dampening period because I perceive that it is particularly difficult to >> implement cleanly/efficiently.  However, this issue has been discussed >> previously, and I have no particular desire to slow the RFC progress >> down with further discussion on this. >> > No change made > >> (18) Section 3.3, conceptual process, step 1 states that access control >> rules are checked to ensure the receiver is authorized to view all >> subscribed datastore nodes, but I think that this should state that the >> access control rules are used to filter the subscribed datastore nodes >> to those that the client has access rights to. > I added " (and filter out any nodes for which this is not the case)" to make this clearer; this now reads " Just before a change, or at the start of a dampening period, evaluate any filtering and any access control rules to ensure receiver is authorized to view all subscribed datastore nodes (and filter out any nodes for which this is not the case). " > OK, but I would change "and filter" to "filtering". > >> (19) A related question:  When happens if there is an access control >> change, i.e. the receiver had access previously, but then it was >> revoked.  Does it see a delete?  Or does it not get any notification? >> Similarly, if they didn't previously have access, but then access was >> granted before the end of the dampening period?  OK, I see that this is >> described in more detail in section 3.9, paragraph 3.  Perhaps a forward >> reference would be useful here. > I think this is defined in detail in 3.9, as you note. I think the spirit of the description here is clear, and I don't want to overly burden the text with cross-references within the same text. So, I suggest keeping this as-is. > OK. >> (20) Section 3.3, last paragraph, "can be created" => "must be created". > Actually, I think it is "can". It is up to the discretion of what the subscriber wants to do. As an alternative to using the word "can" (not sure if this is really needed), rephrasing it to " In cases where a subscriber wants to have separate dampening periods for different objects, the subscriber has the option to create multiple subscriptions with different selection filters. " must is correct, since that is the only available solution to the client if they want different dampening periods.  I.e. the clients choice is: don't have separate dampening periods or create separate subscriptions.  But this is a minor point, not worth lengthy discussion, so you can decide what to do. >> (21) Section 3.4, second paragraph doesn't quite scan.  "This includes >>    indicating the fact that an update is incomplete as part of a push- >>    update respectively push-change-update notification ..." >> > I think it does scan, but to make it just slightly more clear, how about updating to " This includes indicating the fact that an update is incomplete as part of a push-update (respectively push-change-update) notification, as well as emitting a subscription-suspended notification as applicable. " > It is the "push-update respectively push-change-update" that doesn't make any sense to me.  Do you just mean "or", e.g. "push-update or push-change-update"? > >> (22) Section 3.4, 3rd paragraph, "able fulfill" => "able to fulfill" >> > changed > >> (23) Section 3.5.2, 1st paragraph, "not restricted to configuration >> objects only" => "not only restricted to configuration objects". >> > changing to " not restricted to only configuration objects" (the "only" refers to the configuration objects, not to the fact that it is restricted) Yes., OK. > >> (24) Section 3.5.2, 2nd paragraph, possible alternative text: >> >> OLD: >> >>    A publisher will indicate a change to the effect that a value of a >>    datastore node has been updated by indicating a "replace" operation >>    (applied to the datastore node) in the patch.  When a new datastore >>    node was created (other than an entry in a user ordered list), a >>    publisher will indicate a "create" operation in the patch.  When a >>    datastore node was deleted, the publisher indicates this by a >>    "delete".  When a new entry in a user-ordered list was created, the >>    publisher indicates this by an "insert" operation. When an entry in >>    a user-ordered list was moved, the publisher indicates this by a >>    "move" operation. >> >> NEW: >> >>   A publisher indicates the type of change to a datastore node using >> the different YANG patch operations:  the "create" operation is used for >> newly created objects (except entries in a user-ordered list), the >> "delete" operation is used for deleted objects (including in >> user-ordered lists), the "replace" operation is used when only the >> object value changes, the "insert" operation is used when a new entry is >> inserted in a list, and the "move" operation is used when an existing >> entry in a user-ordered list is moved. >> > OK (I don't feel strongly about this) > >> (25) Section 3.5.2, last paragraph: If you want to allow duplicate >> "create" and "delete" events, then it might be cleaner to encode them as >> "merge" and "remove"?  I.e. it seems that you have created a slightly >> different encoding from vanilla YANG patch because of the way that >> errors are handled differently.  Ideally, it would be better if a client >> could just apply this as regular YANG patch, but this only works with >> the encoding described here if the clients copy of the datastore is in >> sync with the servers old copy of the datastore at the point that the >> patch is generated from.  This seems slightly fragile to unexpected >> inconsistencies between client and server (which I appreciate that you >> try and avoid). >> > Hmm. While it may be possible to replace "delete" with "remove", I am not so sure about the "merge" part. At the end of the day, the use here is different from having a client apply a patch operation to the server, and the semantics may be a little clearer by keeping things as they are, so would prefer to keep things as defined now. > I think that is probably right. I think that it is a slight shame that vanilla YANG patch won't work here, but as you say I think that it will need to be applied in a slightly different way regardless. > >> (26) Section 3.6, second paragraph, would it not be easier to allow the >> client to replace an existing filter rather than having to explicitly >> remove the old filter and add the new one?  Or if you mean that any new >> filter replaces the existing filter, then this may be more clearly >> indicated with the text: "An RPC request proposing a new selection >> filter replaces any existing filter. " >> > OK, changing per your suggestion to make it clear that the existing filter is replaced. > >> (27) Section 3.6, paragraph 6, starting "XPath".  The "boolean" example >> is unclear to me given that a xpath filter always returns a node set so >> can't return a boolean result.  I also suggest changing "passes a >> datastore node" to  "includes a datastore node". > removed the sentence and shortened the paragraph. It now reads as follows: > " XPath itself provides powerful filtering constructs and care must be used in filter definition. Consider an XPath filter which only passes a datastore node when an interface is up. It is up to the receiver to understand implications of the presence or absence of objects in each update." > OK. >> (28) Section 3.6, paragraph 7.  I think that the text must be more >> explicit on when the filter is evaluated for a periodic subscription. >> Am I right in thinking that it is only evaluated once when the >> subscription is created, or the subscription is changed? Specifically, >> if the nodeset evaluated during the lifetime of an Xpath subscription >> changes then does that affect which nodes are returned? >> > Not sure what changes you are looking for. The filter is in effect throughout the subscription until it is changed. It is up to an implementation to decide whether to apply it once when the subscription is established to determine the datastore nodes (tracking any subtree changes to make sure nodes in the subtrees are included as needed), or whether to apply it at each update anew. > As far as receiver authorization is concerned (i.e. access control filters), this is explained in section 3.9. Applying no text changes at this point unless you can be more clear on what you would like to see? > OK.  Not considering NACM, I think that is already covered, was thinking of an Xpath filter.  I am right in thinking that logically the Xpath filter is [re-]applied whenever the periodic push notification is constructed. If so, possibly change: " When the set of selection filtering criteria is applied for a    periodic subscription, all selected datastore nodes to which a    receiver has access are provided to that receiver." To something along the lines of ... " When the set of selection filtering criteria is applied for a   periodic subscription, then they are applied whenever a periodic   update record is constructed, and only datastore nodes that pass   the filter and to which areceiver has access are provided to   that receiver." > >> (29) Section 3.7, paragraph 3:  Perhaps make this text conditional to >> dampened subscriptions.  Presumably for non dampened subscriptions all >> changes are reported as separate push-change-update notifications? >> >> OLD: >> In cases where multiple changes have occurred and the object >>    has not been deleted, the object's most current value is reported. >> >> NEW: >> In cases where multiple changes have occurred in a subscription that has >> dampening enabled, and the object >>    has not been deleted, the object's most current value is reported. >> > Well, the text states clearly that this concerns any changes since the last notification message. So, the fact that dampening is enabled is already implied. > How about rephrasing slightly as follows: > " In cases where multiple changes have occurred over the course of a dampening period and the object has not been deleted, the object's most current value is reported." > This text is fine. But this raises another question: If no dampening is enabled, then is it expected that all changes to an object are always notified.  [If this is a requirement, then I think that it should probably be stated clearly in the YANG model and perhaps in section 3 as well.] Specifically, say you are monitoring interface state, without dampening, and it starts to flap 100 times per second.  Is the publisher required to notify of every single change.  Or is the publisher only required to notify that the at least one change has occurred, and guarantee that it always notifies the latest value. > >> (30) Section 3.7, paragraph 5, "Ethernet port" => "Ethernet interface" >> > changed > >> (31) Section 3.7, last paragraph: Why start at "1" rather than "0". On >> overflow, why overflow to "1" rather than "0", is that deliberate?  If >> you are going to force it to "1" then I would also restrict the upper >> bound to int32 max rather than uint32 max to make life easier in Java >> land ... > OK, got it. Updated the text to reflect start at 0. > > >> (32) Section 3.8, tree diagrams.  I would think that another key metric >> regarding whether a subscription can be satisfied would be object-rate >> and data-rate.  E.g. a publisher implementation may be able to push 100k >> objects/second, so a client has a choice of either monitoring less >> objects, or decreasing the period.  Hence I was wondering whether rates >> should be provided in addition to the object-count-estimate/limit and >> kilobyte-estimate/limit.  Of course, a rate is also implicitly defined >> by including the period hint, so perhaps that is sufficient without >> needing to send more fields back to the client. >> > Would prefer to keep this to the basics, i.e. as-is. As mentioned, you can compute a rate from this. Yes, that is fine.  Additional fields could be augmented in future if needed. > >> (33) Section 3.9, 2nd paragraph, "particular each" => "particular" > changed > >> (34) Section 3.9, 3rd paragraph:  It was not entirely obvious to me what >> the 3rd paragraph text (reproduced below) actually means.  I think that >> this boils down to:  If, after access control has been applied, there >> are no objects remaining in an update record then only a single empty >> "push-update" notification MAY be sent and empty "push-change-update" >> messages MUST NOT be sent.  This is required to ensure that clients >> cannot surreptitiously monitor objects that they do not have access to >> via carefully crafted selection filters. >> >> "A publisher MUST allow for the possibility that a subscription's >>    selection filter references non-existent or access-protected data. >>    Such support permits a receiver the ability to monitor the entire >>    lifecyle of some datastore tree.  In this case, all "push-update" >>    notifications must be sent empty, and no "push-change-update" >>    notifications will be sent until some data becomes visible for a >>    receiver." >> > Modified the paragraph already due to another comment in another thread. Updated this further per your comments. Now it reads as follows: > " A publisher MUST allow for the possibility that a subscription's selection filter references non-existent data or data that a receiver is not allowed to access. Such support permits a receiver the ability to monitor the entire lifecyle of some datastore tree without needing to explicitly enumerate every individual datastore node. If, after access control has been applied, there are no objects remaining in an update record, then (in case of a periodic subscription) only a single empty "push-update" notification MAY be sent. Empty "push-change-update" messages (in case of an on-change subscription) MUST NOT be sent. This is required to ensure that clients cannot surreptitiously monitor objects that they do not have access to via carefully crafted selection filters." > > Also adding the following sentence, to clarify the effect on dampening: " By the same token, changes to objects that are filtered MUST NOT affect any dampening intervals." > Text looks good.  My only question is on the sentence with the MAY. I've been told by some old hands that everywhere you see "MAY" in an RFC then it is entirely valid to also interpret that as "MAY NOT". I think that it should perhaps be: "... then (in case of a periodic subscription) the publisher MUST only send single empty "push-update" notification. or, alternatively (if you don't want MUST): "... then (in case of a periodic subscription) the publisher is allowed to send only a single empty "push-update" notification. > >> (35) Section 3.10.  This text seems to be very closely related to the >> text in section 3.3, so perhaps section 3.10 would be better moved to >> become section 3.3.1? >> > > Don't want to apply major editorial restructuing at this point. > That is fine. > >> (36) Section 3.10, last paragraph.  "will be expected to" => "SHOULD"? > Not sure we want it to sound so normative, but sure - changing it to SHOULD. > >> (37) Section 3.11.1 "incomplete-update" flag.  In the YANG definition >> this flag is set in the header of the message (i.e. before the data), >> but for applications that are generating the notifications in a streamed >> way, it would probably be better to put the flag after data.  This >> potentially minimizes the requirement that a publisher has to buffer all >> data to be able to set the incomplete-update flag if necessary. > OK, so you are suggesting to move the "incomplete-update" leaf behind the datastore contents (respectively datastore-changes). Sure, will change that. > Yes, thanks. > > >> (38) Section 3.11.1 3rd paragraph and bullet points.  With the text as >> currently written, it is acceptable for a publisher to do nothing even >> if an error is hit.  They can satisfy the first "MUST" by selecting the >> 2nd choice, and they can satisfy the "MAY" of the second choice by doing >> nothing at all.  Instead I think that the text should state that the >> publisher MUST set the "incomplete-update" flag, or suspend the >> subscription, or both. >> > > OK, I think the problem is with "MUST take on or more of the following actions" (although I think what is meant is clear). Rephrasing this as follows: " In this case, the publisher MUST act as follows." > > Also adding the following to the second bullet item: > " If the publisher does not create an update record at all, it MUST suspend the subscription. " > (This is really the only logical choice; we don't want a publisher to have the option of staying entirely silent.) Yes, the change looks good. Thanks, Rob > > --- Alex > > >> Thanks, >> Rob >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf --------------1F05DECC4667D45AC3B1C3D2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Alex,

Please see inline ...


On 05/09/2018 23:28, Alexander Clemm wrote:
Hello Rob,

thank you for your comments!  Please find my replies inline, <ALEX>, with corresponding changes to be incorporated into the next revision (-19).

--- Alex



-----Original Message-----
From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: Tuesday, September 04, 2018 7:37 AM
To: netconf@ietf.org
Subject: [Netconf] RGW YANG push -18 LC comments [part 1]

Hi,

I've reviewed the -18 YANG push draft up to section 4 so far . I've included my
comments below.  I think that they are all minor/cosmetic except for the issue
regarding the dampened subscriptions which has been discussed below and
probably does not need to be rehashed again.

In the Abstract:
(1) Is "continuous" the right choice of word here.  E.g. I thought that sometimes
the stream of updates is not continuous.  Possibly remove "continuous"?


<ALEX>Would prefer to keep, unless you feel very strongly about this?  What we want to bring across is that this is different from a one-time, on-demand type of update.  "Stream" might imply this already, but this way we would emphasize this a bit further.  
</ALEX>
Keeping is fine if that is what you prefer.



In the Introduction:
(2) "remote visibility" in the first sentence is a bit obscure. Perhaps replace the
first sentence with "Traditional approaches to monitoring management data on
remote devices have been built upon polling".

<ALEX> How about changing this to: "Traditional approaches to providing visibility into managed entities from remote have been built on polling. "
[I understand your point, but reason for alternative phrasing is that I don't think we want to restrict this to monitoring (because (a) you can use this also to mirror state for other purposes, e.g. to assess specifics of what needs to be done to provision a service successfully, for troubleshooting, maintenance, validation, etc, and (b) monitoring does include other aspects such as alarm management).  LIkewise, suggest to refer to "managed entities" (not "devices") to not preclude application to things that are not devices (e.g. virtual "things"). ] 
</ALEX>
Your phrasing is fine.


      

        
(3) The work isn't actually fruitless if polling is the only available option, hence
perhaps change:

OLD:
"For applications that monitor for changes, many remote polling
  cycles place ultimately fruitless load on the network, devices,
  and applications."

NEW:
   "For applications that monitor for changes, many remote polling
   cycles place unwanted load on the network, devices,
   and applications, particularly if the monitored values are only changing
infrequently."



      

      
<ALEX. The "ultimately fruitless" also refers to the fact that many polls will not yield new information (other than "no new information"), as you might e.g. retrieve a lot of stuff to see if it changed only to find that it didn't.  
How about: " For applications that monitor for changes, many remote polling cycles place unwanted and ultimately fruitless load on the network, devices, and applications, particularly when changes occur only infrequently. "
</ALEX>

    

    My point is that if the only choice is polling then it is not
    fruitless load, because it serves a useful purpose, that purpose
    being detecting changes in the monitored data.  Hence the load is
    "unwanted" not "fruitless".

    

    But this is a minor consideration, so I'm OK with whatever you
    decide here. :-)

    

    

      



      

        
(4) In paragraph starting " A more effective alternative", possibly suggest
changing "publisher" to "server" since the introduction is before the
definitions/acronyms where "publisher" is formally referenced.



      

      
<ALEX> Rewording to "... that enables the server (also referred to as publisher) to push  ... " </ALEX>

    

    OK.

    

    

      

      

        
In definitions:

(5) Suggest tying this definition more closely to the terminology already defined
in RFC 8342, hence:

OLD:
    o  Datastore node: An instance of management information in a
       datastore.  Also known as "object".

NEW:
    o  Datastore node: A node in the instantiated YANG data tree associated with
a datastore.  In this document, datastore nodes are often referred to as "YANG
objects" or "objects"


      

      
<ALEX> OK.  (and removed instance of "YANG object" from the document, as there were only two.) </ALEX>

    

    OK.

    

    

      



      

        
(6) "Datastore node update" definition: Does this update only contain the value,
or does it also contain the path to the datastore node as well?  If this also
contains the path then it would be good if that was explicit in the definition.



      

      
<ALEX> Updated as follows: " A data item containing the current value of a datastore node at the time the datastore node update was created, as well as the path to the datastore node."  </ALEX>

    

    Looks good.

    

    

      



      

        
(7) Perhaps the following definition is more precise?  Or by "updates"
do you actually mean "update records"?  There are other references to
"updates" in the definitions, do these all refer to "update records"? If so then I
would suggest moving the definition of "update record" above "datastore
subscription".

OLD:

"Datastore subscription: A subscription to updates regarding
       contents of a datastore."

NEW:

"Datastore subscription: A subscription to a stream of datastore node updates."


      

      
<ALEX> ok, changed </ALEX>



      

        
(8) Suggest removing "instantiated" from the following definition, and using
descendant (which is used in 7950) instead of contained .. I also suggest moving
the definition up, directly below "datastore node":

OLD:

    o Datastore subtree: An instantiated datastore node and the
       datastore nodes that are hierarchically contained within it.

NEW:

    o Datastore subtree: A  datastore node and all its descendant datastore
nodes."



      

      
<ALEX> changed </ALEX>



      

        
(9) Sec 3. Solution overview, last sentence.   It is not "YANG objects"
that are being pushed, but surely "datastore node updates" or perhaps
"update records" that are pushed, or even "Changes to YANG objects"



      

      
<ALEX> Changed to "datastore node updates" </ALEX>


      

        
Sec 3.1 Subscription model:

(10) Perhaps change"subtrees within a datastore" to "datastore subtrees".



      

      
<ALEX> changed </ALEX>



      

        
(11) It is not obvious to me from this text what "Anchor time" is,
although I suspect that it is described in more detail later in the
document.  Given that the section on-change subscriptions has more
detail for various parameters, I wonder whether it would be helpful to
describe anchor time in more detail in this section?



      

      
<ALEX> Roughly what it is is explained in the same sentence, but how about changing it as follows:
" These parameters are the period interval with which to report updates, and an "anchor time", i.e. a reference point in time that can be used to calculate at which points in time periodic updates need to be assembled and sent. "
</ALEX>

    

    I think I get this, but didn't find it completely clear until I had
    looked at the model.  I think that you updated text is OK.

    

    Although I have a slight concern (e.g. in section 4.2),

    

    
      *  an "anchor-time"; update intervals always fall on the points in
         time that are a multiple of a "period" from an "anchor-time".

    

    I can see implementations will try and keep to this interval, but I
    suspect that the vast majority of implementations will not be able
    to guarantee that it is exact multiples of the given period, given
    that "anchor-time" seems to take an arbitrary sub-section precision,
    and timeticks are in hundreds of a second.  Possibly, weakening the
    text (e.g. as per below, but the YANG model would probably need to
    be updated) might be a good idea?

    

    
      *  an "anchor-time"; update intervals always fall as close as possible to the points in
         time that are a multiple of a "period" from an "anchor-time".

    

    

    

    

      



      

        
(12) Dampening period: The text states that "The dampening period
collectively applies to the set of all datastore nodes selected by a
single subscription and sent to a single receiver."  This would imply
that if a single subscription had multiple receivers that they would be
dampened independently, but it wasn't obvious to me that this makes
sense.  I would assume that for a given subscription that all receivers
would receive the same update records.


      

      
<ALEX> Yes.  Removed "and sent to a single receiver".  Also clarified further (in a slight rewording) " This means that when there is a change to one or more subscribed objects, an update record containing those objects is created immediately (when no dampening period is in effect) or at the end of a dampening period (when a dampening period is in fact in effect).  "
</ALEX>


    

    OK.

    

    

      

      

        
(13) Rather than "No Sync on start", it might be better to refer to this
as  "sync on start", which could be defined as a boolean with default
true [I've not checked the YANG model]


      

      
<ALEX> it's not defined as a boolean but as a leaf of type empty.  (So, the "default" is in fact true, unless  no-sync-on-start is present).  I don't see a compelling reason to change this and suggest to keep this as-is.  
</ALEX>

    

    OK.  I think that in YANG, particularly considering NMDA, it is
    cleaner to model this as a boolean with default true, particularly
    if you do a get-data request on the operational state, since it more
    clearly and explicitly indicates whether sync-on-start is enabled.

    

    With the current model, on a get-data request against operation, the
    server returns "no-synch-on-start", it is obvious that it won't
    perform a sync-on-start, however, the reverse if the leaf isn't
    present isn't quite so clear.  If it doesn't return
    "no-synch-on-start" then that either means the device will perform
    sync-on-start, or perhaps the node the server isn't returning any
    information, or perhaps it has been deviated.  So, in summary, I
    think that flags that turn something off, are better modeled with
    default true, rather than as empty leafs.  Flags that turn something
    on can be modeled equally well either way.

    

    BTW, I also notice that is uses "synch" in various leaf name, but I
    would recommend the abbreviation "sync" instead.  It is shorter, and
    I think more commonly used. 
    https://english.stackexchange.com/questions/681/synced-or-synched

     

    

    

      

      

        

Sec 3.2. Negotiation of Subscription Policies

(14) "Random guessing at" => "Random guessing of".  Although, I think
that probably this first sentence, and the "Therfore, " could just be
deleted.  I.e. starting the paragraph "In order to minimize ..."



      

      
<ALEX> Changed "at" to "of", however, prefer to keep the first sentence as it does provide some explanation.  </ALEX>

    

    OK.

    

    

      



      

        
(15) Suggest minor rewording of 3.3. third paragraph:

OLD:

In that case, updates are sent only for those objects
    within the scope that do support on-change updates whereas other
    objects are excluded from update records, whether or not their values
    actually change.

NEW:

In that case, updates are sent only for those objects
    within the scope that do support on-change updates, whereas other
    objects are excluded from update records, even if their values change.



      

      
<ALEX> changed </ALEX>



      

        
(16) Question on 3.3. fifth paragraph (below), it's unclear to me what
is meant by "which are current at the time":

"Values sent at the end of the
    dampening period are the current values of all changed objects which
    are current at the time the dampening period expires."


      

      
<ALEX> Rephrase the paragraph as follows, just to make it clear (it's a bit more verbose than it has to, but we want to make sure there is no question as to what value to send - the value of the original change or the value at the time of updating).  
"... .  Values sent at the end of the dampening period are the values that are current at the end of the dampening period of all changed objects.  Changed objects include those which were deleted or newly created during that dampening period.  If an object has returned to its original value (or even has been created and then deleted) during the dampening-period, that value (and not the interim change) will still be sent. ..."
</ALEX> 


    

    Yes, I think that the longer and more explicit text is better.

    

    

      

      

        
(17) I still doubt that all implementations will strictly follow all of
3.3. paragraph 5, particularly the created and deleted within a
dampening period because I perceive that it is particularly difficult to
implement cleanly/efficiently.  However, this issue has been discussed
previously, and I have no particular desire to slow the RFC progress
down with further discussion on this.



      

      
<ALEX> No change made </ALEX> 



      

        
(18) Section 3.3, conceptual process, step 1 states that access control
rules are checked to ensure the receiver is authorized to view all
subscribed datastore nodes, but I think that this should state that the
access control rules are used to filter the subscribed datastore nodes
to those that the client has access rights to.


      

      
<ALEX>  I added " (and filter out any nodes for which this is not the case)" to make this clearer; this now reads " Just before a change, or at the start of a dampening period, evaluate any filtering and any access control rules to ensure receiver is authorized to view all subscribed datastore nodes (and filter out any nodes for which this is not the case). "
</ALEX>

    

    OK, but I would change "and filter" to "filtering".

    

    

    

      



      

        
(19) A related question:  When happens if there is an access control
change, i.e. the receiver had access previously, but then it was
revoked.  Does it see a delete?  Or does it not get any notification?
Similarly, if they didn't previously have access, but then access was
granted before the end of the dampening period?  OK, I see that this is
described in more detail in section 3.9, paragraph 3.  Perhaps a forward
reference would be useful here.


      

      
<ALEX> I think this is defined in detail in 3.9, as you note.  I think the spirit of the description here is clear, and I don't want to overly burden the text with cross-references within the same text.  So, I suggest keeping this as-is.  
</ALEX>

    

    OK.

    

    

      

      

        
(20) Section 3.3, last paragraph, "can be created" => "must be created".


      

      
<ALEX> Actually, I think it is "can".  It is up to the discretion of what the subscriber wants to do.   As an alternative to using the word "can" (not sure if this is really needed), rephrasing it to " In cases where a subscriber wants to have separate dampening periods for different objects, the subscriber has the option to create multiple subscriptions with different selection filters. " </ALEX>

    

    must is correct, since that is the only available solution to the
    client if they want different dampening periods.  I.e. the clients
    choice is: don't have separate dampening periods or create separate
    subscriptions.  But this is a minor point, not worth lengthy
    discussion, so you can decide what to do.

    

    

    

      

      

        
(21) Section 3.4, second paragraph doesn't quite scan.  "This includes
    indicating the fact that an update is incomplete as part of a push-
    update respectively push-change-update notification ..."



      

      
<ALEX> I think it does scan, but to make it just slightly more clear, how about updating to " This includes indicating the fact that an update is incomplete as part of a push-update (respectively push-change-update) notification, as well as emitting a subscription-suspended notification as applicable. "
</ALEX>

    

    It is the "push-update respectively push-change-update" that doesn't
    make any sense to me.  Do you just mean "or", e.g. "push-update or
    push-change-update"?
    

      



      

        
(22) Section 3.4, 3rd paragraph, "able fulfill" => "able to fulfill"



      

      
<ALEX> changed </ALEX>



      

        
(23) Section 3.5.2, 1st paragraph, "not restricted to configuration
objects only" => "not only restricted to configuration objects".



      

      
<ALEX> changing to " not restricted to only configuration objects"  (the "only" refers to the configuration objects, not to the fact that it is restricted) </ALEX>

    

    Yes., OK.

    

      



      

        
(24) Section 3.5.2, 2nd paragraph, possible alternative text:

OLD:

    A publisher will indicate a change to the effect that a value of a
    datastore node has been updated by indicating a "replace" operation
    (applied to the datastore node) in the patch.  When a new datastore
    node was created (other than an entry in a user ordered list), a
    publisher will indicate a "create" operation in the patch.  When a
    datastore node was deleted, the publisher indicates this by a
    "delete".  When a new entry in a user-ordered list was created, the
    publisher indicates this by an "insert" operation. When an entry in
    a user-ordered list was moved, the publisher indicates this by a
    "move" operation.

NEW:

   A publisher indicates the type of change to a datastore node using
the different YANG patch operations:  the "create" operation is used for
newly created objects (except entries in a user-ordered list), the
"delete" operation is used for deleted objects (including in
user-ordered lists), the "replace" operation is used when only the
object value changes, the "insert" operation is used when a new entry is
inserted in a list, and the "move" operation is used when an existing
entry in a user-ordered list is moved.



      

      
<ALEX> OK (I don't feel strongly about this) </ALEX>



      

        
(25) Section 3.5.2, last paragraph: If you want to allow duplicate
"create" and "delete" events, then it might be cleaner to encode them as
"merge" and "remove"?  I.e. it seems that you have created a slightly
different encoding from vanilla YANG patch because of the way that
errors are handled differently.  Ideally, it would be better if a client
could just apply this as regular YANG patch, but this only works with
the encoding described here if the clients copy of the datastore is in
sync with the servers old copy of the datastore at the point that the
patch is generated from.  This seems slightly fragile to unexpected
inconsistencies between client and server (which I appreciate that you
try and avoid).



      

      
<ALEX> Hmm.  While it may be possible to replace "delete" with "remove", I am not so sure about the "merge" part.  At the end of the day, the use here is different from having a client apply a patch operation to the server, and the semantics may be a little clearer by keeping things as they are, so would prefer to keep things as defined now.  
</ALEX>  

    

    I think that is probably right.

    

    I think that it is a slight shame that vanilla YANG patch won't work
    here, but as you say I think that it will need to be applied in a
    slightly different way regardless.

    

    

      



      

        
(26) Section 3.6, second paragraph, would it not be easier to allow the
client to replace an existing filter rather than having to explicitly
remove the old filter and add the new one?  Or if you mean that any new
filter replaces the existing filter, then this may be more clearly
indicated with the text: "An RPC request proposing a new selection
filter replaces any existing filter. "



      

      
<ALEX> OK, changing per your suggestion to make it clear that the existing filter is replaced.  </ALEX>



      

        
(27) Section 3.6, paragraph 6, starting "XPath".  The "boolean" example
is unclear to me given that a xpath filter always returns a node set so
can't return a boolean result.  I also suggest changing "passes a
datastore node" to  "includes a datastore node".


      

      
<ALEX> removed the sentence and shortened the paragraph.  It now reads as follows: 
" XPath itself provides powerful filtering constructs and care must be used in filter definition. Consider an XPath filter which only passes a datastore node when an interface is up. It is up to the receiver to understand implications of the presence or absence of objects in each update. "
</ALEX>


    

    OK.

    

    

    

      

      

        
(28) Section 3.6, paragraph 7.  I think that the text must be more
explicit on when the filter is evaluated for a periodic subscription.
Am I right in thinking that it is only evaluated once when the
subscription is created, or the subscription is changed? Specifically,
if the nodeset evaluated during the lifetime of an Xpath subscription
changes then does that affect which nodes are returned?



      

      
<ALEX> Not sure what changes you are looking for.  The filter is in effect throughout the subscription until it is changed.  It is up to an implementation to decide whether to apply it once when the subscription is established to determine the datastore nodes (tracking any subtree changes to make sure nodes in the subtrees are included as needed), or whether to apply it at each update anew.    
As far as receiver authorization is concerned (i.e. access control filters), this is explained in section 3.9.  Applying no text changes at this point unless you can be more clear on what you would like to see?
</ALEX>

    

    OK.  Not considering NACM, I think that is already covered, was
    thinking of an Xpath filter.  I am right in thinking that logically
    the Xpath filter is [re-]applied whenever the periodic push
    notification is constructed.

    

    If so, possibly change:

    

    "   When the set of selection filtering criteria is applied for
      a

       periodic subscription, all selected datastore nodes to
      which a

       receiver has access are provided to that receiver."

    

    To something along the lines of ...

    

    "   When the set of selection filtering criteria is applied for
      a

      periodic subscription, then they are applied whenever a
      periodic

        update record is constructed, and only datastore nodes that pass

        the filter and to which a receiver has access
      are provided to

        that receiver."

    

    

      



      

        
(29) Section 3.7, paragraph 3:  Perhaps make this text conditional to
dampened subscriptions.  Presumably for non dampened subscriptions all
changes are reported as separate push-change-update notifications?

OLD:
In cases where multiple changes have occurred and the object
    has not been deleted, the object's most current value is reported.

NEW:
In cases where multiple changes have occurred in a subscription that has
dampening enabled, and the object
    has not been deleted, the object's most current value is reported.



      

      
<ALEX> Well, the text states clearly that this concerns any changes since the last notification message.  So, the fact that dampening is enabled is already implied. 
How about rephrasing slightly as follows:
" In cases where multiple changes have occurred over the course of a dampening period and the object has not been deleted, the object's most current value is reported.  "
</ALEX>

    

    This text is fine.

    

    But this raises another question:

    

    If no dampening is enabled, then is it expected that all changes to
    an object are always notified.  [If this is a requirement, then I
    think that it should probably be stated clearly in the YANG model
    and perhaps in section 3 as well.]

    

    Specifically, say you are monitoring interface state, without
    dampening, and it starts to flap 100 times per second.  Is the
    publisher required to notify of every single change.  Or is the
    publisher only required to notify that the at least one change has
    occurred, and guarantee that it always notifies the latest value.

    

    

      



      

        
(30) Section 3.7, paragraph 5, "Ethernet port" => "Ethernet interface"



      

      
<ALEX> changed </ALEX>



      

        
(31) Section 3.7, last paragraph: Why start at "1" rather than "0". On
overflow, why overflow to "1" rather than "0", is that deliberate?  If
you are going to force it to "1" then I would also restrict the upper
bound to int32 max rather than uint32 max to make life easier in Java
land ...


      

      
<ALEX> OK, got it.  Updated the text to reflect start at 0.  
</ALEX> 



      

        
(32) Section 3.8, tree diagrams.  I would think that another key metric
regarding whether a subscription can be satisfied would be object-rate
and data-rate.  E.g. a publisher implementation may be able to push 100k
objects/second, so a client has a choice of either monitoring less
objects, or decreasing the period.  Hence I was wondering whether rates
should be provided in addition to the object-count-estimate/limit and
kilobyte-estimate/limit.  Of course, a rate is also implicitly defined
by including the period hint, so perhaps that is sufficient without
needing to send more fields back to the client.



      

      
<ALEX> Would prefer to keep this to the basics, i.e. as-is.  As mentioned, you can compute a rate from this.  </ALEX>

    

    Yes, that is fine.  Additional fields could be augmented in future
    if needed.

    

    

      



      

        
(33) Section 3.9, 2nd paragraph, "particular each" => "particular"


      

      
<ALEX> changed </ALEX>



      

        
(34) Section 3.9, 3rd paragraph:  It was not entirely obvious to me what
the 3rd paragraph text (reproduced below) actually means.  I think that
this boils down to:  If, after access control has been applied, there
are no objects remaining in an update record then only a single empty
"push-update" notification MAY be sent and empty "push-change-update"
messages MUST NOT be sent.  This is required to ensure that clients
cannot surreptitiously monitor objects that they do not have access to
via carefully crafted selection filters.

"A publisher MUST allow for the possibility that a subscription's
    selection filter references non-existent or access-protected data.
    Such support permits a receiver the ability to monitor the entire
    lifecyle of some datastore tree.  In this case, all "push-update"
    notifications must be sent empty, and no "push-change-update"
    notifications will be sent until some data becomes visible for a
    receiver."



      

      
<ALEX> Modified the paragraph already due to another comment in another thread.  Updated this further per your comments.  Now it reads as follows:
" A publisher MUST allow for the possibility that a subscription's selection filter references non-existent data or data that a receiver is not allowed to access.  Such support permits a receiver the ability to monitor the entire lifecyle of some datastore tree without needing to explicitly enumerate every individual datastore node.  If, after access control has been applied, there are no objects remaining in an update record, then (in case of a periodic subscription) only a single empty "push-update" notification MAY be sent. Empty "push-change-update" messages (in case of an on-change subscription) MUST NOT be sent.  This is required to ensure that clients cannot surreptitiously monitor objects that they do not have access to via carefully crafted selection filters."

Also adding the following sentence, to clarify the effect on dampening: " By the same token, changes to objects that are filtered MUST NOT affect any dampening intervals."
</ALEX>


    

    Text looks good.  My only question is on the sentence with the MAY.
    I've been told by some old hands that everywhere you see "MAY" in an
    RFC then it is entirely valid to also interpret that as "MAY NOT".

    

    I think that it should perhaps be:

    

    "... then (in case of a periodic subscription) the publisher MUST
    only send single empty "push-update" notification.

    

    or, alternatively (if you don't want MUST):

    

    "... then (in case of a periodic subscription) the publisher is
    allowed to send only a single empty "push-update" notification.

    

    

      



      

        
(35) Section 3.10.  This text seems to be very closely related to the
text in section 3.3, so perhaps section 3.10 would be better moved to
become section 3.3.1?



      

      
<ALEX>
Don't want to apply major editorial restructuing at this point.
</ALEX>

    

    That is fine.

    

    

      



      

        
(36) Section 3.10, last paragraph.  "will be expected to" => "SHOULD"?


      

      
<ALEX>Not sure we want it to sound so normative, but sure - changing it to SHOULD. </ALEX>



      

        
(37) Section 3.11.1 "incomplete-update" flag.  In the YANG definition
this flag is set in the header of the message (i.e. before the data),
but for applications that are generating the notifications in a streamed
way, it would probably be better to put the flag after data.  This
potentially minimizes the requirement that a publisher has to buffer all
data to be able to set the incomplete-update flag if necessary.


      

      
<ALEX> OK, so you are suggesting to move the "incomplete-update" leaf behind the datastore contents (respectively datastore-changes).   Sure, will change that. 
</ALEX>

    

    Yes, thanks.

    

    

      
  



      

        
(38) Section 3.11.1 3rd paragraph and bullet points.  With the text as
currently written, it is acceptable for a publisher to do nothing even
if an error is hit.  They can satisfy the first "MUST" by selecting the
2nd choice, and they can satisfy the "MAY" of the second choice by doing
nothing at all.  Instead I think that the text should state that the
publisher MUST set the "incomplete-update" flag, or suspend the
subscription, or both.



      

      
<ALEX>
OK, I think the problem is with "MUST take on or more of the following actions"  (although I think what is meant is clear).  Rephrasing this as follows:  " In this case, the publisher MUST act as follows."

Also adding the following to the second bullet item: 
" If the publisher does not create an update record at all, it MUST suspend the subscription.  " 
 (This is really the only logical choice; we don't want a publisher to have the option of staying entirely silent.)  

    

    Yes, the change looks good.

    

    Thanks,

    Rob

    

    

    

      

--- Alex
</ALEX>



      

        
Thanks,
Rob

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


      

    

    

  


--------------1F05DECC4667D45AC3B1C3D2--


From nobody Thu Sep  6 12:36:17 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2862612F18C for ; Thu,  6 Sep 2018 12:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 OMM4GZHJiuby for ; Thu,  6 Sep 2018 12:36:09 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84CB1130F25 for ; Thu,  6 Sep 2018 12:36:08 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 5966C58093307 for ; Thu,  6 Sep 2018 20:36:03 +0100 (IST)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 6 Sep 2018 20:36:04 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.188]) by SJCEML703-CHM.china.huawei.com ([169.254.5.30]) with mapi id 14.03.0415.000; Thu, 6 Sep 2018 12:35:57 -0700
From: Alexander Clemm 
To: Robert Wilton , "netconf@ietf.org" 
Thread-Topic: [Netconf] RGW YANG push -18 LC comments [part 1]
Thread-Index: AQHURFz5mZcbfiuvOkCz4w7aa9Vnj6Th+3bAgAGRugCAAA6HUA==
Date: Thu, 6 Sep 2018 19:35:56 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CE72@sjceml521-mbs.china.huawei.com>
References: <386e425f-d250-a0a9-0927-1a484aed9042@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CA9A@sjceml521-mbs.china.huawei.com> <8b2bd7da-7fd3-907d-1df0-947ce2052904@cisco.com>
In-Reply-To: <8b2bd7da-7fd3-907d-1df0-947ce2052904@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.35.120]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CE72sjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] RGW YANG push -18 LC comments [part 1]
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Sep 2018 19:36:16 -0000

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

SGkgUm9iLA0KDQp0aGFuayB5b3UgZm9yIHlvdXIgcmVzcG9uc2VzIC0gcmVwbGllcyB0byB0aG9z
ZSBpbiA8QUxFWC0yPg0KDQpUaGFua3MhDQotLS0gQWxleA0KDQpGcm9tOiBSb2JlcnQgV2lsdG9u
IFttYWlsdG86cndpbHRvbkBjaXNjby5jb21dDQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDA2
LCAyMDE4IDM6NTcgQU0NClRvOiBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3
ZWkuY29tPjsgbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBSR1cgWUFO
RyBwdXNoIC0xOCBMQyBjb21tZW50cyBbcGFydCAxXQ0KDQoNCkhpIEFsZXgsDQoNClBsZWFzZSBz
ZWUgaW5saW5lIC4uLg0KDQpPbiAwNS8wOS8yMDE4IDIzOjI4LCBBbGV4YW5kZXIgQ2xlbW0gd3Jv
dGU6DQoNCkhlbGxvIFJvYiwNCg0KDQoNCnRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cyEgIFBs
ZWFzZSBmaW5kIG15IHJlcGxpZXMgaW5saW5lLCA8QUxFWD4sIHdpdGggY29ycmVzcG9uZGluZyBj
aGFuZ2VzIHRvIGJlIGluY29ycG9yYXRlZCBpbnRvIHRoZSBuZXh0IHJldmlzaW9uICgtMTkpLg0K
DQoNCg0KLS0tIEFsZXgNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpG
cm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgUm9iZXJ0IFdpbHRvbg0KDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTggNzoz
NyBBTQ0KDQpUbzogbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCg0K
U3ViamVjdDogW05ldGNvbmZdIFJHVyBZQU5HIHB1c2ggLTE4IExDIGNvbW1lbnRzIFtwYXJ0IDFd
DQoNCg0KDQpIaSwNCg0KDQoNCkkndmUgcmV2aWV3ZWQgdGhlIC0xOCBZQU5HIHB1c2ggZHJhZnQg
dXAgdG8gc2VjdGlvbiA0IHNvIGZhciAuIEkndmUgaW5jbHVkZWQgbXkNCg0KY29tbWVudHMgYmVs
b3cuICBJIHRoaW5rIHRoYXQgdGhleSBhcmUgYWxsIG1pbm9yL2Nvc21ldGljIGV4Y2VwdCBmb3Ig
dGhlIGlzc3VlDQoNCnJlZ2FyZGluZyB0aGUgZGFtcGVuZWQgc3Vic2NyaXB0aW9ucyB3aGljaCBo
YXMgYmVlbiBkaXNjdXNzZWQgYmVsb3cgYW5kDQoNCnByb2JhYmx5IGRvZXMgbm90IG5lZWQgdG8g
YmUgcmVoYXNoZWQgYWdhaW4uDQoNCg0KDQpJbiB0aGUgQWJzdHJhY3Q6DQoNCigxKSBJcyAiY29u
dGludW91cyIgdGhlIHJpZ2h0IGNob2ljZSBvZiB3b3JkIGhlcmUuICBFLmcuIEkgdGhvdWdodCB0
aGF0IHNvbWV0aW1lcw0KDQp0aGUgc3RyZWFtIG9mIHVwZGF0ZXMgaXMgbm90IGNvbnRpbnVvdXMu
ICBQb3NzaWJseSByZW1vdmUgImNvbnRpbnVvdXMiPw0KDQoNCg0KDQoNCjxBTEVYPldvdWxkIHBy
ZWZlciB0byBrZWVwLCB1bmxlc3MgeW91IGZlZWwgdmVyeSBzdHJvbmdseSBhYm91dCB0aGlzPyAg
V2hhdCB3ZSB3YW50IHRvIGJyaW5nIGFjcm9zcyBpcyB0aGF0IHRoaXMgaXMgZGlmZmVyZW50IGZy
b20gYSBvbmUtdGltZSwgb24tZGVtYW5kIHR5cGUgb2YgdXBkYXRlLiAgIlN0cmVhbSIgbWlnaHQg
aW1wbHkgdGhpcyBhbHJlYWR5LCBidXQgdGhpcyB3YXkgd2Ugd291bGQgZW1waGFzaXplIHRoaXMg
YSBiaXQgZnVydGhlci4NCg0KPC9BTEVYPg0KS2VlcGluZyBpcyBmaW5lIGlmIHRoYXQgaXMgd2hh
dCB5b3UgcHJlZmVyLg0KDQoNCg0KPEFMRVgtMj4gVGhhbmtzIDwvQUxFWC0yPg0KDQoNCg0KDQoN
CkluIHRoZSBJbnRyb2R1Y3Rpb246DQoNCigyKSAicmVtb3RlIHZpc2liaWxpdHkiIGluIHRoZSBm
aXJzdCBzZW50ZW5jZSBpcyBhIGJpdCBvYnNjdXJlLiBQZXJoYXBzIHJlcGxhY2UgdGhlDQoNCmZp
cnN0IHNlbnRlbmNlIHdpdGggIlRyYWRpdGlvbmFsIGFwcHJvYWNoZXMgdG8gbW9uaXRvcmluZyBt
YW5hZ2VtZW50IGRhdGEgb24NCg0KcmVtb3RlIGRldmljZXMgaGF2ZSBiZWVuIGJ1aWx0IHVwb24g
cG9sbGluZyIuDQoNCg0KDQo8QUxFWD4gSG93IGFib3V0IGNoYW5naW5nIHRoaXMgdG86ICJUcmFk
aXRpb25hbCBhcHByb2FjaGVzIHRvIHByb3ZpZGluZyB2aXNpYmlsaXR5IGludG8gbWFuYWdlZCBl
bnRpdGllcyBmcm9tIHJlbW90ZSBoYXZlIGJlZW4gYnVpbHQgb24gcG9sbGluZy4gIg0KDQpbSSB1
bmRlcnN0YW5kIHlvdXIgcG9pbnQsIGJ1dCByZWFzb24gZm9yIGFsdGVybmF0aXZlIHBocmFzaW5n
IGlzIHRoYXQgSSBkb24ndCB0aGluayB3ZSB3YW50IHRvIHJlc3RyaWN0IHRoaXMgdG8gbW9uaXRv
cmluZyAoYmVjYXVzZSAoYSkgeW91IGNhbiB1c2UgdGhpcyBhbHNvIHRvIG1pcnJvciBzdGF0ZSBm
b3Igb3RoZXIgcHVycG9zZXMsIGUuZy4gdG8gYXNzZXNzIHNwZWNpZmljcyBvZiB3aGF0IG5lZWRz
IHRvIGJlIGRvbmUgdG8gcHJvdmlzaW9uIGEgc2VydmljZSBzdWNjZXNzZnVsbHksIGZvciB0cm91
Ymxlc2hvb3RpbmcsIG1haW50ZW5hbmNlLCB2YWxpZGF0aW9uLCBldGMsIGFuZCAoYikgbW9uaXRv
cmluZyBkb2VzIGluY2x1ZGUgb3RoZXIgYXNwZWN0cyBzdWNoIGFzIGFsYXJtIG1hbmFnZW1lbnQp
LiAgTElrZXdpc2UsIHN1Z2dlc3QgdG8gcmVmZXIgdG8gIm1hbmFnZWQgZW50aXRpZXMiIChub3Qg
ImRldmljZXMiKSB0byBub3QgcHJlY2x1ZGUgYXBwbGljYXRpb24gdG8gdGhpbmdzIHRoYXQgYXJl
IG5vdCBkZXZpY2VzIChlLmcuIHZpcnR1YWwgInRoaW5ncyIpLiBdDQoNCjwvQUxFWD4NCg0KWW91
ciBwaHJhc2luZyBpcyBmaW5lLg0KDQo8QUxFWC0yPiBUaGFua3MgPC9BTEVYLTI+DQoNCg0KDQoN
Cg0KDQooMykgVGhlIHdvcmsgaXNuJ3QgYWN0dWFsbHkgZnJ1aXRsZXNzIGlmIHBvbGxpbmcgaXMg
dGhlIG9ubHkgYXZhaWxhYmxlIG9wdGlvbiwgaGVuY2UNCg0KcGVyaGFwcyBjaGFuZ2U6DQoNCg0K
DQpPTEQ6DQoNCiJGb3IgYXBwbGljYXRpb25zIHRoYXQgbW9uaXRvciBmb3IgY2hhbmdlcywgbWFu
eSByZW1vdGUgcG9sbGluZw0KDQogIGN5Y2xlcyBwbGFjZSB1bHRpbWF0ZWx5IGZydWl0bGVzcyBs
b2FkIG9uIHRoZSBuZXR3b3JrLCBkZXZpY2VzLA0KDQogIGFuZCBhcHBsaWNhdGlvbnMuIjxORVc6
wqA+DQoNCiA8TkVXOsKgPg0KDQpORVc6PE5FVzrCoD4NCg0KICAgIjxORVc6wqA+Rm9yIGFwcGxp
Y2F0aW9ucyB0aGF0IG1vbml0b3IgZm9yIGNoYW5nZXMsIG1hbnkgcmVtb3RlIHBvbGxpbmcNCg0K
ICAgY3ljbGVzIHBsYWNlIHVud2FudGVkIGxvYWQgb24gdGhlIG5ldHdvcmssIGRldmljZXMsDQoN
CiAgIGFuZCBhcHBsaWNhdGlvbnMsIHBhcnRpY3VsYXJseSBpZiB0aGUgbW9uaXRvcmVkIHZhbHVl
cyBhcmUgb25seSBjaGFuZ2luZw0KDQppbmZyZXF1ZW50bHkuIg0KDQoNCg0KDQoNCjxBTEVYLiBU
aGUgInVsdGltYXRlbHkgZnJ1aXRsZXNzIiBhbHNvIHJlZmVycyB0byB0aGUgZmFjdCB0aGF0IG1h
bnkgcG9sbHMgd2lsbCBub3QgeWllbGQgbmV3IGluZm9ybWF0aW9uIChvdGhlciB0aGFuICJubyBu
ZXcgaW5mb3JtYXRpb24iKSwgYXMgeW91IG1pZ2h0IGUuZy4gcmV0cmlldmUgYSBsb3Qgb2Ygc3R1
ZmYgdG8gc2VlIGlmIGl0IGNoYW5nZWQgb25seSB0byBmaW5kIHRoYXQgaXQgZGlkbid0Lg0KDQpI
b3cgYWJvdXQ6ICIgRm9yIGFwcGxpY2F0aW9ucyB0aGF0IG1vbml0b3IgZm9yIGNoYW5nZXMsIG1h
bnkgcmVtb3RlIHBvbGxpbmcgY3ljbGVzIHBsYWNlIHVud2FudGVkIGFuZCB1bHRpbWF0ZWx5IGZy
dWl0bGVzcyBsb2FkIG9uIHRoZSBuZXR3b3JrLCBkZXZpY2VzLCBhbmQgYXBwbGljYXRpb25zLCBw
YXJ0aWN1bGFybHkgd2hlbiBjaGFuZ2VzIG9jY3VyIG9ubHkgaW5mcmVxdWVudGx5LiAiDQoNCjwv
QUxFWD4NCg0KTXkgcG9pbnQgaXMgdGhhdCBpZiB0aGUgb25seSBjaG9pY2UgaXMgcG9sbGluZyB0
aGVuIGl0IGlzIG5vdCBmcnVpdGxlc3MgbG9hZCwgYmVjYXVzZSBpdCBzZXJ2ZXMgYSB1c2VmdWwg
cHVycG9zZSwgdGhhdCBwdXJwb3NlIGJlaW5nIGRldGVjdGluZyBjaGFuZ2VzIGluIHRoZSBtb25p
dG9yZWQgZGF0YS4gIEhlbmNlIHRoZSBsb2FkIGlzICJ1bndhbnRlZCIgbm90ICJmcnVpdGxlc3Mi
Lg0KDQpCdXQgdGhpcyBpcyBhIG1pbm9yIGNvbnNpZGVyYXRpb24sIHNvIEknbSBPSyB3aXRoIHdo
YXRldmVyIHlvdSBkZWNpZGUgaGVyZS4gOi0pDQoNCjxBTEVYLTI+IExldOKAmXMgY2hhbmdlIOKA
nGZydWl0bGVzc+KAnSB0byDigJx3YXN0ZWZ1bOKAnSA8L0FMRVgtMj4NCg0KDQoNCg0KDQoNCig0
KSBJbiBwYXJhZ3JhcGggc3RhcnRpbmcgIiBBIG1vcmUgZWZmZWN0aXZlIGFsdGVybmF0aXZlIiwg
cG9zc2libHkgc3VnZ2VzdA0KDQpjaGFuZ2luZyAicHVibGlzaGVyIiB0byAic2VydmVyIiBzaW5j
ZSB0aGUgaW50cm9kdWN0aW9uIGlzIGJlZm9yZSB0aGUNCg0KZGVmaW5pdGlvbnMvYWNyb255bXMg
d2hlcmUgInB1Ymxpc2hlciIgaXMgZm9ybWFsbHkgcmVmZXJlbmNlZC4NCg0KDQoNCjxBTEVYPiBS
ZXdvcmRpbmcgdG8gIi4uLiB0aGF0IGVuYWJsZXMgdGhlIHNlcnZlciAoYWxzbyByZWZlcnJlZCB0
byBhcyBwdWJsaXNoZXIpIHRvIHB1c2ggIC4uLiAiIDwvQUxFWD4NCk9LLg0KDQoNCg0KDQoNCg0K
DQpJbiBkZWZpbml0aW9uczoNCg0KDQoNCig1KSBTdWdnZXN0IHR5aW5nIHRoaXMgZGVmaW5pdGlv
biBtb3JlIGNsb3NlbHkgdG8gdGhlIHRlcm1pbm9sb2d5IGFscmVhZHkgZGVmaW5lZA0KDQppbiBS
RkMgODM0MiwgaGVuY2U6DQoNCg0KDQpPTEQ6DQoNCiAgICBvICBEYXRhc3RvcmUgbm9kZTogQW4g
aW5zdGFuY2Ugb2YgbWFuYWdlbWVudCBpbmZvcm1hdGlvbiBpbiBhDQoNCiAgICAgICBkYXRhc3Rv
cmUuICBBbHNvIGtub3duIGFzICJvYmplY3QiLg0KDQoNCg0KTkVXOg0KDQogICAgbyAgRGF0YXN0
b3JlIG5vZGU6IEEgbm9kZSBpbiB0aGUgaW5zdGFudGlhdGVkIFlBTkcgZGF0YSB0cmVlIGFzc29j
aWF0ZWQgd2l0aA0KDQphIGRhdGFzdG9yZS4gIEluIHRoaXMgZG9jdW1lbnQsIGRhdGFzdG9yZSBu
b2RlcyBhcmUgb2Z0ZW4gcmVmZXJyZWQgdG8gYXMgIllBTkcNCg0Kb2JqZWN0cyIgb3IgIm9iamVj
dHMiDQoNCg0KDQo8QUxFWD4gT0suICAoYW5kIHJlbW92ZWQgaW5zdGFuY2Ugb2YgIllBTkcgb2Jq
ZWN0IiBmcm9tIHRoZSBkb2N1bWVudCwgYXMgdGhlcmUgd2VyZSBvbmx5IHR3by4pIDwvQUxFWD4N
Ck9LLg0KDQoNCg0KDQoNCg0KDQoNCg0KKDYpICJEYXRhc3RvcmUgbm9kZSB1cGRhdGUiIGRlZmlu
aXRpb246IERvZXMgdGhpcyB1cGRhdGUgb25seSBjb250YWluIHRoZSB2YWx1ZSwNCg0Kb3IgZG9l
cyBpdCBhbHNvIGNvbnRhaW4gdGhlIHBhdGggdG8gdGhlIGRhdGFzdG9yZSBub2RlIGFzIHdlbGw/
ICBJZiB0aGlzIGFsc28NCg0KY29udGFpbnMgdGhlIHBhdGggdGhlbiBpdCB3b3VsZCBiZSBnb29k
IGlmIHRoYXQgd2FzIGV4cGxpY2l0IGluIHRoZSBkZWZpbml0aW9uLg0KDQoNCg0KDQoNCjxBTEVY
PiBVcGRhdGVkIGFzIGZvbGxvd3M6ICIgQSBkYXRhIGl0ZW0gY29udGFpbmluZyB0aGUgY3VycmVu
dCB2YWx1ZSBvZiBhIGRhdGFzdG9yZSBub2RlIGF0IHRoZSB0aW1lIHRoZSBkYXRhc3RvcmUgbm9k
ZSB1cGRhdGUgd2FzIGNyZWF0ZWQsIGFzIHdlbGwgYXMgdGhlIHBhdGggdG8gdGhlIGRhdGFzdG9y
ZSBub2RlLiIgIDwvQUxFWD4NCkxvb2tzIGdvb2QuDQoNCg0KDQoNCg0KDQoNCig3KSBQZXJoYXBz
IHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbiBpcyBtb3JlIHByZWNpc2U/ICBPciBieSAidXBkYXRl
cyINCg0KZG8geW91IGFjdHVhbGx5IG1lYW4gInVwZGF0ZSByZWNvcmRzIj8gIFRoZXJlIGFyZSBv
dGhlciByZWZlcmVuY2VzIHRvDQoNCiJ1cGRhdGVzIiBpbiB0aGUgZGVmaW5pdGlvbnMsIGRvIHRo
ZXNlIGFsbCByZWZlciB0byAidXBkYXRlIHJlY29yZHMiPyBJZiBzbyB0aGVuIEkNCg0Kd291bGQg
c3VnZ2VzdCBtb3ZpbmcgdGhlIGRlZmluaXRpb24gb2YgInVwZGF0ZSByZWNvcmQiIGFib3ZlICJk
YXRhc3RvcmUNCg0Kc3Vic2NyaXB0aW9uIi4NCg0KDQoNCk9MRDoNCg0KDQoNCiJEYXRhc3RvcmUg
c3Vic2NyaXB0aW9uOiBBIHN1YnNjcmlwdGlvbiB0byB1cGRhdGVzIHJlZ2FyZGluZw0KDQogICAg
ICAgY29udGVudHMgb2YgYSBkYXRhc3RvcmUuIjxORVc6Pg0KDQogPE5FVzo+DQoNCk5FVzoNCg0K
IDxORVc6Pg0KDQoiPE5FVzo+RGF0YXN0b3JlIHN1YnNjcmlwdGlvbjogQSBzdWJzY3JpcHRpb24g
dG8gYSBzdHJlYW0gb2YgZGF0YXN0b3JlIG5vZGUgdXBkYXRlcy4iDQoNCg0KDQo8QUxFWD4gb2ss
IGNoYW5nZWQgPC9BTEVYPg0KDQoNCg0KDQoNCig4KSBTdWdnZXN0IHJlbW92aW5nICJpbnN0YW50
aWF0ZWQiIGZyb20gdGhlIGZvbGxvd2luZyBkZWZpbml0aW9uLCBhbmQgdXNpbmcNCg0KZGVzY2Vu
ZGFudCAod2hpY2ggaXMgdXNlZCBpbiA3OTUwKSBpbnN0ZWFkIG9mIGNvbnRhaW5lZCAuLiBJIGFs
c28gc3VnZ2VzdCBtb3ZpbmcNCg0KdGhlIGRlZmluaXRpb24gdXAsIGRpcmVjdGx5IGJlbG93ICJk
YXRhc3RvcmUgbm9kZSI6DQoNCg0KDQpPTEQ6DQoNCg0KDQogICAgbyBEYXRhc3RvcmUgc3VidHJl
ZTogQW4gaW5zdGFudGlhdGVkIGRhdGFzdG9yZSBub2RlIGFuZCB0aGUNCg0KICAgICAgIGRhdGFz
dG9yZSBub2RlcyB0aGF0IGFyZSBoaWVyYXJjaGljYWxseSBjb250YWluZWQgd2l0aGluIGl0Lg0K
DQoNCg0KTkVXOg0KDQoNCg0KICAgIG8gRGF0YXN0b3JlIHN1YnRyZWU6IEEgIGRhdGFzdG9yZSBu
b2RlIGFuZCBhbGwgaXRzIGRlc2NlbmRhbnQgZGF0YXN0b3JlDQoNCm5vZGVzLiINCg0KDQoNCg0K
DQo8QUxFWD4gY2hhbmdlZCA8L0FMRVg+DQoNCg0KDQoNCg0KKDkpIFNlYyAzLiBTb2x1dGlvbiBv
dmVydmlldywgbGFzdCBzZW50ZW5jZS4gICBJdCBpcyBub3QgIllBTkcgb2JqZWN0cyINCg0KdGhh
dCBhcmUgYmVpbmcgcHVzaGVkLCBidXQgc3VyZWx5ICJkYXRhc3RvcmUgbm9kZSB1cGRhdGVzIiBv
ciBwZXJoYXBzDQoNCiJ1cGRhdGUgcmVjb3JkcyIgdGhhdCBhcmUgcHVzaGVkLCBvciBldmVuICJD
aGFuZ2VzIHRvIFlBTkcgb2JqZWN0cyINCg0KDQoNCg0KDQo8QUxFWD4gQ2hhbmdlZCB0byAiZGF0
YXN0b3JlIG5vZGUgdXBkYXRlcyIgPC9BTEVYPg0KDQoNCg0KU2VjIDMuMSBTdWJzY3JpcHRpb24g
bW9kZWw6DQoNCg0KDQooMTApIFBlcmhhcHMgY2hhbmdlInN1YnRyZWVzIHdpdGhpbiBhIGRhdGFz
dG9yZSIgdG8gImRhdGFzdG9yZSBzdWJ0cmVlcyIuDQoNCg0KDQoNCg0KPEFMRVg+IGNoYW5nZWQg
PC9BTEVYPg0KDQoNCg0KKDExKSBJdCBpcyBub3Qgb2J2aW91cyB0byBtZSBmcm9tIHRoaXMgdGV4
dCB3aGF0ICJBbmNob3IgdGltZSIgaXMsDQoNCmFsdGhvdWdoIEkgc3VzcGVjdCB0aGF0IGl0IGlz
IGRlc2NyaWJlZCBpbiBtb3JlIGRldGFpbCBsYXRlciBpbiB0aGUNCg0KZG9jdW1lbnQuICBHaXZl
biB0aGF0IHRoZSBzZWN0aW9uIG9uLWNoYW5nZSBzdWJzY3JpcHRpb25zIGhhcyBtb3JlDQoNCmRl
dGFpbCBmb3IgdmFyaW91cyBwYXJhbWV0ZXJzLCBJIHdvbmRlciB3aGV0aGVyIGl0IHdvdWxkIGJl
IGhlbHBmdWwgdG8NCg0KZGVzY3JpYmUgYW5jaG9yIHRpbWUgaW4gbW9yZSBkZXRhaWwgaW4gdGhp
cyBzZWN0aW9uPw0KDQoNCg0KDQoNCjxBTEVYPiBSb3VnaGx5IHdoYXQgaXQgaXMgaXMgZXhwbGFp
bmVkIGluIHRoZSBzYW1lIHNlbnRlbmNlLCBidXQgaG93IGFib3V0IGNoYW5naW5nIGl0IGFzIGZv
bGxvd3M6DQoNCiIgVGhlc2UgcGFyYW1ldGVycyBhcmUgdGhlIHBlcmlvZCBpbnRlcnZhbCB3aXRo
IHdoaWNoIHRvIHJlcG9ydCB1cGRhdGVzLCBhbmQgYW4gImFuY2hvciB0aW1lIiwgaS5lLiBhIHJl
ZmVyZW5jZSBwb2ludCBpbiB0aW1lIHRoYXQgY2FuIGJlIHVzZWQgdG8gY2FsY3VsYXRlIGF0IHdo
aWNoIHBvaW50cyBpbiB0aW1lIHBlcmlvZGljIHVwZGF0ZXMgbmVlZCB0byBiZSBhc3NlbWJsZWQg
YW5kIHNlbnQuICINCg0KPC9BTEVYPg0KSSB0aGluayBJIGdldCB0aGlzLCBidXQgZGlkbid0IGZp
bmQgaXQgY29tcGxldGVseSBjbGVhciB1bnRpbCBJIGhhZCBsb29rZWQgYXQgdGhlIG1vZGVsLiAg
SSB0aGluayB0aGF0IHlvdSB1cGRhdGVkIHRleHQgaXMgT0suDQoNCkFsdGhvdWdoIEkgaGF2ZSBh
IHNsaWdodCBjb25jZXJuIChlLmcuIGluIHNlY3Rpb24gNC4yKSwNCg0KDQoNCiAgICAgICogIGFu
ICJhbmNob3ItdGltZSI7IHVwZGF0ZSBpbnRlcnZhbHMgYWx3YXlzIGZhbGwgb24gdGhlIHBvaW50
cyBpbg0KDQogICAgICAgICB0aW1lIHRoYXQgYXJlIGEgbXVsdGlwbGUgb2YgYSAicGVyaW9kIiBm
cm9tIGFuICJhbmNob3ItdGltZSIuDQoNCkkgY2FuIHNlZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCB0
cnkgYW5kIGtlZXAgdG8gdGhpcyBpbnRlcnZhbCwgYnV0IEkgc3VzcGVjdCB0aGF0IHRoZSB2YXN0
IG1ham9yaXR5IG9mIGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdCBiZSBhYmxlIHRvIGd1YXJhbnRl
ZSB0aGF0IGl0IGlzIGV4YWN0IG11bHRpcGxlcyBvZiB0aGUgZ2l2ZW4gcGVyaW9kLCBnaXZlbiB0
aGF0ICJhbmNob3ItdGltZSIgc2VlbXMgdG8gdGFrZSBhbiBhcmJpdHJhcnkgc3ViLXNlY3Rpb24g
cHJlY2lzaW9uLCBhbmQgdGltZXRpY2tzIGFyZSBpbiBodW5kcmVkcyBvZiBhIHNlY29uZC4gIFBv
c3NpYmx5LCB3ZWFrZW5pbmcgdGhlIHRleHQgKGUuZy4gYXMgcGVyIGJlbG93LCBidXQgdGhlIFlB
TkcgbW9kZWwgd291bGQgcHJvYmFibHkgbmVlZCB0byBiZSB1cGRhdGVkKSBtaWdodCBiZSBhIGdv
b2QgaWRlYT8NCg0KDQoNCiAgICAgICogIGFuICJhbmNob3ItdGltZSI7IHVwZGF0ZSBpbnRlcnZh
bHMgYWx3YXlzIGZhbGwgYXMgY2xvc2UgYXMgcG9zc2libGUgdG8gdGhlIHBvaW50cyBpbg0KDQog
ICAgICAgICB0aW1lIHRoYXQgYXJlIGEgbXVsdGlwbGUgb2YgYSAicGVyaW9kIiBmcm9tIGFuICJh
bmNob3ItdGltZSIuDQoNCg0KPEFMRVgtMj5JIGRvbuKAmXQgbGlrZSB0aGUg4oCcYXMgY2xvc2Ug
YXMgcG9zc2libGXigJ0uICBXaGF0IGlzIHBvc3NpYmxlIG1heSBkaWZmZXIgYmV0d2VlbiBpbXBs
ZW1lbnRhdGlvbnM7IEkgZmVlbCB0aGF0IHRoaXMgZm9ybXVsYXRpb24gYmx1cnMgbW9yZSB0aGFu
IGl0IGNsYXJpZmllcy4gIFBlcmhhcHMgd2Ugc2hvdWxkIHNpbXBseSByZW1vdmUgdGhlIOKAnGFs
d2F5c+KAnSDigJMgdG8gcmVhZA0KDQrigJx1cGRhdGUgaW50ZXJ2YWxzIGZhbGwgb24gdGhlIHBv
aW50cyBpbiB0aW1lIHRoYXQgYXJlIGEgbXVsdGlwbGUgb2YgYSAicGVyaW9kIiBmcm9tIGFuICJh
bmNob3ItdGltZSIgPC9BTEVYLTI+DQoNCg0KDQoNCg0KDQoNCigxMikgRGFtcGVuaW5nIHBlcmlv
ZDogVGhlIHRleHQgc3RhdGVzIHRoYXQgIlRoZSBkYW1wZW5pbmcgcGVyaW9kDQoNCmNvbGxlY3Rp
dmVseSBhcHBsaWVzIHRvIHRoZSBzZXQgb2YgYWxsIGRhdGFzdG9yZSBub2RlcyBzZWxlY3RlZCBi
eSBhDQoNCnNpbmdsZSBzdWJzY3JpcHRpb24gYW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2ZXIu
IiAgVGhpcyB3b3VsZCBpbXBseQ0KDQp0aGF0IGlmIGEgc2luZ2xlIHN1YnNjcmlwdGlvbiBoYWQg
bXVsdGlwbGUgcmVjZWl2ZXJzIHRoYXQgdGhleSB3b3VsZCBiZQ0KDQpkYW1wZW5lZCBpbmRlcGVu
ZGVudGx5LCBidXQgaXQgd2Fzbid0IG9idmlvdXMgdG8gbWUgdGhhdCB0aGlzIG1ha2VzDQoNCnNl
bnNlLiAgSSB3b3VsZCBhc3N1bWUgdGhhdCBmb3IgYSBnaXZlbiBzdWJzY3JpcHRpb24gdGhhdCBh
bGwgcmVjZWl2ZXJzDQoNCndvdWxkIHJlY2VpdmUgdGhlIHNhbWUgdXBkYXRlIHJlY29yZHMuDQoN
Cg0KDQo8QUxFWD4gWWVzLiAgUmVtb3ZlZCAiYW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2ZXIi
LiAgQWxzbyBjbGFyaWZpZWQgZnVydGhlciAoaW4gYSBzbGlnaHQgcmV3b3JkaW5nKSAiIFRoaXMg
bWVhbnMgdGhhdCB3aGVuIHRoZXJlIGlzIGEgY2hhbmdlIHRvIG9uZSBvciBtb3JlIHN1YnNjcmli
ZWQgb2JqZWN0cywgYW4gdXBkYXRlIHJlY29yZCBjb250YWluaW5nIHRob3NlIG9iamVjdHMgaXMg
Y3JlYXRlZCBpbW1lZGlhdGVseSAod2hlbiBubyBkYW1wZW5pbmcgcGVyaW9kIGlzIGluIGVmZmVj
dCkgb3IgYXQgdGhlIGVuZCBvZiBhIGRhbXBlbmluZyBwZXJpb2QgKHdoZW4gYSBkYW1wZW5pbmcg
cGVyaW9kIGlzIGluIGZhY3QgaW4gZWZmZWN0KS4gICINCg0KPC9BTEVYPg0KT0suDQoNCg0KDQoN
Cg0KDQoNCigxMykgUmF0aGVyIHRoYW4gIk5vIFN5bmMgb24gc3RhcnQiLCBpdCBtaWdodCBiZSBi
ZXR0ZXIgdG8gcmVmZXIgdG8gdGhpcw0KDQphcyAgInN5bmMgb24gc3RhcnQiLCB3aGljaCBjb3Vs
ZCBiZSBkZWZpbmVkIGFzIGEgYm9vbGVhbiB3aXRoIGRlZmF1bHQNCg0KdHJ1ZSBbSSd2ZSBub3Qg
Y2hlY2tlZCB0aGUgWUFORyBtb2RlbF0NCg0KDQoNCjxBTEVYPiBpdCdzIG5vdCBkZWZpbmVkIGFz
IGEgYm9vbGVhbiBidXQgYXMgYSBsZWFmIG9mIHR5cGUgZW1wdHkuICAoU28sIHRoZSAiZGVmYXVs
dCIgaXMgaW4gZmFjdCB0cnVlLCB1bmxlc3MgIG5vLXN5bmMtb24tc3RhcnQgaXMgcHJlc2VudCku
ICBJIGRvbid0IHNlZSBhIGNvbXBlbGxpbmcgcmVhc29uIHRvIGNoYW5nZSB0aGlzIGFuZCBzdWdn
ZXN0IHRvIGtlZXAgdGhpcyBhcy1pcy4NCg0KPC9BTEVYPg0KDQpPSy4gIEkgdGhpbmsgdGhhdCBp
biBZQU5HLCBwYXJ0aWN1bGFybHkgY29uc2lkZXJpbmcgTk1EQSwgaXQgaXMgY2xlYW5lciB0byBt
b2RlbCB0aGlzIGFzIGEgYm9vbGVhbiB3aXRoIGRlZmF1bHQgdHJ1ZSwgcGFydGljdWxhcmx5IGlm
IHlvdSBkbyBhIGdldC1kYXRhIHJlcXVlc3Qgb24gdGhlIG9wZXJhdGlvbmFsIHN0YXRlLCBzaW5j
ZSBpdCBtb3JlIGNsZWFybHkgYW5kIGV4cGxpY2l0bHkgaW5kaWNhdGVzIHdoZXRoZXIgc3luYy1v
bi1zdGFydCBpcyBlbmFibGVkLg0KDQpXaXRoIHRoZSBjdXJyZW50IG1vZGVsLCBvbiBhIGdldC1k
YXRhIHJlcXVlc3QgYWdhaW5zdCBvcGVyYXRpb24sIHRoZSBzZXJ2ZXIgcmV0dXJucyAibm8tc3lu
Y2gtb24tc3RhcnQiLCBpdCBpcyBvYnZpb3VzIHRoYXQgaXQgd29uJ3QgcGVyZm9ybSBhIHN5bmMt
b24tc3RhcnQsIGhvd2V2ZXIsIHRoZSByZXZlcnNlIGlmIHRoZSBsZWFmIGlzbid0IHByZXNlbnQg
aXNuJ3QgcXVpdGUgc28gY2xlYXIuICBJZiBpdCBkb2Vzbid0IHJldHVybiAibm8tc3luY2gtb24t
c3RhcnQiIHRoZW4gdGhhdCBlaXRoZXIgbWVhbnMgdGhlIGRldmljZSB3aWxsIHBlcmZvcm0gc3lu
Yy1vbi1zdGFydCwgb3IgcGVyaGFwcyB0aGUgbm9kZSB0aGUgc2VydmVyIGlzbid0IHJldHVybmlu
ZyBhbnkgaW5mb3JtYXRpb24sIG9yIHBlcmhhcHMgaXQgaGFzIGJlZW4gZGV2aWF0ZWQuICBTbywg
aW4gc3VtbWFyeSwgSSB0aGluayB0aGF0IGZsYWdzIHRoYXQgdHVybiBzb21ldGhpbmcgb2ZmLCBh
cmUgYmV0dGVyIG1vZGVsZWQgd2l0aCBkZWZhdWx0IHRydWUsIHJhdGhlciB0aGFuIGFzIGVtcHR5
IGxlYWZzLiAgRmxhZ3MgdGhhdCB0dXJuIHNvbWV0aGluZyBvbiBjYW4gYmUgbW9kZWxlZCBlcXVh
bGx5IHdlbGwgZWl0aGVyIHdheS4NCg0KDQoNCjxBTEVYLTI+SW4gdGVybXMgb2YgaW5zdGFudGlh
dGlvbiwgSSBmaW5kIGVtcHR5IGxlYXZlcyBtb3JlIGVsZWdhbnQsIHBhcnRpY3VsYXJseSBpZiB0
aGVyZSBpcyBhIGRlZmF1bHQgdmFsdWUuICBJIHRoaW5rIDxuby1zeW5jLW9uLXN0YXJ0Lz4gaXMg
bW9yZSBlbGVnYW50IHRoYW4gPG5vLXN5bmMtb24tc3RhcnQ+VHJ1ZTwvbm8tc3luYy1vbi1zdGFy
dD4uDQoNCldvdWxkIHlvdSBiZSBzYXRpc2ZpZWQgaWYgd2UgdHVybiB0aGUgZGVmYXVsdCBhcm91
bmQsIGkuZS4gY2hhbmdlIOKAnG5vLXN5bmMtb24tc3RhcnTigJ0gdG8g4oCcc3luYy1vbi1zdGFy
dOKAnSwgYnV0IGtlZXBpbmcgaXQgYW4gZW1wdHk/DQoNCg0KDQogPC9BTEVYLTI+DQoNCg0KDQoN
CkJUVywgSSBhbHNvIG5vdGljZSB0aGF0IGlzIHVzZXMgInN5bmNoIiBpbiB2YXJpb3VzIGxlYWYg
bmFtZSwgYnV0IEkgd291bGQgcmVjb21tZW5kIHRoZSBhYmJyZXZpYXRpb24gInN5bmMiIGluc3Rl
YWQuICBJdCBpcyBzaG9ydGVyLCBhbmQgSSB0aGluayBtb3JlIGNvbW1vbmx5IHVzZWQuICBodHRw
czovL2VuZ2xpc2guc3RhY2tleGNoYW5nZS5jb20vcXVlc3Rpb25zLzY4MS9zeW5jZWQtb3Itc3lu
Y2hlZA0KDQoNCjxBTEVYLTI+SGF2ZSBjaGFuZ2VkIOKAnHN5bmNo4oCdIChhbmQg4oCccmVzeW5j
aOKAnSkgdG8gc3luYyAvIHJlc3luYyB0aHJvdWdvdXQgdGhlIGRvY3VtZW50dCwgYWxzbyBwZXIg
Um9oaXTigJlzIGVhcmxpZXIgY29tbWVudC4NCg0KPC9BTEVYLTI+DQoNCg0KDQoNCg0KDQoNCg0K
U2VjIDMuMi4gTmVnb3RpYXRpb24gb2YgU3Vic2NyaXB0aW9uIFBvbGljaWVzDQoNCg0KDQooMTQp
ICJSYW5kb20gZ3Vlc3NpbmcgYXQiID0+ICJSYW5kb20gZ3Vlc3Npbmcgb2YiLiAgQWx0aG91Z2gs
IEkgdGhpbmsNCg0KdGhhdCBwcm9iYWJseSB0aGlzIGZpcnN0IHNlbnRlbmNlLCBhbmQgdGhlICJU
aGVyZm9yZSwgIiBjb3VsZCBqdXN0IGJlDQoNCmRlbGV0ZWQuICBJLmUuIHN0YXJ0aW5nIHRoZSBw
YXJhZ3JhcGggIkluIG9yZGVyIHRvIG1pbmltaXplIC4uLiINCg0KDQoNCg0KDQo8QUxFWD4gQ2hh
bmdlZCAiYXQiIHRvICJvZiIsIGhvd2V2ZXIsIHByZWZlciB0byBrZWVwIHRoZSBmaXJzdCBzZW50
ZW5jZSBhcyBpdCBkb2VzIHByb3ZpZGUgc29tZSBleHBsYW5hdGlvbi4gIDwvQUxFWD4NCk9LLg0K
DQoNCg0KDQoNCg0KDQooMTUpIFN1Z2dlc3QgbWlub3IgcmV3b3JkaW5nIG9mIDMuMy4gdGhpcmQg
cGFyYWdyYXBoOg0KDQoNCg0KT0xEOg0KDQoNCg0KSW4gdGhhdCBjYXNlLCB1cGRhdGVzIGFyZSBz
ZW50IG9ubHkgZm9yIHRob3NlIG9iamVjdHMNCg0KICAgIHdpdGhpbiB0aGUgc2NvcGUgdGhhdCBk
byBzdXBwb3J0IG9uLWNoYW5nZSB1cGRhdGVzIHdoZXJlYXMgb3RoZXINCg0KICAgIG9iamVjdHMg
YXJlIGV4Y2x1ZGVkIGZyb20gdXBkYXRlIHJlY29yZHMsIHdoZXRoZXIgb3Igbm90IHRoZWlyIHZh
bHVlcw0KDQogICAgYWN0dWFsbHkgY2hhbmdlLg0KDQoNCg0KTkVXOg0KDQoNCg0KSW4gdGhhdCBj
YXNlLCB1cGRhdGVzIGFyZSBzZW50IG9ubHkgZm9yIHRob3NlIG9iamVjdHMNCg0KICAgIHdpdGhp
biB0aGUgc2NvcGUgdGhhdCBkbyBzdXBwb3J0IG9uLWNoYW5nZSB1cGRhdGVzLCB3aGVyZWFzIG90
aGVyDQoNCiAgICBvYmplY3RzIGFyZSBleGNsdWRlZCBmcm9tIHVwZGF0ZSByZWNvcmRzLCBldmVu
IGlmIHRoZWlyIHZhbHVlcyBjaGFuZ2UuDQoNCg0KDQo8QUxFWD4gY2hhbmdlZCA8L0FMRVg+DQoN
Cg0KDQoNCg0KKDE2KSBRdWVzdGlvbiBvbiAzLjMuIGZpZnRoIHBhcmFncmFwaCAoYmVsb3cpLCBp
dCdzIHVuY2xlYXIgdG8gbWUgd2hhdA0KDQppcyBtZWFudCBieSAid2hpY2ggYXJlIGN1cnJlbnQg
YXQgdGhlIHRpbWUiOg0KDQoNCg0KIlZhbHVlcyBzZW50IGF0IHRoZSBlbmQgb2YgdGhlDQoNCiAg
ICBkYW1wZW5pbmcgcGVyaW9kIGFyZSB0aGUgY3VycmVudCB2YWx1ZXMgb2YgYWxsIGNoYW5nZWQg
b2JqZWN0cyB3aGljaA0KDQogICAgYXJlIGN1cnJlbnQgYXQgdGhlIHRpbWUgdGhlIGRhbXBlbmlu
ZyBwZXJpb2QgZXhwaXJlcy4iDQoNCg0KDQo8QUxFWD4gUmVwaHJhc2UgdGhlIHBhcmFncmFwaCBh
cyBmb2xsb3dzLCBqdXN0IHRvIG1ha2UgaXQgY2xlYXIgKGl0J3MgYSBiaXQgbW9yZSB2ZXJib3Nl
IHRoYW4gaXQgaGFzIHRvLCBidXQgd2Ugd2FudCB0byBtYWtlIHN1cmUgdGhlcmUgaXMgbm8gcXVl
c3Rpb24gYXMgdG8gd2hhdCB2YWx1ZSB0byBzZW5kIC0gdGhlIHZhbHVlIG9mIHRoZSBvcmlnaW5h
bCBjaGFuZ2Ugb3IgdGhlIHZhbHVlIGF0IHRoZSB0aW1lIG9mIHVwZGF0aW5nKS4NCg0KIi4uLiAu
ICBWYWx1ZXMgc2VudCBhdCB0aGUgZW5kIG9mIHRoZSBkYW1wZW5pbmcgcGVyaW9kIGFyZSB0aGUg
dmFsdWVzIHRoYXQgYXJlIGN1cnJlbnQgYXQgdGhlIGVuZCBvZiB0aGUgZGFtcGVuaW5nIHBlcmlv
ZCBvZiBhbGwgY2hhbmdlZCBvYmplY3RzLiAgQ2hhbmdlZCBvYmplY3RzIGluY2x1ZGUgdGhvc2Ug
d2hpY2ggd2VyZSBkZWxldGVkIG9yIG5ld2x5IGNyZWF0ZWQgZHVyaW5nIHRoYXQgZGFtcGVuaW5n
IHBlcmlvZC4gIElmIGFuIG9iamVjdCBoYXMgcmV0dXJuZWQgdG8gaXRzIG9yaWdpbmFsIHZhbHVl
IChvciBldmVuIGhhcyBiZWVuIGNyZWF0ZWQgYW5kIHRoZW4gZGVsZXRlZCkgZHVyaW5nIHRoZSBk
YW1wZW5pbmctcGVyaW9kLCB0aGF0IHZhbHVlIChhbmQgbm90IHRoZSBpbnRlcmltIGNoYW5nZSkg
d2lsbCBzdGlsbCBiZSBzZW50LiAuLi4iDQoNCjwvQUxFWD4NClllcywgSSB0aGluayB0aGF0IHRo
ZSBsb25nZXIgYW5kIG1vcmUgZXhwbGljaXQgdGV4dCBpcyBiZXR0ZXIuDQoNCg0KDQoNCg0KDQoN
CigxNykgSSBzdGlsbCBkb3VidCB0aGF0IGFsbCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBzdHJpY3Rs
eSBmb2xsb3cgYWxsIG9mDQoNCjMuMy4gcGFyYWdyYXBoIDUsIHBhcnRpY3VsYXJseSB0aGUgY3Jl
YXRlZCBhbmQgZGVsZXRlZCB3aXRoaW4gYQ0KDQpkYW1wZW5pbmcgcGVyaW9kIGJlY2F1c2UgSSBw
ZXJjZWl2ZSB0aGF0IGl0IGlzIHBhcnRpY3VsYXJseSBkaWZmaWN1bHQgdG8NCg0KaW1wbGVtZW50
IGNsZWFubHkvZWZmaWNpZW50bHkuICBIb3dldmVyLCB0aGlzIGlzc3VlIGhhcyBiZWVuIGRpc2N1
c3NlZA0KDQpwcmV2aW91c2x5LCBhbmQgSSBoYXZlIG5vIHBhcnRpY3VsYXIgZGVzaXJlIHRvIHNs
b3cgdGhlIFJGQyBwcm9ncmVzcw0KDQpkb3duIHdpdGggZnVydGhlciBkaXNjdXNzaW9uIG9uIHRo
aXMuDQoNCg0KDQoNCg0KPEFMRVg+IE5vIGNoYW5nZSBtYWRlIDwvQUxFWD4NCg0KDQoNCigxOCkg
U2VjdGlvbiAzLjMsIGNvbmNlcHR1YWwgcHJvY2Vzcywgc3RlcCAxIHN0YXRlcyB0aGF0IGFjY2Vz
cyBjb250cm9sDQoNCnJ1bGVzIGFyZSBjaGVja2VkIHRvIGVuc3VyZSB0aGUgcmVjZWl2ZXIgaXMg
YXV0aG9yaXplZCB0byB2aWV3IGFsbA0KDQpzdWJzY3JpYmVkIGRhdGFzdG9yZSBub2RlcywgYnV0
IEkgdGhpbmsgdGhhdCB0aGlzIHNob3VsZCBzdGF0ZSB0aGF0IHRoZQ0KDQphY2Nlc3MgY29udHJv
bCBydWxlcyBhcmUgdXNlZCB0byBmaWx0ZXIgdGhlIHN1YnNjcmliZWQgZGF0YXN0b3JlIG5vZGVz
DQoNCnRvIHRob3NlIHRoYXQgdGhlIGNsaWVudCBoYXMgYWNjZXNzIHJpZ2h0cyB0by4NCg0KDQoN
CjxBTEVYPiAgSSBhZGRlZCAiIChhbmQgZmlsdGVyIG91dCBhbnkgbm9kZXMgZm9yIHdoaWNoIHRo
aXMgaXMgbm90IHRoZSBjYXNlKSIgdG8gbWFrZSB0aGlzIGNsZWFyZXI7IHRoaXMgbm93IHJlYWRz
ICIgSnVzdCBiZWZvcmUgYSBjaGFuZ2UsIG9yIGF0IHRoZSBzdGFydCBvZiBhIGRhbXBlbmluZyBw
ZXJpb2QsIGV2YWx1YXRlIGFueSBmaWx0ZXJpbmcgYW5kIGFueSBhY2Nlc3MgY29udHJvbCBydWxl
cyB0byBlbnN1cmUgcmVjZWl2ZXIgaXMgYXV0aG9yaXplZCB0byB2aWV3IGFsbCBzdWJzY3JpYmVk
IGRhdGFzdG9yZSBub2RlcyAoYW5kIGZpbHRlciBvdXQgYW55IG5vZGVzIGZvciB3aGljaCB0aGlz
IGlzIG5vdCB0aGUgY2FzZSkuICINCg0KPC9BTEVYPg0KDQpPSywgYnV0IEkgd291bGQgY2hhbmdl
ICJhbmQgZmlsdGVyIiB0byAiZmlsdGVyaW5nIi4NCg0KPEFMRVgtMj5PSywgY2hhbmdlZCA8L0FM
RVgtMj4NCg0KDQoNCg0KDQooMTkpIEEgcmVsYXRlZCBxdWVzdGlvbjogIFdoZW4gaGFwcGVucyBp
ZiB0aGVyZSBpcyBhbiBhY2Nlc3MgY29udHJvbA0KDQpjaGFuZ2UsIGkuZS4gdGhlIHJlY2VpdmVy
IGhhZCBhY2Nlc3MgcHJldmlvdXNseSwgYnV0IHRoZW4gaXQgd2FzDQoNCnJldm9rZWQuICBEb2Vz
IGl0IHNlZSBhIGRlbGV0ZT8gIE9yIGRvZXMgaXQgbm90IGdldCBhbnkgbm90aWZpY2F0aW9uPw0K
DQpTaW1pbGFybHksIGlmIHRoZXkgZGlkbid0IHByZXZpb3VzbHkgaGF2ZSBhY2Nlc3MsIGJ1dCB0
aGVuIGFjY2VzcyB3YXMNCg0KZ3JhbnRlZCBiZWZvcmUgdGhlIGVuZCBvZiB0aGUgZGFtcGVuaW5n
IHBlcmlvZD8gIE9LLCBJIHNlZSB0aGF0IHRoaXMgaXMNCg0KZGVzY3JpYmVkIGluIG1vcmUgZGV0
YWlsIGluIHNlY3Rpb24gMy45LCBwYXJhZ3JhcGggMy4gIFBlcmhhcHMgYSBmb3J3YXJkDQoNCnJl
ZmVyZW5jZSB3b3VsZCBiZSB1c2VmdWwgaGVyZS4NCg0KDQoNCjxBTEVYPiBJIHRoaW5rIHRoaXMg
aXMgZGVmaW5lZCBpbiBkZXRhaWwgaW4gMy45LCBhcyB5b3Ugbm90ZS4gIEkgdGhpbmsgdGhlIHNw
aXJpdCBvZiB0aGUgZGVzY3JpcHRpb24gaGVyZSBpcyBjbGVhciwgYW5kIEkgZG9uJ3Qgd2FudCB0
byBvdmVybHkgYnVyZGVuIHRoZSB0ZXh0IHdpdGggY3Jvc3MtcmVmZXJlbmNlcyB3aXRoaW4gdGhl
IHNhbWUgdGV4dC4gIFNvLCBJIHN1Z2dlc3Qga2VlcGluZyB0aGlzIGFzLWlzLg0KDQo8L0FMRVg+
DQpPSy4NCg0KDQoNCg0KDQoNCg0KKDIwKSBTZWN0aW9uIDMuMywgbGFzdCBwYXJhZ3JhcGgsICJj
YW4gYmUgY3JlYXRlZCIgPT4gIm11c3QgYmUgY3JlYXRlZCIuDQoNCg0KDQo8QUxFWD4gQWN0dWFs
bHksIEkgdGhpbmsgaXQgaXMgImNhbiIuICBJdCBpcyB1cCB0byB0aGUgZGlzY3JldGlvbiBvZiB3
aGF0IHRoZSBzdWJzY3JpYmVyIHdhbnRzIHRvIGRvLiAgIEFzIGFuIGFsdGVybmF0aXZlIHRvIHVz
aW5nIHRoZSB3b3JkICJjYW4iIChub3Qgc3VyZSBpZiB0aGlzIGlzIHJlYWxseSBuZWVkZWQpLCBy
ZXBocmFzaW5nIGl0IHRvICIgSW4gY2FzZXMgd2hlcmUgYSBzdWJzY3JpYmVyIHdhbnRzIHRvIGhh
dmUgc2VwYXJhdGUgZGFtcGVuaW5nIHBlcmlvZHMgZm9yIGRpZmZlcmVudCBvYmplY3RzLCB0aGUg
c3Vic2NyaWJlciBoYXMgdGhlIG9wdGlvbiB0byBjcmVhdGUgbXVsdGlwbGUgc3Vic2NyaXB0aW9u
cyB3aXRoIGRpZmZlcmVudCBzZWxlY3Rpb24gZmlsdGVycy4gIiA8L0FMRVg+DQoNCm11c3QgaXMg
Y29ycmVjdCwgc2luY2UgdGhhdCBpcyB0aGUgb25seSBhdmFpbGFibGUgc29sdXRpb24gdG8gdGhl
IGNsaWVudCBpZiB0aGV5IHdhbnQgZGlmZmVyZW50IGRhbXBlbmluZyBwZXJpb2RzLiAgSS5lLiB0
aGUgY2xpZW50cyBjaG9pY2UgaXM6IGRvbid0IGhhdmUgc2VwYXJhdGUgZGFtcGVuaW5nIHBlcmlv
ZHMgb3IgY3JlYXRlIHNlcGFyYXRlIHN1YnNjcmlwdGlvbnMuICBCdXQgdGhpcyBpcyBhIG1pbm9y
IHBvaW50LCBub3Qgd29ydGggbGVuZ3RoeSBkaXNjdXNzaW9uLCBzbyB5b3UgY2FuIGRlY2lkZSB3
aGF0IHRvIGRvLg0KDQo8QUxFWC0yPk9LLCBrZWVwaW5nIGl0LjwvQUxFWC0yPg0KDQoNCg0KDQoN
Cg0KDQooMjEpIFNlY3Rpb24gMy40LCBzZWNvbmQgcGFyYWdyYXBoIGRvZXNuJ3QgcXVpdGUgc2Nh
bi4gICJUaGlzIGluY2x1ZGVzDQoNCiAgICBpbmRpY2F0aW5nIHRoZSBmYWN0IHRoYXQgYW4gdXBk
YXRlIGlzIGluY29tcGxldGUgYXMgcGFydCBvZiBhIHB1c2gtDQoNCiAgICB1cGRhdGUgcmVzcGVj
dGl2ZWx5IHB1c2gtY2hhbmdlLXVwZGF0ZSBub3RpZmljYXRpb24gLi4uIg0KDQoNCg0KDQoNCjxB
TEVYPiBJIHRoaW5rIGl0IGRvZXMgc2NhbiwgYnV0IHRvIG1ha2UgaXQganVzdCBzbGlnaHRseSBt
b3JlIGNsZWFyLCBob3cgYWJvdXQgdXBkYXRpbmcgdG8gIiBUaGlzIGluY2x1ZGVzIGluZGljYXRp
bmcgdGhlIGZhY3QgdGhhdCBhbiB1cGRhdGUgaXMgaW5jb21wbGV0ZSBhcyBwYXJ0IG9mIGEgcHVz
aC11cGRhdGUgKHJlc3BlY3RpdmVseSBwdXNoLWNoYW5nZS11cGRhdGUpIG5vdGlmaWNhdGlvbiwg
YXMgd2VsbCBhcyBlbWl0dGluZyBhIHN1YnNjcmlwdGlvbi1zdXNwZW5kZWQgbm90aWZpY2F0aW9u
IGFzIGFwcGxpY2FibGUuICINCg0KPC9BTEVYPg0KSXQgaXMgdGhlICJwdXNoLXVwZGF0ZSByZXNw
ZWN0aXZlbHkgcHVzaC1jaGFuZ2UtdXBkYXRlIiB0aGF0IGRvZXNuJ3QgbWFrZSBhbnkgc2Vuc2Ug
dG8gbWUuICBEbyB5b3UganVzdCBtZWFuICJvciIsIGUuZy4gInB1c2gtdXBkYXRlIG9yIHB1c2gt
Y2hhbmdlLXVwZGF0ZSI/DQoNCg0KDQo8QUxFWC0yPk9LLCBjaGFuZ2luZyBpdCB0byDigJxvcuKA
nSAoSSBndWVzcyBteSBuYXRpdmVuZXNzIHRvIHRoZSBHZXJtYW4gbGFuZ3VhZ2Ugc2hpbmVzIHRo
cm91Z2ggaGVyZSwgaW4gd2hpY2ggdGhlcmUgaXMgYSBmaW5lciBkaXN0aW5jdGlvbiBiZXR3ZWVu
IHR3byB0eXBlcyBvZiDigJxvcuKAnSwgb25lIG9mIHdoaWNoIGlzIHRoZSB0ZXJtIOKAnGJlemll
aHVuZ3N3ZWlzZeKAnSAod2hpY2ggd291bGQgYmUgdGhlIHByb3BlciBjaG9pY2UgaGVyZSDigJMg
eWVzLCBzb21lIHdvcmRzIGluIEdlcm1hbiBhcmUgbG9uZ2VyIHRoYW4gaW4gRW5nbGlzaCwgZXZl
biB0aGUgYWJicmV2aWF0aW9uIOKAnGJ6dy7igJ0gaXMgc3RpbGwgbG9uZ2VyIHRoYW4g4oCcb3Li
gJ07LSksIHdoaWNoIHRyYW5zbGF0ZXMgcm91Z2hseSBidXQgcGVyaGFwcyBub3QgZXhhY3RseSBp
bnRvIOKAnHJlcGVjdGl2ZWx54oCdLik8L0FMRVgtMj4NCg0KDQoNCigyMikgU2VjdGlvbiAzLjQs
IDNyZCBwYXJhZ3JhcGgsICJhYmxlIGZ1bGZpbGwiID0+ICJhYmxlIHRvIGZ1bGZpbGwiDQoNCg0K
DQoNCg0KPEFMRVg+IGNoYW5nZWQgPC9BTEVYPg0KDQoNCg0KKDIzKSBTZWN0aW9uIDMuNS4yLCAx
c3QgcGFyYWdyYXBoLCAibm90IHJlc3RyaWN0ZWQgdG8gY29uZmlndXJhdGlvbg0KDQpvYmplY3Rz
IG9ubHkiID0+ICJub3Qgb25seSByZXN0cmljdGVkIHRvIGNvbmZpZ3VyYXRpb24gb2JqZWN0cyIu
DQoNCg0KDQoNCg0KPEFMRVg+IGNoYW5naW5nIHRvICIgbm90IHJlc3RyaWN0ZWQgdG8gb25seSBj
b25maWd1cmF0aW9uIG9iamVjdHMiICAodGhlICJvbmx5IiByZWZlcnMgdG8gdGhlIGNvbmZpZ3Vy
YXRpb24gb2JqZWN0cywgbm90IHRvIHRoZSBmYWN0IHRoYXQgaXQgaXMgcmVzdHJpY3RlZCkgPC9B
TEVYPg0KWWVzLiwgT0suDQoNCg0KDQoNCg0KDQooMjQpIFNlY3Rpb24gMy41LjIsIDJuZCBwYXJh
Z3JhcGgsIHBvc3NpYmxlIGFsdGVybmF0aXZlIHRleHQ6DQoNCg0KDQpPTEQ6DQoNCg0KDQogICAg
QSBwdWJsaXNoZXIgd2lsbCBpbmRpY2F0ZSBhIGNoYW5nZSB0byB0aGUgZWZmZWN0IHRoYXQgYSB2
YWx1ZSBvZiBhDQoNCiAgICBkYXRhc3RvcmUgbm9kZSBoYXMgYmVlbiB1cGRhdGVkIGJ5IGluZGlj
YXRpbmcgYSAicmVwbGFjZSIgb3BlcmF0aW9uDQoNCiAgICAoYXBwbGllZCB0byB0aGUgZGF0YXN0
b3JlIG5vZGUpIGluIHRoZSBwYXRjaC4gIFdoZW4gYSBuZXcgZGF0YXN0b3JlDQoNCiAgICBub2Rl
IHdhcyBjcmVhdGVkIChvdGhlciB0aGFuIGFuIGVudHJ5IGluIGEgdXNlciBvcmRlcmVkIGxpc3Qp
LCBhDQoNCiAgICBwdWJsaXNoZXIgd2lsbCBpbmRpY2F0ZSBhICJjcmVhdGUiIG9wZXJhdGlvbiBp
biB0aGUgcGF0Y2guICBXaGVuIGENCg0KICAgIGRhdGFzdG9yZSBub2RlIHdhcyBkZWxldGVkLCB0
aGUgcHVibGlzaGVyIGluZGljYXRlcyB0aGlzIGJ5IGENCg0KICAgICJkZWxldGUiLiAgV2hlbiBh
IG5ldyBlbnRyeSBpbiBhIHVzZXItb3JkZXJlZCBsaXN0IHdhcyBjcmVhdGVkLCB0aGUNCg0KICAg
IHB1Ymxpc2hlciBpbmRpY2F0ZXMgdGhpcyBieSBhbiAiaW5zZXJ0IiBvcGVyYXRpb24uIFdoZW4g
YW4gZW50cnkgaW4NCg0KICAgIGEgdXNlci1vcmRlcmVkIGxpc3Qgd2FzIG1vdmVkLCB0aGUgcHVi
bGlzaGVyIGluZGljYXRlcyB0aGlzIGJ5IGENCg0KICAgICJtb3ZlIiBvcGVyYXRpb24uDQoNCg0K
DQpORVc6DQoNCg0KDQogICBBIHB1Ymxpc2hlciBpbmRpY2F0ZXMgdGhlIHR5cGUgb2YgY2hhbmdl
IHRvIGEgZGF0YXN0b3JlIG5vZGUgdXNpbmcNCg0KdGhlIGRpZmZlcmVudCBZQU5HIHBhdGNoIG9w
ZXJhdGlvbnM6ICB0aGUgImNyZWF0ZSIgb3BlcmF0aW9uIGlzIHVzZWQgZm9yDQoNCm5ld2x5IGNy
ZWF0ZWQgb2JqZWN0cyAoZXhjZXB0IGVudHJpZXMgaW4gYSB1c2VyLW9yZGVyZWQgbGlzdCksIHRo
ZQ0KDQoiZGVsZXRlIiBvcGVyYXRpb24gaXMgdXNlZCBmb3IgZGVsZXRlZCBvYmplY3RzIChpbmNs
dWRpbmcgaW4NCg0KdXNlci1vcmRlcmVkIGxpc3RzKSwgdGhlICJyZXBsYWNlIiBvcGVyYXRpb24g
aXMgdXNlZCB3aGVuIG9ubHkgdGhlDQoNCm9iamVjdCB2YWx1ZSBjaGFuZ2VzLCB0aGUgImluc2Vy
dCIgb3BlcmF0aW9uIGlzIHVzZWQgd2hlbiBhIG5ldyBlbnRyeSBpcw0KDQppbnNlcnRlZCBpbiBh
IGxpc3QsIGFuZCB0aGUgIm1vdmUiIG9wZXJhdGlvbiBpcyB1c2VkIHdoZW4gYW4gZXhpc3RpbmcN
Cg0KZW50cnkgaW4gYSB1c2VyLW9yZGVyZWQgbGlzdCBpcyBtb3ZlZC4NCg0KDQoNCg0KDQo8QUxF
WD4gT0sgKEkgZG9uJ3QgZmVlbCBzdHJvbmdseSBhYm91dCB0aGlzKSA8L0FMRVg+DQoNCg0KDQoN
Cg0KKDI1KSBTZWN0aW9uIDMuNS4yLCBsYXN0IHBhcmFncmFwaDogSWYgeW91IHdhbnQgdG8gYWxs
b3cgZHVwbGljYXRlDQoNCiJjcmVhdGUiIGFuZCAiZGVsZXRlIiBldmVudHMsIHRoZW4gaXQgbWln
aHQgYmUgY2xlYW5lciB0byBlbmNvZGUgdGhlbSBhcw0KDQoibWVyZ2UiIGFuZCAicmVtb3ZlIj8g
IEkuZS4gaXQgc2VlbXMgdGhhdCB5b3UgaGF2ZSBjcmVhdGVkIGEgc2xpZ2h0bHkNCg0KZGlmZmVy
ZW50IGVuY29kaW5nIGZyb20gdmFuaWxsYSBZQU5HIHBhdGNoIGJlY2F1c2Ugb2YgdGhlIHdheSB0
aGF0DQoNCmVycm9ycyBhcmUgaGFuZGxlZCBkaWZmZXJlbnRseS4gIElkZWFsbHksIGl0IHdvdWxk
IGJlIGJldHRlciBpZiBhIGNsaWVudA0KDQpjb3VsZCBqdXN0IGFwcGx5IHRoaXMgYXMgcmVndWxh
ciBZQU5HIHBhdGNoLCBidXQgdGhpcyBvbmx5IHdvcmtzIHdpdGgNCg0KdGhlIGVuY29kaW5nIGRl
c2NyaWJlZCBoZXJlIGlmIHRoZSBjbGllbnRzIGNvcHkgb2YgdGhlIGRhdGFzdG9yZSBpcyBpbg0K
DQpzeW5jIHdpdGggdGhlIHNlcnZlcnMgb2xkIGNvcHkgb2YgdGhlIGRhdGFzdG9yZSBhdCB0aGUg
cG9pbnQgdGhhdCB0aGUNCg0KcGF0Y2ggaXMgZ2VuZXJhdGVkIGZyb20uICBUaGlzIHNlZW1zIHNs
aWdodGx5IGZyYWdpbGUgdG8gdW5leHBlY3RlZA0KDQppbmNvbnNpc3RlbmNpZXMgYmV0d2VlbiBj
bGllbnQgYW5kIHNlcnZlciAod2hpY2ggSSBhcHByZWNpYXRlIHRoYXQgeW91DQoNCnRyeSBhbmQg
YXZvaWQpLg0KDQoNCg0KDQoNCjxBTEVYPiBIbW0uICBXaGlsZSBpdCBtYXkgYmUgcG9zc2libGUg
dG8gcmVwbGFjZSAiZGVsZXRlIiB3aXRoICJyZW1vdmUiLCBJIGFtIG5vdCBzbyBzdXJlIGFib3V0
IHRoZSAibWVyZ2UiIHBhcnQuICBBdCB0aGUgZW5kIG9mIHRoZSBkYXksIHRoZSB1c2UgaGVyZSBp
cyBkaWZmZXJlbnQgZnJvbSBoYXZpbmcgYSBjbGllbnQgYXBwbHkgYSBwYXRjaCBvcGVyYXRpb24g
dG8gdGhlIHNlcnZlciwgYW5kIHRoZSBzZW1hbnRpY3MgbWF5IGJlIGEgbGl0dGxlIGNsZWFyZXIg
Ynkga2VlcGluZyB0aGluZ3MgYXMgdGhleSBhcmUsIHNvIHdvdWxkIHByZWZlciB0byBrZWVwIHRo
aW5ncyBhcyBkZWZpbmVkIG5vdy4NCg0KPC9BTEVYPg0KSSB0aGluayB0aGF0IGlzIHByb2JhYmx5
IHJpZ2h0Lg0KDQpJIHRoaW5rIHRoYXQgaXQgaXMgYSBzbGlnaHQgc2hhbWUgdGhhdCB2YW5pbGxh
IFlBTkcgcGF0Y2ggd29uJ3Qgd29yayBoZXJlLCBidXQgYXMgeW91IHNheSBJIHRoaW5rIHRoYXQg
aXQgd2lsbCBuZWVkIHRvIGJlIGFwcGxpZWQgaW4gYSBzbGlnaHRseSBkaWZmZXJlbnQgd2F5IHJl
Z2FyZGxlc3MuDQoNCjxBTEVYLTI+T0suIEtlZXBpbmcgaXQuPC9BTEVYLTI+DQoNCg0KDQoNCg0K
KDI2KSBTZWN0aW9uIDMuNiwgc2Vjb25kIHBhcmFncmFwaCwgd291bGQgaXQgbm90IGJlIGVhc2ll
ciB0byBhbGxvdyB0aGUNCg0KY2xpZW50IHRvIHJlcGxhY2UgYW4gZXhpc3RpbmcgZmlsdGVyIHJh
dGhlciB0aGFuIGhhdmluZyB0byBleHBsaWNpdGx5DQoNCnJlbW92ZSB0aGUgb2xkIGZpbHRlciBh
bmQgYWRkIHRoZSBuZXcgb25lPyAgT3IgaWYgeW91IG1lYW4gdGhhdCBhbnkgbmV3DQoNCmZpbHRl
ciByZXBsYWNlcyB0aGUgZXhpc3RpbmcgZmlsdGVyLCB0aGVuIHRoaXMgbWF5IGJlIG1vcmUgY2xl
YXJseQ0KDQppbmRpY2F0ZWQgd2l0aCB0aGUgdGV4dDogIkFuIFJQQyByZXF1ZXN0IHByb3Bvc2lu
ZyBhIG5ldyBzZWxlY3Rpb24NCg0KZmlsdGVyIHJlcGxhY2VzIGFueSBleGlzdGluZyBmaWx0ZXIu
ICINCg0KDQoNCg0KDQo8QUxFWD4gT0ssIGNoYW5naW5nIHBlciB5b3VyIHN1Z2dlc3Rpb24gdG8g
bWFrZSBpdCBjbGVhciB0aGF0IHRoZSBleGlzdGluZyBmaWx0ZXIgaXMgcmVwbGFjZWQuICA8L0FM
RVg+DQoNCg0KDQooMjcpIFNlY3Rpb24gMy42LCBwYXJhZ3JhcGggNiwgc3RhcnRpbmcgIlhQYXRo
Ii4gIFRoZSAiYm9vbGVhbiIgZXhhbXBsZQ0KDQppcyB1bmNsZWFyIHRvIG1lIGdpdmVuIHRoYXQg
YSB4cGF0aCBmaWx0ZXIgYWx3YXlzIHJldHVybnMgYSBub2RlIHNldCBzbw0KDQpjYW4ndCByZXR1
cm4gYSBib29sZWFuIHJlc3VsdC4gIEkgYWxzbyBzdWdnZXN0IGNoYW5naW5nICJwYXNzZXMgYQ0K
DQpkYXRhc3RvcmUgbm9kZSIgdG8gICJpbmNsdWRlcyBhIGRhdGFzdG9yZSBub2RlIi4NCg0KDQoN
CjxBTEVYPiByZW1vdmVkIHRoZSBzZW50ZW5jZSBhbmQgc2hvcnRlbmVkIHRoZSBwYXJhZ3JhcGgu
ICBJdCBub3cgcmVhZHMgYXMgZm9sbG93czoNCg0KIiBYUGF0aCBpdHNlbGYgcHJvdmlkZXMgcG93
ZXJmdWwgZmlsdGVyaW5nIGNvbnN0cnVjdHMgYW5kIGNhcmUgbXVzdCBiZSB1c2VkIGluIGZpbHRl
ciBkZWZpbml0aW9uLiBDb25zaWRlciBhbiBYUGF0aCBmaWx0ZXIgd2hpY2ggb25seSBwYXNzZXMg
YSBkYXRhc3RvcmUgbm9kZSB3aGVuIGFuIGludGVyZmFjZSBpcyB1cC4gSXQgaXMgdXAgdG8gdGhl
IHJlY2VpdmVyIHRvIHVuZGVyc3RhbmQgaW1wbGljYXRpb25zIG9mIHRoZSBwcmVzZW5jZSBvciBh
YnNlbmNlIG9mIG9iamVjdHMgaW4gZWFjaCB1cGRhdGUuICINCg0KPC9BTEVYPg0KT0suDQoNCg0K
DQoNCg0KDQoNCg0KKDI4KSBTZWN0aW9uIDMuNiwgcGFyYWdyYXBoIDcuICBJIHRoaW5rIHRoYXQg
dGhlIHRleHQgbXVzdCBiZSBtb3JlDQoNCmV4cGxpY2l0IG9uIHdoZW4gdGhlIGZpbHRlciBpcyBl
dmFsdWF0ZWQgZm9yIGEgcGVyaW9kaWMgc3Vic2NyaXB0aW9uLg0KDQpBbSBJIHJpZ2h0IGluIHRo
aW5raW5nIHRoYXQgaXQgaXMgb25seSBldmFsdWF0ZWQgb25jZSB3aGVuIHRoZQ0KDQpzdWJzY3Jp
cHRpb24gaXMgY3JlYXRlZCwgb3IgdGhlIHN1YnNjcmlwdGlvbiBpcyBjaGFuZ2VkPyBTcGVjaWZp
Y2FsbHksDQoNCmlmIHRoZSBub2Rlc2V0IGV2YWx1YXRlZCBkdXJpbmcgdGhlIGxpZmV0aW1lIG9m
IGFuIFhwYXRoIHN1YnNjcmlwdGlvbg0KDQpjaGFuZ2VzIHRoZW4gZG9lcyB0aGF0IGFmZmVjdCB3
aGljaCBub2RlcyBhcmUgcmV0dXJuZWQ/DQoNCg0KDQoNCg0KPEFMRVg+IE5vdCBzdXJlIHdoYXQg
Y2hhbmdlcyB5b3UgYXJlIGxvb2tpbmcgZm9yLiAgVGhlIGZpbHRlciBpcyBpbiBlZmZlY3QgdGhy
b3VnaG91dCB0aGUgc3Vic2NyaXB0aW9uIHVudGlsIGl0IGlzIGNoYW5nZWQuICBJdCBpcyB1cCB0
byBhbiBpbXBsZW1lbnRhdGlvbiB0byBkZWNpZGUgd2hldGhlciB0byBhcHBseSBpdCBvbmNlIHdo
ZW4gdGhlIHN1YnNjcmlwdGlvbiBpcyBlc3RhYmxpc2hlZCB0byBkZXRlcm1pbmUgdGhlIGRhdGFz
dG9yZSBub2RlcyAodHJhY2tpbmcgYW55IHN1YnRyZWUgY2hhbmdlcyB0byBtYWtlIHN1cmUgbm9k
ZXMgaW4gdGhlIHN1YnRyZWVzIGFyZSBpbmNsdWRlZCBhcyBuZWVkZWQpLCBvciB3aGV0aGVyIHRv
IGFwcGx5IGl0IGF0IGVhY2ggdXBkYXRlIGFuZXcuDQoNCkFzIGZhciBhcyByZWNlaXZlciBhdXRo
b3JpemF0aW9uIGlzIGNvbmNlcm5lZCAoaS5lLiBhY2Nlc3MgY29udHJvbCBmaWx0ZXJzKSwgdGhp
cyBpcyBleHBsYWluZWQgaW4gc2VjdGlvbiAzLjkuICBBcHBseWluZyBubyB0ZXh0IGNoYW5nZXMg
YXQgdGhpcyBwb2ludCB1bmxlc3MgeW91IGNhbiBiZSBtb3JlIGNsZWFyIG9uIHdoYXQgeW91IHdv
dWxkIGxpa2UgdG8gc2VlPw0KDQo8L0FMRVg+DQpPSy4gIE5vdCBjb25zaWRlcmluZyBOQUNNLCBJ
IHRoaW5rIHRoYXQgaXMgYWxyZWFkeSBjb3ZlcmVkLCB3YXMgdGhpbmtpbmcgb2YgYW4gWHBhdGgg
ZmlsdGVyLiAgSSBhbSByaWdodCBpbiB0aGlua2luZyB0aGF0IGxvZ2ljYWxseSB0aGUgWHBhdGgg
ZmlsdGVyIGlzIFtyZS1dYXBwbGllZCB3aGVuZXZlciB0aGUgcGVyaW9kaWMgcHVzaCBub3RpZmlj
YXRpb24gaXMgY29uc3RydWN0ZWQuDQoNCklmIHNvLCBwb3NzaWJseSBjaGFuZ2U6DQoNCiIgICBX
aGVuIHRoZSBzZXQgb2Ygc2VsZWN0aW9uIGZpbHRlcmluZyBjcml0ZXJpYSBpcyBhcHBsaWVkIGZv
ciBhDQogICBwZXJpb2RpYyBzdWJzY3JpcHRpb24sIGFsbCBzZWxlY3RlZCBkYXRhc3RvcmUgbm9k
ZXMgdG8gd2hpY2ggYQ0KICAgcmVjZWl2ZXIgaGFzIGFjY2VzcyBhcmUgcHJvdmlkZWQgdG8gdGhh
dCByZWNlaXZlci4iDQoNClRvIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YgLi4uDQoNCiIg
ICBXaGVuIHRoZSBzZXQgb2Ygc2VsZWN0aW9uIGZpbHRlcmluZyBjcml0ZXJpYSBpcyBhcHBsaWVk
IGZvciBhDQogIHBlcmlvZGljIHN1YnNjcmlwdGlvbiwgdGhlbiB0aGV5IGFyZSBhcHBsaWVkIHdo
ZW5ldmVyIGEgcGVyaW9kaWMNCiAgdXBkYXRlIHJlY29yZCBpcyBjb25zdHJ1Y3RlZCwgYW5kIG9u
bHkgZGF0YXN0b3JlIG5vZGVzIHRoYXQgcGFzcw0KICB0aGUgZmlsdGVyIGFuZCB0byB3aGljaCBh
IHJlY2VpdmVyIGhhcyBhY2Nlc3MgYXJlIHByb3ZpZGVkIHRvDQogIHRoYXQgcmVjZWl2ZXIuIg0K
DQoNCjxBTEVYLTI+T0ssIEkgYW0gbWFraW5nIHRoZSBjaGFuZ2UgYXMgc3VnZ2VzdGVkLiAgKEhv
d2V2ZXIsIHByZXN1bWFibHkgYW4gaW1wbGVtZW50YXRpb24gY291bGQgY2hvb3NlIHRvIGFwcGx5
IHRoZSBmaWx0ZXIgdG8gc2VsZWN0IHRoZSBzZXQgb2YgZGF0YXN0b3JlIG5vZGVzIG9uY2UsIGFu
ZCB0aGVuLCBhc3N1bWluZyB0aGUgZmlsdGVyIGFuZCBzZXQgb2YgZGF0YXN0b3JlIG5vZGVzIGRv
buKAmXQgY2hhbmdlLCBzaW1wbHkgc2VuZCB1cGRhdGVzIGFib3V0IHRoZSBub2RlcyBmb3JtIHRo
ZSBzZXQsIG5vPykgPC9BTEVYLTI+DQoNCg0KDQoNCg0KDQoNCigyOSkgU2VjdGlvbiAzLjcsIHBh
cmFncmFwaCAzOiAgUGVyaGFwcyBtYWtlIHRoaXMgdGV4dCBjb25kaXRpb25hbCB0bw0KDQpkYW1w
ZW5lZCBzdWJzY3JpcHRpb25zLiAgUHJlc3VtYWJseSBmb3Igbm9uIGRhbXBlbmVkIHN1YnNjcmlw
dGlvbnMgYWxsDQoNCmNoYW5nZXMgYXJlIHJlcG9ydGVkIGFzIHNlcGFyYXRlIHB1c2gtY2hhbmdl
LXVwZGF0ZSBub3RpZmljYXRpb25zPw0KDQoNCg0KT0xEOg0KDQpJbiBjYXNlcyB3aGVyZSBtdWx0
aXBsZSBjaGFuZ2VzIGhhdmUgb2NjdXJyZWQgYW5kIHRoZSBvYmplY3QNCg0KICAgIGhhcyBub3Qg
YmVlbiBkZWxldGVkLCB0aGUgb2JqZWN0J3MgbW9zdCBjdXJyZW50IHZhbHVlIGlzIHJlcG9ydGVk
Lg0KDQoNCg0KTkVXOg0KDQpJbiBjYXNlcyB3aGVyZSBtdWx0aXBsZSBjaGFuZ2VzIGhhdmUgb2Nj
dXJyZWQgaW4gYSBzdWJzY3JpcHRpb24gdGhhdCBoYXMNCg0KZGFtcGVuaW5nIGVuYWJsZWQsIGFu
ZCB0aGUgb2JqZWN0DQoNCiAgICBoYXMgbm90IGJlZW4gZGVsZXRlZCwgdGhlIG9iamVjdCdzIG1v
c3QgY3VycmVudCB2YWx1ZSBpcyByZXBvcnRlZC4NCg0KDQoNCg0KDQo8QUxFWD4gV2VsbCwgdGhl
IHRleHQgc3RhdGVzIGNsZWFybHkgdGhhdCB0aGlzIGNvbmNlcm5zIGFueSBjaGFuZ2VzIHNpbmNl
IHRoZSBsYXN0IG5vdGlmaWNhdGlvbiBtZXNzYWdlLiAgU28sIHRoZSBmYWN0IHRoYXQgZGFtcGVu
aW5nIGlzIGVuYWJsZWQgaXMgYWxyZWFkeSBpbXBsaWVkLg0KDQpIb3cgYWJvdXQgcmVwaHJhc2lu
ZyBzbGlnaHRseSBhcyBmb2xsb3dzOg0KDQoiIEluIGNhc2VzIHdoZXJlIG11bHRpcGxlIGNoYW5n
ZXMgaGF2ZSBvY2N1cnJlZCBvdmVyIHRoZSBjb3Vyc2Ugb2YgYSBkYW1wZW5pbmcgcGVyaW9kIGFu
ZCB0aGUgb2JqZWN0IGhhcyBub3QgYmVlbiBkZWxldGVkLCB0aGUgb2JqZWN0J3MgbW9zdCBjdXJy
ZW50IHZhbHVlIGlzIHJlcG9ydGVkLiAgIg0KDQo8L0FMRVg+DQpUaGlzIHRleHQgaXMgZmluZS4N
Cg0KQnV0IHRoaXMgcmFpc2VzIGFub3RoZXIgcXVlc3Rpb246DQoNCklmIG5vIGRhbXBlbmluZyBp
cyBlbmFibGVkLCB0aGVuIGlzIGl0IGV4cGVjdGVkIHRoYXQgYWxsIGNoYW5nZXMgdG8gYW4gb2Jq
ZWN0IGFyZSBhbHdheXMgbm90aWZpZWQuICBbSWYgdGhpcyBpcyBhIHJlcXVpcmVtZW50LCB0aGVu
IEkgdGhpbmsgdGhhdCBpdCBzaG91bGQgcHJvYmFibHkgYmUgc3RhdGVkIGNsZWFybHkgaW4gdGhl
IFlBTkcgbW9kZWwgYW5kIHBlcmhhcHMgaW4gc2VjdGlvbiAzIGFzIHdlbGwuXQ0KDQpTcGVjaWZp
Y2FsbHksIHNheSB5b3UgYXJlIG1vbml0b3JpbmcgaW50ZXJmYWNlIHN0YXRlLCB3aXRob3V0IGRh
bXBlbmluZywgYW5kIGl0IHN0YXJ0cyB0byBmbGFwIDEwMCB0aW1lcyBwZXIgc2Vjb25kLiAgSXMg
dGhlIHB1Ymxpc2hlciByZXF1aXJlZCB0byBub3RpZnkgb2YgZXZlcnkgc2luZ2xlIGNoYW5nZS4g
IE9yIGlzIHRoZSBwdWJsaXNoZXIgb25seSByZXF1aXJlZCB0byBub3RpZnkgdGhhdCB0aGUgYXQg
bGVhc3Qgb25lIGNoYW5nZSBoYXMgb2NjdXJyZWQsIGFuZCBndWFyYW50ZWUgdGhhdCBpdCBhbHdh
eXMgbm90aWZpZXMgdGhlIGxhdGVzdCB2YWx1ZS4NCg0KPEFMRVgtMj4gVGhpcyBpcyBleGFjdGx5
IHRoZSByZWFzb24gd2h5IGRhbXBlbmluZyB3YXMgaW50cm9kdWNlZC4gIEkgdGhpbmsgdGhpcyBp
cyB3ZWxsIGRvY3VtZW50ZWQuICBJZiBhIHN1YnNjcmliZXIgZG9lcyBub3QgdHVybiBvbiBkYW1w
ZW5pbmcsIGFuZCB0aHVzIHRoZSBzZXJ2ZXIgZ2V0cyBvdmVyd2hlbG1lZCwgdGhleSBjYW4gc3Vz
cGVuZCBvciB0ZXJtaW5hdGUgdGhlIHN1YnNjcmlwdGlvbi4gIEluIHRoYXQgY2FzZSB0aGV5IHNo
b3VsZCBnaXZlIGEg4oCccGVyaW9kLXVuc3VwcG9ydGVk4oCdIGVycm9yLg0KVGhpbmtpbmcgYWJv
dXQgaXQgc29tZSBtb3JlLCB0aGlzIG5lZWRzIHRvIGJlIG1vcmUgY2xlYXJseSBzcGVsbGVkIG91
dCBpbiB0aGUgZGVzY3JpcHRpb24gb2Yg4oCccGVyaW9kLXVuc3VwcG9ydGVk4oCdLg0KDQpDaGFu
Z2luZyB0aGUgWUFORyBkZWZpbml0aW9uIChkZXNjcmlwdGlubyBzdGF0ZW1lbnQpIGFzIGZvbGxv
d3M6DQogIGlkZW50aXR5IHBlcmlvZC11bnN1cHBvcnRlZCB7DQogICAgYmFzZSBzbjplc3RhYmxp
c2gtc3Vic2NyaXB0aW9uLWVycm9yOw0KICAgIGJhc2Ugc246bW9kaWZ5LXN1YnNjcmlwdGlvbi1l
cnJvcjsNCiAgICBiYXNlIHNuOnN1YnNjcmlwdGlvbi1zdXNwZW5kZWQtcmVhc29uOw0KICAgIGRl
c2NyaXB0aW9uDQogICAgICAiUmVxdWVzdGVkIHRpbWUgcGVyaW9kIG9yIGRhbXBlbmluZy1wZXJp
b2QgaXMgdG9vIHNob3J0LiBUaGlzDQogICAgICBjYW4gYmUgZm9yIGJvdGggcGVyaW9kaWMgYW5k
IG9uLWNoYW5nZSBzdWJzY3JpcHRpb25zICh3aXRoIG9yDQogICAgICB3aXRob3V0IGRhbXBlbmlu
Zy4pIEhpbnRzIHN1Z2dlc3RpbmcgYWx0ZXJuYXRpdmUgcGVyaW9kcyBtYXkNCiAgICAgIGJlIHJl
dHVybmVkIGFzIHN1cHBsZW1lbnRhbCBpbmZvcm1hdGlvbi4iOw0KICB9DQo8L0FMRVgtMj4NCg0K
DQoNCg0KDQoNCg0KDQooMzApIFNlY3Rpb24gMy43LCBwYXJhZ3JhcGggNSwgIkV0aGVybmV0IHBv
cnQiID0+ICJFdGhlcm5ldCBpbnRlcmZhY2UiDQoNCg0KDQoNCg0KPEFMRVg+IGNoYW5nZWQgPC9B
TEVYPg0KDQoNCg0KKDMxKSBTZWN0aW9uIDMuNywgbGFzdCBwYXJhZ3JhcGg6IFdoeSBzdGFydCBh
dCAiMSIgcmF0aGVyIHRoYW4gIjAiLiBPbg0KDQpvdmVyZmxvdywgd2h5IG92ZXJmbG93IHRvICIx
IiByYXRoZXIgdGhhbiAiMCIsIGlzIHRoYXQgZGVsaWJlcmF0ZT8gIElmDQoNCnlvdSBhcmUgZ29p
bmcgdG8gZm9yY2UgaXQgdG8gIjEiIHRoZW4gSSB3b3VsZCBhbHNvIHJlc3RyaWN0IHRoZSB1cHBl
cg0KDQpib3VuZCB0byBpbnQzMiBtYXggcmF0aGVyIHRoYW4gdWludDMyIG1heCB0byBtYWtlIGxp
ZmUgZWFzaWVyIGluIEphdmENCg0KbGFuZCAuLi4NCg0KDQoNCjxBTEVYPiBPSywgZ290IGl0LiAg
VXBkYXRlZCB0aGUgdGV4dCB0byByZWZsZWN0IHN0YXJ0IGF0IDAuDQoNCjwvQUxFWD4NCg0KDQoN
Cg0KDQooMzIpIFNlY3Rpb24gMy44LCB0cmVlIGRpYWdyYW1zLiAgSSB3b3VsZCB0aGluayB0aGF0
IGFub3RoZXIga2V5IG1ldHJpYw0KDQpyZWdhcmRpbmcgd2hldGhlciBhIHN1YnNjcmlwdGlvbiBj
YW4gYmUgc2F0aXNmaWVkIHdvdWxkIGJlIG9iamVjdC1yYXRlDQoNCmFuZCBkYXRhLXJhdGUuICBF
LmcuIGEgcHVibGlzaGVyIGltcGxlbWVudGF0aW9uIG1heSBiZSBhYmxlIHRvIHB1c2ggMTAwaw0K
DQpvYmplY3RzL3NlY29uZCwgc28gYSBjbGllbnQgaGFzIGEgY2hvaWNlIG9mIGVpdGhlciBtb25p
dG9yaW5nIGxlc3MNCg0Kb2JqZWN0cywgb3IgZGVjcmVhc2luZyB0aGUgcGVyaW9kLiAgSGVuY2Ug
SSB3YXMgd29uZGVyaW5nIHdoZXRoZXIgcmF0ZXMNCg0Kc2hvdWxkIGJlIHByb3ZpZGVkIGluIGFk
ZGl0aW9uIHRvIHRoZSBvYmplY3QtY291bnQtZXN0aW1hdGUvbGltaXQgYW5kDQoNCmtpbG9ieXRl
LWVzdGltYXRlL2xpbWl0LiAgT2YgY291cnNlLCBhIHJhdGUgaXMgYWxzbyBpbXBsaWNpdGx5IGRl
ZmluZWQNCg0KYnkgaW5jbHVkaW5nIHRoZSBwZXJpb2QgaGludCwgc28gcGVyaGFwcyB0aGF0IGlz
IHN1ZmZpY2llbnQgd2l0aG91dA0KDQpuZWVkaW5nIHRvIHNlbmQgbW9yZSBmaWVsZHMgYmFjayB0
byB0aGUgY2xpZW50Lg0KDQoNCg0KDQoNCjxBTEVYPiBXb3VsZCBwcmVmZXIgdG8ga2VlcCB0aGlz
IHRvIHRoZSBiYXNpY3MsIGkuZS4gYXMtaXMuICBBcyBtZW50aW9uZWQsIHlvdSBjYW4gY29tcHV0
ZSBhIHJhdGUgZnJvbSB0aGlzLiAgPC9BTEVYPg0KWWVzLCB0aGF0IGlzIGZpbmUuICBBZGRpdGlv
bmFsIGZpZWxkcyBjb3VsZCBiZSBhdWdtZW50ZWQgaW4gZnV0dXJlIGlmIG5lZWRlZC4NCg0KDQoN
Cg0KDQoNCg0KKDMzKSBTZWN0aW9uIDMuOSwgMm5kIHBhcmFncmFwaCwgInBhcnRpY3VsYXIgZWFj
aCIgPT4gInBhcnRpY3VsYXIiDQoNCg0KDQo8QUxFWD4gY2hhbmdlZCA8L0FMRVg+DQoNCg0KDQoN
Cg0KKDM0KSBTZWN0aW9uIDMuOSwgM3JkIHBhcmFncmFwaDogIEl0IHdhcyBub3QgZW50aXJlbHkg
b2J2aW91cyB0byBtZSB3aGF0DQoNCnRoZSAzcmQgcGFyYWdyYXBoIHRleHQgKHJlcHJvZHVjZWQg
YmVsb3cpIGFjdHVhbGx5IG1lYW5zLiAgSSB0aGluayB0aGF0DQoNCnRoaXMgYm9pbHMgZG93biB0
bzogIElmLCBhZnRlciBhY2Nlc3MgY29udHJvbCBoYXMgYmVlbiBhcHBsaWVkLCB0aGVyZQ0KDQph
cmUgbm8gb2JqZWN0cyByZW1haW5pbmcgaW4gYW4gdXBkYXRlIHJlY29yZCB0aGVuIG9ubHkgYSBz
aW5nbGUgZW1wdHkNCg0KInB1c2gtdXBkYXRlIiBub3RpZmljYXRpb24gTUFZIGJlIHNlbnQgYW5k
IGVtcHR5ICJwdXNoLWNoYW5nZS11cGRhdGUiDQoNCm1lc3NhZ2VzIE1VU1QgTk9UIGJlIHNlbnQu
ICBUaGlzIGlzIHJlcXVpcmVkIHRvIGVuc3VyZSB0aGF0IGNsaWVudHMNCg0KY2Fubm90IHN1cnJl
cHRpdGlvdXNseSBtb25pdG9yIG9iamVjdHMgdGhhdCB0aGV5IGRvIG5vdCBoYXZlIGFjY2VzcyB0
bw0KDQp2aWEgY2FyZWZ1bGx5IGNyYWZ0ZWQgc2VsZWN0aW9uIGZpbHRlcnMuDQoNCg0KDQoiQSBw
dWJsaXNoZXIgTVVTVCBhbGxvdyBmb3IgdGhlIHBvc3NpYmlsaXR5IHRoYXQgYSBzdWJzY3JpcHRp
b24ncw0KDQogICAgc2VsZWN0aW9uIGZpbHRlciByZWZlcmVuY2VzIG5vbi1leGlzdGVudCBvciBh
Y2Nlc3MtcHJvdGVjdGVkIGRhdGEuDQoNCiAgICBTdWNoIHN1cHBvcnQgcGVybWl0cyBhIHJlY2Vp
dmVyIHRoZSBhYmlsaXR5IHRvIG1vbml0b3IgdGhlIGVudGlyZQ0KDQogICAgbGlmZWN5bGUgb2Yg
c29tZSBkYXRhc3RvcmUgdHJlZS4gIEluIHRoaXMgY2FzZSwgYWxsICJwdXNoLXVwZGF0ZSINCg0K
ICAgIG5vdGlmaWNhdGlvbnMgbXVzdCBiZSBzZW50IGVtcHR5LCBhbmQgbm8gInB1c2gtY2hhbmdl
LXVwZGF0ZSINCg0KICAgIG5vdGlmaWNhdGlvbnMgd2lsbCBiZSBzZW50IHVudGlsIHNvbWUgZGF0
YSBiZWNvbWVzIHZpc2libGUgZm9yIGENCg0KICAgIHJlY2VpdmVyLiINCg0KDQoNCg0KDQo8QUxF
WD4gTW9kaWZpZWQgdGhlIHBhcmFncmFwaCBhbHJlYWR5IGR1ZSB0byBhbm90aGVyIGNvbW1lbnQg
aW4gYW5vdGhlciB0aHJlYWQuICBVcGRhdGVkIHRoaXMgZnVydGhlciBwZXIgeW91ciBjb21tZW50
cy4gIE5vdyBpdCByZWFkcyBhcyBmb2xsb3dzOg0KDQoiIEEgcHVibGlzaGVyIE1VU1QgYWxsb3cg
Zm9yIHRoZSBwb3NzaWJpbGl0eSB0aGF0IGEgc3Vic2NyaXB0aW9uJ3Mgc2VsZWN0aW9uIGZpbHRl
ciByZWZlcmVuY2VzIG5vbi1leGlzdGVudCBkYXRhIG9yIGRhdGEgdGhhdCBhIHJlY2VpdmVyIGlz
IG5vdCBhbGxvd2VkIHRvIGFjY2Vzcy4gIFN1Y2ggc3VwcG9ydCBwZXJtaXRzIGEgcmVjZWl2ZXIg
dGhlIGFiaWxpdHkgdG8gbW9uaXRvciB0aGUgZW50aXJlIGxpZmVjeWxlIG9mIHNvbWUgZGF0YXN0
b3JlIHRyZWUgd2l0aG91dCBuZWVkaW5nIHRvIGV4cGxpY2l0bHkgZW51bWVyYXRlIGV2ZXJ5IGlu
ZGl2aWR1YWwgZGF0YXN0b3JlIG5vZGUuICBJZiwgYWZ0ZXIgYWNjZXNzIGNvbnRyb2wgaGFzIGJl
ZW4gYXBwbGllZCwgdGhlcmUgYXJlIG5vIG9iamVjdHMgcmVtYWluaW5nIGluIGFuIHVwZGF0ZSBy
ZWNvcmQsIHRoZW4gKGluIGNhc2Ugb2YgYSBwZXJpb2RpYyBzdWJzY3JpcHRpb24pIG9ubHkgYSBz
aW5nbGUgZW1wdHkgInB1c2gtdXBkYXRlIiBub3RpZmljYXRpb24gTUFZIGJlIHNlbnQuIEVtcHR5
ICJwdXNoLWNoYW5nZS11cGRhdGUiIG1lc3NhZ2VzIChpbiBjYXNlIG9mIGFuIG9uLWNoYW5nZSBz
dWJzY3JpcHRpb24pIE1VU1QgTk9UIGJlIHNlbnQuICBUaGlzIGlzIHJlcXVpcmVkIHRvIGVuc3Vy
ZSB0aGF0IGNsaWVudHMgY2Fubm90IHN1cnJlcHRpdGlvdXNseSBtb25pdG9yIG9iamVjdHMgdGhh
dCB0aGV5IGRvIG5vdCBoYXZlIGFjY2VzcyB0byB2aWEgY2FyZWZ1bGx5IGNyYWZ0ZWQgc2VsZWN0
aW9uIGZpbHRlcnMuIg0KDQoNCg0KQWxzbyBhZGRpbmcgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSwg
dG8gY2xhcmlmeSB0aGUgZWZmZWN0IG9uIGRhbXBlbmluZzogIiBCeSB0aGUgc2FtZSB0b2tlbiwg
Y2hhbmdlcyB0byBvYmplY3RzIHRoYXQgYXJlIGZpbHRlcmVkIE1VU1QgTk9UIGFmZmVjdCBhbnkg
ZGFtcGVuaW5nIGludGVydmFscy4iDQoNCjwvQUxFWD4NClRleHQgbG9va3MgZ29vZC4gIE15IG9u
bHkgcXVlc3Rpb24gaXMgb24gdGhlIHNlbnRlbmNlIHdpdGggdGhlIE1BWS4gSSd2ZSBiZWVuIHRv
bGQgYnkgc29tZSBvbGQgaGFuZHMgdGhhdCBldmVyeXdoZXJlIHlvdSBzZWUgIk1BWSIgaW4gYW4g
UkZDIHRoZW4gaXQgaXMgZW50aXJlbHkgdmFsaWQgdG8gYWxzbyBpbnRlcnByZXQgdGhhdCBhcyAi
TUFZIE5PVCIuDQoNCkkgdGhpbmsgdGhhdCBpdCBzaG91bGQgcGVyaGFwcyBiZToNCg0KIi4uLiB0
aGVuIChpbiBjYXNlIG9mIGEgcGVyaW9kaWMgc3Vic2NyaXB0aW9uKSB0aGUgcHVibGlzaGVyIE1V
U1Qgb25seSBzZW5kIHNpbmdsZSBlbXB0eSAicHVzaC11cGRhdGUiIG5vdGlmaWNhdGlvbi4NCg0K
b3IsIGFsdGVybmF0aXZlbHkgKGlmIHlvdSBkb24ndCB3YW50IE1VU1QpOg0KDQoiLi4uIHRoZW4g
KGluIGNhc2Ugb2YgYSBwZXJpb2RpYyBzdWJzY3JpcHRpb24pIHRoZSBwdWJsaXNoZXIgaXMgYWxs
b3dlZCB0byBzZW5kIG9ubHkgYSBzaW5nbGUgZW1wdHkgInB1c2gtdXBkYXRlIiBub3RpZmljYXRp
b24uDQoNCg0KPEFMRVgtMj4NCkkgZG9u4oCZdCBzZWUgaG93IOKAnGFsbG93ZWQgdG/igJ0gcmVh
bGx5IGNoYW5nZXMgdGhlIG1lYW5pbmcgb2Yg4oCcTUFZ4oCdLCBzbyBJIGFtIHRha2luZyB5b3Vy
IHN1Z2dlc3Rpb24gYW5kIGFtIHJlcGxhY2luZyB0aGUgTUFZIHdpdGggTVVTVC4NCjwvQUxFWC0y
Pg0KDQoNCg0KDQoNCg0KKDM1KSBTZWN0aW9uIDMuMTAuICBUaGlzIHRleHQgc2VlbXMgdG8gYmUg
dmVyeSBjbG9zZWx5IHJlbGF0ZWQgdG8gdGhlDQoNCnRleHQgaW4gc2VjdGlvbiAzLjMsIHNvIHBl
cmhhcHMgc2VjdGlvbiAzLjEwIHdvdWxkIGJlIGJldHRlciBtb3ZlZCB0bw0KDQpiZWNvbWUgc2Vj
dGlvbiAzLjMuMT8NCg0KDQoNCg0KDQo8QUxFWD4NCg0KRG9uJ3Qgd2FudCB0byBhcHBseSBtYWpv
ciBlZGl0b3JpYWwgcmVzdHJ1Y3R1aW5nIGF0IHRoaXMgcG9pbnQuDQoNCjwvQUxFWD4NClRoYXQg
aXMgZmluZS4NCg0KDQoNCg0KDQoNCg0KKDM2KSBTZWN0aW9uIDMuMTAsIGxhc3QgcGFyYWdyYXBo
LiAgIndpbGwgYmUgZXhwZWN0ZWQgdG8iID0+ICJTSE9VTEQiPw0KDQoNCg0KPEFMRVg+Tm90IHN1
cmUgd2Ugd2FudCBpdCB0byBzb3VuZCBzbyBub3JtYXRpdmUsIGJ1dCBzdXJlIC0gY2hhbmdpbmcg
aXQgdG8gU0hPVUxELiA8L0FMRVg+DQoNCg0KDQoNCg0KKDM3KSBTZWN0aW9uIDMuMTEuMSAiaW5j
b21wbGV0ZS11cGRhdGUiIGZsYWcuICBJbiB0aGUgWUFORyBkZWZpbml0aW9uDQoNCnRoaXMgZmxh
ZyBpcyBzZXQgaW4gdGhlIGhlYWRlciBvZiB0aGUgbWVzc2FnZSAoaS5lLiBiZWZvcmUgdGhlIGRh
dGEpLA0KDQpidXQgZm9yIGFwcGxpY2F0aW9ucyB0aGF0IGFyZSBnZW5lcmF0aW5nIHRoZSBub3Rp
ZmljYXRpb25zIGluIGEgc3RyZWFtZWQNCg0Kd2F5LCBpdCB3b3VsZCBwcm9iYWJseSBiZSBiZXR0
ZXIgdG8gcHV0IHRoZSBmbGFnIGFmdGVyIGRhdGEuICBUaGlzDQoNCnBvdGVudGlhbGx5IG1pbmlt
aXplcyB0aGUgcmVxdWlyZW1lbnQgdGhhdCBhIHB1Ymxpc2hlciBoYXMgdG8gYnVmZmVyIGFsbA0K
DQpkYXRhIHRvIGJlIGFibGUgdG8gc2V0IHRoZSBpbmNvbXBsZXRlLXVwZGF0ZSBmbGFnIGlmIG5l
Y2Vzc2FyeS4NCg0KDQoNCjxBTEVYPiBPSywgc28geW91IGFyZSBzdWdnZXN0aW5nIHRvIG1vdmUg
dGhlICJpbmNvbXBsZXRlLXVwZGF0ZSIgbGVhZiBiZWhpbmQgdGhlIGRhdGFzdG9yZSBjb250ZW50
cyAocmVzcGVjdGl2ZWx5IGRhdGFzdG9yZS1jaGFuZ2VzKS4gICBTdXJlLCB3aWxsIGNoYW5nZSB0
aGF0Lg0KDQo8L0FMRVg+DQpZZXMsIHRoYW5rcy4NCg0KDQoNCg0KDQoNCg0KDQoNCigzOCkgU2Vj
dGlvbiAzLjExLjEgM3JkIHBhcmFncmFwaCBhbmQgYnVsbGV0IHBvaW50cy4gIFdpdGggdGhlIHRl
eHQgYXMNCg0KY3VycmVudGx5IHdyaXR0ZW4sIGl0IGlzIGFjY2VwdGFibGUgZm9yIGEgcHVibGlz
aGVyIHRvIGRvIG5vdGhpbmcgZXZlbg0KDQppZiBhbiBlcnJvciBpcyBoaXQuICBUaGV5IGNhbiBz
YXRpc2Z5IHRoZSBmaXJzdCAiTVVTVCIgYnkgc2VsZWN0aW5nIHRoZQ0KDQoybmQgY2hvaWNlLCBh
bmQgdGhleSBjYW4gc2F0aXNmeSB0aGUgIk1BWSIgb2YgdGhlIHNlY29uZCBjaG9pY2UgYnkgZG9p
bmcNCg0Kbm90aGluZyBhdCBhbGwuICBJbnN0ZWFkIEkgdGhpbmsgdGhhdCB0aGUgdGV4dCBzaG91
bGQgc3RhdGUgdGhhdCB0aGUNCg0KcHVibGlzaGVyIE1VU1Qgc2V0IHRoZSAiaW5jb21wbGV0ZS11
cGRhdGUiIGZsYWcsIG9yIHN1c3BlbmQgdGhlDQoNCnN1YnNjcmlwdGlvbiwgb3IgYm90aC4NCg0K
DQoNCg0KDQo8QUxFWD4NCg0KT0ssIEkgdGhpbmsgdGhlIHByb2JsZW0gaXMgd2l0aCAiTVVTVCB0
YWtlIG9uIG9yIG1vcmUgb2YgdGhlIGZvbGxvd2luZyBhY3Rpb25zIiAgKGFsdGhvdWdoIEkgdGhp
bmsgd2hhdCBpcyBtZWFudCBpcyBjbGVhcikuICBSZXBocmFzaW5nIHRoaXMgYXMgZm9sbG93czog
ICIgSW4gdGhpcyBjYXNlLCB0aGUgcHVibGlzaGVyIE1VU1QgYWN0IGFzIGZvbGxvd3MuIg0KDQoN
Cg0KQWxzbyBhZGRpbmcgdGhlIGZvbGxvd2luZyB0byB0aGUgc2Vjb25kIGJ1bGxldCBpdGVtOg0K
DQoiIElmIHRoZSBwdWJsaXNoZXIgZG9lcyBub3QgY3JlYXRlIGFuIHVwZGF0ZSByZWNvcmQgYXQg
YWxsLCBpdCBNVVNUIHN1c3BlbmQgdGhlIHN1YnNjcmlwdGlvbi4gICINCg0KIChUaGlzIGlzIHJl
YWxseSB0aGUgb25seSBsb2dpY2FsIGNob2ljZTsgd2UgZG9uJ3Qgd2FudCBhIHB1Ymxpc2hlciB0
byBoYXZlIHRoZSBvcHRpb24gb2Ygc3RheWluZyBlbnRpcmVseSBzaWxlbnQuKQ0KWWVzLCB0aGUg
Y2hhbmdlIGxvb2tzIGdvb2QuDQoNClRoYW5rcywNClJvYg0KPEFMRVgtMj4NClRoYW5rcywgUm9i
DQotLS0gQWxleA0KPC9BTEVYLTI+DQoNCg0KDQoNCg0KDQoNCg0KLS0tIEFsZXgNCg0KPC9BTEVY
Pg0KDQoNCg0KVGhhbmtzLA0KDQpSb2INCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQoNCk5ldGNvbmYgbWFpbGluZyBsaXN0DQoNCk5ldGNvbmZA
aWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs
dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp
bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ
bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnR0DQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRN
TFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENo
YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm
b3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u
RW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjIN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp
biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv
c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl
ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i
ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv
aGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp
bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFJvYiw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoYW5rIHlvdSBmb3IgeW91ciByZXNwb25z
ZXMgLSByZXBsaWVzIHRvIHRob3NlIGluDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw
MEIwNTAiPiZsdDtBTEVYLTImZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyE8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+LS0tIEFsZXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw
dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3
aW5kb3d0ZXh0Ij4gUm9iZXJ0IFdpbHRvbiBbbWFpbHRvOnJ3aWx0b25AY2lzY28uY29tXQ0KPGJy
Pg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBTZXB0ZW1iZXIgMDYsIDIwMTggMzo1NyBBTTxicj4N
CjxiPlRvOjwvYj4gQWxleGFuZGVyIENsZW1tICZsdDthbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNv
bSZndDs7IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25m
XSBSR1cgWUFORyBwdXNoIC0xOCBMQyBjb21tZW50cyBbcGFydCAxXTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwPkhpIEFsZXgsPG86cD48L286cD48L3A+DQo8cD5QbGVhc2Ugc2VlIGlubGlu
ZSAuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA1LzA5LzIwMTggMjM6Mjgs
IEFsZXhhbmRlciBDbGVtbSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkhl
bGxvIFJvYiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT50aGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMhJm5ic3A7IFBsZWFzZSBmaW5kIG15IHJl
cGxpZXMgaW5saW5lLCAmbHQ7QUxFWCZndDssIHdpdGggY29ycmVzcG9uZGluZyBjaGFuZ2VzIHRv
IGJlIGluY29ycG9yYXRlZCBpbnRvIHRoZSBuZXh0IHJldmlzaW9uICgtMTkpLjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0tLSBBbGV4PG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPHByZT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPkZyb206IE5ldGNvbmYgWzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJv
dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBC
ZWhhbGYgT2YgUm9iZXJ0IFdpbHRvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFR1ZXNk
YXksIFNlcHRlbWJlciAwNCwgMjAxOCA3OjM3IEFNPG86cD48L286cD48L3ByZT4NCjxwcmU+VG86
IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1YmplY3Q6IFtOZXRjb25mXSBSR1cgWUFORyBwdXNoIC0x
OCBMQyBjb21tZW50cyBbcGFydCAxXTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlPkhpLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlPkkndmUgcmV2aWV3ZWQgdGhlIC0xOCBZQU5HIHB1c2ggZHJhZnQg
dXAgdG8gc2VjdGlvbiA0IHNvIGZhciAuIEkndmUgaW5jbHVkZWQgbXk8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5jb21tZW50cyBiZWxvdy4mbmJzcDsgSSB0aGluayB0aGF0IHRoZXkgYXJlIGFsbCBt
aW5vci9jb3NtZXRpYyBleGNlcHQgZm9yIHRoZSBpc3N1ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PnJlZ2FyZGluZyB0aGUgZGFtcGVuZWQgc3Vic2NyaXB0aW9ucyB3aGljaCBoYXMgYmVlbiBkaXNj
dXNzZWQgYmVsb3cgYW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+cHJvYmFibHkgZG9lcyBub3Qg
bmVlZCB0byBiZSByZWhhc2hlZCBhZ2Fpbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JbiB0aGUgQWJzdHJhY3Q6PG86cD48L286cD48L3ByZT4N
CjxwcmU+KDEpIElzICZxdW90O2NvbnRpbnVvdXMmcXVvdDsgdGhlIHJpZ2h0IGNob2ljZSBvZiB3
b3JkIGhlcmUuJm5ic3A7IEUuZy4gSSB0aG91Z2h0IHRoYXQgc29tZXRpbWVzPG86cD48L286cD48
L3ByZT4NCjxwcmU+dGhlIHN0cmVhbSBvZiB1cGRhdGVzIGlzIG5vdCBjb250aW51b3VzLiZuYnNw
OyBQb3NzaWJseSByZW1vdmUgJnF1b3Q7Y29udGludW91cyZxdW90Oz88bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbHQ7QUxFWCZndDtXb3VsZCBwcmVmZXIgdG8ga2Vl
cCwgdW5sZXNzIHlvdSBmZWVsIHZlcnkgc3Ryb25nbHkgYWJvdXQgdGhpcz8mbmJzcDsgV2hhdCB3
ZSB3YW50IHRvIGJyaW5nIGFjcm9zcyBpcyB0aGF0IHRoaXMgaXMgZGlmZmVyZW50IGZyb20gYSBv
bmUtdGltZSwgb24tZGVtYW5kIHR5cGUgb2YgdXBkYXRlLiZuYnNwOyAmcXVvdDtTdHJlYW0mcXVv
dDsgbWlnaHQgaW1wbHkgdGhpcyBhbHJlYWR5LCBidXQgdGhpcyB3YXkgd2Ugd291bGQgZW1waGFz
aXplIHRoaXMgYSBiaXQgZnVydGhlci4mbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jmx0
Oy9BTEVYJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5LZWVwaW5nIGlzIGZpbmUgaWYgdGhhdCBpcyB3aGF0IHlvdSBwcmVmZXIuPGJyPg0K
PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj4mbHQ7QUxF
WC0yJmd0OyBUaGFua3MgJmx0Oy9BTEVYLTImZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+SW4gdGhlIEludHJvZHVjdGlvbjo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4oMikg
JnF1b3Q7cmVtb3RlIHZpc2liaWxpdHkmcXVvdDsgaW4gdGhlIGZpcnN0IHNlbnRlbmNlIGlzIGEg
Yml0IG9ic2N1cmUuIFBlcmhhcHMgcmVwbGFjZSB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5m
aXJzdCBzZW50ZW5jZSB3aXRoICZxdW90O1RyYWRpdGlvbmFsIGFwcHJvYWNoZXMgdG8gbW9uaXRv
cmluZyBtYW5hZ2VtZW50IGRhdGEgb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZW1vdGUgZGV2
aWNlcyBoYXZlIGJlZW4gYnVpbHQgdXBvbiBwb2xsaW5nJnF1b3Q7LjxvOnA+PC9vOnA+PC9wcmU+
DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDtB
TEVYJmd0OyBIb3cgYWJvdXQgY2hhbmdpbmcgdGhpcyB0bzogJnF1b3Q7VHJhZGl0aW9uYWwgYXBw
cm9hY2hlcyB0byBwcm92aWRpbmcgdmlzaWJpbGl0eSBpbnRvIG1hbmFnZWQgZW50aXRpZXMgZnJv
bSByZW1vdGUgaGF2ZSBiZWVuIGJ1aWx0IG9uIHBvbGxpbmcuICZxdW90OzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPltJIHVuZGVyc3RhbmQgeW91ciBwb2ludCwgYnV0IHJlYXNvbiBmb3IgYWx0ZXJu
YXRpdmUgcGhyYXNpbmcgaXMgdGhhdCBJIGRvbid0IHRoaW5rIHdlIHdhbnQgdG8gcmVzdHJpY3Qg
dGhpcyB0byBtb25pdG9yaW5nIChiZWNhdXNlIChhKSB5b3UgY2FuIHVzZSB0aGlzIGFsc28gdG8g
bWlycm9yIHN0YXRlIGZvciBvdGhlciBwdXJwb3NlcywgZS5nLiB0byBhc3Nlc3Mgc3BlY2lmaWNz
IG9mIHdoYXQgbmVlZHMgdG8gYmUgZG9uZSB0byBwcm92aXNpb24gYSBzZXJ2aWNlIHN1Y2Nlc3Nm
dWxseSwgZm9yIHRyb3VibGVzaG9vdGluZywgbWFpbnRlbmFuY2UsIHZhbGlkYXRpb24sIGV0Yywg
YW5kIChiKSBtb25pdG9yaW5nIGRvZXMgaW5jbHVkZSBvdGhlciBhc3BlY3RzIHN1Y2ggYXMgYWxh
cm0gbWFuYWdlbWVudCkuJm5ic3A7IExJa2V3aXNlLCBzdWdnZXN0IHRvIHJlZmVyIHRvICZxdW90
O21hbmFnZWQgZW50aXRpZXMmcXVvdDsgKG5vdCAmcXVvdDtkZXZpY2VzJnF1b3Q7KSB0byBub3Qg
cHJlY2x1ZGUgYXBwbGljYXRpb24gdG8gdGhpbmdzIHRoYXQgYXJlIG5vdCBkZXZpY2VzIChlLmcu
IHZpcnR1YWwgJnF1b3Q7dGhpbmdzJnF1b3Q7KS4gXSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bHQ7L0FMRVgmZ3Q7IDxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPllvdXIg
cGhyYXNpbmcgaXMgZmluZS48YnI+PGJyPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+Jmx0O0FMRVgtMiZndDsgVGhh
bmtzICZsdDsvQUxFWC0yJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4oMykgVGhlIHdvcmsg
aXNuJ3QgYWN0dWFsbHkgZnJ1aXRsZXNzIGlmIHBvbGxpbmcgaXMgdGhlIG9ubHkgYXZhaWxhYmxl
IG9wdGlvbiwgaGVuY2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wZXJoYXBzIGNoYW5nZTo8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PTEQ6PG86
cD48L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7Rm9yIGFwcGxpY2F0aW9ucyB0aGF0IG1vbml0b3Ig
Zm9yIGNoYW5nZXMsIG1hbnkgcmVtb3RlIHBvbGxpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4g
Jm5ic3A7Y3ljbGVzIHBsYWNlIHVsdGltYXRlbHkgZnJ1aXRsZXNzIGxvYWQgb24gdGhlIG5ldHdv
cmssIGRldmljZXMsPG86cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwO2FuZCBhcHBsaWNhdGlv
bnMuPGEgaHJlZj0iTkVXOiZuYnNwOyI+JnF1b3Q7PG86cD48L286cD48L2E+PC9wcmU+DQo8cHJl
PjxzcGFuIGNsYXNzPSJNc29IeXBlcmxpbmsiPjxhIGhyZWY9Ik5FVzombmJzcDsiPjxvOnA+PHNw
YW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj4mbmJzcDs8L3NwYW4+PC9vOnA+PC9hPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gY2xhc3M9Ik1zb0h5cGVybGluayI+PGEgaHJlZj0iTkVX
OiZuYnNwOyI+TkVXOjxvOnA+PC9vOnA+PC9hPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gY2xh
c3M9Ik1zb0h5cGVybGluayI+PGEgaHJlZj0iTkVXOiZuYnNwOyI+ICZuYnNwOyAmcXVvdDs8L2E+
PC9zcGFuPkZvciBhcHBsaWNhdGlvbnMgdGhhdCBtb25pdG9yIGZvciBjaGFuZ2VzLCBtYW55IHJl
bW90ZSBwb2xsaW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwOyBjeWNsZXMgcGxhY2Ug
dW53YW50ZWQgbG9hZCBvbiB0aGUgbmV0d29yaywgZGV2aWNlcyw8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4gJm5ic3A7IGFuZCBhcHBsaWNhdGlvbnMsIHBhcnRpY3VsYXJseSBpZiB0aGUgbW9uaXRv
cmVkIHZhbHVlcyBhcmUgb25seSBjaGFuZ2luZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmluZnJl
cXVlbnRseS4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4m
bHQ7QUxFWC4gVGhlICZxdW90O3VsdGltYXRlbHkgZnJ1aXRsZXNzJnF1b3Q7IGFsc28gcmVmZXJz
IHRvIHRoZSBmYWN0IHRoYXQgbWFueSBwb2xscyB3aWxsIG5vdCB5aWVsZCBuZXcgaW5mb3JtYXRp
b24gKG90aGVyIHRoYW4gJnF1b3Q7bm8gbmV3IGluZm9ybWF0aW9uJnF1b3Q7KSwgYXMgeW91IG1p
Z2h0IGUuZy4gcmV0cmlldmUgYSBsb3Qgb2Ygc3R1ZmYgdG8gc2VlIGlmIGl0IGNoYW5nZWQgb25s
eSB0byBmaW5kIHRoYXQgaXQgZGlkbid0LiZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5I
b3cgYWJvdXQ6ICZxdW90OyBGb3IgYXBwbGljYXRpb25zIHRoYXQgbW9uaXRvciBmb3IgY2hhbmdl
cywgbWFueSByZW1vdGUgcG9sbGluZyBjeWNsZXMgcGxhY2UgdW53YW50ZWQgYW5kIHVsdGltYXRl
bHkgZnJ1aXRsZXNzIGxvYWQgb24gdGhlIG5ldHdvcmssIGRldmljZXMsIGFuZCBhcHBsaWNhdGlv
bnMsIHBhcnRpY3VsYXJseSB3aGVuIGNoYW5nZXMgb2NjdXIgb25seSBpbmZyZXF1ZW50bHkuICZx
dW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDsvQUxFWCZndDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHByZT5NeSBwb2ludCBpcyB0aGF0IGlmIHRoZSBvbmx5IGNob2lj
ZSBpcyBwb2xsaW5nIHRoZW4gaXQgaXMgbm90IGZydWl0bGVzcyBsb2FkLCBiZWNhdXNlIGl0IHNl
cnZlcyBhIHVzZWZ1bCBwdXJwb3NlLCB0aGF0IHB1cnBvc2UgYmVpbmcgZGV0ZWN0aW5nIGNoYW5n
ZXMgaW4gdGhlIG1vbml0b3JlZCBkYXRhLiZuYnNwOyBIZW5jZSB0aGUgbG9hZCBpcyAmcXVvdDt1
bndhbnRlZCZxdW90OyBub3QgJnF1b3Q7ZnJ1aXRsZXNzJnF1b3Q7Ljxicj48YnI+QnV0IHRoaXMg
aXMgYSBtaW5vciBjb25zaWRlcmF0aW9uLCBzbyBJJ20gT0sgd2l0aCB3aGF0ZXZlciB5b3UgZGVj
aWRlIGhlcmUuIDotKTxicj48YnI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj4mbHQ7QUxFWC0yJmd0OyBMZXTigJlz
IGNoYW5nZSDigJxmcnVpdGxlc3PigJ0gdG8g4oCcd2FzdGVmdWzigJ0gJmx0Oy9BTEVYLTImZ3Q7
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPig0KSBJbiBwYXJhZ3JhcGggc3RhcnRpbmcgJnF1b3Q7
IEEgbW9yZSBlZmZlY3RpdmUgYWx0ZXJuYXRpdmUmcXVvdDssIHBvc3NpYmx5IHN1Z2dlc3Q8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5jaGFuZ2luZyAmcXVvdDtwdWJsaXNoZXImcXVvdDsgdG8gJnF1
b3Q7c2VydmVyJnF1b3Q7IHNpbmNlIHRoZSBpbnRyb2R1Y3Rpb24gaXMgYmVmb3JlIHRoZTxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPmRlZmluaXRpb25zL2Fjcm9ueW1zIHdoZXJlICZxdW90O3B1Ymxp
c2hlciZxdW90OyBpcyBmb3JtYWxseSByZWZlcmVuY2VkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPiZsdDtBTEVYJmd0
OyBSZXdvcmRpbmcgdG8gJnF1b3Q7Li4uIHRoYXQgZW5hYmxlcyB0aGUgc2VydmVyIChhbHNvIHJl
ZmVycmVkIHRvIGFzIHB1Ymxpc2hlcikgdG8gcHVzaCZuYnNwOyAuLi4gJnF1b3Q7ICZsdDsvQUxF
WCZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+T0suPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JbiBk
ZWZpbml0aW9uczo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZT4oNSkgU3VnZ2VzdCB0eWluZyB0aGlzIGRlZmluaXRpb24gbW9yZSBjbG9zZWx5IHRv
IHRoZSB0ZXJtaW5vbG9neSBhbHJlYWR5IGRlZmluZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5p
biBSRkMgODM0MiwgaGVuY2U6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+T0xEOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsmbmJzcDsg
byZuYnNwOyBEYXRhc3RvcmUgbm9kZTogQW4gaW5zdGFuY2Ugb2YgbWFuYWdlbWVudCBpbmZvcm1h
dGlvbiBpbiBhPG86cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBkYXRhc3RvcmUuJm5ic3A7IEFsc28ga25vd24gYXMgJnF1b3Q7b2JqZWN0JnF1b3Q7
LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk5F
Vzo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gJm5ic3A7Jm5ic3A7IG8mbmJzcDsgRGF0YXN0b3Jl
IG5vZGU6IEEgbm9kZSBpbiB0aGUgaW5zdGFudGlhdGVkIFlBTkcgZGF0YSB0cmVlIGFzc29jaWF0
ZWQgd2l0aDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgZGF0YXN0b3JlLiZuYnNwOyBJbiB0aGlz
IGRvY3VtZW50LCBkYXRhc3RvcmUgbm9kZXMgYXJlIG9mdGVuIHJlZmVycmVkIHRvIGFzICZxdW90
O1lBTkc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5vYmplY3RzJnF1b3Q7IG9yICZxdW90O29iamVj
dHMmcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT4mbHQ7QUxFWCZndDsgT0suJm5ic3A7IChhbmQgcmVtb3ZlZCBp
bnN0YW5jZSBvZiAmcXVvdDtZQU5HIG9iamVjdCZxdW90OyBmcm9tIHRoZSBkb2N1bWVudCwgYXMg
dGhlcmUgd2VyZSBvbmx5IHR3by4pICZsdDsvQUxFWCZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9i
bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0suPGJyPg0KPGJyPg0KPGJyPg0KPG86
cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4o
NikgJnF1b3Q7RGF0YXN0b3JlIG5vZGUgdXBkYXRlJnF1b3Q7IGRlZmluaXRpb246IERvZXMgdGhp
cyB1cGRhdGUgb25seSBjb250YWluIHRoZSB2YWx1ZSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5v
ciBkb2VzIGl0IGFsc28gY29udGFpbiB0aGUgcGF0aCB0byB0aGUgZGF0YXN0b3JlIG5vZGUgYXMg
d2VsbD8mbmJzcDsgSWYgdGhpcyBhbHNvPG86cD48L286cD48L3ByZT4NCjxwcmU+Y29udGFpbnMg
dGhlIHBhdGggdGhlbiBpdCB3b3VsZCBiZSBnb29kIGlmIHRoYXQgd2FzIGV4cGxpY2l0IGluIHRo
ZSBkZWZpbml0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZs
dDtBTEVYJmd0OyBVcGRhdGVkIGFzIGZvbGxvd3M6ICZxdW90OyBBIGRhdGEgaXRlbSBjb250YWlu
aW5nIHRoZSBjdXJyZW50IHZhbHVlIG9mIGEgZGF0YXN0b3JlIG5vZGUgYXQgdGhlIHRpbWUgdGhl
IGRhdGFzdG9yZSBub2RlIHVwZGF0ZSB3YXMgY3JlYXRlZCwgYXMgd2VsbCBhcyB0aGUgcGF0aCB0
byB0aGUgZGF0YXN0b3JlIG5vZGUuJnF1b3Q7Jm5ic3A7ICZsdDsvQUxFWCZndDs8bzpwPjwvbzpw
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9va3MgZ29vZC48
YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPig3KSBQZXJoYXBz
IHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbiBpcyBtb3JlIHByZWNpc2U/Jm5ic3A7IE9yIGJ5ICZx
dW90O3VwZGF0ZXMmcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kbyB5b3UgYWN0dWFsbHkg
bWVhbiAmcXVvdDt1cGRhdGUgcmVjb3JkcyZxdW90Oz8mbmJzcDsgVGhlcmUgYXJlIG90aGVyIHJl
ZmVyZW5jZXMgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mcXVvdDt1cGRhdGVzJnF1b3Q7IGlu
IHRoZSBkZWZpbml0aW9ucywgZG8gdGhlc2UgYWxsIHJlZmVyIHRvICZxdW90O3VwZGF0ZSByZWNv
cmRzJnF1b3Q7PyBJZiBzbyB0aGVuIEk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53b3VsZCBzdWdn
ZXN0IG1vdmluZyB0aGUgZGVmaW5pdGlvbiBvZiAmcXVvdDt1cGRhdGUgcmVjb3JkJnF1b3Q7IGFi
b3ZlICZxdW90O2RhdGFzdG9yZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnN1YnNjcmlwdGlvbiZx
dW90Oy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT5PTEQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+JnF1b3Q7RGF0YXN0b3JlIHN1YnNjcmlwdGlvbjogQSBzdWJzY3JpcHRpb24gdG8gdXBkYXRl
cyByZWdhcmRpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IGNvbnRlbnRzIG9mIGEgZGF0YXN0b3JlLjxhIGhyZWY9Ik5FVzoiPiZxdW90Ozxv
OnA+PC9vOnA+PC9hPjwvcHJlPg0KPHByZT48c3BhbiBjbGFzcz0iTXNvSHlwZXJsaW5rIj48YSBo
cmVmPSJORVc6Ij48bzpwPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+Jm5ic3A7
PC9zcGFuPjwvbzpwPjwvYT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGNsYXNzPSJNc29IeXBl
cmxpbmsiPjxhIGhyZWY9Ik5FVzoiPk5FVzo8bzpwPjwvbzpwPjwvYT48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGNsYXNzPSJNc29IeXBlcmxpbmsiPjxhIGhyZWY9Ik5FVzoiPjxvOnA+PHNwYW4g
c3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj4mbmJzcDs8L3NwYW4+PC9vOnA+PC9hPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gY2xhc3M9Ik1zb0h5cGVybGluayI+PGEgaHJlZj0iTkVXOiI+
JnF1b3Q7PC9hPjwvc3Bhbj5EYXRhc3RvcmUgc3Vic2NyaXB0aW9uOiBBIHN1YnNjcmlwdGlvbiB0
byBhIHN0cmVhbSBvZiBkYXRhc3RvcmUgbm9kZSB1cGRhdGVzLiZxdW90OzxvOnA+PC9vOnA+PC9w
cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZs
dDtBTEVYJmd0OyBvaywgY2hhbmdlZCAmbHQ7L0FMRVgmZ3Q7PG86cD48L286cD48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZT4oOCkgU3VnZ2VzdCByZW1vdmluZyAmcXVvdDtpbnN0YW50aWF0ZWQmcXVvdDsgZnJv
bSB0aGUgZm9sbG93aW5nIGRlZmluaXRpb24sIGFuZCB1c2luZzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPmRlc2NlbmRhbnQgKHdoaWNoIGlzIHVzZWQgaW4gNzk1MCkgaW5zdGVhZCBvZiBjb250YWlu
ZWQgLi4gSSBhbHNvIHN1Z2dlc3QgbW92aW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlIGRl
ZmluaXRpb24gdXAsIGRpcmVjdGx5IGJlbG93ICZxdW90O2RhdGFzdG9yZSBub2RlJnF1b3Q7Ojxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk9MRDo8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4gJm5i
c3A7Jm5ic3A7IG8gRGF0YXN0b3JlIHN1YnRyZWU6IEFuIGluc3RhbnRpYXRlZCBkYXRhc3RvcmUg
bm9kZSBhbmQgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBkYXRhc3RvcmUgbm9kZXMgdGhhdCBhcmUgaGllcmFyY2hpY2FsbHkgY29udGFp
bmVkIHdpdGhpbiBpdC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5ORVc6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+ICZuYnNwOyZuYnNwOyBvIERhdGFzdG9yZSBzdWJ0cmVlOiBBJm5ic3A7IGRh
dGFzdG9yZSBub2RlIGFuZCBhbGwgaXRzIGRlc2NlbmRhbnQgZGF0YXN0b3JlPG86cD48L286cD48
L3ByZT4NCjxwcmU+bm9kZXMuJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+Jmx0O0FMRVgmZ3Q7IGNoYW5nZWQgJmx0Oy9BTEVYJmd0OzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+KDkpIFNlYyAzLiBTb2x1dGlvbiBvdmVydmlldywgbGFzdCBzZW50ZW5j
ZS4mbmJzcDsmbmJzcDsgSXQgaXMgbm90ICZxdW90O1lBTkcgb2JqZWN0cyZxdW90OzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPnRoYXQgYXJlIGJlaW5nIHB1c2hlZCwgYnV0IHN1cmVseSAmcXVvdDtk
YXRhc3RvcmUgbm9kZSB1cGRhdGVzJnF1b3Q7IG9yIHBlcmhhcHM8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mcXVvdDt1cGRhdGUgcmVjb3JkcyZxdW90OyB0aGF0IGFyZSBwdXNoZWQsIG9yIGV2ZW4g
JnF1b3Q7Q2hhbmdlcyB0byBZQU5HIG9iamVjdHMmcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT4mbHQ7QUxFWCZndDsgQ2hhbmdlZCB0byAmcXVvdDtkYXRhc3Rv
cmUgbm9kZSB1cGRhdGVzJnF1b3Q7ICZsdDsvQUxFWCZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlNlYyAzLjEgU3Vic2NyaXB0aW9uIG1v
ZGVsOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PigxMCkgUGVyaGFwcyBjaGFuZ2UmcXVvdDtzdWJ0cmVlcyB3aXRoaW4gYSBkYXRhc3RvcmUmcXVv
dDsgdG8gJnF1b3Q7ZGF0YXN0b3JlIHN1YnRyZWVzJnF1b3Q7LjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDtBTEVYJmd0OyBjaGFuZ2VkICZsdDsvQUxFWCZndDs8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPigx
MSkgSXQgaXMgbm90IG9idmlvdXMgdG8gbWUgZnJvbSB0aGlzIHRleHQgd2hhdCAmcXVvdDtBbmNo
b3IgdGltZSZxdW90OyBpcyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbHRob3VnaCBJIHN1c3Bl
Y3QgdGhhdCBpdCBpcyBkZXNjcmliZWQgaW4gbW9yZSBkZXRhaWwgbGF0ZXIgaW4gdGhlPG86cD48
L286cD48L3ByZT4NCjxwcmU+ZG9jdW1lbnQuJm5ic3A7IEdpdmVuIHRoYXQgdGhlIHNlY3Rpb24g
b24tY2hhbmdlIHN1YnNjcmlwdGlvbnMgaGFzIG1vcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5k
ZXRhaWwgZm9yIHZhcmlvdXMgcGFyYW1ldGVycywgSSB3b25kZXIgd2hldGhlciBpdCB3b3VsZCBi
ZSBoZWxwZnVsIHRvPG86cD48L286cD48L3ByZT4NCjxwcmU+ZGVzY3JpYmUgYW5jaG9yIHRpbWUg
aW4gbW9yZSBkZXRhaWwgaW4gdGhpcyBzZWN0aW9uPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8cHJlPiZsdDtBTEVYJmd0OyBSb3VnaGx5IHdoYXQgaXQgaXMgaXMgZXhwbGFp
bmVkIGluIHRoZSBzYW1lIHNlbnRlbmNlLCBidXQgaG93IGFib3V0IGNoYW5naW5nIGl0IGFzIGZv
bGxvd3M6PG86cD48L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7IFRoZXNlIHBhcmFtZXRlcnMgYXJl
IHRoZSBwZXJpb2QgaW50ZXJ2YWwgd2l0aCB3aGljaCB0byByZXBvcnQgdXBkYXRlcywgYW5kIGFu
ICZxdW90O2FuY2hvciB0aW1lJnF1b3Q7LCBpLmUuIGEgcmVmZXJlbmNlIHBvaW50IGluIHRpbWUg
dGhhdCBjYW4gYmUgdXNlZCB0byBjYWxjdWxhdGUgYXQgd2hpY2ggcG9pbnRzIGluIHRpbWUgcGVy
aW9kaWMgdXBkYXRlcyBuZWVkIHRvIGJlIGFzc2VtYmxlZCBhbmQgc2VudC4gJnF1b3Q7PG86cD48
L286cD48L3ByZT4NCjxwcmU+Jmx0Oy9BTEVYJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2Nr
cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIEkgZ2V0IHRoaXMsIGJ1dCBkaWRu
J3QgZmluZCBpdCBjb21wbGV0ZWx5IGNsZWFyIHVudGlsIEkgaGFkIGxvb2tlZCBhdCB0aGUgbW9k
ZWwuJm5ic3A7IEkgdGhpbmsgdGhhdCB5b3UgdXBkYXRlZCB0ZXh0IGlzIE9LLjxicj4NCjxicj4N
CkFsdGhvdWdoIEkgaGF2ZSBhIHNsaWdodCBjb25jZXJuIChlLmcuIGluIHNlY3Rpb24gNC4yKSw8
YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50
OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0
IDguMHB0IDguMHB0IDguMHB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDti
b3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7IGFuICZxdW90O2FuY2hvci10aW1l
JnF1b3Q7OyB1cGRhdGUgaW50ZXJ2YWxzIGFsd2F5cyBmYWxsIG9uIHRoZSBwb2ludHMgaW48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFj
a2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6
MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRpbWUgdGhhdCBhcmUgYSBtdWx0aXBsZSBvZiBh
ICZxdW90O3BlcmlvZCZxdW90OyBmcm9tIGFuICZxdW90O2FuY2hvci10aW1lJnF1b3Q7LjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJ
IGNhbiBzZWUgaW1wbGVtZW50YXRpb25zIHdpbGwgdHJ5IGFuZCBrZWVwIHRvIHRoaXMgaW50ZXJ2
YWwsIGJ1dCBJIHN1c3BlY3QgdGhhdCB0aGUgdmFzdCBtYWpvcml0eSBvZiBpbXBsZW1lbnRhdGlv
bnMgd2lsbCBub3QgYmUgYWJsZSB0byBndWFyYW50ZWUgdGhhdCBpdCBpcyBleGFjdCBtdWx0aXBs
ZXMgb2YgdGhlIGdpdmVuIHBlcmlvZCwgZ2l2ZW4gdGhhdCAmcXVvdDthbmNob3ItdGltZSZxdW90
OyBzZWVtcyB0byB0YWtlIGFuIGFyYml0cmFyeSBzdWItc2VjdGlvbg0KIHByZWNpc2lvbiwgYW5k
IHRpbWV0aWNrcyBhcmUgaW4gaHVuZHJlZHMgb2YgYSBzZWNvbmQuJm5ic3A7IFBvc3NpYmx5LCB3
ZWFrZW5pbmcgdGhlIHRleHQgKGUuZy4gYXMgcGVyIGJlbG93LCBidXQgdGhlIFlBTkcgbW9kZWwg
d291bGQgcHJvYmFibHkgbmVlZCB0byBiZSB1cGRhdGVkKSBtaWdodCBiZSBhIGdvb2QgaWRlYT88
YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50
OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0
IDguMHB0IDguMHB0IDguMHB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDti
b3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7IGFuICZxdW90O2FuY2hvci10aW1l
JnF1b3Q7OyB1cGRhdGUgaW50ZXJ2YWxzIGFsd2F5cyBmYWxsIGFzIGNsb3NlIGFzIHBvc3NpYmxl
IHRvIHRoZSBwb2ludHMgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs
O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRpbWUgdGhh
dCBhcmUgYSBtdWx0aXBsZSBvZiBhICZxdW90O3BlcmlvZCZxdW90OyBmcm9tIGFuICZxdW90O2Fu
Y2hvci10aW1lJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxicj48YnI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj4mbHQ7QUxFWC0y
Jmd0O0kgZG9u4oCZdCBsaWtlIHRoZSDigJxhcyBjbG9zZSBhcyBwb3NzaWJsZeKAnS4mbmJzcDsg
V2hhdCBpcyBwb3NzaWJsZSBtYXkgZGlmZmVyIGJldHdlZW4gaW1wbGVtZW50YXRpb25zOyBJIGZl
ZWwgdGhhdCB0aGlzIGZvcm11bGF0aW9uIGJsdXJzIG1vcmUgdGhhbiBpdCBjbGFyaWZpZXMuJm5i
c3A7IFBlcmhhcHMgd2Ugc2hvdWxkIHNpbXBseSByZW1vdmUgdGhlIOKAnGFsd2F5c+KAnSDigJMg
dG8gcmVhZCA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0
OjEwLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDBCMDUwIj7igJx1cGRhdGUgaW50ZXJ2YWxzIGZhbGwgb24gdGhlIHBv
aW50cyBpbiB0aW1lIHRoYXQgYXJlIGEgbXVsdGlwbGUgb2YgYSAmcXVvdDtwZXJpb2QmcXVvdDsg
ZnJvbSBhbiAmcXVvdDthbmNob3ItdGltZSZxdW90OyAmbHQ7L0FMRVgtMiZndDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v
OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxwcmU+KDEyKSBEYW1wZW5pbmcgcGVyaW9kOiBUaGUgdGV4dCBzdGF0
ZXMgdGhhdCAmcXVvdDtUaGUgZGFtcGVuaW5nIHBlcmlvZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PmNvbGxlY3RpdmVseSBhcHBsaWVzIHRvIHRoZSBzZXQgb2YgYWxsIGRhdGFzdG9yZSBub2RlcyBz
ZWxlY3RlZCBieSBhPG86cD48L286cD48L3ByZT4NCjxwcmU+c2luZ2xlIHN1YnNjcmlwdGlvbiBh
bmQgc2VudCB0byBhIHNpbmdsZSByZWNlaXZlci4mcXVvdDsmbmJzcDsgVGhpcyB3b3VsZCBpbXBs
eTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoYXQgaWYgYSBzaW5nbGUgc3Vic2NyaXB0aW9uIGhh
ZCBtdWx0aXBsZSByZWNlaXZlcnMgdGhhdCB0aGV5IHdvdWxkIGJlPG86cD48L286cD48L3ByZT4N
CjxwcmU+ZGFtcGVuZWQgaW5kZXBlbmRlbnRseSwgYnV0IGl0IHdhc24ndCBvYnZpb3VzIHRvIG1l
IHRoYXQgdGhpcyBtYWtlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNlbnNlLiZuYnNwOyBJIHdv
dWxkIGFzc3VtZSB0aGF0IGZvciBhIGdpdmVuIHN1YnNjcmlwdGlvbiB0aGF0IGFsbCByZWNlaXZl
cnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53b3VsZCByZWNlaXZlIHRoZSBzYW1lIHVwZGF0ZSBy
ZWNvcmRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDtBTEVYJmd0OyBZZXMuJm5ic3A7IFJlbW92ZWQgJnF1b3Q7
YW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2ZXImcXVvdDsuJm5ic3A7IEFsc28gY2xhcmlmaWVk
IGZ1cnRoZXIgKGluIGEgc2xpZ2h0IHJld29yZGluZykgJnF1b3Q7IFRoaXMgbWVhbnMgdGhhdCB3
aGVuIHRoZXJlIGlzIGEgY2hhbmdlIHRvIG9uZSBvciBtb3JlIHN1YnNjcmliZWQgb2JqZWN0cywg
YW4gdXBkYXRlIHJlY29yZCBjb250YWluaW5nIHRob3NlIG9iamVjdHMgaXMgY3JlYXRlZCBpbW1l
ZGlhdGVseSAod2hlbiBubyBkYW1wZW5pbmcgcGVyaW9kIGlzIGluIGVmZmVjdCkgb3IgYXQgdGhl
IGVuZCBvZiBhIGRhbXBlbmluZyBwZXJpb2QgKHdoZW4gYSBkYW1wZW5pbmcgcGVyaW9kIGlzIGlu
IGZhY3QgaW4gZWZmZWN0KS4mbmJzcDsgJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jmx0
Oy9BTEVYJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5PSy48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PigxMykgUmF0aGVyIHRoYW4gJnF1b3Q7Tm8gU3luYyBvbiBzdGFydCZxdW90OywgaXQgbWlnaHQg
YmUgYmV0dGVyIHRvIHJlZmVyIHRvIHRoaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hcyZuYnNw
OyAmcXVvdDtzeW5jIG9uIHN0YXJ0JnF1b3Q7LCB3aGljaCBjb3VsZCBiZSBkZWZpbmVkIGFzIGEg
Ym9vbGVhbiB3aXRoIGRlZmF1bHQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50cnVlIFtJJ3ZlIG5v
dCBjaGVja2VkIHRoZSBZQU5HIG1vZGVsXTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDtBTEVYJmd0OyBpdCdzIG5v
dCBkZWZpbmVkIGFzIGEgYm9vbGVhbiBidXQgYXMgYSBsZWFmIG9mIHR5cGUgZW1wdHkuJm5ic3A7
IChTbywgdGhlICZxdW90O2RlZmF1bHQmcXVvdDsgaXMgaW4gZmFjdCB0cnVlLCB1bmxlc3MmbmJz
cDsgbm8tc3luYy1vbi1zdGFydCBpcyBwcmVzZW50KS4mbmJzcDsgSSBkb24ndCBzZWUgYSBjb21w
ZWxsaW5nIHJlYXNvbiB0byBjaGFuZ2UgdGhpcyBhbmQgc3VnZ2VzdCB0byBrZWVwIHRoaXMgYXMt
aXMuJm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDsvQUxFWCZndDs8bzpwPjwvbzpw
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTAuNXB0Ij5P
Sy4mbmJzcDsgSSB0aGluayB0aGF0IGluIFlBTkcsIHBhcnRpY3VsYXJseSBjb25zaWRlcmluZyBO
TURBLCBpdCBpcyBjbGVhbmVyIHRvIG1vZGVsIHRoaXMgYXMgYSBib29sZWFuIHdpdGggZGVmYXVs
dCB0cnVlLCBwYXJ0aWN1bGFybHkgaWYgeW91IGRvIGEgZ2V0LWRhdGEgcmVxdWVzdCBvbiB0aGUg
b3BlcmF0aW9uYWwgc3RhdGUsIHNpbmNlIGl0IG1vcmUgY2xlYXJseSBhbmQgZXhwbGljaXRseSBp
bmRpY2F0ZXMgd2hldGhlciBzeW5jLW9uLXN0YXJ0IGlzIGVuYWJsZWQuPGJyPjxicj5XaXRoIHRo
ZSBjdXJyZW50IG1vZGVsLCBvbiBhIGdldC1kYXRhIHJlcXVlc3QgYWdhaW5zdCBvcGVyYXRpb24s
IHRoZSBzZXJ2ZXIgcmV0dXJucyAmcXVvdDtuby1zeW5jaC1vbi1zdGFydCZxdW90OywgaXQgaXMg
b2J2aW91cyB0aGF0IGl0IHdvbid0IHBlcmZvcm0gYSBzeW5jLW9uLXN0YXJ0LCBob3dldmVyLCB0
aGUgcmV2ZXJzZSBpZiB0aGUgbGVhZiBpc24ndCBwcmVzZW50IGlzbid0IHF1aXRlIHNvIGNsZWFy
LiZuYnNwOyBJZiBpdCBkb2Vzbid0IHJldHVybiAmcXVvdDtuby1zeW5jaC1vbi1zdGFydCZxdW90
OyB0aGVuIHRoYXQgZWl0aGVyIG1lYW5zIHRoZSBkZXZpY2Ugd2lsbCBwZXJmb3JtIHN5bmMtb24t
c3RhcnQsIG9yIHBlcmhhcHMgdGhlIG5vZGUgdGhlIHNlcnZlciBpc24ndCByZXR1cm5pbmcgYW55
IGluZm9ybWF0aW9uLCBvciBwZXJoYXBzIGl0IGhhcyBiZWVuIGRldmlhdGVkLiZuYnNwOyBTbywg
aW4gc3VtbWFyeSwgSSB0aGluayB0aGF0IGZsYWdzIHRoYXQgdHVybiBzb21ldGhpbmcgb2ZmLCBh
cmUgYmV0dGVyIG1vZGVsZWQgd2l0aCBkZWZhdWx0IHRydWUsIHJhdGhlciB0aGFuIGFzIGVtcHR5
IGxlYWZzLiZuYnNwOyBGbGFncyB0aGF0IHR1cm4gc29tZXRoaW5nIG9uIGNhbiBiZSBtb2RlbGVk
IGVxdWFsbHkgd2VsbCBlaXRoZXIgd2F5LjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv
d3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu
LWxlZnQ6MTAuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPiZsdDtBTEVYLTImZ3Q7SW4gdGVybXMgb2YgaW5z
dGFudGlhdGlvbiwgSSBmaW5kIGVtcHR5IGxlYXZlcyBtb3JlIGVsZWdhbnQsIHBhcnRpY3VsYXJs
eSBpZiB0aGVyZSBpcyBhIGRlZmF1bHQgdmFsdWUuICZuYnNwO0kgdGhpbmsgJmx0O25vLXN5bmMt
b24tc3RhcnQvJmd0OyBpcyBtb3JlIGVsZWdhbnQgdGhhbiAmbHQ7bm8tc3luYy1vbi1zdGFydCZn
dDtUcnVlJmx0Oy9uby1zeW5jLW9uLXN0YXJ0Jmd0Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj5Xb3VsZCB5b3Ug
YmUgc2F0aXNmaWVkIGlmIHdlIHR1cm4gdGhlIGRlZmF1bHQgYXJvdW5kLCBpLmUuIGNoYW5nZSDi
gJxuby1zeW5jLW9uLXN0YXJ04oCdIHRvIOKAnHN5bmMtb24tc3RhcnTigJ0sIGJ1dCBrZWVwaW5n
IGl0IGFuIGVtcHR5PyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0OjEwLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwLjVwdCI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj4m
bmJzcDsmbHQ7L0FMRVgtMiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTAuNXB0Ij48YnI+PGJyPkJUVywgSSBhbHNvIG5v
dGljZSB0aGF0IGlzIHVzZXMgJnF1b3Q7c3luY2gmcXVvdDsgaW4gdmFyaW91cyBsZWFmIG5hbWUs
IGJ1dCBJIHdvdWxkIHJlY29tbWVuZCB0aGUgYWJicmV2aWF0aW9uICZxdW90O3N5bmMmcXVvdDsg
aW5zdGVhZC4mbmJzcDsgSXQgaXMgc2hvcnRlciwgYW5kIEkgdGhpbmsgbW9yZSBjb21tb25seSB1
c2VkLiZuYnNwOyA8YSBocmVmPSJodHRwczovL2VuZ2xpc2guc3RhY2tleGNoYW5nZS5jb20vcXVl
c3Rpb25zLzY4MS9zeW5jZWQtb3Itc3luY2hlZCI+aHR0cHM6Ly9lbmdsaXNoLnN0YWNrZXhjaGFu
Z2UuY29tL3F1ZXN0aW9ucy82ODEvc3luY2VkLW9yLXN5bmNoZWQ8L2E+PGJyPiZuYnNwOzxicj48
YnI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDBCMDUwIj4mbHQ7QUxFWC0yJmd0O0hhdmUgY2hhbmdlZCDigJxzeW5jaOKAnSAo
YW5kIOKAnHJlc3luY2jigJ0pIHRvIHN5bmMgLyByZXN5bmMgdGhyb3Vnb3V0IHRoZSBkb2N1bWVu
dHQsIGFsc28gcGVyIFJvaGl04oCZcyBlYXJsaWVyIGNvbW1lbnQuJm5ic3A7IDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTAuNXB0Ij48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIw
NTAiPiZsdDsvQUxFWC0yJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT5TZWMgMy4yLiBOZWdvdGlhdGlvbiBvZiBTdWJzY3JpcHRpb24gUG9s
aWNpZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT4oMTQpICZxdW90O1JhbmRvbSBndWVzc2luZyBhdCZxdW90OyA9Jmd0OyAmcXVvdDtSYW5kb20g
Z3Vlc3Npbmcgb2YmcXVvdDsuJm5ic3A7IEFsdGhvdWdoLCBJIHRoaW5rPG86cD48L286cD48L3By
ZT4NCjxwcmU+dGhhdCBwcm9iYWJseSB0aGlzIGZpcnN0IHNlbnRlbmNlLCBhbmQgdGhlICZxdW90
O1RoZXJmb3JlLCAmcXVvdDsgY291bGQganVzdCBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRl
bGV0ZWQuJm5ic3A7IEkuZS4gc3RhcnRpbmcgdGhlIHBhcmFncmFwaCAmcXVvdDtJbiBvcmRlciB0
byBtaW5pbWl6ZSAuLi4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT4mbHQ7QUxFWCZndDsgQ2hhbmdlZCAmcXVvdDthdCZxdW90OyB0byAmcXVvdDtvZiZxdW90
OywgaG93ZXZlciwgcHJlZmVyIHRvIGtlZXAgdGhlIGZpcnN0IHNlbnRlbmNlIGFzIGl0IGRvZXMg
cHJvdmlkZSBzb21lIGV4cGxhbmF0aW9uLiZuYnNwOyAmbHQ7L0FMRVgmZ3Q7PG86cD48L286cD48
L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9LLjxicj4NCjxicj4N
Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+KDE1KSBTdWdnZXN0IG1pbm9yIHJl
d29yZGluZyBvZiAzLjMuIHRoaXJkIHBhcmFncmFwaDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PTEQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SW4gdGhhdCBjYXNlLCB1cGRhdGVzIGFyZSBz
ZW50IG9ubHkgZm9yIHRob3NlIG9iamVjdHM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gJm5ic3A7
Jm5ic3A7IHdpdGhpbiB0aGUgc2NvcGUgdGhhdCBkbyBzdXBwb3J0IG9uLWNoYW5nZSB1cGRhdGVz
IHdoZXJlYXMgb3RoZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gJm5ic3A7Jm5ic3A7IG9iamVj
dHMgYXJlIGV4Y2x1ZGVkIGZyb20gdXBkYXRlIHJlY29yZHMsIHdoZXRoZXIgb3Igbm90IHRoZWly
IHZhbHVlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsmbmJzcDsgYWN0dWFsbHkgY2hh
bmdlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
Pk5FVzo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT5JbiB0aGF0IGNhc2UsIHVwZGF0ZXMgYXJlIHNlbnQgb25seSBmb3IgdGhvc2Ugb2JqZWN0czxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsmbmJzcDsgd2l0aGluIHRoZSBzY29wZSB0aGF0
IGRvIHN1cHBvcnQgb24tY2hhbmdlIHVwZGF0ZXMsIHdoZXJlYXMgb3RoZXI8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4gJm5ic3A7Jm5ic3A7IG9iamVjdHMgYXJlIGV4Y2x1ZGVkIGZyb20gdXBkYXRl
IHJlY29yZHMsIGV2ZW4gaWYgdGhlaXIgdmFsdWVzIGNoYW5nZS48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT4mbHQ7QUxF
WCZndDsgY2hhbmdlZCAmbHQ7L0FMRVgmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4o
MTYpIFF1ZXN0aW9uIG9uIDMuMy4gZmlmdGggcGFyYWdyYXBoIChiZWxvdyksIGl0J3MgdW5jbGVh
ciB0byBtZSB3aGF0PG86cD48L286cD48L3ByZT4NCjxwcmU+aXMgbWVhbnQgYnkgJnF1b3Q7d2hp
Y2ggYXJlIGN1cnJlbnQgYXQgdGhlIHRpbWUmcXVvdDs6PG86cD48L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7VmFsdWVzIHNlbnQgYXQgdGhlIGVu
ZCBvZiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gJm5ic3A7Jm5ic3A7IGRhbXBlbmluZyBw
ZXJpb2QgYXJlIHRoZSBjdXJyZW50IHZhbHVlcyBvZiBhbGwgY2hhbmdlZCBvYmplY3RzIHdoaWNo
PG86cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZuYnNwOyBhcmUgY3VycmVudCBhdCB0aGUg
dGltZSB0aGUgZGFtcGVuaW5nIHBlcmlvZCBleHBpcmVzLiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+
DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDtB
TEVYJmd0OyBSZXBocmFzZSB0aGUgcGFyYWdyYXBoIGFzIGZvbGxvd3MsIGp1c3QgdG8gbWFrZSBp
dCBjbGVhciAoaXQncyBhIGJpdCBtb3JlIHZlcmJvc2UgdGhhbiBpdCBoYXMgdG8sIGJ1dCB3ZSB3
YW50IHRvIG1ha2Ugc3VyZSB0aGVyZSBpcyBubyBxdWVzdGlvbiBhcyB0byB3aGF0IHZhbHVlIHRv
IHNlbmQgLSB0aGUgdmFsdWUgb2YgdGhlIG9yaWdpbmFsIGNoYW5nZSBvciB0aGUgdmFsdWUgYXQg
dGhlIHRpbWUgb2YgdXBkYXRpbmcpLiZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mcXVv
dDsuLi4gLiZuYnNwOyBWYWx1ZXMgc2VudCBhdCB0aGUgZW5kIG9mIHRoZSBkYW1wZW5pbmcgcGVy
aW9kIGFyZSB0aGUgdmFsdWVzIHRoYXQgYXJlIGN1cnJlbnQgYXQgdGhlIGVuZCBvZiB0aGUgZGFt
cGVuaW5nIHBlcmlvZCBvZiBhbGwgY2hhbmdlZCBvYmplY3RzLiZuYnNwOyBDaGFuZ2VkIG9iamVj
dHMgaW5jbHVkZSB0aG9zZSB3aGljaCB3ZXJlIGRlbGV0ZWQgb3IgbmV3bHkgY3JlYXRlZCBkdXJp
bmcgdGhhdCBkYW1wZW5pbmcgcGVyaW9kLiZuYnNwOyBJZiBhbiBvYmplY3QgaGFzIHJldHVybmVk
IHRvIGl0cyBvcmlnaW5hbCB2YWx1ZSAob3IgZXZlbiBoYXMgYmVlbiBjcmVhdGVkIGFuZCB0aGVu
IGRlbGV0ZWQpIGR1cmluZyB0aGUgZGFtcGVuaW5nLXBlcmlvZCwgdGhhdCB2YWx1ZSAoYW5kIG5v
dCB0aGUgaW50ZXJpbSBjaGFuZ2UpIHdpbGwgc3RpbGwgYmUgc2VudC4gLi4uJnF1b3Q7PG86cD48
L286cD48L3ByZT4NCjxwcmU+Jmx0Oy9BTEVYJmd0OyA8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9j
a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBJIHRoaW5rIHRoYXQgdGhlIGxvbmdl
ciBhbmQgbW9yZSBleHBsaWNpdCB0ZXh0IGlzIGJldHRlci48YnI+DQo8YnI+DQo8YnI+DQo8bzpw
PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPigxNykgSSBzdGlsbCBkb3VidCB0aGF0IGFsbCBpbXBs
ZW1lbnRhdGlvbnMgd2lsbCBzdHJpY3RseSBmb2xsb3cgYWxsIG9mPG86cD48L286cD48L3ByZT4N
CjxwcmU+My4zLiBwYXJhZ3JhcGggNSwgcGFydGljdWxhcmx5IHRoZSBjcmVhdGVkIGFuZCBkZWxl
dGVkIHdpdGhpbiBhPG86cD48L286cD48L3ByZT4NCjxwcmU+ZGFtcGVuaW5nIHBlcmlvZCBiZWNh
dXNlIEkgcGVyY2VpdmUgdGhhdCBpdCBpcyBwYXJ0aWN1bGFybHkgZGlmZmljdWx0IHRvPG86cD48
L286cD48L3ByZT4NCjxwcmU+aW1wbGVtZW50IGNsZWFubHkvZWZmaWNpZW50bHkuJm5ic3A7IEhv
d2V2ZXIsIHRoaXMgaXNzdWUgaGFzIGJlZW4gZGlzY3Vzc2VkPG86cD48L286cD48L3ByZT4NCjxw
cmU+cHJldmlvdXNseSwgYW5kIEkgaGF2ZSBubyBwYXJ0aWN1bGFyIGRlc2lyZSB0byBzbG93IHRo
ZSBSRkMgcHJvZ3Jlc3M8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kb3duIHdpdGggZnVydGhlciBk
aXNjdXNzaW9uIG9uIHRoaXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+Jmx0O0FMRVgmZ3Q7IE5vIGNoYW5nZSBtYWRlICZsdDsvQUxFWCZndDsgPG86cD48L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4oMTgpIFNlY3Rpb24g
My4zLCBjb25jZXB0dWFsIHByb2Nlc3MsIHN0ZXAgMSBzdGF0ZXMgdGhhdCBhY2Nlc3MgY29udHJv
bDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJ1bGVzIGFyZSBjaGVja2VkIHRvIGVuc3VyZSB0aGUg
cmVjZWl2ZXIgaXMgYXV0aG9yaXplZCB0byB2aWV3IGFsbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PnN1YnNjcmliZWQgZGF0YXN0b3JlIG5vZGVzLCBidXQgSSB0aGluayB0aGF0IHRoaXMgc2hvdWxk
IHN0YXRlIHRoYXQgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+YWNjZXNzIGNvbnRyb2wgcnVs
ZXMgYXJlIHVzZWQgdG8gZmlsdGVyIHRoZSBzdWJzY3JpYmVkIGRhdGFzdG9yZSBub2RlczxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPnRvIHRob3NlIHRoYXQgdGhlIGNsaWVudCBoYXMgYWNjZXNzIHJp
Z2h0cyB0by48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT4mbHQ7QUxFWCZndDsmbmJzcDsgSSBhZGRlZCAmcXVvdDsgKGFu
ZCBmaWx0ZXIgb3V0IGFueSBub2RlcyBmb3Igd2hpY2ggdGhpcyBpcyBub3QgdGhlIGNhc2UpJnF1
b3Q7IHRvIG1ha2UgdGhpcyBjbGVhcmVyOyB0aGlzIG5vdyByZWFkcyAmcXVvdDsgSnVzdCBiZWZv
cmUgYSBjaGFuZ2UsIG9yIGF0IHRoZSBzdGFydCBvZiBhIGRhbXBlbmluZyBwZXJpb2QsIGV2YWx1
YXRlIGFueSBmaWx0ZXJpbmcgYW5kIGFueSBhY2Nlc3MgY29udHJvbCBydWxlcyB0byBlbnN1cmUg
cmVjZWl2ZXIgaXMgYXV0aG9yaXplZCB0byB2aWV3IGFsbCBzdWJzY3JpYmVkIGRhdGFzdG9yZSBu
b2RlcyAoYW5kIGZpbHRlciBvdXQgYW55IG5vZGVzIGZvciB3aGljaCB0aGlzIGlzIG5vdCB0aGUg
Y2FzZSkuICZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDsvQUxFWCZndDs8bzpwPjwv
bzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTUuM3B0
Ij5PSywgYnV0IEkgd291bGQgY2hhbmdlICZxdW90O2FuZCBmaWx0ZXImcXVvdDsgdG8gJnF1b3Q7
ZmlsdGVyaW5nJnF1b3Q7Ljxicj48YnI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj4mbHQ7QUxFWC0yJmd0O09LLCBj
aGFuZ2VkICZsdDsvQUxFWC0yJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+KDE5KSBBIHJlbGF0ZWQgcXVlc3Rpb246Jm5ic3A7IFdoZW4gaGFwcGVucyBpZiB0aGVyZSBp
cyBhbiBhY2Nlc3MgY29udHJvbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNoYW5nZSwgaS5lLiB0
aGUgcmVjZWl2ZXIgaGFkIGFjY2VzcyBwcmV2aW91c2x5LCBidXQgdGhlbiBpdCB3YXM8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5yZXZva2VkLiZuYnNwOyBEb2VzIGl0IHNlZSBhIGRlbGV0ZT8mbmJz
cDsgT3IgZG9lcyBpdCBub3QgZ2V0IGFueSBub3RpZmljYXRpb24/PG86cD48L286cD48L3ByZT4N
CjxwcmU+U2ltaWxhcmx5LCBpZiB0aGV5IGRpZG4ndCBwcmV2aW91c2x5IGhhdmUgYWNjZXNzLCBi
dXQgdGhlbiBhY2Nlc3Mgd2FzPG86cD48L286cD48L3ByZT4NCjxwcmU+Z3JhbnRlZCBiZWZvcmUg
dGhlIGVuZCBvZiB0aGUgZGFtcGVuaW5nIHBlcmlvZD8mbmJzcDsgT0ssIEkgc2VlIHRoYXQgdGhp
cyBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRlc2NyaWJlZCBpbiBtb3JlIGRldGFpbCBpbiBz
ZWN0aW9uIDMuOSwgcGFyYWdyYXBoIDMuJm5ic3A7IFBlcmhhcHMgYSBmb3J3YXJkPG86cD48L286
cD48L3ByZT4NCjxwcmU+cmVmZXJlbmNlIHdvdWxkIGJlIHVzZWZ1bCBoZXJlLjxvOnA+PC9vOnA+
PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PiZsdDtBTEVYJmd0OyBJIHRoaW5rIHRoaXMgaXMgZGVmaW5lZCBpbiBkZXRhaWwgaW4gMy45LCBh
cyB5b3Ugbm90ZS4mbmJzcDsgSSB0aGluayB0aGUgc3Bpcml0IG9mIHRoZSBkZXNjcmlwdGlvbiBo
ZXJlIGlzIGNsZWFyLCBhbmQgSSBkb24ndCB3YW50IHRvIG92ZXJseSBidXJkZW4gdGhlIHRleHQg
d2l0aCBjcm9zcy1yZWZlcmVuY2VzIHdpdGhpbiB0aGUgc2FtZSB0ZXh0LiZuYnNwOyBTbywgSSBz
dWdnZXN0IGtlZXBpbmcgdGhpcyBhcy1pcy4mbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+
Jmx0Oy9BTEVYJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5PSy48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlPigyMCkgU2VjdGlvbiAzLjMsIGxhc3QgcGFyYWdyYXBoLCAmcXVvdDtjYW4gYmUgY3JlYXRl
ZCZxdW90OyA9Jmd0OyAmcXVvdDttdXN0IGJlIGNyZWF0ZWQmcXVvdDsuPG86cD48L286cD48L3By
ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jmx0
O0FMRVgmZ3Q7IEFjdHVhbGx5LCBJIHRoaW5rIGl0IGlzICZxdW90O2NhbiZxdW90Oy4mbmJzcDsg
SXQgaXMgdXAgdG8gdGhlIGRpc2NyZXRpb24gb2Ygd2hhdCB0aGUgc3Vic2NyaWJlciB3YW50cyB0
byBkby4mbmJzcDsmbmJzcDsgQXMgYW4gYWx0ZXJuYXRpdmUgdG8gdXNpbmcgdGhlIHdvcmQgJnF1
b3Q7Y2FuJnF1b3Q7IChub3Qgc3VyZSBpZiB0aGlzIGlzIHJlYWxseSBuZWVkZWQpLCByZXBocmFz
aW5nIGl0IHRvICZxdW90OyBJbiBjYXNlcyB3aGVyZSBhIHN1YnNjcmliZXIgd2FudHMgdG8gaGF2
ZSBzZXBhcmF0ZSBkYW1wZW5pbmcgcGVyaW9kcyBmb3IgZGlmZmVyZW50IG9iamVjdHMsIHRoZSBz
dWJzY3JpYmVyIGhhcyB0aGUgb3B0aW9uIHRvIGNyZWF0ZSBtdWx0aXBsZSBzdWJzY3JpcHRpb25z
IHdpdGggZGlmZmVyZW50IHNlbGVjdGlvbiBmaWx0ZXJzLiAmcXVvdDsgJmx0Oy9BTEVYJmd0Ozxv
OnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDox
MC4wNXB0Ij5tdXN0IGlzIGNvcnJlY3QsIHNpbmNlIHRoYXQgaXMgdGhlIG9ubHkgYXZhaWxhYmxl
IHNvbHV0aW9uIHRvIHRoZSBjbGllbnQgaWYgdGhleSB3YW50IGRpZmZlcmVudCBkYW1wZW5pbmcg
cGVyaW9kcy4mbmJzcDsgSS5lLiB0aGUgY2xpZW50cyBjaG9pY2UgaXM6IGRvbid0IGhhdmUgc2Vw
YXJhdGUgZGFtcGVuaW5nIHBlcmlvZHMgb3IgY3JlYXRlIHNlcGFyYXRlIHN1YnNjcmlwdGlvbnMu
Jm5ic3A7IEJ1dCB0aGlzIGlzIGEgbWlub3IgcG9pbnQsIG5vdCB3b3J0aCBsZW5ndGh5IGRpc2N1
c3Npb24sIHNvIHlvdSBjYW4gZGVjaWRlIHdoYXQgdG8gZG8uPGJyPjxicj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAi
PiZsdDtBTEVYLTImZ3Q7T0ssIGtlZXBpbmcgaXQuJmx0Oy9BTEVYLTImZ3Q7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlPigyMSkgU2VjdGlvbiAzLjQsIHNlY29uZCBwYXJhZ3JhcGggZG9l
c24ndCBxdWl0ZSBzY2FuLiZuYnNwOyAmcXVvdDtUaGlzIGluY2x1ZGVzPG86cD48L286cD48L3By
ZT4NCjxwcmU+ICZuYnNwOyZuYnNwOyBpbmRpY2F0aW5nIHRoZSBmYWN0IHRoYXQgYW4gdXBkYXRl
IGlzIGluY29tcGxldGUgYXMgcGFydCBvZiBhIHB1c2gtPG86cD48L286cD48L3ByZT4NCjxwcmU+
ICZuYnNwOyZuYnNwOyB1cGRhdGUgcmVzcGVjdGl2ZWx5IHB1c2gtY2hhbmdlLXVwZGF0ZSBub3Rp
ZmljYXRpb24gLi4uJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+Jmx0O0FMRVgmZ3Q7IEkgdGhpbmsgaXQgZG9lcyBzY2FuLCBidXQgdG8gbWFrZSBpdCBqdXN0
IHNsaWdodGx5IG1vcmUgY2xlYXIsIGhvdyBhYm91dCB1cGRhdGluZyB0byAmcXVvdDsgVGhpcyBp
bmNsdWRlcyBpbmRpY2F0aW5nIHRoZSBmYWN0IHRoYXQgYW4gdXBkYXRlIGlzIGluY29tcGxldGUg
YXMgcGFydCBvZiBhIHB1c2gtdXBkYXRlIChyZXNwZWN0aXZlbHkgcHVzaC1jaGFuZ2UtdXBkYXRl
KSBub3RpZmljYXRpb24sIGFzIHdlbGwgYXMgZW1pdHRpbmcgYSBzdWJzY3JpcHRpb24tc3VzcGVu
ZGVkIG5vdGlmaWNhdGlvbiBhcyBhcHBsaWNhYmxlLiAmcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbHQ7L0FMRVgmZ3Q7PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkl0IGlzIHRoZSAmcXVvdDtwdXNoLXVwZGF0ZSByZXNwZWN0aXZlbHkg
cHVzaC1jaGFuZ2UtdXBkYXRlJnF1b3Q7IHRoYXQgZG9lc24ndCBtYWtlIGFueSBzZW5zZSB0byBt
ZS4mbmJzcDsgRG8geW91IGp1c3QgbWVhbiAmcXVvdDtvciZxdW90OywgZS5nLiAmcXVvdDtwdXNo
LXVwZGF0ZSBvciBwdXNoLWNoYW5nZS11cGRhdGUmcXVvdDs/DQo8bzpwPjwvbzpwPjwvcD4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PHByZT48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+Jmx0O0FMRVgtMiZndDtPSywgY2hhbmdpbmcg
aXQgdG8g4oCcb3LigJ0gKEkgZ3Vlc3MgbXkgbmF0aXZlbmVzcyB0byB0aGUgR2VybWFuIGxhbmd1
YWdlIHNoaW5lcyB0aHJvdWdoIGhlcmUsIGluIHdoaWNoIHRoZXJlIGlzIGEgZmluZXIgZGlzdGlu
Y3Rpb24gYmV0d2VlbiB0d28gdHlwZXMgb2Yg4oCcb3LigJ0sIG9uZSBvZiB3aGljaCBpcyB0aGUg
dGVybSDigJxiZXppZWh1bmdzd2Vpc2XigJ0gKHdoaWNoIHdvdWxkIGJlIHRoZSBwcm9wZXIgY2hv
aWNlIGhlcmUg4oCTIHllcywgc29tZSB3b3JkcyBpbiBHZXJtYW4gYXJlIGxvbmdlciB0aGFuIGlu
IEVuZ2xpc2gsIGV2ZW4gdGhlIGFiYnJldmlhdGlvbiDigJxiencu4oCdIGlzIHN0aWxsIGxvbmdl
ciB0aGFuIOKAnG9y4oCdOy0pLCB3aGljaCB0cmFuc2xhdGVzIHJvdWdobHkgYnV0IHBlcmhhcHMg
bm90IGV4YWN0bHkgaW50byDigJxyZXBlY3RpdmVseeKAnS4pJmx0Oy9BTEVYLTImZ3Q7PC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4oMjIpIFNlY3Rpb24gMy40
LCAzcmQgcGFyYWdyYXBoLCAmcXVvdDthYmxlIGZ1bGZpbGwmcXVvdDsgPSZndDsgJnF1b3Q7YWJs
ZSB0byBmdWxmaWxsJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+Jmx0O0FMRVgmZ3Q7IGNoYW5nZWQgJmx0Oy9BTEVYJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+KDIzKSBTZWN0aW9uIDMuNS4yLCAx
c3QgcGFyYWdyYXBoLCAmcXVvdDtub3QgcmVzdHJpY3RlZCB0byBjb25maWd1cmF0aW9uPG86cD48
L286cD48L3ByZT4NCjxwcmU+b2JqZWN0cyBvbmx5JnF1b3Q7ID0mZ3Q7ICZxdW90O25vdCBvbmx5
IHJlc3RyaWN0ZWQgdG8gY29uZmlndXJhdGlvbiBvYmplY3RzJnF1b3Q7LjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDtBTEVYJmd0OyBjaGFuZ2luZyB0byAmcXVv
dDsgbm90IHJlc3RyaWN0ZWQgdG8gb25seSBjb25maWd1cmF0aW9uIG9iamVjdHMmcXVvdDsmbmJz
cDsgKHRoZSAmcXVvdDtvbmx5JnF1b3Q7IHJlZmVycyB0byB0aGUgY29uZmlndXJhdGlvbiBvYmpl
Y3RzLCBub3QgdG8gdGhlIGZhY3QgdGhhdCBpdCBpcyByZXN0cmljdGVkKSAmbHQ7L0FMRVgmZ3Q7
PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlll
cy4sIE9LLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+KDI0KSBTZWN0
aW9uIDMuNS4yLCAybmQgcGFyYWdyYXBoLCBwb3NzaWJsZSBhbHRlcm5hdGl2ZSB0ZXh0OjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk9MRDo8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4gJm5ic3A7
Jm5ic3A7IEEgcHVibGlzaGVyIHdpbGwgaW5kaWNhdGUgYSBjaGFuZ2UgdG8gdGhlIGVmZmVjdCB0
aGF0IGEgdmFsdWUgb2YgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsmbmJzcDsgZGF0
YXN0b3JlIG5vZGUgaGFzIGJlZW4gdXBkYXRlZCBieSBpbmRpY2F0aW5nIGEgJnF1b3Q7cmVwbGFj
ZSZxdW90OyBvcGVyYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gJm5ic3A7Jm5ic3A7IChh
cHBsaWVkIHRvIHRoZSBkYXRhc3RvcmUgbm9kZSkgaW4gdGhlIHBhdGNoLiZuYnNwOyBXaGVuIGEg
bmV3IGRhdGFzdG9yZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsmbmJzcDsgbm9kZSB3
YXMgY3JlYXRlZCAob3RoZXIgdGhhbiBhbiBlbnRyeSBpbiBhIHVzZXIgb3JkZXJlZCBsaXN0KSwg
YTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsmbmJzcDsgcHVibGlzaGVyIHdpbGwgaW5k
aWNhdGUgYSAmcXVvdDtjcmVhdGUmcXVvdDsgb3BlcmF0aW9uIGluIHRoZSBwYXRjaC4mbmJzcDsg
V2hlbiBhPG86cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZuYnNwOyBkYXRhc3RvcmUgbm9k
ZSB3YXMgZGVsZXRlZCwgdGhlIHB1Ymxpc2hlciBpbmRpY2F0ZXMgdGhpcyBieSBhPG86cD48L286
cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZuYnNwOyAmcXVvdDtkZWxldGUmcXVvdDsuJm5ic3A7IFdo
ZW4gYSBuZXcgZW50cnkgaW4gYSB1c2VyLW9yZGVyZWQgbGlzdCB3YXMgY3JlYXRlZCwgdGhlPG86
cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZuYnNwOyBwdWJsaXNoZXIgaW5kaWNhdGVzIHRo
aXMgYnkgYW4gJnF1b3Q7aW5zZXJ0JnF1b3Q7IG9wZXJhdGlvbi4gV2hlbiBhbiBlbnRyeSBpbjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsmbmJzcDsgYSB1c2VyLW9yZGVyZWQgbGlzdCB3
YXMgbW92ZWQsIHRoZSBwdWJsaXNoZXIgaW5kaWNhdGVzIHRoaXMgYnkgYTxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiAmbmJzcDsmbmJzcDsgJnF1b3Q7bW92ZSZxdW90OyBvcGVyYXRpb24uPG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+TkVXOjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsg
QSBwdWJsaXNoZXIgaW5kaWNhdGVzIHRoZSB0eXBlIG9mIGNoYW5nZSB0byBhIGRhdGFzdG9yZSBu
b2RlIHVzaW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlIGRpZmZlcmVudCBZQU5HIHBhdGNo
IG9wZXJhdGlvbnM6Jm5ic3A7IHRoZSAmcXVvdDtjcmVhdGUmcXVvdDsgb3BlcmF0aW9uIGlzIHVz
ZWQgZm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+bmV3bHkgY3JlYXRlZCBvYmplY3RzIChleGNl
cHQgZW50cmllcyBpbiBhIHVzZXItb3JkZXJlZCBsaXN0KSwgdGhlPG86cD48L286cD48L3ByZT4N
CjxwcmU+JnF1b3Q7ZGVsZXRlJnF1b3Q7IG9wZXJhdGlvbiBpcyB1c2VkIGZvciBkZWxldGVkIG9i
amVjdHMgKGluY2x1ZGluZyBpbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnVzZXItb3JkZXJlZCBs
aXN0cyksIHRoZSAmcXVvdDtyZXBsYWNlJnF1b3Q7IG9wZXJhdGlvbiBpcyB1c2VkIHdoZW4gb25s
eSB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5vYmplY3QgdmFsdWUgY2hhbmdlcywgdGhlICZx
dW90O2luc2VydCZxdW90OyBvcGVyYXRpb24gaXMgdXNlZCB3aGVuIGEgbmV3IGVudHJ5IGlzPG86
cD48L286cD48L3ByZT4NCjxwcmU+aW5zZXJ0ZWQgaW4gYSBsaXN0LCBhbmQgdGhlICZxdW90O21v
dmUmcXVvdDsgb3BlcmF0aW9uIGlzIHVzZWQgd2hlbiBhbiBleGlzdGluZzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPmVudHJ5IGluIGEgdXNlci1vcmRlcmVkIGxpc3QgaXMgbW92ZWQuPG86cD48L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jmx0O0FMRVgmZ3Q7IE9LIChJIGRvbid0
IGZlZWwgc3Ryb25nbHkgYWJvdXQgdGhpcykgJmx0Oy9BTEVYJmd0OzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+KDI1KSBTZWN0aW9uIDMuNS4yLCBsYXN0IHBhcmFncmFwaDogSWYgeW91IHdh
bnQgdG8gYWxsb3cgZHVwbGljYXRlPG86cD48L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7Y3JlYXRl
JnF1b3Q7IGFuZCAmcXVvdDtkZWxldGUmcXVvdDsgZXZlbnRzLCB0aGVuIGl0IG1pZ2h0IGJlIGNs
ZWFuZXIgdG8gZW5jb2RlIHRoZW0gYXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mcXVvdDttZXJn
ZSZxdW90OyBhbmQgJnF1b3Q7cmVtb3ZlJnF1b3Q7PyZuYnNwOyBJLmUuIGl0IHNlZW1zIHRoYXQg
eW91IGhhdmUgY3JlYXRlZCBhIHNsaWdodGx5PG86cD48L286cD48L3ByZT4NCjxwcmU+ZGlmZmVy
ZW50IGVuY29kaW5nIGZyb20gdmFuaWxsYSBZQU5HIHBhdGNoIGJlY2F1c2Ugb2YgdGhlIHdheSB0
aGF0PG86cD48L286cD48L3ByZT4NCjxwcmU+ZXJyb3JzIGFyZSBoYW5kbGVkIGRpZmZlcmVudGx5
LiZuYnNwOyBJZGVhbGx5LCBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgYSBjbGllbnQ8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5jb3VsZCBqdXN0IGFwcGx5IHRoaXMgYXMgcmVndWxhciBZQU5HIHBhdGNo
LCBidXQgdGhpcyBvbmx5IHdvcmtzIHdpdGg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGUgZW5j
b2RpbmcgZGVzY3JpYmVkIGhlcmUgaWYgdGhlIGNsaWVudHMgY29weSBvZiB0aGUgZGF0YXN0b3Jl
IGlzIGluPG86cD48L286cD48L3ByZT4NCjxwcmU+c3luYyB3aXRoIHRoZSBzZXJ2ZXJzIG9sZCBj
b3B5IG9mIHRoZSBkYXRhc3RvcmUgYXQgdGhlIHBvaW50IHRoYXQgdGhlPG86cD48L286cD48L3By
ZT4NCjxwcmU+cGF0Y2ggaXMgZ2VuZXJhdGVkIGZyb20uJm5ic3A7IFRoaXMgc2VlbXMgc2xpZ2h0
bHkgZnJhZ2lsZSB0byB1bmV4cGVjdGVkPG86cD48L286cD48L3ByZT4NCjxwcmU+aW5jb25zaXN0
ZW5jaWVzIGJldHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXIgKHdoaWNoIEkgYXBwcmVjaWF0ZSB0aGF0
IHlvdTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRyeSBhbmQgYXZvaWQpLjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDtBTEVYJmd0OyBIbW0uJm5ic3A7IFdoaWxl
IGl0IG1heSBiZSBwb3NzaWJsZSB0byByZXBsYWNlICZxdW90O2RlbGV0ZSZxdW90OyB3aXRoICZx
dW90O3JlbW92ZSZxdW90OywgSSBhbSBub3Qgc28gc3VyZSBhYm91dCB0aGUgJnF1b3Q7bWVyZ2Um
cXVvdDsgcGFydC4mbmJzcDsgQXQgdGhlIGVuZCBvZiB0aGUgZGF5LCB0aGUgdXNlIGhlcmUgaXMg
ZGlmZmVyZW50IGZyb20gaGF2aW5nIGEgY2xpZW50IGFwcGx5IGEgcGF0Y2ggb3BlcmF0aW9uIHRv
IHRoZSBzZXJ2ZXIsIGFuZCB0aGUgc2VtYW50aWNzIG1heSBiZSBhIGxpdHRsZSBjbGVhcmVyIGJ5
IGtlZXBpbmcgdGhpbmdzIGFzIHRoZXkgYXJlLCBzbyB3b3VsZCBwcmVmZXIgdG8ga2VlcCB0aGlu
Z3MgYXMgZGVmaW5lZCBub3cuJm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDsvQUxF
WCZndDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkkgdGhpbmsgdGhhdCBpcyBwcm9iYWJseSByaWdodC48YnI+DQo8YnI+DQpJIHRo
aW5rIHRoYXQgaXQgaXMgYSBzbGlnaHQgc2hhbWUgdGhhdCB2YW5pbGxhIFlBTkcgcGF0Y2ggd29u
J3Qgd29yayBoZXJlLCBidXQgYXMgeW91IHNheSBJIHRoaW5rIHRoYXQgaXQgd2lsbCBuZWVkIHRv
IGJlIGFwcGxpZWQgaW4gYSBzbGlnaHRseSBkaWZmZXJlbnQgd2F5IHJlZ2FyZGxlc3MuPGJyPg0K
PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+Jmx0O0FMRVgtMiZndDtPSy4g
S2VlcGluZyBpdC4mbHQ7L0FMRVgtMiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp
bmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwcmU+KDI2KSBTZWN0aW9uIDMuNiwgc2Vjb25kIHBhcmFncmFwaCwgd291bGQgaXQgbm90
IGJlIGVhc2llciB0byBhbGxvdyB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jbGllbnQgdG8g
cmVwbGFjZSBhbiBleGlzdGluZyBmaWx0ZXIgcmF0aGVyIHRoYW4gaGF2aW5nIHRvIGV4cGxpY2l0
bHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZW1vdmUgdGhlIG9sZCBmaWx0ZXIgYW5kIGFkZCB0
aGUgbmV3IG9uZT8mbmJzcDsgT3IgaWYgeW91IG1lYW4gdGhhdCBhbnkgbmV3PG86cD48L286cD48
L3ByZT4NCjxwcmU+ZmlsdGVyIHJlcGxhY2VzIHRoZSBleGlzdGluZyBmaWx0ZXIsIHRoZW4gdGhp
cyBtYXkgYmUgbW9yZSBjbGVhcmx5PG86cD48L286cD48L3ByZT4NCjxwcmU+aW5kaWNhdGVkIHdp
dGggdGhlIHRleHQ6ICZxdW90O0FuIFJQQyByZXF1ZXN0IHByb3Bvc2luZyBhIG5ldyBzZWxlY3Rp
b248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5maWx0ZXIgcmVwbGFjZXMgYW55IGV4aXN0aW5nIGZp
bHRlci4gJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jmx0
O0FMRVgmZ3Q7IE9LLCBjaGFuZ2luZyBwZXIgeW91ciBzdWdnZXN0aW9uIHRvIG1ha2UgaXQgY2xl
YXIgdGhhdCB0aGUgZXhpc3RpbmcgZmlsdGVyIGlzIHJlcGxhY2VkLiZuYnNwOyAmbHQ7L0FMRVgm
Z3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHBy
ZT4oMjcpIFNlY3Rpb24gMy42LCBwYXJhZ3JhcGggNiwgc3RhcnRpbmcgJnF1b3Q7WFBhdGgmcXVv
dDsuJm5ic3A7IFRoZSAmcXVvdDtib29sZWFuJnF1b3Q7IGV4YW1wbGU8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5pcyB1bmNsZWFyIHRvIG1lIGdpdmVuIHRoYXQgYSB4cGF0aCBmaWx0ZXIgYWx3YXlz
IHJldHVybnMgYSBub2RlIHNldCBzbzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNhbid0IHJldHVy
biBhIGJvb2xlYW4gcmVzdWx0LiZuYnNwOyBJIGFsc28gc3VnZ2VzdCBjaGFuZ2luZyAmcXVvdDtw
YXNzZXMgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRhdGFzdG9yZSBub2RlJnF1b3Q7IHRvJm5i
c3A7ICZxdW90O2luY2x1ZGVzIGEgZGF0YXN0b3JlIG5vZGUmcXVvdDsuPG86cD48L286cD48L3By
ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jmx0
O0FMRVgmZ3Q7IHJlbW92ZWQgdGhlIHNlbnRlbmNlIGFuZCBzaG9ydGVuZWQgdGhlIHBhcmFncmFw
aC4mbmJzcDsgSXQgbm93IHJlYWRzIGFzIGZvbGxvd3M6IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZxdW90OyBYUGF0aCBpdHNlbGYgcHJvdmlkZXMgcG93ZXJmdWwgZmlsdGVyaW5nIGNvbnN0cnVj
dHMgYW5kIGNhcmUgbXVzdCBiZSB1c2VkIGluIGZpbHRlciBkZWZpbml0aW9uLiBDb25zaWRlciBh
biBYUGF0aCBmaWx0ZXIgd2hpY2ggb25seSBwYXNzZXMgYSBkYXRhc3RvcmUgbm9kZSB3aGVuIGFu
IGludGVyZmFjZSBpcyB1cC4gSXQgaXMgdXAgdG8gdGhlIHJlY2VpdmVyIHRvIHVuZGVyc3RhbmQg
aW1wbGljYXRpb25zIG9mIHRoZSBwcmVzZW5jZSBvciBhYnNlbmNlIG9mIG9iamVjdHMgaW4gZWFj
aCB1cGRhdGUuICZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDsvQUxFWCZndDs8bzpw
PjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0suPGJy
Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4oMjgpIFNl
Y3Rpb24gMy42LCBwYXJhZ3JhcGggNy4mbmJzcDsgSSB0aGluayB0aGF0IHRoZSB0ZXh0IG11c3Qg
YmUgbW9yZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmV4cGxpY2l0IG9uIHdoZW4gdGhlIGZpbHRl
ciBpcyBldmFsdWF0ZWQgZm9yIGEgcGVyaW9kaWMgc3Vic2NyaXB0aW9uLjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPkFtIEkgcmlnaHQgaW4gdGhpbmtpbmcgdGhhdCBpdCBpcyBvbmx5IGV2YWx1YXRl
ZCBvbmNlIHdoZW4gdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+c3Vic2NyaXB0aW9uIGlzIGNy
ZWF0ZWQsIG9yIHRoZSBzdWJzY3JpcHRpb24gaXMgY2hhbmdlZD8gU3BlY2lmaWNhbGx5LDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPmlmIHRoZSBub2Rlc2V0IGV2YWx1YXRlZCBkdXJpbmcgdGhlIGxp
ZmV0aW1lIG9mIGFuIFhwYXRoIHN1YnNjcmlwdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNo
YW5nZXMgdGhlbiBkb2VzIHRoYXQgYWZmZWN0IHdoaWNoIG5vZGVzIGFyZSByZXR1cm5lZD88bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3Rl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbHQ7QUxFWCZndDsgTm90IHN1
cmUgd2hhdCBjaGFuZ2VzIHlvdSBhcmUgbG9va2luZyBmb3IuJm5ic3A7IFRoZSBmaWx0ZXIgaXMg
aW4gZWZmZWN0IHRocm91Z2hvdXQgdGhlIHN1YnNjcmlwdGlvbiB1bnRpbCBpdCBpcyBjaGFuZ2Vk
LiZuYnNwOyBJdCBpcyB1cCB0byBhbiBpbXBsZW1lbnRhdGlvbiB0byBkZWNpZGUgd2hldGhlciB0
byBhcHBseSBpdCBvbmNlIHdoZW4gdGhlIHN1YnNjcmlwdGlvbiBpcyBlc3RhYmxpc2hlZCB0byBk
ZXRlcm1pbmUgdGhlIGRhdGFzdG9yZSBub2RlcyAodHJhY2tpbmcgYW55IHN1YnRyZWUgY2hhbmdl
cyB0byBtYWtlIHN1cmUgbm9kZXMgaW4gdGhlIHN1YnRyZWVzIGFyZSBpbmNsdWRlZCBhcyBuZWVk
ZWQpLCBvciB3aGV0aGVyIHRvIGFwcGx5IGl0IGF0IGVhY2ggdXBkYXRlIGFuZXcuJm5ic3A7Jm5i
c3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGZhciBhcyByZWNlaXZlciBhdXRo
b3JpemF0aW9uIGlzIGNvbmNlcm5lZCAoaS5lLiBhY2Nlc3MgY29udHJvbCBmaWx0ZXJzKSwgdGhp
cyBpcyBleHBsYWluZWQgaW4gc2VjdGlvbiAzLjkuJm5ic3A7IEFwcGx5aW5nIG5vIHRleHQgY2hh
bmdlcyBhdCB0aGlzIHBvaW50IHVubGVzcyB5b3UgY2FuIGJlIG1vcmUgY2xlYXIgb24gd2hhdCB5
b3Ugd291bGQgbGlrZSB0byBzZWU/PG86cD48L286cD48L3ByZT4NCjxwcmU+Jmx0Oy9BTEVYJmd0
OzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P
Sy4mbmJzcDsgTm90IGNvbnNpZGVyaW5nIE5BQ00sIEkgdGhpbmsgdGhhdCBpcyBhbHJlYWR5IGNv
dmVyZWQsIHdhcyB0aGlua2luZyBvZiBhbiBYcGF0aCBmaWx0ZXIuJm5ic3A7IEkgYW0gcmlnaHQg
aW4gdGhpbmtpbmcgdGhhdCBsb2dpY2FsbHkgdGhlIFhwYXRoIGZpbHRlciBpcyBbcmUtXWFwcGxp
ZWQgd2hlbmV2ZXIgdGhlIHBlcmlvZGljIHB1c2ggbm90aWZpY2F0aW9uIGlzIGNvbnN0cnVjdGVk
Ljxicj4NCjxicj4NCklmIHNvLCBwb3NzaWJseSBjaGFuZ2U6PGJyPg0KPGJyPg0KJnF1b3Q7Jm5i
c3A7Jm5ic3A7IDx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+V2hlbiB0aGUgc2V0
IG9mIHNlbGVjdGlvbiBmaWx0ZXJpbmcgY3JpdGVyaWEgaXMgYXBwbGllZCBmb3IgYTwvc3Bhbj48
L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHBlcmlvZGljIHN1YnNjcmlwdGlv
biwgYWxsIHNlbGVjdGVkIGRhdGFzdG9yZSBub2RlcyB0byB3aGljaCBhPC90dD48YnI+DQo8dHQ+
Jm5ic3A7Jm5ic3A7IHJlY2VpdmVyIGhhcyBhY2Nlc3MgYXJlIHByb3ZpZGVkIHRvIHRoYXQgcmVj
ZWl2ZXIuPC90dD48L3NwYW4+JnF1b3Q7PGJyPg0KPGJyPg0KVG8gc29tZXRoaW5nIGFsb25nIHRo
ZSBsaW5lcyBvZiAuLi48YnI+DQo8YnI+DQomcXVvdDsmbmJzcDsmbmJzcDsgPHR0PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0Ij5XaGVuIHRoZSBzZXQgb2Ygc2VsZWN0aW9uIGZpbHRlcmlu
ZyBjcml0ZXJpYSBpcyBhcHBsaWVkIGZvciBhPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0
dD4mbmJzcDsgcGVyaW9kaWMgc3Vic2NyaXB0aW9uLCB0aGVuIHRoZXkgYXJlIGFwcGxpZWQgd2hl
bmV2ZXIgYSBwZXJpb2RpYzwvdHQ+PGJyPg0KPHR0PiZuYnNwOyB1cGRhdGUgcmVjb3JkIGlzIGNv
bnN0cnVjdGVkLCBhbmQgb25seSBkYXRhc3RvcmUgbm9kZXMgdGhhdCBwYXNzPC90dD48YnI+DQo8
dHQ+Jm5ic3A7IHRoZSBmaWx0ZXIgYW5kIHRvIHdoaWNoIGEgcmVjZWl2ZXIgaGFzIGFjY2VzcyBh
cmUgcHJvdmlkZWQgdG88L3R0Pjxicj4NCjx0dD4mbmJzcDsgdGhhdCByZWNlaXZlci48L3R0Pjwv
c3Bhbj4mcXVvdDs8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj4mbHQ7QUxFWC0yJmd0O09LLCBJIGFtIG1ha2luZyB0
aGUgY2hhbmdlIGFzIHN1Z2dlc3RlZC4mbmJzcDsgKEhvd2V2ZXIsIHByZXN1bWFibHkgYW4gaW1w
bGVtZW50YXRpb24gY291bGQgY2hvb3NlIHRvIGFwcGx5IHRoZSBmaWx0ZXIgdG8gc2VsZWN0IHRo
ZSBzZXQgb2YgZGF0YXN0b3JlIG5vZGVzIG9uY2UsIGFuZCB0aGVuLA0KIGFzc3VtaW5nIHRoZSBm
aWx0ZXIgYW5kIHNldCBvZiBkYXRhc3RvcmUgbm9kZXMgZG9u4oCZdCBjaGFuZ2UsIHNpbXBseSBz
ZW5kIHVwZGF0ZXMgYWJvdXQgdGhlIG5vZGVzIGZvcm0gdGhlIHNldCwgbm8/KSAmbHQ7L0FMRVgt
MiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93
dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxwcmU+KDI5KSBTZWN0aW9uIDMuNywgcGFyYWdyYXBoIDM6Jm5ic3A7IFBl
cmhhcHMgbWFrZSB0aGlzIHRleHQgY29uZGl0aW9uYWwgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5kYW1wZW5lZCBzdWJzY3JpcHRpb25zLiZuYnNwOyBQcmVzdW1hYmx5IGZvciBub24gZGFtcGVu
ZWQgc3Vic2NyaXB0aW9ucyBhbGw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jaGFuZ2VzIGFyZSBy
ZXBvcnRlZCBhcyBzZXBhcmF0ZSBwdXNoLWNoYW5nZS11cGRhdGUgbm90aWZpY2F0aW9ucz88bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PTEQ6PG86
cD48L286cD48L3ByZT4NCjxwcmU+SW4gY2FzZXMgd2hlcmUgbXVsdGlwbGUgY2hhbmdlcyBoYXZl
IG9jY3VycmVkIGFuZCB0aGUgb2JqZWN0PG86cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZu
YnNwOyBoYXMgbm90IGJlZW4gZGVsZXRlZCwgdGhlIG9iamVjdCdzIG1vc3QgY3VycmVudCB2YWx1
ZSBpcyByZXBvcnRlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5ORVc6PG86cD48L286cD48L3ByZT4NCjxwcmU+SW4gY2FzZXMgd2hlcmUgbXVs
dGlwbGUgY2hhbmdlcyBoYXZlIG9jY3VycmVkIGluIGEgc3Vic2NyaXB0aW9uIHRoYXQgaGFzPG86
cD48L286cD48L3ByZT4NCjxwcmU+ZGFtcGVuaW5nIGVuYWJsZWQsIGFuZCB0aGUgb2JqZWN0PG86
cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZuYnNwOyBoYXMgbm90IGJlZW4gZGVsZXRlZCwg
dGhlIG9iamVjdCdzIG1vc3QgY3VycmVudCB2YWx1ZSBpcyByZXBvcnRlZC48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbHQ7QUxFWCZndDsgV2VsbCwgdGhlIHRleHQg
c3RhdGVzIGNsZWFybHkgdGhhdCB0aGlzIGNvbmNlcm5zIGFueSBjaGFuZ2VzIHNpbmNlIHRoZSBs
YXN0IG5vdGlmaWNhdGlvbiBtZXNzYWdlLiZuYnNwOyBTbywgdGhlIGZhY3QgdGhhdCBkYW1wZW5p
bmcgaXMgZW5hYmxlZCBpcyBhbHJlYWR5IGltcGxpZWQuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PkhvdyBhYm91dCByZXBocmFzaW5nIHNsaWdodGx5IGFzIGZvbGxvd3M6PG86cD48L286cD48L3By
ZT4NCjxwcmU+JnF1b3Q7IEluIGNhc2VzIHdoZXJlIG11bHRpcGxlIGNoYW5nZXMgaGF2ZSBvY2N1
cnJlZCBvdmVyIHRoZSBjb3Vyc2Ugb2YgYSBkYW1wZW5pbmcgcGVyaW9kIGFuZCB0aGUgb2JqZWN0
IGhhcyBub3QgYmVlbiBkZWxldGVkLCB0aGUgb2JqZWN0J3MgbW9zdCBjdXJyZW50IHZhbHVlIGlz
IHJlcG9ydGVkLiZuYnNwOyAmcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbHQ7L0FMRVgm
Z3Q7PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlRoaXMgdGV4dCBpcyBmaW5lLjxicj4NCjxicj4NCkJ1dCB0aGlzIHJhaXNlcyBhbm90aGVyIHF1
ZXN0aW9uOjxicj4NCjxicj4NCklmIG5vIGRhbXBlbmluZyBpcyBlbmFibGVkLCB0aGVuIGlzIGl0
IGV4cGVjdGVkIHRoYXQgYWxsIGNoYW5nZXMgdG8gYW4gb2JqZWN0IGFyZSBhbHdheXMgbm90aWZp
ZWQuJm5ic3A7IFtJZiB0aGlzIGlzIGEgcmVxdWlyZW1lbnQsIHRoZW4gSSB0aGluayB0aGF0IGl0
IHNob3VsZCBwcm9iYWJseSBiZSBzdGF0ZWQgY2xlYXJseSBpbiB0aGUgWUFORyBtb2RlbCBhbmQg
cGVyaGFwcyBpbiBzZWN0aW9uIDMgYXMgd2VsbC5dPGJyPg0KPGJyPg0KU3BlY2lmaWNhbGx5LCBz
YXkgeW91IGFyZSBtb25pdG9yaW5nIGludGVyZmFjZSBzdGF0ZSwgd2l0aG91dCBkYW1wZW5pbmcs
IGFuZCBpdCBzdGFydHMgdG8gZmxhcCAxMDAgdGltZXMgcGVyIHNlY29uZC4mbmJzcDsgSXMgdGhl
IHB1Ymxpc2hlciByZXF1aXJlZCB0byBub3RpZnkgb2YgZXZlcnkgc2luZ2xlIGNoYW5nZS4mbmJz
cDsgT3IgaXMgdGhlIHB1Ymxpc2hlciBvbmx5IHJlcXVpcmVkIHRvIG5vdGlmeSB0aGF0IHRoZSBh
dCBsZWFzdCBvbmUgY2hhbmdlIGhhcyBvY2N1cnJlZCwNCiBhbmQgZ3VhcmFudGVlIHRoYXQgaXQg
YWx3YXlzIG5vdGlmaWVzIHRoZSBsYXRlc3QgdmFsdWUuPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUw
Ij4mbHQ7QUxFWC0yJmd0OyBUaGlzIGlzIGV4YWN0bHkgdGhlIHJlYXNvbiB3aHkgZGFtcGVuaW5n
IHdhcyBpbnRyb2R1Y2VkLiZuYnNwOyBJIHRoaW5rIHRoaXMgaXMgd2VsbCBkb2N1bWVudGVkLiZu
YnNwOyBJZiBhIHN1YnNjcmliZXIgZG9lcyBub3QgdHVybiBvbiBkYW1wZW5pbmcsIGFuZCB0aHVz
IHRoZSBzZXJ2ZXIgZ2V0cyBvdmVyd2hlbG1lZCwgdGhleSBjYW4gc3VzcGVuZA0KIG9yIHRlcm1p
bmF0ZSB0aGUgc3Vic2NyaXB0aW9uLiZuYnNwOyBJbiB0aGF0IGNhc2UgdGhleSBzaG91bGQgZ2l2
ZSBhIOKAnHBlcmlvZC11bnN1cHBvcnRlZOKAnSBlcnJvci4mbmJzcDsNCjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+VGhpbmtpbmcgYWJv
dXQgaXQgc29tZSBtb3JlLCB0aGlzIG5lZWRzIHRvIGJlIG1vcmUgY2xlYXJseSBzcGVsbGVkIG91
dCBpbiB0aGUgZGVzY3JpcHRpb24gb2Yg4oCccGVyaW9kLXVuc3VwcG9ydGVk4oCdLiZuYnNwOw0K
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUw
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMwMEIwNTAiPkNoYW5naW5nIHRoZSBZQU5HIGRlZmluaXRpb24gKGRlc2NyaXB0aW5vIHN0YXRl
bWVudCkgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NC44cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7IGlkZW50
aXR5IHBlcmlvZC11bnN1cHBvcnRlZCB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQuOHB0Ij48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPiZuYnNw
OyZuYnNwOyZuYnNwOyBiYXNlIHNuOmVzdGFibGlzaC1zdWJzY3JpcHRpb24tZXJyb3I7PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
OjQuOHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyBiYXNlIHNuOm1vZGlmeS1z
dWJzY3JpcHRpb24tZXJyb3I7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQuOHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNw
OyZuYnNwOyBiYXNlIHNuOnN1YnNjcmlwdGlvbi1zdXNwZW5kZWQtcmVhc29uOzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo0Ljhw
dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb24NCjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo0
LjhwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
cXVvdDtSZXF1ZXN0ZWQgdGltZSBwZXJpb2Qgb3IgZGFtcGVuaW5nLXBlcmlvZCBpcyB0b28gc2hv
cnQuIFRoaXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDo0LjhwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDtjYW4gYmUgZm9yIGJvdGggcGVyaW9kaWMgYW5kIG9uLWNoYW5nZSBz
dWJzY3JpcHRpb25zICh3aXRoIG9yDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NC44cHQiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7d2l0aG91dCBkYW1wZW5pbmcuKSBIaW50cyBz
dWdnZXN0aW5nIGFsdGVybmF0aXZlIHBlcmlvZHMgbWF5DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NC44cHQiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw
QjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YmUgcmV0dXJuZWQgYXMg
c3VwcGxlbWVudGFsIGluZm9ybWF0aW9uLiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPiZuYnNwOyB9PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUwIj4mbHQ7L0FMRVgtMiZn
dDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+KDMwKSBTZWN0aW9uIDMuNywg
cGFyYWdyYXBoIDUsICZxdW90O0V0aGVybmV0IHBvcnQmcXVvdDsgPSZndDsgJnF1b3Q7RXRoZXJu
ZXQgaW50ZXJmYWNlJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+Jmx0O0FMRVgmZ3Q7IGNoYW5nZWQgJmx0Oy9BTEVYJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+KDMxKSBTZWN0aW9uIDMuNywgbGFz
dCBwYXJhZ3JhcGg6IFdoeSBzdGFydCBhdCAmcXVvdDsxJnF1b3Q7IHJhdGhlciB0aGFuICZxdW90
OzAmcXVvdDsuIE9uPG86cD48L286cD48L3ByZT4NCjxwcmU+b3ZlcmZsb3csIHdoeSBvdmVyZmxv
dyB0byAmcXVvdDsxJnF1b3Q7IHJhdGhlciB0aGFuICZxdW90OzAmcXVvdDssIGlzIHRoYXQgZGVs
aWJlcmF0ZT8mbmJzcDsgSWY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT55b3UgYXJlIGdvaW5nIHRv
IGZvcmNlIGl0IHRvICZxdW90OzEmcXVvdDsgdGhlbiBJIHdvdWxkIGFsc28gcmVzdHJpY3QgdGhl
IHVwcGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+Ym91bmQgdG8gaW50MzIgbWF4IHJhdGhlciB0
aGFuIHVpbnQzMiBtYXggdG8gbWFrZSBsaWZlIGVhc2llciBpbiBKYXZhPG86cD48L286cD48L3By
ZT4NCjxwcmU+bGFuZCAuLi48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbHQ7QUxFWCZndDsgT0ssIGdvdCBpdC4mbmJz
cDsgVXBkYXRlZCB0aGUgdGV4dCB0byByZWZsZWN0IHN0YXJ0IGF0IDAuJm5ic3A7IDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZsdDsvQUxFWCZndDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT4oMzIpIFNlY3Rpb24gMy44LCB0cmVlIGRpYWdyYW1zLiZuYnNwOyBJIHdvdWxkIHRoaW5rIHRo
YXQgYW5vdGhlciBrZXkgbWV0cmljPG86cD48L286cD48L3ByZT4NCjxwcmU+cmVnYXJkaW5nIHdo
ZXRoZXIgYSBzdWJzY3JpcHRpb24gY2FuIGJlIHNhdGlzZmllZCB3b3VsZCBiZSBvYmplY3QtcmF0
ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFuZCBkYXRhLXJhdGUuJm5ic3A7IEUuZy4gYSBwdWJs
aXNoZXIgaW1wbGVtZW50YXRpb24gbWF5IGJlIGFibGUgdG8gcHVzaCAxMDBrPG86cD48L286cD48
L3ByZT4NCjxwcmU+b2JqZWN0cy9zZWNvbmQsIHNvIGEgY2xpZW50IGhhcyBhIGNob2ljZSBvZiBl
aXRoZXIgbW9uaXRvcmluZyBsZXNzPG86cD48L286cD48L3ByZT4NCjxwcmU+b2JqZWN0cywgb3Ig
ZGVjcmVhc2luZyB0aGUgcGVyaW9kLiZuYnNwOyBIZW5jZSBJIHdhcyB3b25kZXJpbmcgd2hldGhl
ciByYXRlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNob3VsZCBiZSBwcm92aWRlZCBpbiBhZGRp
dGlvbiB0byB0aGUgb2JqZWN0LWNvdW50LWVzdGltYXRlL2xpbWl0IGFuZDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPmtpbG9ieXRlLWVzdGltYXRlL2xpbWl0LiZuYnNwOyBPZiBjb3Vyc2UsIGEgcmF0
ZSBpcyBhbHNvIGltcGxpY2l0bHkgZGVmaW5lZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmJ5IGlu
Y2x1ZGluZyB0aGUgcGVyaW9kIGhpbnQsIHNvIHBlcmhhcHMgdGhhdCBpcyBzdWZmaWNpZW50IHdp
dGhvdXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5uZWVkaW5nIHRvIHNlbmQgbW9yZSBmaWVsZHMg
YmFjayB0byB0aGUgY2xpZW50LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlPiZsdDtBTEVYJmd0OyBXb3VsZCBwcmVmZXIgdG8ga2VlcCB0aGlzIHRvIHRoZSBiYXNpY3Ms
IGkuZS4gYXMtaXMuJm5ic3A7IEFzIG1lbnRpb25lZCwgeW91IGNhbiBjb21wdXRlIGEgcmF0ZSBm
cm9tIHRoaXMuJm5ic3A7ICZsdDsvQUxFWCZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB0aGF0IGlzIGZpbmUuJm5ic3A7IEFkZGl0
aW9uYWwgZmllbGRzIGNvdWxkIGJlIGF1Z21lbnRlZCBpbiBmdXR1cmUgaWYgbmVlZGVkLjxicj4N
Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+KDMzKSBTZWN0aW9uIDMu
OSwgMm5kIHBhcmFncmFwaCwgJnF1b3Q7cGFydGljdWxhciBlYWNoJnF1b3Q7ID0mZ3Q7ICZxdW90
O3BhcnRpY3VsYXImcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbHQ7QUxFWCZndDsgY2hhbmdlZCAmbHQ7L0FM
RVgmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4oMzQpIFNlY3Rpb24gMy45LCAzcmQg
cGFyYWdyYXBoOiZuYnNwOyBJdCB3YXMgbm90IGVudGlyZWx5IG9idmlvdXMgdG8gbWUgd2hhdDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZSAzcmQgcGFyYWdyYXBoIHRleHQgKHJlcHJvZHVjZWQg
YmVsb3cpIGFjdHVhbGx5IG1lYW5zLiZuYnNwOyBJIHRoaW5rIHRoYXQ8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT50aGlzIGJvaWxzIGRvd24gdG86Jm5ic3A7IElmLCBhZnRlciBhY2Nlc3MgY29udHJv
bCBoYXMgYmVlbiBhcHBsaWVkLCB0aGVyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFyZSBubyBv
YmplY3RzIHJlbWFpbmluZyBpbiBhbiB1cGRhdGUgcmVjb3JkIHRoZW4gb25seSBhIHNpbmdsZSBl
bXB0eTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZxdW90O3B1c2gtdXBkYXRlJnF1b3Q7IG5vdGlm
aWNhdGlvbiBNQVkgYmUgc2VudCBhbmQgZW1wdHkgJnF1b3Q7cHVzaC1jaGFuZ2UtdXBkYXRlJnF1
b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+bWVzc2FnZXMgTVVTVCBOT1QgYmUgc2VudC4mbmJz
cDsgVGhpcyBpcyByZXF1aXJlZCB0byBlbnN1cmUgdGhhdCBjbGllbnRzPG86cD48L286cD48L3By
ZT4NCjxwcmU+Y2Fubm90IHN1cnJlcHRpdGlvdXNseSBtb25pdG9yIG9iamVjdHMgdGhhdCB0aGV5
IGRvIG5vdCBoYXZlIGFjY2VzcyB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnZpYSBjYXJlZnVs
bHkgY3JhZnRlZCBzZWxlY3Rpb24gZmlsdGVycy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mcXVvdDtBIHB1Ymxpc2hlciBNVVNUIGFsbG93IGZv
ciB0aGUgcG9zc2liaWxpdHkgdGhhdCBhIHN1YnNjcmlwdGlvbidzPG86cD48L286cD48L3ByZT4N
CjxwcmU+ICZuYnNwOyZuYnNwOyBzZWxlY3Rpb24gZmlsdGVyIHJlZmVyZW5jZXMgbm9uLWV4aXN0
ZW50IG9yIGFjY2Vzcy1wcm90ZWN0ZWQgZGF0YS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gJm5i
c3A7Jm5ic3A7IFN1Y2ggc3VwcG9ydCBwZXJtaXRzIGEgcmVjZWl2ZXIgdGhlIGFiaWxpdHkgdG8g
bW9uaXRvciB0aGUgZW50aXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZuYnNwOyBs
aWZlY3lsZSBvZiBzb21lIGRhdGFzdG9yZSB0cmVlLiZuYnNwOyBJbiB0aGlzIGNhc2UsIGFsbCAm
cXVvdDtwdXNoLXVwZGF0ZSZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsmbmJz
cDsgbm90aWZpY2F0aW9ucyBtdXN0IGJlIHNlbnQgZW1wdHksIGFuZCBubyAmcXVvdDtwdXNoLWNo
YW5nZS11cGRhdGUmcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gJm5ic3A7Jm5ic3A7IG5v
dGlmaWNhdGlvbnMgd2lsbCBiZSBzZW50IHVudGlsIHNvbWUgZGF0YSBiZWNvbWVzIHZpc2libGUg
Zm9yIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gJm5ic3A7Jm5ic3A7IHJlY2VpdmVyLiZxdW90
OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2Nr
cXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDtBTEVYJmd0OyBN
b2RpZmllZCB0aGUgcGFyYWdyYXBoIGFscmVhZHkgZHVlIHRvIGFub3RoZXIgY29tbWVudCBpbiBh
bm90aGVyIHRocmVhZC4mbmJzcDsgVXBkYXRlZCB0aGlzIGZ1cnRoZXIgcGVyIHlvdXIgY29tbWVu
dHMuJm5ic3A7IE5vdyBpdCByZWFkcyBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZxdW90OyBBIHB1Ymxpc2hlciBNVVNUIGFsbG93IGZvciB0aGUgcG9zc2liaWxpdHkgdGhhdCBh
IHN1YnNjcmlwdGlvbidzIHNlbGVjdGlvbiBmaWx0ZXIgcmVmZXJlbmNlcyBub24tZXhpc3RlbnQg
ZGF0YSBvciBkYXRhIHRoYXQgYSByZWNlaXZlciBpcyBub3QgYWxsb3dlZCB0byBhY2Nlc3MuJm5i
c3A7IFN1Y2ggc3VwcG9ydCBwZXJtaXRzIGEgcmVjZWl2ZXIgdGhlIGFiaWxpdHkgdG8gbW9uaXRv
ciB0aGUgZW50aXJlIGxpZmVjeWxlIG9mIHNvbWUgZGF0YXN0b3JlIHRyZWUgd2l0aG91dCBuZWVk
aW5nIHRvIGV4cGxpY2l0bHkgZW51bWVyYXRlIGV2ZXJ5IGluZGl2aWR1YWwgZGF0YXN0b3JlIG5v
ZGUuJm5ic3A7IElmLCBhZnRlciBhY2Nlc3MgY29udHJvbCBoYXMgYmVlbiBhcHBsaWVkLCB0aGVy
ZSBhcmUgbm8gb2JqZWN0cyByZW1haW5pbmcgaW4gYW4gdXBkYXRlIHJlY29yZCwgdGhlbiAoaW4g
Y2FzZSBvZiBhIHBlcmlvZGljIHN1YnNjcmlwdGlvbikgb25seSBhIHNpbmdsZSBlbXB0eSAmcXVv
dDtwdXNoLXVwZGF0ZSZxdW90OyBub3RpZmljYXRpb24gTUFZIGJlIHNlbnQuIEVtcHR5ICZxdW90
O3B1c2gtY2hhbmdlLXVwZGF0ZSZxdW90OyBtZXNzYWdlcyAoaW4gY2FzZSBvZiBhbiBvbi1jaGFu
Z2Ugc3Vic2NyaXB0aW9uKSBNVVNUIE5PVCBiZSBzZW50LiZuYnNwOyBUaGlzIGlzIHJlcXVpcmVk
IHRvIGVuc3VyZSB0aGF0IGNsaWVudHMgY2Fubm90IHN1cnJlcHRpdGlvdXNseSBtb25pdG9yIG9i
amVjdHMgdGhhdCB0aGV5IGRvIG5vdCBoYXZlIGFjY2VzcyB0byB2aWEgY2FyZWZ1bGx5IGNyYWZ0
ZWQgc2VsZWN0aW9uIGZpbHRlcnMuJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+QWxzbyBhZGRpbmcgdGhlIGZvbGxvd2luZyBzZW50ZW5j
ZSwgdG8gY2xhcmlmeSB0aGUgZWZmZWN0IG9uIGRhbXBlbmluZzogJnF1b3Q7IEJ5IHRoZSBzYW1l
IHRva2VuLCBjaGFuZ2VzIHRvIG9iamVjdHMgdGhhdCBhcmUgZmlsdGVyZWQgTVVTVCBOT1QgYWZm
ZWN0IGFueSBkYW1wZW5pbmcgaW50ZXJ2YWxzLiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZsdDsvQUxFWCZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGV4dCBsb29rcyBnb29kLiZuYnNwOyBNeSBvbmx5IHF1ZXN0aW9uIGlzIG9u
IHRoZSBzZW50ZW5jZSB3aXRoIHRoZSBNQVkuIEkndmUgYmVlbiB0b2xkIGJ5IHNvbWUgb2xkIGhh
bmRzIHRoYXQgZXZlcnl3aGVyZSB5b3Ugc2VlICZxdW90O01BWSZxdW90OyBpbiBhbiBSRkMgdGhl
biBpdCBpcyBlbnRpcmVseSB2YWxpZCB0byBhbHNvIGludGVycHJldCB0aGF0IGFzICZxdW90O01B
WSBOT1QmcXVvdDsuPGJyPg0KPGJyPg0KSSB0aGluayB0aGF0IGl0IHNob3VsZCBwZXJoYXBzIGJl
Ojxicj4NCjxicj4NCiZxdW90Oy4uLiB0aGVuIChpbiBjYXNlIG9mIGEgcGVyaW9kaWMgc3Vic2Ny
aXB0aW9uKSB0aGUgcHVibGlzaGVyIE1VU1Qgb25seSBzZW5kIHNpbmdsZSBlbXB0eSAmcXVvdDtw
dXNoLXVwZGF0ZSZxdW90OyBub3RpZmljYXRpb24uPGJyPg0KPGJyPg0Kb3IsIGFsdGVybmF0aXZl
bHkgKGlmIHlvdSBkb24ndCB3YW50IE1VU1QpOjxicj4NCjxicj4NCiZxdW90Oy4uLiB0aGVuIChp
biBjYXNlIG9mIGEgcGVyaW9kaWMgc3Vic2NyaXB0aW9uKSB0aGUgcHVibGlzaGVyIGlzIGFsbG93
ZWQgdG8gc2VuZCBvbmx5IGEgc2luZ2xlIGVtcHR5ICZxdW90O3B1c2gtdXBkYXRlJnF1b3Q7IG5v
dGlmaWNhdGlvbi48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+Jmx0O0FMRVgtMiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPkkgZG9u4oCZdCBzZWUgaG93
IOKAnGFsbG93ZWQgdG/igJ0gcmVhbGx5IGNoYW5nZXMgdGhlIG1lYW5pbmcgb2Yg4oCcTUFZ4oCd
LCBzbyBJIGFtIHRha2luZyB5b3VyIHN1Z2dlc3Rpb24gYW5kIGFtIHJlcGxhY2luZyB0aGUgTUFZ
IHdpdGggTVVTVC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzAwQjA1MCI+Jmx0Oy9BTEVYLTImZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+KDM1KSBTZWN0aW9uIDMuMTAuJm5ic3A7IFRoaXMg
dGV4dCBzZWVtcyB0byBiZSB2ZXJ5IGNsb3NlbHkgcmVsYXRlZCB0byB0aGU8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT50ZXh0IGluIHNlY3Rpb24gMy4zLCBzbyBwZXJoYXBzIHNlY3Rpb24gMy4xMCB3
b3VsZCBiZSBiZXR0ZXIgbW92ZWQgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5iZWNvbWUgc2Vj
dGlvbiAzLjMuMT88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbHQ7
QUxFWCZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Eb24ndCB3YW50IHRvIGFwcGx5IG1ham9y
IGVkaXRvcmlhbCByZXN0cnVjdHVpbmcgYXQgdGhpcyBwb2ludC48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbHQ7L0FMRVgmZ3Q7PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgZmluZS48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cHJlPigzNikgU2VjdGlvbiAzLjEwLCBsYXN0IHBhcmFncmFwaC4mbmJz
cDsgJnF1b3Q7d2lsbCBiZSBleHBlY3RlZCB0byZxdW90OyA9Jmd0OyAmcXVvdDtTSE9VTEQmcXVv
dDs/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+Jmx0O0FMRVgmZ3Q7Tm90IHN1cmUgd2Ugd2FudCBpdCB0byBzb3VuZCBz
byBub3JtYXRpdmUsIGJ1dCBzdXJlIC0gY2hhbmdpbmcgaXQgdG8gU0hPVUxELiAmbHQ7L0FMRVgm
Z3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4oMzcpIFNlY3Rpb24gMy4xMS4xICZxdW90
O2luY29tcGxldGUtdXBkYXRlJnF1b3Q7IGZsYWcuJm5ic3A7IEluIHRoZSBZQU5HIGRlZmluaXRp
b248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGlzIGZsYWcgaXMgc2V0IGluIHRoZSBoZWFkZXIg
b2YgdGhlIG1lc3NhZ2UgKGkuZS4gYmVmb3JlIHRoZSBkYXRhKSw8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5idXQgZm9yIGFwcGxpY2F0aW9ucyB0aGF0IGFyZSBnZW5lcmF0aW5nIHRoZSBub3RpZmlj
YXRpb25zIGluIGEgc3RyZWFtZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53YXksIGl0IHdvdWxk
IHByb2JhYmx5IGJlIGJldHRlciB0byBwdXQgdGhlIGZsYWcgYWZ0ZXIgZGF0YS4mbmJzcDsgVGhp
czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBvdGVudGlhbGx5IG1pbmltaXplcyB0aGUgcmVxdWly
ZW1lbnQgdGhhdCBhIHB1Ymxpc2hlciBoYXMgdG8gYnVmZmVyIGFsbDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPmRhdGEgdG8gYmUgYWJsZSB0byBzZXQgdGhlIGluY29tcGxldGUtdXBkYXRlIGZsYWcg
aWYgbmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDtBTEVYJmd0OyBPSywgc28geW91IGFyZSBzdWdn
ZXN0aW5nIHRvIG1vdmUgdGhlICZxdW90O2luY29tcGxldGUtdXBkYXRlJnF1b3Q7IGxlYWYgYmVo
aW5kIHRoZSBkYXRhc3RvcmUgY29udGVudHMgKHJlc3BlY3RpdmVseSBkYXRhc3RvcmUtY2hhbmdl
cykuJm5ic3A7Jm5ic3A7IFN1cmUsIHdpbGwgY2hhbmdlIHRoYXQuIDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZsdDsvQUxFWCZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB0aGFua3MuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286
cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxwcmU+Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+KDM4KSBT
ZWN0aW9uIDMuMTEuMSAzcmQgcGFyYWdyYXBoIGFuZCBidWxsZXQgcG9pbnRzLiZuYnNwOyBXaXRo
IHRoZSB0ZXh0IGFzPG86cD48L286cD48L3ByZT4NCjxwcmU+Y3VycmVudGx5IHdyaXR0ZW4sIGl0
IGlzIGFjY2VwdGFibGUgZm9yIGEgcHVibGlzaGVyIHRvIGRvIG5vdGhpbmcgZXZlbjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPmlmIGFuIGVycm9yIGlzIGhpdC4mbmJzcDsgVGhleSBjYW4gc2F0aXNm
eSB0aGUgZmlyc3QgJnF1b3Q7TVVTVCZxdW90OyBieSBzZWxlY3RpbmcgdGhlPG86cD48L286cD48
L3ByZT4NCjxwcmU+Mm5kIGNob2ljZSwgYW5kIHRoZXkgY2FuIHNhdGlzZnkgdGhlICZxdW90O01B
WSZxdW90OyBvZiB0aGUgc2Vjb25kIGNob2ljZSBieSBkb2luZzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPm5vdGhpbmcgYXQgYWxsLiZuYnNwOyBJbnN0ZWFkIEkgdGhpbmsgdGhhdCB0aGUgdGV4dCBz
aG91bGQgc3RhdGUgdGhhdCB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wdWJsaXNoZXIgTVVT
VCBzZXQgdGhlICZxdW90O2luY29tcGxldGUtdXBkYXRlJnF1b3Q7IGZsYWcsIG9yIHN1c3BlbmQg
dGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+c3Vic2NyaXB0aW9uLCBvciBib3RoLjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDtBTEVYJmd0OzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPk9LLCBJIHRoaW5rIHRoZSBwcm9ibGVtIGlzIHdpdGggJnF1b3Q7TVVTVCB0
YWtlIG9uIG9yIG1vcmUgb2YgdGhlIGZvbGxvd2luZyBhY3Rpb25zJnF1b3Q7Jm5ic3A7IChhbHRo
b3VnaCBJIHRoaW5rIHdoYXQgaXMgbWVhbnQgaXMgY2xlYXIpLiZuYnNwOyBSZXBocmFzaW5nIHRo
aXMgYXMgZm9sbG93czombmJzcDsgJnF1b3Q7IEluIHRoaXMgY2FzZSwgdGhlIHB1Ymxpc2hlciBN
VVNUIGFjdCBhcyBmb2xsb3dzLiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPkFsc28gYWRkaW5nIHRoZSBmb2xsb3dpbmcgdG8gdGhlIHNl
Y29uZCBidWxsZXQgaXRlbTogPG86cD48L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7IElmIHRoZSBw
dWJsaXNoZXIgZG9lcyBub3QgY3JlYXRlIGFuIHVwZGF0ZSByZWNvcmQgYXQgYWxsLCBpdCBNVVNU
IHN1c3BlbmQgdGhlIHN1YnNjcmlwdGlvbi4mbmJzcDsgJnF1b3Q7IDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyhUaGlzIGlzIHJlYWxseSB0aGUgb25seSBsb2dpY2FsIGNob2ljZTsgd2Ug
ZG9uJ3Qgd2FudCBhIHB1Ymxpc2hlciB0byBoYXZlIHRoZSBvcHRpb24gb2Ygc3RheWluZyBlbnRp
cmVseSBzaWxlbnQuKSZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB0aGUgY2hhbmdlIGxvb2tzIGdvb2QuPGJyPg0KPGJyPg0K
VGhhbmtzLDxicj4NClJvYjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+Jmx0O0FMRVgtMiZndDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPlRoYW5r
cywgUm9iPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MDBCMDUwIj4tLS0gQWxleDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzAwQjA1MCI+Jmx0Oy9BTEVYLTImZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tLS0gQWxl
eDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZsdDsvQUxFWCZndDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPlRoYW5rcyw8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5Sb2I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk5ldGNvbmYgbWFpbGluZyBsaXN0PG86cD48L286cD48
L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0
Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N
CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CE72sjceml521mbschi_--


From nobody Fri Sep  7 06:46:29 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303D0130E00 for ; Fri,  7 Sep 2018 06:46: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, 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, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, 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 78FU9vMowUN5 for ; Fri,  7 Sep 2018 06:46:21 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2987128CF3 for ; Fri,  7 Sep 2018 06:46:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=121520; q=dns/txt; s=iport; t=1536327980; x=1537537580; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=WHG5nidTpPjRf8eElsAAUZ+u3m1JfyKUdxbui3qOlmo=; b=dtBgflgMacLyAmkNz+8DJYJqyw1v8UX3Cr4pho1jki8n/hMaN44rLhuF LOCA3ypO0suj7IQtnelYqf8BrhammGH1eyBHA9ZXXgYKHD2/gI4AOda1K LMKxosK01twPV87+InYWCbpBxZQk7ptphrqU0PBWsvrIepQ31W75db/8G g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQB+gJJb/xbLJq1RAgcZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBgldIBYEPbRIog3KIco1QeJVOgWMDCxgBCoQDRgKEAjg?= =?us-ascii?q?UAQIBAQIBAQJtHAyFOAEBAQMBAQEYAQgKOgcQBwQJAhEEAQEBDRMBBgMCAic?= =?us-ascii?q?fCQgGAQwGAgEBFQKCO0sBgXkID4lYm0uBLh+EDwE9hRcFinyBQT+BEieCNgc?= =?us-ascii?q?ugxsBAQKBNQMBDgIDSYJLglcCiAOFPwGFTYhtCYY4gnyDA4NEBheBQCCEH4J?= =?us-ascii?q?ZJYVwiEiCcIJchXSBWSEngS4zGggbFTuCbIM2AQKCSIUUhT8+MIpoAQEFHwI?= =?us-ascii?q?BBIIeAQE?=
X-IronPort-AV: E=Sophos;i="5.53,342,1531785600"; d="scan'208,217";a="6346360"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2018 13:46:16 +0000
Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w87DkFKM005924; Fri, 7 Sep 2018 13:46:15 GMT
To: Alexander Clemm , "netconf@ietf.org" 
References: <386e425f-d250-a0a9-0927-1a484aed9042@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CA9A@sjceml521-mbs.china.huawei.com> <8b2bd7da-7fd3-907d-1df0-947ce2052904@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CE72@sjceml521-mbs.china.huawei.com>
From: Robert Wilton 
Message-ID: <8941118a-33de-22c7-cf9e-7a836c18c063@cisco.com>
Date: Fri, 7 Sep 2018 14:46:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CE72@sjceml521-mbs.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------FC76366E65BFB332F728E895"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [Netconf] RGW YANG push -18 LC comments [part 1]
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Sep 2018 13:46:28 -0000

This is a multi-part message in MIME format.
--------------FC76366E65BFB332F728E895
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Alex,

I'm marked my replies RW, in case the indentation isn't working.


On 06/09/2018 20:35, Alexander Clemm wrote:
>
> Hi Rob,
>
> thank you for your responses - replies to those in 
>
> Thanks!
>
> --- Alex
>
> *From:*Robert Wilton [mailto:rwilton@cisco.com]
> *Sent:* Thursday, September 06, 2018 3:57 AM
> *To:* Alexander Clemm ; netconf@ietf.org
> *Subject:* Re: [Netconf] RGW YANG push -18 LC comments [part 1]
>
> Hi Alex,
>
> Please see inline ...
>
> On 05/09/2018 23:28, Alexander Clemm wrote:
>
>     Hello Rob,
>
>     thank you for your comments!  Please find my replies inline, , with corresponding changes to be incorporated into the next revision (-19).
>
>     --- Alex
>
>         -----Original Message-----
>
>         From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert Wilton
>
>         Sent: Tuesday, September 04, 2018 7:37 AM
>
>         To:netconf@ietf.org 
>
>         Subject: [Netconf] RGW YANG push -18 LC comments [part 1]
>
>         Hi,
>
>         I've reviewed the -18 YANG push draft up to section 4 so far . I've included my
>
>         comments below.  I think that they are all minor/cosmetic except for the issue
>
>         regarding the dampened subscriptions which has been discussed below and
>
>         probably does not need to be rehashed again.
>
>         In the Abstract:
>
>         (1) Is "continuous" the right choice of word here.  E.g. I thought that sometimes
>
>         the stream of updates is not continuous.  Possibly remove "continuous"?
>
>     Would prefer to keep, unless you feel very strongly about this?  What we want to bring across is that this is different from a one-time, on-demand type of update.  "Stream" might imply this already, but this way we would emphasize this a bit further.
>
>     
>
> Keeping is fine if that is what you prefer.
>
>
>      Thanks 
>
>         In the Introduction:
>
>         (2) "remote visibility" in the first sentence is a bit obscure. Perhaps replace the
>
>         first sentence with "Traditional approaches to monitoring management data on
>
>         remote devices have been built upon polling".
>
>      How about changing this to: "Traditional approaches to providing visibility into managed entities from remote have been built on polling. "
>
>     [I understand your point, but reason for alternative phrasing is that I don't think we want to restrict this to monitoring (because (a) you can use this also to mirror state for other purposes, e.g. to assess specifics of what needs to be done to provision a service successfully, for troubleshooting, maintenance, validation, etc, and (b) monitoring does include other aspects such as alarm management).  LIkewise, suggest to refer to "managed entities" (not "devices") to not preclude application to things that are not devices (e.g. virtual "things"). ]
>
>     
>
> Your phrasing is fine.
>
>  Thanks 
>
>         (3) The work isn't actually fruitless if polling is the only available option, hence
>
>         perhaps change:
>
>         OLD:
>
>         "For applications that monitor for changes, many remote polling
>
>            cycles place ultimately fruitless load on the network, devices,
>
>            and applications."
>
>         
>
>         NEW:
>
>           " For applications that monitor for changes, many remote polling
>
>             cycles place unwanted load on the network, devices,
>
>             and applications, particularly if the monitored values are only changing
>
>         infrequently."
>
>     
>     How about: " For applications that monitor for changes, many remote polling cycles place unwanted and ultimately fruitless load on the network, devices, and applications, particularly when changes occur only infrequently. "
>
>     
>
> My point is that if the only choice is polling then it is not fruitless load, because it serves a useful purpose, that purpose being detecting changes in the monitored data.  Hence the load is "unwanted" not "fruitless".
>
> But this is a minor consideration, so I'm OK with whatever you decide here. :-)
>
>  Let’s change “fruitless†to “wasteful†
>
>         (4) In paragraph starting " A more effective alternative", possibly suggest
>
>         changing "publisher" to "server" since the introduction is before the
>
>         definitions/acronyms where "publisher" is formally referenced.
>
>      Rewording to "... that enables the server (also referred to as publisher) to push  ... " 
>
> OK.
>
>
>         In definitions:
>
>         (5) Suggest tying this definition more closely to the terminology already defined
>
>         in RFC 8342, hence:
>
>         OLD:
>
>              o  Datastore node: An instance of management information in a
>
>                 datastore.  Also known as "object".
>
>         NEW:
>
>              o  Datastore node: A node in the instantiated YANG data tree associated with
>
>         a datastore.  In this document, datastore nodes are often referred to as "YANG
>
>         objects" or "objects"
>
>      OK.  (and removed instance of "YANG object" from the document, as there were only two.) 
>
> OK.
>
>
>         (6) "Datastore node update" definition: Does this update only contain the value,
>
>         or does it also contain the path to the datastore node as well?  If this also
>
>         contains the path then it would be good if that was explicit in the definition.
>
>      Updated as follows: " A data item containing the current value of a datastore node at the time the datastore node update was created, as well as the path to the datastore node."  
>
> Looks good.
>
>
>         (7) Perhaps the following definition is more precise?  Or by "updates"
>
>         do you actually mean "update records"?  There are other references to
>
>         "updates" in the definitions, do these all refer to "update records"? If so then I
>
>         would suggest moving the definition of "update record" above "datastore
>
>         subscription".
>
>         OLD:
>
>         "Datastore subscription: A subscription to updates regarding
>
>                 contents of a datastore."
>
>         
>
>         NEW:
>
>         
>
>         " Datastore subscription: A subscription to a stream of datastore node updates."
>
>      ok, changed 
>
>         (8) Suggest removing "instantiated" from the following definition, and using
>
>         descendant (which is used in 7950) instead of contained .. I also suggest moving
>
>         the definition up, directly below "datastore node":
>
>         OLD:
>
>              o Datastore subtree: An instantiated datastore node and the
>
>                 datastore nodes that are hierarchically contained within it.
>
>         NEW:
>
>              o Datastore subtree: A  datastore node and all its descendant datastore
>
>         nodes."
>
>      changed 
>
>         (9) Sec 3. Solution overview, last sentence.   It is not "YANG objects"
>
>         that are being pushed, but surely "datastore node updates" or perhaps
>
>         "update records" that are pushed, or even "Changes to YANG objects"
>
>      Changed to "datastore node updates" 
>
>         Sec 3.1 Subscription model:
>
>         (10) Perhaps change"subtrees within a datastore" to "datastore subtrees".
>
>      changed 
>
>         (11) It is not obvious to me from this text what "Anchor time" is,
>
>         although I suspect that it is described in more detail later in the
>
>         document.  Given that the section on-change subscriptions has more
>
>         detail for various parameters, I wonder whether it would be helpful to
>
>         describe anchor time in more detail in this section?
>
>      Roughly what it is is explained in the same sentence, but how about changing it as follows:
>
>     " These parameters are the period interval with which to report updates, and an "anchor time", i.e. a reference point in time that can be used to calculate at which points in time periodic updates need to be assembled and sent."
>
>     
>
> I think I get this, but didn't find it completely clear until I had 
> looked at the model.  I think that you updated text is OK.
>
> Although I have a slight concern (e.g. in section 4.2),
>
>
>       *  an "anchor-time"; update intervals always fall on the points in
>          time that are a multiple of a "period" from an "anchor-time".
>
>
> I can see implementations will try and keep to this interval, but I 
> suspect that the vast majority of implementations will not be able to 
> guarantee that it is exact multiples of the given period, given that 
> "anchor-time" seems to take an arbitrary sub-section precision, and 
> timeticks are in hundreds of a second. Possibly, weakening the text 
> (e.g. as per below, but the YANG model would probably need to be 
> updated) might be a good idea?
>
>
>       *  an "anchor-time"; update intervals always fall as close as 
> possible to the points in
>          time that are a multiple of a "period" from an "anchor-time".
>
> I don’t like the “as close as possibleâ€.  What is possible may 
> differ between implementations; I feel that this formulation blurs 
> more than it clarifies.  Perhaps we should simply remove the “always†
> – to read
> “update intervals fall on the points in time that are a multiple of a 
> "period" from an "anchor-time" 
RW:
Yes, that is probably OK, the alternative could be "SHOULD fall", but 
even that is probably a bit strong.

What I want to avoid is clients assuming that they will receive updates 
exactly period interval apart, e.g. when calculating rates. Instead, 
they should use the timestamps of the previous and current notification 
to determine the time interval to use when calculating any rates.

>
>
>         (12) Dampening period: The text states that "The dampening period
>
>         collectively applies to the set of all datastore nodes selected by a
>
>         single subscription and sent to a single receiver."  This would imply
>
>         that if a single subscription had multiple receivers that they would be
>
>         dampened independently, but it wasn't obvious to me that this makes
>
>         sense.  I would assume that for a given subscription that all receivers
>
>         would receive the same update records.
>
>      Yes.  Removed "and sent to a single receiver".  Also clarified further (in a slight rewording) " This means that when there is a change to one or more subscribed objects, an update record containing those objects is created immediately (when no dampening period is in effect) or at the end of a dampening period (when a dampening period is in fact in effect).  "
>
>     
>
> OK.
>
>
>         (13) Rather than "No Sync on start", it might be better to refer to this
>
>         as  "sync on start", which could be defined as a boolean with default
>
>         true [I've not checked the YANG model]
>
>      it's not defined as a boolean but as a leaf of type empty.  (So, the "default" is in fact true, unless  no-sync-on-start is present).  I don't see a compelling reason to change this and suggest to keep this as-is.
>
>     
>
> OK.  I think that in YANG, particularly considering NMDA, it is cleaner to model this as a boolean with default true, particularly if you do a get-data request on the operational state, since it more clearly and explicitly indicates whether sync-on-start is enabled.
>
> With the current model, on a get-data request against operation, the server returns "no-synch-on-start", it is obvious that it won't perform a sync-on-start, however, the reverse if the leaf isn't present isn't quite so clear.  If it doesn't return "no-synch-on-start" then that either means the device will perform sync-on-start, or perhaps the node the server isn't returning any information, or perhaps it has been deviated.  So, in summary, I think that flags that turn something off, are better modeled with default true, rather than as empty leafs.  Flags that turn something on can be modeled equally well either way.
> In terms of instantiation, I find empty leaves more elegant, 
> particularly if there is a default value.  I think  
> is more elegant than True.
> Would you be satisfied if we turn the default around, i.e. change 
> “no-sync-on-start†to “sync-on-startâ€, but keeping it an empty?
>  
RW: Yes, changing it to "sync-on-start" keeping the type as empty is fine.

>
> BTW, I also notice that is uses "synch" in various leaf name, but I would recommend the abbreviation "sync" instead.  It is shorter, and I think more commonly used.https://english.stackexchange.com/questions/681/synced-or-synched
>   
>
> Have changed “synch†(and “resynchâ€) to sync / resync 
> througout the documentt, also per Rohit’s earlier comment.
> 
RW: OK.

>         Sec 3.2. Negotiation of Subscription Policies
>
>         (14) "Random guessing at" => "Random guessing of".  Although, I think
>
>         that probably this first sentence, and the "Therfore, " could just be
>
>         deleted.  I.e. starting the paragraph "In order to minimize ..."
>
>      Changed "at" to "of", however, prefer to keep the first sentence as it does provide some explanation.  
>
> OK.
>
>
>         (15) Suggest minor rewording of 3.3. third paragraph:
>
>         OLD:
>
>         In that case, updates are sent only for those objects
>
>              within the scope that do support on-change updates whereas other
>
>              objects are excluded from update records, whether or not their values
>
>              actually change.
>
>         NEW:
>
>         In that case, updates are sent only for those objects
>
>              within the scope that do support on-change updates, whereas other
>
>              objects are excluded from update records, even if their values change.
>
>      changed 
>
>         (16) Question on 3.3. fifth paragraph (below), it's unclear to me what
>
>         is meant by "which are current at the time":
>
>         "Values sent at the end of the
>
>              dampening period are the current values of all changed objects which
>
>              are current at the time the dampening period expires."
>
>      Rephrase the paragraph as follows, just to make it clear (it's a bit more verbose than it has to, but we want to make sure there is no question as to what value to send - the value of the original change or the value at the time of updating).
>
>     "... .  Values sent at the end of the dampening period are the values that are current at the end of the dampening period of all changed objects.  Changed objects include those which were deleted or newly created during that dampening period.  If an object has returned to its original value (or even has been created and then deleted) during the dampening-period, that value (and not the interim change) will still be sent. ..."
>
>     
>
> Yes, I think that the longer and more explicit text is better.
>
>
>         (17) I still doubt that all implementations will strictly follow all of
>
>         3.3. paragraph 5, particularly the created and deleted within a
>
>         dampening period because I perceive that it is particularly difficult to
>
>         implement cleanly/efficiently.  However, this issue has been discussed
>
>         previously, and I have no particular desire to slow the RFC progress
>
>         down with further discussion on this.
>
>      No change made 
>
>         (18) Section 3.3, conceptual process, step 1 states that access control
>
>         rules are checked to ensure the receiver is authorized to view all
>
>         subscribed datastore nodes, but I think that this should state that the
>
>         access control rules are used to filter the subscribed datastore nodes
>
>         to those that the client has access rights to.
>
>       I added " (and filter out any nodes for which this is not the case)" to make this clearer; this now reads " Just before a change, or at the start of a dampening period, evaluate any filtering and any access control rules to ensure receiver is authorized to view all subscribed datastore nodes (and filter out any nodes for which this is not the case). "
>
>     
>
> OK, but I would change "and filter" to "filtering".
>
> OK, changed 
>
>         (19) A related question:  When happens if there is an access control
>
>         change, i.e. the receiver had access previously, but then it was
>
>         revoked.  Does it see a delete?  Or does it not get any notification?
>
>         Similarly, if they didn't previously have access, but then access was
>
>         granted before the end of the dampening period?  OK, I see that this is
>
>         described in more detail in section 3.9, paragraph 3.  Perhaps a forward
>
>         reference would be useful here.
>
>      I think this is defined in detail in 3.9, as you note.  I think the spirit of the description here is clear, and I don't want to overly burden the text with cross-references within the same text.  So, I suggest keeping this as-is.
>
>     
>
> OK.
>
>
>         (20) Section 3.3, last paragraph, "can be created" => "must be created".
>
>      Actually, I think it is "can".  It is up to the discretion of what the subscriber wants to do.   As an alternative to using the word "can" (not sure if this is really needed), rephrasing it to " In cases where a subscriber wants to have separate dampening periods for different objects, the subscriber has the option to create multiple subscriptions with different selection filters. " 
>
> must is correct, since that is the only available solution to the client if they want different dampening periods.  I.e. the clients choice is: don't have separate dampening periods or create separate subscriptions.  But this is a minor point, not worth lengthy discussion, so you can decide what to do.
>
> OK, keeping it.
RW: OK.

>
>
>         (21) Section 3.4, second paragraph doesn't quite scan.  "This includes
>
>              indicating the fact that an update is incomplete as part of a push-
>
>              update respectively push-change-update notification ..."
>
>      I think it does scan, but to make it just slightly more clear, how about updating to " This includes indicating the fact that an update is incomplete as part of a push-update (respectively push-change-update) notification, as well as emitting a subscription-suspended notification as applicable. "
>
>     
>
> It is the "push-update respectively push-change-update" that doesn't 
> make any sense to me.  Do you just mean "or", e.g. "push-update or 
> push-change-update"?
>
>     OK, changing it to “or†(I guess my nativeness to the
>     German language shines through here, in which there is a finer
>     distinction between two types of “orâ€, one of which is the term
>     “beziehungsweise†(which would be the proper choice here – yes,
>     some words in German are longer than in English, even the
>     abbreviation “bzw.†is still longer than “orâ€;-), which translates
>     roughly but perhaps not exactly into “repectivelyâ€.)
>
RW: Thanks.

>         (22) Section 3.4, 3rd paragraph, "able fulfill" => "able to fulfill"
>
>      changed 
>
>         (23) Section 3.5.2, 1st paragraph, "not restricted to configuration
>
>         objects only" => "not only restricted to configuration objects".
>
>      changing to " not restricted to only configuration objects"  (the "only" refers to the configuration objects, not to the fact that it is restricted) 
>
> Yes., OK.
>
>         (24) Section 3.5.2, 2nd paragraph, possible alternative text:
>
>         OLD:
>
>              A publisher will indicate a change to the effect that a value of a
>
>              datastore node has been updated by indicating a "replace" operation
>
>              (applied to the datastore node) in the patch.  When a new datastore
>
>              node was created (other than an entry in a user ordered list), a
>
>              publisher will indicate a "create" operation in the patch.  When a
>
>              datastore node was deleted, the publisher indicates this by a
>
>              "delete".  When a new entry in a user-ordered list was created, the
>
>              publisher indicates this by an "insert" operation. When an entry in
>
>              a user-ordered list was moved, the publisher indicates this by a
>
>              "move" operation.
>
>         NEW:
>
>             A publisher indicates the type of change to a datastore node using
>
>         the different YANG patch operations:  the "create" operation is used for
>
>         newly created objects (except entries in a user-ordered list), the
>
>         "delete" operation is used for deleted objects (including in
>
>         user-ordered lists), the "replace" operation is used when only the
>
>         object value changes, the "insert" operation is used when a new entry is
>
>         inserted in a list, and the "move" operation is used when an existing
>
>         entry in a user-ordered list is moved.
>
>      OK (I don't feel strongly about this) 
>
>         (25) Section 3.5.2, last paragraph: If you want to allow duplicate
>
>         "create" and "delete" events, then it might be cleaner to encode them as
>
>         "merge" and "remove"?  I.e. it seems that you have created a slightly
>
>         different encoding from vanilla YANG patch because of the way that
>
>         errors are handled differently.  Ideally, it would be better if a client
>
>         could just apply this as regular YANG patch, but this only works with
>
>         the encoding described here if the clients copy of the datastore is in
>
>         sync with the servers old copy of the datastore at the point that the
>
>         patch is generated from.  This seems slightly fragile to unexpected
>
>         inconsistencies between client and server (which I appreciate that you
>
>         try and avoid).
>
>      Hmm.  While it may be possible to replace "delete" with "remove", I am not so sure about the "merge" part.  At the end of the day, the use here is different from having a client apply a patch operation to the server, and the semantics may be a little clearer by keeping things as they are, so would prefer to keep things as defined now.
>
>     
>
> I think that is probably right.
>
> I think that it is a slight shame that vanilla YANG patch won't work 
> here, but as you say I think that it will need to be applied in a 
> slightly different way regardless.
>
> OK. Keeping it.
>
>
>
>         (26) Section 3.6, second paragraph, would it not be easier to allow the
>
>         client to replace an existing filter rather than having to explicitly
>
>         remove the old filter and add the new one?  Or if you mean that any new
>
>         filter replaces the existing filter, then this may be more clearly
>
>         indicated with the text: "An RPC request proposing a new selection
>
>         filter replaces any existing filter. "
>
>      OK, changing per your suggestion to make it clear that the existing filter is replaced.  
>
>         (27) Section 3.6, paragraph 6, starting "XPath".  The "boolean" example
>
>         is unclear to me given that a xpath filter always returns a node set so
>
>         can't return a boolean result.  I also suggest changing "passes a
>
>         datastore node" to  "includes a datastore node".
>
>      removed the sentence and shortened the paragraph.  It now reads as follows:
>
>     " XPath itself provides powerful filtering constructs and care must be used in filter definition. Consider an XPath filter which only passes a datastore node when an interface is up. It is up to the receiver to understand implications of the presence or absence of objects in each update."
>
>     
>
> OK.
>
>
>
>         (28) Section 3.6, paragraph 7.  I think that the text must be more
>
>         explicit on when the filter is evaluated for a periodic subscription.
>
>         Am I right in thinking that it is only evaluated once when the
>
>         subscription is created, or the subscription is changed? Specifically,
>
>         if the nodeset evaluated during the lifetime of an Xpath subscription
>
>         changes then does that affect which nodes are returned?
>
>      Not sure what changes you are looking for.  The filter is in effect throughout the subscription until it is changed.  It is up to an implementation to decide whether to apply it once when the subscription is established to determine the datastore nodes (tracking any subtree changes to make sure nodes in the subtrees are included as needed), or whether to apply it at each update anew.
>
>     As far as receiver authorization is concerned (i.e. access control filters), this is explained in section 3.9.  Applying no text changes at this point unless you can be more clear on what you would like to see?
>
>     
>
> OK.  Not considering NACM, I think that is already covered, was 
> thinking of an Xpath filter.  I am right in thinking that logically 
> the Xpath filter is [re-]applied whenever the periodic push 
> notification is constructed.
>
> If so, possibly change:
>
> " When the set of selection filtering criteria is applied for a
>    periodic subscription, all selected datastore nodes to which a
>    receiver has access are provided to that receiver."
>
> To something along the lines of ...
>
> " When the set of selection filtering criteria is applied for a
>   periodic subscription, then they are applied whenever a periodic
>   update record is constructed, and only datastore nodes that pass
>   the filter and to which a receiver has access are provided to
>   that receiver."
>
>
>     OK, I am making the change as suggested.  (However,
>     presumably an implementation could choose to apply the filter to
>     select the set of datastore nodes once, and then, assuming the
>     filter and set of datastore nodes don’t change, simply send
>     updates about the nodes form the set, no?) 
>
RW:
If the set of filtered nodes is that same at each periodic update then 
it is equivalent to applying the filter once.

I was more thinking of an XPath example (e.g. inclusion of a node in the 
nodeset depends on whether an interface is up).  Here, the filter 
logically needs to be re-calculated at each periodic interface to ensure 
that the right nodes are returned.

>         (29) Section 3.7, paragraph 3:  Perhaps make this text conditional to
>
>         dampened subscriptions.  Presumably for non dampened subscriptions all
>
>         changes are reported as separate push-change-update notifications?
>
>         OLD:
>
>         In cases where multiple changes have occurred and the object
>
>              has not been deleted, the object's most current value is reported.
>
>         NEW:
>
>         In cases where multiple changes have occurred in a subscription that has
>
>         dampening enabled, and the object
>
>              has not been deleted, the object's most current value is reported.
>
>      Well, the text states clearly that this concerns any changes since the last notification message.  So, the fact that dampening is enabled is already implied.
>
>     How about rephrasing slightly as follows:
>
>     " In cases where multiple changes have occurred over the course of a dampening period and the object has not been deleted, the object's most current value is reported. "
>
>     
>
> This text is fine.
>
> But this raises another question:
>
> If no dampening is enabled, then is it expected that all changes to an 
> object are always notified.  [If this is a requirement, then I think 
> that it should probably be stated clearly in the YANG model and 
> perhaps in section 3 as well.]
>
> Specifically, say you are monitoring interface state, without 
> dampening, and it starts to flap 100 times per second.  Is the 
> publisher required to notify of every single change.  Or is the 
> publisher only required to notify that the at least one change has 
> occurred, and guarantee that it always notifies the latest value.
>
>  This is exactly the reason why dampening was introduced. I 
> think this is well documented.  If a subscriber does not turn on 
> dampening, and thus the server gets overwhelmed, they can suspend or 
> terminate the subscription.  In that case they should give a 
> “period-unsupported†error.
>
> Thinking about it some more, this needs to be more clearly spelled out 
> in the description of “period-unsupportedâ€.
>
RW:
OK, but there are other ways of solving this that may be more 
appropriate for some objects like interface states.

E.g. it is quite possible that I can't have a single dampened 
subscription for all interface states because I don't want a down event 
on one interface to prevent fast down notification of another interface 
in the same subscription.  Nor does having a separate subscription for 
each of (10,000+ interfaces appeal).

For interface states, the proper solution is to use a feature like 
carrier delay that limits flaps in a sensible way (fast down, slow up), 
and that is done on a per interface basis outside of YANG. I.e. the 
stream of changes is limited enough that dampening is not required.

I think that a future draft (or drafts) may want to look at other forms 
of dampening.

But for this draft, I still think that it needs to be clear for a 
subscription without dampening if the server MUST notify of *every* change.


> Changing the YANG definition (descriptino statement) as follows:
>
> identity period-unsupported {
>
> base sn:establish-subscription-error;
>
> base sn:modify-subscription-error;
>
> base sn:subscription-suspended-reason;
>
> description
>
>       "Requested time period or dampening-period is too short. This
>
>       can be for both periodic and on-change subscriptions (with or
>
>       without dampening.) Hints suggesting alternative periods may
>
>       be returned as supplemental information.";
>
> }
>
> 
>
>         (30) Section 3.7, paragraph 5, "Ethernet port" => "Ethernet interface"
>
>      changed 
>
>         (31) Section 3.7, last paragraph: Why start at "1" rather than "0". On
>
>         overflow, why overflow to "1" rather than "0", is that deliberate?  If
>
>         you are going to force it to "1" then I would also restrict the upper
>
>         bound to int32 max rather than uint32 max to make life easier in Java
>
>         land ...
>
>      OK, got it.  Updated the text to reflect start at 0.
>
>     
>
>         (32) Section 3.8, tree diagrams.  I would think that another key metric
>
>         regarding whether a subscription can be satisfied would be object-rate
>
>         and data-rate.  E.g. a publisher implementation may be able to push 100k
>
>         objects/second, so a client has a choice of either monitoring less
>
>         objects, or decreasing the period.  Hence I was wondering whether rates
>
>         should be provided in addition to the object-count-estimate/limit and
>
>         kilobyte-estimate/limit.  Of course, a rate is also implicitly defined
>
>         by including the period hint, so perhaps that is sufficient without
>
>         needing to send more fields back to the client.
>
>      Would prefer to keep this to the basics, i.e. as-is.  As mentioned, you can compute a rate from this.  
>
> Yes, that is fine.  Additional fields could be augmented in future if 
> needed.
>
>
>         (33) Section 3.9, 2nd paragraph, "particular each" => "particular"
>
>      changed 
>
>         (34) Section 3.9, 3rd paragraph:  It was not entirely obvious to me what
>
>         the 3rd paragraph text (reproduced below) actually means.  I think that
>
>         this boils down to:  If, after access control has been applied, there
>
>         are no objects remaining in an update record then only a single empty
>
>         "push-update" notification MAY be sent and empty "push-change-update"
>
>         messages MUST NOT be sent.  This is required to ensure that clients
>
>         cannot surreptitiously monitor objects that they do not have access to
>
>         via carefully crafted selection filters.
>
>         "A publisher MUST allow for the possibility that a subscription's
>
>              selection filter references non-existent or access-protected data.
>
>              Such support permits a receiver the ability to monitor the entire
>
>              lifecyle of some datastore tree.  In this case, all "push-update"
>
>              notifications must be sent empty, and no "push-change-update"
>
>              notifications will be sent until some data becomes visible for a
>
>              receiver."
>
>      Modified the paragraph already due to another comment in another thread.  Updated this further per your comments.  Now it reads as follows:
>
>     " A publisher MUST allow for the possibility that a subscription's selection filter references non-existent data or data that a receiver is not allowed to access.  Such support permits a receiver the ability to monitor the entire lifecyle of some datastore tree without needing to explicitly enumerate every individual datastore node.  If, after access control has been applied, there are no objects remaining in an update record, then (in case of a periodic subscription) only a single empty "push-update" notification MAY be sent. Empty "push-change-update" messages (in case of an on-change subscription) MUST NOT be sent.  This is required to ensure that clients cannot surreptitiously monitor objects that they do not have access to via carefully crafted selection filters."
>
>     Also adding the following sentence, to clarify the effect on dampening: " By the same token, changes to objects that are filtered MUST NOT affect any dampening intervals."
>
>     
>
> Text looks good.  My only question is on the sentence with the MAY. 
> I've been told by some old hands that everywhere you see "MAY" in an 
> RFC then it is entirely valid to also interpret that as "MAY NOT".
>
> I think that it should perhaps be:
>
> "... then (in case of a periodic subscription) the publisher MUST only 
> send single empty "push-update" notification.
>
> or, alternatively (if you don't want MUST):
>
> "... then (in case of a periodic subscription) the publisher is 
> allowed to send only a single empty "push-update" notification.
>
>
> 
>
> I don’t see how “allowed to†really changes the meaning of “MAYâ€, so I 
> am taking your suggestion and am replacing the MAY with MUST.
>
> 
>
RW: OK

Thanks,
Rob


>         (35) Section 3.10.  This text seems to be very closely related to the
>
>         text in section 3.3, so perhaps section 3.10 would be better moved to
>
>         become section 3.3.1?
>
>     
>
>     Don't want to apply major editorial restructuing at this point.
>
>     
>
> That is fine.
>
>
>         (36) Section 3.10, last paragraph.  "will be expected to" => "SHOULD"?
>
>     Not sure we want it to sound so normative, but sure - changing it to SHOULD. 
>
>         (37) Section 3.11.1 "incomplete-update" flag.  In the YANG definition
>
>         this flag is set in the header of the message (i.e. before the data),
>
>         but for applications that are generating the notifications in a streamed
>
>         way, it would probably be better to put the flag after data.  This
>
>         potentially minimizes the requirement that a publisher has to buffer all
>
>         data to be able to set the incomplete-update flag if necessary.
>
>      OK, so you are suggesting to move the "incomplete-update" leaf behind the datastore contents (respectively datastore-changes).   Sure, will change that.
>
>     
>
> Yes, thanks.
>
>
>        
>
>         (38) Section 3.11.1 3rd paragraph and bullet points.  With the text as
>
>         currently written, it is acceptable for a publisher to do nothing even
>
>         if an error is hit.  They can satisfy the first "MUST" by selecting the
>
>         2nd choice, and they can satisfy the "MAY" of the second choice by doing
>
>         nothing at all.  Instead I think that the text should state that the
>
>         publisher MUST set the "incomplete-update" flag, or suspend the
>
>         subscription, or both.
>
>     
>
>     OK, I think the problem is with "MUST take on or more of the following actions"  (although I think what is meant is clear).  Rephrasing this as follows:  " In this case, the publisher MUST act as follows."
>
>     Also adding the following to the second bullet item:
>
>     " If the publisher does not create an update record at all, it MUST suspend the subscription.  "
>
>       (This is really the only logical choice; we don't want a publisher to have the option of staying entirely silent.)
>
> Yes, the change looks good.
>
> Thanks,
> Rob
> 
>
> Thanks, Rob
>
> --- Alex
>
> 
>
>
>
>
>     --- Alex
>
>     
>
>         Thanks,
>
>         Rob
>
>         _______________________________________________
>
>         Netconf mailing list
>
>         Netconf@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/netconf
>


--------------FC76366E65BFB332F728E895
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Alex,

    
I'm marked my replies RW, in case the indentation isn't working.

    

    

    
On 06/09/2018 20:35, Alexander Clemm
      wrote:

    

    

      
      
      
      

        
Hi
            Rob,

        
 

        
thank
            you for your responses - replies to those in
          <ALEX-2>

        
 

        
Thanks!

        
---
            Alex

        
 

        

          

            

              
From:
                  Robert Wilton [mailto:rwilton@cisco.com]
                  

                  Sent: Thursday, September 06, 2018 3:57 AM

                  To: Alexander Clemm
                  <alexander.clemm@huawei.com>; netconf@ietf.org

                  Subject: Re: [Netconf] RGW YANG push -18 LC
                  comments [part 1]

            

          

          
 

          
Hi Alex,

          
Please see inline ...

          
 

          

            
On 05/09/2018 23:28, Alexander Clemm
              wrote:

          

          

            
Hello Rob,

            
 

            
thank you for your comments!  Please find my replies inline, <ALEX>, with corresponding changes to be incorporated into the next revision (-19).

            
 

            
--- Alex

            
 

            
 

            

              
-----Original Message-----

              
From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert Wilton

              
Sent: Tuesday, September 04, 2018 7:37 AM

              
To: netconf@ietf.org

              
Subject: [Netconf] RGW YANG push -18 LC comments [part 1]

              
 

              
Hi,

              
 

              
I've reviewed the -18 YANG push draft up to section 4 so far . I've included my

              
comments below.  I think that they are all minor/cosmetic except for the issue

              
regarding the dampened subscriptions which has been discussed below and

              
probably does not need to be rehashed again.

              
 

              
In the Abstract:

              
(1) Is "continuous" the right choice of word here.  E.g. I thought that sometimes

              
the stream of updates is not continuous.  Possibly remove "continuous"?

              
 

            

            
 

            
<ALEX>Would prefer to keep, unless you feel very strongly about this?  What we want to bring across is that this is different from a one-time, on-demand type of update.  "Stream" might imply this already, but this way we would emphasize this a bit further.  

            
</ALEX>

          

          
Keeping is fine if that is what you
            prefer.

            

            

            

          

            
<ALEX-2> Thanks </ALEX-2>

            
 

            

              
 

              
In the Introduction:

              
(2) "remote visibility" in the first sentence is a bit obscure. Perhaps replace the

              
first sentence with "Traditional approaches to monitoring management data on

              
remote devices have been built upon polling".

            

            
 

            
<ALEX> How about changing this to: "Traditional approaches to providing visibility into managed entities from remote have been built on polling. "

            
[I understand your point, but reason for alternative phrasing is that I don't think we want to restrict this to monitoring (because (a) you can use this also to mirror state for other purposes, e.g. to assess specifics of what needs to be done to provision a service successfully, for troubleshooting, maintenance, validation, etc, and (b) monitoring does include other aspects such as alarm management).  LIkewise, suggest to refer to "managed entities" (not "devices") to not preclude application to things that are not devices (e.g. virtual "things"). ] 

            
</ALEX> 

          

          
Your phrasing is fine.

<ALEX-2> Thanks </ALEX-2>

          
 

          

            
 

            

              
 

              
(3) The work isn't actually fruitless if polling is the only available option, hence

              
perhaps change:

              
 

              
OLD:

              
"For applications that monitor for changes, many remote polling

              
  cycles place ultimately fruitless load on the network, devices,

              
  and applications."

              
 

              
NEW:

              
   "For applications that monitor for changes, many remote polling

              
   cycles place unwanted load on the network, devices,

              
   and applications, particularly if the monitored values are only changing

              
infrequently."

              
 

            

            
 

            
<ALEX. The "ultimately fruitless" also refers to the fact that many polls will not yield new information (other than "no new information"), as you might e.g. retrieve a lot of stuff to see if it changed only to find that it didn't.  

            
How about: " For applications that monitor for changes, many remote polling cycles place unwanted and ultimately fruitless load on the network, devices, and applications, particularly when changes occur only infrequently. "

            
</ALEX>

          

          
My point is that if the only choice is polling then it is not fruitless load, because it serves a useful purpose, that purpose being detecting changes in the monitored data.  Hence the load is "unwanted" not "fruitless".

But this is a minor consideration, so I'm OK with whatever you decide here. :-)

<ALEX-2> Let’s change “fruitless†to “wasteful†</ALEX-2>

          
 

          

            
 

            
 

            

              
(4) In paragraph starting " A more effective alternative", possibly suggest

              
changing "publisher" to "server" since the introduction is before the

              
definitions/acronyms where "publisher" is formally referenced.

              
 

            

            
<ALEX> Rewording to "... that enables the server (also referred to as publisher) to push  ... " </ALEX>

          

          
OK.

            

            

            

          

            
 

            

              
 

              
In definitions:

              
 

              
(5) Suggest tying this definition more closely to the terminology already defined

              
in RFC 8342, hence:

              
 

              
OLD:

              
    o  Datastore node: An instance of management information in a

              
       datastore.  Also known as "object".

              
 

              
NEW:

              
    o  Datastore node: A node in the instantiated YANG data tree associated with

              
a datastore.  In this document, datastore nodes are often referred to as "YANG

              
objects" or "objects"

            

            
 

            
<ALEX> OK.  (and removed instance of "YANG object" from the document, as there were only two.) </ALEX>

          

          
OK.

            

            

            

          

            
 

            
 

            

              
 

              
(6) "Datastore node update" definition: Does this update only contain the value,

              
or does it also contain the path to the datastore node as well?  If this also

              
contains the path then it would be good if that was explicit in the definition.

              
 

            

            
 

            
<ALEX> Updated as follows: " A data item containing the current value of a datastore node at the time the datastore node update was created, as well as the path to the datastore node."  </ALEX>

          

          
Looks good.

            

            

            

          

            
 

            
 

            

              
(7) Perhaps the following definition is more precise?  Or by "updates"

              
do you actually mean "update records"?  There are other references to

              
"updates" in the definitions, do these all refer to "update records"? If so then I

              
would suggest moving the definition of "update record" above "datastore

              
subscription".

              
 

              
OLD:

              
 

              
"Datastore subscription: A subscription to updates regarding

              
       contents of a datastore."

              
 

              
NEW:

              
 

              
"Datastore subscription: A subscription to a stream of datastore node updates."

            

            
 

            
<ALEX> ok, changed </ALEX>

            
 

            

              
 

              
(8) Suggest removing "instantiated" from the following definition, and using

              
descendant (which is used in 7950) instead of contained .. I also suggest moving

              
the definition up, directly below "datastore node":

              
 

              
OLD:

              
 

              
    o Datastore subtree: An instantiated datastore node and the

              
       datastore nodes that are hierarchically contained within it.

              
 

              
NEW:

              
 

              
    o Datastore subtree: A  datastore node and all its descendant datastore

              
nodes."

              
 

            

            
 

            
<ALEX> changed </ALEX>

            
 

            

              
 

              
(9) Sec 3. Solution overview, last sentence.   It is not "YANG objects"

              
that are being pushed, but surely "datastore node updates" or perhaps

              
"update records" that are pushed, or even "Changes to YANG objects"

              
 

            

            
 

            
<ALEX> Changed to "datastore node updates" </ALEX>

            

              
 

              
Sec 3.1 Subscription model:

              
 

              
(10) Perhaps change"subtrees within a datastore" to "datastore subtrees".

              
 

            

            
 

            
<ALEX> changed </ALEX>

            
 

            

              
(11) It is not obvious to me from this text what "Anchor time" is,

              
although I suspect that it is described in more detail later in the

              
document.  Given that the section on-change subscriptions has more

              
detail for various parameters, I wonder whether it would be helpful to

              
describe anchor time in more detail in this section?

              
 

            

            
 

            
<ALEX> Roughly what it is is explained in the same sentence, but how about changing it as follows:

            
" These parameters are the period interval with which to report updates, and an "anchor time", i.e. a reference point in time that can be used to calculate at which points in time periodic updates need to be assembled and sent. "

            
</ALEX>

          

          
I think I get this, but didn't find it
            completely clear until I had looked at the model.  I think
            that you updated text is OK.

            

            Although I have a slight concern (e.g. in section 4.2),

            

            

            

          

            
      *  an "anchor-time"; update intervals always fall on the points in

            
         time that are a multiple of a "period" from an "anchor-time".

          

          


            I can see implementations will try and keep to this
            interval, but I suspect that the vast majority of
            implementations will not be able to guarantee that it is
            exact multiples of the given period, given that
            "anchor-time" seems to take an arbitrary sub-section
            precision, and timeticks are in hundreds of a second. 
            Possibly, weakening the text (e.g. as per below, but the
            YANG model would probably need to be updated) might be a
            good idea?

            

            

            

          

            
      *  an "anchor-time"; update intervals always fall as close as possible to the points in

            
         time that are a multiple of a "period" from an "anchor-time".

          

          

<ALEX-2>I don’t like the “as close as possibleâ€.  What is possible may differ between implementations; I feel that this formulation blurs more than it clarifies.  Perhaps we should simply remove the “always†– to read 

          
“update intervals fall on the points in time that are a multiple of a "period" from an "anchor-time" </ALEX-2>

        

      

    

    RW:

    Yes, that is probably OK, the alternative could be "SHOULD fall",
    but even that is probably a bit strong.

    

    What I want to avoid is clients assuming that they will receive
    updates exactly period interval apart, e.g. when calculating rates. 
    Instead, they should use the timestamps of the previous and current
    notification to determine the time interval to use when calculating
    any rates.

    

    

      

        

          

          


            

            

          

            
 

            
 

            

              
(12) Dampening period: The text states that "The dampening period

              
collectively applies to the set of all datastore nodes selected by a

              
single subscription and sent to a single receiver."  This would imply

              
that if a single subscription had multiple receivers that they would be

              
dampened independently, but it wasn't obvious to me that this makes

              
sense.  I would assume that for a given subscription that all receivers

              
would receive the same update records.

            

            
 

            
<ALEX> Yes.  Removed "and sent to a single receiver".  Also clarified further (in a slight rewording) " This means that when there is a change to one or more subscribed objects, an update record containing those objects is created immediately (when no dampening period is in effect) or at the end of a dampening period (when a dampening period is in fact in effect).  "

            
</ALEX>

          

          
OK.

            

            

            

          

            
 

            

              
 

              
(13) Rather than "No Sync on start", it might be better to refer to this

              
as  "sync on start", which could be defined as a boolean with default

              
true [I've not checked the YANG model]

            

            
 

            
<ALEX> it's not defined as a boolean but as a leaf of type empty.  (So, the "default" is in fact true, unless  no-sync-on-start is present).  I don't see a compelling reason to change this and suggest to keep this as-is.  

            
</ALEX>

          

          
OK.  I think that in YANG, particularly considering NMDA, it is cleaner to model this as a boolean with default true, particularly if you do a get-data request on the operational state, since it more clearly and explicitly indicates whether sync-on-start is enabled.

With the current model, on a get-data request against operation, the server returns "no-synch-on-start", it is obvious that it won't perform a sync-on-start, however, the reverse if the leaf isn't present isn't quite so clear.  If it doesn't return "no-synch-on-start" then that either means the device will perform sync-on-start, or perhaps the node the server isn't returning any information, or perhaps it has been deviated.  So, in summary, I think that flags that turn something off, are better modeled with default true, rather than as empty leafs.  Flags that turn something on can be modeled equally well either way.

          
 

          
<ALEX-2>In terms of instantiation, I find empty leaves more elegant, particularly if there is a default value.  I think <no-sync-on-start/> is more elegant than <no-sync-on-start>True</no-sync-on-start>.

          
Would you be satisfied if we turn the default around, i.e. change “no-sync-on-start†to “sync-on-startâ€, but keeping it an empty?  

          
 

          
 </ALEX-2>

        

      

    

    RW: Yes, changing it to "sync-on-start" keeping the type as empty is
    fine.

    

    

      

        

          

          
 

          

BTW, I also notice that is uses "synch" in various leaf name, but I would recommend the abbreviation "sync" instead.  It is shorter, and I think more commonly used.  https://english.stackexchange.com/questions/681/synced-or-synched
 

<ALEX-2>Have changed “synch†(and “resynchâ€) to sync / resync througout the documentt, also per Rohit’s earlier comment.  

          
</ALEX-2>

        

      

    

    RW: OK.

    

    

      

        

          

          
 

          

            
 

            

              
 

              
 

              
Sec 3.2. Negotiation of Subscription Policies

              
 

              
(14) "Random guessing at" => "Random guessing of".  Although, I think

              
that probably this first sentence, and the "Therfore, " could just be

              
deleted.  I.e. starting the paragraph "In order to minimize ..."

              
 

            

            
 

            
<ALEX> Changed "at" to "of", however, prefer to keep the first sentence as it does provide some explanation.  </ALEX>

          

          
OK.

            

            

            

          

            
 

            
 

            

              
(15) Suggest minor rewording of 3.3. third paragraph:

              
 

              
OLD:

              
 

              
In that case, updates are sent only for those objects

              
    within the scope that do support on-change updates whereas other

              
    objects are excluded from update records, whether or not their values

              
    actually change.

              
 

              
NEW:

              
 

              
In that case, updates are sent only for those objects

              
    within the scope that do support on-change updates, whereas other

              
    objects are excluded from update records, even if their values change.

              
 

            

            
<ALEX> changed </ALEX>

            
 

            

              
 

              
(16) Question on 3.3. fifth paragraph (below), it's unclear to me what

              
is meant by "which are current at the time":

              
 

              
"Values sent at the end of the

              
    dampening period are the current values of all changed objects which

              
    are current at the time the dampening period expires."

            

            
 

            
<ALEX> Rephrase the paragraph as follows, just to make it clear (it's a bit more verbose than it has to, but we want to make sure there is no question as to what value to send - the value of the original change or the value at the time of updating).  

            
"... .  Values sent at the end of the dampening period are the values that are current at the end of the dampening period of all changed objects.  Changed objects include those which were deleted or newly created during that dampening period.  If an object has returned to its original value (or even has been created and then deleted) during the dampening-period, that value (and not the interim change) will still be sent. ..."

            
</ALEX> 

          

          
Yes, I think that the longer and more
            explicit text is better.

            

            

            

          

            
 

            

              
 

              
(17) I still doubt that all implementations will strictly follow all of

              
3.3. paragraph 5, particularly the created and deleted within a

              
dampening period because I perceive that it is particularly difficult to

              
implement cleanly/efficiently.  However, this issue has been discussed

              
previously, and I have no particular desire to slow the RFC progress

              
down with further discussion on this.

              
 

            

            
 

            
<ALEX> No change made </ALEX> 

            
 

            

              
(18) Section 3.3, conceptual process, step 1 states that access control

              
rules are checked to ensure the receiver is authorized to view all

              
subscribed datastore nodes, but I think that this should state that the

              
access control rules are used to filter the subscribed datastore nodes

              
to those that the client has access rights to.

            

            
 

            
<ALEX>  I added " (and filter out any nodes for which this is not the case)" to make this clearer; this now reads " Just before a change, or at the start of a dampening period, evaluate any filtering and any access control rules to ensure receiver is authorized to view all subscribed datastore nodes (and filter out any nodes for which this is not the case). "

            
</ALEX>

          

          
OK, but I would change "and filter" to "filtering".

<ALEX-2>OK, changed </ALEX-2>

          

            
 

            

              
 

              
(19) A related question:  When happens if there is an access control

              
change, i.e. the receiver had access previously, but then it was

              
revoked.  Does it see a delete?  Or does it not get any notification?

              
Similarly, if they didn't previously have access, but then access was

              
granted before the end of the dampening period?  OK, I see that this is

              
described in more detail in section 3.9, paragraph 3.  Perhaps a forward

              
reference would be useful here.

            

            
 

            
<ALEX> I think this is defined in detail in 3.9, as you note.  I think the spirit of the description here is clear, and I don't want to overly burden the text with cross-references within the same text.  So, I suggest keeping this as-is.  

            
</ALEX>

          

          
OK.

            

            

            

          

            
 

            

              
 

              
(20) Section 3.3, last paragraph, "can be created" => "must be created".

            

            
 

            
<ALEX> Actually, I think it is "can".  It is up to the discretion of what the subscriber wants to do.   As an alternative to using the word "can" (not sure if this is really needed), rephrasing it to " In cases where a subscriber wants to have separate dampening periods for different objects, the subscriber has the option to create multiple subscriptions with different selection filters. " </ALEX>

          

          
must is correct, since that is the only available solution to the client if they want different dampening periods.  I.e. the clients choice is: don't have separate dampening periods or create separate subscriptions.  But this is a minor point, not worth lengthy discussion, so you can decide what to do.

<ALEX-2>OK, keeping it.</ALEX-2>

        

      

    

    RW: OK.

    

    

      

        

          

          


            

            

          

            
 

            

              
 

              
(21) Section 3.4, second paragraph doesn't quite scan.  "This includes

              
    indicating the fact that an update is incomplete as part of a push-

              
    update respectively push-change-update notification ..."

              
 

            

            
 

            
<ALEX> I think it does scan, but to make it just slightly more clear, how about updating to " This includes indicating the fact that an update is incomplete as part of a push-update (respectively push-change-update) notification, as well as emitting a subscription-suspended notification as applicable. "

            
</ALEX>

          

          
It is the "push-update respectively
            push-change-update" that doesn't make any sense to me.  Do
            you just mean "or", e.g. "push-update or
            push-change-update"?
            

          

            
 

            
<ALEX-2>OK, changing it to “or†(I guess my nativeness to the German language shines through here, in which there is a finer distinction between two types of “orâ€, one of which is the term “beziehungsweise†(which would be the proper choice here – yes, some words in German are longer than in English, even the abbreviation “bzw.†is still longer than “orâ€;-), which translates roughly but perhaps not exactly into “repectivelyâ€.)</ALEX-2>

          

        

      

    

    RW: Thanks.

    

    

      

        

          

            

            
 

            

              
(22) Section 3.4, 3rd paragraph, "able fulfill" => "able to fulfill"

              
 

            

            
 

            
<ALEX> changed </ALEX>

            
 

            

              
(23) Section 3.5.2, 1st paragraph, "not restricted to configuration

              
objects only" => "not only restricted to configuration objects".

              
 

            

            
 

            
<ALEX> changing to " not restricted to only configuration objects"  (the "only" refers to the configuration objects, not to the fact that it is restricted) </ALEX>

          

          
Yes., OK.

            

            

          

            
 

            
 

            

              
(24) Section 3.5.2, 2nd paragraph, possible alternative text:

              
 

              
OLD:

              
 

              
    A publisher will indicate a change to the effect that a value of a

              
    datastore node has been updated by indicating a "replace" operation

              
    (applied to the datastore node) in the patch.  When a new datastore

              
    node was created (other than an entry in a user ordered list), a

              
    publisher will indicate a "create" operation in the patch.  When a

              
    datastore node was deleted, the publisher indicates this by a

              
    "delete".  When a new entry in a user-ordered list was created, the

              
    publisher indicates this by an "insert" operation. When an entry in

              
    a user-ordered list was moved, the publisher indicates this by a

              
    "move" operation.

              
 

              
NEW:

              
 

              
   A publisher indicates the type of change to a datastore node using

              
the different YANG patch operations:  the "create" operation is used for

              
newly created objects (except entries in a user-ordered list), the

              
"delete" operation is used for deleted objects (including in

              
user-ordered lists), the "replace" operation is used when only the

              
object value changes, the "insert" operation is used when a new entry is

              
inserted in a list, and the "move" operation is used when an existing

              
entry in a user-ordered list is moved.

              
 

            

            
 

            
<ALEX> OK (I don't feel strongly about this) </ALEX>

            
 

            

              
 

              
(25) Section 3.5.2, last paragraph: If you want to allow duplicate

              
"create" and "delete" events, then it might be cleaner to encode them as

              
"merge" and "remove"?  I.e. it seems that you have created a slightly

              
different encoding from vanilla YANG patch because of the way that

              
errors are handled differently.  Ideally, it would be better if a client

              
could just apply this as regular YANG patch, but this only works with

              
the encoding described here if the clients copy of the datastore is in

              
sync with the servers old copy of the datastore at the point that the

              
patch is generated from.  This seems slightly fragile to unexpected

              
inconsistencies between client and server (which I appreciate that you

              
try and avoid).

              
 

            

            
 

            
<ALEX> Hmm.  While it may be possible to replace "delete" with "remove", I am not so sure about the "merge" part.  At the end of the day, the use here is different from having a client apply a patch operation to the server, and the semantics may be a little clearer by keeping things as they are, so would prefer to keep things as defined now.  

            
</ALEX>  

          

          
I think that is probably right.

            

            I think that it is a slight shame that vanilla YANG patch
            won't work here, but as you say I think that it will need to
            be applied in a slightly different way regardless.

            

            

          
<ALEX-2>OK.
              Keeping it.</ALEX-2>

          

            


              

              

            
 

            

              
(26) Section 3.6, second paragraph, would it not be easier to allow the

              
client to replace an existing filter rather than having to explicitly

              
remove the old filter and add the new one?  Or if you mean that any new

              
filter replaces the existing filter, then this may be more clearly

              
indicated with the text: "An RPC request proposing a new selection

              
filter replaces any existing filter. "

              
 

            

            
 

            
<ALEX> OK, changing per your suggestion to make it clear that the existing filter is replaced.  </ALEX>

            
 

            

              
(27) Section 3.6, paragraph 6, starting "XPath".  The "boolean" example

              
is unclear to me given that a xpath filter always returns a node set so

              
can't return a boolean result.  I also suggest changing "passes a

              
datastore node" to  "includes a datastore node".

            

            
 

            
<ALEX> removed the sentence and shortened the paragraph.  It now reads as follows: 

            
" XPath itself provides powerful filtering constructs and care must be used in filter definition. Consider an XPath filter which only passes a datastore node when an interface is up. It is up to the receiver to understand implications of the presence or absence of objects in each update. "

            
</ALEX>

          

          
OK.

            

            

            

            

          

            
 

            

              
 

              
(28) Section 3.6, paragraph 7.  I think that the text must be more

              
explicit on when the filter is evaluated for a periodic subscription.

              
Am I right in thinking that it is only evaluated once when the

              
subscription is created, or the subscription is changed? Specifically,

              
if the nodeset evaluated during the lifetime of an Xpath subscription

              
changes then does that affect which nodes are returned?

              
 

            

            
 

            
<ALEX> Not sure what changes you are looking for.  The filter is in effect throughout the subscription until it is changed.  It is up to an implementation to decide whether to apply it once when the subscription is established to determine the datastore nodes (tracking any subtree changes to make sure nodes in the subtrees are included as needed), or whether to apply it at each update anew.    

            
As far as receiver authorization is concerned (i.e. access control filters), this is explained in section 3.9.  Applying no text changes at this point unless you can be more clear on what you would like to see?

            
</ALEX>

          

          
OK.  Not considering NACM, I think that
            is already covered, was thinking of an Xpath filter.  I am
            right in thinking that logically the Xpath filter is
            [re-]applied whenever the periodic push notification is
            constructed.

            

            If so, possibly change:

            

            "   When the set of
                selection filtering criteria is applied for a

                 periodic subscription, all selected datastore nodes
                to which a

                 receiver has access are provided to that receiver."

            

            To something along the lines of ...

            

            "   When the set of
                selection filtering criteria is applied for a

                periodic subscription, then they are applied
                whenever a periodic

                update record is constructed, and only datastore
                nodes that pass

                the filter and to which a receiver has access are
                provided to

                that receiver."

            

            

            

          

            
<ALEX-2>OK,
                I am making the change as suggested.  (However,
                presumably an implementation could choose to apply the
                filter to select the set of datastore nodes once, and
                then, assuming the filter and set of datastore nodes
                don’t change, simply send updates about the nodes form
                the set, no?) </ALEX-2>

          

        

      

    

    RW:

    If the set of filtered nodes is that same at each periodic update
    then it is equivalent to applying the filter once.

    

    I was more thinking of an XPath example (e.g. inclusion of a node in
    the nodeset depends on whether an interface is up).  Here, the
    filter logically needs to be re-calculated at each periodic
    interface to ensure that the right nodes are returned.

    

    

      

        

          

            

            
 

            
 

            
 

            

              
(29) Section 3.7, paragraph 3:  Perhaps make this text conditional to

              
dampened subscriptions.  Presumably for non dampened subscriptions all

              
changes are reported as separate push-change-update notifications?

              
 

              
OLD:

              
In cases where multiple changes have occurred and the object

              
    has not been deleted, the object's most current value is reported.

              
 

              
NEW:

              
In cases where multiple changes have occurred in a subscription that has

              
dampening enabled, and the object

              
    has not been deleted, the object's most current value is reported.

              
 

            

            
 

            
<ALEX> Well, the text states clearly that this concerns any changes since the last notification message.  So, the fact that dampening is enabled is already implied. 

            
How about rephrasing slightly as follows:

            
" In cases where multiple changes have occurred over the course of a dampening period and the object has not been deleted, the object's most current value is reported.  "

            
</ALEX>

          

          
This text is fine.

            

            But this raises another question:

            

            If no dampening is enabled, then is it expected that all
            changes to an object are always notified.  [If this is a
            requirement, then I think that it should probably be stated
            clearly in the YANG model and perhaps in section 3 as well.]

            

            Specifically, say you are monitoring interface state,
            without dampening, and it starts to flap 100 times per
            second.  Is the publisher required to notify of every single
            change.  Or is the publisher only required to notify that
            the at least one change has occurred, and guarantee that it
            always notifies the latest value.

            

            <ALEX-2>
              This is exactly the reason why dampening was introduced. 
              I think this is well documented.  If a subscriber does not
              turn on dampening, and thus the server gets overwhelmed,
              they can suspend or terminate the subscription.  In that
              case they should give a “period-unsupported†error. 
              

          
Thinking
              about it some more, this needs to be more clearly spelled
              out in the description of “period-unsupportedâ€. 
            

        

      

    

    RW:

    OK, but there are other ways of solving this that may be more
    appropriate for some objects like interface states.

    

    E.g. it is quite possible that I can't have a single dampened
    subscription for all interface states because I don't want a down
    event on one interface to prevent fast down notification of another
    interface in the same subscription.  Nor does having a separate
    subscription for each of (10,000+ interfaces appeal).

    

    For interface states, the proper solution is to use a feature like
    carrier delay that limits flaps in a sensible way (fast down, slow
    up), and that is done on a per interface basis outside of YANG. 
    I.e. the stream of changes is limited enough that dampening is not
    required.

    

    I think that a future draft (or drafts) may want to look at other
    forms of dampening.

    

    But for this draft, I still think that it needs to be clear for a
    subscription without dampening if the server MUST notify of *every*
    change.

    

    

    

      

        

          

          
 

          
Changing
              the YANG definition (descriptino statement) as follows:

          
 
              identity period-unsupported {

          
   
              base sn:establish-subscription-error;

          
   
              base sn:modify-subscription-error;

          
   
              base sn:subscription-suspended-reason;

          
   
              description
              

          
      "Requested
              time period or dampening-period is too short. This
              

          
      can
              be for both periodic and on-change subscriptions (with or
              

          
      without
              dampening.) Hints suggesting alternative periods may
              

          
      be
              returned as supplemental information.";

          
 
              }

          
</ALEX-2>

          
 

          

            
 

            
 

            

              
 

              
(30) Section 3.7, paragraph 5, "Ethernet port" => "Ethernet interface"

              
 

            

            
 

            
<ALEX> changed </ALEX>

            
 

            

              
(31) Section 3.7, last paragraph: Why start at "1" rather than "0". On

              
overflow, why overflow to "1" rather than "0", is that deliberate?  If

              
you are going to force it to "1" then I would also restrict the upper

              
bound to int32 max rather than uint32 max to make life easier in Java

              
land ...

            

            
 

            
<ALEX> OK, got it.  Updated the text to reflect start at 0.  

            
</ALEX> 

            
 

            

              
 

              
(32) Section 3.8, tree diagrams.  I would think that another key metric

              
regarding whether a subscription can be satisfied would be object-rate

              
and data-rate.  E.g. a publisher implementation may be able to push 100k

              
objects/second, so a client has a choice of either monitoring less

              
objects, or decreasing the period.  Hence I was wondering whether rates

              
should be provided in addition to the object-count-estimate/limit and

              
kilobyte-estimate/limit.  Of course, a rate is also implicitly defined

              
by including the period hint, so perhaps that is sufficient without

              
needing to send more fields back to the client.

              
 

            

            
 

            
<ALEX> Would prefer to keep this to the basics, i.e. as-is.  As mentioned, you can compute a rate from this.  </ALEX>

          

          
Yes, that is fine.  Additional fields
            could be augmented in future if needed.

            

            

            

          

            
 

            
 

            

              
(33) Section 3.9, 2nd paragraph, "particular each" => "particular"

            

            
 

            
<ALEX> changed </ALEX>

            
 

            

              
 

              
(34) Section 3.9, 3rd paragraph:  It was not entirely obvious to me what

              
the 3rd paragraph text (reproduced below) actually means.  I think that

              
this boils down to:  If, after access control has been applied, there

              
are no objects remaining in an update record then only a single empty

              
"push-update" notification MAY be sent and empty "push-change-update"

              
messages MUST NOT be sent.  This is required to ensure that clients

              
cannot surreptitiously monitor objects that they do not have access to

              
via carefully crafted selection filters.

              
 

              
"A publisher MUST allow for the possibility that a subscription's

              
    selection filter references non-existent or access-protected data.

              
    Such support permits a receiver the ability to monitor the entire

              
    lifecyle of some datastore tree.  In this case, all "push-update"

              
    notifications must be sent empty, and no "push-change-update"

              
    notifications will be sent until some data becomes visible for a

              
    receiver."

              
 

            

            
 

            
<ALEX> Modified the paragraph already due to another comment in another thread.  Updated this further per your comments.  Now it reads as follows:

            
" A publisher MUST allow for the possibility that a subscription's selection filter references non-existent data or data that a receiver is not allowed to access.  Such support permits a receiver the ability to monitor the entire lifecyle of some datastore tree without needing to explicitly enumerate every individual datastore node.  If, after access control has been applied, there are no objects remaining in an update record, then (in case of a periodic subscription) only a single empty "push-update" notification MAY be sent. Empty "push-change-update" messages (in case of an on-change subscription) MUST NOT be sent.  This is required to ensure that clients cannot surreptitiously monitor objects that they do not have access to via carefully crafted selection filters."

            
 

            
Also adding the following sentence, to clarify the effect on dampening: " By the same token, changes to objects that are filtered MUST NOT affect any dampening intervals."

            
</ALEX>

          

          
Text looks good.  My only question is on
            the sentence with the MAY. I've been told by some old hands
            that everywhere you see "MAY" in an RFC then it is entirely
            valid to also interpret that as "MAY NOT".

            

            I think that it should perhaps be:

            

            "... then (in case of a periodic subscription) the publisher
            MUST only send single empty "push-update" notification.

            

            or, alternatively (if you don't want MUST):

            

            "... then (in case of a periodic subscription) the publisher
            is allowed to send only a single empty "push-update"
            notification.

            

            

            

          
<ALEX-2>

          
I
              don’t see how “allowed to†really changes the meaning of
              “MAYâ€, so I am taking your suggestion and am replacing the
              MAY with MUST. 
              

          
</ALEX-2>

        

      

    

    RW: OK

    

    Thanks,

    Rob

    

    

    

      

        

          

          
 

          

            
 

            
 

            

              
(35) Section 3.10.  This text seems to be very closely related to the

              
text in section 3.3, so perhaps section 3.10 would be better moved to

              
become section 3.3.1?

              
 

            

            
 

            
<ALEX>

            
Don't want to apply major editorial restructuing at this point.

            
</ALEX>

          

          
That is fine.

            

            

            

          

            
 

            
 

            

              
(36) Section 3.10, last paragraph.  "will be expected to" => "SHOULD"?

            

            
 

            
<ALEX>Not sure we want it to sound so normative, but sure - changing it to SHOULD. </ALEX>

            
 

            

              
 

              
(37) Section 3.11.1 "incomplete-update" flag.  In the YANG definition

              
this flag is set in the header of the message (i.e. before the data),

              
but for applications that are generating the notifications in a streamed

              
way, it would probably be better to put the flag after data.  This

              
potentially minimizes the requirement that a publisher has to buffer all

              
data to be able to set the incomplete-update flag if necessary.

            

            
 

            
<ALEX> OK, so you are suggesting to move the "incomplete-update" leaf behind the datastore contents (respectively datastore-changes).   Sure, will change that. 

            
</ALEX>

          

          
Yes, thanks.

            

            

            

          

            
  

            
 

            

              
 

              
(38) Section 3.11.1 3rd paragraph and bullet points.  With the text as

              
currently written, it is acceptable for a publisher to do nothing even

              
if an error is hit.  They can satisfy the first "MUST" by selecting the

              
2nd choice, and they can satisfy the "MAY" of the second choice by doing

              
nothing at all.  Instead I think that the text should state that the

              
publisher MUST set the "incomplete-update" flag, or suspend the

              
subscription, or both.

              
 

            

            
 

            
<ALEX>

            
OK, I think the problem is with "MUST take on or more of the following actions"  (although I think what is meant is clear).  Rephrasing this as follows:  " In this case, the publisher MUST act as follows."

            
 

            
Also adding the following to the second bullet item: 

            
" If the publisher does not create an update record at all, it MUST suspend the subscription.  " 

            
 (This is really the only logical choice; we don't want a publisher to have the option of staying entirely silent.)  

          

          
Yes, the change looks good.

            

            Thanks,

            Rob

            <ALEX-2>

          
Thanks,
              Rob

          
---
              Alex

          
</ALEX-2>

          


            

            

            

          

            
 

            
 

            
--- Alex

            
</ALEX>

            
 

            

              
Thanks,

              
Rob

              
 

              
_______________________________________________

              
Netconf mailing list

              
Netconf@ietf.org

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

            

          

          
 

        

      

    

    

  


--------------FC76366E65BFB332F728E895--


From nobody Mon Sep 10 02:33:12 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A176130DE7 for ; Mon, 10 Sep 2018 02:33:10 -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 ButjdeI1iVdu for ; Mon, 10 Sep 2018 02:33:08 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 29B39127332 for ; Mon, 10 Sep 2018 02:33:08 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id C787A1AE018A; Mon, 10 Sep 2018 11:33:06 +0200 (CEST)
Date: Mon, 10 Sep 2018 11:33:06 +0200 (CEST)
Message-Id: <20180910.113306.485462508157787231.mbj@tail-f.com>
To: alexander.clemm@huawei.com
Cc: netconf@ietf.org, evoit@cisco.com
From: Martin Bjorklund 
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CABF@sjceml521-mbs.china.huawei.com>
References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5B91A@sjceml521-mbs.china.huawei.com> <20180830.081021.1805437789668143807.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CABF@sjceml521-mbs.china.huawei.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Sep 2018 09:33:10 -0000

Hi,


Alexander Clemm  wrote:
> Hi Martin,
> 
> please see my responses inline, , trimming the closed stuff
> ("Ok.")
> 
> Thanks
> --- Alex
> ...
> > 
> > > > > > > > o  3.11.1
> > > > > > > >
> > > > > > > >   The text says:
> > > > > > > >
> > > > > > > >    It is not
> > > > > > > >    required to merge pending update messages.
> > > > > > > >
> > > > > > > >   This can be read as indicating that a server MAY merge pending
> > > > > > > >   update messages.  I assume that it should say that pending
> > > > > > > >   update
> > > > > > > >   messages MUST NOT be merged.
> > > > > > >
> > > > > > >  Hmm.  I am not sure I agree.  The server is not
> > > > > > > required to merge pending update messages - i.e. can send
> > > > > > > multiple messages each with a separate update record.
> > > > > > > However, there is no reason to preclude that they could be
> > > > > > > combined.  So, I don't think an update is needed here.
> > > > > > > 
> > > > > >
> > > > > > So you say that the text means that the server MAY merge pending
> > > > > > update messages in this case?  If so, I think you should update
> > > > > > the text so that this is clear.
> > > > > >
> > >
> > >  OK, how about saying "The server MAY (but does not have to)
> > > merge pending update messages". 
> > 
> > Well, the term "update message" is not defined, so it shouldn't be
> > used.
> > Presumably you mean "update record".
> 
>  sure 
> 
> > 
> > But I still don't really understand how this is supposed to work.  The
> > push-code in
> > the publisher creates an update record A and hands it over to the
> > transport
> > layer, where it is queued:
> > 
> >    It is perfectly acceptable to have a series of "push-change-
> >    update" notifications (and even "push update" notifications) serially
> >    queued at the transport layer awaiting transmission.
> > 
> > Then the push-code in the publisher creates another update record B
> > and hands
> > it over to the transport layer.
> > 
> > Are you saying that the transport layer code now can merge these two
> > update
> > records into a single record?

You didn't answer this question.

> > So if record A had "create foo, delete
> > bar" and
> > record B had "delete foo", there would be a single record with "delete
> > bar,
> > delete foo"?

You didn't answer this question.

> > If two records are merged, what happens to the idea of using the
> > 'patch-id' as
> > an indication of lost records?

You didn't answer this question.


>  All this is saying is that it is up to the publisher to decide
> how to "group" the updates: whether to send a single update record (in
> a single notification), or whether to create multiple records (sent
> with multiple notifications).
> To make this clear, slight updates as follows:
> " It is perfectly acceptable to have a series of "push-change-update"
> notifications (and even "push update" notifications) serially queued
> at the transport layer awaiting transmission.  It is not required for
> the publisher to merge pending update records sent at the the same
> time."
> 

I think that if you really want to allow such merging, it needs to be
described how it is supposed to be done, e.g. wrt. the patch-id.  But
I would rather see that this "merging" feature is removed.

(In one sense, it doesn't matter much; it is an optional behaviour so
since I don't understand it, I can simply just not implement it.)



/martin


From nobody Mon Sep 10 02:49:02 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD0C130E62 for ; Mon, 10 Sep 2018 02:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 x9pUHA5qDE2r for ; Mon, 10 Sep 2018 02:48:59 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 71DFB130E48 for ; Mon, 10 Sep 2018 02:48:59 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id AD2041AE018A; Mon, 10 Sep 2018 11:48:58 +0200 (CEST)
Date: Mon, 10 Sep 2018 11:48:58 +0200 (CEST)
Message-Id: <20180910.114858.2047503111224561678.mbj@tail-f.com>
To: rwilton=40cisco.com@dmarc.ietf.org
Cc: alexander.clemm@huawei.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <8941118a-33de-22c7-cf9e-7a836c18c063@cisco.com>
References: <8b2bd7da-7fd3-907d-1df0-947ce2052904@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5CE72@sjceml521-mbs.china.huawei.com> <8941118a-33de-22c7-cf9e-7a836c18c063@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [Netconf] RGW YANG push -18 LC comments [part 1]
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Sep 2018 09:49:01 -0000

SGksDQoNCkkgaGF2ZSBvbmUgY29tbWVudCBvbiB0aGlzIHRocmVhZC4NCg0KUm9iZXJ0IFdpbHRv
biA8cndpbHRvbj00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+IE9uIDA2LzA5
LzIwMTggMjA6MzUsIEFsZXhhbmRlciBDbGVtbSB3cm90ZToNCg0KWy4uLl0NCg0KPiA+ICAgICAg
ICAgKDEzKSBSYXRoZXIgdGhhbiAiTm8gU3luYyBvbiBzdGFydCIsIGl0IG1pZ2h0IGJlIGJldHRl
ciB0byByZWZlciB0bw0KPiA+ICAgICAgICAgdGhpcw0KPiA+DQo+ID4gICAgICAgICBhc8KgICJz
eW5jIG9uIHN0YXJ0Iiwgd2hpY2ggY291bGQgYmUgZGVmaW5lZCBhcyBhIGJvb2xlYW4gd2l0aCBk
ZWZhdWx0DQo+ID4NCj4gPiAgICAgICAgIHRydWUgW0kndmUgbm90IGNoZWNrZWQgdGhlIFlBTkcg
bW9kZWxdDQo+ID4NCj4gPiAgICAgPEFMRVg+IGl0J3Mgbm90IGRlZmluZWQgYXMgYSBib29sZWFu
IGJ1dCBhcyBhIGxlYWYgb2YgdHlwZSBlbXB0eS7CoA0KPiA+ICAgICAoU28sIHRoZSAiZGVmYXVs
dCIgaXMgaW4gZmFjdCB0cnVlLCB1bmxlc3PCoCBuby1zeW5jLW9uLXN0YXJ0IGlzDQo+ID4gICAg
IHByZXNlbnQpLsKgIEkgZG9uJ3Qgc2VlIGEgY29tcGVsbGluZyByZWFzb24gdG8gY2hhbmdlIHRo
aXMgYW5kIHN1Z2dlc3QNCj4gPiAgICAgdG8ga2VlcCB0aGlzIGFzLWlzLg0KPiA+DQo+ID4gICAg
IDwvQUxFWD4NCj4gPg0KPiA+IE9LLsKgIEkgdGhpbmsgdGhhdCBpbiBZQU5HLCBwYXJ0aWN1bGFy
bHkgY29uc2lkZXJpbmcgTk1EQSwgaXQgaXMNCj4gPiBjbGVhbmVyIHRvIG1vZGVsIHRoaXMgYXMg
YSBib29sZWFuIHdpdGggZGVmYXVsdCB0cnVlLCBwYXJ0aWN1bGFybHkgaWYNCj4gPiB5b3UgZG8g
YSBnZXQtZGF0YSByZXF1ZXN0IG9uIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSwgc2luY2UgaXQgbW9y
ZQ0KPiA+IGNsZWFybHkgYW5kIGV4cGxpY2l0bHkgaW5kaWNhdGVzIHdoZXRoZXIgc3luYy1vbi1z
dGFydCBpcyBlbmFibGVkLg0KPiA+DQo+ID4gV2l0aCB0aGUgY3VycmVudCBtb2RlbCwgb24gYSBn
ZXQtZGF0YSByZXF1ZXN0IGFnYWluc3Qgb3BlcmF0aW9uLCB0aGUNCj4gPiBzZXJ2ZXIgcmV0dXJu
cyAibm8tc3luY2gtb24tc3RhcnQiLCBpdCBpcyBvYnZpb3VzIHRoYXQgaXQgd29uJ3QNCj4gPiBw
ZXJmb3JtIGEgc3luYy1vbi1zdGFydCwgaG93ZXZlciwgdGhlIHJldmVyc2UgaWYgdGhlIGxlYWYg
aXNuJ3QNCj4gPiBwcmVzZW50IGlzbid0IHF1aXRlIHNvIGNsZWFyLsKgIElmIGl0IGRvZXNuJ3Qg
cmV0dXJuDQo+ID4gIm5vLXN5bmNoLW9uLXN0YXJ0IiB0aGVuIHRoYXQgZWl0aGVyIG1lYW5zIHRo
ZSBkZXZpY2Ugd2lsbCBwZXJmb3JtDQo+ID4gc3luYy1vbi1zdGFydCwgb3IgcGVyaGFwcyB0aGUg
bm9kZSB0aGUgc2VydmVyIGlzbid0IHJldHVybmluZyBhbnkNCj4gPiBpbmZvcm1hdGlvbiwgb3Ig
cGVyaGFwcyBpdCBoYXMgYmVlbiBkZXZpYXRlZC7CoCBTbywgaW4gc3VtbWFyeSwgSSB0aGluaw0K
PiA+IHRoYXQgZmxhZ3MgdGhhdCB0dXJuIHNvbWV0aGluZyBvZmYsIGFyZSBiZXR0ZXIgbW9kZWxl
ZCB3aXRoIGRlZmF1bHQNCj4gPiB0cnVlLCByYXRoZXIgdGhhbiBhcyBlbXB0eSBsZWFmcy7CoCBG
bGFncyB0aGF0IHR1cm4gc29tZXRoaW5nIG9uIGNhbiBiZQ0KPiA+IG1vZGVsZWQgZXF1YWxseSB3
ZWxsIGVpdGhlciB3YXkuDQo+ID4gPEFMRVgtMj5JbiB0ZXJtcyBvZiBpbnN0YW50aWF0aW9uLCBJ
IGZpbmQgZW1wdHkgbGVhdmVzIG1vcmUgZWxlZ2FudCwNCj4gPiBwYXJ0aWN1bGFybHkgaWYgdGhl
cmUgaXMgYSBkZWZhdWx0IHZhbHVlLiDCoEkgdGhpbmsgPG5vLXN5bmMtb24tc3RhcnQvPg0KPiA+
IGlzIG1vcmUgZWxlZ2FudCB0aGFuIDxuby1zeW5jLW9uLXN0YXJ0PlRydWU8L25vLXN5bmMtb24t
c3RhcnQ+Lg0KPiA+IFdvdWxkIHlvdSBiZSBzYXRpc2ZpZWQgaWYgd2UgdHVybiB0aGUgZGVmYXVs
dCBhcm91bmQsIGkuZS4gY2hhbmdlDQo+ID4g4oCcbm8tc3luYy1vbi1zdGFydOKAnSB0byDigJxz
eW5jLW9uLXN0YXJ04oCdLCBidXQga2VlcGluZyBpdCBhbiBlbXB0eT8NCj4gPiDCoDwvQUxFWC0y
Pg0KPiBSVzogWWVzLCBjaGFuZ2luZyBpdCB0byAic3luYy1vbi1zdGFydCIga2VlcGluZyB0aGUg
dHlwZSBhcyBlbXB0eSBpcw0KPiBmaW5lLg0KDQpCdXQgdGhpcyB3b3VsZCBjaGFuZ2UgdGhlIGRl
ZmF1bHQgYmVoYXZpb3VyIHRoYXQgdGhlIFdHIGhhcyBhY2NlcHRlZC4NCkkgZG9uJ3QgdGhpbmsg
dGhpcyBpcyBhIGdvb2QgY2hhbmdlLiAgSSBhZ3JlZSB3aXRoIFJvYmVydCdzIGluaXRpYWwNCmNv
bW1lbnQgdGhhdCB0aGlzIHNob3VsZCBiZSBtb2RlbGVkIGFzIGEgbGVhZiAnc3luYy1vbi1zdGFy
dCcgb2YgdHlwZQ0KYm9vbGVhbiwgd2l0aCBkZWZhdWx0IHRydWUuICBJIHByZWZlciB0aGUgYmV0
dGVyIG1vZGVsIGJlZm9yZSBhIG1vcmUNCmVsZWdhbnQgZW5jb2RpbmcuDQoNCg0KL21hcnRpbg0K


From nobody Mon Sep 10 03:19:03 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0158C130E59 for ; Mon, 10 Sep 2018 03:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_HIGH=-0.01, 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 TUz4X6OCani3 for ; Mon, 10 Sep 2018 03:19:00 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBC7130DEB for ; Mon, 10 Sep 2018 03:18:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14129; q=dns/txt; s=iport; t=1536574739; x=1537784339; h=from:subject:to:message-id:date:mime-version; bh=d5e8DrJPMeplIGWdxje+BeL+6R0wPvmlmAVK7GzdUNI=; b=Egdf4jwJUSD7Tk60LLZd33ovzUeTgA2UglDJgNZxqquQK6jPYxGcZFu7 Ywy3olPGBiJKz6O3dvWZuWT6kAGqzvng4UME3C2+4qenZheWv98srmwhv moKeIiNnnxfCu6h/LGo68BOXWljdmZ8//vb8+por9Zhq8yYssm1CAuLk9 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AQAmRJZb/xbLJq1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYJXgkkShBqIco0jCINUjVKFR4FmC4kGOBQBAgEBAgEBAm0ohWK?= =?us-ascii?q?BFh0CXwEMCAEBgx2CAqRHgS4fhE2FDIp8gUE/gRInDIciJYMXglcCiAVDhH2?= =?us-ascii?q?BM40QCY98BheBQIcYhhiISYVPhXWBWSGBVTMaCBsVO4JtkFM+jkkBAQ?=
X-IronPort-AV: E=Sophos;i="5.53,355,1531785600"; d="scan'208,217";a="6462521"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2018 10:18:57 +0000
Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w8AAIub0005611; Mon, 10 Sep 2018 10:18:57 GMT
From: Robert Wilton 
To: "'Alexander Clemm'" , "netconf@ietf.org" 
Message-ID: 
Date: Mon, 10 Sep 2018 11:18:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------DC38323796E2C22D59D40FD8"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: [Netconf] RGW YANG push -18 LC comments [part 2]
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Sep 2018 10:19:02 -0000

This is a multi-part message in MIME format.
--------------DC38323796E2C22D59D40FD8
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Alex, authors,

Here are my remaining comments from my WG LC review of the YANG push 
draft.  Again, I think that these are all minor.

1. Sec 4.3.2, paragraph 2.  "resulted in a particular push" => "resulted 
in a particular update record"?

2. Sec 4.4.1, after Figure 7, "MAY respond" => "may respond". This is 
just an example from that normative behaviour.

3. Sec 4.4.1, paragraph starting "If a request is rejected ...".  Is it 
really right for this to be "SHOULD" rather than "MAY"?  Early text 
(e.g. 3.2. paragraph 2 uses "may be inserted".  Also in section 4.4.2, 
paragraph after Figure 11.

4. Sec 4.4.1, "Optionally, an "error-severity" of "error" (this MAY but 
does nothave to be included).", I don't think that the last clause is 
required (given that it is predicated by Optionally, so suggest deleting 
the clause in parenthesis. Otherwise it is also inconsistent with the 
following "error-info" description.  If this change, it should also be 
changed for "error-severity" in Sec 4.4.2.

5. Sec 4.4.1, NETCONF specific text about errors.  Should that text 
really be in this draft?  Would it not be nicer to keep all of the 
NETCONF specifics to a NETCONF protocol draft?  Perhaps this is not 
practical, but the WG is currently experiencing some pain where NETCONF 
protocol specific normative text is in RFC 7950.  Hence, it would be 
nice to avoid introducing that issue here if possible. This same comment 
also applies to Sec 4.4.2.

6. Sec 4.4.2, description paragraph.  Suggest the following change to 
match the actual example: "modify the "period" of a subscription." => 
"modify the "period" and "datastore XPath filter" of a subscription."

7. Sec 4.4.2, first paragraph after figure 11:  Possible rewording:

Old:

    The publisher MUST respond explicitly positively or negatively to the
    request.  If the subscription modification is rejected, the
    subscription is maintained as it was before the modification request.
    In addition, the publisher MUST send an RPC error response.  This RPC
    error response SHOULD contain hints encapsulated within the yang-data
    structure "modify-subscription-error-datastore".  A subscription MAY
    be modified multiple times.


NEW:

    The publisher MUST respond to the subscription modification request.
    If the request is rejected, the existing subscription is left unchanged, and
    the publisher MUST send an RPC error response, which MAY|SHOULD contain
    hints encapsulated within the yang-data structure
    "modify-subscription-error-datastore".  A subscription MAY be modified
    multiple times.


8. Sec 4.4.4, no figure number under the example.

9. Sec 4.4.5, paragraph 1:
I think that it would be better if this just referred to YANG library, 
hence suggest changing the first two paragraphs:

OLD:

    To make subscription requests, the subscriber needs to know the YANG
    module library available on the publisher.  The YANG 1 module library
    information is sent by a NETCONF server in the NETCONF "hello"
    message.  For YANG 1.1 modules and all modules used with the RESTCONF
    [RFC8040] protocol, this information is provided by the YANG Library
    module (ietf-yang-library.yang from [RFC7895].  This YANG library
    information is important for the receiver to reproduce the set of
    object definitions used within the publisher.

    The YANG library includes a module list with the name, revision,
    enabled features, and applied deviations for each YANG module
    implemented by the publisher.  The receiver is expected to know the
    YANG library information before starting a subscription.


NEW:

    To make subscription requests, the subscriber needs to know the YANG
    datastore schemas used by the publisher, which are available via the YANG
    Library module, ietf-yang-library.yang from [RFC7895].  The receiver
    is expected to know the YANG library information before starting a
    subscription.


YANG module:

10. Top level description statement, it looks like the copyright has 
accidentally been indented by 4 chars.

Identities:
11. I suggest renaming "no-such-subscription-resynch" to just 
"no-such-subscription".  I would have thought that this error could also 
be returned to cancel an unknown subscription.

12. "synchronization-size" doesn't sound like an error, perhaps 
"synchronization-too-big" or "resync-too-big" might be better?

Type definitions:
13.  Change all instances (create, delete, insert, move, replace) of 
"data node" to "datastore node".

14. grouping selection-filter-types, anydata datastore-subtree-filter, 
perhaps add a reference to "RFC 6241: Network Configuration Protocol, 
Section 6.", mirroring draft-ietf-netconf-nmda-netconf.

15. grouping update-policy-modifiable, container on-change description 
statement, needs to be indented by 2 spaces.

16. grouping hints, description, indent the second description line by 1 
space.

17. rpc resynch-subscription, description statement, last two lines 
require alignment.

Thanks,
Rob

--------------DC38323796E2C22D59D40FD8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Alex, authors,

    

    Here are my remaining comments from my WG LC review of the YANG push
    draft.  Again, I think that these are all minor.

    

    1. Sec 4.3.2, paragraph 2.  "resulted in a particular push" =>
    "resulted in a particular update record"?

    

    2. Sec 4.4.1, after Figure 7, "MAY respond" => "may respond". 
    This is just an example from that normative behaviour.

    

    3. Sec 4.4.1, paragraph starting "If a request is rejected ...".  Is
    it really right for this to be "SHOULD" rather than "MAY"?  Early
    text (e.g. 3.2. paragraph 2 uses "may be inserted".  Also in section
    4.4.2, paragraph after Figure 11.

    

    4. Sec 4.4.1, "Optionally, an "error-severity" of "error" (this
      MAY but does not have to be included).", I don't
    think that the last clause is required (given that it is predicated
    by Optionally, so suggest deleting the clause in parenthesis. 
    Otherwise it is also inconsistent with the following "error-info"
    description.  If this change, it should also be changed for
    "error-severity" in Sec 4.4.2.

    

    5. Sec 4.4.1, NETCONF specific text about errors.  Should that text
    really be in this draft?  Would it not be nicer to keep all of the
    NETCONF specifics to a NETCONF protocol draft?  Perhaps this is not
    practical, but the WG is currently experiencing some pain where
    NETCONF protocol specific normative text is in RFC 7950.  Hence, it
    would be nice to avoid introducing that issue here if possible. 
    This same comment also applies to Sec 4.4.2.

    

    6. Sec 4.4.2, description paragraph.  Suggest the following change
    to match the actual example: "modify the "period" of a
      subscription." => "modify the "period" and "datastore
      XPath filter" of a subscription."

    

    7. Sec 4.4.2, first paragraph after figure 11:  Possible rewording:

    

    Old:

    
   The publisher MUST respond explicitly positively or negatively to the
   request.  If the subscription modification is rejected, the
   subscription is maintained as it was before the modification request.
   In addition, the publisher MUST send an RPC error response.  This RPC
   error response SHOULD contain hints encapsulated within the yang-data
   structure "modify-subscription-error-datastore".  A subscription MAY
   be modified multiple times.

    

    NEW:

    
   The publisher MUST respond to the subscription modification request.
   If the request is rejected, the existing subscription is left unchanged, and
   the publisher MUST send an RPC error response, which MAY|SHOULD contain
   hints encapsulated within the yang-data structure
   "modify-subscription-error-datastore".  A subscription MAY be modified
   multiple times.

    

    8. Sec 4.4.4, no figure number under the example.

    

    9. Sec 4.4.5, paragraph 1:

    I think that it would be better if this just referred to YANG
    library, hence suggest changing the first two paragraphs:

    

    OLD:

    
   To make subscription requests, the subscriber needs to know the YANG
   module library available on the publisher.  The YANG 1 module library
   information is sent by a NETCONF server in the NETCONF "hello"
   message.  For YANG 1.1 modules and all modules used with the RESTCONF
   [RFC8040] protocol, this information is provided by the YANG Library
   module (ietf-yang-library.yang from [RFC7895].  This YANG library
   information is important for the receiver to reproduce the set of
   object definitions used within the publisher.

   The YANG library includes a module list with the name, revision,
   enabled features, and applied deviations for each YANG module
   implemented by the publisher.  The receiver is expected to know the
   YANG library information before starting a subscription.

    

    NEW:

    
   To make subscription requests, the subscriber needs to know the YANG
   datastore schemas used by the publisher, which are available via the YANG
   Library module, ietf-yang-library.yang from [RFC7895].  The receiver
   is expected to know the YANG library information before starting a
   subscription.

    

    YANG module:

    

    10. Top level description statement, it looks like the copyright has
    accidentally been indented by 4 chars.

    

    Identities:

    11. I suggest renaming "no-such-subscription-resynch" to just
    "no-such-subscription".  I would have thought that this error could
    also be returned to cancel an unknown subscription.

    

    12. "synchronization-size" doesn't sound like an error, perhaps
    "synchronization-too-big" or "resync-too-big" might be better?

    

    Type definitions:

    13.  Change all instances (create, delete, insert, move, replace) 
    of "data node" to "datastore node". 

    

    14. grouping selection-filter-types, anydata
    datastore-subtree-filter, perhaps add a reference to "RFC 6241:
    Network Configuration Protocol, Section 6.", mirroring
    draft-ietf-netconf-nmda-netconf.

    

    15. grouping update-policy-modifiable, container on-change
    description statement, needs to be indented by 2 spaces.

    

    16. grouping hints, description, indent the second description line
    by 1 space.

    

    17. rpc resynch-subscription, description statement, last two lines
    require alignment.

    

    Thanks,

    Rob

  


--------------DC38323796E2C22D59D40FD8--


From nobody Mon Sep 10 10:19:29 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7822F130F08 for ; Mon, 10 Sep 2018 10:19: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, 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 z72TcnLBOSTX for ; Mon, 10 Sep 2018 10:19:26 -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 44E53130EEC for ; Mon, 10 Sep 2018 10:19:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39574; q=dns/txt; s=iport; t=1536599966; x=1537809566; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NOmsUXRv+r+y9b6dWpN0rExHGfTq4PIDvdnWXQ+Rs/M=; b=DFU+fK6+2JfQkLp61iolN/svmJc2xEjFn9mDIEjGa6phBxXXdfG+rRHy D7z7wX4nk7YMt6ABGuKlud2vc9gSTWikUsj9f5M/BXD4AyFthK8id9O+P iQ0HNJb0ftXAFsJsEVziih1icyl+Y8bR/eHCvxEZ26GRnI2n9bQPgMML7 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AgBcppZb/5BdJa1TCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCV3dlfzKDaJQygg2WSIFmC4RsAheDYyE4FAECAQECAQE?= =?us-ascii?q?CbSiFOAEBAQEDIwpMEAIBCBUQEwEJAgICMCUCBA4NgxqBHWSlGIEuH4liimU?= =?us-ascii?q?XgUE/gRKCZC6EQxEUHQcqgkmCVwKIBUOEahOBM4QbiHUJAo94H4FAjTCISYs?= =?us-ascii?q?dAhEUgSU0IYFVcBU7gm2QUo1ogR0BAQ?=
X-IronPort-AV: E=Sophos;i="5.53,356,1531785600";  d="scan'208,217";a="169139555"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2018 17:19:25 +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 w8AHJOod011637 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Sep 2018 17:19:25 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.1395.4; Mon, 10 Sep 2018 13:19:24 -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.1395.000; Mon, 10 Sep 2018 13:19:24 -0400
From: "Eric Voit (evoit)" 
To: Robert Wilton 
CC: "'Alexander Clemm'" , "netconf@ietf.org" 
Thread-Topic: [Netconf] RGW YANG push -18 LC comments [part 2]
Thread-Index: AQHUSO/FNXKE0k4fYEW4TLD4dEyf0qTpskjQ
Date: Mon, 10 Sep 2018 17:19:24 +0000
Message-ID: <9743f8e24d6f448687517c83d07db025@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.234]
Content-Type: multipart/alternative; boundary="_000_9743f8e24d6f448687517c83d07db025XCHRTP013ciscocom_"
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] RGW YANG push -18 LC comments [part 2]
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Sep 2018 17:19:28 -0000

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

SGkgUm9iZXJ0LA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gIEluLWxpbmUgd2l0aCA8RXJp
Yz4uLi4uDQoNCkZyb206IFJvYmVydCBXaWx0b24sIFNlcHRlbWJlciAxMCwgMjAxOCA2OjE5IEFN
DQoNCkhpIEFsZXgsIGF1dGhvcnMsDQoNCkhlcmUgYXJlIG15IHJlbWFpbmluZyBjb21tZW50cyBm
cm9tIG15IFdHIExDIHJldmlldyBvZiB0aGUgWUFORyBwdXNoIGRyYWZ0LiAgQWdhaW4sIEkgdGhp
bmsgdGhhdCB0aGVzZSBhcmUgYWxsIG1pbm9yLg0KDQoxLiBTZWMgNC4zLjIsIHBhcmFncmFwaCAy
LiAgInJlc3VsdGVkIGluIGEgcGFydGljdWxhciBwdXNoIiA9PiAicmVzdWx0ZWQgaW4gYSBwYXJ0
aWN1bGFyIHVwZGF0ZSByZWNvcmQiPw0KDQo8RXJpYz4gQWdyZWUsIHdlIHNob3VsZCBtYWtlIHRo
aXMgdHdlYWsuDQoNCg0KMi4gU2VjIDQuNC4xLCBhZnRlciBGaWd1cmUgNywgIk1BWSByZXNwb25k
IiA9PiAibWF5IHJlc3BvbmQiLiAgVGhpcyBpcyBqdXN0IGFuIGV4YW1wbGUgZnJvbSB0aGF0IG5v
cm1hdGl2ZSBiZWhhdmlvdXIuDQoNCjxFcmljPiBBZ3JlZSwgd2Ugc2hvdWxkIG1ha2UgdGhpcyB0
d2Vhay4NCg0KDQozLiBTZWMgNC40LjEsIHBhcmFncmFwaCBzdGFydGluZyAiSWYgYSByZXF1ZXN0
IGlzIHJlamVjdGVkIC4uLiIuICBJcyBpdCByZWFsbHkgcmlnaHQgZm9yIHRoaXMgdG8gYmUgIlNI
T1VMRCIgcmF0aGVyIHRoYW4gIk1BWSI/ICBFYXJseSB0ZXh0IChlLmcuIDMuMi4gcGFyYWdyYXBo
IDIgdXNlcyAibWF5IGJlIGluc2VydGVkIi4gIEFsc28gaW4gc2VjdGlvbiA0LjQuMiwgcGFyYWdy
YXBoIGFmdGVyIEZpZ3VyZSAxMS4NCg0KPEVyaWM+IEkgcHJlZmVyIFNIT1VMRC4gIFNlY3Rpb24g
My4yIHRleHQgaGFkIOKAnG1heeKAnSBpbnN0ZWFkIG9mIOKAnE1BWeKAnS4NCg0KDQo0LiBTZWMg
NC40LjEsICJPcHRpb25hbGx5LCBhbiAiZXJyb3Itc2V2ZXJpdHkiIG9mICJlcnJvciIgKHRoaXMg
TUFZIGJ1dCBkb2VzIG5vdCBoYXZlIHRvIGJlIGluY2x1ZGVkKS4iLCBJIGRvbid0IHRoaW5rIHRo
YXQgdGhlIGxhc3QgY2xhdXNlIGlzIHJlcXVpcmVkIChnaXZlbiB0aGF0IGl0IGlzIHByZWRpY2F0
ZWQgYnkgT3B0aW9uYWxseSwgc28gc3VnZ2VzdCBkZWxldGluZyB0aGUgY2xhdXNlIGluIHBhcmVu
dGhlc2lzLiAgT3RoZXJ3aXNlIGl0IGlzIGFsc28gaW5jb25zaXN0ZW50IHdpdGggdGhlIGZvbGxv
d2luZyAiZXJyb3ItaW5mbyIgZGVzY3JpcHRpb24uICBJZiB0aGlzIGNoYW5nZSwgaXQgc2hvdWxk
IGFsc28gYmUgY2hhbmdlZCBmb3IgImVycm9yLXNldmVyaXR5IiBpbiBTZWMgNC40LjIuDQoNCjxF
cmljPiBBZ3JlZSwgd2Ugc2hvdWxkIG1ha2UgdGhpcyB0d2Vhay4NCg0KDQo1LiBTZWMgNC40LjEs
IE5FVENPTkYgc3BlY2lmaWMgdGV4dCBhYm91dCBlcnJvcnMuICBTaG91bGQgdGhhdCB0ZXh0IHJl
YWxseSBiZSBpbiB0aGlzIGRyYWZ0PyAgV291bGQgaXQgbm90IGJlIG5pY2VyIHRvIGtlZXAgYWxs
IG9mIHRoZSBORVRDT05GIHNwZWNpZmljcyB0byBhIE5FVENPTkYgcHJvdG9jb2wgZHJhZnQ/ICBQ
ZXJoYXBzIHRoaXMgaXMgbm90IHByYWN0aWNhbCwgYnV0IHRoZSBXRyBpcyBjdXJyZW50bHkgZXhw
ZXJpZW5jaW5nIHNvbWUgcGFpbiB3aGVyZSBORVRDT05GIHByb3RvY29sIHNwZWNpZmljIG5vcm1h
dGl2ZSB0ZXh0IGlzIGluIFJGQyA3OTUwLiAgSGVuY2UsIGl0IHdvdWxkIGJlIG5pY2UgdG8gYXZv
aWQgaW50cm9kdWNpbmcgdGhhdCBpc3N1ZSBoZXJlIGlmIHBvc3NpYmxlLiAgVGhpcyBzYW1lIGNv
bW1lbnQgYWxzbyBhcHBsaWVzIHRvIFNlYyA0LjQuMi4NCg0KPEVyaWM+IEFzIHRoaXMgaXMgYSBu
b24tbm9ybWF0aXZlIGV4YW1wbGUsIHdlIHNob3VsZCBub3QgaGl0IHRoZSBzYW1lIGlzc3VlLiAg
SSBkbyBsaWtlIGV4YW1wbGVzIGZvciByZWFkZXJzIHRvIGRpZ2VzdC4NCg0KDQo2LiBTZWMgNC40
LjIsIGRlc2NyaXB0aW9uIHBhcmFncmFwaC4gIFN1Z2dlc3QgdGhlIGZvbGxvd2luZyBjaGFuZ2Ug
dG8gbWF0Y2ggdGhlIGFjdHVhbCBleGFtcGxlOiAibW9kaWZ5IHRoZSAicGVyaW9kIiBvZiBhIHN1
YnNjcmlwdGlvbi4iID0+ICJtb2RpZnkgdGhlICJwZXJpb2QiIGFuZCAiZGF0YXN0b3JlIFhQYXRo
IGZpbHRlciIgb2YgYSBzdWJzY3JpcHRpb24uIg0KDQo8RXJpYz4gQWdyZWUsIHdlIHNob3VsZCBt
YWtlIHRoaXMgdHdlYWsuDQoNCg0KNy4gU2VjIDQuNC4yLCBmaXJzdCBwYXJhZ3JhcGggYWZ0ZXIg
ZmlndXJlIDExOiAgUG9zc2libGUgcmV3b3JkaW5nOg0KDQpPbGQ6DQoNCg0KICAgVGhlIHB1Ymxp
c2hlciBNVVNUIHJlc3BvbmQgZXhwbGljaXRseSBwb3NpdGl2ZWx5IG9yIG5lZ2F0aXZlbHkgdG8g
dGhlDQoNCiAgIHJlcXVlc3QuICBJZiB0aGUgc3Vic2NyaXB0aW9uIG1vZGlmaWNhdGlvbiBpcyBy
ZWplY3RlZCwgdGhlDQoNCiAgIHN1YnNjcmlwdGlvbiBpcyBtYWludGFpbmVkIGFzIGl0IHdhcyBi
ZWZvcmUgdGhlIG1vZGlmaWNhdGlvbiByZXF1ZXN0Lg0KDQogICBJbiBhZGRpdGlvbiwgdGhlIHB1
Ymxpc2hlciBNVVNUIHNlbmQgYW4gUlBDIGVycm9yIHJlc3BvbnNlLiAgVGhpcyBSUEMNCg0KICAg
ZXJyb3IgcmVzcG9uc2UgU0hPVUxEIGNvbnRhaW4gaGludHMgZW5jYXBzdWxhdGVkIHdpdGhpbiB0
aGUgeWFuZy1kYXRhDQoNCiAgIHN0cnVjdHVyZSAibW9kaWZ5LXN1YnNjcmlwdGlvbi1lcnJvci1k
YXRhc3RvcmUiLiAgQSBzdWJzY3JpcHRpb24gTUFZDQoNCiAgIGJlIG1vZGlmaWVkIG11bHRpcGxl
IHRpbWVzLg0KDQpORVc6DQoNCg0KICAgVGhlIHB1Ymxpc2hlciBNVVNUIHJlc3BvbmQgdG8gdGhl
IHN1YnNjcmlwdGlvbiBtb2RpZmljYXRpb24gcmVxdWVzdC4NCg0KICAgSWYgdGhlIHJlcXVlc3Qg
aXMgcmVqZWN0ZWQsIHRoZSBleGlzdGluZyBzdWJzY3JpcHRpb24gaXMgbGVmdCB1bmNoYW5nZWQs
IGFuZA0KDQogICB0aGUgcHVibGlzaGVyIE1VU1Qgc2VuZCBhbiBSUEMgZXJyb3IgcmVzcG9uc2Us
IHdoaWNoIE1BWXxTSE9VTEQgY29udGFpbg0KDQogICBoaW50cyBlbmNhcHN1bGF0ZWQgd2l0aGlu
IHRoZSB5YW5nLWRhdGEgc3RydWN0dXJlDQoNCiAgICJtb2RpZnktc3Vic2NyaXB0aW9uLWVycm9y
LWRhdGFzdG9yZSIuICBBIHN1YnNjcmlwdGlvbiBNQVkgYmUgbW9kaWZpZWQNCg0KICAgbXVsdGlw
bGUgdGltZXMuDQoNCjxFcmljPiBQcm9wb3NlZCB0ZXh0IGxvb2tzIGZpbmUsIHdpdGggYSBzbWFs
bCB0d2VhazoNCg0KVGhlIHB1Ymxpc2hlciBNVVNUIHJlc3BvbmQgdG8gdGhlIHN1YnNjcmlwdGlv
biBtb2RpZmljYXRpb24gcmVxdWVzdC4gIElmIHRoZSByZXF1ZXN0IGlzIHJlamVjdGVkLCB0aGUg
ZXhpc3Rpbmcgc3Vic2NyaXB0aW9uIGlzIGxlZnQgdW5jaGFuZ2VkLCBhbmQgdGhlIHB1Ymxpc2hl
ciBNVVNUIHNlbmQgYW4gUlBDIGVycm9yIHJlc3BvbnNlLiAgVGhpcyByZXNwb25zZSBtaWdodCBo
YXZlIGhpbnRzIGVuY2Fwc3VsYXRlZCB3aXRoaW4gdGhlIHlhbmctZGF0YSBzdHJ1Y3R1cmUgIm1v
ZGlmeS1zdWJzY3JpcHRpb24tZXJyb3ItZGF0YXN0b3JlIi4gIEEgc3Vic2NyaXB0aW9uIE1BWSBi
ZSBtb2RpZmllZCBtdWx0aXBsZSB0aW1lcy4NCg0KDQo4LiBTZWMgNC40LjQsIG5vIGZpZ3VyZSBu
dW1iZXIgdW5kZXIgdGhlIGV4YW1wbGUuDQoNCjxFcmljPiBBZ3JlZS4gIEFsZXgsIGNhbiB5b3Ug
dHdlYWsgdGhlIFhNTD8NCg0KDQo5LiBTZWMgNC40LjUsIHBhcmFncmFwaCAxOg0KSSB0aGluayB0
aGF0IGl0IHdvdWxkIGJlIGJldHRlciBpZiB0aGlzIGp1c3QgcmVmZXJyZWQgdG8gWUFORyBsaWJy
YXJ5LCBoZW5jZSBzdWdnZXN0IGNoYW5naW5nIHRoZSBmaXJzdCB0d28gcGFyYWdyYXBoczoNCg0K
T0xEOg0KDQoNCiAgIFRvIG1ha2Ugc3Vic2NyaXB0aW9uIHJlcXVlc3RzLCB0aGUgc3Vic2NyaWJl
ciBuZWVkcyB0byBrbm93IHRoZSBZQU5HDQoNCiAgIG1vZHVsZSBsaWJyYXJ5IGF2YWlsYWJsZSBv
biB0aGUgcHVibGlzaGVyLiAgVGhlIFlBTkcgMSBtb2R1bGUgbGlicmFyeQ0KDQogICBpbmZvcm1h
dGlvbiBpcyBzZW50IGJ5IGEgTkVUQ09ORiBzZXJ2ZXIgaW4gdGhlIE5FVENPTkYgImhlbGxvIg0K
DQogICBtZXNzYWdlLiAgRm9yIFlBTkcgMS4xIG1vZHVsZXMgYW5kIGFsbCBtb2R1bGVzIHVzZWQg
d2l0aCB0aGUgUkVTVENPTkYNCg0KICAgW1JGQzgwNDBdIHByb3RvY29sLCB0aGlzIGluZm9ybWF0
aW9uIGlzIHByb3ZpZGVkIGJ5IHRoZSBZQU5HIExpYnJhcnkNCg0KICAgbW9kdWxlIChpZXRmLXlh
bmctbGlicmFyeS55YW5nIGZyb20gW1JGQzc4OTVdLiAgVGhpcyBZQU5HIGxpYnJhcnkNCg0KICAg
aW5mb3JtYXRpb24gaXMgaW1wb3J0YW50IGZvciB0aGUgcmVjZWl2ZXIgdG8gcmVwcm9kdWNlIHRo
ZSBzZXQgb2YNCg0KICAgb2JqZWN0IGRlZmluaXRpb25zIHVzZWQgd2l0aGluIHRoZSBwdWJsaXNo
ZXIuDQoNCg0KDQogICBUaGUgWUFORyBsaWJyYXJ5IGluY2x1ZGVzIGEgbW9kdWxlIGxpc3Qgd2l0
aCB0aGUgbmFtZSwgcmV2aXNpb24sDQoNCiAgIGVuYWJsZWQgZmVhdHVyZXMsIGFuZCBhcHBsaWVk
IGRldmlhdGlvbnMgZm9yIGVhY2ggWUFORyBtb2R1bGUNCg0KICAgaW1wbGVtZW50ZWQgYnkgdGhl
IHB1Ymxpc2hlci4gIFRoZSByZWNlaXZlciBpcyBleHBlY3RlZCB0byBrbm93IHRoZQ0KDQogICBZ
QU5HIGxpYnJhcnkgaW5mb3JtYXRpb24gYmVmb3JlIHN0YXJ0aW5nIGEgc3Vic2NyaXB0aW9uLg0K
DQpORVc6DQoNCg0KICAgVG8gbWFrZSBzdWJzY3JpcHRpb24gcmVxdWVzdHMsIHRoZSBzdWJzY3Jp
YmVyIG5lZWRzIHRvIGtub3cgdGhlIFlBTkcNCg0KICAgZGF0YXN0b3JlIHNjaGVtYXMgdXNlZCBi
eSB0aGUgcHVibGlzaGVyLCB3aGljaCBhcmUgYXZhaWxhYmxlIHZpYSB0aGUgWUFORw0KDQogICBM
aWJyYXJ5IG1vZHVsZSwgaWV0Zi15YW5nLWxpYnJhcnkueWFuZyBmcm9tIFtSRkM3ODk1XS4gIFRo
ZSByZWNlaXZlcg0KDQogICBpcyBleHBlY3RlZCB0byBrbm93IHRoZSBZQU5HIGxpYnJhcnkgaW5m
b3JtYXRpb24gYmVmb3JlIHN0YXJ0aW5nIGENCg0KICAgc3Vic2NyaXB0aW9uLg0KDQo8RXJpYz4g
QWdyZWUsIHdlIHNob3VsZCBtYWtlIHRoaXMgdHdlYWsuDQoNCg0KWUFORyBtb2R1bGU6DQoNCjEw
LiBUb3AgbGV2ZWwgZGVzY3JpcHRpb24gc3RhdGVtZW50LCBpdCBsb29rcyBsaWtlIHRoZSBjb3B5
cmlnaHQgaGFzIGFjY2lkZW50YWxseSBiZWVuIGluZGVudGVkIGJ5IDQgY2hhcnMuDQoNCjxFcmlj
PiBBZ3JlZSwgd2Ugc2hvdWxkIG1ha2UgdGhpcyB0d2Vhay4NCg0KDQpJZGVudGl0aWVzOg0KMTEu
IEkgc3VnZ2VzdCByZW5hbWluZyAibm8tc3VjaC1zdWJzY3JpcHRpb24tcmVzeW5jaCIgdG8ganVz
dCAibm8tc3VjaC1zdWJzY3JpcHRpb24iLiAgSSB3b3VsZCBoYXZlIHRob3VnaHQgdGhhdCB0aGlz
IGVycm9yIGNvdWxkIGFsc28gYmUgcmV0dXJuZWQgdG8gY2FuY2VsIGFuIHVua25vd24gc3Vic2Ny
aXB0aW9uLg0KDQo8ZXJpYz4gVGhlIHJlYXNvbiB3ZSBuZWVkICJuby1zdWNoLXN1YnNjcmlwdGlv
bi1yZXN5bmNoIiBpcyB0aGF0ICJuby1zdWNoLXN1YnNjcmlwdGlvbiIgaXMgYWxyZWFkeSB1c2Vk
IGluIFNOLiAgKEkuZS4sIGlzIG5vdCBwb3NzaWJsZSB0byBhdWdtZW50IHRoZSBleGlzdGluZyBp
ZGVudGl0eSB3aXRoIGEgbmV3IGJhc2UuKQ0KDQoNCjEyLiAic3luY2hyb25pemF0aW9uLXNpemUi
IGRvZXNuJ3Qgc291bmQgbGlrZSBhbiBlcnJvciwgcGVyaGFwcyAic3luY2hyb25pemF0aW9uLXRv
by1iaWciIG9yICJyZXN5bmMtdG9vLWJpZyIgbWlnaHQgYmUgYmV0dGVyPw0KDQo8ZXJpYz4gSSBo
YXZlIG5vIHByb2JsZW0gd2l0aCBjaGFuZ2luZyBpdCB0byAic3luY2hyb25pemF0aW9uLXRvby1i
aWciLCB0aGF0IGFsaWducyB0byB0aGUgb3RoZXIgaWRlbnRpdHkgInVwZGF0ZS10b28tYmlnIg0K
DQoNClR5cGUgZGVmaW5pdGlvbnM6DQoNCjEzLiAgQ2hhbmdlIGFsbCBpbnN0YW5jZXMgKGNyZWF0
ZSwgZGVsZXRlLCBpbnNlcnQsIG1vdmUsIHJlcGxhY2UpICBvZiAiZGF0YSBub2RlIiB0byAiZGF0
YXN0b3JlIG5vZGUiLg0KDQoxNC4gZ3JvdXBpbmcgc2VsZWN0aW9uLWZpbHRlci10eXBlcywgYW55
ZGF0YSBkYXRhc3RvcmUtc3VidHJlZS1maWx0ZXIsIHBlcmhhcHMgYWRkIGEgcmVmZXJlbmNlIHRv
ICJSRkMgNjI0MTogTmV0d29yayBDb25maWd1cmF0aW9uIFByb3RvY29sLCBTZWN0aW9uIDYuIiwg
bWlycm9yaW5nIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLW5ldGNvbmYuDQoNCjE1LiBncm91cGlu
ZyB1cGRhdGUtcG9saWN5LW1vZGlmaWFibGUsIGNvbnRhaW5lciBvbi1jaGFuZ2UgZGVzY3JpcHRp
b24gc3RhdGVtZW50LCBuZWVkcyB0byBiZSBpbmRlbnRlZCBieSAyIHNwYWNlcy4NCg0KMTYuIGdy
b3VwaW5nIGhpbnRzLCBkZXNjcmlwdGlvbiwgaW5kZW50IHRoZSBzZWNvbmQgZGVzY3JpcHRpb24g
bGluZSBieSAxIHNwYWNlLg0KDQoxNy4gcnBjIHJlc3luY2gtc3Vic2NyaXB0aW9uLCBkZXNjcmlw
dGlvbiBzdGF0ZW1lbnQsIGxhc3QgdHdvIGxpbmVzIHJlcXVpcmUgYWxpZ25tZW50Lg0KDQoNCjxl
cmljPiBJIHRoaW5rIGFsbCBmaXZlIHN1Z2dlc3Rpb25zIGFib3ZlIGFyZSBnb29kIHR3ZWFrcy4N
Cg0KRXJpYw0KDQoNClRoYW5rcywNClJvYg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l
dyIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u
b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFu
LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl
ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg
UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpz
cGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHls
ZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl
IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g
MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot
LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4
dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl
eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+
DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYz
QzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+SGkgUm9iZXJ0
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+VGhhbmtz
IGZvciB0aGUgY29tbWVudHMuJm5ic3A7IEluLWxpbmUgd2l0aCAmbHQ7RXJpYyZndDsuLi4uPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz
b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9z
cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IFJvYmVydCBXaWx0b24s
IFNlcHRlbWJlciAxMCwgMjAxOCA2OjE5IEFNPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFsZXgsIGF1dGhv
cnMsPGJyPg0KPGJyPg0KSGVyZSBhcmUgbXkgcmVtYWluaW5nIGNvbW1lbnRzIGZyb20gbXkgV0cg
TEMgcmV2aWV3IG9mIHRoZSBZQU5HIHB1c2ggZHJhZnQuJm5ic3A7IEFnYWluLCBJIHRoaW5rIHRo
YXQgdGhlc2UgYXJlIGFsbCBtaW5vci48YnI+DQo8YnI+DQoxLiBTZWMgNC4zLjIsIHBhcmFncmFw
aCAyLiZuYnNwOyAmcXVvdDtyZXN1bHRlZCBpbiBhIHBhcnRpY3VsYXIgcHVzaCZxdW90OyA9Jmd0
OyAmcXVvdDtyZXN1bHRlZCBpbiBhIHBhcnRpY3VsYXIgdXBkYXRlIHJlY29yZCZxdW90Oz88c3Bh
biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbHQ7RXJpYyZndDsgQWdyZWUsIHdlIHNob3VsZCBtYWtlIHRo
aXMgdHdlYWsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy
Pg0KPGJyPg0KMi4gU2VjIDQuNC4xLCBhZnRlciBGaWd1cmUgNywgJnF1b3Q7TUFZIHJlc3BvbmQm
cXVvdDsgPSZndDsgJnF1b3Q7bWF5IHJlc3BvbmQmcXVvdDsuJm5ic3A7IFRoaXMgaXMganVzdCBh
biBleGFtcGxlIGZyb20gdGhhdCBub3JtYXRpdmUgYmVoYXZpb3VyLjxzcGFuIHN0eWxlPSJjb2xv
cjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv
d3RleHQiPiZsdDtFcmljJmd0OyBBZ3JlZSwgd2Ugc2hvdWxkIG1ha2UgdGhpcyB0d2Vhay48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQozLiBT
ZWMgNC40LjEsIHBhcmFncmFwaCBzdGFydGluZyAmcXVvdDtJZiBhIHJlcXVlc3QgaXMgcmVqZWN0
ZWQgLi4uJnF1b3Q7LiZuYnNwOyBJcyBpdCByZWFsbHkgcmlnaHQgZm9yIHRoaXMgdG8gYmUgJnF1
b3Q7U0hPVUxEJnF1b3Q7IHJhdGhlciB0aGFuICZxdW90O01BWSZxdW90Oz8mbmJzcDsgRWFybHkg
dGV4dCAoZS5nLiAzLjIuIHBhcmFncmFwaCAyIHVzZXMgJnF1b3Q7bWF5IGJlIGluc2VydGVkJnF1
b3Q7LiZuYnNwOyBBbHNvIGluIHNlY3Rpb24gNC40LjIsIHBhcmFncmFwaCBhZnRlciBGaWd1cmUg
MTEuPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jmx0O0VyaWMmZ3Q7IEkgcHJlZmVyIFNIT1VMRC4m
bmJzcDsgU2VjdGlvbiAzLjIgdGV4dCBoYWQg4oCcbWF54oCdIGluc3RlYWQgb2Yg4oCcTUFZ4oCd
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N
CjQuIFNlYyA0LjQuMSwgJnF1b3Q7PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5P
cHRpb25hbGx5LCBhbiAmcXVvdDtlcnJvci1zZXZlcml0eSZxdW90OyBvZiAmcXVvdDtlcnJvciZx
dW90OyAodGhpcyBNQVkgYnV0IGRvZXMgbm90IGhhdmUgdG8gYmUgaW5jbHVkZWQpLiZxdW90OywN
Cjwvc3Bhbj48L3R0PkkgZG9uJ3QgdGhpbmsgdGhhdCB0aGUgbGFzdCBjbGF1c2UgaXMgcmVxdWly
ZWQgKGdpdmVuIHRoYXQgaXQgaXMgcHJlZGljYXRlZCBieSBPcHRpb25hbGx5LCBzbyBzdWdnZXN0
IGRlbGV0aW5nIHRoZSBjbGF1c2UgaW4gcGFyZW50aGVzaXMuJm5ic3A7IE90aGVyd2lzZSBpdCBp
cyBhbHNvIGluY29uc2lzdGVudCB3aXRoIHRoZSBmb2xsb3dpbmcgJnF1b3Q7ZXJyb3ItaW5mbyZx
dW90OyBkZXNjcmlwdGlvbi4mbmJzcDsgSWYgdGhpcyBjaGFuZ2UsIGl0IHNob3VsZA0KIGFsc28g
YmUgY2hhbmdlZCBmb3IgJnF1b3Q7ZXJyb3Itc2V2ZXJpdHkmcXVvdDsgaW4gU2VjIDQuNC4yLjxz
cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOndpbmRvd3RleHQiPiZsdDtFcmljJmd0OyBBZ3JlZSwgd2Ugc2hvdWxkIG1ha2Ug
dGhpcyB0d2Vhay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
YnI+DQo8YnI+DQo1LiBTZWMgNC40LjEsIE5FVENPTkYgc3BlY2lmaWMgdGV4dCBhYm91dCBlcnJv
cnMuJm5ic3A7IFNob3VsZCB0aGF0IHRleHQgcmVhbGx5IGJlIGluIHRoaXMgZHJhZnQ/Jm5ic3A7
IFdvdWxkIGl0IG5vdCBiZSBuaWNlciB0byBrZWVwIGFsbCBvZiB0aGUgTkVUQ09ORiBzcGVjaWZp
Y3MgdG8gYSBORVRDT05GIHByb3RvY29sIGRyYWZ0PyZuYnNwOyBQZXJoYXBzIHRoaXMgaXMgbm90
IHByYWN0aWNhbCwgYnV0IHRoZSBXRyBpcyBjdXJyZW50bHkgZXhwZXJpZW5jaW5nIHNvbWUgcGFp
bg0KIHdoZXJlIE5FVENPTkYgcHJvdG9jb2wgc3BlY2lmaWMgbm9ybWF0aXZlIHRleHQgaXMgaW4g
UkZDIDc5NTAuJm5ic3A7IEhlbmNlLCBpdCB3b3VsZCBiZSBuaWNlIHRvIGF2b2lkIGludHJvZHVj
aW5nIHRoYXQgaXNzdWUgaGVyZSBpZiBwb3NzaWJsZS4mbmJzcDsgVGhpcyBzYW1lIGNvbW1lbnQg
YWxzbyBhcHBsaWVzIHRvIFNlYyA0LjQuMi48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbHQ7RXJp
YyZndDsgQXMgdGhpcyBpcyBhIG5vbi1ub3JtYXRpdmUgZXhhbXBsZSwgd2Ugc2hvdWxkIG5vdCBo
aXQgdGhlIHNhbWUgaXNzdWUuJm5ic3A7IEkgZG8gbGlrZSBleGFtcGxlcyBmb3IgcmVhZGVycyB0
byBkaWdlc3QuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
YnI+DQo8YnI+DQo2LiBTZWMgNC40LjIsIGRlc2NyaXB0aW9uIHBhcmFncmFwaC4mbmJzcDsgU3Vn
Z2VzdCB0aGUgZm9sbG93aW5nIGNoYW5nZSB0byBtYXRjaCB0aGUgYWN0dWFsIGV4YW1wbGU6ICZx
dW90Ozx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+bW9kaWZ5IHRoZSAmcXVvdDtw
ZXJpb2QmcXVvdDsgb2YgYSBzdWJzY3JpcHRpb24uPC9zcGFuPjwvdHQ+JnF1b3Q7ID0mZ3Q7ICZx
dW90Ozx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+bW9kaWZ5IHRoZSAmcXVvdDtw
ZXJpb2QmcXVvdDsgYW5kICZxdW90O2RhdGFzdG9yZQ0KIFhQYXRoIGZpbHRlciZxdW90OyBvZiBh
IHN1YnNjcmlwdGlvbi48L3NwYW4+PC90dD4mcXVvdDs8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93
dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4m
bHQ7RXJpYyZndDsgQWdyZWUsIHdlIHNob3VsZCBtYWtlIHRoaXMgdHdlYWsuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KNy4gU2VjIDQuNC4y
LCBmaXJzdCBwYXJhZ3JhcGggYWZ0ZXIgZmlndXJlIDExOiZuYnNwOyBQb3NzaWJsZSByZXdvcmRp
bmc6PGJyPg0KPGJyPg0KT2xkOjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls
ZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0
O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4wcHQgOC4wcHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJl
YWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IFRoZSBwdWJsaXNoZXIgTVVTVCByZXNwb25kIGV4cGxp
Y2l0bHkgcG9zaXRpdmVseSBvciBuZWdhdGl2ZWx5IHRvIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7
d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsgJm5ic3A7cmVxdWVzdC4mbmJzcDsgSWYgdGhlIHN1
YnNjcmlwdGlvbiBtb2RpZmljYXRpb24gaXMgcmVqZWN0ZWQsIHRoZTxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZE
RjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgc3Vic2NyaXB0aW9uIGlzIG1haW50
YWluZWQgYXMgaXQgd2FzIGJlZm9yZSB0aGUgbW9kaWZpY2F0aW9uIHJlcXVlc3QuPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91
bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBJbiBhZGRpdGlvbiwg
dGhlIHB1Ymxpc2hlciBNVVNUIHNlbmQgYW4gUlBDIGVycm9yIHJlc3BvbnNlLiZuYnNwOyBUaGlz
IFJQQzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3
LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7
cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsg
ZXJyb3IgcmVzcG9uc2UgU0hPVUxEIGNvbnRhaW4gaGludHMgZW5jYXBzdWxhdGVkIHdpdGhpbiB0
aGUgeWFuZy1kYXRhPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3Jk
ZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNw
OyZuYnNwOyBzdHJ1Y3R1cmUgJnF1b3Q7bW9kaWZ5LXN1YnNjcmlwdGlvbi1lcnJvci1kYXRhc3Rv
cmUmcXVvdDsuJm5ic3A7IEEgc3Vic2NyaXB0aW9uIE1BWTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29y
ZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgYmUgbW9kaWZpZWQgbXVsdGlwbGUgdGltZXMu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
cj4NCk5FVzo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9Im1zby1lbGVt
ZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjgu
MHB0IDguMHB0IDguMHB0IDguMHB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs
bDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi
PiZuYnNwOyZuYnNwOyBUaGUgcHVibGlzaGVyIE1VU1QgcmVzcG9uZCB0byB0aGUgc3Vic2NyaXB0
aW9uIG1vZGlmaWNhdGlvbiByZXF1ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz
dHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpi
cmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0Ij4mbmJzcDsmbmJzcDsgSWYgdGhlIHJlcXVlc3QgaXMgcmVqZWN0ZWQsIHRoZSBleGlz
dGluZyBzdWJzY3JpcHRpb24gaXMgbGVmdCB1bmNoYW5nZWQsIGFuZDxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZE
RjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgdGhlIHB1Ymxpc2hlciBNVVNUIHNl
bmQgYW4gUlBDIGVycm9yIHJlc3BvbnNlLCB3aGljaCBNQVl8U0hPVUxEIGNvbnRhaW48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dy
b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGlu
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IGhpbnRzIGVuY2Fw
c3VsYXRlZCB3aXRoaW4gdGhlIHlhbmctZGF0YSBzdHJ1Y3R1cmU8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1
O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7ICZxdW90O21vZGlmeS1zdWJzY3JpcHRp
b24tZXJyb3ItZGF0YXN0b3JlJnF1b3Q7LiZuYnNwOyBBIHN1YnNjcmlwdGlvbiBNQVkgYmUgbW9k
aWZpZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206
Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25l
O3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7
IG11bHRpcGxlIHRpbWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOndpbmRvd3RleHQiPiZsdDtFcmljJmd0OyBQcm9wb3NlZCB0ZXh0IGxvb2tzIGZpbmUsIHdp
dGggYSBzbWFsbCB0d2Vhazo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp
bmRvd3RleHQiPlRoZSBwdWJsaXNoZXIgTVVTVCByZXNwb25kIHRvIHRoZSBzdWJzY3JpcHRpb24g
bW9kaWZpY2F0aW9uIHJlcXVlc3QuICZuYnNwO0lmIHRoZSByZXF1ZXN0IGlzIHJlamVjdGVkLCB0
aGUgZXhpc3Rpbmcgc3Vic2NyaXB0aW9uIGlzIGxlZnQgdW5jaGFuZ2VkLCBhbmQgdGhlIHB1Ymxp
c2hlcg0KIE1VU1Qgc2VuZCBhbiBSUEMgZXJyb3IgcmVzcG9uc2UuJm5ic3A7IFRoaXMgcmVzcG9u
c2UgbWlnaHQgaGF2ZSBoaW50cyBlbmNhcHN1bGF0ZWQgd2l0aGluIHRoZSB5YW5nLWRhdGEgc3Ry
dWN0dXJlICZxdW90O21vZGlmeS1zdWJzY3JpcHRpb24tZXJyb3ItZGF0YXN0b3JlJnF1b3Q7LiZu
YnNwOyBBIHN1YnNjcmlwdGlvbiBNQVkgYmUgbW9kaWZpZWQgbXVsdGlwbGUgdGltZXMuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxicj4NCjguIFNlYyA0LjQuNCwgbm8gZmlndXJlIG51bWJlciB1bmRlciB0aGUg
ZXhhbXBsZS48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl
eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbHQ7RXJpYyZndDsgQWdyZWUuJm5ic3A7
IEFsZXgsIGNhbiB5b3UgdHdlYWsgdGhlIFhNTD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo5LiBTZWMgNC40LjUsIHBhcmFncmFwaCAxOjxi
cj4NCkkgdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgdGhpcyBqdXN0IHJlZmVycmVk
IHRvIFlBTkcgbGlicmFyeSwgaGVuY2Ugc3VnZ2VzdCBjaGFuZ2luZyB0aGUgZmlyc3QgdHdvIHBh
cmFncmFwaHM6PGJyPg0KPGJyPg0KT0xEOjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp
diBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4wcHQgOC4wcHQ7YmFja2dyb3VuZDojRkZGREY1
Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dv
cmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IFRvIG1ha2Ugc3Vic2NyaXB0aW9uIHJlcXVl
c3RzLCB0aGUgc3Vic2NyaWJlciBuZWVkcyB0byBrbm93IHRoZSBZQU5HPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG
RkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBtb2R1bGUgbGlicmFyeSBhdmFp
bGFibGUgb24gdGhlIHB1Ymxpc2hlci4mbmJzcDsgVGhlIFlBTkcgMSBtb2R1bGUgbGlicmFyeTxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDti
YWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGlu
ZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgaW5mb3Jt
YXRpb24gaXMgc2VudCBieSBhIE5FVENPTkYgc2VydmVyIGluIHRoZSBORVRDT05GICZxdW90O2hl
bGxvJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6
bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZu
YnNwOyBtZXNzYWdlLiZuYnNwOyBGb3IgWUFORyAxLjEgbW9kdWxlcyBhbmQgYWxsIG1vZHVsZXMg
dXNlZCB3aXRoIHRoZSBSRVNUQ09ORjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVh
ay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0Ij4mbmJzcDsmbmJzcDsgW1JGQzgwNDBdIHByb3RvY29sLCB0aGlzIGluZm9ybWF0aW9uIGlz
IHByb3ZpZGVkIGJ5IHRoZSBZQU5HIExpYnJhcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJl
YWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IG1vZHVsZSAoaWV0Zi15YW5nLWxpYnJhcnkueWFuZyBm
cm9tIFtSRkM3ODk1XS4mbmJzcDsgVGhpcyBZQU5HIGxpYnJhcnk8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1
O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIGlzIGltcG9ydGFu
dCBmb3IgdGhlIHJlY2VpdmVyIHRvIHJlcHJvZHVjZSB0aGUgc2V0IG9mPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG
RkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBvYmplY3QgZGVmaW5pdGlvbnMg
dXNlZCB3aXRoaW4gdGhlIHB1Ymxpc2hlci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg
c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6
YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDti
b3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZu
YnNwOyZuYnNwOyBUaGUgWUFORyBsaWJyYXJ5IGluY2x1ZGVzIGEgbW9kdWxlIGxpc3Qgd2l0aCB0
aGUgbmFtZSwgcmV2aXNpb24sPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs
bDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi
PiZuYnNwOyZuYnNwOyBlbmFibGVkIGZlYXR1cmVzLCBhbmQgYXBwbGllZCBkZXZpYXRpb25zIGZv
ciBlYWNoIFlBTkcgbW9kdWxlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs
bDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi
PiZuYnNwOyZuYnNwOyBpbXBsZW1lbnRlZCBieSB0aGUgcHVibGlzaGVyLiZuYnNwOyBUaGUgcmVj
ZWl2ZXIgaXMgZXhwZWN0ZWQgdG8ga25vdyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJl
YWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IFlBTkcgbGlicmFyeSBpbmZvcm1hdGlvbiBiZWZvcmUg
c3RhcnRpbmcgYSBzdWJzY3JpcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk5FVzo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv
cD4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0O2JhY2tncm91bmQ6
I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG
RkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBUbyBtYWtlIHN1YnNjcmlwdGlv
biByZXF1ZXN0cywgdGhlIHN1YnNjcmliZXIgbmVlZHMgdG8ga25vdyB0aGUgWUFORzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3Jv
dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgZGF0YXN0b3JlIHNj
aGVtYXMgdXNlZCBieSB0aGUgcHVibGlzaGVyLCB3aGljaCBhcmUgYXZhaWxhYmxlIHZpYSB0aGUg
WUFORzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3
LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7
cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsg
TGlicmFyeSBtb2R1bGUsIGlldGYteWFuZy1saWJyYXJ5LnlhbmcgZnJvbSBbUkZDNzg5NV0uJm5i
c3A7IFRoZSByZWNlaXZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy
Z2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7
Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4m
bmJzcDsmbmJzcDsgaXMgZXhwZWN0ZWQgdG8ga25vdyB0aGUgWUFORyBsaWJyYXJ5IGluZm9ybWF0
aW9uIGJlZm9yZSBzdGFydGluZyBhPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr
LWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQiPiZuYnNwOyZuYnNwOyBzdWJzY3JpcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0
ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jmx0O0VyaWMmZ3Q7IEFncmVlLCB3ZSBz
aG91bGQgbWFrZSB0aGlzIHR3ZWFrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpZQU5HIG1vZHVsZTo8YnI+
DQo8YnI+DQoxMC4gVG9wIGxldmVsIGRlc2NyaXB0aW9uIHN0YXRlbWVudCwgaXQgbG9va3MgbGlr
ZSB0aGUgY29weXJpZ2h0IGhhcyBhY2NpZGVudGFsbHkgYmVlbiBpbmRlbnRlZCBieSA0IGNoYXJz
LjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiZsdDtFcmljJmd0OyBBZ3JlZSwgd2Ugc2hvdWxkIG1h
a2UgdGhpcyB0d2Vhay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48YnI+DQo8YnI+DQpJZGVudGl0aWVzOjxicj4NCjExLiBJIHN1Z2dlc3QgcmVuYW1pbmcgJnF1
b3Q7bm8tc3VjaC1zdWJzY3JpcHRpb24tcmVzeW5jaCZxdW90OyB0byBqdXN0ICZxdW90O25vLXN1
Y2gtc3Vic2NyaXB0aW9uJnF1b3Q7LiZuYnNwOyBJIHdvdWxkIGhhdmUgdGhvdWdodCB0aGF0IHRo
aXMgZXJyb3IgY291bGQgYWxzbyBiZSByZXR1cm5lZCB0byBjYW5jZWwgYW4gdW5rbm93biBzdWJz
Y3JpcHRpb24uPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0
ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jmx0O2VyaWMmZ3Q7IFRoZSByZWFzb24g
d2UgbmVlZCAmcXVvdDtuby1zdWNoLXN1YnNjcmlwdGlvbi1yZXN5bmNoJnF1b3Q7IGlzIHRoYXQN
Cjwvc3Bhbj4mcXVvdDtuby1zdWNoLXN1YnNjcmlwdGlvbiZxdW90OyBpcyBhbHJlYWR5IHVzZWQg
aW4gU04uJm5ic3A7IChJLmUuLCBpcyBub3QgcG9zc2libGUgdG8gYXVnbWVudCB0aGUgZXhpc3Rp
bmcgaWRlbnRpdHkgd2l0aCBhIG5ldyBiYXNlLik8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93
dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K
PGJyPg0KMTIuICZxdW90O3N5bmNocm9uaXphdGlvbi1zaXplJnF1b3Q7IGRvZXNuJ3Qgc291bmQg
bGlrZSBhbiBlcnJvciwgcGVyaGFwcyAmcXVvdDtzeW5jaHJvbml6YXRpb24tdG9vLWJpZyZxdW90
OyBvciAmcXVvdDtyZXN5bmMtdG9vLWJpZyZxdW90OyBtaWdodCBiZSBiZXR0ZXI/PHNwYW4gc3R5
bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6d2luZG93dGV4dCI+Jmx0O2VyaWMmZ3Q7IEkgaGF2ZSBubyBwcm9ibGVtIHdpdGggY2hhbmdp
bmcgaXQgdG8gJnF1b3Q7c3luY2hyb25pemF0aW9uLXRvby1iaWcmcXVvdDssIHRoYXQgYWxpZ25z
IHRvIHRoZSBvdGhlciBpZGVudGl0eSAmcXVvdDt1cGRhdGUtdG9vLWJpZyZxdW90OzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NClR5cGUgZGVm
aW5pdGlvbnM6PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjEzLiZuYnNwOyBDaGFuZ2UgYWxsIGlu
c3RhbmNlcyAoY3JlYXRlLCBkZWxldGUsIGluc2VydCwgbW92ZSwgcmVwbGFjZSkmbmJzcDsgb2Yg
JnF1b3Q7ZGF0YSBub2RlJnF1b3Q7IHRvICZxdW90O2RhdGFzdG9yZSBub2RlJnF1b3Q7Lg0KPGJy
Pg0KPGJyPg0KMTQuIGdyb3VwaW5nIHNlbGVjdGlvbi1maWx0ZXItdHlwZXMsIGFueWRhdGEgZGF0
YXN0b3JlLXN1YnRyZWUtZmlsdGVyLCBwZXJoYXBzIGFkZCBhIHJlZmVyZW5jZSB0byAmcXVvdDtS
RkMgNjI0MTogTmV0d29yayBDb25maWd1cmF0aW9uIFByb3RvY29sLCBTZWN0aW9uIDYuJnF1b3Q7
LCBtaXJyb3JpbmcgZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEtbmV0Y29uZi48YnI+DQo8YnI+DQox
NS4gZ3JvdXBpbmcgdXBkYXRlLXBvbGljeS1tb2RpZmlhYmxlLCBjb250YWluZXIgb24tY2hhbmdl
IGRlc2NyaXB0aW9uIHN0YXRlbWVudCwgbmVlZHMgdG8gYmUgaW5kZW50ZWQgYnkgMiBzcGFjZXMu
PGJyPg0KPGJyPg0KMTYuIGdyb3VwaW5nIGhpbnRzLCBkZXNjcmlwdGlvbiwgaW5kZW50IHRoZSBz
ZWNvbmQgZGVzY3JpcHRpb24gbGluZSBieSAxIHNwYWNlLjxicj4NCjxicj4NCjE3LiBycGMgcmVz
eW5jaC1zdWJzY3JpcHRpb24sIGRlc2NyaXB0aW9uIHN0YXRlbWVudCwgbGFzdCB0d28gbGluZXMg
cmVxdWlyZSBhbGlnbm1lbnQuPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OndpbmRvd3RleHQiPiZsdDtlcmljJmd0OyBJIHRoaW5rIGFsbCBmaXZlIHN1Z2dlc3Rpb25zIGFi
b3ZlIGFyZSBnb29kIHR3ZWFrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OndpbmRvd3RleHQiPkVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KUm9iPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_9743f8e24d6f448687517c83d07db025XCHRTP013ciscocom_--


From nobody Mon Sep 10 10:41:57 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5D0130F0F for ; Mon, 10 Sep 2018 10:41:56 -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 IMP91T-K83fB for ; Mon, 10 Sep 2018 10:41:53 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE39130EEC for ; Mon, 10 Sep 2018 10:41:53 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 924121AE018A for ; Mon, 10 Sep 2018 19:41:52 +0200 (CEST)
Date: Mon, 10 Sep 2018 19:41:52 +0200 (CEST)
Message-Id: <20180910.194152.138356385922962289.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Sep 2018 17:41:56 -0000

Hi,

I have reviewed this document, and I think it is almost ready.  Here
are my comments:


o  Section 1.4

  s/RFC-5277/RFC 5277/


o  Section 2.1

  The text says:

    It is out of the scope of this document
    to identify [...] b) how event records are defined

  Is this really what we want?  Shouldn't this document specify that
  an event record is an instance of a YANG "notification" statement?
  Do we want to support event records that are not defined in YANG?

  This was discussed in the thread "comments on
  draft-ietf-netconf-subscribed-notifications-12", and it seems that
  noone really have any use case for non-YANG-defined event records,
  accessed with YANG-defined operations.

  I think that this document should state that an event record is an
  instance of a YANG "notification" statement.  If not, it is unclear
  both how subtree/xpath filters and xml/json/... encodings would work.


o  Section 2.1

  The text says:

    Among
    these included NETCONF XML event records are individual YANG 1.1
    notifications described in section 7.16 of [RFC7950].

  First of all, does this mean that there can be event records on the
  "NETCONF" stream that are *not* defined with a "notification"
  statement?

  Second, this seems to imply that *all* notifications defined in all
  YANG modules end up in the "NETCONF" stream, but I don't think this
  is the intention.  At least I hope so.  ("yp:push-update" is an
  example of a notification that will not be sent on the "NETCONF"
  stream.)

  Further, the text says:

    Each of these
    YANG 1.1 notifications will be treated as a distinct event record.

  This seems to confuse the schema definition with specific instances;
  it is not the schema definition that is treated as a disctinct event
  record, but the notification instances.

  So, I suggest that these two sentences are removed.


o  Section 2.4.1

  OLD:

   o  A delete or kill RPC will end the subscription, as will the
      reaching of a "stop-time".

  NEW:

   o  A "delete-subscription" or "kill-subscription" RPC will end the
      subscription, as will the reaching of a "stop-time".

o  Section 2.4.1

  OLD:

      Successful
      modification returns the subscription to an active state.

  NEW:

      Successful
      modification returns the subscription to the active state.


o  Section 2.4.2

  The text says:

    The transport selected by the subscriber
    to reach the publisher MUST be able to support multiple "establish-
    subscription" requests made within the same transport session.

  This seems to indicate that RESTCONF cannot be used with this
  specification, since RESTCONF doesn't have sessions.

  This makes me wonder, why does this document specify this
  requirement?  I agree that this is the behaviour we want from
  NETCONF, but then I think that should be defined in the
  netconf-notif draft.


o  Section 2.4.2

  s/"start-time"/"replay-start-time"/  (3 occurrences)

  Also, the text says that the replay-start-time MUST be in the past.

  Suppose the server receives a "replay-start-time" of 12:00:00.001,
  and the replay buffer is empty.

  A) If the current time is 12:00:00.002, the request is accepted, and
     a "replay-completed" notif is sent.

  B) If the current time is 12:00:00.000, the request is rejected with
     an error.

  Why is this important?  Why not simply just send the
  replay-completed notif in both cases?


o  Section 2.4.2.1

  OLD:

   If the time the replay starts is later than the time marked within
   any event records retained within the replay buffer, then the
   publisher MUST send a "replay-completed" notification immediately
   after a successful establish-subscription RPC response.

  NEW:

   If the given "replay-start-time" is later than the time marked within
   any event records retained within the replay buffer, then the
   publisher MUST send a "replay-completed" notification immediately
   after a successful establish-subscription RPC response.


o  Section 2.4.2.1

  There is no text that explains what happens in the "succesful" case;
  i.e., when there are buffered event records with time greater than
  or equal to the requested "replay-start-time".

  Maybe the first paragraph is supposed to cover this, but it just
  says "meets the timeframe criteria", which is a bit vague.


o  Section 2.4.5

  OLD:

    A publisher MUST terminate any dynamic
    subscription identified by RPC request.


  NEW:

    A publisher MUST terminate the dynamic
    subscription identified by the "identifier" parameter in the RPC
    request, if such a subscription exists.


o  Section 2.4.6

  The text says:

    1.  "establish-subscription-stream-error-info": This MUST be returned
        if an RPC error reason has not been placed elsewhere within the
        transport portion of a failed "establish-subscription" RPC
        response.

  (and similar for the other errors)

  What exactly does "if an RPC error reason has not been placed
  elsewhere" mean?


o  Section 2.5.1

  In the second diagram (for the valid state), the states are called
  "receiver connecting", "reciever timeout" etc.  I find this a bit
  confusing; it is not the *receiver* that is connecting, it is the
  publisher.  Ok, the legend then says:

     dashed boxes which include the word 'receiver' show the possible
     states for an individual receiver

 But since all dashed boxes include the word "receiver", and the
 diagram specifically is the state machine *per receiver*, maybe we
 can simply remove the word "receiver" from the boxes?


o  Section 2.5.2

  s/details."/details./


o  Section 2.5.6

  I know that this feature was presented in Montreal.  I think it is
  problematic, and suggest it is removed.

  For example, what happens if the transport session is lost and
  re-established; are all event records in the buffer replayed again?

  What happens if a new receiver is added to a subscription that
  already has a receiver, will all events in the buffer be replayed to
  the new receiver?

  When a new subscription is configured with configured-replay set,
  the publisher will immediately try to connect to the publisher and
  send all buffered event from the last reboot.  Is this really
  useful?


  If the mechansim relies on the subscriber being able to also use
  dynamic subscriptions for replay of all event records, maybe we
  could simplify things by always relying on dynamic subscriptions for
  replay for configured subscriptions.  Specifically, remove
  "configured-replay" etc, but keep the "replay-previous-event-time"
  in the "subscription-started" notification.  Then a subscriber can
  simply check this value to see if anything is missing, and if it is,
  use a dynamic subscription to request replay from the latest time he
  knows about.


o  Section 2.6

  It just occurred to me that this text about using the 
  message shouldn't be in this document, but in the netconf-notif (and
  restconf-notif) document.  It is highly transport and encoding
  specific.


o  Section 2.7

  This section talks about "subscription state" notifications.  But in
  many places in the document, you use the term "state change"
  notification.  I suggest pick one term and use it consistently, to
  avoid confusion.


o  Section 2.8

  s/operational datastore/operational state datastore/

 (four occurrences)


o  Section 4

          action reset {
            if-feature "configured";
            description
              "Allows the reset of this configured subscription receiver

  This action will be available also for dynamic subscription, if the
  server supports the "configured" feature.  Maybe add:

    when "../../../configured-subscription-state";


o  Section 4

  Should the rpc kill-subscription be marked with
  nacm:default-deny-all?  Otherwise, by default, anyone can terminate
  any other's subscriptions.


o  Section 4

  I suggest that the leaf /filters/stream-filter/identifier is renamed
  to "name", for consistency, and that it is of type "string", and
  that the type "filter-id" is removed, for consistency and
  simplicity.

  Also, I suggest that the leaf /subscriptions/subscription/target/
  stream-filter/by-reference/stream-filter-ref is renamed to
  "stream-filter", or maybe "stream-filter-name".


o  Section 4

  I suggest that the subscription's key leaf "identifier" is
  renamed to simply "id".  This would match the name of the type which
  is "subscription-id".

  (it is also consistent with other (not all) IETF models, where a
  "name" is used for an arbitrary string key, and "id" for a more
  strict key, often some integer type)

  NOTE: yang push should also be changed to use the same naming
  convention


o  Section 4

  I suggest the counters "count-sent" and "count-exlcuded" are renamed
  to something more descriptive, perhaps "out-event-records" or
  "sent-event-records", and "excluded-event-records" or
  "dropped-event-records", respectively.


o  Section 4

  I suggest you consistently format the YANG module wrt. spaces etc.
  Also, some lines are longer than 69 characters and should be
  adjusted.

  You can use pyang --ietf --max-line-length 69 to help with the
  latter, and pyang -f yang --keep-comments to help with the former.
  (note that you may need to manually fix the output of pyang -f,
  e.g. if some lines are too long)


  (The RFC editor checks this, so it is better to do it now)


o  Section 4

  OLD:

    "This feature indicates support for xpath filtering.";

  NEW:

    "This feature indicates support for XPath filtering.";


o  Section 4

  With the inclusion of "replay-start-time-revision", shouldn't the
  identity "history-unavailable" be removed?


o  Section 4

  identity no-such-subscription {
    base modify-subscription-error;
    base delete-subscription-error;
    base subscription-terminated-reason;
    description
     "Referenced subscription doesn't exist. This may be as a result of
      a non-existent subscription ID, an ID which belongs to another
      subscriber, or an ID for configured subscription.";
  }

  s/ID/id/


o  Section 5.4

   s/publisher"/publisher/


o  Appendix A

  Since this appendix defines an example module, it needs to be named
  accordingly.  Specifically, the module should be called
  "example-foo-subscribed-notifications", and the namespace should be
  "urn:example:foo-subscribed-notifications".

  (with this change, you can also remove the note to the RFC editor)


o  Appendix A

  The name of Figure 21 should be changed:

  OLD:

           Figure 21: Example Transport Augmentation for NETCONF

  NEW:
           Figure 21: Example Transport Augmentation for the
           fictitious protocol foo



/martin


From nobody Mon Sep 10 13:17:31 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28E4130F6F for ; Mon, 10 Sep 2018 13:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham 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 olH6ayTZpUZ3 for ; Mon, 10 Sep 2018 13:17:26 -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 23A8D130F30 for ; Mon, 10 Sep 2018 13:17:26 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8AKEBbn001871; Mon, 10 Sep 2018 13:17:24 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=0n5syBqjfxc9KLA2rF102qoN7xcVkB2WwM04MO0j7eI=; b=XUkb88qwjqx3ttW4N4Qo53Mix+DKpvNvhidtbzILm9cus4EzHCSBbR+t/sAsw7TVZj4J LM0Shk87iGlX65yZuPmlbpVhxL80PickaXJPCD2zAJ96JO6AXI7RLzQ3xnl8LFZRKTFt USSUxElJXzIsNhFzNYarK/qdmXRZoo1v8sxfwMSZgfl2o0htGL264EPeTBGIQ4rzu5bL FXx+ooGeu8Op8d7x996aQGXYI7eS6OIRkrtl41Zx5TZ8lvsbCgTRgTdwapk9i+YAUmc8 KJt5PiMe5kDF+bWAfyq69gaRYIojIy2WD1KE5Eyp0ARmKqJk5T7jcVVTkPy0KCVMezZ/ PQ== 
Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp0049.outbound.protection.outlook.com [216.32.181.49]) by mx0b-00273201.pphosted.com with ESMTP id 2mdt6r0rc5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 10 Sep 2018 13:17:24 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4203.namprd05.prod.outlook.com (20.176.72.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.8; Mon, 10 Sep 2018 20:17:22 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1143.010; Mon, 10 Sep 2018 20:17:22 +0000
From: Kent Watsen 
To: Mahesh Jethanandani 
CC: Netconf 
Thread-Topic: Shepherd review of draft-ietf-netconf-zerotouch-22
Thread-Index: AQHUOY4aXc46vTDN+EiCRIcfB2nTiqTLuzkAgBJCAwCAC9MnAA==
Date: Mon, 10 Sep 2018 20:17:21 +0000
Message-ID: <7D8941E8-738B-44AC-BD0A-CEE45C5900AC@juniper.net>
References:  <32AB6932-94CE-4FF1-965F-F7D2E65AF96B@juniper.net> <83227CCC-ED4B-47A7-BA7F-180FE2AFB068@gmail.com>
In-Reply-To: <83227CCC-ED4B-47A7-BA7F-180FE2AFB068@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4203; 6:1E59d/Z//Do8h3E4Ew3l8FiTKP2TaFgqL0h6nmUvzk5PsumC8jVZNtt02bOrICw0VyML/1S0R4971WUNc6G69v/76LSxKvNRqZm3rWqJZNqr4kXjmZIsD1uReodiN+s+97F10rlYciuVCnjEPr3hgRW4c8w/mb+dOIyl98o+Mf6cN1xq1TD+O7I57suorZH73vXEcCu98W+5vr+XyvuDKXJwy+KUWz88UbaVA9595lw+EGq56XGNFiMCTxYbW96M7kCnhVtGnG0IX98x6K7MN8SlbS65qu1qPDvdZW/HCc96ItTeNa7IJoN4pVmm3t71s42piyPYaERiJL/1sG/MS9APlt9BbDDEcyuMAbh2Se3IasNnDuEIE6ygNsuealrv/02+tTLBWoJY05dotapMwZroO4EpoGvQxCQg/FBpfkz2bnjvhcTBbRU1jnv2ula/HvHYyHsowj1MlfaZ2fOAyg==; 5:Rjwn0KuNQrNWjxQ0mdaWR2ylM/v1wC1V3BqkqzWwAkd1oADwKlKSXxpjPp+ZO3Sr4NRJSYM3l68d+7Oy/cFhn7CzlJde4R5BlZhBSDSG8OwlWvCxKT1QBBqPeZ1IDEs8hhzydG+5tKmi/iOhe7S0fVSXh+qCq9XwVKEmo4POw4I=; 7:FcoW9i3BDS2eUKwnUTuQlAYg+mq9+IA/OnBLwn/ihPm5GK3pMX+Dd0JfSIUyrqWjkSrvepZspx90l7dXNwispKlDuDmwMo1UJjyJajXcIHsrDqayMUU8rZcywS5fhUfQDDCPLvE5hYbZp0N5GNMK5Z3Sltm6PUTmRlnE2E+rlp0ZbOp81XhwZX//cNGrnhnVOu2tdczxCaPyJeic8CVmjOrCeR9WGlK86c/UyuhPV6E9Tem6qAGLofr7vjQSBcfB
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: b6bdb521-766e-4201-8150-08d6175a6a7a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4203; 
x-ms-traffictypediagnostic: DM6PR05MB4203:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699050); SRVR:DM6PR05MB4203; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4203; 
x-forefront-prvs: 07915F544A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(346002)(376002)(39860400002)(396003)(51444003)(189003)(199004)(2906002)(81156014)(6506007)(6436002)(81166006)(97736004)(102836004)(1411001)(316002)(76176011)(33656002)(106356001)(66066001)(6486002)(58126008)(105586002)(478600001)(186003)(486006)(26005)(229853002)(5250100002)(2616005)(83716003)(11346002)(446003)(476003)(6246003)(53936002)(39060400002)(6116002)(86362001)(68736007)(3846002)(6512007)(2900100001)(4326008)(5660300001)(14454004)(99286004)(8676002)(305945005)(8936002)(36756003)(25786009)(6916009)(256004)(7736002)(82746002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4203; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: +VbmX8JyjnFCT+TbKcrrCjZuuab5L1H1Xg6nnlnkBBGb6A+fWH/AVjq/CkbRffdckUyKQ2ztHIapaeDmNKL+JlI3zAgKP7ksXObQpT7RjXBo4FUHX/pWW89I7KM+utYbAg3nXZcEOPxBNpPQc0v9HchW/1e9sTJjXowW2lxDZPrZYsR7AQVDQDNuQXTWiC4NetgdOrDskAf74TKIAOlFD5MYXm9R6aDIzYzOde89q5qpzyoy52oEBSmbsgryMf/Jdmoa2LYzRthiIbCCl0qZaGOys3xvzYSwaDuWPdL9WhvPu+LAmfv9jw9JuuUcaqzNXIidlefT16sYJHS5kcaap3rg2xRMrxdiisy5tFCebXs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <1F723920B0A69042A8A8DDE3C874EB24@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: b6bdb521-766e-4201-8150-08d6175a6a7a
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2018 20:17:21.8891 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4203
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-10_10:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809100200
Archived-At: 
Subject: Re: [Netconf] Shepherd review of draft-ietf-netconf-zerotouch-22
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Sep 2018 20:17:29 -0000

SGkgTWFoZXNoLA0KDQpDYXRjaGluZyB1cCBvbiBtYWlsIGZyb20gbGFzdCB3ZWVrLg0KDQoNCj4+
IFNlY3Rpb24gNi4zLiBZb3UgbmVlZCB0byBhZGQgcmVmZXJlbmNlcyB0byB0aGUgUkZDcyB0aGF0
IHlvdQ0KPj4gaW1wb3J0IG9yIHJlZmVyZW5jZSBpbiB0aGUgWUFORyBtb2RlbCwgZS5nLiBSRkMg
Njk5MS4NCj4+IA0KPj4gPEtXPiBJIHRoaW5rIHRoYXQgdGhpcyBpcyBhbHJlYWR5IHRoZSBjYXNl
LiAgUGxlYXNlIHNlZSB0aGUNCj4+IDJuZCBwYXJhZ3JhcGggaW4gU2VjdGlvbiA2LjMuICBJcyB0
aGVyZSBhIHBhcnRpY3VsYXIgaXNzdWU/DQo+DQo+IEluIFNlY3Rpb24gNy4zLCB5b3UgbWFrZSBh
IHJlZmVyZW5jZSB0byBSRkMgNjE4NyB3aXRoaW4gdGhlIA0KPiBZQU5HIG1vZHVsZSwgYnV0IHRo
ZSBzYW1lIGlzIG5vdCByZWZlcmVuY2VkIGluIHRoZSBiZWdpbm5pbmcNCj4gb2YgdGhlIHNlY3Rp
b24uDQoNCkFkZGVkIHRoZSBtaXNzaW5nIHJlZiBpbiBteSBsb2NhbCBjb3B5ICh3aGF0IHdpbGwg
YmVjb21lIC0yNSkNCkknbGwgd2FpdCBmb3IgbW9yZSB1cGRhdGVzIGJlZm9yZSBwb3N0aW5nIC0y
NS4uLg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0K


From nobody Mon Sep 10 13:41:36 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A80130FAB for ; Mon, 10 Sep 2018 13:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham 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 iuyTAu8_lsGs for ; Mon, 10 Sep 2018 13:41:22 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 20125130F94 for ; Mon, 10 Sep 2018 13:41:22 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8AKd4cu015543; Mon, 10 Sep 2018 13:41:21 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=ZzvDdiknHthJRcc1s9Pd2DzptZKPEgWydfTNkcYxSEw=; b=e95jUvbsyCq8JrIi7kxF0/qQ94h6yZSQqehn+WUwRjwMC3NI7zzLWlMVibd5nPLEn1Pq Pd97jshS+VDbmxT/dCbbrXRe2neRv1onsGJYWY5/FNta0e1OiMPATgS4fZeW6EWYicwz Mz13cUBUXmMNFqePCqfWeGYbS5jvaQLDHbm33IdQ8x0AV62XEqaK6V061U4BQTA092va sImuQhbhWChWaoMKacsvQ1OLSf76Qg+L2YYrTIVTqDgKcgYV1An0SI/FtSIvMvAYwMWO q53RLP3sZxWbgBtL4pbQPxxLTrgb5pfbEvZI2NIVAeJD3/sXthwe4OWx2Gn2HGDpenQr Ng== 
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0180.outbound.protection.outlook.com [216.32.180.180]) by mx0a-00273201.pphosted.com with ESMTP id 2mdx2ug6e6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 10 Sep 2018 13:41:21 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB5066.namprd05.prod.outlook.com (20.177.223.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.11; Mon, 10 Sep 2018 20:41:18 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1143.010; Mon, 10 Sep 2018 20:41:18 +0000
From: Kent Watsen 
To: Martin Bjorklund 
CC: "j.schoenwaelder@jacobs-university.de" , "netconf@ietf.org" 
Thread-Topic: [Netconf] netconf call home connection type
Thread-Index: AQHUOUk8IdLBwLq95EWszUO4eDF4yKTKZDSAgAESIICAA7pUAIAEHU8AgADmugCAAJdjAIAAUaEAgAB3VoCAAB6KgIAAqSQAgACmc4CAAOQtgIAAjK4AgAEzsICAAA+kAIAAiuMAgAQSqgCAC4K2gA==
Date: Mon, 10 Sep 2018 20:41:18 +0000
Message-ID: <8BAC2AAA-0E70-4EDA-B6A8-E4F94445D2F0@juniper.net>
References: <20180831.112941.578054615225468495.mbj@tail-f.com> <20180831102540.ileyzgsrades5m7g@anna.jacobs.jacobs-university.de>  <20180903.105436.927964486928721459.mbj@tail-f.com>
In-Reply-To: <20180903.105436.927964486928721459.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB5066; 6:+LMi+qRzNpNz4eRqMCo+PP49DgkA4DqBTFrdWurKr1WNIeJTnfzrdHO0uC4qA52zeVdLmSRDOTLeY2Wll/PMkigvJnpj3P4Fj3ete6g+MM14Bc9uLx2t1vg0iOXUj89u5r1SrjYtpkHs7/gudsv2r5MgzsZlX5G8yTwaBQe9piZoDC+zDlmrZeCvvluGqfvtxxDNyII54wAraYaEy/j9MHROJKqcUCHCxBYDjFBv2X/+BgV9ZZoQSx5JuDdpzkyRoGid+mdMnfsDyrkKSX7ESaS7zzeJxCDesjG9l7cq6B5i06FTBgIixGaMBrBBU3/mREHpmloREAvftdQ5Y18a019JyTQ6TqBzQDYp6oj/7UySvOaoOSMqkE0u7k3xnBQqBXLDbCQbnscP+vXCawhwa3R3kOjzEIWGGMEXWbgpD0p7WXvrnumrG5F5dBSpSo65+ZEumZhA1QLTK6oUv23pnw==; 5:z7azwvcYBV3tJPmtPC0q8KuYI/mricmEhh7G5d/0o2ERheapxKOlylkVfXYoKhU+3HA6aRsVJaST/M1oc/pjs+R1qkrhc1w9lPByx70JUvkU7bDUsWLI3inYJJY/qsEE1OVk8vMbGwAUmvQi19tUF3fw/+X3BJo0zciyrVduSdQ=; 7:SJahe52gDEI2OhtpS5GOqvw5mCEd/bu6TLTIaNqVSRZEZvqWP+v5wwMq6LquXev/Xnr7shV6SUsiazAKa+wywbwY3p+rggn/+hnkIr4us/iyGLl0zawqBB5p6929occITxu1LcJyT+S88bt+/poQXmBbwq23O3o7KdtH8+FbDlvOTnxU/g3HKnpbIPBSoXjBcXKwcOYCAbQkIys+z/yHBYalhYQMRiH2j1rScttumF5pTPpfsKLFtyJpPnjZoeYc
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 71cc08c6-f32a-423a-bc0f-08d6175dc2d6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB5066; 
x-ms-traffictypediagnostic: DM6PR05MB5066:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699050); SRVR:DM6PR05MB5066; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB5066; 
x-forefront-prvs: 07915F544A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(376002)(396003)(366004)(346002)(189003)(199004)(256004)(14444005)(26005)(6486002)(6436002)(54906003)(6916009)(229853002)(25786009)(6512007)(5660300001)(102836004)(86362001)(478600001)(4326008)(14454004)(8936002)(58126008)(53936002)(33656002)(6506007)(186003)(6246003)(2906002)(486006)(305945005)(11346002)(93886005)(36756003)(5250100002)(82746002)(6116002)(446003)(81166006)(2616005)(476003)(2900100001)(83716003)(81156014)(316002)(66066001)(8676002)(7736002)(99286004)(68736007)(105586002)(3846002)(106356001)(97736004)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5066; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 8QbFMACQodYAm+l5EQsDb62mNwMBh529QDquIjWeOVqclCCcYk95/8zsMYt+/riIRk+YrtUAIi6XpP97fBK7Ux24bI6xtOYS1KV+P01xTgX1UsEHG2WtF/K/kiDAK4gRcwt6SysaYstAXxIZeF5cCGZvVzUZbtPctkb9EaLIea5O/Tt6iwc0ZSxSpTS2ERZ1aOpBl31sPi1r+evaHL+VRuQS2/B4mII1Qz+UIuoygf2gYMClLbZWKfvREtR0oScYKsiwEPTIhsNZ0MdX0zX7Qh3DZb6OlOAqk82Ri0ANJzbW5kCKHGd7TlIgHFlIu4wPIXkV9UcToGOT2fqjZHbKcfc6HVj1tqWrj3/9e0/+ee8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 71cc08c6-f32a-423a-bc0f-08d6175dc2d6
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2018 20:41:18.6322 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5066
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-10_10:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809100203
Archived-At: 
Subject: Re: [Netconf] netconf call home connection type
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Sep 2018 20:41:34 -0000

SGkgTWFydGluLA0KDQpDYXRjaGluZyB1cCBvbiBtYWlsIGZyb20gbGFzdCB3ZWVrLg0KDQoNCj4+
IEFsc28sIGl0IHNlZW1zIHRoYXQsIGlmIHdlIHdhbnQgWVArU04gdG8gYmUgYWJsZSB0byB1c2Ug
Y2FsbC1ob21lIA0KPj4gZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucywgdGhlbiB3ZSBuZWVk
IHRvIHVwZGF0ZSB0aGUgU04gZHJhZnQNCj4+IHRvIEEpIGRlZmluZSB0aGUgImFjdGl2YXRlLWNv
bmZpZ3VyZWQtc3Vic2NyaXB0aW9uIiBSUEMNCj4NCj4gSSBzdGFydGVkIHRvIHdyaXRlIHRoYXQg
SSBkb24ndCB0aGluayB0aGlzIGJlbG9uZ3MgdG8gdGhlIFNOIGRyYWZ0LA0KPiBzaW5jZSBpdCBp
cyBORVRDT05GLXNwZWNpZmljLiAgQnV0IGFmdGVyIHRoaW5raW5nIHNvbWUgbW9yZSBhYm91dCBp
dCBJDQo+IHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRvIGRlZmluZSB0aGlzIG9wZXJhdGlvbiBpbiB0
aGUgU04gZHJhZnQuDQo+DQo+IEZvciBSRVNUQ09ORiAobm90IGEgbmV3IEhUVFAgcHJvdG9jb2wp
IHRoaXMgcnBjIGNvdWxkIGJlIHVzZWQNCj4gYnkgYXVnbWVudGluZyBhICdsb2NhdGlvbicgbGVh
ZiB0byBpdHMgb3V0cHV0Lg0KPg0KPiBJdCBpcyBwcm9iYWJseSB1c2VmdWwgZm9yIGFueSBwcm90
b2NvbCB0aGF0IGRvZXMgUlBDcy4gIEJ1dCBmb3IgYQ0KPiBub3RpZi1zcGVjaWZpYyB0cmFuc3Bv
cnQgbGlrZSBhIFVEUC1iYXNlZCBwcm90b2NvbCwgdGhhdCBkb2Vzbid0IGRvDQo+IG5vcm1hbCBS
UENzIGF0IGFsbCwgYW4gImFjdGl2YXRlLWNvbmZpZ3VyZWQtc3Vic2NyaXB0aW9uIiBSUEMgZG9l
c24ndA0KPiBtYWtlIHNlbnNlLiAgQnV0IHRoYXQgaXMgb2suDQoNClJpZ2h0LCBidXQgdGhlcmUg
aXMgYW4gaXNzdWUgb2YgdGltaW5nLiAgVGhlcmUgaXMgYSBxdWVzdGlvbiBpZiB0aGlzDQppcyBu
ZWVkZWQgbm93IG9yIGlmIGl0IGNhbiBiZSBhZGRlZCBpbiBhIFNOLWJpcy4gIEFkZGluZyB0aGUg
UlBDIHdvdWxkDQplYXN5LCBidXQgYWRkaW5nIHRoZSBpZGVudGl0eSAocmZjODA3MWJpcz8pIHdv
dWxkIGJlIG1vcmUgaW52b2x2ZWQuDQoNCk5vdGUgdGhhdCBzYWlkIFJQQyB3b3VsZCBiZSB1c2Vk
IGZvciBjYWxsLWhvbWUgY29ubmVjdGlvbnMgKGkuZS4sIHdoZXJlDQp0aGUgcm9sZXMgYXJlIHJl
dmVyc2VkKSwgYnV0IHVubGlrZWx5IHRvIGJlIHVzZWQgZm9yIHJlZ3VsYXIgY29ubmVjdGlvbnMN
CihpLmUuLCB3aGVuIHRoZSBwdWJsaXNoZXIgaXMgdGhlIE5DL1JDLWNsaWVudCkuICBUaGUgUlBD
IHdvdWxkIG5lZWQgdG8NCmJlIGRvY3VtZW50ZWQgYXMgb25seSBiZWluZyByZWxldmFudCB0byBj
YWxsLWhvbWUgY29ubmVjdGlvbnMuDQoNCg0KPj4gYW5kIEIpDQo+PiBkZWZpbmUgYW4gaWRlbnRp
dHkgb2ZmIG9mIHRoZSBiYXNlICJjYWxsLWhvbWUtcmVhc29uIiBpZGVudGl0eQ0KPj4gZGVmaW5l
ZCBpbiB0aGUgYWZvcmVtZW50aW9uZWQgSS1ELiAgVGhpcyBpcyBuZWVkZWQgYmVmb3JlIGFueQ0K
Pj4gbm90aWYgZHJhZnQgY2FuIGRlZmluZSBzdXBwb3J0IGZvciAiY29uZmlndXJlZCIgc3Vic2Ny
aXB0aW9ucywNCj4+IHJpZ2h0Pw0KPg0KPiBZZXMsIGJ1dCBpZiB3ZSBkZWZpbmUgdGhpcyBpZGVu
dGl0eSBub3cgaW4gU04gaXQgd291bGQgZGVsYXkgU04uDQo+IEJldHRlciB0byBkZWZpbmUgaXQg
bGF0ZXIgZWl0aGVyIGluIFNOLWJpcyBvciBkaXJlY3RseSBpbiBhIHNlcGFyYXRlDQo+IGRvY3Vt
ZW50Lg0KDQpTbywgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGluIFNOIGlzIGtub3duIHRvIGJl
IGJyb2tlbiBmb3IgY2FsbC1ob21lDQpjb25uZWN0aW9ucz8gIFNob3VsZCB0aGUgU04gZHJhZnQg
aWRlbnRpZnkgdGhpcyBhcyBhIGtub3duIGxpbWl0YXRpb24/DQoNCg0KS2VudCAvLyBjb250cmli
dXRvcg0KDQoNCg==


From nobody Mon Sep 10 17:58:25 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C00C130DE2 for ; Mon, 10 Sep 2018 17:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 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, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 izXq1O1GtRuo for ; Mon, 10 Sep 2018 17:58:21 -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 3D8AB1271FF for ; Mon, 10 Sep 2018 17:58:21 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8B0rVsx022553; Mon, 10 Sep 2018 17:58:18 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=mXkWCJxDYhJBJbH4o68/IGYLmcohPO7to5zV4IKJOG8=; b=AlpEXrlQOvedCnv9JQPsTp7G6CrECZsDrom4x+EtsZzmzlEe1qWOL+tP2DVKHc0Vz6BH FvZCh0aDsjwn4K1GrHMEfvCU5WLmqi4OcM+6CuRXe7n3gtm0zN5oAw6mxkoNOHW5Cm5o 3qXq7i6cFJ7TKm8gVqYfn0PpbDGkuBtcRlYWOnVWTQMKYGvsNK4Ab+okQJ+OnBYOepwl D6zPgbNMD4ambWF340Cxt1oK8g66KOMDYo13FUtujl5/fSm+g8EdoNK3CD9SJciSVb1F b95jc3LZsdtZjO6/b8c1QbnTaZEn3dputP+hJX0Twyt3CcWCRZXnT31otC2SsDIAW78Z cw== 
Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp0083.outbound.protection.outlook.com [216.32.180.83]) by mx0b-00273201.pphosted.com with ESMTP id 2mdy48re0c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 10 Sep 2018 17:58:18 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4300.namprd05.prod.outlook.com (20.176.78.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.11; Tue, 11 Sep 2018 00:58:16 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1143.010; Tue, 11 Sep 2018 00:58:16 +0000
From: Kent Watsen 
To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , Martin Bjorklund 
CC: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netconf@ietf.org" 
Thread-Topic: [Netconf] Mandatory local configuration in Keystore groupings
Thread-Index: AQHUE4rJV5t3ZASQT0G65kk51KFdjKSAiWUAgEnK74CAACpJAIABPX8AgAOrEACABC+ZAIAAwASAgAC9gACAAHNjgIAAFAaAgAEgEwCAAicPgIAF1PmAgAF1VYCACj3EgA==
Date: Tue, 11 Sep 2018 00:58:16 +0000
Message-ID: <185C7E6D-7EF1-4FFE-9A9B-74BA7E16D946@juniper.net>
References:    <20180903.121823.1406711858636851159.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4300; 6:yDYBh0BYJG9Kys+3qQb1S2ZuR9hvwir9ocXW/Jo0ij7vB0gtcFQ+6tyPyjrDor0H5e0k2m/qfiTCYFg/lzq2RWquT+BVFIiERw5P0BbtmjY0ZH/kYNB5GJ/7kyvbIFgT6Gl0K0BzgnyawOajfGkLZ5JByUKnbx8dOPQqMsq32z2VyxCKbgxaXTLZsbjmzKbEMmO71leMyEnpDO81n0AaMwMQAPPTpqp+6VM0KPwiH+R42FjycoSiID8exAbfFUx3nBmPSMiz8REKwpV4YWLuOOBMqU2NdC89KQl/5UNkEsna8jsbgXxvkiQpcPd0Qp6PVvNdNOf/Eo4j2bIeUYHRnrcIfu0L1sZUbBEnfMmmJT6Us1C8PK1hq10NotYVn4iJ/syqU4SxjXVNc+gdGmZMek7OfWmYX/oYjBnFKvEZ5GMBuN4F1xWMdeGN4byZgpIac+nH33t5WKrPuVgC39xM6Q==; 5:TrjYK6Te7rqBO/ndG5MrlXrYF46PcD7BrnsNc4buy2FWmKw5r8Fa4hnKYI2AlCHRenVrj44SJAFo3kP8+wpo7LJ4t5N5lT/t26QokXlpDvB3Mt1eL0E3JLUUIBDj1PoBq9NVLHkYkyjTW2ZN7ExZoz3X37TdQYDbIfI+DzSBjJY=; 7:mGplUMRGcgRuHuPDZTf6r9mllUecQkmeTB1qc1yObdyZYO0Mr4uygmSXwCHbp24GC+AocjIbZ9BP6tp4EXjEqpQoXt7XBdicU1eGgyc/gLUWIfHoz3v3HT/IPR3ydKToijR+YUSJt8UnwIdPItdlvtk8T2IwaJ9b0R+2uBxtB3IUf1hfpIoyi/6Hpaf7hyWo6rpNJE8Ke0e9PRA/LTsZU73z7gAcrmiYnZ+asysKA1IV2sgMyKaRxsHi6lbz3WG6
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 078ae5cb-7a0c-4ec2-b243-08d61781a8b1
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4300; 
x-ms-traffictypediagnostic: DM6PR05MB4300:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(138986009662008)(248295561703944)(17755550239193); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231344)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699050)(76991033); SRVR:DM6PR05MB4300; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4300; 
x-forefront-prvs: 0792DBEAD0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(346002)(376002)(39860400002)(189003)(199004)(13464003)(66066001)(6246003)(93886005)(11346002)(486006)(81156014)(81166006)(36756003)(33656002)(14444005)(102836004)(76176011)(6512007)(5250100002)(4326008)(476003)(446003)(2616005)(6346003)(26005)(186003)(105586002)(53936002)(229853002)(256004)(106356001)(6116002)(6436002)(14454004)(3846002)(97736004)(99286004)(6506007)(53546011)(86362001)(68736007)(8936002)(54906003)(25786009)(110136005)(2906002)(316002)(58126008)(82746002)(6486002)(8676002)(2900100001)(7736002)(5660300001)(305945005)(478600001)(83716003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4300; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: vX94IGBQZeZLyrS2vVTWaN+dMpY7dwynimCD7BsHnrtCAHZDoB5v7kaw6CzHj9IbmR1rkoDUSIr7xQMsiOCEXgEk+nAJ65FGjvtFNDHpUklwK8UmrKDUjh4PKF/BktyMFNLK98VT4k57aaYhKqOFks+xxvu/U9Eek9Az/caftzY+NAMmr3QL28mC7emhQDArMJuKuC1P8PAMMkepy8p6CdY8se/fYFWneLo1Dsro8fAPUhVSjQdQs0KlSX38eR7ubMPuVWCiSc1A/+2zHf+JxbheQrKwLdQtCJXUgdtHEvW1ZzPhX5fV4e4JbMsYa5YnrI/mPdoYQyqJ2QbXLjKrprKuJ0yrul3ZIuG0RAUxZYc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 078ae5cb-7a0c-4ec2-b243-08d61781a8b1
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2018 00:58:16.6360 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4300
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-10_12:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809110008
Archived-At: 
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Sep 2018 00:58:24 -0000

DQpUaGVyZSBhcmUgdHdvIHNvbHV0aW9ucyBiZWluZyBkaXNjdXNzZWQgaGVyZS4gIA0KDQpUaGUg
Zmlyc3QgcmVnYXJkcyBob3cgdG8gZW5hYmxlIGEgY2VydGlmaWNhdGUgdG8gYmUgY29uZmlndXJl
ZCBmb3IgYSBrZXkNCmluIDxvcGVyYXRpb25hbD4gKGUuZy4sIGFuIExEZXZJRCBjZXJ0IGZvciBh
IHByZWV4aXN0aW5nIGtleSkuICBCb3RoDQpzb2x1dGlvbiAoQSkgYW5kIChDKSBnaXZlIHVzIHRo
aXMgLSBhIGxhIFJGQyA4MzQyIFNlY3Rpb24gQy4zLjIuDQoNClRoZSBzZWNvbmQgaXMgaG93IHRv
IGRlbGV0ZSBhICJoaWRkZW4ga2V5IiBjcmVhdGVkIGJ5IGEgY2xpZW50IChub3RlIGhlcmUNCnRo
YXQgSSdtIGRpc3Rpbmd1aXNoaW5nIHRoaXMgY2FzZSBmcm9tIGhpZGRlbiBrZXlzIG5vdCBjcmVh
dGVkIGJ5IGEgY2xpZW50LA0KaS5lLiwgaW4gPG9wZXJhdGlvbmFsPiwgd2hpY2ggY2Fubm90IGJl
IGRlbGV0ZWQpLiAgSGVyZSdzIHdoZXJlIHRoZSBpZGVhcw0KZGl2ZXJnZToNCg0KICAtIHdpdGgg
KEEpLCB3ZSBrZWVwIHRoZSAiZ2VuZXJhdGUiIGFjdGlvbiBvdXRzaWRlIHRoZSBsaXN0IGVudHJ5
ICh0aHVzDQogICAgcmVzdWx0cyBhcmUgaW4gPG9wZXJhdGlvbmFsPiwgYW5kIGFkZCBhIG5ldyAi
ZGVsZXRlLWFzeW1tZXRyaWMta2V5Ig0KICAgIGFjdGlvbiBpcyBuZWVkZWQuDQoNCiAgLSB3aXRo
IChDKSwgdGhlIGFjdGlvbiBpcyBtb3ZlZCBpbnNpZGUgdGhlIGxpc3QgZW50cnksIHRodXMgdGhl
IGxpc3QNCiAgICBlbnRyeSBub2RlIGl0c2VsZiBpbiA8aW50ZW5kZWQ+LCBhbmQgaGVuY2UgY2Fu
IGJlIHJlbW92ZWQgZnJvbQ0KICAgIDxpbnRlbmRlZD4gdmlhIGEgbm9ybWFsIGNvbmZpZyBvcGVy
YXRpb24gKG5vIHNwZWNpYWwgYWN0aW9uIG5lZWRlZCkuDQoNCkkgZG9uJ3Qgc2VlIGFuIGlzc3Vl
IGNvbmZpZ3VyaW5nIGNlcnRpZmljYXRlcyBpbiBlaXRoZXIgY2FzZS4gIEFzIEkgd3JvdGUNCmFi
b3ZlLCBib3RoIHNvbHV0aW9uIChBKSBhbmQgKEMpIGdpdmUgdXMgdGhpcy4gKEMpIHN0aWxsIGhh
cyB0byBoYW5kbGUNCnRoZSBjYXNlIHdoZXJlIHRoZSBrZXkgaXMgaW4gPG9wZXJhdGlvbmFsPiBz
YW1lIGFzIChBKS4gIFdpdGggKEMpLCBpdCdzDQp0aGUgMSUgY2FzZSwgd2hlcmVhcyB3aXRoIChB
KSBpdOKAmXMgdGhlIDEwMCUgY2FzZS4NCg0KVGhleSBzZWVtIGNsb3NlLiAgRm9yIHRoZSBwdXJw
b3NlIG9mIGNyZWF0aW5nIGEga2V5LCAoQykgaXMgbW9yZQ0KY29tcGxpY2F0ZWQuICBGb3IgdGhl
IHB1cnBvc2Ugb2YgZGVsZXRpbmcgYSBrZXksIChDKSBzZWVtcyBlYXNpZXIuDQoNCklmIHRoZSBh
Y3Rpb24gaXMgYnJvdWdodCBpbnNpZGUgdGhlIGxpc3QgZW50cnksIHRoZW4gcmVuYW1pbmcgaXQg
dG8NCiJnZW5lcmF0ZS1oaWRkZW4ta2V5IiBtYWtlcyBzZW5zZS4NCg0KS2VudCAvLyBjb250cmli
dXRvcg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KSGkgTWFydGluLA0KDQpJ
IHByZWZlciB5b3VyIGFsdGVybmF0aXZlIChDKSB3aXRoIHNvbWUgY29tbWVudHMuDQoNCkknZCBr
ZWVwIHRoZSBuYW1lIG9mIHRoZSBhY3Rpb24gYXMgJ2dlbmVyYXRlLWFzeW1tZXRyaWMta2V5Jy4g
SSB0aGluayB0aGUgd29yZCAnYXN5bW1ldHJpYycgZ2l2ZXMgYSBoaW50IG9uIGl0cyBpbnRlbmRl
ZCB1c2UgY2FzZSwgc28gaXQgaXMgaW1wb3J0YW50ICh0aG91Z2ggaXQgaXMgYWxyZWFkeSBpbiBh
biBhc3ltbWV0cmljLWtleSBsaXN0KS4gVGhlIHdvcmQgJ2hpZGRlbicgaXMgbm90IHRoYXQgaW1w
b3J0YW50IGZvciBtZSBzaW5jZSB0aGUgYWN0aW9uIGluIGl0c2VsZiBoaW50cyB0aGF0IHRoZSBr
ZXkgaW4gdGhpcyBjYXNlIGlzIG5vdCBwcm92aWRlZCBieSB0aGUgb3BlcmF0b3IsIHRodXMgaXRz
IGJpbmFyeSB2YWx1ZSB3b24ndCBhcHBlYXIgZWl0aGVyLiBJZiBvcGVyYXRvciBuZWVkcyB0byBw
cm92aWRlIGl0LCBpdCBoYXMgdG8gZ28gdmlhIHRoZSAncHJpdmF0ZS1rZXknIGxlYWYuIE9yIHRo
ZSBhY3Rpb24gY291bGQgYmUganVzdCBjYWxsZWQgJ2dlbmVyYXRlLWtleScuDQoNCkEgcXVlc3Rp
b24gc3RpbGw6IGl0IGlzIHVuY2xlYXIgdG8gbWUgd2hhdCB0aGUgZGlmZmVyZW5jZSBpcyBiZXR3
ZWVuIGNhbGxpbmcgdGhlIGFjdGlvbiB2cyBqdXN0IGNvbmZpZ3VyaW5nIHRoZSAncHJpdmF0ZS1r
ZXknIHRvIGVudW0gJ2hpZGRlbicuDQoNCkJyLA0KQmFsYXpzDQoNCg0KPiAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4N
Cj4gU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMywgMjAxOCAxMjoxOCBQTQ0KPiBUbzoga3dhdHNl
bkBqdW5pcGVyLm5ldA0KPiBDYzogQmFsw6F6cyBLb3bDoWNzIDxiYWxhenMua292YWNzQGVyaWNz
c29uLmNvbT47IEJhbMOhenMgTGVuZ3llbA0KPiA8YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t
PjsgbmV0Y29uZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIE1hbmRhdG9yeSBs
b2NhbCBjb25maWd1cmF0aW9uIGluIEtleXN0b3JlIGdyb3VwaW5ncw0KPiANCj4gS2VudCBXYXRz
ZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiA+ID4gQmFsYXpzPiBUaGUgY2VydGlm
aWNhdGVzIGluIGtleXN0b3JlIGFyZSB1c2VsZXNzIHdpdGhvdXQgYQ0KPiA+ID4gQmFsYXpzPiBj
b3JyZXNwb25kaW5nDQo+ID4gPiBwcml2YXRlIGtleSwgc28gY2VydGlmaWNhdGVzIG9mIGEga2V5
IGNhbm5vdCBiZSBpbiB0aGUgY29uZmlndXJhdGlvbg0KPiA+ID4gdHJlZSBvbmNlIHRoZSBjb3Jy
ZXNwb25kaW5nIGtleSBpcyByZW1vdmVkLiBCeSB0aGUgd2F5LCBob3cgd291bGQgYQ0KPiA+ID4g
cHJpdmF0ZSBrZXkgYmUgcmVtb3ZlZCBmcm9tIDxvcGVyYXRpb25hbD4gaWYgaXQgZG9lcyBub3Qg
ZXhpc3QgaW4NCj4gPiA+IGNvbmZpZ3VyYXRpb24/IElmIHlvdSBkbyBpdCB3aXRoIGFuIGFjdGlv
biB0b28sIGhvdyB3b3VsZCB0aGUNCj4gPiA+IGNvcnJlc3BvbmRpbmcgY2VydGlmaWNhdGVzIGJl
IHJlbW92ZWQgZnJvbSB0aGUgY29uZmlndXJhdGlvbj8NCj4gPg0KPiA+IEdvb2QgcG9pbnRzLg0K
PiANCj4gWWVzLiAgVGhlIGxpZmVjeWNsZSBvZiBrZXlzIGFyZSBub3QgaGFuZGxlZCBmdWxseSBp
biB0aGUgY3VycmVudCBkcmFmdC4gIEJ1dCBJDQo+IHRoaW5rIHRoYXQgaWYgdGhpcyBpcyBkb25l
IHByb3Blcmx5LCBzZXBhcmF0aW5nIHRoZSBjb25maWcgb2Yga2V5cyBhbmQNCj4gY2VydGlmaWNh
dGVzIHdvdWxkIG5vdCBjaGFuZ2UgdGhlIGxpZmVjeWNsZSBvZiBob3cga2V5cy4gIFNvIGxldCdz
IGZpcnN0IGRpc2N1c3MNCj4gaG93IHdlIHdhbnQgdG8gaGFuZGxlIGNyZWF0aW9uIGFuZCByZW1v
dmFsIG9mIHRoZSBoaWRkZW4ga2V5cyAoY29uZmlndXJlZA0KPiBrZXlzIGFyZSBub3QgYSBwcm9i
bGVtKS4NCj4gDQo+IFdpdGggdGhlIGN1cnJlbnQgZHJhZnQsIGEgaGlkZGVuIGtleSBpcyBjcmVh
dGVkIGluIDxvcGVyYXRpb24+IHdpdGggYW4gYWN0aW9uDQo+IGFuZCBtYXkgbm90IGJlIHByZXNl
bnQgaW4gPHJ1bm5pbmc+IGFuZCA8aW50ZW5kZWQ+LiAgVGhlcmUgaXMgbm8gd2F5IHRvDQo+IGRl
bGV0ZSBzdWNoIGEga2V5LiAgV2Ugd291bGQgaGF2ZSB0byBjcmVhdGUgYSBuZXcgYWN0aW9uIHRv
IHJlbW92ZSBpdC4NCj4gDQo+IEFuIGFsdGVybmF0aXZlIGRlc2lnbiBjb3VsZCBiZSB0byBtb3Zl
IHRoZSBhY3Rpb24gImdlbmVyYXRlLWFzeW1tZXRyaWMtDQo+IGtleSIgaW50byB0aGUgImFzeW1t
ZXRyaWMta2V5IiBsaXN0IChhbmQgbWF5YmUgcmVuYW1lIGl0IHRvICJnZW5lcmF0ZS0NCj4gaGlk
ZGVuLWtleSIpLiAgQSBjbGllbnQgd291bGQgdGhlbiBmaXJzdCBoYXZlIHRvIGNvbmZpZ3VyZSBh
biBlbnRyeSBpbiB0aGUNCj4gImFzeW1tZXRyaWMta2V5IiBsaXN0LCBhbmQgdGhlbiBpdCBjYW4g
Z2VuZXJhdGUgdGhlIGhpZGRlbiBrZXkuICBJZiB0aGUNCj4gYXN5bW1ldHJpYy1rZXkgbGlzdCBl
bnRyeSBpcyByZW1vdmVkIGZyb20gPGludGVuZGVkPiwgdGhlbiBwcmVzdW1hYmx5IHRoZQ0KPiBj
b3JyZXNwb25kaW5nIGhpZGRlbiBrZXkgaXMgcmVtb3ZlZCBhcyB3ZWxsLg0KPiANCj4gV2l0aCB0
aGlzIGRlc2lnbiwgYSBzZXBhcmF0ZSAiY2VydGlmaWNhdGUiIGxpc3QgY291bGQgaGF2ZSBub3Jt
YWwgbGVhZnJlZg0KPiAocmVxdWlyZS1pbnN0YW5jZSB0cnVlKSBpbnRvIHRoZSAiYXN5bW1ldHJp
Yy1rZXkiIGxpc3QuDQo+IEhvd2V2ZXIsIHdpdGggdGhpcyBuZXcgZGVzaWduIG15IG9yaWdpbmFs
IGlzc3VlIHdpdGggaG93IGNlcnRpZmljYXRlcyBhcmUNCj4gaGFuZGxlZCBnb2VzIGF3YXksIHNv
IGhhdmluZyB0aGVtIGNvbnRhaW5lZCBpbiB0aGUgImFzeW1tZXRyaWMta2V5IiBsaXN0DQo+IHdv
cmtzIGZpbmUuDQo+IA0KPiA+ID4+IE1hcnRpbiBtYWtlcyBhIGNhc2UgZm9yICdCJywgYnV0IGhl
IGFsc28gc2FpZCB0aGF0IG15ICdiJyB3YXMNCj4gPiA+PiAiQmV0dGVyIiBidXQgaGFzIHNjYWxp
bmcgaXNzdWVzIGluIHRoZSBnZW5lcmFsIGNhc2UuICBQZXJoYXBzIHdlDQo+ID4gPj4gZG9uJ3Qg
d29ycnkgYWJvdXQgdGhlIGdlbmVyYWwgY2FzZSBoZXJlPw0KPiA+ID4NCj4gPiA+IEJhbGF6cz4g
V2FzIGl0IHNvPyBJIHNhdyBhbiBBIGFuZCBCIG1vZGVsLCBBIGNvbnRhaW5pbmcNCj4gPiA+IG11
c3QgIihhbGdvcml0aG0gYW5kIHB1YmxpYy1rZXkgYW5kIHByaXZhdGUta2V5KQ0KPiA+ID4gICAg
ICAgICAgICAgIG9yIG5vdCAoYWxnb3JpdGhtIG9yIHB1YmxpYy1rZXkgb3IgcHJpdmF0ZS1rZXkp
IjsgYW5kIEINCj4gPiA+IGNvbnRhaW5pbmcgdGhlIGtleXMgYW5kIHRoZSBjZXJ0aWZpY2F0ZXMg
aW4gc2VwYXJhdGUgY29udGFpbmVyLCBhbmQNCj4gPiA+IGEgbm90ZSAiSSB0aGluayBtb2RlbCBC
IGlzIGNsZWFuZXIiLg0KPiA+DQo+ID4gUmlnaHQsIGJ1dCBpZiB5b3Ugc2Nyb2xsIHVwIGhpZ2hl
ciwgSSBoYWQgcHJldmlvdXNseSBoYWQgYW4gKGEpIGFuZA0KPiA+IChiKSBbbm90ZSBsb3dlcmNh
c2VdIHRvIHdoaWNoIGhlIHNhaWQgKGIpIHdhcyAiYmV0dGVyIi4gIE1heWJlIGl0J3MNCj4gPiBt
b290LCBzaW5jZSBoaXMgKEEpIHdhcyBlZmZlY3RpdmVseSBteSAoYikuDQo+IA0KPiBIZXJlJ3Mg
dGhlIG5ldyBhbHRlcm5hdGl2ZToNCj4gDQo+IChDKQ0KPiANCj4gICBjb250YWluZXIga2V5c3Rv
cmUgew0KPiAgICAgY29udGFpbmVyIGFzeW1tZXRyaWMta2V5cyB7DQo+ICAgICAgIGxpc3QgYXN5
bW1ldHJpYy1rZXkgew0KPiAgICAgICAgIGtleSBuYW1lOw0KPiANCj4gICAgICAgICBsZWFmIG5h
bWUgeyAuLi4gfQ0KPiAgICAgICAgIGxlYWYgYWxnb3JpdGhtIHsgbWFuZGF0b3J5IHRydWU7IC4u
LiB9DQo+IA0KPiAgICAgICAgIGxlYWYgcHVibGljLWtleSB7IC4uLiB9DQo+ICAgICAgICAgbGVh
ZiBwcml2YXRlLWtleSB7IC4uLiB9DQo+IA0KPiAgICAgICAgIC8vIGVuc3VyZSB0aGF0IGJvdGgg
b3Igbm9uZSBhcmUgZ2l2ZW4NCj4gICAgICAgICBtdXN0ICIocHVibGljLWtleSBhbmQgcHJpdmF0
ZS1rZXkpDQo+ICAgICAgICAgICAgICAgb3Igbm90IChwdWJsaWMta2V5IG9yIHByaXZhdGUta2V5
KSI7DQo+IA0KPiAgICAgICAgIGFjdGlvbiBnZW5lcmF0ZS1oaWRkZW4ta2V5IHsgLy8gbm8gaW5w
dXQgcGFyYW1zIH0NCj4gDQo+ICAgICAgICAgY29udGFpbmVyIGNlcnRpZmljYXRlcyB7DQo+ICAg
ICAgICAgICBsaXN0IGNlcnRpZmljYXRlIHsgLi4uIH0NCj4gICAgICAgICB9DQo+ICAgICB9DQo+
ICAgfQ0KPiANCj4gQSBwb3NzaWJsZSBleHRlbnNpb24gdG8gdGhpcyB3b3VsZCBiZSB0byBhZGQg
YW5vdGVyIGFjdGlvbiBuZXh0IHRvDQo+ICJnZW5lcmF0ZS1oaWRkZW4ta2V5IjoNCj4gDQo+ICAg
IGFjdGlvbiBpbnN0YWxsLWhpZGRlbi1rZXkgew0KPiAgICAgICBsZWFmIHB1YmxpYy1rZXkgeyAu
Li4gfQ0KPiAgICAgICBsZWFmIHByaXZhdGUta2V5IHsgLi4uIH0NCj4gICAgfQ0KPiANCj4gDQo+
IE9uZSBjYXNlIHRvIGNvbnNpZGVyIGlzIHRoYXQgdGhlcmUgbWF5IGV4aXN0IGFuIGVudHJ5IGlu
IDxpbnRlbmRlZD4gdGhhdCBoYXMNCj4gYmVlbiBjb25maWd1cmVkIGJ1dCBubyBoaWRkZW4ga2V5
IGhhcyB5ZXQgYmVlbiBnZW5lcmF0ZWQuDQo+IFN1Y2ggYW4gZW50cnkgd291bGQgdGhlbiBub3Qg
ZXhpc3QgaW4gPG9wZXJhdGlvbmFsPiwgYW5kIHRoZSBhY3Rpb24NCj4gImdlbmVyYXRlLWNlcnRp
ZmljYXRlLXNpZ25pbmctcmVxdWVzdCIgd291bGQgZmFpbC4NCj4gDQo+IA0KPiANCj4gL21hcnRp
bg0KDQoNCg==


From nobody Tue Sep 11 00:33:13 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2611130E36 for ; Tue, 11 Sep 2018 00:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 r6atoPa-G8sn for ; Tue, 11 Sep 2018 00:33:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CD022130E41 for ; Tue, 11 Sep 2018 00:33:09 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id BA6931AE03F5; Tue, 11 Sep 2018 09:33:07 +0200 (CEST)
Date: Tue, 11 Sep 2018 09:33:07 +0200 (CEST)
Message-Id: <20180911.093307.1050612475582993510.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: j.schoenwaelder@jacobs-university.de, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <8BAC2AAA-0E70-4EDA-B6A8-E4F94445D2F0@juniper.net>
References:  <20180903.105436.927964486928721459.mbj@tail-f.com> <8BAC2AAA-0E70-4EDA-B6A8-E4F94445D2F0@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] netconf call home connection type
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Sep 2018 07:33:11 -0000

Kent Watsen  wrote:
> Hi Martin,
> 
> Catching up on mail from last week.
> 
> 
> >> Also, it seems that, if we want YP+SN to be able to use call-home 
> >> for configured subscriptions, then we need to update the SN draft
> >> to A) define the "activate-configured-subscription" RPC
> >
> > I started to write that I don't think this belongs to the SN draft,
> > since it is NETCONF-specific.  But after thinking some more about it I
> > think it makes sense to define this operation in the SN draft.
> >
> > For RESTCONF (not a new HTTP protocol) this rpc could be used
> > by augmenting a 'location' leaf to its output.
> >
> > It is probably useful for any protocol that does RPCs.  But for a
> > notif-specific transport like a UDP-based protocol, that doesn't do
> > normal RPCs at all, an "activate-configured-subscription" RPC doesn't
> > make sense.  But that is ok.
> 
> Right, but there is an issue of timing.  There is a question if this
> is needed now or if it can be added in a SN-bis.  Adding the RPC would
> easy, but adding the identity (rfc8071bis?) would be more involved.
> 
> Note that said RPC would be used for call-home connections (i.e., where
> the roles are reversed), but unlikely to be used for regular connections
> (i.e., when the publisher is the NC/RC-client).  The RPC would need to
> be documented as only being relevant to call-home connections.

Yes.

> >> and B)
> >> define an identity off of the base "call-home-reason" identity
> >> defined in the aforementioned I-D.  This is needed before any
> >> notif draft can define support for "configured" subscriptions,
> >> right?
> >
> > Yes, but if we define this identity now in SN it would delay SN.
> > Better to define it later either in SN-bis or directly in a separate
> > document.
> 
> So, configured subscriptions in SN is known to be broken for call-home
> connections?  Should the SN draft identify this as a known limitation?

If we have the rpc, it is less broken.  I would prefer to define the
rpc in SN now.  Since we decided to work out the details for
configured subscriptions now in SN, I don't think we can ignore this
issue.

The identity is less important imo.  And of course, the identity is of
no use until the "call-home-reason" data model has been defined...


/martin


From nobody Tue Sep 11 00:53:48 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDC71310E6 for ; Tue, 11 Sep 2018 00:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Eij9qJ1y_MuS for ; Tue, 11 Sep 2018 00:53:35 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 703861310E0 for ; Tue, 11 Sep 2018 00:53:35 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id ADE7F1AE03F5; Tue, 11 Sep 2018 09:53:34 +0200 (CEST)
Date: Tue, 11 Sep 2018 09:53:34 +0200 (CEST)
Message-Id: <20180911.095334.2041631968993039535.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: balazs.kovacs@ericsson.com, balazs.lengyel@ericsson.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <185C7E6D-7EF1-4FFE-9A9B-74BA7E16D946@juniper.net>
References: <20180903.121823.1406711858636851159.mbj@tail-f.com>  <185C7E6D-7EF1-4FFE-9A9B-74BA7E16D946@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Sep 2018 07:53:46 -0000

SGksICAgICAgICANCg0KS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0K
PiANCj4gVGhlcmUgYXJlIHR3byBzb2x1dGlvbnMgYmVpbmcgZGlzY3Vzc2VkIGhlcmUuICANCj4g
DQo+IFRoZSBmaXJzdCByZWdhcmRzIGhvdyB0byBlbmFibGUgYSBjZXJ0aWZpY2F0ZSB0byBiZSBj
b25maWd1cmVkIGZvciBhIGtleQ0KPiBpbiA8b3BlcmF0aW9uYWw+IChlLmcuLCBhbiBMRGV2SUQg
Y2VydCBmb3IgYSBwcmVleGlzdGluZyBrZXkpLiAgQm90aA0KPiBzb2x1dGlvbiAoQSkgYW5kIChD
KSBnaXZlIHVzIHRoaXMgLSBhIGxhIFJGQyA4MzQyIFNlY3Rpb24gQy4zLjIuDQo+IA0KPiBUaGUg
c2Vjb25kIGlzIGhvdyB0byBkZWxldGUgYSAiaGlkZGVuIGtleSIgY3JlYXRlZCBieSBhIGNsaWVu
dCAobm90ZSBoZXJlDQo+IHRoYXQgSSdtIGRpc3Rpbmd1aXNoaW5nIHRoaXMgY2FzZSBmcm9tIGhp
ZGRlbiBrZXlzIG5vdCBjcmVhdGVkIGJ5IGEgY2xpZW50LA0KPiBpLmUuLCBpbiA8b3BlcmF0aW9u
YWw+LCB3aGljaCBjYW5ub3QgYmUgZGVsZXRlZCkuICBIZXJlJ3Mgd2hlcmUgdGhlIGlkZWFzDQo+
IGRpdmVyZ2U6DQo+IA0KPiAgIC0gd2l0aCAoQSksIHdlIGtlZXAgdGhlICJnZW5lcmF0ZSIgYWN0
aW9uIG91dHNpZGUgdGhlIGxpc3QgZW50cnkgKHRodXMNCj4gICAgIHJlc3VsdHMgYXJlIGluIDxv
cGVyYXRpb25hbD4sIGFuZCBhZGQgYSBuZXcgImRlbGV0ZS1hc3ltbWV0cmljLWtleSINCj4gICAg
IGFjdGlvbiBpcyBuZWVkZWQuDQo+IA0KPiAgIC0gd2l0aCAoQyksIHRoZSBhY3Rpb24gaXMgbW92
ZWQgaW5zaWRlIHRoZSBsaXN0IGVudHJ5LCB0aHVzIHRoZSBsaXN0DQo+ICAgICBlbnRyeSBub2Rl
IGl0c2VsZiBpbiA8aW50ZW5kZWQ+LCBhbmQgaGVuY2UgY2FuIGJlIHJlbW92ZWQgZnJvbQ0KPiAg
ICAgPGludGVuZGVkPiB2aWEgYSBub3JtYWwgY29uZmlnIG9wZXJhdGlvbiAobm8gc3BlY2lhbCBh
Y3Rpb24gbmVlZGVkKS4NCj4gDQo+IEkgZG9uJ3Qgc2VlIGFuIGlzc3VlIGNvbmZpZ3VyaW5nIGNl
cnRpZmljYXRlcyBpbiBlaXRoZXIgY2FzZS4gIEFzIEkgd3JvdGUNCj4gYWJvdmUsIGJvdGggc29s
dXRpb24gKEEpIGFuZCAoQykgZ2l2ZSB1cyB0aGlzLiAoQykgc3RpbGwgaGFzIHRvIGhhbmRsZQ0K
PiB0aGUgY2FzZSB3aGVyZSB0aGUga2V5IGlzIGluIDxvcGVyYXRpb25hbD4gc2FtZSBhcyAoQSku
ICBXaXRoIChDKSwgaXQncw0KPiB0aGUgMSUgY2FzZSwgd2hlcmVhcyB3aXRoIChBKSBpdOKAmXMg
dGhlIDEwMCUgY2FzZS4NCg0KSG93IGNhbiBhIGtleSBiZSBpbiBvcGVyYXRpb25hbCBidXQgbm90
IGluIGNvbmZpZyBpbiAoQyk/ICBJLmUuLCB3aGF0DQppcyB0aGUgMSUgY2FzZT8NCg0KPiBUaGV5
IHNlZW0gY2xvc2UuICBGb3IgdGhlIHB1cnBvc2Ugb2YgY3JlYXRpbmcgYSBrZXksIChDKSBpcyBt
b3JlDQo+IGNvbXBsaWNhdGVkLiAgRm9yIHRoZSBwdXJwb3NlIG9mIGRlbGV0aW5nIGEga2V5LCAo
Qykgc2VlbXMgZWFzaWVyLg0KDQpGb3IgdGhlIHB1cnBvc2Ugb2YgY3JlYXRpbmcgYSBjZXJ0aWZp
Y2F0ZSAoQSkgaXMgbW9yZSBjb21wbGljYXRlZC4NCg0KRGVwZW5kaW5nIG9uIHRoZSBhbnN3ZXIg
YWJvdmUsIChDKSBoYXMgdGhlIGFkdmFudGFnZSB0aGF0IHJlZmVyZW5jZXMNCihsZWFmcmVmcykg
dG8gYSBrZXkgY2FuIGJlIHJlcXVpcmUgaW5zdGFuY2UgdHJ1ZS4gIFdpdGggKEEpIHRoZXkgaGF2
ZQ0KdG8gYmUgcmVxdWlyZSBpbnN0YW5jZSBmYWxzZSwgc2luY2Ugc29tZSBrZXlzIG9ubHkgZXhp
c3RzIGluDQpvcGVyYXRpb25hbCwgd2hpY2ggbWVhbnMgdGhhdCB3aGVuZXZlciB0aGVyZSBpcyBh
IHJlZmVyZW5jZSB0byBhIGtleSwNCnRoYXQgbW9kZWwgYW5kIGNvZGUgbXVzdCBiZSBhYmxlIHRv
IGhhbmRsZSB0aGUgY2FzZSB0aGF0IHRoZSBrZXkNCmRvZXNuJ3QgZXhpc3QuDQoNCg0KDQoNCg0K
L21hcnRpbg0KDQoNCj4gDQo+IElmIHRoZSBhY3Rpb24gaXMgYnJvdWdodCBpbnNpZGUgdGhlIGxp
c3QgZW50cnksIHRoZW4gcmVuYW1pbmcgaXQgdG8NCj4gImdlbmVyYXRlLWhpZGRlbi1rZXkiIG1h
a2VzIHNlbnNlLg0KPiANCj4gS2VudCAvLyBjb250cmlidXRvcg0KPiANCj4gDQo+IA0KPiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiANCj4gSGkgTWFydGluLA0KPiANCj4gSSBwcmVmZXIg
eW91ciBhbHRlcm5hdGl2ZSAoQykgd2l0aCBzb21lIGNvbW1lbnRzLg0KPiANCj4gSSdkIGtlZXAg
dGhlIG5hbWUgb2YgdGhlIGFjdGlvbiBhcyAnZ2VuZXJhdGUtYXN5bW1ldHJpYy1rZXknLiBJIHRo
aW5rIHRoZSB3b3JkICdhc3ltbWV0cmljJyBnaXZlcyBhIGhpbnQgb24gaXRzIGludGVuZGVkIHVz
ZSBjYXNlLCBzbyBpdCBpcyBpbXBvcnRhbnQgKHRob3VnaCBpdCBpcyBhbHJlYWR5IGluIGFuIGFz
eW1tZXRyaWMta2V5IGxpc3QpLiBUaGUgd29yZCAnaGlkZGVuJyBpcyBub3QgdGhhdCBpbXBvcnRh
bnQgZm9yIG1lIHNpbmNlIHRoZSBhY3Rpb24gaW4gaXRzZWxmIGhpbnRzIHRoYXQgdGhlIGtleSBp
biB0aGlzIGNhc2UgaXMgbm90IHByb3ZpZGVkIGJ5IHRoZSBvcGVyYXRvciwgdGh1cyBpdHMgYmlu
YXJ5IHZhbHVlIHdvbid0IGFwcGVhciBlaXRoZXIuIElmIG9wZXJhdG9yIG5lZWRzIHRvIHByb3Zp
ZGUgaXQsIGl0IGhhcyB0byBnbyB2aWEgdGhlICdwcml2YXRlLWtleScgbGVhZi4gT3IgdGhlIGFj
dGlvbiBjb3VsZCBiZSBqdXN0IGNhbGxlZCAnZ2VuZXJhdGUta2V5Jy4NCj4gDQo+IEEgcXVlc3Rp
b24gc3RpbGw6IGl0IGlzIHVuY2xlYXIgdG8gbWUgd2hhdCB0aGUgZGlmZmVyZW5jZSBpcyBiZXR3
ZWVuIGNhbGxpbmcgdGhlIGFjdGlvbiB2cyBqdXN0IGNvbmZpZ3VyaW5nIHRoZSAncHJpdmF0ZS1r
ZXknIHRvIGVudW0gJ2hpZGRlbicuDQo+IA0KPiBCciwNCj4gQmFsYXpzDQo+IA0KPiANCj4gPiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IE1hcnRpbiBCam9ya2x1bmQgPG1i
akB0YWlsLWYuY29tPg0KPiA+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDMsIDIwMTggMTI6MTgg
UE0NCj4gPiBUbzoga3dhdHNlbkBqdW5pcGVyLm5ldA0KPiA+IENjOiBCYWzDoXpzIEtvdsOhY3Mg
PGJhbGF6cy5rb3ZhY3NAZXJpY3Nzb24uY29tPjsgQmFsw6F6cyBMZW5neWVsDQo+ID4gPGJhbGF6
cy5sZW5neWVsQGVyaWNzc29uLmNvbT47IG5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBS
ZTogW05ldGNvbmZdIE1hbmRhdG9yeSBsb2NhbCBjb25maWd1cmF0aW9uIGluIEtleXN0b3JlIGdy
b3VwaW5ncw0KPiA+IA0KPiA+IEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90
ZToNCj4gPiA+ID4gQmFsYXpzPiBUaGUgY2VydGlmaWNhdGVzIGluIGtleXN0b3JlIGFyZSB1c2Vs
ZXNzIHdpdGhvdXQgYQ0KPiA+ID4gPiBCYWxhenM+IGNvcnJlc3BvbmRpbmcNCj4gPiA+ID4gcHJp
dmF0ZSBrZXksIHNvIGNlcnRpZmljYXRlcyBvZiBhIGtleSBjYW5ub3QgYmUgaW4gdGhlIGNvbmZp
Z3VyYXRpb24NCj4gPiA+ID4gdHJlZSBvbmNlIHRoZSBjb3JyZXNwb25kaW5nIGtleSBpcyByZW1v
dmVkLiBCeSB0aGUgd2F5LCBob3cgd291bGQgYQ0KPiA+ID4gPiBwcml2YXRlIGtleSBiZSByZW1v
dmVkIGZyb20gPG9wZXJhdGlvbmFsPiBpZiBpdCBkb2VzIG5vdCBleGlzdCBpbg0KPiA+ID4gPiBj
b25maWd1cmF0aW9uPyBJZiB5b3UgZG8gaXQgd2l0aCBhbiBhY3Rpb24gdG9vLCBob3cgd291bGQg
dGhlDQo+ID4gPiA+IGNvcnJlc3BvbmRpbmcgY2VydGlmaWNhdGVzIGJlIHJlbW92ZWQgZnJvbSB0
aGUgY29uZmlndXJhdGlvbj8NCj4gPiA+DQo+ID4gPiBHb29kIHBvaW50cy4NCj4gPiANCj4gPiBZ
ZXMuICBUaGUgbGlmZWN5Y2xlIG9mIGtleXMgYXJlIG5vdCBoYW5kbGVkIGZ1bGx5IGluIHRoZSBj
dXJyZW50IGRyYWZ0LiAgQnV0IEkNCj4gPiB0aGluayB0aGF0IGlmIHRoaXMgaXMgZG9uZSBwcm9w
ZXJseSwgc2VwYXJhdGluZyB0aGUgY29uZmlnIG9mIGtleXMgYW5kDQo+ID4gY2VydGlmaWNhdGVz
IHdvdWxkIG5vdCBjaGFuZ2UgdGhlIGxpZmVjeWNsZSBvZiBob3cga2V5cy4gIFNvIGxldCdzIGZp
cnN0IGRpc2N1c3MNCj4gPiBob3cgd2Ugd2FudCB0byBoYW5kbGUgY3JlYXRpb24gYW5kIHJlbW92
YWwgb2YgdGhlIGhpZGRlbiBrZXlzIChjb25maWd1cmVkDQo+ID4ga2V5cyBhcmUgbm90IGEgcHJv
YmxlbSkuDQo+ID4gDQo+ID4gV2l0aCB0aGUgY3VycmVudCBkcmFmdCwgYSBoaWRkZW4ga2V5IGlz
IGNyZWF0ZWQgaW4gPG9wZXJhdGlvbj4gd2l0aCBhbiBhY3Rpb24NCj4gPiBhbmQgbWF5IG5vdCBi
ZSBwcmVzZW50IGluIDxydW5uaW5nPiBhbmQgPGludGVuZGVkPi4gIFRoZXJlIGlzIG5vIHdheSB0
bw0KPiA+IGRlbGV0ZSBzdWNoIGEga2V5LiAgV2Ugd291bGQgaGF2ZSB0byBjcmVhdGUgYSBuZXcg
YWN0aW9uIHRvIHJlbW92ZSBpdC4NCj4gPiANCj4gPiBBbiBhbHRlcm5hdGl2ZSBkZXNpZ24gY291
bGQgYmUgdG8gbW92ZSB0aGUgYWN0aW9uICJnZW5lcmF0ZS1hc3ltbWV0cmljLQ0KPiA+IGtleSIg
aW50byB0aGUgImFzeW1tZXRyaWMta2V5IiBsaXN0IChhbmQgbWF5YmUgcmVuYW1lIGl0IHRvICJn
ZW5lcmF0ZS0NCj4gPiBoaWRkZW4ta2V5IikuICBBIGNsaWVudCB3b3VsZCB0aGVuIGZpcnN0IGhh
dmUgdG8gY29uZmlndXJlIGFuIGVudHJ5IGluIHRoZQ0KPiA+ICJhc3ltbWV0cmljLWtleSIgbGlz
dCwgYW5kIHRoZW4gaXQgY2FuIGdlbmVyYXRlIHRoZSBoaWRkZW4ga2V5LiAgSWYgdGhlDQo+ID4g
YXN5bW1ldHJpYy1rZXkgbGlzdCBlbnRyeSBpcyByZW1vdmVkIGZyb20gPGludGVuZGVkPiwgdGhl
biBwcmVzdW1hYmx5IHRoZQ0KPiA+IGNvcnJlc3BvbmRpbmcgaGlkZGVuIGtleSBpcyByZW1vdmVk
IGFzIHdlbGwuDQo+ID4gDQo+ID4gV2l0aCB0aGlzIGRlc2lnbiwgYSBzZXBhcmF0ZSAiY2VydGlm
aWNhdGUiIGxpc3QgY291bGQgaGF2ZSBub3JtYWwgbGVhZnJlZg0KPiA+IChyZXF1aXJlLWluc3Rh
bmNlIHRydWUpIGludG8gdGhlICJhc3ltbWV0cmljLWtleSIgbGlzdC4NCj4gPiBIb3dldmVyLCB3
aXRoIHRoaXMgbmV3IGRlc2lnbiBteSBvcmlnaW5hbCBpc3N1ZSB3aXRoIGhvdyBjZXJ0aWZpY2F0
ZXMgYXJlDQo+ID4gaGFuZGxlZCBnb2VzIGF3YXksIHNvIGhhdmluZyB0aGVtIGNvbnRhaW5lZCBp
biB0aGUgImFzeW1tZXRyaWMta2V5IiBsaXN0DQo+ID4gd29ya3MgZmluZS4NCj4gPiANCj4gPiA+
ID4+IE1hcnRpbiBtYWtlcyBhIGNhc2UgZm9yICdCJywgYnV0IGhlIGFsc28gc2FpZCB0aGF0IG15
ICdiJyB3YXMNCj4gPiA+ID4+ICJCZXR0ZXIiIGJ1dCBoYXMgc2NhbGluZyBpc3N1ZXMgaW4gdGhl
IGdlbmVyYWwgY2FzZS4gIFBlcmhhcHMgd2UNCj4gPiA+ID4+IGRvbid0IHdvcnJ5IGFib3V0IHRo
ZSBnZW5lcmFsIGNhc2UgaGVyZT8NCj4gPiA+ID4NCj4gPiA+ID4gQmFsYXpzPiBXYXMgaXQgc28/
IEkgc2F3IGFuIEEgYW5kIEIgbW9kZWwsIEEgY29udGFpbmluZw0KPiA+ID4gPiBtdXN0ICIoYWxn
b3JpdGhtIGFuZCBwdWJsaWMta2V5IGFuZCBwcml2YXRlLWtleSkNCj4gPiA+ID4gICAgICAgICAg
ICAgIG9yIG5vdCAoYWxnb3JpdGhtIG9yIHB1YmxpYy1rZXkgb3IgcHJpdmF0ZS1rZXkpIjsgYW5k
IEINCj4gPiA+ID4gY29udGFpbmluZyB0aGUga2V5cyBhbmQgdGhlIGNlcnRpZmljYXRlcyBpbiBz
ZXBhcmF0ZSBjb250YWluZXIsIGFuZA0KPiA+ID4gPiBhIG5vdGUgIkkgdGhpbmsgbW9kZWwgQiBp
cyBjbGVhbmVyIi4NCj4gPiA+DQo+ID4gPiBSaWdodCwgYnV0IGlmIHlvdSBzY3JvbGwgdXAgaGln
aGVyLCBJIGhhZCBwcmV2aW91c2x5IGhhZCBhbiAoYSkgYW5kDQo+ID4gPiAoYikgW25vdGUgbG93
ZXJjYXNlXSB0byB3aGljaCBoZSBzYWlkIChiKSB3YXMgImJldHRlciIuICBNYXliZSBpdCdzDQo+
ID4gPiBtb290LCBzaW5jZSBoaXMgKEEpIHdhcyBlZmZlY3RpdmVseSBteSAoYikuDQo+ID4gDQo+
ID4gSGVyZSdzIHRoZSBuZXcgYWx0ZXJuYXRpdmU6DQo+ID4gDQo+ID4gKEMpDQo+ID4gDQo+ID4g
ICBjb250YWluZXIga2V5c3RvcmUgew0KPiA+ICAgICBjb250YWluZXIgYXN5bW1ldHJpYy1rZXlz
IHsNCj4gPiAgICAgICBsaXN0IGFzeW1tZXRyaWMta2V5IHsNCj4gPiAgICAgICAgIGtleSBuYW1l
Ow0KPiA+IA0KPiA+ICAgICAgICAgbGVhZiBuYW1lIHsgLi4uIH0NCj4gPiAgICAgICAgIGxlYWYg
YWxnb3JpdGhtIHsgbWFuZGF0b3J5IHRydWU7IC4uLiB9DQo+ID4gDQo+ID4gICAgICAgICBsZWFm
IHB1YmxpYy1rZXkgeyAuLi4gfQ0KPiA+ICAgICAgICAgbGVhZiBwcml2YXRlLWtleSB7IC4uLiB9
DQo+ID4gDQo+ID4gICAgICAgICAvLyBlbnN1cmUgdGhhdCBib3RoIG9yIG5vbmUgYXJlIGdpdmVu
DQo+ID4gICAgICAgICBtdXN0ICIocHVibGljLWtleSBhbmQgcHJpdmF0ZS1rZXkpDQo+ID4gICAg
ICAgICAgICAgICBvciBub3QgKHB1YmxpYy1rZXkgb3IgcHJpdmF0ZS1rZXkpIjsNCj4gPiANCj4g
PiAgICAgICAgIGFjdGlvbiBnZW5lcmF0ZS1oaWRkZW4ta2V5IHsgLy8gbm8gaW5wdXQgcGFyYW1z
IH0NCj4gPiANCj4gPiAgICAgICAgIGNvbnRhaW5lciBjZXJ0aWZpY2F0ZXMgew0KPiA+ICAgICAg
ICAgICBsaXN0IGNlcnRpZmljYXRlIHsgLi4uIH0NCj4gPiAgICAgICAgIH0NCj4gPiAgICAgfQ0K
PiA+ICAgfQ0KPiA+IA0KPiA+IEEgcG9zc2libGUgZXh0ZW5zaW9uIHRvIHRoaXMgd291bGQgYmUg
dG8gYWRkIGFub3RlciBhY3Rpb24gbmV4dCB0bw0KPiA+ICJnZW5lcmF0ZS1oaWRkZW4ta2V5IjoN
Cj4gPiANCj4gPiAgICBhY3Rpb24gaW5zdGFsbC1oaWRkZW4ta2V5IHsNCj4gPiAgICAgICBsZWFm
IHB1YmxpYy1rZXkgeyAuLi4gfQ0KPiA+ICAgICAgIGxlYWYgcHJpdmF0ZS1rZXkgeyAuLi4gfQ0K
PiA+ICAgIH0NCj4gPiANCj4gPiANCj4gPiBPbmUgY2FzZSB0byBjb25zaWRlciBpcyB0aGF0IHRo
ZXJlIG1heSBleGlzdCBhbiBlbnRyeSBpbiA8aW50ZW5kZWQ+IHRoYXQgaGFzDQo+ID4gYmVlbiBj
b25maWd1cmVkIGJ1dCBubyBoaWRkZW4ga2V5IGhhcyB5ZXQgYmVlbiBnZW5lcmF0ZWQuDQo+ID4g
U3VjaCBhbiBlbnRyeSB3b3VsZCB0aGVuIG5vdCBleGlzdCBpbiA8b3BlcmF0aW9uYWw+LCBhbmQg
dGhlIGFjdGlvbg0KPiA+ICJnZW5lcmF0ZS1jZXJ0aWZpY2F0ZS1zaWduaW5nLXJlcXVlc3QiIHdv
dWxkIGZhaWwuDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gL21hcnRpbg0KPiANCj4gDQo=


From nobody Tue Sep 11 00:58:45 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37F4126DBF for ; Tue, 11 Sep 2018 00:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.331
X-Spam-Level: 
X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 header.b=bXZIuf8t; dkim=pass (1024-bit key) header.d=ericsson.com header.b=W9aXzrdS
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4xPD_-w0Q4F for ; Tue, 11 Sep 2018 00:58:41 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F614130E65 for ; Tue, 11 Sep 2018 00:58:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536652718; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2GjyY5LLAMucfgxxxW3f9wiKexP6pZ6FD+dwj/Vu438=; b=bXZIuf8twlJCKqGSkqN0TjiRgf6buxUDol3hk0RfU7zw6aw5E9gd84qpqgxQbFWN 7RaPBLU69FoW3ls/La0RkOyr4CDaJf2aCfBNMvF0YdWTUMj3+IfwBhGxi+rOXFoU /Ywb5eKrABVGZMH4pQXmxR8EvxZAZWJM2ecrw9FsT0w=;
X-AuditID: c1b4fb3a-2f5ff70000007a64-38-5b9775ae8213
Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5B.63.31332.EA5779B5; Tue, 11 Sep 2018 09:58:38 +0200 (CEST)
Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 11 Sep 2018 09:58:38 +0200
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 11 Sep 2018 09:58:38 +0200
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=2GjyY5LLAMucfgxxxW3f9wiKexP6pZ6FD+dwj/Vu438=; b=W9aXzrdSPxzCAwbNTMuCzBB++9ygHBHIKQJFKdrEfaT0UbTxrRvY9pBgfWW7jap8/8FOvDwl+2ksAdlcjrTXq3JgbS0RaKTiwjfiH66gNEOzhC0jVT72BJKnr1zPQQdyHw8k1YARIBZyuc46PQzlOSZAWb7wsmWhf4N9nYJ0gHI=
Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com (10.167.209.150) by VI1PR0701MB2622.eurprd07.prod.outlook.com (10.173.78.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.11; Tue, 11 Sep 2018 07:58:37 +0000
Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::bd7a:c3c7:f6f1:4e9]) by VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::bd7a:c3c7:f6f1:4e9%4]) with mapi id 15.20.1143.010; Tue, 11 Sep 2018 07:58:36 +0000
From: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= 
To: Martin Bjorklund , "kwatsen@juniper.net" 
CC: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netconf@ietf.org" 
Thread-Topic: [Netconf] Mandatory local configuration in Keystore groupings
Thread-Index: AQHUE4npYduSZhsf/U2Th8xceQbCUaSAzHaAgEmH34CAAG1ZgIAA+nAAgAPuH4CAA+yKAIABAxSAgAB6cACAAHFXIIAAWSCAgADMp9CAAnp9gIAFkemAgAFwH/CACoYJAIAAdAkAgAAAVuA=
Date: Tue, 11 Sep 2018 07:58:36 +0000
Message-ID: 
References: <20180903.121823.1406711858636851159.mbj@tail-f.com>  <185C7E6D-7EF1-4FFE-9A9B-74BA7E16D946@juniper.net> <20180911.095334.2041631968993039535.mbj@tail-f.com>
In-Reply-To: <20180911.095334.2041631968993039535.mbj@tail-f.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-microsoft-exchange-diagnostics: 1; VI1PR0701MB2622; 6:LnQsLp7j1xzUWP35hy0hen/GEWKBtNtnowqETih50O55xttEdZxZvipdSLqDAxxS7sUSbCjJxvtEyEIUw8uuxDxyiElIeKk2hYLEAKBSP+FYUwU5YPv35pXk8rcli83DiK/z55fiK2GsV2nqBEkDVX1op26McD6HbnX9aw0dBYv6awmkk8zrEeZcWrlxgWh/A7jdcmqUqYrRfr+pevUaZ3LEj1HVEyZRxl5QvkV6ta6HvLBN6vKZhnq/7sJFOVH+UyzCt1URRzz1NRtVCaS2H2RjH9cjCL8TZd+FWDLXpH6Ugq9kCqpeXijBgnqagByLAc+ZP9TcLL8FhyfVjvWV9t3R5jYRHEDusTgPsTQA+sHb8Am7HkhpFp2ZO7ql11VVCXKiWZ98jtmkYAeJJQB3lI8hEKe924uQI75mEA4H/ayJgse8RWqhqpEn6sLphnDqBmNU8SXDTU3I9SJppg6obA==; 5:NvqBOavXigkQT8y+oDHmIUfB6wStdCtbgeOPqLyUJxv+Y47uJMhxiiReaDsr+ntlG6gjQHEvysDiaWc4HHvFeSsxMC+UQ+5PLp1LIGuWLtlWxiVx89stxG0tmwKYp25U3EkfS/EifPbee4Sfq/0+aZYZcZOvnarsctN2LewjBNU=; 7:Ofa8EESVFW+lnf5n5jZF9u6jItCSBuZWlAsCd0ju1eXue4PwU94PyElrUD1yidG/iStum3Eit8VtXcabjB8TVkyDBhyv8pnE31Dj34aYjMDKpdXKUuyp6/Cdr+0BDhLAhR11FM+Wu9jNpDtZrjMVQMBE7bJAmtZncBQ1Z7Ie7qtdMeD3TtUnmHeUUcwpSsvqUheOuEFczJ3iL5e6Tuz6ttgICOLyvtPwoXFdzXtdTpawSZXBLAXLl5ngU7PrlAFD
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(136003)(346002)(39860400002)(366004)(376002)(396003)(199004)(189003)(51444003)(13464003)(81166006)(81156014)(446003)(186003)(54906003)(5250100002)(110136005)(7696005)(6506007)(6436002)(2900100001)(76176011)(53546011)(476003)(68736007)(8676002)(486006)(97736004)(53936002)(102836004)(2501003)(9686003)(11346002)(93886005)(8936002)(6116002)(99286004)(3846002)(26005)(55016002)(85202003)(14444005)(256004)(6246003)(229853002)(7736002)(33656002)(478600001)(25786009)(66066001)(14454004)(106356001)(1941001)(316002)(5660300001)(105586002)(4326008)(86362001)(85182001)(74316002)(305945005)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2622; H:VI1PR0701MB2016.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
x-ms-office365-filtering-correlation-id: e3725460-0412-438a-33d2-08d617bc60aa
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(5600074)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2622; 
x-ms-traffictypediagnostic: VI1PR0701MB2622:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(138986009662008)(248295561703944)(17755550239193); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699050); SRVR:VI1PR0701MB2622; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2622; 
x-forefront-prvs: 0792DBEAD0
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 948r2oaTs+3Lf0LJjrvVTMqGkS3h1RGdjwh1xmHV7GGXavmvpi8xzv/y2IQ/rHzWXW//TlUdjeInQ4KlPdBa2Hi8R4Lng9pVdgacZIpCxaF8AQGwsVCGGMT9C+AY+m8xqwe4Q8ixqeu/mvH3vjuhCHxOUo5F0MutEF74xFsHJXC2YBWnWuNzFHIW9cGdEQneFR8O40/Nqna1kBb6WVa/filQUDAcIPlVq1PIqjfm6DeslxndUuf5CpMKwyKL1Oq5bjS95+MSARmwYuuOqF+97dUyL8M0/6tzApDubnGr3epcmtDEzqM7kZjXFUH5JC0EcJZlC7xkrBqo98+pQcBHQ3RlpCHxhIaU6ZxA/5MCJzM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e3725460-0412-438a-33d2-08d617bc60aa
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2018 07:58:36.1600 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2622
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH+e3e7V5Hi19T82AFtQh6+EiTMI3w0R9aSA8NfGA68/rAJ7vT 1L9EQXBLG9bcXDZTV5SZuiFMfKQOIzTBR5mxCWWOyt4RmG9zuwv673PO95zzPZzfjybEKr43 nZ0vZ2T50lyJQEg2xJtLfTuKNEnH3373Dx5qpIKVyg9UsNpk44cRUQbDCi9qtmKGijKutpIX iUTh6XQmN7uYkfmfSRVm2YwGqvBpbMn06BhZjtovKRBNAw4C4+IFBRLSYvwMQVflGKVAbtvB EoKqtXBOMPBA3VdLOQISqwjQTM7yOUXLg6UXGzwusCMw3ZwnHf0CHAkTnxZ4DvbAcaBoruM7 mMA5sPx4xZl3x+egd8CGuJrzcEM5SDoGeWA9AuPIsnMREh8C+61hwsEinApdbTUU51bJA4uh 2TnVDYdD15jW2YDwbvgz1s7j3LzAam9yMmAMhv4JgmNPWFzY5HP1ydDzZY7i8hLQfrbyOd4H 001K5DADPESB/r3J1RwAzx8NEpygF4B13exyiIGRH+sCThhFsNX3zSX4wMSaTsBxAbRNaV2c C7ZxC1KhAN1/2+q234XAR6Cz159LH4DbynlK57zALhhtsJP3ENmGPFmGZfMyAwP9GFn2NZYt yPfLZ+QmtP1PhrvXQnrQ8MdwC8I0kuwQ/U7RJIn50mK2NM+CgCYkHqJen/oksShdWlrGyApS ZEW5DGtBe2hS4iWKyAhOFONMqZzJYZhCRvZP5dFu3uUoUlATX9GZ8XBjhqm3yWsDqzJiTFdP lbgdVjSo+3xDxwOjJ08ciy2+/rVi9krygFndqlpv27u50J9ZnVB3tsvcOXfH85W+Wp/2+tfP qSdlD9LFIT13mzWtU9a04YT7uCWB1F7eKfeMPrl6ML5lfaux+03S/nfGjlD3iJdBPmHiuH4J yWZJA44SMlb6Fx+OjiwjAwAA
Archived-At: 
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Sep 2018 07:58:44 -0000

SGkgS2VudCBhbmQgTWFydGluLA0KDQpJIGFncmVlIHdpdGggdGhlIGNvbW1lbnRzIG9mIE1hcnRp
bi4gSWYgeW91IGxvb2sgYXQgdGhlIHdob2xlIHVzZSBjYXNlIG9mIGtleSBhbmQgY2VydGlmaWNh
dGUgcHJvdmlzaW9uaW5nLCAoQykgaXMgc2ltcGxlciBmb3IgYm90aCBjcmVhdGlvbiBhbmQgcmVt
b3ZhbC4gVGhlIGlzc3VlIG9mIGxlYWZyZWZzIGFkZHMgZXZlbiBtb3JlIG9uIHRoZSBzaWRlIG9m
IChDKS4NCg0KQnIsDQpCYWxhenMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiANClNlbnQ6IFR1ZXNkYXksIFNlcHRl
bWJlciAxMSwgMjAxOCA5OjU0IEFNDQpUbzoga3dhdHNlbkBqdW5pcGVyLm5ldA0KQ2M6IEJhbMOh
enMgS292w6FjcyA8YmFsYXpzLmtvdmFjc0Blcmljc3Nvbi5jb20+OyBCYWzDoXpzIExlbmd5ZWwg
PGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbT47IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6
IFJlOiBbTmV0Y29uZl0gTWFuZGF0b3J5IGxvY2FsIGNvbmZpZ3VyYXRpb24gaW4gS2V5c3RvcmUg
Z3JvdXBpbmdzDQoNCkhpLCAgICAgICAgDQoNCktlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIu
bmV0PiB3cm90ZToNCj4gDQo+IFRoZXJlIGFyZSB0d28gc29sdXRpb25zIGJlaW5nIGRpc2N1c3Nl
ZCBoZXJlLiAgDQo+IA0KPiBUaGUgZmlyc3QgcmVnYXJkcyBob3cgdG8gZW5hYmxlIGEgY2VydGlm
aWNhdGUgdG8gYmUgY29uZmlndXJlZCBmb3IgYSANCj4ga2V5IGluIDxvcGVyYXRpb25hbD4gKGUu
Zy4sIGFuIExEZXZJRCBjZXJ0IGZvciBhIHByZWV4aXN0aW5nIGtleSkuICANCj4gQm90aCBzb2x1
dGlvbiAoQSkgYW5kIChDKSBnaXZlIHVzIHRoaXMgLSBhIGxhIFJGQyA4MzQyIFNlY3Rpb24gQy4z
LjIuDQo+IA0KPiBUaGUgc2Vjb25kIGlzIGhvdyB0byBkZWxldGUgYSAiaGlkZGVuIGtleSIgY3Jl
YXRlZCBieSBhIGNsaWVudCAobm90ZSANCj4gaGVyZSB0aGF0IEknbSBkaXN0aW5ndWlzaGluZyB0
aGlzIGNhc2UgZnJvbSBoaWRkZW4ga2V5cyBub3QgY3JlYXRlZCBieSANCj4gYSBjbGllbnQsIGku
ZS4sIGluIDxvcGVyYXRpb25hbD4sIHdoaWNoIGNhbm5vdCBiZSBkZWxldGVkKS4gIEhlcmUncyAN
Cj4gd2hlcmUgdGhlIGlkZWFzDQo+IGRpdmVyZ2U6DQo+IA0KPiAgIC0gd2l0aCAoQSksIHdlIGtl
ZXAgdGhlICJnZW5lcmF0ZSIgYWN0aW9uIG91dHNpZGUgdGhlIGxpc3QgZW50cnkgKHRodXMNCj4g
ICAgIHJlc3VsdHMgYXJlIGluIDxvcGVyYXRpb25hbD4sIGFuZCBhZGQgYSBuZXcgImRlbGV0ZS1h
c3ltbWV0cmljLWtleSINCj4gICAgIGFjdGlvbiBpcyBuZWVkZWQuDQo+IA0KPiAgIC0gd2l0aCAo
QyksIHRoZSBhY3Rpb24gaXMgbW92ZWQgaW5zaWRlIHRoZSBsaXN0IGVudHJ5LCB0aHVzIHRoZSBs
aXN0DQo+ICAgICBlbnRyeSBub2RlIGl0c2VsZiBpbiA8aW50ZW5kZWQ+LCBhbmQgaGVuY2UgY2Fu
IGJlIHJlbW92ZWQgZnJvbQ0KPiAgICAgPGludGVuZGVkPiB2aWEgYSBub3JtYWwgY29uZmlnIG9w
ZXJhdGlvbiAobm8gc3BlY2lhbCBhY3Rpb24gbmVlZGVkKS4NCj4gDQo+IEkgZG9uJ3Qgc2VlIGFu
IGlzc3VlIGNvbmZpZ3VyaW5nIGNlcnRpZmljYXRlcyBpbiBlaXRoZXIgY2FzZS4gIEFzIEkgDQo+
IHdyb3RlIGFib3ZlLCBib3RoIHNvbHV0aW9uIChBKSBhbmQgKEMpIGdpdmUgdXMgdGhpcy4gKEMp
IHN0aWxsIGhhcyB0byANCj4gaGFuZGxlIHRoZSBjYXNlIHdoZXJlIHRoZSBrZXkgaXMgaW4gPG9w
ZXJhdGlvbmFsPiBzYW1lIGFzIChBKS4gIFdpdGggDQo+IChDKSwgaXQncyB0aGUgMSUgY2FzZSwg
d2hlcmVhcyB3aXRoIChBKSBpdOKAmXMgdGhlIDEwMCUgY2FzZS4NCg0KSG93IGNhbiBhIGtleSBi
ZSBpbiBvcGVyYXRpb25hbCBidXQgbm90IGluIGNvbmZpZyBpbiAoQyk/ICBJLmUuLCB3aGF0IGlz
IHRoZSAxJSBjYXNlPw0KDQo+IFRoZXkgc2VlbSBjbG9zZS4gIEZvciB0aGUgcHVycG9zZSBvZiBj
cmVhdGluZyBhIGtleSwgKEMpIGlzIG1vcmUgDQo+IGNvbXBsaWNhdGVkLiAgRm9yIHRoZSBwdXJw
b3NlIG9mIGRlbGV0aW5nIGEga2V5LCAoQykgc2VlbXMgZWFzaWVyLg0KDQpGb3IgdGhlIHB1cnBv
c2Ugb2YgY3JlYXRpbmcgYSBjZXJ0aWZpY2F0ZSAoQSkgaXMgbW9yZSBjb21wbGljYXRlZC4NCg0K
RGVwZW5kaW5nIG9uIHRoZSBhbnN3ZXIgYWJvdmUsIChDKSBoYXMgdGhlIGFkdmFudGFnZSB0aGF0
IHJlZmVyZW5jZXMNCihsZWFmcmVmcykgdG8gYSBrZXkgY2FuIGJlIHJlcXVpcmUgaW5zdGFuY2Ug
dHJ1ZS4gIFdpdGggKEEpIHRoZXkgaGF2ZSB0byBiZSByZXF1aXJlIGluc3RhbmNlIGZhbHNlLCBz
aW5jZSBzb21lIGtleXMgb25seSBleGlzdHMgaW4gb3BlcmF0aW9uYWwsIHdoaWNoIG1lYW5zIHRo
YXQgd2hlbmV2ZXIgdGhlcmUgaXMgYSByZWZlcmVuY2UgdG8gYSBrZXksIHRoYXQgbW9kZWwgYW5k
IGNvZGUgbXVzdCBiZSBhYmxlIHRvIGhhbmRsZSB0aGUgY2FzZSB0aGF0IHRoZSBrZXkgZG9lc24n
dCBleGlzdC4NCg0KDQoNCg0KDQovbWFydGluDQoNCg0KPiANCj4gSWYgdGhlIGFjdGlvbiBpcyBi
cm91Z2h0IGluc2lkZSB0aGUgbGlzdCBlbnRyeSwgdGhlbiByZW5hbWluZyBpdCB0byANCj4gImdl
bmVyYXRlLWhpZGRlbi1rZXkiIG1ha2VzIHNlbnNlLg0KPiANCj4gS2VudCAvLyBjb250cmlidXRv
cg0KPiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiANCj4gSGkgTWFy
dGluLA0KPiANCj4gSSBwcmVmZXIgeW91ciBhbHRlcm5hdGl2ZSAoQykgd2l0aCBzb21lIGNvbW1l
bnRzLg0KPiANCj4gSSdkIGtlZXAgdGhlIG5hbWUgb2YgdGhlIGFjdGlvbiBhcyAnZ2VuZXJhdGUt
YXN5bW1ldHJpYy1rZXknLiBJIHRoaW5rIHRoZSB3b3JkICdhc3ltbWV0cmljJyBnaXZlcyBhIGhp
bnQgb24gaXRzIGludGVuZGVkIHVzZSBjYXNlLCBzbyBpdCBpcyBpbXBvcnRhbnQgKHRob3VnaCBp
dCBpcyBhbHJlYWR5IGluIGFuIGFzeW1tZXRyaWMta2V5IGxpc3QpLiBUaGUgd29yZCAnaGlkZGVu
JyBpcyBub3QgdGhhdCBpbXBvcnRhbnQgZm9yIG1lIHNpbmNlIHRoZSBhY3Rpb24gaW4gaXRzZWxm
IGhpbnRzIHRoYXQgdGhlIGtleSBpbiB0aGlzIGNhc2UgaXMgbm90IHByb3ZpZGVkIGJ5IHRoZSBv
cGVyYXRvciwgdGh1cyBpdHMgYmluYXJ5IHZhbHVlIHdvbid0IGFwcGVhciBlaXRoZXIuIElmIG9w
ZXJhdG9yIG5lZWRzIHRvIHByb3ZpZGUgaXQsIGl0IGhhcyB0byBnbyB2aWEgdGhlICdwcml2YXRl
LWtleScgbGVhZi4gT3IgdGhlIGFjdGlvbiBjb3VsZCBiZSBqdXN0IGNhbGxlZCAnZ2VuZXJhdGUt
a2V5Jy4NCj4gDQo+IEEgcXVlc3Rpb24gc3RpbGw6IGl0IGlzIHVuY2xlYXIgdG8gbWUgd2hhdCB0
aGUgZGlmZmVyZW5jZSBpcyBiZXR3ZWVuIGNhbGxpbmcgdGhlIGFjdGlvbiB2cyBqdXN0IGNvbmZp
Z3VyaW5nIHRoZSAncHJpdmF0ZS1rZXknIHRvIGVudW0gJ2hpZGRlbicuDQo+IA0KPiBCciwNCj4g
QmFsYXpzDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206
IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPg0KPiA+IFNlbnQ6IE1vbmRheSwgU2Vw
dGVtYmVyIDMsIDIwMTggMTI6MTggUE0NCj4gPiBUbzoga3dhdHNlbkBqdW5pcGVyLm5ldA0KPiA+
IENjOiBCYWzDoXpzIEtvdsOhY3MgPGJhbGF6cy5rb3ZhY3NAZXJpY3Nzb24uY29tPjsgQmFsw6F6
cyBMZW5neWVsIA0KPiA+IDxiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+OyBuZXRjb25mQGll
dGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBNYW5kYXRvcnkgbG9jYWwgY29uZmln
dXJhdGlvbiBpbiBLZXlzdG9yZSANCj4gPiBncm91cGluZ3MNCj4gPiANCj4gPiBLZW50IFdhdHNl
biA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+ID4gPiA+IEJhbGF6cz4gVGhlIGNlcnRp
ZmljYXRlcyBpbiBrZXlzdG9yZSBhcmUgdXNlbGVzcyB3aXRob3V0IGEgDQo+ID4gPiA+IEJhbGF6
cz4gY29ycmVzcG9uZGluZw0KPiA+ID4gPiBwcml2YXRlIGtleSwgc28gY2VydGlmaWNhdGVzIG9m
IGEga2V5IGNhbm5vdCBiZSBpbiB0aGUgDQo+ID4gPiA+IGNvbmZpZ3VyYXRpb24gdHJlZSBvbmNl
IHRoZSBjb3JyZXNwb25kaW5nIGtleSBpcyByZW1vdmVkLiBCeSB0aGUgDQo+ID4gPiA+IHdheSwg
aG93IHdvdWxkIGEgcHJpdmF0ZSBrZXkgYmUgcmVtb3ZlZCBmcm9tIDxvcGVyYXRpb25hbD4gaWYg
aXQgDQo+ID4gPiA+IGRvZXMgbm90IGV4aXN0IGluIGNvbmZpZ3VyYXRpb24/IElmIHlvdSBkbyBp
dCB3aXRoIGFuIGFjdGlvbiANCj4gPiA+ID4gdG9vLCBob3cgd291bGQgdGhlIGNvcnJlc3BvbmRp
bmcgY2VydGlmaWNhdGVzIGJlIHJlbW92ZWQgZnJvbSB0aGUgY29uZmlndXJhdGlvbj8NCj4gPiA+
DQo+ID4gPiBHb29kIHBvaW50cy4NCj4gPiANCj4gPiBZZXMuICBUaGUgbGlmZWN5Y2xlIG9mIGtl
eXMgYXJlIG5vdCBoYW5kbGVkIGZ1bGx5IGluIHRoZSBjdXJyZW50IA0KPiA+IGRyYWZ0LiAgQnV0
IEkgdGhpbmsgdGhhdCBpZiB0aGlzIGlzIGRvbmUgcHJvcGVybHksIHNlcGFyYXRpbmcgdGhlIA0K
PiA+IGNvbmZpZyBvZiBrZXlzIGFuZCBjZXJ0aWZpY2F0ZXMgd291bGQgbm90IGNoYW5nZSB0aGUg
bGlmZWN5Y2xlIG9mIA0KPiA+IGhvdyBrZXlzLiAgU28gbGV0J3MgZmlyc3QgZGlzY3VzcyBob3cg
d2Ugd2FudCB0byBoYW5kbGUgY3JlYXRpb24gYW5kIA0KPiA+IHJlbW92YWwgb2YgdGhlIGhpZGRl
biBrZXlzIChjb25maWd1cmVkIGtleXMgYXJlIG5vdCBhIHByb2JsZW0pLg0KPiA+IA0KPiA+IFdp
dGggdGhlIGN1cnJlbnQgZHJhZnQsIGEgaGlkZGVuIGtleSBpcyBjcmVhdGVkIGluIDxvcGVyYXRp
b24+IHdpdGggDQo+ID4gYW4gYWN0aW9uIGFuZCBtYXkgbm90IGJlIHByZXNlbnQgaW4gPHJ1bm5p
bmc+IGFuZCA8aW50ZW5kZWQ+LiAgVGhlcmUgDQo+ID4gaXMgbm8gd2F5IHRvIGRlbGV0ZSBzdWNo
IGEga2V5LiAgV2Ugd291bGQgaGF2ZSB0byBjcmVhdGUgYSBuZXcgYWN0aW9uIHRvIHJlbW92ZSBp
dC4NCj4gPiANCj4gPiBBbiBhbHRlcm5hdGl2ZSBkZXNpZ24gY291bGQgYmUgdG8gbW92ZSB0aGUg
YWN0aW9uIA0KPiA+ICJnZW5lcmF0ZS1hc3ltbWV0cmljLSBrZXkiIGludG8gdGhlICJhc3ltbWV0
cmljLWtleSIgbGlzdCAoYW5kIG1heWJlIA0KPiA+IHJlbmFtZSBpdCB0byAiZ2VuZXJhdGUtIGhp
ZGRlbi1rZXkiKS4gIEEgY2xpZW50IHdvdWxkIHRoZW4gZmlyc3QgDQo+ID4gaGF2ZSB0byBjb25m
aWd1cmUgYW4gZW50cnkgaW4gdGhlICJhc3ltbWV0cmljLWtleSIgbGlzdCwgYW5kIHRoZW4gaXQg
DQo+ID4gY2FuIGdlbmVyYXRlIHRoZSBoaWRkZW4ga2V5LiAgSWYgdGhlIGFzeW1tZXRyaWMta2V5
IGxpc3QgZW50cnkgaXMgDQo+ID4gcmVtb3ZlZCBmcm9tIDxpbnRlbmRlZD4sIHRoZW4gcHJlc3Vt
YWJseSB0aGUgY29ycmVzcG9uZGluZyBoaWRkZW4ga2V5IGlzIHJlbW92ZWQgYXMgd2VsbC4NCj4g
PiANCj4gPiBXaXRoIHRoaXMgZGVzaWduLCBhIHNlcGFyYXRlICJjZXJ0aWZpY2F0ZSIgbGlzdCBj
b3VsZCBoYXZlIG5vcm1hbCANCj4gPiBsZWFmcmVmIChyZXF1aXJlLWluc3RhbmNlIHRydWUpIGlu
dG8gdGhlICJhc3ltbWV0cmljLWtleSIgbGlzdC4NCj4gPiBIb3dldmVyLCB3aXRoIHRoaXMgbmV3
IGRlc2lnbiBteSBvcmlnaW5hbCBpc3N1ZSB3aXRoIGhvdyANCj4gPiBjZXJ0aWZpY2F0ZXMgYXJl
IGhhbmRsZWQgZ29lcyBhd2F5LCBzbyBoYXZpbmcgdGhlbSBjb250YWluZWQgaW4gdGhlIA0KPiA+
ICJhc3ltbWV0cmljLWtleSIgbGlzdCB3b3JrcyBmaW5lLg0KPiA+IA0KPiA+ID4gPj4gTWFydGlu
IG1ha2VzIGEgY2FzZSBmb3IgJ0InLCBidXQgaGUgYWxzbyBzYWlkIHRoYXQgbXkgJ2InIHdhcyAN
Cj4gPiA+ID4+ICJCZXR0ZXIiIGJ1dCBoYXMgc2NhbGluZyBpc3N1ZXMgaW4gdGhlIGdlbmVyYWwg
Y2FzZS4gIFBlcmhhcHMgDQo+ID4gPiA+PiB3ZSBkb24ndCB3b3JyeSBhYm91dCB0aGUgZ2VuZXJh
bCBjYXNlIGhlcmU/DQo+ID4gPiA+DQo+ID4gPiA+IEJhbGF6cz4gV2FzIGl0IHNvPyBJIHNhdyBh
biBBIGFuZCBCIG1vZGVsLCBBIGNvbnRhaW5pbmcNCj4gPiA+ID4gbXVzdCAiKGFsZ29yaXRobSBh
bmQgcHVibGljLWtleSBhbmQgcHJpdmF0ZS1rZXkpDQo+ID4gPiA+ICAgICAgICAgICAgICBvciBu
b3QgKGFsZ29yaXRobSBvciBwdWJsaWMta2V5IG9yIHByaXZhdGUta2V5KSI7IA0KPiA+ID4gPiBh
bmQgQiBjb250YWluaW5nIHRoZSBrZXlzIGFuZCB0aGUgY2VydGlmaWNhdGVzIGluIHNlcGFyYXRl
IA0KPiA+ID4gPiBjb250YWluZXIsIGFuZCBhIG5vdGUgIkkgdGhpbmsgbW9kZWwgQiBpcyBjbGVh
bmVyIi4NCj4gPiA+DQo+ID4gPiBSaWdodCwgYnV0IGlmIHlvdSBzY3JvbGwgdXAgaGlnaGVyLCBJ
IGhhZCBwcmV2aW91c2x5IGhhZCBhbiAoYSkgDQo+ID4gPiBhbmQNCj4gPiA+IChiKSBbbm90ZSBs
b3dlcmNhc2VdIHRvIHdoaWNoIGhlIHNhaWQgKGIpIHdhcyAiYmV0dGVyIi4gIE1heWJlIA0KPiA+
ID4gaXQncyBtb290LCBzaW5jZSBoaXMgKEEpIHdhcyBlZmZlY3RpdmVseSBteSAoYikuDQo+ID4g
DQo+ID4gSGVyZSdzIHRoZSBuZXcgYWx0ZXJuYXRpdmU6DQo+ID4gDQo+ID4gKEMpDQo+ID4gDQo+
ID4gICBjb250YWluZXIga2V5c3RvcmUgew0KPiA+ICAgICBjb250YWluZXIgYXN5bW1ldHJpYy1r
ZXlzIHsNCj4gPiAgICAgICBsaXN0IGFzeW1tZXRyaWMta2V5IHsNCj4gPiAgICAgICAgIGtleSBu
YW1lOw0KPiA+IA0KPiA+ICAgICAgICAgbGVhZiBuYW1lIHsgLi4uIH0NCj4gPiAgICAgICAgIGxl
YWYgYWxnb3JpdGhtIHsgbWFuZGF0b3J5IHRydWU7IC4uLiB9DQo+ID4gDQo+ID4gICAgICAgICBs
ZWFmIHB1YmxpYy1rZXkgeyAuLi4gfQ0KPiA+ICAgICAgICAgbGVhZiBwcml2YXRlLWtleSB7IC4u
LiB9DQo+ID4gDQo+ID4gICAgICAgICAvLyBlbnN1cmUgdGhhdCBib3RoIG9yIG5vbmUgYXJlIGdp
dmVuDQo+ID4gICAgICAgICBtdXN0ICIocHVibGljLWtleSBhbmQgcHJpdmF0ZS1rZXkpDQo+ID4g
ICAgICAgICAgICAgICBvciBub3QgKHB1YmxpYy1rZXkgb3IgcHJpdmF0ZS1rZXkpIjsNCj4gPiAN
Cj4gPiAgICAgICAgIGFjdGlvbiBnZW5lcmF0ZS1oaWRkZW4ta2V5IHsgLy8gbm8gaW5wdXQgcGFy
YW1zIH0NCj4gPiANCj4gPiAgICAgICAgIGNvbnRhaW5lciBjZXJ0aWZpY2F0ZXMgew0KPiA+ICAg
ICAgICAgICBsaXN0IGNlcnRpZmljYXRlIHsgLi4uIH0NCj4gPiAgICAgICAgIH0NCj4gPiAgICAg
fQ0KPiA+ICAgfQ0KPiA+IA0KPiA+IEEgcG9zc2libGUgZXh0ZW5zaW9uIHRvIHRoaXMgd291bGQg
YmUgdG8gYWRkIGFub3RlciBhY3Rpb24gbmV4dCB0bw0KPiA+ICJnZW5lcmF0ZS1oaWRkZW4ta2V5
IjoNCj4gPiANCj4gPiAgICBhY3Rpb24gaW5zdGFsbC1oaWRkZW4ta2V5IHsNCj4gPiAgICAgICBs
ZWFmIHB1YmxpYy1rZXkgeyAuLi4gfQ0KPiA+ICAgICAgIGxlYWYgcHJpdmF0ZS1rZXkgeyAuLi4g
fQ0KPiA+ICAgIH0NCj4gPiANCj4gPiANCj4gPiBPbmUgY2FzZSB0byBjb25zaWRlciBpcyB0aGF0
IHRoZXJlIG1heSBleGlzdCBhbiBlbnRyeSBpbiA8aW50ZW5kZWQ+IA0KPiA+IHRoYXQgaGFzIGJl
ZW4gY29uZmlndXJlZCBidXQgbm8gaGlkZGVuIGtleSBoYXMgeWV0IGJlZW4gZ2VuZXJhdGVkLg0K
PiA+IFN1Y2ggYW4gZW50cnkgd291bGQgdGhlbiBub3QgZXhpc3QgaW4gPG9wZXJhdGlvbmFsPiwg
YW5kIHRoZSBhY3Rpb24gDQo+ID4gImdlbmVyYXRlLWNlcnRpZmljYXRlLXNpZ25pbmctcmVxdWVz
dCIgd291bGQgZmFpbC4NCj4gPiANCj4gPiANCj4gPiANCj4gPiAvbWFydGluDQo+IA0KPiANCg==


From nobody Tue Sep 11 02:13:44 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F396130E8F for ; Tue, 11 Sep 2018 02:13:42 -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 CrMVlfVgk1pU for ; Tue, 11 Sep 2018 02:13:39 -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 9F326130E5C for ; Tue, 11 Sep 2018 02:13:39 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C0B326D5B284F for ; Tue, 11 Sep 2018 10:13:34 +0100 (IST)
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 11 Sep 2018 10:13:36 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.7]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0399.000; Tue, 11 Sep 2018 17:13:23 +0800
From: Rohit R Ranade 
To: Alexander Clemm , "netconf@ietf.org" 
Thread-Topic: [Netconf] Comments on Yang-push-18 //RE: I-D Action: draft-ietf-netconf-yang-push-18.txt
Thread-Index: AQHURLV8jIgnhgVF1EWHjzKvGxWUnqTq0XIQ
Date: Tue, 11 Sep 2018 09:13:23 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BC31BD4@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BC192DD@dggeml530-mbs.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5C6FA@sjceml521-mbs.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5C6FA@sjceml521-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] Comments on Yang-push-18 //RE: I-D Action: draft-ietf-netconf-yang-push-18.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Sep 2018 09:13:42 -0000

Hi Alex,

I agree with your replies for most of the comments and those comments have =
been removed in the text blow. Some comments which I feel need more discuss=
ion are kept below.

> 4. Section 3.5.2
>    "To support this, it is valid to encode a YANG patch operation so=20
> that its application would result
>    in no change between the previous and current state.  This indicates
>    that some churn has occurred on the object.  An example of this would
>    be a patch that does a "create" operation for a datastore node where
>    the receiver believes one already exists, or a "replace" operation
>    which replaces a previous value with the same value."
>=20
>     Some points here need more clarification.
>     a. If there is no change, but only a churn then why is it=20
> important to send this object in a YANG push ? What is the benefit ?

It indicates the fact that churn has occurred.  Basically, it allows =
a client to recognize that the value has not been static/unchanged, but did=
 undergo some kind of oscillation.  The benefits to only indicate the last =
change is per the dampening period (reduce bandwidth and CPU). =20


[Rohit]: I am still not clear which scenario this is trying to solve. Some =
devices maybe track only the differences and don't want to handle this spec=
ial scenario. Such devices may not want to implement this feature.

>     b. If there was a "create" and "delete" on object X, within a=20
> dampening period, then what will be the patch record operation ?


We would send a delete.  (even if the object did not exist originally).  We=
 should indicate this actually.  Adding the following to the same item:=20
" In case the changes involve creating a new datastore node, then deleting =
it, the YANG patch record will indicate deletion of the datastore node.  Si=
milarly, in case the changes involve deleting a new datastore node, then re=
creating it, the YANG patch record will indicate creation of the datastore =
node."


[Rohit] : Why would the client be interested in a "delete" of a record X, w=
hen such a record X did not exist in its previous sync ?=20

> 12. Section 3.9
>   "If read access into previously accessible nodes has been lost due to
>    a receiver permissions change, this SHOULD be reported as a patch
>    "delete" operation for on-change subscriptions."
>   I think we should not have such mechanisms. If a user does not have=20
> access, we should not try to evaluate what was the last update sent
>   to such user, and how to send a subsequent patch which will=20
> stabilize the user's DB due to the access-control changes.
>=20

 I can see your point; that said I think one can argue to keep things=
 as-is.  When a receiver can no longer access a datastore node, the node ha=
s effectively "disappeared" to the receiver.  By keeping it, the receiver w=
ill be under the illusion of no change even when the value does change.  Th=
is might cause a receiver to "not trust" a subscription any more and start =
polling, which is something we would absolutely want to avoid.  So, I prefe=
r to keep things as they are.   Alternatively, an implementation may always=
 delete the subscription / force subscription reestablishment. =20
--- Alex


[Rohit] " receiver will be under the illusion of no change even when the va=
lue does change."  Since the receiver has no permission, the receiver will =
not know that indeed there was a change in value. So if the receiver alread=
y had got the record on a path in its previous sync, if now the NACM rules =
got applied, the receiver will never receive any other update on that path,=
 which would have been the purpose of adding the NACM rules.


With Regards,
Rohit R Ranade

-----Original Message-----
From: Alexander Clemm=20
Sent: 05 September 2018 06:42
To: Rohit R Ranade ; netconf@ietf.org
Subject: RE: [Netconf] Comments on Yang-push-18 //RE: I-D Action: draft-iet=
f-netconf-yang-push-18.txt

Hi Rohit,=20

thank you for the comments!  I am in the process of incorporating them into=
 -19, which I hope to post by Thursday.

Replies to your items inline.

--- Alex

> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Rohit R=20
> Ranade
> Sent: Tuesday, August 28, 2018 10:01 PM
> To: netconf@ietf.org
> Subject: [Netconf] Comments on Yang-push-18 //RE: I-D Action:=20
> draft-ietf- netconf-yang-push-18.txt
>=20
> Hi All,
>=20
>=20
> 1. In Section 3.3
>   The whole para from "To avoid flooding receivers .. the last change=20
> will still be sent." looks like a repetition
>   of Section 3.1 , description of "Dampening period"
>=20

 3.1 describes the model, while 3.3 discusses the considerations behi=
nd it and provides additional explanation.  While the explanation may be re=
dundant, we felt it is still useful to explain the rational.  Hence we woul=
d like to keep it. =20


> 2. Section 3.3, Point 4
>   "insert into the YANG patch record the last change made for any=20
> object which otherwise wouldn't have appeared."
>    I am not able to understand this statement clearly. Can this=20
> statement be simplified ?


Rephrasing it as follows: " insert into the YANG patch record the last chan=
ge made, even if the new value is no different from the original value (sin=
ce changes that were made in the interim were canceled out)."


>=20
> 3. Section 3.5.2
>   The para "A publisher will indicate a change to the effect ... this by =
a
>    "move" operation."
>    This is already defined in the YANG Patch RFC right ? What is the=20
> need to define this again in this RFC ?

 The patch is generated by the publisher, not by the client.  In that=
 sense, we use it a bit different from RFC 8072.  We thought it will be use=
ful in the interest of greater clarity to explain it.  So, while it would b=
e possible to editorially tighten, again we would like to keep it. =20

>=20
> 4. Section 3.5.2
>    "To support this, it is valid to encode a YANG patch operation so=20
> that its application would result
>    in no change between the previous and current state.  This indicates
>    that some churn has occurred on the object.  An example of this would
>    be a patch that does a "create" operation for a datastore node where
>    the receiver believes one already exists, or a "replace" operation
>    which replaces a previous value with the same value."
>=20
>     Some points here need more clarification.
>     a. If there is no change, but only a churn then why is it=20
> important to send this object in a YANG push ? What is the benefit ?

It indicates the fact that churn has occurred.  Basically, it allows =
a client to recognize that the value has not been static/unchanged, but did=
 undergo some kind of oscillation.  The benefits to only indicate the last =
change is per the dampening period (reduce bandwidth and CPU). =20


>     b. If there was a "create" and "delete" on object X, within a=20
> dampening period, then what will be the patch record operation ?


We would send a delete.  (even if the object did not exist originally).  We=
 should indicate this actually.  Adding the following to the same item:=20
" In case the changes involve creating a new datastore node, then deleting =
it, the YANG patch record will indicate deletion of the datastore node.  Si=
milarly, in case the changes involve deleting a new datastore node, then re=
creating it, the YANG patch record will indicate creation of the datastore =
node."


>     c. s/patch that does a "create" operation /patch that indicates a "cr=
eate"
> operation  ? Patch can indicate the operation not do it.

 changed "does" do "indicates" /ALEX>

>=20
> 5. Section 3.7
>   "the counter MUST be reset to '1' the after passing a maximum value=20
> of '4294967295'"
>   s/reset to '1' the after passing/reset to '1' after passing
>=20

 changed 

> 6. Section 3.7 Figure 2: Push example for on change
>    The "yang-patch" should be under the namespace=20
> "urn:ietf:params:xml:ns:yang:ietf-yang-patch"
>=20

 changed 

> 7. In the ietf-yang-push, tree diagram
>    "
>              +--ro datastore-changes?
>                  +--ro ypatch:yang-patch
>                 +--ro patch-id        string
>    "
>     There looks to be an indentation problem for "ypatch:yang-patch"
>=20

 changed (apparently somewhere a tab character sneaked into the .xml,=
 which was not rendered correctly) 

> 8. resynch-subscription-error
>    I feel "sync" is a better abbreviation than "synch" for=20
> synchronization, because when reading this name, we may
>    not pronounce this correctly or read correctly.  I also feel=20
> "re-sync" is better when compared to "resync"
>=20

 Hmm.  This will also require to change the name of RPCs, and everywh=
ere else the term "sync(h)" is used.  I agree that while not a major item, =
this would have been a better choice, so I am applying the change throughou=
t.   =20

> 9. Section 3.9.
>    "since the last notification message was sent to a particular each rec=
eiver.".
>    s/sent to a particular each receiver/sent to a particular receiver
>=20

 changed 

>=20
> 10. Section 3.9
>   "To accomplish this, implementations SHOULD support the
>    conceptual authorization model of [RFC8341], specifically section 3.2.=
4.".
>    The link to section 3.2.4 seems to be broken as it is taking the=20
> reader to the YANG Push draft and not to NACM
>=20

 Yes indeed, I see it.  Interestingly this is autogenerated in the .h=
tml version (and only there), the XML source does not include a link.  I am=
 not sure how to change it.  Note for the RFC Editor?


> 11. Section 3.9
>   I think here "access-protected data", is used to indicate that the=20
> receiver has "no access". I think this is misleading.
>   "access-protected data" means that there are NACM rules to protect=20
> the data. Maybe we can replace it with "access-denied data" ?
>=20

 Rephrased the passages in question as follows: " A publisher MUST al=
low for the possibility that a subscription's selection filter references n=
on-existent data or data that the receiver is not allowed to access." and "=
 A publisher MAY choose to reject an establish-subscription request which s=
elects non-existent data or data that a receiver is not allowed to access. =
"  

> 12. Section 3.9
>   "If read access into previously accessible nodes has been lost due to
>    a receiver permissions change, this SHOULD be reported as a patch
>    "delete" operation for on-change subscriptions."
>   I think we should not have such mechanisms. If a user does not have=20
> access, we should not try to evaluate what was the last update sent
>   to such user, and how to send a subsequent patch which will=20
> stabilize the user's DB due to the access-control changes.
>=20

 I can see your point; that said I think one can argue to keep things=
 as-is.  When a receiver can no longer access a datastore node, the node ha=
s effectively "disappeared" to the receiver.  By keeping it, the receiver w=
ill be under the illusion of no change even when the value does change.  Th=
is might cause a receiver to "not trust" a subscription any more and start =
polling, which is something we would absolutely want to avoid.  So, I prefe=
r to keep things as they are.   Alternatively, an implementation may always=
 delete the subscription / force subscription reestablishment. =20
--- Alex


>=20
> With Regards,
> Rohit R Ranade
>=20
> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of internet-=20
> drafts@ietf.org
> Sent: 29 August 2018 06:24
> To: i-d-announce@ietf.org
> Cc: netconf@ietf.org
> Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-push-18.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Network Configuration WG of the IETF.
>=20
>         Title           : YANG Datastore Subscription
>         Authors         : Alexander Clemm
>                           Eric Voit
>                           Alberto Gonzalez Prieto
>                           Ambika Prasad Tripathy
>                           Einar Nilsen-Nygaard
>                           Andy Bierman
>                           Balazs Lengyel
> 	Filename        : draft-ietf-netconf-yang-push-18.txt
> 	Pages           : 57
> 	Date            : 2018-08-28
>=20
> 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.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netconf-yang-push-18
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push-18
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-yang-push-18
>=20
>=20
> Please note that it may take a couple of minutes from the time of=20
> submission until the htmlized version and diff are available at tools.iet=
f.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Tue Sep 11 02:34:37 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E172C130DCB for ; Tue, 11 Sep 2018 02:34: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, 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, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, 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 9t-rXNmjOZTr for ; Tue, 11 Sep 2018 02:34:32 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50134130DBE for ; Tue, 11 Sep 2018 02:34:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40001; q=dns/txt; s=iport; t=1536658471; x=1537868071; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=72VVUV1y9JdjeiW52TNoh0H8cJVl9F0LUzHlMCE0Kpk=; b=OEOrVZ2QLykycX5FuvxmUnnnuSnGwgmePfgl6PqHhT4e8Ws1mNIOFqcS wuDUxDsS5hpO17F5cNGHpb3B90QP3LsOASnA823g8U1Vy+uzJoexMlY8V rbldOsKDnj8CtAzbU9BkPrX8ahfgXQR4klhSByMNg9bc7pvujr0ZvBYQ9 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQDLipdb/xbLJq1SCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCV02CDoQaiHKNIAgllkiBZguEbAKEKDgUAQIBAQIBAQJ?= =?us-ascii?q?tKIU4AQEBAQIBIwpMBQsLFQMNEwEJAgJXBg0IAQEXgjtLgXoIpRCBLh+ETYU?= =?us-ascii?q?einyBQT+BEicMgjEuhEMRFIMXglcCiAUZKoR9gTOMQk4Jj3wGAhWBQIQ/glm?= =?us-ascii?q?GGIhJhU+FdYFZIYFVMxoIGxU7gm2QUz6OSgEB?=
X-IronPort-AV: E=Sophos;i="5.53,359,1531785600"; d="scan'208,217";a="6424645"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2018 09:34:28 +0000
Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w8B9YSaw013542; Tue, 11 Sep 2018 09:34:28 GMT
To: "Eric Voit (evoit)" 
Cc: "'Alexander Clemm'" , "netconf@ietf.org" 
References:  <9743f8e24d6f448687517c83d07db025@XCH-RTP-013.cisco.com>
From: Robert Wilton 
Message-ID: <51902072-7382-8ea9-3601-8e15bcbfe12b@cisco.com>
Date: Tue, 11 Sep 2018 10:34:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <9743f8e24d6f448687517c83d07db025@XCH-RTP-013.cisco.com>
Content-Type: multipart/alternative; boundary="------------95CCC4F3660BF4DCFA6FDD07"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [Netconf] RGW YANG push -18 LC comments [part 2]
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Sep 2018 09:34:35 -0000

This is a multi-part message in MIME format.
--------------95CCC4F3660BF4DCFA6FDD07
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Eric,

Please see inline (RW:).  Most issues are closed, just a couple that 
require further resolution.


On 10/09/2018 18:19, Eric Voit (evoit) wrote:
>
> Hi Robert,
>
> Thanks for the comments.  In-line with ....
>
> *From:*Robert Wilton, September 10, 2018 6:19 AM
>
> Hi Alex, authors,
>
> Here are my remaining comments from my WG LC review of the YANG push 
> draft.  Again, I think that these are all minor.
>
> 1. Sec 4.3.2, paragraph 2.  "resulted in a particular push" => 
> "resulted in a particular update record"?
>
>  Agree, we should make this tweak.
>
>
>
> 2. Sec 4.4.1, after Figure 7, "MAY respond" => "may respond".  This is 
> just an example from that normative behaviour.
>
>  Agree, we should make this tweak.
>
>
>
> 3. Sec 4.4.1, paragraph starting "If a request is rejected ...".  Is 
> it really right for this to be "SHOULD" rather than "MAY"?  Early text 
> (e.g. 3.2. paragraph 2 uses "may be inserted".  Also in section 4.4.2, 
> paragraph after Figure 11.
>
>  I prefer SHOULD.  Section 3.2 text had “may†instead of “MAYâ€.
>
My reading of the text in 3.2, paragraph 2, is that the error 
information is some optional, whereas section 4.4.1 strongly encourages 
it.  I think that it would be better if these two were consistent, i.e. 
if you want to keep the "SHOULD" in 4.4.1, then I think that it would be 
better if the "may" in sec 3.2 was a "should".

>
>
> 4. Sec 4.4.1, "Optionally, an "error-severity" of "error" (this MAY 
> but does not have to be included).", I don't think that the last 
> clause is required (given that it is predicated by Optionally, so 
> suggest deleting the clause in parenthesis.  Otherwise it is also 
> inconsistent with the following "error-info" description. If this 
> change, it should also be changed for "error-severity" in Sec 4.4.2.
>
>  Agree, we should make this tweak.
>
>
>
> 5. Sec 4.4.1, NETCONF specific text about errors.  Should that text 
> really be in this draft?  Would it not be nicer to keep all of the 
> NETCONF specifics to a NETCONF protocol draft?  Perhaps this is not 
> practical, but the WG is currently experiencing some pain where 
> NETCONF protocol specific normative text is in RFC 7950.  Hence, it 
> would be nice to avoid introducing that issue here if possible.  This 
> same comment also applies to Sec 4.4.2.
>
>  As this is a non-normative example, we should not hit the same 
> issue.  I do like examples for readers to digest.
>
RW:
I was meaning this text:

In the case of NETCONF
    [I-D.draft-ietf-netconf-netconf-event-notifications], when a
    subscription request is rejected, the NETCONF RPC reply MUST include
    an "rpc-error" element with the following elements:

    o  "error-type" of "application".

    o  "error-tag" of "operation-failed".

    o  Optionally, an "error-severity" of "error" (this MAY but does not
       have to be included).

    o  Optionally, "error-info" containing XML-encoded data with hints
       for parameter settings that might result in future RPC success per
       yang-data definition "establish-subscription-error-datastore".


This text includes RFC 2119 language, so a reader would surely interpret 
that text as being normative.

If your want to be non-normative then I think that you need to replace 
the "reply MUST include" statement with "reply would be expected to 
include ", and prefix the text with, "For example, in the case of 
NETCONF ..."



>
>
> 6. Sec 4.4.2, description paragraph.  Suggest the following change to 
> match the actual example: "modify the "period" of a subscription." => 
> "modify the "period" and "datastore XPath filter" of a subscription."
>
>  Agree, we should make this tweak.
>
>
>
> 7. Sec 4.4.2, first paragraph after figure 11:  Possible rewording:
>
> Old:
>
>    The publisher MUST respond explicitly positively or negatively to the
>    request.  If the subscription modification is rejected, the
>    subscription is maintained as it was before the modification request.
>    In addition, the publisher MUST send an RPC error response.  This RPC
>    error response SHOULD contain hints encapsulated within the yang-data
>    structure "modify-subscription-error-datastore".  A subscription MAY
>    be modified multiple times.
>
>
> NEW:
>
>    The publisher MUST respond to the subscription modification request.
>    If the request is rejected, the existing subscription is left 
> unchanged, and
>    the publisher MUST send an RPC error response, which MAY|SHOULD contain
>    hints encapsulated within the yang-data structure
>    "modify-subscription-error-datastore".  A subscription MAY be modified
>    multiple times.
>
>  Proposed text looks fine, with a small tweak:
>
> The publisher MUST respond to the subscription modification request. 
>  If the request is rejected, the existing subscription is left 
> unchanged, and the publisher MUST send an RPC error response.  This 
> response might have hints encapsulated within the yang-data structure 
> "modify-subscription-error-datastore".  A subscription MAY be modified 
> multiple times.
>
RW:
I think that "SHOULD" it better than "might" for consistency, as per the 
same discussion point above (which is why my original text was 
MAY|SHOULD, i.e. only a single one should be used depending on how issue 
3 above got resolved).

>
> 8. Sec 4.4.4, no figure number under the example.
>
>  Agree.  Alex, can you tweak the XML?
>
>
>
> 9. Sec 4.4.5, paragraph 1:
> I think that it would be better if this just referred to YANG library, 
> hence suggest changing the first two paragraphs:
>
> OLD:
>
>    To make subscription requests, the subscriber needs to know the YANG
>    module library available on the publisher.  The YANG 1 module library
>    information is sent by a NETCONF server in the NETCONF "hello"
>    message.  For YANG 1.1 modules and all modules used with the RESTCONF
>    [RFC8040] protocol, this information is provided by the YANG Library
>    module (ietf-yang-library.yang from [RFC7895].  This YANG library
>    information is important for the receiver to reproduce the set of
>    object definitions used within the publisher.
>    The YANG library includes a module list with the name, revision,
>    enabled features, and applied deviations for each YANG module
>    implemented by the publisher.  The receiver is expected to know the
>    YANG library information before starting a subscription.
>
>
> NEW:
>
>    To make subscription requests, the subscriber needs to know the YANG
>    datastore schemas used by the publisher, which are available via 
> the YANG
>    Library module, ietf-yang-library.yang from [RFC7895].  The receiver
>    is expected to know the YANG library information before starting a
>    subscription.
>
>  Agree, we should make this tweak.
>
>
> YANG module:
>
> 10. Top level description statement, it looks like the copyright has 
> accidentally been indented by 4 chars.
>
>  Agree, we should make this tweak.
>
>
>
> Identities:
> 11. I suggest renaming "no-such-subscription-resynch" to just 
> "no-such-subscription".  I would have thought that this error could 
> also be returned to cancel an unknown subscription.
>
>  The reason we need "no-such-subscription-resynch" is that 
> "no-such-subscription" is already used in SN.  (I.e., is not possible 
> to augment the existing identity with a new base.)
>
RW:

Hum, OK.

It is somewhat of a shame that the original error can't just be used here.

I wonder if the using multiple bases for the different subscription 
errors isn't trying to be too clever.  I.e. I wonder whether it would be 
better to just have a single base identity for subscription errors.

An alternative solution would be to define the "resync-subscription" rpc 
in the base subscribed notifications draft, and then make use of that 
RPC here.  I think that it is slightly plausible that a 
resync-subscription could still be useful in the case of a periodic 
subscription.  E.g. perhaps some client size buffers get overloaded so 
the client has to disregard the request.

But this is a minor wart, having a separate name isn't the end of the 
world.  Making "no-such-subscription-resync" also have 
"no-such-subscription" as a base might also be sensible.

>
>
> 12. "synchronization-size" doesn't sound like an error, perhaps 
> "synchronization-too-big" or "resync-too-big" might be better?
>
>  I have no problem with changing it to 
> "synchronization-too-big", that aligns to the other identity 
> "update-too-big"
>
>
>
> Type definitions:
>
>
> 13.  Change all instances (create, delete, insert, move, replace)  of 
> "data node" to "datastore node".
>
> 14. grouping selection-filter-types, anydata datastore-subtree-filter, 
> perhaps add a reference to "RFC 6241: Network Configuration Protocol, 
> Section 6.", mirroring draft-ietf-netconf-nmda-netconf.
>
> 15. grouping update-policy-modifiable, container on-change description 
> statement, needs to be indented by 2 spaces.
>
> 16. grouping hints, description, indent the second description line by 
> 1 space.
>
> 17. rpc resynch-subscription, description statement, last two lines 
> require alignment.
>
>  I think all five suggestions above are good tweaks.
>

Thanks,
Rob


> Eric
>
>
>
> Thanks,
> Rob
>


--------------95CCC4F3660BF4DCFA6FDD07
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Eric,

    
Please see inline (RW:).  Most issues are closed, just a couple
      that require further resolution.

    

    

    
On 10/09/2018 18:19, Eric Voit (evoit)
      wrote:

    

    

      
      
      
      

        
Hi
            Robert,

        
 

        
Thanks
            for the comments.  In-line with <Eric>....

        
 

        

          

            

              
From:
                  Robert Wilton, September 10, 2018 6:19 AM

                  

                  

            

          

          
Hi Alex, authors,

            

            Here are my remaining comments from my WG LC review of the
            YANG push draft.  Again, I think that these are all minor.

            

            1. Sec 4.3.2, paragraph 2.  "resulted in a particular push"
            => "resulted in a particular update record"?

          
 

          
<Eric>
              Agree, we should make this tweak.

          


            

            2. Sec 4.4.1, after Figure 7, "MAY respond" => "may
            respond".  This is just an example from that normative
            behaviour.

          
 

          
<Eric>
              Agree, we should make this tweak.

          


            

            3. Sec 4.4.1, paragraph starting "If a request is rejected
            ...".  Is it really right for this to be "SHOULD" rather
            than "MAY"?  Early text (e.g. 3.2. paragraph 2 uses "may be
            inserted".  Also in section 4.4.2, paragraph after Figure
            11.

          
 

          
<Eric>
              I prefer SHOULD.  Section 3.2 text had “may†instead of
              “MAYâ€.

        

      

    

    My reading of the text in 3.2, paragraph 2, is that the error
    information is some optional, whereas section 4.4.1 strongly
    encourages it.  I think that it would be better if these two were
    consistent, i.e. if you want to keep the "SHOULD" in 4.4.1, then I
    think that it would be better if the "may" in sec 3.2 was a
    "should".

    

    

      

        

          

          


            

            4. Sec 4.4.1, "Optionally,
                an "error-severity" of "error" (this MAY but does not
                have to be included).",
              I don't think that the last clause is required
            (given that it is predicated by Optionally, so suggest
            deleting the clause in parenthesis.  Otherwise it is also
            inconsistent with the following "error-info" description. 
            If this change, it should also be changed for
            "error-severity" in Sec 4.4.2.

          
 

          
<Eric>
              Agree, we should make this tweak.

          


            

            5. Sec 4.4.1, NETCONF specific text about errors.  Should
            that text really be in this draft?  Would it not be nicer to
            keep all of the NETCONF specifics to a NETCONF protocol
            draft?  Perhaps this is not practical, but the WG is
            currently experiencing some pain where NETCONF protocol
            specific normative text is in RFC 7950.  Hence, it would be
            nice to avoid introducing that issue here if possible.  This
            same comment also applies to Sec 4.4.2.

          
 

          
<Eric>
              As this is a non-normative example, we should not hit the
              same issue.  I do like examples for readers to digest.
            

        

      

    

    RW: 

    I was meaning this text:

    

    
In the case of NETCONF
   [I-D.draft-ietf-netconf-netconf-event-notifications], when a
   subscription request is rejected, the NETCONF RPC reply MUST include
   an "rpc-error" element with the following elements:

   o  "error-type" of "application".

   o  "error-tag" of "operation-failed".

   o  Optionally, an "error-severity" of "error" (this MAY but does not
      have to be included).

   o  Optionally, "error-info" containing XML-encoded data with hints
      for parameter settings that might result in future RPC success per
      yang-data definition "establish-subscription-error-datastore".

    

    This text includes RFC 2119 language, so a reader would surely
    interpret that text as being normative.

    

    If your want to be non-normative then I think that you need to
    replace the "reply MUST include" statement with "reply would be
    expected to include ", and prefix the text with, "For example, in
    the case of NETCONF ..."

    

    

    

    

      

        

          

          


            

            6. Sec 4.4.2, description paragraph.  Suggest the following
            change to match the actual example: "modify the "period" of a
                subscription." => "modify the "period" and
                "datastore XPath filter" of a subscription."

          
 

          
<Eric>
              Agree, we should make this tweak.

          


            

            7. Sec 4.4.2, first paragraph after figure 11:  Possible
            rewording:

            

            Old:

            

            

          

            
   The publisher MUST respond explicitly positively or negatively to the

            
   request.  If the subscription modification is rejected, the

            
   subscription is maintained as it was before the modification request.

            
   In addition, the publisher MUST send an RPC error response.  This RPC

            
   error response SHOULD contain hints encapsulated within the yang-data

            
   structure "modify-subscription-error-datastore".  A subscription MAY

            
   be modified multiple times.

          

          


            NEW:

            

            

          

            
   The publisher MUST respond to the subscription modification request.

            
   If the request is rejected, the existing subscription is left unchanged, and

            
   the publisher MUST send an RPC error response, which MAY|SHOULD contain

            
   hints encapsulated within the yang-data structure

            
   "modify-subscription-error-datastore".  A subscription MAY be modified

            
   multiple times.

          

          
 

          
<Eric>
              Proposed text looks fine, with a small tweak:

          
 

          
The
              publisher MUST respond to the subscription modification
              request.  If the request is rejected, the existing
              subscription is left unchanged, and the publisher MUST
              send an RPC error response.  This response might have
              hints encapsulated within the yang-data structure
              "modify-subscription-error-datastore".  A subscription MAY
              be modified multiple times.

          
 

        

      

    

    RW: 

    I think that "SHOULD" it better than "might" for consistency, as per
    the same discussion point above (which is why my original text was
    MAY|SHOULD, i.e. only a single one should be used depending on how
    issue 3 above got resolved).

    

    

      

        

          


            8. Sec 4.4.4, no figure number under the example.

          
 

          
<Eric>
              Agree.  Alex, can you tweak the XML?

          


            

            9. Sec 4.4.5, paragraph 1:

            I think that it would be better if this just referred to
            YANG library, hence suggest changing the first two
            paragraphs:

            

            OLD:

            

            

          

            
   To make subscription requests, the subscriber needs to know the YANG

            
   module library available on the publisher.  The YANG 1 module library

            
   information is sent by a NETCONF server in the NETCONF "hello"

            
   message.  For YANG 1.1 modules and all modules used with the RESTCONF

            
   [RFC8040] protocol, this information is provided by the YANG Library

            
   module (ietf-yang-library.yang from [RFC7895].  This YANG library

            
   information is important for the receiver to reproduce the set of

            
   object definitions used within the publisher.

            
 

            
   The YANG library includes a module list with the name, revision,

            
   enabled features, and applied deviations for each YANG module

            
   implemented by the publisher.  The receiver is expected to know the

            
   YANG library information before starting a subscription.

          

          


            NEW:

            

            

          

            
   To make subscription requests, the subscriber needs to know the YANG

            
   datastore schemas used by the publisher, which are available via the YANG

            
   Library module, ietf-yang-library.yang from [RFC7895].  The receiver

            
   is expected to know the YANG library information before starting a

            
   subscription.

          

          
 

          
<Eric>
              Agree, we should make this tweak.

          
 

          


            YANG module:

            

            10. Top level description statement, it looks like the
            copyright has accidentally been indented by 4 chars.

          
 

          
<Eric>
              Agree, we should make this tweak.

          


            

            Identities:

            11. I suggest renaming "no-such-subscription-resynch" to
            just "no-such-subscription".  I would have thought that this
            error could also be returned to cancel an unknown
            subscription.

          
 

          
<eric>
              The reason we need "no-such-subscription-resynch" is that
            "no-such-subscription" is already used in SN.  (I.e.,
            is not possible to augment the existing identity with a new
            base.)

        

      

    

    RW: 

    

    Hum, OK.

    

    It is somewhat of a shame that the original error can't just be used
    here.

    

    I wonder if the using multiple bases for the different subscription
    errors isn't trying to be too clever.  I.e. I wonder whether it
    would be better to just have a single base identity for subscription
    errors.

    

    An alternative solution would be to define the "resync-subscription"
    rpc in the base subscribed notifications draft, and then make use of
    that RPC here.  I think that it is slightly plausible that a
    resync-subscription could still be useful in the case of a periodic
    subscription.  E.g. perhaps some client size buffers get overloaded
    so the client has to disregard the request.

    

    But this is a minor wart, having a separate name isn't the end of
    the world.  Making "no-such-subscription-resync" also have
    "no-such-subscription" as a base might also be sensible.

    

    

      

        

          

          


            

            12. "synchronization-size" doesn't sound like an error,
            perhaps "synchronization-too-big" or "resync-too-big" might
            be better?

          
 

          
<eric>
              I have no problem with changing it to
              "synchronization-too-big", that aligns to the other
              identity "update-too-big"

          


            

            Type definitions:

          


            13.  Change all instances (create, delete, insert, move,
            replace)  of "data node" to "datastore node".
            

            

            14. grouping selection-filter-types, anydata
            datastore-subtree-filter, perhaps add a reference to "RFC
            6241: Network Configuration Protocol, Section 6.", mirroring
            draft-ietf-netconf-nmda-netconf.

            

            15. grouping update-policy-modifiable, container on-change
            description statement, needs to be indented by 2 spaces.

            

            16. grouping hints, description, indent the second
            description line by 1 space.

            

            17. rpc resynch-subscription, description statement, last
            two lines require alignment.

          
 

          
 

          
<eric>
              I think all five suggestions above are good tweaks.

        

      

    

    

    Thanks,

    Rob

    

    

    

      

        

          

          
 

          
Eric

          


            

            Thanks,

            Rob

        

      

    

    

  


--------------95CCC4F3660BF4DCFA6FDD07--


From nobody Tue Sep 11 08:25:21 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEA9130EA1 for ; Tue, 11 Sep 2018 08:25:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, 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 ZfjWxxQQjxfx for ; Tue, 11 Sep 2018 08:25:16 -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 47D70130E9D for ; Tue, 11 Sep 2018 08:25:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56408; q=dns/txt; s=iport; t=1536679516; x=1537889116; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=y2V18lxQT0nl422x/y5y70zvdBsg/3fgcaMOlbacECc=; b=XlpPkjn2J0hFfvWzQsUVLVHMQusgTCYLhnEvq0lywhIiqhvFpxMIFiPp gY7OG13vtjCoActNoj7mQ5gIzgZ3tSBx+QA0FFT3ltDseVDCqvZxf27sn Qxcxd4SAjjuQlzS7VXkqbzH4+2cuKNC12KF4mTqqXyvQwtVS0hKCLLq1H 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgA93Zdb/40NJK1SCRoBAQEBAQI?= =?us-ascii?q?BAQEBCAEBAQGCV00qZX8yg2iUNYINlk6BZguEbAIXg3YhNxUBAgEBAgEBAm0?= =?us-ascii?q?ohTgBAQEBAyMKTBACAQgVEBMBCQICAjAlAgQODROCO0yBHWSlSoEuH4llimc?= =?us-ascii?q?XgUE/gRKCZC6EQxEDER0HCSGCSYJXAogFGSqEahOBNIQciC5OCQKPfB+BQIR?= =?us-ascii?q?BiHSIS4smAhEUgSUzIoFVcBU7gm2QUo0BgS6BHgEB?=
X-IronPort-AV: E=Sophos;i="5.53,360,1531785600";  d="scan'208,217";a="170456096"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2018 15:25:15 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w8BFPEY0008921 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Sep 2018 15:25:15 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.1395.4; Tue, 11 Sep 2018 11:25:13 -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.1395.000; Tue, 11 Sep 2018 11:25:13 -0400
From: "Eric Voit (evoit)" 
To: Robert Wilton 
CC: "'Alexander Clemm'" , "netconf@ietf.org" 
Thread-Topic: [Netconf] RGW YANG push -18 LC comments [part 2]
Thread-Index: AQHUSO/FNXKE0k4fYEW4TLD4dEyf0qTpskjQgAFkKwCAABresA==
Date: Tue, 11 Sep 2018 15:25:13 +0000
Message-ID: <1c05cc85fb664699bd34ffdde6b40d0e@XCH-RTP-013.cisco.com>
References:  <9743f8e24d6f448687517c83d07db025@XCH-RTP-013.cisco.com> <51902072-7382-8ea9-3601-8e15bcbfe12b@cisco.com>
In-Reply-To: <51902072-7382-8ea9-3601-8e15bcbfe12b@cisco.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.234]
Content-Type: multipart/alternative; boundary="_000_1c05cc85fb664699bd34ffdde6b40d0eXCHRTP013ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.154, xch-rtp-014.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: 
Subject: Re: [Netconf] RGW YANG push -18 LC comments [part 2]
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Sep 2018 15:25:19 -0000

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

VGhhbmtzIFJvYmVydCwgICBpbmxpbmUuLi4uDQoNCg0KRnJvbTogUm9iZXJ0IFdpbHRvbiwgU2Vw
dGVtYmVyIDExLCAyMDE4IDU6MzQgQU0NCg0KDQpIaSBFcmljLA0KDQpQbGVhc2Ugc2VlIGlubGlu
ZSAoUlc6KS4gIE1vc3QgaXNzdWVzIGFyZSBjbG9zZWQsIGp1c3QgYSBjb3VwbGUgdGhhdCByZXF1
aXJlIGZ1cnRoZXIgcmVzb2x1dGlvbi4NCg0KT24gMTAvMDkvMjAxOCAxODoxOSwgRXJpYyBWb2l0
IChldm9pdCkgd3JvdGU6DQpIaSBSb2JlcnQsDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiAg
SW4tbGluZSB3aXRoIDxFcmljPi4uLi4NCg0KRnJvbTogUm9iZXJ0IFdpbHRvbiwgU2VwdGVtYmVy
IDEwLCAyMDE4IDY6MTkgQU0NCg0KDQpIaSBBbGV4LCBhdXRob3JzLA0KDQpIZXJlIGFyZSBteSBy
ZW1haW5pbmcgY29tbWVudHMgZnJvbSBteSBXRyBMQyByZXZpZXcgb2YgdGhlIFlBTkcgcHVzaCBk
cmFmdC4gIEFnYWluLCBJIHRoaW5rIHRoYXQgdGhlc2UgYXJlIGFsbCBtaW5vci4NCg0KMS4gU2Vj
IDQuMy4yLCBwYXJhZ3JhcGggMi4gICJyZXN1bHRlZCBpbiBhIHBhcnRpY3VsYXIgcHVzaCIgPT4g
InJlc3VsdGVkIGluIGEgcGFydGljdWxhciB1cGRhdGUgcmVjb3JkIj8NCg0KPEVyaWM+IEFncmVl
LCB3ZSBzaG91bGQgbWFrZSB0aGlzIHR3ZWFrLg0KDQoNCjIuIFNlYyA0LjQuMSwgYWZ0ZXIgRmln
dXJlIDcsICJNQVkgcmVzcG9uZCIgPT4gIm1heSByZXNwb25kIi4gIFRoaXMgaXMganVzdCBhbiBl
eGFtcGxlIGZyb20gdGhhdCBub3JtYXRpdmUgYmVoYXZpb3VyLg0KDQo8RXJpYz4gQWdyZWUsIHdl
IHNob3VsZCBtYWtlIHRoaXMgdHdlYWsuDQoNCg0KMy4gU2VjIDQuNC4xLCBwYXJhZ3JhcGggc3Rh
cnRpbmcgIklmIGEgcmVxdWVzdCBpcyByZWplY3RlZCAuLi4iLiAgSXMgaXQgcmVhbGx5IHJpZ2h0
IGZvciB0aGlzIHRvIGJlICJTSE9VTEQiIHJhdGhlciB0aGFuICJNQVkiPyAgRWFybHkgdGV4dCAo
ZS5nLiAzLjIuIHBhcmFncmFwaCAyIHVzZXMgIm1heSBiZSBpbnNlcnRlZCIuICBBbHNvIGluIHNl
Y3Rpb24gNC40LjIsIHBhcmFncmFwaCBhZnRlciBGaWd1cmUgMTEuDQoNCjxFcmljPiBJIHByZWZl
ciBTSE9VTEQuICBTZWN0aW9uIDMuMiB0ZXh0IGhhZCDigJxtYXnigJ0gaW5zdGVhZCBvZiDigJxN
QVnigJ0uDQpNeSByZWFkaW5nIG9mIHRoZSB0ZXh0IGluIDMuMiwgcGFyYWdyYXBoIDIsIGlzIHRo
YXQgdGhlIGVycm9yIGluZm9ybWF0aW9uIGlzIHNvbWUgb3B0aW9uYWwsIHdoZXJlYXMgc2VjdGlv
biA0LjQuMSBzdHJvbmdseSBlbmNvdXJhZ2VzIGl0LiAgSSB0aGluayB0aGF0IGl0IHdvdWxkIGJl
IGJldHRlciBpZiB0aGVzZSB0d28gd2VyZSBjb25zaXN0ZW50LCBpLmUuIGlmIHlvdSB3YW50IHRv
IGtlZXAgdGhlICJTSE9VTEQiIGluIDQuNC4xLCB0aGVuIEkgdGhpbmsgdGhhdCBpdCB3b3VsZCBi
ZSBiZXR0ZXIgaWYgdGhlICJtYXkiIGluIHNlYyAzLjIgd2FzIGEgInNob3VsZCIuDQoNCjxFcmlj
PiBXb3JrcyBmb3IgbWUuDQoNCg0KDQoNCjQuIFNlYyA0LjQuMSwgIk9wdGlvbmFsbHksIGFuICJl
cnJvci1zZXZlcml0eSIgb2YgImVycm9yIiAodGhpcyBNQVkgYnV0IGRvZXMgbm90IGhhdmUgdG8g
YmUgaW5jbHVkZWQpLiIsIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGUgbGFzdCBjbGF1c2UgaXMgcmVx
dWlyZWQgKGdpdmVuIHRoYXQgaXQgaXMgcHJlZGljYXRlZCBieSBPcHRpb25hbGx5LCBzbyBzdWdn
ZXN0IGRlbGV0aW5nIHRoZSBjbGF1c2UgaW4gcGFyZW50aGVzaXMuICBPdGhlcndpc2UgaXQgaXMg
YWxzbyBpbmNvbnNpc3RlbnQgd2l0aCB0aGUgZm9sbG93aW5nICJlcnJvci1pbmZvIiBkZXNjcmlw
dGlvbi4gIElmIHRoaXMgY2hhbmdlLCBpdCBzaG91bGQgYWxzbyBiZSBjaGFuZ2VkIGZvciAiZXJy
b3Itc2V2ZXJpdHkiIGluIFNlYyA0LjQuMi4NCg0KPEVyaWM+IEFncmVlLCB3ZSBzaG91bGQgbWFr
ZSB0aGlzIHR3ZWFrLg0KDQoNCjUuIFNlYyA0LjQuMSwgTkVUQ09ORiBzcGVjaWZpYyB0ZXh0IGFi
b3V0IGVycm9ycy4gIFNob3VsZCB0aGF0IHRleHQgcmVhbGx5IGJlIGluIHRoaXMgZHJhZnQ/ICBX
b3VsZCBpdCBub3QgYmUgbmljZXIgdG8ga2VlcCBhbGwgb2YgdGhlIE5FVENPTkYgc3BlY2lmaWNz
IHRvIGEgTkVUQ09ORiBwcm90b2NvbCBkcmFmdD8gIFBlcmhhcHMgdGhpcyBpcyBub3QgcHJhY3Rp
Y2FsLCBidXQgdGhlIFdHIGlzIGN1cnJlbnRseSBleHBlcmllbmNpbmcgc29tZSBwYWluIHdoZXJl
IE5FVENPTkYgcHJvdG9jb2wgc3BlY2lmaWMgbm9ybWF0aXZlIHRleHQgaXMgaW4gUkZDIDc5NTAu
ICBIZW5jZSwgaXQgd291bGQgYmUgbmljZSB0byBhdm9pZCBpbnRyb2R1Y2luZyB0aGF0IGlzc3Vl
IGhlcmUgaWYgcG9zc2libGUuICBUaGlzIHNhbWUgY29tbWVudCBhbHNvIGFwcGxpZXMgdG8gU2Vj
IDQuNC4yLg0KDQo8RXJpYz4gQXMgdGhpcyBpcyBhIG5vbi1ub3JtYXRpdmUgZXhhbXBsZSwgd2Ug
c2hvdWxkIG5vdCBoaXQgdGhlIHNhbWUgaXNzdWUuICBJIGRvIGxpa2UgZXhhbXBsZXMgZm9yIHJl
YWRlcnMgdG8gZGlnZXN0Lg0KUlc6DQpJIHdhcyBtZWFuaW5nIHRoaXMgdGV4dDoNCg0KDQoNCklu
IHRoZSBjYXNlIG9mIE5FVENPTkYNCg0KICAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYtbmV0Y29u
Zi1ldmVudC1ub3RpZmljYXRpb25zXSwgd2hlbiBhDQoNCiAgIHN1YnNjcmlwdGlvbiByZXF1ZXN0
IGlzIHJlamVjdGVkLCB0aGUgTkVUQ09ORiBSUEMgcmVwbHkgTVVTVCBpbmNsdWRlDQoNCiAgIGFu
ICJycGMtZXJyb3IiIGVsZW1lbnQgd2l0aCB0aGUgZm9sbG93aW5nIGVsZW1lbnRzOg0KDQoNCg0K
ICAgbyAgImVycm9yLXR5cGUiIG9mICJhcHBsaWNhdGlvbiIuDQoNCg0KDQogICBvICAiZXJyb3It
dGFnIiBvZiAib3BlcmF0aW9uLWZhaWxlZCIuDQoNCg0KDQogICBvICBPcHRpb25hbGx5LCBhbiAi
ZXJyb3Itc2V2ZXJpdHkiIG9mICJlcnJvciIgKHRoaXMgTUFZIGJ1dCBkb2VzIG5vdA0KDQogICAg
ICBoYXZlIHRvIGJlIGluY2x1ZGVkKS4NCg0KDQoNCiAgIG8gIE9wdGlvbmFsbHksICJlcnJvci1p
bmZvIiBjb250YWluaW5nIFhNTC1lbmNvZGVkIGRhdGEgd2l0aCBoaW50cw0KDQogICAgICBmb3Ig
cGFyYW1ldGVyIHNldHRpbmdzIHRoYXQgbWlnaHQgcmVzdWx0IGluIGZ1dHVyZSBSUEMgc3VjY2Vz
cyBwZXINCg0KICAgICAgeWFuZy1kYXRhIGRlZmluaXRpb24gImVzdGFibGlzaC1zdWJzY3JpcHRp
b24tZXJyb3ItZGF0YXN0b3JlIi4NCg0KVGhpcyB0ZXh0IGluY2x1ZGVzIFJGQyAyMTE5IGxhbmd1
YWdlLCBzbyBhIHJlYWRlciB3b3VsZCBzdXJlbHkgaW50ZXJwcmV0IHRoYXQgdGV4dCBhcyBiZWlu
ZyBub3JtYXRpdmUuDQoNCklmIHlvdXIgd2FudCB0byBiZSBub24tbm9ybWF0aXZlIHRoZW4gSSB0
aGluayB0aGF0IHlvdSBuZWVkIHRvIHJlcGxhY2UgdGhlICJyZXBseSBNVVNUIGluY2x1ZGUiIHN0
YXRlbWVudCB3aXRoICJyZXBseSB3b3VsZCBiZSBleHBlY3RlZCB0byBpbmNsdWRlICIsIGFuZCBw
cmVmaXggdGhlIHRleHQgd2l0aCwgIkZvciBleGFtcGxlLCBpbiB0aGUgY2FzZSBvZiBORVRDT05G
IC4uLiINCg0KDQo8ZXJpYz4gQWdyZWUuICBJLmUuLCBJIHRoaW5rIHdlIGNhbiBtYWtlIHRoZSBj
aGFuZ2VzIG5lZWRlZCBmb3IgdGhpcyB0ZXh0IHRvIGJlY29tZSBub24tbm9ybWF0aXZlLg0KDQoN
Cg0KNi4gU2VjIDQuNC4yLCBkZXNjcmlwdGlvbiBwYXJhZ3JhcGguICBTdWdnZXN0IHRoZSBmb2xs
b3dpbmcgY2hhbmdlIHRvIG1hdGNoIHRoZSBhY3R1YWwgZXhhbXBsZTogIm1vZGlmeSB0aGUgInBl
cmlvZCIgb2YgYSBzdWJzY3JpcHRpb24uIiA9PiAibW9kaWZ5IHRoZSAicGVyaW9kIiBhbmQgImRh
dGFzdG9yZSBYUGF0aCBmaWx0ZXIiIG9mIGEgc3Vic2NyaXB0aW9uLiINCg0KPEVyaWM+IEFncmVl
LCB3ZSBzaG91bGQgbWFrZSB0aGlzIHR3ZWFrLg0KDQoNCjcuIFNlYyA0LjQuMiwgZmlyc3QgcGFy
YWdyYXBoIGFmdGVyIGZpZ3VyZSAxMTogIFBvc3NpYmxlIHJld29yZGluZzoNCg0KT2xkOg0KDQoN
Cg0KICAgVGhlIHB1Ymxpc2hlciBNVVNUIHJlc3BvbmQgZXhwbGljaXRseSBwb3NpdGl2ZWx5IG9y
IG5lZ2F0aXZlbHkgdG8gdGhlDQoNCiAgIHJlcXVlc3QuICBJZiB0aGUgc3Vic2NyaXB0aW9uIG1v
ZGlmaWNhdGlvbiBpcyByZWplY3RlZCwgdGhlDQoNCiAgIHN1YnNjcmlwdGlvbiBpcyBtYWludGFp
bmVkIGFzIGl0IHdhcyBiZWZvcmUgdGhlIG1vZGlmaWNhdGlvbiByZXF1ZXN0Lg0KDQogICBJbiBh
ZGRpdGlvbiwgdGhlIHB1Ymxpc2hlciBNVVNUIHNlbmQgYW4gUlBDIGVycm9yIHJlc3BvbnNlLiAg
VGhpcyBSUEMNCg0KICAgZXJyb3IgcmVzcG9uc2UgU0hPVUxEIGNvbnRhaW4gaGludHMgZW5jYXBz
dWxhdGVkIHdpdGhpbiB0aGUgeWFuZy1kYXRhDQoNCiAgIHN0cnVjdHVyZSAibW9kaWZ5LXN1YnNj
cmlwdGlvbi1lcnJvci1kYXRhc3RvcmUiLiAgQSBzdWJzY3JpcHRpb24gTUFZDQoNCiAgIGJlIG1v
ZGlmaWVkIG11bHRpcGxlIHRpbWVzLg0KDQpORVc6DQoNCg0KDQogICBUaGUgcHVibGlzaGVyIE1V
U1QgcmVzcG9uZCB0byB0aGUgc3Vic2NyaXB0aW9uIG1vZGlmaWNhdGlvbiByZXF1ZXN0Lg0KDQog
ICBJZiB0aGUgcmVxdWVzdCBpcyByZWplY3RlZCwgdGhlIGV4aXN0aW5nIHN1YnNjcmlwdGlvbiBp
cyBsZWZ0IHVuY2hhbmdlZCwgYW5kDQoNCiAgIHRoZSBwdWJsaXNoZXIgTVVTVCBzZW5kIGFuIFJQ
QyBlcnJvciByZXNwb25zZSwgd2hpY2ggTUFZfFNIT1VMRCBjb250YWluDQoNCiAgIGhpbnRzIGVu
Y2Fwc3VsYXRlZCB3aXRoaW4gdGhlIHlhbmctZGF0YSBzdHJ1Y3R1cmUNCg0KICAgIm1vZGlmeS1z
dWJzY3JpcHRpb24tZXJyb3ItZGF0YXN0b3JlIi4gIEEgc3Vic2NyaXB0aW9uIE1BWSBiZSBtb2Rp
ZmllZA0KDQogICBtdWx0aXBsZSB0aW1lcy4NCg0KPEVyaWM+IFByb3Bvc2VkIHRleHQgbG9va3Mg
ZmluZSwgd2l0aCBhIHNtYWxsIHR3ZWFrOg0KDQpUaGUgcHVibGlzaGVyIE1VU1QgcmVzcG9uZCB0
byB0aGUgc3Vic2NyaXB0aW9uIG1vZGlmaWNhdGlvbiByZXF1ZXN0LiAgSWYgdGhlIHJlcXVlc3Qg
aXMgcmVqZWN0ZWQsIHRoZSBleGlzdGluZyBzdWJzY3JpcHRpb24gaXMgbGVmdCB1bmNoYW5nZWQs
IGFuZCB0aGUgcHVibGlzaGVyIE1VU1Qgc2VuZCBhbiBSUEMgZXJyb3IgcmVzcG9uc2UuICBUaGlz
IHJlc3BvbnNlIG1pZ2h0IGhhdmUgaGludHMgZW5jYXBzdWxhdGVkIHdpdGhpbiB0aGUgeWFuZy1k
YXRhIHN0cnVjdHVyZSAibW9kaWZ5LXN1YnNjcmlwdGlvbi1lcnJvci1kYXRhc3RvcmUiLiAgQSBz
dWJzY3JpcHRpb24gTUFZIGJlIG1vZGlmaWVkIG11bHRpcGxlIHRpbWVzLg0KDQpSVzoNCkkgdGhp
bmsgdGhhdCAiU0hPVUxEIiBpdCBiZXR0ZXIgdGhhbiAibWlnaHQiIGZvciBjb25zaXN0ZW5jeSwg
YXMgcGVyIHRoZSBzYW1lIGRpc2N1c3Npb24gcG9pbnQgYWJvdmUgKHdoaWNoIGlzIHdoeSBteSBv
cmlnaW5hbCB0ZXh0IHdhcyBNQVl8U0hPVUxELCBpLmUuIG9ubHkgYSBzaW5nbGUgb25lIHNob3Vs
ZCBiZSB1c2VkIGRlcGVuZGluZyBvbiBob3cgaXNzdWUgMyBhYm92ZSBnb3QgcmVzb2x2ZWQpLg0K
DQo8RXJpYz4gU0hPVUxEIGlzIG5vdCBhcHByb3ByaWF0ZSBoZXJlLCBhcyB1c3VhbGx5IHRoZXJl
IHdpbGwgbm90IGJlIGhpbnRzIGVuY2Fwc3VsYXRlZC4NCg0KDQoNCg0KOC4gU2VjIDQuNC40LCBu
byBmaWd1cmUgbnVtYmVyIHVuZGVyIHRoZSBleGFtcGxlLg0KDQo8RXJpYz4gQWdyZWUuICBBbGV4
LCBjYW4geW91IHR3ZWFrIHRoZSBYTUw/DQoNCg0KOS4gU2VjIDQuNC41LCBwYXJhZ3JhcGggMToN
CkkgdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgdGhpcyBqdXN0IHJlZmVycmVkIHRv
IFlBTkcgbGlicmFyeSwgaGVuY2Ugc3VnZ2VzdCBjaGFuZ2luZyB0aGUgZmlyc3QgdHdvIHBhcmFn
cmFwaHM6DQoNCk9MRDoNCg0KDQoNCiAgIFRvIG1ha2Ugc3Vic2NyaXB0aW9uIHJlcXVlc3RzLCB0
aGUgc3Vic2NyaWJlciBuZWVkcyB0byBrbm93IHRoZSBZQU5HDQoNCiAgIG1vZHVsZSBsaWJyYXJ5
IGF2YWlsYWJsZSBvbiB0aGUgcHVibGlzaGVyLiAgVGhlIFlBTkcgMSBtb2R1bGUgbGlicmFyeQ0K
DQogICBpbmZvcm1hdGlvbiBpcyBzZW50IGJ5IGEgTkVUQ09ORiBzZXJ2ZXIgaW4gdGhlIE5FVENP
TkYgImhlbGxvIg0KDQogICBtZXNzYWdlLiAgRm9yIFlBTkcgMS4xIG1vZHVsZXMgYW5kIGFsbCBt
b2R1bGVzIHVzZWQgd2l0aCB0aGUgUkVTVENPTkYNCg0KICAgW1JGQzgwNDBdIHByb3RvY29sLCB0
aGlzIGluZm9ybWF0aW9uIGlzIHByb3ZpZGVkIGJ5IHRoZSBZQU5HIExpYnJhcnkNCg0KICAgbW9k
dWxlIChpZXRmLXlhbmctbGlicmFyeS55YW5nIGZyb20gW1JGQzc4OTVdLiAgVGhpcyBZQU5HIGxp
YnJhcnkNCg0KICAgaW5mb3JtYXRpb24gaXMgaW1wb3J0YW50IGZvciB0aGUgcmVjZWl2ZXIgdG8g
cmVwcm9kdWNlIHRoZSBzZXQgb2YNCg0KICAgb2JqZWN0IGRlZmluaXRpb25zIHVzZWQgd2l0aGlu
IHRoZSBwdWJsaXNoZXIuDQoNCg0KDQogICBUaGUgWUFORyBsaWJyYXJ5IGluY2x1ZGVzIGEgbW9k
dWxlIGxpc3Qgd2l0aCB0aGUgbmFtZSwgcmV2aXNpb24sDQoNCiAgIGVuYWJsZWQgZmVhdHVyZXMs
IGFuZCBhcHBsaWVkIGRldmlhdGlvbnMgZm9yIGVhY2ggWUFORyBtb2R1bGUNCg0KICAgaW1wbGVt
ZW50ZWQgYnkgdGhlIHB1Ymxpc2hlci4gIFRoZSByZWNlaXZlciBpcyBleHBlY3RlZCB0byBrbm93
IHRoZQ0KDQogICBZQU5HIGxpYnJhcnkgaW5mb3JtYXRpb24gYmVmb3JlIHN0YXJ0aW5nIGEgc3Vi
c2NyaXB0aW9uLg0KDQpORVc6DQoNCg0KDQogICBUbyBtYWtlIHN1YnNjcmlwdGlvbiByZXF1ZXN0
cywgdGhlIHN1YnNjcmliZXIgbmVlZHMgdG8ga25vdyB0aGUgWUFORw0KDQogICBkYXRhc3RvcmUg
c2NoZW1hcyB1c2VkIGJ5IHRoZSBwdWJsaXNoZXIsIHdoaWNoIGFyZSBhdmFpbGFibGUgdmlhIHRo
ZSBZQU5HDQoNCiAgIExpYnJhcnkgbW9kdWxlLCBpZXRmLXlhbmctbGlicmFyeS55YW5nIGZyb20g
W1JGQzc4OTVdLiAgVGhlIHJlY2VpdmVyDQoNCiAgIGlzIGV4cGVjdGVkIHRvIGtub3cgdGhlIFlB
TkcgbGlicmFyeSBpbmZvcm1hdGlvbiBiZWZvcmUgc3RhcnRpbmcgYQ0KDQogICBzdWJzY3JpcHRp
b24uDQoNCjxFcmljPiBBZ3JlZSwgd2Ugc2hvdWxkIG1ha2UgdGhpcyB0d2Vhay4NCg0KDQpZQU5H
IG1vZHVsZToNCg0KMTAuIFRvcCBsZXZlbCBkZXNjcmlwdGlvbiBzdGF0ZW1lbnQsIGl0IGxvb2tz
IGxpa2UgdGhlIGNvcHlyaWdodCBoYXMgYWNjaWRlbnRhbGx5IGJlZW4gaW5kZW50ZWQgYnkgNCBj
aGFycy4NCg0KPEVyaWM+IEFncmVlLCB3ZSBzaG91bGQgbWFrZSB0aGlzIHR3ZWFrLg0KDQoNCklk
ZW50aXRpZXM6DQoxMS4gSSBzdWdnZXN0IHJlbmFtaW5nICJuby1zdWNoLXN1YnNjcmlwdGlvbi1y
ZXN5bmNoIiB0byBqdXN0ICJuby1zdWNoLXN1YnNjcmlwdGlvbiIuICBJIHdvdWxkIGhhdmUgdGhv
dWdodCB0aGF0IHRoaXMgZXJyb3IgY291bGQgYWxzbyBiZSByZXR1cm5lZCB0byBjYW5jZWwgYW4g
dW5rbm93biBzdWJzY3JpcHRpb24uDQoNCjxlcmljPiBUaGUgcmVhc29uIHdlIG5lZWQgIm5vLXN1
Y2gtc3Vic2NyaXB0aW9uLXJlc3luY2giIGlzIHRoYXQgIm5vLXN1Y2gtc3Vic2NyaXB0aW9uIiBp
cyBhbHJlYWR5IHVzZWQgaW4gU04uICAoSS5lLiwgaXMgbm90IHBvc3NpYmxlIHRvIGF1Z21lbnQg
dGhlIGV4aXN0aW5nIGlkZW50aXR5IHdpdGggYSBuZXcgYmFzZS4pDQpSVzoNCg0KSHVtLCBPSy4N
Cg0KSXQgaXMgc29tZXdoYXQgb2YgYSBzaGFtZSB0aGF0IHRoZSBvcmlnaW5hbCBlcnJvciBjYW4n
dCBqdXN0IGJlIHVzZWQgaGVyZS4NCg0KPEVyaWM+IEFncmVlDQoNCg0KSSB3b25kZXIgaWYgdGhl
IHVzaW5nIG11bHRpcGxlIGJhc2VzIGZvciB0aGUgZGlmZmVyZW50IHN1YnNjcmlwdGlvbiBlcnJv
cnMgaXNuJ3QgdHJ5aW5nIHRvIGJlIHRvbyBjbGV2ZXIuICBJLmUuIEkgd29uZGVyIHdoZXRoZXIg
aXQgd291bGQgYmUgYmV0dGVyIHRvIGp1c3QgaGF2ZSBhIHNpbmdsZSBiYXNlIGlkZW50aXR5IGZv
ciBzdWJzY3JpcHRpb24gZXJyb3JzLg0KDQo8RXJpYz4gV2UgaGFkIHRoYXQgb3JpZ2luYWxseS4g
IE90aGVyIGNvbW1lbnRlcnMgcmVxdWVzdGVkIHRoZSBjaGFuZ2UgYmUgbWFkZSBzbyB0aGF0IHRo
ZSB3cm9uZyBlcnJvciBtZXNzYWdlcyBjb3VsZG7igJl0IHBvc3NpYmx5IGJlIGRlbGl2ZXJlZC4N
Cg0KDQpBbiBhbHRlcm5hdGl2ZSBzb2x1dGlvbiB3b3VsZCBiZSB0byBkZWZpbmUgdGhlICJyZXN5
bmMtc3Vic2NyaXB0aW9uIiBycGMgaW4gdGhlIGJhc2Ugc3Vic2NyaWJlZCBub3RpZmljYXRpb25z
IGRyYWZ0LCBhbmQgdGhlbiBtYWtlIHVzZSBvZiB0aGF0IFJQQyBoZXJlLiAgSSB0aGluayB0aGF0
IGl0IGlzIHNsaWdodGx5IHBsYXVzaWJsZSB0aGF0IGEgcmVzeW5jLXN1YnNjcmlwdGlvbiBjb3Vs
ZCBzdGlsbCBiZSB1c2VmdWwgaW4gdGhlIGNhc2Ugb2YgYSBwZXJpb2RpYyBzdWJzY3JpcHRpb24u
ICBFLmcuIHBlcmhhcHMgc29tZSBjbGllbnQgc2l6ZSBidWZmZXJzIGdldCBvdmVybG9hZGVkIHNv
IHRoZSBjbGllbnQgaGFzIHRvIGRpc3JlZ2FyZCB0aGUgcmVxdWVzdC4NCg0KQnV0IHRoaXMgaXMg
YSBtaW5vciB3YXJ0LCBoYXZpbmcgYSBzZXBhcmF0ZSBuYW1lIGlzbid0IHRoZSBlbmQgb2YgdGhl
IHdvcmxkLiAgTWFraW5nICJuby1zdWNoLXN1YnNjcmlwdGlvbi1yZXN5bmMiIGFsc28gaGF2ZSAi
bm8tc3VjaC1zdWJzY3JpcHRpb24iIGFzIGEgYmFzZSBtaWdodCBhbHNvIGJlIHNlbnNpYmxlLg0K
DQo8RXJpYz4gVGhlc2UgYXJlIGFsbCBwb3NzaWJsZS4gIEJ1dCBJIGFtIGhvcGluZyB3aGF0IHdl
IGN1cnJlbnRseSBoYXZlIGlzIHN1ZmZpY2llbnQuICAoUmlnaHQgbm93IHdlIGhhdmUgbGltaXRl
ZCB0aGUgZGVzaWduIHRvIHR3byB0aWVycyBvZiBpZGVudGl0aWVzLiAgSXQgd291bGQgYmUgZ29v
ZCBub3QgdG8gYWRkIG1vcmUuKQ0KDQpFcmljDQoNCg0KDQoxMi4gInN5bmNocm9uaXphdGlvbi1z
aXplIiBkb2Vzbid0IHNvdW5kIGxpa2UgYW4gZXJyb3IsIHBlcmhhcHMgInN5bmNocm9uaXphdGlv
bi10b28tYmlnIiBvciAicmVzeW5jLXRvby1iaWciIG1pZ2h0IGJlIGJldHRlcj8NCg0KPGVyaWM+
IEkgaGF2ZSBubyBwcm9ibGVtIHdpdGggY2hhbmdpbmcgaXQgdG8gInN5bmNocm9uaXphdGlvbi10
b28tYmlnIiwgdGhhdCBhbGlnbnMgdG8gdGhlIG90aGVyIGlkZW50aXR5ICJ1cGRhdGUtdG9vLWJp
ZyINCg0KDQpUeXBlIGRlZmluaXRpb25zOg0KDQoxMy4gIENoYW5nZSBhbGwgaW5zdGFuY2VzIChj
cmVhdGUsIGRlbGV0ZSwgaW5zZXJ0LCBtb3ZlLCByZXBsYWNlKSAgb2YgImRhdGEgbm9kZSIgdG8g
ImRhdGFzdG9yZSBub2RlIi4NCg0KMTQuIGdyb3VwaW5nIHNlbGVjdGlvbi1maWx0ZXItdHlwZXMs
IGFueWRhdGEgZGF0YXN0b3JlLXN1YnRyZWUtZmlsdGVyLCBwZXJoYXBzIGFkZCBhIHJlZmVyZW5j
ZSB0byAiUkZDIDYyNDE6IE5ldHdvcmsgQ29uZmlndXJhdGlvbiBQcm90b2NvbCwgU2VjdGlvbiA2
LiIsIG1pcnJvcmluZyBkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1uZXRjb25mLg0KDQoxNS4gZ3Jv
dXBpbmcgdXBkYXRlLXBvbGljeS1tb2RpZmlhYmxlLCBjb250YWluZXIgb24tY2hhbmdlIGRlc2Ny
aXB0aW9uIHN0YXRlbWVudCwgbmVlZHMgdG8gYmUgaW5kZW50ZWQgYnkgMiBzcGFjZXMuDQoNCjE2
LiBncm91cGluZyBoaW50cywgZGVzY3JpcHRpb24sIGluZGVudCB0aGUgc2Vjb25kIGRlc2NyaXB0
aW9uIGxpbmUgYnkgMSBzcGFjZS4NCg0KMTcuIHJwYyByZXN5bmNoLXN1YnNjcmlwdGlvbiwgZGVz
Y3JpcHRpb24gc3RhdGVtZW50LCBsYXN0IHR3byBsaW5lcyByZXF1aXJlIGFsaWdubWVudC4NCg0K
DQo8ZXJpYz4gSSB0aGluayBhbGwgZml2ZSBzdWdnZXN0aW9ucyBhYm92ZSBhcmUgZ29vZCB0d2Vh
a3MuDQoNClRoYW5rcywNClJvYg0KDQoNCg0KDQpFcmljDQoNCg0KVGhhbmtzLA0KUm9iDQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjsNCgljb2xvcjpibGFjazt9DQp0
dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iixz
ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z
by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn
aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0
OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
LHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv
LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5
OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHls
ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv
bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u
YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4
dDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N
c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox
MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp
bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y
ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd
LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+
DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht
bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V
UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgUm9iZXJ0LCZu
YnNwOyZuYnNwOyBpbmxpbmUuLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0
Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBSb2Jl
cnQgV2lsdG9uLCBTZXB0ZW1iZXIgMTEsIDIwMTggNTozNCBBTTxicj4NCjxicj4NCjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwPkhpIEVyaWMsPG86cD48L286cD48L3A+DQo8cD5QbGVhc2Ugc2Vl
IGlubGluZSAoUlc6KS4mbmJzcDsgTW9zdCBpc3N1ZXMgYXJlIGNsb3NlZCwganVzdCBhIGNvdXBs
ZSB0aGF0IHJlcXVpcmUgZnVydGhlciByZXNvbHV0aW9uLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMC8wOS8yMDE4
IDE4OjE5LCBFcmljIFZvaXQgKGV2b2l0KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+
SGkgUm9iZXJ0LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4
dCI+VGhhbmtzIGZvciB0aGUgY29tbWVudHMuJm5ic3A7IEluLWxpbmUgd2l0aCAmbHQ7RXJpYyZn
dDsuLi4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IFJvYmVy
dCBXaWx0b24sIFNlcHRlbWJlciAxMCwgMjAxOCA2OjE5IEFNPGJyPg0KPGJyPg0KPGJyPg0KPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkhpIEFsZXgsIGF1dGhvcnMsPGJyPg0KPGJyPg0KSGVyZSBhcmUgbXkgcmVtYWluaW5nIGNvbW1l
bnRzIGZyb20gbXkgV0cgTEMgcmV2aWV3IG9mIHRoZSBZQU5HIHB1c2ggZHJhZnQuJm5ic3A7IEFn
YWluLCBJIHRoaW5rIHRoYXQgdGhlc2UgYXJlIGFsbCBtaW5vci48YnI+DQo8YnI+DQoxLiBTZWMg
NC4zLjIsIHBhcmFncmFwaCAyLiZuYnNwOyAmcXVvdDtyZXN1bHRlZCBpbiBhIHBhcnRpY3VsYXIg
cHVzaCZxdW90OyA9Jmd0OyAmcXVvdDtyZXN1bHRlZCBpbiBhIHBhcnRpY3VsYXIgdXBkYXRlIHJl
Y29yZCZxdW90Oz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jmx0
O0VyaWMmZ3Q7IEFncmVlLCB3ZSBzaG91bGQgbWFrZSB0aGlzIHR3ZWFrLjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjIuIFNlYyA0LjQuMSwg
YWZ0ZXIgRmlndXJlIDcsICZxdW90O01BWSByZXNwb25kJnF1b3Q7ID0mZ3Q7ICZxdW90O21heSBy
ZXNwb25kJnF1b3Q7LiZuYnNwOyBUaGlzIGlzIGp1c3QgYW4gZXhhbXBsZSBmcm9tIHRoYXQgbm9y
bWF0aXZlIGJlaGF2aW91ci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4
dCI+Jmx0O0VyaWMmZ3Q7IEFncmVlLCB3ZSBzaG91bGQgbWFrZSB0aGlzIHR3ZWFrLjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjMuIFNlYyA0
LjQuMSwgcGFyYWdyYXBoIHN0YXJ0aW5nICZxdW90O0lmIGEgcmVxdWVzdCBpcyByZWplY3RlZCAu
Li4mcXVvdDsuJm5ic3A7IElzIGl0IHJlYWxseSByaWdodCBmb3IgdGhpcyB0byBiZSAmcXVvdDtT
SE9VTEQmcXVvdDsgcmF0aGVyIHRoYW4gJnF1b3Q7TUFZJnF1b3Q7PyZuYnNwOyBFYXJseSB0ZXh0
IChlLmcuIDMuMi4gcGFyYWdyYXBoIDIgdXNlcyAmcXVvdDttYXkgYmUgaW5zZXJ0ZWQmcXVvdDsu
Jm5ic3A7IEFsc28gaW4gc2VjdGlvbiA0LjQuMiwgcGFyYWdyYXBoIGFmdGVyIEZpZ3VyZSAxMS48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jmx0O0VyaWMmZ3Q7IEkg
cHJlZmVyIFNIT1VMRC4mbmJzcDsgU2VjdGlvbiAzLjIgdGV4dCBoYWQg4oCcbWF54oCdIGluc3Rl
YWQgb2Yg4oCcTUFZ4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgcmVhZGluZyBvZiB0aGUgdGV4dCBpbiAzLjIs
IHBhcmFncmFwaCAyLCBpcyB0aGF0IHRoZSBlcnJvciBpbmZvcm1hdGlvbiBpcyBzb21lIG9wdGlv
bmFsLCB3aGVyZWFzIHNlY3Rpb24gNC40LjEgc3Ryb25nbHkgZW5jb3VyYWdlcyBpdC4mbmJzcDsg
SSB0aGluayB0aGF0IGl0IHdvdWxkIGJlIGJldHRlciBpZiB0aGVzZSB0d28gd2VyZSBjb25zaXN0
ZW50LCBpLmUuIGlmIHlvdSB3YW50IHRvIGtlZXAgdGhlICZxdW90O1NIT1VMRCZxdW90Ow0KIGlu
IDQuNC4xLCB0aGVuIEkgdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgdGhlICZxdW90
O21heSZxdW90OyBpbiBzZWMgMy4yIHdhcyBhICZxdW90O3Nob3VsZCZxdW90Oy48c3BhbiBzdHls
ZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj4mbHQ7RXJpYyZndDsgV29ya3MgZm9yIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu
IDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KNC4gU2Vj
IDQuNC4xLCAmcXVvdDs8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk9wdGlvbmFs
bHksIGFuICZxdW90O2Vycm9yLXNldmVyaXR5JnF1b3Q7IG9mICZxdW90O2Vycm9yJnF1b3Q7ICh0
aGlzIE1BWSBidXQgZG9lcyBub3QgaGF2ZSB0byBiZSBpbmNsdWRlZCkuJnF1b3Q7LA0KPC9zcGFu
PjwvdHQ+SSBkb24ndCB0aGluayB0aGF0IHRoZSBsYXN0IGNsYXVzZSBpcyByZXF1aXJlZCAoZ2l2
ZW4gdGhhdCBpdCBpcyBwcmVkaWNhdGVkIGJ5IE9wdGlvbmFsbHksIHNvIHN1Z2dlc3QgZGVsZXRp
bmcgdGhlIGNsYXVzZSBpbiBwYXJlbnRoZXNpcy4mbmJzcDsgT3RoZXJ3aXNlIGl0IGlzIGFsc28g
aW5jb25zaXN0ZW50IHdpdGggdGhlIGZvbGxvd2luZyAmcXVvdDtlcnJvci1pbmZvJnF1b3Q7IGRl
c2NyaXB0aW9uLiZuYnNwOyBJZiB0aGlzIGNoYW5nZSwgaXQgc2hvdWxkDQogYWxzbyBiZSBjaGFu
Z2VkIGZvciAmcXVvdDtlcnJvci1zZXZlcml0eSZxdW90OyBpbiBTZWMgNC40LjIuPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93
dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiZsdDtFcmljJmd0OyBBZ3JlZSwgd2Ug
c2hvdWxkIG1ha2UgdGhpcyB0d2Vhay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo1LiBTZWMgNC40LjEsIE5FVENPTkYgc3BlY2lmaWMgdGV4
dCBhYm91dCBlcnJvcnMuJm5ic3A7IFNob3VsZCB0aGF0IHRleHQgcmVhbGx5IGJlIGluIHRoaXMg
ZHJhZnQ/Jm5ic3A7IFdvdWxkIGl0IG5vdCBiZSBuaWNlciB0byBrZWVwIGFsbCBvZiB0aGUgTkVU
Q09ORiBzcGVjaWZpY3MgdG8gYSBORVRDT05GIHByb3RvY29sIGRyYWZ0PyZuYnNwOyBQZXJoYXBz
IHRoaXMgaXMgbm90IHByYWN0aWNhbCwgYnV0IHRoZSBXRyBpcyBjdXJyZW50bHkgZXhwZXJpZW5j
aW5nIHNvbWUgcGFpbg0KIHdoZXJlIE5FVENPTkYgcHJvdG9jb2wgc3BlY2lmaWMgbm9ybWF0aXZl
IHRleHQgaXMgaW4gUkZDIDc5NTAuJm5ic3A7IEhlbmNlLCBpdCB3b3VsZCBiZSBuaWNlIHRvIGF2
b2lkIGludHJvZHVjaW5nIHRoYXQgaXNzdWUgaGVyZSBpZiBwb3NzaWJsZS4mbmJzcDsgVGhpcyBz
YW1lIGNvbW1lbnQgYWxzbyBhcHBsaWVzIHRvIFNlYyA0LjQuMi48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jmx0O0VyaWMmZ3Q7IEFzIHRoaXMgaXMgYSBub24tbm9y
bWF0aXZlIGV4YW1wbGUsIHdlIHNob3VsZCBub3QgaGl0IHRoZSBzYW1lIGlzc3VlLiZuYnNwOyBJ
IGRvIGxpa2UgZXhhbXBsZXMgZm9yIHJlYWRlcnMgdG8gZGlnZXN0Lg0KPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SVzog
PGJyPg0KSSB3YXMgbWVhbmluZyB0aGlzIHRleHQ6PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286
cD48L3A+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdDtiYWNrZ3Jv
dW5kOiNGRkZERjUiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5k
OiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5JbiB0aGUgY2FzZSBvZiBORVRDT05GPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tn
cm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBp
biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBbSS1ELmRyYWZ0
LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlvbnNdLCB3aGVuIGE8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dy
b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGlu
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IHN1YnNjcmlwdGlv
biByZXF1ZXN0IGlzIHJlamVjdGVkLCB0aGUgTkVUQ09ORiBSUEMgcmVwbHkgTVVTVCBpbmNsdWRl
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0
O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRk
aW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBhbiAm
cXVvdDtycGMtZXJyb3ImcXVvdDsgZWxlbWVudCB3aXRoIHRoZSBmb2xsb3dpbmcgZWxlbWVudHM6
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0
O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRk
aW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5k
OiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyAmcXVvdDtl
cnJvci10eXBlJnF1b3Q7IG9mICZxdW90O2FwcGxpY2F0aW9uJnF1b3Q7LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNG
RkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQt
YnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgJnF1b3Q7ZXJyb3ItdGFnJnF1b3Q7
IG9mICZxdW90O29wZXJhdGlvbi1mYWlsZWQmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3Jk
LWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVh
ay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBPcHRpb25hbGx5LCBhbiAmcXVvdDtlcnJvci1zZXZl
cml0eSZxdW90OyBvZiAmcXVvdDtlcnJvciZxdW90OyAodGhpcyBNQVkgYnV0IGRvZXMgbm90PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2Jh
Y2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5n
OjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBoYXZlIHRvIGJlIGluY2x1ZGVkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQt
YnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr
LWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IE9wdGlvbmFsbHksICZxdW90O2Vycm9yLWluZm8mcXVv
dDsgY29udGFpbmluZyBYTUwtZW5jb2RlZCBkYXRhIHdpdGggaGludHM8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZG
REY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZv
ciBwYXJhbWV0ZXIgc2V0dGluZ3MgdGhhdCBtaWdodCByZXN1bHQgaW4gZnV0dXJlIFJQQyBzdWNj
ZXNzIHBlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRv
bTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5v
bmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgeWFuZy1kYXRhIGRlZmluaXRpb24gJnF1b3Q7ZXN0YWJsaXNo
LXN1YnNjcmlwdGlvbi1lcnJvci1kYXRhc3RvcmUmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoaXMgdGV4dCBpbmNsdWRl
cyBSRkMgMjExOSBsYW5ndWFnZSwgc28gYSByZWFkZXIgd291bGQgc3VyZWx5IGludGVycHJldCB0
aGF0IHRleHQgYXMgYmVpbmcgbm9ybWF0aXZlLjxicj4NCjxicj4NCklmIHlvdXIgd2FudCB0byBi
ZSBub24tbm9ybWF0aXZlIHRoZW4gSSB0aGluayB0aGF0IHlvdSBuZWVkIHRvIHJlcGxhY2UgdGhl
ICZxdW90O3JlcGx5IE1VU1QgaW5jbHVkZSZxdW90OyBzdGF0ZW1lbnQgd2l0aCAmcXVvdDtyZXBs
eSB3b3VsZCBiZSBleHBlY3RlZCB0byBpbmNsdWRlICZxdW90OywgYW5kIHByZWZpeCB0aGUgdGV4
dCB3aXRoLCAmcXVvdDtGb3IgZXhhbXBsZSwgaW4gdGhlIGNhc2Ugb2YgTkVUQ09ORiAuLi4mcXVv
dDs8YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0O2VyaWMm
Z3Q7IEFncmVlLiZuYnNwOyBJLmUuLCBJIHRoaW5rIHdlIGNhbiBtYWtlIHRoZSBjaGFuZ2VzIG5l
ZWRlZCBmb3IgdGhpcyB0ZXh0IHRvIGJlY29tZSBub24tbm9ybWF0aXZlLjwvc3Bhbj48YnI+DQo8
YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjYuIFNlYyA0LjQuMiwgZGVzY3JpcHRpb24gcGFyYWdy
YXBoLiZuYnNwOyBTdWdnZXN0IHRoZSBmb2xsb3dpbmcgY2hhbmdlIHRvIG1hdGNoIHRoZSBhY3R1
YWwgZXhhbXBsZTogJnF1b3Q7PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5tb2Rp
ZnkgdGhlICZxdW90O3BlcmlvZCZxdW90OyBvZiBhIHN1YnNjcmlwdGlvbi48L3NwYW4+PC90dD4m
cXVvdDsgPSZndDsgJnF1b3Q7PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5tb2Rp
ZnkgdGhlICZxdW90O3BlcmlvZCZxdW90OyBhbmQgJnF1b3Q7ZGF0YXN0b3JlDQogWFBhdGggZmls
dGVyJnF1b3Q7IG9mIGEgc3Vic2NyaXB0aW9uLjwvc3Bhbj48L3R0PiZxdW90OzxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl
eHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbHQ7RXJpYyZndDsgQWdyZWUsIHdlIHNo
b3VsZCBtYWtlIHRoaXMgdHdlYWsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGJyPg0KPGJyPg0KNy4gU2VjIDQuNC4yLCBmaXJzdCBwYXJhZ3JhcGggYWZ0ZXIg
ZmlndXJlIDExOiZuYnNwOyBQb3NzaWJsZSByZXdvcmRpbmc6PGJyPg0KPGJyPg0KT2xkOjxicj4N
Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICND
Q0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdCI+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr
LWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBUaGUgcHVi
bGlzaGVyIE1VU1QgcmVzcG9uZCBleHBsaWNpdGx5IHBvc2l0aXZlbHkgb3IgbmVnYXRpdmVseSB0
byB0aGU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206
Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7ICZuYnNwO3JlcXVlc3QuJm5ic3A7IElmIHRoZSBz
dWJzY3JpcHRpb24gbW9kaWZpY2F0aW9uIGlzIHJlamVjdGVkLCB0aGU8L3NwYW4+PG86cD48L286
cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZG
REY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+
Jm5ic3A7Jm5ic3A7IHN1YnNjcmlwdGlvbiBpcyBtYWludGFpbmVkIGFzIGl0IHdhcyBiZWZvcmUg
dGhlIG1vZGlmaWNhdGlvbiByZXF1ZXN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz
dHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpi
cmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgSW4g
YWRkaXRpb24sIHRoZSBwdWJsaXNoZXIgTVVTVCBzZW5kIGFuIFJQQyBlcnJvciByZXNwb25zZS4m
bmJzcDsgVGhpcyBSUEM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp
bi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IGVycm9yIHJlc3BvbnNl
IFNIT1VMRCBjb250YWluIGhpbnRzIGVuY2Fwc3VsYXRlZCB3aXRoaW4gdGhlIHlhbmctZGF0YTwv
c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDti
YWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgc3RydWN0dXJlICZxdW90O21vZGlmeS1zdWJzY3Jp
cHRpb24tZXJyb3ItZGF0YXN0b3JlJnF1b3Q7LiZuYnNwOyBBIHN1YnNjcmlwdGlvbiBNQVk8L3Nw
YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFj
a2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IGJlIG1vZGlmaWVkIG11bHRpcGxlIHRpbWVzLjwvc3Bh
bj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpO
RVc6PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0Ij4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJl
YWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7
IFRoZSBwdWJsaXNoZXIgTVVTVCByZXNwb25kIHRvIHRoZSBzdWJzY3JpcHRpb24gbW9kaWZpY2F0
aW9uIHJlcXVlc3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBJZiB0aGUgcmVxdWVzdCBp
cyByZWplY3RlZCwgdGhlIGV4aXN0aW5nIHN1YnNjcmlwdGlvbiBpcyBsZWZ0IHVuY2hhbmdlZCwg
YW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcu
OXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyB0aGUgcHVibGlzaGVyIE1VU1Qgc2VuZCBh
biBSUEMgZXJyb3IgcmVzcG9uc2UsIHdoaWNoIE1BWXxTSE9VTEQgY29udGFpbjwvc3Bhbj48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5k
OiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0Ij4mbmJzcDsmbmJzcDsgaGludHMgZW5jYXBzdWxhdGVkIHdpdGhpbiB0aGUgeWFuZy1kYXRh
IHN0cnVjdHVyZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJv
dHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgJnF1b3Q7bW9kaWZ5LXN1YnNj
cmlwdGlvbi1lcnJvci1kYXRhc3RvcmUmcXVvdDsuJm5ic3A7IEEgc3Vic2NyaXB0aW9uIE1BWSBi
ZSBtb2RpZmllZDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJv
dHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgbXVsdGlwbGUgdGltZXMuPC9z
cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jmx0
O0VyaWMmZ3Q7IFByb3Bvc2VkIHRleHQgbG9va3MgZmluZSwgd2l0aCBhIHNtYWxsIHR3ZWFrOjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+VGhlIHB1Ymxp
c2hlciBNVVNUIHJlc3BvbmQgdG8gdGhlIHN1YnNjcmlwdGlvbiBtb2RpZmljYXRpb24gcmVxdWVz
dC4gJm5ic3A7SWYgdGhlIHJlcXVlc3QgaXMgcmVqZWN0ZWQsIHRoZSBleGlzdGluZyBzdWJzY3Jp
cHRpb24gaXMgbGVmdCB1bmNoYW5nZWQsIGFuZCB0aGUgcHVibGlzaGVyDQogTVVTVCBzZW5kIGFu
IFJQQyBlcnJvciByZXNwb25zZS4mbmJzcDsgVGhpcyByZXNwb25zZSBtaWdodCBoYXZlIGhpbnRz
IGVuY2Fwc3VsYXRlZCB3aXRoaW4gdGhlIHlhbmctZGF0YSBzdHJ1Y3R1cmUgJnF1b3Q7bW9kaWZ5
LXN1YnNjcmlwdGlvbi1lcnJvci1kYXRhc3RvcmUmcXVvdDsuJm5ic3A7IEEgc3Vic2NyaXB0aW9u
IE1BWSBiZSBtb2RpZmllZCBtdWx0aXBsZSB0aW1lcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5SVzogPGJyPg0KSSB0aGluayB0aGF0ICZxdW90O1NIT1VMRCZxdW90OyBp
dCBiZXR0ZXIgdGhhbiAmcXVvdDttaWdodCZxdW90OyBmb3IgY29uc2lzdGVuY3ksIGFzIHBlciB0
aGUgc2FtZSBkaXNjdXNzaW9uIHBvaW50IGFib3ZlICh3aGljaCBpcyB3aHkgbXkgb3JpZ2luYWwg
dGV4dCB3YXMgTUFZfFNIT1VMRCwgaS5lLiBvbmx5IGEgc2luZ2xlIG9uZSBzaG91bGQgYmUgdXNl
ZCBkZXBlbmRpbmcgb24gaG93IGlzc3VlIDMgYWJvdmUgZ290IHJlc29sdmVkKS48c3BhbiBzdHls
ZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj4mbHQ7RXJpYyZndDsgU0hPVUxEIGlzIG5vdCBhcHByb3ByaWF0ZSBoZXJlLCBhcyB1c3Vh
bGx5IHRoZXJlIHdpbGwgbm90IGJlIGhpbnRzIGVuY2Fwc3VsYXRlZC4mbmJzcDsNCjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxv
OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGJyPg0KOC4gU2VjIDQuNC40LCBubyBmaWd1cmUgbnVtYmVyIHVuZGVyIHRoZSBleGFt
cGxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbHQ7RXJpYyZn
dDsgQWdyZWUuJm5ic3A7IEFsZXgsIGNhbiB5b3UgdHdlYWsgdGhlIFhNTD88L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo5LiBTZWMgNC40LjUs
IHBhcmFncmFwaCAxOjxicj4NCkkgdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgdGhp
cyBqdXN0IHJlZmVycmVkIHRvIFlBTkcgbGlicmFyeSwgaGVuY2Ugc3VnZ2VzdCBjaGFuZ2luZyB0
aGUgZmlyc3QgdHdvIHBhcmFncmFwaHM6PGJyPg0KPGJyPg0KT0xEOjxicj4NCjxicj4NCjxicj4N
CjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7
cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBUbyBtYWtlIHN1YnNjcmlwdGlv
biByZXF1ZXN0cywgdGhlIHN1YnNjcmliZXIgbmVlZHMgdG8ga25vdyB0aGUgWUFORzwvc3Bhbj48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3Jv
dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0Ij4mbmJzcDsmbmJzcDsgbW9kdWxlIGxpYnJhcnkgYXZhaWxhYmxlIG9uIHRoZSBwdWJs
aXNoZXIuJm5ic3A7IFRoZSBZQU5HIDEgbW9kdWxlIGxpYnJhcnk8L3NwYW4+PG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1
O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5i
c3A7Jm5ic3A7IGluZm9ybWF0aW9uIGlzIHNlbnQgYnkgYSBORVRDT05GIHNlcnZlciBpbiB0aGUg
TkVUQ09ORiAmcXVvdDtoZWxsbyZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz
dHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpi
cmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgbWVz
c2FnZS4mbmJzcDsgRm9yIFlBTkcgMS4xIG1vZHVsZXMgYW5kIGFsbCBtb2R1bGVzIHVzZWQgd2l0
aCB0aGUgUkVTVENPTkY8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp
bi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IFtSRkM4MDQwXSBwcm90
b2NvbCwgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZCBieSB0aGUgWUFORyBMaWJyYXJ5PC9z
cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2Jh
Y2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBtb2R1bGUgKGlldGYteWFuZy1saWJyYXJ5Lnlhbmcg
ZnJvbSBbUkZDNzg5NV0uJm5ic3A7IFRoaXMgWUFORyBsaWJyYXJ5PC9zcGFuPjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRG
NTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZu
YnNwOyZuYnNwOyBpbmZvcm1hdGlvbiBpcyBpbXBvcnRhbnQgZm9yIHRoZSByZWNlaXZlciB0byBy
ZXByb2R1Y2UgdGhlIHNldCBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i
bWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1h
bGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgb2JqZWN0IGRl
ZmluaXRpb25zIHVzZWQgd2l0aGluIHRoZSBwdWJsaXNoZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3
b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3Ljlw
dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgVGhlIFlBTkcgbGlicmFyeSBpbmNsdWRlcyBh
IG1vZHVsZSBsaXN0IHdpdGggdGhlIG5hbWUsIHJldmlzaW9uLDwvc3Bhbj48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7
d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJz
cDsmbmJzcDsgZW5hYmxlZCBmZWF0dXJlcywgYW5kIGFwcGxpZWQgZGV2aWF0aW9ucyBmb3IgZWFj
aCBZQU5HIG1vZHVsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu
LWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgaW1wbGVtZW50ZWQgYnkg
dGhlIHB1Ymxpc2hlci4mbmJzcDsgVGhlIHJlY2VpdmVyIGlzIGV4cGVjdGVkIHRvIGtub3cgdGhl
PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0
O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBZQU5HIGxpYnJhcnkgaW5mb3JtYXRpb24gYmVm
b3JlIHN0YXJ0aW5nIGEgc3Vic2NyaXB0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpORVc6PGJyPg0KPGJyPg0KPGJyPg0KPG86
cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk
aW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206
Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IFRvIG1ha2Ugc3Vic2NyaXB0aW9uIHJl
cXVlc3RzLCB0aGUgc3Vic2NyaWJlciBuZWVkcyB0byBrbm93IHRoZSBZQU5HPC9zcGFuPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6
I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQiPiZuYnNwOyZuYnNwOyBkYXRhc3RvcmUgc2NoZW1hcyB1c2VkIGJ5IHRoZSBwdWJsaXNoZXIs
IHdoaWNoIGFyZSBhdmFpbGFibGUgdmlhIHRoZSBZQU5HPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3Jk
LWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZu
YnNwOyBMaWJyYXJ5IG1vZHVsZSwgaWV0Zi15YW5nLWxpYnJhcnkueWFuZyBmcm9tIFtSRkM3ODk1
XS4mbmJzcDsgVGhlIHJlY2VpdmVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr
LWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBpcyBleHBl
Y3RlZCB0byBrbm93IHRoZSBZQU5HIGxpYnJhcnkgaW5mb3JtYXRpb24gYmVmb3JlIHN0YXJ0aW5n
IGE8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45
cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IHN1YnNjcmlwdGlvbi48L3NwYW4+PG86cD48
L286cD48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbHQ7RXJpYyZn
dDsgQWdyZWUsIHdlIHNob3VsZCBtYWtlIHRoaXMgdHdlYWsuPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCllB
TkcgbW9kdWxlOjxicj4NCjxicj4NCjEwLiBUb3AgbGV2ZWwgZGVzY3JpcHRpb24gc3RhdGVtZW50
LCBpdCBsb29rcyBsaWtlIHRoZSBjb3B5cmlnaHQgaGFzIGFjY2lkZW50YWxseSBiZWVuIGluZGVu
dGVkIGJ5IDQgY2hhcnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi
PiZsdDtFcmljJmd0OyBBZ3JlZSwgd2Ugc2hvdWxkIG1ha2UgdGhpcyB0d2Vhay48L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpJZGVudGl0aWVz
Ojxicj4NCjExLiBJIHN1Z2dlc3QgcmVuYW1pbmcgJnF1b3Q7bm8tc3VjaC1zdWJzY3JpcHRpb24t
cmVzeW5jaCZxdW90OyB0byBqdXN0ICZxdW90O25vLXN1Y2gtc3Vic2NyaXB0aW9uJnF1b3Q7LiZu
YnNwOyBJIHdvdWxkIGhhdmUgdGhvdWdodCB0aGF0IHRoaXMgZXJyb3IgY291bGQgYWxzbyBiZSBy
ZXR1cm5lZCB0byBjYW5jZWwgYW4gdW5rbm93biBzdWJzY3JpcHRpb24uPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiZsdDtlcmljJmd0OyBUaGUgcmVhc29uIHdlIG5l
ZWQgJnF1b3Q7bm8tc3VjaC1zdWJzY3JpcHRpb24tcmVzeW5jaCZxdW90OyBpcyB0aGF0DQo8L3Nw
YW4+JnF1b3Q7bm8tc3VjaC1zdWJzY3JpcHRpb24mcXVvdDsgaXMgYWxyZWFkeSB1c2VkIGluIFNO
LiZuYnNwOyAoSS5lLiwgaXMgbm90IHBvc3NpYmxlIHRvIGF1Z21lbnQgdGhlIGV4aXN0aW5nIGlk
ZW50aXR5IHdpdGggYSBuZXcgYmFzZS4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJXOiA8YnI+DQo8YnI+DQpIdW0sIE9LLjxicj4N
Cjxicj4NCkl0IGlzIHNvbWV3aGF0IG9mIGEgc2hhbWUgdGhhdCB0aGUgb3JpZ2luYWwgZXJyb3Ig
Y2FuJ3QganVzdCBiZSB1c2VkIGhlcmUuPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmx0O0VyaWMmZ3Q7IEFncmVl
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K
SSB3b25kZXIgaWYgdGhlIHVzaW5nIG11bHRpcGxlIGJhc2VzIGZvciB0aGUgZGlmZmVyZW50IHN1
YnNjcmlwdGlvbiBlcnJvcnMgaXNuJ3QgdHJ5aW5nIHRvIGJlIHRvbyBjbGV2ZXIuJm5ic3A7IEku
ZS4gSSB3b25kZXIgd2hldGhlciBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8ganVzdCBoYXZlIGEgc2lu
Z2xlIGJhc2UgaWRlbnRpdHkgZm9yIHN1YnNjcmlwdGlvbiBlcnJvcnMuPHNwYW4gc3R5bGU9ImNv
bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
Jmx0O0VyaWMmZ3Q7IFdlIGhhZCB0aGF0IG9yaWdpbmFsbHkuJm5ic3A7IE90aGVyIGNvbW1lbnRl
cnMgcmVxdWVzdGVkIHRoZSBjaGFuZ2UgYmUgbWFkZSBzbyB0aGF0IHRoZSB3cm9uZyBlcnJvciBt
ZXNzYWdlcyBjb3VsZG7igJl0IHBvc3NpYmx5IGJlIGRlbGl2ZXJlZC4NCjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCkFuIGFsdGVybmF0aXZl
IHNvbHV0aW9uIHdvdWxkIGJlIHRvIGRlZmluZSB0aGUgJnF1b3Q7cmVzeW5jLXN1YnNjcmlwdGlv
biZxdW90OyBycGMgaW4gdGhlIGJhc2Ugc3Vic2NyaWJlZCBub3RpZmljYXRpb25zIGRyYWZ0LCBh
bmQgdGhlbiBtYWtlIHVzZSBvZiB0aGF0IFJQQyBoZXJlLiZuYnNwOyBJIHRoaW5rIHRoYXQgaXQg
aXMgc2xpZ2h0bHkgcGxhdXNpYmxlIHRoYXQgYSByZXN5bmMtc3Vic2NyaXB0aW9uIGNvdWxkIHN0
aWxsIGJlIHVzZWZ1bCBpbiB0aGUgY2FzZSBvZiBhDQogcGVyaW9kaWMgc3Vic2NyaXB0aW9uLiZu
YnNwOyBFLmcuIHBlcmhhcHMgc29tZSBjbGllbnQgc2l6ZSBidWZmZXJzIGdldCBvdmVybG9hZGVk
IHNvIHRoZSBjbGllbnQgaGFzIHRvIGRpc3JlZ2FyZCB0aGUgcmVxdWVzdC48YnI+DQo8YnI+DQpC
dXQgdGhpcyBpcyBhIG1pbm9yIHdhcnQsIGhhdmluZyBhIHNlcGFyYXRlIG5hbWUgaXNuJ3QgdGhl
IGVuZCBvZiB0aGUgd29ybGQuJm5ic3A7IE1ha2luZyAmcXVvdDtuby1zdWNoLXN1YnNjcmlwdGlv
bi1yZXN5bmMmcXVvdDsgYWxzbyBoYXZlICZxdW90O25vLXN1Y2gtc3Vic2NyaXB0aW9uJnF1b3Q7
IGFzIGEgYmFzZSBtaWdodCBhbHNvIGJlIHNlbnNpYmxlLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZsdDtFcmlj
Jmd0OyBUaGVzZSBhcmUgYWxsIHBvc3NpYmxlLiZuYnNwOyBCdXQgSSBhbSBob3Bpbmcgd2hhdCB3
ZSBjdXJyZW50bHkgaGF2ZSBpcyBzdWZmaWNpZW50LiZuYnNwOyAoUmlnaHQgbm93IHdlIGhhdmUg
bGltaXRlZCB0aGUgZGVzaWduIHRvIHR3byB0aWVycyBvZiBpZGVudGl0aWVzLiZuYnNwOyBJdCB3
b3VsZA0KIGJlIGdvb2Qgbm90IHRvIGFkZCBtb3JlLikmbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPHNwYW4gc3R5bGU9
ImNvbG9yOiMxRjQ5N0QiPkVyaWM8L3NwYW4+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk
ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+
DQoxMi4gJnF1b3Q7c3luY2hyb25pemF0aW9uLXNpemUmcXVvdDsgZG9lc24ndCBzb3VuZCBsaWtl
IGFuIGVycm9yLCBwZXJoYXBzICZxdW90O3N5bmNocm9uaXphdGlvbi10b28tYmlnJnF1b3Q7IG9y
ICZxdW90O3Jlc3luYy10b28tYmlnJnF1b3Q7IG1pZ2h0IGJlIGJldHRlcj88bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jmx0O2VyaWMmZ3Q7IEkgaGF2ZSBubyBwcm9i
bGVtIHdpdGggY2hhbmdpbmcgaXQgdG8gJnF1b3Q7c3luY2hyb25pemF0aW9uLXRvby1iaWcmcXVv
dDssIHRoYXQgYWxpZ25zIHRvIHRoZSBvdGhlciBpZGVudGl0eSAmcXVvdDt1cGRhdGUtdG9vLWJp
ZyZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N
Cjxicj4NClR5cGUgZGVmaW5pdGlvbnM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48YnI+DQoxMy4mbmJzcDsgQ2hhbmdlIGFsbCBpbnN0YW5jZXMgKGNyZWF0ZSwgZGVsZXRl
LCBpbnNlcnQsIG1vdmUsIHJlcGxhY2UpJm5ic3A7IG9mICZxdW90O2RhdGEgbm9kZSZxdW90OyB0
byAmcXVvdDtkYXRhc3RvcmUgbm9kZSZxdW90Oy4NCjxicj4NCjxicj4NCjE0LiBncm91cGluZyBz
ZWxlY3Rpb24tZmlsdGVyLXR5cGVzLCBhbnlkYXRhIGRhdGFzdG9yZS1zdWJ0cmVlLWZpbHRlciwg
cGVyaGFwcyBhZGQgYSByZWZlcmVuY2UgdG8gJnF1b3Q7UkZDIDYyNDE6IE5ldHdvcmsgQ29uZmln
dXJhdGlvbiBQcm90b2NvbCwgU2VjdGlvbiA2LiZxdW90OywgbWlycm9yaW5nIGRyYWZ0LWlldGYt
bmV0Y29uZi1ubWRhLW5ldGNvbmYuPGJyPg0KPGJyPg0KMTUuIGdyb3VwaW5nIHVwZGF0ZS1wb2xp
Y3ktbW9kaWZpYWJsZSwgY29udGFpbmVyIG9uLWNoYW5nZSBkZXNjcmlwdGlvbiBzdGF0ZW1lbnQs
IG5lZWRzIHRvIGJlIGluZGVudGVkIGJ5IDIgc3BhY2VzLjxicj4NCjxicj4NCjE2LiBncm91cGlu
ZyBoaW50cywgZGVzY3JpcHRpb24sIGluZGVudCB0aGUgc2Vjb25kIGRlc2NyaXB0aW9uIGxpbmUg
YnkgMSBzcGFjZS48YnI+DQo8YnI+DQoxNy4gcnBjIHJlc3luY2gtc3Vic2NyaXB0aW9uLCBkZXNj
cmlwdGlvbiBzdGF0ZW1lbnQsIGxhc3QgdHdvIGxpbmVzIHJlcXVpcmUgYWxpZ25tZW50LjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp
bmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu
ZG93dGV4dCI+Jmx0O2VyaWMmZ3Q7IEkgdGhpbmsgYWxsIGZpdmUgc3VnZ2VzdGlvbnMgYWJvdmUg
YXJlIGdvb2QgdHdlYWtzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhhbmtzLDxicj4NClJvYjxicj4NCjxi
cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5FcmljPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClJvYjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_1c05cc85fb664699bd34ffdde6b40d0eXCHRTP013ciscocom_--


From nobody Tue Sep 11 12:04:15 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98F130EEC for ; Tue, 11 Sep 2018 12:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_HIGH=-0.01, 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 Uh_jJFNQneew for ; Tue, 11 Sep 2018 12:04:10 -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 3911E130D7A for ; Tue, 11 Sep 2018 12:04:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19149; q=dns/txt; s=iport; t=1536692650; x=1537902250; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NJerden7QwsuQJtXhTXxIWM/WesPSnI5vLKZpI42M/I=; b=hIKGI3LvFrA4Q8o419UCM4ydPy2794qGH1mNV9qZJwEd79ycQtC9+BSr ofqjmLVU1V1Et63YzCwf/6P4/kH7IcfkKhAC1cm8+vgAZlAqe1h4z3Ej0 uRfxpyLsDkFeFLtYHPtX+w4ENA97ZQ+3hwDPCfPA+Bmg49uXUGWigZOHt M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAQDUEJhb/4kNJK1RAQkZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBgyQqZX8oCpgggg14lUIUgWYLGAuEA0YCgzAhNhYBAgE?= =?us-ascii?q?BAgEBAm0cDIU4AQEBAQIBAQE4NAkCBQsCAQgOBxARECcLJQIEDgUIE4I7TIF?= =?us-ascii?q?5CA+mcYl+BYpnF4FBP4ESghRJNYMbAQEBgTUBCgEBBgEBSIUmAogFGSqEfYE?= =?us-ascii?q?0hBAMiC5OCQKPfB+BQIRBhAiEbIhLiyYCERSBJSQBMIFVcBU7gmyDNgECh1y?= =?us-ascii?q?FPQFvAYwRBwgXgQiBHgEB?=
X-IronPort-AV: E=Sophos;i="5.53,361,1531785600"; d="scan'208";a="447766643"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2018 19:04:09 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id w8BJ48cd005747 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Sep 2018 19:04:08 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.1395.4; Tue, 11 Sep 2018 15:04:07 -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.1395.000; Tue, 11 Sep 2018 15:04:07 -0400
From: "Eric Voit (evoit)" 
To: Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of subscribed-notifications-16
Thread-Index: AQHUSS2c6fWPWMQnpECqHWzj9l2RFqTpyY1w
Date: Tue, 11 Sep 2018 19:04:07 +0000
Message-ID: 
References: <20180910.194152.138356385922962289.mbj@tail-f.com>
In-Reply-To: <20180910.194152.138356385922962289.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.234]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Sep 2018 19:04:14 -0000

Thanks for the comments Martin,  thoughts in-line...

> From: Martin Bjorklund, September 10, 2018 1:42 PM
>=20
> Hi,
>=20
> I have reviewed this document, and I think it is almost ready.  Here are =
my
> comments:
>=20
>=20
> o  Section 1.4
>=20
>   s/RFC-5277/RFC 5277/

Done

> o  Section 2.1
>=20
>   The text says:
>=20
>     It is out of the scope of this document
>     to identify [...] b) how event records are defined
>=20
>   Is this really what we want?  Shouldn't this document specify that
>   an event record is an instance of a YANG "notification" statement?
>   Do we want to support event records that are not defined in YANG?
>
>   This was discussed in the thread "comments on
>   draft-ietf-netconf-subscribed-notifications-12", and it seems that
>   noone really have any use case for non-YANG-defined event records,
>   accessed with YANG-defined operations.

Yes this was discussed previously.  My reading was that others wanted to su=
pport subscription to non-YANG events.  =20
E.g., see Andy & Tianran's thoughts in
https://www.ietf.org/mail-archive/web/netconf/current/msg14764.html=20

>   I think that this document should state that an event record is an
>   instance of a YANG "notification" statement.  If not, it is unclear
>   both how subtree/xpath filters and xml/json/... encodings would work.

Applying xpath filters against XML based event records seems viable to me. =
 Of course it will be up to the definition of any particular stream to arti=
culate the event record contents sufficiently for filters to be created.

> o  Section 2.1
>=20
>   The text says:
>=20
>     Among
>     these included NETCONF XML event records are individual YANG 1.1
>     notifications described in section 7.16 of [RFC7950].
>=20
>   First of all, does this mean that there can be event records on the
>   "NETCONF" stream that are *not* defined with a "notification"
>   statement?

For the NETCONF stream, personally I only care about things YANG notificati=
on statement.  But looking again at Andy's comment from:
https://www.ietf.org/mail-archive/web/netconf/current/msg14764.html=20
he says "I would say SHOULD be defined in YANG, for the "NETCONF" stream." =
  So for -v16 I updated the text in a way that doesn't preclude this. =20
=20
>   Second, this seems to imply that *all* notifications defined in all
>   YANG modules end up in the "NETCONF" stream, but I don't think this
>   is the intention.  At least I hope so.  ("yp:push-update" is an
>   example of a notification that will not be sent on the "NETCONF"
>   stream.)

The NETCONF stream has a very broad/inclusive definition in RFC-5277.  This=
 definition is: "This stream contains all NETCONF XML event notifications s=
upported by the NETCONF server".

To me, thinking about how that statement and applying it to YANG, this tran=
slates as YANG 1.1 notifications should go into the NETCONF stream, unless =
explicitly excluded.  This provides a very simple way determining which typ=
es of notifications should be placed on the stream.  (Otherwise, how is a d=
eveloper of a YANG notification supposed to know whether it should go into =
the NETCONF stream or not?  The alternative would seem to be having each no=
tification opt-in to the NETCONF stream.)

So if you agree with this reasoning, how about:

The "NETCONF" event stream contains all instances of YANG 1.1 notifications=
 generated by a publisher, except where a type of notification has explicit=
ly been excluded from the stream.=20
=20
>   Further, the text says:
>=20
>     Each of these
>     YANG 1.1 notifications will be treated as a distinct event record.
>=20
>   This seems to confuse the schema definition with specific instances;
>   it is not the schema definition that is treated as a disctinct event
>   record, but the notification instances.
>=20
>   So, I suggest that these two sentences are removed.

Removed.

> o  Section 2.4.1
>=20
>   OLD:
>=20
>    o  A delete or kill RPC will end the subscription, as will the
>       reaching of a "stop-time".
>=20
>   NEW:
>=20
>    o  A "delete-subscription" or "kill-subscription" RPC will end the
>       subscription, as will the reaching of a "stop-time".

updated

> o  Section 2.4.1
>=20
>   OLD:
>=20
>       Successful
>       modification returns the subscription to an active state.
>=20
>   NEW:
>=20
>       Successful
>       modification returns the subscription to the active state.

updated

> o  Section 2.4.2
>=20
>   The text says:
>=20
>     The transport selected by the subscriber
>     to reach the publisher MUST be able to support multiple "establish-
>     subscription" requests made within the same transport session.
>=20
>   This seems to indicate that RESTCONF cannot be used with this
>   specification, since RESTCONF doesn't have sessions.

The desired behavior is that a subscriber can request multiple subscription=
s without each requiring a separate transport session establishment.  I thi=
nk we are ok here with RESTCONF because underneath RESTCONF is HTTP, TLS, T=
CP.  And each of those lower layers can have sessions. =20

To clarify further, I have tweaked the text to:

"The transport selected by the subscriber to reach the publisher MUST be ab=
le to support multiple "establish-subscription" requests without each requi=
ring a separate persistent transport connection."

>   This makes me wonder, why does this document specify this
>   requirement?  I agree that this is the behaviour we want from
>   NETCONF, but then I think that should be defined in the
>   netconf-notif draft.

By saying something in SN about this requirement, I believe we can preclude=
 an implementation which can only support one subscription per subscriber. =
 In any case, the specific "how" details will still need to be articulated =
in each transport draft.

> o  Section 2.4.2
>=20
>   s/"start-time"/"replay-start-time"/  (3 occurrences)

Fixed

>   Also, the text says that the replay-start-time MUST be in the past.
>=20
>   Suppose the server receives a "replay-start-time" of 12:00:00.001,
>   and the replay buffer is empty.
>=20
>   A) If the current time is 12:00:00.002, the request is accepted, and
>      a "replay-completed" notif is sent.
>=20
>   B) If the current time is 12:00:00.000, the request is rejected with
>      an error.
>=20
>   Why is this important?  Why not simply just send the
>   replay-completed notif in both cases?

For (B), if an event occurs at 12:00:00.0005, should it be sent?  Should it=
 be sent before or after the "replay-start-time"?  How long should we allow=
 the clocks to drift before we reject the subscription?    As we don't supp=
ort future/pending subscriptions, we don't have to worry about these questi=
ons with the current definition. =20

> o  Section 2.4.2.1
>=20
>   OLD:
>=20
>    If the time the replay starts is later than the time marked within
>    any event records retained within the replay buffer, then the
>    publisher MUST send a "replay-completed" notification immediately
>    after a successful establish-subscription RPC response.
>=20
>   NEW:
>=20
>    If the given "replay-start-time" is later than the time marked within
>    any event records retained within the replay buffer, then the
>    publisher MUST send a "replay-completed" notification immediately
>    after a successful establish-subscription RPC response.

Change made

> o  Section 2.4.2.1
>=20
>   There is no text that explains what happens in the "succesful" case;
>   i.e., when there are buffered event records with time greater than
>   or equal to the requested "replay-start-time".
>=20
>   Maybe the first paragraph is supposed to cover this, but it just
>   says "meets the timeframe criteria", which is a bit vague.

This was supposed to be covered by the first paragraph.  To help clarify, I=
 have updated the text to:

"In other words, as the subscription initializes itself, it sends any event=
 records within the target event stream which meet the filter criteria, whi=
ch have an event time which is after the "replay-start-time", and which hav=
e an event time before the "stop-time" should this "stop-time" exist."

> o  Section 2.4.5
>=20
>   OLD:
>=20
>     A publisher MUST terminate any dynamic
>     subscription identified by RPC request.
>=20
>=20
>   NEW:
>=20
>     A publisher MUST terminate the dynamic
>     subscription identified by the "identifier" parameter in the RPC
>     request, if such a subscription exists.

updated

> o  Section 2.4.6
>=20
>   The text says:
>=20
>     1.  "establish-subscription-stream-error-info": This MUST be returned
>         if an RPC error reason has not been placed elsewhere within the
>         transport portion of a failed "establish-subscription" RPC
>         response.
>=20
>   (and similar for the other errors)
>=20
>   What exactly does "if an RPC error reason has not been placed
>   elsewhere" mean?

The intent is to match how NETCONF & RESTCONF historically handles errors. =
 As you know with NETCONF, each error identity will be inserted as the "err=
or-app-tag".  And therefore placing the YANG data "establish-subscription-s=
tream-error-info" would be redundant.  For NETCONF,  "establish-subscriptio=
n-stream-error-info" are only needed when hints to be provided.

Therefore assuming you are looking for an alternative way to make this poin=
t, I have tweaked the text to:=20
"This MUST be returned if an RPC error reason has not been mapped down into=
 transport specific error objects contained within a failed "establish-subs=
cription" RPC response."

> o  Section 2.5.1
>=20
>   In the second diagram (for the valid state), the states are called
>   "receiver connecting", "reciever timeout" etc.  I find this a bit
>   confusing; it is not the *receiver* that is connecting, it is the
>   publisher.  Ok, the legend then says:
>=20
>      dashed boxes which include the word 'receiver' show the possible
>      states for an individual receiver
>=20
>  But since all dashed boxes include the word "receiver", and the  diagram
> specifically is the state machine *per receiver*, maybe we  can simply re=
move
> the word "receiver" from the boxes?

There have been some discussions on this.  I agree it is certainly valid to=
 remove "receiver" from these four boxes.  However I have found that gettin=
g readers to really internalize that the state machine is actually per-rece=
iver rather than per-subscription, it seems to go faster/cleaner when recei=
ver is shown in the four boxes. =20

Nevertheless, if you absolutely want "receiver" removed from the boxes, I c=
an do that.  =20

> o  Section 2.5.2
>=20
>   s/details."/details./

Fixed

> o  Section 2.5.6
>=20
>   I know that this feature was presented in Montreal.  I think it is
>   problematic, and suggest it is removed.

This issue was discussed in Montreal.    The feature is of course is option=
al.  There are a large number of downsides for someone who chooses not to i=
mplement for certain use cases.  Please see the Montreal slides and the lon=
g threads with Kent for more details.  If you want to pursue this further i=
t is probably best to start a new thread dedicated to this topic alone.

>   For example, what happens if the transport session is lost and
>   re-established; are all event records in the buffer replayed again?

No.  The publisher will not lose context of what was sent.
=20
>   What happens if a new receiver is added to a subscription that
>   already has a receiver, will all events in the buffer be replayed to
>   the new receiver?

Yes.  (To clarify, I added "to each configured receiver" at the end of the =
last sentence of the first paragraph.)

>   When a new subscription is configured with configured-replay set,
>   the publisher will immediately try to connect to the publisher and
>   send all buffered event from the last reboot.  Is this really
>   useful?

Yes.  See the security cases reviewed on the earlier threads with Kent.  If=
 someone doesn't care about log entries since boot, they simply don't have =
to implement this optional feature.

>   If the mechansim relies on the subscriber being able to also use
>   dynamic subscriptions for replay of all event records, maybe we
>   could simplify things by always relying on dynamic subscriptions for
>   replay for configured subscriptions.  Specifically, remove
>   "configured-replay" etc, but keep the "replay-previous-event-time"
>   in the "subscription-started" notification.  Then a subscriber can
>   simply check this value to see if anything is missing, and if it is,
>   use a dynamic subscription to request replay from the latest time he
>   knows about.

This is a valid approach, and can be used as an alternative to this optiona=
l feature.  However there are still many downsides to the alternative.  See=
 the slides from Montreal, as well as the previous thread discussions for d=
etails.

> o  Section 2.6
>=20
>   It just occurred to me that this text about using the 
>   message shouldn't be in this document, but in the netconf-notif (and
>   restconf-notif) document.  It is highly transport and encoding
>   specific.

I think you are referring to both the sentence: "This notification message =
MUST be encoded in a  message as defined within [RFC5277], Se=
ction 4.  And per [RFC5277]'s "eventTime" object definition, the "eventTime=
" is populated with the event occurrence time."  As well as to the example =
compliant message in Figure 10.

While the text could be extracted and placed in the netconf-notif document,=
 extracting it fully from SN would leave no baseline message format.  Perha=
ps others will have a problem if the SN solution does not have some pre-def=
ined structure to hold event records?

I can move this if I hear no objection.   As you know, I am hoping that dra=
ft-ietf-netconf-notification-messages at some point displaces the  message of [RFC5277], Section 4.    And this is easier to do with few=
er references to RFC5277 within SN.

> o  Section 2.7
>=20
>   This section talks about "subscription state" notifications.  But in
>   many places in the document, you use the term "state change"
>   notification.  I suggest pick one term and use it consistently, to
>   avoid confusion.

Updated to subscription state change notification

> o  Section 2.8
>=20
>   s/operational datastore/operational state datastore/
>=20
>  (four occurrences)

updated

> o  Section 4
>=20
>           action reset {
>             if-feature "configured";
>             description
>               "Allows the reset of this configured subscription receiver
>=20
>   This action will be available also for dynamic subscription, if the
>   server supports the "configured" feature.  Maybe add:
>=20
>     when "../../../configured-subscription-state";

This would be nice to have.  But action doesn't support "when" as an allowe=
d sub-statement.

> o  Section 4
>=20
>   Should the rpc kill-subscription be marked with
>   nacm:default-deny-all?  Otherwise, by default, anyone can terminate
>   any other's subscriptions.

This is a good idea.  Added.

> o  Section 4
>=20
>   I suggest that the leaf /filters/stream-filter/identifier is renamed
>   to "name", for consistency, and that it is of type "string", and
>   that the type "filter-id" is removed, for consistency and
>   simplicity.

Done

>   Also, I suggest that the leaf /subscriptions/subscription/target/
>   stream-filter/by-reference/stream-filter-ref is renamed to
>   "stream-filter", or maybe "stream-filter-name".

Done.   (It is now 'stream-filter-name')

> o  Section 4
>=20
>   I suggest that the subscription's key leaf "identifier" is
>   renamed to simply "id".  This would match the name of the type which
>   is "subscription-id".
>=20
>   (it is also consistent with other (not all) IETF models, where a
>   "name" is used for an arbitrary string key, and "id" for a more
>   strict key, often some integer type)
>=20
>   NOTE: yang push should also be changed to use the same naming
>   convention

Change made.   Alex knows to make this to YANG Push as well.

> o  Section 4
>=20
>   I suggest the counters "count-sent" and "count-exlcuded" are renamed
>   to something more descriptive, perhaps "out-event-records" or
>   "sent-event-records", and "excluded-event-records" or
>   "dropped-event-records", respectively.

Changed to "sent-event-records" and "excluded-event-records".

> o  Section 4
>=20
>   I suggest you consistently format the YANG module wrt. spaces etc.
>   Also, some lines are longer than 69 characters and should be
>   adjusted.

All lines are no longer that 69 characters now.
=20
>   You can use pyang --ietf --max-line-length 69 to help with the
>   latter, and pyang -f yang --keep-comments to help with the former.
>   (note that you may need to manually fix the output of pyang -f,
>   e.g. if some lines are too long)
>=20
>=20
>   (The RFC editor checks this, so it is better to do it now)

Done.=20

> o  Section 4
>=20
>   OLD:
>=20
>     "This feature indicates support for xpath filtering.";
>=20
>   NEW:
>=20
>     "This feature indicates support for XPath filtering.";

Updated.

> o  Section 4
>=20
>   With the inclusion of "replay-start-time-revision", shouldn't the
>   identity "history-unavailable" be removed?

Removed.

> o  Section 4
>=20
>   identity no-such-subscription {
>     base modify-subscription-error;
>     base delete-subscription-error;
>     base subscription-terminated-reason;
>     description
>      "Referenced subscription doesn't exist. This may be as a result of
>       a non-existent subscription ID, an ID which belongs to another
>       subscriber, or an ID for configured subscription.";
>   }
>=20
>   s/ID/id/

Updated

> o  Section 5.4
>=20
>    s/publisher"/publisher/

Updated

> o  Appendix A
>=20
>   Since this appendix defines an example module, it needs to be named
>   accordingly.  Specifically, the module should be called
>   "example-foo-subscribed-notifications", and the namespace should be
>   "urn:example:foo-subscribed-notifications".
>=20
>   (with this change, you can also remove the note to the RFC editor)

Updated

> o  Appendix A
>=20
>   The name of Figure 21 should be changed:
>=20
>   OLD:
>=20
>            Figure 21: Example Transport Augmentation for NETCONF
>=20
>   NEW:
>            Figure 21: Example Transport Augmentation for the
>            fictitious protocol foo

Done.   And thanks!

Eric

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


From nobody Tue Sep 11 12:26:59 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65865130F1B for ; Tue, 11 Sep 2018 12:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham 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 4AEIPzgPnr2l for ; Tue, 11 Sep 2018 12:26:54 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 B3BEB130F2B for ; Tue, 11 Sep 2018 12:26:54 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8BJJVrX007716; Tue, 11 Sep 2018 12:20:47 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=PGD0KdVw2EKGuF2UVU8tRfYUxDbTpIndmDh19CXNDf0=; b=ftBshHVqvSXr13ILITNkx4IdjWdnVzOsrBd50uafJbu8W8d1tZNhgH2BRP8+upE2wv8J V8oAH9mNfC80+VvAxc+0M351AovnSgk0Ab95i14khfSegzNVQwvacDRXk/phJ8+flry6 /px1nJmd2GCHBYOLIZgIMyrnvtjORAPvdABpnYTbQ8Y6CyWU4a7M6PoJLTL80BCdjHaq VNi8eQptm5tWrReKSP/XCWlWfKyJoDnqa5XiU1FX1xTPRR3yDAXHE3Xl55CzmlauyA7P mUGATwXuKCON8JircL+Qym/qVKCn5pLGecOh8LPBoWHReW+Hp9FjBjw9P7afiF4hsE94 Kw== 
Received: from nam05-by2-obe.outbound.protection.outlook.com (mail-by2nam05lp0243.outbound.protection.outlook.com [216.32.181.243]) by mx0a-00273201.pphosted.com with ESMTP id 2mejty03f5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 11 Sep 2018 12:20:47 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4122.namprd05.prod.outlook.com (20.176.72.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.6; Tue, 11 Sep 2018 19:20:46 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1143.010; Tue, 11 Sep 2018 19:20:46 +0000
From: Kent Watsen 
To: Martin Bjorklund 
CC: "j.schoenwaelder@jacobs-university.de" , "netconf@ietf.org" 
Thread-Topic: [Netconf] netconf call home connection type
Thread-Index: AQHUOUk8IdLBwLq95EWszUO4eDF4yKTKZDSAgAESIICAA7pUAIAEHU8AgADmugCAAJdjAIAAUaEAgAB3VoCAAB6KgIAAqSQAgACmc4CAAOQtgIAAjK4AgAEzsICAAA+kAIAAiuMAgAQSqgCAC4K2gIAA+SyAgACCpoA=
Date: Tue, 11 Sep 2018 19:20:45 +0000
Message-ID: 
References:  <20180903.105436.927964486928721459.mbj@tail-f.com> <8BAC2AAA-0E70-4EDA-B6A8-E4F94445D2F0@juniper.net> <20180911.093307.1050612475582993510.mbj@tail-f.com>
In-Reply-To: <20180911.093307.1050612475582993510.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4122; 6:uA7xP1MnGoGZOck3furCq66+asdt3KN/4laKlUnBZEwSIgezp04W6IC7qAGnfstm5pe30hXG89h2afyfodGSHxXHpeeInzMh9tEzVXiN91Oy6hBcdNkYLW4pih1WASI3sOWPBzD/nNSBsVmlziuZO7qxfu4yRCkWBXYpr+/d0NKFQSKjby928Nefi8SKRWwisQ1gqJSzSAQVM6IFHaFWuFlOj7H4rP4rNdAFqxIYrmLc4AkQWxQCzHC5r+7bEgCXep2mREtB35GR3lWFSPWzLNxhWf7sXG+xZAnMrZ6Mh1voE0sZ8ZYz2iPwKxjswx/2OTKDrDgbPJTlck1K3GZC62pdx00lD3jKZMQFv6Ig7wXldt42+v9gopHomkSCYuTA7jorp3OZwKZ2Qk6oe9CKwNGLijXd/IGJ/TFZK43f1aU6yE/8shkY+4143uMNCq6kTMF2X1kW9sWD1RNRbFwNbw==; 5:7rg185DFiqykzbAZ6nwdhvSv6MqK83lmLuU03zEvw2N/neH1j6DOflGBKemAy0ZHiGGMMkW338sYMWWp56hX32A2WdrEUGke7oCvhJlSKEIIi8t32oh+CB/D6nIwdiMvwZl7JV1eKU3J63kUeYvmJdFgdhIVs4MIjqT71Yq7FxU=; 7:aRTyi9q9i6nmp7/+MIoYMYk/yB/1tPhkZ1AgGbCngmX4/MEizX0wK7uifGAhX3nJuitSr00bYtOsZa5DTA3prgwx5PfJ+7nfaCfSSQEe/MMXMeNdPU8JffrxiqWxjnY1gDpsEUAv478MHFAjY341TMHN6eorcl4P2ybMyQK+DJKNe8lanM4uZ3Sn/9TvPsuUKz2TaK2Gn9qD+78Ue/yirfXywByQ5lkhaXSZLYTKazmCsljEpc6s3cR+fX8CJe7w
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 9c026440-35dd-469e-1230-08d6181bacc5
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4122; 
x-ms-traffictypediagnostic: DM6PR05MB4122:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231311)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201708071742011)(7699050); SRVR:DM6PR05MB4122; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4122; 
x-forefront-prvs: 0792DBEAD0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(346002)(376002)(366004)(396003)(189003)(199004)(36756003)(97736004)(105586002)(106356001)(58126008)(82746002)(6506007)(54906003)(6486002)(66066001)(2906002)(99286004)(93886005)(186003)(81156014)(83716003)(26005)(8936002)(229853002)(6436002)(81166006)(2900100001)(305945005)(86362001)(68736007)(6246003)(8676002)(478600001)(6916009)(11346002)(4326008)(2616005)(7736002)(5660300001)(5250100002)(446003)(6512007)(33656002)(316002)(102836004)(14444005)(256004)(25786009)(53936002)(14454004)(6116002)(3846002)(76176011)(476003)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4122; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Rzi/XYCTwC3SetqRCe2mZWPXIdjMRiEymT9NjRxO3MmTXVpjj4VSGcOJPhMIp37IY9txULePYHJK6fY4wjp2iHYPzwZoDiRnb2L1k+ZmP9L/qIbjdI1hyroaFEV18ekpkiZts6v8X6BIJTVn6Zblh5qAs+RNqtzaFNi0IXEi3IYLpKThlc4oxDzkuIKJ6oVZ6ElonfJ9SwzzhJBjsv5V4rlI04Rr3iiFhqGCekHzdHwGb5WiLGNw3s5Mhf1ryHlB5veFBA/eeLNfsZDD/KW7W/VEWk96QLOHEo3IHu0pnKRxk0YJVhnV50aSihT7xZkmrKiHF7/FT+kndbJlmDtMFFmnTYKyYrvYOJHwN9krGic=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <4446F75477F77E4CA3D09A5826B63819@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c026440-35dd-469e-1230-08d6181bacc5
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2018 19:20:46.0263 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4122
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-11_09:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809110189
Archived-At: 
Subject: Re: [Netconf] netconf call home connection type
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Sep 2018 19:26:58 -0000

DQo+IElmIHdlIGhhdmUgdGhlIHJwYywgaXQgaXMgbGVzcyBicm9rZW4uICBJIHdvdWxkIHByZWZl
ciB0byBkZWZpbmUgdGhlDQo+IHJwYyBpbiBTTiBub3cuICBTaW5jZSB3ZSBkZWNpZGVkIHRvIHdv
cmsgb3V0IHRoZSBkZXRhaWxzIGZvcg0KPiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMgbm93IGlu
IFNOLCBJIGRvbid0IHRoaW5rIHdlIGNhbiBpZ25vcmUgdGhpcw0KPiBpc3N1ZS4NCg0KQWdyZWVk
LiAgV2l0aG91dCB0aGUgInJlYXNvbiIgaWRlbnRpdHksIGFuIG9wZXJhdG9yIGNvdWxkIHN0aWxs
IGtub3cNCnRoYXQgY2VydGFpbiBjYWxsLWhvbWUgY29ubmVjdGlvbnMgKGUuZy4sIHRvIGEgc2Vy
dmVyIG9yIHBvcnQpIGFyZSBvbmx5DQpmb3IgY29uZmlndXJlZC1zdWJzY3JpcHRpb25zLiAgQnV0
LCB3aXRob3V0IGFuICJhY3RpdmF0ZS1jb25maWd1cmVkLQ0Kc3Vic2NyaXB0aW9uIiBSUEMsIHRo
ZXJlIHdvdWxkIGJlIG5vIHdheSB0byBzdGFydCB0aGUgZmxvdyBvZiBldmVudA0Kbm90aWZpY2F0
aW9ucy4gIENhbiB5b3UgcGxlYXNlIGhlbHAgcmFpc2UgdGhlIG5lZWQgZm9yIGFuIFJQQyBpbiB5
b3VyDQpTTiBMQyByZXZpZXc/ICANCg0KDQo+IFRoZSBpZGVudGl0eSBpcyBsZXNzIGltcG9ydGFu
dCBpbW8uICBBbmQgb2YgY291cnNlLCB0aGUgaWRlbnRpdHkgaXMgb2YNCj4gbm8gdXNlIHVudGls
IHRoZSAiY2FsbC1ob21lLXJlYXNvbiIgZGF0YSBtb2RlbCBoYXMgYmVlbiBkZWZpbmVkLi4uDQoN
ClllcywgbGVzcyBpbXBvcnRhbnQgZm9yIHRoZSByZWFzb24gbWVudGlvbmVkIGFib3ZlLg0KDQoN
CktlbnQgLy8gY29udHJpYnV0b3INCg0KDQoNCg==


From nobody Tue Sep 11 12:36:05 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A3A130F36 for ; Tue, 11 Sep 2018 12:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wUCKV3Kz-ov for ; Tue, 11 Sep 2018 12:36:03 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9352130F29 for ; Tue, 11 Sep 2018 12:36:02 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id x26-v6so21340925lfi.7 for ; Tue, 11 Sep 2018 12:36:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=06R8iNwxISaBUQOmMtm+4OA5E3uYjOZFm64RMX4WCA0=; b=Xy4a+Ij5bdCZmMFat6xFHmCJkwjukvRVSKPr4WBfC/C5J2UnN8Y2rPLVmKShx9kgBe XCuWJ7W8ryOHuws6BYunk2r7nqt7gHQXgTKwcuoi/eeUljwVwEQdxheHtxuXJ4sDJTOV xgEKCIiroE55K0VlTdmUKMKq85jTs27xpRIJv9g1/EPFk3OKlf2STt36YhAu33z5IUbO dpedMkNJTvF8Y/RrMzKCdG/JZ6u6vHgdj03xJtXXbxA4RP/Yqly+SPuw7SKy4hsRrjOd b330znEUlr0zDLV1La7oQLVMckEg/IZs88nYPL4CoKBJa0d0BbCloo8NxMYN57TMfLyc pobw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=06R8iNwxISaBUQOmMtm+4OA5E3uYjOZFm64RMX4WCA0=; b=VMdGK2XCduXHNPAJ2rwE9/pJqZ+SheF1/BxK72x/17GDTqT2bjaAidXiZKfAAvqhPp Xx7L8AiH+GItLNoimB/Q4njdmzVdDCj32bfWnUkL5Z8x6EJW3ts3PxhcvCPOmYp7wIoG LauLPeth6vI8Ls7//oVdO+0bYT+tatQMwZWGBoOE3fexBhfs+eM/H3J2Uts1zYhiR9Jc T+NivVbAZEFAk9vz2LfkhBE/169wJRjKWNYxB5RefOrtdIXiw/BCWBwIofuBLJZeLHLw pU+eRj0wmgxAAtpLAyYY3DxSvOXo/EHmyiZ5DIRGPXZ5fFUNKfBFtF3ObyeNzVrwaMEq WWxg==
X-Gm-Message-State: APzg51A9yn+WDO+V3wBVT6TxCTPWJ7ANPpodnt860N0EVHNW83r96ujG q2wvCqN69daJZXV8CRIJ5ELiAmfq3r2IaECC7ErBeA==
X-Google-Smtp-Source: ANB0VdbacEWxZ0oJBhMsQyN2AG1Kc3ij9JOERYf6IQF0dq5v5BS/NtaZsV4SAo2l5F822QWyG45wvu1TPCLA4taRkWs=
X-Received: by 2002:a19:8c55:: with SMTP id i21-v6mr16776329lfj.90.1536694560603;  Tue, 11 Sep 2018 12:36:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:48c9:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 12:35:59 -0700 (PDT)
In-Reply-To: 
References:  <20180903.105436.927964486928721459.mbj@tail-f.com> <8BAC2AAA-0E70-4EDA-B6A8-E4F94445D2F0@juniper.net> <20180911.093307.1050612475582993510.mbj@tail-f.com> 
From: Andy Bierman 
Date: Tue, 11 Sep 2018 12:35:59 -0700
Message-ID: 
To: Kent Watsen 
Cc: Martin Bjorklund , "netconf@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000069cb5005759d95ad"
Archived-At: 
Subject: Re: [Netconf] netconf call home connection type
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Sep 2018 19:36:05 -0000

--00000000000069cb5005759d95ad
Content-Type: text/plain; charset="UTF-8"

On Tue, Sep 11, 2018 at 12:20 PM, Kent Watsen  wrote:

>
> > If we have the rpc, it is less broken.  I would prefer to define the
> > rpc in SN now.  Since we decided to work out the details for
> > configured subscriptions now in SN, I don't think we can ignore this
> > issue.
>
> Agreed.  Without the "reason" identity, an operator could still know
> that certain call-home connections (e.g., to a server or port) are only
> for configured-subscriptions.  But, without an "activate-configured-
> subscription" RPC, there would be no way to start the flow of event
> notifications.  Can you please help raise the need for an RPC in your
> SN LC review?
>
>

It may be hard to separate implementation details from the standard details.

IMO configured subscription delivery connections could very well be 1 way
and the receiver may not be designed to send anything to the publisher
(like SNMP).

This is completely different than CallHome, where the purpose is to
establish
a NETCONF or RESTCONF session (neither of which allows ANY server-initiated
operations). So this "activate-configured-subscription" RPC is needed for
CallHome,
not really for all configured subscriptions.



>
> > The identity is less important imo.  And of course, the identity is of
> > no use until the "call-home-reason" data model has been defined...
>
> Yes, less important for the reason mentioned above.
>
>
> Kent // contributor
>
>

Andy



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

--00000000000069cb5005759d95ad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, Sep 11, 2018 at 12:20 PM, Kent Watsen <kwatsen@juniper.net> wrote:


> If we have the rpc, it is less broken.=C2=A0 I would prefer to define =
the

> rpc in SN now.=C2=A0 Since we decided to work out the details for

> configured subscriptions now in SN, I don't think we can ignore th=
is

> issue.



Agreed.=C2=A0 Without the "reason" identity, an operator could st=
ill know

that certain call-home connections (e.g., to a server or port) are only

for configured-subscriptions.=C2=A0 But, without an "activate-configur=
ed-

subscription" RPC, there would be no way to start the flow of event
notifications.=C2=A0 Can you please help raise the need for an RPC in your<=
br>
SN LC review?=C2=A0 




It may be hard to separ=
ate implementation details from the standard details.

<=
div>IMO configured subscription delivery connections could very well be 1 w=
ay

=


=C2=A0



> The identity is less important imo.=C2=A0 And of course, the identity =
is of

> no use until the "call-home-reason" data model has been defi=
ned...



Yes, less important for the reason mentioned above.





Kent // contributor




Andy



--00000000000069cb5005759d95ad--


From nobody Tue Sep 11 12:41:05 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2D1130F1F for ; Tue, 11 Sep 2018 12:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 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, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7cN6Uu746c2u for ; Tue, 11 Sep 2018 12:41:02 -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 EC7F1130F29 for ; Tue, 11 Sep 2018 12:41:01 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8BJdnVp013769; Tue, 11 Sep 2018 12:40:59 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=qvuptQEequR5ar4Mh19jwwET/ZrIIh0bsZtbyxDvbU4=; b=ARQK6KxXsMIU/oaZdsiUzW7XindFWiFaETwGzL1BZI/B1VnFrKi3eON33L+DwDFy5hg+ ZyvlhAgnuOLbXd3x+7D+eqaJ0n3TJhvEA8NmcGdntI10X3SnXRzNmc9X5BBPafVWENOq U98Y7zNh17c4m1w24XrRueFyGO3/zw1ZK6hGWELL3aaLuW425cHDweejy38P1J3QNUph tMPm0eGEPwMsjROKjvmNUVBMdM4IfnAxfV9E+ICxWb35c1Xl7jrUB9ufNx7QVfXYkk8f wseJQSCfsvRVG5ENVnTnrm/79MtDw8CroznG/felIW3GAu+sxZWxPWkz6p/ULKklFLrD 8A== 
Received: from nam05-by2-obe.outbound.protection.outlook.com (mail-by2nam05lp0241.outbound.protection.outlook.com [216.32.181.241]) by mx0b-00273201.pphosted.com with ESMTP id 2mehc68ce6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 11 Sep 2018 12:40:59 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4362.namprd05.prod.outlook.com (20.176.78.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.11; Tue, 11 Sep 2018 19:40:57 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1143.010; Tue, 11 Sep 2018 19:40:57 +0000
From: Kent Watsen 
To: Martin Bjorklund 
CC: "balazs.kovacs@ericsson.com" , "balazs.lengyel@ericsson.com" , "netconf@ietf.org" 
Thread-Topic: [Netconf] Mandatory local configuration in Keystore groupings
Thread-Index: AQHUE4rJV5t3ZASQT0G65kk51KFdjKSAiWUAgEnK74CAACpJAIABPX8AgAOrEACABC+ZAIAAwASAgAC9gACAAHNjgIAAFAaAgAEgEwCAAicPgIAF1PmAgAF1VYCACj3EgIAAtxgAgACClQA=
Date: Tue, 11 Sep 2018 19:40:57 +0000
Message-ID: <1F126D9A-775C-4590-A645-6529C3066C14@juniper.net>
References: <20180903.121823.1406711858636851159.mbj@tail-f.com>  <185C7E6D-7EF1-4FFE-9A9B-74BA7E16D946@juniper.net> <20180911.095334.2041631968993039535.mbj@tail-f.com>
In-Reply-To: <20180911.095334.2041631968993039535.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4362; 6:leZFdRT7FdGmH7p5iNHkCE9DHg4DohMefqxGcqfKKhUfUvulLVnryz7DnDuGv3U7OG/0NK0RKUrpYN5S/CWn5sQGq1gJGCwx25zMIUH1/V8/SNZHMmp7Kr2t/p1uzNZmBxeVE4ILPD5MLW52XEqJ9ugLA166drWrfgcQScta+f8pZPzqYoMJ5RloO4Tfz5n9uJfHnUlTwSerg2leWwM8koTuF9cH/T2yo0i16a76xR60snclO0k9Zm2GTK7oNSXRG0F9U+H67Rk4lDvvCZsKRLMf4ijn8qSeq1Wnz6dornEGL5YvcwiOViQrcG4/rlcOTTxr38TkITX0DcF8Vez++pHjIEk5NY23OeXrn7Hpncomx1BsRmLxlOMzQDfc46mxNCV42jFK8CTGTPWp/16BR+9QdwetRq2jNFHKJTPrsf+7vzhDev2VjumVuuzLVvUikhzqY9xjt8Vvkgoru77f/w==; 5:VcklYgS8HGb5rG8HGNThVb1c/z3LsjMhfYFBTE9i4LpPiqlrYjtOFS8FAqIcxOpTKZaAq+3RLnL3XcLDjwvVccGvqHbhDjYIbuKRIoErfxiAfhJo0GPppLH2PFklS8iPViFx8KpFtEpOd2SxJyyLgavic2Ssdl8yoqlbxhI0V5o=; 7:NUAmRX/72HGwOwX+pry8yeIzQrb8C7uRbrds7x8scmC8ViLoLGGcgRTy2/kotaaVo+vXOh4waAzKE2QeIM/kyJchV8wyk0O2+xTSdJPdnKGVqb3XMmE7GiHifODX+sV0qXBVyQ32xR9LQjvGuRzxQqrdreP6vJ6/hmJgwhIx4U7rCxF79+s2peG8sfdPTV5Dvd+Oyef3kCUBoODT9JxU7s4+/DcoAbBAhPpZ6DP70wUDlhHp8cESQ9bzTb0+yX9d
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 70466042-abcf-40f3-2326-08d6181e7ea9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4362; 
x-ms-traffictypediagnostic: DM6PR05MB4362:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(17755550239193);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231311)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699050); SRVR:DM6PR05MB4362; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4362; 
x-forefront-prvs: 0792DBEAD0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(376002)(39860400002)(366004)(346002)(199004)(189003)(26005)(476003)(36756003)(446003)(186003)(6436002)(6306002)(6512007)(76176011)(7736002)(14454004)(8676002)(486006)(6916009)(2616005)(305945005)(97736004)(6506007)(105586002)(86362001)(478600001)(14444005)(68736007)(106356001)(256004)(11346002)(966005)(82746002)(229853002)(83716003)(2900100001)(102836004)(81166006)(8936002)(33656002)(53936002)(5250100002)(66066001)(81156014)(58126008)(2906002)(3846002)(6116002)(5660300001)(6246003)(6486002)(54906003)(93886005)(4326008)(316002)(25786009)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4362; H:DM6PR05MB4665.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-microsoft-antispam-message-info: jT4i63v3VSOB6D84vB5K0nLeTot6lMPh3fwukiaHBoKk66toAXXM/ejqUIh45sHJQ5PT8fUwjlVG6NfiDSQSHO3yQOTcl4LcphK8Tfuy4TZxiGOAjtxa/fEXyTCeYRiv6RuLpse+GGWi9vBdxs0SK187hycv2YBP/qw6qi8eAznwet/ZJm0H08fh1w/W6G9RqJu1yYfIxvM0rYEkYYONo5FoiBOT4R6bwHYneIUSsWlkOwbz/2dN6nT29E/7pu+W9p6vVspV/hOjw7GDb1ZGfhE8biG44zUOaTua2IZdN9VN7h4HnPFYUkNldo9tPNrKSYCgCevIpTw432K/A7vrT9EkYTu166NnkUK5dMJDOTE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <2F10DFB8EF17FF4AA2A63B497831D67C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 70466042-abcf-40f3-2326-08d6181e7ea9
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2018 19:40:57.0941 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4362
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-11_10:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809110193
Archived-At: 
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Sep 2018 19:41:04 -0000

DQoNCj4+IFRoZXJlIGFyZSB0d28gc29sdXRpb25zIGJlaW5nIGRpc2N1c3NlZCBoZXJlLiAgDQo+
PiANCj4+IFRoZSBmaXJzdCByZWdhcmRzIGhvdyB0byBlbmFibGUgYSBjZXJ0aWZpY2F0ZSB0byBi
ZSBjb25maWd1cmVkIGZvciBhIGtleQ0KPj4gaW4gPG9wZXJhdGlvbmFsPiAoZS5nLiwgYW4gTERl
dklEIGNlcnQgZm9yIGEgcHJlZXhpc3Rpbmcga2V5KS4gIEJvdGgNCj4+IHNvbHV0aW9uIChBKSBh
bmQgKEMpIGdpdmUgdXMgdGhpcyAtIGEgbGEgUkZDIDgzNDIgU2VjdGlvbiBDLjMuMi4NCj4+IA0K
Pj4gVGhlIHNlY29uZCBpcyBob3cgdG8gZGVsZXRlIGEgImhpZGRlbiBrZXkiIGNyZWF0ZWQgYnkg
YSBjbGllbnQgKG5vdGUgaGVyZQ0KPj4gdGhhdCBJJ20gZGlzdGluZ3Vpc2hpbmcgdGhpcyBjYXNl
IGZyb20gaGlkZGVuIGtleXMgbm90IGNyZWF0ZWQgYnkgYSBjbGllbnQsDQo+PiBpLmUuLCBpbiA8
b3BlcmF0aW9uYWw+LCB3aGljaCBjYW5ub3QgYmUgZGVsZXRlZCkuICBIZXJlJ3Mgd2hlcmUgdGhl
IGlkZWFzDQo+PiBkaXZlcmdlOg0KPj4gDQo+PiAgIC0gd2l0aCAoQSksIHdlIGtlZXAgdGhlICJn
ZW5lcmF0ZSIgYWN0aW9uIG91dHNpZGUgdGhlIGxpc3QgZW50cnkgKHRodXMNCj4+ICAgICByZXN1
bHRzIGFyZSBpbiA8b3BlcmF0aW9uYWw+LCBhbmQgYWRkIGEgbmV3ICJkZWxldGUtYXN5bW1ldHJp
Yy1rZXkiDQo+PiAgICAgYWN0aW9uIGlzIG5lZWRlZC4NCj4+IA0KPj4gICAtIHdpdGggKEMpLCB0
aGUgYWN0aW9uIGlzIG1vdmVkIGluc2lkZSB0aGUgbGlzdCBlbnRyeSwgdGh1cyB0aGUgbGlzdA0K
Pj4gICAgIGVudHJ5IG5vZGUgaXRzZWxmIGluIDxpbnRlbmRlZD4sIGFuZCBoZW5jZSBjYW4gYmUg
cmVtb3ZlZCBmcm9tDQo+PiAgICAgPGludGVuZGVkPiB2aWEgYSBub3JtYWwgY29uZmlnIG9wZXJh
dGlvbiAobm8gc3BlY2lhbCBhY3Rpb24gbmVlZGVkKS4NCj4+IA0KPj4gSSBkb24ndCBzZWUgYW4g
aXNzdWUgY29uZmlndXJpbmcgY2VydGlmaWNhdGVzIGluIGVpdGhlciBjYXNlLiAgQXMgSSB3cm90
ZQ0KPj4gYWJvdmUsIGJvdGggc29sdXRpb24gKEEpIGFuZCAoQykgZ2l2ZSB1cyB0aGlzLiAoQykg
c3RpbGwgaGFzIHRvIGhhbmRsZQ0KPj4gdGhlIGNhc2Ugd2hlcmUgdGhlIGtleSBpcyBpbiA8b3Bl
cmF0aW9uYWw+IHNhbWUgYXMgKEEpLiAgV2l0aCAoQyksIGl0J3MNCj4+IHRoZSAxJSBjYXNlLCB3
aGVyZWFzIHdpdGggKEEpIGl04oCZcyB0aGUgMTAwJSBjYXNlLg0KPg0KPiBIb3cgY2FuIGEga2V5
IGJlIGluIG9wZXJhdGlvbmFsIGJ1dCBub3QgaW4gY29uZmlnIGluIChDKT8gIEkuZS4sIHdoYXQN
Cj4gaXMgdGhlIDElIGNhc2U/DQoNCk1heWJlIHRvbyBzdWJ0bGUsIGJ1dCBpbiBteSBmaXJzdCBw
YXJhZ3JhcGggYWJvdmUgc2FpZCAiZS5nLiwgYW4gTERldklEDQpjZXJ0IGZvciBhIHByZWV4aXN0
aW5nIGtleSIuICBJJ20gcmVmZXJyaW5nIHRvIGhvdywgZHVyaW5nIG1hbnVmYWN0dXJpbmcsDQph
IHByaXZhdGUga2V5IGFuZCBhbiBhc3NvY2lhdGVkIElEZXZJRCBjZXJ0aWZpY2F0ZSBhcmUgY3Jl
YXRlZCBhbmQgbG9hZGVkDQpvbnRvIHRoZSBkZXZpY2UuICBUaGlzIGtleSBhbmQgY2VydCBhcmUg
aW1tdXRhYmxlLCBidXQgYW5vdGhlciBjZXJ0IGNvdWxkDQpiZSBsb2FkZWQgZm9yIHRoZSBzYW1l
IGtleS4gIFRoaXMgaXMgdGhlIHNjZW5hcmlvIGNhcHR1cmVkIGluIHRoZSBleGFtcGxlDQppbjog
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1rZXlzdG9yZS0w
NSNzZWN0aW9uLTMuMi4NCihzZWFyY2ggZm9yICJ0cG0tcHJvdGVjdGVkLWtleSIpLiAgVGhpcyBp
cyB0aGUgMSUgY2FzZS4NCg0KDQoNCj4+IFRoZXkgc2VlbSBjbG9zZS4gIEZvciB0aGUgcHVycG9z
ZSBvZiBjcmVhdGluZyBhIGtleSwgKEMpIGlzIG1vcmUNCj4+IGNvbXBsaWNhdGVkLiAgRm9yIHRo
ZSBwdXJwb3NlIG9mIGRlbGV0aW5nIGEga2V5LCAoQykgc2VlbXMgZWFzaWVyLg0KPg0KPiBGb3Ig
dGhlIHB1cnBvc2Ugb2YgY3JlYXRpbmcgYSBjZXJ0aWZpY2F0ZSAoQSkgaXMgbW9yZSBjb21wbGlj
YXRlZC4NCg0KSG93IGlzIHRoYXQgc28/ICBBY3R1YWxseSwgaXQgc2VlbXMgdGhhdCAoQSkgYW5k
IChDKSBhcmUgaWRlbnRpY2FsDQppbiB0aGlzIHJlc3BlY3QsIGZyb20gYSBwcm90b2NvbCBwZXJz
cGVjdGl2ZS4gIFRoZSBvbmx5IGRpZmZlcmVuY2UNCmlzIGluIHRoZSBiYWNrZW5kLCB3aGVyZSBp
dCB1c2VzIHRoZSBSRkMgODM0MiBTZWN0aW9uIEMuMy4yIG92ZXJsYXkNCmJlaGF2aW9yLg0KDQoN
Cj4gRGVwZW5kaW5nIG9uIHRoZSBhbnN3ZXIgYWJvdmUsIChDKSBoYXMgdGhlIGFkdmFudGFnZSB0
aGF0IHJlZmVyZW5jZXMNCj4gKGxlYWZyZWZzKSB0byBhIGtleSBjYW4gYmUgcmVxdWlyZSBpbnN0
YW5jZSB0cnVlLiAgV2l0aCAoQSkgdGhleSBoYXZlDQo+IHRvIGJlIHJlcXVpcmUgaW5zdGFuY2Ug
ZmFsc2UsIHNpbmNlIHNvbWUga2V5cyBvbmx5IGV4aXN0cyBpbg0KPiBvcGVyYXRpb25hbCwgd2hp
Y2ggbWVhbnMgdGhhdCB3aGVuZXZlciB0aGVyZSBpcyBhIHJlZmVyZW5jZSB0byBhIGtleSwNCj4g
dGhhdCBtb2RlbCBhbmQgY29kZSBtdXN0IGJlIGFibGUgdG8gaGFuZGxlIHRoZSBjYXNlIHRoYXQg
dGhlIGtleQ0KPiBkb2Vzbid0IGV4aXN0Lg0KDQpFdmVuIHdpdGggKEMpLCBzb21lIGtleXMgY2Fu
IGJlIGluIDxvcGVyYXRpb25hbD4gLSB0aGUgMSUgY2FzZSwgcmlnaHQ/DQoNClllcywgaWYgKmFs
bCoga2V5cyBoYWQgYSBwcmVzZW5jZSBpbiA8aW50ZW5kZWQ+LCB0aGVuIGxlYXJlZnMgdG8ga2V5
cw0KY291bGQgYmUgInJlcXVpcmUtaW5zdGFuY2UgdHJ1ZSIuDQoNCg0KS2VudCAvLyBjb250cmli
dXRvcg0KDQoNCg==


From nobody Tue Sep 11 17:50:58 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89194130E0F for ; Tue, 11 Sep 2018 17:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc6AgYoNp7TR for ; Tue, 11 Sep 2018 17:50:55 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 EB404126CC7 for ; Tue, 11 Sep 2018 17:50:54 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id t19-v6so84591ply.13 for ; Tue, 11 Sep 2018 17:50:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PZ4dSj3nP9MxWLtZlRE5fe5iherKVeA0CK8laOXmW2E=; b=ALRVAS1qhNIZNKxsKb4/r2XF9FjqwekDR9Qn+O9bMGuPCW0ClAkUerpial12v4V5IR vSQ9qHMEG09prshFe5B8SIplF5M5WxqsEWtGAaU2M+5YmeDGQ0VUFRrmCXFCsP/ij6Nk cQoisYDO6V11E8MaE78f6g7mkcBfHxjFarib5mwZX45GpF9/cKxR68fY79hsArPdrJRS yuVlZZIXAUr37pXVjgcfQFPH1ihhPp0KtFvk5Su+r8WFie2JcRq1Td+g8Yars3Of6UNI gNeg2P6TVbO9yegw4h5kCwU9fv/NebwDHs0vD52U4n7ZnLsLQxtzNGQ/WzT9trQQnuh8 WElA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=PZ4dSj3nP9MxWLtZlRE5fe5iherKVeA0CK8laOXmW2E=; b=tbBl5xwD3bh1cIXwcwkxeldhFj7KqJFH8B68xBcPJa1EdtvHLirRwQl/QG9XqvjLO/ ZBU5W01iV8d/gUO+ZGZM5tjPt0Ws86PzD02TSEcVhKnpLMdFTJja5ynpmHPjiCQZk+GI fcWSLlme/kU1WVVGHrR/1IFQDsTrYjrWpPsPKSGmKcNktEDttOVVK77CSIUu3VxbKaL5 La0raTH9LWx2U0udz8X631gtkY5hveeORdyFGJNVM2lurwwqSFzxqbX4Ij7G3gR+Z3ET 7xTlhdRtS22c9tjz2OvqUVikNaFK4LczzpcmvFXPKcx1Fq8hcnDFem0+y2z0knaAHyrD jxrg==
X-Gm-Message-State: APzg51DEvIPrJIiFd/u4qorYIpBzTVVH0QFlZu4JVKrxwEp1wri6Uw8W haUJ3oNlvlUFntRRQiX6Tc+Hf46Z
X-Google-Smtp-Source: ANB0VdZ8vaT8SqqORSoqNSm1AmaSqRxd4sESzPOlpTDQo/cuXShAhsgyAOKBcZawkSMykQiWs0FHeQ==
X-Received: by 2002:a17:902:b212:: with SMTP id t18-v6mr30459560plr.107.1536713454438;  Tue, 11 Sep 2018 17:50:54 -0700 (PDT)
Received: from [10.2.48.47] ([208.91.2.2]) by smtp.gmail.com with ESMTPSA id v19-v6sm27796946pgn.94.2018.09.11.17.50.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 17:50:53 -0700 (PDT)
From: Mahesh Jethanandani 
Message-Id: <4EF52CE6-AE64-47AB-94E3-F114E41E5E28@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B736A1AD-FAB4-4925-8B9B-181D5592AC6E"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 11 Sep 2018 17:50:52 -0700
In-Reply-To: <20171113.155741.613591566578760847.mbj@tail-f.com>
Cc: Netconf 
To: Martin Bjorklund , Kent Watsen 
References:  <20171102.145546.466862355235662064.mbj@tail-f.com> <9430CAD9-E45D-4AC1-BC0C-C3353AFA5085@juniper.net> <20171113.155741.613591566578760847.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [Netconf] WGLC on zerotouch draft
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 00:50:57 -0000

--Apple-Mail=_B736A1AD-FAB4-4925-8B9B-181D5592AC6E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


I do not see any e-mail or updates in the document that reflect what was =
finally agreed upon for this issue raised.


> On Nov 13, 2017, at 6:57 AM, Martin Bjorklund  wrote:
>=20
>>>=20
>>> o  Section 5.1, item 1
>>>=20
>>> Add reference to the new module ietf-zerotouch-device, maybe tweak
>>> the text?
>>=20
>> I put the reference to the module up a level (Section 5) as the =
module
>> applies to more than just item 1.  Regarding tweaking the text, do =
you
>> have a suggestion?
>=20
> The text has guidelines for how a vendor should define a
> "enable zerotouch" variable.  Maybe replace the text with a reference
> to the standard module instead.


Mahesh Jethanandani
mjethanandani@gmail.com=

--Apple-Mail=_B736A1AD-FAB4-4925-8B9B-181D5592AC6E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



I do =
not see any e-mail or updates in the document that reflect what was =
finally agreed upon for this issue raised.






On Nov 13, 2017, at 6:57 AM, Martin Bjorklund <mbj@tail-f.com> =
wrote:


o  Section 5.1, item 1

Add reference to the new module =
ietf-zerotouch-device, maybe tweak
the text?

I put the reference to the module =
up a level (Section 5) as the module
applies to more than =
just item 1.  Regarding tweaking the text, do you
have =
a suggestion?

The text has guidelines for how a vendor should define =
a
"enable =
zerotouch" variable.  Maybe replace the text with a =
reference
to the =
standard module instead.


Mahesh Jethanandani
=

--Apple-Mail=_B736A1AD-FAB4-4925-8B9B-181D5592AC6E--


From nobody Tue Sep 11 18:44:13 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385CE1271FF for ; Tue, 11 Sep 2018 18:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsq3pj1NlFsl for ; Tue, 11 Sep 2018 18:44:08 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C811B130DF0 for ; Tue, 11 Sep 2018 18:44:08 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id f6-v6so163628plo.1 for ; Tue, 11 Sep 2018 18:44:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:date:references:to:in-reply-to:message-id;  bh=OSvlRoaBBRuHf42NnhmwRSMyuYqvxbSs12taDF6XT14=; b=bA64Shr8MrwdWoTKF/4tKNJ6dA1Dg7r4arc5qHLLtXlqsm+knlVmrGbAlf337MNyeq p9Vu9gaqjrxLyoaMwgRa8DUimrYC4x4VMhTJTrEiZR5HdHIynZAusQkSl3c+E1s/Pn4W CLcWHBvPO0fXsUCWnZ+HEAk+5DAY2/FTPGkEO5KEuhkkKC3cRYKHMUV3IGimR9QdHM4/ 9Y7uuHVFbP1eEVbOPNLpZ5ABbcQUZ1audcdS5pfUsba6vilNQlS3/Y1aCM/wdoN+X4U+ ZYHw+Im8WJ1FBDb7vdmFe88xnGHq+4R9qIivAI6Voy4hgf+/K0x+DnwvC7wuUoQLOXF5 aGHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=OSvlRoaBBRuHf42NnhmwRSMyuYqvxbSs12taDF6XT14=; b=W9GNEzccvOrCJPMohdkFODimJ0E/Hl58GAzcV/mYho7QSpdOhZC3Vvhnt9oEwilgIn +3ohE8zE+LFL7oQN90jdN2ftSBB8aY0RFcaD4F50aNFAF3Lg8ADA4s95jM+ZvdhtT7k3 tJgF0bprCpSxTgawWANocPW7B0xPNcO///gVwkeKqvV5mdEvLu6pQJeKT8y18Qx8FTPa MgbWngMqih2IMmjj/ypbSS9gzBaIxtFFLwzx1bewKBQb+IS18jb9Gx4mvLSTIbwRgRH2 KN3/YGviAASp7NtpXgZbsSeM0V6byZduVXPZlJekVhkHVu21V1IJdSjr2rNL/Mqd8aP9 1ujA==
X-Gm-Message-State: APzg51AEbUYN9dO9O3qeZfBMIvkT45pTg8LowagxJyQU1o/2bRtCnUn3 mTPuMm1Ryj73eo2UFgIM5KyP9Clr
X-Google-Smtp-Source: ANB0VdZrVAV9Y/86SbS+T5nKs68LC9thnfmenxOgi0+Kbyj30koA1Lcz7YSg2Krc7GhF3Xj0oRuPTQ==
X-Received: by 2002:a17:902:464:: with SMTP id 91-v6mr30407828ple.125.1536716647818;  Tue, 11 Sep 2018 18:44:07 -0700 (PDT)
Received: from [10.2.48.47] ([208.91.2.2]) by smtp.gmail.com with ESMTPSA id h85-v6sm38237374pfk.71.2018.09.11.18.44.07 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 18:44:07 -0700 (PDT)
From: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary="Apple-Mail=_45A49E61-E260-4F09-A19C-15E044861E22"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 11 Sep 2018 18:44:06 -0700
References: <9F33F0C4-7697-4774-B7F1-A8556A6A73A1@gmail.com>
To: netconf 
In-Reply-To: <9F33F0C4-7697-4774-B7F1-A8556A6A73A1@gmail.com>
Message-Id: 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: [Netconf] IPR and known implementation (Was Re: WG LC for zerotouch)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 01:44:11 -0000

--Apple-Mail=_45A49E61-E260-4F09-A19C-15E044861E22
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Sep 25, 2017, at 6:45 PM, Mahesh Jethanandani =
 wrote:
>=20
> The last round of WG LC on Zerotouch draft =
 resulted =
in lot comments being posted about the draft. Kent has since then =
updated the document to address all those comments and posted -17 =
version of the draft.
>=20
> We believe the document is now ready for a re-run of that call. This =
starts a two-week WG LC on the draft. Please indicate your support if =
you believe the document is now ready for LC. We need affirmation of =
support for the LC to succeed. Unfortunately, silence is not =
affirmation. If you believe the document is still not ready, please =
indicate why. The LC will conclude on Oct. 9.
>=20
> Authors, please indicate if you are aware of any IPRs related to the =
document. Also, please indicate if there are any known implementations =
of the draft.

This thread devolved into a review of the draft, where the two questions =
on IPR and known implementations got lost. And while there exists one =
IPR disclosure, this question is still pertinent. Please note that a =
response is required from ALL the authors or contributors to this =
e-mail. Without it, the document cannot be advanced.=20

Are the authors or contributors to the draft aware of any IPRs related =
to the draft? Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft=E2=80=9D

If so, has this IPR been disclosed in compliance with IETF IPR rules =
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think =
appropriate.

If you are on the WG mailing list and/or attend WG meetings, it is your =
obligation under the IPR rules to notify IETF.

For more information, please see RFCs 3669, 5378, 8179 and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty =
.

Finally, if you are aware of any implementations of this draft, please =
let us know.

>=20
> Thanks.


Mahesh Jethanandani
mjethanandani@gmail.com



--Apple-Mail=_45A49E61-E260-4F09-A19C-15E044861E22
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8





On Sep 25, 2017, at 6:45 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

The last round =
of WG LC on Zerotouch draft resulted in lot comments being =
posted about the draft. Kent has since then updated the document to =
address all those comments and posted -17 version of the draft.

We believe the document =
is now ready for a re-run of that call. This starts a two-week WG LC on =
the draft. Please indicate your support if you believe the document is =
now ready for LC. We need affirmation of support for the LC to succeed. =
Unfortunately, silence is not affirmation. If you believe the document =
is still not ready, please indicate why. The LC will conclude on Oct. =
9.

Authors, =
please indicate if you are aware of any IPRs related to the document. =
Also, please indicate if there are any known implementations of the =
draft.

This =
thread devolved into a review of the draft, where the two questions on =
IPR and known implementations got lost. And while there exists one IPR =
disclosure, this question is still pertinent. Please note that a =
response is required from ALL the authors or contributors to this =
e-mail. Without it, the document cannot be advanced. 

Are the authors or contributors to the draft aware =
of any IPRs related to the draft? Please state either:

"No, I'm not aware of any IPR that applies to this =
draft"
or
"Yes, I'm aware of IPR that =
applies to this draft=E2=80=9D

If =
so, has this IPR been disclosed in compliance with IETF IPR =
rules (see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance =
with IETF IPR rules"
or
"No, the IPR has not =
been disclosed"

If you answer no, please =
provide any additional details you think appropriate.

If you are on the WG =
mailing list and/or attend WG meetings, it is your obligation under the =
IPR rules to notify IETF.

For more =
information, please see RFCs 3669, 5378, 8179 and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPro=
perty.

Finally, if you are aware =
of any implementations of this draft, please let us know.


Thanks.


Mahesh =
Jethanandani


=

--Apple-Mail=_45A49E61-E260-4F09-A19C-15E044861E22--


From nobody Tue Sep 11 23:32:06 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331AD130EC4 for ; Tue, 11 Sep 2018 23:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F02aAbTHtiZB for ; Tue, 11 Sep 2018 23:32:02 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502A8130DD6 for ; Tue, 11 Sep 2018 23:32:02 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id E4DCBB4; Wed, 12 Sep 2018 08:31:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1536733919; bh=33M/fhgqNABkT61zFFTYU4NKS6i4V6osYhlCNzoL9xY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=zX+t+BtoZMhe8/XrVfhJuixOKkWHURGbLITisxWchqs3XThEFeOnFAYRfrPdNX6l7 w8kEjqpFVfA+G4coHZ20ZayhTsVmkCi00oVNm2YPXvjKCKBfQB2naqvlbVzXDCZZnA akvQ1j452Js+7g5VdknUTuHjdJgTUkvbmLN4Q9fI=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E035DB3; Wed, 12 Sep 2018 08:31:59 +0200 (CEST)
Date: Wed, 12 Sep 2018 08:31:59 +0200 (CEST)
From: Mikael Abrahamsson 
To: Mahesh Jethanandani 
cc: netconf 
In-Reply-To: 
Message-ID: 
References: <9F33F0C4-7697-4774-B7F1-A8556A6A73A1@gmail.com> 
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="-137064504-59105169-1536733919=:24654"
Archived-At: 
Subject: Re: [Netconf] IPR and known implementation (Was Re: WG LC for zerotouch)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 06:32:05 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---137064504-59105169-1536733919=:24654
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT


After reading the IPR disclosures done for the draft, I can say:

"Yes, I'm aware of IPR that applies to this draftâ€

The only IPR I am aware of is the one Juniper has filed in

https://datatracker.ietf.org/ipr/2581/

I can't judge if that's done according to the rules, but from my knowledge 
it looks ok.

So:

I am not aware of any unfiled IPR against this draft.

On Tue, 11 Sep 2018, Mahesh Jethanandani wrote:

>
>
>> On Sep 25, 2017, at 6:45 PM, Mahesh Jethanandani  wrote:
>>
>> The last round of WG LC on Zerotouch draft  resulted in lot comments being posted about the draft. Kent has since then updated the document to address all those comments and posted -17 version of the draft.
>>
>> We believe the document is now ready for a re-run of that call. This starts a two-week WG LC on the draft. Please indicate your support if you believe the document is now ready for LC. We need affirmation of support for the LC to succeed. Unfortunately, silence is not affirmation. If you believe the document is still not ready, please indicate why. The LC will conclude on Oct. 9.
>>
>> Authors, please indicate if you are aware of any IPRs related to the document. Also, please indicate if there are any known implementations of the draft.
>
> This thread devolved into a review of the draft, where the two questions on IPR and known implementations got lost. And while there exists one IPR disclosure, this question is still pertinent. Please note that a response is required from ALL the authors or contributors to this e-mail. Without it, the document cannot be advanced.
>
> Are the authors or contributors to the draft aware of any IPRs related to the draft? Please state either:
>
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draftâ€
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you think appropriate.
>
> If you are on the WG mailing list and/or attend WG meetings, it is your obligation under the IPR rules to notify IETF.
>
> For more information, please see RFCs 3669, 5378, 8179 and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty .
>
> Finally, if you are aware of any implementations of this draft, please let us know.
>
>>
>> Thanks.
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
---137064504-59105169-1536733919=:24654--


From nobody Wed Sep 12 02:34:53 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DA312008A for ; Wed, 12 Sep 2018 02:34:52 -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 95HtZ2U0mXgx for ; Wed, 12 Sep 2018 02:34:49 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9A720126DBF for ; Wed, 12 Sep 2018 02:34:49 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E01B1AE02BE; Wed, 12 Sep 2018 11:34:46 +0200 (CEST)
Date: Wed, 12 Sep 2018 11:34:46 +0200 (CEST)
Message-Id: <20180912.113446.2017030234338816835.mbj@tail-f.com>
To: evoit@cisco.com
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20180910.194152.138356385922962289.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 09:34:53 -0000

"Eric Voit (evoit)"  wrote:
> Thanks for the comments Martin,  thoughts in-line...
> 
> > From: Martin Bjorklund, September 10, 2018 1:42 PM

[...]

> > o  Section 2.1
> > 
> >   The text says:
> > 
> >     It is out of the scope of this document
> >     to identify [...] b) how event records are defined
> > 
> >   Is this really what we want?  Shouldn't this document specify that
> >   an event record is an instance of a YANG "notification" statement?
> >   Do we want to support event records that are not defined in YANG?
> >
> >   This was discussed in the thread "comments on
> >   draft-ietf-netconf-subscribed-notifications-12", and it seems that
> >   noone really have any use case for non-YANG-defined event records,
> >   accessed with YANG-defined operations.
> 
> Yes this was discussed previously.  My reading was that others wanted
> to support subscription to non-YANG events.
> E.g., see Andy & Tianran's thoughts in
> https://www.ietf.org/mail-archive/web/netconf/current/msg14764.html 

Yes, but read on in that thread, see
https://www.ietf.org/mail-archive/web/netconf/current/msg14766.html
for a clarification.

AFAIK, noone has presented a use case for sending non-YANG-defined
data here.

> >   I think that this document should state that an event record is an
> >   instance of a YANG "notification" statement.  If not, it is unclear
> >   both how subtree/xpath filters and xml/json/... encodings would work.
> 
> Applying xpath filters against XML based event records seems viable to
> me.

Where does it say that it has to be XML?  Whatabout mixed-content?
What if such a notification is sent when the encoding is JSON?

If you want to make this specification open for other data modeling
languages, I think you need to carefully define how that is supposed
to work; essentially similar to how we handle transports; we have a
set of requirement on what a transport document must define.  IMO this
is super complicated and overkill.  This draft is complex enough.
Don't add even more complexity.

> Of course it will be up to the definition of any particular
> stream to articulate the event record contents sufficiently for
> filters to be created.
> 
> > o  Section 2.1
> > 
> >   The text says:
> > 
> >     Among
> >     these included NETCONF XML event records are individual YANG 1.1
> >     notifications described in section 7.16 of [RFC7950].
> > 
> >   First of all, does this mean that there can be event records on the
> >   "NETCONF" stream that are *not* defined with a "notification"
> >   statement?
> 
> For the NETCONF stream, personally I only care about things YANG
> notification statement.  But looking again at Andy's comment from:
> https://www.ietf.org/mail-archive/web/netconf/current/msg14764.html 
> he says "I would say SHOULD be defined in YANG, for the "NETCONF"
> stream."

I strongly disagree.

> So for -v16 I updated the text in a way that doesn't
> preclude this.

See above.  If all events records are defined in YANG we can remove
this.


> >   Second, this seems to imply that *all* notifications defined in all
> >   YANG modules end up in the "NETCONF" stream, but I don't think this
> >   is the intention.  At least I hope so.  ("yp:push-update" is an
> >   example of a notification that will not be sent on the "NETCONF"
> >   stream.)
> 
> The NETCONF stream has a very broad/inclusive definition in RFC-5277.
> This definition is: "This stream contains all NETCONF XML event
> notifications supported by the NETCONF server".

This is very underspecified.  IIRC the original intention was
notifications related to NETCONF, hence "*NETCONF* XML event
notifications".

> To me, thinking about how that statement and applying it to YANG, this
> translates as YANG 1.1 notifications should go into the NETCONF
> stream, unless explicitly excluded.

I disagree.  This is not how 5277 works.  Until we have worked out a
useful way to assign notifications to streams, we shouldn't restrict
anything in this regard.

> This provides a very simple way
> determining which types of notifications should be placed on the
> stream.  (Otherwise, how is a developer of a YANG notification
> supposed to know whether it should go into the NETCONF stream or
> not?

They don't.  But note that it might be an operator decision for how to
assign notifications to streams.

> The alternative would seem to be having each notification opt-in to
> the NETCONF stream.)
> 
> So if you agree with this reasoning, how about:
> 
> The "NETCONF" event stream contains all instances of YANG 1.1
> notifications generated by a publisher, except where a type of
> notification has explicitly been excluded from the stream.

I think that this document should keep the definition of the NETCONF
stream as defined in RFC 5277.

Also, I think it should state that an event record is an instantiation
of a YANG "notification" statement (any version of YANG).

[...]

> > o  Section 2.4.2
> > 
> >   The text says:
> > 
> >     The transport selected by the subscriber
> >     to reach the publisher MUST be able to support multiple "establish-
> >     subscription" requests made within the same transport session.
> > 
> >   This seems to indicate that RESTCONF cannot be used with this
> >   specification, since RESTCONF doesn't have sessions.
> 
> The desired behavior is that a subscriber can request multiple
> subscriptions without each requiring a separate transport session
> establishment.  I think we are ok here with RESTCONF because
> underneath RESTCONF is HTTP, TLS, TCP.  And each of those lower layers
> can have sessions.
> 
> To clarify further, I have tweaked the text to:
> 
> "The transport selected by the subscriber to reach the publisher MUST
> be able to support multiple "establish-subscription" requests without
> each requiring a separate persistent transport connection."
> 
> >   This makes me wonder, why does this document specify this
> >   requirement?  I agree that this is the behaviour we want from
> >   NETCONF, but then I think that should be defined in the
> >   netconf-notif draft.
> 
> By saying something in SN about this requirement, I believe we can
> preclude an implementation which can only support one subscription per
> subscriber.  In any case, the specific "how" details will still need
> to be articulated in each transport draft.

I think you are mixing the specification and implementation.  If a
transport document says that an implemention MUST support multiple
subscriptions per session (in a transport-specific way), then an
implementation cannot just support a sinlge subscription.

My point is that this a transport-specific requirement, and it doesn't
belong in this document.

> > o  Section 2.4.2
> > 
> >   s/"start-time"/"replay-start-time"/  (3 occurrences)
> 
> Fixed
> 
> >   Also, the text says that the replay-start-time MUST be in the past.
> > 
> >   Suppose the server receives a "replay-start-time" of 12:00:00.001,
> >   and the replay buffer is empty.
> > 
> >   A) If the current time is 12:00:00.002, the request is accepted, and
> >      a "replay-completed" notif is sent.
> > 
> >   B) If the current time is 12:00:00.000, the request is rejected with
> >      an error.
> > 
> >   Why is this important?  Why not simply just send the
> >   replay-completed notif in both cases?
> 
> For (B), if an event occurs at 12:00:00.0005, should it be sent?
> Should it be sent before or after the "replay-start-time"?  How long
> should we allow the clocks to drift before we reject the subscription?
> As we don't support future/pending subscriptions, we don't have to
> worry about these questions with the current definition.

I would simply say that if the replay-start-time is later than any
buffered notif, then "replay-complete" is immediately sent.  It dont'
matter if it is one microsecond or one year later.

The problem otherwise is how to decide if something is "in the past".
In the past when the client sent the request?  When the server parsed
the XML?  When the instrumentation code runs?

But this is not a big issue.

[...]

> > o  Section 2.4.2.1
> > 
> >   There is no text that explains what happens in the "succesful" case;
> >   i.e., when there are buffered event records with time greater than
> >   or equal to the requested "replay-start-time".
> > 
> >   Maybe the first paragraph is supposed to cover this, but it just
> >   says "meets the timeframe criteria", which is a bit vague.
> 
> This was supposed to be covered by the first paragraph.  To help
> clarify, I have updated the text to:
> 
> "In other words, as the subscription initializes itself, it sends any
> event records within the target event stream which meet the filter
> criteria, which have an event time which is after the
> "replay-start-time", and which have an event time before the
> "stop-time" should this "stop-time" exist."

Ok.

[...]

> > o  Section 2.4.6
> > 
> >   The text says:
> > 
> >     1.  "establish-subscription-stream-error-info": This MUST be returned
> >         if an RPC error reason has not been placed elsewhere within the
> >         transport portion of a failed "establish-subscription" RPC
> >         response.
> > 
> >   (and similar for the other errors)
> > 
> >   What exactly does "if an RPC error reason has not been placed
> >   elsewhere" mean?
> 
> The intent is to match how NETCONF & RESTCONF historically handles
> errors.  As you know with NETCONF, each error identity will be
> inserted as the "error-app-tag".

It could also be in "error-tag" and/or "error-message".  My point is
that I don't think that you mean that if an implementation populate
say "error-message", then it should not popluate error-info with
establish-subscription-stream-error-info.

> And therefore placing the YANG data
> "establish-subscription-stream-error-info" would be redundant.  For
> NETCONF, "establish-subscription-stream-error-info" are only needed
> when hints to be provided.
> 
> Therefore assuming you are looking for an alternative way to make this
> point, I have tweaked the text to:
> "This MUST be returned if an RPC error reason has not been mapped down
> into transport specific error objects contained within a failed
> "establish-subscription" RPC response."

Howabout simply removing this sentence?

> > o  Section 2.5.1
> > 
> >   In the second diagram (for the valid state), the states are called
> >   "receiver connecting", "reciever timeout" etc.  I find this a bit
> >   confusing; it is not the *receiver* that is connecting, it is the
> >   publisher.  Ok, the legend then says:
> > 
> >      dashed boxes which include the word 'receiver' show the possible
> >      states for an individual receiver
> > 
> >  But since all dashed boxes include the word "receiver", and the
> >  diagram
> > specifically is the state machine *per receiver*, maybe we can simply
> > remove
> > the word "receiver" from the boxes?
> 
> There have been some discussions on this.  I agree it is certainly
> valid to remove "receiver" from these four boxes.  However I have
> found that getting readers to really internalize that the state
> machine is actually per-receiver rather than per-subscription, it
> seems to go faster/cleaner when receiver is shown in the four boxes.
> 
> Nevertheless, if you absolutely want "receiver" removed from the
> boxes, I can do that.

Maybe you can remove receiver from the individual boxes and then
change the word "valid" from the outer box to "per-receiver state
machine"?

Or maybe remove the outer box and add a Figure title: 'per-receiver
state machine for the subscription's "valid" state'

Also not a big deal, but I found it confusing.

[...]

> > o  Section 2.5.6
> > 
> >   I know that this feature was presented in Montreal.  I think it is
> >   problematic, and suggest it is removed.
> 
> This issue was discussed in Montreal.  The feature is of course is
> optional.  There are a large number of downsides for someone who
> chooses not to implement for certain use cases.  Please see the
> Montreal slides and the long threads with Kent for more details.

I did watch the Montreal session, but I didn't see any discussion on
this issue (just your presentation).   Can you send a pointer to the
email thread with Kent?

> If
> you want to pursue this further it is probably best to start a new
> thread dedicated to this topic alone.
> 
> >   For example, what happens if the transport session is lost and
> >   re-established; are all event records in the buffer replayed again?
> 
> No.  The publisher will not lose context of what was sent.

This is not clear from the text.  In fact, the text explicitly says:

   The leading event record sent will be the first event record
   subsequent to the latest of three different times: the
   "replay-log-creation-time", "replay-log-aged- time", or the most
   recent publisher boot time.

> >   What happens if a new receiver is added to a subscription that
> >   already has a receiver, will all events in the buffer be replayed to
> >   the new receiver?
> 
> Yes.  (To clarify, I added "to each configured receiver" at the end of
> the last sentence of the first paragraph.)
> 
> >   When a new subscription is configured with configured-replay set,
> >   the publisher will immediately try to connect to the publisher and
> >   send all buffered event from the last reboot.  Is this really
> >   useful?
> 
> Yes.  See the security cases reviewed on the earlier threads with
> Kent.  If someone doesn't care about log entries since boot, they
> simply don't have to implement this optional feature.
> 
> >   If the mechansim relies on the subscriber being able to also use
> >   dynamic subscriptions for replay of all event records, maybe we
> >   could simplify things by always relying on dynamic subscriptions for
> >   replay for configured subscriptions.  Specifically, remove
> >   "configured-replay" etc, but keep the "replay-previous-event-time"
> >   in the "subscription-started" notification.  Then a subscriber can
> >   simply check this value to see if anything is missing, and if it is,
> >   use a dynamic subscription to request replay from the latest time he
> >   knows about.
> 
> This is a valid approach, and can be used as an alternative to this
> optional feature.  However there are still many downsides to the
> alternative.  See the slides from Montreal, as well as the previous
> thread discussions for details.
> 
> > o  Section 2.6
> > 
> >   It just occurred to me that this text about using the 
> >   message shouldn't be in this document, but in the netconf-notif (and
> >   restconf-notif) document.  It is highly transport and encoding
> >   specific.
> 
> I think you are referring to both the sentence: "This notification
> message MUST be encoded in a  message as defined within
> [RFC5277], Section 4.  And per [RFC5277]'s "eventTime" object
> definition, the "eventTime" is populated with the event occurrence
> time."  As well as to the example compliant message in Figure 10.
> 
> While the text could be extracted and placed in the netconf-notif
> document, extracting it fully from SN would leave no baseline message
> format.

Things like this are inevitable when you have a transport-independent
specification.  Of course, you can require that all transports MUST
use the 5277 spec of a notification.  But then I think you rule out
transports like CoMI and possibly other future binary protocols.

> Perhaps others will have a problem if the SN solution does
> not have some pre-defined structure to hold event records?
> 
> I can move this if I hear no objection.  As you know, I am hoping that
> draft-ietf-netconf-notification-messages at some point displaces the
>  message of [RFC5277], Section 4.  And this is easier to
> do with fewer references to RFC5277 within SN.

[...]

> > o  Section 4
> > 
> >           action reset {
> >             if-feature "configured";
> >             description
> >               "Allows the reset of this configured subscription receiver
> > 
> >   This action will be available also for dynamic subscription, if the
> >   server supports the "configured" feature.  Maybe add:
> > 
> >     when "../../../configured-subscription-state";
> 
> This would be nice to have.  But action doesn't support "when" as an
> allowed sub-statement.

Ha!  That's unfortunate... I wonder why we didn't allow this...



/martin


From nobody Wed Sep 12 04:44:32 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7607D129C6A for ; Wed, 12 Sep 2018 04:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level: 
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 k_FODmVoomxi for ; Wed, 12 Sep 2018 04:44:28 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 74DAB1286D9 for ; Wed, 12 Sep 2018 04:44:28 -0700 (PDT)
Received: from ians-mbp.lan ([80.159.240.8]) by mail.gmx.com (mrgmx102 [212.227.17.174]) with ESMTPSA (Nemesis) id 0MP1PX-1fxYzf3xcF-006LJL; Wed, 12 Sep 2018 13:44:24 +0200
From: ianfarrer@gmx.com
Message-Id: <8D70476B-827E-4A59-8BC6-08505D70286A@gmx.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_67039F6C-E572-4391-97D5-FE0270E06B82"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 12 Sep 2018 13:44:23 +0200
In-Reply-To: 
Cc: netconf 
To: Mahesh Jethanandani 
References: <9F33F0C4-7697-4774-B7F1-A8556A6A73A1@gmail.com> 
X-Mailer: Apple Mail (2.3445.9.1)
X-Provags-ID: V03:K1:ag5Z8HxhgvjkV7JWuZX+vejb9b7UHAoA/+Ia7Yimg/zSGwxm/K4 2ri4tO90Xvt0EMjDWg9+F9DCuEH65RBVLVf96YnKgA07J3Oa1OKNJOMp9JP4HKdSam6tC6n jG1+cHHqdS/LlDV7voIDYpWW1t6eAk/EcB7j0pKWcqBoh0hv/SCHkHu96VdFqru4kzyBoft jYrBj3QpIDOwlgejcFarg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:IwbfjLt9IGo=:lKIFLKUYsavGLQufecfdq+ WPjEiNyFVuCokhYjjzCxFu+DJ9zsiv6i7sMV6SFaOvJSfnB63chpeIHYV0bCHGhQqMrgmq3l2 4uHYme/Vv6Tgwaj3GiZWThXkC/vfTXgrsxhTXlb/BtPxlW/xas4ygK5Prro+FlQyi1MtX59n3 FeGFlVUAz6R+LHeO3xZMT5XwaTuF2VYgxWO0/sDXffVJH7N8SCVOwtLfz5blWFjDAlVtpXfz2 LylIs+JShA86vNrzBDHBYPtsz0gnyajVwpzp5XdmFQBPCNY2MVrAPq4of2H/1FZxywBqHOMUC dUh8gkjPHbcWLABBDQxlsE+qVgBrEiEjnZ1pBdd5ZhlvuBZLFmuvoMSGGgguyDQFXqIsVFrXD /4DEA/0lKdHn/n6LSd2lgl7h3imjqnZaUU1kW+CcbU+lFIqS+egLNdoS6QqZa2wrP1XSr0c0Q 6Oxpr9RcykRFMFNX2CgpYbtF7pFIygNZrfMG5PZBZOKn0PuiMLsFagkXib5GGurxaLD//5/yk eIIVGAIdP2PdkgjZeGuFELVaIujBy8P/3CYyYz0grSf/p+d8fDfW+Hdc6hWFtjdlwK2rjL2EU dRFHvW17S8+k6l3cPHvLCDYvn5qRYhTMVOd7UDOeDQyB+6sonwrEM7q5US0M78CsuXBsduKQW pZvZZuj01qcKhrPgSZsTKLIPw4yN9QwAchfXQGeKs7RbZaAVJPJyi9rvXGnsZXfaPuxHx7K/n 8BdxR3Kxus8hWVBq6V1NmPDKArSrAIMBJnBSM5B0WlDpHqW+OH5kEgNWUfkxgl/+JGh4GJPPS DL6Su3ACzX4U3aaRan6iYxqEqBphNmDy7JEmFa+9EpXtF2dasw=
Archived-At: 
Subject: Re: [Netconf] IPR and known implementation (Was Re: WG LC for zerotouch)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 11:44:30 -0000

--Apple-Mail=_67039F6C-E572-4391-97D5-FE0270E06B82
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Mahesh,

No, I am not aware of any IPR that applies to this draft which hasn=E2=80=99=
t already been filed. I=E2=80=99m also not aware of any implementations.

Thanks,
Ian

> On 12. Sep 2018, at 03:44, Mahesh Jethanandani =
 wrote:
>=20
>=20
>=20
>> On Sep 25, 2017, at 6:45 PM, Mahesh Jethanandani =
> wrote:
>>=20
>> The last round of WG LC on Zerotouch draft =
 resulted =
in lot comments being posted about the draft. Kent has since then =
updated the document to address all those comments and posted -17 =
version of the draft.
>>=20
>> We believe the document is now ready for a re-run of that call. This =
starts a two-week WG LC on the draft. Please indicate your support if =
you believe the document is now ready for LC. We need affirmation of =
support for the LC to succeed. Unfortunately, silence is not =
affirmation. If you believe the document is still not ready, please =
indicate why. The LC will conclude on Oct. 9.
>>=20
>> Authors, please indicate if you are aware of any IPRs related to the =
document. Also, please indicate if there are any known implementations =
of the draft.
>=20
> This thread devolved into a review of the draft, where the two =
questions on IPR and known implementations got lost. And while there =
exists one IPR disclosure, this question is still pertinent. Please note =
that a response is required from ALL the authors or contributors to this =
e-mail. Without it, the document cannot be advanced.=20
>=20
> Are the authors or contributors to the draft aware of any IPRs related =
to the draft? Please state either:
>=20
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft=E2=80=9D
>=20
> If so, has this IPR been disclosed in compliance with IETF IPR rules =
(see RFCs 3669, 5378 and 8179 for more details)?
>=20
> If yes to the above, please state either:
>=20
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>=20
> If you answer no, please provide any additional details you think =
appropriate.
>=20
> If you are on the WG mailing list and/or attend WG meetings, it is =
your obligation under the IPR rules to notify IETF.
>=20
> For more information, please see RFCs 3669, 5378, 8179 and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty =
.
>=20
> Finally, if you are aware of any implementations of this draft, please =
let us know.
>=20
>>=20
>> Thanks.
>=20
>=20
> Mahesh Jethanandani
> mjethanandani@gmail.com 
>=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


--Apple-Mail=_67039F6C-E572-4391-97D5-FE0270E06B82
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Mahesh,

No, I am not =
aware of any IPR that applies to this draft which hasn=E2=80=99t already =
been filed. I=E2=80=99m also not aware of any implementations.

Thanks,
Ian

On 12. Sep 2018, at 03:44, Mahesh =
Jethanandani <mjethanandani@gmail.com> wrote:





On Sep 25, 2017, at 6:45 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

The last round =
of WG LC on Zerotouch draft resulted in lot comments being =
posted about the draft. Kent has since then updated the document to =
address all those comments and posted -17 version of the draft.

We believe the document =
is now ready for a re-run of that call. This starts a two-week WG LC on =
the draft. Please indicate your support if you believe the document is =
now ready for LC. We need affirmation of support for the LC to succeed. =
Unfortunately, silence is not affirmation. If you believe the document =
is still not ready, please indicate why. The LC will conclude on Oct. =
9.

Authors, =
please indicate if you are aware of any IPRs related to the document. =
Also, please indicate if there are any known implementations of the =
draft.

This thread devolved into a review of the draft, where =
the two questions on IPR and known implementations got lost. And while =
there exists one IPR disclosure, this question is still pertinent. =
Please note that a response is required from ALL the authors or =
contributors to this e-mail. Without it, the document cannot be =
advanced. 

Are the authors or contributors to the draft aware of any =
IPRs related to the draft? Please state either:

"No, I'm not aware of any IPR that =
applies to this draft"
or
"Yes, I'm aware of =
IPR that applies to this draft=E2=80=9D

If so, has this IPR been disclosed in =
compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for =
more details)?

If yes to the above, please =
state either:

"Yes, the IPR has been =
disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you =
think appropriate.

If you are on the WG mailing list =
and/or attend WG meetings, it is your obligation under the IPR rules to =
notify IETF.

For=
 more information, please see RFCs 3669, 5378, 8179 and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPro=
perty.

Finally, if you are aware of any implementations of this =
draft, please let us know.


Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com


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

=

--Apple-Mail=_67039F6C-E572-4391-97D5-FE0270E06B82--


From nobody Wed Sep 12 05:01:20 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AD3130DEE for ; Wed, 12 Sep 2018 05:01:18 -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 QGUHFBpioGah for ; Wed, 12 Sep 2018 05:01:12 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B7FBB129C6A for ; Wed, 12 Sep 2018 05:01:11 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 229731AE02BE for ; Wed, 12 Sep 2018 14:01:10 +0200 (CEST)
Date: Wed, 12 Sep 2018 14:01:09 +0200 (CEST)
Message-Id: <20180912.140109.1250692833398495223.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 12:01:18 -0000

Hi,

I forgot one thing in my review, that has been discussed (slightly
off-topic) in the thread "netconf call home connection type".

The SN draft (implicitly) assumes that for dynamic subscriptions,
after a successful "establish-subscription" operation, notification
messages can start to flow to the client.

The exact mechanism for this is transport-protocol-dependent.

For NETCONF, the netconf-notif draft will need to update RFC 6241,
since 6241 refers to 5277 which says that a  message can
only be sent after a successful "create-subscription".  netconf-notif
updates this to allow  messages to also be sent after a
succsessful "establish-subscription".

For RESTCONF, the restconf-notif draft defines a new mechanism for how
notifications are delivered; instead of locating the SSE resource url
from the "streams" in "ietf-restconf-monitoring", this draft now
augments a location leaf to the output of "establish-subscription".
(It probably doesn't have to update 8040, but *maybe* the mechanism in
8040 ought to be deprecated)


For configured subscriptions however, the SN draft doesn't specify how
the flow of notifications should start.  One view is that this is
transport-protocol-specific.  However, I think that for all RPC-based
transport-protocols (currently NETCONF and RESTCONF) it makes sense to
have a common way to get the notifications to be sent.  Hence I
suggest that this draft adds a new rpc operation
"activate-configured-subscription" (better name anyone?).  This rpc
would be invoked by the client after a call home to start the flow of
configured subscriptions.  If there are no such subscriptions or the
session is not a call home session and error would be returned.

We might define non-RPC-based transport protocols for configured
subscriptions in the future.  Such a protocol can obviously not use
this rpc, but OTOH it can't use establish-subscription either.  I
think this is ok.

With such an RPC, netconf-notif would udate 6241 to say that
 messages can be sent after a succsessful
"establish-subscription" or "activate-configured-subscription" rpc.

And with such an RPC, restconf-notif can support configured
subscriptions over proper RESTCONF; it would augment a "location" leaf
to the output of activate-configured-subscription, which would contain
the URL to the event flow, so that it works just like dynamic
subscriptions.


If we don't add this RPC to the SN draft, each protocol draft will
have to define its own version of this operation.



/martin


From nobody Wed Sep 12 08:02:08 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36909130DF5 for ; Wed, 12 Sep 2018 08:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham 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 2TfCHeevzfTw for ; Wed, 12 Sep 2018 08:01:59 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 E34721292AD for ; Wed, 12 Sep 2018 08:01:59 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8CF10BE010776; Wed, 12 Sep 2018 08:01:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=yJjKws2FOcJoyMj/2isp9Q1nCAgUl2HdRUphQV+FQjw=; b=YVMabr9O2TVwiXQYvIFw+tPfLmEyS2TmCAaUhBDeoV8Ky81OIh40FsdTLIRlwkanWDYA PQm0T06Mrd603ys+vA6Fw9ff60mrNYWT9ieg6zv9qO7OocFsjCMHC+55v5u5i+YcF/vp EKvOFcsDWBcBcCLKZrbXag8n6BoUrPT9+r+8wdCX3rjoRmiyoumuC/jeSSajdaIZi3oC Vu5wRIUi5dBTs7eIQbEMZhDLq/KYJcDW1pvEZLtfYYXhOpVdlrZyfa1s6/8QugzVqiOc hW34EqIWM77dECGCxpvyvpqcGjwvBITN5WTmnhqOUtGTtdFm7GaqXt/D/zmQC0xVqaky Qg== 
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0179.outbound.protection.outlook.com [216.32.180.179]) by mx0a-00273201.pphosted.com with ESMTP id 2mf52rr031-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 12 Sep 2018 08:01:53 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4412.namprd05.prod.outlook.com (20.176.78.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.11; Wed, 12 Sep 2018 15:01:45 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1143.010; Wed, 12 Sep 2018 15:01:45 +0000
From: Kent Watsen 
To: Mahesh Jethanandani , Martin Bjorklund 
CC: Netconf 
Thread-Topic: [Netconf] WGLC on zerotouch draft
Thread-Index: AQHTSo2X/9y7wRXxl0KFrYdSEL3me6MBL3QAgA3gOQCAA3q5gIHbRc0AgACqroA=
Date: Wed, 12 Sep 2018 15:01:45 +0000
Message-ID: <81650046-7DB3-4D95-9ED2-8D915B24C62D@juniper.net>
References:  <20171102.145546.466862355235662064.mbj@tail-f.com> <9430CAD9-E45D-4AC1-BC0C-C3353AFA5085@juniper.net> <20171113.155741.613591566578760847.mbj@tail-f.com> <4EF52CE6-AE64-47AB-94E3-F114E41E5E28@gmail.com>
In-Reply-To: <4EF52CE6-AE64-47AB-94E3-F114E41E5E28@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4412; 6:7TGhLpcj6gFkKKbQijifMxGEwMWzk75NcXANvhpdTO4boGxCra3x6/uJ5P2YXKJhmBkXPLGBW3XIgLw9a4JmrLCR9LWrscknC4vPD3M9uxXB/3J+TeOmE23hI8eAzmL3S3MwQZI1y8WnBO3e20KUAl71HqfnhthVRZFsFwsRQLimWw3BniDdMlWNP7R3WWHEW6WM7iMFD+uaIz2pbaVctZJXdUFJwjsBS2y+wLOQ7Y54eRKdDO8/VDVXDlEf8M4l+IpBhYdORpLxUVbJDx5Qiz7vyBI3bssqnUHK3P4GUcKzzgmk9qHiXmS/c9AXEk+9vwKzKOVM+rAfM+mjSNZABKsavrGXz1dck4B2BTrbBLIHcHjm8bXTnx6HdqylChhz5n+5nSrWt8tmi7dp6ByJblURO1FEbfLQNqLtaMLo55Xi3xVhMNPvhqYaZqVMFBeNrtXPnq+nUmYy4sPoA8Hi/g==; 5:vzfsKKElbnO/mcYrdJ6p9OgLuYt6VyADG1paLVcH3S4ZsQt3WSl/rOnHoc2SDUL5V/iCuvCRULa7SV+7I3d02hDmYOlr7dzHlgRQaad/ANXCdmHZbhkLkBbcaTDxZHfGQgQdO3rQ7SxeKLHKlwuaO4+5qe9VXtW14zGlnUctuUk=; 7:L06jdNn6mRyDwPhY8ZS//rhcwkPvHpaJJ0fPHarq/ey+Wo8sW0cSalivdmFAqxEXLsSlHnwx+F1Q+1ijXGx/eRhSwvWpDVW0LvZxDGZgZgvHaVlg727Z25OAji+426TaU46aCldOvZNchNwq4ClXHluu79BSdz0REGoof7MH2IeTUijBH6+BU/LTeYuSzFVyO8+qLT6QI6BScDE17rsEatw2cf+dlqi1j8jQeW+g1In0AiI93m+eVRqzEf8PdnkG
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: efa82eac-316a-4c1d-8841-08d618c0a848
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4412; 
x-ms-traffictypediagnostic: DM6PR05MB4412:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(788757137089)(21748063052155); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699050); SRVR:DM6PR05MB4412; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4412; 
x-forefront-prvs: 07935ACF08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(376002)(396003)(346002)(39860400002)(199004)(189003)(52084003)(105586002)(68736007)(14454004)(8936002)(4326008)(446003)(93886005)(81166006)(66066001)(9326002)(186003)(33656002)(76176011)(11346002)(26005)(5250100002)(81156014)(229853002)(478600001)(53546011)(6506007)(102836004)(6436002)(5660300001)(25786009)(14444005)(6116002)(256004)(6306002)(83716003)(316002)(8676002)(36756003)(54896002)(2900100001)(99286004)(39060400002)(476003)(106356001)(82746002)(2616005)(3846002)(6246003)(6486002)(2906002)(53936002)(236005)(6512007)(86362001)(110136005)(97736004)(486006)(58126008)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4412; H:DM6PR05MB4665.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-microsoft-antispam-message-info: uu1RkCvHmcuBGRffcZz9dop3lfJZzlndvU/KfxLrfEgCgCBAtkmrWlI9TxQpMIDfjn2iX9UkylqevR/D7Qx+hdtTFOAQCttq4BlISWBnWu+PGeoyQbbjNlAjVjx1EL5PpT7gXy8dOkTYOesrn1rUB+yxaaOGmo8ebngG+9PGRFgdMe5Tvuc7nynTZbux5ThwQY3SnpUFhIxGXNv7LkWI3elX4vN7+w4XDsikAuuxggMjnXpD2ympZqedzCwiaD/rJ0C00yitH9TWiAJUClTBLjjdO+EkZk2BPCRcyOEj1qY4HGtp27R8350tLMMzo+Zn6yc0lj+aTtM3z7WH0HMtqEVp9I1+0isDUPJyphDeq38=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_816500467DB34D959ED28D915B24C62Djunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: efa82eac-316a-4c1d-8841-08d618c0a848
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2018 15:01:45.4276 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4412
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-12_08:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809120155
Archived-At: 
Subject: Re: [Netconf] WGLC on zerotouch draft
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 15:02:02 -0000

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

SGkgTWFoZXNoLA0KDQpUaGlzIGlzIHRoZSBpc3N1ZSB0aGF0IHVsdGltYXRlbHkgbGVkIHRvIHRo
ZSBjcmVhdGlvbiBvZiBub24tbm9ybWF0aXZlIGRldmljZSBtb2RlbCBpbiBBcHBlbmRpeCBBLCB3
aGljaCB5b3UgY2FuIHNlZSBpbmNsdWRlcyBhIGxlYWYgbm9kZSBjYWxsZWQgImVuYWJsZWQiLiAg
QWxzbyBub3RlIHRoaXMgc2VudGVuY2UgYXQgdGhlIGVuZCBvZiBTZWN0aW9uIDUuMTogIkEgWUFO
RyBtb2R1bGUgcmVwcmVzZW50aW5nIHRoaXMgZGF0YSBpcyBwcm92aWRlZCBpbiBBcHBlbmRpeCBB
LiINCg0KU2VwYXJhdGVseSwgcGxlYXNlIGJlIGFkdmlzZWQgdGhhdCwgaW4gYWRkaXRpb24gdG8g
YWRkaW5nIGEgcmVmIHRvIFJGQyA2MTg3LCBwZXIgeW91ciByZXF1ZXN0LCBJYW4sIG15IGNvLWF1
dGhvciwganVzdCBub3RpY2VkIGEgYnVnIGluIFNlY3Rpb24gOCAocy91cmktbGVuZ3RoOiB2YXJp
YWJsZSwgaW4gb2N0ZXRzL3VyaS1sZW5ndGg6IDIgb2N0ZXRzIGxvbmcsIHNwZWNpZmllcyB0aGUg
bGVuZ3RoIG9mIHRoZSBVUkkgZGF0YSkgYW5kLCBhbHNvLCBJIHJlY2VpdmVkIGEgcHJpdmF0ZSBl
bWFpbCB0aGlzIG1vcm5pbmcgbm90aW5nIHRoYXQgdGhlIHRlcm0gImJvb3RzdHJhcHBpbmcgaW5m
b3JtYXRpb24iIGlzIGJlaW5nIHVzZWQgaW4gcGxhY2VzLCB3aGVyZSBpdCBzaG91bGQgYmUgZWl0
aGVyICJib290c3RyYXBwaW5nIGRhdGEiIG9yICJ6ZXJvdG91Y2ggaW5mb3JtYXRpb24iLiAgIEkn
ZCBsaWtlIHRvIGNsZWFuIHVwIHRoZXNlIGVkaXRvcmlhbCBpc3N1ZXMgbm93IGFuZCBwb3N0IC0y
NSAodG9kYXkpIC0gb2theT8NCg0KVGhhbmtzLA0KS2VudCAvLyBjb250cmlidXRvcg0KDQoNCk9u
IDkvMTEvMTgsIDg6NTAgUE0sICJNYWhlc2ggSmV0aGFuYW5kYW5pIiA8bWpldGhhbmFuZGFuaUBn
bWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KSSBk
byBub3Qgc2VlIGFueSBlLW1haWwgb3IgdXBkYXRlcyBpbiB0aGUgZG9jdW1lbnQgdGhhdCByZWZs
ZWN0IHdoYXQgd2FzIGZpbmFsbHkgYWdyZWVkIHVwb24gZm9yIHRoaXMgaXNzdWUgcmFpc2VkLg0K
DQoNCg0KT24gTm92IDEzLCAyMDE3LCBhdCA2OjU3IEFNLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpA
dGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+PiB3cm90ZToNCg0KDQpvICBTZWN0aW9u
IDUuMSwgaXRlbSAxDQoNCkFkZCByZWZlcmVuY2UgdG8gdGhlIG5ldyBtb2R1bGUgaWV0Zi16ZXJv
dG91Y2gtZGV2aWNlLCBtYXliZSB0d2Vhaw0KdGhlIHRleHQ/DQoNCkkgcHV0IHRoZSByZWZlcmVu
Y2UgdG8gdGhlIG1vZHVsZSB1cCBhIGxldmVsIChTZWN0aW9uIDUpIGFzIHRoZSBtb2R1bGUNCmFw
cGxpZXMgdG8gbW9yZSB0aGFuIGp1c3QgaXRlbSAxLiAgUmVnYXJkaW5nIHR3ZWFraW5nIHRoZSB0
ZXh0LCBkbyB5b3UNCmhhdmUgYSBzdWdnZXN0aW9uPw0KDQpUaGUgdGV4dCBoYXMgZ3VpZGVsaW5l
cyBmb3IgaG93IGEgdmVuZG9yIHNob3VsZCBkZWZpbmUgYQ0KImVuYWJsZSB6ZXJvdG91Y2giIHZh
cmlhYmxlLiAgTWF5YmUgcmVwbGFjZSB0aGUgdGV4dCB3aXRoIGEgcmVmZXJlbmNlDQp0byB0aGUg
c3RhbmRhcmQgbW9kdWxlIGluc3RlYWQuDQoNCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhh
bmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0K

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj
b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u
Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkhpIE1haGVz
aCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPlRoaXMg
aXMgdGhlIGlzc3VlIHRoYXQgdWx0aW1hdGVseSBsZWQgdG8gdGhlIGNyZWF0aW9uIG9mIG5vbi1u
b3JtYXRpdmUgZGV2aWNlIG1vZGVsIGluIEFwcGVuZGl4IEEsIHdoaWNoIHlvdSBjYW4gc2VlIGlu
Y2x1ZGVzIGEgbGVhZiBub2RlIGNhbGxlZCAmcXVvdDtlbmFibGVkJnF1b3Q7LiZuYnNwOyBBbHNv
IG5vdGUgdGhpcyBzZW50ZW5jZSBhdCB0aGUgZW5kIG9mIFNlY3Rpb24NCiA1LjE6ICZxdW90O0Eg
WUFORyBtb2R1bGUgcmVwcmVzZW50aW5nIHRoaXMgZGF0YSBpcyBwcm92aWRlZCBpbiBBcHBlbmRp
eCBBLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy
aSI+U2VwYXJhdGVseSwgcGxlYXNlIGJlIGFkdmlzZWQgdGhhdCwgaW4gYWRkaXRpb24gdG8gYWRk
aW5nIGEgcmVmIHRvIFJGQyA2MTg3LCBwZXIgeW91ciByZXF1ZXN0LCBJYW4sIG15IGNvLWF1dGhv
ciwganVzdCBub3RpY2VkIGEgYnVnIGluIFNlY3Rpb24gOCAocy91cmktbGVuZ3RoOiB2YXJpYWJs
ZSwgaW4gb2N0ZXRzL3VyaS1sZW5ndGg6IDIgb2N0ZXRzDQogbG9uZywgc3BlY2lmaWVzIHRoZSBs
ZW5ndGggb2YgdGhlIFVSSSBkYXRhKSBhbmQsIGFsc28sIEkgcmVjZWl2ZWQgYSBwcml2YXRlIGVt
YWlsIHRoaXMgbW9ybmluZyBub3RpbmcgdGhhdCB0aGUgdGVybSAmcXVvdDtib290c3RyYXBwaW5n
IGluZm9ybWF0aW9uJnF1b3Q7IGlzIGJlaW5nIHVzZWQgaW4gcGxhY2VzLCB3aGVyZSBpdCBzaG91
bGQgYmUgZWl0aGVyICZxdW90O2Jvb3RzdHJhcHBpbmcgZGF0YSZxdW90OyBvciAmcXVvdDt6ZXJv
dG91Y2ggaW5mb3JtYXRpb24mcXVvdDsuICZuYnNwOyZuYnNwO0knZCBsaWtlIHRvDQogY2xlYW4g
dXAgdGhlc2UgZWRpdG9yaWFsIGlzc3VlcyBub3cgYW5kIHBvc3QgLTI1ICh0b2RheSkgLSBva2F5
PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtz
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpDYWxpYnJpIj5LZW50IC8vIGNvbnRyaWJ1dG9yPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh
bGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDkvMTEvMTgsIDg6
NTAgUE0sICZxdW90O01haGVzaCBKZXRoYW5hbmRhbmkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0
bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+Jmd0
OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj
YTtjb2xvcjpibGFjayI+SSBkbyBub3Qgc2VlIGFueSBlLW1haWwgb3IgdXBkYXRlcyBpbiB0aGUg
ZG9jdW1lbnQgdGhhdCByZWZsZWN0IHdoYXQgd2FzIGZpbmFsbHkgYWdyZWVkIHVwb24gZm9yIHRo
aXMgaXNzdWUgcmFpc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAxMywgMjAxNywgYXQgNjo1NyBBTSwgTWFydGluIEJqb3Jr
bHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwv
YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDtmb250LXZhcmlhbnQtY2Fwczog
bm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtp
dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3
b3JkLXNwYWNpbmc6MHB4Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxicj4NCm8gJm5ic3A7U2VjdGlv
biA1LjEsIGl0ZW0gMTxicj4NCjxicj4NCkFkZCByZWZlcmVuY2UgdG8gdGhlIG5ldyBtb2R1bGUg
aWV0Zi16ZXJvdG91Y2gtZGV2aWNlLCBtYXliZSB0d2Vhazxicj4NCnRoZSB0ZXh0PzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnI+DQpJIHB1
dCB0aGUgcmVmZXJlbmNlIHRvIHRoZSBtb2R1bGUgdXAgYSBsZXZlbCAoU2VjdGlvbiA1KSBhcyB0
aGUgbW9kdWxlPGJyPg0KYXBwbGllcyB0byBtb3JlIHRoYW4ganVzdCBpdGVtIDEuICZuYnNwO1Jl
Z2FyZGluZyB0d2Vha2luZyB0aGUgdGV4dCwgZG8geW91PGJyPg0KaGF2ZSBhIHN1Z2dlc3Rpb24/
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxi
cj4NClRoZSB0ZXh0IGhhcyBndWlkZWxpbmVzIGZvciBob3cgYSB2ZW5kb3Igc2hvdWxkIGRlZmlu
ZSBhPGJyPg0KJnF1b3Q7ZW5hYmxlIHplcm90b3VjaCZxdW90OyB2YXJpYWJsZS4gJm5ic3A7TWF5
YmUgcmVwbGFjZSB0aGUgdGV4dCB3aXRoIGEgcmVmZXJlbmNlPGJyPg0KdG8gdGhlIHN0YW5kYXJk
IG1vZHVsZSBpbnN0ZWFkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1haGVzaCBKZXRo
YW5hbmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFu
aUBnbWFpbC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_816500467DB34D959ED28D915B24C62Djunipernet_--


From nobody Wed Sep 12 09:47:26 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9F6130E95 for ; Wed, 12 Sep 2018 09:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNYYI-laqdLB for ; Wed, 12 Sep 2018 09:47:22 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 677B7130E94 for ; Wed, 12 Sep 2018 09:47:21 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id d1-v6so1354927pgo.3 for ; Wed, 12 Sep 2018 09:47:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DC2gbNSPAChAHy/ZtDsax2bXba4EOOiG8RZYLimMdtg=; b=rlpcGNFxN1C1/YO3ZcoL9Yv8sxaFECpSd/IZ599fCcyAlq84EciEn+YIAd9Sbun8J5 Pr4sOV2HrG4MO3WvOH7/0jdQlfiX3HdfZW2qOM1ZtLtoAGaXJIidIzoI/ZfyEKwBldif +44tPdiM6L6uGS09pDNWELgUrH+i63oUiln0pK6ThbjZeZ+HZPVuDR9dStpBF0HZQ7vn EHrG9O5EFKi7CsTJ/6/HYdj02HjDSnKReMAYhLuJvBAmAj9JuhnGbFS2jRcwRUkOnau1 gvTdUwgO1fNG/eWdgI8FXsB2hmlG6BFOjb0KZAPRGSwMRVlMsrk0oVhoYvcAZNgYg6vP ouCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DC2gbNSPAChAHy/ZtDsax2bXba4EOOiG8RZYLimMdtg=; b=tMFEjse1JzU3q+eyxy2hjqF0xtK+4p0i3Irv3WbO4AQlHnOSMSmFPI1dm55BVMM+dU 9Nu9+mKXzOkTI+ra+SPhay3DwtyPDb2rwqZWYKd/WAzkPFO4SnnakZzmgPrWf5gRBfgi sWdmETWVTD1GTqmRDdz4quhczAVErRQrWHVXjGH5EJRRGL1rIz3etlVBuJv7PKvBuAEo bbN7yG7knQJxVRNddeyaYSVj1BMpbG0zMQOA3zGneo7V2DhCpS5aG9mVXhTOu+HilIXP VY8HRQ2FosgNcORR+Y/7V51W8NMMKQInZphL8UEvHhSjSvKOp0shE/H+6AMxZWsBDJ+m SoVw==
X-Gm-Message-State: APzg51CWJCsywuRKu9I/CSqH7esZrZfKFDaHHZEDREqcHhR2cLAMbwth 0M2sskxyrmh5FGYJkKpmzJ00LPm0
X-Google-Smtp-Source: ANB0VdbeACrD6rwAP4jZ3yKkBFsrOG3uzELaMGyj8SULNf/eIS6850um3/mOVyqPBs4PCAgg7ZnzuQ==
X-Received: by 2002:a63:e001:: with SMTP id e1-v6mr3308610pgh.380.1536770840883;  Wed, 12 Sep 2018 09:47:20 -0700 (PDT)
Received: from [10.2.48.47] ([208.91.2.2]) by smtp.gmail.com with ESMTPSA id r12-v6sm4528317pfh.79.2018.09.12.09.47.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 09:47:19 -0700 (PDT)
From: Mahesh Jethanandani 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_209A9196-5A47-4764-97B7-709B8B3EAFCC"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 12 Sep 2018 09:47:18 -0700
In-Reply-To: <81650046-7DB3-4D95-9ED2-8D915B24C62D@juniper.net>
Cc: Martin Bjorklund , Netconf 
To: Kent Watsen 
References:  <20171102.145546.466862355235662064.mbj@tail-f.com> <9430CAD9-E45D-4AC1-BC0C-C3353AFA5085@juniper.net> <20171113.155741.613591566578760847.mbj@tail-f.com> <4EF52CE6-AE64-47AB-94E3-F114E41E5E28@gmail.com> <81650046-7DB3-4D95-9ED2-8D915B24C62D@juniper.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [Netconf] WGLC on zerotouch draft
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 16:47:25 -0000

--Apple-Mail=_209A9196-5A47-4764-97B7-709B8B3EAFCC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Kent,

> On Sep 12, 2018, at 8:01 AM, Kent Watsen  wrote:
>=20
> Hi Mahesh,
> =20
> This is the issue that ultimately led to the creation of non-normative =
device model in Appendix A, which you can see includes a leaf node =
called "enabled".  Also note this sentence at the end of Section 5.1: "A =
YANG module representing this data is provided in Appendix A.=E2=80=9D

Thanks for the clarification.

> =20
> Separately, please be advised that, in addition to adding a ref to RFC =
6187, per your request, Ian, my co-author, just noticed a bug in Section =
8 (s/uri-length: variable, in octets/uri-length: 2 octets long, =
specifies the length of the URI data) and, also, I received a private =
email this morning noting that the term "bootstrapping information" is =
being used in places, where it should be either "bootstrapping data" or =
"zerotouch information".   I'd like to clean up these editorial issues =
now and post -25 (today) - okay?

Sounds good.

Cheers.

> =20
> Thanks,
> Kent // contributor
> =20
> =20
> On 9/11/18, 8:50 PM, "Mahesh Jethanandani" > wrote:
> =20
> =20
> I do not see any e-mail or updates in the document that reflect what =
was finally agreed upon for this issue raised.
> =20
>=20
>=20
>> On Nov 13, 2017, at 6:57 AM, Martin Bjorklund > wrote:
>> =20
>>>>=20
>>>> o  Section 5.1, item 1
>>>>=20
>>>> Add reference to the new module ietf-zerotouch-device, maybe tweak
>>>> the text?
>>>=20
>>> I put the reference to the module up a level (Section 5) as the =
module
>>> applies to more than just item 1.  Regarding tweaking the text, do =
you
>>> have a suggestion?
>>=20
>> The text has guidelines for how a vendor should define a
>> "enable zerotouch" variable.  Maybe replace the text with a reference
>> to the standard module instead.
>=20
> =20
> =20
> Mahesh Jethanandani
> mjethanandani@gmail.com 

--Apple-Mail=_209A9196-5A47-4764-97B7-709B8B3EAFCC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Hi Kent,





On Sep 12, 2018, at 8:01 AM, Kent Watsen <kwatsen@juniper.net>=
 wrote:

Hi Mahesh,
 
This is the issue that ultimately led to the =
creation of non-normative device model in Appendix A, which you can see =
includes a leaf node called "enabled".  Also note this sentence at =
the end of Section 5.1: "A YANG module representing this data is =
provided in Appendix A.=E2=80=9D

Thanks for the clarification.

 
Separately, please be advised that, in addition to =
adding a ref to RFC 6187, per your request, Ian, my co-author, just =
noticed a bug in Section 8 (s/uri-length: variable, in =
octets/uri-length: 2 octets long, specifies the length of the URI data) =
and, also, I received a private email this morning noting that the term =
"bootstrapping information" is being used in places, where it should be =
either "bootstrapping data" or "zerotouch information".   I'd =
like to clean up these editorial issues now and post -25 (today) - =
okay?

Sounds good.

Cheers.

 
Thanks,
Kent // contributor
 
 
On =
9/11/18, 8:50 PM, "Mahesh Jethanandani" <mjethanandani@gmail.com> =
wrote:
 
 
I do not =
see any e-mail or updates in the document that reflect what was finally =
agreed upon for this issue raised.
 


On Nov 13, 2017, at 6:57 AM, =
Martin Bjorklund <mbj@tail-f.com> =
wrote:
 

o  Section 5.1, item 1

Add =
reference to the new module ietf-zerotouch-device, maybe tweak
the text?

I put the reference =
to the module up a level (Section 5) as the module
applies =
to more than just item 1.  Regarding tweaking the text, do you
have a suggestion?

The text has guidelines for how a vendor =
should define a
"enable zerotouch" variable.  Maybe =
replace the text with a reference
to the standard module =
instead.
 
 
Mahesh Jethanandani
mjethanandani@gmail.com

=

--Apple-Mail=_209A9196-5A47-4764-97B7-709B8B3EAFCC--


From nobody Wed Sep 12 10:24:20 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D53C128CF2 for ; Wed, 12 Sep 2018 10:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham 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 KxS95-tlVYGN for ; Wed, 12 Sep 2018 10:24:15 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 B39B41277BB for ; Wed, 12 Sep 2018 10:24:15 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8CHJMjI030823; Wed, 12 Sep 2018 10:24:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=Yju/VSY1HCym4cRi1HEeWb4SpkZj4jlbmB2feBVGMag=; b=epY+TaVu26BGL4jW94PtqKf2Y63sVYcb/Cg+n4IL+SoOLbm3Y8kAKbLQfg1IUH7YA1UE nSctfbhg+cviDQzuOLzjeSJxzYn8lbhq1B1b9n9BTQoOFbQcFNwMyfyUNW45zyFcOBpY g3YOXSMunsr+m9AeOVayLn7f/qpo84hxsRgIDHiaKctlilq+w+CC8OZzhb+SiEkQsYnN i7UnL7UOwHpDMcqBAcwSXOlZVeO2PgtTa8yCADhkwczLoEPg2G4Sk93FeMe7CLAgZzOl TMFeha8J9cVsEasks8jybnKUErScl0S9JopJWkLkNtPOdxTWvUIGiu8+OzkZASsW0MiD RQ== 
Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp0120.outbound.protection.outlook.com [216.32.181.120]) by mx0a-00273201.pphosted.com with ESMTP id 2mew0uh9sa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 12 Sep 2018 10:24:14 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6SPR01MB3.namprd05.prod.outlook.com (20.176.102.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.7; Wed, 12 Sep 2018 17:24:12 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1143.010; Wed, 12 Sep 2018 17:24:12 +0000
From: Kent Watsen 
To: Mahesh Jethanandani , netconf 
Thread-Topic: [Netconf] IPR and known implementation (Was Re: WG LC for zerotouch)
Thread-Index: AQHUSjogJftDkrd43EiFh2/7t6Y4l6Tso1SA
Date: Wed, 12 Sep 2018 17:24:12 +0000
Message-ID: <1AF83AB6-9DC0-4840-AFEA-17F6242EC334@juniper.net>
References: <9F33F0C4-7697-4774-B7F1-A8556A6A73A1@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6SPR01MB3; 6:h1WuF2OjM8WO08TsLpa/21O0O0/Wst0d7sFNpnCsse/ZK01nB5CCQ1v0OiYWxEnKs5+zhrVST4gFofKERinTWd2a2c7TbLKG9NS8PnyYxUWbXQzVGut+4+Qdbecu/ax/BLu2KTvk3tHKKr82BhJSmsH8Xy/081WrxxlmSiiOuz1kkRQRHq4hYmcd7zf7pi08Bnd7H3inlD37YF2QptB4lAJpNK2yfF1ir1lDypPVGFhywMvEmRa2EQUCUftu7zN+3GUnWMXXrqgGLFrBb7dM5+WLXR4cIFBoUtfW/tNzao1S8wgBYDy/yriFm+RLVYMsvsszJmldmvj8lPXauxykdK7DIpFWfgyy3jh41UYzN8UtE9obs09BgsKRE6cL8tOZ/QRkKIncKjg2lOYWkk3SYu8N+nZ1jt1NjBeO2yVpKC5+h7ur+dUgO9BgYVLGhLRqkWJ4m/tHFLds2tHolpia+Q==; 5:YunAUk7KnQKKqEqQttN3l6LiVjykGGe3FuXeExRCxippeoDbQIn5wqUWTTqzbSPUII7e3AbUvL7cNcLJTfps/NPYnO2k96k+LSxweB3V2qJG6ypGX/emJRPhmqQ9QwKA95HVisrri1Lkb5EfnoK9Pf6iFK5kbHuQUiYQzcWaBnI=; 7:cnIwlvAJSmY/R5uKUTmKEyxJ+nNUZbot19LgNd2A4s98sLTaV/cttbPKkYqYQc/JrQXvZWsTKbDzJPaq+xU5+yUvOo1yzidYrwlVfb4UtjmW5mltnhFfg75Wt0p7T4U5hwem+I3RwYTasjL/cK3qT6Mt73DlVBxmyhgK5iDm83KeHDs7Bpn4FNI7P2lKTeojctyp4TSue+GPqW86fXNHK0reCwFCUQIoO9WdQlYSoRqSWuZ71lF35hRxOU4D0Jee
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 5910d9a4-3458-4e92-93f4-08d618d48e93
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(4534165)(4627221)(201703031133081)(201702281549075)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6SPR01MB3; 
x-ms-traffictypediagnostic: DM6SPR01MB3:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(120809045254105)(85827821059158)(21748063052155)(163750095850);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231344)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699050)(76991041); SRVR:DM6SPR01MB3; BCL:0; PCL:0; RULEID:; SRVR:DM6SPR01MB3; 
x-forefront-prvs: 07935ACF08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39860400002)(136003)(396003)(199004)(189003)(76176011)(966005)(8936002)(36756003)(3846002)(6246003)(39060400002)(6116002)(5660300001)(66066001)(82746002)(83716003)(25786009)(6486002)(102836004)(2900100001)(68736007)(478600001)(53546011)(186003)(81156014)(81166006)(2906002)(33656002)(106356001)(26005)(6506007)(105586002)(2616005)(486006)(5250100002)(7736002)(8676002)(58126008)(14444005)(99286004)(476003)(54896002)(6436002)(256004)(110136005)(229853002)(11346002)(6346003)(316002)(6512007)(86362001)(606006)(6306002)(53936002)(97736004)(236005)(446003)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6SPR01MB3; H:DM6PR05MB4665.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-microsoft-antispam-message-info: ShLt6MrC7S3DmLvTWnixgkd+D1UskWYudkq+WIBYrifxAqyYomXM37yNpr8zt2SDK9nzXyC97+6CfdTU0U9MAd0psUPx9zLN+8eeAKZaCACIubL+yqSOXBZ11DInsIs0ydHxzMei8crHTz/Bk3Ec8750dHuLn3a8Q89J/z+T9ZWVeUoJYKGYQZqvgpIvmNcEgKXf5KZZr2DJprq2z4QjK4n13AZibWI7r115BBH6aaO5mkwPp2xSJD0REMqYCbl77y7VrU0rRJgkAoDnOC8VuivmGS6aJpuabBeHMtw7OB+PszuEpPl1Fb/Pzd4eizn2EdpshRvKfXzyWy6PNXL5iSH30Atg3d+orzq7iU6RqTM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_1AF83AB69DC04840AFEA17F6242EC334junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 5910d9a4-3458-4e92-93f4-08d618d48e93
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2018 17:24:12.2712 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6SPR01MB3
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-12_09:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809120174
Archived-At: 
Subject: Re: [Netconf] IPR and known implementation (Was Re: WG LC for zerotouch)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 17:24:18 -0000

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

WWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Lg0KWWVzLCB0
aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVs
ZXMuDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yNTgxLg0KDQpLZW50IC8vIGNv
LWF1dGhvcg0KDQoNCg0KT24gOS8xMS8xOCwgOTo0NCBQTSwgIk5ldGNvbmYgb24gYmVoYWxmIG9m
IE1haGVzaCBKZXRoYW5hbmRhbmkiIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5l
dGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIG1qZXRoYW5hbmRhbmlAZ21haWwu
Y29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCg0KDQpPbiBT
ZXAgMjUsIDIwMTcsIGF0IDY6NDUgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRh
bmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpU
aGUgbGFzdCByb3VuZCBvZiBXRyBMQyBvbiBaZXJvdG91Y2ggZHJhZnQ8aHR0cHM6Ly91cmxkZWZl
bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1s
X2RyYWZ0LTJEaWV0Zi0yRG5ldGNvbmYtMkR6ZXJvdG91Y2gtMkQxNyZkPUR3TUZhUSZjPUhBa1l1
aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQ
b09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09WUpkUEJuekFtMGFTeDVCUk9QN3BkQm5ya0hU
T0ZyN2N3NXpOOWx2aVF2ZyZzPS1HLUl0QkpaZmxhYnZEUG5OemVHR0JaVEcxblhXaUQ4bnRtMEpZ
OGltOXcmZT0+IHJlc3VsdGVkIGluIGxvdCBjb21tZW50cyBiZWluZyBwb3N0ZWQgYWJvdXQgdGhl
IGRyYWZ0LiBLZW50IGhhcyBzaW5jZSB0aGVuIHVwZGF0ZWQgdGhlIGRvY3VtZW50IHRvIGFkZHJl
c3MgYWxsIHRob3NlIGNvbW1lbnRzIGFuZCBwb3N0ZWQgLTE3IHZlcnNpb24gb2YgdGhlIGRyYWZ0
Lg0KDQpXZSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyBub3cgcmVhZHkgZm9yIGEgcmUtcnVuIG9m
IHRoYXQgY2FsbC4gVGhpcyBzdGFydHMgYSB0d28td2VlayBXRyBMQyBvbiB0aGUgZHJhZnQuIFBs
ZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgaWYgeW91IGJlbGlldmUgdGhlIGRvY3VtZW50IGlz
IG5vdyByZWFkeSBmb3IgTEMuIFdlIG5lZWQgYWZmaXJtYXRpb24gb2Ygc3VwcG9ydCBmb3IgdGhl
IExDIHRvIHN1Y2NlZWQuIFVuZm9ydHVuYXRlbHksIHNpbGVuY2UgaXMgbm90IGFmZmlybWF0aW9u
LiBJZiB5b3UgYmVsaWV2ZSB0aGUgZG9jdW1lbnQgaXMgc3RpbGwgbm90IHJlYWR5LCBwbGVhc2Ug
aW5kaWNhdGUgd2h5LiBUaGUgTEMgd2lsbCBjb25jbHVkZSBvbiBPY3QuIDkuDQoNCkF1dGhvcnMs
IHBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFJzIHJlbGF0ZWQgdG8g
dGhlIGRvY3VtZW50LiBBbHNvLCBwbGVhc2UgaW5kaWNhdGUgaWYgdGhlcmUgYXJlIGFueSBrbm93
biBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIGRyYWZ0Lg0KDQpUaGlzIHRocmVhZCBkZXZvbHZlZCBp
bnRvIGEgcmV2aWV3IG9mIHRoZSBkcmFmdCwgd2hlcmUgdGhlIHR3byBxdWVzdGlvbnMgb24gSVBS
IGFuZCBrbm93biBpbXBsZW1lbnRhdGlvbnMgZ290IGxvc3QuIEFuZCB3aGlsZSB0aGVyZSBleGlz
dHMgb25lIElQUiBkaXNjbG9zdXJlLCB0aGlzIHF1ZXN0aW9uIGlzIHN0aWxsIHBlcnRpbmVudC4g
UGxlYXNlIG5vdGUgdGhhdCBhIHJlc3BvbnNlIGlzIHJlcXVpcmVkIGZyb20gQUxMIHRoZSBhdXRo
b3JzIG9yIGNvbnRyaWJ1dG9ycyB0byB0aGlzIGUtbWFpbC4gV2l0aG91dCBpdCwgdGhlIGRvY3Vt
ZW50IGNhbm5vdCBiZSBhZHZhbmNlZC4NCg0KQXJlIHRoZSBhdXRob3JzIG9yIGNvbnRyaWJ1dG9y
cyB0byB0aGUgZHJhZnQgYXdhcmUgb2YgYW55IElQUnMgcmVsYXRlZCB0byB0aGUgZHJhZnQ/IFBs
ZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQg
YXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0Kb3INCiJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBh
cHBsaWVzIHRvIHRoaXMgZHJhZnTigJ0NCg0KSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Ns
b3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM2NjksIDUz
NzggYW5kIDgxNzkgZm9yIG1vcmUgZGV0YWlscyk/DQoNCklmIHllcyB0byB0aGUgYWJvdmUsIHBs
ZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGlu
IGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyINCm9yDQoiTm8sIHRoZSBJUFIgaGFzIG5v
dCBiZWVuIGRpc2Nsb3NlZCINCg0KSWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55
IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbmsgYXBwcm9wcmlhdGUuDQoNCklmIHlvdSBhcmUg
b24gdGhlIFdHIG1haWxpbmcgbGlzdCBhbmQvb3IgYXR0ZW5kIFdHIG1lZXRpbmdzLCBpdCBpcyB5
b3VyIG9ibGlnYXRpb24gdW5kZXIgdGhlIElQUiBydWxlcyB0byBub3RpZnkgSUVURi4NCg0KRm9y
IG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgUkZDcyAzNjY5LCA1Mzc4LCA4MTc5IGFuZA0K
aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0
dWFsUHJvcGVydHk8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0
dHAtM0FfX3RyYWMudG9vbHMuaWV0Zi5vcmdfZ3JvdXBfaWVzZ190cmFjX3dpa2lfSW50ZWxsZWN0
dWFsUHJvcGVydHkmZD1Ed01GYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3Zv
RFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZt
PVlKZFBCbnpBbTBhU3g1QlJPUDdwZEJucmtIVE9GcjdjdzV6TjlsdmlRdmcmcz10bVFBWXQwMjRT
NDlxMGZlZXhMV1BNdEJQdVRTS3ZFYkxLQ29PMWlJR2Y0JmU9Pi4NCg0KRmluYWxseSwgaWYgeW91
IGFyZSBhd2FyZSBvZiBhbnkgaW1wbGVtZW50YXRpb25zIG9mIHRoaXMgZHJhZnQsIHBsZWFzZSBs
ZXQgdXMga25vdy4NCg0KDQpUaGFua3MuDQoNCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhh
bmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0K

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj
b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u
Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPlllcywgSSdt
IGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs
aWJyaSI+WWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGgg
SUVURiBJUFIgcnVsZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPmh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvaXByLzI1ODEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpIj5LZW50IC8vIGNvLWF1dGhvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
T24gOS8xMS8xOCwgOTo0NCBQTSwgJnF1b3Q7TmV0Y29uZiBvbiBiZWhhbGYgb2YgTWFoZXNoIEpl
dGhhbmFuZGFuaSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRm
Lm9yZyI+bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9
Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208
L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+T24gU2VwIDI1LCAyMDE3LCBhdCA2OjQ1IFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5p
ICZsdDs8YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRh
bmlAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5UaGUgbGFzdCByb3VuZCBvZiBXRyBMQyBvbiZuYnNwOzxhIGhyZWY9
Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9v
bHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRuZXRjb25mLTJEemVyb3RvdWNoLTJEMTcm
YW1wO2Q9RHdNRmFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhj
V3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZh
bXA7bT1ZSmRQQm56QW0wYVN4NUJST1A3cGRCbnJrSFRPRnI3Y3c1ek45bHZpUXZnJmFtcDtzPS1H
LUl0QkpaZmxhYnZEUG5OemVHR0JaVEcxblhXaUQ4bnRtMEpZOGltOXcmYW1wO2U9Ij5aZXJvdG91
Y2gNCiBkcmFmdDwvYT4mbmJzcDtyZXN1bHRlZCBpbiBsb3QgY29tbWVudHMgYmVpbmcgcG9zdGVk
IGFib3V0IHRoZSBkcmFmdC4gS2VudCBoYXMgc2luY2UgdGhlbiB1cGRhdGVkIHRoZSBkb2N1bWVu
dCB0byBhZGRyZXNzIGFsbCB0aG9zZSBjb21tZW50cyBhbmQgcG9zdGVkIC0xNyB2ZXJzaW9uIG9m
IHRoZSBkcmFmdC4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+V2UgYmVsaWV2ZSB0aGUgZG9jdW1lbnQgaXMgbm93IHJlYWR5IGZvciBhIHJlLXJ1biBvZiB0
aGF0IGNhbGwuIFRoaXMgc3RhcnRzIGEgdHdvLXdlZWsgV0cgTEMgb24gdGhlIGRyYWZ0LiBQbGVh
c2UgaW5kaWNhdGUgeW91ciBzdXBwb3J0IGlmIHlvdSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyBu
b3cgcmVhZHkgZm9yIExDLiBXZSBuZWVkIGFmZmlybWF0aW9uIG9mIHN1cHBvcnQgZm9yIHRoZSBM
QyB0byBzdWNjZWVkLg0KIFVuZm9ydHVuYXRlbHksIHNpbGVuY2UgaXMgbm90IGFmZmlybWF0aW9u
LiBJZiB5b3UgYmVsaWV2ZSB0aGUgZG9jdW1lbnQgaXMgc3RpbGwgbm90IHJlYWR5LCBwbGVhc2Ug
aW5kaWNhdGUgd2h5LiBUaGUgTEMgd2lsbCBjb25jbHVkZSBvbiBPY3QuIDkuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF1dGhvcnMsIHBsZWFz
ZSBpbmRpY2F0ZSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFJzIHJlbGF0ZWQgdG8gdGhlIGRv
Y3VtZW50LiBBbHNvLCBwbGVhc2UgaW5kaWNhdGUgaWYgdGhlcmUgYXJlIGFueSBrbm93biBpbXBs
ZW1lbnRhdGlvbnMgb2YgdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHRocmVh
ZCBkZXZvbHZlZCBpbnRvIGEgcmV2aWV3IG9mIHRoZSBkcmFmdCwgd2hlcmUgdGhlIHR3byBxdWVz
dGlvbnMgb24gSVBSIGFuZCBrbm93biBpbXBsZW1lbnRhdGlvbnMgZ290IGxvc3QuIEFuZCB3aGls
ZSB0aGVyZSBleGlzdHMgb25lIElQUiBkaXNjbG9zdXJlLCB0aGlzIHF1ZXN0aW9uIGlzIHN0aWxs
IHBlcnRpbmVudC4gUGxlYXNlIG5vdGUgdGhhdCBhIHJlc3BvbnNlIGlzIHJlcXVpcmVkIGZyb20N
CiBBTEwgdGhlIGF1dGhvcnMgb3IgY29udHJpYnV0b3JzIHRvIHRoaXMgZS1tYWlsLiBXaXRob3V0
IGl0LCB0aGUgZG9jdW1lbnQgY2Fubm90IGJlIGFkdmFuY2VkLiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcmUgdGhlIGF1dGhvcnMg
b3IgY29udHJpYnV0b3JzIHRvIHRoZSBkcmFmdCBhd2FyZSBvZiBhbnkgSVBScyByZWxhdGVkIHRv
IHRoZSBkcmFmdD8gUGxlYXNlIHN0YXRlIGVpdGhlcjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7Tm8sIEknbSBub3QgYXdhcmUgb2Yg
YW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCZxdW90Ozxicj4NCm9yPGJyPg0KJnF1
b3Q7WWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ04oCdPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHNv
LCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBS
IHJ1bGVzJm5ic3A7KHNlZSBSRkNzIDM2NjksIDUzNzggYW5kIDgxNzkgZm9yIG1vcmUgZGV0YWls
cyk/PGJyPg0KPGJyPg0KSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjo8
YnI+DQo8YnI+DQomcXVvdDtZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBs
aWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyZxdW90Ozxicj4NCm9yPGJyPg0KJnF1b3Q7Tm8sIHRo
ZSBJUFIgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCZxdW90Ozxicj4NCjxicj4NCklmIHlvdSBhbnN3
ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rJm5i
c3A7YXBwcm9wcmlhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPklmIHlvdSBhcmUgb24gdGhlIFdHIG1haWxpbmcgbGlzdCBhbmQvb3IgYXR0
ZW5kIFdHIG1lZXRpbmdzLCBpdCBpcyB5b3VyIG9ibGlnYXRpb24gdW5kZXIgdGhlIElQUiBydWxl
cyB0byBub3RpZnkgSUVURi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Rm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUmbmJzcDtSRkNz
IDM2NjksIDUzNzgsIDgxNzkmbmJzcDthbmQ8YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVu
c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fdHJhYy50b29scy5pZXRmLm9yZ19n
cm91cF9pZXNnX3RyYWNfd2lraV9JbnRlbGxlY3R1YWxQcm9wZXJ0eSZhbXA7ZD1Ed01GYVEmYW1w
O2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQ
MHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPVlKZFBCbnpBbTBh
U3g1QlJPUDdwZEJucmtIVE9GcjdjdzV6TjlsdmlRdmcmYW1wO3M9dG1RQVl0MDI0UzQ5cTBmZWV4
TFdQTXRCUHVUU0t2RWJMS0NvTzFpSUdmNCZhbXA7ZT0iPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYu
b3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5PC9hPi48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmluYWxseSwg
aWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgaW1wbGVtZW50YXRpb25zIG9mIHRoaXMgZHJhZnQsIHBs
ZWFzZSBsZXQgdXMga25vdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFoZXNoIEpldGhhbmFuZGFuaTxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOm1qZXRo
YW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N
CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_1AF83AB69DC04840AFEA17F6242EC334junipernet_--


From nobody Wed Sep 12 10:27:37 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FEF130F67 for ; Wed, 12 Sep 2018 10:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham 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 bEW_FVztwQDp for ; Wed, 12 Sep 2018 10:27:28 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 7AB54130ECE for ; Wed, 12 Sep 2018 10:27:27 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8CHPB8g030064; Wed, 12 Sep 2018 10:27:26 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=6PUulFV9h5oZJVc2TZk7Ui4tnSrTcMxHO7OG174SZZI=; b=vW9O3JCuth5mHJkQVqG/QjwUGdN0q6y2ul7FhxcyrPq1F8zI3ncjCGH+eiUyAT3Lu9Qo WxlB3T9H9uwFQa/t3QkxIcfr/ADNc95IRchQ4IdLBZu3cAqWDFv0/QDz3L25j5sDK6Pd cYEMMX7HqvufhBo8xGz9M6rqorH53NCCKgr8kRNq/6WBC+IJdItbMeHThj4lgOUXS2dZ J4EbXupQovM0SjArQqLh3FetRldxPOZGCbSt7TF6lwmPVpyjjrJVuDemPX6xDviLHT6N xGnWHJQyVxffzX0IMXTDiRm4kVcBnh84kMWnH62QMfPVWqh4f1wDyMTPkPVZLfPcIuYM GA== 
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0176.outbound.protection.outlook.com [216.32.180.176]) by mx0a-00273201.pphosted.com with ESMTP id 2mf52rr9tq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 12 Sep 2018 10:27:26 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4489.namprd05.prod.outlook.com (20.176.79.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.6; Wed, 12 Sep 2018 17:27:23 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1143.010; Wed, 12 Sep 2018 17:27:23 +0000
From: Kent Watsen 
To: Mahesh Jethanandani , netconf 
Thread-Topic: [Netconf] IPR and known implementation (Was Re: WG LC for zerotouch)
Thread-Index: AQHUSjogJftDkrd43EiFh2/7t6Y4l6Tso1SAgAAA5YA=
Date: Wed, 12 Sep 2018 17:27:23 +0000
Message-ID: 
References: <9F33F0C4-7697-4774-B7F1-A8556A6A73A1@gmail.com>  <1AF83AB6-9DC0-4840-AFEA-17F6242EC334@juniper.net>
In-Reply-To: <1AF83AB6-9DC0-4840-AFEA-17F6242EC334@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4489; 6:jUZqbGoW5arZ7z8z1u2MRX7crvT2niHFanTOmyE6Tkoz4zz2Y//OXbHpG3w3XqAO9PYPHYy6d0mua+xawMV7UgZHFmo5WWyqOhziT4V8KM2q71cadrB8A5bLJmTrWGEj/sfuKvjD1GuWERVCBTvs+M+524QeQqxSeUfy1V8DzDDSvsOMyBMuGqmMcUsgcanYZ3Z0S2jhRJ1qroHd3tJ0E5ndJJmn1pEEQeRY7aZRH6jBz3bNLseq2helFZkekUQ55cvE+KA+skS9IBYRWcRbyamfZXd87IkisFDczOV3/iV1aCBLfhBOtdDDJTY5Zg365fZu4pUD2OaB4zxs/IrrtDYZKxKl8IOopXPa90omTC/HHZoaccbO2XMPAy7j/EEFZNPDohL7oZvrSV7JUR7CAOji+EonoM3gJRgz2q8pxXQxUMEwqjFhgKTXL3QJ7yg70UEsvVbZ7eKea+CFS7d1vQ==; 5:7RSd/l4gBZ9e/6qTZ1fkS4FCLvoT7IJmO+JCPGxRsQS6Ak1WAWHSubz1oHEAEqRbwvrXv+uLEQHynN5wEXTg0b68TciReb0SfAFvn1LHWFpT+oOjLXe8PFMdPmDMqHhoz3BTrViFDK43h23yzBwz9LhifRSp0tL2O2gOQi2SDFU=; 7:r9v4vuCdbFKSkhb68yduVdXxRKkIRgoADdR6JZZmUjKuzYjJMtSuE+OxRI7VOh2zEYEP2hU3IAL9X3fHDC2VgDM3r3b2RRA4MbgJRuRyv29eZmmNJflemvigN/IdHHCq8fqXR89Q7E70lz/FKg1ZlX7zTWFXY4jvalmFcAVMjNIllr0ytZbV5DML/P97+GV8qhmW49/UWikPtVhqw4S0np2eoAFjcw79mqbBdgwBNs3w+059/WQ+P5LNX6CmAfBd
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 9cc6e8cf-eca0-4cc4-23b6-08d618d500bf
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4489; 
x-ms-traffictypediagnostic: DM6PR05MB4489:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(120809045254105)(138986009662008)(85827821059158)(21748063052155)(163750095850);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231344)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699050)(76991041); SRVR:DM6PR05MB4489; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4489; 
x-forefront-prvs: 07935ACF08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(376002)(346002)(396003)(366004)(199004)(189003)(5660300001)(256004)(6246003)(14444005)(6486002)(68736007)(966005)(54896002)(6306002)(53936002)(86362001)(606006)(2900100001)(6512007)(82746002)(99286004)(8676002)(236005)(6116002)(3846002)(105586002)(39060400002)(110136005)(81156014)(7736002)(97736004)(58126008)(2906002)(316002)(81166006)(14454004)(6506007)(25786009)(53546011)(33656002)(8936002)(83716003)(66066001)(106356001)(36756003)(5250100002)(6436002)(476003)(102836004)(229853002)(478600001)(26005)(76176011)(486006)(446003)(186003)(6346003)(2616005)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4489; H:DM6PR05MB4665.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-microsoft-antispam-message-info: Ll7s0fxRURJBevOLNS80Y2etrY6uKR37ScIsQNVDLBYpxtAmYNt21g3m3j0Qefs1t59YSG+uaip4mFHSe+gp6z8emTxOivqSbwge1R+Yz0lazeVlIXwZBxMzNf2RgWW3Ncnfnhaoglw05ivuwjMXU52fZd1n4SRsvVgzTWfcuZnx0hYY0MGI7g9AJSW2uIaIk38Y+odCsMc64I/lN90FY2nauePTlUdmK2C/8pY69qHnHw9UyzRISkVofc6V+L0Ozc/NsKpRQ6gb6BJNTTDBjzoG/Tu3xYz17WfXef24o0TUCn2VpP/AW86NmbZXfc9zGsIyR095D+36TWrHakBxODfLi5LQDYSf/iGnwzUnqwQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CE063410BB964F61BDDB1C7152BB0AF7junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 9cc6e8cf-eca0-4cc4-23b6-08d618d500bf
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2018 17:27:23.7870 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4489
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-12_09:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809120175
Archived-At: 
Subject: Re: [Netconf] IPR and known implementation (Was Re: WG LC for zerotouch)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 17:27:35 -0000

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

QXMgZm9yIGltcGxlbWVudGF0aW9ucywgbW9zdCBldmVyeXRoaW5nIGhhcyBiZWVuIGltcGxlbWVu
dGVkIGluIHVuaXQgdGVzdHMsIGFuZCBwYXJ0cyBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgaW4gcHJv
ZHVjdGlvbi4NCg0KS2VudA0KDQoNCk9uIDkvMTIvMTgsIDE6MjQgUE0sICJOZXRjb25mIG9uIGJl
aGFsZiBvZiBLZW50IFdhdHNlbiIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0
Y29uZi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Yga3dhdHNlbkBqdW5pcGVyLm5ldDxt
YWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KDQpZZXMsIEknbSBhd2FyZSBvZiBJ
UFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQuDQpZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlz
Y2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcy4NCmh0dHBzOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvaXByLzI1ODEuDQoNCktlbnQgLy8gY28tYXV0aG9yDQoNCg0KDQpPbiA5
LzExLzE4LCA5OjQ0IFBNLCAiTmV0Y29uZiBvbiBiZWhhbGYgb2YgTWFoZXNoIEpldGhhbmFuZGFu
aSIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYu
b3JnPiBvbiBiZWhhbGYgb2YgbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5h
bmRhbmlAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KDQoNCg0KT24gU2VwIDI1LCAyMDE3LCBhdCA2
OjQ1IFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWls
dG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+PiB3cm90ZToNCg0KVGhlIGxhc3Qgcm91bmQgb2Yg
V0cgTEMgb24gWmVyb3RvdWNoIGRyYWZ0PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv
bS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRu
ZXRjb25mLTJEemVyb3RvdWNoLTJEMTcmZD1Ed01GYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVq
QlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2
aklTbGFKZGNabyZtPVlKZFBCbnpBbTBhU3g1QlJPUDdwZEJucmtIVE9GcjdjdzV6TjlsdmlRdmcm
cz0tRy1JdEJKWmZsYWJ2RFBuTnplR0dCWlRHMW5YV2lEOG50bTBKWThpbTl3JmU9PiByZXN1bHRl
ZCBpbiBsb3QgY29tbWVudHMgYmVpbmcgcG9zdGVkIGFib3V0IHRoZSBkcmFmdC4gS2VudCBoYXMg
c2luY2UgdGhlbiB1cGRhdGVkIHRoZSBkb2N1bWVudCB0byBhZGRyZXNzIGFsbCB0aG9zZSBjb21t
ZW50cyBhbmQgcG9zdGVkIC0xNyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0KV2UgYmVsaWV2ZSB0
aGUgZG9jdW1lbnQgaXMgbm93IHJlYWR5IGZvciBhIHJlLXJ1biBvZiB0aGF0IGNhbGwuIFRoaXMg
c3RhcnRzIGEgdHdvLXdlZWsgV0cgTEMgb24gdGhlIGRyYWZ0LiBQbGVhc2UgaW5kaWNhdGUgeW91
ciBzdXBwb3J0IGlmIHlvdSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyBub3cgcmVhZHkgZm9yIExD
LiBXZSBuZWVkIGFmZmlybWF0aW9uIG9mIHN1cHBvcnQgZm9yIHRoZSBMQyB0byBzdWNjZWVkLiBV
bmZvcnR1bmF0ZWx5LCBzaWxlbmNlIGlzIG5vdCBhZmZpcm1hdGlvbi4gSWYgeW91IGJlbGlldmUg
dGhlIGRvY3VtZW50IGlzIHN0aWxsIG5vdCByZWFkeSwgcGxlYXNlIGluZGljYXRlIHdoeS4gVGhl
IExDIHdpbGwgY29uY2x1ZGUgb24gT2N0LiA5Lg0KDQpBdXRob3JzLCBwbGVhc2UgaW5kaWNhdGUg
aWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBScyByZWxhdGVkIHRvIHRoZSBkb2N1bWVudC4gQWxz
bywgcGxlYXNlIGluZGljYXRlIGlmIHRoZXJlIGFyZSBhbnkga25vd24gaW1wbGVtZW50YXRpb25z
IG9mIHRoZSBkcmFmdC4NCg0KVGhpcyB0aHJlYWQgZGV2b2x2ZWQgaW50byBhIHJldmlldyBvZiB0
aGUgZHJhZnQsIHdoZXJlIHRoZSB0d28gcXVlc3Rpb25zIG9uIElQUiBhbmQga25vd24gaW1wbGVt
ZW50YXRpb25zIGdvdCBsb3N0LiBBbmQgd2hpbGUgdGhlcmUgZXhpc3RzIG9uZSBJUFIgZGlzY2xv
c3VyZSwgdGhpcyBxdWVzdGlvbiBpcyBzdGlsbCBwZXJ0aW5lbnQuIFBsZWFzZSBub3RlIHRoYXQg
YSByZXNwb25zZSBpcyByZXF1aXJlZCBmcm9tIEFMTCB0aGUgYXV0aG9ycyBvciBjb250cmlidXRv
cnMgdG8gdGhpcyBlLW1haWwuIFdpdGhvdXQgaXQsIHRoZSBkb2N1bWVudCBjYW5ub3QgYmUgYWR2
YW5jZWQuDQoNCkFyZSB0aGUgYXV0aG9ycyBvciBjb250cmlidXRvcnMgdG8gdGhlIGRyYWZ0IGF3
YXJlIG9mIGFueSBJUFJzIHJlbGF0ZWQgdG8gdGhlIGRyYWZ0PyBQbGVhc2Ugc3RhdGUgZWl0aGVy
Og0KDQoiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBk
cmFmdCINCm9yDQoiWWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRy
YWZ04oCdDQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5j
ZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzNjY5LCA1Mzc4IGFuZCA4MTc5IGZvciBt
b3JlIGRldGFpbHMpPw0KDQpJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVy
Og0KDQoiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGgg
SUVURiBJUFIgcnVsZXMiDQpvcg0KIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQi
DQoNCklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFp
bHMgeW91IHRoaW5rIGFwcHJvcHJpYXRlLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBXRyBtYWlsaW5n
IGxpc3QgYW5kL29yIGF0dGVuZCBXRyBtZWV0aW5ncywgaXQgaXMgeW91ciBvYmxpZ2F0aW9uIHVu
ZGVyIHRoZSBJUFIgcnVsZXMgdG8gbm90aWZ5IElFVEYuDQoNCkZvciBtb3JlIGluZm9ybWF0aW9u
LCBwbGVhc2Ugc2VlIFJGQ3MgMzY2OSwgNTM3OCwgODE3OSBhbmQNCmh0dHA6Ly90cmFjLnRvb2xz
LmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5PGh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX190cmFjLnRvb2xz
LmlldGYub3JnX2dyb3VwX2llc2dfdHJhY193aWtpX0ludGVsbGVjdHVhbFByb3BlcnR5JmQ9RHdN
RmFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1Aw
eG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1ZSmRQQm56QW0wYVN4NUJS
T1A3cGRCbnJrSFRPRnI3Y3c1ek45bHZpUXZnJnM9dG1RQVl0MDI0UzQ5cTBmZWV4TFdQTXRCUHVU
U0t2RWJMS0NvTzFpSUdmNCZlPT4uDQoNCkZpbmFsbHksIGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55
IGltcGxlbWVudGF0aW9ucyBvZiB0aGlzIGRyYWZ0LCBwbGVhc2UgbGV0IHVzIGtub3cuDQoNCg0K
VGhhbmtzLg0KDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29t
PG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg0K

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh
bWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3
aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUg
bm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWZv
bnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQt
dHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1h
bGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s
eTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNv
bG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7
DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx
MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv
bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJn
Y29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8
ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkFzIGZvciBpbXBsZW1lbnRhdGlvbnMsIG1vc3QgZXZl
cnl0aGluZyBoYXMgYmVlbiBpbXBsZW1lbnRlZCBpbiB1bml0IHRlc3RzLCBhbmQgcGFydHMgaGF2
ZSBiZWVuIGltcGxlbWVudGVkIGluIHByb2R1Y3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5LZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDkvMTIvMTgsIDE6MjQgUE0sICZxdW90
O05ldGNvbmYgb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls
dG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIj5uZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+
IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQiPmt3YXRz
ZW5AanVuaXBlci5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp
YnJpIj5ZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQuPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OkNhbGlicmkiPlllcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29t
cGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5odHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yNTgxLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+S2VudCAvLyBjby1hdXRob3I8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs
aWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp
YnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk9uIDkvMTEvMTgsIDk6NDQgUE0sICZxdW90O05ldGNvbmYgb24gYmVoYWxm
IG9mIE1haGVzaCBKZXRoYW5hbmRhbmkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25m
LWJvdW5jZXNAaWV0Zi5vcmciPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxm
IG9mDQo8YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRh
bmlAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNlcCAyNSwgMjAxNywgYXQgNjo0NSBQTSwg
TWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21h
aWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGxhc3Qgcm91bmQgb2YgV0cg
TEMgb24mbmJzcDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEbmV0Y29u
Zi0yRHplcm90b3VjaC0yRDE3JmFtcDtkPUR3TUZhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZo
MFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJn
c0JZYUdUdmpJU2xhSmRjWm8mYW1wO209WUpkUEJuekFtMGFTeDVCUk9QN3BkQm5ya0hUT0ZyN2N3
NXpOOWx2aVF2ZyZhbXA7cz0tRy1JdEJKWmZsYWJ2RFBuTnplR0dCWlRHMW5YV2lEOG50bTBKWThp
bTl3JmFtcDtlPSI+WmVyb3RvdWNoDQogZHJhZnQ8L2E+Jm5ic3A7cmVzdWx0ZWQgaW4gbG90IGNv
bW1lbnRzIGJlaW5nIHBvc3RlZCBhYm91dCB0aGUgZHJhZnQuIEtlbnQgaGFzIHNpbmNlIHRoZW4g
dXBkYXRlZCB0aGUgZG9jdW1lbnQgdG8gYWRkcmVzcyBhbGwgdGhvc2UgY29tbWVudHMgYW5kIHBv
c3RlZCAtMTcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIG5vdyByZWFk
eSBmb3IgYSByZS1ydW4gb2YgdGhhdCBjYWxsLiBUaGlzIHN0YXJ0cyBhIHR3by13ZWVrIFdHIExD
IG9uIHRoZSBkcmFmdC4gUGxlYXNlIGluZGljYXRlIHlvdXIgc3VwcG9ydCBpZiB5b3UgYmVsaWV2
ZSB0aGUgZG9jdW1lbnQgaXMgbm93IHJlYWR5IGZvciBMQy4gV2UgbmVlZCBhZmZpcm1hdGlvbiBv
ZiBzdXBwb3J0IGZvciB0aGUgTEMgdG8gc3VjY2VlZC4NCiBVbmZvcnR1bmF0ZWx5LCBzaWxlbmNl
IGlzIG5vdCBhZmZpcm1hdGlvbi4gSWYgeW91IGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIHN0aWxs
IG5vdCByZWFkeSwgcGxlYXNlIGluZGljYXRlIHdoeS4gVGhlIExDIHdpbGwgY29uY2x1ZGUgb24g
T2N0LiA5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5BdXRob3JzLCBwbGVhc2UgaW5kaWNhdGUgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBS
cyByZWxhdGVkIHRvIHRoZSBkb2N1bWVudC4gQWxzbywgcGxlYXNlIGluZGljYXRlIGlmIHRoZXJl
IGFyZSBhbnkga25vd24gaW1wbGVtZW50YXRpb25zIG9mIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+VGhpcyB0aHJlYWQgZGV2b2x2ZWQgaW50byBhIHJldmlldyBvZiB0aGUgZHJhZnQs
IHdoZXJlIHRoZSB0d28gcXVlc3Rpb25zIG9uIElQUiBhbmQga25vd24gaW1wbGVtZW50YXRpb25z
IGdvdCBsb3N0LiBBbmQgd2hpbGUgdGhlcmUgZXhpc3RzIG9uZSBJUFIgZGlzY2xvc3VyZSwgdGhp
cyBxdWVzdGlvbiBpcyBzdGlsbCBwZXJ0aW5lbnQuIFBsZWFzZSBub3RlIHRoYXQgYSByZXNwb25z
ZSBpcyByZXF1aXJlZCBmcm9tDQogQUxMIHRoZSBhdXRob3JzIG9yIGNvbnRyaWJ1dG9ycyB0byB0
aGlzIGUtbWFpbC4gV2l0aG91dCBpdCwgdGhlIGRvY3VtZW50IGNhbm5vdCBiZSBhZHZhbmNlZC4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+QXJlIHRoZSBhdXRob3JzIG9yIGNvbnRyaWJ1dG9ycyB0byB0aGUgZHJhZnQgYXdhcmUgb2Yg
YW55IElQUnMgcmVsYXRlZCB0byB0aGUgZHJhZnQ/IFBsZWFzZSBzdGF0ZSBlaXRoZXI6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O05v
LCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQmcXVv
dDs8YnI+DQpvcjxicj4NCiZxdW90O1llcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMg
dG8gdGhpcyBkcmFmdOKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5JZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBs
aWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyZuYnNwOyhzZWUgUkZDcyAzNjY5LCA1Mzc4IGFuZCA4
MTc5IGZvciBtb3JlIGRldGFpbHMpPzxicj4NCjxicj4NCklmIHllcyB0byB0aGUgYWJvdmUsIHBs
ZWFzZSBzdGF0ZSBlaXRoZXI6PGJyPg0KPGJyPg0KJnF1b3Q7WWVzLCB0aGUgSVBSIGhhcyBiZWVu
IGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMmcXVvdDs8YnI+DQpv
cjxicj4NCiZxdW90O05vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQmcXVvdDs8YnI+
DQo8YnI+DQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBk
ZXRhaWxzIHlvdSB0aGluayZuYnNwO2FwcHJvcHJpYXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UgYXJlIG9uIHRoZSBXRyBtYWls
aW5nIGxpc3QgYW5kL29yIGF0dGVuZCBXRyBtZWV0aW5ncywgaXQgaXMgeW91ciBvYmxpZ2F0aW9u
IHVuZGVyIHRoZSBJUFIgcnVsZXMgdG8gbm90aWZ5IElFVEYuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBtb3JlIGluZm9ybWF0aW9uLCBw
bGVhc2Ugc2VlJm5ic3A7UkZDcyAzNjY5LCA1Mzc4LCA4MTc5Jm5ic3A7YW5kPGJyPg0KPGEgaHJl
Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3Ry
YWMudG9vbHMuaWV0Zi5vcmdfZ3JvdXBfaWVzZ190cmFjX3dpa2lfSW50ZWxsZWN0dWFsUHJvcGVy
dHkmYW1wO2Q9RHdNRmFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9E
VFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNa
byZhbXA7bT1ZSmRQQm56QW0wYVN4NUJST1A3cGRCbnJrSFRPRnI3Y3c1ek45bHZpUXZnJmFtcDtz
PXRtUUFZdDAyNFM0OXEwZmVleExXUE10QlB1VFNLdkViTEtDb08xaUlHZjQmYW1wO2U9Ij5odHRw
Oi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQ
cm9wZXJ0eTwvYT4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkZpbmFsbHksIGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55IGltcGxlbWVudGF0aW9u
cyBvZiB0aGlzIGRyYWZ0LCBwbGVhc2UgbGV0IHVzIGtub3cuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UaGFua3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1haGVzaCBKZXRoYW5hbmRh
bmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh
IGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFp
bC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_CE063410BB964F61BDDB1C7152BB0AF7junipernet_--


From nobody Wed Sep 12 11:35:43 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8A7130DC3 for ; Wed, 12 Sep 2018 11:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_DKIMWL_WL_MED=-0.01, 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 wOQTPpbLxbXn for ; Wed, 12 Sep 2018 11:35:37 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98CE3130EA8 for ; Wed, 12 Sep 2018 11:35:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19548; q=dns/txt; s=iport; t=1536777337; x=1537986937; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kM6o0qEYlvYM/W/ySOzYqswPBDK+BauuxosI2Apht9g=; b=bAb2XBO0AAQngthtk6xbiuoBb+LGwa7MswCiLdJzr/qYvyD+7sbljIG5 4S+LMCjoCX7FhqZMQH1BKBqrHAP4tTLXkVXbkMPZuIJcTzouGJewYAxK1 QuHjiFIpontsLJR4rPQg0a51V7hGs+/AQ8g7N5KsoRJOqzvaiR6GrWC6l o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAADtW5lb/5FdJa1RAQkaAQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBgU+BXSplfygKmiaWPRSBZgslhAFGAoNNITUXAQIBAQIBAQJ?= =?us-ascii?q?tHAyFOAEBAQECATo9AgULAgEIDgcDDREQMiUCBA4FCBOCO0yBeQgPpnWKCAW?= =?us-ascii?q?KZxeBQT+BEoMSgxsCAQIBgSoBBwEJAgEGAkiFJgKIIRQWhjSEEYhBTwkChjm?= =?us-ascii?q?JRx+BQYRDgwCBCoRtiE+Cdog0AhEUgSUfAzNkcXAVGoMNgiUXegECgkiFFIU?= =?us-ascii?q?9AW8BjC8HgSeBHgEB?=
X-IronPort-AV: E=Sophos;i="5.53,365,1531785600"; d="scan'208";a="170841234"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2018 18:35:36 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w8CIZZ2Q004058 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Sep 2018 18:35:36 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Sep 2018 14:35:35 -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.1395.000; Wed, 12 Sep 2018 14:35:35 -0400
From: "Eric Voit (evoit)" 
To: Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of subscribed-notifications-16
Thread-Index: AQHUSS2c6fWPWMQnpECqHWzj9l2RFqTpyY1wgALe1QCAACWmwA==
Date: Wed, 12 Sep 2018 18:35:35 +0000
Message-ID: <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com>
References: <20180910.194152.138356385922962289.mbj@tail-f.com>  <20180912.113446.2017030234338816835.mbj@tail-f.com>
In-Reply-To: <20180912.113446.2017030234338816835.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.234]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 18:35:42 -0000

Hi Martin,

Much incorporated.  Latest is at:
https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-sub=
scribed-notifications-17.txt

Specific responses in-line...

> From: Martin Bjorklund, September 12, 2018 5:35 AM
>=20
> "Eric Voit (evoit)"  wrote:
> > Thanks for the comments Martin,  thoughts in-line...
> >
> > > From: Martin Bjorklund, September 10, 2018 1:42 PM
>=20
> [...]
>=20
> > > o  Section 2.1
> > >
> > >   The text says:
> > >
> > >     It is out of the scope of this document
> > >     to identify [...] b) how event records are defined
> > >
> > >   Is this really what we want?  Shouldn't this document specify that
> > >   an event record is an instance of a YANG "notification" statement?
> > >   Do we want to support event records that are not defined in YANG?
> > >
> > >   This was discussed in the thread "comments on
> > >   draft-ietf-netconf-subscribed-notifications-12", and it seems that
> > >   noone really have any use case for non-YANG-defined event records,
> > >   accessed with YANG-defined operations.
> >
> > Yes this was discussed previously.  My reading was that others wanted
> > to support subscription to non-YANG events.
> > E.g., see Andy & Tianran's thoughts in
> > https://www.ietf.org/mail-archive/web/netconf/current/msg14764.html
>=20
> Yes, but read on in that thread, see
> https://www.ietf.org/mail-archive/web/netconf/current/msg14766.html
> for a clarification.
>=20
> AFAIK, noone has presented a use case for sending non-YANG-defined data
> here.

As anything can be YANG wrapped, per the thread above.  I am fine with this=
.

> > >   I think that this document should state that an event record is an
> > >   instance of a YANG "notification" statement.  If not, it is unclear
> > >   both how subtree/xpath filters and xml/json/... encodings would wor=
k.
> >
> > Applying xpath filters against XML based event records seems viable to
> > me.
>=20
> Where does it say that it has to be XML?  Whatabout mixed-content?
> What if such a notification is sent when the encoding is JSON?
>=20
> If you want to make this specification open for other data modeling langu=
ages,
> I think you need to carefully define how that is supposed to work; essent=
ially
> similar to how we handle transports; we have a set of requirement on what=
 a
> transport document must define.  IMO this is super complicated and overki=
ll.
> This draft is complex enough.
> Don't add even more complexity.

If you are just saying that we can put everything into a YANG wrapper, that=
 is fine with me.  To clarify this, I have tweaked the first sentence of Se=
ction 2.1 to:
"An event stream is a named entity on a publisher which exposes a continuou=
sly updating set of YANG encoded event records."

And I have tweaked the first sentence of the third paragraph to:
"As YANG encoded event records are created by a system,..."

> > Of course it will be up to the definition of any particular stream to
> > articulate the event record contents sufficiently for filters to be
> > created.
> >
> > > o  Section 2.1
> > >
> > >   The text says:
> > >
> > >     Among
> > >     these included NETCONF XML event records are individual YANG 1.1
> > >     notifications described in section 7.16 of [RFC7950].
> > >
> > >   First of all, does this mean that there can be event records on the
> > >   "NETCONF" stream that are *not* defined with a "notification"
> > >   statement?
> >
> > For the NETCONF stream, personally I only care about things YANG
> > notification statement.  But looking again at Andy's comment from:
> > https://www.ietf.org/mail-archive/web/netconf/current/msg14764.html
> > he says "I would say SHOULD be defined in YANG, for the "NETCONF"
> > stream."
>=20
> I strongly disagree.
>=20
> > So for -v16 I updated the text in a way that doesn't preclude this.
>=20
> See above.  If all events records are defined in YANG we can remove this.

Per above, I have included text above so that YANG encapsulation is require=
d.  I think YANG Data should be an allowable structure (so I didn't specify=
 just a "Notification").  If you think that YANG Data should be excluded fr=
om the allowed event records. I can refine the words.

> > >   Second, this seems to imply that *all* notifications defined in all
> > >   YANG modules end up in the "NETCONF" stream, but I don't think this
> > >   is the intention.  At least I hope so.  ("yp:push-update" is an
> > >   example of a notification that will not be sent on the "NETCONF"
> > >   stream.)
> >
> > The NETCONF stream has a very broad/inclusive definition in RFC-5277.
> > This definition is: "This stream contains all NETCONF XML event
> > notifications supported by the NETCONF server".
>=20
> This is very underspecified.  IIRC the original intention was notificatio=
ns related
> to NETCONF, hence "*NETCONF* XML event notifications".
>=20
> > To me, thinking about how that statement and applying it to YANG, this
> > translates as YANG 1.1 notifications should go into the NETCONF
> > stream, unless explicitly excluded.
>=20
> I disagree.  This is not how 5277 works.  Until we have worked out a usef=
ul way
> to assign notifications to streams, we shouldn't restrict anything in thi=
s regard.

Ok.  Effectively we are naming the stream NETCONF without improving the def=
inition of what membership in that stream should be.  And that is fine.  As=
 people seem to understand what this is supposed to be, I will return to th=
e original definition.  See text, and let me know if you have issues.
=20
> > This provides a very simple way
> > determining which types of notifications should be placed on the
> > stream.  (Otherwise, how is a developer of a YANG notification
> > supposed to know whether it should go into the NETCONF stream or not?
>=20
> They don't.  But note that it might be an operator decision for how to as=
sign
> notifications to streams.

Ok.  A stream membership definition is out-of-scope for all other streams, =
we can leave it this way for the "NETCONF" stream.  Someone else can pick u=
p and define this in another draft the WG feels it necessary.
=20
> > The alternative would seem to be having each notification opt-in to
> > the NETCONF stream.)
> >
> > So if you agree with this reasoning, how about:
> >
> > The "NETCONF" event stream contains all instances of YANG 1.1
> > notifications generated by a publisher, except where a type of
> > notification has explicitly been excluded from the stream.
>=20
> I think that this document should keep the definition of the NETCONF stre=
am as
> defined in RFC 5277.

Ok

> Also, I think it should state that an event record is an instantiation of=
 a YANG
> "notification" statement (any version of YANG).

What about a YANG Data?  (Per above)

> [...]
>=20
> > > o  Section 2.4.2
> > >
> > >   The text says:
> > >
> > >     The transport selected by the subscriber
> > >     to reach the publisher MUST be able to support multiple "establis=
h-
> > >     subscription" requests made within the same transport session.
> > >
> > >   This seems to indicate that RESTCONF cannot be used with this
> > >   specification, since RESTCONF doesn't have sessions.
> >
> > The desired behavior is that a subscriber can request multiple
> > subscriptions without each requiring a separate transport session
> > establishment.  I think we are ok here with RESTCONF because
> > underneath RESTCONF is HTTP, TLS, TCP.  And each of those lower layers
> > can have sessions.
> >
> > To clarify further, I have tweaked the text to:
> >
> > "The transport selected by the subscriber to reach the publisher MUST
> > be able to support multiple "establish-subscription" requests without
> > each requiring a separate persistent transport connection."
> >
> > >   This makes me wonder, why does this document specify this
> > >   requirement?  I agree that this is the behaviour we want from
> > >   NETCONF, but then I think that should be defined in the
> > >   netconf-notif draft.
> >
> > By saying something in SN about this requirement, I believe we can
> > preclude an implementation which can only support one subscription per
> > subscriber.  In any case, the specific "how" details will still need
> > to be articulated in each transport draft.
>=20
> I think you are mixing the specification and implementation.  If a transp=
ort
> document says that an implemention MUST support multiple subscriptions pe=
r
> session (in a transport-specific way), then an implementation cannot just
> support a sinlge subscription.
>=20
> My point is that this a transport-specific requirement, and it doesn't be=
long in
> this document.

I can see why you don't see it applicable to Section 2.4.2.    However Sect=
ion 5.3 provides guidelines for transport document developers (this is a se=
ction Kent requested.)  And so I have moved the requirement there.  Is that=
 sufficient.=20

> > > o  Section 2.4.2
> > >
> > >   s/"start-time"/"replay-start-time"/  (3 occurrences)
> >
> > Fixed
> >
> > >   Also, the text says that the replay-start-time MUST be in the past.
> > >
> > >   Suppose the server receives a "replay-start-time" of 12:00:00.001,
> > >   and the replay buffer is empty.
> > >
> > >   A) If the current time is 12:00:00.002, the request is accepted, an=
d
> > >      a "replay-completed" notif is sent.
> > >
> > >   B) If the current time is 12:00:00.000, the request is rejected wit=
h
> > >      an error.
> > >
> > >   Why is this important?  Why not simply just send the
> > >   replay-completed notif in both cases?
> >
> > For (B), if an event occurs at 12:00:00.0005, should it be sent?
> > Should it be sent before or after the "replay-start-time"?  How long
> > should we allow the clocks to drift before we reject the subscription?
> > As we don't support future/pending subscriptions, we don't have to
> > worry about these questions with the current definition.
>=20
> I would simply say that if the replay-start-time is later than any buffer=
ed notif,
> then "replay-complete" is immediately sent.  It dont'
> matter if it is one microsecond or one year later.

Tweaked the sentence:

"If the given "replay-start-time" is later than the time marked within any =
event records retained within the replay buffer, then the publisher MUST se=
nd a "replay-completed" notification immediately after a successful establi=
sh-subscription RPC response."
=20
> The problem otherwise is how to decide if something is "in the past".
> In the past when the client sent the request?  When the server parsed the=
 XML?
> When the instrumentation code runs?
>=20
> But this is not a big issue.

Hopefully with the tweak, we can leave it as modified.

[..]
> > > o  Section 2.4.6
> > >
> > >   The text says:
> > >
> > >     1.  "establish-subscription-stream-error-info": This MUST be retu=
rned
> > >         if an RPC error reason has not been placed elsewhere within t=
he
> > >         transport portion of a failed "establish-subscription" RPC
> > >         response.
> > >
> > >   (and similar for the other errors)
> > >
> > >   What exactly does "if an RPC error reason has not been placed
> > >   elsewhere" mean?
> >
> > The intent is to match how NETCONF & RESTCONF historically handles
> > errors.  As you know with NETCONF, each error identity will be
> > inserted as the "error-app-tag".
>=20
> It could also be in "error-tag" and/or "error-message".  My point is that=
 I don't
> think that you mean that if an implementation populate say "error-message=
",
> then it should not popluate error-info with establish-subscription-stream=
-
> error-info.

I do mean that.  I don't think we should send: "establish-subscription-stre=
am-error-info" for NETCONF when there is no hint included.  All the necessa=
ry error info is already in the existing message.

> > And therefore placing the YANG data
> > "establish-subscription-stream-error-info" would be redundant.  For
> > NETCONF, "establish-subscription-stream-error-info" are only needed
> > when hints to be provided.
> >
> > Therefore assuming you are looking for an alternative way to make this
> > point, I have tweaked the text to:
> > "This MUST be returned if an RPC error reason has not been mapped down
> > into transport specific error objects contained within a failed
> > "establish-subscription" RPC response."
>=20
> Howabout simply removing this sentence?

Done

> > > o  Section 2.5.1
> > >
> > >   In the second diagram (for the valid state), the states are called
> > >   "receiver connecting", "reciever timeout" etc.  I find this a bit
> > >   confusing; it is not the *receiver* that is connecting, it is the
> > >   publisher.  Ok, the legend then says:
> > >
> > >      dashed boxes which include the word 'receiver' show the possible
> > >      states for an individual receiver
> > >
> > >  But since all dashed boxes include the word "receiver", and the
> > > diagram specifically is the state machine *per receiver*, maybe we
> > > can simply remove the word "receiver" from the boxes?
> >
> > There have been some discussions on this.  I agree it is certainly
> > valid to remove "receiver" from these four boxes.  However I have
> > found that getting readers to really internalize that the state
> > machine is actually per-receiver rather than per-subscription, it
> > seems to go faster/cleaner when receiver is shown in the four boxes.
> >
> > Nevertheless, if you absolutely want "receiver" removed from the
> > boxes, I can do that.
>=20
> Maybe you can remove receiver from the individual boxes and then change t=
he
> word "valid" from the outer box to "per-receiver state machine"?
>=20
> Or maybe remove the outer box and add a Figure title: 'per-receiver state
> machine for the subscription's "valid" state'
>=20
> Also not a big deal, but I found it confusing.

All are viable.  But I have found the current diagram useable. Do you have =
a major issue if we leave it as it is?
=20
> [...]
>=20
> > > o  Section 2.5.6
> > >
> > >   I know that this feature was presented in Montreal.  I think it is
> > >   problematic, and suggest it is removed.
> >
> > This issue was discussed in Montreal.  The feature is of course is
> > optional.  There are a large number of downsides for someone who
> > chooses not to implement for certain use cases.  Please see the
> > Montreal slides and the long threads with Kent for more details.
>=20
> I did watch the Montreal session, but I didn't see any discussion on
> this issue (just your presentation).   Can you send a pointer to the
> email thread with Kent?

Some minutes on the topic can be seen at:
https://datatracker.ietf.org/doc/minutes-102-netconf/=20
With the WG vote in Montreal, I would love not to re-open. =20

The previous exchange was long.  Some items include:
https://www.ietf.org/mail-archive/web/netconf/current/msg14575.html
https://www.ietf.org/mail-archive/web/netconf/current/msg14902.html=20

> > If
> > you want to pursue this further it is probably best to start a new
> > thread dedicated to this topic alone.
> >
> > >   For example, what happens if the transport session is lost and
> > >   re-established; are all event records in the buffer replayed again?
> >
> > No.  The publisher will not lose context of what was sent.
>=20
> This is not clear from the text.  In fact, the text explicitly says:
>=20
>    The leading event record sent will be the first event record
>    subsequent to the latest of three different times: the
>    "replay-log-creation-time", "replay-log-aged- time", or the most
>    recent publisher boot time.

I see your point.   I have tweaked the text to:

" If the publisher does not know the next record intended for the receiver,=
 the leading event record..."
=20
I have also made a corresponding tweak to the YANG model.

> > >   What happens if a new receiver is added to a subscription that
> > >   already has a receiver, will all events in the buffer be replayed t=
o
> > >   the new receiver?
> >
> > Yes.  (To clarify, I added "to each configured receiver" at the end of
> > the last sentence of the first paragraph.)
> >
> > >   When a new subscription is configured with configured-replay set,
> > >   the publisher will immediately try to connect to the publisher and
> > >   send all buffered event from the last reboot.  Is this really
> > >   useful?
> >
> > Yes.  See the security cases reviewed on the earlier threads with
> > Kent.  If someone doesn't care about log entries since boot, they
> > simply don't have to implement this optional feature.
> >
> > >   If the mechansim relies on the subscriber being able to also use
> > >   dynamic subscriptions for replay of all event records, maybe we
> > >   could simplify things by always relying on dynamic subscriptions fo=
r
> > >   replay for configured subscriptions.  Specifically, remove
> > >   "configured-replay" etc, but keep the "replay-previous-event-time"
> > >   in the "subscription-started" notification.  Then a subscriber can
> > >   simply check this value to see if anything is missing, and if it is=
,
> > >   use a dynamic subscription to request replay from the latest time h=
e
> > >   knows about.
> >
> > This is a valid approach, and can be used as an alternative to this
> > optional feature.  However there are still many downsides to the
> > alternative.  See the slides from Montreal, as well as the previous
> > thread discussions for details.
> >
> > > o  Section 2.6
> > >
> > >   It just occurred to me that this text about using the 
> > >   message shouldn't be in this document, but in the netconf-notif (an=
d
> > >   restconf-notif) document.  It is highly transport and encoding
> > >   specific.
> >
> > I think you are referring to both the sentence: "This notification
> > message MUST be encoded in a  message as defined within
> > [RFC5277], Section 4.  And per [RFC5277]'s "eventTime" object
> > definition, the "eventTime" is populated with the event occurrence
> > time."  As well as to the example compliant message in Figure 10.
> >
> > While the text could be extracted and placed in the netconf-notif
> > document, extracting it fully from SN would leave no baseline message
> > format.
>=20
> Things like this are inevitable when you have a transport-independent
> specification.  Of course, you can require that all transports MUST use t=
he 5277
> spec of a notification.  But then I think you rule out transports like Co=
MI and
> possibly other future binary protocols.

Ok, I am fine with the move.  I have moved the identified text to NETCONF-N=
otif.  (Actually the text was already there too.  So I just tweaked it.)
=20
Thanks,
Eric

> > Perhaps others will have a problem if the SN solution does not have
> > some pre-defined structure to hold event records?
> >
> > I can move this if I hear no objection.  As you know, I am hoping that
> > draft-ietf-netconf-notification-messages at some point displaces the
> >  message of [RFC5277], Section 4.  And this is easier to
> > do with fewer references to RFC5277 within SN.
>=20
> [...]
> /martin


From nobody Wed Sep 12 11:42:41 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C0D130EB7 for ; Wed, 12 Sep 2018 11:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-0.01] 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 3aIDf36OdnbB for ; Wed, 12 Sep 2018 11:42:33 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 841E0130EA8 for ; Wed, 12 Sep 2018 11:42:32 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id i7-v6so2610981lfh.5 for ; Wed, 12 Sep 2018 11:42:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zvzo1Sxul4P0c8DixjRfkdkzKDmv7Fa+VMCBH1n1agA=; b=vR1BD9CHjM84VkvazqtxW+ZjV4Wvf2YqcuQdfW4wn1LCmUgCzPQJnZjPhQQPbej9KM tJSrQnzq5hH3GwbENOKoL8KQZLBIzMSgJAfzulQFzD7vSZpZzx4ZIwcJUV+PNDG8R8gL pOXGkUtpuhlUcrxv+dDYiuU3yv5hPPLUH3bIcolRiJ7fNx69A9skOxCF5lCgSgjGtXCi BY0dKIKr94iowhssYnZustLLa/CtMpl3ijnAYwCgHcqKdQxwyCZM9rBZdrWSY0I6iXmG qjoRkExduxuBUZ8SFYGCX+gXGE1ZCjpa1IIjCl9WGbIIgipH7LmR0fThhGUX0YS7iGG1 iwWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zvzo1Sxul4P0c8DixjRfkdkzKDmv7Fa+VMCBH1n1agA=; b=CsxhPy5bztwsHsM0fCj/BOW53xjBNcTK60S8h7Q2D6cyQjEZoLzErn0FEnc8UwQn/Q /CkyDk8iP9/58dnx5rRXRvWfjh3VZGKDP4ysROBaeCBPJuohxML2sr5PCyPD8Z6S0W3G Pu+y0rG7TzdyrVmxZzEbSeGM2SpaZ5jBrZ7Y9ivbo7PcGdzpooFFzPeTT7+aRikGmFz7 JsBeIB028iS5drMwHXlJYybg6gkEPK+aIFEisuSKSTHMmZwdAYeoM7sxP+CrDqKXWVHy NxJEGuXxQL7rRkeqV7INfsdH+fo9/PjVdxzJxtVnDpoplTHfLra5rPnAske2bNX2Bk69 MinA==
X-Gm-Message-State: APzg51BVpagI5+hrd/1Nvam6kOGPsmzdjExvW40BVN/ykaEUAzgCZfdh T8A046c9vGo/x7tzwyqPE7aD+krEkT6Bm/zQC8e+ca+W
X-Google-Smtp-Source: ANB0VdaajmApOos2nrhTyFfcRlz3l+k775r2jzT61IyeoMLcGaYc0DbHXr7EgWGzoUtxRHcqrGRGTKJEpz0MzAxvWqo=
X-Received: by 2002:a19:8c55:: with SMTP id i21-v6mr2385710lfj.90.1536777748883;  Wed, 12 Sep 2018 11:42:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:48c9:0:0:0:0:0 with HTTP; Wed, 12 Sep 2018 11:42:28 -0700 (PDT)
In-Reply-To: <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com>
References: <20180910.194152.138356385922962289.mbj@tail-f.com>  <20180912.113446.2017030234338816835.mbj@tail-f.com> <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com>
From: Andy Bierman 
Date: Wed, 12 Sep 2018 11:42:28 -0700
Message-ID: 
To: "Eric Voit (evoit)" 
Cc: Martin Bjorklund , "netconf@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000d23fda0575b0f31a"
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 18:42:40 -0000

--000000000000d23fda0575b0f31a
Content-Type: text/plain; charset="UTF-8"

On Wed, Sep 12, 2018 at 11:35 AM, Eric Voit (evoit) <
evoit=40cisco.com@dmarc.ietf.org> wrote:

> Hi Martin,
>
> Much incorporated.  Latest is at:
> https://github.com/netconf-wg/rfc5277bis/blob/master/draft-
> ietf-netconf-subscribed-notifications-17.txt
>
> Specific responses in-line...
>
> > From: Martin Bjorklund, September 12, 2018 5:35 AM
> >
> > "Eric Voit (evoit)"  wrote:
> > > Thanks for the comments Martin,  thoughts in-line...
> > >
> > > > From: Martin Bjorklund, September 10, 2018 1:42 PM
> >
> > [...]
> >
> > > > o  Section 2.1
> > > >
> > > >   The text says:
> > > >
> > > >     It is out of the scope of this document
> > > >     to identify [...] b) how event records are defined
> > > >
> > > >   Is this really what we want?  Shouldn't this document specify that
> > > >   an event record is an instance of a YANG "notification" statement?
> > > >   Do we want to support event records that are not defined in YANG?
> > > >
> > > >   This was discussed in the thread "comments on
> > > >   draft-ietf-netconf-subscribed-notifications-12", and it seems that
> > > >   noone really have any use case for non-YANG-defined event records,
> > > >   accessed with YANG-defined operations.
> > >
> > > Yes this was discussed previously.  My reading was that others wanted
> > > to support subscription to non-YANG events.
> > > E.g., see Andy & Tianran's thoughts in
> > > https://www.ietf.org/mail-archive/web/netconf/current/msg14764.html
> >
> > Yes, but read on in that thread, see
> > https://www.ietf.org/mail-archive/web/netconf/current/msg14766.html
> > for a clarification.
> >
> > AFAIK, noone has presented a use case for sending non-YANG-defined data
> > here.
>
> As anything can be YANG wrapped, per the thread above.  I am fine with
> this.
>


I think my concern was simply that I take notice any time anyone
uses the term MUST in an I-D.  I ask myself "What harm to interoperability
will result if this MUST is not followed?  If I cannot think of anything
(as in this case) then MUST is probably a SHOULD instead.

The use-case I have in mind -- protobuffs -- I don't see why it is
important to
require a YANG module for every .proto file. Even worse, why is the
subscription draft making this requirement?

Andy



> > > >   I think that this document should state that an event record is an
> > > >   instance of a YANG "notification" statement.  If not, it is unclear
> > > >   both how subtree/xpath filters and xml/json/... encodings would
> work.
> > >
> > > Applying xpath filters against XML based event records seems viable to
> > > me.
> >
> > Where does it say that it has to be XML?  Whatabout mixed-content?
> > What if such a notification is sent when the encoding is JSON?
> >
> > If you want to make this specification open for other data modeling
> languages,
> > I think you need to carefully define how that is supposed to work;
> essentially
> > similar to how we handle transports; we have a set of requirement on
> what a
> > transport document must define.  IMO this is super complicated and
> overkill.
> > This draft is complex enough.
> > Don't add even more complexity.
>
> If you are just saying that we can put everything into a YANG wrapper,
> that is fine with me.  To clarify this, I have tweaked the first sentence
> of Section 2.1 to:
> "An event stream is a named entity on a publisher which exposes a
> continuously updating set of YANG encoded event records."
>
> And I have tweaked the first sentence of the third paragraph to:
> "As YANG encoded event records are created by a system,..."
>
> > > Of course it will be up to the definition of any particular stream to
> > > articulate the event record contents sufficiently for filters to be
> > > created.
> > >
> > > > o  Section 2.1
> > > >
> > > >   The text says:
> > > >
> > > >     Among
> > > >     these included NETCONF XML event records are individual YANG 1.1
> > > >     notifications described in section 7.16 of [RFC7950].
> > > >
> > > >   First of all, does this mean that there can be event records on the
> > > >   "NETCONF" stream that are *not* defined with a "notification"
> > > >   statement?
> > >
> > > For the NETCONF stream, personally I only care about things YANG
> > > notification statement.  But looking again at Andy's comment from:
> > > https://www.ietf.org/mail-archive/web/netconf/current/msg14764.html
> > > he says "I would say SHOULD be defined in YANG, for the "NETCONF"
> > > stream."
> >
> > I strongly disagree.
> >
> > > So for -v16 I updated the text in a way that doesn't preclude this.
> >
> > See above.  If all events records are defined in YANG we can remove this.
>
> Per above, I have included text above so that YANG encapsulation is
> required.  I think YANG Data should be an allowable structure (so I didn't
> specify just a "Notification").  If you think that YANG Data should be
> excluded from the allowed event records. I can refine the words.
>
> > > >   Second, this seems to imply that *all* notifications defined in all
> > > >   YANG modules end up in the "NETCONF" stream, but I don't think this
> > > >   is the intention.  At least I hope so.  ("yp:push-update" is an
> > > >   example of a notification that will not be sent on the "NETCONF"
> > > >   stream.)
> > >
> > > The NETCONF stream has a very broad/inclusive definition in RFC-5277.
> > > This definition is: "This stream contains all NETCONF XML event
> > > notifications supported by the NETCONF server".
> >
> > This is very underspecified.  IIRC the original intention was
> notifications related
> > to NETCONF, hence "*NETCONF* XML event notifications".
> >
> > > To me, thinking about how that statement and applying it to YANG, this
> > > translates as YANG 1.1 notifications should go into the NETCONF
> > > stream, unless explicitly excluded.
> >
> > I disagree.  This is not how 5277 works.  Until we have worked out a
> useful way
> > to assign notifications to streams, we shouldn't restrict anything in
> this regard.
>
> Ok.  Effectively we are naming the stream NETCONF without improving the
> definition of what membership in that stream should be.  And that is fine.
> As people seem to understand what this is supposed to be, I will return to
> the original definition.  See text, and let me know if you have issues.
>
> > > This provides a very simple way
> > > determining which types of notifications should be placed on the
> > > stream.  (Otherwise, how is a developer of a YANG notification
> > > supposed to know whether it should go into the NETCONF stream or not?
> >
> > They don't.  But note that it might be an operator decision for how to
> assign
> > notifications to streams.
>
> Ok.  A stream membership definition is out-of-scope for all other streams,
> we can leave it this way for the "NETCONF" stream.  Someone else can pick
> up and define this in another draft the WG feels it necessary.
>
> > > The alternative would seem to be having each notification opt-in to
> > > the NETCONF stream.)
> > >
> > > So if you agree with this reasoning, how about:
> > >
> > > The "NETCONF" event stream contains all instances of YANG 1.1
> > > notifications generated by a publisher, except where a type of
> > > notification has explicitly been excluded from the stream.
> >
> > I think that this document should keep the definition of the NETCONF
> stream as
> > defined in RFC 5277.
>
> Ok
>
> > Also, I think it should state that an event record is an instantiation
> of a YANG
> > "notification" statement (any version of YANG).
>
> What about a YANG Data?  (Per above)
>
> > [...]
> >
> > > > o  Section 2.4.2
> > > >
> > > >   The text says:
> > > >
> > > >     The transport selected by the subscriber
> > > >     to reach the publisher MUST be able to support multiple
> "establish-
> > > >     subscription" requests made within the same transport session.
> > > >
> > > >   This seems to indicate that RESTCONF cannot be used with this
> > > >   specification, since RESTCONF doesn't have sessions.
> > >
> > > The desired behavior is that a subscriber can request multiple
> > > subscriptions without each requiring a separate transport session
> > > establishment.  I think we are ok here with RESTCONF because
> > > underneath RESTCONF is HTTP, TLS, TCP.  And each of those lower layers
> > > can have sessions.
> > >
> > > To clarify further, I have tweaked the text to:
> > >
> > > "The transport selected by the subscriber to reach the publisher MUST
> > > be able to support multiple "establish-subscription" requests without
> > > each requiring a separate persistent transport connection."
> > >
> > > >   This makes me wonder, why does this document specify this
> > > >   requirement?  I agree that this is the behaviour we want from
> > > >   NETCONF, but then I think that should be defined in the
> > > >   netconf-notif draft.
> > >
> > > By saying something in SN about this requirement, I believe we can
> > > preclude an implementation which can only support one subscription per
> > > subscriber.  In any case, the specific "how" details will still need
> > > to be articulated in each transport draft.
> >
> > I think you are mixing the specification and implementation.  If a
> transport
> > document says that an implemention MUST support multiple subscriptions
> per
> > session (in a transport-specific way), then an implementation cannot just
> > support a sinlge subscription.
> >
> > My point is that this a transport-specific requirement, and it doesn't
> belong in
> > this document.
>
> I can see why you don't see it applicable to Section 2.4.2.    However
> Section 5.3 provides guidelines for transport document developers (this is
> a section Kent requested.)  And so I have moved the requirement there.  Is
> that sufficient.
>
> > > > o  Section 2.4.2
> > > >
> > > >   s/"start-time"/"replay-start-time"/  (3 occurrences)
> > >
> > > Fixed
> > >
> > > >   Also, the text says that the replay-start-time MUST be in the past.
> > > >
> > > >   Suppose the server receives a "replay-start-time" of 12:00:00.001,
> > > >   and the replay buffer is empty.
> > > >
> > > >   A) If the current time is 12:00:00.002, the request is accepted,
> and
> > > >      a "replay-completed" notif is sent.
> > > >
> > > >   B) If the current time is 12:00:00.000, the request is rejected
> with
> > > >      an error.
> > > >
> > > >   Why is this important?  Why not simply just send the
> > > >   replay-completed notif in both cases?
> > >
> > > For (B), if an event occurs at 12:00:00.0005, should it be sent?
> > > Should it be sent before or after the "replay-start-time"?  How long
> > > should we allow the clocks to drift before we reject the subscription?
> > > As we don't support future/pending subscriptions, we don't have to
> > > worry about these questions with the current definition.
> >
> > I would simply say that if the replay-start-time is later than any
> buffered notif,
> > then "replay-complete" is immediately sent.  It dont'
> > matter if it is one microsecond or one year later.
>
> Tweaked the sentence:
>
> "If the given "replay-start-time" is later than the time marked within any
> event records retained within the replay buffer, then the publisher MUST
> send a "replay-completed" notification immediately after a successful
> establish-subscription RPC response."
>
> > The problem otherwise is how to decide if something is "in the past".
> > In the past when the client sent the request?  When the server parsed
> the XML?
> > When the instrumentation code runs?
> >
> > But this is not a big issue.
>
> Hopefully with the tweak, we can leave it as modified.
>
> [..]
> > > > o  Section 2.4.6
> > > >
> > > >   The text says:
> > > >
> > > >     1.  "establish-subscription-stream-error-info": This MUST be
> returned
> > > >         if an RPC error reason has not been placed elsewhere within
> the
> > > >         transport portion of a failed "establish-subscription" RPC
> > > >         response.
> > > >
> > > >   (and similar for the other errors)
> > > >
> > > >   What exactly does "if an RPC error reason has not been placed
> > > >   elsewhere" mean?
> > >
> > > The intent is to match how NETCONF & RESTCONF historically handles
> > > errors.  As you know with NETCONF, each error identity will be
> > > inserted as the "error-app-tag".
> >
> > It could also be in "error-tag" and/or "error-message".  My point is
> that I don't
> > think that you mean that if an implementation populate say
> "error-message",
> > then it should not popluate error-info with
> establish-subscription-stream-
> > error-info.
>
> I do mean that.  I don't think we should send: "establish-subscription-stream-error-info"
> for NETCONF when there is no hint included.  All the necessary error info
> is already in the existing message.
>
> > > And therefore placing the YANG data
> > > "establish-subscription-stream-error-info" would be redundant.  For
> > > NETCONF, "establish-subscription-stream-error-info" are only needed
> > > when hints to be provided.
> > >
> > > Therefore assuming you are looking for an alternative way to make this
> > > point, I have tweaked the text to:
> > > "This MUST be returned if an RPC error reason has not been mapped down
> > > into transport specific error objects contained within a failed
> > > "establish-subscription" RPC response."
> >
> > Howabout simply removing this sentence?
>
> Done
>
> > > > o  Section 2.5.1
> > > >
> > > >   In the second diagram (for the valid state), the states are called
> > > >   "receiver connecting", "reciever timeout" etc.  I find this a bit
> > > >   confusing; it is not the *receiver* that is connecting, it is the
> > > >   publisher.  Ok, the legend then says:
> > > >
> > > >      dashed boxes which include the word 'receiver' show the possible
> > > >      states for an individual receiver
> > > >
> > > >  But since all dashed boxes include the word "receiver", and the
> > > > diagram specifically is the state machine *per receiver*, maybe we
> > > > can simply remove the word "receiver" from the boxes?
> > >
> > > There have been some discussions on this.  I agree it is certainly
> > > valid to remove "receiver" from these four boxes.  However I have
> > > found that getting readers to really internalize that the state
> > > machine is actually per-receiver rather than per-subscription, it
> > > seems to go faster/cleaner when receiver is shown in the four boxes.
> > >
> > > Nevertheless, if you absolutely want "receiver" removed from the
> > > boxes, I can do that.
> >
> > Maybe you can remove receiver from the individual boxes and then change
> the
> > word "valid" from the outer box to "per-receiver state machine"?
> >
> > Or maybe remove the outer box and add a Figure title: 'per-receiver state
> > machine for the subscription's "valid" state'
> >
> > Also not a big deal, but I found it confusing.
>
> All are viable.  But I have found the current diagram useable. Do you have
> a major issue if we leave it as it is?
>
> > [...]
> >
> > > > o  Section 2.5.6
> > > >
> > > >   I know that this feature was presented in Montreal.  I think it is
> > > >   problematic, and suggest it is removed.
> > >
> > > This issue was discussed in Montreal.  The feature is of course is
> > > optional.  There are a large number of downsides for someone who
> > > chooses not to implement for certain use cases.  Please see the
> > > Montreal slides and the long threads with Kent for more details.
> >
> > I did watch the Montreal session, but I didn't see any discussion on
> > this issue (just your presentation).   Can you send a pointer to the
> > email thread with Kent?
>
> Some minutes on the topic can be seen at:
> https://datatracker.ietf.org/doc/minutes-102-netconf/
> With the WG vote in Montreal, I would love not to re-open.
>
> The previous exchange was long.  Some items include:
> https://www.ietf.org/mail-archive/web/netconf/current/msg14575.html
> https://www.ietf.org/mail-archive/web/netconf/current/msg14902.html
>
> > > If
> > > you want to pursue this further it is probably best to start a new
> > > thread dedicated to this topic alone.
> > >
> > > >   For example, what happens if the transport session is lost and
> > > >   re-established; are all event records in the buffer replayed again?
> > >
> > > No.  The publisher will not lose context of what was sent.
> >
> > This is not clear from the text.  In fact, the text explicitly says:
> >
> >    The leading event record sent will be the first event record
> >    subsequent to the latest of three different times: the
> >    "replay-log-creation-time", "replay-log-aged- time", or the most
> >    recent publisher boot time.
>
> I see your point.   I have tweaked the text to:
>
> " If the publisher does not know the next record intended for the
> receiver, the leading event record..."
>
> I have also made a corresponding tweak to the YANG model.
>
> > > >   What happens if a new receiver is added to a subscription that
> > > >   already has a receiver, will all events in the buffer be replayed
> to
> > > >   the new receiver?
> > >
> > > Yes.  (To clarify, I added "to each configured receiver" at the end of
> > > the last sentence of the first paragraph.)
> > >
> > > >   When a new subscription is configured with configured-replay set,
> > > >   the publisher will immediately try to connect to the publisher and
> > > >   send all buffered event from the last reboot.  Is this really
> > > >   useful?
> > >
> > > Yes.  See the security cases reviewed on the earlier threads with
> > > Kent.  If someone doesn't care about log entries since boot, they
> > > simply don't have to implement this optional feature.
> > >
> > > >   If the mechansim relies on the subscriber being able to also use
> > > >   dynamic subscriptions for replay of all event records, maybe we
> > > >   could simplify things by always relying on dynamic subscriptions
> for
> > > >   replay for configured subscriptions.  Specifically, remove
> > > >   "configured-replay" etc, but keep the "replay-previous-event-time"
> > > >   in the "subscription-started" notification.  Then a subscriber can
> > > >   simply check this value to see if anything is missing, and if it
> is,
> > > >   use a dynamic subscription to request replay from the latest time
> he
> > > >   knows about.
> > >
> > > This is a valid approach, and can be used as an alternative to this
> > > optional feature.  However there are still many downsides to the
> > > alternative.  See the slides from Montreal, as well as the previous
> > > thread discussions for details.
> > >
> > > > o  Section 2.6
> > > >
> > > >   It just occurred to me that this text about using the
> 
> > > >   message shouldn't be in this document, but in the netconf-notif
> (and
> > > >   restconf-notif) document.  It is highly transport and encoding
> > > >   specific.
> > >
> > > I think you are referring to both the sentence: "This notification
> > > message MUST be encoded in a  message as defined within
> > > [RFC5277], Section 4.  And per [RFC5277]'s "eventTime" object
> > > definition, the "eventTime" is populated with the event occurrence
> > > time."  As well as to the example compliant message in Figure 10.
> > >
> > > While the text could be extracted and placed in the netconf-notif
> > > document, extracting it fully from SN would leave no baseline message
> > > format.
> >
> > Things like this are inevitable when you have a transport-independent
> > specification.  Of course, you can require that all transports MUST use
> the 5277
> > spec of a notification.  But then I think you rule out transports like
> CoMI and
> > possibly other future binary protocols.
>
> Ok, I am fine with the move.  I have moved the identified text to
> NETCONF-Notif.  (Actually the text was already there too.  So I just
> tweaked it.)
>
> Thanks,
> Eric
>
> > > Perhaps others will have a problem if the SN solution does not have
> > > some pre-defined structure to hold event records?
> > >
> > > I can move this if I hear no objection.  As you know, I am hoping that
> > > draft-ietf-netconf-notification-messages at some point displaces the
> > >  message of [RFC5277], Section 4.  And this is easier to
> > > do with fewer references to RFC5277 within SN.
> >
> > [...]
> > /martin
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--000000000000d23fda0575b0f31a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Sep 12, 2018 at 11:35 AM, Eric Voit (evoit) &=
lt;=
evoit=3D40cisco.com@dmarc.ietf.org> wrote:
Hi Martin,



Much incorporated.=C2=A0 Latest is at:

https://github.com/netconf-wg/rfc5277bis/blob/master/draft-iet=
f-netconf-subscribed-notifications-17.txt



Specific responses in-line...



> From: Martin Bjorklund, September 12, 2018 5:35 AM

> 

> "Eric Voit (evoit)" <e=
voit@cisco.com> wrote:

> > Thanks for the comments Martin,=C2=A0 thoughts in-line...

> >

> > > From: Martin Bjorklund, September 10, 2018 1:42 PM

> 

> [...]

> 

> > > o=C2=A0 Section 2.1

> > >

> > >=C2=A0 =C2=A0The text says:

> > >

> > >=C2=A0 =C2=A0 =C2=A0It is out of the scope of this document
> > >=C2=A0 =C2=A0 =C2=A0to identify [...] b) how event records ar=
e defined

> > >

> > >=C2=A0 =C2=A0Is this really what we want?=C2=A0 Shouldn't=
 this document specify that

> > >=C2=A0 =C2=A0an event record is an instance of a YANG "n=
otification" statement?

> > >=C2=A0 =C2=A0Do we want to support event records that are not=
 defined in YANG?

> > >

> > >=C2=A0 =C2=A0This was discussed in the thread "comments =
on

> > >=C2=A0 =C2=A0draft-ietf-netconf-subscribed-notifications=
-12", and it seems that

> > >=C2=A0 =C2=A0noone really have any use case for non-YANG-defi=
ned event records,

> > >=C2=A0 =C2=A0accessed with YANG-defined operations.

> >

> > Yes this was discussed previously.=C2=A0 My reading was that othe=
rs wanted

> > to support subscription to non-YANG events.

> > E.g., see Andy & Tianran's thoughts in

> > https://www.ietf.org/ma=
il-archive/web/netconf/current/msg14764.html

> 

> Yes, but read on in that thread, see

> https://www.ietf.org/mail-archive/web/netconf/current/msg14766.html

> for a clarification.

> 

> AFAIK, noone has presented a use case for sending non-YANG-defined dat=
a

> here.



As anything can be YANG wrapped, per the thread above.=C2=A0 I am fine with=
 this.


I think my concer=
n was simply that I take notice any time anyone
uses the term MUS=
T in an I-D.=C2=A0 I ask myself "What harm to interoperability
will result if this MUST is not followed?=C2=A0 If I cannot think of any=
thing
(as in this case) then MUST is probably a SHOULD instead.

The use-case I have in mind -- protobuffs -- I don&=
#39;t see why it is important to
require a YANG module for every =
.proto file. Even worse, why is the
subscription draft making thi=
s requirement?

Andy


<=
/div>



> > >=C2=A0 =C2=A0I think that this document should state that an =
event record is an

> > >=C2=A0 =C2=A0instance of a YANG "notification" stat=
ement.=C2=A0 If not, it is unclear

> > >=C2=A0 =C2=A0both how subtree/xpath filters and xml/json/... =
encodings would work.

> >

> > Applying xpath filters against XML based event records seems viab=
le to

> > me.

> 

> Where does it say that it has to be XML?=C2=A0 Whatabout mixed-content=
?

> What if such a notification is sent when the encoding is JSON?

> 

> If you want to make this specification open for other data modeling la=
nguages,

> I think you need to carefully define how that is supposed to work; ess=
entially

> similar to how we handle transports; we have a set of requirement on w=
hat a

> transport document must define.=C2=A0 IMO this is super complicated an=
d overkill.

> This draft is complex enough.

> Don't add even more complexity.



If you are just saying that we can put everything into a YANG wrapper, that=
 is fine with me.=C2=A0 To clarify this, I have tweaked the first sentence =
of Section 2.1 to:

"An event stream is a named entity on a publisher which exposes a cont=
inuously updating set of YANG encoded event records."



And I have tweaked the first sentence of the third paragraph to:

"As YANG encoded event records are created by a system,..."



> > Of course it will be up to the definition of any particular strea=
m to

> > articulate the event record contents sufficiently for filters to =
be

> > created.

> >

> > > o=C2=A0 Section 2.1

> > >

> > >=C2=A0 =C2=A0The text says:

> > >

> > >=C2=A0 =C2=A0 =C2=A0Among

> > >=C2=A0 =C2=A0 =C2=A0these included NETCONF XML event records =
are individual YANG 1.1

> > >=C2=A0 =C2=A0 =C2=A0notifications described in section 7.16 o=
f [RFC7950].

> > >

> > >=C2=A0 =C2=A0First of all, does this mean that there can be e=
vent records on the

> > >=C2=A0 =C2=A0"NETCONF" stream that are *not* define=
d with a "notification"

> > >=C2=A0 =C2=A0statement?

> >

> > For the NETCONF stream, personally I only care about things YANG<=
br>
> > notification statement.=C2=A0 But looking again at Andy's com=
ment from:

> > https://www.ietf.org/ma=
il-archive/web/netconf/current/msg14764.html

> > he says "I would say SHOULD be defined in YANG, for the &quo=
t;NETCONF"

> > stream."

> 

> I strongly disagree.

> 

> > So for -v16 I updated the text in a way that doesn't preclude=
 this.

> 

> See above.=C2=A0 If all events records are defined in YANG we can remo=
ve this.



Per above, I have included text above so that YANG encapsulation is require=
d.=C2=A0 I think YANG Data should be an allowable structure (so I didn'=
t specify just a "Notification").=C2=A0 If you think that YANG Da=
ta should be excluded from the allowed event records. I can refine the word=
s.



> > >=C2=A0 =C2=A0Second, this seems to imply that *all* notificat=
ions defined in all

> > >=C2=A0 =C2=A0YANG modules end up in the "NETCONF" s=
tream, but I don't think this

> > >=C2=A0 =C2=A0is the intention.=C2=A0 At least I hope so.=C2=
=A0 ("yp:push-update" is an

> > >=C2=A0 =C2=A0example of a notification that will not be sent =
on the "NETCONF"

> > >=C2=A0 =C2=A0stream.)

> >

> > The NETCONF stream has a very broad/inclusive definition in RFC-5=
277.

> > This definition is: "This stream contains all NETCONF XML ev=
ent

> > notifications supported by the NETCONF server".

> 

> This is very underspecified.=C2=A0 IIRC the original intention was not=
ifications related

> to NETCONF, hence "*NETCONF* XML event notifications".

> 

> > To me, thinking about how that statement and applying it to YANG,=
 this

> > translates as YANG 1.1 notifications should go into the NETCONF
> > stream, unless explicitly excluded.

> 

> I disagree.=C2=A0 This is not how 5277 works.=C2=A0 Until we have work=
ed out a useful way

> to assign notifications to streams, we shouldn't restrict anything=
 in this regard.



Ok.=C2=A0 Effectively we are naming the stream NETCONF without improving th=
e definition of what membership in that stream should be.=C2=A0 And that is=
 fine.=C2=A0 As people seem to understand what this is supposed to be, I wi=
ll return to the original definition.=C2=A0 See text, and let me know if yo=
u have issues.



> > This provides a very simple way

> > determining which types of notifications should be placed on the<=
br>
> > stream.=C2=A0 (Otherwise, how is a developer of a YANG notificati=
on

> > supposed to know whether it should go into the NETCONF stream or =
not?

> 

> They don't.=C2=A0 But note that it might be an operator decision f=
or how to assign

> notifications to streams.



Ok.=C2=A0 A stream membership definition is out-of-scope for all other stre=
ams, we can leave it this way for the "NETCONF" stream.=C2=A0 Som=
eone else can pick up and define this in another draft the WG feels it nece=
ssary.



> > The alternative would seem to be having each notification opt-in =
to

> > the NETCONF stream.)

> >

> > So if you agree with this reasoning, how about:

> >

> > The "NETCONF" event stream contains all instances of YA=
NG 1.1

> > notifications generated by a publisher, except where a type of
> > notification has explicitly been excluded from the stream.

> 

> I think that this document should keep the definition of the NETCONF s=
tream as

> defined in RFC 5277.



Ok



> Also, I think it should state that an event record is an instantiation=
 of a YANG

> "notification" statement (any version of YANG).



What about a YANG Data?=C2=A0 (Per above)



> [...]

> 

> > > o=C2=A0 Section 2.4.2

> > >

> > >=C2=A0 =C2=A0The text says:

> > >

> > >=C2=A0 =C2=A0 =C2=A0The transport selected by the subscriber<=
br>
> > >=C2=A0 =C2=A0 =C2=A0to reach the publisher MUST be able to su=
pport multiple "establish-

> > >=C2=A0 =C2=A0 =C2=A0subscription" requests made within t=
he same transport session.

> > >

> > >=C2=A0 =C2=A0This seems to indicate that RESTCONF cannot be u=
sed with this

> > >=C2=A0 =C2=A0specification, since RESTCONF doesn't have s=
essions.

> >

> > The desired behavior is that a subscriber can request multiple
> > subscriptions without each requiring a separate transport session=


> > establishment.=C2=A0 I think we are ok here with RESTCONF because=


> > underneath RESTCONF is HTTP, TLS, TCP.=C2=A0 And each of those lo=
wer layers

> > can have sessions.

> >

> > To clarify further, I have tweaked the text to:

> >

> > "The transport selected by the subscriber to reach the publi=
sher MUST

> > be able to support multiple "establish-subscription" re=
quests without

> > each requiring a separate persistent transport connection."<=
br>
> >

> > >=C2=A0 =C2=A0This makes me wonder, why does this document spe=
cify this

> > >=C2=A0 =C2=A0requirement?=C2=A0 I agree that this is the beha=
viour we want from

> > >=C2=A0 =C2=A0NETCONF, but then I think that should be defined=
 in the

> > >=C2=A0 =C2=A0netconf-notif draft.

> >

> > By saying something in SN about this requirement, I believe we ca=
n

> > preclude an implementation which can only support one subscriptio=
n per

> > subscriber.=C2=A0 In any case, the specific "how" detai=
ls will still need

> > to be articulated in each transport draft.

> 

> I think you are mixing the specification and implementation.=C2=A0 If =
a transport

> document says that an implemention MUST support multiple subscriptions=
 per

> session (in a transport-specific way), then an implementation cannot j=
ust

> support a sinlge subscription.

> 

> My point is that this a transport-specific requirement, and it doesn&#=
39;t belong in

> this document.



I can see why you don't see it applicable to Section 2.4.2.=C2=A0 =C2=
=A0 However Section 5.3 provides guidelines for transport document develope=
rs (this is a section Kent requested.)=C2=A0 And so I have moved the requir=
ement there.=C2=A0 Is that sufficient. 



> > > o=C2=A0 Section 2.4.2

> > >

> > >=C2=A0 =C2=A0s/"start-time"/"replay-start-time"/=C2=A0 (3 occurrences)

> >

> > Fixed

> >

> > >=C2=A0 =C2=A0Also, the text says that the replay-start-time M=
UST be in the past.

> > >

> > >=C2=A0 =C2=A0Suppose the server receives a "replay-start=
-time" of 12:00:00.001,

> > >=C2=A0 =C2=A0and the replay buffer is empty.

> > >

> > >=C2=A0 =C2=A0A) If the current time is 12:00:00.002, the requ=
est is accepted, and

> > >=C2=A0 =C2=A0 =C2=A0 a "replay-completed" notif is =
sent.

> > >

> > >=C2=A0 =C2=A0B) If the current time is 12:00:00.000, the requ=
est is rejected with

> > >=C2=A0 =C2=A0 =C2=A0 an error.

> > >

> > >=C2=A0 =C2=A0Why is this important?=C2=A0 Why not simply just=
 send the

> > >=C2=A0 =C2=A0replay-completed notif in both cases?

> >

> > For (B), if an event occurs at 12:00:00.0005, should it be sent?<=
br>
> > Should it be sent before or after the "replay-start-time&quo=
t;?=C2=A0 How long

> > should we allow the clocks to drift before we reject the subscrip=
tion?

> > As we don't support future/pending subscriptions, we don'=
t have to

> > worry about these questions with the current definition.

> 

> I would simply say that if the replay-start-time is later than any buf=
fered notif,

> then "replay-complete" is immediately sent.=C2=A0 It dont=
9;

> matter if it is one microsecond or one year later.



Tweaked the sentence:



"If the given "replay-start-time" is later than the time mar=
ked within any event records retained within the replay buffer, then the pu=
blisher MUST send a "replay-completed" notification immediately a=
fter a successful establish-subscription RPC response."



> The problem otherwise is how to decide if something is "in the pa=
st".

> In the past when the client sent the request?=C2=A0 When the server pa=
rsed the XML?

> When the instrumentation code runs?

> 

> But this is not a big issue.



Hopefully with the tweak, we can leave it as modified.



[..]

> > > o=C2=A0 Section 2.4.6

> > >

> > >=C2=A0 =C2=A0The text says:

> > >

> > >=C2=A0 =C2=A0 =C2=A01.=C2=A0 "establish-subscription-stream-error-info": This MUST be returned

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if an RPC error reason has =
not been placed elsewhere within the

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transport portion of a fail=
ed "establish-subscription" RPC

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0response.

> > >

> > >=C2=A0 =C2=A0(and similar for the other errors)

> > >

> > >=C2=A0 =C2=A0What exactly does "if an RPC error reason h=
as not been placed

> > >=C2=A0 =C2=A0elsewhere" mean?

> >

> > The intent is to match how NETCONF & RESTCONF historically ha=
ndles

> > errors.=C2=A0 As you know with NETCONF, each error identity will =
be

> > inserted as the "error-app-tag".

> 

> It could also be in "error-tag" and/or "error-message&q=
uot;.=C2=A0 My point is that I don't

> think that you mean that if an implementation populate say "error=
-message",

> then it should not popluate error-info with establish-subscription-str=
eam-

> error-info.



I do mean that.=C2=A0 I don't think we should send: "establish-sub=
scription-stream-error-info" for NETCONF when there is no hint in=
cluded.=C2=A0 All the necessary error info is already in the existing messa=
ge.



> > And therefore placing the YANG data

> > "establish-subscription-stream-error-info" would b=
e redundant.=C2=A0 For

> > NETCONF, "establish-subscription-stream-error-info"=
; are only needed

> > when hints to be provided.

> >

> > Therefore assuming you are looking for an alternative way to make=
 this

> > point, I have tweaked the text to:

> > "This MUST be returned if an RPC error reason has not been m=
apped down

> > into transport specific error objects contained within a failed
> > "establish-subscription" RPC response."

> 

> Howabout simply removing this sentence?



Done



> > > o=C2=A0 Section 2.5.1

> > >

> > >=C2=A0 =C2=A0In the second diagram (for the valid state), the=
 states are called

> > >=C2=A0 =C2=A0"receiver connecting", "reciever =
timeout" etc.=C2=A0 I find this a bit

> > >=C2=A0 =C2=A0confusing; it is not the *receiver* that is conn=
ecting, it is the

> > >=C2=A0 =C2=A0publisher.=C2=A0 Ok, the legend then says:

> > >

> > >=C2=A0 =C2=A0 =C2=A0 dashed boxes which include the word '=
;receiver' show the possible

> > >=C2=A0 =C2=A0 =C2=A0 states for an individual receiver

> > >

> > >=C2=A0 But since all dashed boxes include the word "rece=
iver", and the

> > > diagram specifically is the state machine *per receiver*, ma=
ybe we

> > > can simply remove the word "receiver" from the box=
es?

> >

> > There have been some discussions on this.=C2=A0 I agree it is cer=
tainly

> > valid to remove "receiver" from these four boxes.=C2=A0=
 However I have

> > found that getting readers to really internalize that the state
> > machine is actually per-receiver rather than per-subscription, it=


> > seems to go faster/cleaner when receiver is shown in the four box=
es.

> >

> > Nevertheless, if you absolutely want "receiver" removed=
 from the

> > boxes, I can do that.

> 

> Maybe you can remove receiver from the individual boxes and then chang=
e the

> word "valid" from the outer box to "per-receiver state =
machine"?

> 

> Or maybe remove the outer box and add a Figure title: 'per-receive=
r state

> machine for the subscription's "valid" state'

> 

> Also not a big deal, but I found it confusing.



All are viable.=C2=A0 But I have found the current diagram useable. Do you =
have a major issue if we leave it as it is?



> [...]

> 

> > > o=C2=A0 Section 2.5.6

> > >

> > >=C2=A0 =C2=A0I know that this feature was presented in Montre=
al.=C2=A0 I think it is

> > >=C2=A0 =C2=A0problematic, and suggest it is removed.

> >

> > This issue was discussed in Montreal.=C2=A0 The feature is of cou=
rse is

> > optional.=C2=A0 There are a large number of downsides for someone=
 who

> > chooses not to implement for certain use cases.=C2=A0 Please see =
the

> > Montreal slides and the long threads with Kent for more details.<=
br>
> 

> I did watch the Montreal session, but I didn't see any discussion =
on

> this issue (just your presentation).=C2=A0 =C2=A0Can you send a pointe=
r to the

> email thread with Kent?



Some minutes on the topic can be seen at:

https://datatracker.ietf.org/doc/minutes-1=
02-netconf/ 

With the WG vote in Montreal, I would love not to re-open.=C2=A0 



The previous exchange was long.=C2=A0 Some items include:

https://www.ietf.org/mail-ar=
chive/web/netconf/current/msg14575.html

https://www.ietf.org/mail-ar=
chive/web/netconf/current/msg14902.html 



> > If

> > you want to pursue this further it is probably best to start a ne=
w

> > thread dedicated to this topic alone.

> >

> > >=C2=A0 =C2=A0For example, what happens if the transport sessi=
on is lost and

> > >=C2=A0 =C2=A0re-established; are all event records in the buf=
fer replayed again?

> >

> > No.=C2=A0 The publisher will not lose context of what was sent.
> 

> This is not clear from the text.=C2=A0 In fact, the text explicitly sa=
ys:

> 

>=C2=A0 =C2=A0 The leading event record sent will be the first event rec=
ord

>=C2=A0 =C2=A0 subsequent to the latest of three different times: the
>=C2=A0 =C2=A0 "replay-log-creation-time", "replay-log-ag=
ed- time", or the most

>=C2=A0 =C2=A0 recent publisher boot time.



I see your point.=C2=A0 =C2=A0I have tweaked the text to:



" If the publisher does not know the next record intended for the rece=
iver, the leading event record..."



I have also made a corresponding tweak to the YANG model.



> > >=C2=A0 =C2=A0What happens if a new receiver is added to a sub=
scription that

> > >=C2=A0 =C2=A0already has a receiver, will all events in the b=
uffer be replayed to

> > >=C2=A0 =C2=A0the new receiver?

> >

> > Yes.=C2=A0 (To clarify, I added "to each configured receiver=
" at the end of

> > the last sentence of the first paragraph.)

> >

> > >=C2=A0 =C2=A0When a new subscription is configured with confi=
gured-replay set,

> > >=C2=A0 =C2=A0the publisher will immediately try to connect to=
 the publisher and

> > >=C2=A0 =C2=A0send all buffered event from the last reboot.=C2=
=A0 Is this really

> > >=C2=A0 =C2=A0useful?

> >

> > Yes.=C2=A0 See the security cases reviewed on the earlier threads=
 with

> > Kent.=C2=A0 If someone doesn't care about log entries since b=
oot, they

> > simply don't have to implement this optional feature.

> >

> > >=C2=A0 =C2=A0If the mechansim relies on the subscriber being =
able to also use

> > >=C2=A0 =C2=A0dynamic subscriptions for replay of all event re=
cords, maybe we

> > >=C2=A0 =C2=A0could simplify things by always relying on dynam=
ic subscriptions for

> > >=C2=A0 =C2=A0replay for configured subscriptions.=C2=A0 Speci=
fically, remove

> > >=C2=A0 =C2=A0"configured-replay" etc, but keep the =
"replay-previous-event-time"

> > >=C2=A0 =C2=A0in the "subscription-started" notifica=
tion.=C2=A0 Then a subscriber can

> > >=C2=A0 =C2=A0simply check this value to see if anything is mi=
ssing, and if it is,

> > >=C2=A0 =C2=A0use a dynamic subscription to request replay fro=
m the latest time he

> > >=C2=A0 =C2=A0knows about.

> >

> > This is a valid approach, and can be used as an alternative to th=
is

> > optional feature.=C2=A0 However there are still many downsides to=
 the

> > alternative.=C2=A0 See the slides from Montreal, as well as the p=
revious

> > thread discussions for details.

> >

> > > o=C2=A0 Section 2.6

> > >

> > >=C2=A0 =C2=A0It just occurred to me that this text about usin=
g the <notification>

> > >=C2=A0 =C2=A0message shouldn't be in this document, but i=
n the netconf-notif (and

> > >=C2=A0 =C2=A0restconf-notif) document.=C2=A0 It is highly tra=
nsport and encoding

> > >=C2=A0 =C2=A0specific.

> >

> > I think you are referring to both the sentence: "This notifi=
cation

> > message MUST be encoded in a <notification> message as defi=
ned within

> > [RFC5277], Section 4.=C2=A0 And per [RFC5277]'s "eventTi=
me" object

> > definition, the "eventTime" is populated with the event=
 occurrence

> > time."=C2=A0 As well as to the example compliant message in =
Figure 10.

> >

> > While the text could be extracted and placed in the netconf-notif=


> > document, extracting it fully from SN would leave no baseline mes=
sage

> > format.

> 

> Things like this are inevitable when you have a transport-independent<=
br>
> specification.=C2=A0 Of course, you can require that all transports MU=
ST use the 5277

> spec of a notification.=C2=A0 But then I think you rule out transports=
 like CoMI and

> possibly other future binary protocols.



Ok, I am fine with the move.=C2=A0 I have moved the identified text to NETC=
ONF-Notif.=C2=A0 (Actually the text was already there too.=C2=A0 So I just =
tweaked it.)



Thanks,

Eric



> > Perhaps others will have a problem if the SN solution does not ha=
ve

> > some pre-defined structure to hold event records?

> >

> > I can move this if I hear no objection.=C2=A0 As you know, I am h=
oping that

> > draft-ietf-netconf-notification-messages at some point displ=
aces the

> > <notification> message of [RFC5277], Section 4.=C2=A0 And t=
his is easier to

> > do with fewer references to RFC5277 within SN.

> 

> [...]

> /martin



_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--000000000000d23fda0575b0f31a--


From nobody Wed Sep 12 13:02:15 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F00130EA9 for ; Wed, 12 Sep 2018 13:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_MED=-0.01, 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 PFvXX6a9gmMv for ; Wed, 12 Sep 2018 13:02:11 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661FF130D7A for ; Wed, 12 Sep 2018 13:02:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13908; q=dns/txt; s=iport; t=1536782531; x=1537992131; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3Nb6NRAMaLl8jcyOmUNjkJefyoIKRAFgKLdYfpJM4ao=; b=fWnLlcvoj3bjJY7ggjl55tVh47inkSXzOnFCXcPmSZmsASmc64E/xS/h ymVj5ILQlex9mpOLOSFujJD2ey3yxFalsPjoRTnCtsMuSdlxkWk06llBf lLtJ2BsmuTPRdM+C3z3wioVui0zzljCQKvx1AzN2fiGSPFHFXmkEKRxC1 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AACxb5lb/4gNJK1SChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGBToERTSplfygKg2iIFY4pkQiFNYF6CyWEAUYCF4M2ITQ?= =?us-ascii?q?YAQIBAQIBAQJtHAyFOAEBAQECASMKSgIFCwIBCBUDDRoDAgICMBQRAgQBDQU?= =?us-ascii?q?Igk5MgR1cCA+lSYEuigsFimcXgUE/gRKDEoMbAgEBgTQLAQFUgkuCVwKINYU?= =?us-ascii?q?DjmgJAoY5gkeDPYNDH4FBIYcihXeLRYg0AhEUgSUdOIFVcBWDJ4YBhRSFPm8?= =?us-ascii?q?BjD6BH4EeAQE?=
X-IronPort-AV: E=Sophos;i="5.53,366,1531785600";  d="scan'208,217";a="170822474"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2018 20:02:10 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id w8CK2AWS026976 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Sep 2018 20:02:10 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Sep 2018 16:02: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.1395.000; Wed, 12 Sep 2018 16:02:09 -0400
From: "Eric Voit (evoit)" 
To: Andy Bierman , Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of subscribed-notifications-16
Thread-Index: AQHUSS2c6fWPWMQnpECqHWzj9l2RFqTpyY1wgALe1QCAACWmwIAAc2AA///OXHA=
Date: Wed, 12 Sep 2018 20:02:09 +0000
Message-ID: 
References: <20180910.194152.138356385922962289.mbj@tail-f.com>  <20180912.113446.2017030234338816835.mbj@tail-f.com> <013a970e210d4b9693116818f3d5688e@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.234]
Content-Type: multipart/alternative; boundary="_000_ccac3373a7b0434db41177943e9300f4XCHRTP013ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 20:02:14 -0000

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

RnJvbTogQW5keSBCaWVybWFuLCBTZXB0ZW1iZXIgMTIsIDIwMTggMjo0MiBQTQ0KDQpPbiBXZWQs
IFNlcCAxMiwgMjAxOCBhdCAxMTozNSBBTSwgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0PTQwY2lz
Y28uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpldm9pdD00MGNpc2NvLmNvbUBkbWFyYy5pZXRm
Lm9yZz4+IHdyb3RlOg0KSGkgTWFydGluLA0KDQpNdWNoIGluY29ycG9yYXRlZC4gIExhdGVzdCBp
cyBhdDoNCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3JmYzUyNzdiaXMvYmxvYi9tYXN0
ZXIvZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucy0xNy50eHQNCg0K
U3BlY2lmaWMgcmVzcG9uc2VzIGluLWxpbmUuLi4NCg0KPiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5k
LCBTZXB0ZW1iZXIgMTIsIDIwMTggNTozNSBBTQ0KPg0KPiAiRXJpYyBWb2l0IChldm9pdCkiIDxl
dm9pdEBjaXNjby5jb208bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+IHdyb3RlOg0KPiA+IFRoYW5r
cyBmb3IgdGhlIGNvbW1lbnRzIE1hcnRpbiwgIHRob3VnaHRzIGluLWxpbmUuLi4NCj4gPg0KPiA+
ID4gRnJvbTogTWFydGluIEJqb3JrbHVuZCwgU2VwdGVtYmVyIDEwLCAyMDE4IDE6NDIgUE0NCj4N
Cj4gWy4uLl0NCj4NCj4gPiA+IG8gIFNlY3Rpb24gMi4xDQo+ID4gPg0KPiA+ID4gICBUaGUgdGV4
dCBzYXlzOg0KPiA+ID4NCj4gPiA+ICAgICBJdCBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMg
ZG9jdW1lbnQNCj4gPiA+ICAgICB0byBpZGVudGlmeSBbLi4uXSBiKSBob3cgZXZlbnQgcmVjb3Jk
cyBhcmUgZGVmaW5lZA0KPiA+ID4NCj4gPiA+ICAgSXMgdGhpcyByZWFsbHkgd2hhdCB3ZSB3YW50
PyAgU2hvdWxkbid0IHRoaXMgZG9jdW1lbnQgc3BlY2lmeSB0aGF0DQo+ID4gPiAgIGFuIGV2ZW50
IHJlY29yZCBpcyBhbiBpbnN0YW5jZSBvZiBhIFlBTkcgIm5vdGlmaWNhdGlvbiIgc3RhdGVtZW50
Pw0KPiA+ID4gICBEbyB3ZSB3YW50IHRvIHN1cHBvcnQgZXZlbnQgcmVjb3JkcyB0aGF0IGFyZSBu
b3QgZGVmaW5lZCBpbiBZQU5HPw0KPiA+ID4NCj4gPiA+ICAgVGhpcyB3YXMgZGlzY3Vzc2VkIGlu
IHRoZSB0aHJlYWQgImNvbW1lbnRzIG9uDQo+ID4gPiAgIGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJz
Y3JpYmVkLW5vdGlmaWNhdGlvbnMtMTIiLCBhbmQgaXQgc2VlbXMgdGhhdA0KPiA+ID4gICBub29u
ZSByZWFsbHkgaGF2ZSBhbnkgdXNlIGNhc2UgZm9yIG5vbi1ZQU5HLWRlZmluZWQgZXZlbnQgcmVj
b3JkcywNCj4gPiA+ICAgYWNjZXNzZWQgd2l0aCBZQU5HLWRlZmluZWQgb3BlcmF0aW9ucy4NCj4g
Pg0KPiA+IFllcyB0aGlzIHdhcyBkaXNjdXNzZWQgcHJldmlvdXNseS4gIE15IHJlYWRpbmcgd2Fz
IHRoYXQgb3RoZXJzIHdhbnRlZA0KPiA+IHRvIHN1cHBvcnQgc3Vic2NyaXB0aW9uIHRvIG5vbi1Z
QU5HIGV2ZW50cy4NCj4gPiBFLmcuLCBzZWUgQW5keSAmIFRpYW5yYW4ncyB0aG91Z2h0cyBpbg0K
PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi9jdXJyZW50
L21zZzE0NzY0Lmh0bWwNCj4NCj4gWWVzLCBidXQgcmVhZCBvbiBpbiB0aGF0IHRocmVhZCwgc2Vl
DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi9jdXJyZW50
L21zZzE0NzY2Lmh0bWwNCj4gZm9yIGEgY2xhcmlmaWNhdGlvbi4NCj4NCj4gQUZBSUssIG5vb25l
IGhhcyBwcmVzZW50ZWQgYSB1c2UgY2FzZSBmb3Igc2VuZGluZyBub24tWUFORy1kZWZpbmVkIGRh
dGENCj4gaGVyZS4NCg0KQXMgYW55dGhpbmcgY2FuIGJlIFlBTkcgd3JhcHBlZCwgcGVyIHRoZSB0
aHJlYWQgYWJvdmUuICBJIGFtIGZpbmUgd2l0aCB0aGlzLg0KDQoNCkkgdGhpbmsgbXkgY29uY2Vy
biB3YXMgc2ltcGx5IHRoYXQgSSB0YWtlIG5vdGljZSBhbnkgdGltZSBhbnlvbmUNCnVzZXMgdGhl
IHRlcm0gTVVTVCBpbiBhbiBJLUQuICBJIGFzayBteXNlbGYgIldoYXQgaGFybSB0byBpbnRlcm9w
ZXJhYmlsaXR5DQp3aWxsIHJlc3VsdCBpZiB0aGlzIE1VU1QgaXMgbm90IGZvbGxvd2VkPyAgSWYg
SSBjYW5ub3QgdGhpbmsgb2YgYW55dGhpbmcNCihhcyBpbiB0aGlzIGNhc2UpIHRoZW4gTVVTVCBp
cyBwcm9iYWJseSBhIFNIT1VMRCBpbnN0ZWFkLg0KDQpUaGUgdXNlLWNhc2UgSSBoYXZlIGluIG1p
bmQgLS0gcHJvdG9idWZmcyAtLSBJIGRvbid0IHNlZSB3aHkgaXQgaXMgaW1wb3J0YW50IHRvDQpy
ZXF1aXJlIGEgWUFORyBtb2R1bGUgZm9yIGV2ZXJ5IC4ucHJvdG8gZmlsZS4gRXZlbiB3b3JzZSwg
d2h5IGlzIHRoZQ0Kc3Vic2NyaXB0aW9uIGRyYWZ0IG1ha2luZyB0aGlzIHJlcXVpcmVtZW50Pw0K
DQo8ZXJpYz4gIEkgYW0gZ29vZCB3aXRoIHdoYXRldmVyIHdvcmtzIGZvciBwZW9wbGUuICBJIGRv
buKAmXQgc2VlIHRoZSB3cmFwcGVyIGFzIG5lY2Vzc2FyeSwgd2hpY2ggaXMgd2h5IGl0IHdhc27i
gJl0IGluIHRoZSBkb2N1bWVudCB0aHJvdWdoIOKAk3YxNi4gIElmIHlvdXIgYXJndW1lbnQgb24g
dGhlIC5wcm90byBmaWxlIHN3YXlzIE1hcnRpbiwgSSBhbSBoYXBweSB0byBnbyBiYWNrIHRvIHRo
ZSBlYXJsaWVyIHRleHQuDQoNCkVyaWMNCg0KQW5keQ0KDQoNCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp
biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1
bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i
cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w
cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux
RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
IEFuZHkgQmllcm1hbiwgU2VwdGVtYmVyIDEyLCAyMDE4IDI6NDIgUE08YnI+DQo8YnI+DQo8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBTZXAgMTIsIDIwMTggYXQgMTE6MzUgQU0sIEVy
aWMgVm9pdCAoZXZvaXQpICZsdDs8YSBocmVmPSJtYWlsdG86ZXZvaXQ9NDBjaXNjby5jb21AZG1h
cmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ldm9pdD00MGNpc2NvLmNvbUBkbWFyYy5pZXRm
Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkhpIE1hcnRpbiw8YnI+DQo8YnI+DQpNdWNoIGluY29ycG9yYXRlZC4mbmJz
cDsgTGF0ZXN0IGlzIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25m
LXdnL3JmYzUyNzdiaXMvYmxvYi9tYXN0ZXIvZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQt
bm90aWZpY2F0aW9ucy0xNy50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20v
bmV0Y29uZi13Zy9yZmM1Mjc3YmlzL2Jsb2IvbWFzdGVyL2RyYWZ0LWlldGYtbmV0Y29uZi1zdWJz
Y3JpYmVkLW5vdGlmaWNhdGlvbnMtMTcudHh0PC9hPjxicj4NCjxicj4NClNwZWNpZmljIHJlc3Bv
bnNlcyBpbi1saW5lLi4uPGJyPg0KPGJyPg0KJmd0OyBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kLCBT
ZXB0ZW1iZXIgMTIsIDIwMTggNTozNSBBTTxicj4NCiZndDsgPGJyPg0KJmd0OyAmcXVvdDtFcmlj
IFZvaXQgKGV2b2l0KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2b2l0QGNpc2NvLmNvbSI+
ZXZvaXRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IFRoYW5rcyBmb3Ig
dGhlIGNvbW1lbnRzIE1hcnRpbiwmbmJzcDsgdGhvdWdodHMgaW4tbGluZS4uLjxicj4NCiZndDsg
Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEZyb206IE1hcnRpbiBCam9ya2x1bmQsIFNlcHRlbWJl
ciAxMCwgMjAxOCAxOjQyIFBNPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFsuLi5dPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyBvJm5ic3A7IFNlY3Rpb24gMi4xPGJyPg0KJmd0OyAmZ3Q7ICZn
dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDtUaGUgdGV4dCBzYXlzOjxicj4NCiZn
dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0l0IGlz
IG91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudDxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5i
c3A7ICZuYnNwOyAmbmJzcDt0byBpZGVudGlmeSBbLi4uXSBiKSBob3cgZXZlbnQgcmVjb3JkcyBh
cmUgZGVmaW5lZDxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsg
Jm5ic3A7SXMgdGhpcyByZWFsbHkgd2hhdCB3ZSB3YW50PyZuYnNwOyBTaG91bGRuJ3QgdGhpcyBk
b2N1bWVudCBzcGVjaWZ5IHRoYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDthbiBl
dmVudCByZWNvcmQgaXMgYW4gaW5zdGFuY2Ugb2YgYSBZQU5HICZxdW90O25vdGlmaWNhdGlvbiZx
dW90OyBzdGF0ZW1lbnQ/PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7RG8gd2Ugd2Fu
dCB0byBzdXBwb3J0IGV2ZW50IHJlY29yZHMgdGhhdCBhcmUgbm90IGRlZmluZWQgaW4gWUFORz88
YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO1RoaXMg
d2FzIGRpc2N1c3NlZCBpbiB0aGUgdGhyZWFkICZxdW90O2NvbW1lbnRzIG9uPGJyPg0KJmd0OyAm
Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZp
Y2F0aW9ucy0xMiZxdW90OywgYW5kIGl0IHNlZW1zIHRoYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZu
YnNwOyAmbmJzcDtub29uZSByZWFsbHkgaGF2ZSBhbnkgdXNlIGNhc2UgZm9yIG5vbi1ZQU5HLWRl
ZmluZWQgZXZlbnQgcmVjb3Jkcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDthY2Nl
c3NlZCB3aXRoIFlBTkctZGVmaW5lZCBvcGVyYXRpb25zLjxicj4NCiZndDsgJmd0Ozxicj4NCiZn
dDsgJmd0OyBZZXMgdGhpcyB3YXMgZGlzY3Vzc2VkIHByZXZpb3VzbHkuJm5ic3A7IE15IHJlYWRp
bmcgd2FzIHRoYXQgb3RoZXJzIHdhbnRlZDxicj4NCiZndDsgJmd0OyB0byBzdXBwb3J0IHN1YnNj
cmlwdGlvbiB0byBub24tWUFORyBldmVudHMuPGJyPg0KJmd0OyAmZ3Q7IEUuZy4sIHNlZSBBbmR5
ICZhbXA7IFRpYW5yYW4ncyB0aG91Z2h0cyBpbjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cxNDc2
NC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp
dmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cxNDc2NC5odG1sPC9hPjxicj4NCiZndDsgPGJyPg0K
Jmd0OyBZZXMsIGJ1dCByZWFkIG9uIGluIHRoYXQgdGhyZWFkLCBzZWU8YnI+DQomZ3Q7IDxhIGhy
ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi9jdXJyZW50
L21zZzE0NzY2Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi9jdXJyZW50L21zZzE0NzY2Lmh0bWw8L2E+PGJyPg0KJmd0
OyBmb3IgYSBjbGFyaWZpY2F0aW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBBRkFJSywgbm9vbmUg
aGFzIHByZXNlbnRlZCBhIHVzZSBjYXNlIGZvciBzZW5kaW5nIG5vbi1ZQU5HLWRlZmluZWQgZGF0
YTxicj4NCiZndDsgaGVyZS48YnI+DQo8YnI+DQpBcyBhbnl0aGluZyBjYW4gYmUgWUFORyB3cmFw
cGVkLCBwZXIgdGhlIHRocmVhZCBhYm92ZS4mbmJzcDsgSSBhbSBmaW5lIHdpdGggdGhpcy48bzpw
PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+SSB0aGluayBteSBjb25jZXJuIHdhcyBzaW1wbHkgdGhhdCBJIHRha2Ugbm90aWNlIGFueSB0
aW1lIGFueW9uZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+dXNlcyB0aGUgdGVybSBNVVNUIGluIGFuIEktRC4mbmJzcDsgSSBhc2sgbXlzZWxmICZx
dW90O1doYXQgaGFybSB0byBpbnRlcm9wZXJhYmlsaXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aWxsIHJlc3VsdCBpZiB0aGlzIE1VU1QgaXMg
bm90IGZvbGxvd2VkPyZuYnNwOyBJZiBJIGNhbm5vdCB0aGluayBvZiBhbnl0aGluZzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KGFzIGluIHRoaXMg
Y2FzZSkgdGhlbiBNVVNUIGlzIHByb2JhYmx5IGEgU0hPVUxEIGluc3RlYWQuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB1c2UtY2FzZSBJ
IGhhdmUgaW4gbWluZCAtLSBwcm90b2J1ZmZzIC0tIEkgZG9uJ3Qgc2VlIHdoeSBpdCBpcyBpbXBv
cnRhbnQgdG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPnJlcXVpcmUgYSBZQU5HIG1vZHVsZSBmb3IgZXZlcnkgLi5wcm90byBmaWxlLiBFdmVuIHdv
cnNlLCB3aHkgaXMgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5zdWJzY3JpcHRpb24gZHJhZnQgbWFraW5nIHRoaXMgcmVxdWlyZW1lbnQ/PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZsdDtlcmljJmd0OyZuYnNwOyBJIGFt
IGdvb2Qgd2l0aCB3aGF0ZXZlciB3b3JrcyBmb3IgcGVvcGxlLiZuYnNwOyBJIGRvbuKAmXQgc2Vl
IHRoZSB3cmFwcGVyIGFzIG5lY2Vzc2FyeSwgd2hpY2ggaXMgd2h5IGl0IHdhc27igJl0IGluIHRo
ZSBkb2N1bWVudCB0aHJvdWdoIOKAk3YxNi4mbmJzcDsgSWYgeW91ciBhcmd1bWVudA0KIG9uIHRo
ZSAucHJvdG8gZmlsZSBzd2F5cyBNYXJ0aW4sIEkgYW0gaGFwcHkgdG8gZ28gYmFjayB0byB0aGUg
ZWFybGllciB0ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48YnI+DQpFcmljPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_ccac3373a7b0434db41177943e9300f4XCHRTP013ciscocom_--


From nobody Wed Sep 12 13:08:14 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E7C130EBF for ; Wed, 12 Sep 2018 13:08:12 -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 GgXj8Uo0iWZ3 for ; Wed, 12 Sep 2018 13:08:08 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D6856130EB2 for ; Wed, 12 Sep 2018 13:08:07 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id D3EF71AE02BE; Wed, 12 Sep 2018 22:08:05 +0200 (CEST)
Date: Wed, 12 Sep 2018 22:08:05 +0200 (CEST)
Message-Id: <20180912.220805.1931099349419935246.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: evoit=40cisco.com@dmarc.ietf.org, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20180912.113446.2017030234338816835.mbj@tail-f.com> <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 20:08:13 -0000

Andy Bierman  wrote:
> On Wed, Sep 12, 2018 at 11:35 AM, Eric Voit (evoit) <
> evoit=40cisco.com@dmarc.ietf.org> wrote:
> 
> > Hi Martin,
> >
> > Much incorporated.  Latest is at:
> > https://github.com/netconf-wg/rfc5277bis/blob/master/draft-
> > ietf-netconf-subscribed-notifications-17.txt
> >
> > Specific responses in-line...
> >
> > > From: Martin Bjorklund, September 12, 2018 5:35 AM
> > >
> > > "Eric Voit (evoit)"  wrote:
> > > > Thanks for the comments Martin,  thoughts in-line...
> > > >
> > > > > From: Martin Bjorklund, September 10, 2018 1:42 PM
> > >
> > > [...]
> > >
> > > > > o  Section 2.1
> > > > >
> > > > >   The text says:
> > > > >
> > > > >     It is out of the scope of this document
> > > > >     to identify [...] b) how event records are defined
> > > > >
> > > > >   Is this really what we want?  Shouldn't this document specify that
> > > > >   an event record is an instance of a YANG "notification" statement?
> > > > >   Do we want to support event records that are not defined in YANG?
> > > > >
> > > > >   This was discussed in the thread "comments on
> > > > >   draft-ietf-netconf-subscribed-notifications-12", and it seems that
> > > > >   noone really have any use case for non-YANG-defined event records,
> > > > >   accessed with YANG-defined operations.
> > > >
> > > > Yes this was discussed previously.  My reading was that others wanted
> > > > to support subscription to non-YANG events.
> > > > E.g., see Andy & Tianran's thoughts in
> > > > https://www.ietf.org/mail-archive/web/netconf/current/msg14764.html
> > >
> > > Yes, but read on in that thread, see
> > > https://www.ietf.org/mail-archive/web/netconf/current/msg14766.html
> > > for a clarification.
> > >
> > > AFAIK, noone has presented a use case for sending non-YANG-defined data
> > > here.
> >
> > As anything can be YANG wrapped, per the thread above.  I am fine with
> > this.
> >
> 
> 
> I think my concern was simply that I take notice any time anyone
> uses the term MUST in an I-D.  I ask myself "What harm to interoperability
> will result if this MUST is not followed?  If I cannot think of anything
> (as in this case) then MUST is probably a SHOULD instead.

As I wrote earlier in the thread, if this is supposed to work with any
(or just other?) DMLs, I think the document has to be explain how it
is supposed to work, and describe the requirements for such a DML.

One thing that would harm interoperability is the requirement to be
able to use multiple encodings; today both XML and JSON are defined,
maybe there will be more in the future.

> The use-case I have in mind -- protobuffs -- I don't see why it is
> important to
> require a YANG module for every .proto file. Even worse, why is the
> subscription draft making this requirement?

Can you describe this use case?  The SN doc simply says that the event
records that you can subscribe to and filter and apply NACM rules to
are defined using YANG's "notification" statement.


/martin



> 
> Andy
> 
> 
> 
> > > > >   I think that this document should state that an event record is an
> > > > >   instance of a YANG "notification" statement.  If not, it is unclear
> > > > >   both how subtree/xpath filters and xml/json/... encodings would
> > work.
> > > >
> > > > Applying xpath filters against XML based event records seems viable to
> > > > me.
> > >
> > > Where does it say that it has to be XML?  Whatabout mixed-content?
> > > What if such a notification is sent when the encoding is JSON?
> > >
> > > If you want to make this specification open for other data modeling
> > languages,
> > > I think you need to carefully define how that is supposed to work;
> > essentially
> > > similar to how we handle transports; we have a set of requirement on
> > what a
> > > transport document must define.  IMO this is super complicated and
> > overkill.
> > > This draft is complex enough.
> > > Don't add even more complexity.
> >
> > If you are just saying that we can put everything into a YANG wrapper,
> > that is fine with me.  To clarify this, I have tweaked the first sentence
> > of Section 2.1 to:
> > "An event stream is a named entity on a publisher which exposes a
> > continuously updating set of YANG encoded event records."
> >
> > And I have tweaked the first sentence of the third paragraph to:
> > "As YANG encoded event records are created by a system,..."
> >
> > > > Of course it will be up to the definition of any particular stream to
> > > > articulate the event record contents sufficiently for filters to be
> > > > created.
> > > >
> > > > > o  Section 2.1
> > > > >
> > > > >   The text says:
> > > > >
> > > > >     Among
> > > > >     these included NETCONF XML event records are individual YANG 1.1
> > > > >     notifications described in section 7.16 of [RFC7950].
> > > > >
> > > > >   First of all, does this mean that there can be event records on the
> > > > >   "NETCONF" stream that are *not* defined with a "notification"
> > > > >   statement?
> > > >
> > > > For the NETCONF stream, personally I only care about things YANG
> > > > notification statement.  But looking again at Andy's comment from:
> > > > https://www.ietf.org/mail-archive/web/netconf/current/msg14764.html
> > > > he says "I would say SHOULD be defined in YANG, for the "NETCONF"
> > > > stream."
> > >
> > > I strongly disagree.
> > >
> > > > So for -v16 I updated the text in a way that doesn't preclude this.
> > >
> > > See above.  If all events records are defined in YANG we can remove this.
> >
> > Per above, I have included text above so that YANG encapsulation is
> > required.  I think YANG Data should be an allowable structure (so I didn't
> > specify just a "Notification").  If you think that YANG Data should be
> > excluded from the allowed event records. I can refine the words.
> >
> > > > >   Second, this seems to imply that *all* notifications defined in all
> > > > >   YANG modules end up in the "NETCONF" stream, but I don't think this
> > > > >   is the intention.  At least I hope so.  ("yp:push-update" is an
> > > > >   example of a notification that will not be sent on the "NETCONF"
> > > > >   stream.)
> > > >
> > > > The NETCONF stream has a very broad/inclusive definition in RFC-5277.
> > > > This definition is: "This stream contains all NETCONF XML event
> > > > notifications supported by the NETCONF server".
> > >
> > > This is very underspecified.  IIRC the original intention was
> > notifications related
> > > to NETCONF, hence "*NETCONF* XML event notifications".
> > >
> > > > To me, thinking about how that statement and applying it to YANG, this
> > > > translates as YANG 1.1 notifications should go into the NETCONF
> > > > stream, unless explicitly excluded.
> > >
> > > I disagree.  This is not how 5277 works.  Until we have worked out a
> > useful way
> > > to assign notifications to streams, we shouldn't restrict anything in
> > this regard.
> >
> > Ok.  Effectively we are naming the stream NETCONF without improving the
> > definition of what membership in that stream should be.  And that is fine.
> > As people seem to understand what this is supposed to be, I will return to
> > the original definition.  See text, and let me know if you have issues.
> >
> > > > This provides a very simple way
> > > > determining which types of notifications should be placed on the
> > > > stream.  (Otherwise, how is a developer of a YANG notification
> > > > supposed to know whether it should go into the NETCONF stream or not?
> > >
> > > They don't.  But note that it might be an operator decision for how to
> > assign
> > > notifications to streams.
> >
> > Ok.  A stream membership definition is out-of-scope for all other streams,
> > we can leave it this way for the "NETCONF" stream.  Someone else can pick
> > up and define this in another draft the WG feels it necessary.
> >
> > > > The alternative would seem to be having each notification opt-in to
> > > > the NETCONF stream.)
> > > >
> > > > So if you agree with this reasoning, how about:
> > > >
> > > > The "NETCONF" event stream contains all instances of YANG 1.1
> > > > notifications generated by a publisher, except where a type of
> > > > notification has explicitly been excluded from the stream.
> > >
> > > I think that this document should keep the definition of the NETCONF
> > stream as
> > > defined in RFC 5277.
> >
> > Ok
> >
> > > Also, I think it should state that an event record is an instantiation
> > of a YANG
> > > "notification" statement (any version of YANG).
> >
> > What about a YANG Data?  (Per above)
> >
> > > [...]
> > >
> > > > > o  Section 2.4.2
> > > > >
> > > > >   The text says:
> > > > >
> > > > >     The transport selected by the subscriber
> > > > >     to reach the publisher MUST be able to support multiple
> > "establish-
> > > > >     subscription" requests made within the same transport session.
> > > > >
> > > > >   This seems to indicate that RESTCONF cannot be used with this
> > > > >   specification, since RESTCONF doesn't have sessions.
> > > >
> > > > The desired behavior is that a subscriber can request multiple
> > > > subscriptions without each requiring a separate transport session
> > > > establishment.  I think we are ok here with RESTCONF because
> > > > underneath RESTCONF is HTTP, TLS, TCP.  And each of those lower layers
> > > > can have sessions.
> > > >
> > > > To clarify further, I have tweaked the text to:
> > > >
> > > > "The transport selected by the subscriber to reach the publisher MUST
> > > > be able to support multiple "establish-subscription" requests without
> > > > each requiring a separate persistent transport connection."
> > > >
> > > > >   This makes me wonder, why does this document specify this
> > > > >   requirement?  I agree that this is the behaviour we want from
> > > > >   NETCONF, but then I think that should be defined in the
> > > > >   netconf-notif draft.
> > > >
> > > > By saying something in SN about this requirement, I believe we can
> > > > preclude an implementation which can only support one subscription per
> > > > subscriber.  In any case, the specific "how" details will still need
> > > > to be articulated in each transport draft.
> > >
> > > I think you are mixing the specification and implementation.  If a
> > transport
> > > document says that an implemention MUST support multiple subscriptions
> > per
> > > session (in a transport-specific way), then an implementation cannot just
> > > support a sinlge subscription.
> > >
> > > My point is that this a transport-specific requirement, and it doesn't
> > belong in
> > > this document.
> >
> > I can see why you don't see it applicable to Section 2.4.2.    However
> > Section 5.3 provides guidelines for transport document developers (this is
> > a section Kent requested.)  And so I have moved the requirement there.  Is
> > that sufficient.
> >
> > > > > o  Section 2.4.2
> > > > >
> > > > >   s/"start-time"/"replay-start-time"/  (3 occurrences)
> > > >
> > > > Fixed
> > > >
> > > > >   Also, the text says that the replay-start-time MUST be in the past.
> > > > >
> > > > >   Suppose the server receives a "replay-start-time" of 12:00:00.001,
> > > > >   and the replay buffer is empty.
> > > > >
> > > > >   A) If the current time is 12:00:00.002, the request is accepted,
> > and
> > > > >      a "replay-completed" notif is sent.
> > > > >
> > > > >   B) If the current time is 12:00:00.000, the request is rejected
> > with
> > > > >      an error.
> > > > >
> > > > >   Why is this important?  Why not simply just send the
> > > > >   replay-completed notif in both cases?
> > > >
> > > > For (B), if an event occurs at 12:00:00.0005, should it be sent?
> > > > Should it be sent before or after the "replay-start-time"?  How long
> > > > should we allow the clocks to drift before we reject the subscription?
> > > > As we don't support future/pending subscriptions, we don't have to
> > > > worry about these questions with the current definition.
> > >
> > > I would simply say that if the replay-start-time is later than any
> > buffered notif,
> > > then "replay-complete" is immediately sent.  It dont'
> > > matter if it is one microsecond or one year later.
> >
> > Tweaked the sentence:
> >
> > "If the given "replay-start-time" is later than the time marked within any
> > event records retained within the replay buffer, then the publisher MUST
> > send a "replay-completed" notification immediately after a successful
> > establish-subscription RPC response."
> >
> > > The problem otherwise is how to decide if something is "in the past".
> > > In the past when the client sent the request?  When the server parsed
> > the XML?
> > > When the instrumentation code runs?
> > >
> > > But this is not a big issue.
> >
> > Hopefully with the tweak, we can leave it as modified.
> >
> > [..]
> > > > > o  Section 2.4.6
> > > > >
> > > > >   The text says:
> > > > >
> > > > >     1.  "establish-subscription-stream-error-info": This MUST be
> > returned
> > > > >         if an RPC error reason has not been placed elsewhere within
> > the
> > > > >         transport portion of a failed "establish-subscription" RPC
> > > > >         response.
> > > > >
> > > > >   (and similar for the other errors)
> > > > >
> > > > >   What exactly does "if an RPC error reason has not been placed
> > > > >   elsewhere" mean?
> > > >
> > > > The intent is to match how NETCONF & RESTCONF historically handles
> > > > errors.  As you know with NETCONF, each error identity will be
> > > > inserted as the "error-app-tag".
> > >
> > > It could also be in "error-tag" and/or "error-message".  My point is
> > that I don't
> > > think that you mean that if an implementation populate say
> > "error-message",
> > > then it should not popluate error-info with
> > establish-subscription-stream-
> > > error-info.
> >
> > I do mean that.  I don't think we should send: "establish-subscription-stream-error-info"
> > for NETCONF when there is no hint included.  All the necessary error info
> > is already in the existing message.
> >
> > > > And therefore placing the YANG data
> > > > "establish-subscription-stream-error-info" would be redundant.  For
> > > > NETCONF, "establish-subscription-stream-error-info" are only needed
> > > > when hints to be provided.
> > > >
> > > > Therefore assuming you are looking for an alternative way to make this
> > > > point, I have tweaked the text to:
> > > > "This MUST be returned if an RPC error reason has not been mapped down
> > > > into transport specific error objects contained within a failed
> > > > "establish-subscription" RPC response."
> > >
> > > Howabout simply removing this sentence?
> >
> > Done
> >
> > > > > o  Section 2.5.1
> > > > >
> > > > >   In the second diagram (for the valid state), the states are called
> > > > >   "receiver connecting", "reciever timeout" etc.  I find this a bit
> > > > >   confusing; it is not the *receiver* that is connecting, it is the
> > > > >   publisher.  Ok, the legend then says:
> > > > >
> > > > >      dashed boxes which include the word 'receiver' show the possible
> > > > >      states for an individual receiver
> > > > >
> > > > >  But since all dashed boxes include the word "receiver", and the
> > > > > diagram specifically is the state machine *per receiver*, maybe we
> > > > > can simply remove the word "receiver" from the boxes?
> > > >
> > > > There have been some discussions on this.  I agree it is certainly
> > > > valid to remove "receiver" from these four boxes.  However I have
> > > > found that getting readers to really internalize that the state
> > > > machine is actually per-receiver rather than per-subscription, it
> > > > seems to go faster/cleaner when receiver is shown in the four boxes.
> > > >
> > > > Nevertheless, if you absolutely want "receiver" removed from the
> > > > boxes, I can do that.
> > >
> > > Maybe you can remove receiver from the individual boxes and then change
> > the
> > > word "valid" from the outer box to "per-receiver state machine"?
> > >
> > > Or maybe remove the outer box and add a Figure title: 'per-receiver state
> > > machine for the subscription's "valid" state'
> > >
> > > Also not a big deal, but I found it confusing.
> >
> > All are viable.  But I have found the current diagram useable. Do you have
> > a major issue if we leave it as it is?
> >
> > > [...]
> > >
> > > > > o  Section 2.5.6
> > > > >
> > > > >   I know that this feature was presented in Montreal.  I think it is
> > > > >   problematic, and suggest it is removed.
> > > >
> > > > This issue was discussed in Montreal.  The feature is of course is
> > > > optional.  There are a large number of downsides for someone who
> > > > chooses not to implement for certain use cases.  Please see the
> > > > Montreal slides and the long threads with Kent for more details.
> > >
> > > I did watch the Montreal session, but I didn't see any discussion on
> > > this issue (just your presentation).   Can you send a pointer to the
> > > email thread with Kent?
> >
> > Some minutes on the topic can be seen at:
> > https://datatracker.ietf.org/doc/minutes-102-netconf/
> > With the WG vote in Montreal, I would love not to re-open.
> >
> > The previous exchange was long.  Some items include:
> > https://www.ietf.org/mail-archive/web/netconf/current/msg14575.html
> > https://www.ietf.org/mail-archive/web/netconf/current/msg14902.html
> >
> > > > If
> > > > you want to pursue this further it is probably best to start a new
> > > > thread dedicated to this topic alone.
> > > >
> > > > >   For example, what happens if the transport session is lost and
> > > > >   re-established; are all event records in the buffer replayed again?
> > > >
> > > > No.  The publisher will not lose context of what was sent.
> > >
> > > This is not clear from the text.  In fact, the text explicitly says:
> > >
> > >    The leading event record sent will be the first event record
> > >    subsequent to the latest of three different times: the
> > >    "replay-log-creation-time", "replay-log-aged- time", or the most
> > >    recent publisher boot time.
> >
> > I see your point.   I have tweaked the text to:
> >
> > " If the publisher does not know the next record intended for the
> > receiver, the leading event record..."
> >
> > I have also made a corresponding tweak to the YANG model.
> >
> > > > >   What happens if a new receiver is added to a subscription that
> > > > >   already has a receiver, will all events in the buffer be replayed
> > to
> > > > >   the new receiver?
> > > >
> > > > Yes.  (To clarify, I added "to each configured receiver" at the end of
> > > > the last sentence of the first paragraph.)
> > > >
> > > > >   When a new subscription is configured with configured-replay set,
> > > > >   the publisher will immediately try to connect to the publisher and
> > > > >   send all buffered event from the last reboot.  Is this really
> > > > >   useful?
> > > >
> > > > Yes.  See the security cases reviewed on the earlier threads with
> > > > Kent.  If someone doesn't care about log entries since boot, they
> > > > simply don't have to implement this optional feature.
> > > >
> > > > >   If the mechansim relies on the subscriber being able to also use
> > > > >   dynamic subscriptions for replay of all event records, maybe we
> > > > >   could simplify things by always relying on dynamic subscriptions
> > for
> > > > >   replay for configured subscriptions.  Specifically, remove
> > > > >   "configured-replay" etc, but keep the "replay-previous-event-time"
> > > > >   in the "subscription-started" notification.  Then a subscriber can
> > > > >   simply check this value to see if anything is missing, and if it
> > is,
> > > > >   use a dynamic subscription to request replay from the latest time
> > he
> > > > >   knows about.
> > > >
> > > > This is a valid approach, and can be used as an alternative to this
> > > > optional feature.  However there are still many downsides to the
> > > > alternative.  See the slides from Montreal, as well as the previous
> > > > thread discussions for details.
> > > >
> > > > > o  Section 2.6
> > > > >
> > > > >   It just occurred to me that this text about using the
> > 
> > > > >   message shouldn't be in this document, but in the netconf-notif
> > (and
> > > > >   restconf-notif) document.  It is highly transport and encoding
> > > > >   specific.
> > > >
> > > > I think you are referring to both the sentence: "This notification
> > > > message MUST be encoded in a  message as defined within
> > > > [RFC5277], Section 4.  And per [RFC5277]'s "eventTime" object
> > > > definition, the "eventTime" is populated with the event occurrence
> > > > time."  As well as to the example compliant message in Figure 10.
> > > >
> > > > While the text could be extracted and placed in the netconf-notif
> > > > document, extracting it fully from SN would leave no baseline message
> > > > format.
> > >
> > > Things like this are inevitable when you have a transport-independent
> > > specification.  Of course, you can require that all transports MUST use
> > the 5277
> > > spec of a notification.  But then I think you rule out transports like
> > CoMI and
> > > possibly other future binary protocols.
> >
> > Ok, I am fine with the move.  I have moved the identified text to
> > NETCONF-Notif.  (Actually the text was already there too.  So I just
> > tweaked it.)
> >
> > Thanks,
> > Eric
> >
> > > > Perhaps others will have a problem if the SN solution does not have
> > > > some pre-defined structure to hold event records?
> > > >
> > > > I can move this if I hear no objection.  As you know, I am hoping that
> > > > draft-ietf-netconf-notification-messages at some point displaces the
> > > >  message of [RFC5277], Section 4.  And this is easier to
> > > > do with fewer references to RFC5277 within SN.
> > >
> > > [...]
> > > /martin
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >


From nobody Wed Sep 12 13:37:15 2018
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 B96DC130EC8; Wed, 12 Sep 2018 13:37:06 -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.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <153678462671.9493.3644504329179402450@ietfa.amsl.com>
Date: Wed, 12 Sep 2018 13:37:06 -0700
Archived-At: 
Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-notif-07.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 20:37:08 -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 Transport for Event Notifications
        Authors         : Eric Voit
                          Reshad Rahman
                          Einar Nilsen-Nygaard
                          Alexander Clemm
                          Andy Bierman
	Filename        : draft-ietf-netconf-restconf-notif-07.txt
	Pages           : 25
	Date            : 2018-09-12

Abstract:
   This document defines a RESTCONF binding to the dynamic subscription
   capability of both subscribed notifications and YANG-Push.
   Subscriptions to publisher defined event streams or nodes/subtrees of
   YANG Datastores is supported.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-notif-07


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

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


From nobody Wed Sep 12 13:50:14 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DEF130DFA for ; Wed, 12 Sep 2018 13:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-0.01] 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 t8kTq-IVTR5O for ; Wed, 12 Sep 2018 13:50:06 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45991292F1 for ; Wed, 12 Sep 2018 13:50:05 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id h64-v6so2892287lfi.10 for ; Wed, 12 Sep 2018 13:50:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qyQu6Q4E0yQ3vbZy55Vx8B6S6/72iGbmlk0Os1ORbWQ=; b=pE2W0ey8CETQT+3cuhpMebAYRhl0IOLEF6S7ifOqsHjLwSckkZkLqhlBFFdUIxToMi Mpg/jTy15unES3oPe0ouYbevmpkVslCsYSKe04q8/x2dkNESfTgcM0aOSu0ZgqK/0aUL LzDCLhQ5xowXAzTwLr06OHKDt1pK+4dav9eBzzB7mJOI4/KtlyTQiHIRDNKFlPEGh5hA Y7wdlxJOZqaQXwtrJgFhuXSsGXh95TqEsY7ZjXtVaPtRTaancBbLQtPir12P0CHyF9Vr SpH4b3WuDsYCFc83lGEaYIVbUV7H3WFC6HifXpCUnA5qbZ/rZ7rEwkcig4NSSQA671G8 Rrig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qyQu6Q4E0yQ3vbZy55Vx8B6S6/72iGbmlk0Os1ORbWQ=; b=V2FPrXgaMrJqRK3egHu5A+JwXejeUQUfX77Hvzzs4BAukaR8mgoqCNhKnEArnj6ejE LLJQyo/JX1w17bGi8jP57LeY9hjdpkhxQxxQ3fn0q2GP8KR/J2Q9pM8oVF/TSMl4Vi+5 IFp5r1cfrhoCrq9C7y8X9Nv1u0wXutBpbx45pwhHn48PFD/13+zg2rVGfat66vDJhvyN 4kAdV+O3jBwgHLrYqyhZZV+BqZuSMfTfYEZOUONEfEyDae/Gtu1TCGtRPNLA4UG8I5jg K2L/WfRhV7x7K2uOjQfec0Z3xef/7o6y9tu1H/HLNHo7AYP4/IO7/PnAxw80lgJidL1C ysdg==
X-Gm-Message-State: APzg51DSZHEa+mcF4dm5ZateEAKTNvZFajobimc7PME3fJyePjbnXK9L vbN4WQ3isIqftjOgSCMyYZ0fRGp3cnh6M0HTAZdWKQ==
X-Google-Smtp-Source: ANB0VdZh9ydSOrqurbe8yNpngAsV31PFbDt0d9sNuNqs/Kvt+VsYOCFZPG65oy03yph5k8vQ2KjmzQe4++6EY4k2vJs=
X-Received: by 2002:a19:2d16:: with SMTP id k22-v6mr2708223lfj.67.1536785403549;  Wed, 12 Sep 2018 13:50:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:48c9:0:0:0:0:0 with HTTP; Wed, 12 Sep 2018 13:50:02 -0700 (PDT)
In-Reply-To: <20180912.220805.1931099349419935246.mbj@tail-f.com>
References: <20180912.113446.2017030234338816835.mbj@tail-f.com> <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com>  <20180912.220805.1931099349419935246.mbj@tail-f.com>
From: Andy Bierman 
Date: Wed, 12 Sep 2018 13:50:02 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: "Eric Voit (evoit)" , Netconf 
Content-Type: multipart/alternative; boundary="0000000000001331570575b2bc61"
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2018 20:50:12 -0000

--0000000000001331570575b2bc61
Content-Type: text/plain; charset="UTF-8"

On Wed, Sep 12, 2018 at 1:08 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Wed, Sep 12, 2018 at 11:35 AM, Eric Voit (evoit) <
> > evoit=40cisco.com@dmarc.ietf.org> wrote:
> >
> > > Hi Martin,
> > >
> > > Much incorporated.  Latest is at:
> > > https://github.com/netconf-wg/rfc5277bis/blob/master/draft-
> > > ietf-netconf-subscribed-notifications-17.txt
> > >
> > > Specific responses in-line...
> > >
> > > > From: Martin Bjorklund, September 12, 2018 5:35 AM
> > > >
> > > > "Eric Voit (evoit)"  wrote:
> > > > > Thanks for the comments Martin,  thoughts in-line...
> > > > >
> > > > > > From: Martin Bjorklund, September 10, 2018 1:42 PM
> > > >
> > > > [...]
> > > >
> > > > > > o  Section 2.1
> > > > > >
> > > > > >   The text says:
> > > > > >
> > > > > >     It is out of the scope of this document
> > > > > >     to identify [...] b) how event records are defined
> > > > > >
> > > > > >   Is this really what we want?  Shouldn't this document specify
> that
> > > > > >   an event record is an instance of a YANG "notification"
> statement?
> > > > > >   Do we want to support event records that are not defined in
> YANG?
> > > > > >
> > > > > >   This was discussed in the thread "comments on
> > > > > >   draft-ietf-netconf-subscribed-notifications-12", and it seems
> that
> > > > > >   noone really have any use case for non-YANG-defined event
> records,
> > > > > >   accessed with YANG-defined operations.
> > > > >
> > > > > Yes this was discussed previously.  My reading was that others
> wanted
> > > > > to support subscription to non-YANG events.
> > > > > E.g., see Andy & Tianran's thoughts in
> > > > > https://www.ietf.org/mail-archive/web/netconf/current/
> msg14764.html
> > > >
> > > > Yes, but read on in that thread, see
> > > > https://www.ietf.org/mail-archive/web/netconf/current/msg14766.html
> > > > for a clarification.
> > > >
> > > > AFAIK, noone has presented a use case for sending non-YANG-defined
> data
> > > > here.
> > >
> > > As anything can be YANG wrapped, per the thread above.  I am fine with
> > > this.
> > >
> >
> >
> > I think my concern was simply that I take notice any time anyone
> > uses the term MUST in an I-D.  I ask myself "What harm to
> interoperability
> > will result if this MUST is not followed?  If I cannot think of anything
> > (as in this case) then MUST is probably a SHOULD instead.
>
> As I wrote earlier in the thread, if this is supposed to work with any
> (or just other?) DMLs, I think the document has to be explain how it
> is supposed to work, and describe the requirements for such a DML.
>
> One thing that would harm interoperability is the requirement to be
> able to use multiple encodings; today both XML and JSON are defined,
> maybe there will be more in the future.
>
> > The use-case I have in mind -- protobuffs -- I don't see why it is
> > important to
> > require a YANG module for every .proto file. Even worse, why is the
> > subscription draft making this requirement?
>
> Can you describe this use case?  The SN doc simply says that the event
> records that you can subscribe to and filter and apply NACM rules to
> are defined using YANG's "notification" statement.
>
>

I don't have any real objection to the requirement, since it is
unenforceable anyway.
One can easily construct a YANG model using an empty container or "anydata"
as a wrapper.



>
> /martin
>
>

Andy


>
>
> >
> > Andy
> >
> >
> >
> > > > > >   I think that this document should state that an event record
> is an
> > > > > >   instance of a YANG "notification" statement.  If not, it is
> unclear
> > > > > >   both how subtree/xpath filters and xml/json/... encodings would
> > > work.
> > > > >
> > > > > Applying xpath filters against XML based event records seems
> viable to
> > > > > me.
> > > >
> > > > Where does it say that it has to be XML?  Whatabout mixed-content?
> > > > What if such a notification is sent when the encoding is JSON?
> > > >
> > > > If you want to make this specification open for other data modeling
> > > languages,
> > > > I think you need to carefully define how that is supposed to work;
> > > essentially
> > > > similar to how we handle transports; we have a set of requirement on
> > > what a
> > > > transport document must define.  IMO this is super complicated and
> > > overkill.
> > > > This draft is complex enough.
> > > > Don't add even more complexity.
> > >
> > > If you are just saying that we can put everything into a YANG wrapper,
> > > that is fine with me.  To clarify this, I have tweaked the first
> sentence
> > > of Section 2.1 to:
> > > "An event stream is a named entity on a publisher which exposes a
> > > continuously updating set of YANG encoded event records."
> > >
> > > And I have tweaked the first sentence of the third paragraph to:
> > > "As YANG encoded event records are created by a system,..."
> > >
> > > > > Of course it will be up to the definition of any particular stream
> to
> > > > > articulate the event record contents sufficiently for filters to be
> > > > > created.
> > > > >
> > > > > > o  Section 2.1
> > > > > >
> > > > > >   The text says:
> > > > > >
> > > > > >     Among
> > > > > >     these included NETCONF XML event records are individual YANG
> 1.1
> > > > > >     notifications described in section 7.16 of [RFC7950].
> > > > > >
> > > > > >   First of all, does this mean that there can be event records
> on the
> > > > > >   "NETCONF" stream that are *not* defined with a "notification"
> > > > > >   statement?
> > > > >
> > > > > For the NETCONF stream, personally I only care about things YANG
> > > > > notification statement.  But looking again at Andy's comment from:
> > > > > https://www.ietf.org/mail-archive/web/netconf/current/
> msg14764.html
> > > > > he says "I would say SHOULD be defined in YANG, for the "NETCONF"
> > > > > stream."
> > > >
> > > > I strongly disagree.
> > > >
> > > > > So for -v16 I updated the text in a way that doesn't preclude this.
> > > >
> > > > See above.  If all events records are defined in YANG we can remove
> this.
> > >
> > > Per above, I have included text above so that YANG encapsulation is
> > > required.  I think YANG Data should be an allowable structure (so I
> didn't
> > > specify just a "Notification").  If you think that YANG Data should be
> > > excluded from the allowed event records. I can refine the words.
> > >
> > > > > >   Second, this seems to imply that *all* notifications defined
> in all
> > > > > >   YANG modules end up in the "NETCONF" stream, but I don't think
> this
> > > > > >   is the intention.  At least I hope so.  ("yp:push-update" is an
> > > > > >   example of a notification that will not be sent on the
> "NETCONF"
> > > > > >   stream.)
> > > > >
> > > > > The NETCONF stream has a very broad/inclusive definition in
> RFC-5277.
> > > > > This definition is: "This stream contains all NETCONF XML event
> > > > > notifications supported by the NETCONF server".
> > > >
> > > > This is very underspecified.  IIRC the original intention was
> > > notifications related
> > > > to NETCONF, hence "*NETCONF* XML event notifications".
> > > >
> > > > > To me, thinking about how that statement and applying it to YANG,
> this
> > > > > translates as YANG 1.1 notifications should go into the NETCONF
> > > > > stream, unless explicitly excluded.
> > > >
> > > > I disagree.  This is not how 5277 works.  Until we have worked out a
> > > useful way
> > > > to assign notifications to streams, we shouldn't restrict anything in
> > > this regard.
> > >
> > > Ok.  Effectively we are naming the stream NETCONF without improving the
> > > definition of what membership in that stream should be.  And that is
> fine.
> > > As people seem to understand what this is supposed to be, I will
> return to
> > > the original definition.  See text, and let me know if you have issues.
> > >
> > > > > This provides a very simple way
> > > > > determining which types of notifications should be placed on the
> > > > > stream.  (Otherwise, how is a developer of a YANG notification
> > > > > supposed to know whether it should go into the NETCONF stream or
> not?
> > > >
> > > > They don't.  But note that it might be an operator decision for how
> to
> > > assign
> > > > notifications to streams.
> > >
> > > Ok.  A stream membership definition is out-of-scope for all other
> streams,
> > > we can leave it this way for the "NETCONF" stream.  Someone else can
> pick
> > > up and define this in another draft the WG feels it necessary.
> > >
> > > > > The alternative would seem to be having each notification opt-in to
> > > > > the NETCONF stream.)
> > > > >
> > > > > So if you agree with this reasoning, how about:
> > > > >
> > > > > The "NETCONF" event stream contains all instances of YANG 1.1
> > > > > notifications generated by a publisher, except where a type of
> > > > > notification has explicitly been excluded from the stream.
> > > >
> > > > I think that this document should keep the definition of the NETCONF
> > > stream as
> > > > defined in RFC 5277.
> > >
> > > Ok
> > >
> > > > Also, I think it should state that an event record is an
> instantiation
> > > of a YANG
> > > > "notification" statement (any version of YANG).
> > >
> > > What about a YANG Data?  (Per above)
> > >
> > > > [...]
> > > >
> > > > > > o  Section 2.4.2
> > > > > >
> > > > > >   The text says:
> > > > > >
> > > > > >     The transport selected by the subscriber
> > > > > >     to reach the publisher MUST be able to support multiple
> > > "establish-
> > > > > >     subscription" requests made within the same transport
> session.
> > > > > >
> > > > > >   This seems to indicate that RESTCONF cannot be used with this
> > > > > >   specification, since RESTCONF doesn't have sessions.
> > > > >
> > > > > The desired behavior is that a subscriber can request multiple
> > > > > subscriptions without each requiring a separate transport session
> > > > > establishment.  I think we are ok here with RESTCONF because
> > > > > underneath RESTCONF is HTTP, TLS, TCP.  And each of those lower
> layers
> > > > > can have sessions.
> > > > >
> > > > > To clarify further, I have tweaked the text to:
> > > > >
> > > > > "The transport selected by the subscriber to reach the publisher
> MUST
> > > > > be able to support multiple "establish-subscription" requests
> without
> > > > > each requiring a separate persistent transport connection."
> > > > >
> > > > > >   This makes me wonder, why does this document specify this
> > > > > >   requirement?  I agree that this is the behaviour we want from
> > > > > >   NETCONF, but then I think that should be defined in the
> > > > > >   netconf-notif draft.
> > > > >
> > > > > By saying something in SN about this requirement, I believe we can
> > > > > preclude an implementation which can only support one subscription
> per
> > > > > subscriber.  In any case, the specific "how" details will still
> need
> > > > > to be articulated in each transport draft.
> > > >
> > > > I think you are mixing the specification and implementation.  If a
> > > transport
> > > > document says that an implemention MUST support multiple
> subscriptions
> > > per
> > > > session (in a transport-specific way), then an implementation cannot
> just
> > > > support a sinlge subscription.
> > > >
> > > > My point is that this a transport-specific requirement, and it
> doesn't
> > > belong in
> > > > this document.
> > >
> > > I can see why you don't see it applicable to Section 2.4.2.    However
> > > Section 5.3 provides guidelines for transport document developers
> (this is
> > > a section Kent requested.)  And so I have moved the requirement
> there.  Is
> > > that sufficient.
> > >
> > > > > > o  Section 2.4.2
> > > > > >
> > > > > >   s/"start-time"/"replay-start-time"/  (3 occurrences)
> > > > >
> > > > > Fixed
> > > > >
> > > > > >   Also, the text says that the replay-start-time MUST be in the
> past.
> > > > > >
> > > > > >   Suppose the server receives a "replay-start-time" of
> 12:00:00.001,
> > > > > >   and the replay buffer is empty.
> > > > > >
> > > > > >   A) If the current time is 12:00:00.002, the request is
> accepted,
> > > and
> > > > > >      a "replay-completed" notif is sent.
> > > > > >
> > > > > >   B) If the current time is 12:00:00.000, the request is rejected
> > > with
> > > > > >      an error.
> > > > > >
> > > > > >   Why is this important?  Why not simply just send the
> > > > > >   replay-completed notif in both cases?
> > > > >
> > > > > For (B), if an event occurs at 12:00:00.0005, should it be sent?
> > > > > Should it be sent before or after the "replay-start-time"?  How
> long
> > > > > should we allow the clocks to drift before we reject the
> subscription?
> > > > > As we don't support future/pending subscriptions, we don't have to
> > > > > worry about these questions with the current definition.
> > > >
> > > > I would simply say that if the replay-start-time is later than any
> > > buffered notif,
> > > > then "replay-complete" is immediately sent.  It dont'
> > > > matter if it is one microsecond or one year later.
> > >
> > > Tweaked the sentence:
> > >
> > > "If the given "replay-start-time" is later than the time marked within
> any
> > > event records retained within the replay buffer, then the publisher
> MUST
> > > send a "replay-completed" notification immediately after a successful
> > > establish-subscription RPC response."
> > >
> > > > The problem otherwise is how to decide if something is "in the past".
> > > > In the past when the client sent the request?  When the server parsed
> > > the XML?
> > > > When the instrumentation code runs?
> > > >
> > > > But this is not a big issue.
> > >
> > > Hopefully with the tweak, we can leave it as modified.
> > >
> > > [..]
> > > > > > o  Section 2.4.6
> > > > > >
> > > > > >   The text says:
> > > > > >
> > > > > >     1.  "establish-subscription-stream-error-info": This MUST be
> > > returned
> > > > > >         if an RPC error reason has not been placed elsewhere
> within
> > > the
> > > > > >         transport portion of a failed "establish-subscription"
> RPC
> > > > > >         response.
> > > > > >
> > > > > >   (and similar for the other errors)
> > > > > >
> > > > > >   What exactly does "if an RPC error reason has not been placed
> > > > > >   elsewhere" mean?
> > > > >
> > > > > The intent is to match how NETCONF & RESTCONF historically handles
> > > > > errors.  As you know with NETCONF, each error identity will be
> > > > > inserted as the "error-app-tag".
> > > >
> > > > It could also be in "error-tag" and/or "error-message".  My point is
> > > that I don't
> > > > think that you mean that if an implementation populate say
> > > "error-message",
> > > > then it should not popluate error-info with
> > > establish-subscription-stream-
> > > > error-info.
> > >
> > > I do mean that.  I don't think we should send: "establish-subscription-
> stream-error-info"
> > > for NETCONF when there is no hint included.  All the necessary error
> info
> > > is already in the existing message.
> > >
> > > > > And therefore placing the YANG data
> > > > > "establish-subscription-stream-error-info" would be redundant.
> For
> > > > > NETCONF, "establish-subscription-stream-error-info" are only
> needed
> > > > > when hints to be provided.
> > > > >
> > > > > Therefore assuming you are looking for an alternative way to make
> this
> > > > > point, I have tweaked the text to:
> > > > > "This MUST be returned if an RPC error reason has not been mapped
> down
> > > > > into transport specific error objects contained within a failed
> > > > > "establish-subscription" RPC response."
> > > >
> > > > Howabout simply removing this sentence?
> > >
> > > Done
> > >
> > > > > > o  Section 2.5.1
> > > > > >
> > > > > >   In the second diagram (for the valid state), the states are
> called
> > > > > >   "receiver connecting", "reciever timeout" etc.  I find this a
> bit
> > > > > >   confusing; it is not the *receiver* that is connecting, it is
> the
> > > > > >   publisher.  Ok, the legend then says:
> > > > > >
> > > > > >      dashed boxes which include the word 'receiver' show the
> possible
> > > > > >      states for an individual receiver
> > > > > >
> > > > > >  But since all dashed boxes include the word "receiver", and the
> > > > > > diagram specifically is the state machine *per receiver*, maybe
> we
> > > > > > can simply remove the word "receiver" from the boxes?
> > > > >
> > > > > There have been some discussions on this.  I agree it is certainly
> > > > > valid to remove "receiver" from these four boxes.  However I have
> > > > > found that getting readers to really internalize that the state
> > > > > machine is actually per-receiver rather than per-subscription, it
> > > > > seems to go faster/cleaner when receiver is shown in the four
> boxes.
> > > > >
> > > > > Nevertheless, if you absolutely want "receiver" removed from the
> > > > > boxes, I can do that.
> > > >
> > > > Maybe you can remove receiver from the individual boxes and then
> change
> > > the
> > > > word "valid" from the outer box to "per-receiver state machine"?
> > > >
> > > > Or maybe remove the outer box and add a Figure title: 'per-receiver
> state
> > > > machine for the subscription's "valid" state'
> > > >
> > > > Also not a big deal, but I found it confusing.
> > >
> > > All are viable.  But I have found the current diagram useable. Do you
> have
> > > a major issue if we leave it as it is?
> > >
> > > > [...]
> > > >
> > > > > > o  Section 2.5.6
> > > > > >
> > > > > >   I know that this feature was presented in Montreal.  I think
> it is
> > > > > >   problematic, and suggest it is removed.
> > > > >
> > > > > This issue was discussed in Montreal.  The feature is of course is
> > > > > optional.  There are a large number of downsides for someone who
> > > > > chooses not to implement for certain use cases.  Please see the
> > > > > Montreal slides and the long threads with Kent for more details.
> > > >
> > > > I did watch the Montreal session, but I didn't see any discussion on
> > > > this issue (just your presentation).   Can you send a pointer to the
> > > > email thread with Kent?
> > >
> > > Some minutes on the topic can be seen at:
> > > https://datatracker.ietf.org/doc/minutes-102-netconf/
> > > With the WG vote in Montreal, I would love not to re-open.
> > >
> > > The previous exchange was long.  Some items include:
> > > https://www.ietf.org/mail-archive/web/netconf/current/msg14575.html
> > > https://www.ietf.org/mail-archive/web/netconf/current/msg14902.html
> > >
> > > > > If
> > > > > you want to pursue this further it is probably best to start a new
> > > > > thread dedicated to this topic alone.
> > > > >
> > > > > >   For example, what happens if the transport session is lost and
> > > > > >   re-established; are all event records in the buffer replayed
> again?
> > > > >
> > > > > No.  The publisher will not lose context of what was sent.
> > > >
> > > > This is not clear from the text.  In fact, the text explicitly says:
> > > >
> > > >    The leading event record sent will be the first event record
> > > >    subsequent to the latest of three different times: the
> > > >    "replay-log-creation-time", "replay-log-aged- time", or the most
> > > >    recent publisher boot time.
> > >
> > > I see your point.   I have tweaked the text to:
> > >
> > > " If the publisher does not know the next record intended for the
> > > receiver, the leading event record..."
> > >
> > > I have also made a corresponding tweak to the YANG model.
> > >
> > > > > >   What happens if a new receiver is added to a subscription that
> > > > > >   already has a receiver, will all events in the buffer be
> replayed
> > > to
> > > > > >   the new receiver?
> > > > >
> > > > > Yes.  (To clarify, I added "to each configured receiver" at the
> end of
> > > > > the last sentence of the first paragraph.)
> > > > >
> > > > > >   When a new subscription is configured with configured-replay
> set,
> > > > > >   the publisher will immediately try to connect to the publisher
> and
> > > > > >   send all buffered event from the last reboot.  Is this really
> > > > > >   useful?
> > > > >
> > > > > Yes.  See the security cases reviewed on the earlier threads with
> > > > > Kent.  If someone doesn't care about log entries since boot, they
> > > > > simply don't have to implement this optional feature.
> > > > >
> > > > > >   If the mechansim relies on the subscriber being able to also
> use
> > > > > >   dynamic subscriptions for replay of all event records, maybe we
> > > > > >   could simplify things by always relying on dynamic
> subscriptions
> > > for
> > > > > >   replay for configured subscriptions.  Specifically, remove
> > > > > >   "configured-replay" etc, but keep the
> "replay-previous-event-time"
> > > > > >   in the "subscription-started" notification.  Then a subscriber
> can
> > > > > >   simply check this value to see if anything is missing, and if
> it
> > > is,
> > > > > >   use a dynamic subscription to request replay from the latest
> time
> > > he
> > > > > >   knows about.
> > > > >
> > > > > This is a valid approach, and can be used as an alternative to this
> > > > > optional feature.  However there are still many downsides to the
> > > > > alternative.  See the slides from Montreal, as well as the previous
> > > > > thread discussions for details.
> > > > >
> > > > > > o  Section 2.6
> > > > > >
> > > > > >   It just occurred to me that this text about using the
> > > 
> > > > > >   message shouldn't be in this document, but in the netconf-notif
> > > (and
> > > > > >   restconf-notif) document.  It is highly transport and encoding
> > > > > >   specific.
> > > > >
> > > > > I think you are referring to both the sentence: "This notification
> > > > > message MUST be encoded in a  message as defined
> within
> > > > > [RFC5277], Section 4.  And per [RFC5277]'s "eventTime" object
> > > > > definition, the "eventTime" is populated with the event occurrence
> > > > > time."  As well as to the example compliant message in Figure 10.
> > > > >
> > > > > While the text could be extracted and placed in the netconf-notif
> > > > > document, extracting it fully from SN would leave no baseline
> message
> > > > > format.
> > > >
> > > > Things like this are inevitable when you have a transport-independent
> > > > specification.  Of course, you can require that all transports MUST
> use
> > > the 5277
> > > > spec of a notification.  But then I think you rule out transports
> like
> > > CoMI and
> > > > possibly other future binary protocols.
> > >
> > > Ok, I am fine with the move.  I have moved the identified text to
> > > NETCONF-Notif.  (Actually the text was already there too.  So I just
> > > tweaked it.)
> > >
> > > Thanks,
> > > Eric
> > >
> > > > > Perhaps others will have a problem if the SN solution does not have
> > > > > some pre-defined structure to hold event records?
> > > > >
> > > > > I can move this if I hear no objection.  As you know, I am hoping
> that
> > > > > draft-ietf-netconf-notification-messages at some point displaces
> the
> > > > >  message of [RFC5277], Section 4.  And this is
> easier to
> > > > > do with fewer references to RFC5277 within SN.
> > > >
> > > > [...]
> > > > /martin
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
>

--0000000000001331570575b2bc61
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Sep 12, 2018 at 1:08 PM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> On Wed, Sep 12, 2018 at 11:35 AM, Eric Voit (evoit) <

> evoit=3D40cisco.com@dmar=
c.ietf.org> wrote:

> 

> > Hi Martin,

> >

> > Much incorporated.=C2=A0 Latest is at:

> > https://github.com/netconf-wg/<=
wbr>rfc5277bis/blob/master/draft-

> > ietf-netconf-subscribed-notifications-17.txt

> >

> > Specific responses in-line...

> >

> > > From: Martin Bjorklund, September 12, 2018 5:35 AM

> > >

> > > "Eric Voit (evoit)" <evoit@cisco.com> wrote:

> > > > Thanks for the comments Martin,=C2=A0 thoughts in-line.=
..

> > > >

> > > > > From: Martin Bjorklund, September 10, 2018 1:42 PM=


> > >

> > > [...]

> > >

> > > > > o=C2=A0 Section 2.1

> > > > >

> > > > >=C2=A0 =C2=A0The text says:

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0It is out of the scope of this =
document

> > > > >=C2=A0 =C2=A0 =C2=A0to identify [...] b) how event =
records are defined

> > > > >

> > > > >=C2=A0 =C2=A0Is this really what we want?=C2=A0 Sho=
uldn't this document specify that

> > > > >=C2=A0 =C2=A0an event record is an instance of a YA=
NG "notification" statement?

> > > > >=C2=A0 =C2=A0Do we want to support event records th=
at are not defined in YANG?

> > > > >

> > > > >=C2=A0 =C2=A0This was discussed in the thread "=
;comments on

> > > > >=C2=A0 =C2=A0draft-ietf-netconf-subscribed-not=
ifications-12", and it seems that

> > > > >=C2=A0 =C2=A0noone really have any use case for non=
-YANG-defined event records,

> > > > >=C2=A0 =C2=A0accessed with YANG-defined operations.=


> > > >

> > > > Yes this was discussed previously.=C2=A0 My reading was=
 that others wanted

> > > > to support subscription to non-YANG events.

> > > > E.g., see Andy & Tianran's thoughts in

> > > > https://www.i=
etf.org/mail-archive/web/netconf/current/msg14764.html

> > >

> > > Yes, but read on in that thread, see

> > > https://www.ietf.o=
rg/mail-archive/web/netconf/current/msg14766.html

> > > for a clarification.

> > >

> > > AFAIK, noone has presented a use case for sending non-YANG-d=
efined data

> > > here.

> >

> > As anything can be YANG wrapped, per the thread above.=C2=A0 I am=
 fine with

> > this.

> >

> 

> 

> I think my concern was simply that I take notice any time anyone

> uses the term MUST in an I-D.=C2=A0 I ask myself "What harm to in=
teroperability

> will result if this MUST is not followed?=C2=A0 If I cannot think of a=
nything

> (as in this case) then MUST is probably a SHOULD instead.



As I wrote earlier in the thread, if this is supposed to work with any

(or just other?) DMLs, I think the document has to be explain how it

is supposed to work, and describe the requirements for such a DML.



One thing that would harm interoperability is the requirement to be

able to use multiple encodings; today both XML and JSON are defined,

maybe there will be more in the future.



> The use-case I have in mind -- protobuffs -- I don't see why it is=


> important to

> require a YANG module for every .proto file. Even worse, why is the
> subscription draft making this requirement?



Can you describe this use case?=C2=A0 The SN doc simply says that the event=


records that you can subscribe to and filter and apply NACM rules to

are defined using YANG's "notification" statement.




I don't have any re=
al objection to the requirement, since it is unenforceable anyway.
One can easily construct a YANG model using an empty container or "a=
nydata" as a wrapper.

=C2=A0



/martin




Andy
=C2=A0





> 

> Andy

> 

> 

> 

> > > > >=C2=A0 =C2=A0I think that this document should stat=
e that an event record is an

> > > > >=C2=A0 =C2=A0instance of a YANG "notification&=
quot; statement.=C2=A0 If not, it is unclear

> > > > >=C2=A0 =C2=A0both how subtree/xpath filters and xml=
/json/... encodings would

> > work.

> > > >

> > > > Applying xpath filters against XML based event records =
seems viable to

> > > > me.

> > >

> > > Where does it say that it has to be XML?=C2=A0 Whatabout mix=
ed-content?

> > > What if such a notification is sent when the encoding is JSO=
N?

> > >

> > > If you want to make this specification open for other data m=
odeling

> > languages,

> > > I think you need to carefully define how that is supposed to=
 work;

> > essentially

> > > similar to how we handle transports; we have a set of requir=
ement on

> > what a

> > > transport document must define.=C2=A0 IMO this is super comp=
licated and

> > overkill.

> > > This draft is complex enough.

> > > Don't add even more complexity.

> >

> > If you are just saying that we can put everything into a YANG wra=
pper,

> > that is fine with me.=C2=A0 To clarify this, I have tweaked the f=
irst sentence

> > of Section 2.1 to:

> > "An event stream is a named entity on a publisher which expo=
ses a

> > continuously updating set of YANG encoded event records."
> >

> > And I have tweaked the first sentence of the third paragraph to:<=
br>
> > "As YANG encoded event records are created by a system,...&q=
uot;

> >

> > > > Of course it will be up to the definition of any partic=
ular stream to

> > > > articulate the event record contents sufficiently for f=
ilters to be

> > > > created.

> > > >

> > > > > o=C2=A0 Section 2.1

> > > > >

> > > > >=C2=A0 =C2=A0The text says:

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0Among

> > > > >=C2=A0 =C2=A0 =C2=A0these included NETCONF XML even=
t records are individual YANG 1.1

> > > > >=C2=A0 =C2=A0 =C2=A0notifications described in sect=
ion 7.16 of [RFC7950].

> > > > >

> > > > >=C2=A0 =C2=A0First of all, does this mean that ther=
e can be event records on the

> > > > >=C2=A0 =C2=A0"NETCONF" stream that are *n=
ot* defined with a "notification"

> > > > >=C2=A0 =C2=A0statement?

> > > >

> > > > For the NETCONF stream, personally I only care about th=
ings YANG

> > > > notification statement.=C2=A0 But looking again at Andy=
's comment from:

> > > > https://www.i=
etf.org/mail-archive/web/netconf/current/msg14764.html

> > > > he says "I would say SHOULD be defined in YANG, fo=
r the "NETCONF"

> > > > stream."

> > >

> > > I strongly disagree.

> > >

> > > > So for -v16 I updated the text in a way that doesn'=
t preclude this.

> > >

> > > See above.=C2=A0 If all events records are defined in YANG w=
e can remove this.

> >

> > Per above, I have included text above so that YANG encapsulation =
is

> > required.=C2=A0 I think YANG Data should be an allowable structur=
e (so I didn't

> > specify just a "Notification").=C2=A0 If you think that=
 YANG Data should be

> > excluded from the allowed event records. I can refine the words.<=
br>
> >

> > > > >=C2=A0 =C2=A0Second, this seems to imply that *all*=
 notifications defined in all

> > > > >=C2=A0 =C2=A0YANG modules end up in the "NETCO=
NF" stream, but I don't think this

> > > > >=C2=A0 =C2=A0is the intention.=C2=A0 At least I hop=
e so.=C2=A0 ("yp:push-update" is an

> > > > >=C2=A0 =C2=A0example of a notification that will no=
t be sent on the "NETCONF"

> > > > >=C2=A0 =C2=A0stream.)

> > > >

> > > > The NETCONF stream has a very broad/inclusive definitio=
n in RFC-5277.

> > > > This definition is: "This stream contains all NETC=
ONF XML event

> > > > notifications supported by the NETCONF server".
> > >

> > > This is very underspecified.=C2=A0 IIRC the original intenti=
on was

> > notifications related

> > > to NETCONF, hence "*NETCONF* XML event notifications&qu=
ot;.

> > >

> > > > To me, thinking about how that statement and applying i=
t to YANG, this

> > > > translates as YANG 1.1 notifications should go into the=
 NETCONF

> > > > stream, unless explicitly excluded.

> > >

> > > I disagree.=C2=A0 This is not how 5277 works.=C2=A0 Until we=
 have worked out a

> > useful way

> > > to assign notifications to streams, we shouldn't restric=
t anything in

> > this regard.

> >

> > Ok.=C2=A0 Effectively we are naming the stream NETCONF without im=
proving the

> > definition of what membership in that stream should be.=C2=A0 And=
 that is fine.

> > As people seem to understand what this is supposed to be, I will =
return to

> > the original definition.=C2=A0 See text, and let me know if you h=
ave issues.

> >

> > > > This provides a very simple way

> > > > determining which types of notifications should be plac=
ed on the

> > > > stream.=C2=A0 (Otherwise, how is a developer of a YANG =
notification

> > > > supposed to know whether it should go into the NETCONF =
stream or not?

> > >

> > > They don't.=C2=A0 But note that it might be an operator =
decision for how to

> > assign

> > > notifications to streams.

> >

> > Ok.=C2=A0 A stream membership definition is out-of-scope for all =
other streams,

> > we can leave it this way for the "NETCONF" stream.=C2=
=A0 Someone else can pick

> > up and define this in another draft the WG feels it necessary.
> >

> > > > The alternative would seem to be having each notificati=
on opt-in to

> > > > the NETCONF stream.)

> > > >

> > > > So if you agree with this reasoning, how about:

> > > >

> > > > The "NETCONF" event stream contains all insta=
nces of YANG 1.1

> > > > notifications generated by a publisher, except where a =
type of

> > > > notification has explicitly been excluded from the stre=
am.

> > >

> > > I think that this document should keep the definition of the=
 NETCONF

> > stream as

> > > defined in RFC 5277.

> >

> > Ok

> >

> > > Also, I think it should state that an event record is an ins=
tantiation

> > of a YANG

> > > "notification" statement (any version of YANG).
> >

> > What about a YANG Data?=C2=A0 (Per above)

> >

> > > [...]

> > >

> > > > > o=C2=A0 Section 2.4.2

> > > > >

> > > > >=C2=A0 =C2=A0The text says:

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0The transport selected by the s=
ubscriber

> > > > >=C2=A0 =C2=A0 =C2=A0to reach the publisher MUST be =
able to support multiple

> > "establish-

> > > > >=C2=A0 =C2=A0 =C2=A0subscription" requests mad=
e within the same transport session.

> > > > >

> > > > >=C2=A0 =C2=A0This seems to indicate that RESTCONF c=
annot be used with this

> > > > >=C2=A0 =C2=A0specification, since RESTCONF doesn=
9;t have sessions.

> > > >

> > > > The desired behavior is that a subscriber can request m=
ultiple

> > > > subscriptions without each requiring a separate transpo=
rt session

> > > > establishment.=C2=A0 I think we are ok here with RESTCO=
NF because

> > > > underneath RESTCONF is HTTP, TLS, TCP.=C2=A0 And each o=
f those lower layers

> > > > can have sessions.

> > > >

> > > > To clarify further, I have tweaked the text to:

> > > >

> > > > "The transport selected by the subscriber to reach=
 the publisher MUST

> > > > be able to support multiple "establish-subscriptio=
n" requests without

> > > > each requiring a separate persistent transport connecti=
on."

> > > >

> > > > >=C2=A0 =C2=A0This makes me wonder, why does this do=
cument specify this

> > > > >=C2=A0 =C2=A0requirement?=C2=A0 I agree that this i=
s the behaviour we want from

> > > > >=C2=A0 =C2=A0NETCONF, but then I think that should =
be defined in the

> > > > >=C2=A0 =C2=A0netconf-notif draft.

> > > >

> > > > By saying something in SN about this requirement, I bel=
ieve we can

> > > > preclude an implementation which can only support one s=
ubscription per

> > > > subscriber.=C2=A0 In any case, the specific "how&q=
uot; details will still need

> > > > to be articulated in each transport draft.

> > >

> > > I think you are mixing the specification and implementation.=
=C2=A0 If a

> > transport

> > > document says that an implemention MUST support multiple sub=
scriptions

> > per

> > > session (in a transport-specific way), then an implementatio=
n cannot just

> > > support a sinlge subscription.

> > >

> > > My point is that this a transport-specific requirement, and =
it doesn't

> > belong in

> > > this document.

> >

> > I can see why you don't see it applicable to Section 2.4.2.=
=C2=A0 =C2=A0 However

> > Section 5.3 provides guidelines for transport document developers=
 (this is

> > a section Kent requested.)=C2=A0 And so I have moved the requirem=
ent there.=C2=A0 Is

> > that sufficient.

> >

> > > > > o=C2=A0 Section 2.4.2

> > > > >

> > > > >=C2=A0 =C2=A0s/"start-time"/"replay-=
start-time"/=C2=A0 (3 occurrences)

> > > >

> > > > Fixed

> > > >

> > > > >=C2=A0 =C2=A0Also, the text says that the replay-st=
art-time MUST be in the past.

> > > > >

> > > > >=C2=A0 =C2=A0Suppose the server receives a "re=
play-start-time" of 12:00:00.001,

> > > > >=C2=A0 =C2=A0and the replay buffer is empty.

> > > > >

> > > > >=C2=A0 =C2=A0A) If the current time is 12:00:00.002=
, the request is accepted,

> > and

> > > > >=C2=A0 =C2=A0 =C2=A0 a "replay-completed"=
 notif is sent.

> > > > >

> > > > >=C2=A0 =C2=A0B) If the current time is 12:00:00.000=
, the request is rejected

> > with

> > > > >=C2=A0 =C2=A0 =C2=A0 an error.

> > > > >

> > > > >=C2=A0 =C2=A0Why is this important?=C2=A0 Why not s=
imply just send the

> > > > >=C2=A0 =C2=A0replay-completed notif in both cases?<=
br>
> > > >

> > > > For (B), if an event occurs at 12:00:00.0005, should it=
 be sent?

> > > > Should it be sent before or after the "replay-star=
t-time"?=C2=A0 How long

> > > > should we allow the clocks to drift before we reject th=
e subscription?

> > > > As we don't support future/pending subscriptions, w=
e don't have to

> > > > worry about these questions with the current definition=
.

> > >

> > > I would simply say that if the replay-start-time is later th=
an any

> > buffered notif,

> > > then "replay-complete" is immediately sent.=C2=A0 =
It dont'

> > > matter if it is one microsecond or one year later.

> >

> > Tweaked the sentence:

> >

> > "If the given "replay-start-time" is later than th=
e time marked within any

> > event records retained within the replay buffer, then the publish=
er MUST

> > send a "replay-completed" notification immediately afte=
r a successful

> > establish-subscription RPC response."

> >

> > > The problem otherwise is how to decide if something is "=
;in the past".

> > > In the past when the client sent the request?=C2=A0 When the=
 server parsed

> > the XML?

> > > When the instrumentation code runs?

> > >

> > > But this is not a big issue.

> >

> > Hopefully with the tweak, we can leave it as modified.

> >

> > [..]

> > > > > o=C2=A0 Section 2.4.6

> > > > >

> > > > >=C2=A0 =C2=A0The text says:

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A01.=C2=A0 "establish-subscr=
iption-stream-error-info": This MUST be

> > returned

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if an RPC error r=
eason has not been placed elsewhere within

> > the

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transport portion=
 of a failed "establish-subscription" RPC

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0response.

> > > > >

> > > > >=C2=A0 =C2=A0(and similar for the other errors)

> > > > >

> > > > >=C2=A0 =C2=A0What exactly does "if an RPC erro=
r reason has not been placed

> > > > >=C2=A0 =C2=A0elsewhere" mean?

> > > >

> > > > The intent is to match how NETCONF & RESTCONF histo=
rically handles

> > > > errors.=C2=A0 As you know with NETCONF, each error iden=
tity will be

> > > > inserted as the "error-app-tag".

> > >

> > > It could also be in "error-tag" and/or "error=
-message".=C2=A0 My point is

> > that I don't

> > > think that you mean that if an implementation populate say
> > "error-message",

> > > then it should not popluate error-info with

> > establish-subscription-stream-

> > > error-info.

> >

> > I do mean that.=C2=A0 I don't think we should send: "est=
ablish-subscription-stream-error-info"

> > for NETCONF when there is no hint included.=C2=A0 All the necessa=
ry error info

> > is already in the existing message.

> >

> > > > And therefore placing the YANG data

> > > > "establish-subscription-stream-error-info&quo=
t; would be redundant.=C2=A0 For

> > > > NETCONF, "establish-subscription-stream-error=
-info" are only needed

> > > > when hints to be provided.

> > > >

> > > > Therefore assuming you are looking for an alternative w=
ay to make this

> > > > point, I have tweaked the text to:

> > > > "This MUST be returned if an RPC error reason has =
not been mapped down

> > > > into transport specific error objects contained within =
a failed

> > > > "establish-subscription" RPC response."<=
br>
> > >

> > > Howabout simply removing this sentence?

> >

> > Done

> >

> > > > > o=C2=A0 Section 2.5.1

> > > > >

> > > > >=C2=A0 =C2=A0In the second diagram (for the valid s=
tate), the states are called

> > > > >=C2=A0 =C2=A0"receiver connecting", "=
;reciever timeout" etc.=C2=A0 I find this a bit

> > > > >=C2=A0 =C2=A0confusing; it is not the *receiver* th=
at is connecting, it is the

> > > > >=C2=A0 =C2=A0publisher.=C2=A0 Ok, the legend then s=
ays:

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 dashed boxes which include the=
 word 'receiver' show the possible

> > > > >=C2=A0 =C2=A0 =C2=A0 states for an individual recei=
ver

> > > > >

> > > > >=C2=A0 But since all dashed boxes include the word =
"receiver", and the

> > > > > diagram specifically is the state machine *per rec=
eiver*, maybe we

> > > > > can simply remove the word "receiver" fr=
om the boxes?

> > > >

> > > > There have been some discussions on this.=C2=A0 I agree=
 it is certainly

> > > > valid to remove "receiver" from these four bo=
xes.=C2=A0 However I have

> > > > found that getting readers to really internalize that t=
he state

> > > > machine is actually per-receiver rather than per-subscr=
iption, it

> > > > seems to go faster/cleaner when receiver is shown in th=
e four boxes.

> > > >

> > > > Nevertheless, if you absolutely want "receiver&quo=
t; removed from the

> > > > boxes, I can do that.

> > >

> > > Maybe you can remove receiver from the individual boxes and =
then change

> > the

> > > word "valid" from the outer box to "per-recei=
ver state machine"?

> > >

> > > Or maybe remove the outer box and add a Figure title: 'p=
er-receiver state

> > > machine for the subscription's "valid" state&#=
39;

> > >

> > > Also not a big deal, but I found it confusing.

> >

> > All are viable.=C2=A0 But I have found the current diagram useabl=
e. Do you have

> > a major issue if we leave it as it is?

> >

> > > [...]

> > >

> > > > > o=C2=A0 Section 2.5.6

> > > > >

> > > > >=C2=A0 =C2=A0I know that this feature was presented=
 in Montreal.=C2=A0 I think it is

> > > > >=C2=A0 =C2=A0problematic, and suggest it is removed=
.

> > > >

> > > > This issue was discussed in Montreal.=C2=A0 The feature=
 is of course is

> > > > optional.=C2=A0 There are a large number of downsides f=
or someone who

> > > > chooses not to implement for certain use cases.=C2=A0 P=
lease see the

> > > > Montreal slides and the long threads with Kent for more=
 details.

> > >

> > > I did watch the Montreal session, but I didn't see any d=
iscussion on

> > > this issue (just your presentation).=C2=A0 =C2=A0Can you sen=
d a pointer to the

> > > email thread with Kent?

> >

> > Some minutes on the topic can be seen at:

> > https://datatracker.ietf.org/doc=
/minutes-102-netconf/

> > With the WG vote in Montreal, I would love not to re-open.

> >

> > The previous exchange was long.=C2=A0 Some items include:

> > https://www.ietf.org/ma=
il-archive/web/netconf/current/msg14575.html

> > https://www.ietf.org/ma=
il-archive/web/netconf/current/msg14902.html

> >

> > > > If

> > > > you want to pursue this further it is probably best to =
start a new

> > > > thread dedicated to this topic alone.

> > > >

> > > > >=C2=A0 =C2=A0For example, what happens if the trans=
port session is lost and

> > > > >=C2=A0 =C2=A0re-established; are all event records =
in the buffer replayed again?

> > > >

> > > > No.=C2=A0 The publisher will not lose context of what w=
as sent.

> > >

> > > This is not clear from the text.=C2=A0 In fact, the text exp=
licitly says:

> > >

> > >=C2=A0 =C2=A0 The leading event record sent will be the first=
 event record

> > >=C2=A0 =C2=A0 subsequent to the latest of three different tim=
es: the

> > >=C2=A0 =C2=A0 "replay-log-creation-time", "rep=
lay-log-aged- time", or the most

> > >=C2=A0 =C2=A0 recent publisher boot time.

> >

> > I see your point.=C2=A0 =C2=A0I have tweaked the text to:

> >

> > " If the publisher does not know the next record intended fo=
r the

> > receiver, the leading event record..."

> >

> > I have also made a corresponding tweak to the YANG model.

> >

> > > > >=C2=A0 =C2=A0What happens if a new receiver is adde=
d to a subscription that

> > > > >=C2=A0 =C2=A0already has a receiver, will all event=
s in the buffer be replayed

> > to

> > > > >=C2=A0 =C2=A0the new receiver?

> > > >

> > > > Yes.=C2=A0 (To clarify, I added "to each configure=
d receiver" at the end of

> > > > the last sentence of the first paragraph.)

> > > >

> > > > >=C2=A0 =C2=A0When a new subscription is configured =
with configured-replay set,

> > > > >=C2=A0 =C2=A0the publisher will immediately try to =
connect to the publisher and

> > > > >=C2=A0 =C2=A0send all buffered event from the last =
reboot.=C2=A0 Is this really

> > > > >=C2=A0 =C2=A0useful?

> > > >

> > > > Yes.=C2=A0 See the security cases reviewed on the earli=
er threads with

> > > > Kent.=C2=A0 If someone doesn't care about log entri=
es since boot, they

> > > > simply don't have to implement this optional featur=
e.

> > > >

> > > > >=C2=A0 =C2=A0If the mechansim relies on the subscri=
ber being able to also use

> > > > >=C2=A0 =C2=A0dynamic subscriptions for replay of al=
l event records, maybe we

> > > > >=C2=A0 =C2=A0could simplify things by always relyin=
g on dynamic subscriptions

> > for

> > > > >=C2=A0 =C2=A0replay for configured subscriptions.=
=C2=A0 Specifically, remove

> > > > >=C2=A0 =C2=A0"configured-replay" etc, but=
 keep the "replay-previous-event-time"

> > > > >=C2=A0 =C2=A0in the "subscription-started"=
; notification.=C2=A0 Then a subscriber can

> > > > >=C2=A0 =C2=A0simply check this value to see if anyt=
hing is missing, and if it

> > is,

> > > > >=C2=A0 =C2=A0use a dynamic subscription to request =
replay from the latest time

> > he

> > > > >=C2=A0 =C2=A0knows about.

> > > >

> > > > This is a valid approach, and can be used as an alterna=
tive to this

> > > > optional feature.=C2=A0 However there are still many do=
wnsides to the

> > > > alternative.=C2=A0 See the slides from Montreal, as wel=
l as the previous

> > > > thread discussions for details.

> > > >

> > > > > o=C2=A0 Section 2.6

> > > > >

> > > > >=C2=A0 =C2=A0It just occurred to me that this text =
about using the

> > <notification>

> > > > >=C2=A0 =C2=A0message shouldn't be in this docum=
ent, but in the netconf-notif

> > (and

> > > > >=C2=A0 =C2=A0restconf-notif) document.=C2=A0 It is =
highly transport and encoding

> > > > >=C2=A0 =C2=A0specific.

> > > >

> > > > I think you are referring to both the sentence: "T=
his notification

> > > > message MUST be encoded in a <notification> messa=
ge as defined within

> > > > [RFC5277], Section 4.=C2=A0 And per [RFC5277]'s &qu=
ot;eventTime" object

> > > > definition, the "eventTime" is populated with=
 the event occurrence

> > > > time."=C2=A0 As well as to the example compliant m=
essage in Figure 10.

> > > >

> > > > While the text could be extracted and placed in the net=
conf-notif

> > > > document, extracting it fully from SN would leave no ba=
seline message

> > > > format.

> > >

> > > Things like this are inevitable when you have a transport-in=
dependent

> > > specification.=C2=A0 Of course, you can require that all tra=
nsports MUST use

> > the 5277

> > > spec of a notification.=C2=A0 But then I think you rule out =
transports like

> > CoMI and

> > > possibly other future binary protocols.

> >

> > Ok, I am fine with the move.=C2=A0 I have moved the identified te=
xt to

> > NETCONF-Notif.=C2=A0 (Actually the text was already there too.=C2=
=A0 So I just

> > tweaked it.)

> >

> > Thanks,

> > Eric

> >

> > > > Perhaps others will have a problem if the SN solution d=
oes not have

> > > > some pre-defined structure to hold event records?

> > > >

> > > > I can move this if I hear no objection.=C2=A0 As you kn=
ow, I am hoping that

> > > > draft-ietf-netconf-notification-messages at some p=
oint displaces the

> > > > <notification> message of [RFC5277], Section 4.=
=C2=A0 And this is easier to

> > > > do with fewer references to RFC5277 within SN.

> > >

> > > [...]

> > > /martin

> >

> > _______________________________________________

> > Netconf mailing list

> > Netconf@ietf.org

> > https://www.ietf.org/mailman/listinfo/ne=
tconf

> >





--0000000000001331570575b2bc61--


From nobody Thu Sep 13 00:21:41 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AD712D7F8 for ; Thu, 13 Sep 2018 00:21:39 -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 OGFQIl3Y3ZJW for ; Thu, 13 Sep 2018 00:21:36 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4B7130DDC for ; Thu, 13 Sep 2018 00:21:35 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 7E5E71AE018A; Thu, 13 Sep 2018 09:21:34 +0200 (CEST)
Date: Thu, 13 Sep 2018 09:21:34 +0200 (CEST)
Message-Id: <20180913.092134.395462318086733174.mbj@tail-f.com>
To: evoit@cisco.com
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com>
References:  <20180912.113446.2017030234338816835.mbj@tail-f.com> <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 07:21:39 -0000

Hi,

Thank you for addressing my comments.  More inline.


"Eric Voit (evoit)"  wrote:
> Hi Martin,
> 
> Much incorporated.  Latest is at:
> https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-subscribed-notifications-17.txt
> 
> Specific responses in-line...
> 
> > From: Martin Bjorklund, September 12, 2018 5:35 AM
> > 
> > "Eric Voit (evoit)"  wrote:
> > > Thanks for the comments Martin,  thoughts in-line...
> > >
> > > > From: Martin Bjorklund, September 10, 2018 1:42 PM
> > 
> > [...]
> > 
> > > > o  Section 2.1
> > > >
> > > >   The text says:
> > > >
> > > >     It is out of the scope of this document
> > > >     to identify [...] b) how event records are defined
> > > >
> > > >   Is this really what we want?  Shouldn't this document specify that
> > > >   an event record is an instance of a YANG "notification" statement?
> > > >   Do we want to support event records that are not defined in YANG?
> > > >
> > > >   This was discussed in the thread "comments on
> > > >   draft-ietf-netconf-subscribed-notifications-12", and it seems that
> > > >   noone really have any use case for non-YANG-defined event records,
> > > >   accessed with YANG-defined operations.
> > >
> > > Yes this was discussed previously.  My reading was that others wanted
> > > to support subscription to non-YANG events.
> > > E.g., see Andy & Tianran's thoughts in
> > > https://www.ietf.org/mail-archive/web/netconf/current/msg14764.html
> > 
> > Yes, but read on in that thread, see
> > https://www.ietf.org/mail-archive/web/netconf/current/msg14766.html
> > for a clarification.
> > 
> > AFAIK, noone has presented a use case for sending non-YANG-defined
> > data
> > here.
> 
> As anything can be YANG wrapped, per the thread above.  I am fine with
> this.
> 
> > > >   I think that this document should state that an event record is an
> > > >   instance of a YANG "notification" statement.  If not, it is unclear
> > > >   both how subtree/xpath filters and xml/json/... encodings would work.
> > >
> > > Applying xpath filters against XML based event records seems viable to
> > > me.
> > 
> > Where does it say that it has to be XML?  Whatabout mixed-content?
> > What if such a notification is sent when the encoding is JSON?
> > 
> > If you want to make this specification open for other data modeling
> > languages,
> > I think you need to carefully define how that is supposed to work;
> > essentially
> > similar to how we handle transports; we have a set of requirement on
> > what a
> > transport document must define.  IMO this is super complicated and
> > overkill.
> > This draft is complex enough.
> > Don't add even more complexity.
> 
> If you are just saying that we can put everything into a YANG wrapper,
> that is fine with me.  To clarify this, I have tweaked the first
> sentence of Section 2.1 to:
> "An event stream is a named entity on a publisher which exposes a
> continuously updating set of YANG encoded event records."

Howabout:

OLD:

   An event stream is a named entity on a publisher which exposes a
   continuously updating set of event records.  Each event stream is
   available for subscription.  It is out of the scope of this document
   to identify a) how streams are defined (other than the NETCONF
   stream), b) how event records are defined/generated, and c) how event
   records are assigned to streams.

NEW:

   An event stream is a named entity on a publisher which exposes a
   continuously updating set of event records.  An event record is
   defined with the "notification" YANG statement.  Each event stream is
   available for subscription.  It is out of the scope of this document
   to identify a) how streams are defined (other than the NETCONF
   stream), b) how event records are generated, and c) how event
   records are assigned to streams.

> And I have tweaked the first sentence of the third paragraph to:
> "As YANG encoded event records are created by a system,..."

I think the original sentence is better.

Also, some tweaks are needed to the filter leafs in the YANG module:

OLD:

          The subtree filter is applied to the representation of
          individual, delineated event records as contained within the
          event stream.  For example, if the notification message
          contains an instance of a notification defined in YANG, then
          the top-level element is the name of the YANG notification.

NEW:

          The subtree filter is applied to the representation of
          individual, delineated event records as contained within the
          event stream.  The top-level element in the event record is
          the name of the YANG notification.

and

OLD:

           The XPath expression is evaluated on the representation of
           individual, delineated event records as contained within
           the event stream.  For example, if the notification message
           contains an instance of a notification defined in YANG,
           then the top-level element is the name of the YANG
           notification, and the root node has this top-level element
           as the only child.

NEW:


           The XPath expression is evaluated on the representation of
           individual, delineated event records as contained within
           the event stream.  The top-level element in the event
           record is the name of the YANG notification, and the root
           node has this top-level element as the only child.


(I think it would be useful with some filtering examples, like in
section 5 of RFC 5277, but I think you have all examples in
netconf-notif, so they would go into that draft.  (re-reading an old
thread I found that examples for filters were requested before)).



> > > Of course it will be up to the definition of any particular stream to
> > > articulate the event record contents sufficiently for filters to be
> > > created.
> > >
> > > > o  Section 2.1
> > > >
> > > >   The text says:
> > > >
> > > >     Among
> > > >     these included NETCONF XML event records are individual YANG 1.1
> > > >     notifications described in section 7.16 of [RFC7950].
> > > >
> > > >   First of all, does this mean that there can be event records on the
> > > >   "NETCONF" stream that are *not* defined with a "notification"
> > > >   statement?
> > >
> > > For the NETCONF stream, personally I only care about things YANG
> > > notification statement.  But looking again at Andy's comment from:
> > > https://www.ietf.org/mail-archive/web/netconf/current/msg14764.html
> > > he says "I would say SHOULD be defined in YANG, for the "NETCONF"
> > > stream."
> > 
> > I strongly disagree.
> > 
> > > So for -v16 I updated the text in a way that doesn't preclude this.
> > 
> > See above.  If all events records are defined in YANG we can remove
> > this.
> 
> Per above, I have included text above so that YANG encapsulation is
> required.  I think YANG Data should be an allowable structure (so I
> didn't specify just a "Notification").  If you think that YANG Data
> should be excluded from the allowed event records. I can refine the
> words.

Yes I think yang-data must be excluded (actually this was one of the
concerns, raised by Andy I think; that people start to use yang-data
for things that we already have proper YANG statements for...)

> > > >   Second, this seems to imply that *all* notifications defined in all
> > > >   YANG modules end up in the "NETCONF" stream, but I don't think this
> > > >   is the intention.  At least I hope so.  ("yp:push-update" is an
> > > >   example of a notification that will not be sent on the "NETCONF"
> > > >   stream.)
> > >
> > > The NETCONF stream has a very broad/inclusive definition in RFC-5277.
> > > This definition is: "This stream contains all NETCONF XML event
> > > notifications supported by the NETCONF server".
> > 
> > This is very underspecified.  IIRC the original intention was
> > notifications related
> > to NETCONF, hence "*NETCONF* XML event notifications".
> > 
> > > To me, thinking about how that statement and applying it to YANG, this
> > > translates as YANG 1.1 notifications should go into the NETCONF
> > > stream, unless explicitly excluded.
> > 
> > I disagree.  This is not how 5277 works.  Until we have worked out a
> > useful way
> > to assign notifications to streams, we shouldn't restrict anything in
> > this regard.
> 
> Ok.  Effectively we are naming the stream NETCONF without improving
> the definition of what membership in that stream should be.  And that
> is fine.  As people seem to understand what this is supposed to be, I
> will return to the original definition.  See text, and let me know if
> you have issues.

Maybe one small tweak from the original text:

OLD:

  The "NETCONF" event stream contains all NETCONF XML event
  record information supported by the publisher

NEW:

  The "NETCONF" event stream contains all NETCONF event
  record information supported by the publisher


(since it actually is possible to get them in JSON over RESTCONF)


> > > This provides a very simple way
> > > determining which types of notifications should be placed on the
> > > stream.  (Otherwise, how is a developer of a YANG notification
> > > supposed to know whether it should go into the NETCONF stream or not?
> > 
> > They don't.  But note that it might be an operator decision for how to
> > assign
> > notifications to streams.
> 
> Ok.  A stream membership definition is out-of-scope for all other
> streams, we can leave it this way for the "NETCONF" stream.  Someone
> else can pick up and define this in another draft the WG feels it
> necessary.

Yes.

> > > The alternative would seem to be having each notification opt-in to
> > > the NETCONF stream.)
> > >
> > > So if you agree with this reasoning, how about:
> > >
> > > The "NETCONF" event stream contains all instances of YANG 1.1
> > > notifications generated by a publisher, except where a type of
> > > notification has explicitly been excluded from the stream.
> > 
> > I think that this document should keep the definition of the NETCONF
> > stream as
> > defined in RFC 5277.
> 
> Ok
> 
> > Also, I think it should state that an event record is an instantiation
> > of a YANG
> > "notification" statement (any version of YANG).
> 
> What about a YANG Data?  (Per above)

See above.

> > [...]
> > 
> > > > o  Section 2.4.2
> > > >
> > > >   The text says:
> > > >
> > > >     The transport selected by the subscriber
> > > >     to reach the publisher MUST be able to support multiple "establish-
> > > >     subscription" requests made within the same transport session.
> > > >
> > > >   This seems to indicate that RESTCONF cannot be used with this
> > > >   specification, since RESTCONF doesn't have sessions.
> > >
> > > The desired behavior is that a subscriber can request multiple
> > > subscriptions without each requiring a separate transport session
> > > establishment.  I think we are ok here with RESTCONF because
> > > underneath RESTCONF is HTTP, TLS, TCP.  And each of those lower layers
> > > can have sessions.
> > >
> > > To clarify further, I have tweaked the text to:
> > >
> > > "The transport selected by the subscriber to reach the publisher MUST
> > > be able to support multiple "establish-subscription" requests without
> > > each requiring a separate persistent transport connection."
> > >
> > > >   This makes me wonder, why does this document specify this
> > > >   requirement?  I agree that this is the behaviour we want from
> > > >   NETCONF, but then I think that should be defined in the
> > > >   netconf-notif draft.
> > >
> > > By saying something in SN about this requirement, I believe we can
> > > preclude an implementation which can only support one subscription per
> > > subscriber.  In any case, the specific "how" details will still need
> > > to be articulated in each transport draft.
> > 
> > I think you are mixing the specification and implementation.  If a
> > transport
> > document says that an implemention MUST support multiple subscriptions
> > per
> > session (in a transport-specific way), then an implementation cannot
> > just
> > support a sinlge subscription.
> > 
> > My point is that this a transport-specific requirement, and it doesn't
> > belong in
> > this document.
> 
> I can see why you don't see it applicable to Section 2.4.2.  However
> Section 5.3 provides guidelines for transport document developers
> (this is a section Kent requested.)  And so I have moved the
> requirement there.  Is that sufficient.

Ok, I agree that the text belongs to section 5.3 rather than 2.4.2.  I
just don't agree with the text ;-)  But I can accept it.


> > > > o  Section 2.4.2
> > > >
> > > >   s/"start-time"/"replay-start-time"/  (3 occurrences)
> > >
> > > Fixed
> > >
> > > >   Also, the text says that the replay-start-time MUST be in the past.
> > > >
> > > >   Suppose the server receives a "replay-start-time" of 12:00:00.001,
> > > >   and the replay buffer is empty.
> > > >
> > > >   A) If the current time is 12:00:00.002, the request is accepted, and
> > > >      a "replay-completed" notif is sent.
> > > >
> > > >   B) If the current time is 12:00:00.000, the request is rejected with
> > > >      an error.
> > > >
> > > >   Why is this important?  Why not simply just send the
> > > >   replay-completed notif in both cases?
> > >
> > > For (B), if an event occurs at 12:00:00.0005, should it be sent?
> > > Should it be sent before or after the "replay-start-time"?  How long
> > > should we allow the clocks to drift before we reject the subscription?
> > > As we don't support future/pending subscriptions, we don't have to
> > > worry about these questions with the current definition.
> > 
> > I would simply say that if the replay-start-time is later than any
> > buffered notif,
> > then "replay-complete" is immediately sent.  It dont'
> > matter if it is one microsecond or one year later.
> 
> Tweaked the sentence:
> 
> "If the given "replay-start-time" is later than the time marked within
> any event records retained within the replay buffer, then the
> publisher MUST send a "replay-completed" notification immediately
> after a successful establish-subscription RPC response."
>  
> > The problem otherwise is how to decide if something is "in the past".
> > In the past when the client sent the request?  When the server parsed
> > the XML?
> > When the instrumentation code runs?
> > 
> > But this is not a big issue.
> 
> Hopefully with the tweak, we can leave it as modified.

Ok.


> [..]
> > > > o  Section 2.4.6
> > > >
> > > >   The text says:
> > > >
> > > >     1.  "establish-subscription-stream-error-info": This MUST be returned
> > > >         if an RPC error reason has not been placed elsewhere within the
> > > >         transport portion of a failed "establish-subscription" RPC
> > > >         response.
> > > >
> > > >   (and similar for the other errors)
> > > >
> > > >   What exactly does "if an RPC error reason has not been placed
> > > >   elsewhere" mean?
> > >
> > > The intent is to match how NETCONF & RESTCONF historically handles
> > > errors.  As you know with NETCONF, each error identity will be
> > > inserted as the "error-app-tag".
> > 
> > It could also be in "error-tag" and/or "error-message".  My point is
> > that I don't
> > think that you mean that if an implementation populate say
> > "error-message",
> > then it should not popluate error-info with
> > establish-subscription-stream-
> > error-info.
> 
> I do mean that.  I don't think we should send:
> "establish-subscription-stream-error-info" for NETCONF when there is
> no hint included.  All the necessary error info is already in the
> existing message.

But is this really true?  In the
"establish-subscription-stream-error-info" there is a leaf called
"reason", which is an identity with a detailed error reason, for
example "history-unavailable".  This info is not present anywhere else
in the rpc-error, so it needs to be present here.


> > > And therefore placing the YANG data
> > > "establish-subscription-stream-error-info" would be redundant.  For
> > > NETCONF, "establish-subscription-stream-error-info" are only needed
> > > when hints to be provided.
> > >
> > > Therefore assuming you are looking for an alternative way to make this
> > > point, I have tweaked the text to:
> > > "This MUST be returned if an RPC error reason has not been mapped down
> > > into transport specific error objects contained within a failed
> > > "establish-subscription" RPC response."
> > 
> > Howabout simply removing this sentence?
> 
> Done
> 
> > > > o  Section 2.5.1
> > > >
> > > >   In the second diagram (for the valid state), the states are called
> > > >   "receiver connecting", "reciever timeout" etc.  I find this a bit
> > > >   confusing; it is not the *receiver* that is connecting, it is the
> > > >   publisher.  Ok, the legend then says:
> > > >
> > > >      dashed boxes which include the word 'receiver' show the possible
> > > >      states for an individual receiver
> > > >
> > > >  But since all dashed boxes include the word "receiver", and the
> > > > diagram specifically is the state machine *per receiver*, maybe we
> > > > can simply remove the word "receiver" from the boxes?
> > >
> > > There have been some discussions on this.  I agree it is certainly
> > > valid to remove "receiver" from these four boxes.  However I have
> > > found that getting readers to really internalize that the state
> > > machine is actually per-receiver rather than per-subscription, it
> > > seems to go faster/cleaner when receiver is shown in the four boxes.
> > >
> > > Nevertheless, if you absolutely want "receiver" removed from the
> > > boxes, I can do that.
> > 
> > Maybe you can remove receiver from the individual boxes and then
> > change the
> > word "valid" from the outer box to "per-receiver state machine"?
> > 
> > Or maybe remove the outer box and add a Figure title: 'per-receiver
> > state
> > machine for the subscription's "valid" state'
> > 
> > Also not a big deal, but I found it confusing.
> 
> All are viable.  But I have found the current diagram useable. Do you
> have a major issue if we leave it as it is?

No.  As I said, I found it confusing, but if others think it is more
helpful without my suggested changes, we should leave it as is.

> > [...]
> > 
> > > > o  Section 2.5.6
> > > >
> > > >   I know that this feature was presented in Montreal.  I think it is
> > > >   problematic, and suggest it is removed.
> > >
> > > This issue was discussed in Montreal.  The feature is of course is
> > > optional.  There are a large number of downsides for someone who
> > > chooses not to implement for certain use cases.  Please see the
> > > Montreal slides and the long threads with Kent for more details.
> > 
> > I did watch the Montreal session, but I didn't see any discussion on
> > this issue (just your presentation).   Can you send a pointer to the
> > email thread with Kent?
> 
> Some minutes on the topic can be seen at:
> https://datatracker.ietf.org/doc/minutes-102-netconf/ 
> With the WG vote in Montreal, I would love not to re-open.  
> 
> The previous exchange was long.  Some items include:
> https://www.ietf.org/mail-archive/web/netconf/current/msg14575.html
> https://www.ietf.org/mail-archive/web/netconf/current/msg14902.html 

Ok, if you believe that this thread shows that the WG supports this
feature, I won't pursue this.

> > > If
> > > you want to pursue this further it is probably best to start a new
> > > thread dedicated to this topic alone.
> > >
> > > >   For example, what happens if the transport session is lost and
> > > >   re-established; are all event records in the buffer replayed again?
> > >
> > > No.  The publisher will not lose context of what was sent.
> > 
> > This is not clear from the text.  In fact, the text explicitly says:
> > 
> >    The leading event record sent will be the first event record
> >    subsequent to the latest of three different times: the
> >    "replay-log-creation-time", "replay-log-aged- time", or the most
> >    recent publisher boot time.
> 
> I see your point.   I have tweaked the text to:
> 
> " If the publisher does not know the next record intended for the
> receiver, the leading event record..."

Hmm, not sure this helps.  How about:

OLD:

   As a result, when any configured subscription receivers become
   active, buffered event records will be sent immediately after the
   "subscription-started" notification.  If the publisher does not know
   the next record intended for the receiver, the leading event record
   sent will be the first event record subsequent to the latest of three
   different times: the "replay-log-creation-time", "replay-log-aged-
   time", or the most recent publisher boot time.

NEW:

   As a result, when any configured subscription receivers become
   active, buffered event records will be sent immediately after the
   "subscription-started" notification.  The leading event record
   sent will be the first event record subsequent to the latest of four
   different times: the "replay-log-creation-time", "replay-log-aged-
   time", the most recent publisher boot time, and the time of the
   last event record sent to the reciever, if any.


> I have also made a corresponding tweak to the YANG model.

In the leaf "configured-replay"?  I couldn't find this text.

> > > >   What happens if a new receiver is added to a subscription that
> > > >   already has a receiver, will all events in the buffer be replayed to
> > > >   the new receiver?
> > >
> > > Yes.  (To clarify, I added "to each configured receiver" at the end of
> > > the last sentence of the first paragraph.)
> > >
> > > >   When a new subscription is configured with configured-replay set,
> > > >   the publisher will immediately try to connect to the publisher and
> > > >   send all buffered event from the last reboot.  Is this really
> > > >   useful?
> > >
> > > Yes.  See the security cases reviewed on the earlier threads with
> > > Kent.  If someone doesn't care about log entries since boot, they
> > > simply don't have to implement this optional feature.
> > >
> > > >   If the mechansim relies on the subscriber being able to also use
> > > >   dynamic subscriptions for replay of all event records, maybe we
> > > >   could simplify things by always relying on dynamic subscriptions for
> > > >   replay for configured subscriptions.  Specifically, remove
> > > >   "configured-replay" etc, but keep the "replay-previous-event-time"
> > > >   in the "subscription-started" notification.  Then a subscriber can
> > > >   simply check this value to see if anything is missing, and if it is,
> > > >   use a dynamic subscription to request replay from the latest time he
> > > >   knows about.
> > >
> > > This is a valid approach, and can be used as an alternative to this
> > > optional feature.  However there are still many downsides to the
> > > alternative.  See the slides from Montreal, as well as the previous
> > > thread discussions for details.
> > >
> > > > o  Section 2.6
> > > >
> > > >   It just occurred to me that this text about using the 
> > > >   message shouldn't be in this document, but in the netconf-notif (and
> > > >   restconf-notif) document.  It is highly transport and encoding
> > > >   specific.
> > >
> > > I think you are referring to both the sentence: "This notification
> > > message MUST be encoded in a  message as defined within
> > > [RFC5277], Section 4.  And per [RFC5277]'s "eventTime" object
> > > definition, the "eventTime" is populated with the event occurrence
> > > time."  As well as to the example compliant message in Figure 10.
> > >
> > > While the text could be extracted and placed in the netconf-notif
> > > document, extracting it fully from SN would leave no baseline message
> > > format.
> > 
> > Things like this are inevitable when you have a transport-independent
> > specification.  Of course, you can require that all transports MUST
> > use the 5277
> > spec of a notification.  But then I think you rule out transports like
> > CoMI and
> > possibly other future binary protocols.
> 
> Ok, I am fine with the move.  I have moved the identified text to
> NETCONF-Notif.  (Actually the text was already there too.  So I just
> tweaked it.)
>  
> Thanks,
> Eric
> 
> > > Perhaps others will have a problem if the SN solution does not have
> > > some pre-defined structure to hold event records?
> > >
> > > I can move this if I hear no objection.  As you know, I am hoping that
> > > draft-ietf-netconf-notification-messages at some point displaces the
> > >  message of [RFC5277], Section 4.  And this is easier to
> > > do with fewer references to RFC5277 within SN.
> > 
> > [...]
> > /martin
> 


/martin


From nobody Thu Sep 13 07:21:23 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17451252B7 for ; Thu, 13 Sep 2018 07:21:20 -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 H2uSVJ6UdM07 for ; Thu, 13 Sep 2018 07:21:18 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA08124D68 for ; Thu, 13 Sep 2018 07:21:18 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 6A4F41AE018A; Thu, 13 Sep 2018 16:21:17 +0200 (CEST)
Date: Thu, 13 Sep 2018 16:21:17 +0200 (CEST)
Message-Id: <20180913.162117.1031242545011500593.mbj@tail-f.com>
To: evoit@cisco.com
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20180913.092134.395462318086733174.mbj@tail-f.com>
References: <20180912.113446.2017030234338816835.mbj@tail-f.com> <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com> <20180913.092134.395462318086733174.mbj@tail-f.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 14:21:21 -0000

Hi,

One problematic thing below.

Martin Bjorklund  wrote:
> Hi,
> 
> Thank you for addressing my comments.  More inline.
> 
> 
> "Eric Voit (evoit)"  wrote:
> > Hi Martin,
> > 
> > Much incorporated.  Latest is at:
> > https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-subscribed-notifications-17.txt
> > 
> > Specific responses in-line...
> > 
> > > From: Martin Bjorklund, September 12, 2018 5:35 AM
> > > 
> > > "Eric Voit (evoit)"  wrote:
> > > > Thanks for the comments Martin,  thoughts in-line...
> > > >
> > > > > From: Martin Bjorklund, September 10, 2018 1:42 PM
> > > 
> > > [...]
> > > 
> > > > > o  Section 2.1
> > > > >
> > > > >   The text says:
> > > > >
> > > > >     It is out of the scope of this document
> > > > >     to identify [...] b) how event records are defined
> > > > >
> > > > >   Is this really what we want?  Shouldn't this document specify that
> > > > >   an event record is an instance of a YANG "notification" statement?
> > > > >   Do we want to support event records that are not defined in YANG?
> > > > >
> > > > >   This was discussed in the thread "comments on
> > > > >   draft-ietf-netconf-subscribed-notifications-12", and it seems that
> > > > >   noone really have any use case for non-YANG-defined event records,
> > > > >   accessed with YANG-defined operations.
> > > >
> > > > Yes this was discussed previously.  My reading was that others wanted
> > > > to support subscription to non-YANG events.
> > > > E.g., see Andy & Tianran's thoughts in
> > > > https://www.ietf.org/mail-archive/web/netconf/current/msg14764.html
> > > 
> > > Yes, but read on in that thread, see
> > > https://www.ietf.org/mail-archive/web/netconf/current/msg14766.html
> > > for a clarification.
> > > 
> > > AFAIK, noone has presented a use case for sending non-YANG-defined
> > > data
> > > here.
> > 
> > As anything can be YANG wrapped, per the thread above.  I am fine with
> > this.
> > 
> > > > >   I think that this document should state that an event record is an
> > > > >   instance of a YANG "notification" statement.  If not, it is unclear
> > > > >   both how subtree/xpath filters and xml/json/... encodings would work.
> > > >
> > > > Applying xpath filters against XML based event records seems viable to
> > > > me.
> > > 
> > > Where does it say that it has to be XML?  Whatabout mixed-content?
> > > What if such a notification is sent when the encoding is JSON?
> > > 
> > > If you want to make this specification open for other data modeling
> > > languages,
> > > I think you need to carefully define how that is supposed to work;
> > > essentially
> > > similar to how we handle transports; we have a set of requirement on
> > > what a
> > > transport document must define.  IMO this is super complicated and
> > > overkill.
> > > This draft is complex enough.
> > > Don't add even more complexity.
> > 
> > If you are just saying that we can put everything into a YANG wrapper,
> > that is fine with me.  To clarify this, I have tweaked the first
> > sentence of Section 2.1 to:
> > "An event stream is a named entity on a publisher which exposes a
> > continuously updating set of YANG encoded event records."
> 
> Howabout:
> 
> OLD:
> 
>    An event stream is a named entity on a publisher which exposes a
>    continuously updating set of event records.  Each event stream is
>    available for subscription.  It is out of the scope of this document
>    to identify a) how streams are defined (other than the NETCONF
>    stream), b) how event records are defined/generated, and c) how event
>    records are assigned to streams.
> 
> NEW:
> 
>    An event stream is a named entity on a publisher which exposes a
>    continuously updating set of event records.  An event record is
>    defined with the "notification" YANG statement.  Each event stream is
>    available for subscription.  It is out of the scope of this document
>    to identify a) how streams are defined (other than the NETCONF
>    stream), b) how event records are generated, and c) how event
>    records are assigned to streams.
> 
> > And I have tweaked the first sentence of the third paragraph to:
> > "As YANG encoded event records are created by a system,..."
> 
> I think the original sentence is better.
> 
> Also, some tweaks are needed to the filter leafs in the YANG module:
> 
> OLD:
> 
>           The subtree filter is applied to the representation of
>           individual, delineated event records as contained within the
>           event stream.  For example, if the notification message
>           contains an instance of a notification defined in YANG, then
>           the top-level element is the name of the YANG notification.
> 
> NEW:
> 
>           The subtree filter is applied to the representation of
>           individual, delineated event records as contained within the
>           event stream.  The top-level element in the event record is
>           the name of the YANG notification.
> 
> and
> 
> OLD:
> 
>            The XPath expression is evaluated on the representation of
>            individual, delineated event records as contained within
>            the event stream.  For example, if the notification message
>            contains an instance of a notification defined in YANG,
>            then the top-level element is the name of the YANG
>            notification, and the root node has this top-level element
>            as the only child.
> 
> NEW:
> 
> 
>            The XPath expression is evaluated on the representation of
>            individual, delineated event records as contained within
>            the event stream.  The top-level element in the event
>            record is the name of the YANG notification, and the root
>            node has this top-level element as the only child.


This text is problematic b/c it doesn't work well with inline
notifications.

Consider the example in section 7.16.3 in RFC 7950:

       container interfaces {
         list interface {
           key "name";
           leaf name {
             type string;
           }
           notification interface-enabled {
             leaf by-user {
               type string;
             }
           }
         }
       }
       
and corresponding XML example:

     
       2008-07-08T00:01:00Z
       
         
           eth1
           
             fred
           
         
       
     

What, in this example, is the "event record"?  I assume it is this
part:

       
         
           eth1
           
             fred
           
         
       

But the element that is the name of the YANG notification is this:

           
             fred
           


(With draft-ietf-netconf-notification-message, the "event record"
would be placed in the  anydata)


A problem is that the containment hierarchy is defined in RFC 7950 in
the XML encoding text.  There is no text in RFC 7951 or RFC 8040 for
how to do this in JSON for RESTCONF.  It is natural to do a pure
JSON-translation of the XML example, but this isn't specified
anywhere.


So I propose the following tweaked changes:


OLD:

   An event stream is a named entity on a publisher which exposes a
   continuously updating set of event records.  Each event stream is
   available for subscription.  It is out of the scope of this document
   to identify a) how streams are defined (other than the NETCONF
   stream), b) how event records are defined/generated, and c) how event
   records are assigned to streams.

NEW:

   An event stream is a named entity on a publisher which exposes a
   continuously updating set of event records.  An event record is an
   intantiation of a "notification" YANG statement.  If the
   "notification" is defined as a child to a data node, the
   intantiation includes the hierarchy of nodes that identifies the
   data node in the datastore (see Section 7.16.2 of RFC 7950).  Each
   event stream is available for subscription.  It is out of the scope
   of this document to identify a) how streams are defined (other than
   the NETCONF stream), b) how event records are generated, and c) how
   event records are assigned to streams.


and in the YANG module:

OLD:

          The subtree filter is applied to the representation of
          individual, delineated event records as contained within the
          event stream.  For example, if the notification message
          contains an instance of a notification defined in YANG, then
          the top-level element is the name of the YANG notification.

NEW:

          The subtree filter is applied to the representation of
          individual, delineated event records as contained within the
          event stream.

and

OLD:

           The XPath expression is evaluated on the representation of
           individual, delineated event records as contained within
           the event stream.  For example, if the notification message
           contains an instance of a notification defined in YANG,
           then the top-level element is the name of the YANG
           notification, and the root node has this top-level element
           as the only child.

NEW:


           The XPath expression is evaluated on the representation of
           individual, delineated event records as contained within
           the event stream.

> (I think it would be useful with some filtering examples, like in
> section 5 of RFC 5277, but I think you have all examples in
> netconf-notif, so they would go into that draft.  (re-reading an old
> thread I found that examples for filters were requested before)).

And I strongly think that we should add examples in an appendix, even
though this is a protocol and encoding neutral document.  Maybe one
example with NETCONF XML and one with RESTCONF JSON.  One example can
show a subtree filter and a top-level notif, and the other an XPath
filter with an inline notif.



/martin


From nobody Thu Sep 13 08:08:19 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD608130DD3 for ; Thu, 13 Sep 2018 08:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_HIGH=-0.01, 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 VnGsGbCoqBmt for ; Thu, 13 Sep 2018 08:08:14 -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 4AB4D130DD1 for ; Thu, 13 Sep 2018 08:08:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11994; q=dns/txt; s=iport; t=1536851294; x=1538060894; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=X2idoFflyNPLXC8Wm4BBuo688m2x6heKYsw/yCUEuUQ=; b=WXA5j1oudpSkpEQo+2OQ2A66XMBDGJPehiBqmu1K6ONtTi+i9C+k90v8 zcxlqitRKUa+FuqpN5veQDKf+coaKpqUnaWWfj0oiVkM5vXI7rsa7Xuhz ZpnkTqkCoCKGQtqLv8ME4Cx0fMtP7fp/FUGjXMOwknCNP6W5uKRYjdvuY E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5AABrfJpb/4QNJK1RChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGBT4FdKmV/KAqYFYINlj6BegsjhANGAoNXITUXAQIBAQI?= =?us-ascii?q?BAQJtHAyFOAEBAQECATo9AgULAgEIDgcDDREQMiUCBA4FCIJOTIF5CA+nEIo?= =?us-ascii?q?JBYpoF4FBP4ESgxKDGwIBgTULAQGFdgKIOIUWjglPCQKGOYlNH4FBh0iFeot?= =?us-ascii?q?OiD4CERSBJR4BNoFVcBU7gmyGAYUUhT5vAYtggR+BHgEB?=
X-IronPort-AV: E=Sophos;i="5.53,369,1531785600"; d="scan'208";a="171475484"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 15:08:13 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w8DF8Cus019875 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Sep 2018 15:08:13 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 13 Sep 2018 11:08:12 -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.1395.000; Thu, 13 Sep 2018 11:08:12 -0400
From: "Eric Voit (evoit)" 
To: Martin Bjorklund 
CC: "netconf@ietf.org" , "Reshad Rahman (rrahman)" 
Thread-Topic: [Netconf] mbj's WGLC review of subscribed-notifications-16
Thread-Index: AQHUSS2c6fWPWMQnpECqHWzj9l2RFqTpyY1wgALe1QCAACWmwIABR3cAgAB1RYD//78NEA==
Date: Thu, 13 Sep 2018 15:08:11 +0000
Message-ID: 
References: <20180912.113446.2017030234338816835.mbj@tail-f.com> <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com> <20180913.092134.395462318086733174.mbj@tail-f.com> <20180913.162117.1031242545011500593.mbj@tail-f.com>
In-Reply-To: <20180913.162117.1031242545011500593.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.234]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.141, xch-rtp-001.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 15:08:17 -0000

Hi Martin,

I am fine with the three text clarifications proposed, and will incorporate=
.   More in-line...

> From: Martin Bjorklund, September 13, 2018 10:21 AM
>=20
> Hi,
>=20
> One problematic thing below.
>=20
> Martin Bjorklund  wrote:
> > Hi,
> >
> > Thank you for addressing my comments.  More inline.
> >
> >
> > "Eric Voit (evoit)"  wrote:
> > > Hi Martin,
> > >
> > > Much incorporated.  Latest is at:
> > > https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netc
> > > onf-subscribed-notifications-17.txt
> > >
> > > Specific responses in-line...
> > >
> > > > From: Martin Bjorklund, September 12, 2018 5:35 AM
> > > >
> > > > "Eric Voit (evoit)"  wrote:
> > > > > Thanks for the comments Martin,  thoughts in-line...
> > > > >
> > > > > > From: Martin Bjorklund, September 10, 2018 1:42 PM
> > > >
> > > > [...]
> > > >
> > > > > > o  Section 2.1
> > > > > >
> > > > > >   The text says:
> > > > > >
> > > > > >     It is out of the scope of this document
> > > > > >     to identify [...] b) how event records are defined
> > > > > >
> > > > > >   Is this really what we want?  Shouldn't this document specify=
 that
> > > > > >   an event record is an instance of a YANG "notification" state=
ment?
> > > > > >   Do we want to support event records that are not defined in Y=
ANG?
> > > > > >
> > > > > >   This was discussed in the thread "comments on
> > > > > >   draft-ietf-netconf-subscribed-notifications-12", and it seems=
 that
> > > > > >   noone really have any use case for non-YANG-defined event rec=
ords,
> > > > > >   accessed with YANG-defined operations.
> > > > >
> > > > > Yes this was discussed previously.  My reading was that others
> > > > > wanted to support subscription to non-YANG events.
> > > > > E.g., see Andy & Tianran's thoughts in
> > > > > https://www.ietf.org/mail-archive/web/netconf/current/msg14764.h
> > > > > tml
> > > >
> > > > Yes, but read on in that thread, see
> > > > https://www.ietf.org/mail-archive/web/netconf/current/msg14766.htm
> > > > l
> > > > for a clarification.
> > > >
> > > > AFAIK, noone has presented a use case for sending non-YANG-defined
> > > > data here.
> > >
> > > As anything can be YANG wrapped, per the thread above.  I am fine
> > > with this.
> > >
> > > > > >   I think that this document should state that an event record =
is an
> > > > > >   instance of a YANG "notification" statement.  If not, it is u=
nclear
> > > > > >   both how subtree/xpath filters and xml/json/... encodings wou=
ld
> work.
> > > > >
> > > > > Applying xpath filters against XML based event records seems
> > > > > viable to me.
> > > >
> > > > Where does it say that it has to be XML?  Whatabout mixed-content?
> > > > What if such a notification is sent when the encoding is JSON?
> > > >
> > > > If you want to make this specification open for other data
> > > > modeling languages, I think you need to carefully define how that
> > > > is supposed to work; essentially similar to how we handle
> > > > transports; we have a set of requirement on what a transport
> > > > document must define.  IMO this is super complicated and overkill.
> > > > This draft is complex enough.
> > > > Don't add even more complexity.
> > >
> > > If you are just saying that we can put everything into a YANG
> > > wrapper, that is fine with me.  To clarify this, I have tweaked the
> > > first sentence of Section 2.1 to:
> > > "An event stream is a named entity on a publisher which exposes a
> > > continuously updating set of YANG encoded event records."
> >
> > Howabout:
> >
> > OLD:
> >
> >    An event stream is a named entity on a publisher which exposes a
> >    continuously updating set of event records.  Each event stream is
> >    available for subscription.  It is out of the scope of this document
> >    to identify a) how streams are defined (other than the NETCONF
> >    stream), b) how event records are defined/generated, and c) how even=
t
> >    records are assigned to streams.
> >
> > NEW:
> >
> >    An event stream is a named entity on a publisher which exposes a
> >    continuously updating set of event records.  An event record is
> >    defined with the "notification" YANG statement.  Each event stream i=
s
> >    available for subscription.  It is out of the scope of this document
> >    to identify a) how streams are defined (other than the NETCONF
> >    stream), b) how event records are generated, and c) how event
> >    records are assigned to streams.
> >
> > > And I have tweaked the first sentence of the third paragraph to:
> > > "As YANG encoded event records are created by a system,..."
> >
> > I think the original sentence is better.
> >
> > Also, some tweaks are needed to the filter leafs in the YANG module:
> >
> > OLD:
> >
> >           The subtree filter is applied to the representation of
> >           individual, delineated event records as contained within the
> >           event stream.  For example, if the notification message
> >           contains an instance of a notification defined in YANG, then
> >           the top-level element is the name of the YANG notification.
> >
> > NEW:
> >
> >           The subtree filter is applied to the representation of
> >           individual, delineated event records as contained within the
> >           event stream.  The top-level element in the event record is
> >           the name of the YANG notification.
> >
> > and
> >
> > OLD:
> >
> >            The XPath expression is evaluated on the representation of
> >            individual, delineated event records as contained within
> >            the event stream.  For example, if the notification message
> >            contains an instance of a notification defined in YANG,
> >            then the top-level element is the name of the YANG
> >            notification, and the root node has this top-level element
> >            as the only child.
> >
> > NEW:
> >
> >
> >            The XPath expression is evaluated on the representation of
> >            individual, delineated event records as contained within
> >            the event stream.  The top-level element in the event
> >            record is the name of the YANG notification, and the root
> >            node has this top-level element as the only child.
>=20
>=20
> This text is problematic b/c it doesn't work well with inline notificatio=
ns.
>=20
> Consider the example in section 7.16.3 in RFC 7950:
>=20
>        container interfaces {
>          list interface {
>            key "name";
>            leaf name {
>              type string;
>            }
>            notification interface-enabled {
>              leaf by-user {
>                type string;
>              }
>            }
>          }
>        }
>=20
> and corresponding XML example:
>=20
>              xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0">
>        2008-07-08T00:01:00Z
>        
>          
>            eth1
>            
>              fred
>            
>          
>        
>      
>=20
> What, in this example, is the "event record"?  I assume it is this
> part:
>=20
>        
>          
>            eth1
>            
>              fred
>            
>          
>        
>=20
> But the element that is the name of the YANG notification is this:
>=20
>            
>              fred
>            
>=20
>=20
> (With draft-ietf-netconf-notification-message, the "event record"
> would be placed in the  anydata)
>=20
>=20
> A problem is that the containment hierarchy is defined in RFC 7950 in the=
 XML
> encoding text.  There is no text in RFC 7951 or RFC 8040 for how to do th=
is in
> JSON for RESTCONF.  It is natural to do a pure JSON-translation of the XM=
L
> example, but this isn't specified anywhere.
>=20
>=20
> So I propose the following tweaked changes:
>=20
>=20
> OLD:
>=20
>    An event stream is a named entity on a publisher which exposes a
>    continuously updating set of event records.  Each event stream is
>    available for subscription.  It is out of the scope of this document
>    to identify a) how streams are defined (other than the NETCONF
>    stream), b) how event records are defined/generated, and c) how event
>    records are assigned to streams.
>=20
> NEW:
>=20
>    An event stream is a named entity on a publisher which exposes a
>    continuously updating set of event records.  An event record is an
>    intantiation of a "notification" YANG statement.  If the
>    "notification" is defined as a child to a data node, the
>    intantiation includes the hierarchy of nodes that identifies the
>    data node in the datastore (see Section 7.16.2 of RFC 7950).  Each
>    event stream is available for subscription.  It is out of the scope
>    of this document to identify a) how streams are defined (other than
>    the NETCONF stream), b) how event records are generated, and c) how
>    event records are assigned to streams.
>=20
>=20
> and in the YANG module:
>=20
> OLD:
>=20
>           The subtree filter is applied to the representation of
>           individual, delineated event records as contained within the
>           event stream.  For example, if the notification message
>           contains an instance of a notification defined in YANG, then
>           the top-level element is the name of the YANG notification.
>=20
> NEW:
>=20
>           The subtree filter is applied to the representation of
>           individual, delineated event records as contained within the
>           event stream.
>=20
> and
>=20
> OLD:
>=20
>            The XPath expression is evaluated on the representation of
>            individual, delineated event records as contained within
>            the event stream.  For example, if the notification message
>            contains an instance of a notification defined in YANG,
>            then the top-level element is the name of the YANG
>            notification, and the root node has this top-level element
>            as the only child.
>=20
> NEW:
>=20
>=20
>            The XPath expression is evaluated on the representation of
>            individual, delineated event records as contained within
>            the event stream.
>=20
> > (I think it would be useful with some filtering examples, like in
> > section 5 of RFC 5277, but I think you have all examples in
> > netconf-notif, so they would go into that draft.  (re-reading an old
> > thread I found that examples for filters were requested before)).
>
> And I strongly think that we should add examples in an appendix, even tho=
ugh
> this is a protocol and encoding neutral document.  Maybe one example with
> NETCONF XML and one with RESTCONF JSON.  One example can show a
> subtree filter and a top-level notif, and the other an XPath filter with =
an inline
> notif.

We have worked very hard to keep the document protocol agnostic.  Even the =
Appendix A example protocol for configured subscriptions is 'foo'.

If you are ok with it, I am completely fine with adding two such NETCONF XM=
L filtering examples into a new Appendix section A.4 in NETCONF-Notif.  Per=
haps Reshad would be able to do the same for RESTCONF JSON within RESTCONF-=
Notif.

Eric



> /martin


From nobody Thu Sep 13 08:15:32 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D53F130DE8 for ; Thu, 13 Sep 2018 08:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 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, T_DKIMWL_WL_HIGH=-0.01, 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 nU4eUFmBLap9 for ; Thu, 13 Sep 2018 08:15:27 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCCC8130DD8 for ; Thu, 13 Sep 2018 08:15:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47478; q=dns/txt; s=iport; t=1536851726; x=1538061326; h=from:to:subject:date:message-id:mime-version; bh=RvoVy2iUZexrTwg91KCZ93XxsSNhGeWSPvKBG3dLjRE=; b=BtjdMsn+DSIVrGxORRhRB58pSSwizMF2UuilDZ1djY3w1C8toWi0q7PK M6cUW8DiA24kDHu7s9k8gAPHDX8t39mLCZUSfNGMnZ0IbtmCnHe49qIDb hbjtTve3f+ix3WN3GxBbs2Fb6ZPswNItT0O9bZu8KurYzHuN8OYVlkjWD U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AACUfZpb/5FdJa1TBxoBAQEBAQI?= =?us-ascii?q?BAQEBCAEBAQGBUIEPTSomP38oCoNolC2YSxSBYwMLGAEMB4RZg0AhNhYBAgE?= =?us-ascii?q?BAgEBAm0cAQuFYgQGIRgRFAEsARMBCQIELwEnBA8FHASCNUsBgR0DYQ+lV3s?= =?us-ascii?q?zhHKEeiKKaBeBQT+BEicfhVwLAQEBAQEXgTAEgxQxgiYCiCSFF4FHhB2JBwk?= =?us-ascii?q?ChjmFA4RSEQaBQYdIhXqLTog+AhEUgSUkBC2BVXAVZQGCQQkKghIXegECgki?= =?us-ascii?q?FFIU+bwEPgQaKPCmBBQGBHQEB?=
X-IronPort-AV: E=Sophos;i="5.53,369,1531785600";  d="scan'208,217";a="233822524"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 15:15:25 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w8DFFPod004056 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Sep 2018 15:15:25 GMT
Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 13 Sep 2018 11:15:24 -0400
Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1395.000; Thu, 13 Sep 2018 11:15:24 -0400
From: "Tim Jenkins (timjenki)" 
To: "netconf@ietf.org" 
Thread-Topic: last call on draft-ietf-netconf-subscribed-notifications-16
Thread-Index: AQHUS3SYdjH1bOxqTkC41erEdgjQeg==
Date: Thu, 13 Sep 2018 15:15:24 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.174]
Content-Type: multipart/alternative; boundary="_000_E546DB21171F4BC2843CB20544DCA47Fciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: 
Subject: [Netconf] last call on draft-ietf-netconf-subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 15:15:30 -0000

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

R3JlZXRpbmdzLA0KDQpJIGhhdmUgcmVhZCBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1u
b3RpZmljYXRpb25zLTE2IGFuZCBzdXBwb3J0IGl0IGdvaW5nIHRvIElFU0cuDQoNCkkgaGF2ZSBh
IG51bWJlciBvZiBjb21tZW50cywgbW9zdGx5IGV4dHJlbWVseSBtaW5vciBpbiBuYXR1cmUsIGFu
ZCBub25lIG5lZWQgYWZmZWN0IGZvcndhcmQgcHJvZ3Jlc3Mgb2Ygc3Vic2NyaWJlZCBub3RpZmlj
YXRpb25zLg0KDQpUaW0NCg0KPT0+DQoNCkNvbW1lbnRzIG9uIGh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLTE2DQoN
ClNlY3Rpb24gMS4yLCBOb3RpZmljYXRpb24gbWVzc2FnZSBkZWZpbml0aW9uOiByZW1vdmUgdGhl
ICgpIGFyb3VuZCBldmVudChzKQ0KDQpTZWN0aW9uIDEuMi4gTm8gZGVmaW5pdGlvbiBmb3IganVz
dCAic3RyZWFtIjsgdGhlIHdvcmQgc3RyZWFtIGlzIHVzZWQgYWxvbmUgKHdpdGhvdXQgJ2V2ZW50
JyBpbiBmcm9udCBvZiBpdCBpbiBhIGZldyBwbGFjZXMpDQoNClNob3VsZCB0aGlzIHBhcmFncmFw
aCBiZSBpbiB0aGUgVGVybWlub2xvZ3kgc2VjdGlvbj8NCiAgIEFsbCBZQU5HIHRyZWUgZGlhZ3Jh
bXMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IGZvbGxvdyB0aGUgbm90YXRpb24NCiAgIGRlZmluZWQg
aW4gW1JGQzgzNDBdLg0KDQpTZWN0aW9uIDEuMywgcGFyYWdyYXBoIG51bWJlcmVkIDE6IGNoYW5n
ZSAid291bGQgaGF2ZSBlbmFibGVkIiB0byAibWF5IGhhdmUgZW5hYmxlZCIuIFVzZSBvZiB3b3Vs
ZCBpbXBsaWVzIHVzZSBvZiB0aGUgc3VnZ2VzdGVkIGhpbnRzIHdvdWxkIHN1Y2NlZWQsIGFuZCB0
aGlzIGNhbm5vdCBiZSBndWFyYW50ZWVkLiAoVGhpcyB3b3VsZCB0aGVuIGJlIG1vcmUgY29uc2lz
dGVudCB3aXRoIHNhbWUgdGV4dCBpbiBTZWN0aW9uIDIuNC4yLikNCg0KU2VjdGlvbiAxLjMsIHBh
cmFncmFwaCBudW1iZXIgMjogSXQncyBzb3J0IG9mIGEgY2lyY3VsYXIgZGVmaW5pdGlvbjoNCiAg
ICAgICJDb25maWd1cmVkIHN1YnNjcmlwdGlvbnMsIHdoaWNoIGFsbG93IHRoZSBtYW5hZ2VtZW50
IG9mDQogICAgICAgc3Vic2NyaXB0aW9ucyB2aWEgYSBjb25maWd1cmF0aW9uIHNvIHRoYXQgYSBw
dWJsaXNoZXIgY2FuIHNlbmQNCiAgICAgICBub3RpZmljYXRpb24gbWVzc2FnZXMgdG8gYSByZWNl
aXZlciBvZiBhIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uLiINCiAgICAgICBTdWdnZXN0IHJlcGhy
YXNpbmcgYW5kIHJlbW92aW5nIHRoZSAicmVjZWl2ZXIgb2YgYSBjb25maWd1cmVkIHN1YnNjcmlw
dGlvbiIgcGFydC4NCg0KU2VjdGlvbiAxLjMsIHNlY29uZCBsYXN0IHBhcmFncmFwaDogUGFydGx5
IHJlcGVhdHMgc2Vjb25kIGJ1bGxldGVkIHBhcmFncmFwaCwgd2hpY2ggZXhwbGljaXRseSBsaXN0
cyBleGNlcHRpb24gdG8gdGhpcyBzdGF0ZW1lbnQgIlNpbWlsYXJseSwgYSBzdWJzY3JpcHRpb24g
ZXN0YWJsaXNoZWQgdmlhIFJQQyBjYW5ub3QgYmUgbW9kaWZpZWQgdGhyb3VnaCBjb25maWd1cmF0
aW9uIG9wZXJhdGlvbnMiLiBJIHdvdWxkIHN1Z2dlc3QgcmVtb3ZpbmcgZHVwbGljYXRlIHN0YXRl
bWVudHMgZnJvbSB0aGVzZSBwYXJhZ3JhcGhzIHJlZ2FyZGluZyB3aGF0IGNhbiBiZSBjaGFuZ2Vk
Lg0KDQpTZWN0aW9uIDEuNCwgcmVwbGFjZSAidGhlIFJQQyBvcGVyYXRpb25zIGluIHRoaXMgZHJh
ZnQgcmVwbGFjZXMiIHdpdGggInRoZSBSUEMgb3BlcmF0aW9ucyBpbiB0aGlzIGRyYWZ0IHJlcGxh
Y2UiDQoNClNlY3Rpb24gMS40LCByZXBsYWNlICJzaW5nbGUgdHJhbnNwb3J0IHNlc3Npb24NCiAg
ICAgIHRvIGludGVybWl4IG9mIG5vdGlmaWNhdGlvbiBtZXNzYWdlcyIgd2l0aCAic2luZ2xlIHRy
YW5zcG9ydCBzZXNzaW9uDQogICAgICB0byBpbnRlcm1peCBub3RpZmljYXRpb24gbWVzc2FnZXMi
DQoNClNlY3Rpb24gMi4zOiBTZWNvbmQgYnVsbGV0ZWQgcGFyYWdyYXBoIHNlZW0gdG8gaW1wbHkg
dGhhdCB0aGUgd2VpZ2h0aW5nIGlzIHBlci1yZWNlaXZlci4gUGVyaGFwcyByZXBocmFzZSBvciBy
ZWZlciBpbnN0ZWFkIHRvIGRlc2NyaXB0aW9uIGVsc2V3aGVyZS4NCg0KU2VjdGlvbiAyLjM6IElz
IGRzY3Agb3B0aW9uYWw/IE5vdCBzdGF0ZWQgaGVyZSwgYnV0IGlzIGZvciBvdGhlcnMuIFNlZW1z
IGl0IGlzLg0KDQpTZWN0aW9uIDIuNC4xOiBEb2VzIG5vdCBzaG93IHRoZSB0cmFuc2l0aW9uIGRl
c2NyaWJlZCBpbiBzZWNvbmQgbGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiAyLjEsIG9yIHRoZSB0
cmFuc2l0aW9uIGRlc2NyaWJlZCBpbiBzZWNvbmQgbyBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAyLjQu
MS4gQnV0IHRoZSBzZWNvbmQgZG9lc24ndCBleGlzdCBiYXNlZCBvbiBzZWN0aW9uIDIuNC4zOyBp
dCBleHBsaWNpdGx5IHNheXMgdG8gY2hhbmdlIHN0YXRlIGFuZCB0aGVtIG1vdmVkIGltbWVkaWF0
ZWx5IGJhY2sgaWYgbmVlZGVkLCBzbyBwZXJoYXBzIGFkZCBzb21ldGhpbmcgdG8gc2Vjb25kIG8g
cGFyYWdyYXBoIG9mIHNlY3Rpb24gMi40LjEiOg0KDQogICBvICBGYWlsZWQgIm1vZGlmeS1zdWJz
Y3JpcHRpb24iIFJQQ3Mgd2lsbCBsZWF2ZSB0aGUgc3Vic2NyaXB0aW9uIGluDQogICAgICBpdHMg
cHJldmlvdXMgc3RhdGUsIHdpdGggbm8gdmlzaWJsZSBjaGFuZ2UgdG8gYW55IHN0cmVhbWluZw0K
ICAgICAgdXBkYXRlcy4gVGhlIHRyYW5zaXRpb24gdG8gdGhlIHJlY2VpdmVyIGFjdGl2ZSBzdGF0
ZSBhbmQgYmFjayB0bw0KICAgICAgcmVjZWl2ZXIgc3VzcGVuZGVkIHN0YXRlIG1pZ2h0IG5vdCBi
ZSBub3QgZXh0ZXJuYWxseSB2aXNpYmxlLg0KDQpTZWN0aW9uIDIuNC4yLCB0aGlyZCBvIHBhcmFn
cmFwaDogUmVtb3ZlICJOb3RlOiAiIHNpbmNlIHN0YXRlbWVudCBpcyBkZWZpbml0aXZlIGFib3V0
IGJlaGF2aW91ciAoaXQncyBub3QgYSBub3RlKS4NCg0KU2VjdGlvbiAyLjQuNTogU2hvdWxkIHRo
ZXJlIGJlIHNvbWUgbWVudGlvbiBhYm91dCBwZXJtaXNzaW9ucz8NCg0KU2VjdGlvbiAyLjQuNjog
U2hvdWxkIHRoZXJlIGJlIGEgcGVybWlzc2lvbnMgZmFpbHVyZSBlcnJvciBmb3Iga2lsbC1zdWJz
Y3JpcHRpb24/IE9yIGlzIHRoYXQgbW9yZSBnZW5lcmljPyBNZWFuaW5nLCBpcyBjb21tYW5kIGV4
ZWN1dGlvbiBwZXJtaXNzaW9uIGVuZm9yY2VtZW50IG5vdCBwYXJ0IG9mIHRoaXMgc3BlY2lmaWNh
dGlvbj8NCg0KU2VjdGlvbiAyLjU6IFNob3VsZCB0aGlzDQogICAgICAiYW4gYWJpbGl0eSB0byBz
ZW5kIG5vdGlmaWNhdGlvbiBtZXNzYWdlcyB0byBtb3JlIHRoYW4gb25lIHJlY2VpdmVyDQogICAg
ICAobm90ZSB0aGF0IHJlY2VpdmVycyBhcmUgdW5hd2FyZSBvZiB0aGUgZXhpc3RlbmNlIG9mIGFu
eSBvdGhlcg0KICAgICAgcmVjZWl2ZXJzLikiDQpiZSBjaGFuZ2VkIHRvIHNvbWV0aGluZyBsaWtl
IHRoaXMNCiAgICAgICJhbiBhYmlsaXR5IHRvIHNlbmQgbm90aWZpY2F0aW9uIG1lc3NhZ2VzIHRv
IG1vcmUgdGhhbiBvbmUgcmVjZWl2ZXIuDQogICAgICBSZWNlaXZlcnMgTVVTVCBub3QgYmUgYXdh
cmUgb2YgdGhlIGV4aXN0ZW5jZSBvZiBvdGhlciByZWNlaXZlcnMuDQogICAgICAiPw0KDQoyLjUu
MSwgcmVjZWl2ZXIgc3RhdGU6IEkgdGhpbmsgSSBwcmVmZXIgdGhlIHN0YXRlICJyZWNlaXZlciBk
aXNjb25uZWN0ZWQiIG92ZXIgInJlY2VpdmVyIHRpbWVvdXQiIHNpbmNlIHRoZXJlIGFyZSBtb3Jl
IHJlYXNvbnMgYSByZWNlaXZlciB3b3VsZCBiZSBkaXNjb25uZWN0ZWQuIFdoaWxlIHRoZSB0ZXh0
IHNheXMgdGhlIHN0YXRlcyBhcmUgb25seSBtZWFuaW5nZnVsIHdoZW4gdGhlIHN1YnNjcmlwdGlv
biBzdGF0ZSBpcyB2YWxpZCwgaW4gcHJhY3Rpc2UgcmVjZWl2ZXJzIG9mIGludmFsaWQgc3Vic2Ny
aXB0aW9ucyB3aWxsIGhhdmUgc3RhdGUgYXMgd2VsbCwgYW5kICJ0aW1lb3V0IiBpc24ndCByZWFs
bHkgdHJ1ZS4gRnVydGhlciwgYW4gaW1wbGVtZW50YXRpb24gbWF5IGNob29zZSB0byBub3QgZXZl
biBjcmVhdGUgY29ubmVjdGlvbnMgdW5kZXIgb3ZlcmxvYWQgY29uZGl0aW9ucywgc28gdGhlIHJl
Y2VpdmVyIHdvbid0IGJlIGp1c3QgInN1c3BlbmRlZCIgbm9yIHdpbGwgaXQgYmUgInRpbWVvdXQi
Lg0KDQpBZGRpdGlvbmFsbHksIHNob3VsZCBpdCBub3QgYmUgc3RhdGVkIHRoYXQgdGhlICJjb25u
ZWN0aW5nIiBzdGF0ZSBpcyBvbmx5IGZvciB3aGVuIHRoZSBwdWJsaXNoZXIgaXMgYWN0aXZlbHkg
dHJ5aW5nIHRvIGNvbm5lY3QgdG8gdGhlIHJlY2VpdmVyPyBUaGlzIHNlbnRlbmNlIHNlZW1zIHRv
IGltcGx5IGl0J3MgbW9yZSB0aGFuIHRoYXQgIkluIGFkZGl0aW9uLCBhIGNvbmZpZ3VyZWQNCiAg
IHN1YnNjcmlwdGlvbidzIHJlY2VpdmVyIE1VU1QgYmUgbW92ZWQgdG8gY29ubmVjdGluZyBpZiB0
cmFuc3BvcnQNCiAgIGNvbm5lY3Rpdml0eSBjYW5ub3QgYmUgYWNoaWV2ZWQsIG9yIC4uLiIgT3Ig
bWF5YmUgdGhlICJjYW5ub3QiIGNvbmZ1c2VzIG1lOiBjYW5ub3QgYmVmb3JlIHRpbWVvdXQgaXMg
cmVhbGx5IHdoYXQgaXMgbWVhbnQ/DQoNClNlY3Rpb24gMi41LjINCg0KTGFzdCBwYXJhZ3JhcGgg
c2F5cyB0aGF0IHJlcGxheSBpcyBzdXBwb3J0ZWQgb24gY29uZmlndXJlZCBzdWJzY3JpcHRpb25z
LiBTbyB3aHkgdGhpcyBzdGF0ZW1lbnQgaW4gc2VjdGlvbiAyLjU/ICJPbiBhIHJlY2VpdmVyIG9m
IGENCiAgIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uLCBzdXBwb3J0IGZvciBkeW5hbWljIHN1YnNj
cmlwdGlvbnMgaXMNCiAgIG9wdGlvbmFsIGV4Y2VwdCB3aGVyZSByZXBsYXlpbmcgbWlzc2VkIGV2
ZW50IHJlY29yZHMgaXMgcmVxdWlyZWQuDQoiDQoNClNlY3Rpb24gMi41LjMsIHNlY29uZCBwYXJh
Z3JhcGg6IFJlY2VpdmVycyB3b3VsZCBvbmx5IGJlIHB1dCBpbnRvIHRoZSBjb25uZWN0aW5nIHN0
YXRlIGlmIHRoZSBwcm90b2NvbCBzcGVjaWZpYyBjYWxsaG9tZSBtZWNoYW5pc20gd2FzIGludm9r
ZWQuIENvdWxkIHRoZXkgbm90IGFsc28gZ28gaW5zdGVhZCB0byB0aGUgYWN0aXZlIHN0YXRlIGlm
IHRoZSBjb25uZWN0aW9uIG5lZWRlZCBhbHJlYWR5IGV4aXN0ZWQ/DQoNClNlY3Rpb24gMi41LjMs
IG1heWJlIGNoYW5nZQ0KIkFsc28gbm90ZSB0aGF0IGlmIG11bHRpcGxlIG1vZGlmaWNhdGlvbnMg
aGF2ZSBvY2N1cnJlZCBkdXJpbmcgdGhlDQogICBzdXNwZW5zaW9uLCBvbmx5IHRoZSBsYXRlc3Qg
b25lIG5lZWQgYmUgc2VudCB0byB0aGUgcmVjZWl2ZXIuIg0KdG8NCiJBbHNvIG5vdGUgdGhhdCBp
ZiBtdWx0aXBsZSBtb2RpZmljYXRpb25zIGhhdmUgb2NjdXJyZWQgZHVyaW5nIHRoZQ0KICAgc3Vz
cGVuc2lvbiwgb25seSB0aGUgInN1YnNjcmlwdGlvbi1tb2RpZmllZCIgbm90aWZpY2F0aW9uIGRl
c2NyaWJpbmcgdGhlIGxhdGVzdCBvbmUgbmVlZCBiZSBzZW50IHRvIHRoZSByZWNlaXZlci4NCiIN
Cg0KU2VjdGlvbiAyLjUuNTogbWF5YmUgY2hhbmdlICJyZS1pbml0aWFsaXphdGlvbiIgdG8gImFj
dGlvbiIgLSBpdCdzIG5vdCByZWFsbHkgYSByZS1pbml0aWFsaXphdGlvbg0KDQpTZWN0aW9uIDIu
NS42LCBmaXJzdCBwYXJhZ3JhcGgsIGxhc3Qgc2VudGVuY2U6IGV2ZW50IC0+IGV2ZW50cw0KDQpT
ZWN0aW9uIDIuNy4yLCBwYXJhZ3JhcGggbnVtYmVyZWQgMjogdGhpcyBjYXNlIHdvdWxkIGFwcGx5
IHRvIGJvdGggZHluYW1pYyBhbmQgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zOyBzdWdnZXN0IHJl
cGhyYXNpbmcgdG8gZGVzY3JpYmUgdGhlIHNpdHVhdGlvbiBhbmQgdGhlbiBzYXlpbmcgdGhhdCBp
dCBhcHBsaWVzIHRvIGJvdGgNCg0KU2VjdGlvbiAyLjgsIG1heWJlIGNoYW5nZQ0KIlRoaXMgbGVh
ZiBhbHNvDQogICBpbmRpY2F0ZXMgaWYgY3VycmVudCBzdGF0ZSBvZiB0aGF0IHN1YnNjcmlwdGlv
biBpcyB2YWxpZCwgaW52YWxpZCwNCiAgIGFuZCBjb25jbHVkZWQuIg0KdG8NCiJUaGlzIGxlYWYg
YWxzbw0KICAgaW5kaWNhdGVzIGlmIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoYXQgc3Vic2NyaXB0
aW9uIGlzIHZhbGlkLCBpbnZhbGlkLA0KICAgb3IgY29uY2x1ZGVkLiINCg0KU2VjdGlvbiAyLjgs
IHBhcmFncmFwaCAzOiByZW1vdmUgImNvbmZpZ3VyZWQgYW5kIGR5bmFtaWMiIGZyb20gZmlyc3Qg
c2VudGVuY2UNCg0KU2VjdGlvbiAyLjgsIHBhcmFncmFwaCAzOiBJcyBpdCBub3QgYSBwb3RlbnRp
YWwgc2VjdXJpdHkgbGVhayB0byBoYXZlIGV2ZW50IG5vdGlmaWNhdGlvbnMgc3VwcHJlc3NlZCBi
eSBwZXJtaXNzaW9ucyBjaGFuZ2UgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgdHdvIGNvdW50
cz8NCg0KU2VjdGlvbiAyLjk6IENoYW5nZQ0KIkluIGFkZGl0aW9uIHN1cHBvcnQgZm9yIG9wdGlv
bmFsIGZlYXR1cmVzICJlbmNvZGUteG1sIiwNCiAgICJlbmNvZGUtanNvbiIsICJjb25maWd1cmVk
IiAic3VwcG9ydHMtdnJmIiwgInFvcyIsICJ4cGF0aCIsDQogICAic3VidHJlZSIsICJpbnRlcmZh
Y2UtZGVzaWduYXRpb24iLCAiZHNjcCIsIGFuZCAicmVwbGF5IiBNVVNUIGJlDQogICBpbmRpY2F0
ZWQgaWYgc3VwcG9ydGVkLiINCnRvDQoiSWYgc3VwcG9ydGVkLCB0aGUgb3B0aW9uYWwgZmVhdHVy
ZXMgImVuY29kZS14bWwiLA0KICAgImVuY29kZS1qc29uIiwgImNvbmZpZ3VyZWQiICJzdXBwb3J0
cy12cmYiLCAicW9zIiwgInhwYXRoIiwNCiAgICJzdWJ0cmVlIiwgImludGVyZmFjZS1kZXNpZ25h
dGlvbiIsICJkc2NwIiwgYW5kICJyZXBsYXkiIE1VU1QgYmUNCiAgIGluZGljYXRlZC4NCiINCg0K
U2VjdGlvbiAzLCB0aGlyZCBzZW50ZW5jZTogcmVtb3ZlIGZpcnN0IHdvcmQgIk9yIg0KDQpTZWN0
aW9uIDQsIGZlYXR1cmVzIGZvciBlbmNvZGluZzogSSBkb24ndCBzZWUgdGhlIHBvaW50IG9mIGds
b2JhbCBmZWF0dXJlcyBmb3Igc2hvd2luZyBzdXBwb3J0IGZvciBlbmNvZGluZ3MuIFRoZSBlbmNv
ZGluZ3MgdGhhdCBhcmUgc3VwcG9ydGVkIGFyZSB0aWVkIHRvIHRoZSBwcm90b2NvbHMgdGhhdCBh
cmUgc3VwcG9ydGVkLCBhbmQgaXQncyB1bmxpa2VseSBhbnkgZW5jb2Rpbmcgd2lsbCBiZSBzdXBw
b3J0ZWQgb3ZlciBhbGwgcHJvdG9jb2xzLg0KDQpTZWN0aW9uIDQsIGZlYXR1cmUgInJlcGxheSI6
IEdpdmVuIHRoYXQgdGhlIHN0cmVhbXMgdGFibGUgc2hvd3Mgd2hpY2ggc3RyZWFtcyBzdXBwb3J0
IHJlcGx5LCBpcyB0aGVyZSBhIG5lZWQgZm9yIHRoaXMgZmVhdHVyZT8NCg0KU2VjdGlvbiA0LCBE
QVRBIE5PREVTOiBsZWFmICJyZXBsYXktbG9nLWNyZWF0aW9uLXRpbWUiIGhhcw0KICAgICAgICB3
aGVuICIuLi9yZXBsYXktc3VwcG9ydCI7DQogICAgICAgIGlmLWZlYXR1cmUgInJlcGxheSI7DQpi
dXQgbGVhZiAicmVwbGF5LWxvZy1hZ2VkLXRpbWUiIGhhcyBvbmx5DQogICAgICAgIGlmLWZlYXR1
cmUgInJlcGxheSI7DQoNClNob3VsZCB0aGV5IGJlIHRoZSBzYW1lPw0KDQpBbHNvLCBpcyB0aGUN
CiAgICAgICAgaWYtZmVhdHVyZSAicmVwbGF5IjsNCm5lZWRlZCBpZg0KICAgICAgICB3aGVuICIu
Li9yZXBsYXktc3VwcG9ydCI7DQppcyB1c2VkIHdoZW4gaXQgaXMgdXNpbmcNCiAgICAgICAgaWYt
ZmVhdHVyZSAicmVwbGF5IjsNCmFscmVhZHk/DQoNClNlY3Rpb24gNCwgImxlYWYgY29uZmlndXJl
ZC1zdWJzY3JpcHRpb24tc3RhdGUiOiBUaGUgZGVzY3JpcHRpb24gZm9yICJlbnVtIHZhbGlkIiBs
b29rcyB3cm9uZy4NCg0KU2VjdGlvbiA0LCAibGVhZiBjb3VudC1zZW50IjogU2hvdWxkIHRoaXMg
YmUgcmVzZXQgdG8gemVybyBvbiByZWNlaXZlciBzdGF0ZSB0cmFuc2l0aW9uIHRvIGFjdGl2ZSBh
cyBvcHBvc2VkIHRvIHN1YnNjcmlwdGlvbiB0cmFuc2l0aW9uIHRvIHZhbGlkPyBKdXN0IGJlY2F1
c2UgdGhlIHN1YnNjcmlwdGlvbiBpcyB2YWxpZCBkb2Vzbid0IG1lYW4gdGhlIHJlY2VpdmVyJ3Mg
YmVpbmcgc2VudCBhbnl0aGluZyBpZiB0aGUgY29ubmVjdGlvbiBpc24ndCB1cC4NCg0KU2VjdGlv
biA1LjQ6ICJkaXNjb3ZlcmVkLHRha2UiIHRvICJkaXNjb3ZlcmVkLCB0YWtlIg0KDQoNCi0tDQpD
aXNjbyBTeXN0ZW1zIENhbmFkYSBDby4NCjIwMDAgSW5ub3ZhdGlvbiBEcml2ZQ0KS2FuYXRhLCBP
TiwgQ2FuYWRhLCBLMksgM0U4DQpQcmVmZXJlbmNlcyA8aHR0cDovL3d3dy5jaXNjby5jb20vb2Zm
ZXIvc3Vic2NyaWJlLz9zaWQ9MDAwNDc4MzI2Pg0KVW5zdWJzY3JpYmUgPGh0dHA6Ly93d3cuY2lz
Y28uY29tL29mZmVyL3Vuc3Vic2NyaWJlLz9zaWQ9MDAwNDc4MzI3Pg0KUHJpdmFjeSA8aHR0cDov
L3d3dy5jaXNjby5jb20vd2ViL3NpdGVhc3NldHMvbGVnYWwvcHJpdmFjeS5odG1sPg0KDQo=

--_000_E546DB21171F4BC2843CB20544DCA47Fciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <8D1E0690CCD4814D96F4384D99C3F83C@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K
CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNv
bXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93
dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7
c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw
dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg
ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N
Cjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2
IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5HcmVldGluZ3MsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkg
aGF2ZSByZWFkIGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMtMTYg
YW5kIHN1cHBvcnQgaXQgZ29pbmcgdG8gSUVTRy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBoYXZlIGEgbnVtYmVy
IG9mIGNvbW1lbnRzLCBtb3N0bHkgZXh0cmVtZWx5IG1pbm9yIGluIG5hdHVyZSwgYW5kIG5vbmUg
bmVlZCBhZmZlY3QgZm9yd2FyZCBwcm9ncmVzcyBvZiBzdWJzY3JpYmVkIG5vdGlmaWNhdGlvbnMu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPlRpbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+w6g8L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+Q29tbWVudHMgb24gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0
Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMtMTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2VjdGlvbiAxLjIs
IE5vdGlmaWNhdGlvbiBtZXNzYWdlIGRlZmluaXRpb246IHJlbW92ZSB0aGUgKCkgYXJvdW5kIGV2
ZW50KHMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPlNlY3Rpb24gMS4yLiBObyBkZWZpbml0aW9uIGZvciBqdXN0ICZx
dW90O3N0cmVhbSZxdW90OzsgdGhlIHdvcmQgc3RyZWFtIGlzIHVzZWQgYWxvbmUgKHdpdGhvdXQg
J2V2ZW50JyBpbiBmcm9udCBvZiBpdCBpbiBhIGZldyBwbGFjZXMpPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNob3Vs
ZCB0aGlzIHBhcmFncmFwaCBiZSBpbiB0aGUgVGVybWlub2xvZ3kgc2VjdGlvbj88bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBBbGwgWUFORyB0cmVlIGRpYWdyYW1z
IHVzZWQgaW4gdGhpcyBkb2N1bWVudCBmb2xsb3cgdGhlIG5vdGF0aW9uPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgZGVmaW5lZCBpbiBbUkZDODM0MF0uPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPlNlY3Rpb24gMS4zLCBwYXJhZ3JhcGggbnVtYmVyZWQgMTogY2hhbmdlICZxdW90O3dv
dWxkIGhhdmUgZW5hYmxlZCZxdW90OyB0byAmcXVvdDttYXkgaGF2ZSBlbmFibGVkJnF1b3Q7LiBV
c2Ugb2Ygd291bGQgaW1wbGllcyB1c2Ugb2YgdGhlIHN1Z2dlc3RlZCBoaW50cyB3b3VsZCBzdWNj
ZWVkLCBhbmQgdGhpcyBjYW5ub3QgYmUgZ3VhcmFudGVlZC4gKFRoaXMgd291bGQNCiB0aGVuIGJl
IG1vcmUgY29uc2lzdGVudCB3aXRoIHNhbWUgdGV4dCBpbiBTZWN0aW9uIDIuNC4yLik8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+U2VjdGlvbiAxLjMsIHBhcmFncmFwaCBudW1iZXIgMjogSXQncyBzb3J0IG9mIGEgY2ly
Y3VsYXIgZGVmaW5pdGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtDb25maWd1cmVkIHN1YnNjcmlwdGlvbnMsIHdo
aWNoIGFsbG93IHRoZSBtYW5hZ2VtZW50IG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3Vic2NyaXB0aW9ucyB2aWEg
YSBjb25maWd1cmF0aW9uIHNvIHRoYXQgYSBwdWJsaXNoZXIgY2FuIHNlbmQ8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBu
b3RpZmljYXRpb24gbWVzc2FnZXMgdG8gYSByZWNlaXZlciBvZiBhIGNvbmZpZ3VyZWQgc3Vic2Ny
aXB0aW9uLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN1Z2dlc3QgcmVwaHJhc2luZyBhbmQgcmVtb3Zpbmcg
dGhlICZxdW90O3JlY2VpdmVyIG9mIGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24mcXVvdDsgcGFy
dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+U2VjdGlvbiAxLjMsIHNlY29uZCBsYXN0IHBhcmFncmFwaDogUGFydGx5
IHJlcGVhdHMgc2Vjb25kIGJ1bGxldGVkIHBhcmFncmFwaCwgd2hpY2ggZXhwbGljaXRseSBsaXN0
cyBleGNlcHRpb24gdG8gdGhpcyBzdGF0ZW1lbnQgJnF1b3Q7U2ltaWxhcmx5LCBhIHN1YnNjcmlw
dGlvbiBlc3RhYmxpc2hlZCB2aWEgUlBDIGNhbm5vdCBiZSBtb2RpZmllZA0KIHRocm91Z2ggY29u
ZmlndXJhdGlvbiBvcGVyYXRpb25zJnF1b3Q7LiBJIHdvdWxkIHN1Z2dlc3QgcmVtb3ZpbmcgZHVw
bGljYXRlIHN0YXRlbWVudHMgZnJvbSB0aGVzZSBwYXJhZ3JhcGhzIHJlZ2FyZGluZyB3aGF0IGNh
biBiZSBjaGFuZ2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TZWN0aW9uIDEuNCwgcmVwbGFjZSAmcXVvdDt0aGUg
UlBDIG9wZXJhdGlvbnMgaW4gdGhpcyBkcmFmdCByZXBsYWNlcyZxdW90OyB3aXRoICZxdW90O3Ro
ZSBSUEMgb3BlcmF0aW9ucyBpbiB0aGlzIGRyYWZ0IHJlcGxhY2UmcXVvdDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
U2VjdGlvbiAxLjQsIHJlcGxhY2UgJnF1b3Q7c2luZ2xlIHRyYW5zcG9ydCBzZXNzaW9uPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
dG8gaW50ZXJtaXggb2Ygbm90aWZpY2F0aW9uIG1lc3NhZ2VzJnF1b3Q7IHdpdGggJnF1b3Q7c2lu
Z2xlIHRyYW5zcG9ydCBzZXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gaW50ZXJtaXggbm90aWZpY2F0aW9uIG1lc3Nh
Z2VzJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNlY3Rpb24gMi4zOiBTZWNvbmQgYnVsbGV0ZWQgcGFyYWdy
YXBoIHNlZW0gdG8gaW1wbHkgdGhhdCB0aGUgd2VpZ2h0aW5nIGlzIHBlci1yZWNlaXZlci4gUGVy
aGFwcyByZXBocmFzZSBvciByZWZlciBpbnN0ZWFkIHRvIGRlc2NyaXB0aW9uIGVsc2V3aGVyZS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+U2VjdGlvbiAyLjM6IElzIGRzY3Agb3B0aW9uYWw/IE5vdCBzdGF0ZWQgaGVy
ZSwgYnV0IGlzIGZvciBvdGhlcnMuIFNlZW1zIGl0IGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TZWN0aW9uIDIu
NC4xOiBEb2VzIG5vdCBzaG93IHRoZSB0cmFuc2l0aW9uIGRlc2NyaWJlZCBpbiBzZWNvbmQgbGFz
dCBwYXJhZ3JhcGggb2YgU2VjdGlvbiAyLjEsIG9yIHRoZSB0cmFuc2l0aW9uIGRlc2NyaWJlZCBp
biBzZWNvbmQgbyBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAyLjQuMS4gQnV0IHRoZSBzZWNvbmQgZG9l
c24ndCBleGlzdA0KIGJhc2VkIG9uIHNlY3Rpb24gMi40LjM7IGl0IGV4cGxpY2l0bHkgc2F5cyB0
byBjaGFuZ2Ugc3RhdGUgYW5kIHRoZW0gbW92ZWQgaW1tZWRpYXRlbHkgYmFjayBpZiBuZWVkZWQs
IHNvIHBlcmhhcHMgYWRkIHNvbWV0aGluZyB0byBzZWNvbmQgbyBwYXJhZ3JhcGggb2Ygc2VjdGlv
biAyLjQuMSZxdW90Ozo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgRmFpbGVkICZx
dW90O21vZGlmeS1zdWJzY3JpcHRpb24mcXVvdDsgUlBDcyB3aWxsIGxlYXZlIHRoZSBzdWJzY3Jp
cHRpb24gaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBpdHMgcHJldmlvdXMgc3RhdGUsIHdpdGggbm8gdmlzaWJsZSBjaGFuZ2Ug
dG8gYW55IHN0cmVhbWluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVwZGF0ZXMuIFRoZSB0cmFuc2l0aW9uIHRvIHRoZSByZWNl
aXZlciBhY3RpdmUgc3RhdGUgYW5kIGJhY2sgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWNlaXZlciBzdXNwZW5kZWQgc3Rh
dGUgbWlnaHQgbm90IGJlIG5vdCBleHRlcm5hbGx5IHZpc2libGUuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNlY3Rp
b24gMi40LjIsIHRoaXJkIG8gcGFyYWdyYXBoOiBSZW1vdmUgJnF1b3Q7Tm90ZTogJnF1b3Q7IHNp
bmNlIHN0YXRlbWVudCBpcyBkZWZpbml0aXZlIGFib3V0IGJlaGF2aW91ciAoaXQncyBub3QgYSBu
b3RlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+U2VjdGlvbiAyLjQuNTogU2hvdWxkIHRoZXJlIGJlIHNvbWUgbWVu
dGlvbiBhYm91dCBwZXJtaXNzaW9ucz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2VjdGlvbiAyLjQuNjogU2hvdWxk
IHRoZXJlIGJlIGEgcGVybWlzc2lvbnMgZmFpbHVyZSBlcnJvciBmb3Iga2lsbC1zdWJzY3JpcHRp
b24/IE9yIGlzIHRoYXQgbW9yZSBnZW5lcmljPyBNZWFuaW5nLCBpcyBjb21tYW5kIGV4ZWN1dGlv
biBwZXJtaXNzaW9uIGVuZm9yY2VtZW50IG5vdCBwYXJ0IG9mIHRoaXMgc3BlY2lmaWNhdGlvbj88
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+U2VjdGlvbiAyLjU6IFNob3VsZCB0aGlzPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7YW4gYWJpbGl0
eSB0byBzZW5kIG5vdGlmaWNhdGlvbiBtZXNzYWdlcyB0byBtb3JlIHRoYW4gb25lIHJlY2VpdmVy
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgKG5vdGUgdGhhdCByZWNlaXZlcnMgYXJlIHVuYXdhcmUgb2YgdGhlIGV4aXN0ZW5jZSBv
ZiBhbnkgb3RoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyByZWNlaXZlcnMuKSZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+YmUgY2hhbmdlZCB0byBzb21ldGhpbmcgbGlrZSB0aGlzPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7YW4g
YWJpbGl0eSB0byBzZW5kIG5vdGlmaWNhdGlvbiBtZXNzYWdlcyB0byBtb3JlIHRoYW4gb25lIHJl
Y2VpdmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IFJlY2VpdmVycyBNVVNUIG5vdCBiZSBhd2FyZSBvZiB0aGUgZXhpc3RlbmNl
IG9mIG90aGVyIHJlY2VpdmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjIuNS4xLCByZWNl
aXZlciBzdGF0ZTogSSB0aGluayBJIHByZWZlciB0aGUgc3RhdGUgJnF1b3Q7cmVjZWl2ZXIgZGlz
Y29ubmVjdGVkJnF1b3Q7IG92ZXIgJnF1b3Q7cmVjZWl2ZXIgdGltZW91dCZxdW90OyBzaW5jZSB0
aGVyZSBhcmUgbW9yZSByZWFzb25zIGEgcmVjZWl2ZXIgd291bGQgYmUgZGlzY29ubmVjdGVkLiBX
aGlsZSB0aGUgdGV4dCBzYXlzIHRoZSBzdGF0ZXMNCiBhcmUgb25seSBtZWFuaW5nZnVsIHdoZW4g
dGhlIHN1YnNjcmlwdGlvbiBzdGF0ZSBpcyB2YWxpZCwgaW4gcHJhY3Rpc2UgcmVjZWl2ZXJzIG9m
IGludmFsaWQgc3Vic2NyaXB0aW9ucyB3aWxsIGhhdmUgc3RhdGUgYXMgd2VsbCwgYW5kICZxdW90
O3RpbWVvdXQmcXVvdDsgaXNuJ3QgcmVhbGx5IHRydWUuIEZ1cnRoZXIsIGFuIGltcGxlbWVudGF0
aW9uIG1heSBjaG9vc2UgdG8gbm90IGV2ZW4gY3JlYXRlIGNvbm5lY3Rpb25zIHVuZGVyIG92ZXJs
b2FkIGNvbmRpdGlvbnMsDQogc28gdGhlIHJlY2VpdmVyIHdvbid0IGJlIGp1c3QgJnF1b3Q7c3Vz
cGVuZGVkJnF1b3Q7IG5vciB3aWxsIGl0IGJlICZxdW90O3RpbWVvdXQmcXVvdDsuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPkFkZGl0aW9uYWxseSwgc2hvdWxkIGl0IG5vdCBiZSBzdGF0ZWQgdGhhdCB0aGUgJnF1b3Q7
Y29ubmVjdGluZyZxdW90OyBzdGF0ZSBpcyBvbmx5IGZvciB3aGVuIHRoZSBwdWJsaXNoZXIgaXMg
YWN0aXZlbHkgdHJ5aW5nIHRvIGNvbm5lY3QgdG8gdGhlIHJlY2VpdmVyPyBUaGlzIHNlbnRlbmNl
IHNlZW1zIHRvIGltcGx5IGl0J3MgbW9yZSB0aGFuIHRoYXQNCiAmcXVvdDtJbiBhZGRpdGlvbiwg
YSBjb25maWd1cmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsg
c3Vic2NyaXB0aW9uJ3MgcmVjZWl2ZXIgTVVTVCBiZSBtb3ZlZCB0byBjb25uZWN0aW5nIGlmIHRy
YW5zcG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IGNvbm5l
Y3Rpdml0eSBjYW5ub3QgYmUgYWNoaWV2ZWQsIG9yIC4uLiZxdW90OyBPciBtYXliZSB0aGUgJnF1
b3Q7Y2Fubm90JnF1b3Q7IGNvbmZ1c2VzIG1lOiBjYW5ub3QgYmVmb3JlIHRpbWVvdXQgaXMgcmVh
bGx5IHdoYXQgaXMgbWVhbnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNlY3Rpb24gMi41LjI8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
TGFzdCBwYXJhZ3JhcGggc2F5cyB0aGF0IHJlcGxheSBpcyBzdXBwb3J0ZWQgb24gY29uZmlndXJl
ZCBzdWJzY3JpcHRpb25zLiBTbyB3aHkgdGhpcyBzdGF0ZW1lbnQgaW4gc2VjdGlvbiAyLjU/ICZx
dW90O09uIGEgcmVjZWl2ZXIgb2YgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i
c3A7Jm5ic3A7IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uLCBzdXBwb3J0IGZvciBkeW5hbWljIHN1
YnNjcmlwdGlvbnMgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNw
OyBvcHRpb25hbCBleGNlcHQgd2hlcmUgcmVwbGF5aW5nIG1pc3NlZCBldmVudCByZWNvcmRzIGlz
IHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+JnF1b3Q7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPlNlY3Rpb24gMi41LjMsIHNlY29uZCBwYXJhZ3JhcGg6IFJlY2VpdmVycyB3b3VsZCBvbmx5
IGJlIHB1dCBpbnRvIHRoZSBjb25uZWN0aW5nIHN0YXRlIGlmIHRoZSBwcm90b2NvbCBzcGVjaWZp
YyBjYWxsaG9tZSBtZWNoYW5pc20gd2FzIGludm9rZWQuIENvdWxkIHRoZXkgbm90IGFsc28gZ28g
aW5zdGVhZCB0byB0aGUgYWN0aXZlIHN0YXRlDQogaWYgdGhlIGNvbm5lY3Rpb24gbmVlZGVkIGFs
cmVhZHkgZXhpc3RlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2VjdGlvbiAyLjUuMywgbWF5YmUgY2hhbmdlDQo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZxdW90O0Fsc28gbm90ZSB0aGF0IGlmIG11
bHRpcGxlIG1vZGlmaWNhdGlvbnMgaGF2ZSBvY2N1cnJlZCBkdXJpbmcgdGhlPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgc3VzcGVuc2lvbiwgb25seSB0aGUgbGF0
ZXN0IG9uZSBuZWVkIGJlIHNlbnQgdG8gdGhlIHJlY2VpdmVyLiZxdW90OzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+dG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZxdW90
O0Fsc28gbm90ZSB0aGF0IGlmIG11bHRpcGxlIG1vZGlmaWNhdGlvbnMgaGF2ZSBvY2N1cnJlZCBk
dXJpbmcgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgc3Vz
cGVuc2lvbiwgb25seSB0aGUgJnF1b3Q7c3Vic2NyaXB0aW9uLW1vZGlmaWVkJnF1b3Q7IG5vdGlm
aWNhdGlvbiBkZXNjcmliaW5nIHRoZSBsYXRlc3Qgb25lIG5lZWQgYmUgc2VudCB0byB0aGUgcmVj
ZWl2ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mcXVvdDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
U2VjdGlvbiAyLjUuNTogbWF5YmUgY2hhbmdlICZxdW90O3JlLWluaXRpYWxpemF0aW9uJnF1b3Q7
IHRvICZxdW90O2FjdGlvbiZxdW90OyAtIGl0J3Mgbm90IHJlYWxseSBhIHJlLWluaXRpYWxpemF0
aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPlNlY3Rpb24gMi41LjYsIGZpcnN0IHBhcmFncmFwaCwgbGFzdCBzZW50
ZW5jZTogZXZlbnQgLSZndDsgZXZlbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNlY3Rpb24gMi43LjIsIHBhcmFn
cmFwaCBudW1iZXJlZCAyOiB0aGlzIGNhc2Ugd291bGQgYXBwbHkgdG8gYm90aCBkeW5hbWljIGFu
ZCBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnM7IHN1Z2dlc3QgcmVwaHJhc2luZyB0byBkZXNjcmli
ZSB0aGUgc2l0dWF0aW9uIGFuZCB0aGVuIHNheWluZyB0aGF0IGl0IGFwcGxpZXMgdG8gYm90aDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij5TZWN0aW9uIDIuOCwgbWF5YmUgY2hhbmdlPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij4mcXVvdDtUaGlzIGxlYWYgYWxzbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+Jm5ic3A7Jm5ic3A7IGluZGljYXRlcyBpZiBjdXJyZW50IHN0YXRlIG9mIHRoYXQgc3Vi
c2NyaXB0aW9uIGlzIHZhbGlkLCBpbnZhbGlkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+Jm5ic3A7Jm5ic3A7IGFuZCBjb25jbHVkZWQuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij50bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+JnF1b3Q7VGhpcyBs
ZWFmIGFsc288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBpbmRp
Y2F0ZXMgaWYgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhhdCBzdWJzY3JpcHRpb24gaXMgdmFsaWQs
IGludmFsaWQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgb3Ig
Y29uY2x1ZGVkLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TZWN0aW9uIDIuOCwgcGFyYWdyYXBoIDM6IHJl
bW92ZSAmcXVvdDtjb25maWd1cmVkIGFuZCBkeW5hbWljJnF1b3Q7IGZyb20gZmlyc3Qgc2VudGVu
Y2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+U2VjdGlvbiAyLjgsIHBhcmFncmFwaCAzOiBJcyBpdCBub3QgYSBwb3Rl
bnRpYWwgc2VjdXJpdHkgbGVhayB0byBoYXZlIGV2ZW50IG5vdGlmaWNhdGlvbnMgc3VwcHJlc3Nl
ZCBieSBwZXJtaXNzaW9ucyBjaGFuZ2UgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgdHdvIGNv
dW50cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+U2VjdGlvbiAyLjk6IENoYW5nZTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+JnF1b3Q7SW4gYWRkaXRpb24gc3VwcG9ydCBmb3Igb3B0aW9uYWwgZmVhdHVy
ZXMgJnF1b3Q7ZW5jb2RlLXhtbCZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PiZuYnNwOyZuYnNwOyAmcXVvdDtlbmNvZGUtanNvbiZxdW90OywgJnF1b3Q7Y29uZmlndXJlZCZx
dW90OyAmcXVvdDtzdXBwb3J0cy12cmYmcXVvdDssICZxdW90O3FvcyZxdW90OywgJnF1b3Q7eHBh
dGgmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgJnF1
b3Q7c3VidHJlZSZxdW90OywgJnF1b3Q7aW50ZXJmYWNlLWRlc2lnbmF0aW9uJnF1b3Q7LCAmcXVv
dDtkc2NwJnF1b3Q7LCBhbmQgJnF1b3Q7cmVwbGF5JnF1b3Q7IE1VU1QgYmU8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBpbmRpY2F0ZWQgaWYgc3VwcG9ydGVkLiZx
dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+dG88bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPiZxdW90O0lmIHN1cHBvcnRlZCwgdGhlIG9wdGlvbmFsIGZlYXR1cmVzICZx
dW90O2VuY29kZS14bWwmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz
cDsmbmJzcDsgJnF1b3Q7ZW5jb2RlLWpzb24mcXVvdDssICZxdW90O2NvbmZpZ3VyZWQmcXVvdDsg
JnF1b3Q7c3VwcG9ydHMtdnJmJnF1b3Q7LCAmcXVvdDtxb3MmcXVvdDssICZxdW90O3hwYXRoJnF1
b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7ICZxdW90O3N1
YnRyZWUmcXVvdDssICZxdW90O2ludGVyZmFjZS1kZXNpZ25hdGlvbiZxdW90OywgJnF1b3Q7ZHNj
cCZxdW90OywgYW5kICZxdW90O3JlcGxheSZxdW90OyBNVVNUIGJlPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgaW5kaWNhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNlY3Rpb24gMywgdGhpcmQgc2VudGVuY2U6
IHJlbW92ZSBmaXJzdCB3b3JkICZxdW90O09yJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNlY3Rpb24gNCwg
ZmVhdHVyZXMgZm9yIGVuY29kaW5nOiBJIGRvbid0IHNlZSB0aGUgcG9pbnQgb2YgZ2xvYmFsIGZl
YXR1cmVzIGZvciBzaG93aW5nIHN1cHBvcnQgZm9yIGVuY29kaW5ncy4gVGhlIGVuY29kaW5ncyB0
aGF0IGFyZSBzdXBwb3J0ZWQgYXJlIHRpZWQgdG8gdGhlIHByb3RvY29scyB0aGF0IGFyZSBzdXBw
b3J0ZWQsIGFuZA0KIGl0J3MgdW5saWtlbHkgYW55IGVuY29kaW5nIHdpbGwgYmUgc3VwcG9ydGVk
IG92ZXIgYWxsIHByb3RvY29scy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2VjdGlvbiA0LCBmZWF0dXJlICZxdW90
O3JlcGxheSZxdW90OzogR2l2ZW4gdGhhdCB0aGUgc3RyZWFtcyB0YWJsZSBzaG93cyB3aGljaCBz
dHJlYW1zIHN1cHBvcnQgcmVwbHksIGlzIHRoZXJlIGEgbmVlZCBmb3IgdGhpcyBmZWF0dXJlPzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij5TZWN0aW9uIDQsIERBVEEgTk9ERVM6IGxlYWYgJnF1b3Q7cmVwbGF5LWxvZy1j
cmVhdGlvbi10aW1lJnF1b3Q7IGhhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoZW4gJnF1b3Q7Li4vcmVw
bGF5LXN1cHBvcnQmcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWYtZmVhdHVyZSAmcXVvdDtyZXBs
YXkmcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5idXQgbGVhZiAmcXVvdDty
ZXBsYXktbG9nLWFnZWQtdGltZSZxdW90OyBoYXMgb25seTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmLWZl
YXR1cmUgJnF1b3Q7cmVwbGF5JnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TaG91bGQgdGhleSBiZSB0aGUg
c2FtZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+QWxzbywgaXMgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWYtZmVhdHVy
ZSAmcXVvdDtyZXBsYXkmcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5uZWVk
ZWQgaWY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGVuICZxdW90Oy4uL3JlcGxheS1zdXBwb3J0JnF1b3Q7
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+aXMgdXNlZCB3aGVuIGl0IGlzIHVzaW5n
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgaWYtZmVhdHVyZSAmcXVvdDtyZXBsYXkmcXVvdDs7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij5hbHJlYWR5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TZWN0aW9uIDQsICZx
dW90O2xlYWYgY29uZmlndXJlZC1zdWJzY3JpcHRpb24tc3RhdGUmcXVvdDs6IFRoZSBkZXNjcmlw
dGlvbiBmb3IgJnF1b3Q7ZW51bSB2YWxpZCZxdW90OyBsb29rcyB3cm9uZy48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
U2VjdGlvbiA0LCAmcXVvdDtsZWFmIGNvdW50LXNlbnQmcXVvdDs6IFNob3VsZCB0aGlzIGJlIHJl
c2V0IHRvIHplcm8gb24gcmVjZWl2ZXIgc3RhdGUgdHJhbnNpdGlvbiB0byBhY3RpdmUgYXMgb3Bw
b3NlZCB0byBzdWJzY3JpcHRpb24gdHJhbnNpdGlvbiB0byB2YWxpZD8gSnVzdCBiZWNhdXNlIHRo
ZSBzdWJzY3JpcHRpb24gaXMgdmFsaWQgZG9lc24ndA0KIG1lYW4gdGhlIHJlY2VpdmVyJ3MgYmVp
bmcgc2VudCBhbnl0aGluZyBpZiB0aGUgY29ubmVjdGlvbiBpc24ndCB1cC48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
U2VjdGlvbiA1LjQ6ICZxdW90O2Rpc2NvdmVyZWQsdGFrZSZxdW90OyB0byAmcXVvdDtkaXNjb3Zl
cmVkLCB0YWtlJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Y29sb3I6YmxhY2siPi0tJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPkNpc2NvIFN5c3Rl
bXMgQ2FuYWRhIENvLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+MjAwMCBJbm5vdmF0aW9uIERyaXZl
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz
O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5LYW5hdGEsIE9OLCBDYW5hZGEsIEsySyAzRTg8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6
YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s
YXM7Y29sb3I6YmxhY2siPlByZWZlcmVuY2VzICZsdDs8YSBocmVmPSJodHRwOi8vd3d3LmNpc2Nv
LmNvbS9vZmZlci9zdWJzY3JpYmUvP3NpZD0wMDA0NzgzMjYiPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bHVlIj5odHRwOi8vd3d3LmNpc2NvLmNvbS9vZmZlci9zdWJzY3JpYmUvP3NpZD0wMDA0NzgzMjY8
L3NwYW4+PC9hPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlVuc3Vic2NyaWJlICZsdDs8YSBo
cmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS9vZmZlci91bnN1YnNjcmliZS8/c2lkPTAwMDQ3ODMy
NyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPmh0dHA6Ly93d3cuY2lzY28uY29tL29mZmVyL3Vu
c3Vic2NyaWJlLz9zaWQ9MDAwNDc4MzI3PC9zcGFuPjwvYT4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJs
YWNrIj5Qcml2YWN5ICZsdDs8YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvc2l0ZWFz
c2V0cy9sZWdhbC9wcml2YWN5Lmh0bWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj5odHRwOi8v
d3d3LmNpc2NvLmNvbS93ZWIvc2l0ZWFzc2V0cy9sZWdhbC9wcml2YWN5Lmh0bWw8L3NwYW4+PC9h
PiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29u
c29sYXM7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_E546DB21171F4BC2843CB20544DCA47Fciscocom_--


From nobody Thu Sep 13 09:00:39 2018
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 C6F661292AD; Thu, 13 Sep 2018 09:00:36 -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.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <153685443672.29568.8200485636086386413@ietfa.amsl.com>
Date: Thu, 13 Sep 2018 09:00:36 -0700
Archived-At: 
Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-25.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 16:00:37 -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           : Zero Touch Provisioning for Networking Devices
        Authors         : Kent Watsen
                          Mikael Abrahamsson
                          Ian Farrer
	Filename        : draft-ietf-netconf-zerotouch-25.txt
	Pages           : 88
	Date            : 2018-09-13

Abstract:
   This draft presents a technique to securely provision a networking
   device when it is booting in a factory-default state.  Variations in
   the solution enables 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.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-25


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

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


From nobody Thu Sep 13 09:08:03 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5957B130E23 for ; Thu, 13 Sep 2018 09:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.308
X-Spam-Level: 
X-Spam-Status: No, score=-4.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 header.b=N4XhkiAf; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=I6BZFD7d
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSYTdVIjVsp0 for ; Thu, 13 Sep 2018 09:07:57 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF8D130DFF for ; Thu, 13 Sep 2018 09:07:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536854875; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aIZtV0Gfny171FgIGVx43g46GRunn4CdZ+ipm24cNgM=; b=N4XhkiAftFLIdlgDkZk8tiiDTo2/lZZTGwgk5ZWPG8BvQZokAKUipsMC/jCOb6Uy BD9ujrfUhfTo2vL/GFb5IRloktCTUp3NsE5zZfzDjiCjWMOryR6nnF7c6BULijdf 971k6ZFK8dWz3qoVPZC53urvitytuNgorQi6KXfVGK8=;
X-AuditID: c1b4fb30-3cd869c0000055da-91-5b9a8b5bcde1
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 93.FF.21978.B5B8A9B5; Thu, 13 Sep 2018 18:07:55 +0200 (CEST)
Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 13 Sep 2018 18:07:53 +0200
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 13 Sep 2018 18:07:53 +0200
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=xaT80ShyvQlNa1wehxAUGQ2EB2qrhAob+xyh+dzk9oo=; b=I6BZFD7dEZLPeYetjY4ZM8ACUp4qOVcPxguyWDCYPt0xZ9KM1DVzY7uW73myA0RvXc959k/NOImgIr7mqSaIKMNbydZNN6O7Cg9vDpNX5xyOUFRr93HHlBduu++SJ/f8yL0lB65OUoxsOhvMPei7ynrVqsMAtxPN6pc5E6WEBAY=
Received: from [159.107.199.36] (89.135.192.225) by DB6PR0701MB2725.eurprd07.prod.outlook.com (2603:10a6:4:24::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.11; Thu, 13 Sep 2018 16:07:52 +0000
To: Kent Watsen , "netconf@ietf.org" 
References: <7AC66C1A-9E8A-42C2-B577-0B129E67568D@juniper.net>
From: Balazs Lengyel 
Message-ID: <4e925c5a-68be-4aca-c7bb-265de3bb6dc9@ericsson.com>
Date: Thu, 13 Sep 2018 18:07:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <7AC66C1A-9E8A-42C2-B577-0B129E67568D@juniper.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070703050705070001080503"
X-Originating-IP: [89.135.192.225]
X-ClientProxiedBy: DB6PR07CA0023.eurprd07.prod.outlook.com (2603:10a6:6:2d::33) To DB6PR0701MB2725.eurprd07.prod.outlook.com (2603:10a6:4:24::7)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 85a590a2-8a7f-4168-28e4-08d619930f5b
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DB6PR0701MB2725; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2725; 3:xdWRi0fl81rKUEKvs0JU93R5wKnT4tRmcZJXDQ4vYR2krtkST5roIA7OIx7mUQX01Sa+q/lvaiKWA664/ALmP+LhdVSxkVtuTSKHVyUsgIaa5qcbnH2NBPsks6C0di4m393R8t0SiSfUJ/m1I9LnJp4Ik0nzGSqxHOSlbOYBPNGVgc4FJh7XYo+jQf5dKZ4MpvmcQn7akCHCfb56w/8XYELVHoMyx2Wy60hwGHqxYOh9sWsIJuEUUjv+U1+EUal0; 25:sYrQLnLChYJH6SS7kXc3KRvs+OjC8uwTpTbrScKDdPbi4Him+nrznONkUrSx5TdgB/VzfVShTY3aPovlp+invYnvBPMkiqfCJR7r6/ZUNI9zUjAdX++Gsy7QW3IPZPJxLqgd7osp3zSUbRjGfOr1FDo5IZTwYs+rfS3hSNLQxh8XB3UCO2HuEtN+i+dsMZF7uVW42QVwfNjF68mIrYfKAMf4rtOG2MTy+yCyTJlCDlOCmc5JP9Bgrgl9+2yIDyfFXBqP03+zZUAe9V2kH2nbBpkGOmU/PFuzD0UG0cOIU2Wo/KGq99GHcEYqFocNrgtoSJiST4Y+jIfT2yd2jYmC3A==; 31:gqeoa/8TOUsaHtJzHk6SyEw+0fpk0vGczJKNUaTnhtisG9HjYbF6qN5jAHV6/qRRkpYEXKenhQ2/beg4n6rDZ7UJK/p+nseT/P692NHlChOFmBF1InmoEYtNYFNKwhARgNMA6R12YwsaXrS7pNpQtfRoOUyJi7NcJfcgmys5AsYIywf4qX7DMmIUSdwsdIJFTZJ0NxrEla1XSXlKTJ+ioX49DyP2CHguBLXjjBk9I7s=
X-MS-TrafficTypeDiagnostic: DB6PR0701MB2725:
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2725; 20:K2E+HvbqVufyDQRNUAOmB/XjZ03wTlflZLW0LoqaJxiKbWs4kiPu1tlNzqLYjdBVJyO2Bv/QGk/uEfKe8aax9nEi8emFAslcnAdQ9Qdjo9EHMFdwr7wO45nCF2QSWS1IKLgNtmwGjbtISJxG/CkDXkaUI52Q/WIb9AIqPdrUsWwhcLQ5g1AV6ZevBTDGP4mURA/2L1ddKftqa2DwowJRZO91VxEjjE61xSDtaFs+6pnsxrVSinShaVLCtyavzAatbP16PvSFWjvqMZKJsN+4Pkn215VHJmsvWQWu43LXRX9dPSDVYnhRLfwfJaPCaXecSaWjfLz+npiQyIfEY3k0w7pbhIDsNNMdisv1Sj2OW/sy4SYYJH6crSV2e+i51hpmcVFLStf5K/54brETtNU4tI1EGolN5XysWZO/ctX0Nrs1PsCNr40/mccLU5vVl0Bm2y8mMMuqev1ekUVoAShEpFH9F1wK/Sk+AnMAXyY7TLjnPZs+/0T2CD7hqHp6Qxx1; 4:DMPyJwqj1VWk/tkgOgWZHEOlTAkZ06EmePDlLRlx+I3tmjwvwIJ7Sr449rrytAmMHpinPDZ3mnhP/6ilK/N43toNh9ZooSfgxCDwwkn6YWaQ2JX8QDDiaQVaWNxJmQWcaN+etr4X0ssXXq1qObi0YAfVWy5x5TEfRarmsG0mpUkohFddTj5+uo4TFGHdGZM+L6Ha2n1RQI+AJvg61tSSHGZYKZY+Ciy1RHrkn60d8wcTVYECg095XwwMAq8P88Mmd54mRYunrV4CCP8vM/c2rKau7yMMv4HVNOTOXzSiv0i8JR74xU1H/uZJc/Fneao3kTPhh6agx1SlXvABfqAu6PiJuV7sx507rPhScr+Rs1rqaxuQqFOKVHNEgxVKLTYv
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(120809045254105)(248295561703944); 
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231344)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699050)(76991041); SRVR:DB6PR0701MB2725; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2725; 
X-Forefront-PRVS: 07943272E1
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(376002)(396003)(136003)(346002)(366004)(39860400002)(189003)(199004)(252514010)(6306002)(229853002)(16586007)(7736002)(106356001)(105586002)(97736004)(6486002)(6346003)(386003)(49976009)(53546011)(316002)(16576012)(58126008)(568964002)(110136005)(15650500001)(305945005)(6116002)(68736007)(1941001)(3846002)(6246003)(3260700006)(8936002)(81166006)(84326002)(25786009)(478600001)(81156014)(446003)(31696002)(2906002)(64126003)(966005)(53936002)(8676002)(31686004)(5660300001)(33964004)(486006)(36756003)(476003)(86362001)(6666003)(11346002)(52116002)(16526019)(186003)(76176011)(65826007)(5024004)(65806001)(44832011)(65956001)(66066001)(2501003)(26005)(956004)(2616005)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2725; H:[159.107.199.36]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB6PR0701MB2725; 23:1bVoDrPL9cVPNay8IRKhZXxiEY8+kjkeBdnPdu+?= =?us-ascii?Q?vBZ2JOgzQJFZIkmmiHU7YzgoxE0Tft8p/fhcFpeyH+qZyVwPneikaYJUjHAS?= =?us-ascii?Q?NRFKiWm3GEf3y7ZYSgWtIzONCr1uPVXmTJJI91UfoWhVZ3vubORgIbJOS0F6?= =?us-ascii?Q?4cNZbQRqCQFkAW3387VdngkOoTmWKFI8O6JE6NGN1k4OTYRZGneX8nw530ht?= =?us-ascii?Q?Rb31A8bkVJ2iyn9TqUQUmtOIj2weSewzdFGJu/BKcuXl+PeOTikcpJ3HNPTo?= =?us-ascii?Q?dBwoglM7LgUpF08D/U2xmYe2nPDVi5hS29sEFejU6qQki7ybkZcI2ACR8R1k?= =?us-ascii?Q?GKA0EEUiXNjHoQTY22AcNjyH0S7y6Df13IyHV7IHG0xvyeR9MvQlIyjLfXaa?= =?us-ascii?Q?9mCBRmDSV6kBYZlCsOk2XSR0ennhAclQ0BiIhkBY9Dx73Sapdu8T1LwxhVOZ?= =?us-ascii?Q?JTW7QgExbTZe42YWK4bBOCG2TCLxtaIYFYovvPkngZyWb2+C6VTdSLPIdA4H?= =?us-ascii?Q?n8uwdfrQ5Y2OQ4852eIpl9An800lUCKpQPD0aN0WCJBwTUcKIm0FOeB+3KUN?= =?us-ascii?Q?8e2fBrEcE0nCvp9ZZ7iR57HrL0u8rNHN4sBG0eUvOeUsq+ZRKelDKxGg5MwK?= =?us-ascii?Q?QNor1ol8ElUd9xgE6G08FMZt0mMU1PVn3BckSK3pnLBQzSsrS7SlWgmSr3Yj?= =?us-ascii?Q?Qqfdp+294iJ8+bejiN65ttSdOcYTImRQYfRw2NDPug+oUTjBr61mC86MNRNF?= =?us-ascii?Q?clFDZRpN46Mir1agZ1qqJuntdXHi+2UoqPn+A6dXI/iIHMDXkSQREzZLQmXM?= =?us-ascii?Q?SIqDH6A5VGKcoUwn+oJ2KzXX01XRmTkVhcojt8QmU5iFHLlC0Z22CIBu1WhV?= =?us-ascii?Q?+/RDJxVXY8gnKil98lb4xlOY+tZjvCMUEvmLVA+1UxbGggr4Z+iT6eaV/rbh?= =?us-ascii?Q?dGJ2k39A0N0Z1nUk0BVdToIxJfTfW+alipaxeq1jq+X0MoxD3GI7Cb7UsIqX?= =?us-ascii?Q?kkx+urOR9+Uu9UQukBiubYq+qLAR+nqUJr2FEP4yVwp2iHjgM4fCgxjfXnsP?= =?us-ascii?Q?/vu0t1CI+XRl/VfmXgDxnN+AyDSt0WEjAqmrckpALGFeRuVq8fqJw9W1mxuy?= =?us-ascii?Q?+5tHpP8oOPSRzt6/P0vJuzhKVhbWngc/CVj/iB0XCWE7la7lUKRJf16xhZlG?= =?us-ascii?Q?pNL7BUF/X74RJ6GomlJbD3lj22qbVL2d0prknndmdliKq1l6NZJKaAuC5h0n?= =?us-ascii?Q?gswIBJ9nKogcu0gOzOkQsG+0b/ccaLRmI3jlHqYB8z3N3A8NiAavDRYZx/2U?= =?us-ascii?Q?bonFvIlvzlh4FgEXsTGdft2FfotX0/1rtc+hPdu+1VzwgXJ+Qd2T7QNtkWvK?= =?us-ascii?Q?Y3dWLj/GLUY5cHGWIf+gJDaZr/1yUrH+//xk05wvJqi7rtrjBWWiIolAFGaq?= =?us-ascii?Q?Z2F3efdxzwf0ziO3Ifbdm8nUAUFdwX7X6DqR8GoamF6Qeo2by6eorAHS2skH?= =?us-ascii?Q?GdQGcCw/ROAX2SJpjgChRujdDrWupbf2Zu+so+aQCnrwtioNtOqU9WB2o0mH?= =?us-ascii?Q?owou9opqnPIquw/l8YBgjC/0beVej/A86/u6qJlg=3D?=
X-Microsoft-Antispam-Message-Info: M5JM3AXpaM9uKE8uxpjRXQJFTnTmJ+Uhcnix/WqzWAjwXRCrY2+T5BP8nLTs7Qb7nglFAW2kPeTJ45JFtMy8tuD8St3MNRRJtk8hiZr4OgOWTXojbfFfon4PEf0uq2ctK/UOhoDQL1WHfaKcYDEd3dzW3y0Bs7li4toGwyrK9zj2A+B/ydxRj+3T/aoQ7ybqD/DLeBgePqCtCE0jvHfnkubaxSFhSzTTCQvTy9oTXfIbVjyswdFe5ukubLORVy+gY7IZVPe+g0NW5oqLsNbJrHutvBH4b07FmOIZIQsOWjxdfUSsOHPkOSWijFnI257huDkItn6t+KzWXj9GSMHxhVw46dNs5tP+sBdpJ7WHxjs=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2725; 6:3GfYwuojeOYZ4D/RJ7FaMC89ca+7L+kLZXisihljgEIIXSonsAl3/uqkpHnbq6AhZuaGdIJVk+xpCbRWZkJdqQOFGViNBbApVU9UoUMsUcweGpozPNwWiucKR8ls+7G/CIyb0SLwVKgyPKN2/57y2Fj05RuFmNllIUmVLukVSLl/INRgF40UeXm6yxFwWF9PvYd0p/wSzIBqe9moMpzjb9++QFEPu+USRsm7dpiPAcawNBI2XihveeTJbPtKlZbaqjYjzWrQBl7QhORdI/RvIA+bkTeEUrn9q1yX30zGuCieXQH/FkaXs2YOLvR0WeIlSTvcxUgmzmn35IZwN9vDwUuyWLHLfDj3r6UzHmNjXR0uRJcU1+gIhC4Kt1mhbrXpQVrG5a5S3mBEfBpSTqKZZC6rlcbHr1pWtM5+jr434uJ/2r5W7hw1P+KcXCmkAa4Iiyn5wICqsH70T1ktAPEOSQ==; 5:FsxWDy753S7jp017mQEWaBDZVE0YCkQeVUes1klGca1PKertH+T785N86UOuKnt5z+lTv4nDJ8l8CjnVkAx5Cwa4CGsT0rDPNxs0Z/988hNcygOaYdGAYpyU6cdlllakJHmHmTWQ0fuyn3bXTIDrqLK3o60Ag/D3BodgtHhxs9U=; 7:YFQfOHIozzJ5T5nXVX3F2IJLpDOmg+N2S8xm9dc5GQz7vmwEEk2fNP0vKC4RpYYGWPMDN8K5sU712Wl37D/ALjLWdrVilyzQ8JjqXgG7p8uVattM8fb/51vQqv66CsTskJ2QPlWOqv8ZY67M0Q4RUs3adGy5ZvYIx9kmr5Dyk9PpG7uLfXhtv9R0t3Dq5TK+AscQW+NQv6pVh3s7KYHMzF/b/j356ba6MVKxV71nzbus05/B+ivt8TOqh/HBw/wn
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2018 16:07:52.3989 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 85a590a2-8a7f-4168-28e4-08d619930f5b
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2725
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85OzsOB6ep+KClOAqk1NRKjPISfhG6fhHMmTbzoCPddDNT P6krq6lkpummlC0R0zDTlTfyMpugeMs0bwQZSl6+eCvLS7XtXeC33/v+f8/zPg+8DCka5bkw Mnkap5RLk8S0gNJGttz2luTrJL4/+twDuyv5gaVNs7xQIry6+jcRPpk7wb9CRAnOxnNJsnRO eTz4uiCxsd/IS6kMzhja20HZaOG0BtkxwJ6EtV8LtAYJGBFrQtB0r5NnCUTsTwSLhVk4qCZg q3ucshwotoiE4tw/FLbUBKyu2lvYgQ0BTYGab2FH9gKMbehsnYKhwvjVek+z/lD6cMRaKzT7 bwqnrfcUewRa27bMPsM4sRJY/yvDygHo185bdTuzXr6czbPMQLIPENQXGGi8ghjGNp9YhwO2 BIF+O4/ED3vC3OgeD0uHwDRUSWG+CPm7PTQu6EfwvneWhw+5fFBr+ghsecH9wnUCB+18aJsa tLVSQG2ZgcQcDTN1u3zMbjBQOGwr6CXB1FiDcHAQ7mpbbO99pqFbO0HjATkwTN2hi5CXbt+2 uv0bWgKSDYCnzXMk5mNQ83zFxs4wM/+MwHwGyrd7bL4HlOTP8TGfghXTGsJ8Amoa9ugqZFeH nFScKi45wd/fh1PKbqhUCrmPnEtrQua/1WPY8W1FS9/PGRHLILG9sLxOKxHxpOmqzGQjOmzu 862xfhS5UHKFnBM7Cl9H6CQiYbw0M4tTKmKVt5I4lRG5MpTYWRh4qTlKxCZI07ibHJfCKf+n BGPnko1S7fUB5yfjMjoGZxwUXWEF2aOi3sqt+IGqLcfenNiSLybJK70+b1j94lOYX7GrOiqv yn2htSzHFLrkEOg5jF7mBT8eH5IFBTXHrNRuDFZ77LXHdFzr2ui8/GhNsDnyzi8miHk7PK0Z X1xuiGDDl5IqvD9+CEk1XN31c42ObDK5iSlVotTvKKlUSf8BmSsTymMDAAA=
Archived-At: 
Subject: Re: [Netconf] Last Call on subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 16:08:02 -0000

--------------ms070703050705070001080503
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hello,

I have reviewed the latest changes. In my view the document is ready to=20
progress.

regards Balazs

On 9/6/2018 1:31 AM, Kent Watsen wrote:
> This message starts a Last Call on draft-ietf-netconf-subscribed-notifi=
cations-16:
>
>    https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notificati=
ons-16
>
> This marks the second of the last calls on the yang push suite of draft=
s.
> As explained before, given the size and number of documents, the chairs=

> decided to break the reviews up into pieces so as to get focus on each
> in turn.  We are choosing to go top-down, starting with yang-push and
> ending with the "notif" drafts.  We plan to submit the drafts for
> publication when they are ready as a collective.  The goal is to do
> all this prior to IETF 103.
>
> While it's always nice to receive messages of support, at this time, th=
e
> question isn't so much if the working group supports the work than if
> the document is ready to progress.  The chairs need to see reviews that=

> indicate thorough end-to-end reading of the text.  Of course, if there
> are any objections, these should be brought forward now as well.
>
> The current version (-16) of this draft was published on Aug 15th, abou=
t
> three weeks after IETF 102.  The datatracker page for the draft is here=
:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifica=
tions.
>
>
> Thanks,
> Kent (and Mahesh)
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com



--------------ms070703050705070001080503
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDkxMzE2MDc0N1ow
LwYJKoZIhvcNAQkEMSIEIMr3y1zt1fzpiHzZK1BrP79HbtzZP60xb1l0MyeIVLHGMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAD0p3IdfZEtGOfYPe9A/9LWSvfR4lHr3RJoGv5YdXTBiOz5A
jr/AvfYehCkqFb+VhEfVWR/1Y5lsWRJIZWzb+tRECQMA7Ife1D/OqHI/+Zdk4+GKUVjpQyX/
MrU9OYR0U2pqYErrhd/CZgysrJdjP8oOYCc3yKlD3NKTorngZR7n4ijvmDfk0G2qEz8Wa1T9
v9GferxMYubQBoybe65VciushOXXJc2Ttd4h5Qne8GgocE/NUJwxN6yiMxbrv5yfi3MWaOR4
7kH2/EWQihm7uJhDqnKZ4ACsfDTh4NyPnaRmPvNdoIlAY7iUr5WsvOZvucf9CpCw/FmNG16W
YN+TWicAAAAAAAA=
--------------ms070703050705070001080503--


From nobody Thu Sep 13 09:39:03 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACB11294D0 for ; Thu, 13 Sep 2018 09:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_MED=-0.01, 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 7pHdHjGrlcHz for ; Thu, 13 Sep 2018 09:38:58 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BC312F1A5 for ; Thu, 13 Sep 2018 09:38:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21969; q=dns/txt; s=iport; t=1536856737; x=1538066337; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Qh0dyhYJbzJcfiQKKS9HsqqfRZC1ZkF/zS0tixD+8Oc=; b=CMgt6K2SvBmZTE2l6sGIHsfMNW1blWol2/1abJS5rx6BhGB6liwhQxgh 8n1Mz8QIzV4E5Ja8zYbW6XpMbe4Bi28ii5MxOPH0CY3/Ya1ofNheewp0e Cn2iAdHN9HWy4XxZgZB07P6KA011kgEg/PHYjDq4JUGDF9+HWUewvsF5Q Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AACVkZpb/5hdJa1QAQkZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBgywqZX8oCpgUgg14lVqBZgsjhANGAoNYIUwBAgEBAgE?= =?us-ascii?q?BAm0cDIU4AQEBAQIBGiA9AgULAgEIDgcDDREQMiUCBA4FCIJOTIF5CA+nGoo?= =?us-ascii?q?IBYpoF4FBP4ESghRJNYMbAgECAYEqAQcBCQIBBgJIhSYCiCQqhQCBNIQRDIg?= =?us-ascii?q?4TwkChjmJTR+BQYRIhAqEcIhTgnuIPgIRFIElNCFkcXAVGoMNgiUXegECgki?= =?us-ascii?q?FFIU9AW8Bi1EHgSeBHgEB?=
X-IronPort-AV: E=Sophos;i="5.53,369,1531785600"; d="scan'208";a="171271808"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 16:38:56 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w8DGcudw025203 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Sep 2018 16:38:56 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.1395.4; Thu, 13 Sep 2018 12:38:55 -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.1395.000; Thu, 13 Sep 2018 12:38:55 -0400
From: "Eric Voit (evoit)" 
To: Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of subscribed-notifications-16
Thread-Index: AQHUSS2c6fWPWMQnpECqHWzj9l2RFqTpyY1wgALe1QCAACWmwIABR3cAgABBbiA=
Date: Thu, 13 Sep 2018 16:38:55 +0000
Message-ID: 
References:  <20180912.113446.2017030234338816835.mbj@tail-f.com> <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com> <20180913.092134.395462318086733174.mbj@tail-f.com>
In-Reply-To: <20180913.092134.395462318086733174.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.234]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 16:39:01 -0000

Hi Martin,

> From: Martin Bjorklund, September 13, 2018 3:22 AM
>=20
> Hi,
>=20
> Thank you for addressing my comments.  More inline.
>=20
>=20
> "Eric Voit (evoit)"  wrote:
> > Hi Martin,
> >
> > Much incorporated.  Latest is at:
> > https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netcon
> > f-subscribed-notifications-17.txt
> >
> > Specific responses in-line...
> >
> > > From: Martin Bjorklund, September 12, 2018 5:35 AM
> > >
> > > "Eric Voit (evoit)"  wrote:
> > > > Thanks for the comments Martin,  thoughts in-line...
> > > >
> > > > > From: Martin Bjorklund, September 10, 2018 1:42 PM
> > >
> > >=20
[...]
> > > > >   I think that this document should state that an event record is=
 an
> > > > >   instance of a YANG "notification" statement.  If not, it is unc=
lear
> > > > >   both how subtree/xpath filters and xml/json/... encodings would=
 work.
> > > >
> > > > Applying xpath filters against XML based event records seems
> > > > viable to me.
> > >
> > > Where does it say that it has to be XML?  Whatabout mixed-content?
> > > What if such a notification is sent when the encoding is JSON?
> > >
> > > If you want to make this specification open for other data modeling
> > > languages, I think you need to carefully define how that is supposed
> > > to work; essentially similar to how we handle transports; we have a
> > > set of requirement on what a transport document must define.  IMO
> > > this is super complicated and overkill.
> > > This draft is complex enough.
> > > Don't add even more complexity.
> >
> > If you are just saying that we can put everything into a YANG wrapper,
> > that is fine with me.  To clarify this, I have tweaked the first
> > sentence of Section 2.1 to:
> > "An event stream is a named entity on a publisher which exposes a
> > continuously updating set of YANG encoded event records."
>=20
> Howabout:
>=20
> OLD:
>=20
>    An event stream is a named entity on a publisher which exposes a
>    continuously updating set of event records.  Each event stream is
>    available for subscription.  It is out of the scope of this document
>    to identify a) how streams are defined (other than the NETCONF
>    stream), b) how event records are defined/generated, and c) how event
>    records are assigned to streams.
>=20
> NEW:
>=20
>    An event stream is a named entity on a publisher which exposes a
>    continuously updating set of event records.  An event record is
>    defined with the "notification" YANG statement.  Each event stream is
>    available for subscription.  It is out of the scope of this document
>    to identify a) how streams are defined (other than the NETCONF
>    stream), b) how event records are generated, and c) how event
>    records are assigned to streams.
>=20
> > And I have tweaked the first sentence of the third paragraph to:
> > "As YANG encoded event records are created by a system,..."
>=20
> I think the original sentence is better.
>=20
> Also, some tweaks are needed to the filter leafs in the YANG module:
>=20
> OLD:
>=20
>           The subtree filter is applied to the representation of
>           individual, delineated event records as contained within the
>           event stream.  For example, if the notification message
>           contains an instance of a notification defined in YANG, then
>           the top-level element is the name of the YANG notification.
>=20
> NEW:
>=20
>           The subtree filter is applied to the representation of
>           individual, delineated event records as contained within the
>           event stream.  The top-level element in the event record is
>           the name of the YANG notification.
>=20
> and
>=20
> OLD:
>=20
>            The XPath expression is evaluated on the representation of
>            individual, delineated event records as contained within
>            the event stream.  For example, if the notification message
>            contains an instance of a notification defined in YANG,
>            then the top-level element is the name of the YANG
>            notification, and the root node has this top-level element
>            as the only child.
>=20
> NEW:
>=20
>=20
>            The XPath expression is evaluated on the representation of
>            individual, delineated event records as contained within
>            the event stream.  The top-level element in the event
>            record is the name of the YANG notification, and the root
>            node has this top-level element as the only child.
>=20
>=20
> (I think it would be useful with some filtering examples, like in section=
 5 of RFC
> 5277, but I think you have all examples in netconf-notif, so they would g=
o into
> that draft.  (re-reading an old thread I found that examples for filters =
were
> requested before)).

This portion of this thread resulted in updated text based on the updated t=
hread you sent out.  We should continue discussions there if there are ques=
tions.

> > > > Of course it will be up to the definition of any particular stream
> > > > to articulate the event record contents sufficiently for filters
> > > > to be created.
> > > >
> > > > > o  Section 2.1
> > > > >
> > > > >   The text says:
> > > > >
> > > > >     Among
> > > > >     these included NETCONF XML event records are individual YANG =
1.1
> > > > >     notifications described in section 7.16 of [RFC7950].
> > > > >
> > > > >   First of all, does this mean that there can be event records on=
 the
> > > > >   "NETCONF" stream that are *not* defined with a "notification"
> > > > >   statement?
> > > >
> > > > For the NETCONF stream, personally I only care about things YANG
> > > > notification statement.  But looking again at Andy's comment from:
> > > > https://www.ietf.org/mail-archive/web/netconf/current/msg14764.htm
> > > > l he says "I would say SHOULD be defined in YANG, for the
> > > > "NETCONF"
> > > > stream."
> > >
> > > I strongly disagree.
> > >
> > > > So for -v16 I updated the text in a way that doesn't preclude this.
> > >
> > > See above.  If all events records are defined in YANG we can remove
> > > this.
> >
> > Per above, I have included text above so that YANG encapsulation is
> > required.  I think YANG Data should be an allowable structure (so I
> > didn't specify just a "Notification").  If you think that YANG Data
> > should be excluded from the allowed event records. I can refine the
> > words.
>=20
> Yes I think yang-data must be excluded (actually this was one of the conc=
erns,
> raised by Andy I think; that people start to use yang-data for things tha=
t we
> already have proper YANG statements for...)

Ok.  With the text in the other thread, this should be covered.

> > > > >   Second, this seems to imply that *all* notifications defined in=
 all
> > > > >   YANG modules end up in the "NETCONF" stream, but I don't think =
this
> > > > >   is the intention.  At least I hope so.  ("yp:push-update" is an
> > > > >   example of a notification that will not be sent on the "NETCONF=
"
> > > > >   stream.)
> > > >
> > > > The NETCONF stream has a very broad/inclusive definition in RFC-527=
7.
> > > > This definition is: "This stream contains all NETCONF XML event
> > > > notifications supported by the NETCONF server".
> > >
> > > This is very underspecified.  IIRC the original intention was
> > > notifications related to NETCONF, hence "*NETCONF* XML event
> > > notifications".
> > >
> > > > To me, thinking about how that statement and applying it to YANG,
> > > > this translates as YANG 1.1 notifications should go into the
> > > > NETCONF stream, unless explicitly excluded.
> > >
> > > I disagree.  This is not how 5277 works.  Until we have worked out a
> > > useful way to assign notifications to streams, we shouldn't restrict
> > > anything in this regard.
> >
> > Ok.  Effectively we are naming the stream NETCONF without improving
> > the definition of what membership in that stream should be.  And that
> > is fine.  As people seem to understand what this is supposed to be, I
> > will return to the original definition.  See text, and let me know if
> > you have issues.
>=20
> Maybe one small tweak from the original text:
>=20
> OLD:
>=20
>   The "NETCONF" event stream contains all NETCONF XML event
>   record information supported by the publisher
>=20
> NEW:
>=20
>   The "NETCONF" event stream contains all NETCONF event
>   record information supported by the publisher
>=20
>=20
> (since it actually is possible to get them in JSON over RESTCONF)

Updated

[...]
> > >
> > > > > o  Section 2.4.2
> > > > >
> > > > >   The text says:
> > > > >
> > > > >     The transport selected by the subscriber
> > > > >     to reach the publisher MUST be able to support multiple "esta=
blish-
> > > > >     subscription" requests made within the same transport session=
.
> > > > >
> > > > >   This seems to indicate that RESTCONF cannot be used with this
> > > > >   specification, since RESTCONF doesn't have sessions.
> > > >
> > > > The desired behavior is that a subscriber can request multiple
> > > > subscriptions without each requiring a separate transport session
> > > > establishment.  I think we are ok here with RESTCONF because
> > > > underneath RESTCONF is HTTP, TLS, TCP.  And each of those lower
> > > > layers can have sessions.
> > > >
> > > > To clarify further, I have tweaked the text to:
> > > >
> > > > "The transport selected by the subscriber to reach the publisher
> > > > MUST be able to support multiple "establish-subscription" requests
> > > > without each requiring a separate persistent transport connection."
> > > >
> > > > >   This makes me wonder, why does this document specify this
> > > > >   requirement?  I agree that this is the behaviour we want from
> > > > >   NETCONF, but then I think that should be defined in the
> > > > >   netconf-notif draft.
> > > >
> > > > By saying something in SN about this requirement, I believe we can
> > > > preclude an implementation which can only support one subscription
> > > > per subscriber.  In any case, the specific "how" details will
> > > > still need to be articulated in each transport draft.
> > >
> > > I think you are mixing the specification and implementation.  If a
> > > transport document says that an implemention MUST support multiple
> > > subscriptions per session (in a transport-specific way), then an
> > > implementation cannot just support a sinlge subscription.
> > >
> > > My point is that this a transport-specific requirement, and it
> > > doesn't belong in this document.
> >
> > I can see why you don't see it applicable to Section 2.4.2.  However
> > Section 5.3 provides guidelines for transport document developers
> > (this is a section Kent requested.)  And so I have moved the
> > requirement there.  Is that sufficient.
>=20
> Ok, I agree that the text belongs to section 5.3 rather than 2.4.2.  I ju=
st don't
> agree with the text ;-)  But I can accept it.

Thanks.

> > > > > o  Section 2.4.2
> > > > >
> > > > >   s/"start-time"/"replay-start-time"/  (3 occurrences)
> > > >
> > > > Fixed
> > > >
> > > > >   Also, the text says that the replay-start-time MUST be in the p=
ast.
> > > > >
> > > > >   Suppose the server receives a "replay-start-time" of 12:00:00.0=
01,
> > > > >   and the replay buffer is empty.
> > > > >
> > > > >   A) If the current time is 12:00:00.002, the request is accepted=
, and
> > > > >      a "replay-completed" notif is sent.
> > > > >
> > > > >   B) If the current time is 12:00:00.000, the request is rejected=
 with
> > > > >      an error.
> > > > >
> > > > >   Why is this important?  Why not simply just send the
> > > > >   replay-completed notif in both cases?
> > > >
> > > > For (B), if an event occurs at 12:00:00.0005, should it be sent?
> > > > Should it be sent before or after the "replay-start-time"?  How
> > > > long should we allow the clocks to drift before we reject the
> subscription?
> > > > As we don't support future/pending subscriptions, we don't have to
> > > > worry about these questions with the current definition.
> > >
> > > I would simply say that if the replay-start-time is later than any
> > > buffered notif, then "replay-complete" is immediately sent.  It
> > > dont'
> > > matter if it is one microsecond or one year later.
> >
> > Tweaked the sentence:
> >
> > "If the given "replay-start-time" is later than the time marked within
> > any event records retained within the replay buffer, then the
> > publisher MUST send a "replay-completed" notification immediately
> > after a successful establish-subscription RPC response."
> >
> > > The problem otherwise is how to decide if something is "in the past".
> > > In the past when the client sent the request?  When the server
> > > parsed the XML?
> > > When the instrumentation code runs?
> > >
> > > But this is not a big issue.
> >
> > Hopefully with the tweak, we can leave it as modified.
>=20
> Ok.
>=20
>=20
> > [..]
> > > > > o  Section 2.4.6
> > > > >
> > > > >   The text says:
> > > > >
> > > > >     1.  "establish-subscription-stream-error-info": This MUST be =
returned
> > > > >         if an RPC error reason has not been placed elsewhere with=
in the
> > > > >         transport portion of a failed "establish-subscription" RP=
C
> > > > >         response.
> > > > >
> > > > >   (and similar for the other errors)
> > > > >
> > > > >   What exactly does "if an RPC error reason has not been placed
> > > > >   elsewhere" mean?
> > > >
> > > > The intent is to match how NETCONF & RESTCONF historically handles
> > > > errors.  As you know with NETCONF, each error identity will be
> > > > inserted as the "error-app-tag".
> > >
> > > It could also be in "error-tag" and/or "error-message".  My point is
> > > that I don't think that you mean that if an implementation populate
> > > say "error-message", then it should not popluate error-info with
> > > establish-subscription-stream-
> > > error-info.
> >
> > I do mean that.  I don't think we should send:
> > "establish-subscription-stream-error-info" for NETCONF when there is
> > no hint included.  All the necessary error info is already in the
> > existing message.
>=20
> But is this really true?  In the
> "establish-subscription-stream-error-info" there is a leaf called "reason=
", which
> is an identity with a detailed error reason, for example "history-unavail=
able".
> This info is not present anywhere else in the rpc-error, so it needs to b=
e
> present here.

For NETCONF, this info should be mapped into .  See section =
7 of NETCONF-Notif, as well as Figure 10 for an example.  Or section 3 of R=
ESTCONF-Notif, with Figure 7.

This was done to align things with existing NETCONF & RESTCONF error mechan=
isms.

> > > > And therefore placing the YANG data
> > > > "establish-subscription-stream-error-info" would be redundant.
> > > > For NETCONF, "establish-subscription-stream-error-info" are only
> > > > needed when hints to be provided.
> > > >
> > > > Therefore assuming you are looking for an alternative way to make
> > > > this point, I have tweaked the text to:
> > > > "This MUST be returned if an RPC error reason has not been mapped
> > > > down into transport specific error objects contained within a
> > > > failed "establish-subscription" RPC response."
> > >
> > > Howabout simply removing this sentence?
> >
> > Done
> >
> > > > > o  Section 2.5.1
> > > > >
> > > > >   In the second diagram (for the valid state), the states are cal=
led
> > > > >   "receiver connecting", "reciever timeout" etc.  I find this a b=
it
> > > > >   confusing; it is not the *receiver* that is connecting, it is t=
he
> > > > >   publisher.  Ok, the legend then says:
> > > > >
> > > > >      dashed boxes which include the word 'receiver' show the poss=
ible
> > > > >      states for an individual receiver
> > > > >
> > > > >  But since all dashed boxes include the word "receiver", and the
> > > > > diagram specifically is the state machine *per receiver*, maybe
> > > > > we can simply remove the word "receiver" from the boxes?
> > > >
> > > > There have been some discussions on this.  I agree it is certainly
> > > > valid to remove "receiver" from these four boxes.  However I have
> > > > found that getting readers to really internalize that the state
> > > > machine is actually per-receiver rather than per-subscription, it
> > > > seems to go faster/cleaner when receiver is shown in the four boxes=
.
> > > >
> > > > Nevertheless, if you absolutely want "receiver" removed from the
> > > > boxes, I can do that.
> > >
> > > Maybe you can remove receiver from the individual boxes and then
> > > change the word "valid" from the outer box to "per-receiver state
> > > machine"?
> > >
> > > Or maybe remove the outer box and add a Figure title: 'per-receiver
> > > state machine for the subscription's "valid" state'
> > >
> > > Also not a big deal, but I found it confusing.
> >
> > All are viable.  But I have found the current diagram useable. Do you
> > have a major issue if we leave it as it is?
>=20
> No.  As I said, I found it confusing, but if others think it is more help=
ful without
> my suggested changes, we should leave it as is.

Will see if others chime in.
=20
> > > [...]
> > >
> > > > > o  Section 2.5.6
> > > > >
> > > > >   I know that this feature was presented in Montreal.  I think it=
 is
> > > > >   problematic, and suggest it is removed.
> > > >
> > > > This issue was discussed in Montreal.  The feature is of course is
> > > > optional.  There are a large number of downsides for someone who
> > > > chooses not to implement for certain use cases.  Please see the
> > > > Montreal slides and the long threads with Kent for more details.
> > >
> > > I did watch the Montreal session, but I didn't see any discussion on
> > > this issue (just your presentation).   Can you send a pointer to the
> > > email thread with Kent?
> >
> > Some minutes on the topic can be seen at:
> > https://datatracker.ietf.org/doc/minutes-102-netconf/
> > With the WG vote in Montreal, I would love not to re-open.
> >
> > The previous exchange was long.  Some items include:
> > https://www.ietf.org/mail-archive/web/netconf/current/msg14575.html
> > https://www.ietf.org/mail-archive/web/netconf/current/msg14902.html
>=20
> Ok, if you believe that this thread shows that the WG supports this featu=
re, I
> won't pursue this.

Thanks

> > > > If
> > > > you want to pursue this further it is probably best to start a new
> > > > thread dedicated to this topic alone.
> > > >
> > > > >   For example, what happens if the transport session is lost and
> > > > >   re-established; are all event records in the buffer replayed ag=
ain?
> > > >
> > > > No.  The publisher will not lose context of what was sent.
> > >
> > > This is not clear from the text.  In fact, the text explicitly says:
> > >
> > >    The leading event record sent will be the first event record
> > >    subsequent to the latest of three different times: the
> > >    "replay-log-creation-time", "replay-log-aged- time", or the most
> > >    recent publisher boot time.
> >
> > I see your point.   I have tweaked the text to:
> >
> > " If the publisher does not know the next record intended for the
> > receiver, the leading event record..."
>=20
> Hmm, not sure this helps.  How about:
>=20
> OLD:
>=20
>    As a result, when any configured subscription receivers become
>    active, buffered event records will be sent immediately after the
>    "subscription-started" notification.  If the publisher does not know
>    the next record intended for the receiver, the leading event record
>    sent will be the first event record subsequent to the latest of three
>    different times: the "replay-log-creation-time", "replay-log-aged-
>    time", or the most recent publisher boot time.
>=20
> NEW:
>=20
>    As a result, when any configured subscription receivers become
>    active, buffered event records will be sent immediately after the
>    "subscription-started" notification.  The leading event record
>    sent will be the first event record subsequent to the latest of four
>    different times: the "replay-log-creation-time", "replay-log-aged-
>    time", the most recent publisher boot time, and the time of the
>    last event record sent to the reciever, if any.

The reason I didn't word it this way is if there are multiple events with t=
he same timestamp.  How about the text below...

NEW=20

If the publisher knows the last event record sent to a receiver, and the pu=
blisher has not rebooted, the next event record on the stream which meets f=
iltering criteria will be the leading event record sent.  Otherwise, the le=
ading event record will be the first event record meeting filtering criteri=
a subsequent to the latest of three different times: the "replay-log-creati=
on-time", "replay-log-aged-time", or the most recent publisher boot time.

> > I have also made a corresponding tweak to the YANG model.
>=20
> In the leaf "configured-replay"?  I couldn't find this text.

Not in the configured-replay leaf, that looks good to me.   The first time =
this object is configured, this is when replay starts.   If it turns out th=
ere are multiple subscription-started notifications due to transport loss, =
the YANG model won't change.

To find the updated text, look for: refine "target/stream/replay-start-time=
"

Eric

[..]
> /martin


From nobody Thu Sep 13 10:25:49 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CD5130DF3 for ; Thu, 13 Sep 2018 10:25:47 -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 h99iBRsJcTBy for ; Thu, 13 Sep 2018 10:25:43 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1DA130E29 for ; Thu, 13 Sep 2018 10:25:42 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 24F621AE018A; Thu, 13 Sep 2018 19:25:41 +0200 (CEST)
Date: Thu, 13 Sep 2018 19:25:40 +0200 (CEST)
Message-Id: <20180913.192540.2025732002830196760.mbj@tail-f.com>
To: evoit@cisco.com
Cc: netconf@ietf.org, rrahman@cisco.com
From: Martin Bjorklund 
In-Reply-To: 
References: <20180913.092134.395462318086733174.mbj@tail-f.com> <20180913.162117.1031242545011500593.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 17:25:48 -0000

"Eric Voit (evoit)"  wrote:
> Hi Martin,
> 
> I am fine with the three text clarifications proposed, and will
> incorporate.  More in-line...
> 
> > From: Martin Bjorklund, September 13, 2018 10:21 AM
> > 
> > Hi,
> > 
> > One problematic thing below.
> > 
> > Martin Bjorklund  wrote:
> > > Hi,
> > >
> > > Thank you for addressing my comments.  More inline.
> > >
> > >
> > > "Eric Voit (evoit)"  wrote:
> > > > Hi Martin,
> > > >
> > > > Much incorporated.  Latest is at:
> > > > https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netc
> > > > onf-subscribed-notifications-17.txt
> > > >
> > > > Specific responses in-line...
> > > >
> > > > > From: Martin Bjorklund, September 12, 2018 5:35 AM
> > > > >
> > > > > "Eric Voit (evoit)"  wrote:
> > > > > > Thanks for the comments Martin,  thoughts in-line...
> > > > > >
> > > > > > > From: Martin Bjorklund, September 10, 2018 1:42 PM
> > > > >
> > > > > [...]
> > > > >
> > > > > > > o  Section 2.1
> > > > > > >
> > > > > > >   The text says:
> > > > > > >
> > > > > > >     It is out of the scope of this document
> > > > > > >     to identify [...] b) how event records are defined
> > > > > > >
> > > > > > >   Is this really what we want?  Shouldn't this document specify
> > > > > > >   that
> > > > > > >   an event record is an instance of a YANG "notification"
> > > > > > >   statement?
> > > > > > >   Do we want to support event records that are not defined in YANG?
> > > > > > >
> > > > > > >   This was discussed in the thread "comments on
> > > > > > >   draft-ietf-netconf-subscribed-notifications-12", and it seems
> > > > > > >   that
> > > > > > >   noone really have any use case for non-YANG-defined event
> > > > > > >   records,
> > > > > > >   accessed with YANG-defined operations.
> > > > > >
> > > > > > Yes this was discussed previously.  My reading was that others
> > > > > > wanted to support subscription to non-YANG events.
> > > > > > E.g., see Andy & Tianran's thoughts in
> > > > > > https://www.ietf.org/mail-archive/web/netconf/current/msg14764.h
> > > > > > tml
> > > > >
> > > > > Yes, but read on in that thread, see
> > > > > https://www.ietf.org/mail-archive/web/netconf/current/msg14766.htm
> > > > > l
> > > > > for a clarification.
> > > > >
> > > > > AFAIK, noone has presented a use case for sending non-YANG-defined
> > > > > data here.
> > > >
> > > > As anything can be YANG wrapped, per the thread above.  I am fine
> > > > with this.
> > > >
> > > > > > >   I think that this document should state that an event record is
> > > > > > >   an
> > > > > > >   instance of a YANG "notification" statement.  If not, it is
> > > > > > >   unclear
> > > > > > >   both how subtree/xpath filters and xml/json/... encodings would
> > work.
> > > > > >
> > > > > > Applying xpath filters against XML based event records seems
> > > > > > viable to me.
> > > > >
> > > > > Where does it say that it has to be XML?  Whatabout mixed-content?
> > > > > What if such a notification is sent when the encoding is JSON?
> > > > >
> > > > > If you want to make this specification open for other data
> > > > > modeling languages, I think you need to carefully define how that
> > > > > is supposed to work; essentially similar to how we handle
> > > > > transports; we have a set of requirement on what a transport
> > > > > document must define.  IMO this is super complicated and overkill.
> > > > > This draft is complex enough.
> > > > > Don't add even more complexity.
> > > >
> > > > If you are just saying that we can put everything into a YANG
> > > > wrapper, that is fine with me.  To clarify this, I have tweaked the
> > > > first sentence of Section 2.1 to:
> > > > "An event stream is a named entity on a publisher which exposes a
> > > > continuously updating set of YANG encoded event records."
> > >
> > > Howabout:
> > >
> > > OLD:
> > >
> > >    An event stream is a named entity on a publisher which exposes a
> > >    continuously updating set of event records.  Each event stream is
> > >    available for subscription.  It is out of the scope of this document
> > >    to identify a) how streams are defined (other than the NETCONF
> > >    stream), b) how event records are defined/generated, and c) how event
> > >    records are assigned to streams.
> > >
> > > NEW:
> > >
> > >    An event stream is a named entity on a publisher which exposes a
> > >    continuously updating set of event records.  An event record is
> > >    defined with the "notification" YANG statement.  Each event stream is
> > >    available for subscription.  It is out of the scope of this document
> > >    to identify a) how streams are defined (other than the NETCONF
> > >    stream), b) how event records are generated, and c) how event
> > >    records are assigned to streams.
> > >
> > > > And I have tweaked the first sentence of the third paragraph to:
> > > > "As YANG encoded event records are created by a system,..."
> > >
> > > I think the original sentence is better.
> > >
> > > Also, some tweaks are needed to the filter leafs in the YANG module:
> > >
> > > OLD:
> > >
> > >           The subtree filter is applied to the representation of
> > >           individual, delineated event records as contained within the
> > >           event stream.  For example, if the notification message
> > >           contains an instance of a notification defined in YANG, then
> > >           the top-level element is the name of the YANG notification.
> > >
> > > NEW:
> > >
> > >           The subtree filter is applied to the representation of
> > >           individual, delineated event records as contained within the
> > >           event stream.  The top-level element in the event record is
> > >           the name of the YANG notification.
> > >
> > > and
> > >
> > > OLD:
> > >
> > >            The XPath expression is evaluated on the representation of
> > >            individual, delineated event records as contained within
> > >            the event stream.  For example, if the notification message
> > >            contains an instance of a notification defined in YANG,
> > >            then the top-level element is the name of the YANG
> > >            notification, and the root node has this top-level element
> > >            as the only child.
> > >
> > > NEW:
> > >
> > >
> > >            The XPath expression is evaluated on the representation of
> > >            individual, delineated event records as contained within
> > >            the event stream.  The top-level element in the event
> > >            record is the name of the YANG notification, and the root
> > >            node has this top-level element as the only child.
> > 
> > 
> > This text is problematic b/c it doesn't work well with inline
> > notifications.
> > 
> > Consider the example in section 7.16.3 in RFC 7950:
> > 
> >        container interfaces {
> >          list interface {
> >            key "name";
> >            leaf name {
> >              type string;
> >            }
> >            notification interface-enabled {
> >              leaf by-user {
> >                type string;
> >              }
> >            }
> >          }
> >        }
> > 
> > and corresponding XML example:
> > 
> >       >        xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
> >        2008-07-08T00:01:00Z
> >        
> >          
> >            eth1
> >            
> >              fred
> >            
> >          
> >        
> >      
> > 
> > What, in this example, is the "event record"?  I assume it is this
> > part:
> > 
> >        
> >          
> >            eth1
> >            
> >              fred
> >            
> >          
> >        
> > 
> > But the element that is the name of the YANG notification is this:
> > 
> >            
> >              fred
> >            
> > 
> > 
> > (With draft-ietf-netconf-notification-message, the "event record"
> > would be placed in the  anydata)
> > 
> > 
> > A problem is that the containment hierarchy is defined in RFC 7950 in
> > the XML
> > encoding text.  There is no text in RFC 7951 or RFC 8040 for how to do
> > this in
> > JSON for RESTCONF.  It is natural to do a pure JSON-translation of the
> > XML
> > example, but this isn't specified anywhere.
> > 
> > 
> > So I propose the following tweaked changes:
> > 
> > 
> > OLD:
> > 
> >    An event stream is a named entity on a publisher which exposes a
> >    continuously updating set of event records.  Each event stream is
> >    available for subscription.  It is out of the scope of this document
> >    to identify a) how streams are defined (other than the NETCONF
> >    stream), b) how event records are defined/generated, and c) how event
> >    records are assigned to streams.
> > 
> > NEW:
> > 
> >    An event stream is a named entity on a publisher which exposes a
> >    continuously updating set of event records.  An event record is an
> >    intantiation of a "notification" YANG statement.  If the
> >    "notification" is defined as a child to a data node, the
> >    intantiation includes the hierarchy of nodes that identifies the
> >    data node in the datastore (see Section 7.16.2 of RFC 7950).  Each
> >    event stream is available for subscription.  It is out of the scope
> >    of this document to identify a) how streams are defined (other than
> >    the NETCONF stream), b) how event records are generated, and c) how
> >    event records are assigned to streams.
> > 
> > 
> > and in the YANG module:
> > 
> > OLD:
> > 
> >           The subtree filter is applied to the representation of
> >           individual, delineated event records as contained within the
> >           event stream.  For example, if the notification message
> >           contains an instance of a notification defined in YANG, then
> >           the top-level element is the name of the YANG notification.
> > 
> > NEW:
> > 
> >           The subtree filter is applied to the representation of
> >           individual, delineated event records as contained within the
> >           event stream.
> > 
> > and
> > 
> > OLD:
> > 
> >            The XPath expression is evaluated on the representation of
> >            individual, delineated event records as contained within
> >            the event stream.  For example, if the notification message
> >            contains an instance of a notification defined in YANG,
> >            then the top-level element is the name of the YANG
> >            notification, and the root node has this top-level element
> >            as the only child.
> > 
> > NEW:
> > 
> > 
> >            The XPath expression is evaluated on the representation of
> >            individual, delineated event records as contained within
> >            the event stream.
> > 
> > > (I think it would be useful with some filtering examples, like in
> > > section 5 of RFC 5277, but I think you have all examples in
> > > netconf-notif, so they would go into that draft.  (re-reading an old
> > > thread I found that examples for filters were requested before)).
> >
> > And I strongly think that we should add examples in an appendix, even
> > though
> > this is a protocol and encoding neutral document.  Maybe one example
> > with
> > NETCONF XML and one with RESTCONF JSON.  One example can show a
> > subtree filter and a top-level notif, and the other an XPath filter
> > with an inline
> > notif.
> 
> We have worked very hard to keep the document protocol agnostic.  Even
> the Appendix A example protocol for configured subscriptions is 'foo'.
> 
> If you are ok with it, I am completely fine with adding two such
> NETCONF XML filtering examples into a new Appendix section A.4 in
> NETCONF-Notif.  Perhaps Reshad would be able to do the same for
> RESTCONF JSON within RESTCONF-Notif.

I think that having an example in one encoding for one protocol (or
two of them) wouldn't make the document less protocol agnostic.  For
example RFC 8342 (the NMDA architecture document) has some XML
examples.

See also section 3.12 of rfc6087bis.  (at least once I added examples
to a document during the AD review).

Examples also help verify that the text is clear.

This said, I won't object to the document moving forward w/o
examples.


/martin


From nobody Thu Sep 13 10:28:09 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBFD130E47 for ; Thu, 13 Sep 2018 10:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_HIGH=-0.01, 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 W2y_d6S86bM4 for ; Thu, 13 Sep 2018 10:28:04 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C7E130E43 for ; Thu, 13 Sep 2018 10:28:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18146; q=dns/txt; s=iport; t=1536859684; x=1538069284; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=w+UTt3zQOSauEafeO+fW8N7eDnawXtHGjcRIiA+kx4E=; b=blazLcl0qOHMSn7nm6UlQsDUyxOZVAa81Hsij2JWjMk9uimkWerNqv9r RAodHIRD0Lv+KmNKkSg3q0n/ZpebcNlKdTiluvrJrI6gcFt2rp8cg64po LRVDaqR7bJNZKAnqQ0SrAPGWQcTRZtHrHx/z0tlRTdQ44oI45PICWdbev 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DuAQDjnZpb/5ldJa1RChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGBT4FdKmV/KAqDaJQvgWglgz2TAYF6CyMJg3pGAheDQSE?= =?us-ascii?q?1FwECAQECAQECbRwMhTgBAQEBAgEjEUMCEAIBCBUDAgIJHQICAjAVEAIEAQ0?= =?us-ascii?q?FglZLAYF5CA+leoEuhHKFFQWBC4ldF4FBP4ESJwwTgkyDGwIBgTULAQEeBxA?= =?us-ascii?q?jgkcxgiYCiDiFFo4JTwkChjmJVReBQYdIhXqLTog+AhEUgSUfAjSBVXAVOyo?= =?us-ascii?q?BgkGGAYUUhT5vAYEVikuBHwGBHQEB?=
X-IronPort-AV: E=Sophos;i="5.53,369,1531785600"; d="scan'208";a="451765392"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 17:28:02 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w8DHS2GV028001 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Sep 2018 17:28:02 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 13 Sep 2018 12:28:01 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Thu, 13 Sep 2018 12:28:01 -0500
From: "Reshad Rahman (rrahman)" 
To: "Eric Voit (evoit)" , Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of subscribed-notifications-16
Thread-Index: AQHUSS2cE8euTQ7TYUmcAsMJ9liqwqTrxeSAgADzQQCAAJcagIAA1gQAgAB1RICAAA0bgP//5AGA
Date: Thu, 13 Sep 2018 17:28:01 +0000
Message-ID: 
References: <20180912.113446.2017030234338816835.mbj@tail-f.com> <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com> <20180913.092134.395462318086733174.mbj@tail-f.com> <20180913.162117.1031242545011500593.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.98]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 17:28:08 -0000

UFNJLg0KDQrvu79PbiAyMDE4LTA5LTEzLCAxMTowOCBBTSwgIkVyaWMgVm9pdCAoZXZvaXQpIiA8
ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCg0KICAgIEhpIE1hcnRpbiwNCiAgICANCiAgICBJIGFt
IGZpbmUgd2l0aCB0aGUgdGhyZWUgdGV4dCBjbGFyaWZpY2F0aW9ucyBwcm9wb3NlZCwgYW5kIHdp
bGwgaW5jb3Jwb3JhdGUuICAgTW9yZSBpbi1saW5lLi4uDQogICAgDQogICAgPiBGcm9tOiBNYXJ0
aW4gQmpvcmtsdW5kLCBTZXB0ZW1iZXIgMTMsIDIwMTggMTA6MjEgQU0NCiAgICA+IA0KICAgID4g
SGksDQogICAgPiANCiAgICA+IE9uZSBwcm9ibGVtYXRpYyB0aGluZyBiZWxvdy4NCiAgICA+IA0K
ICAgID4gTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KICAgID4gPiBI
aSwNCiAgICA+ID4NCiAgICA+ID4gVGhhbmsgeW91IGZvciBhZGRyZXNzaW5nIG15IGNvbW1lbnRz
LiAgTW9yZSBpbmxpbmUuDQogICAgPiA+DQogICAgPiA+DQogICAgPiA+ICJFcmljIFZvaXQgKGV2
b2l0KSIgPGV2b2l0QGNpc2NvLmNvbT4gd3JvdGU6DQogICAgPiA+ID4gSGkgTWFydGluLA0KICAg
ID4gPiA+DQogICAgPiA+ID4gTXVjaCBpbmNvcnBvcmF0ZWQuICBMYXRlc3QgaXMgYXQ6DQogICAg
PiA+ID4gaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvcmZjNTI3N2Jpcy9ibG9iL21hc3Rl
ci9kcmFmdC1pZXRmLW5ldGMNCiAgICA+ID4gPiBvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25z
LTE3LnR4dA0KICAgID4gPiA+DQogICAgPiA+ID4gU3BlY2lmaWMgcmVzcG9uc2VzIGluLWxpbmUu
Li4NCiAgICA+ID4gPg0KICAgID4gPiA+ID4gRnJvbTogTWFydGluIEJqb3JrbHVuZCwgU2VwdGVt
YmVyIDEyLCAyMDE4IDU6MzUgQU0NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiAiRXJpYyBWb2l0
IChldm9pdCkiIDxldm9pdEBjaXNjby5jb20+IHdyb3RlOg0KICAgID4gPiA+ID4gPiBUaGFua3Mg
Zm9yIHRoZSBjb21tZW50cyBNYXJ0aW4sICB0aG91Z2h0cyBpbi1saW5lLi4uDQogICAgPiA+ID4g
PiA+DQogICAgPiA+ID4gPiA+ID4gRnJvbTogTWFydGluIEJqb3JrbHVuZCwgU2VwdGVtYmVyIDEw
LCAyMDE4IDE6NDIgUE0NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiBbLi4uXQ0KICAgID4gPiA+
ID4NCiAgICA+ID4gPiA+ID4gPiBvICBTZWN0aW9uIDIuMQ0KICAgID4gPiA+ID4gPiA+DQogICAg
PiA+ID4gPiA+ID4gICBUaGUgdGV4dCBzYXlzOg0KICAgID4gPiA+ID4gPiA+DQogICAgPiA+ID4g
PiA+ID4gICAgIEl0IGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudA0KICAgID4g
PiA+ID4gPiA+ICAgICB0byBpZGVudGlmeSBbLi4uXSBiKSBob3cgZXZlbnQgcmVjb3JkcyBhcmUg
ZGVmaW5lZA0KICAgID4gPiA+ID4gPiA+DQogICAgPiA+ID4gPiA+ID4gICBJcyB0aGlzIHJlYWxs
eSB3aGF0IHdlIHdhbnQ/ICBTaG91bGRuJ3QgdGhpcyBkb2N1bWVudCBzcGVjaWZ5IHRoYXQNCiAg
ICA+ID4gPiA+ID4gPiAgIGFuIGV2ZW50IHJlY29yZCBpcyBhbiBpbnN0YW5jZSBvZiBhIFlBTkcg
Im5vdGlmaWNhdGlvbiIgc3RhdGVtZW50Pw0KICAgID4gPiA+ID4gPiA+ICAgRG8gd2Ugd2FudCB0
byBzdXBwb3J0IGV2ZW50IHJlY29yZHMgdGhhdCBhcmUgbm90IGRlZmluZWQgaW4gWUFORz8NCiAg
ICA+ID4gPiA+ID4gPg0KICAgID4gPiA+ID4gPiA+ICAgVGhpcyB3YXMgZGlzY3Vzc2VkIGluIHRo
ZSB0aHJlYWQgImNvbW1lbnRzIG9uDQogICAgPiA+ID4gPiA+ID4gICBkcmFmdC1pZXRmLW5ldGNv
bmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLTEyIiwgYW5kIGl0IHNlZW1zIHRoYXQNCiAgICA+
ID4gPiA+ID4gPiAgIG5vb25lIHJlYWxseSBoYXZlIGFueSB1c2UgY2FzZSBmb3Igbm9uLVlBTkct
ZGVmaW5lZCBldmVudCByZWNvcmRzLA0KICAgID4gPiA+ID4gPiA+ICAgYWNjZXNzZWQgd2l0aCBZ
QU5HLWRlZmluZWQgb3BlcmF0aW9ucy4NCiAgICA+ID4gPiA+ID4NCiAgICA+ID4gPiA+ID4gWWVz
IHRoaXMgd2FzIGRpc2N1c3NlZCBwcmV2aW91c2x5LiAgTXkgcmVhZGluZyB3YXMgdGhhdCBvdGhl
cnMNCiAgICA+ID4gPiA+ID4gd2FudGVkIHRvIHN1cHBvcnQgc3Vic2NyaXB0aW9uIHRvIG5vbi1Z
QU5HIGV2ZW50cy4NCiAgICA+ID4gPiA+ID4gRS5nLiwgc2VlIEFuZHkgJiBUaWFucmFuJ3MgdGhv
dWdodHMgaW4NCiAgICA+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl
L3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMTQ3NjQuaA0KICAgID4gPiA+ID4gPiB0bWwNCiAgICA+
ID4gPiA+DQogICAgPiA+ID4gPiBZZXMsIGJ1dCByZWFkIG9uIGluIHRoYXQgdGhyZWFkLCBzZWUN
CiAgICA+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0Y29u
Zi9jdXJyZW50L21zZzE0NzY2Lmh0bQ0KICAgID4gPiA+ID4gbA0KICAgID4gPiA+ID4gZm9yIGEg
Y2xhcmlmaWNhdGlvbi4NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiBBRkFJSywgbm9vbmUgaGFz
IHByZXNlbnRlZCBhIHVzZSBjYXNlIGZvciBzZW5kaW5nIG5vbi1ZQU5HLWRlZmluZWQNCiAgICA+
ID4gPiA+IGRhdGEgaGVyZS4NCiAgICA+ID4gPg0KICAgID4gPiA+IEFzIGFueXRoaW5nIGNhbiBi
ZSBZQU5HIHdyYXBwZWQsIHBlciB0aGUgdGhyZWFkIGFib3ZlLiAgSSBhbSBmaW5lDQogICAgPiA+
ID4gd2l0aCB0aGlzLg0KICAgID4gPiA+DQogICAgPiA+ID4gPiA+ID4gICBJIHRoaW5rIHRoYXQg
dGhpcyBkb2N1bWVudCBzaG91bGQgc3RhdGUgdGhhdCBhbiBldmVudCByZWNvcmQgaXMgYW4NCiAg
ICA+ID4gPiA+ID4gPiAgIGluc3RhbmNlIG9mIGEgWUFORyAibm90aWZpY2F0aW9uIiBzdGF0ZW1l
bnQuICBJZiBub3QsIGl0IGlzIHVuY2xlYXINCiAgICA+ID4gPiA+ID4gPiAgIGJvdGggaG93IHN1
YnRyZWUveHBhdGggZmlsdGVycyBhbmQgeG1sL2pzb24vLi4uIGVuY29kaW5ncyB3b3VsZA0KICAg
ID4gd29yay4NCiAgICA+ID4gPiA+ID4NCiAgICA+ID4gPiA+ID4gQXBwbHlpbmcgeHBhdGggZmls
dGVycyBhZ2FpbnN0IFhNTCBiYXNlZCBldmVudCByZWNvcmRzIHNlZW1zDQogICAgPiA+ID4gPiA+
IHZpYWJsZSB0byBtZS4NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiBXaGVyZSBkb2VzIGl0IHNh
eSB0aGF0IGl0IGhhcyB0byBiZSBYTUw/ICBXaGF0YWJvdXQgbWl4ZWQtY29udGVudD8NCiAgICA+
ID4gPiA+IFdoYXQgaWYgc3VjaCBhIG5vdGlmaWNhdGlvbiBpcyBzZW50IHdoZW4gdGhlIGVuY29k
aW5nIGlzIEpTT04/DQogICAgPiA+ID4gPg0KICAgID4gPiA+ID4gSWYgeW91IHdhbnQgdG8gbWFr
ZSB0aGlzIHNwZWNpZmljYXRpb24gb3BlbiBmb3Igb3RoZXIgZGF0YQ0KICAgID4gPiA+ID4gbW9k
ZWxpbmcgbGFuZ3VhZ2VzLCBJIHRoaW5rIHlvdSBuZWVkIHRvIGNhcmVmdWxseSBkZWZpbmUgaG93
IHRoYXQNCiAgICA+ID4gPiA+IGlzIHN1cHBvc2VkIHRvIHdvcms7IGVzc2VudGlhbGx5IHNpbWls
YXIgdG8gaG93IHdlIGhhbmRsZQ0KICAgID4gPiA+ID4gdHJhbnNwb3J0czsgd2UgaGF2ZSBhIHNl
dCBvZiByZXF1aXJlbWVudCBvbiB3aGF0IGEgdHJhbnNwb3J0DQogICAgPiA+ID4gPiBkb2N1bWVu
dCBtdXN0IGRlZmluZS4gIElNTyB0aGlzIGlzIHN1cGVyIGNvbXBsaWNhdGVkIGFuZCBvdmVya2ls
bC4NCiAgICA+ID4gPiA+IFRoaXMgZHJhZnQgaXMgY29tcGxleCBlbm91Z2guDQogICAgPiA+ID4g
PiBEb24ndCBhZGQgZXZlbiBtb3JlIGNvbXBsZXhpdHkuDQogICAgPiA+ID4NCiAgICA+ID4gPiBJ
ZiB5b3UgYXJlIGp1c3Qgc2F5aW5nIHRoYXQgd2UgY2FuIHB1dCBldmVyeXRoaW5nIGludG8gYSBZ
QU5HDQogICAgPiA+ID4gd3JhcHBlciwgdGhhdCBpcyBmaW5lIHdpdGggbWUuICBUbyBjbGFyaWZ5
IHRoaXMsIEkgaGF2ZSB0d2Vha2VkIHRoZQ0KICAgID4gPiA+IGZpcnN0IHNlbnRlbmNlIG9mIFNl
Y3Rpb24gMi4xIHRvOg0KICAgID4gPiA+ICJBbiBldmVudCBzdHJlYW0gaXMgYSBuYW1lZCBlbnRp
dHkgb24gYSBwdWJsaXNoZXIgd2hpY2ggZXhwb3NlcyBhDQogICAgPiA+ID4gY29udGludW91c2x5
IHVwZGF0aW5nIHNldCBvZiBZQU5HIGVuY29kZWQgZXZlbnQgcmVjb3Jkcy4iDQogICAgPiA+DQog
ICAgPiA+IEhvd2Fib3V0Og0KICAgID4gPg0KICAgID4gPiBPTEQ6DQogICAgPiA+DQogICAgPiA+
ICAgIEFuIGV2ZW50IHN0cmVhbSBpcyBhIG5hbWVkIGVudGl0eSBvbiBhIHB1Ymxpc2hlciB3aGlj
aCBleHBvc2VzIGENCiAgICA+ID4gICAgY29udGludW91c2x5IHVwZGF0aW5nIHNldCBvZiBldmVu
dCByZWNvcmRzLiAgRWFjaCBldmVudCBzdHJlYW0gaXMNCiAgICA+ID4gICAgYXZhaWxhYmxlIGZv
ciBzdWJzY3JpcHRpb24uICBJdCBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQN
CiAgICA+ID4gICAgdG8gaWRlbnRpZnkgYSkgaG93IHN0cmVhbXMgYXJlIGRlZmluZWQgKG90aGVy
IHRoYW4gdGhlIE5FVENPTkYNCiAgICA+ID4gICAgc3RyZWFtKSwgYikgaG93IGV2ZW50IHJlY29y
ZHMgYXJlIGRlZmluZWQvZ2VuZXJhdGVkLCBhbmQgYykgaG93IGV2ZW50DQogICAgPiA+ICAgIHJl
Y29yZHMgYXJlIGFzc2lnbmVkIHRvIHN0cmVhbXMuDQogICAgPiA+DQogICAgPiA+IE5FVzoNCiAg
ICA+ID4NCiAgICA+ID4gICAgQW4gZXZlbnQgc3RyZWFtIGlzIGEgbmFtZWQgZW50aXR5IG9uIGEg
cHVibGlzaGVyIHdoaWNoIGV4cG9zZXMgYQ0KICAgID4gPiAgICBjb250aW51b3VzbHkgdXBkYXRp
bmcgc2V0IG9mIGV2ZW50IHJlY29yZHMuICBBbiBldmVudCByZWNvcmQgaXMNCiAgICA+ID4gICAg
ZGVmaW5lZCB3aXRoIHRoZSAibm90aWZpY2F0aW9uIiBZQU5HIHN0YXRlbWVudC4gIEVhY2ggZXZl
bnQgc3RyZWFtIGlzDQogICAgPiA+ICAgIGF2YWlsYWJsZSBmb3Igc3Vic2NyaXB0aW9uLiAgSXQg
aXMgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50DQogICAgPiA+ICAgIHRvIGlkZW50
aWZ5IGEpIGhvdyBzdHJlYW1zIGFyZSBkZWZpbmVkIChvdGhlciB0aGFuIHRoZSBORVRDT05GDQog
ICAgPiA+ICAgIHN0cmVhbSksIGIpIGhvdyBldmVudCByZWNvcmRzIGFyZSBnZW5lcmF0ZWQsIGFu
ZCBjKSBob3cgZXZlbnQNCiAgICA+ID4gICAgcmVjb3JkcyBhcmUgYXNzaWduZWQgdG8gc3RyZWFt
cy4NCiAgICA+ID4NCiAgICA+ID4gPiBBbmQgSSBoYXZlIHR3ZWFrZWQgdGhlIGZpcnN0IHNlbnRl
bmNlIG9mIHRoZSB0aGlyZCBwYXJhZ3JhcGggdG86DQogICAgPiA+ID4gIkFzIFlBTkcgZW5jb2Rl
ZCBldmVudCByZWNvcmRzIGFyZSBjcmVhdGVkIGJ5IGEgc3lzdGVtLC4uLiINCiAgICA+ID4NCiAg
ICA+ID4gSSB0aGluayB0aGUgb3JpZ2luYWwgc2VudGVuY2UgaXMgYmV0dGVyLg0KICAgID4gPg0K
ICAgID4gPiBBbHNvLCBzb21lIHR3ZWFrcyBhcmUgbmVlZGVkIHRvIHRoZSBmaWx0ZXIgbGVhZnMg
aW4gdGhlIFlBTkcgbW9kdWxlOg0KICAgID4gPg0KICAgID4gPiBPTEQ6DQogICAgPiA+DQogICAg
PiA+ICAgICAgICAgICBUaGUgc3VidHJlZSBmaWx0ZXIgaXMgYXBwbGllZCB0byB0aGUgcmVwcmVz
ZW50YXRpb24gb2YNCiAgICA+ID4gICAgICAgICAgIGluZGl2aWR1YWwsIGRlbGluZWF0ZWQgZXZl
bnQgcmVjb3JkcyBhcyBjb250YWluZWQgd2l0aGluIHRoZQ0KICAgID4gPiAgICAgICAgICAgZXZl
bnQgc3RyZWFtLiAgRm9yIGV4YW1wbGUsIGlmIHRoZSBub3RpZmljYXRpb24gbWVzc2FnZQ0KICAg
ID4gPiAgICAgICAgICAgY29udGFpbnMgYW4gaW5zdGFuY2Ugb2YgYSBub3RpZmljYXRpb24gZGVm
aW5lZCBpbiBZQU5HLCB0aGVuDQogICAgPiA+ICAgICAgICAgICB0aGUgdG9wLWxldmVsIGVsZW1l
bnQgaXMgdGhlIG5hbWUgb2YgdGhlIFlBTkcgbm90aWZpY2F0aW9uLg0KICAgID4gPg0KICAgID4g
PiBORVc6DQogICAgPiA+DQogICAgPiA+ICAgICAgICAgICBUaGUgc3VidHJlZSBmaWx0ZXIgaXMg
YXBwbGllZCB0byB0aGUgcmVwcmVzZW50YXRpb24gb2YNCiAgICA+ID4gICAgICAgICAgIGluZGl2
aWR1YWwsIGRlbGluZWF0ZWQgZXZlbnQgcmVjb3JkcyBhcyBjb250YWluZWQgd2l0aGluIHRoZQ0K
ICAgID4gPiAgICAgICAgICAgZXZlbnQgc3RyZWFtLiAgVGhlIHRvcC1sZXZlbCBlbGVtZW50IGlu
IHRoZSBldmVudCByZWNvcmQgaXMNCiAgICA+ID4gICAgICAgICAgIHRoZSBuYW1lIG9mIHRoZSBZ
QU5HIG5vdGlmaWNhdGlvbi4NCiAgICA+ID4NCiAgICA+ID4gYW5kDQogICAgPiA+DQogICAgPiA+
IE9MRDoNCiAgICA+ID4NCiAgICA+ID4gICAgICAgICAgICBUaGUgWFBhdGggZXhwcmVzc2lvbiBp
cyBldmFsdWF0ZWQgb24gdGhlIHJlcHJlc2VudGF0aW9uIG9mDQogICAgPiA+ICAgICAgICAgICAg
aW5kaXZpZHVhbCwgZGVsaW5lYXRlZCBldmVudCByZWNvcmRzIGFzIGNvbnRhaW5lZCB3aXRoaW4N
CiAgICA+ID4gICAgICAgICAgICB0aGUgZXZlbnQgc3RyZWFtLiAgRm9yIGV4YW1wbGUsIGlmIHRo
ZSBub3RpZmljYXRpb24gbWVzc2FnZQ0KICAgID4gPiAgICAgICAgICAgIGNvbnRhaW5zIGFuIGlu
c3RhbmNlIG9mIGEgbm90aWZpY2F0aW9uIGRlZmluZWQgaW4gWUFORywNCiAgICA+ID4gICAgICAg
ICAgICB0aGVuIHRoZSB0b3AtbGV2ZWwgZWxlbWVudCBpcyB0aGUgbmFtZSBvZiB0aGUgWUFORw0K
ICAgID4gPiAgICAgICAgICAgIG5vdGlmaWNhdGlvbiwgYW5kIHRoZSByb290IG5vZGUgaGFzIHRo
aXMgdG9wLWxldmVsIGVsZW1lbnQNCiAgICA+ID4gICAgICAgICAgICBhcyB0aGUgb25seSBjaGls
ZC4NCiAgICA+ID4NCiAgICA+ID4gTkVXOg0KICAgID4gPg0KICAgID4gPg0KICAgID4gPiAgICAg
ICAgICAgIFRoZSBYUGF0aCBleHByZXNzaW9uIGlzIGV2YWx1YXRlZCBvbiB0aGUgcmVwcmVzZW50
YXRpb24gb2YNCiAgICA+ID4gICAgICAgICAgICBpbmRpdmlkdWFsLCBkZWxpbmVhdGVkIGV2ZW50
IHJlY29yZHMgYXMgY29udGFpbmVkIHdpdGhpbg0KICAgID4gPiAgICAgICAgICAgIHRoZSBldmVu
dCBzdHJlYW0uICBUaGUgdG9wLWxldmVsIGVsZW1lbnQgaW4gdGhlIGV2ZW50DQogICAgPiA+ICAg
ICAgICAgICAgcmVjb3JkIGlzIHRoZSBuYW1lIG9mIHRoZSBZQU5HIG5vdGlmaWNhdGlvbiwgYW5k
IHRoZSByb290DQogICAgPiA+ICAgICAgICAgICAgbm9kZSBoYXMgdGhpcyB0b3AtbGV2ZWwgZWxl
bWVudCBhcyB0aGUgb25seSBjaGlsZC4NCiAgICA+IA0KICAgID4gDQogICAgPiBUaGlzIHRleHQg
aXMgcHJvYmxlbWF0aWMgYi9jIGl0IGRvZXNuJ3Qgd29yayB3ZWxsIHdpdGggaW5saW5lIG5vdGlm
aWNhdGlvbnMuDQogICAgPiANCiAgICA+IENvbnNpZGVyIHRoZSBleGFtcGxlIGluIHNlY3Rpb24g
Ny4xNi4zIGluIFJGQyA3OTUwOg0KICAgID4gDQogICAgPiAgICAgICAgY29udGFpbmVyIGludGVy
ZmFjZXMgew0KICAgID4gICAgICAgICAgbGlzdCBpbnRlcmZhY2Ugew0KICAgID4gICAgICAgICAg
ICBrZXkgIm5hbWUiOw0KICAgID4gICAgICAgICAgICBsZWFmIG5hbWUgew0KICAgID4gICAgICAg
ICAgICAgIHR5cGUgc3RyaW5nOw0KICAgID4gICAgICAgICAgICB9DQogICAgPiAgICAgICAgICAg
IG5vdGlmaWNhdGlvbiBpbnRlcmZhY2UtZW5hYmxlZCB7DQogICAgPiAgICAgICAgICAgICAgbGVh
ZiBieS11c2VyIHsNCiAgICA+ICAgICAgICAgICAgICAgIHR5cGUgc3RyaW5nOw0KICAgID4gICAg
ICAgICAgICAgIH0NCiAgICA+ICAgICAgICAgICAgfQ0KICAgID4gICAgICAgICAgfQ0KICAgID4g
ICAgICAgIH0NCiAgICA+IA0KICAgID4gYW5kIGNvcnJlc3BvbmRpbmcgWE1MIGV4YW1wbGU6DQog
ICAgPiANCiAgICA+ICAgICAgPG5vdGlmaWNhdGlvbg0KICAgID4gICAgICAgIHhtbG5zPSJ1cm46
aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9uOjEuMCI+DQogICAgPiAgICAg
ICAgPGV2ZW50VGltZT4yMDA4LTA3LTA4VDAwOjAxOjAwWjwvZXZlbnRUaW1lPg0KICAgID4gICAg
ICAgIDxpbnRlcmZhY2VzIHhtbG5zPSJ1cm46ZXhhbXBsZTppbnRlcmZhY2UtbW9kdWxlIj4NCiAg
ICA+ICAgICAgICAgIDxpbnRlcmZhY2U+DQogICAgPiAgICAgICAgICAgIDxuYW1lPmV0aDE8L25h
bWU+DQogICAgPiAgICAgICAgICAgIDxpbnRlcmZhY2UtZW5hYmxlZD4NCiAgICA+ICAgICAgICAg
ICAgICA8YnktdXNlcj5mcmVkPC9ieS11c2VyPg0KICAgID4gICAgICAgICAgICA8L2ludGVyZmFj
ZS1lbmFibGVkPg0KICAgID4gICAgICAgICAgPC9pbnRlcmZhY2U+DQogICAgPiAgICAgICAgPC9p
bnRlcmZhY2VzPg0KICAgID4gICAgICA8L25vdGlmaWNhdGlvbj4NCiAgICA+IA0KICAgID4gV2hh
dCwgaW4gdGhpcyBleGFtcGxlLCBpcyB0aGUgImV2ZW50IHJlY29yZCI/ICBJIGFzc3VtZSBpdCBp
cyB0aGlzDQogICAgPiBwYXJ0Og0KICAgID4gDQogICAgPiAgICAgICAgPGludGVyZmFjZXMgeG1s
bnM9InVybjpleGFtcGxlOmludGVyZmFjZS1tb2R1bGUiPg0KICAgID4gICAgICAgICAgPGludGVy
ZmFjZT4NCiAgICA+ICAgICAgICAgICAgPG5hbWU+ZXRoMTwvbmFtZT4NCiAgICA+ICAgICAgICAg
ICAgPGludGVyZmFjZS1lbmFibGVkPg0KICAgID4gICAgICAgICAgICAgIDxieS11c2VyPmZyZWQ8
L2J5LXVzZXI+DQogICAgPiAgICAgICAgICAgIDwvaW50ZXJmYWNlLWVuYWJsZWQ+DQogICAgPiAg
ICAgICAgICA8L2ludGVyZmFjZT4NCiAgICA+ICAgICAgICA8L2ludGVyZmFjZXM+DQogICAgPiAN
CiAgICA+IEJ1dCB0aGUgZWxlbWVudCB0aGF0IGlzIHRoZSBuYW1lIG9mIHRoZSBZQU5HIG5vdGlm
aWNhdGlvbiBpcyB0aGlzOg0KICAgID4gDQogICAgPiAgICAgICAgICAgIDxpbnRlcmZhY2UtZW5h
YmxlZD4NCiAgICA+ICAgICAgICAgICAgICA8YnktdXNlcj5mcmVkPC9ieS11c2VyPg0KICAgID4g
ICAgICAgICAgICA8L2ludGVyZmFjZS1lbmFibGVkPg0KICAgID4gDQogICAgPiANCiAgICA+IChX
aXRoIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZSwgdGhlICJldmVudCBy
ZWNvcmQiDQogICAgPiB3b3VsZCBiZSBwbGFjZWQgaW4gdGhlIDxub3RpZmljYXRpb24tY29udGVu
dHM+IGFueWRhdGEpDQogICAgPiANCiAgICA+IA0KICAgID4gQSBwcm9ibGVtIGlzIHRoYXQgdGhl
IGNvbnRhaW5tZW50IGhpZXJhcmNoeSBpcyBkZWZpbmVkIGluIFJGQyA3OTUwIGluIHRoZSBYTUwN
CiAgICA+IGVuY29kaW5nIHRleHQuICBUaGVyZSBpcyBubyB0ZXh0IGluIFJGQyA3OTUxIG9yIFJG
QyA4MDQwIGZvciBob3cgdG8gZG8gdGhpcyBpbg0KICAgID4gSlNPTiBmb3IgUkVTVENPTkYuICBJ
dCBpcyBuYXR1cmFsIHRvIGRvIGEgcHVyZSBKU09OLXRyYW5zbGF0aW9uIG9mIHRoZSBYTUwNCiAg
ICA+IGV4YW1wbGUsIGJ1dCB0aGlzIGlzbid0IHNwZWNpZmllZCBhbnl3aGVyZS4NCiAgICA+IA0K
ICAgID4gDQogICAgPiBTbyBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0d2Vha2VkIGNoYW5nZXM6
DQogICAgPiANCiAgICA+IA0KICAgID4gT0xEOg0KICAgID4gDQogICAgPiAgICBBbiBldmVudCBz
dHJlYW0gaXMgYSBuYW1lZCBlbnRpdHkgb24gYSBwdWJsaXNoZXIgd2hpY2ggZXhwb3NlcyBhDQog
ICAgPiAgICBjb250aW51b3VzbHkgdXBkYXRpbmcgc2V0IG9mIGV2ZW50IHJlY29yZHMuICBFYWNo
IGV2ZW50IHN0cmVhbSBpcw0KICAgID4gICAgYXZhaWxhYmxlIGZvciBzdWJzY3JpcHRpb24uICBJ
dCBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQNCiAgICA+ICAgIHRvIGlkZW50
aWZ5IGEpIGhvdyBzdHJlYW1zIGFyZSBkZWZpbmVkIChvdGhlciB0aGFuIHRoZSBORVRDT05GDQog
ICAgPiAgICBzdHJlYW0pLCBiKSBob3cgZXZlbnQgcmVjb3JkcyBhcmUgZGVmaW5lZC9nZW5lcmF0
ZWQsIGFuZCBjKSBob3cgZXZlbnQNCiAgICA+ICAgIHJlY29yZHMgYXJlIGFzc2lnbmVkIHRvIHN0
cmVhbXMuDQogICAgPiANCiAgICA+IE5FVzoNCiAgICA+IA0KICAgID4gICAgQW4gZXZlbnQgc3Ry
ZWFtIGlzIGEgbmFtZWQgZW50aXR5IG9uIGEgcHVibGlzaGVyIHdoaWNoIGV4cG9zZXMgYQ0KICAg
ID4gICAgY29udGludW91c2x5IHVwZGF0aW5nIHNldCBvZiBldmVudCByZWNvcmRzLiAgQW4gZXZl
bnQgcmVjb3JkIGlzIGFuDQogICAgPiAgICBpbnRhbnRpYXRpb24gb2YgYSAibm90aWZpY2F0aW9u
IiBZQU5HIHN0YXRlbWVudC4gIElmIHRoZQ0KICAgID4gICAgIm5vdGlmaWNhdGlvbiIgaXMgZGVm
aW5lZCBhcyBhIGNoaWxkIHRvIGEgZGF0YSBub2RlLCB0aGUNCiAgICA+ICAgIGludGFudGlhdGlv
biBpbmNsdWRlcyB0aGUgaGllcmFyY2h5IG9mIG5vZGVzIHRoYXQgaWRlbnRpZmllcyB0aGUNCiAg
ICA+ICAgIGRhdGEgbm9kZSBpbiB0aGUgZGF0YXN0b3JlIChzZWUgU2VjdGlvbiA3LjE2LjIgb2Yg
UkZDIDc5NTApLiAgRWFjaA0KICAgID4gICAgZXZlbnQgc3RyZWFtIGlzIGF2YWlsYWJsZSBmb3Ig
c3Vic2NyaXB0aW9uLiAgSXQgaXMgb3V0IG9mIHRoZSBzY29wZQ0KICAgID4gICAgb2YgdGhpcyBk
b2N1bWVudCB0byBpZGVudGlmeSBhKSBob3cgc3RyZWFtcyBhcmUgZGVmaW5lZCAob3RoZXIgdGhh
bg0KICAgID4gICAgdGhlIE5FVENPTkYgc3RyZWFtKSwgYikgaG93IGV2ZW50IHJlY29yZHMgYXJl
IGdlbmVyYXRlZCwgYW5kIGMpIGhvdw0KICAgID4gICAgZXZlbnQgcmVjb3JkcyBhcmUgYXNzaWdu
ZWQgdG8gc3RyZWFtcy4NCiAgICA+IA0KICAgID4gDQogICAgPiBhbmQgaW4gdGhlIFlBTkcgbW9k
dWxlOg0KICAgID4gDQogICAgPiBPTEQ6DQogICAgPiANCiAgICA+ICAgICAgICAgICBUaGUgc3Vi
dHJlZSBmaWx0ZXIgaXMgYXBwbGllZCB0byB0aGUgcmVwcmVzZW50YXRpb24gb2YNCiAgICA+ICAg
ICAgICAgICBpbmRpdmlkdWFsLCBkZWxpbmVhdGVkIGV2ZW50IHJlY29yZHMgYXMgY29udGFpbmVk
IHdpdGhpbiB0aGUNCiAgICA+ICAgICAgICAgICBldmVudCBzdHJlYW0uICBGb3IgZXhhbXBsZSwg
aWYgdGhlIG5vdGlmaWNhdGlvbiBtZXNzYWdlDQogICAgPiAgICAgICAgICAgY29udGFpbnMgYW4g
aW5zdGFuY2Ugb2YgYSBub3RpZmljYXRpb24gZGVmaW5lZCBpbiBZQU5HLCB0aGVuDQogICAgPiAg
ICAgICAgICAgdGhlIHRvcC1sZXZlbCBlbGVtZW50IGlzIHRoZSBuYW1lIG9mIHRoZSBZQU5HIG5v
dGlmaWNhdGlvbi4NCiAgICA+IA0KICAgID4gTkVXOg0KICAgID4gDQogICAgPiAgICAgICAgICAg
VGhlIHN1YnRyZWUgZmlsdGVyIGlzIGFwcGxpZWQgdG8gdGhlIHJlcHJlc2VudGF0aW9uIG9mDQog
ICAgPiAgICAgICAgICAgaW5kaXZpZHVhbCwgZGVsaW5lYXRlZCBldmVudCByZWNvcmRzIGFzIGNv
bnRhaW5lZCB3aXRoaW4gdGhlDQogICAgPiAgICAgICAgICAgZXZlbnQgc3RyZWFtLg0KICAgID4g
DQogICAgPiBhbmQNCiAgICA+IA0KICAgID4gT0xEOg0KICAgID4gDQogICAgPiAgICAgICAgICAg
IFRoZSBYUGF0aCBleHByZXNzaW9uIGlzIGV2YWx1YXRlZCBvbiB0aGUgcmVwcmVzZW50YXRpb24g
b2YNCiAgICA+ICAgICAgICAgICAgaW5kaXZpZHVhbCwgZGVsaW5lYXRlZCBldmVudCByZWNvcmRz
IGFzIGNvbnRhaW5lZCB3aXRoaW4NCiAgICA+ICAgICAgICAgICAgdGhlIGV2ZW50IHN0cmVhbS4g
IEZvciBleGFtcGxlLCBpZiB0aGUgbm90aWZpY2F0aW9uIG1lc3NhZ2UNCiAgICA+ICAgICAgICAg
ICAgY29udGFpbnMgYW4gaW5zdGFuY2Ugb2YgYSBub3RpZmljYXRpb24gZGVmaW5lZCBpbiBZQU5H
LA0KICAgID4gICAgICAgICAgICB0aGVuIHRoZSB0b3AtbGV2ZWwgZWxlbWVudCBpcyB0aGUgbmFt
ZSBvZiB0aGUgWUFORw0KICAgID4gICAgICAgICAgICBub3RpZmljYXRpb24sIGFuZCB0aGUgcm9v
dCBub2RlIGhhcyB0aGlzIHRvcC1sZXZlbCBlbGVtZW50DQogICAgPiAgICAgICAgICAgIGFzIHRo
ZSBvbmx5IGNoaWxkLg0KICAgID4gDQogICAgPiBORVc6DQogICAgPiANCiAgICA+IA0KICAgID4g
ICAgICAgICAgICBUaGUgWFBhdGggZXhwcmVzc2lvbiBpcyBldmFsdWF0ZWQgb24gdGhlIHJlcHJl
c2VudGF0aW9uIG9mDQogICAgPiAgICAgICAgICAgIGluZGl2aWR1YWwsIGRlbGluZWF0ZWQgZXZl
bnQgcmVjb3JkcyBhcyBjb250YWluZWQgd2l0aGluDQogICAgPiAgICAgICAgICAgIHRoZSBldmVu
dCBzdHJlYW0uDQogICAgPiANCiAgICA+ID4gKEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIHdp
dGggc29tZSBmaWx0ZXJpbmcgZXhhbXBsZXMsIGxpa2UgaW4NCiAgICA+ID4gc2VjdGlvbiA1IG9m
IFJGQyA1Mjc3LCBidXQgSSB0aGluayB5b3UgaGF2ZSBhbGwgZXhhbXBsZXMgaW4NCiAgICA+ID4g
bmV0Y29uZi1ub3RpZiwgc28gdGhleSB3b3VsZCBnbyBpbnRvIHRoYXQgZHJhZnQuICAocmUtcmVh
ZGluZyBhbiBvbGQNCiAgICA+ID4gdGhyZWFkIEkgZm91bmQgdGhhdCBleGFtcGxlcyBmb3IgZmls
dGVycyB3ZXJlIHJlcXVlc3RlZCBiZWZvcmUpKS4NCiAgICA+DQogICAgPiBBbmQgSSBzdHJvbmds
eSB0aGluayB0aGF0IHdlIHNob3VsZCBhZGQgZXhhbXBsZXMgaW4gYW4gYXBwZW5kaXgsIGV2ZW4g
dGhvdWdoDQogICAgPiB0aGlzIGlzIGEgcHJvdG9jb2wgYW5kIGVuY29kaW5nIG5ldXRyYWwgZG9j
dW1lbnQuICBNYXliZSBvbmUgZXhhbXBsZSB3aXRoDQogICAgPiBORVRDT05GIFhNTCBhbmQgb25l
IHdpdGggUkVTVENPTkYgSlNPTi4gIE9uZSBleGFtcGxlIGNhbiBzaG93IGENCiAgICA+IHN1YnRy
ZWUgZmlsdGVyIGFuZCBhIHRvcC1sZXZlbCBub3RpZiwgYW5kIHRoZSBvdGhlciBhbiBYUGF0aCBm
aWx0ZXIgd2l0aCBhbiBpbmxpbmUNCiAgICA+IG5vdGlmLg0KICAgIA0KICAgIFdlIGhhdmUgd29y
a2VkIHZlcnkgaGFyZCB0byBrZWVwIHRoZSBkb2N1bWVudCBwcm90b2NvbCBhZ25vc3RpYy4gIEV2
ZW4gdGhlIEFwcGVuZGl4IEEgZXhhbXBsZSBwcm90b2NvbCBmb3IgY29uZmlndXJlZCBzdWJzY3Jp
cHRpb25zIGlzICdmb28nLg0KICAgIA0KICAgIElmIHlvdSBhcmUgb2sgd2l0aCBpdCwgSSBhbSBj
b21wbGV0ZWx5IGZpbmUgd2l0aCBhZGRpbmcgdHdvIHN1Y2ggTkVUQ09ORiBYTUwgZmlsdGVyaW5n
IGV4YW1wbGVzIGludG8gYSBuZXcgQXBwZW5kaXggc2VjdGlvbiBBLjQgaW4gTkVUQ09ORi1Ob3Rp
Zi4gIFBlcmhhcHMgUmVzaGFkIHdvdWxkIGJlIGFibGUgdG8gZG8gdGhlIHNhbWUgZm9yIFJFU1RD
T05GIEpTT04gd2l0aGluIFJFU1RDT05GLU5vdGlmLg0KICAgIA0KICAgIEVyaWMNCiAgICANCiAg
ICA8UlI+IFllcyAgaWYgaXQgZ2V0cyBhZGRlZCB0byBORVRDT05GLU5vdGlmLCBJIGFncmVlIHRv
IGFkZCBzaW1pbGFyIGV4YW1wbGVzIHRwIFJFU1RDT05GLU5vdGlmLg0KDQpSZWdhcmRzLA0KUmVz
aGFkLg0KICAgIA0KICAgID4gL21hcnRpbg0KICAgIA0KDQo=


From nobody Thu Sep 13 10:41:35 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23585130E47 for ; Thu, 13 Sep 2018 10:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LNOAzCpL6vyj for ; Thu, 13 Sep 2018 10:41:32 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 20DC0130E2F for ; Thu, 13 Sep 2018 10:41:32 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 7E94B1AE018A; Thu, 13 Sep 2018 19:41:30 +0200 (CEST)
Date: Thu, 13 Sep 2018 19:41:30 +0200 (CEST)
Message-Id: <20180913.194130.1322555935706323857.mbj@tail-f.com>
To: evoit@cisco.com
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com> <20180913.092134.395462318086733174.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 17:41:34 -0000

Hi,

"Eric Voit (evoit)"  wrote:

[trimming...]

> > > > > > o  Section 2.4.6
> > > > > >
> > > > > >   The text says:
> > > > > >
> > > > > >     1.  "establish-subscription-stream-error-info": This MUST be
> > > > > >     returned
> > > > > >         if an RPC error reason has not been placed elsewhere within
> > > > > >         the
> > > > > >         transport portion of a failed "establish-subscription" RPC
> > > > > >         response.
> > > > > >
> > > > > >   (and similar for the other errors)
> > > > > >
> > > > > >   What exactly does "if an RPC error reason has not been placed
> > > > > >   elsewhere" mean?
> > > > >
> > > > > The intent is to match how NETCONF & RESTCONF historically handles
> > > > > errors.  As you know with NETCONF, each error identity will be
> > > > > inserted as the "error-app-tag".
> > > >
> > > > It could also be in "error-tag" and/or "error-message".  My point is
> > > > that I don't think that you mean that if an implementation populate
> > > > say "error-message", then it should not popluate error-info with
> > > > establish-subscription-stream-
> > > > error-info.
> > >
> > > I do mean that.  I don't think we should send:
> > > "establish-subscription-stream-error-info" for NETCONF when there is
> > > no hint included.  All the necessary error info is already in the
> > > existing message.
> > 
> > But is this really true?  In the
> > "establish-subscription-stream-error-info" there is a leaf called
> > "reason", which
> > is an identity with a detailed error reason, for example
> > "history-unavailable".
> > This info is not present anywhere else in the rpc-error, so it needs
> > to be
> > present here.
> 
> For NETCONF, this info should be mapped into .  See
> section 7 of NETCONF-Notif, as well as Figure 10 for an example.  Or
> section 3 of RESTCONF-Notif, with Figure 7.
> 
> This was done to align things with existing NETCONF & RESTCONF error
> mechanisms.

Ok.  I thought the special error-app-tag thing was removed.  If we
have the error-app-tag value, why do we also have the "reason" leaf?

Since I thought that the error-app-tag was removed, I asked Alex to
remove them from the examples in YANG push (that doc has examples ;).
These examples in YANG push need to put back the error-app-tag.

So now we're back to the main issue.  Is it clear from the SN text
when to include the error-info yang-data stuff or not?


[...]

> > > > > If
> > > > > you want to pursue this further it is probably best to start a new
> > > > > thread dedicated to this topic alone.
> > > > >
> > > > > >   For example, what happens if the transport session is lost and
> > > > > >   re-established; are all event records in the buffer replayed again?
> > > > >
> > > > > No.  The publisher will not lose context of what was sent.
> > > >
> > > > This is not clear from the text.  In fact, the text explicitly says:
> > > >
> > > >    The leading event record sent will be the first event record
> > > >    subsequent to the latest of three different times: the
> > > >    "replay-log-creation-time", "replay-log-aged- time", or the most
> > > >    recent publisher boot time.
> > >
> > > I see your point.   I have tweaked the text to:
> > >
> > > " If the publisher does not know the next record intended for the
> > > receiver, the leading event record..."
> > 
> > Hmm, not sure this helps.  How about:
> > 
> > OLD:
> > 
> >    As a result, when any configured subscription receivers become
> >    active, buffered event records will be sent immediately after the
> >    "subscription-started" notification.  If the publisher does not know
> >    the next record intended for the receiver, the leading event record
> >    sent will be the first event record subsequent to the latest of three
> >    different times: the "replay-log-creation-time", "replay-log-aged-
> >    time", or the most recent publisher boot time.
> > 
> > NEW:
> > 
> >    As a result, when any configured subscription receivers become
> >    active, buffered event records will be sent immediately after the
> >    "subscription-started" notification.  The leading event record
> >    sent will be the first event record subsequent to the latest of four
> >    different times: the "replay-log-creation-time", "replay-log-aged-
> >    time", the most recent publisher boot time, and the time of the
> >    last event record sent to the reciever, if any.
> 
> The reason I didn't word it this way is if there are multiple events
> with the same timestamp.  How about the text below...
> 
> NEW 
> 
> If the publisher knows the last event record sent to a receiver, and
> the publisher has not rebooted, the next event record on the stream
> which meets filtering criteria will be the leading event record sent.
> Otherwise, the leading event record will be the first event record
> meeting filtering criteria subsequent to the latest of three different
> times: the "replay-log-creation-time", "replay-log-aged-time", or the
> most recent publisher boot time.

Ok.



/martin



> 
> > > I have also made a corresponding tweak to the YANG model.
> > 
> > In the leaf "configured-replay"?  I couldn't find this text.
> 
> Not in the configured-replay leaf, that looks good to me.  The first
> time this object is configured, this is when replay starts.  If it
> turns out there are multiple subscription-started notifications due to
> transport loss, the YANG model won't change.
> 
> To find the updated text, look for: refine
> "target/stream/replay-start-time"
> 
> Eric
> 
> [..]
> > /martin
> 


From nobody Thu Sep 13 11:25:58 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE061128B14 for ; Thu, 13 Sep 2018 11:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_MED=-0.01, 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 QLDKOcvKo3qy for ; Thu, 13 Sep 2018 11:25:54 -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 7526A130FA5 for ; Thu, 13 Sep 2018 11:25:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4479; q=dns/txt; s=iport; t=1536863154; x=1538072754; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OjHg7+2qNNImN3RSzY+Du4Y9DP14CDzZRu1E7B6L820=; b=f3uxygt7hEgt4JQgDSc/EEGykRjHwOV2WSCUGHDqyRRXnSeTngWqb5ej 7/1DC5JBCNtScjC7RQRNOXjfMEt49wA6OTHBAZQR9JOzRLdrHFtGnZ1Bt /Uys46jSagaYqgiUb7QSn3r4N+HFVwVfOu/oLF1Db4oR3GnflCXoWoRVQ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CGAACLqppb/4sNJK1SCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGBUIIGgWQoCpgggg2WPhSBZguEbAKDWCE2FgECAQECAQE?= =?us-ascii?q?CbSiFOAEBAQECATo9AgULAgEIDgcDDREQMiUCBA4FCIUTCKc3igqKaBeBQT+?= =?us-ascii?q?BEoMShFQShXACiCSGXo0kCQKQBh+PA5QMAhEUgSUjATGBVXAVgyeQU2+NAIE?= =?us-ascii?q?eAQE?=
X-IronPort-AV: E=Sophos;i="5.53,370,1531785600"; d="scan'208";a="441534648"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 18:25:53 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w8DIPrxL032589 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Sep 2018 18:25:53 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 13 Sep 2018 14:25: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.1395.000; Thu, 13 Sep 2018 14:25:52 -0400
From: "Eric Voit (evoit)" 
To: Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of subscribed-notifications-16
Thread-Index: AQHUSS2c6fWPWMQnpECqHWzj9l2RFqTpyY1wgALe1QCAACWmwIABR3cAgABBbiCAAGvHAP//vguA
Date: Thu, 13 Sep 2018 18:25:52 +0000
Message-ID: <686dd827ac6e440680a5191d98d80b3e@XCH-RTP-013.cisco.com>
References: <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com> <20180913.092134.395462318086733174.mbj@tail-f.com>  <20180913.194130.1322555935706323857.mbj@tail-f.com>
In-Reply-To: <20180913.194130.1322555935706323857.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.234]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 18:25:57 -0000

Hi Martin,

> From: Martin Bjorklund, September 13, 2018 1:42 PM
>=20
> Hi,
>=20
> "Eric Voit (evoit)"  wrote:
>=20
> [trimming...]
>=20
> > > > > > > o  Section 2.4.6
> > > > > > >
> > > > > > >   The text says:
> > > > > > >
> > > > > > >     1.  "establish-subscription-stream-error-info": This MUST=
 be
> > > > > > >     returned
> > > > > > >         if an RPC error reason has not been placed elsewhere =
within
> > > > > > >         the
> > > > > > >         transport portion of a failed "establish-subscription=
" RPC
> > > > > > >         response.
> > > > > > >
> > > > > > >   (and similar for the other errors)
> > > > > > >
> > > > > > >   What exactly does "if an RPC error reason has not been plac=
ed
> > > > > > >   elsewhere" mean?
> > > > > >
> > > > > > The intent is to match how NETCONF & RESTCONF historically
> > > > > > handles errors.  As you know with NETCONF, each error identity
> > > > > > will be inserted as the "error-app-tag".
> > > > >
> > > > > It could also be in "error-tag" and/or "error-message".  My
> > > > > point is that I don't think that you mean that if an
> > > > > implementation populate say "error-message", then it should not
> > > > > popluate error-info with
> > > > > establish-subscription-stream-
> > > > > error-info.
> > > >
> > > > I do mean that.  I don't think we should send:
> > > > "establish-subscription-stream-error-info" for NETCONF when there
> > > > is no hint included.  All the necessary error info is already in
> > > > the existing message.
> > >
> > > But is this really true?  In the
> > > "establish-subscription-stream-error-info" there is a leaf called
> > > "reason", which is an identity with a detailed error reason, for
> > > example "history-unavailable".
> > > This info is not present anywhere else in the rpc-error, so it needs
> > > to be present here.
> >
> > For NETCONF, this info should be mapped into .  See
> > section 7 of NETCONF-Notif, as well as Figure 10 for an example.  Or
> > section 3 of RESTCONF-Notif, with Figure 7.
> >
> > This was done to align things with existing NETCONF & RESTCONF error
> > mechanisms.
>=20
> Ok.  I thought the special error-app-tag thing was removed.  If we have t=
he
> error-app-tag value, why do we also have the "reason" leaf?

Because of the need to be transport agnostic.  Other protocols are unlikely=
 to have a pre-existing "error-app-tag" construct.  And the current YANG da=
ta structure can be inserted where needed and contain

> Since I thought that the error-app-tag was removed, I asked Alex to remov=
e
> them from the examples in YANG push (that doc has examples ;).
> These examples in YANG push need to put back the error-app-tag.
>=20
> So now we're back to the main issue.  Is it clear from the SN text when t=
o
> include the error-info yang-data stuff or not?

I have added a new sentence which hopefully clarifies this intent within se=
ction 2.4.  I have also re-added the second sentence of each bullet to some=
thing close to the original text of -v16.  It now reads:


   There is one final set of transport independent RPC error elements
   included in the YANG model.  These are three yang-data structures
   which enable the publisher to provide to the receiver that error
   information which does not fit into existing transport layer RPC
   structures.  These three yang-data structures are:

   1.  "establish-subscription-stream-error-info": This MUST be returned
       with the leaf "reason" populated if an RPC error reason has not
       been placed elsewhere within the transport portion of a failed
       "establish-subscription" RPC response.  This MUST be sent if
       hints on how to overcome the RPC error are included.

   2.  "modify-subscription-stream-error-info": This MUST be returned
       with the leaf "reason" populated if an RPC error reason has not
       been placed elsewhere within the transport portion of a failed
       "modify-subscription" RPC response.  This MUST be sent if hints
       on how to overcome the RPC error are included.

   3.  "delete-subscription-error-info": This MUST be returned with the
       leaf "reason" populated if an RPC error reason has not been
       placed elsewhere within the transport portion of a failed
       "delete-subscription" or "kill-subscription" RPC response


Eric

> [...]
> /martin


From nobody Thu Sep 13 11:43:35 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CED130E4F for ; Thu, 13 Sep 2018 11:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fQsJdqy2zfFu for ; Thu, 13 Sep 2018 11:43:31 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A28271293FB for ; Thu, 13 Sep 2018 11:43:31 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 6D28D1AE018A; Thu, 13 Sep 2018 20:43:30 +0200 (CEST)
Date: Thu, 13 Sep 2018 20:43:30 +0200 (CEST)
Message-Id: <20180913.204330.1589475713466728926.mbj@tail-f.com>
To: evoit@cisco.com
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <686dd827ac6e440680a5191d98d80b3e@XCH-RTP-013.cisco.com>
References:  <20180913.194130.1322555935706323857.mbj@tail-f.com> <686dd827ac6e440680a5191d98d80b3e@XCH-RTP-013.cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 18:43:34 -0000

"Eric Voit (evoit)"  wrote:
> Hi Martin,
> 
> > From: Martin Bjorklund, September 13, 2018 1:42 PM
> > 
> > Hi,
> > 
> > "Eric Voit (evoit)"  wrote:
> > 
> > [trimming...]
> > 
> > > > > > > > o  Section 2.4.6
> > > > > > > >
> > > > > > > >   The text says:
> > > > > > > >
> > > > > > > >     1.  "establish-subscription-stream-error-info": This MUST be
> > > > > > > >     returned
> > > > > > > >         if an RPC error reason has not been placed elsewhere within
> > > > > > > >         the
> > > > > > > >         transport portion of a failed "establish-subscription" RPC
> > > > > > > >         response.
> > > > > > > >
> > > > > > > >   (and similar for the other errors)
> > > > > > > >
> > > > > > > >   What exactly does "if an RPC error reason has not been placed
> > > > > > > >   elsewhere" mean?
> > > > > > >
> > > > > > > The intent is to match how NETCONF & RESTCONF historically
> > > > > > > handles errors.  As you know with NETCONF, each error identity
> > > > > > > will be inserted as the "error-app-tag".
> > > > > >
> > > > > > It could also be in "error-tag" and/or "error-message".  My
> > > > > > point is that I don't think that you mean that if an
> > > > > > implementation populate say "error-message", then it should not
> > > > > > popluate error-info with
> > > > > > establish-subscription-stream-
> > > > > > error-info.
> > > > >
> > > > > I do mean that.  I don't think we should send:
> > > > > "establish-subscription-stream-error-info" for NETCONF when there
> > > > > is no hint included.  All the necessary error info is already in
> > > > > the existing message.
> > > >
> > > > But is this really true?  In the
> > > > "establish-subscription-stream-error-info" there is a leaf called
> > > > "reason", which is an identity with a detailed error reason, for
> > > > example "history-unavailable".
> > > > This info is not present anywhere else in the rpc-error, so it needs
> > > > to be present here.
> > >
> > > For NETCONF, this info should be mapped into .  See
> > > section 7 of NETCONF-Notif, as well as Figure 10 for an example.  Or
> > > section 3 of RESTCONF-Notif, with Figure 7.
> > >
> > > This was done to align things with existing NETCONF & RESTCONF error
> > > mechanisms.
> > 
> > Ok.  I thought the special error-app-tag thing was removed.  If we have the
> > error-app-tag value, why do we also have the "reason" leaf?
> 
> Because of the need to be transport agnostic.  Other protocols are
> unlikely to have a pre-existing "error-app-tag" construct.

... which is a reason to not do the error-app-tag trick; it would then
work the same across all protocols.

But are you sure that these "other protocols" even has a mechanism to
insert the new error-info structures into their errors?

> And the
> current YANG data structure can be inserted where needed and contain
> 
> > Since I thought that the error-app-tag was removed, I asked Alex to remove
> > them from the examples in YANG push (that doc has examples ;).
> > These examples in YANG push need to put back the error-app-tag.
> > 
> > So now we're back to the main issue.  Is it clear from the SN text when to
> > include the error-info yang-data stuff or not?
> 
> I have added a new sentence which hopefully clarifies this intent within section 2.4.  I have also re-added the second sentence of each bullet to something close to the original text of -v16.  It now reads:
> 
> 
>    There is one final set of transport independent RPC error elements
>    included in the YANG model.  These are three yang-data structures
>    which enable the publisher to provide to the receiver that error
>    information which does not fit into existing transport layer RPC
>    structures.  These three yang-data structures are:
> 
>    1.  "establish-subscription-stream-error-info": This MUST be returned
>        with the leaf "reason" populated if an RPC error reason has not
>        been placed elsewhere within the transport portion of a failed
>        "establish-subscription" RPC response.  This MUST be sent if
>        hints on how to overcome the RPC error are included.
> 
>    2.  "modify-subscription-stream-error-info": This MUST be returned
>        with the leaf "reason" populated if an RPC error reason has not
>        been placed elsewhere within the transport portion of a failed
>        "modify-subscription" RPC response.  This MUST be sent if hints
>        on how to overcome the RPC error are included.
> 
>    3.  "delete-subscription-error-info": This MUST be returned with the
>        leaf "reason" populated if an RPC error reason has not been
>        placed elsewhere within the transport portion of a failed
>        "delete-subscription" or "kill-subscription" RPC response

Ok, I don't like this solution, but I can accept it.


/martin


From nobody Thu Sep 13 13:33:26 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F67130E63 for ; Thu, 13 Sep 2018 13:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_MED=-0.01, 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 4ZjKzn2YwX5Y for ; Thu, 13 Sep 2018 13:33:21 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E16F130E72 for ; Thu, 13 Sep 2018 13:33:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14952; q=dns/txt; s=iport; t=1536870799; x=1538080399; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4Y29fxmV0bIUyf7Tcf9P28R/q95SLi8L2CiuLMLvYbY=; b=lPnGoWLUY42uo/yT5M0lG3I18eSF9TGqXrMSCF81zmsQ/8tvhInPTBpJ uD3OxuwxormomSCwZXSIJlb0zMcoCwUInQTlwtfi+9kGG4rVMx20q+lS7 AMLAxgBMh1hfEIlRrC57jHX9pUk4Q4MvKPQe2AaEvX6WpPY1SxN369936 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AgAiyZpb/4QNJK1VBxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGBUIFcKmV/FRMKg2iWSYM9kwEUgWYLGAuESQIXg0EhNhY?= =?us-ascii?q?BAgEBAgEBAm0cDIU4AQEBAQIBIwQNGhgRAgULAgEGAhUFAggBHQICAi8BFRA?= =?us-ascii?q?CBA4BBQcVBII1TIF5CA+KOptMezOJaSKBC4ldF4FBP4ESgxKDEAsBAQEBARe?= =?us-ascii?q?BLwEEKoJqglcCiCSGXoQdiQcJAoY5iU0fgUGHSIV6i06IPgIRFIElJAwlgVV?= =?us-ascii?q?wFYMnCQqCEhd6AQKCSIUUhT5vAQ+LRSmBBYEeAQE?=
X-IronPort-AV: E=Sophos;i="5.53,370,1531785600"; d="scan'208";a="451833479"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 20:33:17 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w8DKXHi7025581 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Sep 2018 20:33:17 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.1395.4; Thu, 13 Sep 2018 16:33:16 -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.1395.000; Thu, 13 Sep 2018 16:33:16 -0400
From: "Eric Voit (evoit)" 
To: "Tim Jenkins (timjenki)" 
CC: "netconf@ietf.org" 
Thread-Topic: last call on draft-ietf-netconf-subscribed-notifications-16
Thread-Index: AQHUS3SYdjH1bOxqTkC41erEdgjQeqTuagqQgAAGTiA=
Date: Thu, 13 Sep 2018 20:33:16 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.234]
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-10.cisco.com
Archived-At: 
Subject: Re: [Netconf] last call on draft-ietf-netconf-subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 20:33:25 -0000

SGkgVGltLA0KDQpJbi1saW5lLi4uDQoNCj4gRnJvbTogVGltIEplbmtpbnMsIFNlcHRlbWJlciAx
MywgMjAxOCAxMToxNSBBTQ0KPiANCj4gR3JlZXRpbmdzLA0KPiANCj4gSSBoYXZlIHJlYWQgZHJh
ZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucy0xNiBhbmQgc3VwcG9ydCBp
dCBnb2luZw0KPiB0byBJRVNHLg0KPiANCj4gSSBoYXZlIGEgbnVtYmVyIG9mIGNvbW1lbnRzLCBt
b3N0bHkgZXh0cmVtZWx5IG1pbm9yIGluIG5hdHVyZSwgYW5kIG5vbmUNCj4gbmVlZCBhZmZlY3Qg
Zm9yd2FyZCBwcm9ncmVzcyBvZiBzdWJzY3JpYmVkIG5vdGlmaWNhdGlvbnMuDQo+IA0KPiBUaW0N
Cj4gDQo+IOKHkg0KPiANCj4gQ29tbWVudHMgb24gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLQ0KPiBub3RpZmljYXRpb25zLTE2DQo+IA0K
PiBTZWN0aW9uIDEuMiwgTm90aWZpY2F0aW9uIG1lc3NhZ2UgZGVmaW5pdGlvbjogcmVtb3ZlIHRo
ZSAoKSBhcm91bmQgZXZlbnQocykNCg0KRG9uZQ0KDQo+IFNlY3Rpb24gMS4yLiBObyBkZWZpbml0
aW9uIGZvciBqdXN0ICJzdHJlYW0iOyB0aGUgd29yZCBzdHJlYW0gaXMgdXNlZCBhbG9uZQ0KPiAo
d2l0aG91dCAnZXZlbnQnIGluIGZyb250IG9mIGl0IGluIGEgZmV3IHBsYWNlcykNCg0KVXBkYXRl
ZCB0byAiZXZlbnQgc3RyZWFtIiBldmVyeXdoZXJlIGluIHRoZSBkb2N1bWVudC4NCg0KPiBTaG91
bGQgdGhpcyBwYXJhZ3JhcGggYmUgaW4gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24/DQo+IMKgwqAg
QWxsIFlBTkcgdHJlZSBkaWFncmFtcyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgZm9sbG93IHRoZSBu
b3RhdGlvbg0KPiDCoMKgIGRlZmluZWQgaW4gW1JGQzgzNDBdLg0KPiANCj4gU2VjdGlvbiAxLjMs
IHBhcmFncmFwaCBudW1iZXJlZCAxOiBjaGFuZ2UgIndvdWxkIGhhdmUgZW5hYmxlZCIgdG8gIm1h
eQ0KPiBoYXZlIGVuYWJsZWQiLiBVc2Ugb2Ygd291bGQgaW1wbGllcyB1c2Ugb2YgdGhlIHN1Z2dl
c3RlZCBoaW50cyB3b3VsZCBzdWNjZWVkLA0KPiBhbmQgdGhpcyBjYW5ub3QgYmUgZ3VhcmFudGVl
ZC4gKFRoaXMgd291bGQgdGhlbiBiZSBtb3JlIGNvbnNpc3RlbnQgd2l0aCBzYW1lDQo+IHRleHQg
aW4gU2VjdGlvbiAyLjQuMi4pDQoNCkRvbmUNCiANCj4gU2VjdGlvbiAxLjMsIHBhcmFncmFwaCBu
dW1iZXIgMjogSXQncyBzb3J0IG9mIGEgY2lyY3VsYXIgZGVmaW5pdGlvbjoNCj4gwqDCoMKgwqDC
oCAiQ29uZmlndXJlZCBzdWJzY3JpcHRpb25zLCB3aGljaCBhbGxvdyB0aGUgbWFuYWdlbWVudCBv
Zg0KPiDCoMKgwqDCoMKgwqAgc3Vic2NyaXB0aW9ucyB2aWEgYSBjb25maWd1cmF0aW9uIHNvIHRo
YXQgYSBwdWJsaXNoZXIgY2FuIHNlbmQNCj4gwqDCoMKgwqDCoMKgIG5vdGlmaWNhdGlvbiBtZXNz
YWdlcyB0byBhIHJlY2VpdmVyIG9mIGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24uIg0KPiDCoMKg
wqDCoMKgwqAgU3VnZ2VzdCByZXBocmFzaW5nIGFuZCByZW1vdmluZyB0aGUgInJlY2VpdmVyIG9m
IGEgY29uZmlndXJlZA0KPiBzdWJzY3JpcHRpb24iIHBhcnQuDQoNClJlbW92ZWQgdGhlICJyZWNl
aXZlciBvZiBhIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIi4gICBPdGhlciByZXZpZXdzIGRyb3Zl
IHRoZSBlYXJsaWVyIHdvcmRpbmcgKHByZXZpb3VzbHkgd2FzIGNvbmZpZ3VyYXRpb24gb3BlcmF0
aW9ucyksIHNvIEkgYW0gaG9waW5nIG5vdCB0byBjaGFuZ2UgZnVydGhlci4NCiANCj4gU2VjdGlv
biAxLjMsIHNlY29uZCBsYXN0IHBhcmFncmFwaDogUGFydGx5IHJlcGVhdHMgc2Vjb25kIGJ1bGxl
dGVkIHBhcmFncmFwaCwNCj4gd2hpY2ggZXhwbGljaXRseSBsaXN0cyBleGNlcHRpb24gdG8gdGhp
cyBzdGF0ZW1lbnQgIlNpbWlsYXJseSwgYSBzdWJzY3JpcHRpb24NCj4gZXN0YWJsaXNoZWQgdmlh
IFJQQyBjYW5ub3QgYmUgbW9kaWZpZWQgdGhyb3VnaCBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMi
LiBJDQo+IHdvdWxkIHN1Z2dlc3QgcmVtb3ZpbmcgZHVwbGljYXRlIHN0YXRlbWVudHMgZnJvbSB0
aGVzZSBwYXJhZ3JhcGhzIHJlZ2FyZGluZw0KPiB3aGF0IGNhbiBiZSBjaGFuZ2VkLg0KDQpJIHJl
bW92ZWQgdGhlICJTaW1pbGFybHkuLi4iIHNlbnRlbmNlLiAgWW91IGFyZSBjb3JyZWN0LCBpdCB3
YXMgZnVsbHkgY292ZXJlZCBwcmV2aW91c2x5Lg0KDQo+IFNlY3Rpb24gMS40LCByZXBsYWNlICJ0
aGUgUlBDIG9wZXJhdGlvbnMgaW4gdGhpcyBkcmFmdCByZXBsYWNlcyIgd2l0aCAidGhlIFJQQw0K
PiBvcGVyYXRpb25zIGluIHRoaXMgZHJhZnQgcmVwbGFjZSINCg0KVXBkYXRlZA0KDQo+IFNlY3Rp
b24gMS40LCByZXBsYWNlICJzaW5nbGUgdHJhbnNwb3J0IHNlc3Npb24NCj4gwqDCoMKgwqDCoCB0
byBpbnRlcm1peCBvZiBub3RpZmljYXRpb24gbWVzc2FnZXMiIHdpdGggInNpbmdsZSB0cmFuc3Bv
cnQgc2Vzc2lvbg0KPiDCoMKgwqDCoMKgIHRvIGludGVybWl4IG5vdGlmaWNhdGlvbiBtZXNzYWdl
cyINCg0KVXBkYXRlZA0KIA0KPiBTZWN0aW9uIDIuMzogU2Vjb25kIGJ1bGxldGVkIHBhcmFncmFw
aCBzZWVtIHRvIGltcGx5IHRoYXQgdGhlIHdlaWdodGluZyBpcw0KPiBwZXItcmVjZWl2ZXIuIFBl
cmhhcHMgcmVwaHJhc2Ugb3IgcmVmZXIgaW5zdGVhZCB0byBkZXNjcmlwdGlvbiBlbHNld2hlcmUu
DQoNCkRlbGV0ZWQgdGhlIHBlciByZWNlaXZlciBwYXJ0LiAgVGhhdCBpcyBhZGVxdWF0ZWx5IGNv
dmVyZWQgYSBmZXcgcGFyYWdyYXBocyBiZWxvdy4NCg0KPiBTZWN0aW9uIDIuMzogSXMgZHNjcCBv
cHRpb25hbD8gTm90IHN0YXRlZCBoZXJlLCBidXQgaXMgZm9yIG90aGVycy4gU2VlbXMgaXQgaXMu
DQoNCkl0IGRvZXMgc2F5ICJpZiB0aGUgcHVibGlzaGVyIHN1cHBvcnRzIHRoZSAiZHNjcCIgZmVh
dHVyZSIuICBJIHRoaW5rIHRoYXQgbWFrZXMgaXQgb3B0aW9uYWwuDQogDQo+IFNlY3Rpb24gMi40
LjE6IERvZXMgbm90IHNob3cgdGhlIHRyYW5zaXRpb24gZGVzY3JpYmVkIGluIHNlY29uZCBsYXN0
IHBhcmFncmFwaA0KPiBvZiBTZWN0aW9uIDIuMSwgb3IgdGhlIHRyYW5zaXRpb24gZGVzY3JpYmVk
IGluIHNlY29uZCBvIHBhcmFncmFwaCBvZiBzZWN0aW9uDQo+IDIuNC4xLiBCdXQgdGhlIHNlY29u
ZCBkb2Vzbid0IGV4aXN0IGJhc2VkIG9uIHNlY3Rpb24gMi40LjM7IGl0IGV4cGxpY2l0bHkgc2F5
cyB0bw0KPiBjaGFuZ2Ugc3RhdGUgYW5kIHRoZW0gbW92ZWQgaW1tZWRpYXRlbHkgYmFjayBpZiBu
ZWVkZWQsIHNvIHBlcmhhcHMgYWRkDQo+IHNvbWV0aGluZyB0byBzZWNvbmQgbyBwYXJhZ3JhcGgg
b2Ygc2VjdGlvbiAyLjQuMSI6DQo+IA0KPiDCoMKgIG/CoCBGYWlsZWQgIm1vZGlmeS1zdWJzY3Jp
cHRpb24iIFJQQ3Mgd2lsbCBsZWF2ZSB0aGUgc3Vic2NyaXB0aW9uIGluDQo+IMKgwqDCoMKgwqAg
aXRzIHByZXZpb3VzIHN0YXRlLCB3aXRoIG5vIHZpc2libGUgY2hhbmdlIHRvIGFueSBzdHJlYW1p
bmcNCj4gwqDCoMKgwqDCoCB1cGRhdGVzLiBUaGUgdHJhbnNpdGlvbiB0byB0aGUgcmVjZWl2ZXIg
YWN0aXZlIHN0YXRlIGFuZCBiYWNrIHRvDQo+IMKgwqDCoMKgwqAgcmVjZWl2ZXIgc3VzcGVuZGVk
IHN0YXRlIG1pZ2h0IG5vdCBiZSBub3QgZXh0ZXJuYWxseSB2aXNpYmxlLg0KDQpBcyB0aGVyZSBp
cyBubyB0cmFuc2l0aW9uIG91dCBvZiByZWNlaXZlciBzdXNwZW5kZWQgc3RhdGUsIGl0IGlzIG5v
dCBzaG93bi4gICBUaGUgcmVhc29uIHRoZSBsb29wIGlzIHNob3duIHdpdGggdGhlIG1vZGlmeS1z
dWJzY3JpcHRpb24gZm9yIHRoZSAiYWN0aXZlIiBzdGF0ZSBpcyB0aGF0IHRoZSBzdWJzY3JpcHRp
b24gdGVybXMgYXJlIGFjdHVhbGx5IGNoYW5nZWQgdGhlcmUuDQoNCj4gU2VjdGlvbiAyLjQuMiwg
dGhpcmQgbyBwYXJhZ3JhcGg6IFJlbW92ZSAiTm90ZTogIiBzaW5jZSBzdGF0ZW1lbnQgaXMgZGVm
aW5pdGl2ZQ0KPiBhYm91dCBiZWhhdmlvdXIgKGl0J3Mgbm90IGEgbm90ZSkuDQoNCkRvbmUNCg0K
PiBTZWN0aW9uIDIuNC41OiBTaG91bGQgdGhlcmUgYmUgc29tZSBtZW50aW9uIGFib3V0IHBlcm1p
c3Npb25zPw0KDQpXaXRoIGEgY29tbWVudCBmcm9tIE1hcnRpbiwgTkFDTSBoYXMgYmVlbiBhZGRl
ZCB0byB0aGUgWUFORyBtb2RlbCBleHBsaWNpdGx5LiAgU28gSSB0aGluayB3ZSBhcmUgY292ZXJl
ZC4NCg0KPiBTZWN0aW9uIDIuNC42OiBTaG91bGQgdGhlcmUgYmUgYSBwZXJtaXNzaW9ucyBmYWls
dXJlIGVycm9yIGZvciBraWxsLXN1YnNjcmlwdGlvbj8NCj4gT3IgaXMgdGhhdCBtb3JlIGdlbmVy
aWM/IE1lYW5pbmcsIGlzIGNvbW1hbmQgZXhlY3V0aW9uIHBlcm1pc3Npb24NCj4gZW5mb3JjZW1l
bnQgbm90IHBhcnQgb2YgdGhpcyBzcGVjaWZpY2F0aW9uPw0KDQpJdCBpcyBhIG1vcmUgZ2VuZXJp
YyBSUEMgcGVybWlzc2lvbnMgZmFpbHVyZS4NCiANCj4gU2VjdGlvbiAyLjU6IFNob3VsZCB0aGlz
DQo+IMKgwqDCoMKgwqAgImFuIGFiaWxpdHkgdG8gc2VuZCBub3RpZmljYXRpb24gbWVzc2FnZXMg
dG8gbW9yZSB0aGFuIG9uZSByZWNlaXZlcg0KPiDCoMKgwqDCoMKgIChub3RlIHRoYXQgcmVjZWl2
ZXJzIGFyZSB1bmF3YXJlIG9mIHRoZSBleGlzdGVuY2Ugb2YgYW55IG90aGVyDQo+IMKgwqDCoMKg
wqAgcmVjZWl2ZXJzLikiDQo+IGJlIGNoYW5nZWQgdG8gc29tZXRoaW5nIGxpa2UgdGhpcw0KPiDC
oMKgwqDCoMKgICJhbiBhYmlsaXR5IHRvIHNlbmQgbm90aWZpY2F0aW9uIG1lc3NhZ2VzIHRvIG1v
cmUgdGhhbiBvbmUgcmVjZWl2ZXIuDQo+IMKgwqDCoMKgwqAgUmVjZWl2ZXJzIE1VU1Qgbm90IGJl
IGF3YXJlIG9mIHRoZSBleGlzdGVuY2Ugb2Ygb3RoZXIgcmVjZWl2ZXJzLg0KPiDCoMKgwqDCoMKg
ICI/DQoNCkkgZG9uJ3QgdGhpbmsgc28uICAgT3V0c2lkZSBvZiB0aGlzIHNwZWNpZmljYXRpb24s
IHBlb3BsZSBtaWdodCB3YW50IHRvIGNvb3JkaW5hdGUgcmVjZWl2ZXJzLiAgQnV0IHRoZXkgd29u
J3QgZ2V0IHByb3RvY29sIGhlbHAgaGVyZS4NCiANCj4gMi41LjEsIHJlY2VpdmVyIHN0YXRlOiBJ
IHRoaW5rIEkgcHJlZmVyIHRoZSBzdGF0ZSAicmVjZWl2ZXIgZGlzY29ubmVjdGVkIiBvdmVyDQo+
ICJyZWNlaXZlciB0aW1lb3V0IiBzaW5jZSB0aGVyZSBhcmUgbW9yZSByZWFzb25zIGEgcmVjZWl2
ZXIgd291bGQgYmUNCj4gZGlzY29ubmVjdGVkLiBXaGlsZSB0aGUgdGV4dCBzYXlzIHRoZSBzdGF0
ZXMgYXJlIG9ubHkgbWVhbmluZ2Z1bCB3aGVuIHRoZQ0KPiBzdWJzY3JpcHRpb24gc3RhdGUgaXMg
dmFsaWQsIGluIHByYWN0aXNlIHJlY2VpdmVycyBvZiBpbnZhbGlkIHN1YnNjcmlwdGlvbnMgd2ls
bCBoYXZlDQo+IHN0YXRlIGFzIHdlbGwsIGFuZCAidGltZW91dCIgaXNuJ3QgcmVhbGx5IHRydWUu
IEZ1cnRoZXIsIGFuIGltcGxlbWVudGF0aW9uIG1heQ0KPiBjaG9vc2UgdG8gbm90IGV2ZW4gY3Jl
YXRlIGNvbm5lY3Rpb25zIHVuZGVyIG92ZXJsb2FkIGNvbmRpdGlvbnMsIHNvIHRoZQ0KPiByZWNl
aXZlciB3b24ndCBiZSBqdXN0ICJzdXNwZW5kZWQiIG5vciB3aWxsIGl0IGJlICJ0aW1lb3V0Ii4N
Cg0KQ2hhbmdlZCB0byAiZGlzY29ubmVjdGVkIi4NCg0KPiBBZGRpdGlvbmFsbHksIHNob3VsZCBp
dCBub3QgYmUgc3RhdGVkIHRoYXQgdGhlICJjb25uZWN0aW5nIiBzdGF0ZSBpcyBvbmx5IGZvcg0K
PiB3aGVuIHRoZSBwdWJsaXNoZXIgaXMgYWN0aXZlbHkgdHJ5aW5nIHRvIGNvbm5lY3QgdG8gdGhl
IHJlY2VpdmVyPyBUaGlzIHNlbnRlbmNlDQo+IHNlZW1zIHRvIGltcGx5IGl0J3MgbW9yZSB0aGFu
IHRoYXQgIkluIGFkZGl0aW9uLCBhIGNvbmZpZ3VyZWQNCj4gwqDCoCBzdWJzY3JpcHRpb24ncyBy
ZWNlaXZlciBNVVNUIGJlIG1vdmVkIHRvIGNvbm5lY3RpbmcgaWYgdHJhbnNwb3J0DQo+IMKgwqAg
Y29ubmVjdGl2aXR5IGNhbm5vdCBiZSBhY2hpZXZlZCwgb3IgLi4uIiBPciBtYXliZSB0aGUgImNh
bm5vdCIgY29uZnVzZXMgbWU6DQo+IGNhbm5vdCBiZWZvcmUgdGltZW91dCBpcyByZWFsbHkgd2hh
dCBpcyBtZWFudD8NCg0KTm93IHNheXM6IElmIHRyYW5zcG9ydCBjb25uZWN0aXZpdHkgY2Fubm90
IGJlIGFjaGlldmVkIHdoaWxlIGluIHRoZSBjb25uZWN0aW5nIHN0YXRlLCB0aGUgcmVjZWl2ZXIg
TUFZIGJlIG1vdmVkIHRvIHRoZSBkaXNjb25uZWN0ZWQgc3RhdGUuDQogDQo+IFNlY3Rpb24gMi41
LjINCj4gDQo+IExhc3QgcGFyYWdyYXBoIHNheXMgdGhhdCByZXBsYXkgaXMgc3VwcG9ydGVkIG9u
IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucy4gU28NCj4gd2h5IHRoaXMgc3RhdGVtZW50IGluIHNl
Y3Rpb24gMi41PyAiT24gYSByZWNlaXZlciBvZiBhDQo+IMKgwqAgY29uZmlndXJlZCBzdWJzY3Jp
cHRpb24sIHN1cHBvcnQgZm9yIGR5bmFtaWMgc3Vic2NyaXB0aW9ucyBpcw0KPiDCoMKgIG9wdGlv
bmFsIGV4Y2VwdCB3aGVyZSByZXBsYXlpbmcgbWlzc2VkIGV2ZW50IHJlY29yZHMgaXMgcmVxdWly
ZWQuDQo+ICINCg0KRGVsZXRlZCB0aGUgcGFyYWdyYXBoIGFzIGl0IGlzIHJlcGVhdGVkIGluIHNl
Y3Rpb24gMi41LjYuDQoNCj4gU2VjdGlvbiAyLjUuMywgc2Vjb25kIHBhcmFncmFwaDogUmVjZWl2
ZXJzIHdvdWxkIG9ubHkgYmUgcHV0IGludG8gdGhlDQo+IGNvbm5lY3Rpbmcgc3RhdGUgaWYgdGhl
IHByb3RvY29sIHNwZWNpZmljIGNhbGxob21lIG1lY2hhbmlzbSB3YXMgaW52b2tlZC4NCj4gQ291
bGQgdGhleSBub3QgYWxzbyBnbyBpbnN0ZWFkIHRvIHRoZSBhY3RpdmUgc3RhdGUgaWYgdGhlIGNv
bm5lY3Rpb24gbmVlZGVkDQo+IGFscmVhZHkgZXhpc3RlZD8NCg0KVGhlIGN1cnJlbnQgdGV4dCBp
cyBjb3JyZWN0LiAgQSBzdWJzY3JpcHRpb24gZG9lcyBub3QgZXhpc3QgY29ubmVjdGluZyB1bnRp
bCB0aGUgc3VjY2Vzc2Z1bCBwYXNzaW5nIG9mIGEgInN1YnNjcmlwdGlvbi1zdGFydGVkIg0KDQo+
IFNlY3Rpb24gMi41LjMsIG1heWJlIGNoYW5nZQ0KPiAiQWxzbyBub3RlIHRoYXQgaWYgbXVsdGlw
bGUgbW9kaWZpY2F0aW9ucyBoYXZlIG9jY3VycmVkIGR1cmluZyB0aGUNCj4gwqDCoCBzdXNwZW5z
aW9uLCBvbmx5IHRoZSBsYXRlc3Qgb25lIG5lZWQgYmUgc2VudCB0byB0aGUgcmVjZWl2ZXIuIg0K
PiB0bw0KPiAiQWxzbyBub3RlIHRoYXQgaWYgbXVsdGlwbGUgbW9kaWZpY2F0aW9ucyBoYXZlIG9j
Y3VycmVkIGR1cmluZyB0aGUNCj4gwqDCoCBzdXNwZW5zaW9uLCBvbmx5IHRoZSAic3Vic2NyaXB0
aW9uLW1vZGlmaWVkIiBub3RpZmljYXRpb24gZGVzY3JpYmluZyB0aGUNCj4gbGF0ZXN0IG9uZSBu
ZWVkIGJlIHNlbnQgdG8gdGhlIHJlY2VpdmVyLg0KPiAiDQoNCnVwZGF0ZWQNCiANCj4gU2VjdGlv
biAyLjUuNTogbWF5YmUgY2hhbmdlICJyZS1pbml0aWFsaXphdGlvbiIgdG8gImFjdGlvbiIgLSBp
dCdzIG5vdCByZWFsbHkgYSByZS0NCj4gaW5pdGlhbGl6YXRpb24NCg0KRG9uZQ0KDQo+IFNlY3Rp
b24gMi41LjYsIGZpcnN0IHBhcmFncmFwaCwgbGFzdCBzZW50ZW5jZTogZXZlbnQgLT4gZXZlbnRz
DQoNCk1hZGUgZXZlbnQgcmVjb3Jkcy4NCg0KPiBTZWN0aW9uIDIuNy4yLCBwYXJhZ3JhcGggbnVt
YmVyZWQgMjogdGhpcyBjYXNlIHdvdWxkIGFwcGx5IHRvIGJvdGggZHluYW1pYw0KPiBhbmQgY29u
ZmlndXJlZCBzdWJzY3JpcHRpb25zOyBzdWdnZXN0IHJlcGhyYXNpbmcgdG8gZGVzY3JpYmUgdGhl
IHNpdHVhdGlvbiBhbmQNCj4gdGhlbiBzYXlpbmcgdGhhdCBpdCBhcHBsaWVzIHRvIGJvdGgNCg0K
SSByZW9yZGVyZWQgdGhlIHRleHQgdG8gZG8gdGhpcy4NCg0KPiBTZWN0aW9uIDIuOCwgbWF5YmUg
Y2hhbmdlDQo+ICJUaGlzIGxlYWYgYWxzbw0KPiDCoMKgIGluZGljYXRlcyBpZiBjdXJyZW50IHN0
YXRlIG9mIHRoYXQgc3Vic2NyaXB0aW9uIGlzIHZhbGlkLCBpbnZhbGlkLA0KPiDCoMKgIGFuZCBj
b25jbHVkZWQuIg0KPiB0bw0KPiAiVGhpcyBsZWFmIGFsc28NCj4gwqDCoCBpbmRpY2F0ZXMgaWYg
dGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhhdCBzdWJzY3JpcHRpb24gaXMgdmFsaWQsIGludmFsaWQs
DQo+IMKgwqAgb3IgY29uY2x1ZGVkLiINCg0KdXBkYXRlZA0KIA0KPiBTZWN0aW9uIDIuOCwgcGFy
YWdyYXBoIDM6IHJlbW92ZSAiY29uZmlndXJlZCBhbmQgZHluYW1pYyIgZnJvbSBmaXJzdCBzZW50
ZW5jZQ0KDQpEb25lDQoNCj4gU2VjdGlvbiAyLjgsIHBhcmFncmFwaCAzOiBJcyBpdCBub3QgYSBw
b3RlbnRpYWwgc2VjdXJpdHkgbGVhayB0byBoYXZlIGV2ZW50DQo+IG5vdGlmaWNhdGlvbnMgc3Vw
cHJlc3NlZCBieSBwZXJtaXNzaW9ucyBjaGFuZ2UgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUN
Cj4gdHdvIGNvdW50cz8NCg0KQXMgdGhlIGNvdW50cyBhcmUgb3BlcmF0aW9uYWwgZGF0YSwgdGhp
cyBuZWVkIG5vdCBiZSBnZW5lcmFsbHkgYXZhaWxhYmxlLiAgVGhpcyByaXNrIGlzIGFsc28gZGlz
Y3Vzc2VkIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0KDQo+IFNlY3Rp
b24gMi45OiBDaGFuZ2UNCj4gIkluIGFkZGl0aW9uIHN1cHBvcnQgZm9yIG9wdGlvbmFsIGZlYXR1
cmVzICJlbmNvZGUteG1sIiwNCj4gwqDCoCAiZW5jb2RlLWpzb24iLCAiY29uZmlndXJlZCIgInN1
cHBvcnRzLXZyZiIsICJxb3MiLCAieHBhdGgiLA0KPiDCoMKgICJzdWJ0cmVlIiwgImludGVyZmFj
ZS1kZXNpZ25hdGlvbiIsICJkc2NwIiwgYW5kICJyZXBsYXkiIE1VU1QgYmUNCj4gwqDCoCBpbmRp
Y2F0ZWQgaWYgc3VwcG9ydGVkLiINCj4gdG8NCj4gIklmIHN1cHBvcnRlZCwgdGhlIG9wdGlvbmFs
IGZlYXR1cmVzICJlbmNvZGUteG1sIiwNCj4gwqDCoCAiZW5jb2RlLWpzb24iLCAiY29uZmlndXJl
ZCIgInN1cHBvcnRzLXZyZiIsICJxb3MiLCAieHBhdGgiLA0KPiDCoMKgICJzdWJ0cmVlIiwgImlu
dGVyZmFjZS1kZXNpZ25hdGlvbiIsICJkc2NwIiwgYW5kICJyZXBsYXkiIE1VU1QgYmUNCj4gwqDC
oCBpbmRpY2F0ZWQuDQo+ICINCg0KVXBkYXRlZA0KDQo+IFNlY3Rpb24gMywgdGhpcmQgc2VudGVu
Y2U6IHJlbW92ZSBmaXJzdCB3b3JkICJPciINCg0KRG9uZQ0KIA0KPiBTZWN0aW9uIDQsIGZlYXR1
cmVzIGZvciBlbmNvZGluZzogSSBkb24ndCBzZWUgdGhlIHBvaW50IG9mIGdsb2JhbCBmZWF0dXJl
cyBmb3INCj4gc2hvd2luZyBzdXBwb3J0IGZvciBlbmNvZGluZ3MuIFRoZSBlbmNvZGluZ3MgdGhh
dCBhcmUgc3VwcG9ydGVkIGFyZSB0aWVkIHRvDQo+IHRoZSBwcm90b2NvbHMgdGhhdCBhcmUgc3Vw
cG9ydGVkLCBhbmQgaXQncyB1bmxpa2VseSBhbnkgZW5jb2Rpbmcgd2lsbCBiZQ0KPiBzdXBwb3J0
ZWQgb3ZlciBhbGwgcHJvdG9jb2xzLg0KDQpJIGhvcGUgd2UgZG9uJ3QgcmV2aXNpdCB0aGlzIG9u
ZSA6LSkNCg0KPiBTZWN0aW9uIDQsIGZlYXR1cmUgInJlcGxheSI6IEdpdmVuIHRoYXQgdGhlIHN0
cmVhbXMgdGFibGUgc2hvd3Mgd2hpY2ggc3RyZWFtcw0KPiBzdXBwb3J0IHJlcGx5LCBpcyB0aGVy
ZSBhIG5lZWQgZm9yIHRoaXMgZmVhdHVyZT8NCg0KWWVzLiAgQ2VydGFpbiBvYmplY3RzIGFyZSBv
bmx5IGF2YWlsYWJsZSB3aGVuIHRoZSByZXBsYXkgZmVhdHVyZSBpcyBzdXBwb3J0ZWQuDQoNCj4g
U2VjdGlvbiA0LCBEQVRBIE5PREVTOiBsZWFmICJyZXBsYXktbG9nLWNyZWF0aW9uLXRpbWUiIGhh
cw0KPiDCoMKgwqDCoMKgwqDCoCB3aGVuICIuLi9yZXBsYXktc3VwcG9ydCI7DQo+IMKgwqDCoMKg
wqDCoMKgIGlmLWZlYXR1cmUgInJlcGxheSI7DQo+IGJ1dCBsZWFmICJyZXBsYXktbG9nLWFnZWQt
dGltZSIgaGFzIG9ubHkNCj4gwqDCoMKgwqDCoMKgwqAgaWYtZmVhdHVyZSAicmVwbGF5IjsNCj4g
DQo+IFNob3VsZCB0aGV5IGJlIHRoZSBzYW1lPw0KDQpJIHRoaW5rIHllcy4gICBVcGRhdGVkLg0K
DQo+IEFsc28sIGlzIHRoZQ0KPiDCoMKgwqDCoMKgwqDCoCBpZi1mZWF0dXJlICJyZXBsYXkiOw0K
PiBuZWVkZWQgaWYNCj4gwqDCoMKgwqDCoMKgwqAgd2hlbiAiLi4vcmVwbGF5LXN1cHBvcnQiOw0K
PiBpcyB1c2VkIHdoZW4gaXQgaXMgdXNpbmcNCj4gwqDCoMKgwqDCoMKgwqAgaWYtZmVhdHVyZSAi
cmVwbGF5IjsNCj4gYWxyZWFkeT8NCg0KUGVyaGFwcyBub3QuICAgQnV0IGl0IGRvZXNuJ3QgaHVy
dC4gYW5kIHRoZSBZQU5HIHRyZWUgZGlzcGxheXMgb3B0aW9uYWwgZmVhdHVyZXMuDQoNCj4gU2Vj
dGlvbiA0LCAibGVhZiBjb25maWd1cmVkLXN1YnNjcmlwdGlvbi1zdGF0ZSI6IFRoZSBkZXNjcmlw
dGlvbiBmb3IgImVudW0NCj4gdmFsaWQiIGxvb2tzIHdyb25nLg0KDQpHb29kIGNhdGNoLiAgRml4
ZWQuDQoNCj4gU2VjdGlvbiA0LCAibGVhZiBjb3VudC1zZW50IjogU2hvdWxkIHRoaXMgYmUgcmVz
ZXQgdG8gemVybyBvbiByZWNlaXZlciBzdGF0ZQ0KPiB0cmFuc2l0aW9uIHRvIGFjdGl2ZSBhcyBv
cHBvc2VkIHRvIHN1YnNjcmlwdGlvbiB0cmFuc2l0aW9uIHRvIHZhbGlkPyBKdXN0IGJlY2F1c2UN
Cj4gdGhlIHN1YnNjcmlwdGlvbiBpcyB2YWxpZCBkb2Vzbid0IG1lYW4gdGhlIHJlY2VpdmVyJ3Mg
YmVpbmcgc2VudCBhbnl0aGluZyBpZiB0aGUNCj4gY29ubmVjdGlvbiBpc24ndCB1cC4NCg0KQWdy
ZWUuICAgTWFkZSAicmVjZWl2ZXIiLg0KDQo+IFNlY3Rpb24gNS40OiAiZGlzY292ZXJlZCx0YWtl
IiB0byAiZGlzY292ZXJlZCwgdGFrZSINCg0KVGhhbmtzIFRpbSEgICBDaGFuZ2VzIGhhdmUgYmVl
biBlbWJlZGRlZC4NCg0KRXJpYw0KDQo+IC0tDQo+IENpc2NvIFN5c3RlbXMgQ2FuYWRhIENvLg0K
PiAyMDAwIElubm92YXRpb24gRHJpdmUNCj4gS2FuYXRhLCBPTiwgQ2FuYWRhLCBLMksgM0U4DQo+
IFByZWZlcmVuY2VzIDxodHRwOi8vd3d3LmNpc2NvLmNvbS9vZmZlci9zdWJzY3JpYmUvP3NpZD0w
MDA0NzgzMjY+DQo+IFVuc3Vic2NyaWJlIDxodHRwOi8vd3d3LmNpc2NvLmNvbS9vZmZlci91bnN1
YnNjcmliZS8/c2lkPTAwMDQ3ODMyNz4NCj4gUHJpdmFjeSA8aHR0cDovL3d3dy5jaXNjby5jb20v
d2ViL3NpdGVhc3NldHMvbGVnYWwvcHJpdmFjeS5odG1sPg0KDQo=


From nobody Thu Sep 13 13:37:38 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0339130E77 for ; Thu, 13 Sep 2018 13:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_HIGH=-0.01, 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 iifoRvi2v27F for ; Thu, 13 Sep 2018 13:37:35 -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 C9419130E63 for ; Thu, 13 Sep 2018 13:37:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5448; q=dns/txt; s=iport; t=1536871054; x=1538080654; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Kigj3mDSJVXtJdnoj8F0QTE4wrxwXzgolL+xVf3FZpg=; b=cRYQRWqIDBexXn5rpa2Epn3IVGOkru2HBgbiUfng8jDiO4oTEPz93ElO ZOOniq0hirlFpVBhPj1OKzASOL3mYsHqfO1JDtXnp+DKP5aoOS9z69hME bBvJNa66dzqwUnoLQ8/GYjfgKdliuZ25wIGxZwv+8TrNKeBf2wPXy/0t6 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAABeyppb/5pdJa1TCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGBUYIFgWQoCpoxllKBZguEbAKDWCE3FQECAQECAQECbSi?= =?us-ascii?q?FOAEBAQECATo9AgULAgEIDgcDDREQMiUCBA4FCBOFAAinR4oLimgXgUE/gRK?= =?us-ascii?q?DEoRUEoVwAogkhl6EHYg4TwkCkAYfjwOUDAIRFIElMyKBVXAVgyeQU2+NA4E?= =?us-ascii?q?eAQE?=
X-IronPort-AV: E=Sophos;i="5.53,370,1531785600"; d="scan'208";a="452046038"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 20:37:07 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id w8DKb78L007244 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Sep 2018 20:37:07 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 13 Sep 2018 16:37:06 -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.1395.000; Thu, 13 Sep 2018 16:37:06 -0400
From: "Eric Voit (evoit)" 
To: Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of subscribed-notifications-16
Thread-Index: AQHUSS2c6fWPWMQnpECqHWzj9l2RFqTpyY1wgALe1QCAACWmwIABR3cAgABBbiCAAGvHAP//vguAgABTSAD//9utsA==
Date: Thu, 13 Sep 2018 20:37:06 +0000
Message-ID: <7fa1f7ec55414cffa6619cbe9991f5b9@XCH-RTP-013.cisco.com>
References:  <20180913.194130.1322555935706323857.mbj@tail-f.com> <686dd827ac6e440680a5191d98d80b3e@XCH-RTP-013.cisco.com> <20180913.204330.1589475713466728926.mbj@tail-f.com>
In-Reply-To: <20180913.204330.1589475713466728926.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.234]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 20:37:37 -0000

> From: Martin Bjorklund, September 13, 2018 2:44 PM
>=20
> "Eric Voit (evoit)"  wrote:
> > Hi Martin,
> >
> > > From: Martin Bjorklund, September 13, 2018 1:42 PM
> > >
> > > Hi,
> > >
> > > "Eric Voit (evoit)"  wrote:
> > >
> > > [trimming...]
> > >
> > > > > > > > > o  Section 2.4.6
> > > > > > > > >
> > > > > > > > >   The text says:
> > > > > > > > >
> > > > > > > > >     1.  "establish-subscription-stream-error-info": This =
MUST be
> > > > > > > > >     returned
> > > > > > > > >         if an RPC error reason has not been placed elsewh=
ere within
> > > > > > > > >         the
> > > > > > > > >         transport portion of a failed "establish-subscrip=
tion" RPC
> > > > > > > > >         response.
> > > > > > > > >
> > > > > > > > >   (and similar for the other errors)
> > > > > > > > >
> > > > > > > > >   What exactly does "if an RPC error reason has not been =
placed
> > > > > > > > >   elsewhere" mean?
> > > > > > > >
> > > > > > > > The intent is to match how NETCONF & RESTCONF historically
> > > > > > > > handles errors.  As you know with NETCONF, each error
> > > > > > > > identity will be inserted as the "error-app-tag".
> > > > > > >
> > > > > > > It could also be in "error-tag" and/or "error-message".  My
> > > > > > > point is that I don't think that you mean that if an
> > > > > > > implementation populate say "error-message", then it should
> > > > > > > not popluate error-info with
> > > > > > > establish-subscription-stream- error-info.
> > > > > >
> > > > > > I do mean that.  I don't think we should send:
> > > > > > "establish-subscription-stream-error-info" for NETCONF when
> > > > > > there is no hint included.  All the necessary error info is
> > > > > > already in the existing message.
> > > > >
> > > > > But is this really true?  In the
> > > > > "establish-subscription-stream-error-info" there is a leaf
> > > > > called "reason", which is an identity with a detailed error
> > > > > reason, for example "history-unavailable".
> > > > > This info is not present anywhere else in the rpc-error, so it
> > > > > needs to be present here.
> > > >
> > > > For NETCONF, this info should be mapped into .  See
> > > > section 7 of NETCONF-Notif, as well as Figure 10 for an example.
> > > > Or section 3 of RESTCONF-Notif, with Figure 7.
> > > >
> > > > This was done to align things with existing NETCONF & RESTCONF
> > > > error mechanisms.
> > >
> > > Ok.  I thought the special error-app-tag thing was removed.  If we
> > > have the error-app-tag value, why do we also have the "reason" leaf?
> >
> > Because of the need to be transport agnostic.  Other protocols are
> > unlikely to have a pre-existing "error-app-tag" construct.
>=20
> ... which is a reason to not do the error-app-tag trick; it would then wo=
rk the
> same across all protocols.

Yes, that was our original proposal.   The WG requested this change about a=
 year ago.  (I can find the threads if necessary.)
=20
> But are you sure that these "other protocols" even has a mechanism to ins=
ert
> the new error-info structures into their errors?

We will need to look at them one-by-one.  But I am hoping yes.
=20
> > And the
> > current YANG data structure can be inserted where needed and contain
> >
> > > Since I thought that the error-app-tag was removed, I asked Alex to
> > > remove them from the examples in YANG push (that doc has examples ;).
> > > These examples in YANG push need to put back the error-app-tag.
> > >
> > > So now we're back to the main issue.  Is it clear from the SN text
> > > when to include the error-info yang-data stuff or not?
> >
> > I have added a new sentence which hopefully clarifies this intent withi=
n
> section 2.4.  I have also re-added the second sentence of each bullet to
> something close to the original text of -v16.  It now reads:
> >
> >
> >    There is one final set of transport independent RPC error elements
> >    included in the YANG model.  These are three yang-data structures
> >    which enable the publisher to provide to the receiver that error
> >    information which does not fit into existing transport layer RPC
> >    structures.  These three yang-data structures are:
> >
> >    1.  "establish-subscription-stream-error-info": This MUST be returne=
d
> >        with the leaf "reason" populated if an RPC error reason has not
> >        been placed elsewhere within the transport portion of a failed
> >        "establish-subscription" RPC response.  This MUST be sent if
> >        hints on how to overcome the RPC error are included.
> >
> >    2.  "modify-subscription-stream-error-info": This MUST be returned
> >        with the leaf "reason" populated if an RPC error reason has not
> >        been placed elsewhere within the transport portion of a failed
> >        "modify-subscription" RPC response.  This MUST be sent if hints
> >        on how to overcome the RPC error are included.
> >
> >    3.  "delete-subscription-error-info": This MUST be returned with the
> >        leaf "reason" populated if an RPC error reason has not been
> >        placed elsewhere within the transport portion of a failed
> >        "delete-subscription" or "kill-subscription" RPC response
>=20
> Ok, I don't like this solution, but I can accept it.

Thanks.

Eric

> /martin


From nobody Thu Sep 13 13:46:20 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0C6130E63 for ; Thu, 13 Sep 2018 13:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_HIGH=-0.01, 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 dmPnK_aCYgYb for ; Thu, 13 Sep 2018 13:46:15 -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 70905130E7C for ; Thu, 13 Sep 2018 13:46:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4215; q=dns/txt; s=iport; t=1536871575; x=1538081175; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sWC7GLrQdkRgnrAYUdY2UEt0dW1PiylXz7v772wl0Ec=; b=HNFq6oZA7mO/1PNz+9Wq+1z6BGYTz08/frw566qlModVw4keMhhkdHXZ m12415spZSn4qOmQ0Vr9xKdBF+QMO3qOH2Xxf7dQJVHC/mBN6eLosa0Bw PiNv9obpVTC1LSkQSnVsgTPC2bAYktbTLj+NCX/FGaElQrkc3t2BaGZ+7 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGAQBTy5pb/51dJa1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYMsKmV/KAqaMXiXQAsYC4QDRgKDWCFMAQIBAQIBAQJtHAyFOAE?= =?us-ascii?q?BAQECAQEBODQJBwsCAQgOBxARECcLJQIEARIIgk5MgXkID6c6igYFimgXgUE?= =?us-ascii?q?/gRKCFEk1gxsBAYFLhW4CiAuFQ45YCQKQBh+BQY1CiFOLOQIRFIElNCGBVXA?= =?us-ascii?q?VO4Jsgk2ISIU+b40DgR4BAQ?=
X-IronPort-AV: E=Sophos;i="5.53,370,1531785600"; d="scan'208";a="448818802"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 20:46:08 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w8DKk8g1028733 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Sep 2018 20:46:08 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.1395.4; Thu, 13 Sep 2018 16:46:07 -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.1395.000; Thu, 13 Sep 2018 16:46:07 -0400
From: "Eric Voit (evoit)" 
To: Martin Bjorklund , "netconf@ietf.org" 
Thread-Topic: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
Thread-Index: AQHUSpBZpYtwPWXE1k2ur9Y/QhScQaTs+hAA
Date: Thu, 13 Sep 2018 20:46:07 +0000
Message-ID: 
References: <20180912.140109.1250692833398495223.mbj@tail-f.com>
In-Reply-To: <20180912.140109.1250692833398495223.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.234]
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-6.cisco.com
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Sep 2018 20:46:18 -0000

Hi Martin,

> From: Martin Bjorklund, September 12, 2018 8:01 AM
>=20
> Hi,
>=20
> I forgot one thing in my review, that has been discussed (slightly
> off-topic) in the thread "netconf call home connection type".
>=20
> The SN draft (implicitly) assumes that for dynamic subscriptions, after a
> successful "establish-subscription" operation, notification messages can =
start
> to flow to the client.
>=20
> The exact mechanism for this is transport-protocol-dependent.
>=20
> For NETCONF, the netconf-notif draft will need to update RFC 6241, since =
6241
> refers to 5277 which says that a  message can only be sent =
after a
> successful "create-subscription".  netconf-notif updates this to allow
>  messages to also be sent after a succsessful "establish-
> subscription".

Thanks.  I have included this as a note to the RFC Editor within NETCONF-No=
tif.

> For RESTCONF, the restconf-notif draft defines a new mechanism for how
> notifications are delivered; instead of locating the SSE resource url fro=
m the
> "streams" in "ietf-restconf-monitoring", this draft now augments a locati=
on leaf
> to the output of "establish-subscription".
> (It probably doesn't have to update 8040, but *maybe* the mechanism in
> 8040 ought to be deprecated)
>=20
>=20
> For configured subscriptions however, the SN draft doesn't specify how th=
e
> flow of notifications should start.  One view is that this is transport-p=
rotocol-
> specific.

Yes, protocol specific is what has been assumed for the current draft set. =
=20

> However, I think that for all RPC-based transport-protocols (currently
> NETCONF and RESTCONF) it makes sense to have a common way to get the
> notifications to be sent.=20

Perhaps something will be needed for NETCONF.  But for configured RESTCONF =
subscriptions, RESTCONF-Notif has been assuming that RESTCONF not be used. =
 Instead raw HTTP2 with the Publisher being the HTTP client and the receive=
r the HTTP server seems cleaner.  And the HTTP server need not respond with=
 an 'ok' to a "subscription-started" unless it is ready to accept event rec=
ords.  So I think there are open questions on the best way to do HTTP confi=
gured transport.

> Hence I suggest that this draft adds a new rpc
> operation "activate-configured-subscription" (better name anyone?). This =
rpc
> would be invoked by the client after a call home to start the flow of con=
figured
> subscriptions.  If there are no such subscriptions or the session is not =
a call
> home session and error would be returned.
>
> We might define non-RPC-based transport protocols for configured
> subscriptions in the future.  Such a protocol can obviously not use this =
rpc, but
> OTOH it can't use establish-subscription either.  I think this is ok.

Perhaps this could be useful.  But it would be great wherever possible if w=
e can avoid receiver RPCs as a mandatory element of the establishment flow =
with a configured publisher.  So I believe we should investigate further on=
 this for NETCONF configured in the coming months.   If it does turn out us=
eful, I would like to see more than NETCONF potentially make use of the RPC=
 before generalizing to the SN level.
=20
> With such an RPC, netconf-notif would udate 6241 to say that 
> messages can be sent after a succsessful "establish-subscription" or "act=
ivate-
> configured-subscription" rpc.
>=20
> And with such an RPC, restconf-notif can support configured subscriptions=
 over
> proper RESTCONF; it would augment a "location" leaf to the output of acti=
vate-
> configured-subscription, which would contain the URL to the event flow, s=
o
> that it works just like dynamic subscriptions.
>
> If we don't add this RPC to the SN draft, each protocol draft will have t=
o define
> its own version of this operation.

Defining something local to a protocol might be ok until we get some clarit=
y on the generality of this issue.

Eric

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


From nobody Fri Sep 14 00:11:29 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE940130DD2 for ; Fri, 14 Sep 2018 00:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LKlN95CbcYTm for ; Fri, 14 Sep 2018 00:11:24 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DE808130E10 for ; Fri, 14 Sep 2018 00:11:23 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 4BEE41AE02C9; Fri, 14 Sep 2018 09:11:21 +0200 (CEST)
Date: Fri, 14 Sep 2018 09:11:20 +0200 (CEST)
Message-Id: <20180914.091120.602490077927092016.mbj@tail-f.com>
To: evoit@cisco.com
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20180912.140109.1250692833398495223.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2018 07:11:27 -0000

"Eric Voit (evoit)"  wrote:
> Hi Martin,
> 
> > From: Martin Bjorklund, September 12, 2018 8:01 AM
> > 
> > Hi,
> > 
> > I forgot one thing in my review, that has been discussed (slightly
> > off-topic) in the thread "netconf call home connection type".
> > 
> > The SN draft (implicitly) assumes that for dynamic subscriptions,
> > after a
> > successful "establish-subscription" operation, notification messages
> > can start
> > to flow to the client.
> > 
> > The exact mechanism for this is transport-protocol-dependent.
> > 
> > For NETCONF, the netconf-notif draft will need to update RFC 6241,
> > since 6241
> > refers to 5277 which says that a  message can only be
> > sent after a
> > successful "create-subscription".  netconf-notif updates this to allow
> >  messages to also be sent after a succsessful
> > "establish-
> > subscription".
> 
> Thanks.  I have included this as a note to the RFC Editor within
> NETCONF-Notif.
> 
> > For RESTCONF, the restconf-notif draft defines a new mechanism for how
> > notifications are delivered; instead of locating the SSE resource url
> > from the
> > "streams" in "ietf-restconf-monitoring", this draft now augments a
> > location leaf
> > to the output of "establish-subscription".
> > (It probably doesn't have to update 8040, but *maybe* the mechanism in
> > 8040 ought to be deprecated)
> > 
> > 
> > For configured subscriptions however, the SN draft doesn't specify how
> > the
> > flow of notifications should start.  One view is that this is
> > transport-protocol-
> > specific.
> 
> Yes, protocol specific is what has been assumed for the current draft
> set.
> 
> > However, I think that for all RPC-based transport-protocols (currently
> > NETCONF and RESTCONF) it makes sense to have a common way to get the
> > notifications to be sent. 
> 
> Perhaps something will be needed for NETCONF.  But for configured
> RESTCONF subscriptions, RESTCONF-Notif has been assuming that RESTCONF
> not be used.  Instead raw HTTP2 with the Publisher being the HTTP
> client and the receiver the HTTP server seems cleaner.

This has been pointed out before - the restconf-notif draft should
define *RESTCONF* mechanisms for subscribed notifications.

If you want to define a new "notif-only" protocol that uses HTTP/2,
that should be done in a separate document.

Also, with the addition of a "activate-configured-subecription", we
can use existing RESTCONF mechanisms to support configured
subscriptions; it more or less falls out for free, as I explained.

> And the HTTP
> server need not respond with an 'ok' to a "subscription-started"
> unless it is ready to accept event records.  So I think there are open
> questions on the best way to do HTTP configured transport.

Maybe another reason to do this in a separate document.

> > Hence I suggest that this draft adds a new rpc
> > operation "activate-configured-subscription" (better name
> > anyone?). This rpc
> > would be invoked by the client after a call home to start the flow of
> > configured
> > subscriptions.  If there are no such subscriptions or the session is
> > not a call
> > home session and error would be returned.
> >
> > We might define non-RPC-based transport protocols for configured
> > subscriptions in the future.  Such a protocol can obviously not use
> > this rpc, but
> > OTOH it can't use establish-subscription either.  I think this is ok.
> 
> Perhaps this could be useful.  But it would be great wherever possible
> if we can avoid receiver RPCs as a mandatory element of the
> establishment flow with a configured publisher.

The idea is that the "reciever RPC" is NOT mandatory; if a transport
needs such an RPC in order to start the notif flow, the transport
document will specifiy that the "activate-configured-subscription" rpc
is used for that transport.

If a new "notif-only" protocol is defined that doesn't utilize this
rpc, the transport spec for that protocol will not use it.

> So I believe we
> should investigate further on this for NETCONF configured in the
> coming months.  If it does turn out useful, I would like to see more
> than NETCONF potentially make use of the RPC before generalizing to
> the SN level.

I was hoping we would be able to get configured subscriptions to work,
for NETCONF and RESTCONF, sooner rather than later.


/martin



> > With such an RPC, netconf-notif would udate 6241 to say that
> > 
> > messages can be sent after a succsessful "establish-subscription" or
> > "activate-
> > configured-subscription" rpc.
> > 
> > And with such an RPC, restconf-notif can support configured
> > subscriptions over
> > proper RESTCONF; it would augment a "location" leaf to the output of
> > activate-
> > configured-subscription, which would contain the URL to the event
> > flow, so
> > that it works just like dynamic subscriptions.
> >
> > If we don't add this RPC to the SN draft, each protocol draft will
> > have to define
> > its own version of this operation.
> 
> Defining something local to a protocol might be ok until we get some
> clarity on the generality of this issue.
> 
> Eric
> 
> > 
> > /martin
> > 
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> 


From nobody Fri Sep 14 00:14:53 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99590130E12 for ; Fri, 14 Sep 2018 00:14:50 -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 dXM6jTeAD4B2 for ; Fri, 14 Sep 2018 00:14:48 -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 3D590130DD2 for ; Fri, 14 Sep 2018 00:14:48 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id F1BB2DD4; Fri, 14 Sep 2018 09:14:46 +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 Z0Z9Yr5WvUX8; Fri, 14 Sep 2018 09:14:45 +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; Fri, 14 Sep 2018 09:14:46 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9D8A20037; Fri, 14 Sep 2018 09:14:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xM8whmKFtU9u; Fri, 14 Sep 2018 09:14:46 +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 "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 7558C20036; Fri, 14 Sep 2018 09:14:46 +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.1415.2; Fri, 14 Sep 2018 09:14:45 +0200
Received: by anna.localdomain (Postfix, from userid 501) id B5D1624E0FE3; Fri, 14 Sep 2018 09:14:45 +0200 (CEST)
Date: Fri, 14 Sep 2018 09:14:45 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
CC: , 
Message-ID: <20180914071445.ywfnizh4rnzbrs4f@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , evoit@cisco.com, netconf@ietf.org
References: <20180912.140109.1250692833398495223.mbj@tail-f.com>  <20180914.091120.602490077927092016.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180914.091120.602490077927092016.mbj@tail-f.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2018 07:14:51 -0000

On Fri, Sep 14, 2018 at 09:11:20AM +0200, Martin Bjorklund wrote:
> > 
> > > However, I think that for all RPC-based transport-protocols (currently
> > > NETCONF and RESTCONF) it makes sense to have a common way to get the
> > > notifications to be sent. 
> > 
> > Perhaps something will be needed for NETCONF.  But for configured
> > RESTCONF subscriptions, RESTCONF-Notif has been assuming that RESTCONF
> > not be used.  Instead raw HTTP2 with the Publisher being the HTTP
> > client and the receiver the HTTP server seems cleaner.
> 
> This has been pointed out before - the restconf-notif draft should
> define *RESTCONF* mechanisms for subscribed notifications.
> 
> If you want to define a new "notif-only" protocol that uses HTTP/2,
> that should be done in a separate document.
>

+1

/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 Sep 14 03:37:15 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C176A130E12 for ; Fri, 14 Sep 2018 03:37:13 -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 h8BlJTxZXCpB for ; Fri, 14 Sep 2018 03:37:12 -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 1156B126DBF for ; Fri, 14 Sep 2018 03:37:12 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 775018EB451BD for ; Fri, 14 Sep 2018 11:37:07 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 14 Sep 2018 11:37:09 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0399.000; Fri, 14 Sep 2018 18:37:05 +0800
From: Qin Wu 
To: "netconf@ietf.org" 
Thread-Topic: I-D Action: draft-wu-netconf-restconf-factory-restore-02.txt
Thread-Index: AQHUTBXK9RQ3MUl1GEOIlzNCP3NiF6Tvk24Q
Date: Fri, 14 Sep 2018 10:37:05 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2018 10:37:14 -0000

di0wMiBpcyB1cGxvYWRlZCB0byBhZGRyZXNzIGNvbW1lbnRzIGRpc2N1c3NlZCBvbiB0aGUgbGlz
dCwNClRoZSBkaWZmIGlzOg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0
LXd1LW5ldGNvbmYtcmVzdGNvbmYtZmFjdG9yeS1yZXN0b3JlLTAyDQpUaGUgbWFpbiBjaGFuZ2Vz
IGFyZToNCjEuIEV4dGVuZCBleGlzdGluZyBwcm90b2NvbCBvcGVyYXRpb24gdG8gdGFja2xlIGZh
Y3RvcnkgZGF0YXN0b3JlOw0KMi4gSW50cm9kdWNlIHJlc2V0IG9wZXJhdGlvbiB0byBhbGxvdyBy
ZXNldCB0aGUgZGV2aWNlIHRvIGZhY3RvcnkgZGVmYXVsdDsNCiAgc2V0dGluZyBhbmQgbWFrZSBj
b25maWd1cmF0aW9uIHVwZGF0ZSB0byB0YWtlIGVmZmVjdCwgd2hpY2ggaXMgZGlmZmVyZW50IGZy
b20gd2hhdCBzeXN0ZW0tcmVzdGFydCBpcyBkb2luZyBpbiBpZXRmLXN5c3RlbSBtb2R1bGUuDQoz
LiBMZWF2ZSBzeXN0ZW0gcmVzdG9yZSBvdXQgb2Ygc2NvcGUgZm9yIG5vdy4NCkNvbW1lbnRzIGFu
ZCBzdWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCg0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3
orz+yMs6IEktRC1Bbm5vdW5jZSBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3Jn
XSC0+rHtIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0Kt6LLzcqxvOQ6IDIwMTjE6jnUwjE0yNUg
MTg6MjgNCsrVvP7IyzogaS1kLWFubm91bmNlQGlldGYub3JnDQrW98ziOiBJLUQgQWN0aW9uOiBk
cmFmdC13dS1uZXRjb25mLXJlc3Rjb25mLWZhY3RvcnktcmVzdG9yZS0wMi50eHQNCg0KDQpBIE5l
dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E
cmFmdHMgZGlyZWN0b3JpZXMuDQoNCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBGYWN0b3J5
IGRlZmF1bHQgU2V0dGluZyBDYXBhYmlsaXR5DQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IFFp
biBXdQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBZZSBOaXUNCglGaWxlbmFtZSAgICAgICAg
OiBkcmFmdC13dS1uZXRjb25mLXJlc3Rjb25mLWZhY3RvcnktcmVzdG9yZS0wMi50eHQNCglQYWdl
cyAgICAgICAgICAgOiAxMQ0KCURhdGUgICAgICAgICAgICA6IDIwMTgtMDktMTQNCg0KQWJzdHJh
Y3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgY2FwYWJpbGl0eSBiYXNlZCBleHRlbnNpb24g
dG8gTkVUQ09ORiBhbmQNCiAgIFJFU1RDT05GIHByb3RvY29sIHRoYXQgYWxsb3dzIGEgY2xpZW50
IHRvIGNvbmZpZ3VyZSBuZXdseSBkZXBsb3llZA0KICAgZGV2aWNlcyB3aXRoIGp1c3QgaXRzIHBy
ZWNvbmZpZ3VyZWQgaW5pdGlhbCBzdGF0ZSAoaS5lLiwgZmFjdG9yeQ0KICAgZGVmYXVsdCBzZXR0
aW5ncykgZHVyaW5nIHplcm8gdG91Y2ggYm9vdHN0cmFwcGluZyBwcm9jZXNzIG9yIHJlc2V0DQog
ICB0aGUgZGV2aWNlIHdpdGggdGhlIGNvbnRlbnQgb2YgZmFjdG9yeSBkZWZhdWx0IHNldHRpbmcg
Y29uZmlndXJhdGlvbi4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3Ig
dGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1
LW5ldGNvbmYtcmVzdGNvbmYtZmFjdG9yeS1yZXN0b3JlLw0KDQpUaGVyZSBhcmUgYWxzbyBodG1s
aXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtd3UtbmV0Y29uZi1yZXN0Y29uZi1mYWN0b3J5LXJlc3RvcmUtMDINCmh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtd3UtbmV0Y29uZi1yZXN0Y29uZi1mYWN0
b3J5LXJlc3RvcmUtMDINCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh
aWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXd1LW5l
dGNvbmYtcmVzdGNvbmYtZmFjdG9yeS1yZXN0b3JlLTAyDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBp
dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv
biB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv
b2xzLmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu
b255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSS1ELUFubm91
bmNlIG1haWxpbmcgbGlzdA0KSS1ELUFubm91bmNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0
b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwgb3IgZnRwOi8vZnRwLmlldGYu
b3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCg==


From nobody Fri Sep 14 05:47:24 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0282E130E35 for ; Fri, 14 Sep 2018 05:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_DKIMWL_WL_MED=-0.01, 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 gwu9-6dnEAXu for ; Fri, 14 Sep 2018 05:47:21 -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 87810126DBF for ; Fri, 14 Sep 2018 05:47:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1213; q=dns/txt; s=iport; t=1536929241; x=1538138841; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1mepiIxwj6ZYLb/Rj/5fDV9lFdpr8hh7HCAVffVucgM=; b=ahxrgaVnwXk3wQvEOjLFl2mAGUotJvkxBx4F43sdR8l7EuHUz8pghM+/ Y6oCKWGp2VfGEpOju1gRJV3UfT7ubvuINvQdvbXtNRWmzywv3JA/2aPwu 8jcuVI/XRsYPZ1fnQ7K8v1mYXKASMxQ13uzaiui9xuCl9RO5p7gga3jX+ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AACZrZtb/5NdJa1YAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGBT4IHZX8ymCWCDZZBFIFmCx+ETQKDXCE1FwECAQECAQE?= =?us-ascii?q?CbRwMhTgBAQEBAgE6PQIFCQICAQgOAggeEBsXJQIEAQ0NgxqBeQilb4oCBQW?= =?us-ascii?q?KYxeBQT+BEoMShGYCNyaFEQKcMQkCkAkfjwWUGwIRFIElHgE2gVVwFYMogky?= =?us-ascii?q?DZ4ofjkeBHgEB?=
X-IronPort-AV: E=Sophos;i="5.53,373,1531785600"; d="scan'208";a="171894164"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2018 12:47:20 +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 w8EClKsu028505 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Sep 2018 12:47:20 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.1395.4; Fri, 14 Sep 2018 08:47: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.1395.000; Fri, 14 Sep 2018 08:47:19 -0400
From: "Eric Voit (evoit)" 
To: Juergen Schoenwaelder , "Martin Bjorklund" 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
Thread-Index: AQHUSpBZpYtwPWXE1k2ur9Y/QhScQaTs+hAAgAKoIwCAAAD0gIAAGY/g
Date: Fri, 14 Sep 2018 12:47:19 +0000
Message-ID: <42f41b6da3404c519623e2b320f74817@XCH-RTP-013.cisco.com>
References: <20180912.140109.1250692833398495223.mbj@tail-f.com>  <20180914.091120.602490077927092016.mbj@tail-f.com> <20180914071445.ywfnizh4rnzbrs4f@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180914071445.ywfnizh4rnzbrs4f@anna.jacobs.jacobs-university.de>
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.234]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2018 12:47:23 -0000

> On Fri, Sep 14, 2018 at 09:11:20AM +0200, Martin Bjorklund wrote:
> > >
> > > > However, I think that for all RPC-based transport-protocols
> > > > (currently NETCONF and RESTCONF) it makes sense to have a common
> > > > way to get the notifications to be sent.
> > >
> > > Perhaps something will be needed for NETCONF.  But for configured
> > > RESTCONF subscriptions, RESTCONF-Notif has been assuming that
> > > RESTCONF not be used.  Instead raw HTTP2 with the Publisher being
> > > the HTTP client and the receiver the HTTP server seems cleaner.
> >
> > This has been pointed out before - the restconf-notif draft should
> > define *RESTCONF* mechanisms for subscribed notifications.
> >
> > If you want to define a new "notif-only" protocol that uses HTTP/2,
> > that should be done in a separate document.
> >
>=20
> +1

You will see HTTP2 configured will be removed in the next version of the do=
cument which Reshad will be posting shortly.

Eric

> /js
>=20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         


From nobody Fri Sep 14 07:00:44 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63B8130E3A for ; Fri, 14 Sep 2018 07:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQtqvh4ZZSgB for ; Fri, 14 Sep 2018 07:00:39 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on070b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::70b]) (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 9DBA012785F for ; Fri, 14 Sep 2018 07:00:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZRNGK6MdIf6prvCTtE4ixyrtFrkwsEEeieCTVDySOhA=; b=s6XnXVztuLv9FDZiI/qlyag/eWg2gK/du/bAblujhB6TWDWSYqTl1aYXcY/j4yuyPtZkC2ctc4BwpgudJbPB1vwKCEuIBGv97MEr18q0OE+FW1TU74RFmlZSiyQmV1e3XrwsBAlQ241ybRRkaB4hPE/Z2hE5p7VMGAOqA4a1wvo=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=yves.beauville@nokia.com; 
Received: from [138.203.136.94] (135.245.212.94) by HE1PR07MB1292.eurprd07.prod.outlook.com (2a01:111:e400:59af::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.9; Fri, 14 Sep 2018 14:00:35 +0000
To: netconf@ietf.org
References: <88cded4f-a788-294c-59b8-1e7aa51d77f9@nokia.com>
From: "Beauville, Yves (Nokia - BE/Antwerp)" 
Message-ID: <285a0e14-0777-257a-7d41-2c09d196a498@nokia.com>
Date: Fri, 14 Sep 2018 16:00:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <88cded4f-a788-294c-59b8-1e7aa51d77f9@nokia.com>
Content-Type: multipart/alternative; boundary="------------B6969435CA05244E936C75D0"
Content-Language: en-US
X-Originating-IP: [135.245.212.94]
X-ClientProxiedBy: HE1PR0301CA0010.eurprd03.prod.outlook.com (2603:10a6:3:76::20) To HE1PR07MB1292.eurprd07.prod.outlook.com (2a01:111:e400:59af::26)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: b6291ccc-345d-4c37-664d-08d61a4a71dc
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:HE1PR07MB1292; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1292; 3:nlu6+V0IX6PduhZTTf+E2w6jIhuyNaIcQvT0yHUziml9xmNuiDg9ajekY6XW5lhDJ68UX24cLbgKxBUx+zFt/RseKjgtFCofNTlWAnYpvsHjDlBnrnLrOVOlVQsYdvwymiX2K+wwWmmUeF9K7GTjBO360Dd+a7aKlH3himoMUyQdpsatbEB4g4MCF6ijZciBKJC3hZiMtLU9hW788giEfvklV0sUtIgG/zXToO/WyrU+rf6JtpEXTy7r9fzNb7EU; 25:fBfKL0U2a7DeULkibFXcLe1mXxEb3KpVDJOKBoBhqOLTaR2ituCfOVDzVgJXW4G0ZMoLT0MxYCxaE2gJVaOSp+OrI4hzMMPyD5G1gVvYmPFpH+2feqILzaYd0FgAk02uZMSYavt5O4TCdoq61B5Ef66pHVmwY4uvdfzT/CyJ24Kvw3kCKExuckjSXdlL0FVa48hbwRkwNP6rodxR8xUwu4n1il4d4zWHGh9O2eeE8FAgmWe3YfxibPkPZcK2sLtnQSURtpMYeAfzwctlmSwsQDXCglivGB6reUCtAiAg2iLM9h7HkOscNXHUlrGjYKn0jeUW/JG/7S5jZYC4p6/rPg==; 31:1acGk3XtRyCfySFIBG9G6p4O9IpSyF/McPTq8zRi9b+PKrykQJqfr9gcnU5qs8UD5DKfY9emLCtbI4akejMcM0sCX3jSaJUgNfhohRiScGtOojhmperm/eQVMedHLyXd6UxsWTOzCyvan3p6fTcXYeQqL9IhE7Dcln3C5bocmqdGNQc90SDwKfWXPn0YwtY99RPK2bmQVHDwE4Dnj/QQnq2l+zgfhXVn11F0QEf0Jgk=
X-MS-TrafficTypeDiagnostic: HE1PR07MB1292:
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1292; 20:YI578zBlOqATzaKYEuUV3kYC3fSnuhmVbg+4IRRxOCKVK1PmXic1oL2t3ILlRcho8kTOb9WrdqlR59OMQwBlG5ZknrUcDE3xBs8xpdsc8tuSyXgxz8Voa3MMoJxT8g+AjhBgDhCcanVfVVnpIdNm+5cyAAI/VBidp4bUJXVUlQfzs7YzkgoFdG+1ia0LfxMBD3A2j9tNT86jlWibIOrOEgDVHEuDw8MGMnVuAG0/6poLf/bZK9x6cpP1MwZSLR019LWENP40tLSLamzWf1Q0GnFt9RVgeE4ubeIlMBuDp9o1AhhwW/gH2+kh1yTjI1WwhjwJj3bgVCpED8JsMUSGTyIbcZe9H6lqond0qbcUkgYSZKupBf4n3ZaSwl79Ags6+tyIjSFKBFLfVxy3C+s+e5mobc2KqvU1Q+VMFoF0ongbXYbn/PrFji8S6iiHPt196IrIqhUMBkZO9qgshk2qZ1SQ1sceSzf1UC299aSQT4+GHllImB0ZC9uclYt4+xCi; 4:p98fKq1RYtgX/eiGxfek1+vjL8VFbLEbgRaoD6Wl2OIswAmSURLc81Cy5W21zeJIO2k5wFGM8qbdrkdy2+iO2wqP9l3CNoRF/fk7kuL6NIjitEBjgLKL1jRMA11+AGR2KlToDphuEzwxf4iMR47zUhH46+2Hqp5xCMwwV3Tg3rr3b3igcTjhqwVEXelhW+goPZTRM6uuVCMmOnlXgEMMfAXYnVSnCe4mGfMb0KRIVyneu7+OWaoUveumIY1REZARV9XCwipcKvGHki7B/z5EfjDIVwxOXbwq9lpUtTLtDJENvHw99rSGet9/2mXf16tt7XIsUhpWhnbNLeRSmv4k+L+ynTA5R31ygwFkP2vzxp01NDglXnEwUFWdEb/ubtat
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(82608151540597)(109105607167333)(195916259791689); 
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231311)(11241501184)(806099)(944501410)(52105095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699050); SRVR:HE1PR07MB1292; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1292; 
X-Forefront-PRVS: 07954CC105
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(346002)(376002)(39860400002)(366004)(396003)(136003)(199004)(189003)(53754006)(6916009)(64126003)(6666003)(25786009)(3260700006)(53546011)(36756003)(65826007)(2351001)(31696002)(316002)(217873002)(49976009)(606006)(86362001)(84326002)(236005)(2361001)(68736007)(6486002)(14444005)(6306002)(106356001)(5660300001)(229853002)(6246003)(54896002)(65806001)(26005)(53936002)(65956001)(186003)(81156014)(3846002)(105586002)(2906002)(37036004)(16576012)(386003)(6116002)(11346002)(33964004)(16526019)(7736002)(52116002)(58126008)(966005)(446003)(478600001)(476003)(81166006)(956004)(2616005)(8936002)(97736004)(16586007)(66066001)(76176011)(8676002)(31686004)(486006)(78286006); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1292; H:[138.203.136.94]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1PR07MB1292; 23:ZpM1LH/hoHUUTvJjDRFiMo4f7qJfS333Vhy5oPTLV?= =?us-ascii?Q?fpwEV+D9V1IlJJJ8QIXe8I9q+5c7DZF4WR5kUYm9YCMO1C6xxCTbLwErfghR?= =?us-ascii?Q?zssALbZeMlDT50CCLxhbd+aeG5afDbCt4gvKVWLlc4G+yuzkIwdLGCLuhQJj?= =?us-ascii?Q?vq+Y4A+ljiCi6nY3hHgkIyKtA4r5kxZsuGTdGwwcLQYxWXwT7LDi/+Bwggo2?= =?us-ascii?Q?2OZOzFHCF6wTjt3WNKnSY/hXiacYskjnwX7rnPykalN9xdW5dR8atrScS4Yu?= =?us-ascii?Q?/VpSvhHCNN9ZLwLkNz7RsI8BWTP+I0V3MkxPaghJ7RvKpUenxYSm4v/RBlqS?= =?us-ascii?Q?oixE6IXaiA6ygtLj6fYAdYxgq4pOhCIyfVIlmYbA+3qhAzw0t9MociaTA6br?= =?us-ascii?Q?Jm1uwy3qhJCQQyK+HMct3NvSrG9Drtm0TxJhUGJgvJHodmL4DHrC6G0Bxz+F?= =?us-ascii?Q?vHTr7ABzP8AiDNkZpZyIg+zvMtl0t8Hrd1XFvmD6VFyW77NUe1ze02wAWcdC?= =?us-ascii?Q?7snw+0IS8Mky+g+Rk2YqQbPn/x/OovgEbyYfmY0El4pPBMCoh75SOTSVYHCm?= =?us-ascii?Q?pnM1/PW4Jb4r9RPuTJl6MVYiXJRhegfxmG4dwWOC065EsrKd6++CcTQfXo0y?= =?us-ascii?Q?8YE9zwgJ8AhQcuuDOGbl0GVwB8EiOCE0aHP9OG6ZwT0t+fLbtPTDD+tolcJJ?= =?us-ascii?Q?JSFDdhzyJ2WihzHaaGEFpxtfK/pgiKdN7NfUU5hrmXk1e7qEW84O3Jpgv3L/?= =?us-ascii?Q?9eYuV5m0bki0GGU/BeN33xF429UJSlPGf+9OVXpOxsOweOkBuJGxaxQoSrO0?= =?us-ascii?Q?eE9GbzChJEMpliRFe3NeN0XVQnpK2rhHImpRo2DWGFhShC8JRZ2IEjdpYvxi?= =?us-ascii?Q?jtk1fpzEkl6yrhZH1VQZHrz1Mzimmo/7il8g8wkb36iImjoFx81TSMZUrl1B?= =?us-ascii?Q?g2/VXEt9A2vP9VcR2ZvnGZbTKiISEKVKJlRO+Rjirh9Vt+ad/P/GK9PjCRPv?= =?us-ascii?Q?nmP1Vij9xGT5QlELmufAv9a/EbCE4+HLh/9+UPwOTb4BhK1HnAy35HT1Kpo5?= =?us-ascii?Q?qjqNMp9GkPCjA4GcwwMu2o22QPRPWboCNL7T9RWuy12ZAi+gP85LtgvpeVN5?= =?us-ascii?Q?Gtrc/0Av60igzKjMnXP8SQ9dM1vkdebGbp9HEqCG+IWrc6/Dkp7KuXOGMP2U?= =?us-ascii?Q?O9wVmVvvdf/MmR/hUKN0DyHCwQ7Ah+YACHxV0l+/UOnF9l/D8TeLjDWCl+nQ?= =?us-ascii?Q?F0a0sh0Ed0MM4TwMhDE5puYsweHSfyWoFLklthHKOxjyCB6J8Ia9YLIuNT8q?= =?us-ascii?Q?2V8OnC8VKFXdtOJdipBJMRrwSsJrMYpx4pj3bgD5PZOcHf3kUOPBmrbcsasN?= =?us-ascii?Q?1iJhJXB+hxf4JwDWuYKgNTbdeGzOqq6UMCYSsPzAHRnssgRakbyOBGFSFprl?= =?us-ascii?Q?4CJ2oSndOxeqyW+o63LAPiHZaEzP16YKCqJV70rgjOGp2k6zKH0FDKcOQlE6?= =?us-ascii?Q?JZIlQB/4mRCWa7TDy6coMXvKxMU5AvB9wLh+tPCFX6aTzp62z2LV+tiKEpsK?= =?us-ascii?Q?YF4ntODK2vYGIh5GA=3D=3D?=
X-Microsoft-Antispam-Message-Info: 2KzdBi5ryI04PzPmGUb7i3s1FGlfm5tR8Ls9li3wf4qD3RDXWEGevSOTBY3082KBknwiZ6FtqDeY525LENC0LySKYMtlmuVAUmqAnNfKZxQ35Nsb7XFKkHQUAZvZx1XrCykVf3+oDq0JALH5/PNEDKgNMZ4CV8EhSgeZVZPKxgIJ0qLVzx5rtC7z73a/8Zu0NLE3/PSMqw7pENyNrGmaV5p7JazRO/0oLDPpopD5MFsISlNLEzkS3P240v4QRBM7EOJKm8410DPhlQV8HDjTvMyrhzWJ6RjvgnKxDW4EH1h7A+S9+pakBL+KKyCHy5S321sXXAiwLDmIZGyYH9nnLE8z0koYwZR29zwlFV78505uRUQyESDDdmU3s6TR5iiDx8nWczf6g7NE8+O+MVBvZA==
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1292; 6:z2De69WIqbHt8lOz0BRrwPSmYxQ+U9oFOkTIQu1s61g9f23TKwNSysHFVwoI/q9V9JU9VOjgyIo3dJ8jvYsAzFCSQQeZlrQXhZyeMMXQaUATNs4QgOXB7l5Km8UJuQiTKHl6O/DnbOjc91j3UgClMAkQNQdJ+eWPZJ1fJ/0VtGz+CwiJ9OmVzFnT/cZMQrCTx/L0pHOufwEwBVXfzecBEiIYc+425nJyKg8/pmkESJztmfOyt6lcRYaKqFaDBSXMYtJOhFI3rS4eeWAF6kGl6B34TjQpZv0GiG+VxzSuCj4Rv9b1y6Qm2PvRmno4n+tOg4lCL1WDLgM0BKtM1dzGYiXwbzuDzq+TVhmzDn4JHcbMqV/ub8c2kI+M2wnx2V00J9Jn+5Q95Jcjm5CMt1LedioxkLFLbPWP8WP9KRgUC5xTbTFL+AxhrlKqAVahnfQBT14/WRhx6VhcWO9oAtWl1Q==; 5:yFNhUWZS4WknzbbT4OqTCAdk2y3VMx+VI1DjJhXGoYZmx13yLKYFVR8Kcv6NC7MaAiR9cimFSBn30vZYV2W/IQyClHzP3i3JEA2FMIoeqPGUhrmN8ToKFIC0+rOxjNot3QA2e7jUiNid/iArk6Jvp2jMj04mFCm8uo5Ibvb4cBY=; 7:FZmC/GyiY4rNDvO4hDboIgW1oFEHYGVx6WgoIgyFcDlJPYD/d+rAYe4nib+jEKcAB68TFmnaWixR69D4mZwiiX0TQk8lRofULdENoLTjKnJs70DhCHd9QTUeLoprdqhMotKSzWheJEC/wDxN5oHSu3OWSLv2j9B6Q3wQheIO085NoICYPiOEqiGNGQVNUNoeh8Epvlwc6rQ07u/gWf+YauApJrRWGCe1FI2Rocro7aPK1gUyAQ92zhcqlpkYnUK4
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2018 14:00:35.7800 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b6291ccc-345d-4c37-664d-08d61a4a71dc
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1292
Archived-At: 
Subject: Re: [Netconf] RESTCONF URL for a list with an instance-identifier as a key
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2018 14:00:42 -0000

This is a multi-part message in MIME format.
--------------B6969435CA05244E936C75D0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello all,

I am looking at how to encode a data resource identifiers in RESTCONF 
request URI.

I am looking at the specific case of a YANG list, with an 
instance-identifier as a key.

RFC8040, section 3.5.3, specifies the following:

    If a data node in the path expression is a YANG list node, then the
    key values for the list (if any) MUST be encoded according to the
    following rules:
...
    o  The key value is specified as a string,_using the canonical _       _representation for the YANG data type_.  Any reserved characters
       MUST be percent-encoded, according to Sections2.1   and2.5   of
       [RFC3986 ].  The comma (",") character MUST be percent-encoded if
       it is present in the key value.

For an instance-identifier, RFC7950, section 9.13.3, specifies that:

    Since the lexical form depends on the XML context in which the value
    occurs,_this type does not have a canonical form_.

In the example provided below, I have used RFC7951, section 6.11, that  
defines how
an "instance-identifier" value is encoded a string.

Is this a correct approach? Can anyone confirm?

Best Regards
Yves

On 28-08-18 15:02, Beauville, Yves (Nokia - BE/Antwerp) wrote:
>
> Hi All,
>
>  Given the following list in a dummy module called "disable-alarms":
>
>      list disable-alarm {          key "resource";          leaf 
> resource {              type instance-identifier;          }          
> leaf disable {              type boolean;          }      }
>
> And assuming that an entry exists in that list for a resource 
> referring to an interface named 'port' in the "ietf-interfaces" module 
> of RFC-7332.
>
> How do I build a RESTCONF GET request for that entry?
>
> Will it be:
>
>        GET /restconf/data/disable-alarms:disable-alarm=/ietf-interfaces:interfaces/interface[name='port'] HTTP/1.1
>        Host: example.com
>        Accept: application/yang-data+xml
> I have not encoded the URL above for readability. I understand that it 
> should be something like:
> 	/restconf/data/disable-alarms:disable-alarm=%2Fietf-interfaces%3Ainterfaces%2Finterface[name%3D'port']
> If this is not correct, what should be provided in the URL?
>
> Yves
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


--------------B6969435CA05244E936C75D0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello all,

    
I am looking at how to encode a data resource identifiers in
      RESTCONF request URI.

    
I am looking at the specific case of a YANG list, with an
      instance-identifier as a key.

    

    
RFC8040, section 3.5.3, specifies the following:

    
   If a data node in the path expression is a YANG list node, then the
   key values for the list (if any) MUST be encoded according to the
   following rules:
... 
   o  The key value is specified as a string, using the canonical
      representation for the YANG data type.  Any reserved characters
      MUST be percent-encoded, according to Sections 2.1 and 2.5 of
      [RFC3986].  The comma (",") character MUST be percent-encoded if
      it is present in the key value.


    For an instance-identifier, RFC7950, section 9.13.3, specifies that:

    
   Since the lexical form depends on the XML context in which the value
   occurs, this type does not have a canonical form.

    In the example provided below, I have used RFC7951, section 6.11,
    that  defines how 

    an "instance-identifier" value is encoded a string.

    

    Is this a correct approach? Can anyone confirm?

    

    Best Regards

    Yves

    

    
On 28-08-18 15:02, Beauville, Yves
      (Nokia - BE/Antwerp) wrote:

    

    

      
      
Hi All,

      
 Given the following list in a dummy module called
        "disable-alarms":

      

      
     list disable-alarm {
         key "resource";
         leaf resource {
             type instance-identifier;
         }
         leaf disable {
             type boolean;
         }
     }


      
And assuming that an entry exists in that list for a resource
        referring to an interface named 'port' in the "ietf-interfaces"
        module of RFC-7332.

      

      
How do I build a RESTCONF GET request for that entry?

      
Will it be:

      
      GET /restconf/data/disable-alarms:disable-alarm=/ietf-interfaces:interfaces/interface[name='port'] HTTP/1.1
      Host: example.com
      Accept: application/yang-data+xml


      I have not encoded the URL above for readability. I understand
      that it should be something like:

      
	/restconf/data/disable-alarms:disable-alarm=%2Fietf-interfaces%3Ainterfaces%2Finterface[name%3D'port']

      If this is not correct, what should be provided in the URL?

      

      Yves

      

      

      

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


    

    

  


--------------B6969435CA05244E936C75D0--


From nobody Fri Sep 14 08:35:42 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E40130F27 for ; Fri, 14 Sep 2018 08:35:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 18_GUjV8q2nw for ; Fri, 14 Sep 2018 08:35:26 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F189130F00 for ; Fri, 14 Sep 2018 08:35:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2418; q=dns/txt; s=iport; t=1536939326; x=1538148926; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D4oGHHaMUgq09FsSO0yxoah+AUP9nG1F33ylj+V6j+4=; b=L8qF5SZrf+PE54bp3pUINBhxUdFfNWp2z2Y+Xj9RTi7xv1h95XyV1xnZ +dAg5KrNdqXSnKQT0+NZZtMSMXt309G0ZI0xbLtpQaPa1BjXb5qk8T+ix kuAb1ySUMu4Le+d/LicpvRqOVJg+ntF5NYMhQVKapgOMBf2VNJ3k7A065 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQAW1Jtb/4ENJK1YAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGBUIIIZX8oCoNoiBWMKYFoJYM9kwQUgWYLGAsJg3pGAhe?= =?us-ascii?q?DRyE0GAEDAQECAQECbRwMhTgBAQEDAQEBIRE6CQIOAgIBCBAIAgImAgICGQw?= =?us-ascii?q?LFRACBAENBYMhAYF5CA+kdYEuiX8FBYEGiV0XgUE/gRInDBOCTIMbAQECgUc?= =?us-ascii?q?CFhcKGQ2COjGCJgKcNAkCkBIXjwWUHQIRFIElHTiBVXAVOyoBgkGCTYNnhGG?= =?us-ascii?q?FPm8BgRWMRgGBHQEB?=
X-IronPort-AV: E=Sophos;i="5.53,373,1531785600"; d="scan'208";a="171722680"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2018 15:35:25 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w8EFZPEa024989 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Sep 2018 15:35:25 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 14 Sep 2018 10:35:24 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Fri, 14 Sep 2018 10:35:24 -0500
From: "Reshad Rahman (rrahman)" 
To: "Eric Voit (evoit)" , "Juergen Schoenwaelder" , Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
Thread-Index: AQHUSpBZ2OwX3D2gjEWhlFrVZ2QCMKTvBEeAgACurwCAAAD1gIAAXOuA///r5QA=
Date: Fri, 14 Sep 2018 15:35:24 +0000
Message-ID: <257B5D33-5CC2-4693-BF81-244916B903AE@cisco.com>
References: <20180912.140109.1250692833398495223.mbj@tail-f.com>  <20180914.091120.602490077927092016.mbj@tail-f.com> <20180914071445.ywfnizh4rnzbrs4f@anna.jacobs.jacobs-university.de> <42f41b6da3404c519623e2b320f74817@XCH-RTP-013.cisco.com>
In-Reply-To: <42f41b6da3404c519623e2b320f74817@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.39]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Sep 2018 15:35:41 -0000

T24gMjAxOC0wOS0xNCwgODo0NyBBTSwgIk5ldGNvbmYgb24gYmVoYWxmIG9mIEVyaWMgVm9pdCAo
ZXZvaXQpIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBldm9pdD00MGNp
c2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoNCiAgICA+IE9uIEZyaSwgU2VwIDE0LCAy
MDE4IGF0IDA5OjExOjIwQU0gKzAyMDAsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQogICAgPiA+
ID4NCiAgICA+ID4gPiA+IEhvd2V2ZXIsIEkgdGhpbmsgdGhhdCBmb3IgYWxsIFJQQy1iYXNlZCB0
cmFuc3BvcnQtcHJvdG9jb2xzDQogICAgPiA+ID4gPiAoY3VycmVudGx5IE5FVENPTkYgYW5kIFJF
U1RDT05GKSBpdCBtYWtlcyBzZW5zZSB0byBoYXZlIGEgY29tbW9uDQogICAgPiA+ID4gPiB3YXkg
dG8gZ2V0IHRoZSBub3RpZmljYXRpb25zIHRvIGJlIHNlbnQuDQogICAgPiA+ID4NCiAgICA+ID4g
PiBQZXJoYXBzIHNvbWV0aGluZyB3aWxsIGJlIG5lZWRlZCBmb3IgTkVUQ09ORi4gIEJ1dCBmb3Ig
Y29uZmlndXJlZA0KICAgID4gPiA+IFJFU1RDT05GIHN1YnNjcmlwdGlvbnMsIFJFU1RDT05GLU5v
dGlmIGhhcyBiZWVuIGFzc3VtaW5nIHRoYXQNCiAgICA+ID4gPiBSRVNUQ09ORiBub3QgYmUgdXNl
ZC4gIEluc3RlYWQgcmF3IEhUVFAyIHdpdGggdGhlIFB1Ymxpc2hlciBiZWluZw0KICAgID4gPiA+
IHRoZSBIVFRQIGNsaWVudCBhbmQgdGhlIHJlY2VpdmVyIHRoZSBIVFRQIHNlcnZlciBzZWVtcyBj
bGVhbmVyLg0KICAgID4gPg0KICAgID4gPiBUaGlzIGhhcyBiZWVuIHBvaW50ZWQgb3V0IGJlZm9y
ZSAtIHRoZSByZXN0Y29uZi1ub3RpZiBkcmFmdCBzaG91bGQNCiAgICA+ID4gZGVmaW5lICpSRVNU
Q09ORiogbWVjaGFuaXNtcyBmb3Igc3Vic2NyaWJlZCBub3RpZmljYXRpb25zLg0KICAgID4gPg0K
ICAgID4gPiBJZiB5b3Ugd2FudCB0byBkZWZpbmUgYSBuZXcgIm5vdGlmLW9ubHkiIHByb3RvY29s
IHRoYXQgdXNlcyBIVFRQLzIsDQogICAgPiA+IHRoYXQgc2hvdWxkIGJlIGRvbmUgaW4gYSBzZXBh
cmF0ZSBkb2N1bWVudC4NCiAgICA+ID4NCiAgICA+IA0KICAgID4gKzENCiAgICANCiAgICBZb3Ug
d2lsbCBzZWUgSFRUUDIgY29uZmlndXJlZCB3aWxsIGJlIHJlbW92ZWQgaW4gdGhlIG5leHQgdmVy
c2lvbiBvZiB0aGUgZG9jdW1lbnQgd2hpY2ggUmVzaGFkIHdpbGwgYmUgcG9zdGluZyBzaG9ydGx5
Lg0KICAgIA0KICAgIEVyaWMNCg0KPFJSPiBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1p
ZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYtMDcudHh0IGhhcyBkeW5hbWljIHN1YnNjcmlwdGlv
bnMgb25seS4NCg0KUmVnYXJkcywNClJlc2hhZC4NCiAgICANCiAgICA+IC9qcw0KICAgID4gDQog
ICAgPiAtLQ0KICAgID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5p
dmVyc2l0eSBCcmVtZW4gZ0dtYkgNCiAgICA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAg
ICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCiAgICA+IEZheDogICAr
NDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRl
Lz4NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KICAgIE5ldGNvbmYgbWFpbGluZyBsaXN0DQogICAgTmV0Y29uZkBpZXRmLm9yZw0KICAg
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KICAgIA0KDQo=


From nobody Fri Sep 14 18:45:14 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58308130DF1 for ; Fri, 14 Sep 2018 18:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 pJbD5uhVtaLh for ; Fri, 14 Sep 2018 18:45:08 -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 A8FFF12008A for ; Fri, 14 Sep 2018 18:45:07 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 398994E73D6F2 for ; Sat, 15 Sep 2018 02:45:04 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sat, 15 Sep 2018 02:45:04 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0399.000; Sat, 15 Sep 2018 09:44:58 +0800
From: Qin Wu 
To: "Beauville, Yves (Nokia - BE/Antwerp)" , "netconf@ietf.org" 
Thread-Topic: [Netconf] RESTCONF URL for a list with an instance-identifier as a key
Thread-Index: AQHUPs+bSBoVNYpi6UemT7iL5IWhvaTvYtkAgAFGTrA=
Date: Sat, 15 Sep 2018 01:44:57 +0000
Message-ID: 
References: <88cded4f-a788-294c-59b8-1e7aa51d77f9@nokia.com> <285a0e14-0777-257a-7d41-2c09d196a498@nokia.com>
In-Reply-To: <285a0e14-0777-257a-7d41-2c09d196a498@nokia.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B0438F6nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] RESTCONF URL for a list with an instance-identifier as a key
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Sep 2018 01:45:11 -0000

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

SSBkb27igJl0IHRoaW5rIFJFU1RDT05GIGNhbiB0cmFuc2xhdGUgcmVzb3VyY2UgaW50byBwb3J0
IGluc3RhbmNlIGRlZmluZWQgaW4gaWV0Zi1pbnRlcmZhY2VzIGF1dG9tYXRpY2FsbHkuDQpUaGUg
Y29ycmVjdCBSRVNUQ09ORiByZXF1ZXN0IGlzOg0KDQpHRVQgL3Jlc3Rjb25mL2RhdGEvZGlzYWJs
ZS1hbGFybXM6ZGlzYWJsZS1hbGFybS9yZXNvdXJjZT14eHggIEhUVFAvMS4xDQoNCiAgICAgIEhv
c3Q6IGV4YW1wbGUuY29tDQoNCiAgICAgIEFjY2VwdDogYXBwbGljYXRpb24veWFuZy1kYXRhK3ht
bA0KDQpJZiB5b3UgbGluayByZXNvdXJjZSB3aXRoIHBvcnQgaW50ZXJmYWNlIGRlZmluZWQgaW4g
aWV0Zi1pbnRlcmZhY2VzIG1vZHVsZXMsIHh4eCBzaG91bGQgcHJvYmFibHkgYmUgcmVwbGFjZWQg
YnkNCg0KdGhlIHBhdGggdG8gdGhlIHBvcnQgaW50ZXJmYWNlLCBlLmcuLCBzb21ldGhpbmcgbGlr
ZSAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2VbbmFtZT0ncG9ydCddLyBpZjppZkluT2N0ZXRz
DQpwcm9iYWJseSBib3RoIG1vZHVsZXMgbmFtZXNwYWNlIHNob3VsZCBiZSBkZWNsYXJlZCBzb21l
d2hlcmUuDQoNCi1RaW4NCuWPkeS7tuS6ujogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNl
c0BpZXRmLm9yZ10g5Luj6KGoIEJlYXV2aWxsZSwgWXZlcyAoTm9raWEgLSBCRS9BbnR3ZXJwKQ0K
5Y+R6YCB5pe26Ze0OiAyMDE45bm0OeaciDE05pelIDIyOjAwDQrmlLbku7bkuro6IG5ldGNvbmZA
aWV0Zi5vcmcNCuS4u+mimDogUmU6IFtOZXRjb25mXSBSRVNUQ09ORiBVUkwgZm9yIGEgbGlzdCB3
aXRoIGFuIGluc3RhbmNlLWlkZW50aWZpZXIgYXMgYSBrZXkNCg0KDQpIZWxsbyBhbGwsDQoNCkkg
YW0gbG9va2luZyBhdCBob3cgdG8gZW5jb2RlIGEgZGF0YSByZXNvdXJjZSBpZGVudGlmaWVycyBp
biBSRVNUQ09ORiByZXF1ZXN0IFVSSS4NCg0KSSBhbSBsb29raW5nIGF0IHRoZSBzcGVjaWZpYyBj
YXNlIG9mIGEgWUFORyBsaXN0LCB3aXRoIGFuIGluc3RhbmNlLWlkZW50aWZpZXIgYXMgYSBrZXku
DQoNClJGQzgwNDAsIHNlY3Rpb24gMy41LjMsIHNwZWNpZmllcyB0aGUgZm9sbG93aW5nOg0KDQog
ICBJZiBhIGRhdGEgbm9kZSBpbiB0aGUgcGF0aCBleHByZXNzaW9uIGlzIGEgWUFORyBsaXN0IG5v
ZGUsIHRoZW4gdGhlDQoNCiAgIGtleSB2YWx1ZXMgZm9yIHRoZSBsaXN0IChpZiBhbnkpIE1VU1Qg
YmUgZW5jb2RlZCBhY2NvcmRpbmcgdG8gdGhlDQoNCiAgIGZvbGxvd2luZyBydWxlczoNCg0KLi4u
Lg0KDQogICBvICBUaGUga2V5IHZhbHVlIGlzIHNwZWNpZmllZCBhcyBhIHN0cmluZywgdXNpbmcg
dGhlIGNhbm9uaWNhbA0KDQogICAgICByZXByZXNlbnRhdGlvbiBmb3IgdGhlIFlBTkcgZGF0YSB0
eXBlLiAgQW55IHJlc2VydmVkIGNoYXJhY3RlcnMNCg0KICAgICAgTVVTVCBiZSBwZXJjZW50LWVu
Y29kZWQsIGFjY29yZGluZyB0byBTZWN0aW9ucyAyLjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL3JmYzgwNDAjc2VjdGlvbi0yLjE+IGFuZCAyLjU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL3JmYzgwNDAjc2VjdGlvbi0yLjU+IG9mDQoNCiAgICAgIFtSRkMzOTg2PGh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9yZmMzOTg2Pl0uICBUaGUgY29tbWEgKCIsIikgY2hhcmFjdGVyIE1V
U1QgYmUgcGVyY2VudC1lbmNvZGVkIGlmDQoNCiAgICAgIGl0IGlzIHByZXNlbnQgaW4gdGhlIGtl
eSB2YWx1ZS4NCkZvciBhbiBpbnN0YW5jZS1pZGVudGlmaWVyLCBSRkM3OTUwLCBzZWN0aW9uIDku
MTMuMywgc3BlY2lmaWVzIHRoYXQ6DQoNCiAgIFNpbmNlIHRoZSBsZXhpY2FsIGZvcm0gZGVwZW5k
cyBvbiB0aGUgWE1MIGNvbnRleHQgaW4gd2hpY2ggdGhlIHZhbHVlDQoNCiAgIG9jY3VycywgdGhp
cyB0eXBlIGRvZXMgbm90IGhhdmUgYSBjYW5vbmljYWwgZm9ybS4NCkluIHRoZSBleGFtcGxlIHBy
b3ZpZGVkIGJlbG93LCBJIGhhdmUgdXNlZCBSRkM3OTUxLCBzZWN0aW9uIDYuMTEsIHRoYXQgIGRl
ZmluZXMgaG93DQphbiAiaW5zdGFuY2UtaWRlbnRpZmllciIgdmFsdWUgaXMgZW5jb2RlZCBhIHN0
cmluZy4NCg0KSXMgdGhpcyBhIGNvcnJlY3QgYXBwcm9hY2g/IENhbiBhbnlvbmUgY29uZmlybT8N
Cg0KQmVzdCBSZWdhcmRzDQpZdmVzDQpPbiAyOC0wOC0xOCAxNTowMiwgQmVhdXZpbGxlLCBZdmVz
IChOb2tpYSAtIEJFL0FudHdlcnApIHdyb3RlOg0KDQpIaSBBbGwsDQoNCiBHaXZlbiB0aGUgZm9s
bG93aW5nIGxpc3QgaW4gYSBkdW1teSBtb2R1bGUgY2FsbGVkICJkaXNhYmxlLWFsYXJtcyI6DQoN
CiAgICAgbGlzdCBkaXNhYmxlLWFsYXJtIHsNCg0KICAgICAgICAga2V5ICJyZXNvdXJjZSI7DQoN
CiAgICAgICAgIGxlYWYgcmVzb3VyY2Ugew0KDQogICAgICAgICAgICAgdHlwZSBpbnN0YW5jZS1p
ZGVudGlmaWVyOw0KDQogICAgICAgICB9DQoNCiAgICAgICAgIGxlYWYgZGlzYWJsZSB7DQoNCiAg
ICAgICAgICAgICB0eXBlIGJvb2xlYW47DQoNCiAgICAgICAgIH0NCg0KICAgICB9DQoNCkFuZCBh
c3N1bWluZyB0aGF0IGFuIGVudHJ5IGV4aXN0cyBpbiB0aGF0IGxpc3QgZm9yIGEgcmVzb3VyY2Ug
cmVmZXJyaW5nIHRvIGFuIGludGVyZmFjZSBuYW1lZCAncG9ydCcgaW4gdGhlICJpZXRmLWludGVy
ZmFjZXMiIG1vZHVsZSBvZiBSRkMtNzMzMi4NCg0KSG93IGRvIEkgYnVpbGQgYSBSRVNUQ09ORiBH
RVQgcmVxdWVzdCBmb3IgdGhhdCBlbnRyeT8NCg0KV2lsbCBpdCBiZToNCg0KICAgICAgR0VUIC9y
ZXN0Y29uZi9kYXRhL2Rpc2FibGUtYWxhcm1zOmRpc2FibGUtYWxhcm09L2lldGYtaW50ZXJmYWNl
czppbnRlcmZhY2VzL2ludGVyZmFjZVtuYW1lPSdwb3J0J10gSFRUUC8xLjENCg0KICAgICAgSG9z
dDogZXhhbXBsZS5jb20NCg0KICAgICAgQWNjZXB0OiBhcHBsaWNhdGlvbi95YW5nLWRhdGEreG1s
DQpJIGhhdmUgbm90IGVuY29kZWQgdGhlIFVSTCBhYm92ZSBmb3IgcmVhZGFiaWxpdHkuIEkgdW5k
ZXJzdGFuZCB0aGF0IGl0IHNob3VsZCBiZSBzb21ldGhpbmcgbGlrZToNCg0KICAvcmVzdGNvbmYv
ZGF0YS9kaXNhYmxlLWFsYXJtczpkaXNhYmxlLWFsYXJtPSUyRmlldGYtaW50ZXJmYWNlcyUzQWlu
dGVyZmFjZXMlMkZpbnRlcmZhY2VbbmFtZSUzRCdwb3J0J10NCklmIHRoaXMgaXMgbm90IGNvcnJl
Y3QsIHdoYXQgc2hvdWxkIGJlIHByb3ZpZGVkIGluIHRoZSBVUkw/DQoNCll2ZXMNCg0KDQoNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KTmV0Y29u
ZiBtYWlsaW5nIGxpc3QNCg0KTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9y
Zz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN
Cgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN
Cgljb2xvcjpibGFjazt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1p
bHk65a6L5L2TO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+
5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi
SFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6
YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw
bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE
O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt
c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0
Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u
MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv
eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg
djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh
cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0
ZSIgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHRoaW5rIFJFU1RD
T05GIGNhbiB0cmFuc2xhdGUgcmVzb3VyY2UgaW50byBwb3J0IGluc3RhbmNlIGRlZmluZWQgaW4g
aWV0Zi1pbnRlcmZhY2VzIGF1dG9tYXRpY2FsbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5UaGUgY29ycmVjdCBSRVNUQ09ORiByZXF1ZXN0IGlzOjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5HRVQgL3Jlc3Rjb25mL2RhdGEvZGlzYWJsZS1hbGFybXM6ZGlz
YWJsZS1hbGFybS9yZXNvdXJjZT14eHggJm5ic3A7SFRUUC8xLjE8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSG9zdDogZXhhbXBsZS5j
b208bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgQWNjZXB0OiBhcHBsaWNhdGlvbi95YW5nLWRhdGEmIzQzO3htbDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPklmIHlvdSBsaW5rIHJlc291cmNlIHdpdGggcG9ydCBpbnRlcmZhY2Ug
ZGVmaW5lZCBpbiBpZXRmLWludGVyZmFjZXMgbW9kdWxlcywgeHh4IHNob3VsZCBwcm9iYWJseSBi
ZSByZXBsYWNlZCBieTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRoZSBwYXRoIHRvIHRo
ZSBwb3J0IGludGVyZmFjZSwgZS5nLiw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiA8L3NwYW4+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5z
b21ldGhpbmcgbGlrZSAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2VbbmFtZT0ncG9ydCddLyBp
ZjppZkluT2N0ZXRzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PnByb2JhYmx5IGJvdGggbW9kdWxlcyBuYW1lc3BhY2Ugc2hvdWxkIGJlIGRlY2xhcmVkIHNvbWV3
aGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVFpbjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0
ZXh0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4g
TmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10NCjwvc3Bhbj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij7ku6PooaggPC9zcGFu
PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2lu
ZG93dGV4dCI+QmVhdXZpbGxlLCBZdmVzIChOb2tpYSAtIEJFL0FudHdlcnApPGJyPg0KPC9zcGFu
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPuWPkemA
geaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPiAyMDE4PC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPuW5tDxz
cGFuIGxhbmc9IkVOLVVTIj45PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4xNDwvc3Bhbj7m
l6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMjI6MDA8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNw
YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gbmV0Y29uZkBp
ZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48
L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW05ldGNvbmZdIFJFU1RDT05GIFVSTCBmb3IgYSBs
aXN0IHdpdGggYW4gaW5zdGFuY2UtaWRlbnRpZmllciBhcyBhIGtleTxvOnA+PC9vOnA+PC9zcGFu
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9
IkVOLVVTIj5IZWxsbyBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i
RU4tVVMiPkkgYW0gbG9va2luZyBhdCBob3cgdG8gZW5jb2RlIGEgZGF0YSByZXNvdXJjZSBpZGVu
dGlmaWVycyBpbiBSRVNUQ09ORiByZXF1ZXN0IFVSSS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cD48c3BhbiBsYW5nPSJFTi1VUyI+SSBhbSBsb29raW5nIGF0IHRoZSBzcGVjaWZpYyBjYXNlIG9m
IGEgWUFORyBsaXN0LCB3aXRoIGFuIGluc3RhbmNlLWlkZW50aWZpZXIgYXMgYSBrZXkuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPlJGQzgwNDAsIHNlY3Rpb24g
My41LjMsIHNwZWNpZmllcyB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
cmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBJZiBhIGRhdGEgbm9kZSBpbiB0aGUg
cGF0aCBleHByZXNzaW9uIGlzIGEgWUFORyBsaXN0IG5vZGUsIHRoZW4gdGhlPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsga2V5IHZh
bHVlcyBmb3IgdGhlIGxpc3QgKGlmIGFueSkgTVVTVCBiZSBlbmNvZGVkIGFjY29yZGluZyB0byB0
aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw
OyZuYnNwOyBmb2xsb3dpbmcgcnVsZXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkVOLVVTIj4uLi4uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7byZuYnNwOyBUaGUga2V5IHZhbHVlIGlz
IHNwZWNpZmllZCBhcyBhIHN0cmluZywgPHU+dXNpbmcgdGhlIGNhbm9uaWNhbDxvOnA+PC9vOnA+
PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyA8dT5yZXByZXNlbnRhdGlvbiBmb3IgdGhlIFlBTkcgZGF0YSB0eXBl
PC91Pi4mbmJzcDsgQW55IHJlc2VydmVkIGNoYXJhY3RlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBNVVNUIGJlIHBlcmNlbnQtZW5jb2RlZCwgYWNjb3JkaW5nIHRvIFNlY3Rpb25zIDxhIGhyZWY9
Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDQwI3NlY3Rpb24tMi4xIj4yLjE8L2E+
IGFuZCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODA0MCNzZWN0aW9u
LTIuNSI+Mi41PC9hPiBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFs8YSBocmVmPSJodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzk4NiIgdGl0bGU9IiZxdW90O1VuaWZvcm0gUmVzb3Vy
Y2UgSWRlbnRpZmllciAoVVJJKTogR2VuZXJpYyBTeW50YXgmcXVvdDsiPlJGQzM5ODY8L2E+XS4m
bmJzcDsgVGhlIGNvbW1hICgmcXVvdDssJnF1b3Q7KSBjaGFyYWN0ZXIgTVVTVCBiZSBwZXJjZW50
LWVuY29kZWQgaWY8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t
VVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpdCBpcyBwcmVzZW50IGluIHRoZSBr
ZXkgdmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIGFuIGluc3RhbmNlLWlkZW50aWZpZXIsIFJGQzc5NTAsIHNl
Y3Rpb24gOS4xMy4zLCBzcGVjaWZpZXMgdGhhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJl
PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgU2luY2UgdGhlIGxleGljYWwgZm9ybSBk
ZXBlbmRzIG9uIHRoZSBYTUwgY29udGV4dCBpbiB3aGljaCB0aGUgdmFsdWU8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBvY2N1cnMs
IDx1PnRoaXMgdHlwZSBkb2VzIG5vdCBoYXZlIGEgY2Fub25pY2FsIGZvcm08L3U+LjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0
b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SW4gdGhlIGV4YW1wbGUgcHJvdmlkZWQgYmVs
b3csIEkgaGF2ZSB1c2VkIFJGQzc5NTEsIHNlY3Rpb24gNi4xMSwgdGhhdCZuYnNwOyBkZWZpbmVz
IGhvdw0KPGJyPg0KYW4gJnF1b3Q7aW5zdGFuY2UtaWRlbnRpZmllciZxdW90OyB2YWx1ZSBpcyBl
bmNvZGVkIGEgc3RyaW5nLjxicj4NCjxicj4NCklzIHRoaXMgYSBjb3JyZWN0IGFwcHJvYWNoPyBD
YW4gYW55b25lIGNvbmZpcm0/PGJyPg0KPGJyPg0KQmVzdCBSZWdhcmRzPGJyPg0KWXZlczxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyI+T24gMjgtMDgtMTggMTU6MDIsIEJlYXV2aWxsZSwgWXZlcyAoTm9raWEgLSBCRS9B
bnR3ZXJwKSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHA+PHNwYW4g
bGFuZz0iRU4tVVMiPkhpIEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5n
PSJFTi1VUyI+Jm5ic3A7R2l2ZW4gdGhlIGZvbGxvd2luZyBsaXN0IGluIGEgZHVtbXkgbW9kdWxl
IGNhbGxlZCAmcXVvdDtkaXNhYmxlLWFsYXJtcyZxdW90Ozo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cHJlPjx0dD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxp
c3QgZGlzYWJsZS1hbGFybSB7PG86cD48L286cD48L3NwYW4+PC90dD48L3ByZT4NCjxwcmU+PHR0
PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsga2V5ICZxdW90O3Jlc291cmNlJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwv
dHQ+PC9wcmU+DQo8cHJlPjx0dD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgcmVzb3VyY2UgezxvOnA+PC9vOnA+
PC9zcGFuPjwvdHQ+PC9wcmU+DQo8cHJlPjx0dD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHR5cGUgaW5zdGFuY2UtaWRlbnRpZmllcjs8bzpwPjwvbzpwPjwvc3Bhbj48L3R0Pjwv
cHJlPg0KPHByZT48dHQ+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC90dD48L3ByZT4N
CjxwcmU+PHR0PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBkaXNhYmxlIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3R0
PjwvcHJlPg0KPHByZT48dHQ+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBl
IGJvb2xlYW47PG86cD48L286cD48L3NwYW4+PC90dD48L3ByZT4NCjxwcmU+PHR0PjxzcGFuIGxh
bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvdHQ+PC9wcmU+DQo8cHJlPjx0dD48c3BhbiBsYW5nPSJF
Ti1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PC90dD48c3BhbiBsYW5nPSJF
Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+QW5k
IGFzc3VtaW5nIHRoYXQgYW4gZW50cnkgZXhpc3RzIGluIHRoYXQgbGlzdCBmb3IgYSByZXNvdXJj
ZSByZWZlcnJpbmcgdG8gYW4gaW50ZXJmYWNlIG5hbWVkICdwb3J0JyBpbiB0aGUgJnF1b3Q7aWV0
Zi1pbnRlcmZhY2VzJnF1b3Q7IG1vZHVsZSBvZiBSRkMtNzMzMi48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+SG93IGRvIEkgYnVpbGQgYSBSRVNUQ09ORiBHRVQg
cmVxdWVzdCBmb3IgdGhhdCBlbnRyeT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBs
YW5nPSJFTi1VUyI+V2lsbCBpdCBiZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFu
IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR0VUIC9yZXN0Y29u
Zi9kYXRhL2Rpc2FibGUtYWxhcm1zOmRpc2FibGUtYWxhcm09L2lldGYtaW50ZXJmYWNlczppbnRl
cmZhY2VzL2ludGVyZmFjZVtuYW1lPSdwb3J0J10gSFRUUC8xLjE8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBIb3N0OiBleGFtcGxlLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFjY2VwdDogYXBw
bGljYXRpb24veWFuZy1kYXRhJiM0Mzt4bWw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGhhdmUgbm90IGVuY29kZWQgdGhl
IFVSTCBhYm92ZSBmb3IgcmVhZGFiaWxpdHkuIEkgdW5kZXJzdGFuZCB0aGF0IGl0IHNob3VsZCBi
ZSBzb21ldGhpbmcgbGlrZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9
IkVOLVVTIj4mbmJzcDsgL3Jlc3Rjb25mL2RhdGEvZGlzYWJsZS1hbGFybXM6ZGlzYWJsZS1hbGFy
bT0lMkZpZXRmLWludGVyZmFjZXMlM0FpbnRlcmZhY2VzJTJGaW50ZXJmYWNlW25hbWUlM0QncG9y
dCddPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyI+SWYgdGhpcyBpcyBub3QgY29ycmVjdCwgd2hhdCBzaG91bGQgYmUgcHJvdmlk
ZWQgaW4gdGhlIFVSTD88YnI+DQo8YnI+DQpZdmVzPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPk5ldGNvbmYgbWFpbGluZyBsaXN0PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86
TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_B8F9A780D330094D99AF023C5877DABA9B0438F6nkgeml513mbxchi_--


From nobody Mon Sep 17 07:38:26 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406C4128CF3 for ; Mon, 17 Sep 2018 07:38:25 -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 VP0AyNr8MWax for ; Mon, 17 Sep 2018 07:38:23 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BEB75127332 for ; Mon, 17 Sep 2018 07:38:22 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id D12611AE0311; Mon, 17 Sep 2018 16:38:19 +0200 (CEST)
Date: Mon, 17 Sep 2018 16:38:19 +0200 (CEST)
Message-Id: <20180917.163819.1278530557866964677.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: balazs.kovacs@ericsson.com, balazs.lengyel@ericsson.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1F126D9A-775C-4590-A645-6529C3066C14@juniper.net>
References: <185C7E6D-7EF1-4FFE-9A9B-74BA7E16D946@juniper.net> <20180911.095334.2041631968993039535.mbj@tail-f.com> <1F126D9A-775C-4590-A645-6529C3066C14@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Sep 2018 14:38:25 -0000

S2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiANCj4gDQo+ID4+IFRo
ZXJlIGFyZSB0d28gc29sdXRpb25zIGJlaW5nIGRpc2N1c3NlZCBoZXJlLiAgDQo+ID4+IA0KPiA+
PiBUaGUgZmlyc3QgcmVnYXJkcyBob3cgdG8gZW5hYmxlIGEgY2VydGlmaWNhdGUgdG8gYmUgY29u
ZmlndXJlZCBmb3IgYSBrZXkNCj4gPj4gaW4gPG9wZXJhdGlvbmFsPiAoZS5nLiwgYW4gTERldklE
IGNlcnQgZm9yIGEgcHJlZXhpc3Rpbmcga2V5KS4gIEJvdGgNCj4gPj4gc29sdXRpb24gKEEpIGFu
ZCAoQykgZ2l2ZSB1cyB0aGlzIC0gYSBsYSBSRkMgODM0MiBTZWN0aW9uIEMuMy4yLg0KPiA+PiAN
Cj4gPj4gVGhlIHNlY29uZCBpcyBob3cgdG8gZGVsZXRlIGEgImhpZGRlbiBrZXkiIGNyZWF0ZWQg
YnkgYSBjbGllbnQgKG5vdGUgaGVyZQ0KPiA+PiB0aGF0IEknbSBkaXN0aW5ndWlzaGluZyB0aGlz
IGNhc2UgZnJvbSBoaWRkZW4ga2V5cyBub3QgY3JlYXRlZCBieSBhIGNsaWVudCwNCj4gPj4gaS5l
LiwgaW4gPG9wZXJhdGlvbmFsPiwgd2hpY2ggY2Fubm90IGJlIGRlbGV0ZWQpLiAgSGVyZSdzIHdo
ZXJlIHRoZSBpZGVhcw0KPiA+PiBkaXZlcmdlOg0KPiA+PiANCj4gPj4gICAtIHdpdGggKEEpLCB3
ZSBrZWVwIHRoZSAiZ2VuZXJhdGUiIGFjdGlvbiBvdXRzaWRlIHRoZSBsaXN0IGVudHJ5ICh0aHVz
DQo+ID4+ICAgICByZXN1bHRzIGFyZSBpbiA8b3BlcmF0aW9uYWw+LCBhbmQgYWRkIGEgbmV3ICJk
ZWxldGUtYXN5bW1ldHJpYy1rZXkiDQo+ID4+ICAgICBhY3Rpb24gaXMgbmVlZGVkLg0KPiA+PiAN
Cj4gPj4gICAtIHdpdGggKEMpLCB0aGUgYWN0aW9uIGlzIG1vdmVkIGluc2lkZSB0aGUgbGlzdCBl
bnRyeSwgdGh1cyB0aGUgbGlzdA0KPiA+PiAgICAgZW50cnkgbm9kZSBpdHNlbGYgaW4gPGludGVu
ZGVkPiwgYW5kIGhlbmNlIGNhbiBiZSByZW1vdmVkIGZyb20NCj4gPj4gICAgIDxpbnRlbmRlZD4g
dmlhIGEgbm9ybWFsIGNvbmZpZyBvcGVyYXRpb24gKG5vIHNwZWNpYWwgYWN0aW9uIG5lZWRlZCku
DQo+ID4+IA0KPiA+PiBJIGRvbid0IHNlZSBhbiBpc3N1ZSBjb25maWd1cmluZyBjZXJ0aWZpY2F0
ZXMgaW4gZWl0aGVyIGNhc2UuICBBcyBJIHdyb3RlDQo+ID4+IGFib3ZlLCBib3RoIHNvbHV0aW9u
IChBKSBhbmQgKEMpIGdpdmUgdXMgdGhpcy4gKEMpIHN0aWxsIGhhcyB0byBoYW5kbGUNCj4gPj4g
dGhlIGNhc2Ugd2hlcmUgdGhlIGtleSBpcyBpbiA8b3BlcmF0aW9uYWw+IHNhbWUgYXMgKEEpLiAg
V2l0aCAoQyksIGl0J3MNCj4gPj4gdGhlIDElIGNhc2UsIHdoZXJlYXMgd2l0aCAoQSkgaXTigJlz
IHRoZSAxMDAlIGNhc2UuDQo+ID4NCj4gPiBIb3cgY2FuIGEga2V5IGJlIGluIG9wZXJhdGlvbmFs
IGJ1dCBub3QgaW4gY29uZmlnIGluIChDKT8gIEkuZS4sIHdoYXQNCj4gPiBpcyB0aGUgMSUgY2Fz
ZT8NCj4gDQo+IE1heWJlIHRvbyBzdWJ0bGUsIGJ1dCBpbiBteSBmaXJzdCBwYXJhZ3JhcGggYWJv
dmUgc2FpZCAiZS5nLiwgYW4gTERldklEDQo+IGNlcnQgZm9yIGEgcHJlZXhpc3Rpbmcga2V5Ii4g
IEknbSByZWZlcnJpbmcgdG8gaG93LCBkdXJpbmcgbWFudWZhY3R1cmluZywNCj4gYSBwcml2YXRl
IGtleSBhbmQgYW4gYXNzb2NpYXRlZCBJRGV2SUQgY2VydGlmaWNhdGUgYXJlIGNyZWF0ZWQgYW5k
IGxvYWRlZA0KPiBvbnRvIHRoZSBkZXZpY2UuICBUaGlzIGtleSBhbmQgY2VydCBhcmUgaW1tdXRh
YmxlLCBidXQgYW5vdGhlciBjZXJ0IGNvdWxkDQo+IGJlIGxvYWRlZCBmb3IgdGhlIHNhbWUga2V5
LiAgVGhpcyBpcyB0aGUgc2NlbmFyaW8gY2FwdHVyZWQgaW4gdGhlIGV4YW1wbGUNCj4gaW46IGh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYta2V5c3RvcmUtMDUj
c2VjdGlvbi0zLjIuDQo+IChzZWFyY2ggZm9yICJ0cG0tcHJvdGVjdGVkLWtleSIpLiAgVGhpcyBp
cyB0aGUgMSUgY2FzZS4NCg0KT2suDQoNCj4gPj4gVGhleSBzZWVtIGNsb3NlLiAgRm9yIHRoZSBw
dXJwb3NlIG9mIGNyZWF0aW5nIGEga2V5LCAoQykgaXMgbW9yZQ0KPiA+PiBjb21wbGljYXRlZC4g
IEZvciB0aGUgcHVycG9zZSBvZiBkZWxldGluZyBhIGtleSwgKEMpIHNlZW1zIGVhc2llci4NCj4g
Pg0KPiA+IEZvciB0aGUgcHVycG9zZSBvZiBjcmVhdGluZyBhIGNlcnRpZmljYXRlIChBKSBpcyBt
b3JlIGNvbXBsaWNhdGVkLg0KPiANCj4gSG93IGlzIHRoYXQgc28/ICBBY3R1YWxseSwgaXQgc2Vl
bXMgdGhhdCAoQSkgYW5kIChDKSBhcmUgaWRlbnRpY2FsDQo+IGluIHRoaXMgcmVzcGVjdCwgZnJv
bSBhIHByb3RvY29sIHBlcnNwZWN0aXZlLiAgVGhlIG9ubHkgZGlmZmVyZW5jZQ0KPiBpcyBpbiB0
aGUgYmFja2VuZCwgd2hlcmUgaXQgdXNlcyB0aGUgUkZDIDgzNDIgU2VjdGlvbiBDLjMuMiBvdmVy
bGF5DQo+IGJlaGF2aW9yLg0KDQpXaXRoIChBKSwgb25jZSB5b3UgaGF2ZSBnZW5lcmF0ZWQgdGhl
IGtleSwgeW91IGZpcnN0IGhhdmUgdG8gY3JlYXRlDQp0aGUgY29uZmlnIGZvciBpdCwgdGhlbiBp
bnZva2UgdGhlIGFjdGlvbi4gIFdpdGggKEMpICg5OSUgb2YpIHRoZSBrZXlzDQphbHJlYWR5IGV4
aXN0IGluIHRoZSBjb25maWcsIHNvIHlvdSBjYW4ganVzdCBpbnZva2UgdGhlIGFjdGlvbi4NCg0K
VG8gc3VtbWFyaXplLCBBIGFuZCBDIGJvdGggZ2V0IHRoZSBqb2IgZG9uZS4gIFdoaWNoIG9uZSBp
cyBiZXR0ZXIgaXMNCnByb2JhYmx5IHN1YmplY3RpdmUuICBJIHRoaW5rIChDKSBpcyBtaWdodCBi
ZSBlYXNpZXIgdG8gdW5kZXJzdGFuZC4NCg0KPiA+IERlcGVuZGluZyBvbiB0aGUgYW5zd2VyIGFi
b3ZlLCAoQykgaGFzIHRoZSBhZHZhbnRhZ2UgdGhhdCByZWZlcmVuY2VzDQo+ID4gKGxlYWZyZWZz
KSB0byBhIGtleSBjYW4gYmUgcmVxdWlyZSBpbnN0YW5jZSB0cnVlLiAgV2l0aCAoQSkgdGhleSBo
YXZlDQo+ID4gdG8gYmUgcmVxdWlyZSBpbnN0YW5jZSBmYWxzZSwgc2luY2Ugc29tZSBrZXlzIG9u
bHkgZXhpc3RzIGluDQo+ID4gb3BlcmF0aW9uYWwsIHdoaWNoIG1lYW5zIHRoYXQgd2hlbmV2ZXIg
dGhlcmUgaXMgYSByZWZlcmVuY2UgdG8gYSBrZXksDQo+ID4gdGhhdCBtb2RlbCBhbmQgY29kZSBt
dXN0IGJlIGFibGUgdG8gaGFuZGxlIHRoZSBjYXNlIHRoYXQgdGhlIGtleQ0KPiA+IGRvZXNuJ3Qg
ZXhpc3QuDQo+IA0KPiBFdmVuIHdpdGggKEMpLCBzb21lIGtleXMgY2FuIGJlIGluIDxvcGVyYXRp
b25hbD4gLSB0aGUgMSUgY2FzZSwgcmlnaHQ/DQo+IA0KPiBZZXMsIGlmICphbGwqIGtleXMgaGFk
IGEgcHJlc2VuY2UgaW4gPGludGVuZGVkPiwgdGhlbiBsZWFyZWZzIHRvIGtleXMNCj4gY291bGQg
YmUgInJlcXVpcmUtaW5zdGFuY2UgdHJ1ZSIuDQoNClJpZ2h0Lg0KDQoNCi9tYXJ0aW4NCg==


From nobody Mon Sep 17 08:26:18 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56567130E95 for ; Mon, 17 Sep 2018 08:26:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_HIGH=-0.01, 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 uRuM6re0CULb for ; Mon, 17 Sep 2018 08:26:13 -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 24E84130E86 for ; Mon, 17 Sep 2018 08:26:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19414; q=dns/txt; s=iport; t=1537197972; x=1538407572; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kZ949GV5SSOlQxZO/65uv76+ojKKjGNPc04c7yszyFs=; b=TIhu+zGjlSrDU6xQfLUKFeHClcOLpXmzIxFNKXCRC9/fjrpnSJzoOr19 +r8zRjCJzN4qTo98xyJvo8eQ3lcISIIhVAu2XBFwxYVkfwot6q9zvVGzq KTrW1BbqmKYftXicu9OZUByV8CkKQfGRgglznKwwqGTHF90SZ9NFkDwRc w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEAAABx59b/4MNJK1RChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGBUIFeKmV/KAqDaIgVjCqCDYM9kw6BegsnhEUCF4NbITQ?= =?us-ascii?q?YAQMBAQIBAQJtHAyFOAEBAQECASMRQwIFCwIBCBUDAgIJHQICAjAVEAIEAQ0?= =?us-ascii?q?FCIJOTIF5CA+lKYEuigEFgQuJYheBQT+BEoMSgxsCgTYLAQElECOCR4JXAog?= =?us-ascii?q?zhS2OFU8JAoY7iVAfgUOHTIV+i12ISwIRFIElHTiBVXAVO4JshgGFFIU+b4s?= =?us-ascii?q?QgR+BHgEB?=
X-IronPort-AV: E=Sophos;i="5.53,385,1531785600"; d="scan'208";a="442981833"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Sep 2018 15:26:10 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w8HFQAqG024094 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Sep 2018 15:26:10 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 17 Sep 2018 11:26: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.1395.000; Mon, 17 Sep 2018 11:26:09 -0400
From: "Eric Voit (evoit)" 
To: "Reshad Rahman (rrahman)" , Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of subscribed-notifications-16
Thread-Index: AQHUSS2c6fWPWMQnpECqHWzj9l2RFqTpyY1wgALe1QCAACWmwIABR3cAgAB1RYD//78NEIAAdR+AgAXjfaA=
Date: Mon, 17 Sep 2018 15:26:09 +0000
Message-ID: <8c2e43f64a1d4b61a203245b69a18eea@XCH-RTP-013.cisco.com>
References: <20180912.113446.2017030234338816835.mbj@tail-f.com> <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com> <20180913.092134.395462318086733174.mbj@tail-f.com> <20180913.162117.1031242545011500593.mbj@tail-f.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.234]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.141, xch-rtp-001.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Sep 2018 15:26:16 -0000

SSBoYXZlIHBsYWNlZCBYcGF0aCBhbmQgc3VidHJlZSBleGFtcGxlcyBpbnRvIHNlY3Rpb24gQS40
IG9mOg0KaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvbm90aWYtbmV0Y29uZi9ibG9iL21h
c3Rlci9kcmFmdC1pZXRmLW5ldGNvbmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25zLTEyLnR4
dA0KDQpJIHdpbGwgdXBsb2FkIE5FVENPTkYtTm90aWYgdjEyIG9uY2UgY29tbWVudHMgb24gc3Vi
c2NyaWJlZC1ub3RpZmljYXRpb25zIHNsb3cuLi4NCg0KRXJpYw0KDQo+IEZyb206IFJlc2hhZCBS
YWhtYW4sIFNlcHRlbWJlciAxMywgMjAxOCAxOjI4IFBNDQo+IA0KPiBQU0kuDQo+IA0KPiDvu79P
biAyMDE4LTA5LTEzLCAxMTowOCBBTSwgIkVyaWMgVm9pdCAoZXZvaXQpIiA8ZXZvaXRAY2lzY28u
Y29tPiB3cm90ZToNCj4gDQo+ICAgICBIaSBNYXJ0aW4sDQo+IA0KPiAgICAgSSBhbSBmaW5lIHdp
dGggdGhlIHRocmVlIHRleHQgY2xhcmlmaWNhdGlvbnMgcHJvcG9zZWQsIGFuZCB3aWxsIGluY29y
cG9yYXRlLg0KPiBNb3JlIGluLWxpbmUuLi4NCj4gDQo+ICAgICA+IEZyb206IE1hcnRpbiBCam9y
a2x1bmQsIFNlcHRlbWJlciAxMywgMjAxOCAxMDoyMSBBTQ0KPiAgICAgPg0KPiAgICAgPiBIaSwN
Cj4gICAgID4NCj4gICAgID4gT25lIHByb2JsZW1hdGljIHRoaW5nIGJlbG93Lg0KPiAgICAgPg0K
PiAgICAgPiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQo+ICAgICA+
ID4gSGksDQo+ICAgICA+ID4NCj4gICAgID4gPiBUaGFuayB5b3UgZm9yIGFkZHJlc3NpbmcgbXkg
Y29tbWVudHMuICBNb3JlIGlubGluZS4NCj4gICAgID4gPg0KPiAgICAgPiA+DQo+ICAgICA+ID4g
IkVyaWMgVm9pdCAoZXZvaXQpIiA8ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCj4gICAgID4gPiA+
IEhpIE1hcnRpbiwNCj4gICAgID4gPiA+DQo+ICAgICA+ID4gPiBNdWNoIGluY29ycG9yYXRlZC4g
IExhdGVzdCBpcyBhdDoNCj4gICAgID4gPiA+IGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdn
L3JmYzUyNzdiaXMvYmxvYi9tYXN0ZXIvZHJhZnQtaWV0Zi1uZXRjDQo+ICAgICA+ID4gPiBvbmYt
c3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLTE3LnR4dA0KPiAgICAgPiA+ID4NCj4gICAgID4gPiA+
IFNwZWNpZmljIHJlc3BvbnNlcyBpbi1saW5lLi4uDQo+ICAgICA+ID4gPg0KPiAgICAgPiA+ID4g
PiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kLCBTZXB0ZW1iZXIgMTIsIDIwMTggNTozNSBBTQ0KPiAg
ICAgPiA+ID4gPg0KPiAgICAgPiA+ID4gPiAiRXJpYyBWb2l0IChldm9pdCkiIDxldm9pdEBjaXNj
by5jb20+IHdyb3RlOg0KPiAgICAgPiA+ID4gPiA+IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzIE1h
cnRpbiwgIHRob3VnaHRzIGluLWxpbmUuLi4NCj4gICAgID4gPiA+ID4gPg0KPiAgICAgPiA+ID4g
PiA+ID4gRnJvbTogTWFydGluIEJqb3JrbHVuZCwgU2VwdGVtYmVyIDEwLCAyMDE4IDE6NDIgUE0N
Cj4gICAgID4gPiA+ID4NCj4gICAgID4gPiA+ID4gWy4uLl0NCj4gICAgID4gPiA+ID4NCj4gICAg
ID4gPiA+ID4gPiA+IG8gIFNlY3Rpb24gMi4xDQo+ICAgICA+ID4gPiA+ID4gPg0KPiAgICAgPiA+
ID4gPiA+ID4gICBUaGUgdGV4dCBzYXlzOg0KPiAgICAgPiA+ID4gPiA+ID4NCj4gICAgID4gPiA+
ID4gPiA+ICAgICBJdCBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQNCj4gICAg
ID4gPiA+ID4gPiA+ICAgICB0byBpZGVudGlmeSBbLi4uXSBiKSBob3cgZXZlbnQgcmVjb3JkcyBh
cmUgZGVmaW5lZA0KPiAgICAgPiA+ID4gPiA+ID4NCj4gICAgID4gPiA+ID4gPiA+ICAgSXMgdGhp
cyByZWFsbHkgd2hhdCB3ZSB3YW50PyAgU2hvdWxkbid0IHRoaXMgZG9jdW1lbnQgc3BlY2lmeQ0K
PiB0aGF0DQo+ICAgICA+ID4gPiA+ID4gPiAgIGFuIGV2ZW50IHJlY29yZCBpcyBhbiBpbnN0YW5j
ZSBvZiBhIFlBTkcgIm5vdGlmaWNhdGlvbiINCj4gc3RhdGVtZW50Pw0KPiAgICAgPiA+ID4gPiA+
ID4gICBEbyB3ZSB3YW50IHRvIHN1cHBvcnQgZXZlbnQgcmVjb3JkcyB0aGF0IGFyZSBub3QgZGVm
aW5lZCBpbg0KPiBZQU5HPw0KPiAgICAgPiA+ID4gPiA+ID4NCj4gICAgID4gPiA+ID4gPiA+ICAg
VGhpcyB3YXMgZGlzY3Vzc2VkIGluIHRoZSB0aHJlYWQgImNvbW1lbnRzIG9uDQo+ICAgICA+ID4g
PiA+ID4gPiAgIGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMtMTIi
LCBhbmQgaXQgc2VlbXMgdGhhdA0KPiAgICAgPiA+ID4gPiA+ID4gICBub29uZSByZWFsbHkgaGF2
ZSBhbnkgdXNlIGNhc2UgZm9yIG5vbi1ZQU5HLWRlZmluZWQgZXZlbnQNCj4gcmVjb3JkcywNCj4g
ICAgID4gPiA+ID4gPiA+ICAgYWNjZXNzZWQgd2l0aCBZQU5HLWRlZmluZWQgb3BlcmF0aW9ucy4N
Cj4gICAgID4gPiA+ID4gPg0KPiAgICAgPiA+ID4gPiA+IFllcyB0aGlzIHdhcyBkaXNjdXNzZWQg
cHJldmlvdXNseS4gIE15IHJlYWRpbmcgd2FzIHRoYXQgb3RoZXJzDQo+ICAgICA+ID4gPiA+ID4g
d2FudGVkIHRvIHN1cHBvcnQgc3Vic2NyaXB0aW9uIHRvIG5vbi1ZQU5HIGV2ZW50cy4NCj4gICAg
ID4gPiA+ID4gPiBFLmcuLCBzZWUgQW5keSAmIFRpYW5yYW4ncyB0aG91Z2h0cyBpbg0KPiAgICAg
PiA+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtDQo+IGFyY2hpdmUvd2ViL25ldGNv
bmYvY3VycmVudC9tc2cxNDc2NC5oDQo+ICAgICA+ID4gPiA+ID4gdG1sDQo+ICAgICA+ID4gPiA+
DQo+ICAgICA+ID4gPiA+IFllcywgYnV0IHJlYWQgb24gaW4gdGhhdCB0aHJlYWQsIHNlZQ0KPiAg
ICAgPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLQ0KPiBhcmNoaXZlL3dlYi9uZXRj
b25mL2N1cnJlbnQvbXNnMTQ3NjYuaHRtDQo+ICAgICA+ID4gPiA+IGwNCj4gICAgID4gPiA+ID4g
Zm9yIGEgY2xhcmlmaWNhdGlvbi4NCj4gICAgID4gPiA+ID4NCj4gICAgID4gPiA+ID4gQUZBSUss
IG5vb25lIGhhcyBwcmVzZW50ZWQgYSB1c2UgY2FzZSBmb3Igc2VuZGluZyBub24tWUFORy0NCj4g
ZGVmaW5lZA0KPiAgICAgPiA+ID4gPiBkYXRhIGhlcmUuDQo+ICAgICA+ID4gPg0KPiAgICAgPiA+
ID4gQXMgYW55dGhpbmcgY2FuIGJlIFlBTkcgd3JhcHBlZCwgcGVyIHRoZSB0aHJlYWQgYWJvdmUu
ICBJIGFtIGZpbmUNCj4gICAgID4gPiA+IHdpdGggdGhpcy4NCj4gICAgID4gPiA+DQo+ICAgICA+
ID4gPiA+ID4gPiAgIEkgdGhpbmsgdGhhdCB0aGlzIGRvY3VtZW50IHNob3VsZCBzdGF0ZSB0aGF0
IGFuIGV2ZW50IHJlY29yZCBpcyBhbg0KPiAgICAgPiA+ID4gPiA+ID4gICBpbnN0YW5jZSBvZiBh
IFlBTkcgIm5vdGlmaWNhdGlvbiIgc3RhdGVtZW50LiAgSWYgbm90LCBpdCBpcyB1bmNsZWFyDQo+
ICAgICA+ID4gPiA+ID4gPiAgIGJvdGggaG93IHN1YnRyZWUveHBhdGggZmlsdGVycyBhbmQgeG1s
L2pzb24vLi4uIGVuY29kaW5ncyB3b3VsZA0KPiAgICAgPiB3b3JrLg0KPiAgICAgPiA+ID4gPiA+
DQo+ICAgICA+ID4gPiA+ID4gQXBwbHlpbmcgeHBhdGggZmlsdGVycyBhZ2FpbnN0IFhNTCBiYXNl
ZCBldmVudCByZWNvcmRzIHNlZW1zDQo+ICAgICA+ID4gPiA+ID4gdmlhYmxlIHRvIG1lLg0KPiAg
ICAgPiA+ID4gPg0KPiAgICAgPiA+ID4gPiBXaGVyZSBkb2VzIGl0IHNheSB0aGF0IGl0IGhhcyB0
byBiZSBYTUw/ICBXaGF0YWJvdXQgbWl4ZWQtY29udGVudD8NCj4gICAgID4gPiA+ID4gV2hhdCBp
ZiBzdWNoIGEgbm90aWZpY2F0aW9uIGlzIHNlbnQgd2hlbiB0aGUgZW5jb2RpbmcgaXMgSlNPTj8N
Cj4gICAgID4gPiA+ID4NCj4gICAgID4gPiA+ID4gSWYgeW91IHdhbnQgdG8gbWFrZSB0aGlzIHNw
ZWNpZmljYXRpb24gb3BlbiBmb3Igb3RoZXIgZGF0YQ0KPiAgICAgPiA+ID4gPiBtb2RlbGluZyBs
YW5ndWFnZXMsIEkgdGhpbmsgeW91IG5lZWQgdG8gY2FyZWZ1bGx5IGRlZmluZSBob3cgdGhhdA0K
PiAgICAgPiA+ID4gPiBpcyBzdXBwb3NlZCB0byB3b3JrOyBlc3NlbnRpYWxseSBzaW1pbGFyIHRv
IGhvdyB3ZSBoYW5kbGUNCj4gICAgID4gPiA+ID4gdHJhbnNwb3J0czsgd2UgaGF2ZSBhIHNldCBv
ZiByZXF1aXJlbWVudCBvbiB3aGF0IGEgdHJhbnNwb3J0DQo+ICAgICA+ID4gPiA+IGRvY3VtZW50
IG11c3QgZGVmaW5lLiAgSU1PIHRoaXMgaXMgc3VwZXIgY29tcGxpY2F0ZWQgYW5kIG92ZXJraWxs
Lg0KPiAgICAgPiA+ID4gPiBUaGlzIGRyYWZ0IGlzIGNvbXBsZXggZW5vdWdoLg0KPiAgICAgPiA+
ID4gPiBEb24ndCBhZGQgZXZlbiBtb3JlIGNvbXBsZXhpdHkuDQo+ICAgICA+ID4gPg0KPiAgICAg
PiA+ID4gSWYgeW91IGFyZSBqdXN0IHNheWluZyB0aGF0IHdlIGNhbiBwdXQgZXZlcnl0aGluZyBp
bnRvIGEgWUFORw0KPiAgICAgPiA+ID4gd3JhcHBlciwgdGhhdCBpcyBmaW5lIHdpdGggbWUuICBU
byBjbGFyaWZ5IHRoaXMsIEkgaGF2ZSB0d2Vha2VkIHRoZQ0KPiAgICAgPiA+ID4gZmlyc3Qgc2Vu
dGVuY2Ugb2YgU2VjdGlvbiAyLjEgdG86DQo+ICAgICA+ID4gPiAiQW4gZXZlbnQgc3RyZWFtIGlz
IGEgbmFtZWQgZW50aXR5IG9uIGEgcHVibGlzaGVyIHdoaWNoIGV4cG9zZXMgYQ0KPiAgICAgPiA+
ID4gY29udGludW91c2x5IHVwZGF0aW5nIHNldCBvZiBZQU5HIGVuY29kZWQgZXZlbnQgcmVjb3Jk
cy4iDQo+ICAgICA+ID4NCj4gICAgID4gPiBIb3dhYm91dDoNCj4gICAgID4gPg0KPiAgICAgPiA+
IE9MRDoNCj4gICAgID4gPg0KPiAgICAgPiA+ICAgIEFuIGV2ZW50IHN0cmVhbSBpcyBhIG5hbWVk
IGVudGl0eSBvbiBhIHB1Ymxpc2hlciB3aGljaCBleHBvc2VzIGENCj4gICAgID4gPiAgICBjb250
aW51b3VzbHkgdXBkYXRpbmcgc2V0IG9mIGV2ZW50IHJlY29yZHMuICBFYWNoIGV2ZW50IHN0cmVh
bSBpcw0KPiAgICAgPiA+ICAgIGF2YWlsYWJsZSBmb3Igc3Vic2NyaXB0aW9uLiAgSXQgaXMgb3V0
IG9mIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50DQo+ICAgICA+ID4gICAgdG8gaWRlbnRpZnkg
YSkgaG93IHN0cmVhbXMgYXJlIGRlZmluZWQgKG90aGVyIHRoYW4gdGhlIE5FVENPTkYNCj4gICAg
ID4gPiAgICBzdHJlYW0pLCBiKSBob3cgZXZlbnQgcmVjb3JkcyBhcmUgZGVmaW5lZC9nZW5lcmF0
ZWQsIGFuZCBjKSBob3cNCj4gZXZlbnQNCj4gICAgID4gPiAgICByZWNvcmRzIGFyZSBhc3NpZ25l
ZCB0byBzdHJlYW1zLg0KPiAgICAgPiA+DQo+ICAgICA+ID4gTkVXOg0KPiAgICAgPiA+DQo+ICAg
ICA+ID4gICAgQW4gZXZlbnQgc3RyZWFtIGlzIGEgbmFtZWQgZW50aXR5IG9uIGEgcHVibGlzaGVy
IHdoaWNoIGV4cG9zZXMgYQ0KPiAgICAgPiA+ICAgIGNvbnRpbnVvdXNseSB1cGRhdGluZyBzZXQg
b2YgZXZlbnQgcmVjb3Jkcy4gIEFuIGV2ZW50IHJlY29yZCBpcw0KPiAgICAgPiA+ICAgIGRlZmlu
ZWQgd2l0aCB0aGUgIm5vdGlmaWNhdGlvbiIgWUFORyBzdGF0ZW1lbnQuICBFYWNoIGV2ZW50IHN0
cmVhbSBpcw0KPiAgICAgPiA+ICAgIGF2YWlsYWJsZSBmb3Igc3Vic2NyaXB0aW9uLiAgSXQgaXMg
b3V0IG9mIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50DQo+ICAgICA+ID4gICAgdG8gaWRlbnRp
ZnkgYSkgaG93IHN0cmVhbXMgYXJlIGRlZmluZWQgKG90aGVyIHRoYW4gdGhlIE5FVENPTkYNCj4g
ICAgID4gPiAgICBzdHJlYW0pLCBiKSBob3cgZXZlbnQgcmVjb3JkcyBhcmUgZ2VuZXJhdGVkLCBh
bmQgYykgaG93IGV2ZW50DQo+ICAgICA+ID4gICAgcmVjb3JkcyBhcmUgYXNzaWduZWQgdG8gc3Ry
ZWFtcy4NCj4gICAgID4gPg0KPiAgICAgPiA+ID4gQW5kIEkgaGF2ZSB0d2Vha2VkIHRoZSBmaXJz
dCBzZW50ZW5jZSBvZiB0aGUgdGhpcmQgcGFyYWdyYXBoIHRvOg0KPiAgICAgPiA+ID4gIkFzIFlB
TkcgZW5jb2RlZCBldmVudCByZWNvcmRzIGFyZSBjcmVhdGVkIGJ5IGEgc3lzdGVtLC4uLiINCj4g
ICAgID4gPg0KPiAgICAgPiA+IEkgdGhpbmsgdGhlIG9yaWdpbmFsIHNlbnRlbmNlIGlzIGJldHRl
ci4NCj4gICAgID4gPg0KPiAgICAgPiA+IEFsc28sIHNvbWUgdHdlYWtzIGFyZSBuZWVkZWQgdG8g
dGhlIGZpbHRlciBsZWFmcyBpbiB0aGUgWUFORyBtb2R1bGU6DQo+ICAgICA+ID4NCj4gICAgID4g
PiBPTEQ6DQo+ICAgICA+ID4NCj4gICAgID4gPiAgICAgICAgICAgVGhlIHN1YnRyZWUgZmlsdGVy
IGlzIGFwcGxpZWQgdG8gdGhlIHJlcHJlc2VudGF0aW9uIG9mDQo+ICAgICA+ID4gICAgICAgICAg
IGluZGl2aWR1YWwsIGRlbGluZWF0ZWQgZXZlbnQgcmVjb3JkcyBhcyBjb250YWluZWQgd2l0aGlu
IHRoZQ0KPiAgICAgPiA+ICAgICAgICAgICBldmVudCBzdHJlYW0uICBGb3IgZXhhbXBsZSwgaWYg
dGhlIG5vdGlmaWNhdGlvbiBtZXNzYWdlDQo+ICAgICA+ID4gICAgICAgICAgIGNvbnRhaW5zIGFu
IGluc3RhbmNlIG9mIGEgbm90aWZpY2F0aW9uIGRlZmluZWQgaW4gWUFORywgdGhlbg0KPiAgICAg
PiA+ICAgICAgICAgICB0aGUgdG9wLWxldmVsIGVsZW1lbnQgaXMgdGhlIG5hbWUgb2YgdGhlIFlB
Tkcgbm90aWZpY2F0aW9uLg0KPiAgICAgPiA+DQo+ICAgICA+ID4gTkVXOg0KPiAgICAgPiA+DQo+
ICAgICA+ID4gICAgICAgICAgIFRoZSBzdWJ0cmVlIGZpbHRlciBpcyBhcHBsaWVkIHRvIHRoZSBy
ZXByZXNlbnRhdGlvbiBvZg0KPiAgICAgPiA+ICAgICAgICAgICBpbmRpdmlkdWFsLCBkZWxpbmVh
dGVkIGV2ZW50IHJlY29yZHMgYXMgY29udGFpbmVkIHdpdGhpbiB0aGUNCj4gICAgID4gPiAgICAg
ICAgICAgZXZlbnQgc3RyZWFtLiAgVGhlIHRvcC1sZXZlbCBlbGVtZW50IGluIHRoZSBldmVudCBy
ZWNvcmQgaXMNCj4gICAgID4gPiAgICAgICAgICAgdGhlIG5hbWUgb2YgdGhlIFlBTkcgbm90aWZp
Y2F0aW9uLg0KPiAgICAgPiA+DQo+ICAgICA+ID4gYW5kDQo+ICAgICA+ID4NCj4gICAgID4gPiBP
TEQ6DQo+ICAgICA+ID4NCj4gICAgID4gPiAgICAgICAgICAgIFRoZSBYUGF0aCBleHByZXNzaW9u
IGlzIGV2YWx1YXRlZCBvbiB0aGUgcmVwcmVzZW50YXRpb24gb2YNCj4gICAgID4gPiAgICAgICAg
ICAgIGluZGl2aWR1YWwsIGRlbGluZWF0ZWQgZXZlbnQgcmVjb3JkcyBhcyBjb250YWluZWQgd2l0
aGluDQo+ICAgICA+ID4gICAgICAgICAgICB0aGUgZXZlbnQgc3RyZWFtLiAgRm9yIGV4YW1wbGUs
IGlmIHRoZSBub3RpZmljYXRpb24gbWVzc2FnZQ0KPiAgICAgPiA+ICAgICAgICAgICAgY29udGFp
bnMgYW4gaW5zdGFuY2Ugb2YgYSBub3RpZmljYXRpb24gZGVmaW5lZCBpbiBZQU5HLA0KPiAgICAg
PiA+ICAgICAgICAgICAgdGhlbiB0aGUgdG9wLWxldmVsIGVsZW1lbnQgaXMgdGhlIG5hbWUgb2Yg
dGhlIFlBTkcNCj4gICAgID4gPiAgICAgICAgICAgIG5vdGlmaWNhdGlvbiwgYW5kIHRoZSByb290
IG5vZGUgaGFzIHRoaXMgdG9wLWxldmVsIGVsZW1lbnQNCj4gICAgID4gPiAgICAgICAgICAgIGFz
IHRoZSBvbmx5IGNoaWxkLg0KPiAgICAgPiA+DQo+ICAgICA+ID4gTkVXOg0KPiAgICAgPiA+DQo+
ICAgICA+ID4NCj4gICAgID4gPiAgICAgICAgICAgIFRoZSBYUGF0aCBleHByZXNzaW9uIGlzIGV2
YWx1YXRlZCBvbiB0aGUgcmVwcmVzZW50YXRpb24gb2YNCj4gICAgID4gPiAgICAgICAgICAgIGlu
ZGl2aWR1YWwsIGRlbGluZWF0ZWQgZXZlbnQgcmVjb3JkcyBhcyBjb250YWluZWQgd2l0aGluDQo+
ICAgICA+ID4gICAgICAgICAgICB0aGUgZXZlbnQgc3RyZWFtLiAgVGhlIHRvcC1sZXZlbCBlbGVt
ZW50IGluIHRoZSBldmVudA0KPiAgICAgPiA+ICAgICAgICAgICAgcmVjb3JkIGlzIHRoZSBuYW1l
IG9mIHRoZSBZQU5HIG5vdGlmaWNhdGlvbiwgYW5kIHRoZSByb290DQo+ICAgICA+ID4gICAgICAg
ICAgICBub2RlIGhhcyB0aGlzIHRvcC1sZXZlbCBlbGVtZW50IGFzIHRoZSBvbmx5IGNoaWxkLg0K
PiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiBUaGlzIHRleHQgaXMgcHJvYmxlbWF0aWMgYi9jIGl0
IGRvZXNuJ3Qgd29yayB3ZWxsIHdpdGggaW5saW5lIG5vdGlmaWNhdGlvbnMuDQo+ICAgICA+DQo+
ICAgICA+IENvbnNpZGVyIHRoZSBleGFtcGxlIGluIHNlY3Rpb24gNy4xNi4zIGluIFJGQyA3OTUw
Og0KPiAgICAgPg0KPiAgICAgPiAgICAgICAgY29udGFpbmVyIGludGVyZmFjZXMgew0KPiAgICAg
PiAgICAgICAgICBsaXN0IGludGVyZmFjZSB7DQo+ICAgICA+ICAgICAgICAgICAga2V5ICJuYW1l
IjsNCj4gICAgID4gICAgICAgICAgICBsZWFmIG5hbWUgew0KPiAgICAgPiAgICAgICAgICAgICAg
dHlwZSBzdHJpbmc7DQo+ICAgICA+ICAgICAgICAgICAgfQ0KPiAgICAgPiAgICAgICAgICAgIG5v
dGlmaWNhdGlvbiBpbnRlcmZhY2UtZW5hYmxlZCB7DQo+ICAgICA+ICAgICAgICAgICAgICBsZWFm
IGJ5LXVzZXIgew0KPiAgICAgPiAgICAgICAgICAgICAgICB0eXBlIHN0cmluZzsNCj4gICAgID4g
ICAgICAgICAgICAgIH0NCj4gICAgID4gICAgICAgICAgICB9DQo+ICAgICA+ICAgICAgICAgIH0N
Cj4gICAgID4gICAgICAgIH0NCj4gICAgID4NCj4gICAgID4gYW5kIGNvcnJlc3BvbmRpbmcgWE1M
IGV4YW1wbGU6DQo+ICAgICA+DQo+ICAgICA+ICAgICAgPG5vdGlmaWNhdGlvbg0KPiAgICAgPiAg
ICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246
MS4wIj4NCj4gICAgID4gICAgICAgIDxldmVudFRpbWU+MjAwOC0wNy0wOFQwMDowMTowMFo8L2V2
ZW50VGltZT4NCj4gICAgID4gICAgICAgIDxpbnRlcmZhY2VzIHhtbG5zPSJ1cm46ZXhhbXBsZTpp
bnRlcmZhY2UtbW9kdWxlIj4NCj4gICAgID4gICAgICAgICAgPGludGVyZmFjZT4NCj4gICAgID4g
ICAgICAgICAgICA8bmFtZT5ldGgxPC9uYW1lPg0KPiAgICAgPiAgICAgICAgICAgIDxpbnRlcmZh
Y2UtZW5hYmxlZD4NCj4gICAgID4gICAgICAgICAgICAgIDxieS11c2VyPmZyZWQ8L2J5LXVzZXI+
DQo+ICAgICA+ICAgICAgICAgICAgPC9pbnRlcmZhY2UtZW5hYmxlZD4NCj4gICAgID4gICAgICAg
ICAgPC9pbnRlcmZhY2U+DQo+ICAgICA+ICAgICAgICA8L2ludGVyZmFjZXM+DQo+ICAgICA+ICAg
ICAgPC9ub3RpZmljYXRpb24+DQo+ICAgICA+DQo+ICAgICA+IFdoYXQsIGluIHRoaXMgZXhhbXBs
ZSwgaXMgdGhlICJldmVudCByZWNvcmQiPyAgSSBhc3N1bWUgaXQgaXMgdGhpcw0KPiAgICAgPiBw
YXJ0Og0KPiAgICAgPg0KPiAgICAgPiAgICAgICAgPGludGVyZmFjZXMgeG1sbnM9InVybjpleGFt
cGxlOmludGVyZmFjZS1tb2R1bGUiPg0KPiAgICAgPiAgICAgICAgICA8aW50ZXJmYWNlPg0KPiAg
ICAgPiAgICAgICAgICAgIDxuYW1lPmV0aDE8L25hbWU+DQo+ICAgICA+ICAgICAgICAgICAgPGlu
dGVyZmFjZS1lbmFibGVkPg0KPiAgICAgPiAgICAgICAgICAgICAgPGJ5LXVzZXI+ZnJlZDwvYnkt
dXNlcj4NCj4gICAgID4gICAgICAgICAgICA8L2ludGVyZmFjZS1lbmFibGVkPg0KPiAgICAgPiAg
ICAgICAgICA8L2ludGVyZmFjZT4NCj4gICAgID4gICAgICAgIDwvaW50ZXJmYWNlcz4NCj4gICAg
ID4NCj4gICAgID4gQnV0IHRoZSBlbGVtZW50IHRoYXQgaXMgdGhlIG5hbWUgb2YgdGhlIFlBTkcg
bm90aWZpY2F0aW9uIGlzIHRoaXM6DQo+ICAgICA+DQo+ICAgICA+ICAgICAgICAgICAgPGludGVy
ZmFjZS1lbmFibGVkPg0KPiAgICAgPiAgICAgICAgICAgICAgPGJ5LXVzZXI+ZnJlZDwvYnktdXNl
cj4NCj4gICAgID4gICAgICAgICAgICA8L2ludGVyZmFjZS1lbmFibGVkPg0KPiAgICAgPg0KPiAg
ICAgPg0KPiAgICAgPiAoV2l0aCBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3Nh
Z2UsIHRoZSAiZXZlbnQgcmVjb3JkIg0KPiAgICAgPiB3b3VsZCBiZSBwbGFjZWQgaW4gdGhlIDxu
b3RpZmljYXRpb24tY29udGVudHM+IGFueWRhdGEpDQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+
IEEgcHJvYmxlbSBpcyB0aGF0IHRoZSBjb250YWlubWVudCBoaWVyYXJjaHkgaXMgZGVmaW5lZCBp
biBSRkMgNzk1MCBpbiB0aGUNCj4gWE1MDQo+ICAgICA+IGVuY29kaW5nIHRleHQuICBUaGVyZSBp
cyBubyB0ZXh0IGluIFJGQyA3OTUxIG9yIFJGQyA4MDQwIGZvciBob3cgdG8gZG8gdGhpcw0KPiBp
bg0KPiAgICAgPiBKU09OIGZvciBSRVNUQ09ORi4gIEl0IGlzIG5hdHVyYWwgdG8gZG8gYSBwdXJl
IEpTT04tdHJhbnNsYXRpb24gb2YgdGhlIFhNTA0KPiAgICAgPiBleGFtcGxlLCBidXQgdGhpcyBp
c24ndCBzcGVjaWZpZWQgYW55d2hlcmUuDQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+IFNvIEkg
cHJvcG9zZSB0aGUgZm9sbG93aW5nIHR3ZWFrZWQgY2hhbmdlczoNCj4gICAgID4NCj4gICAgID4N
Cj4gICAgID4gT0xEOg0KPiAgICAgPg0KPiAgICAgPiAgICBBbiBldmVudCBzdHJlYW0gaXMgYSBu
YW1lZCBlbnRpdHkgb24gYSBwdWJsaXNoZXIgd2hpY2ggZXhwb3NlcyBhDQo+ICAgICA+ICAgIGNv
bnRpbnVvdXNseSB1cGRhdGluZyBzZXQgb2YgZXZlbnQgcmVjb3Jkcy4gIEVhY2ggZXZlbnQgc3Ry
ZWFtIGlzDQo+ICAgICA+ICAgIGF2YWlsYWJsZSBmb3Igc3Vic2NyaXB0aW9uLiAgSXQgaXMgb3V0
IG9mIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50DQo+ICAgICA+ICAgIHRvIGlkZW50aWZ5IGEp
IGhvdyBzdHJlYW1zIGFyZSBkZWZpbmVkIChvdGhlciB0aGFuIHRoZSBORVRDT05GDQo+ICAgICA+
ICAgIHN0cmVhbSksIGIpIGhvdyBldmVudCByZWNvcmRzIGFyZSBkZWZpbmVkL2dlbmVyYXRlZCwg
YW5kIGMpIGhvdyBldmVudA0KPiAgICAgPiAgICByZWNvcmRzIGFyZSBhc3NpZ25lZCB0byBzdHJl
YW1zLg0KPiAgICAgPg0KPiAgICAgPiBORVc6DQo+ICAgICA+DQo+ICAgICA+ICAgIEFuIGV2ZW50
IHN0cmVhbSBpcyBhIG5hbWVkIGVudGl0eSBvbiBhIHB1Ymxpc2hlciB3aGljaCBleHBvc2VzIGEN
Cj4gICAgID4gICAgY29udGludW91c2x5IHVwZGF0aW5nIHNldCBvZiBldmVudCByZWNvcmRzLiAg
QW4gZXZlbnQgcmVjb3JkIGlzIGFuDQo+ICAgICA+ICAgIGludGFudGlhdGlvbiBvZiBhICJub3Rp
ZmljYXRpb24iIFlBTkcgc3RhdGVtZW50LiAgSWYgdGhlDQo+ICAgICA+ICAgICJub3RpZmljYXRp
b24iIGlzIGRlZmluZWQgYXMgYSBjaGlsZCB0byBhIGRhdGEgbm9kZSwgdGhlDQo+ICAgICA+ICAg
IGludGFudGlhdGlvbiBpbmNsdWRlcyB0aGUgaGllcmFyY2h5IG9mIG5vZGVzIHRoYXQgaWRlbnRp
ZmllcyB0aGUNCj4gICAgID4gICAgZGF0YSBub2RlIGluIHRoZSBkYXRhc3RvcmUgKHNlZSBTZWN0
aW9uIDcuMTYuMiBvZiBSRkMgNzk1MCkuICBFYWNoDQo+ICAgICA+ICAgIGV2ZW50IHN0cmVhbSBp
cyBhdmFpbGFibGUgZm9yIHN1YnNjcmlwdGlvbi4gIEl0IGlzIG91dCBvZiB0aGUgc2NvcGUNCj4g
ICAgID4gICAgb2YgdGhpcyBkb2N1bWVudCB0byBpZGVudGlmeSBhKSBob3cgc3RyZWFtcyBhcmUg
ZGVmaW5lZCAob3RoZXIgdGhhbg0KPiAgICAgPiAgICB0aGUgTkVUQ09ORiBzdHJlYW0pLCBiKSBo
b3cgZXZlbnQgcmVjb3JkcyBhcmUgZ2VuZXJhdGVkLCBhbmQgYykgaG93DQo+ICAgICA+ICAgIGV2
ZW50IHJlY29yZHMgYXJlIGFzc2lnbmVkIHRvIHN0cmVhbXMuDQo+ICAgICA+DQo+ICAgICA+DQo+
ICAgICA+IGFuZCBpbiB0aGUgWUFORyBtb2R1bGU6DQo+ICAgICA+DQo+ICAgICA+IE9MRDoNCj4g
ICAgID4NCj4gICAgID4gICAgICAgICAgIFRoZSBzdWJ0cmVlIGZpbHRlciBpcyBhcHBsaWVkIHRv
IHRoZSByZXByZXNlbnRhdGlvbiBvZg0KPiAgICAgPiAgICAgICAgICAgaW5kaXZpZHVhbCwgZGVs
aW5lYXRlZCBldmVudCByZWNvcmRzIGFzIGNvbnRhaW5lZCB3aXRoaW4gdGhlDQo+ICAgICA+ICAg
ICAgICAgICBldmVudCBzdHJlYW0uICBGb3IgZXhhbXBsZSwgaWYgdGhlIG5vdGlmaWNhdGlvbiBt
ZXNzYWdlDQo+ICAgICA+ICAgICAgICAgICBjb250YWlucyBhbiBpbnN0YW5jZSBvZiBhIG5vdGlm
aWNhdGlvbiBkZWZpbmVkIGluIFlBTkcsIHRoZW4NCj4gICAgID4gICAgICAgICAgIHRoZSB0b3At
bGV2ZWwgZWxlbWVudCBpcyB0aGUgbmFtZSBvZiB0aGUgWUFORyBub3RpZmljYXRpb24uDQo+ICAg
ICA+DQo+ICAgICA+IE5FVzoNCj4gICAgID4NCj4gICAgID4gICAgICAgICAgIFRoZSBzdWJ0cmVl
IGZpbHRlciBpcyBhcHBsaWVkIHRvIHRoZSByZXByZXNlbnRhdGlvbiBvZg0KPiAgICAgPiAgICAg
ICAgICAgaW5kaXZpZHVhbCwgZGVsaW5lYXRlZCBldmVudCByZWNvcmRzIGFzIGNvbnRhaW5lZCB3
aXRoaW4gdGhlDQo+ICAgICA+ICAgICAgICAgICBldmVudCBzdHJlYW0uDQo+ICAgICA+DQo+ICAg
ICA+IGFuZA0KPiAgICAgPg0KPiAgICAgPiBPTEQ6DQo+ICAgICA+DQo+ICAgICA+ICAgICAgICAg
ICAgVGhlIFhQYXRoIGV4cHJlc3Npb24gaXMgZXZhbHVhdGVkIG9uIHRoZSByZXByZXNlbnRhdGlv
biBvZg0KPiAgICAgPiAgICAgICAgICAgIGluZGl2aWR1YWwsIGRlbGluZWF0ZWQgZXZlbnQgcmVj
b3JkcyBhcyBjb250YWluZWQgd2l0aGluDQo+ICAgICA+ICAgICAgICAgICAgdGhlIGV2ZW50IHN0
cmVhbS4gIEZvciBleGFtcGxlLCBpZiB0aGUgbm90aWZpY2F0aW9uIG1lc3NhZ2UNCj4gICAgID4g
ICAgICAgICAgICBjb250YWlucyBhbiBpbnN0YW5jZSBvZiBhIG5vdGlmaWNhdGlvbiBkZWZpbmVk
IGluIFlBTkcsDQo+ICAgICA+ICAgICAgICAgICAgdGhlbiB0aGUgdG9wLWxldmVsIGVsZW1lbnQg
aXMgdGhlIG5hbWUgb2YgdGhlIFlBTkcNCj4gICAgID4gICAgICAgICAgICBub3RpZmljYXRpb24s
IGFuZCB0aGUgcm9vdCBub2RlIGhhcyB0aGlzIHRvcC1sZXZlbCBlbGVtZW50DQo+ICAgICA+ICAg
ICAgICAgICAgYXMgdGhlIG9ubHkgY2hpbGQuDQo+ICAgICA+DQo+ICAgICA+IE5FVzoNCj4gICAg
ID4NCj4gICAgID4NCj4gICAgID4gICAgICAgICAgICBUaGUgWFBhdGggZXhwcmVzc2lvbiBpcyBl
dmFsdWF0ZWQgb24gdGhlIHJlcHJlc2VudGF0aW9uIG9mDQo+ICAgICA+ICAgICAgICAgICAgaW5k
aXZpZHVhbCwgZGVsaW5lYXRlZCBldmVudCByZWNvcmRzIGFzIGNvbnRhaW5lZCB3aXRoaW4NCj4g
ICAgID4gICAgICAgICAgICB0aGUgZXZlbnQgc3RyZWFtLg0KPiAgICAgPg0KPiAgICAgPiA+IChJ
IHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB3aXRoIHNvbWUgZmlsdGVyaW5nIGV4YW1wbGVzLCBs
aWtlIGluDQo+ICAgICA+ID4gc2VjdGlvbiA1IG9mIFJGQyA1Mjc3LCBidXQgSSB0aGluayB5b3Ug
aGF2ZSBhbGwgZXhhbXBsZXMgaW4NCj4gICAgID4gPiBuZXRjb25mLW5vdGlmLCBzbyB0aGV5IHdv
dWxkIGdvIGludG8gdGhhdCBkcmFmdC4gIChyZS1yZWFkaW5nIGFuIG9sZA0KPiAgICAgPiA+IHRo
cmVhZCBJIGZvdW5kIHRoYXQgZXhhbXBsZXMgZm9yIGZpbHRlcnMgd2VyZSByZXF1ZXN0ZWQgYmVm
b3JlKSkuDQo+ICAgICA+DQo+ICAgICA+IEFuZCBJIHN0cm9uZ2x5IHRoaW5rIHRoYXQgd2Ugc2hv
dWxkIGFkZCBleGFtcGxlcyBpbiBhbiBhcHBlbmRpeCwgZXZlbg0KPiB0aG91Z2gNCj4gICAgID4g
dGhpcyBpcyBhIHByb3RvY29sIGFuZCBlbmNvZGluZyBuZXV0cmFsIGRvY3VtZW50LiAgTWF5YmUg
b25lIGV4YW1wbGUNCj4gd2l0aA0KPiAgICAgPiBORVRDT05GIFhNTCBhbmQgb25lIHdpdGggUkVT
VENPTkYgSlNPTi4gIE9uZSBleGFtcGxlIGNhbiBzaG93IGENCj4gICAgID4gc3VidHJlZSBmaWx0
ZXIgYW5kIGEgdG9wLWxldmVsIG5vdGlmLCBhbmQgdGhlIG90aGVyIGFuIFhQYXRoIGZpbHRlciB3
aXRoIGFuDQo+IGlubGluZQ0KPiAgICAgPiBub3RpZi4NCj4gDQo+ICAgICBXZSBoYXZlIHdvcmtl
ZCB2ZXJ5IGhhcmQgdG8ga2VlcCB0aGUgZG9jdW1lbnQgcHJvdG9jb2wgYWdub3N0aWMuICBFdmVu
DQo+IHRoZSBBcHBlbmRpeCBBIGV4YW1wbGUgcHJvdG9jb2wgZm9yIGNvbmZpZ3VyZWQgc3Vic2Ny
aXB0aW9ucyBpcyAnZm9vJy4NCj4gDQo+ICAgICBJZiB5b3UgYXJlIG9rIHdpdGggaXQsIEkgYW0g
Y29tcGxldGVseSBmaW5lIHdpdGggYWRkaW5nIHR3byBzdWNoIE5FVENPTkYNCj4gWE1MIGZpbHRl
cmluZyBleGFtcGxlcyBpbnRvIGEgbmV3IEFwcGVuZGl4IHNlY3Rpb24gQS40IGluIE5FVENPTkYt
Tm90aWYuDQo+IFBlcmhhcHMgUmVzaGFkIHdvdWxkIGJlIGFibGUgdG8gZG8gdGhlIHNhbWUgZm9y
IFJFU1RDT05GIEpTT04gd2l0aGluDQo+IFJFU1RDT05GLU5vdGlmLg0KPiANCj4gICAgIEVyaWMN
Cj4gDQo+ICAgICA8UlI+IFllcyAgaWYgaXQgZ2V0cyBhZGRlZCB0byBORVRDT05GLU5vdGlmLCBJ
IGFncmVlIHRvIGFkZCBzaW1pbGFyIGV4YW1wbGVzDQo+IHRwIFJFU1RDT05GLU5vdGlmLg0KPiAN
Cj4gUmVnYXJkcywNCj4gUmVzaGFkLg0KPiANCj4gICAgID4gL21hcnRpbg0KPiANCg0K


From nobody Mon Sep 17 09:23:41 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0268B130EC6 for ; Mon, 17 Sep 2018 09:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbwoSFxPlKxQ for ; Mon, 17 Sep 2018 09:23:28 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 0F6A2130EC4 for ; Mon, 17 Sep 2018 09:23:28 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id d7-v6so8748223lfa.5 for ; Mon, 17 Sep 2018 09:23:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=e/U4pK0XPmVMqFsrR/4+X8Jx0KA7dNYMAUd6/K1RiRc=; b=GoS7iW0j+90pHNYUpzso9QZZp7QLCq0RUvOhAvAZybPGGNqt9uEB7CPctYkpAmDPcG gw+W3NowhKZrVw0qB1faHJLLfJQvrxmV5VObJ/5VJ14w2XSFstNpYC/c0Li2nOCJbi3u UhSsolkIMc18gjjtLMqLgNJ2v2vvUpT7s3uezQpRTw5ElJBDn4NeTQOOnDn7/uOO3IIO kClL20TIn3xULCbiH5P/XhoEx0AxDCQFxnvAlYwqjzljor+SbRoKDQ73I6AN3BFWEbpX wWEeWeQRTc3/NjZzO8JxZVDqYXDT7hE9GkFVsVTGAD8nR90n1jMED8VpIABT0sL7sCnl kHSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=e/U4pK0XPmVMqFsrR/4+X8Jx0KA7dNYMAUd6/K1RiRc=; b=EbMe7JOw3I/2t1Xjs5nEcl0IwOPrvIzRFTQK/Gf5FEFchj1D/XpmzwICDg2vWad+WF aexi32rGaKoZOGZdEHdBHYtz/9yj3oE9ozDEb9Hmc5kTVScfC77ATwVIdyhdJtBA+wV0 vez3p2xKzjwXXbC83DPvk1Mkzg7hVBZbeVo+zJNe2haRcRFXILzvuXEQyPO9F+P35QaJ CQSKjEEMGzoDmGGfA/M09tjgaFTZSJ6MXghoqqyubetcun1CojsCLrHx+GHR7Ro2N+qE e7UZp8Y4IXggPqClhG5gjhBqlwQSIGuS2w7BYGaX4bC/gP0VIFIc+Ur1qabipGNFarpK h7wQ==
X-Gm-Message-State: APzg51DEO7Whb+2KdAZV3XGKcQm4b4M5gOnohJIQTuWMmUk4slC4p7lw RNEbN9BSIgTJGrcWKDqWBQRCQGcDolc1qX58MGzAcA==
X-Google-Smtp-Source: ANB0VdadN5njWPGUgA6YxX/sreL2CBts//XhyKRzJ7zSUDq0yAKc4Mmd8FsDefEWUP1B0NY8Sm8UcXONuEaTfB0/iYM=
X-Received: by 2002:a19:cf05:: with SMTP id f5-v6mr17569207lfg.73.1537201405294;  Mon, 17 Sep 2018 09:23:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:6a19:0:0:0:0:0 with HTTP; Mon, 17 Sep 2018 09:23:24 -0700 (PDT)
In-Reply-To: <20180914071445.ywfnizh4rnzbrs4f@anna.jacobs.jacobs-university.de>
References: <20180912.140109.1250692833398495223.mbj@tail-f.com>  <20180914.091120.602490077927092016.mbj@tail-f.com> <20180914071445.ywfnizh4rnzbrs4f@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Mon, 17 Sep 2018 09:23:24 -0700
Message-ID: 
To: Juergen Schoenwaelder , Martin Bjorklund ,  "Eric Voit (evoit)" , Netconf 
Content-Type: multipart/alternative; boundary="000000000000b60dd90576139736"
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Sep 2018 16:23:39 -0000

--000000000000b60dd90576139736
Content-Type: text/plain; charset="UTF-8"

On Fri, Sep 14, 2018 at 12:14 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Sep 14, 2018 at 09:11:20AM +0200, Martin Bjorklund wrote:
> > >
> > > > However, I think that for all RPC-based transport-protocols
> (currently
> > > > NETCONF and RESTCONF) it makes sense to have a common way to get the
> > > > notifications to be sent.
> > >
> > > Perhaps something will be needed for NETCONF.  But for configured
> > > RESTCONF subscriptions, RESTCONF-Notif has been assuming that RESTCONF
> > > not be used.  Instead raw HTTP2 with the Publisher being the HTTP
> > > client and the receiver the HTTP server seems cleaner.
> >
> > This has been pointed out before - the restconf-notif draft should
> > define *RESTCONF* mechanisms for subscribed notifications.
> >
> > If you want to define a new "notif-only" protocol that uses HTTP/2,
> > that should be done in a separate document.
> >
>
> +1
>


So how should this be fixed?
It seems this draft could be renamed (e.g., s/RESTCONF/HTTP2/) since it
does not use RESTCONF in any way.  I don't think RESTCONF notifications
are used very much, but I don't see why the same SSE delivery of the
 element
would not work (e.g., different resource to GET for establish-subscription
parameters)

The WG seems to refactor drafts a lot, only to end up with even more
unfinished work
than before.  We should learn to drop work that is not backed with lots of
active support
and reviews.



> /js
>

Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--000000000000b60dd90576139736
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, Sep 14, 2018 at 12:14 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Sep 14, 2018 at 09:11:20AM +0200, Martin Bj=
orklund wrote:

> > 

> > > However, I think that for all RPC-based transport-protocols =
(currently

> > > NETCONF and RESTCONF) it makes sense to have a common way to=
 get the

> > > notifications to be sent. 

> > 

> > Perhaps something will be needed for NETCONF.=C2=A0 But for confi=
gured

> > RESTCONF subscriptions, RESTCONF-Notif has been assuming that RES=
TCONF

> > not be used.=C2=A0 Instead raw HTTP2 with the Publisher being the=
 HTTP

> > client and the receiver the HTTP server seems cleaner.

> 

> This has been pointed out before - the restconf-notif draft should

> define *RESTCONF* mechanisms for subscribed notifications.

> 

> If you want to define a new "notif-only" protocol that uses =
HTTP/2,

> that should be done in a separate document.

>



+1


So how should this be=
 fixed?
It seems this draft could be renamed (e.g., s/RESTCONF/HT=
TP2/) since it
does not use RESTCONF in any way.=C2=A0 I don'=
t think RESTCONF notifications
are used very much, but I don'=
t see why the same SSE delivery of the <notification> element
would not work (e.g., different resource to GET for establish-subscripti=
on parameters)

The WG seems to refactor drafts a l=
ot, only to end up with even more unfinished work
than before.=C2=
=A0 We should learn to drop work that is not backed with lots of active sup=
port
and reviews.





/js

Andy
=C2=A0=




-- 

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>



_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--000000000000b60dd90576139736--


From nobody Mon Sep 17 10:26:01 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCECF130E5E for ; Mon, 17 Sep 2018 10:25:58 -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 MznjJ2g-W6Lo for ; Mon, 17 Sep 2018 10:25:57 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DB5E81274D0 for ; Mon, 17 Sep 2018 10:25:56 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 42DC31AE0311; Mon, 17 Sep 2018 19:25:54 +0200 (CEST)
Date: Mon, 17 Sep 2018 19:25:53 +0200 (CEST)
Message-Id: <20180917.192553.249647053760697085.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: j.schoenwaelder@jacobs-university.de, evoit@cisco.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20180914.091120.602490077927092016.mbj@tail-f.com> <20180914071445.ywfnizh4rnzbrs4f@anna.jacobs.jacobs-university.de> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Sep 2018 17:25:59 -0000

Andy Bierman  wrote:
> On Fri, Sep 14, 2018 at 12:14 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Fri, Sep 14, 2018 at 09:11:20AM +0200, Martin Bjorklund wrote:
> > > >
> > > > > However, I think that for all RPC-based transport-protocols
> > (currently
> > > > > NETCONF and RESTCONF) it makes sense to have a common way to get the
> > > > > notifications to be sent.
> > > >
> > > > Perhaps something will be needed for NETCONF.  But for configured
> > > > RESTCONF subscriptions, RESTCONF-Notif has been assuming that RESTCONF
> > > > not be used.  Instead raw HTTP2 with the Publisher being the HTTP
> > > > client and the receiver the HTTP server seems cleaner.
> > >
> > > This has been pointed out before - the restconf-notif draft should
> > > define *RESTCONF* mechanisms for subscribed notifications.
> > >
> > > If you want to define a new "notif-only" protocol that uses HTTP/2,
> > > that should be done in a separate document.
> > >
> >
> > +1
> >
> 
> 
> So how should this be fixed?
> It seems this draft could be renamed (e.g., s/RESTCONF/HTTP2/) since it
> does not use RESTCONF in any way.  I don't think RESTCONF notifications
> are used very much, but I don't see why the same SSE delivery of the
>  element
> would not work (e.g., different resource to GET for establish-subscription
> parameters)

Actually, the most recent version is more RESTCONF specific, and it
does in fact use SSE for notification delivery.  But there are some
issues... I'll start a new thread for this.


/martin


> The WG seems to refactor drafts a lot, only to end up with even more
> unfinished work
> than before.  We should learn to drop work that is not backed with lots of
> active support
> and reviews.
> 
> 
> 
> > /js
> >
> 
> Andy
> 
> 
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >


From nobody Mon Sep 17 10:45:22 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0633124BE5 for ; Mon, 17 Sep 2018 10:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 laDSvBre8xB0 for ; Mon, 17 Sep 2018 10:45:19 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 30AD21200D7 for ; Mon, 17 Sep 2018 10:45:19 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 54B551AE0311 for ; Mon, 17 Sep 2018 19:45:18 +0200 (CEST)
Date: Mon, 17 Sep 2018 19:45:18 +0200 (CEST)
Message-Id: <20180917.194518.233902533629875552.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Netconf] usage of HTTP in restconf-notif-07
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Sep 2018 17:45:21 -0000

Hi,

I think the -07 version is a step in the right direction for this
draft.  But I have a comment on the usage of HTTP/2.

I am not an expert at all in HTTP/2, but I wonder if the way this
draft uses it is correct.  The draft is very short on details, but
essentially says that the client POSTs to the "uri" that the server
returns (probably w/o a body?), and then that the server sends
individual notifications in DATA frames.  Is this really legal?  RFC
7540, section 8 says:

   HTTP/2 is intended to be as compatible as possible with current uses
   of HTTP.  This means that, from the application perspective, the
   features of the protocol are largely unchanged.  To achieve this, all
   request and response semantics are preserved, although the syntax of
   conveying those semantics has changed.

It seems to me that the restconf-notif draft violates this paragraph.

In fact, it seems that what the draft tries to do is more or less
exactly the same as SSE, except w/o the details, e.g., it doesn't
specify the content-type.

It also seems to me (after some googling) that it is perfectly fine to
use standard SSE with HTTP/2, and that's what people are using to
deliver server-generated events/notifs to clients with HTTP/2.

So, this draft should probably not mention HTTP/2 at all, but instead
just specify the semantics of the "uri" resource and how a client can
POST to it to get SSE going.  The draft should the refer to section
6.4 of RFC 8040 for how notifications are sent from this resource.


/martin


From nobody Mon Sep 17 11:24:09 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40148130EC3 for ; Mon, 17 Sep 2018 11:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_MED=-0.01, 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 ifcmm1extd7Q for ; Mon, 17 Sep 2018 11:24:04 -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 08850130E72 for ; Mon, 17 Sep 2018 11:24:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3412; q=dns/txt; s=iport; t=1537208643; x=1538418243; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BkX37451ICdsf+lirOzMqNHS9Y9UzZeqnhpYYWlNNn0=; b=BtsXsXlCyCQtfnyjn25TLkafY2rDycmWqB2hfAgcUTqF0L+mV19IGnl2 yq6PgyyIC9Ee+3qrkX5O31tP/vbE4plSOxN372/i9V3xwyhgN7TXjDkXO iVlv37bg1GzxpQDUBbj6oNbmAIABuR66bC9Byfm9snSAv1ePLB07e8iqQ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAACA8J9b/51dJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYFSggZlfygKg2iUQYVKkw6BegsYCwmDekYCF4NbITYWAQM?= =?us-ascii?q?BAQIBAQJtHAyFOQIBAwEBIRE3AxsCAQgODAImAgICJQsVEAIEARKDIQGCAQ+?= =?us-ascii?q?lc4EuhHOFEAWBC4liF4FBP4E5H4IXNYMbAQGBSxYXI4JHMYImAogllB8JApA?= =?us-ascii?q?TF48NlCgCERSBJSQCLyeBLnAVOyoBgkGLFYU+b4EWixUBgR0BAQ?=
X-IronPort-AV: E=Sophos;i="5.53,386,1531785600"; d="scan'208";a="451436722"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Sep 2018 18:24:02 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w8HIO2nM009454 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Sep 2018 18:24:03 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 17 Sep 2018 13:24:02 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Mon, 17 Sep 2018 13:24:02 -0500
From: "Reshad Rahman (rrahman)" 
To: Martin Bjorklund , "netconf@ietf.org" 
Thread-Topic: [Netconf] usage of HTTP in restconf-notif-07
Thread-Index: AQHUTq5E5QI/GULjdk2n1HliAfS8A6T02p2A
Date: Mon, 17 Sep 2018 18:24:02 +0000
Message-ID: <8F072D11-DBE6-456D-98D0-D55E1C9A0734@cisco.com>
References: <20180917.194518.233902533629875552.mbj@tail-f.com>
In-Reply-To: <20180917.194518.233902533629875552.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.39]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: 
Subject: Re: [Netconf] usage of HTTP in restconf-notif-07
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Sep 2018 18:24:08 -0000

SGksDQoNClBTSS4NCg0K77u/T24gMjAxOC0wOS0xNywgMTo0NSBQTSwgIk5ldGNvbmYgb24gYmVo
YWxmIG9mIE1hcnRpbiBCam9ya2x1bmQiIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo
YWxmIG9mIG1iakB0YWlsLWYuY29tPiB3cm90ZToNCg0KICAgIEhpLA0KICAgIA0KICAgIEkgdGhp
bmsgdGhlIC0wNyB2ZXJzaW9uIGlzIGEgc3RlcCBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uIGZvciB0
aGlzDQogICAgZHJhZnQuICBCdXQgSSBoYXZlIGEgY29tbWVudCBvbiB0aGUgdXNhZ2Ugb2YgSFRU
UC8yLg0KICAgIA0KICAgIEkgYW0gbm90IGFuIGV4cGVydCBhdCBhbGwgaW4gSFRUUC8yLCBidXQg
SSB3b25kZXIgaWYgdGhlIHdheSB0aGlzDQogICAgZHJhZnQgdXNlcyBpdCBpcyBjb3JyZWN0LiAg
VGhlIGRyYWZ0IGlzIHZlcnkgc2hvcnQgb24gZGV0YWlscywgYnV0DQogICAgZXNzZW50aWFsbHkg
c2F5cyB0aGF0IHRoZSBjbGllbnQgUE9TVHMgdG8gdGhlICJ1cmkiIHRoYXQgdGhlIHNlcnZlcg0K
ICAgIHJldHVybnMgKHByb2JhYmx5IHcvbyBhIGJvZHk/KSwgYW5kIHRoZW4gdGhhdCB0aGUgc2Vy
dmVyIHNlbmRzDQogICAgaW5kaXZpZHVhbCBub3RpZmljYXRpb25zIGluIERBVEEgZnJhbWVzLiAg
SXMgdGhpcyByZWFsbHkgbGVnYWw/ICBSRkMNCiAgICA3NTQwLCBzZWN0aW9uIDggc2F5czoNCiAg
ICANCiAgICAgICBIVFRQLzIgaXMgaW50ZW5kZWQgdG8gYmUgYXMgY29tcGF0aWJsZSBhcyBwb3Nz
aWJsZSB3aXRoIGN1cnJlbnQgdXNlcw0KICAgICAgIG9mIEhUVFAuICBUaGlzIG1lYW5zIHRoYXQs
IGZyb20gdGhlIGFwcGxpY2F0aW9uIHBlcnNwZWN0aXZlLCB0aGUNCiAgICAgICBmZWF0dXJlcyBv
ZiB0aGUgcHJvdG9jb2wgYXJlIGxhcmdlbHkgdW5jaGFuZ2VkLiAgVG8gYWNoaWV2ZSB0aGlzLCBh
bGwNCiAgICAgICByZXF1ZXN0IGFuZCByZXNwb25zZSBzZW1hbnRpY3MgYXJlIHByZXNlcnZlZCwg
YWx0aG91Z2ggdGhlIHN5bnRheCBvZg0KICAgICAgIGNvbnZleWluZyB0aG9zZSBzZW1hbnRpY3Mg
aGFzIGNoYW5nZWQuDQogICAgDQogICAgSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgcmVzdGNvbmYt
bm90aWYgZHJhZnQgdmlvbGF0ZXMgdGhpcyBwYXJhZ3JhcGguDQoNCjxSUj4gQWNrLCBIVFRQIHNl
bWFudGljcyBoYXZlIHRvIGJlIGZvbGxvd2VkLCB0aGVyZSdzIG5vIHJlYXNvbiB0byBkbyBvdGhl
cndpc2UuIEknbGwgY2hlY2sgdG8gc2VlIHdoYXQgZGV0YWlscy9jbGFyaWZpY2F0aW9ucyBjYW4g
YmUgYWRkZWQuDQogICAgDQogICAgSW4gZmFjdCwgaXQgc2VlbXMgdGhhdCB3aGF0IHRoZSBkcmFm
dCB0cmllcyB0byBkbyBpcyBtb3JlIG9yIGxlc3MNCiAgICBleGFjdGx5IHRoZSBzYW1lIGFzIFNT
RSwgZXhjZXB0IHcvbyB0aGUgZGV0YWlscywgZS5nLiwgaXQgZG9lc24ndA0KICAgIHNwZWNpZnkg
dGhlIGNvbnRlbnQtdHlwZS4NCiAgICANCiAgICBJdCBhbHNvIHNlZW1zIHRvIG1lIChhZnRlciBz
b21lIGdvb2dsaW5nKSB0aGF0IGl0IGlzIHBlcmZlY3RseSBmaW5lIHRvDQogICAgdXNlIHN0YW5k
YXJkIFNTRSB3aXRoIEhUVFAvMiwgYW5kIHRoYXQncyB3aGF0IHBlb3BsZSBhcmUgdXNpbmcgdG8N
CiAgICBkZWxpdmVyIHNlcnZlci1nZW5lcmF0ZWQgZXZlbnRzL25vdGlmcyB0byBjbGllbnRzIHdp
dGggSFRUUC8yLg0KICAgIA0KICAgIFNvLCB0aGlzIGRyYWZ0IHNob3VsZCBwcm9iYWJseSBub3Qg
bWVudGlvbiBIVFRQLzIgYXQgYWxsLCBidXQgaW5zdGVhZA0KICAgIGp1c3Qgc3BlY2lmeSB0aGUg
c2VtYW50aWNzIG9mIHRoZSAidXJpIiByZXNvdXJjZSBhbmQgaG93IGEgY2xpZW50IGNhbg0KICAg
IFBPU1QgdG8gaXQgdG8gZ2V0IFNTRSBnb2luZy4gIFRoZSBkcmFmdCBzaG91bGQgdGhlIHJlZmVy
IHRvIHNlY3Rpb24NCiAgICA2LjQgb2YgUkZDIDgwNDAgZm9yIGhvdyBub3RpZmljYXRpb25zIGFy
ZSBzZW50IGZyb20gdGhpcyByZXNvdXJjZS4NCg0KPFJSPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRo
YXQgSFRUUDIgaXMgbWVudGlvbmVkIGluIHRoZSBkcmFmdCBzbyB0aGF0IHdlIGNhbiB1c2UgSFRU
UDIgc3RyZWFtcy4gVGhlIHBvaW50IHlvdSdyZSBtYWtpbmcgaXMgdGhhdCBpZiB0aGlzIGlzIGEg
UkVTVENPTkYgdHJhbnNwb3J0IGRyYWZ0IHRoZW4gd2Ugc2hvdWxkIGp1c3QgdXNlIHdoYXQncyBp
biBSRkM4MDQwLCBJJ20gb2sgd2l0aCB0aGF0IGJ1dCB3b3VsZCBsaWtlIHRvIGhlYXIgZnJvbSB0
aGUgb3RoZXIgYXV0aG9ycyBzaW5jZSBJIG1pZ2h0IGJlIG1pc3Npbmcgc29tZSBoaXN0b3J5Lg0K
DQpSZWdhcmRzLA0KUmVzaGFkLg0KICAgIA0KICAgIA0KICAgIC9tYXJ0aW4NCiAgICANCiAgICBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIE5ldGNv
bmYgbWFpbGluZyBsaXN0DQogICAgTmV0Y29uZkBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KICAgIA0KDQo=


From nobody Mon Sep 17 12:18:03 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A277130EE4 for ; Mon, 17 Sep 2018 12:17: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, 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 a-8N_fg8-Bvj for ; Mon, 17 Sep 2018 12:17:54 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 319B6130EFF for ; Mon, 17 Sep 2018 12:17:54 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 0B4301AE0311; Mon, 17 Sep 2018 21:17:53 +0200 (CEST)
Date: Mon, 17 Sep 2018 21:17:52 +0200 (CEST)
Message-Id: <20180917.211752.1252883710011024711.mbj@tail-f.com>
To: rrahman@cisco.com
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <8F072D11-DBE6-456D-98D0-D55E1C9A0734@cisco.com>
References: <20180917.194518.233902533629875552.mbj@tail-f.com> <8F072D11-DBE6-456D-98D0-D55E1C9A0734@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [Netconf] usage of HTTP in restconf-notif-07
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Sep 2018 19:18:02 -0000

IlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+IHdyb3RlOg0KPiBI
aSwNCj4gDQo+IFBTSS4NCj4gDQo+IO+7v09uIDIwMTgtMDktMTcsIDE6NDUgUE0sICJOZXRjb25m
IG9uIGJlaGFsZiBvZiBNYXJ0aW4gQmpvcmtsdW5kIg0KPiA8bmV0Y29uZi1ib3VuY2VzQGlldGYu
b3JnIG9uIGJlaGFsZiBvZiBtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQo+IA0KPiAgICAgSGksDQo+
ICAgICANCj4gICAgIEkgdGhpbmsgdGhlIC0wNyB2ZXJzaW9uIGlzIGEgc3RlcCBpbiB0aGUgcmln
aHQgZGlyZWN0aW9uIGZvciB0aGlzDQo+ICAgICBkcmFmdC4gIEJ1dCBJIGhhdmUgYSBjb21tZW50
IG9uIHRoZSB1c2FnZSBvZiBIVFRQLzIuDQo+ICAgICANCj4gICAgIEkgYW0gbm90IGFuIGV4cGVy
dCBhdCBhbGwgaW4gSFRUUC8yLCBidXQgSSB3b25kZXIgaWYgdGhlIHdheSB0aGlzDQo+ICAgICBk
cmFmdCB1c2VzIGl0IGlzIGNvcnJlY3QuICBUaGUgZHJhZnQgaXMgdmVyeSBzaG9ydCBvbiBkZXRh
aWxzLCBidXQNCj4gICAgIGVzc2VudGlhbGx5IHNheXMgdGhhdCB0aGUgY2xpZW50IFBPU1RzIHRv
IHRoZSAidXJpIiB0aGF0IHRoZSBzZXJ2ZXINCj4gICAgIHJldHVybnMgKHByb2JhYmx5IHcvbyBh
IGJvZHk/KSwgYW5kIHRoZW4gdGhhdCB0aGUgc2VydmVyIHNlbmRzDQo+ICAgICBpbmRpdmlkdWFs
IG5vdGlmaWNhdGlvbnMgaW4gREFUQSBmcmFtZXMuICBJcyB0aGlzIHJlYWxseSBsZWdhbD8gIFJG
Qw0KPiAgICAgNzU0MCwgc2VjdGlvbiA4IHNheXM6DQo+ICAgICANCj4gICAgICAgIEhUVFAvMiBp
cyBpbnRlbmRlZCB0byBiZSBhcyBjb21wYXRpYmxlIGFzIHBvc3NpYmxlIHdpdGggY3VycmVudCB1
c2VzDQo+ICAgICAgICBvZiBIVFRQLiAgVGhpcyBtZWFucyB0aGF0LCBmcm9tIHRoZSBhcHBsaWNh
dGlvbiBwZXJzcGVjdGl2ZSwgdGhlDQo+ICAgICAgICBmZWF0dXJlcyBvZiB0aGUgcHJvdG9jb2wg
YXJlIGxhcmdlbHkgdW5jaGFuZ2VkLiAgVG8gYWNoaWV2ZSB0aGlzLCBhbGwNCj4gICAgICAgIHJl
cXVlc3QgYW5kIHJlc3BvbnNlIHNlbWFudGljcyBhcmUgcHJlc2VydmVkLCBhbHRob3VnaCB0aGUg
c3ludGF4IG9mDQo+ICAgICAgICBjb252ZXlpbmcgdGhvc2Ugc2VtYW50aWNzIGhhcyBjaGFuZ2Vk
Lg0KPiAgICAgDQo+ICAgICBJdCBzZWVtcyB0byBtZSB0aGF0IHRoZSByZXN0Y29uZi1ub3RpZiBk
cmFmdCB2aW9sYXRlcyB0aGlzIHBhcmFncmFwaC4NCj4gDQo+IDxSUj4gQWNrLCBIVFRQIHNlbWFu
dGljcyBoYXZlIHRvIGJlIGZvbGxvd2VkLCB0aGVyZSdzIG5vIHJlYXNvbiB0byBkbw0KPiBvdGhl
cndpc2UuIEknbGwgY2hlY2sgdG8gc2VlIHdoYXQgZGV0YWlscy9jbGFyaWZpY2F0aW9ucyBjYW4g
YmUgYWRkZWQuDQo+ICAgICANCj4gICAgIEluIGZhY3QsIGl0IHNlZW1zIHRoYXQgd2hhdCB0aGUg
ZHJhZnQgdHJpZXMgdG8gZG8gaXMgbW9yZSBvciBsZXNzDQo+ICAgICBleGFjdGx5IHRoZSBzYW1l
IGFzIFNTRSwgZXhjZXB0IHcvbyB0aGUgZGV0YWlscywgZS5nLiwgaXQgZG9lc24ndA0KPiAgICAg
c3BlY2lmeSB0aGUgY29udGVudC10eXBlLg0KPiAgICAgDQo+ICAgICBJdCBhbHNvIHNlZW1zIHRv
IG1lIChhZnRlciBzb21lIGdvb2dsaW5nKSB0aGF0IGl0IGlzIHBlcmZlY3RseSBmaW5lIHRvDQo+
ICAgICB1c2Ugc3RhbmRhcmQgU1NFIHdpdGggSFRUUC8yLCBhbmQgdGhhdCdzIHdoYXQgcGVvcGxl
IGFyZSB1c2luZyB0bw0KPiAgICAgZGVsaXZlciBzZXJ2ZXItZ2VuZXJhdGVkIGV2ZW50cy9ub3Rp
ZnMgdG8gY2xpZW50cyB3aXRoIEhUVFAvMi4NCj4gICAgIA0KPiAgICAgU28sIHRoaXMgZHJhZnQg
c2hvdWxkIHByb2JhYmx5IG5vdCBtZW50aW9uIEhUVFAvMiBhdCBhbGwsIGJ1dCBpbnN0ZWFkDQo+
ICAgICBqdXN0IHNwZWNpZnkgdGhlIHNlbWFudGljcyBvZiB0aGUgInVyaSIgcmVzb3VyY2UgYW5k
IGhvdyBhIGNsaWVudCBjYW4NCj4gICAgIFBPU1QgdG8gaXQgdG8gZ2V0IFNTRSBnb2luZy4gIFRo
ZSBkcmFmdCBzaG91bGQgdGhlIHJlZmVyIHRvIHNlY3Rpb24NCj4gICAgIDYuNCBvZiBSRkMgODA0
MCBmb3IgaG93IG5vdGlmaWNhdGlvbnMgYXJlIHNlbnQgZnJvbSB0aGlzIHJlc291cmNlLg0KPiAN
Cj4gPFJSPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgSFRUUDIgaXMgbWVudGlvbmVkIGluIHRo
ZSBkcmFmdCBzbyB0aGF0DQo+IHdlIGNhbiB1c2UgSFRUUDIgc3RyZWFtcy4gVGhlIHBvaW50IHlv
dSdyZSBtYWtpbmcgaXMgdGhhdCBpZiB0aGlzIGlzIGENCj4gUkVTVENPTkYgdHJhbnNwb3J0IGRy
YWZ0IHRoZW4gd2Ugc2hvdWxkIGp1c3QgdXNlIHdoYXQncyBpbiBSRkM4MDQwLA0KPiBJJ20gb2sg
d2l0aCB0aGF0IGJ1dCB3b3VsZCBsaWtlIHRvIGhlYXIgZnJvbSB0aGUgb3RoZXIgYXV0aG9ycyBz
aW5jZSBJDQo+IG1pZ2h0IGJlIG1pc3Npbmcgc29tZSBoaXN0b3J5Lg0KDQpSaWdodC4gIEkgdGhp
bmsgdGhhdCBpZiBIVFRQLzIgaXMgdXNlZCB0aGVuIGEgY2xpZW50IGNhbiBzdGFydCBhbnkNCnN0
cmVhbSBpdCB3YW50czsgd2UgZG9uJ3QgaGF2ZSB0byBzcGVjaWZ5IGFueXRoaW5nIGFib3V0IHRo
aXMgaW4gdGhpcw0KZHJhZnQuICBGb3IgZXhhbXBsZSwgaWYgYSBjbGllbnQgZG9lc24ndCB3YW50
IHRvIHN0YXJ0IGEgbmV3IHN0cmVhbSwNCnRoYXQgc2hvdWxkIGFsc28gYmUgb2suDQoNCg0KL21h
cnRpbg0K


From nobody Mon Sep 17 14:42:13 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA959130DC6 for ; Mon, 17 Sep 2018 14:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham 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 NcJ3UjlGWr89 for ; Mon, 17 Sep 2018 14:42:08 -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 784801293FB for ; Mon, 17 Sep 2018 14:42:08 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8HLfR8k020121; Mon, 17 Sep 2018 14:42:05 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=uE/17n6ik1HMbJAgf+GJF+KFi3y1XBrOeSEhlV0Tkto=; b=lIw//p3ha5tgJJ83ZSwlvbHxIKAX0Otfh6fLHNvaZ6mYqYoxbDdlyOaBUEEFnRNYDiyo RVcYicdkAKTWUg1RJDkWvXoy3BXYbBJd5irw/0fT043BRQqF68J2ixhpklRd7WFRvmtc P9AMK1bHhT9niAikb2pNdfcJ1ln9+WIRYlU9KmqjTU0zBtzhxWVeM1JMe/z8d4OVFQlP WRVfGBRLqUDIGxNorCfRN6TRgfzJyQktYPIaKa2/seFebmWqHQX29wP3o+jTNkDacvor mqGO9LVV19eyA+mpSbJQipot5DxJjkh35X8L06hDiiBP4J1BUnUh5eUkS+2Q1R32E9wb lQ== 
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0019.outbound.protection.outlook.com [216.32.180.19]) by mx0b-00273201.pphosted.com with ESMTP id 2mj9rkhcd9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 17 Sep 2018 14:42:05 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4603.namprd05.prod.outlook.com (20.176.109.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.11; Mon, 17 Sep 2018 21:42:01 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1164.014; Mon, 17 Sep 2018 21:42:01 +0000
From: Kent Watsen 
To: Martin Bjorklund 
CC: "balazs.kovacs@ericsson.com" , "balazs.lengyel@ericsson.com" , "netconf@ietf.org" 
Thread-Topic: [Netconf] Mandatory local configuration in Keystore groupings
Thread-Index: AQHUE4rJV5t3ZASQT0G65kk51KFdjKSAiWUAgEnK74CAACpJAIABPX8AgAOrEACABC+ZAIAAwASAgAC9gACAAHNjgIAAFAaAgAEgEwCAAicPgIAF1PmAgAF1VYCACj3EgIAAtxgAgACClQCACVx+gIAAM1IA
Date: Mon, 17 Sep 2018 21:42:01 +0000
Message-ID: 
References: <185C7E6D-7EF1-4FFE-9A9B-74BA7E16D946@juniper.net> <20180911.095334.2041631968993039535.mbj@tail-f.com> <1F126D9A-775C-4590-A645-6529C3066C14@juniper.net> <20180917.163819.1278530557866964677.mbj@tail-f.com>
In-Reply-To: <20180917.163819.1278530557866964677.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4603; 6:s0eUu4S9IQZhKSKyayvqbeGfU1Ph0uJLk/B/bu0988xSEblr9qLNCcdwSX7WJj4tWDPR4OQgqjBR8GF6pe6pSTnSCWwC0HmiSsgFqmwtatRvBc1YROh+D1pRENgwJyxx+1x4g9Ow/JYyv7Tto4ofkA8gNVaeMvYhPEfbxrTKA2BniMwy40l97XWU5h4qZn71f2UyVnAmMREQcCDxjYvWd0l3DmZZyJ/FDh0sF2Lkk3cR+REgBmYrUbHGIIfesW2PGrRI2hQT+dfiiVeXY/FtzkOfq2wRM6L7pOakO5HDaWgf8PQ6g2X7ipiTosKPOwaZ8eLZprdSbBHSHmZYRM+JiqxStm/iJZg7Zg8n4m8TPzKQYPHHZRdVwrzMEXuE6MzIP5mJNV5IuoHwxooae+LG8l2aqz9MIffAfvtRuNCBR4HPPYPO1G8ab1dp5VX8qhT6Ku+/uJKlSZQL+93vkI6Vmg==; 5:a7Mkio/mlrKeSXvvmFcZ/O6b37SsfcQAMxyFgg6CJJ+Z0/lkoEOcK+ahFz3+R0txZfpYltVIbCAUN9V+tMsxIVpeyBpyTbjeTfUvLTLbGfA5JIs3qKJNKSy4m6DFDBmLXtc9IH1artsWZdXnzvy6YexC8d86hsvEfjQJCTeplL4=; 7:7WT4BAPtAWEblBw5y0GV8haYBT0zILoEyVDxmioL9OYdL7aHKOlfwBLpekGn1IeuFZYJL2lA/A7n+q5fob2bQhiBBbTJJcxbgecgjWjjFg1mFfG/a7p1QvZLVHzoNRNqHTXoxgk184z+PvK5gAuGNXukDasJHDxqiMcwq7939omS/69RKpd1kVnJDcHPwygzknqAxfwSokICn/uzBsna2eatBTLl0ZoCkZ5xuHFR9d3pTsZigWmUujfCMyAdoV8g
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: d0c6ee94-cb87-4841-be83-08d61ce666db
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4603; 
x-ms-traffictypediagnostic: DM6PR05MB4603:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231355)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699050); SRVR:DM6PR05MB4603; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4603; 
x-forefront-prvs: 0798146F16
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(366004)(39860400002)(396003)(136003)(376002)(346002)(189003)(199004)(478600001)(25786009)(3846002)(66066001)(6436002)(7736002)(81156014)(81166006)(6916009)(99286004)(4326008)(76176011)(97736004)(5250100002)(486006)(316002)(6116002)(6486002)(6512007)(5660300001)(11346002)(2616005)(58126008)(86362001)(229853002)(54906003)(305945005)(68736007)(476003)(53936002)(446003)(6506007)(93886005)(14454004)(102836004)(82746002)(14444005)(256004)(8676002)(33656002)(186003)(8936002)(106356001)(36756003)(83716003)(26005)(2906002)(105586002)(6246003)(2900100001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4603; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: vTj23u60MlBqd20URAjv09VVRJ5PSFenHly86QTIghfAuJo7uHcOntx4cI7YRUoR/XFQwAx8ojf8LuHuG+yC/kXZNaSRiMBo2I2ovVH0XH1Isj53lz9vSRm8hnVFBiFzS7eeFYu9luCKfMxlPPrGQv2GMPy7J7sTBcaj7PMxal12C/WTK5beC2dU8SdZNol7tdEcurmZbVWn+qErhT3lOaF9aOJY5jvfwsxNFn3sOzzP4GSOZkVovuzEQDEZFyrNQjpPjX6Si1bs3THmIp0IDl7Zg7ttp0GHJWOI2h2LkpnYarohJicAD/O5RnxV83UnPEX7IlQB76jxlp6+5GkeGpwOgNWcjfCTf+FNOlCf0ag=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: d0c6ee94-cb87-4841-be83-08d61ce666db
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2018 21:42:01.1835 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4603
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-17_12:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809170215
Archived-At: 
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Sep 2018 21:42:11 -0000

DQo+IFdpdGggKEEpLCBvbmNlIHlvdSBoYXZlIGdlbmVyYXRlZCB0aGUga2V5LCB5b3UgZmlyc3Qg
aGF2ZSB0byBjcmVhdGUNCj4gdGhlIGNvbmZpZyBmb3IgaXQsIHRoZW4gaW52b2tlIHRoZSBhY3Rp
b24uICAgV2l0aCAoQykgKDk5JSBvZikgdGhlIA0KPiBrZXlzIGFscmVhZHkgZXhpc3QgaW4gdGhl
IGNvbmZpZywgc28geW91IGNhbiBqdXN0IGludm9rZSB0aGUgYWN0aW9uLg0KDQpJIGRvbid0IGZv
bGxvdy4gIFdoYXQgSSBzZWUgaXMgdGhhdCwgd2l0aCAoQSksIGEgaGlkZGVuIGtleSBjYW4gYmUg
DQpjcmVhdGVkIHdpdGggYSBzaW5nbGUgYWN0aW9uIGludm9jYXRpb24gd2hpbGUsIHdpdGggKEMp
LCBmaXJzdCBhIA0KY29uZmlndXJhdGlvbiBvcGVyYXRpb24gaXMgbmVlZGVkIHRvIGNyZWF0ZSB0
aGUgImFzeW1tZXRyaWMta2V5IiANCih3aXRob3V0IHRoZSB0aHJlZSBsZWFmcykgZm9sbG93ZWQg
YnkgYW4gYWN0aW9uIGludm9jYXRpb24gKHRvIA0KcG9wdWxhdGUgdGhlIHRocmVlIGxlYWZzKS4N
Cg0KDQo+IFRvIHN1bW1hcml6ZSwgQSBhbmQgQyBib3RoIGdldCB0aGUgam9iIGRvbmUuICBXaGlj
aCBvbmUgaXMgYmV0dGVyIGlzDQo+IHByb2JhYmx5IHN1YmplY3RpdmUuICBJIHRoaW5rIChDKSBp
cyBtaWdodCBiZSBlYXNpZXIgdG8gdW5kZXJzdGFuZC4NCg0KT2theSwgbGV0J3Mgc2VlIGhvdyBp
dCBsb29rcy4gIEJ1YmJsaW5nIGFsbCB0aGUgaWRlYXMgdG8gdGhlIHRvcCwgSSANCmNyZWF0ZWQg
dGhlIGJlbG93IHRyZWUtZGlhZ3JhbXMuICBOb3RlLCBpbiBib3RoIGNhc2VzLCB0aGUgdGhyZWUg
DQoibWFuZGF0b3J5IHRydWUiIGxlYWZzIGFyZSByZXBsYWNlZCB3aXRoIGFuIGFsbC1vci1ub3Ro
aW5nICJtdXN0IiANCmV4cHJlc3Npb246DQoNCg0KKEEpIFVzZXMgUkZDIDgzNDIgU2VjdGlvbiBD
LjMuMiBzdHlsZSBjb25maWcgb3ZlcmxheXMgZm9yIGFsbCBoaWRkZW4ga2V5czsNCiAgICBhbmQg
YW4gYWN0aW9uIHN0YXRlbWVudCBpcyB1c2VkIHRvIGRlbGV0ZSBhbGwgaGlkZGVuIGtleXMuDQoN
CiAgICAgKy0tcncga2V5c3RvcmUNCiAgICAgICAgKy0tcncgYXN5bW1ldHJpYy1rZXlzDQogICAg
ICAgICAgICstLXJ3IGFzeW1tZXRyaWMta2V5KiBbbmFtZV0NCiAgICAgICAgICAgfCAgKy0tcncg
bmFtZSAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcNCiAgICAgICAgICAgfCAgKy0t
cncgYWxnb3JpdGhtPyAgICAgICAgICAgICAgICAgICAgICBjdDprZXktYWxnb3JpdGhtLXJlZg0K
ICAgICAgICAgICB8ICArLS1ydyBwdWJsaWMta2V5PyAgICAgICAgICAgICAgICAgICAgIGJpbmFy
eQ0KICAgICAgICAgICB8ICArLS1ydyBwcml2YXRlLWtleT8gICAgICAgICAgICAgICAgICAgIHVu
aW9uDQogICAgICAgICAgIHwgICstLS1tICIoYWxnb3JpdGhtIGFuZCBwdWJsaWMta2V5IGFuZCBw
cml2YXRlLWtleSkNCiAgICAgICAgICAgfCAgfCAgICAgICBvciBub3QgKGFsZ29yaXRobSBvciBw
dWJsaWMta2V5IG9yIHByaXZhdGUta2V5KSI7DQogICAgICAgICAgIHwgICstLXJ3IGNlcnRpZmlj
YXRlcw0KICAgICAgICAgICB8ICB8ICArLS1ydyBjZXJ0aWZpY2F0ZSogW25hbWVdDQogICAgICAg
ICAgIHwgIHwgICAgICstLXJ3IG5hbWUgICAgICAgICAgICAgICAgICAgICAgc3RyaW5nDQogICAg
ICAgICAgIHwgIHwgICAgICstLXJ3IGNlcnQgICAgICAgICAgICAgICAgICAgICAgY3Q6ZW5kLWVu
dGl0eS1jZXJ0LWNtcw0KICAgICAgICAgICB8ICB8ICAgICArLS0tbiBjZXJ0aWZpY2F0ZS1leHBp
cmF0aW9uDQogICAgICAgICAgIHwgIHwgICAgICAgICstLSBleHBpcmF0aW9uLWRhdGU/ICAgICAg
ICAgeWFuZzpkYXRlLWFuZC10aW1lDQogICAgICAgICAgIHwgICstLS14IGdlbmVyYXRlLWNlcnRp
ZmljYXRlLXNpZ25pbmctcmVxdWVzdA0KICAgICAgICAgICB8ICB8ICArLS0tdyBpbnB1dCAgICAg
ICAgICAgICAgICAgICAgICAgIC8vIEtFWSBNQVkgQkUgSU4gPE9QRVJBVE9OQUw+DQogICAgICAg
ICAgIHwgIHwgIHwgICstLS13IHN1YmplY3QgICAgICAgICAgICAgICAgICAgYmluYXJ5DQogICAg
ICAgICAgIHwgIHwgIHwgICstLS13IGF0dHJpYnV0ZXM/ICAgICAgICAgICAgICAgYmluYXJ5DQog
ICAgICAgICAgIHwgIHwgICstLXJvIG91dHB1dA0KICAgICAgICAgICB8ICB8ICAgICArLS1ybyBj
ZXJ0aWZpY2F0ZS1zaWduaW5nLXJlcXVlc3QgICAgYmluYXJ5DQogICAgICAgICAgIHwgICstLS14
IGRlbGV0ZS1oaWRkZW4ta2V5DQogICAgICAgICAgIHwgICAgICAgIC8vIG5vIHBhcmFtcw0KICAg
ICAgICAgICArLS0teCBnZW5lcmF0ZS1oaWRkZW4ta2V5DQogICAgICAgICAgIHwgICstLS13IGlu
cHV0ICAgICAgICAgICAgICAgICAgICAgICAgICAgLy8gUkVTVUxUIElOIDxPUEVSQVRPTkFMPg0K
ICAgICAgICAgICB8ICAgICArLS0tdyBuYW1lICAgICAgICAgICAgICAgICAgICAgICAgIHN0cmlu
Zw0KICAgICAgICAgICB8ICAgICArLS0tdyBhbGdvcml0aG0gICAgICAgICAgICAgICAgICAgIGN0
OmtleS1hbGdvcml0aG0tcmVmDQogICAgICAgICAgICstLS14IGxvYWQtaGlkZGVuLWtleQ0KICAg
ICAgICAgICAgICArLS0tdyBpbnB1dCAgICAgICAgICAgICAgICAgICAgICAgICAgIC8vIFJFU1VM
VCBJTiA8T1BFUkFUT05BTD4NCiAgICAgICAgICAgICAgICAgKy0tLXcgbmFtZSAgICAgICAgICAg
ICAgICAgICAgICAgICBzdHJpbmcNCiAgICAgICAgICAgICAgICAgKy0tLXcgYWxnb3JpdGhtICAg
ICAgICAgICAgICAgICAgICBjdDprZXktYWxnb3JpdGhtLXJlZg0KICAgICAgICAgICAgICAgICAr
LS0tdyBwdWJsaWMta2V5ICAgICAgICAgICAgICAgICAgIGJpbmFyeQ0KICAgICAgICAgICAgICAg
ICArLS0tdyBwcml2YXRlLWtleSAgICAgICAgICAgICAgICAgIHVuaW9uDQoNCg0KKEMpIFVzZXMg
UkZDIDgzNDIgU2VjdGlvbiBDLjMuMiBzdHlsZSBjb25maWcgb3ZlcmxheXMgb25seSBmb3IgaGlk
ZGVuIGtleXMNCiAgICBjcmVhdGVkIGluIDxvcGVyYXRpb25hbD4gKGkuZS4sIGR1cmluZyBtYW51
ZmFjdHVyaW5nKS4gIEJ1dCBpZiB0aGVyZSBpcw0KICAgIGV2ZW4ganVzdCBvbmUga2V5IGNyZWF0
ZWQgZHVyaW5nIE1hbnVmYWN0dXJpbmcsIGFuZCBpdCBkb2Vzbid0IGFwcGVhcg0KICAgIGluIDxp
bnRlbmRlZD4sIHRoZW4gbGVhZnJlZnMgc3RpbGwgbmVlZCB0byBiZSAicmVxdWlyZS1pbnN0YW5j
ZSBmYWxzZSIsDQogICAgcmlnaHQ/IEFsc28sIGl0IHNlZW1zIHRoYXQgc3VjaCBrZXlzIGNvdWxk
IG5ldmVyIGJlIGRlbGV0ZWQsIHVubGlrZSANCiAgICBvdGhlciBoaWRkZW4ga2V5cywgYnV0IHRo
YXQgaXMgcHJvYmFibHkgb2theSAoY29ycmVjdCBiZWhhdmlvcikuDQoNCiAgICAgKy0tcncga2V5
c3RvcmUNCiAgICAgICAgKy0tcncgYXN5bW1ldHJpYy1rZXlzDQogICAgICAgICAgICstLXJ3IGFz
eW1tZXRyaWMta2V5KiBbbmFtZV0NCiAgICAgICAgICAgICAgKy0tcncgbmFtZSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBzdHJpbmcNCiAgICAgICAgICAgICAgKy0tcncgYWxnb3JpdGhtPyAg
ICAgICAgICAgICAgICAgICAgICBjdDprZXktYWxnb3JpdGhtLXJlZg0KICAgICAgICAgICAgICAr
LS1ydyBwdWJsaWMta2V5PyAgICAgICAgICAgICAgICAgICAgIGJpbmFyeQ0KICAgICAgICAgICAg
ICArLS1ydyBwcml2YXRlLWtleT8gICAgICAgICAgICAgICAgICAgIHVuaW9uDQogICAgICAgICAg
ICAgICstLS1tICIoYWxnb3JpdGhtIGFuZCBwdWJsaWMta2V5IGFuZCBwcml2YXRlLWtleSkNCiAg
ICAgICAgICAgICAgfCAgICAgICBvciBub3QgKGFsZ29yaXRobSBvciBwdWJsaWMta2V5IG9yIHBy
aXZhdGUta2V5KSI7DQogICAgICAgICAgICAgICstLXJ3IGNlcnRpZmljYXRlcw0KICAgICAgICAg
ICAgICB8ICArLS1ydyBjZXJ0aWZpY2F0ZSogW25hbWVdDQogICAgICAgICAgICAgIHwgICAgICst
LXJ3IG5hbWUgICAgICAgICAgICAgICAgICAgICAgc3RyaW5nDQogICAgICAgICAgICAgIHwgICAg
ICstLXJ3IGNlcnQgICAgICAgICAgICAgICAgICAgICAgY3Q6ZW5kLWVudGl0eS1jZXJ0LWNtcyAN
CiAgICAgICAgICAgICAgfCAgICAgKy0tLW4gY2VydGlmaWNhdGUtZXhwaXJhdGlvbg0KICAgICAg
ICAgICAgICB8ICAgICAgICArLS0gZXhwaXJhdGlvbi1kYXRlPyAgICAgICAgIHlhbmc6ZGF0ZS1h
bmQtdGltZQ0KICAgICAgICAgICAgICArLS0teCBnZW5lcmF0ZS1oaWRkZW4ta2V5DQogICAgICAg
ICAgICAgIHwgICstLS13IGlucHV0ICAgICAgICAgICAgICAgICAgICAgICAgLy8gUkVTVUxUIElO
IDxPUEVSQVRPTkFMPg0KICAgICAgICAgICAgICB8ICAgICArLS0tdyBuYW1lICAgICAgICAgICAg
ICAgICAgICAgIHN0cmluZw0KICAgICAgICAgICAgICB8ICAgICArLS0tdyBhbGdvcml0aG0gICAg
ICAgICAgICAgICAgIGN0OmtleS1hbGdvcml0aG0tcmVmDQogICAgICAgICAgICAgICstLS14IGxv
YWQtaGlkZGVuLWtleQ0KICAgICAgICAgICAgICB8ICArLS0tdyBpbnB1dCAgICAgICAgICAgICAg
ICAgICAgICAgIC8vIFJFU1VMVCBJTiA8T1BFUkFUT05BTD4NCiAgICAgICAgICAgICAgfCAgICAg
Ky0tLXcgbmFtZSAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcNCiAgICAgICAgICAgICAgfCAg
ICAgKy0tLXcgYWxnb3JpdGhtICAgICAgICAgICAgICAgICBjdDprZXktYWxnb3JpdGhtLXJlZg0K
ICAgICAgICAgICAgICB8ICAgICArLS0tdyBwdWJsaWMta2V5ICAgICAgICAgICAgICAgIGJpbmFy
eQ0KICAgICAgICAgICAgICB8ICAgICArLS0tdyBwcml2YXRlLWtleSAgICAgICAgICAgICAgIHVu
aW9uDQogICAgICAgICAgICAgICstLS14IGdlbmVyYXRlLWNlcnRpZmljYXRlLXNpZ25pbmctcmVx
dWVzdA0KICAgICAgICAgICAgICAgICArLS0tdyBpbnB1dCAgICAgICAgICAgICAgICAgICAgICAg
IC8vIEtFWSBNQVkgQkUgSU4gPE9QRVJBVE9OQUw+DQogICAgICAgICAgICAgICAgIHwgICstLS13
IHN1YmplY3QgICAgICAgICAgICAgICAgICAgYmluYXJ5DQogICAgICAgICAgICAgICAgIHwgICst
LS13IGF0dHJpYnV0ZXM/ICAgICAgICAgICAgICAgYmluYXJ5DQogICAgICAgICAgICAgICAgICst
LXJvIG91dHB1dA0KICAgICAgICAgICAgICAgICAgICArLS1ybyBjZXJ0aWZpY2F0ZS1zaWduaW5n
LXJlcXVlc3QgICAgYmluYXJ5DQoNCg0KDQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0KDQoNCg==


From nobody Mon Sep 17 18:36:46 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC58130E05 for ; Mon, 17 Sep 2018 18:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 RUA-Mlz3LuFR for ; Mon, 17 Sep 2018 18:36:43 -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 36E3D130DFB for ; Mon, 17 Sep 2018 18:36:43 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 8A1E4BE28869 for ; Tue, 18 Sep 2018 02:36:39 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 18 Sep 2018 02:36:40 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0399.000; Tue, 18 Sep 2018 09:36:34 +0800
From: Qin Wu 
To: "Reshad Rahman (rrahman)" , "Martin Bjorklund" , "netconf@ietf.org" 
Thread-Topic: [Netconf] usage of HTTP in restconf-notif-07
Thread-Index: AQHUTq5Gyl5nGYuwD0CqnTdleHOFK6T0Q74AgAD9YyA=
Date: Tue, 18 Sep 2018 01:36:34 +0000
Message-ID: 
References: <20180917.194518.233902533629875552.mbj@tail-f.com> <8F072D11-DBE6-456D-98D0-D55E1C9A0734@cisco.com>
In-Reply-To: <8F072D11-DBE6-456D-98D0-D55E1C9A0734@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] usage of HTTP in restconf-notif-07
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Sep 2018 01:36:45 -0000

LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBOZXRjb25mIFttYWlsdG86bmV0Y29u
Zi1ib3VuY2VzQGlldGYub3JnXSDku6PooaggUmVzaGFkIFJhaG1hbiAocnJhaG1hbikNCuWPkemA
geaXtumXtDogMjAxOOW5tDnmnIgxOOaXpSAyOjI0DQrmlLbku7bkuro6IE1hcnRpbiBCam9ya2x1
bmQ7IG5ldGNvbmZAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtOZXRjb25mXSB1c2FnZSBvZiBIVFRQ
IGluIHJlc3Rjb25mLW5vdGlmLTA3DQoNCkhpLA0KDQpQU0kuDQoNCu+7v09uIDIwMTgtMDktMTcs
IDE6NDUgUE0sICJOZXRjb25mIG9uIGJlaGFsZiBvZiBNYXJ0aW4gQmpvcmtsdW5kIiA8bmV0Y29u
Zi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQoN
CiAgICBIaSwNCiAgICANCiAgICBJIHRoaW5rIHRoZSAtMDcgdmVyc2lvbiBpcyBhIHN0ZXAgaW4g
dGhlIHJpZ2h0IGRpcmVjdGlvbiBmb3IgdGhpcw0KICAgIGRyYWZ0LiAgQnV0IEkgaGF2ZSBhIGNv
bW1lbnQgb24gdGhlIHVzYWdlIG9mIEhUVFAvMi4NCiAgICANCiAgICBJIGFtIG5vdCBhbiBleHBl
cnQgYXQgYWxsIGluIEhUVFAvMiwgYnV0IEkgd29uZGVyIGlmIHRoZSB3YXkgdGhpcw0KICAgIGRy
YWZ0IHVzZXMgaXQgaXMgY29ycmVjdC4gIFRoZSBkcmFmdCBpcyB2ZXJ5IHNob3J0IG9uIGRldGFp
bHMsIGJ1dA0KICAgIGVzc2VudGlhbGx5IHNheXMgdGhhdCB0aGUgY2xpZW50IFBPU1RzIHRvIHRo
ZSAidXJpIiB0aGF0IHRoZSBzZXJ2ZXINCiAgICByZXR1cm5zIChwcm9iYWJseSB3L28gYSBib2R5
PyksIGFuZCB0aGVuIHRoYXQgdGhlIHNlcnZlciBzZW5kcw0KICAgIGluZGl2aWR1YWwgbm90aWZp
Y2F0aW9ucyBpbiBEQVRBIGZyYW1lcy4gIElzIHRoaXMgcmVhbGx5IGxlZ2FsPyAgUkZDDQogICAg
NzU0MCwgc2VjdGlvbiA4IHNheXM6DQogICAgDQogICAgICAgSFRUUC8yIGlzIGludGVuZGVkIHRv
IGJlIGFzIGNvbXBhdGlibGUgYXMgcG9zc2libGUgd2l0aCBjdXJyZW50IHVzZXMNCiAgICAgICBv
ZiBIVFRQLiAgVGhpcyBtZWFucyB0aGF0LCBmcm9tIHRoZSBhcHBsaWNhdGlvbiBwZXJzcGVjdGl2
ZSwgdGhlDQogICAgICAgZmVhdHVyZXMgb2YgdGhlIHByb3RvY29sIGFyZSBsYXJnZWx5IHVuY2hh
bmdlZC4gIFRvIGFjaGlldmUgdGhpcywgYWxsDQogICAgICAgcmVxdWVzdCBhbmQgcmVzcG9uc2Ug
c2VtYW50aWNzIGFyZSBwcmVzZXJ2ZWQsIGFsdGhvdWdoIHRoZSBzeW50YXggb2YNCiAgICAgICBj
b252ZXlpbmcgdGhvc2Ugc2VtYW50aWNzIGhhcyBjaGFuZ2VkLg0KICAgIA0KICAgIEl0IHNlZW1z
IHRvIG1lIHRoYXQgdGhlIHJlc3Rjb25mLW5vdGlmIGRyYWZ0IHZpb2xhdGVzIHRoaXMgcGFyYWdy
YXBoLg0KDQo8UlI+IEFjaywgSFRUUCBzZW1hbnRpY3MgaGF2ZSB0byBiZSBmb2xsb3dlZCwgdGhl
cmUncyBubyByZWFzb24gdG8gZG8gb3RoZXJ3aXNlLiBJJ2xsIGNoZWNrIHRvIHNlZSB3aGF0IGRl
dGFpbHMvY2xhcmlmaWNhdGlvbnMgY2FuIGJlIGFkZGVkLg0KICAgIA0KICAgIEluIGZhY3QsIGl0
IHNlZW1zIHRoYXQgd2hhdCB0aGUgZHJhZnQgdHJpZXMgdG8gZG8gaXMgbW9yZSBvciBsZXNzDQog
ICAgZXhhY3RseSB0aGUgc2FtZSBhcyBTU0UsIGV4Y2VwdCB3L28gdGhlIGRldGFpbHMsIGUuZy4s
IGl0IGRvZXNuJ3QNCiAgICBzcGVjaWZ5IHRoZSBjb250ZW50LXR5cGUuDQogICAgDQogICAgSXQg
YWxzbyBzZWVtcyB0byBtZSAoYWZ0ZXIgc29tZSBnb29nbGluZykgdGhhdCBpdCBpcyBwZXJmZWN0
bHkgZmluZSB0bw0KICAgIHVzZSBzdGFuZGFyZCBTU0Ugd2l0aCBIVFRQLzIsIGFuZCB0aGF0J3Mg
d2hhdCBwZW9wbGUgYXJlIHVzaW5nIHRvDQogICAgZGVsaXZlciBzZXJ2ZXItZ2VuZXJhdGVkIGV2
ZW50cy9ub3RpZnMgdG8gY2xpZW50cyB3aXRoIEhUVFAvMi4NCiAgICANCiAgICBTbywgdGhpcyBk
cmFmdCBzaG91bGQgcHJvYmFibHkgbm90IG1lbnRpb24gSFRUUC8yIGF0IGFsbCwgYnV0IGluc3Rl
YWQNCiAgICBqdXN0IHNwZWNpZnkgdGhlIHNlbWFudGljcyBvZiB0aGUgInVyaSIgcmVzb3VyY2Ug
YW5kIGhvdyBhIGNsaWVudCBjYW4NCiAgICBQT1NUIHRvIGl0IHRvIGdldCBTU0UgZ29pbmcuICBU
aGUgZHJhZnQgc2hvdWxkIHRoZSByZWZlciB0byBzZWN0aW9uDQogICAgNi40IG9mIFJGQyA4MDQw
IGZvciBob3cgbm90aWZpY2F0aW9ucyBhcmUgc2VudCBmcm9tIHRoaXMgcmVzb3VyY2UuDQoNCjxS
Uj4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IEhUVFAyIGlzIG1lbnRpb25lZCBpbiB0aGUgZHJh
ZnQgc28gdGhhdCB3ZSBjYW4gdXNlIEhUVFAyIHN0cmVhbXMuIFRoZSBwb2ludCB5b3UncmUgbWFr
aW5nIGlzIHRoYXQgaWYgdGhpcyBpcyBhIFJFU1RDT05GIHRyYW5zcG9ydCBkcmFmdCB0aGVuIHdl
IHNob3VsZCBqdXN0IHVzZSB3aGF0J3MgaW4gUkZDODA0MCwgSSdtIG9rIHdpdGggdGhhdCBidXQg
d291bGQgbGlrZSB0byBoZWFyIGZyb20gdGhlIG90aGVyIGF1dGhvcnMgc2luY2UgSSBtaWdodCBi
ZSBtaXNzaW5nIHNvbWUgaGlzdG9yeS4NCg0KW1Fpbl06ICsxLCBNYXJ0aW4gc3BlYWtzIG15IHdv
cmQsIEkgd291bGQgYWxzbyBsaWtlIHRvIHNlZSByZXN0Y29uZi1ub3RpZiBhbGlnbiB3aXRoIFJG
QzgwNDAuIFNldHVwIHR3byBjaGFubmVscyBmb3IgYm90aCBSRVNUQ09ORiBhbmQgSFRUUDIgbWFr
ZXMgbWUgYmVsaWV2ZSBSRVNUQ09ORiBjbGllbnQgTVVTVCBzdXBwb3J0IEhUVFAvMi4NClJlZ2Fy
ZHMsDQpSZXNoYWQuDQogICAgDQogICAgDQogICAgL21hcnRpbg0KICAgIA0KICAgIF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgTmV0Y29uZiBtYWls
aW5nIGxpc3QNCiAgICBOZXRjb25mQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQogICAgDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBp
ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo=


From nobody Tue Sep 18 00:02:36 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C8F128D68 for ; Tue, 18 Sep 2018 00:02:36 -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 I96mEn30ZUGi for ; Tue, 18 Sep 2018 00:02:34 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0AED3126F72 for ; Tue, 18 Sep 2018 00:02:33 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 60BF91AE02BE; Tue, 18 Sep 2018 09:02:28 +0200 (CEST)
Date: Tue, 18 Sep 2018 09:02:27 +0200 (CEST)
Message-Id: <20180918.090227.98113334613843662.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: balazs.kovacs@ericsson.com, balazs.lengyel@ericsson.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <1F126D9A-775C-4590-A645-6529C3066C14@juniper.net> <20180917.163819.1278530557866964677.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Sep 2018 07:02:36 -0000

Hi,

Ok, so we have these two alternatives illustrated below.  There are
some details that probably are wrong, but it doesn't really matter at
this stage.  With (A), there is one more action to control the
lifespan of keys (delete-hidden-key).

In the case that the key is given as config, A and C works in the same
way.

In the case that the key is permanent, A and C also works in the same
way.

A and C differ in how hidden keys are handled.


In order to create a hidden key + certificate, the steps are:

A:  1. call generate-hidden-key with a given name
    2. create an asymmetric-key with the same name in the config
    3. call generate-certificate-signing-request
    4. 
    5. create the certificate in the config

(step 1 and 2 can be done in reverse order)

C   1. create an asymmetric-key in the config
    2. call generate-hidden-key on this key
    3. call generate-certificate-signing-request
    4. 
    5. create the certificate in the config

In order to delete a hidden key completely:

A:  1. call delete-hidden-key on the asymmetric-key to be deleted
    2. delete the asymmetric-key from the config

C:  1. delete the asymmetric-key from the config



In summary, they are very similar.

One possible twist that probably works best for C could be to use
leafrefs with require instance true, and say that in order to use a
permanent key (created during manufacturing), you first need to create
config for the key (more or less empty config).  The benefit is that
we get proper leafref validation (no dangling pointers to handle in
all other models).  FWIW, this is the approach taken in
ietf-interfaces.

If we don't do this twist, I think that we can use either of A and C.



/martin




Kent Watsen  wrote:
> 
> > With (A), once you have generated the key, you first have to create
> > the config for it, then invoke the action.   With (C) (99% of) the 
> > keys already exist in the config, so you can just invoke the action.
> 
> I don't follow.  What I see is that, with (A), a hidden key can be 
> created with a single action invocation while, with (C), first a 
> configuration operation is needed to create the "asymmetric-key" 
> (without the three leafs) followed by an action invocation (to 
> populate the three leafs).
> 
> 
> > To summarize, A and C both get the job done.  Which one is better is
> > probably subjective.  I think (C) is might be easier to understand.
> 
> Okay, let's see how it looks.  Bubbling all the ideas to the top, I 
> created the below tree-diagrams.  Note, in both cases, the three 
> "mandatory true" leafs are replaced with an all-or-nothing "must" 
> expression:
> 
> 
> (A) Uses RFC 8342 Section C.3.2 style config overlays for all hidden keys;
>     and an action statement is used to delete all hidden keys.
> 
>      +--rw keystore
>         +--rw asymmetric-keys
>            +--rw asymmetric-key* [name]
>            |  +--rw name                            string
>            |  +--rw algorithm?                      ct:key-algorithm-ref
>            |  +--rw public-key?                     binary
>            |  +--rw private-key?                    union
>            |  +---m "(algorithm and public-key and private-key)
>            |  |       or not (algorithm or public-key or private-key)";
>            |  +--rw certificates
>            |  |  +--rw certificate* [name]
>            |  |     +--rw name                      string
>            |  |     +--rw cert                      ct:end-entity-cert-cms
>            |  |     +---n certificate-expiration
>            |  |        +-- expiration-date?         yang:date-and-time
>            |  +---x generate-certificate-signing-request
>            |  |  +---w input                        // KEY MAY BE IN 
>            |  |  |  +---w subject                   binary
>            |  |  |  +---w attributes?               binary
>            |  |  +--ro output
>            |  |     +--ro certificate-signing-request    binary
>            |  +---x delete-hidden-key
>            |        // no params
>            +---x generate-hidden-key
>            |  +---w input                           // RESULT IN 
>            |     +---w name                         string
>            |     +---w algorithm                    ct:key-algorithm-ref
>            +---x load-hidden-key
>               +---w input                           // RESULT IN 
>                  +---w name                         string
>                  +---w algorithm                    ct:key-algorithm-ref
>                  +---w public-key                   binary
>                  +---w private-key                  union
> 
> 
> (C) Uses RFC 8342 Section C.3.2 style config overlays only for hidden keys
>     created in  (i.e., during manufacturing).  But if there is
>     even just one key created during Manufacturing, and it doesn't appear
>     in , then leafrefs still need to be "require-instance false",
>     right? Also, it seems that such keys could never be deleted, unlike 
>     other hidden keys, but that is probably okay (correct behavior).
> 
>      +--rw keystore
>         +--rw asymmetric-keys
>            +--rw asymmetric-key* [name]
>               +--rw name                            string
>               +--rw algorithm?                      ct:key-algorithm-ref
>               +--rw public-key?                     binary
>               +--rw private-key?                    union
>               +---m "(algorithm and public-key and private-key)
>               |       or not (algorithm or public-key or private-key)";
>               +--rw certificates
>               |  +--rw certificate* [name]
>               |     +--rw name                      string
>               |     +--rw cert                      ct:end-entity-cert-cms 
>               |     +---n certificate-expiration
>               |        +-- expiration-date?         yang:date-and-time
>               +---x generate-hidden-key
>               |  +---w input                        // RESULT IN 
>               |     +---w name                      string
>               |     +---w algorithm                 ct:key-algorithm-ref
>               +---x load-hidden-key
>               |  +---w input                        // RESULT IN 
>               |     +---w name                      string
>               |     +---w algorithm                 ct:key-algorithm-ref
>               |     +---w public-key                binary
>               |     +---w private-key               union
>               +---x generate-certificate-signing-request
>                  +---w input                        // KEY MAY BE IN 
>                  |  +---w subject                   binary
>                  |  +---w attributes?               binary
>                  +--ro output
>                     +--ro certificate-signing-request    binary
> 
> 
> 
> 
> Kent // contributor
> 
> 
> 


From nobody Tue Sep 18 02:39:54 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF26130EEF for ; Tue, 18 Sep 2018 02:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.312
X-Spam-Level: 
X-Spam-Status: No, score=-4.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=OwFanf+p; dkim=pass (1024-bit key) header.d=ericsson.com header.b=KTI+dvaK
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSP65zvSfon2 for ; Tue, 18 Sep 2018 02:39:50 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60434130E98 for ; Tue, 18 Sep 2018 02:39:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537263588; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jf1SaoTPvfukYWzydjWPejAoYt61FDMI99D4p9xRbvM=; b=OwFanf+pHdzIJT6UPdVlplauJktEm9JGODb9up4kLAtnb9gEhWEIafRAdLBSeYgS VbcunwU7PT41v7z0hanbFWnOx9qX/4IueT4PIOI0kmhHCb2wSeV5C59Zqbb88MDp k1v9JzO6D/qjAahPNoQ9lR5XU9JcyWnfp+Z3OiODYJk=;
X-AuditID: c1b4fb3a-75d969c000003197-70-5ba0c7e48905
Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F1.E4.12695.4E7C0AB5; Tue, 18 Sep 2018 11:39:48 +0200 (CEST)
Received: from ESESBMR506.ericsson.se (153.88.183.202) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 18 Sep 2018 11:39:45 +0200
Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMR506.ericsson.se (153.88.183.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 18 Sep 2018 11:39:45 +0200
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 18 Sep 2018 11:39:45 +0200
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=zYxnCqWtG1FokUzO7kZSxBMA+VRzH5gPwcqJ5sfbUl0=; b=KTI+dvaKjtuqZt5OBp8N0zkF1rFOKPWHHkUNaIlaaRzvOmY/0G3uJkjEQb0N+vLn6tiHC6+11olgsPxE/2M0nM2zabjPIttTVooMS0XEK51V/Sa2mm14Y+gYoDmnt5mKQdYFWrtFMRuaz2viS+E0+L2gS4z2CdjIwahuKO/2Iuk=
Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com (10.167.209.150) by VI1PR0701MB2879.eurprd07.prod.outlook.com (10.173.71.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1164.15; Tue, 18 Sep 2018 09:39:44 +0000
Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::bd7a:c3c7:f6f1:4e9]) by VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::bd7a:c3c7:f6f1:4e9%4]) with mapi id 15.20.1164.014; Tue, 18 Sep 2018 09:39:40 +0000
From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= 
To: Martin Bjorklund , "kwatsen@juniper.net" 
CC: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= , "netconf@ietf.org" 
Thread-Topic: [Netconf] Mandatory local configuration in Keystore groupings
Thread-Index: AQHUE4npYduSZhsf/U2Th8xceQbCUaSAzHaAgEmH34CAAG1ZgIAA+nAAgAPuH4CAA+yKAIABAxSAgAB6cACAAHFXIIAAWSCAgADMp9CAAnp9gIAFkemAgAFwH/CACoYJAIAAdAkAgADFpICACRlvgIAAdmGAgACclYCAACUMUA==
Date: Tue, 18 Sep 2018 09:39:40 +0000
Message-ID: 
References: <1F126D9A-775C-4590-A645-6529C3066C14@juniper.net> <20180917.163819.1278530557866964677.mbj@tail-f.com>  <20180918.090227.98113334613843662.mbj@tail-f.com>
In-Reply-To: <20180918.090227.98113334613843662.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [89.135.192.225]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2879; 6:RAZ5kzzvd0wcCvkt5lXI+Ukdnihx+e9QYJY7nwuftaPmOBQ+wx97VHw6GXawDarSa0EdJnnm6C+UxGdAZI7CRjo+Kr8c06z1184rFI95qXnzf7M77itfVq74U2C7JkGqJV4sCQ5Tpv+8NiIZqweT3S2Ec84eCWdoW7lCsK4jlbqeVoOAEuXpvzLkQ1/TrnnGAEp2OT9TIoUchY+Gk+zHuON56SdYmmeaH5flTNSQLRLkQE4tDl3AJfl8waOfOjshMASr7ZV1wyZvXoGb5IdUBSDzM/xqWSds+RZ+CTYT07N3cme5MDbNv0t2DdXTLEPBtTigtI/HAR4tUKYMGOksHrNttiA+a/xcWv+OnJA6K22qJOP/P2hMwYoC64SlJoHbvHmSOYvid73GCFjwpk7UGyg4/5jfIElNFUJUF9l1iOq7NJ5+d/DerdBKGF3LV5gCGbkb/dE3sRnuGlXJ17AUww==; 5:a9xh9TKxnluchkQ0iEHbCoN+u1x53Tf5s9x+2sX4QkNNSBJqtSP056P0AsRmtqYBKAVwuZLw5kmqehfoE+3FRWpDtgThY8fgGlx/SrZUAw56QwbHJ9l7LEHeAj5pJdWHGsbc4zqk26xeChmEg5Y1UkDTgm4GDy+ogG1RtQEKqFI=; 7:XInSlpAlG7aAmtS/wTbbelry8EVDc7ysTiZM2BcuQ9SBw+q5uKZi0BFPnNV/8oTKflQD6SjjRBSIBPngxAOd6Jmz4or5Qx093zrxeyILhWzyZ2mxMk01fyam4jtD8VCU+HnASb1PXKdJiQGo/9kxiGjzd7XyLajJa6R13HkOaBAwbuk2NulSCtNk8D+O4KY3/SPLX4FAQQc/ToQqtvLBytxBXJT4eTkdJ/KNCCUKO31aVajWR6SS/NnCsDBAkXi/
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(136003)(396003)(39860400002)(51444003)(199004)(13464003)(189003)(93886005)(486006)(6116002)(14444005)(256004)(476003)(25786009)(6246003)(3846002)(14454004)(26005)(186003)(2906002)(8936002)(5250100002)(2900100001)(316002)(11346002)(86362001)(478600001)(6346003)(97736004)(2501003)(446003)(66066001)(4326008)(6436002)(76176011)(1941001)(5660300001)(53936002)(33656002)(54906003)(102836004)(99286004)(7736002)(110136005)(229853002)(53546011)(305945005)(74316002)(9686003)(6506007)(8676002)(55016002)(7696005)(81156014)(81166006)(68736007)(106356001)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2879; H:VI1PR0701MB2016.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
x-ms-office365-filtering-correlation-id: e06ce86a-7aa3-4866-2b51-08d61d4aa82f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2879; 
x-ms-traffictypediagnostic: VI1PR0701MB2879:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(248295561703944)(37575265505322); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(201708071742011)(7699050)(76991041); SRVR:VI1PR0701MB2879; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2879; 
x-forefront-prvs: 0799B1B2D7
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; 
x-microsoft-antispam-message-info: ZNFvrYfpQyPEdpKP3372VYlqm67UQ9MIq3w+qJlilBIGIyjOTNhZb9Wz9ERZ4Fma/yqKCZMHWFNIp4WxWSA8Pk60oK+kCukCwZXofWxa5f0gqDiYZbKKllJESgerAiJGAMOCh7EHAo530tQU4QZJMKZ+H2FSO+80mC/bVSORaOITmYe6UPaxWcItibpZwdR5AUK6q7RSlafOC8ntWEW+GMWV2bzR9dRFLeOZGRiedq+NgcinoC1DoHZpRMy97grNVzKS05apUbzjAdqChw5DjQ4WOgBLA4qb6Oq7s/6SOSB1B3q7xesdva0r/lnanntbH7xdPJLMPTl/yYTvIpYph2tNXIwPqk7u6nniWqwNZYo=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e06ce86a-7aa3-4866-2b51-08d61d4aa82f
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2018 09:39:40.5382 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2879
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH+e3e7d6tFr+W5kEJYugfZc1HD0aGT0pThP6QCA1y5fWBc8q9 S5v/ZIKim6RlA6eVs00llUjpOWc+QpcrFCOx6R8hrVbLPwLFV6Btuxb99/me8z18z4FDE7Lb wlC6SKNlWI1KLRdJSNPFF9qjboc5J3rVHakcuUcpDYZvlNI4sCBMJNKs1g1B2lz1LJXWv2kh zxPZktN5jLqonGGj4nMlha87aqkya9L1qs4lsgoNH9IjMQ34OIzNrJB6JKFleByBc34W8WIV wYZ3lPgnxmfsIl5YBeBwLwr8gsRNBHR6andsLQJwWdooXrgRTNgaBf4YET4DX00blJ+DcBbo O+4I/UxgNVSv9iI/78PpYBtaQLwnAxoMw4G1grANwXbfs8AwiSNgzTUUGJbiXHD1De6s+xnB autIwCTGCWDrryH8jPB+WHP2Cfi0EJh3twv4wzFY7dMEz8Hw48uWkGc5tHjnd/gAfGg3BAIA j1Bg2Zyg+EYMOB4N7ww3i6B+fY8e0T7O9IUpeP8kgkbHL8R7jkDvcBfFe0qhfknMly/B9lSz sAnFtv63Hs8K+GS8K+I5Ero6fhKtgZv3wqTJTZoR2YOCOYbjSgpiYxUMW3SV40o1Cg2jHUC+ Rxl9+vvUSzTqSRpDmEby3dLgV+YcmVBVzulKxhDQhDxIKlb7StI8la6SYUsvs9fUDDeGwmhS HiJNzldmy3CBSssUM0wZw/7tCmhxaBV6fCHfZCHbuvO33089b2OTFYMJ4WWZ0YneivBdXKyw 15leHzE3Y5hOl1QuR23Snc6Pb4xvi+PidNashzVPJrTLK7WNN+sW27Z6HINJ340z3Zobnit2 3Yk8s8drTF2PcJ9MORfmfZBS8e5+RvUxe/zZATK/wZU6pLulz6rTmQ7KSa5QFXOYYDnVH+a8 SKIkAwAA
Archived-At: 
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Sep 2018 09:39:53 -0000

Hi,

I'd just emphasize that in creation step of hidden key, the name must be co=
ordinated between step A/1&2 by external application logic. Same holds for =
deletion of hidden key for A/1&2. "Same name" is important.

Enabling the possibility for 'require instance true' would be also good rem=
ark on the side of (C).

Regarding manufactured keys, I would not expect manufactured keys to be use=
d in other common models, such as in TLS/SSH use cases. If they have some s=
pecific use case, maybe those models could either have 'require instance fa=
lse' or it could be said to create an empty key for them as Martin describe=
d.

Br,
Balazs

-----Original Message-----
From: Martin Bjorklund =20
Sent: Tuesday, September 18, 2018 9:02 AM
To: kwatsen@juniper.net
Cc: Bal=E1zs Kov=E1cs ; Bal=E1zs Lengyel ; netconf@ietf.org
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings

Hi,

Ok, so we have these two alternatives illustrated below.  There are some de=
tails that probably are wrong, but it doesn't really matter at this stage. =
 With (A), there is one more action to control the lifespan of keys (delete=
-hidden-key).

In the case that the key is given as config, A and C works in the same way.

In the case that the key is permanent, A and C also works in the same way.

A and C differ in how hidden keys are handled.


In order to create a hidden key + certificate, the steps are:

A:  1. call generate-hidden-key with a given name
    2. create an asymmetric-key with the same name in the config
    3. call generate-certificate-signing-request
    4. 
    5. create the certificate in the config

(step 1 and 2 can be done in reverse order)

C   1. create an asymmetric-key in the config
    2. call generate-hidden-key on this key
    3. call generate-certificate-signing-request
    4. 
    5. create the certificate in the config

In order to delete a hidden key completely:

A:  1. call delete-hidden-key on the asymmetric-key to be deleted
    2. delete the asymmetric-key from the config

C:  1. delete the asymmetric-key from the config



In summary, they are very similar.

One possible twist that probably works best for C could be to use leafrefs =
with require instance true, and say that in order to use a permanent key (c=
reated during manufacturing), you first need to create config for the key (=
more or less empty config).  The benefit is that we get proper leafref vali=
dation (no dangling pointers to handle in all other models).  FWIW, this is=
 the approach taken in ietf-interfaces.

If we don't do this twist, I think that we can use either of A and C.



/martin




Kent Watsen  wrote:
>=20
> > With (A), once you have generated the key, you first have to create
> > the config for it, then invoke the action.   With (C) (99% of) the=20
> > keys already exist in the config, so you can just invoke the action.
>=20
> I don't follow.  What I see is that, with (A), a hidden key can be=20
> created with a single action invocation while, with (C), first a=20
> configuration operation is needed to create the "asymmetric-key"
> (without the three leafs) followed by an action invocation (to=20
> populate the three leafs).
>=20
>=20
> > To summarize, A and C both get the job done.  Which one is better is=20
> > probably subjective.  I think (C) is might be easier to understand.
>=20
> Okay, let's see how it looks.  Bubbling all the ideas to the top, I=20
> created the below tree-diagrams.  Note, in both cases, the three=20
> "mandatory true" leafs are replaced with an all-or-nothing "must"
> expression:
>=20
>=20
> (A) Uses RFC 8342 Section C.3.2 style config overlays for all hidden keys=
;
>     and an action statement is used to delete all hidden keys.
>=20
>      +--rw keystore
>         +--rw asymmetric-keys
>            +--rw asymmetric-key* [name]
>            |  +--rw name                            string
>            |  +--rw algorithm?                      ct:key-algorithm-ref
>            |  +--rw public-key?                     binary
>            |  +--rw private-key?                    union
>            |  +---m "(algorithm and public-key and private-key)
>            |  |       or not (algorithm or public-key or private-key)";
>            |  +--rw certificates
>            |  |  +--rw certificate* [name]
>            |  |     +--rw name                      string
>            |  |     +--rw cert                      ct:end-entity-cert-cm=
s
>            |  |     +---n certificate-expiration
>            |  |        +-- expiration-date?         yang:date-and-time
>            |  +---x generate-certificate-signing-request
>            |  |  +---w input                        // KEY MAY BE IN 
>            |  |  |  +---w subject                   binary
>            |  |  |  +---w attributes?               binary
>            |  |  +--ro output
>            |  |     +--ro certificate-signing-request    binary
>            |  +---x delete-hidden-key
>            |        // no params
>            +---x generate-hidden-key
>            |  +---w input                           // RESULT IN 
>            |     +---w name                         string
>            |     +---w algorithm                    ct:key-algorithm-ref
>            +---x load-hidden-key
>               +---w input                           // RESULT IN 
>                  +---w name                         string
>                  +---w algorithm                    ct:key-algorithm-ref
>                  +---w public-key                   binary
>                  +---w private-key                  union
>=20
>=20
> (C) Uses RFC 8342 Section C.3.2 style config overlays only for hidden key=
s
>     created in  (i.e., during manufacturing).  But if there =
is
>     even just one key created during Manufacturing, and it doesn't appear
>     in , then leafrefs still need to be "require-instance false=
",
>     right? Also, it seems that such keys could never be deleted, unlike=20
>     other hidden keys, but that is probably okay (correct behavior).
>=20
>      +--rw keystore
>         +--rw asymmetric-keys
>            +--rw asymmetric-key* [name]
>               +--rw name                            string
>               +--rw algorithm?                      ct:key-algorithm-ref
>               +--rw public-key?                     binary
>               +--rw private-key?                    union
>               +---m "(algorithm and public-key and private-key)
>               |       or not (algorithm or public-key or private-key)";
>               +--rw certificates
>               |  +--rw certificate* [name]
>               |     +--rw name                      string
>               |     +--rw cert                      ct:end-entity-cert-cm=
s=20
>               |     +---n certificate-expiration
>               |        +-- expiration-date?         yang:date-and-time
>               +---x generate-hidden-key
>               |  +---w input                        // RESULT IN 
>               |     +---w name                      string
>               |     +---w algorithm                 ct:key-algorithm-ref
>               +---x load-hidden-key
>               |  +---w input                        // RESULT IN 
>               |     +---w name                      string
>               |     +---w algorithm                 ct:key-algorithm-ref
>               |     +---w public-key                binary
>               |     +---w private-key               union
>               +---x generate-certificate-signing-request
>                  +---w input                        // KEY MAY BE IN 
>                  |  +---w subject                   binary
>                  |  +---w attributes?               binary
>                  +--ro output
>                     +--ro certificate-signing-request    binary
>=20
>=20
>=20
>=20
> Kent // contributor
>=20
>=20
>=20


From nobody Tue Sep 18 11:53:10 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EFF1252B7 for ; Tue, 18 Sep 2018 11:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham 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 k0ENcwypHi1E for ; Tue, 18 Sep 2018 11:53:04 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 C06BF130E1C for ; Tue, 18 Sep 2018 11:53:04 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8IImvtV005924; Tue, 18 Sep 2018 11:53:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=XkZBBWFAZLLWy9M1xWYUPpy0hMUZqS2+4gsOLXeqKbU=; b=lUr8cJuHCrItEIAkR+Vj+1b2qTeSljvT9dvQT5dnXkuZqGfKdQRaJedHqTOCwuwL8bdN wA/AezgqtuWGwUDtj16T90X5DRnr4pAdQKkYHd2uHeR+ZuH3I5c6WNjG767TRhbatrPC 1yrbdSs3TgMxpYwRGiLm0gZtl4PZg78iqb2XUwZR5T4sMBMA1k64rD3WeFyEVHj9VzpZ LUMmlr3FkJwgJi3O1CAg30pYHzTU8qUht8sWyIgagzU+vdauwfmTKtzPzJIlsOZToSLo t1dcClOGhjIHDfdXrem4QzNDzg8qI5b7uakMVafjZ5DwnlY4PHZKxx42LBCOxVHM9g/1 rA== 
Received: from nam05-co1-obe.outbound.protection.outlook.com (mail-co1nam05lp0088.outbound.protection.outlook.com [216.32.181.88]) by mx0a-00273201.pphosted.com with ESMTP id 2mk5re04nd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Sep 2018 11:53:01 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4601.namprd05.prod.outlook.com (20.176.109.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.11; Tue, 18 Sep 2018 18:52:58 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1164.014; Tue, 18 Sep 2018 18:52:58 +0000
From: Kent Watsen 
To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , Martin Bjorklund 
CC: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netconf@ietf.org" 
Thread-Topic: [Netconf] Mandatory local configuration in Keystore groupings
Thread-Index: AQHUE4rJV5t3ZASQT0G65kk51KFdjKSAiWUAgEnK74CAACpJAIABPX8AgAOrEACABC+ZAIAAwASAgAC9gACAAHNjgIAAFAaAgAEgEwCAAicPgIAF1PmAgAF1VYCACj3EgIAAtxgAgACClQCACVx+gIAAM1IAgADfpYCAACvtAIAAV4eA
Date: Tue, 18 Sep 2018 18:52:58 +0000
Message-ID: 
References: <1F126D9A-775C-4590-A645-6529C3066C14@juniper.net> <20180917.163819.1278530557866964677.mbj@tail-f.com>  <20180918.090227.98113334613843662.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4601; 6:KeQcbpJwR8UKCmZNhsm69lQPDn5TaMBou4db+ENyAFR0bdvTim7bpIIgdel+q3UH61ms9EoNbmh61FC2g8WrwIDbfxA5LlanPsFtvMdXy/40lTwJ9QBVkHreRb9oLlzjVapjFsnwAYCkUmhH0yakI2psLdu5K5JqhHjYjUmMw5t5lX3zTcpzf6CuZvWDg1p4r8cYx3DrWIOP4BdqB9Q0OHUytYusu9T2AN2OquJtaPUvuqq9Q3mz3KnfA+BmEUhAfWAxY0BgmTrJdGlevntSLxINmi7eblCQwnz9aqywGx53hgN6Eg0IWgnNexrGEcJqOkPAr2Ft12+js3jCHD56YAMC9z0CENNAdtZn3UBvSbj9TH6g2aeRFTMmyiAbdXFpuhlTodhZvnEfydRaLumW4WDfF5XJRTqMYntu9irR09fmWy6AAxj1M29uvh/pr+QDIqiJcFPnPi+8Ov8y+L1zvQ==; 5:53ii2Yrt+M9xmkU3gBEhu7ombY/090OMavbcuIKZnEO4wGo2pWyhReV/C/BgpuXIL40Nm5H5P3yVt1k2So7WXxDIFNV7BFlq46w7mKQo4GYO51o/NM+FHkcPDIV5IfddW5cLF3U7lc57dfwGgF5vBN/PkmiPV22Kp3ARm3HGHZc=; 7:O97fOB5GOBcJ1lnGaC4pOZbnuoFAOCU5zuWPeXXB+qdV9gQq3t+ixfMEoWa5cMjFdT7XcfOzHkmitdXVuQZBkmKV/B/JFbYIWauBtPb8hvrleeCghek715Yi2VaYwKHtEP6bf2AMwH1PXdkhsvnPDFigBQVLD+zdjE7M/mh9BOTwqRMS7UXEfI2rBsfD9umElY/BiTNlzVQbdClp2gHBGkHDqaN4aEpHrses5xV7IMSLSmgLybsndjXubTFQq3Ap
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 69c66f43-7b54-45c1-7f68-08d61d97f3b9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4601; 
x-ms-traffictypediagnostic: DM6PR05MB4601:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(37575265505322)(248295561703944); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699050)(76991041); SRVR:DM6PR05MB4601; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4601; 
x-forefront-prvs: 0799B1B2D7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(346002)(136003)(366004)(376002)(189003)(13464003)(199004)(51444003)(2616005)(53936002)(76176011)(305945005)(66066001)(25786009)(7736002)(486006)(8676002)(5660300001)(6346003)(11346002)(316002)(476003)(81156014)(102836004)(97736004)(6436002)(58126008)(2900100001)(6512007)(26005)(446003)(6246003)(53546011)(186003)(6506007)(256004)(81166006)(14444005)(83716003)(6486002)(36756003)(110136005)(106356001)(99286004)(478600001)(8936002)(3846002)(4326008)(14454004)(54906003)(86362001)(93886005)(6116002)(2906002)(68736007)(33656002)(105586002)(82746002)(229853002)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4601; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Hv07TEHFxW3eNzdVkyMURvUjIZEWMA6+EWkzP64DITiX2EanIwDyKtys8a4IyAbnPtehH5z40ClAYvzjeyyKxA6tUCi3r08e6xj2Ns8i+bgQ4vyVS22FHj6ATrzGDxPdynQkmu3WCVKvu93p3/UwB5HCSbLqtdphU70pLUb3XcOabnyPfC1IwVN4GImmaVz9ZooxMj2bLzajt8faMrsIzoDlORqnvwVBuFfnj4wnTLOps+so8cEdyzd486V1ydWQn5IU23rGUhlhMRivV9xPy4kC4y8Yrv4TuPq8A8cvxqJjIYqhD9Vj1ZqKHKFwgfOOzKpNDslGvKOohHebGNXER6nGgX9mf/LryNZTCJqxBZs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 69c66f43-7b54-45c1-7f68-08d61d97f3b9
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2018 18:52:58.4510 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4601
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-18_07:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809180183
Archived-At: 
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Sep 2018 18:53:08 -0000

DQpJIGxpa2UgTWFydGluJ3MgInR3aXN0IiAtIEkgZG9uJ3QgdmlldyBpdCBhcyBhbiBleHRyZW1l
IGhhcmRzaGlwICh0aGUgMSUgY2FzZSksIGFuZCBJIHByZWZlciAoQykgZm9yIHN1cHBvcnRpbmcg
InJlcXVpcmUtaW5zdGFuY2UgdHJ1ZSIgYXMgd2VsbCBhcyBoYXZpbmcgb25lIGxlc3MgYWN0aW9u
LiAgU28sIGxldCdzIGdvIHdpdGggKEMpLg0KDQpNYXJ0aW4sIHlvdSBtZW50aW9uZWQgc29tZSBk
ZXRhaWxzIG1pZ2h0IGJlIHdyb25nLCBhcmUgdGhleSB3cm9uZyBpbiAoQyk/ICAtIEknZCBsaWtl
IHRvIGhhdmUgaXQgcmlnaHQgd2hlbiBwb3N0aW5nIHRoZSBuZXh0IHVwZGF0ZS4uLg0KDQpCYWxh
enMsIHRoZSBkZXNpcmUgdG8gcmVmZXJlbmNlIGFuIElEZXZJRCBjb3VsZCBiZSBmcm9tIGFueSBT
U0gvVExTLWJhc2VkIGFwcCwgaXQgd291bGQgYmUgaGFyZCB0byBrbm93IGluIGFkdmFuY2Ugd2hl
cmUuICBObyBtYXR0ZXIsIHdpdGggKEMpK3R3aXN0LCB3ZSBjYW4gaGF2ZSAicmVxdWlyZS1pbnN0
YW5jZSB0cnVlIiBhbHdheXMuDQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KDQpIaSwNCg0KSSdkIGp1c3QgZW1waGFzaXplIHRoYXQgaW4gY3Jl
YXRpb24gc3RlcCBvZiBoaWRkZW4ga2V5LCB0aGUgbmFtZSBtdXN0IGJlIGNvb3JkaW5hdGVkIGJl
dHdlZW4gc3RlcCBBLzEmMiBieSBleHRlcm5hbCBhcHBsaWNhdGlvbiBsb2dpYy4gU2FtZSBob2xk
cyBmb3IgZGVsZXRpb24gb2YgaGlkZGVuIGtleSBmb3IgQS8xJjIuICJTYW1lIG5hbWUiIGlzIGlt
cG9ydGFudC4NCg0KRW5hYmxpbmcgdGhlIHBvc3NpYmlsaXR5IGZvciAncmVxdWlyZSBpbnN0YW5j
ZSB0cnVlJyB3b3VsZCBiZSBhbHNvIGdvb2QgcmVtYXJrIG9uIHRoZSBzaWRlIG9mIChDKS4NCg0K
UmVnYXJkaW5nIG1hbnVmYWN0dXJlZCBrZXlzLCBJIHdvdWxkIG5vdCBleHBlY3QgbWFudWZhY3R1
cmVkIGtleXMgdG8gYmUgdXNlZCBpbiBvdGhlciBjb21tb24gbW9kZWxzLCBzdWNoIGFzIGluIFRM
Uy9TU0ggdXNlIGNhc2VzLiBJZiB0aGV5IGhhdmUgc29tZSBzcGVjaWZpYyB1c2UgY2FzZSwgbWF5
YmUgdGhvc2UgbW9kZWxzIGNvdWxkIGVpdGhlciBoYXZlICdyZXF1aXJlIGluc3RhbmNlIGZhbHNl
JyBvciBpdCBjb3VsZCBiZSBzYWlkIHRvIGNyZWF0ZSBhbiBlbXB0eSBrZXkgZm9yIHRoZW0gYXMg
TWFydGluIGRlc2NyaWJlZC4NCg0KQnIsDQpCYWxhenMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiANClNlbnQ6IFR1
ZXNkYXksIFNlcHRlbWJlciAxOCwgMjAxOCA5OjAyIEFNDQpUbzoga3dhdHNlbkBqdW5pcGVyLm5l
dA0KQ2M6IEJhbMOhenMgS292w6FjcyA8YmFsYXpzLmtvdmFjc0Blcmljc3Nvbi5jb20+OyBCYWzD
oXpzIExlbmd5ZWwgPGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbT47IG5ldGNvbmZAaWV0Zi5v
cmcNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gTWFuZGF0b3J5IGxvY2FsIGNvbmZpZ3VyYXRpb24g
aW4gS2V5c3RvcmUgZ3JvdXBpbmdzDQoNCkhpLA0KDQpPaywgc28gd2UgaGF2ZSB0aGVzZSB0d28g
YWx0ZXJuYXRpdmVzIGlsbHVzdHJhdGVkIGJlbG93LiAgVGhlcmUgYXJlIHNvbWUgZGV0YWlscyB0
aGF0IHByb2JhYmx5IGFyZSB3cm9uZywgYnV0IGl0IGRvZXNuJ3QgcmVhbGx5IG1hdHRlciBhdCB0
aGlzIHN0YWdlLiAgV2l0aCAoQSksIHRoZXJlIGlzIG9uZSBtb3JlIGFjdGlvbiB0byBjb250cm9s
IHRoZSBsaWZlc3BhbiBvZiBrZXlzIChkZWxldGUtaGlkZGVuLWtleSkuDQoNCkluIHRoZSBjYXNl
IHRoYXQgdGhlIGtleSBpcyBnaXZlbiBhcyBjb25maWcsIEEgYW5kIEMgd29ya3MgaW4gdGhlIHNh
bWUgd2F5Lg0KDQpJbiB0aGUgY2FzZSB0aGF0IHRoZSBrZXkgaXMgcGVybWFuZW50LCBBIGFuZCBD
IGFsc28gd29ya3MgaW4gdGhlIHNhbWUgd2F5Lg0KDQpBIGFuZCBDIGRpZmZlciBpbiBob3cgaGlk
ZGVuIGtleXMgYXJlIGhhbmRsZWQuDQoNCg0KSW4gb3JkZXIgdG8gY3JlYXRlIGEgaGlkZGVuIGtl
eSArIGNlcnRpZmljYXRlLCB0aGUgc3RlcHMgYXJlOg0KDQpBOiAgMS4gY2FsbCBnZW5lcmF0ZS1o
aWRkZW4ta2V5IHdpdGggYSBnaXZlbiBuYW1lDQogICAgMi4gY3JlYXRlIGFuIGFzeW1tZXRyaWMt
a2V5IHdpdGggdGhlIHNhbWUgbmFtZSBpbiB0aGUgY29uZmlnDQogICAgMy4gY2FsbCBnZW5lcmF0
ZS1jZXJ0aWZpY2F0ZS1zaWduaW5nLXJlcXVlc3QNCiAgICA0LiA8Z2V0IGhvbGQgb2YgYSBjZXJ0
Pg0KICAgIDUuIGNyZWF0ZSB0aGUgY2VydGlmaWNhdGUgaW4gdGhlIGNvbmZpZw0KDQooc3RlcCAx
IGFuZCAyIGNhbiBiZSBkb25lIGluIHJldmVyc2Ugb3JkZXIpDQoNCkMgICAxLiBjcmVhdGUgYW4g
YXN5bW1ldHJpYy1rZXkgaW4gdGhlIGNvbmZpZw0KICAgIDIuIGNhbGwgZ2VuZXJhdGUtaGlkZGVu
LWtleSBvbiB0aGlzIGtleQ0KICAgIDMuIGNhbGwgZ2VuZXJhdGUtY2VydGlmaWNhdGUtc2lnbmlu
Zy1yZXF1ZXN0DQogICAgNC4gPGdldCBob2xkIG9mIGEgY2VydD4NCiAgICA1LiBjcmVhdGUgdGhl
IGNlcnRpZmljYXRlIGluIHRoZSBjb25maWcNCg0KSW4gb3JkZXIgdG8gZGVsZXRlIGEgaGlkZGVu
IGtleSBjb21wbGV0ZWx5Og0KDQpBOiAgMS4gY2FsbCBkZWxldGUtaGlkZGVuLWtleSBvbiB0aGUg
YXN5bW1ldHJpYy1rZXkgdG8gYmUgZGVsZXRlZA0KICAgIDIuIGRlbGV0ZSB0aGUgYXN5bW1ldHJp
Yy1rZXkgZnJvbSB0aGUgY29uZmlnDQoNCkM6ICAxLiBkZWxldGUgdGhlIGFzeW1tZXRyaWMta2V5
IGZyb20gdGhlIGNvbmZpZw0KDQoNCg0KSW4gc3VtbWFyeSwgdGhleSBhcmUgdmVyeSBzaW1pbGFy
Lg0KDQpPbmUgcG9zc2libGUgdHdpc3QgdGhhdCBwcm9iYWJseSB3b3JrcyBiZXN0IGZvciBDIGNv
dWxkIGJlIHRvIHVzZSBsZWFmcmVmcyB3aXRoIHJlcXVpcmUgaW5zdGFuY2UgdHJ1ZSwgYW5kIHNh
eSB0aGF0IGluIG9yZGVyIHRvIHVzZSBhIHBlcm1hbmVudCBrZXkgKGNyZWF0ZWQgZHVyaW5nIG1h
bnVmYWN0dXJpbmcpLCB5b3UgZmlyc3QgbmVlZCB0byBjcmVhdGUgY29uZmlnIGZvciB0aGUga2V5
IChtb3JlIG9yIGxlc3MgZW1wdHkgY29uZmlnKS4gIFRoZSBiZW5lZml0IGlzIHRoYXQgd2UgZ2V0
IHByb3BlciBsZWFmcmVmIHZhbGlkYXRpb24gKG5vIGRhbmdsaW5nIHBvaW50ZXJzIHRvIGhhbmRs
ZSBpbiBhbGwgb3RoZXIgbW9kZWxzKS4gIEZXSVcsIHRoaXMgaXMgdGhlIGFwcHJvYWNoIHRha2Vu
IGluIGlldGYtaW50ZXJmYWNlcy4NCg0KSWYgd2UgZG9uJ3QgZG8gdGhpcyB0d2lzdCwgSSB0aGlu
ayB0aGF0IHdlIGNhbiB1c2UgZWl0aGVyIG9mIEEgYW5kIEMuDQoNCg0KDQovbWFydGluDQoNCg0K
DQoNCktlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gDQo+ID4gV2l0
aCAoQSksIG9uY2UgeW91IGhhdmUgZ2VuZXJhdGVkIHRoZSBrZXksIHlvdSBmaXJzdCBoYXZlIHRv
IGNyZWF0ZQ0KPiA+IHRoZSBjb25maWcgZm9yIGl0LCB0aGVuIGludm9rZSB0aGUgYWN0aW9uLiAg
IFdpdGggKEMpICg5OSUgb2YpIHRoZSANCj4gPiBrZXlzIGFscmVhZHkgZXhpc3QgaW4gdGhlIGNv
bmZpZywgc28geW91IGNhbiBqdXN0IGludm9rZSB0aGUgYWN0aW9uLg0KPiANCj4gSSBkb24ndCBm
b2xsb3cuICBXaGF0IEkgc2VlIGlzIHRoYXQsIHdpdGggKEEpLCBhIGhpZGRlbiBrZXkgY2FuIGJl
IA0KPiBjcmVhdGVkIHdpdGggYSBzaW5nbGUgYWN0aW9uIGludm9jYXRpb24gd2hpbGUsIHdpdGgg
KEMpLCBmaXJzdCBhIA0KPiBjb25maWd1cmF0aW9uIG9wZXJhdGlvbiBpcyBuZWVkZWQgdG8gY3Jl
YXRlIHRoZSAiYXN5bW1ldHJpYy1rZXkiDQo+ICh3aXRob3V0IHRoZSB0aHJlZSBsZWFmcykgZm9s
bG93ZWQgYnkgYW4gYWN0aW9uIGludm9jYXRpb24gKHRvIA0KPiBwb3B1bGF0ZSB0aGUgdGhyZWUg
bGVhZnMpLg0KPiANCj4gDQo+ID4gVG8gc3VtbWFyaXplLCBBIGFuZCBDIGJvdGggZ2V0IHRoZSBq
b2IgZG9uZS4gIFdoaWNoIG9uZSBpcyBiZXR0ZXIgaXMgDQo+ID4gcHJvYmFibHkgc3ViamVjdGl2
ZS4gIEkgdGhpbmsgKEMpIGlzIG1pZ2h0IGJlIGVhc2llciB0byB1bmRlcnN0YW5kLg0KPiANCj4g
T2theSwgbGV0J3Mgc2VlIGhvdyBpdCBsb29rcy4gIEJ1YmJsaW5nIGFsbCB0aGUgaWRlYXMgdG8g
dGhlIHRvcCwgSSANCj4gY3JlYXRlZCB0aGUgYmVsb3cgdHJlZS1kaWFncmFtcy4gIE5vdGUsIGlu
IGJvdGggY2FzZXMsIHRoZSB0aHJlZSANCj4gIm1hbmRhdG9yeSB0cnVlIiBsZWFmcyBhcmUgcmVw
bGFjZWQgd2l0aCBhbiBhbGwtb3Itbm90aGluZyAibXVzdCINCj4gZXhwcmVzc2lvbjoNCj4gDQo+
IA0KPiAoQSkgVXNlcyBSRkMgODM0MiBTZWN0aW9uIEMuMy4yIHN0eWxlIGNvbmZpZyBvdmVybGF5
cyBmb3IgYWxsIGhpZGRlbiBrZXlzOw0KPiAgICAgYW5kIGFuIGFjdGlvbiBzdGF0ZW1lbnQgaXMg
dXNlZCB0byBkZWxldGUgYWxsIGhpZGRlbiBrZXlzLg0KPiANCj4gICAgICArLS1ydyBrZXlzdG9y
ZQ0KPiAgICAgICAgICstLXJ3IGFzeW1tZXRyaWMta2V5cw0KPiAgICAgICAgICAgICstLXJ3IGFz
eW1tZXRyaWMta2V5KiBbbmFtZV0NCj4gICAgICAgICAgICB8ICArLS1ydyBuYW1lICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHN0cmluZw0KPiAgICAgICAgICAgIHwgICstLXJ3IGFsZ29yaXRo
bT8gICAgICAgICAgICAgICAgICAgICAgY3Q6a2V5LWFsZ29yaXRobS1yZWYNCj4gICAgICAgICAg
ICB8ICArLS1ydyBwdWJsaWMta2V5PyAgICAgICAgICAgICAgICAgICAgIGJpbmFyeQ0KPiAgICAg
ICAgICAgIHwgICstLXJ3IHByaXZhdGUta2V5PyAgICAgICAgICAgICAgICAgICAgdW5pb24NCj4g
ICAgICAgICAgICB8ICArLS0tbSAiKGFsZ29yaXRobSBhbmQgcHVibGljLWtleSBhbmQgcHJpdmF0
ZS1rZXkpDQo+ICAgICAgICAgICAgfCAgfCAgICAgICBvciBub3QgKGFsZ29yaXRobSBvciBwdWJs
aWMta2V5IG9yIHByaXZhdGUta2V5KSI7DQo+ICAgICAgICAgICAgfCAgKy0tcncgY2VydGlmaWNh
dGVzDQo+ICAgICAgICAgICAgfCAgfCAgKy0tcncgY2VydGlmaWNhdGUqIFtuYW1lXQ0KPiAgICAg
ICAgICAgIHwgIHwgICAgICstLXJ3IG5hbWUgICAgICAgICAgICAgICAgICAgICAgc3RyaW5nDQo+
ICAgICAgICAgICAgfCAgfCAgICAgKy0tcncgY2VydCAgICAgICAgICAgICAgICAgICAgICBjdDpl
bmQtZW50aXR5LWNlcnQtY21zDQo+ICAgICAgICAgICAgfCAgfCAgICAgKy0tLW4gY2VydGlmaWNh
dGUtZXhwaXJhdGlvbg0KPiAgICAgICAgICAgIHwgIHwgICAgICAgICstLSBleHBpcmF0aW9uLWRh
dGU/ICAgICAgICAgeWFuZzpkYXRlLWFuZC10aW1lDQo+ICAgICAgICAgICAgfCAgKy0tLXggZ2Vu
ZXJhdGUtY2VydGlmaWNhdGUtc2lnbmluZy1yZXF1ZXN0DQo+ICAgICAgICAgICAgfCAgfCAgKy0t
LXcgaW5wdXQgICAgICAgICAgICAgICAgICAgICAgICAvLyBLRVkgTUFZIEJFIElOIDxPUEVSQVRP
TkFMPg0KPiAgICAgICAgICAgIHwgIHwgIHwgICstLS13IHN1YmplY3QgICAgICAgICAgICAgICAg
ICAgYmluYXJ5DQo+ICAgICAgICAgICAgfCAgfCAgfCAgKy0tLXcgYXR0cmlidXRlcz8gICAgICAg
ICAgICAgICBiaW5hcnkNCj4gICAgICAgICAgICB8ICB8ICArLS1ybyBvdXRwdXQNCj4gICAgICAg
ICAgICB8ICB8ICAgICArLS1ybyBjZXJ0aWZpY2F0ZS1zaWduaW5nLXJlcXVlc3QgICAgYmluYXJ5
DQo+ICAgICAgICAgICAgfCAgKy0tLXggZGVsZXRlLWhpZGRlbi1rZXkNCj4gICAgICAgICAgICB8
ICAgICAgICAvLyBubyBwYXJhbXMNCj4gICAgICAgICAgICArLS0teCBnZW5lcmF0ZS1oaWRkZW4t
a2V5DQo+ICAgICAgICAgICAgfCAgKy0tLXcgaW5wdXQgICAgICAgICAgICAgICAgICAgICAgICAg
ICAvLyBSRVNVTFQgSU4gPE9QRVJBVE9OQUw+DQo+ICAgICAgICAgICAgfCAgICAgKy0tLXcgbmFt
ZSAgICAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcNCj4gICAgICAgICAgICB8ICAgICArLS0t
dyBhbGdvcml0aG0gICAgICAgICAgICAgICAgICAgIGN0OmtleS1hbGdvcml0aG0tcmVmDQo+ICAg
ICAgICAgICAgKy0tLXggbG9hZC1oaWRkZW4ta2V5DQo+ICAgICAgICAgICAgICAgKy0tLXcgaW5w
dXQgICAgICAgICAgICAgICAgICAgICAgICAgICAvLyBSRVNVTFQgSU4gPE9QRVJBVE9OQUw+DQo+
ICAgICAgICAgICAgICAgICAgKy0tLXcgbmFtZSAgICAgICAgICAgICAgICAgICAgICAgICBzdHJp
bmcNCj4gICAgICAgICAgICAgICAgICArLS0tdyBhbGdvcml0aG0gICAgICAgICAgICAgICAgICAg
IGN0OmtleS1hbGdvcml0aG0tcmVmDQo+ICAgICAgICAgICAgICAgICAgKy0tLXcgcHVibGljLWtl
eSAgICAgICAgICAgICAgICAgICBiaW5hcnkNCj4gICAgICAgICAgICAgICAgICArLS0tdyBwcml2
YXRlLWtleSAgICAgICAgICAgICAgICAgIHVuaW9uDQo+IA0KPiANCj4gKEMpIFVzZXMgUkZDIDgz
NDIgU2VjdGlvbiBDLjMuMiBzdHlsZSBjb25maWcgb3ZlcmxheXMgb25seSBmb3IgaGlkZGVuIGtl
eXMNCj4gICAgIGNyZWF0ZWQgaW4gPG9wZXJhdGlvbmFsPiAoaS5lLiwgZHVyaW5nIG1hbnVmYWN0
dXJpbmcpLiAgQnV0IGlmIHRoZXJlIGlzDQo+ICAgICBldmVuIGp1c3Qgb25lIGtleSBjcmVhdGVk
IGR1cmluZyBNYW51ZmFjdHVyaW5nLCBhbmQgaXQgZG9lc24ndCBhcHBlYXINCj4gICAgIGluIDxp
bnRlbmRlZD4sIHRoZW4gbGVhZnJlZnMgc3RpbGwgbmVlZCB0byBiZSAicmVxdWlyZS1pbnN0YW5j
ZSBmYWxzZSIsDQo+ICAgICByaWdodD8gQWxzbywgaXQgc2VlbXMgdGhhdCBzdWNoIGtleXMgY291
bGQgbmV2ZXIgYmUgZGVsZXRlZCwgdW5saWtlIA0KPiAgICAgb3RoZXIgaGlkZGVuIGtleXMsIGJ1
dCB0aGF0IGlzIHByb2JhYmx5IG9rYXkgKGNvcnJlY3QgYmVoYXZpb3IpLg0KPiANCj4gICAgICAr
LS1ydyBrZXlzdG9yZQ0KPiAgICAgICAgICstLXJ3IGFzeW1tZXRyaWMta2V5cw0KPiAgICAgICAg
ICAgICstLXJ3IGFzeW1tZXRyaWMta2V5KiBbbmFtZV0NCj4gICAgICAgICAgICAgICArLS1ydyBu
YW1lICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cmluZw0KPiAgICAgICAgICAgICAgICst
LXJ3IGFsZ29yaXRobT8gICAgICAgICAgICAgICAgICAgICAgY3Q6a2V5LWFsZ29yaXRobS1yZWYN
Cj4gICAgICAgICAgICAgICArLS1ydyBwdWJsaWMta2V5PyAgICAgICAgICAgICAgICAgICAgIGJp
bmFyeQ0KPiAgICAgICAgICAgICAgICstLXJ3IHByaXZhdGUta2V5PyAgICAgICAgICAgICAgICAg
ICAgdW5pb24NCj4gICAgICAgICAgICAgICArLS0tbSAiKGFsZ29yaXRobSBhbmQgcHVibGljLWtl
eSBhbmQgcHJpdmF0ZS1rZXkpDQo+ICAgICAgICAgICAgICAgfCAgICAgICBvciBub3QgKGFsZ29y
aXRobSBvciBwdWJsaWMta2V5IG9yIHByaXZhdGUta2V5KSI7DQo+ICAgICAgICAgICAgICAgKy0t
cncgY2VydGlmaWNhdGVzDQo+ICAgICAgICAgICAgICAgfCAgKy0tcncgY2VydGlmaWNhdGUqIFtu
YW1lXQ0KPiAgICAgICAgICAgICAgIHwgICAgICstLXJ3IG5hbWUgICAgICAgICAgICAgICAgICAg
ICAgc3RyaW5nDQo+ICAgICAgICAgICAgICAgfCAgICAgKy0tcncgY2VydCAgICAgICAgICAgICAg
ICAgICAgICBjdDplbmQtZW50aXR5LWNlcnQtY21zIA0KPiAgICAgICAgICAgICAgIHwgICAgICst
LS1uIGNlcnRpZmljYXRlLWV4cGlyYXRpb24NCj4gICAgICAgICAgICAgICB8ICAgICAgICArLS0g
ZXhwaXJhdGlvbi1kYXRlPyAgICAgICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQ0KPiAgICAgICAgICAg
ICAgICstLS14IGdlbmVyYXRlLWhpZGRlbi1rZXkNCj4gICAgICAgICAgICAgICB8ICArLS0tdyBp
bnB1dCAgICAgICAgICAgICAgICAgICAgICAgIC8vIFJFU1VMVCBJTiA8T1BFUkFUT05BTD4NCj4g
ICAgICAgICAgICAgICB8ICAgICArLS0tdyBuYW1lICAgICAgICAgICAgICAgICAgICAgIHN0cmlu
Zw0KPiAgICAgICAgICAgICAgIHwgICAgICstLS13IGFsZ29yaXRobSAgICAgICAgICAgICAgICAg
Y3Q6a2V5LWFsZ29yaXRobS1yZWYNCj4gICAgICAgICAgICAgICArLS0teCBsb2FkLWhpZGRlbi1r
ZXkNCj4gICAgICAgICAgICAgICB8ICArLS0tdyBpbnB1dCAgICAgICAgICAgICAgICAgICAgICAg
IC8vIFJFU1VMVCBJTiA8T1BFUkFUT05BTD4NCj4gICAgICAgICAgICAgICB8ICAgICArLS0tdyBu
YW1lICAgICAgICAgICAgICAgICAgICAgIHN0cmluZw0KPiAgICAgICAgICAgICAgIHwgICAgICst
LS13IGFsZ29yaXRobSAgICAgICAgICAgICAgICAgY3Q6a2V5LWFsZ29yaXRobS1yZWYNCj4gICAg
ICAgICAgICAgICB8ICAgICArLS0tdyBwdWJsaWMta2V5ICAgICAgICAgICAgICAgIGJpbmFyeQ0K
PiAgICAgICAgICAgICAgIHwgICAgICstLS13IHByaXZhdGUta2V5ICAgICAgICAgICAgICAgdW5p
b24NCj4gICAgICAgICAgICAgICArLS0teCBnZW5lcmF0ZS1jZXJ0aWZpY2F0ZS1zaWduaW5nLXJl
cXVlc3QNCj4gICAgICAgICAgICAgICAgICArLS0tdyBpbnB1dCAgICAgICAgICAgICAgICAgICAg
ICAgIC8vIEtFWSBNQVkgQkUgSU4gPE9QRVJBVE9OQUw+DQo+ICAgICAgICAgICAgICAgICAgfCAg
Ky0tLXcgc3ViamVjdCAgICAgICAgICAgICAgICAgICBiaW5hcnkNCj4gICAgICAgICAgICAgICAg
ICB8ICArLS0tdyBhdHRyaWJ1dGVzPyAgICAgICAgICAgICAgIGJpbmFyeQ0KPiAgICAgICAgICAg
ICAgICAgICstLXJvIG91dHB1dA0KPiAgICAgICAgICAgICAgICAgICAgICstLXJvIGNlcnRpZmlj
YXRlLXNpZ25pbmctcmVxdWVzdCAgICBiaW5hcnkNCj4gDQo+IA0KPiANCj4gDQo+IEtlbnQgLy8g
Y29udHJpYnV0b3INCj4gDQo+IA0KPiANCg0KDQo=


From nobody Tue Sep 18 11:57:19 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC391252B7 for ; Tue, 18 Sep 2018 11:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 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_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hubler-us.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEdd3TR0K8Ew for ; Tue, 18 Sep 2018 11:57:15 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 DD3DF130E1C for ; Tue, 18 Sep 2018 11:57:12 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id 75-v6so2445930iou.11 for ; Tue, 18 Sep 2018 11:57:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hubler-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bvYEYRGnuYfrCNXF/3vdWnmsf4MSG+WaR71xUqeu9Ps=; b=Kn6QLNfOhOVMH1EA4epa57EsPS6MEY7IK+OWqbuXbJStGJZTwjGsNbpMO1bGRNPznZ J0EPlDuIMysqEy/4ije7muhDeYeIRtdn99JmQBmyNuYgy3Ucq1tdO9Np7ZJ91wuo5jgK AjVMZxrx1qhfvl27TMw/uFTJwf6hoKCQWbJcMxBlNQu5wrHBhkBPceysHhdW4GlxAR6t J37BZHvvUlxcMhsAC8oog9NwCbYdinReBROISSEAW11tanBS7hohmbXO9My8+0kue1Hn SU8/4ItKPElsY9xA3SpGLYRttDi5G0h0l4fDy0zKAUfCUUlJLcz/+lNNpAwP6sjacolw eRKw==
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=bvYEYRGnuYfrCNXF/3vdWnmsf4MSG+WaR71xUqeu9Ps=; b=kDCb+SR4viQ/cLO0xMzFcBm9UBmEY7rHOYUzwbciOjDF29MR4y0EBEi4wGT0b9nZzA J1jZOHD4DOHqi+7+iaZQWIRT+Ot0Ys8UFxMZoBTjkPTMhmhh7lbVMJIT4cLlanSgJysC /9moKOvvrMBOVdQmXT+q07l3od2ge3jydMnnBeFpdbAPYwfqieCBO3+qvaSp6LbY0r7C EMGYXth+F5WtBz0DmxYIrWtFPIUAW8umPc0V363zcg6K/anejUS1HJt1Ad583rHDHCeT ces/ZYtJukbcxfwswIXc9ySb68+eD+zQieVs1rcnLUch3lojxBdUKug2xh8Cl7bRx7vO zqKw==
X-Gm-Message-State: APzg51CZzSwMM8x1Ee+5+BRjQXYNnFO4byBBXwxOgNfPRTorl9lakqSn 5X01d3Sf/wyuSeZU3X0qiRI2qCzRtag=
X-Google-Smtp-Source: ANB0Vdb735JDXz/LBptDlzy0cv8VNo7G2/4eS2fInfAEUWh/fzfxGhMyOyZdTzO17GKYjTwW/3DhnQ==
X-Received: by 2002:a5e:8408:: with SMTP id h8-v6mr25531995ioj.171.1537297025886;  Tue, 18 Sep 2018 11:57:05 -0700 (PDT)
Received: from mail-it0-f52.google.com (mail-it0-f52.google.com. [209.85.214.52]) by smtp.gmail.com with ESMTPSA id f64-v6sm3113513ite.4.2018.09.18.11.57.05 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Sep 2018 11:57:05 -0700 (PDT)
Received: by mail-it0-f52.google.com with SMTP id 139-v6so4451455itf.0 for ; Tue, 18 Sep 2018 11:57:05 -0700 (PDT)
X-Received: by 2002:a24:2e58:: with SMTP id i85-v6mr18128817ita.32.1537297025097;  Tue, 18 Sep 2018 11:57:05 -0700 (PDT)
MIME-Version: 1.0
References: <20180912.140109.1250692833398495223.mbj@tail-f.com>  <20180914.091120.602490077927092016.mbj@tail-f.com> <20180914071445.ywfnizh4rnzbrs4f@anna.jacobs.jacobs-university.de> 
In-Reply-To: 
From: Douglas Hubler 
Date: Tue, 18 Sep 2018 14:56:53 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Andy Bierman 
Cc: Juergen Schoenwaelder , Martin Bjorklund ,  "Eric Voit (evoit)" , Netconf 
Content-Type: multipart/alternative; boundary="000000000000187331057629db40"
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Sep 2018 18:57:17 -0000

--000000000000187331057629db40
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 17, 2018 at 12:23 PM Andy Bierman  wrote:

> It seems this draft could be renamed (e.g., s/RESTCONF/HTTP2/) since it
> does not use RESTCONF in any way.  I don't think RESTCONF notifications
> are used very much,
>

I make liberal use of them, it's become one of my biggest selling point of
RESTCONF over rolling your own REST API for management.


> but I don't see why the same SSE delivery of the  element
> would not work (e.g., different resource to GET for establish-subscription
> parameters)
>

I avoided implementing SSEs over HTTP/1.1  *because* I used a lot of
notifications and separate session for each subscription obviously doesn't
scale.  I went w/websockets for now with the idea I'd reimplement when a
reasonable draft is assembled.  I had hopes for SSE over HTTP/2 because
seems rather straightforward and in theory should scale.  Obviously with
websockets, my implementation doesn't interop w/other RESTCONF/NETCONF
systems/libs but hoping to change that with this draft.

I don't understand the details surrounding using an RPC to make a dynamic
subscription.  Unless it's optional, then I can start to understand.

Douglas
FreeConf.org

--000000000000187331057629db40
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Mon, Se=
p 17, 2018 at 12:23 PM Andy Bierman <andy@yumaworks.com> wrote:
I=
t seems this draft could be renamed (e.g., s/RESTCONF/HTTP2/) since it
does not use RESTCONF in any way.=C2=A0 I don't think RESTCONF no=
tifications
are used very much, 

I make liberal use of them, it's become one of =
my biggest selling point of RESTCONF over rolling your own REST API for man=
agement.
=C2=A0
but I don=
9;t see why the same SSE delivery of the <notification> element
=

would not work (e.g., different resource to GET for establish-subscrip=
tion parameters)

I =
avoided implementing SSEs over HTTP/1.1=C2=A0 *because* I used a lot of not=
ifications and separate session for each subscription obviously doesn't=
 scale.=C2=A0 I went w/websockets for now with the idea I'd reimplement=
 when a reasonable draft is assembled.=C2=A0 I had hopes for SSE over HTTP/=
2 because seems rather straightforward and in theory should scale.=C2=A0 Ob=
viously with websockets, my implementation doesn't interop w/other REST=
CONF/NETCONF systems/libs but hoping to change that with this draft.
<=
div>
I don't understand the details surrounding using an =
RPC to make a dynamic subscription.=C2=A0 Unless it's optional, then I =
can start to understand.

Douglas
FreeCon=
f.org
=C2=A0


--000000000000187331057629db40--


From nobody Tue Sep 18 12:40:29 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14790129619 for ; Tue, 18 Sep 2018 12:40:28 -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 2pQSBMrFbwcU for ; Tue, 18 Sep 2018 12:40:26 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E2B89120072 for ; Tue, 18 Sep 2018 12:40:25 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 2BBA41AE02BE; Tue, 18 Sep 2018 21:40:23 +0200 (CEST)
Date: Tue, 18 Sep 2018 21:40:22 +0200 (CEST)
Message-Id: <20180918.214022.2268667197465086195.mbj@tail-f.com>
To: douglas@hubler.us
Cc: andy@yumaworks.com, j.schoenwaelder@jacobs-university.de, evoit@cisco.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20180914071445.ywfnizh4rnzbrs4f@anna.jacobs.jacobs-university.de>  
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Sep 2018 19:40:28 -0000

Douglas Hubler  wrote:
> On Mon, Sep 17, 2018 at 12:23 PM Andy Bierman  wrote:
> 
> > It seems this draft could be renamed (e.g., s/RESTCONF/HTTP2/) since it
> > does not use RESTCONF in any way.  I don't think RESTCONF notifications
> > are used very much,
> >
> 
> I make liberal use of them, it's become one of my biggest selling point of
> RESTCONF over rolling your own REST API for management.
> 
> 
> > but I don't see why the same SSE delivery of the  element
> > would not work (e.g., different resource to GET for establish-subscription
> > parameters)
> >
> 
> I avoided implementing SSEs over HTTP/1.1  *because* I used a lot of
> notifications and separate session for each subscription obviously doesn't
> scale.  I went w/websockets for now with the idea I'd reimplement when a
> reasonable draft is assembled.  I had hopes for SSE over HTTP/2 because
> seems rather straightforward and in theory should scale.  Obviously with
> websockets, my implementation doesn't interop w/other RESTCONF/NETCONF
> systems/libs but hoping to change that with this draft.

So it seems you support my point to make this draft use SSE.  Then if
you use HTTP/2 you (the client) can simply create one HTTP/2 stream per
notification stream.  This just falls out for free with HTTP/2.

> I don't understand the details surrounding using an RPC to make a dynamic
> subscription.  Unless it's optional, then I can start to understand.

The client would POST to the "rpc" establish-subscripion, and in the
reply to the POST is a "location" leaf (*) that contains a URI.  The
client then GET this URI; this is the SSE event stream.

(*) in RFC 8040 it is called "location", in this draft it is called
"uri" 


/martin


From nobody Tue Sep 18 13:12:16 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DF0130E60 for ; Tue, 18 Sep 2018 13:12:15 -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 N8BqyKV7ZapI for ; Tue, 18 Sep 2018 13:12:12 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9F86812D7EA for ; Tue, 18 Sep 2018 13:12:12 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id A35ED1AE02BE; Tue, 18 Sep 2018 22:12:10 +0200 (CEST)
Date: Tue, 18 Sep 2018 22:12:10 +0200 (CEST)
Message-Id: <20180918.221210.1111111634668608576.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: balazs.kovacs@ericsson.com, balazs.lengyel@ericsson.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20180918.090227.98113334613843662.mbj@tail-f.com>  
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Sep 2018 20:12:16 -0000

Kent Watsen  wrote:
> =

> I like Martin's "twist" - I don't view it as an extreme hardship (the=

> 1% case), and I prefer (C) for supporting "require-instance true" as
> well as having one less action.  So, let's go with (C).
> =

> Martin, you mentioned some details might be wrong, are they wrong in
> (C)?  - I'd like to have it right when posting the next update...

Yes; in (C), "generate-hidden-key" and "load-hidden-key" doesn't take
"name" as input.


/martin


> Balazs, the desire to reference an IDevID could be from any
> SSH/TLS-based app, it would be hard to know in advance where.  No
> matter, with (C)+twist, we can have "require-instance true" always.
> =

> Kent // contributor
> =

> =

> -----Original Message-----
> =

> Hi,
> =

> I'd just emphasize that in creation step of hidden key, the name must=

> be coordinated between step A/1&2 by external application logic. Same=

> holds for deletion of hidden key for A/1&2. "Same name" is important.=

> =

> Enabling the possibility for 'require instance true' would be also
> good remark on the side of (C).
> =

> Regarding manufactured keys, I would not expect manufactured keys to
> be used in other common models, such as in TLS/SSH use cases. If they=

> have some specific use case, maybe those models could either have
> 'require instance false' or it could be said to create an empty key
> for them as Martin described.
> =

> Br,
> Balazs
> =

> -----Original Message-----
> From: Martin Bjorklund  =

> Sent: Tuesday, September 18, 2018 9:02 AM
> To: kwatsen@juniper.net
> Cc: Bal=E1zs Kov=E1cs ; Bal=E1zs Lengyel
> ; netconf@ietf.org
> Subject: Re: [Netconf] Mandatory local configuration in Keystore
> groupings
> =

> Hi,
> =

> Ok, so we have these two alternatives illustrated below.  There are
> some details that probably are wrong, but it doesn't really matter at=

> this stage.  With (A), there is one more action to control the
> lifespan of keys (delete-hidden-key).
> =

> In the case that the key is given as config, A and C works in the sam=
e
> way.
> =

> In the case that the key is permanent, A and C also works in the same=

> way.
> =

> A and C differ in how hidden keys are handled.
> =

> =

> In order to create a hidden key + certificate, the steps are:
> =

> A:  1. call generate-hidden-key with a given name
>     2. create an asymmetric-key with the same name in the config
>     3. call generate-certificate-signing-request
>     4. 
>     5. create the certificate in the config
> =

> (step 1 and 2 can be done in reverse order)
> =

> C   1. create an asymmetric-key in the config
>     2. call generate-hidden-key on this key
>     3. call generate-certificate-signing-request
>     4. 
>     5. create the certificate in the config
> =

> In order to delete a hidden key completely:
> =

> A:  1. call delete-hidden-key on the asymmetric-key to be deleted
>     2. delete the asymmetric-key from the config
> =

> C:  1. delete the asymmetric-key from the config
> =

> =

> =

> In summary, they are very similar.
> =

> One possible twist that probably works best for C could be to use
> leafrefs with require instance true, and say that in order to use a
> permanent key (created during manufacturing), you first need to creat=
e
> config for the key (more or less empty config).  The benefit is that
> we get proper leafref validation (no dangling pointers to handle in
> all other models).  FWIW, this is the approach taken in
> ietf-interfaces.
> =

> If we don't do this twist, I think that we can use either of A and C.=

> =

> =

> =

> /martin
> =

> =

> =

> =

> Kent Watsen  wrote:
> > =

> > > With (A), once you have generated the key, you first have to crea=
te
> > > the config for it, then invoke the action.   With (C) (99% of) th=
e =

> > > keys already exist in the config, so you can just invoke the acti=
on.
> > =

> > I don't follow.  What I see is that, with (A), a hidden key can be =

> > created with a single action invocation while, with (C), first a =

> > configuration operation is needed to create the "asymmetric-key"
> > (without the three leafs) followed by an action invocation (to =

> > populate the three leafs).
> > =

> > =

> > > To summarize, A and C both get the job done.  Which one is better=
 is =

> > > probably subjective.  I think (C) is might be easier to understan=
d.
> > =

> > Okay, let's see how it looks.  Bubbling all the ideas to the top, I=
 =

> > created the below tree-diagrams.  Note, in both cases, the three =

> > "mandatory true" leafs are replaced with an all-or-nothing "must"
> > expression:
> > =

> > =

> > (A) Uses RFC 8342 Section C.3.2 style config overlays for all hidde=
n
> > keys;
> >     and an action statement is used to delete all hidden keys.
> > =

> >      +--rw keystore
> >         +--rw asymmetric-keys
> >            +--rw asymmetric-key* [name]
> >            |  +--rw name                            string
> >            |  +--rw algorithm?                      ct:key-algorith=
m-ref
> >            |  +--rw public-key?                     binary
> >            |  +--rw private-key?                    union
> >            |  +---m "(algorithm and public-key and private-key)
> >            |  |       or not (algorithm or public-key or private-ke=
y)";
> >            |  +--rw certificates
> >            |  |  +--rw certificate* [name]
> >            |  |     +--rw name                      string
> >            |  |     +--rw cert                      ct:end-entity-c=
ert-cms
> >            |  |     +---n certificate-expiration
> >            |  |        +-- expiration-date?         yang:date-and-t=
ime
> >            |  +---x generate-certificate-signing-request
> >            |  |  +---w input // KEY MAY BE IN 
> >            |  |  |  +---w subject                   binary
> >            |  |  |  +---w attributes?               binary
> >            |  |  +--ro output
> >            |  |     +--ro certificate-signing-request    binary
> >            |  +---x delete-hidden-key
> >            |        // no params
> >            +---x generate-hidden-key
> >            |  +---w input                           // RESULT IN 
> >            |     +---w name                         string
> >            |     +---w algorithm                    ct:key-algorith=
m-ref
> >            +---x load-hidden-key
> >               +---w input                           // RESULT IN 
> >                  +---w name                         string
> >                  +---w algorithm                    ct:key-algorith=
m-ref
> >                  +---w public-key                   binary
> >                  +---w private-key                  union
> > =

> > =

> > (C) Uses RFC 8342 Section C.3.2 style config overlays only for hidd=
en
> > keys
> >     created in  (i.e., during manufacturing).  But if =
there
> >     is
> >     even just one key created during Manufacturing, and it doesn't =
appear
> >     in , then leafrefs still need to be "require-instance=

> >     false",
> >     right? Also, it seems that such keys could never be deleted, un=
like =

> >     other hidden keys, but that is probably okay (correct behavior)=
.=

> > =

> >      +--rw keystore
> >         +--rw asymmetric-keys
> >            +--rw asymmetric-key* [name]
> >               +--rw name                            string
> >               +--rw algorithm?                      ct:key-algorith=
m-ref
> >               +--rw public-key?                     binary
> >               +--rw private-key?                    union
> >               +---m "(algorithm and public-key and private-key)
> >               |       or not (algorithm or public-key or private-ke=
y)";
> >               +--rw certificates
> >               |  +--rw certificate* [name]
> >               |     +--rw name                      string
> >               |     +--rw cert                      ct:end-entity-c=
ert-cms =

> >               |     +---n certificate-expiration
> >               |        +-- expiration-date?         yang:date-and-t=
ime
> >               +---x generate-hidden-key
> >               |  +---w input                        // RESULT IN 
> >               |     +---w name                      string
> >               |     +---w algorithm                 ct:key-algorith=
m-ref
> >               +---x load-hidden-key
> >               |  +---w input                        // RESULT IN 
> >               |     +---w name                      string
> >               |     +---w algorithm                 ct:key-algorith=
m-ref
> >               |     +---w public-key                binary
> >               |     +---w private-key               union
> >               +---x generate-certificate-signing-request
> >                  +---w input // KEY MAY BE IN 
> >                  |  +---w subject                   binary
> >                  |  +---w attributes?               binary
> >                  +--ro output
> >                     +--ro certificate-signing-request    binary
> > =

> > =

> > =

> > =

> > Kent // contributor
> > =

> > =

> > =

> =

> =


From nobody Tue Sep 18 14:35:39 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048BE130E99 for ; Tue, 18 Sep 2018 14:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 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_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hubler-us.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3lb3PqcjG_K for ; Tue, 18 Sep 2018 14:35:35 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 276AA130E8C for ; Tue, 18 Sep 2018 14:35:35 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id y3-v6so2825620ioc.5 for ; Tue, 18 Sep 2018 14:35:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hubler-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+mIO6dgZZwNVUF23g64FV/j2vID4C9gmA/2WYkX4qLk=; b=NPHjkQYEfg5gBl/qNgjsAX/CxhNJ+wBEV/aajBlIHcWUv1byS4UCOIWXEY6ENMYT61 4SzgBU7/6RyqQ7j9+RNdZn9c/DPGNKEve8ezzPsdLcbf2Np8dsiZDSdXB5vd/EP6ZfaX BMcExQh3enp4gOBGcokFXVrcI5qWymkaJpkDpO6eTpwmiHiVkWPzJo9BIP1d0NU2Tw/L E8LYPZpc/8FPn1btQG5luywOJ8hlDRAAEjBk/jMH9cXTw2UkvCPHPt7xkKme9tfWPyxw kVjbGn/RMzKJCIIZWmOAOAN4hjzm14K6fvmD4HRAm37YgdgfI3zvG3uW7I6N49NZeSEQ LCgQ==
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=+mIO6dgZZwNVUF23g64FV/j2vID4C9gmA/2WYkX4qLk=; b=bdm4GpGnNkCWTXsDU++cQdy0IGsVjl5cGWULWNOi5u8YAamOoSX4j+e4zQDLenCPOl A0hT+yPjmLPUZRWn6ZlZ1gxxfhyqFdB0tvm58OpdUS/WVRBI96I70tjPrnOi6psz5tLH ak5s4+ePnO4XIhSe0lfYw1Taqn6akeqV2nn3qyWXG8WHtRMj1qnhwfNvmYMfTJqo/XzC pxB9rj1TnQS5oYu74EQWUbTWw/JV+v97LuqmqQrXxa/wE+asE2xFQ8urjYGIZYtnkR13 /C7JehJjlJLYLGA5ArrDcUcbuRAEH15MR3k8KVKsiTtyK1z1xonYlM9ARgnAgZvkZEqw SiFA==
X-Gm-Message-State: APzg51AJFAGQGOq1icB7fzQ0ODRLaFUiccLDszve7l3aZFX1Vxilca8u Lng4m75/Gubz4gj0K2XcXrZl1suholk=
X-Google-Smtp-Source: ANB0Vdbm/fWtaH5iTjZ/n7NfEKCXATrYr3zz94kkJbth35NI+ONZMGYn7CrP0BZcytEfgWEQs2ugkQ==
X-Received: by 2002:a6b:18c5:: with SMTP id 188-v6mr26246546ioy.211.1537306534307;  Tue, 18 Sep 2018 14:35:34 -0700 (PDT)
Received: from mail-it0-f41.google.com (mail-it0-f41.google.com. [209.85.214.41]) by smtp.gmail.com with ESMTPSA id a14-v6sm6703480ioh.45.2018.09.18.14.35.33 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Sep 2018 14:35:33 -0700 (PDT)
Received: by mail-it0-f41.google.com with SMTP id j81-v6so5502537ite.0 for ; Tue, 18 Sep 2018 14:35:33 -0700 (PDT)
X-Received: by 2002:a02:b517:: with SMTP id l23-v6mr29349452jaj.127.1537306533008;  Tue, 18 Sep 2018 14:35:33 -0700 (PDT)
MIME-Version: 1.0
References: <20180914071445.ywfnizh4rnzbrs4f@anna.jacobs.jacobs-university.de>   <20180918.214022.2268667197465086195.mbj@tail-f.com>
In-Reply-To: <20180918.214022.2268667197465086195.mbj@tail-f.com>
From: Douglas Hubler 
Date: Tue, 18 Sep 2018 17:35:21 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Martin Bjorklund 
Cc: andy@yumaworks.com, j.schoenwaelder@jacobs-university.de, evoit@cisco.com,  netconf@ietf.org
Content-Type: multipart/alternative; boundary="000000000000cf9df505762c11ba"
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Sep 2018 21:35:37 -0000

--000000000000cf9df505762c11ba
Content-Type: text/plain; charset="UTF-8"

On Tue, Sep 18, 2018 at 3:40 PM Martin Bjorklund  wrote:

> So it seems you support my point to make this draft use SSE.  Then if
> you use HTTP/2 you (the client) can simply create one HTTP/2 stream per
> notification stream.  This just falls out for free with HTTP/2.
>

yes, with caveat that I haven't attempted actual implementation yet.


>
> > I don't understand the details surrounding using an RPC to make a dynamic
> > subscription.  Unless it's optional, then I can start to understand.
>
> The client would POST to the "rpc" establish-subscripion, and in the
> reply to the POST is a "location" leaf (*) that contains a URI.  The
> client then GET this URI; this is the SSE event stream.
>

I see.  But if a client reads the YANG as

 module my-module {
    ...
    notification my-event {
    }
}

and client knew base stream URI was:

   /restconf/my-streams

Couldn't the client then deduce SSE URL as:

 GET  /restconf/my-streams/my-module:my-event?...

Thereby saving a trip to server?  Would it be wrong for a client to make
any assumptions?  I realize this ASSUMEs a transport protocol, but
could/would there be a one-time, capability check the client could make to
test for available transports?

I really appreciate your time explaining, I have been following the emails
best I could but I think some basic things are still eluding me.

--000000000000cf9df505762c11ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Tue, Se=
p 18, 2018 at 3:40 PM Martin Bjorklund <mbj@tail-f.com> wrote:
So =
it seems you support my point to make this draft use SSE.=C2=A0 Then if

you use HTTP/2 you (the client) can simply create one HTTP/2 stream per

notification stream.=C2=A0 This just falls out for free with HTTP/2.

yes, with caveat that I haven't attempted=
 actual implementation yet.=C2=A0
=C2=A0



> I don't understand the details surrounding using an RPC to make a =
dynamic

> subscription.=C2=A0 Unless it's optional, then I can start to unde=
rstand.



The client would POST to the "rpc" establish-subscripion, and in =
the

reply to the POST is a "location" leaf (*) that contains a URI.=
=C2=A0 The

client then GET this URI; this is the SSE event stream.

I see.=C2=A0 But if a client reads the YANG as
<=
br>
=C2=A0module my-module {
=C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 notification my-event {
=C2=A0 =C2=A0 }
}

and client knew base stream URI was:
=

=C2=A0 =C2=A0/restconf/my-streams

C=
ouldn't the client then deduce SSE URL as:

=C2=
=A0GET=C2=A0 /restconf/my-streams/my-module:my-event?...

=

Thereby saving a trip to server?=C2=A0 Would it be wrong for a c=
lient to make any assumptions?=C2=A0 I realize this ASSUMEs a transport pro=
tocol, but could/would there be a one-time, capability check the client cou=
ld make to test for available transports?

I really=
 appreciate your time explaining, I have been following the emails best I c=
ould but I think some basic things are still eluding me.



--000000000000cf9df505762c11ba--


From nobody Tue Sep 18 15:43:46 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9A6130E8A for ; Tue, 18 Sep 2018 15:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_HIGH=-0.01, 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 PXLSZivQJJI2 for ; Tue, 18 Sep 2018 15:43:41 -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 948B5130E28 for ; Tue, 18 Sep 2018 15:43:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16248; q=dns/txt; s=iport; t=1537310621; x=1538520221; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MT+QZ1thVa+yC+O93lvNUNxAKJ+qpDCvaGUzGz9eQns=; b=lpKXFuWXtkihn4T0N67mUx549tkRym+sZ2w5VIFDb21pqtNHeYAJXgTI B+UtNFUY1YJNdk371AfljxefYmU25aYZ9dw8n7U/KHHOKTS2T/5ul6f4W kSo3LkDbafKi6adiauoyr+R/WWOOpKl8aKrX3DO9kbnwQWXYSgE8BgyXp E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DFAAADf6Fb/4QNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJhTSplfygKg2iURYINkRGHNQuEbAIXgw8hOBQBAwEBAgE?= =?us-ascii?q?BAm0ohTgBAQEBAgEjCkoCBQsCAQgVEBoDAgICMBQRAgQBDQUIF4I3TIEdXAi?= =?us-ascii?q?kfIEuihCKbReBQT+BEoMShGgkKIJLglcCiCuFKo58CQKQFx+PFJRDAhEUgSU?= =?us-ascii?q?0IYFVcBWDJ4IlFxGOBm+MLoEeAQE?=
X-IronPort-AV: E=Sophos;i="5.53,391,1531785600";  d="scan'208,217";a="454064739"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2018 22:43:40 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w8IMheF9018961 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Sep 2018 22:43:40 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.1395.4; Tue, 18 Sep 2018 18:43:39 -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.1395.000; Tue, 18 Sep 2018 18:43:39 -0400
From: "Eric Voit (evoit)" 
To: Douglas Hubler , Martin Bjorklund 
CC: "andy@yumaworks.com" , "j.schoenwaelder@jacobs-university.de" , "netconf@ietf.org" 
Thread-Topic: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
Thread-Index: AQHUSpBZpYtwPWXE1k2ur9Y/QhScQaTs+hAAgAKoIwCAAAD0gIAFUEkAgAG9N4CAAAwmAIAAICCA//++5KA=
Date: Tue, 18 Sep 2018 22:43:39 +0000
Message-ID: <48e4aac958d142669f4032737cdc4373@XCH-RTP-013.cisco.com>
References: <20180914071445.ywfnizh4rnzbrs4f@anna.jacobs.jacobs-university.de>   <20180918.214022.2268667197465086195.mbj@tail-f.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.234]
Content-Type: multipart/alternative; boundary="_000_48e4aac958d142669f4032737cdc4373XCHRTP013ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Sep 2018 22:43:45 -0000

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

SGkgRG91Z2xhcywNCg0KRnJvbTogRG91Z2xhcyBIdWJsZXIsIFNlcHRlbWJlciAxOCwgMjAxOCA1
OjM1IFBNDQoNCg0KT24gVHVlLCBTZXAgMTgsIDIwMTggYXQgMzo0MCBQTSBNYXJ0aW4gQmpvcmts
dW5kIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+PiB3cm90ZToNClNvIGl0
IHNlZW1zIHlvdSBzdXBwb3J0IG15IHBvaW50IHRvIG1ha2UgdGhpcyBkcmFmdCB1c2UgU1NFLiAg
VGhlbiBpZg0KeW91IHVzZSBIVFRQLzIgeW91ICh0aGUgY2xpZW50KSBjYW4gc2ltcGx5IGNyZWF0
ZSBvbmUgSFRUUC8yIHN0cmVhbSBwZXINCm5vdGlmaWNhdGlvbiBzdHJlYW0uICBUaGlzIGp1c3Qg
ZmFsbHMgb3V0IGZvciBmcmVlIHdpdGggSFRUUC8yLg0KDQp5ZXMsIHdpdGggY2F2ZWF0IHRoYXQg
SSBoYXZlbid0IGF0dGVtcHRlZCBhY3R1YWwgaW1wbGVtZW50YXRpb24geWV0Lg0KDQo8RXJpYz4g
QWdyZWUgdGhhdCBTU0Ugb3ZlciBIVFRQMiBzaG91bGQgd29yay4gIEhvd2V2ZXIgdG8gbWUgdXNp
bmcgU1NFIGhlcmUgc2VlbXMgcmVkdW5kYW50IGFzIEhUVFAyIHByb3ZpZGVzIHRoZSBuZWNlc3Nh
cnkgbWVjaGFuaXNtcy4gIEJ1dCBJIHdvbuKAmXQgZ2V0IGluIHRoZSB3YXkgaWYgcGVvcGxlIHJl
YWxseSBkbyB3YW50IHRvIGdvIGluIHRoaXMgZGlyZWN0aW9uLg0KDQo+IEkgZG9uJ3QgdW5kZXJz
dGFuZCB0aGUgZGV0YWlscyBzdXJyb3VuZGluZyB1c2luZyBhbiBSUEMgdG8gbWFrZSBhIGR5bmFt
aWMNCj4gc3Vic2NyaXB0aW9uLiAgVW5sZXNzIGl0J3Mgb3B0aW9uYWwsIHRoZW4gSSBjYW4gc3Rh
cnQgdG8gdW5kZXJzdGFuZC4NCg0KVGhlIGNsaWVudCB3b3VsZCBQT1NUIHRvIHRoZSAicnBjIiBl
c3RhYmxpc2gtc3Vic2NyaXBpb24sIGFuZCBpbiB0aGUNCnJlcGx5IHRvIHRoZSBQT1NUIGlzIGEg
ImxvY2F0aW9uIiBsZWFmICgqKSB0aGF0IGNvbnRhaW5zIGEgVVJJLiAgVGhlDQpjbGllbnQgdGhl
biBHRVQgdGhpcyBVUkk7IHRoaXMgaXMgdGhlIFNTRSBldmVudCBzdHJlYW0uDQoNCkkgc2VlLiAg
QnV0IGlmIGEgY2xpZW50IHJlYWRzIHRoZSBZQU5HIGFzDQoNCiBtb2R1bGUgbXktbW9kdWxlIHsN
CiAgICAuLi4NCiAgICBub3RpZmljYXRpb24gbXktZXZlbnQgew0KICAgIH0NCn0NCg0KYW5kIGNs
aWVudCBrbmV3IGJhc2Ugc3RyZWFtIFVSSSB3YXM6DQoNCiAgIC9yZXN0Y29uZi9teS1zdHJlYW1z
DQoNCkNvdWxkbid0IHRoZSBjbGllbnQgdGhlbiBkZWR1Y2UgU1NFIFVSTCBhczoNCg0KIEdFVCAg
L3Jlc3Rjb25mL215LXN0cmVhbXMvbXktbW9kdWxlOm15LWV2ZW50Py4uLg0KDQpUaGVyZWJ5IHNh
dmluZyBhIHRyaXAgdG8gc2VydmVyPw0KDQo8RXJpYz4gWWVzLCBpdCB3b3VsZCBiZSBwb3NzaWJs
ZSB0byBzZXQgc29tZXRoaW5nIHVwIHRvIGRlZHVjZSB0aGUgVVJMLiAgZHJhZnQtaWV0Zi1uZXRj
b25mLXJlc3Rjb25mLW5vdGlmIGRvZXNu4oCZdCBjdXJyZW50bHkgYXR0ZW1wdCB0aGlzIGFzIGJl
aW5nIGFibGUgdG8gZGVkdWNlIHRoZSBVUkwgZG9lc27igJl0IHN0b3AgdGhlIGV4dHJhIHRyaXAg
dG8gdGhlIHNlcnZlci4NCg0KVGhlIHJlYXNvbiBpdCBkb2VzbuKAmXQgZ2V0IHJpZCBvZiB0aGUg
ZXh0cmEgcm91bmQgdHJpcCBoYXMgdG8gZG8gd2l0aCBIVFRQMiBzdHJlYW1zLiAgSWYgd2UgYXJl
IGdvaW5nIHRvIHVzZSBIVFRQMiwgdGhlcmUgaXMgc3RpbGwgYSBuZWVkIHRvIGluaXRpYXRlIHRo
ZSBHRVQgKG9yIFBPU1QpIGluIGEgc2VwYXJhdGUgc3RyZWFtIG90aGVyIHRoYW4gdGhlIG9uZSBi
ZWluZyB1c2VkIGZvciBSRVNUQ09ORiBzaWduYWxpbmcuDQoNClNvbWVvbmUgY291bGQgd3JpdGUg
YSBzcGVjaWZpY2F0aW9uIHdoaWNoIGdldHMgYXJvdW5kIHRoaXMgYnkgZm9yY2luZyBldmVyeSBS
RVNUQ09ORiB0cmFuc2FjdGlvbiBvbiBpdHMgb3duIEhUVFAyIHN0cmVhbS4gIEJ1dCBub2JvZHkg
aGFzIHByb3Bvc2VkIHN1Y2ggYSBzcGVjaWZpY2F0aW9uLiAgUGx1cyB0aGVyZSBhcmUgUW9TIHNj
ZW5hcmlvcyB3aGVyZSB5b3UgbWlnaHQgd2FudCBtdWx0aXBsZSBzdWJzY3JpcHRpb25zIG9uIHRo
ZSBzYW1lIEhUVFAyIHN0cmVhbS4gIFNvIGlmIHNvbWVvbmUgd2FudGVkIHRoaXMsIHdlIHdvdWxk
IHN0aWxsIG5lZWQgdG8gcmVmaW5lIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiBy
ZXF1aXJlbWVudHMgd2l0aCB0aGUgYWJpbGl0eSB0byBtb2RpZnkgb3IgZGVsZXRlIGFuIGV4aXN0
aW5nIHN1YnNjcmlwdGlvbiBvbiBhIGRpZmZlcmVudCBIVFRQMiBzdHJlYW0uICBUaGlzIGNvdWxk
IGJlIGRvbmUgb2YgY291cnNlLCBidXQgc29tZW9uZSB3b3VsZCBuZWVkIHRvIGRyaXZlIHRoZSBk
ZWZpbml0aW9uLg0KDQpFcmljDQoNCg0KV291bGQgaXQgYmUgd3JvbmcgZm9yIGEgY2xpZW50IHRv
IG1ha2UgYW55IGFzc3VtcHRpb25zPyAgSSByZWFsaXplIHRoaXMgQVNTVU1FcyBhIHRyYW5zcG9y
dCBwcm90b2NvbCwgYnV0IGNvdWxkL3dvdWxkIHRoZXJlIGJlIGEgb25lLXRpbWUsIGNhcGFiaWxp
dHkgY2hlY2sgdGhlIGNsaWVudCBjb3VsZCBtYWtlIHRvIHRlc3QgZm9yIGF2YWlsYWJsZSB0cmFu
c3BvcnRzPw0KDQpJIHJlYWxseSBhcHByZWNpYXRlIHlvdXIgdGltZSBleHBsYWluaW5nLCBJIGhh
dmUgYmVlbiBmb2xsb3dpbmcgdGhlIGVtYWlscyBiZXN0IEkgY291bGQgYnV0IEkgdGhpbmsgc29t
ZSBiYXNpYyB0aGluZ3MgYXJlIHN0aWxsIGVsdWRpbmcgbWUuDQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh
IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q
IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv
Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5r
LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1
ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl
cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww
LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh
bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl
OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K
CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh
Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb
ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i
ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91
dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi
bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgRG91Z2xhcyw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PiBEb3VnbGFzIEh1YmxlciwgU2VwdGVtYmVyIDE4LCAyMDE4IDU6MzUgUE08YnI+DQo8YnI+DQo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1
ZSwgU2VwIDE4LCAyMDE4IGF0IDM6NDAgUE0gTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0i
bWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGl0IHNlZW1zIHlvdSBzdXBwb3J0
IG15IHBvaW50IHRvIG1ha2UgdGhpcyBkcmFmdCB1c2UgU1NFLiZuYnNwOyBUaGVuIGlmPGJyPg0K
eW91IHVzZSBIVFRQLzIgeW91ICh0aGUgY2xpZW50KSBjYW4gc2ltcGx5IGNyZWF0ZSBvbmUgSFRU
UC8yIHN0cmVhbSBwZXI8YnI+DQpub3RpZmljYXRpb24gc3RyZWFtLiZuYnNwOyBUaGlzIGp1c3Qg
ZmFsbHMgb3V0IGZvciBmcmVlIHdpdGggSFRUUC8yLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1
b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+eWVzLCB3aXRoIGNhdmVhdCB0aGF0
IEkgaGF2ZW4ndCBhdHRlbXB0ZWQgYWN0dWFsIGltcGxlbWVudGF0aW9uIHlldC4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmx0O0VyaWMmZ3Q7IEFncmVlIHRoYXQg
U1NFIG92ZXIgSFRUUDIgc2hvdWxkIHdvcmsuJm5ic3A7IEhvd2V2ZXIgdG8gbWUgdXNpbmcgU1NF
IGhlcmUgc2VlbXMgcmVkdW5kYW50IGFzIEhUVFAyIHByb3ZpZGVzIHRoZSBuZWNlc3NhcnkgbWVj
aGFuaXNtcy4mbmJzcDsgQnV0IEkgd29u4oCZdCBnZXQgaW4gdGhlDQogd2F5IGlmIHBlb3BsZSBy
ZWFsbHkgZG8gd2FudCB0byBnbyBpbiB0aGlzIGRpcmVjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm
dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUg
ZGV0YWlscyBzdXJyb3VuZGluZyB1c2luZyBhbiBSUEMgdG8gbWFrZSBhIGR5bmFtaWM8YnI+DQom
Z3Q7IHN1YnNjcmlwdGlvbi4mbmJzcDsgVW5sZXNzIGl0J3Mgb3B0aW9uYWwsIHRoZW4gSSBjYW4g
c3RhcnQgdG8gdW5kZXJzdGFuZC48YnI+DQo8YnI+DQpUaGUgY2xpZW50IHdvdWxkIFBPU1QgdG8g
dGhlICZxdW90O3JwYyZxdW90OyBlc3RhYmxpc2gtc3Vic2NyaXBpb24sIGFuZCBpbiB0aGU8YnI+
DQpyZXBseSB0byB0aGUgUE9TVCBpcyBhICZxdW90O2xvY2F0aW9uJnF1b3Q7IGxlYWYgKCopIHRo
YXQgY29udGFpbnMgYSBVUkkuJm5ic3A7IFRoZTxicj4NCmNsaWVudCB0aGVuIEdFVCB0aGlzIFVS
STsgdGhpcyBpcyB0aGUgU1NFIGV2ZW50IHN0cmVhbS48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3
RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSBzZWUuJm5ic3A7IEJ1dCBpZiBhIGNsaWVudCByZWFkcyB0aGUgWUFO
RyBhczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDttb2R1bGUgbXktbW9kdWxlIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgLi4uPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IG5vdGlmaWNh
dGlvbiBteS1ldmVudCB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPn08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIGNsaWVudCBrbmV3IGJhc2Ugc3RyZWFtIFVSSSB3YXM6
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOyAmbmJzcDsvcmVzdGNvbmYvbXktc3RyZWFtczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db3VsZG4ndCB0aGUgY2xpZW50IHRoZW4gZGVk
dWNlIFNTRSBVUkwgYXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwO0dFVCZuYnNwOyAvcmVzdGNvbmYvbXktc3RyZWFtcy9teS1tb2R1
bGU6bXktZXZlbnQ/Li4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlRoZXJlYnkgc2F2aW5nIGEgdHJpcCB0byBzZXJ2ZXI/Jm5ic3A7IDxzcGFu
IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+Jmx0O0VyaWMmZ3Q7IFllcywgaXQgd291bGQgYmUgcG9zc2libGUgdG8gc2V0
IHNvbWV0aGluZyB1cCB0byBkZWR1Y2UgdGhlIFVSTC4mbmJzcDsgZHJhZnQtaWV0Zi1uZXRjb25m
LXJlc3Rjb25mLW5vdGlmIGRvZXNu4oCZdCBjdXJyZW50bHkgYXR0ZW1wdCB0aGlzIGFzIGJlaW5n
IGFibGUgdG8gZGVkdWNlDQogdGhlIFVSTCBkb2VzbuKAmXQgc3RvcCB0aGUgZXh0cmEgdHJpcCB0
byB0aGUgc2VydmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
VGhlIHJlYXNvbiBpdCBkb2VzbuKAmXQgZ2V0IHJpZCBvZiB0aGUgZXh0cmEgcm91bmQgdHJpcCBo
YXMgdG8gZG8gd2l0aCBIVFRQMiBzdHJlYW1zLiZuYnNwOyBJZiB3ZSBhcmUgZ29pbmcgdG8gdXNl
IEhUVFAyLCB0aGVyZSBpcyBzdGlsbCBhIG5lZWQgdG8gaW5pdGlhdGUgdGhlIEdFVCAob3INCiBQ
T1NUKSBpbiBhIHNlcGFyYXRlIHN0cmVhbSBvdGhlciB0aGFuIHRoZSBvbmUgYmVpbmcgdXNlZCBm
b3IgUkVTVENPTkYgc2lnbmFsaW5nLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj5Tb21lb25lIGNvdWxkIHdyaXRlIGEgc3BlY2lmaWNhdGlvbiB3aGlj
aCBnZXRzIGFyb3VuZCB0aGlzIGJ5IGZvcmNpbmcgZXZlcnkgUkVTVENPTkYgdHJhbnNhY3Rpb24g
b24gaXRzIG93biBIVFRQMiBzdHJlYW0uJm5ic3A7IEJ1dCBub2JvZHkgaGFzIHByb3Bvc2VkIHN1
Y2ggYSBzcGVjaWZpY2F0aW9uLiZuYnNwOw0KIFBsdXMgdGhlcmUgYXJlIFFvUyBzY2VuYXJpb3Mg
d2hlcmUgeW91IG1pZ2h0IHdhbnQgbXVsdGlwbGUgc3Vic2NyaXB0aW9ucyBvbiB0aGUgc2FtZSBI
VFRQMiBzdHJlYW0uJm5ic3A7IFNvIGlmIHNvbWVvbmUgd2FudGVkIHRoaXMsIHdlIHdvdWxkIHN0
aWxsIG5lZWQgdG8gcmVmaW5lIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiByZXF1
aXJlbWVudHMgd2l0aCB0aGUgYWJpbGl0eSB0byBtb2RpZnkgb3IgZGVsZXRlIGFuIGV4aXN0aW5n
IHN1YnNjcmlwdGlvbg0KIG9uIGEgZGlmZmVyZW50IEhUVFAyIHN0cmVhbS4mbmJzcDsgVGhpcyBj
b3VsZCBiZSBkb25lIG9mIGNvdXJzZSwgYnV0IHNvbWVvbmUgd291bGQgbmVlZCB0byBkcml2ZSB0
aGUgZGVmaW5pdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PkVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIGl0IGJlIHdy
b25nIGZvciBhIGNsaWVudCB0byBtYWtlIGFueSBhc3N1bXB0aW9ucz8mbmJzcDsgSSByZWFsaXpl
IHRoaXMgQVNTVU1FcyBhIHRyYW5zcG9ydCBwcm90b2NvbCwgYnV0IGNvdWxkL3dvdWxkIHRoZXJl
IGJlIGEgb25lLXRpbWUsIGNhcGFiaWxpdHkgY2hlY2sgdGhlIGNsaWVudCBjb3VsZCBtYWtlIHRv
IHRlc3QgZm9yIGF2YWlsYWJsZSB0cmFuc3BvcnRzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHJlYWxseSBhcHByZWNpYXRlIHlvdXIgdGlt
ZSBleHBsYWluaW5nLCBJIGhhdmUgYmVlbiBmb2xsb3dpbmcgdGhlIGVtYWlscyBiZXN0IEkgY291
bGQgYnV0IEkgdGhpbmsgc29tZSBiYXNpYyB0aGluZ3MgYXJlIHN0aWxsIGVsdWRpbmcgbWUuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_48e4aac958d142669f4032737cdc4373XCHRTP013ciscocom_--


From nobody Tue Sep 18 20:06:57 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD36130E29 for ; Tue, 18 Sep 2018 20:06:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 3FgbNPRBN0LO for ; Tue, 18 Sep 2018 20:06:54 -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 BFADF130DFD for ; Tue, 18 Sep 2018 20:06:53 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [10.201.108.46]) by Forcepoint Email with ESMTP id 7B019676A5F3A for ; Wed, 19 Sep 2018 04:06:49 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 19 Sep 2018 04:06:50 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0399.000; Wed, 19 Sep 2018 11:06:45 +0800
From: Qin Wu 
To: "Eric Voit (evoit)" , Douglas Hubler , Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
Thread-Index: AQHUSpBgBUFGD5oy2kmpOilc7/EuyqTuKlmAgACurwCAAAD1gIAFUEkAgAG9NoCAAAwnAIAAICCAgAATFYCAAM5uAA==
Date: Wed, 19 Sep 2018 03:06:45 +0000
Message-ID: 
References: <20180914071445.ywfnizh4rnzbrs4f@anna.jacobs.jacobs-university.de>   <20180918.214022.2268667197465086195.mbj@tail-f.com>  <48e4aac958d142669f4032737cdc4373@XCH-RTP-013.cisco.com>
In-Reply-To: <48e4aac958d142669f4032737cdc4373@XCH-RTP-013.cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B04B16Cnkgeml513mbxchi_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2018 03:06:56 -0000

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

DQrlj5Hku7bkuro6IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIOS7
o+ihqCBFcmljIFZvaXQgKGV2b2l0KQ0K5Y+R6YCB5pe26Ze0OiAyMDE45bm0OeaciDE55pelIDY6
NDQNCuaUtuS7tuS6ujogRG91Z2xhcyBIdWJsZXI7IE1hcnRpbiBCam9ya2x1bmQNCuaKhOmAgTog
bmV0Y29uZkBpZXRmLm9yZw0K5Li76aKYOiBSZTogW05ldGNvbmZdIGFjdGl2YXRlLWNvbmZpZ3Vy
ZWQtc3ViZWNyaXB0aW9uIC0gV0dMQyBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMtMTYNCg0KSGkg
RG91Z2xhcywNCg0KRnJvbTogRG91Z2xhcyBIdWJsZXIsIFNlcHRlbWJlciAxOCwgMjAxOCA1OjM1
IFBNDQoNCk9uIFR1ZSwgU2VwIDE4LCAyMDE4IGF0IDM6NDAgUE0gTWFydGluIEJqb3JrbHVuZCA8
bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4gd3JvdGU6DQpTbyBpdCBzZWVt
cyB5b3Ugc3VwcG9ydCBteSBwb2ludCB0byBtYWtlIHRoaXMgZHJhZnQgdXNlIFNTRS4gIFRoZW4g
aWYNCnlvdSB1c2UgSFRUUC8yIHlvdSAodGhlIGNsaWVudCkgY2FuIHNpbXBseSBjcmVhdGUgb25l
IEhUVFAvMiBzdHJlYW0gcGVyDQpub3RpZmljYXRpb24gc3RyZWFtLiAgVGhpcyBqdXN0IGZhbGxz
IG91dCBmb3IgZnJlZSB3aXRoIEhUVFAvMi4NCg0KeWVzLCB3aXRoIGNhdmVhdCB0aGF0IEkgaGF2
ZW4ndCBhdHRlbXB0ZWQgYWN0dWFsIGltcGxlbWVudGF0aW9uIHlldC4NCg0KPEVyaWM+IEFncmVl
IHRoYXQgU1NFIG92ZXIgSFRUUDIgc2hvdWxkIHdvcmsuICBIb3dldmVyIHRvIG1lIHVzaW5nIFNT
RSBoZXJlIHNlZW1zIHJlZHVuZGFudCBhcyBIVFRQMiBwcm92aWRlcyB0aGUgbmVjZXNzYXJ5IG1l
Y2hhbmlzbXMuICBCdXQgSSB3b27igJl0IGdldCBpbiB0aGUgd2F5IGlmIHBlb3BsZSByZWFsbHkg
ZG8gd2FudCB0byBnbyBpbiB0aGlzIGRpcmVjdGlvbi4NCg0KW1Fpbl06IEhUVFAyIHByb3ZpZGVz
IFNlcnZlciBQdXNoIG1lY2hhbmlzbSBob3dldmVyIHRoZXJlIGFyZSBsb3RzIG9mIGRyYXdiYWNr
cywgdHlwaWNhbCBvbmUgaXMgU2VydmVyIFB1c2ggbWF5IGJlIGJsb2NrZWQsIHRoZXJlZm9yZSBI
VFRQMS4xKyBTU0UgaXMgZmF2b3JlZC4NCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBD
aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
OS4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLm1zb25v
cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z
b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K
CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bh
bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQ2hhcg0KCXtt
c28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L
5L2TO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp
emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN
CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk
aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5Y+R5Lu25Lq6PHNwYW4g
bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj4gTmV0Y29uZiBbbWFpbHRvOm5l
dGNvbmYtYm91bmNlc0BpZXRmLm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPuS7o+ihqCA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPkVyaWMg
Vm9pdCAoZXZvaXQpPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OuWui+S9kyI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw
YW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk65a6L5L2TIj4gMjAxODwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTrlrovkvZMiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj45PC9zcGFuPuac
iDxzcGFuIGxhbmc9IkVOLVVTIj4xOTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogNjo0
NDxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+
PHNwYW4gbGFuZz0iRU4tVVMiPiBEb3VnbGFzIEh1YmxlcjsgTWFydGluIEJqb3JrbHVuZDxicj4N
Cjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFu
Zz0iRU4tVVMiPiBuZXRjb25mQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxh
bmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbTmV0Y29uZl0g
YWN0aXZhdGUtY29uZmlndXJlZC1zdWJlY3JpcHRpb24gLSBXR0xDIHN1YnNjcmliZWQtbm90aWZp
Y2F0aW9ucy0xNjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgRG91Z2xhcyw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERvdWdsYXMgSHVibGVyLCBTZXB0
ZW1iZXIgMTgsDQogMjAxOCA1OjM1IFBNPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIj5PbiBUdWUsIFNlcCAxOCwgMjAxOCBhdCAzOjQwIFBNIE1hcnRpbiBCam9ya2x1bmQg
Jmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+bWJqQHRhaWwtZi5jb208L2E+Jmd0
OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt
IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
cmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiPlNvIGl0IHNlZW1zIHlvdSBzdXBwb3J0IG15IHBvaW50IHRvIG1ha2Ug
dGhpcyBkcmFmdCB1c2UgU1NFLiZuYnNwOyBUaGVuIGlmPGJyPg0KeW91IHVzZSBIVFRQLzIgeW91
ICh0aGUgY2xpZW50KSBjYW4gc2ltcGx5IGNyZWF0ZSBvbmUgSFRUUC8yIHN0cmVhbSBwZXI8YnI+
DQpub3RpZmljYXRpb24gc3RyZWFtLiZuYnNwOyBUaGlzIGp1c3QgZmFsbHMgb3V0IGZvciBmcmVl
IHdpdGggSFRUUC8yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiPnllcywgd2l0aCBjYXZlYXQgdGhhdCBJIGhhdmVuJ3QgYXR0ZW1wdGVkIGFj
dHVhbCBpbXBsZW1lbnRhdGlvbiB5ZXQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPiZsdDtFcmljJmd0OyBBZ3JlZSB0aGF0IFNTRSBvdmVyIEhUVFAyIHNob3VsZCB3
b3JrLiZuYnNwOyBIb3dldmVyIHRvIG1lIHVzaW5nIFNTRSBoZXJlIHNlZW1zIHJlZHVuZGFudCBh
cyBIVFRQMiBwcm92aWRlcyB0aGUgbmVjZXNzYXJ5IG1lY2hhbmlzbXMuJm5ic3A7IEJ1dCBJDQog
d29u4oCZdCBnZXQgaW4gdGhlIHdheSBpZiBwZW9wbGUgcmVhbGx5IGRvIHdhbnQgdG8gZ28gaW4g
dGhpcyBkaXJlY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1Fpbl06IEhUVFAyIHByb3ZpZGVzIFNlcnZl
ciBQdXNoIG1lY2hhbmlzbSBob3dldmVyIHRoZXJlIGFyZSBsb3RzIG9mIGRyYXdiYWNrcywgdHlw
aWNhbCBvbmUgaXMgU2VydmVyIFB1c2ggbWF5IGJlIGJsb2NrZWQsIHRoZXJlZm9yZSBIVFRQMS4x
JiM0MzsNCiBTU0UgaXMgZmF2b3JlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_B8F9A780D330094D99AF023C5877DABA9B04B16Cnkgeml513mbxchi_--


From nobody Tue Sep 18 23:38:14 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318D2130F66 for ; Tue, 18 Sep 2018 23:38: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, 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 H7qtTNptshvf for ; Tue, 18 Sep 2018 23:38:09 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A529912008A for ; Tue, 18 Sep 2018 23:38:09 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 5E69B1AE02EF; Wed, 19 Sep 2018 08:38:06 +0200 (CEST)
Date: Wed, 19 Sep 2018 08:38:05 +0200 (CEST)
Message-Id: <20180919.083805.1103902318002046181.mbj@tail-f.com>
To: evoit@cisco.com
Cc: douglas@hubler.us, andy@yumaworks.com, j.schoenwaelder@jacobs-university.de, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <48e4aac958d142669f4032737cdc4373@XCH-RTP-013.cisco.com>
References: <20180918.214022.2268667197465086195.mbj@tail-f.com>  <48e4aac958d142669f4032737cdc4373@XCH-RTP-013.cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2018 06:38:12 -0000

SGksDQoNCiJFcmljIFZvaXQgKGV2b2l0KSIgPGV2b2l0QGNpc2NvLmNvbT4gd3JvdGU6DQo+IEhp
IERvdWdsYXMsDQo+IA0KPiBGcm9tOiBEb3VnbGFzIEh1YmxlciwgU2VwdGVtYmVyIDE4LCAyMDE4
IDU6MzUgUE0NCj4gDQo+IA0KPiBPbiBUdWUsIFNlcCAxOCwgMjAxOCBhdCAzOjQwIFBNIE1hcnRp
biBCam9ya2x1bmQNCj4gPG1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT4+IHdy
b3RlOg0KPiBTbyBpdCBzZWVtcyB5b3Ugc3VwcG9ydCBteSBwb2ludCB0byBtYWtlIHRoaXMgZHJh
ZnQgdXNlIFNTRS4gIFRoZW4gaWYNCj4geW91IHVzZSBIVFRQLzIgeW91ICh0aGUgY2xpZW50KSBj
YW4gc2ltcGx5IGNyZWF0ZSBvbmUgSFRUUC8yIHN0cmVhbQ0KPiBwZXINCj4gbm90aWZpY2F0aW9u
IHN0cmVhbS4gIFRoaXMganVzdCBmYWxscyBvdXQgZm9yIGZyZWUgd2l0aCBIVFRQLzIuDQo+IA0K
PiB5ZXMsIHdpdGggY2F2ZWF0IHRoYXQgSSBoYXZlbid0IGF0dGVtcHRlZCBhY3R1YWwgaW1wbGVt
ZW50YXRpb24geWV0Lg0KPiANCj4gPEVyaWM+IEFncmVlIHRoYXQgU1NFIG92ZXIgSFRUUDIgc2hv
dWxkIHdvcmsuICBIb3dldmVyIHRvIG1lIHVzaW5nIFNTRQ0KPiBoZXJlIHNlZW1zIHJlZHVuZGFu
dCBhcyBIVFRQMiBwcm92aWRlcyB0aGUgbmVjZXNzYXJ5IG1lY2hhbmlzbXMuDQoNCkVyaWMsIGNh
biB5b3UgZXhwbGFpbiBob3cgdGhpcyB3b3VsZCB3b3JrIHcvbyBTU0U/ICBXaGljaCBtZWNoYW5p
c20gaW4NCkhUVFAvMiBhcmUgeW91IHJlZmVycmluZyB0bz8NCg0KPiBCdXQNCj4gSSB3b27igJl0
IGdldCBpbiB0aGUgd2F5IGlmIHBlb3BsZSByZWFsbHkgZG8gd2FudCB0byBnbyBpbiB0aGlzDQo+
IGRpcmVjdGlvbi4NCj4gDQo+ID4gSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBkZXRhaWxzIHN1cnJv
dW5kaW5nIHVzaW5nIGFuIFJQQyB0byBtYWtlIGENCj4gPiBkeW5hbWljDQo+ID4gc3Vic2NyaXB0
aW9uLiAgVW5sZXNzIGl0J3Mgb3B0aW9uYWwsIHRoZW4gSSBjYW4gc3RhcnQgdG8gdW5kZXJzdGFu
ZC4NCj4gDQo+IFRoZSBjbGllbnQgd291bGQgUE9TVCB0byB0aGUgInJwYyIgZXN0YWJsaXNoLXN1
YnNjcmlwaW9uLCBhbmQgaW4gdGhlDQo+IHJlcGx5IHRvIHRoZSBQT1NUIGlzIGEgImxvY2F0aW9u
IiBsZWFmICgqKSB0aGF0IGNvbnRhaW5zIGEgVVJJLiAgVGhlDQo+IGNsaWVudCB0aGVuIEdFVCB0
aGlzIFVSSTsgdGhpcyBpcyB0aGUgU1NFIGV2ZW50IHN0cmVhbS4NCj4gDQo+IEkgc2VlLiAgQnV0
IGlmIGEgY2xpZW50IHJlYWRzIHRoZSBZQU5HIGFzDQo+IA0KPiAgbW9kdWxlIG15LW1vZHVsZSB7
DQo+ICAgICAuLi4NCj4gICAgIG5vdGlmaWNhdGlvbiBteS1ldmVudCB7DQo+ICAgICB9DQo+IH0N
Cj4gDQo+IGFuZCBjbGllbnQga25ldyBiYXNlIHN0cmVhbSBVUkkgd2FzOg0KPiANCj4gICAgL3Jl
c3Rjb25mL215LXN0cmVhbXMNCj4gDQo+IENvdWxkbid0IHRoZSBjbGllbnQgdGhlbiBkZWR1Y2Ug
U1NFIFVSTCBhczoNCj4gDQo+ICBHRVQgIC9yZXN0Y29uZi9teS1zdHJlYW1zL215LW1vZHVsZTpt
eS1ldmVudD8uLi4NCg0KTm8uDQoNCldpdGggUkZDIDgwNDAsIHRoZSBTU0UgVVJMIGlzICJzdGFi
bGUiLCBhbmQgaWYgdGhlIGNsaWVudCBoYXMgcmVhZCBpdA0Kb252ZSwgaXQgZG9lc24ndCBoYXZl
IHRvIHJlYWQgaXQgYWdhaW4gKG1vZHVsbyBzb21lIGRlZmluaXRpb24gb2YNCiJzdGFibGUiKS4g
IFRoZSBjbGllbnQgY2FuIHBhc3MgYSBmaWx0ZXIgaW4gdGhlIEdFVCByZXF1ZXN0IGZvciB0aGUN
ClNTRSBzdHJlYW0uDQoNCldpdGggdGhlIG1lY2hhbmlzbSBpbiB0aGlzIGRyYWZ0LCB0aGUgU1NF
IFVSTCB3aWxsIHZhcnkgZm9yIGVhY2gNCnJlcXVlc3QgdGhhdCBoYXMgYSBkaWZmZXJlbnQgZmls
dGVyIChhdCBhIG1pbmltdW0pLCBzaW5jZSB0aGUgZmlsdGVyDQppcyBwYXNzZWQgYSBwYXJhbWV0
ZXIgdG8gImVzdGFibGlzaC1zdWJzY3JpcHRpb24iIGFuZCB0aGUgU1NFIFVSTCBpcw0Kc2VudCBi
YWNrIGluIHRoZSByZXBseSB0byAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIuICBXaXRoIHRoZSBT
U0UgVVJMLA0KdGhlIHNlcnZlciBtYXkgaGlkZSBzb21lIHN0YXRlIHRoYXQgY29ycmVzcG9uZHMg
dG8gdGhlIGZpbHRlciBwYXJhbXMNCmV0Yy4gIChOT1RFIHRoZSB3b3JkICptYXkqIGluIHRoZSBw
cmV2aW91cyBzZW50ZW5jZS4gIEEgc2VydmVyIGNvdWxkDQphcyB3ZWxsIHNlbmQgYmFjayBhIFNT
RSBVUkwgd2l0aCB0aGUgZmlsdGVyIHBhcmFtZXRlcnMgZW1iZWRkZWQgaW4gdGhlDQpVUkwuLi4p
DQoNClNvIGluIGdlbmVyYWwsIGEgY2xpZW50IGNhbm5vdCBhc3N1bWUgdGhhdCBpdCBjYW4gcmUt
dXNlIGEgU1NFIFVSTA0KdGhhdCB3YXMgcmV0dXJuZWQgZnJvbSBhIGNhbGwgdG8gImVzdGFibGlz
aC1zdWJzY3JpcHRpb24iLg0KDQo+IFRoZXJlYnkgc2F2aW5nIGEgdHJpcCB0byBzZXJ2ZXI/DQo+
IA0KPiA8RXJpYz4gWWVzLCBpdCB3b3VsZCBiZSBwb3NzaWJsZSB0byBzZXQgc29tZXRoaW5nIHVw
IHRvIGRlZHVjZSB0aGUNCj4gVVJMLiAgZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlm
IGRvZXNu4oCZdCBjdXJyZW50bHkgYXR0ZW1wdCB0aGlzDQo+IGFzIGJlaW5nIGFibGUgdG8gZGVk
dWNlIHRoZSBVUkwgZG9lc27igJl0IHN0b3AgdGhlIGV4dHJhIHRyaXAgdG8gdGhlDQo+IHNlcnZl
ci4NCj4gDQo+IFRoZSByZWFzb24gaXQgZG9lc27igJl0IGdldCByaWQgb2YgdGhlIGV4dHJhIHJv
dW5kIHRyaXAgaGFzIHRvIGRvIHdpdGgNCj4gSFRUUDIgc3RyZWFtcy4gIElmIHdlIGFyZSBnb2lu
ZyB0byB1c2UgSFRUUDIsIHRoZXJlIGlzIHN0aWxsIGEgbmVlZCB0bw0KPiBpbml0aWF0ZSB0aGUg
R0VUIChvciBQT1NUKSBpbiBhIHNlcGFyYXRlIHN0cmVhbSBvdGhlciB0aGFuIHRoZSBvbmUNCj4g
YmVpbmcgdXNlZCBmb3IgUkVTVENPTkYgc2lnbmFsaW5nLg0KDQpJIGRpc2FncmVlLiAgSWYgdGhl
IGNsaWVudCB3YW50cyB0byBoYXZlIGEgc2VwYXJhdGUgSFRUUC8yIHN0cmVhbSBmb3INCnRoZSBu
b3RpZnMsIHRoZW4gaXQgc2hvdWxkIHN0YXJ0IHN1Y2ggYSBzdHJlYW0uICBJZiB0aGUgY2xpZW50
IGRvZXNuJ3QNCndhbnQgYSBzZXBhcmF0ZSBIVFRQLzIgc3RyZWFtIHRoZW4gdGhhdCBzaG91bGQg
YmUgb2sgdG9vLg0KDQpDb21wYXJlIHRvIE5FVENPTkYuICBIVFRQLzIgc3RyZWFtcyBhcmUgc2lt
aWxhciB0byBTU0ggY2hhbm5lbHMuICBBDQpORVRDT05GIGNsaWVudCBjYW4gb3BlbiBhIHNlcGFy
YXRlIFNTSCBjaGFubmVsIGZvciBlYWNoIHN1YnNjcmlwdGlvbiwNCm9yIGl0IGNhbiB1c2UgYSBz
aW5nbGUgY2hhbm5lbC4gIFVwIHRvIHRoZSBjbGllbnQuDQoNCj4gU29tZW9uZSBjb3VsZCB3cml0
ZSBhIHNwZWNpZmljYXRpb24gd2hpY2ggZ2V0cyBhcm91bmQgdGhpcyBieSBmb3JjaW5nDQo+IGV2
ZXJ5IFJFU1RDT05GIHRyYW5zYWN0aW9uIG9uIGl0cyBvd24gSFRUUDIgc3RyZWFtLiAgQnV0IG5v
Ym9keSBoYXMNCj4gcHJvcG9zZWQgc3VjaCBhIHNwZWNpZmljYXRpb24uICBQbHVzIHRoZXJlIGFy
ZSBRb1Mgc2NlbmFyaW9zIHdoZXJlIHlvdQ0KPiBtaWdodCB3YW50IG11bHRpcGxlIHN1YnNjcmlw
dGlvbnMgb24gdGhlIHNhbWUgSFRUUDIgc3RyZWFtLg0KDQpIb3cgd291bGQgdGhpcyB3b3JrPyAg
T25jZSB5b3Ugc3RhcnQgU1NFIG9uIGEgc3RyZWFtLCB0aGF0IHN0cmVhbSBpcw0KImJsb2NrZWQi
LCByaWdodD8NCg0KPiBTbyBpZg0KPiBzb21lb25lIHdhbnRlZCB0aGlzLCB3ZSB3b3VsZCBzdGls
bCBuZWVkIHRvIHJlZmluZQ0KPiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYgcmVx
dWlyZW1lbnRzIHdpdGggdGhlIGFiaWxpdHkgdG8NCj4gbW9kaWZ5IG9yIGRlbGV0ZSBhbiBleGlz
dGluZyBzdWJzY3JpcHRpb24gb24gYSBkaWZmZXJlbnQgSFRUUDIgc3RyZWFtLg0KDQpJc24ndCB0
aGlzIGhvdyBpdCBpcyBzdXBwb3NlZCB0byB3b3JrPyAgVGhlIGRyYWZ0IGlzIHNpbGVudCBvbiBo
b3cgdG8NCmRlbGV0ZSBhIHN1YnNjcmlwdGlvbiwgYW5kIGFsc28gb24gaG93IG1vZGlmeS1zdWJz
Y3JpcHRpb24gaXMgc3VwcG9zZWQNCnRvIHdvcmsuDQoNClRoZSBkcmFmdCBpcyBhbHNvIHNpbGVu
dCBvbiB0aGUgbGlmZXRpbWUgb2YgdGhlIHJlc3VsdCBvZg0KImVzdGFibGlzaC1zdWJzY3JpcHRp
b24iLiAgV2l0aCBORVRDT05GLCB0aGUgc3Vic2NyaXB0aW9uIGVuZHMgaWYgdGhlDQpzZXNzaW9u
IGVuZHMsIGJ1dCBpbiBSRVNUQ09ORiB0aGVyZSBhcmUgbm8gc2Vzc2lvbnMsIHNvIGhvdyBsb25n
IGRvZXMNCnRoZSBzdWJzY3JpcHRpb24gbGl2ZSBhZnRlciBpdCBoYXMgYmVlbiBjcmVhdGVkPw0K
DQpOb3RlIHRoYXQgdGhlIGFwcHJvYWNoIGluIFJGQyA4MDQwIGlzIGRvZXNuJ3QgaGF2ZSB0aGlz
IGlzc3VlLg0KDQoNCi9tYXJ0aW4NCg0KDQo+IFRoaXMgY291bGQgYmUgZG9uZSBvZiBjb3Vyc2Us
IGJ1dCBzb21lb25lIHdvdWxkIG5lZWQgdG8gZHJpdmUgdGhlDQo+IGRlZmluaXRpb24uDQo+IA0K
PiBFcmljDQo+IA0KPiANCj4gV291bGQgaXQgYmUgd3JvbmcgZm9yIGEgY2xpZW50IHRvIG1ha2Ug
YW55IGFzc3VtcHRpb25zPyAgSSByZWFsaXplDQo+IHRoaXMgQVNTVU1FcyBhIHRyYW5zcG9ydCBw
cm90b2NvbCwgYnV0IGNvdWxkL3dvdWxkIHRoZXJlIGJlIGENCj4gb25lLXRpbWUsIGNhcGFiaWxp
dHkgY2hlY2sgdGhlIGNsaWVudCBjb3VsZCBtYWtlIHRvIHRlc3QgZm9yIGF2YWlsYWJsZQ0KPiB0
cmFuc3BvcnRzPw0KPiANCj4gSSByZWFsbHkgYXBwcmVjaWF0ZSB5b3VyIHRpbWUgZXhwbGFpbmlu
ZywgSSBoYXZlIGJlZW4gZm9sbG93aW5nIHRoZQ0KPiBlbWFpbHMgYmVzdCBJIGNvdWxkIGJ1dCBJ
IHRoaW5rIHNvbWUgYmFzaWMgdGhpbmdzIGFyZSBzdGlsbCBlbHVkaW5nDQo+IG1lLg0KPiANCg==


From nobody Wed Sep 19 00:25:29 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE548130F89 for ; Wed, 19 Sep 2018 00:25:27 -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 zVOEFM786SEd for ; Wed, 19 Sep 2018 00:25:26 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 36194130F41 for ; Wed, 19 Sep 2018 00:25:26 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C8711AE02EF; Wed, 19 Sep 2018 09:25:23 +0200 (CEST)
Date: Wed, 19 Sep 2018 09:25:22 +0200 (CEST)
Message-Id: <20180919.092522.1558587282279688362.mbj@tail-f.com>
To: bill.wu@huawei.com
Cc: evoit=40cisco.com@dmarc.ietf.org, douglas@hubler.us, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <48e4aac958d142669f4032737cdc4373@XCH-RTP-013.cisco.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2018 07:25:28 -0000

UWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4g5Y+R5Lu25Lq6OiBOZXRj
b25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSDku6PooaggRXJpYyBWb2l0DQo+
IChldm9pdCkNCj4g5Y+R6YCB5pe26Ze0OiAyMDE45bm0OeaciDE55pelIDY6NDQNCj4g5pS25Lu2
5Lq6OiBEb3VnbGFzIEh1YmxlcjsgTWFydGluIEJqb3JrbHVuZA0KPiDmioTpgIE6IG5ldGNvbmZA
aWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW05ldGNvbmZdIGFjdGl2YXRlLWNvbmZpZ3VyZWQtc3Vi
ZWNyaXB0aW9uIC0gV0dMQw0KPiBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMtMTYNCj4gDQo+IEhp
IERvdWdsYXMsDQo+IA0KPiBGcm9tOiBEb3VnbGFzIEh1YmxlciwgU2VwdGVtYmVyIDE4LCAyMDE4
IDU6MzUgUE0NCj4gDQo+IE9uIFR1ZSwgU2VwIDE4LCAyMDE4IGF0IDM6NDAgUE0gTWFydGluIEJq
b3JrbHVuZA0KPiA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4gd3JvdGU6
DQo+IFNvIGl0IHNlZW1zIHlvdSBzdXBwb3J0IG15IHBvaW50IHRvIG1ha2UgdGhpcyBkcmFmdCB1
c2UgU1NFLiAgVGhlbiBpZg0KPiB5b3UgdXNlIEhUVFAvMiB5b3UgKHRoZSBjbGllbnQpIGNhbiBz
aW1wbHkgY3JlYXRlIG9uZSBIVFRQLzIgc3RyZWFtDQo+IHBlcg0KPiBub3RpZmljYXRpb24gc3Ry
ZWFtLiAgVGhpcyBqdXN0IGZhbGxzIG91dCBmb3IgZnJlZSB3aXRoIEhUVFAvMi4NCj4gDQo+IHll
cywgd2l0aCBjYXZlYXQgdGhhdCBJIGhhdmVuJ3QgYXR0ZW1wdGVkIGFjdHVhbCBpbXBsZW1lbnRh
dGlvbiB5ZXQuDQo+IA0KPiA8RXJpYz4gQWdyZWUgdGhhdCBTU0Ugb3ZlciBIVFRQMiBzaG91bGQg
d29yay4gIEhvd2V2ZXIgdG8gbWUgdXNpbmcgU1NFDQo+IGhlcmUgc2VlbXMgcmVkdW5kYW50IGFz
IEhUVFAyIHByb3ZpZGVzIHRoZSBuZWNlc3NhcnkgbWVjaGFuaXNtcy4gIEJ1dA0KPiBJIHdvbuKA
mXQgZ2V0IGluIHRoZSB3YXkgaWYgcGVvcGxlIHJlYWxseSBkbyB3YW50IHRvIGdvIGluIHRoaXMN
Cj4gZGlyZWN0aW9uLg0KPiANCj4gW1Fpbl06IEhUVFAyIHByb3ZpZGVzIFNlcnZlciBQdXNoIG1l
Y2hhbmlzbSBob3dldmVyIHRoZXJlIGFyZSBsb3RzIG9mDQo+IGRyYXdiYWNrcywgdHlwaWNhbCBv
bmUgaXMgU2VydmVyIFB1c2ggbWF5IGJlIGJsb2NrZWQsIHRoZXJlZm9yZQ0KPiBIVFRQMS4xKyBT
U0UgaXMgZmF2b3JlZC4NCg0KQnV0IEhUVFAvMiBzZXJ2ZXIgcHVzaCBkb2Vzbid0IGV2ZW4gYWRk
cmVzcyB0aGUgc2FtZSBwcm9ibGVtOyBob3cgdG8NCmdldCBhIHN0cmVhbSBvZiBub3RpZnMgc2Vu
dCBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIGNsaWVudC4gIElmIEknbSBub3QNCm1pc3Rha2VuLCBz
ZXJ2ZXIgcHVzaCBjb3VsZCBiZSBkb25lIHcvIHRoZSBHRVQgb2YgdGhlIFNTRSBzdHJlYW0sDQpz
byBtYXliZSBzZXJ2ZXIgcHVzaCBjb3VsZCBiZSB1c2VkIHRvIGF2b2lkIHRoZSByb3VuZCB0cmlw
Og0KDQogICAgY2xpZW50ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VydmVyDQogICAg
LS0tLS0tICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tDQogICAgICB8ICAgICAg
ZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiAgICANCiAgICAgIHwgICAgICAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0+ICAgIHwNCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHwNCiAgICAgIHwgICAgICAgICBPSywgbG9jYXRpb249U1NFIFVSTCAgICAgIHwNCiAgICAgIHwg
ICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgIHwNCiAgICAgIHwgICAgICAgICBQVVNI
X1BST01JU0UsICAgICAgICAgICAgIHwNCiAgICAgIHwgICAgICAgICAgIG5ldyBzdHJlYW0sIFNT
RSBVUkwgICAgIHwNCiAgICAgIHwgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgIHwN
CiAgICAgIHwgICAgICAgICAgIFNTRSBldmVudCAobm90aWYpICAgICAgIHwNCiAgICAgIHwgICAg
ICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgIHwNCiAgICAgIHwgICAgICAgICAgIFNTRSBl
dmVudCAobm90aWYpICAgICAgIHwNCiAgICAgIHwgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tICAgIHwNCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg
ICAgICAgICAgIA0KDQoNCi9tYXJ0aW4NCg==


From nobody Wed Sep 19 01:36:56 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129A2130FCA for ; Wed, 19 Sep 2018 01:36:55 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1VAj1keOoT5 for ; Wed, 19 Sep 2018 01:36:54 -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 DEA80130F88 for ; Wed, 19 Sep 2018 01:36:53 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 100BBE1318098 for ; Wed, 19 Sep 2018 09:36:49 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 19 Sep 2018 09:36:50 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0399.000; Wed, 19 Sep 2018 16:36:46 +0800
From: Qin Wu 
To: Martin Bjorklund 
CC: "evoit=40cisco.com@dmarc.ietf.org" , "douglas@hubler.us" , "netconf@ietf.org" 
Thread-Topic: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
Thread-Index: AQHUSpBgBUFGD5oy2kmpOilc7/EuyqTuKlmAgACurwCAAAD1gIAFUEkAgAG9NoCAAAwnAIAAICCAgAATFYCAAM5uAP//w1YAgACXhhA=
Date: Wed, 19 Sep 2018 08:36:46 +0000
Message-ID: 
References:  <48e4aac958d142669f4032737cdc4373@XCH-RTP-013.cisco.com>  <20180919.092522.1558587282279688362.mbj@tail-f.com>
In-Reply-To: <20180919.092522.1558587282279688362.mbj@tail-f.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2018 08:36:55 -0000

DQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogTWFydGluIEJqb3JrbHVuZCBb
bWFpbHRvOm1iakB0YWlsLWYuY29tXSANCuWPkemAgeaXtumXtDogMjAxOOW5tDnmnIgxOeaXpSAx
NToyNQ0K5pS25Lu25Lq6OiBRaW4gV3UNCuaKhOmAgTogZXZvaXQ9NDBjaXNjby5jb21AZG1hcmMu
aWV0Zi5vcmc7IGRvdWdsYXNAaHVibGVyLnVzOyBuZXRjb25mQGlldGYub3JnDQrkuLvpopg6IFJl
OiBbTmV0Y29uZl0gYWN0aXZhdGUtY29uZmlndXJlZC1zdWJlY3JpcHRpb24gLSBXR0xDIHN1YnNj
cmliZWQtbm90aWZpY2F0aW9ucy0xNg0KDQpRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4gd3Jv
dGU6DQo+IA0KPiDlj5Hku7bkuro6IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0
Zi5vcmddIOS7o+ihqCBFcmljIFZvaXQNCj4gKGV2b2l0KQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTjl
ubQ55pyIMTnml6UgNjo0NA0KPiDmlLbku7bkuro6IERvdWdsYXMgSHVibGVyOyBNYXJ0aW4gQmpv
cmtsdW5kDQo+IOaKhOmAgTogbmV0Y29uZkBpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBbTmV0Y29u
Zl0gYWN0aXZhdGUtY29uZmlndXJlZC1zdWJlY3JpcHRpb24gLSBXR0xDDQo+IHN1YnNjcmliZWQt
bm90aWZpY2F0aW9ucy0xNg0KPiANCj4gSGkgRG91Z2xhcywNCj4gDQo+IEZyb206IERvdWdsYXMg
SHVibGVyLCBTZXB0ZW1iZXIgMTgsIDIwMTggNTozNSBQTQ0KPiANCj4gT24gVHVlLCBTZXAgMTgs
IDIwMTggYXQgMzo0MCBQTSBNYXJ0aW4gQmpvcmtsdW5kIA0KPiA8bWJqQHRhaWwtZi5jb208bWFp
bHRvOm1iakB0YWlsLWYuY29tPj4gd3JvdGU6DQo+IFNvIGl0IHNlZW1zIHlvdSBzdXBwb3J0IG15
IHBvaW50IHRvIG1ha2UgdGhpcyBkcmFmdCB1c2UgU1NFLiAgVGhlbiBpZiANCj4geW91IHVzZSBI
VFRQLzIgeW91ICh0aGUgY2xpZW50KSBjYW4gc2ltcGx5IGNyZWF0ZSBvbmUgSFRUUC8yIHN0cmVh
bSANCj4gcGVyIG5vdGlmaWNhdGlvbiBzdHJlYW0uICBUaGlzIGp1c3QgZmFsbHMgb3V0IGZvciBm
cmVlIHdpdGggSFRUUC8yLg0KPiANCj4geWVzLCB3aXRoIGNhdmVhdCB0aGF0IEkgaGF2ZW4ndCBh
dHRlbXB0ZWQgYWN0dWFsIGltcGxlbWVudGF0aW9uIHlldC4NCj4gDQo+IDxFcmljPiBBZ3JlZSB0
aGF0IFNTRSBvdmVyIEhUVFAyIHNob3VsZCB3b3JrLiAgSG93ZXZlciB0byBtZSB1c2luZyBTU0Ug
DQo+IGhlcmUgc2VlbXMgcmVkdW5kYW50IGFzIEhUVFAyIHByb3ZpZGVzIHRoZSBuZWNlc3Nhcnkg
bWVjaGFuaXNtcy4gIEJ1dCANCj4gSSB3b27igJl0IGdldCBpbiB0aGUgd2F5IGlmIHBlb3BsZSBy
ZWFsbHkgZG8gd2FudCB0byBnbyBpbiB0aGlzIA0KPiBkaXJlY3Rpb24uDQo+IA0KPiBbUWluXTog
SFRUUDIgcHJvdmlkZXMgU2VydmVyIFB1c2ggbWVjaGFuaXNtIGhvd2V2ZXIgdGhlcmUgYXJlIGxv
dHMgb2YgDQo+IGRyYXdiYWNrcywgdHlwaWNhbCBvbmUgaXMgU2VydmVyIFB1c2ggbWF5IGJlIGJs
b2NrZWQsIHRoZXJlZm9yZSANCj4gSFRUUDEuMSsgU1NFIGlzIGZhdm9yZWQuDQoNCkJ1dCBIVFRQ
LzIgc2VydmVyIHB1c2ggZG9lc24ndCBldmVuIGFkZHJlc3MgdGhlIHNhbWUgcHJvYmxlbTsgaG93
IHRvIGdldCBhIHN0cmVhbSBvZiBub3RpZnMgc2VudCBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIGNs
aWVudC4gIElmIEknbSBub3QgbWlzdGFrZW4sIHNlcnZlciBwdXNoIGNvdWxkIGJlIGRvbmUgdy8g
dGhlIEdFVCBvZiB0aGUgU1NFIHN0cmVhbSwgc28gbWF5YmUgc2VydmVyIHB1c2ggY291bGQgYmUg
dXNlZCB0byBhdm9pZCB0aGUgcm91bmQgdHJpcDoNCg0KICAgIGNsaWVudCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHNlcnZlcg0KICAgIC0tLS0tLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIC0tLS0tLQ0KICAgICAgfCAgICAgIGVzdGFibGlzaC1zdWJzY3JpcHRpb24gICAgDQog
ICAgICB8ICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPiAgICB8DQogICAgICB8ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICB8ICAgICAgICAgT0ssIGxvY2F0
aW9uPVNTRSBVUkwgICAgICB8DQogICAgICB8ICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LSAgICB8DQogICAgICB8ICAgICAgICAgUFVTSF9QUk9NSVNFLCAgICAgICAgICAgICB8DQogICAg
ICB8ICAgICAgICAgICBuZXcgc3RyZWFtLCBTU0UgVVJMICAgICB8DQogICAgICB8ICAgICAgPC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgICB8DQogICAgICB8ICAgICAgICAgICBTU0UgZXZlbnQg
KG5vdGlmKSAgICAgICB8DQogICAgICB8ICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAg
ICB8DQogICAgICB8ICAgICAgICAgICBTU0UgZXZlbnQgKG5vdGlmKSAgICAgICB8DQogICAgICB8
ICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgICB8DQogICAgICB8ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICANCltRaW5dOiBZZXMsIEhUVFAv
MiBzZXJ2ZXIgcHVzaCBjYW4gc2F2ZSByb3VuZCB0cmlwLCBidXQgaWYgSFRUUC8yIHNlcnZlciBw
dXNoIGlzIHVzZWQsIHR3byBjaGFubmVscyBuZWVkIHRvIGJlIGVzdGFibGlzaGVkLCBvbmUgZm9y
IGVzdGFibGlzaC1zdWJzY3JpcHRpb24sDQpPbmUgZm9yIEhUVFAvMiBTZXJ2ZXIgUHVzaCwgbm90
IHN1cmUgdGhlIHNlcXVlbmNlIG9mIHdvcmsgZmxvdyBoZXJlIGlzIGNvcnJlY3QsIGZpcnN0IGhv
dyBkb2VzIGVzdGFibGlzaC1zdWJzY3JpcHRpb24gUlBDIGluZGljYXRlIHNlcnZlciBwdXNoIHN1
cHBvcnQsIGhvdyBkb2VzIHNlcnZlciBrbm93IHNlcnZlciBwdXNoIHNob3VsZCBiZSB1c2VkIGZv
ciByZXNwb25zZS4NClNlY29uZCwgU1NFIGV2ZW50IGFuZCBPSywgUFVTSC1QUk9NSVNFIHNob3Vs
ZCBiZSBlc3RhYmxpc2hlZCBpbiBhbm90aGVyIGNoYW5uZWwgb3IgSFRUUCBjb25uZWN0aW9uPw0K
DQpIVFRQIHNlcnZlciBwdXNoIGhhcyB0d28gdHlwaWNhbCBkcmF3YmFja3M6DQoxLiBIVFRQLzIg
ZG9lcyBub3QgZ3VhcmFudGVlIHRoYXQgcHVzaGVkIHJlc291cmNlcyBhcmUgZGVsaXZlcmVkDQog
ICB0byB0aGUgY2xpZW50IGluIHRoZSBvcmRlciB0aGV5IHdlcmUgc2VudCBieSB0aGUgY2xpZW50
DQoyLlNlcnZlciBQdXNoIGlzIG9wdGlvbmFsIGFuZCBjYW4gYmUgZGlzYWJsZWQgYnkgYW55IHBy
b3h5IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlci4NClRoZXJlZm9yZSBIVFRQLzIg
U2VydmVyIFB1c2ggaXMgbm90IGRlc2lyYWJsZSBjb21wYXJpbmcgd2l0aCBIVFRQMS4xK1NTRQ0K
DQovbWFydGluDQo=


From nobody Wed Sep 19 02:05:47 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD4A130EE1 for ; Wed, 19 Sep 2018 02:05: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, 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 vR396-YOnEex for ; Wed, 19 Sep 2018 02:05:44 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A8F9D130DDE for ; Wed, 19 Sep 2018 02:05:44 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 119D11AE02EF; Wed, 19 Sep 2018 11:05:43 +0200 (CEST)
Date: Wed, 19 Sep 2018 11:05:41 +0200 (CEST)
Message-Id: <20180919.110541.1111834445198880499.mbj@tail-f.com>
To: bill.wu@huawei.com
Cc: evoit=40cisco.com@dmarc.ietf.org, douglas@hubler.us, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <20180919.092522.1558587282279688362.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2018 09:05:47 -0000

UWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gDQo+IC0tLS0t6YKu5Lu2
5Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBNYXJ0aW4gQmpvcmtsdW5kIFttYWlsdG86bWJqQHRh
aWwtZi5jb21dIA0KPiDlj5HpgIHml7bpl7Q6IDIwMTjlubQ55pyIMTnml6UgMTU6MjUNCj4g5pS2
5Lu25Lq6OiBRaW4gV3UNCj4g5oqE6YCBOiBldm9pdD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9y
ZzsgZG91Z2xhc0BodWJsZXIudXM7DQo+IG5ldGNvbmZAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTog
W05ldGNvbmZdIGFjdGl2YXRlLWNvbmZpZ3VyZWQtc3ViZWNyaXB0aW9uIC0gV0dMQw0KPiBzdWJz
Y3JpYmVkLW5vdGlmaWNhdGlvbnMtMTYNCj4gDQo+IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29t
PiB3cm90ZToNCj4gPiANCj4gPiDlj5Hku7bkuro6IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJv
dW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBFcmljIFZvaXQNCj4gPiAoZXZvaXQpDQo+ID4g5Y+R6YCB
5pe26Ze0OiAyMDE45bm0OeaciDE55pelIDY6NDQNCj4gPiDmlLbku7bkuro6IERvdWdsYXMgSHVi
bGVyOyBNYXJ0aW4gQmpvcmtsdW5kDQo+ID4g5oqE6YCBOiBuZXRjb25mQGlldGYub3JnDQo+ID4g
5Li76aKYOiBSZTogW05ldGNvbmZdIGFjdGl2YXRlLWNvbmZpZ3VyZWQtc3ViZWNyaXB0aW9uIC0g
V0dMQw0KPiA+IHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucy0xNg0KPiA+IA0KPiA+IEhpIERvdWds
YXMsDQo+ID4gDQo+ID4gRnJvbTogRG91Z2xhcyBIdWJsZXIsIFNlcHRlbWJlciAxOCwgMjAxOCA1
OjM1IFBNDQo+ID4gDQo+ID4gT24gVHVlLCBTZXAgMTgsIDIwMTggYXQgMzo0MCBQTSBNYXJ0aW4g
QmpvcmtsdW5kIA0KPiA+IDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+PiB3
cm90ZToNCj4gPiBTbyBpdCBzZWVtcyB5b3Ugc3VwcG9ydCBteSBwb2ludCB0byBtYWtlIHRoaXMg
ZHJhZnQgdXNlIFNTRS4gIFRoZW4gaWYgDQo+ID4geW91IHVzZSBIVFRQLzIgeW91ICh0aGUgY2xp
ZW50KSBjYW4gc2ltcGx5IGNyZWF0ZSBvbmUgSFRUUC8yIHN0cmVhbSANCj4gPiBwZXIgbm90aWZp
Y2F0aW9uIHN0cmVhbS4gIFRoaXMganVzdCBmYWxscyBvdXQgZm9yIGZyZWUgd2l0aCBIVFRQLzIu
DQo+ID4gDQo+ID4geWVzLCB3aXRoIGNhdmVhdCB0aGF0IEkgaGF2ZW4ndCBhdHRlbXB0ZWQgYWN0
dWFsIGltcGxlbWVudGF0aW9uIHlldC4NCj4gPiANCj4gPiA8RXJpYz4gQWdyZWUgdGhhdCBTU0Ug
b3ZlciBIVFRQMiBzaG91bGQgd29yay4gIEhvd2V2ZXIgdG8gbWUgdXNpbmcgU1NFDQo+ID4gaGVy
ZSBzZWVtcyByZWR1bmRhbnQgYXMgSFRUUDIgcHJvdmlkZXMgdGhlIG5lY2Vzc2FyeSBtZWNoYW5p
c21zLiAgQnV0IA0KPiA+IEkgd29u4oCZdCBnZXQgaW4gdGhlIHdheSBpZiBwZW9wbGUgcmVhbGx5
IGRvIHdhbnQgdG8gZ28gaW4gdGhpcyANCj4gPiBkaXJlY3Rpb24uDQo+ID4gDQo+ID4gW1Fpbl06
IEhUVFAyIHByb3ZpZGVzIFNlcnZlciBQdXNoIG1lY2hhbmlzbSBob3dldmVyIHRoZXJlIGFyZSBs
b3RzIG9mIA0KPiA+IGRyYXdiYWNrcywgdHlwaWNhbCBvbmUgaXMgU2VydmVyIFB1c2ggbWF5IGJl
IGJsb2NrZWQsIHRoZXJlZm9yZSANCj4gPiBIVFRQMS4xKyBTU0UgaXMgZmF2b3JlZC4NCj4gDQo+
IEJ1dCBIVFRQLzIgc2VydmVyIHB1c2ggZG9lc24ndCBldmVuIGFkZHJlc3MgdGhlIHNhbWUgcHJv
YmxlbTsgaG93IHRvDQo+IGdldCBhIHN0cmVhbSBvZiBub3RpZnMgc2VudCBmcm9tIHRoZSBzZXJ2
ZXIgdG8gdGhlIGNsaWVudC4gIElmIEknbSBub3QNCj4gbWlzdGFrZW4sIHNlcnZlciBwdXNoIGNv
dWxkIGJlIGRvbmUgdy8gdGhlIEdFVCBvZiB0aGUgU1NFIHN0cmVhbSwgc28NCj4gbWF5YmUgc2Vy
dmVyIHB1c2ggY291bGQgYmUgdXNlZCB0byBhdm9pZCB0aGUgcm91bmQgdHJpcDoNCj4gDQo+ICAg
ICBjbGllbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzZXJ2ZXINCj4gICAgIC0tLS0t
LSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLQ0KPiAgICAgICB8ICAgICAgZXN0
YWJsaXNoLXN1YnNjcmlwdGlvbiAgICANCj4gICAgICAgfCAgICAgIC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLT4gICAgfA0KPiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8DQo+ICAgICAgIHwgICAgICAgICBPSywgbG9jYXRpb249U1NFIFVSTCAgICAgIHwNCj4gICAg
ICAgfCAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gICAgfA0KPiAgICAgICB8ICAgICAg
ICAgUFVTSF9QUk9NSVNFLCAgICAgICAgICAgICB8DQo+ICAgICAgIHwgICAgICAgICAgIG5ldyBz
dHJlYW0sIFNTRSBVUkwgICAgIHwNCj4gICAgICAgfCAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0gICAgfA0KPiAgICAgICB8ICAgICAgICAgICBTU0UgZXZlbnQgKG5vdGlmKSAgICAgICB8
DQo+ICAgICAgIHwgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgIHwNCj4gICAgICAg
fCAgICAgICAgICAgU1NFIGV2ZW50IChub3RpZikgICAgICAgfA0KPiAgICAgICB8ICAgICAgPC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgICB8DQo+ICAgICAgIHwgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHwNCj4gICAgICAgICAgICAgDQo+IFtRaW5dOiBZZXMsIEhUVFAvMiBz
ZXJ2ZXIgcHVzaCBjYW4gc2F2ZSByb3VuZCB0cmlwLCBidXQgaWYgSFRUUC8yDQo+IHNlcnZlciBw
dXNoIGlzIHVzZWQsIHR3byBjaGFubmVscyBuZWVkIHRvIGJlIGVzdGFibGlzaGVkLCBvbmUgZm9y
DQo+IGVzdGFibGlzaC1zdWJzY3JpcHRpb24sDQo+IE9uZSBmb3IgSFRUUC8yIFNlcnZlciBQdXNo
LCBub3Qgc3VyZSB0aGUgc2VxdWVuY2Ugb2Ygd29yayBmbG93IGhlcmUgaXMNCj4gY29ycmVjdA0K
DQpJbiB0aGUgZGlhZ3JhbSBJIHdyb3RlICJQVVNIX1BST01JU0UgbmV3IHN0cmVhbSIgd2hpY2gg
d2FzIHN1cHBvc2VkIHRvDQppbmRpY2F0ZSB0aGF0IHRoZSBQVVNIIChhbmQgc3Vic2VxdWVudCBk
YXRhKSBhcmUgc2VudCBpbiBhIG5ldyBzdHJlYW0uDQoNCj4gLCBmaXJzdCBob3cgZG9lcyBlc3Rh
Ymxpc2gtc3Vic2NyaXB0aW9uIFJQQyBpbmRpY2F0ZSBzZXJ2ZXINCj4gcHVzaCBzdXBwb3J0LCBo
b3cgZG9lcyBzZXJ2ZXIga25vdyBzZXJ2ZXIgcHVzaCBzaG91bGQgYmUgdXNlZCBmb3INCj4gcmVz
cG9uc2UuDQoNClRoaXMgaXMgbm90IHNwZWNpZmljIHRvIHRoaXMgZHJhZnQsIGl0IGlzIGEgZ2Vu
ZXJpYyBIVFRQLzIgcXVlc3Rpb24sDQpyaWdodD8gIElmIEknbSBub3QgbWlzdGFrZW4gdGhpcyBp
cyB0YWtlbiBjYXJlIG9mIGJ5IHRoZSBIVFRQLzIgc3BlYy4NCg0KPiBTZWNvbmQsIFNTRSBldmVu
dCBhbmQgT0ssIFBVU0gtUFJPTUlTRSBzaG91bGQgYmUgZXN0YWJsaXNoZWQgaW4NCj4gYW5vdGhl
ciBjaGFubmVsIG9yIEhUVFAgY29ubmVjdGlvbj8NCg0KWWVzLCBhbm90aGVyIHN0cmVhbSwgc2Vl
IGFib3ZlLg0KDQo+IEhUVFAgc2VydmVyIHB1c2ggaGFzIHR3byB0eXBpY2FsIGRyYXdiYWNrczoN
Cj4gMS4gSFRUUC8yIGRvZXMgbm90IGd1YXJhbnRlZSB0aGF0IHB1c2hlZCByZXNvdXJjZXMgYXJl
IGRlbGl2ZXJlZA0KPiAgICB0byB0aGUgY2xpZW50IGluIHRoZSBvcmRlciB0aGV5IHdlcmUgc2Vu
dCBieSB0aGUgY2xpZW50DQo+IDIuU2VydmVyIFB1c2ggaXMgb3B0aW9uYWwgYW5kIGNhbiBiZSBk
aXNhYmxlZCBieSBhbnkgcHJveHkgYmV0d2VlbiB0aGUNCj4gY2xpZW50IGFuZCB0aGUgc2VydmVy
Lg0KDQpBZ2FpbiwgdGhpcyBpcyBhIGdlbmVyaWMgSFRUUC8yIFBVU0ggaXNzdWUuICBJZiB0aGUg
Y2xpZW50IGRvZXNuJ3QNCnJlY3ZlaXZlIHRoZSBQVVNIX1BST01JU0UsIGl0IHdvdWxkIGhhdmUg
dG8gc2VuZCBhIEdFVCBhcyB1c3VhbC4NCg0KPiBUaGVyZWZvcmUgSFRUUC8yIFNlcnZlciBQdXNo
IGlzIG5vdCBkZXNpcmFibGUgY29tcGFyaW5nIHdpdGgNCj4gSFRUUDEuMStTU0UNCg0KTm90ZSB0
aGF0IHRoZSBkaWFncmFtIGFib3ZlIGFzc3VtZXMgSFRUUC8yICsgU1NFLiAgSXQganVzdCBzaG93
cyBob3cNClBVU0hfUFJPTUlTRSBjb3VsZCBiZSB1c2VkIHdpdGggSFRUUC8yICsgU1NFLg0KDQoN
Cg0KL21hcnRpbg0K


From nobody Wed Sep 19 02:15:43 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05F0130E37 for ; Wed, 19 Sep 2018 02:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7WL6pRU6gon for ; Wed, 19 Sep 2018 02:15:41 -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 15E5D130E58 for ; Wed, 19 Sep 2018 02:15:41 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0BFD1EFDE2755 for ; Wed, 19 Sep 2018 10:15:36 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 19 Sep 2018 10:15:37 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0399.000; Wed, 19 Sep 2018 17:15:32 +0800
From: Qin Wu 
To: Martin Bjorklund 
CC: "evoit=40cisco.com@dmarc.ietf.org" , "douglas@hubler.us" , "netconf@ietf.org" 
Thread-Topic: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
Thread-Index: AQHUSpBgBUFGD5oy2kmpOilc7/EuyqTuKlmAgACurwCAAAD1gIAFUEkAgAG9NoCAAAwnAIAAICCAgAATFYCAAM5uAP//w1YAgACXhhD//4SBgIAAhzDw
Date: Wed, 19 Sep 2018 09:15:32 +0000
Message-ID: 
References:  <20180919.092522.1558587282279688362.mbj@tail-f.com>  <20180919.110541.1111834445198880499.mbj@tail-f.com>
In-Reply-To: <20180919.110541.1111834445198880499.mbj@tail-f.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2018 09:15:43 -0000

PiBUaGVyZWZvcmUgSFRUUC8yIFNlcnZlciBQdXNoIGlzIG5vdCBkZXNpcmFibGUgY29tcGFyaW5n
IHdpdGggDQo+IEhUVFAxLjErU1NFDQoNCk5vdGUgdGhhdCB0aGUgZGlhZ3JhbSBhYm92ZSBhc3N1
bWVzIEhUVFAvMiArIFNTRS4gIEl0IGp1c3Qgc2hvd3MgaG93IFBVU0hfUFJPTUlTRSBjb3VsZCBi
ZSB1c2VkIHdpdGggSFRUUC8yICsgU1NFLg0KDQpbUWluXTogTWF5YmUgdGhpcyBpcyBpbXBsZW1l
bnRhdGlvbiBzcGVjaWZpYyBpc3N1ZSwgYnV0IGhvdyBkb2VzIHRoZSBzZXJ2ZXIga25vdyB3aGVu
IHRvIHVzZSBTZXJ2ZXIgUHVzaCBmb3IgUFVTSF9QUk9NSVNFIGFuZCB3aGVuIHRvIHVzZSBTU0Uu
DQpJIGp1c3QgU1NFIGFuZCBTZXJ2ZXIgUFVTSCBhcmUgdmVyeSBzaW1pbGFyLiBFbmFibGluZyBi
b3RoIG1lY2hhbmlzbSBjb3VsZHMgY29uZnVzZSB0aGUgc2VydmVyLg0KDQoNCi9tYXJ0aW4NCg==


From nobody Wed Sep 19 02:21:23 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A94130ECF for ; Wed, 19 Sep 2018 02:21:22 -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=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg0iVc2qeNG6 for ; Wed, 19 Sep 2018 02:21:14 -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 809AE130E58 for ; Wed, 19 Sep 2018 02:21:14 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A3B00B31; Wed, 19 Sep 2018 11:21: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 R3dtv2ZOR_c6; Wed, 19 Sep 2018 11:21: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; Wed, 19 Sep 2018 11:21:12 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BFF120035; Wed, 19 Sep 2018 11:21:12 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cQWlBAmFdH7E; Wed, 19 Sep 2018 11:21:12 +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 "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 0B54F20031; Wed, 19 Sep 2018 11:21: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.1415.2; Wed, 19 Sep 2018 11:21:10 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 5328F2520AFB; Wed, 19 Sep 2018 11:21:10 +0200 (CEST)
Date: Wed, 19 Sep 2018 11:21:10 +0200
From: Juergen Schoenwaelder 
To: Qin Wu 
CC: Martin Bjorklund , "evoit=40cisco.com@dmarc.ietf.org" , "netconf@ietf.org" 
Message-ID: <20180919092110.ztrplabel42wie55@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Qin Wu , Martin Bjorklund , "evoit=40cisco.com@dmarc.ietf.org" , "netconf@ietf.org" 
References:  <20180919.092522.1558587282279688362.mbj@tail-f.com>  <20180919.110541.1111834445198880499.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: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2018 09:21:22 -0000

On Wed, Sep 19, 2018 at 09:15:32AM +0000, Qin Wu wrote:
> 
> [Qin]: Maybe this is implementation specific issue, but how does the server know when to use Server Push for PUSH_PROMISE and when to use SSE.
> I just SSE and Server PUSH are very similar. Enabling both mechanism coulds confuse the server.
>

HTTP/2 push is a mechanism for a server to push data into a cache in
the hope that something using the cache may find the data useful. For
streaming event notifications, you can't rely on HTTP/2 push. I think
Martin is right.

/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 Sep 19 02:53:12 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B9A130ECC for ; Wed, 19 Sep 2018 02:53: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzuRfL-dOXEB for ; Wed, 19 Sep 2018 02:53:09 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF45130DC7 for ; Wed, 19 Sep 2018 02:53:09 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6421735969B08; Wed, 19 Sep 2018 10:53:05 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 19 Sep 2018 10:53:07 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0399.000; Wed, 19 Sep 2018 17:52:53 +0800
From: Qin Wu 
To: Juergen Schoenwaelder 
CC: Martin Bjorklund , "evoit=40cisco.com@dmarc.ietf.org" , "netconf@ietf.org" 
Thread-Topic: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
Thread-Index: AQHUSpBgBUFGD5oy2kmpOilc7/EuyqTuKlmAgACurwCAAAD1gIAFUEkAgAG9NoCAAAwnAIAAICCAgAATFYCAAM5uAP//w1YAgACXhhD//4SBgIAAhzDw//99JAAAEdamsA==
Date: Wed, 19 Sep 2018 09:52:53 +0000
Message-ID: 
References:  <20180919.092522.1558587282279688362.mbj@tail-f.com>  <20180919.110541.1111834445198880499.mbj@tail-f.com>  <20180919092110.ztrplabel42wie55@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180919092110.ztrplabel42wie55@anna.jacobs.jacobs-university.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2018 09:53:11 -0000

R29vZCwgdGhhbmtzIGZvciBjbGFyaWZpY2F0aW9uIGZyb20gYm90aC4NCg0KLVFpbg0KLS0tLS3T
yrz+1K28/i0tLS0tDQq3orz+yMs6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRvOmouc2No
b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0gDQq3osvNyrG85DogMjAxOMTqOdTCMTnI
1SAxNzoyMQ0KytW8/sjLOiBRaW4gV3UNCrOty806IE1hcnRpbiBCam9ya2x1bmQ7IGV2b2l0PTQw
Y2lzY28uY29tQGRtYXJjLmlldGYub3JnOyBuZXRjb25mQGlldGYub3JnDQrW98ziOiBSZTogW05l
dGNvbmZdIGFjdGl2YXRlLWNvbmZpZ3VyZWQtc3ViZWNyaXB0aW9uIC0gV0dMQyBzdWJzY3JpYmVk
LW5vdGlmaWNhdGlvbnMtMTYNCg0KT24gV2VkLCBTZXAgMTksIDIwMTggYXQgMDk6MTU6MzJBTSAr
MDAwMCwgUWluIFd1IHdyb3RlOg0KPiANCj4gW1Fpbl06IE1heWJlIHRoaXMgaXMgaW1wbGVtZW50
YXRpb24gc3BlY2lmaWMgaXNzdWUsIGJ1dCBob3cgZG9lcyB0aGUgc2VydmVyIGtub3cgd2hlbiB0
byB1c2UgU2VydmVyIFB1c2ggZm9yIFBVU0hfUFJPTUlTRSBhbmQgd2hlbiB0byB1c2UgU1NFLg0K
PiBJIGp1c3QgU1NFIGFuZCBTZXJ2ZXIgUFVTSCBhcmUgdmVyeSBzaW1pbGFyLiBFbmFibGluZyBi
b3RoIG1lY2hhbmlzbSBjb3VsZHMgY29uZnVzZSB0aGUgc2VydmVyLg0KPg0KDQpIVFRQLzIgcHVz
aCBpcyBhIG1lY2hhbmlzbSBmb3IgYSBzZXJ2ZXIgdG8gcHVzaCBkYXRhIGludG8gYSBjYWNoZSBp
biB0aGUgaG9wZSB0aGF0IHNvbWV0aGluZyB1c2luZyB0aGUgY2FjaGUgbWF5IGZpbmQgdGhlIGRh
dGEgdXNlZnVsLiBGb3Igc3RyZWFtaW5nIGV2ZW50IG5vdGlmaWNhdGlvbnMsIHlvdSBjYW4ndCBy
ZWx5IG9uIEhUVFAvMiBwdXNoLiBJIHRoaW5rIE1hcnRpbiBpcyByaWdodC4NCg0KL2pzDQoNCi0t
IA0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVt
ZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8
IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAg
PGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg==


From nobody Wed Sep 19 09:38:50 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7621310F1 for ; Wed, 19 Sep 2018 09:38:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level: 
X-Spam-Status: No, score=-1.908 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_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hubler-us.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoxA5pxLhtAm for ; Wed, 19 Sep 2018 09:38:40 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9919131106 for ; Wed, 19 Sep 2018 09:38:39 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id p79-v6so9166058itp.3 for ; Wed, 19 Sep 2018 09:38:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hubler-us.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=tDQ+xvxemThywc/Y9Ko23rc5OHE8Y0SiPf3md0dFww4=; b=05ZKenD3GpghdllOBNpHPBzq1nJpf8iN4xBoyp5ljrl5G6tUSGEUoN2zr6Jhd+4n4A CDf3iLNsDZExZ5KWsl5q3zZZigF3BcqHx0NxYXjWr0DG9ewlIJLi70/obR0U8RRswosA pnOuUWYVaJD+HRMhOZzeDNj38AXjPf0WMnRMg1ByHYRZYHI/CtjYq+CuAuBO8ovWTwvb kHXFRdu8R8Z06z4QJ1RAR1vaxVS0cfesgwgmUvOSnLwhXlgbElVLAOFVejpZstY48DWR w9z9BqPs8TyhrQd8y3X7T+Z1Znrfxyx2DmtQepFT/PQuotc5eLMlOsK/hYL/mIj1JWVK UB0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tDQ+xvxemThywc/Y9Ko23rc5OHE8Y0SiPf3md0dFww4=; b=JzrDKO/yZ8HJ/gBlkEGr7lh5RjlAGUIl9BlRZwjBkGGUQB9fT9WDMAANdsWeBqfmq+ meNTKOx/fpc2j/6YtxpvQ/q8alfPbJtwuOMz8eAp7gZ1hsiG/Irq+RRGEvCMcB9ZEmE0 /OpjzCouemI4Ji4PoIumkTuAPxU8IUVQUmluEuUi6PKBMyVRsASqqn2PtCHuPshmeLtL qoHoD24cMZVaCVwQ5ODeDjpxeh/SPLDOGKrCTz/c14yopaH/56m2yWVb7G9MRgxu0f88 2xvU83UsE2IaWHWQrMuMhk3Q7ozdDDIJABEOVj+45aBmV0udL9QdS2PcTx9ynLx1sW2J 3s1A==
X-Gm-Message-State: APzg51CjIy1eCnn57z2d7FGRKaL3zoQKW5cGGkV+o1GOId/RdB3SOmfh mb09MyKk98SUTcszJdP8ne9WbZIhLao=
X-Google-Smtp-Source: ANB0VdZoasUaamYLLvx3m8FDV02BzgysS1CMgR8Lg/W/yFznzTs226C1fxIjjPETFCC5Jy/gYUfsLg==
X-Received: by 2002:a24:c48a:: with SMTP id v132-v6mr23058330itf.72.1537375118937;  Wed, 19 Sep 2018 09:38:38 -0700 (PDT)
Received: from mail-it0-f49.google.com (mail-it0-f49.google.com. [209.85.214.49]) by smtp.gmail.com with ESMTPSA id a11-v6sm6001162ita.21.2018.09.19.09.38.37 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Sep 2018 09:38:37 -0700 (PDT)
Received: by mail-it0-f49.google.com with SMTP id d10-v6so9137393itj.5 for ; Wed, 19 Sep 2018 09:38:37 -0700 (PDT)
X-Received: by 2002:a24:d651:: with SMTP id o78-v6mr21372312itg.140.1537375117431;  Wed, 19 Sep 2018 09:38:37 -0700 (PDT)
MIME-Version: 1.0
From: Douglas Hubler 
Date: Wed, 19 Sep 2018 12:38:26 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Netconf 
Content-Type: multipart/alternative; boundary="000000000000c2da6705763c09f3"
Archived-At: 
Subject: [Netconf] RESTCONF/Notif/SSE payload delimiter question
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2018 16:38:48 -0000

--000000000000c2da6705763c09f3
Content-Type: text/plain; charset="UTF-8"

While implementing client reader for notification events in an SSE stream,
I believe I need to know where one event payload ends and another event
payload starts.  I don't believe I can rely on zero bytes left in buffer
should the events be back-to-back.

While reading RESTCONF RFC
   https://tools.ietf.org/html/rfc8040#section-6.4
It mentions a server *could* use a line terminator, but doesn't not specify
the server *must* use one.

Stream-based XML/JSON reader, while possible, might be putting a burden on
client readers.

--000000000000c2da6705763c09f3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


While implementing client reader for notification eve=
nts in an SSE stream, I believe I need to know where one event payload ends=
 and another event payload starts.=C2=A0 I don't believe I can rely on =
zero bytes left in buffer should the events be back-to-back.

=

While reading RESTCONF RFC
=C2=A0 =C2=A0https://tools.ietf.org/html/rfc804=
0#section-6.4
It mentions a server *could* use a line terminator, b=
ut doesn't not specify the server *must* use one.=C2=A0=C2=A0

Stream-based XML/JSON reader, while possible, might be putt=
ing a burden on client readers.





--000000000000c2da6705763c09f3--


From nobody Wed Sep 19 09:44:34 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E587A130E12 for ; Wed, 19 Sep 2018 09:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApBC1Eg0Aof7 for ; Wed, 19 Sep 2018 09:44:30 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56405130E18 for ; Wed, 19 Sep 2018 09:44:30 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id q127-v6so5660351ljq.11 for ; Wed, 19 Sep 2018 09:44:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Sl3rdG6Zb9gMEY4hCBqvCKt5yS+YhSNaqt5cVT8C/fY=; b=fJeMDhLXMHNVO5Qhka4kmYSD8AF/we5CbpAXvLu3RVg7SQQdGUDbaQCz2OyelAwDWS dfTU8zfs5CSmQKFQAHLL466F1FyiEeR+Vrh/yfFP5iBabmnyD/6ShcPWG9pgrO0AhU2B 7OB2dGn4FZ2i9RKRDIclkXOGPd07tZaMj20YWNYv7195nWtm1DcB6NXLKGnvSPN1pW3X VCr/yIruc+K9nZl/xGtUTzNs76bR991U9/mSMkzUqskKn4LBmqFMte21Mw5gxLFBYk3K f+gMZ8HFy+lPvfjm6PX4wgTSjNhKFKecWDTSpMjoFtgklWFPMxio3CY1zM73xOZ78hEA 6eJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Sl3rdG6Zb9gMEY4hCBqvCKt5yS+YhSNaqt5cVT8C/fY=; b=hekHYT6SUgBerMcWOyft+grAckHEKx4SIY4QwDuxZKD8t3H2C/LUZMlP+2IxtsK0aN 0fc0dH8x2QWRiMV5JG4EJ+vGsgCqO7jN7cRH9ZHYd7wD8HUKqWVjZFk/mR6BkspacKwn L5gyfWCuTiHcxfJV4O2Sq8VxSfBwbRoB9Su6AQPdt9m5MZxxLD0L+16J5cY2m/5LGjKC xjlVzfdB0GVxXDUKHq6pcZ1I1RWxJdXWYP+Y1v5qqu569NNCQNuOk6lDIxf690t0h6Br cZ5cV0k0jo4TA+U8S6Hpa5Ce+zTX9TQuIj9EVp6QtfgEGUcmuTPfyW4eMNfQ7aUGCaHR WA4A==
X-Gm-Message-State: APzg51AVBW8Q2nSdITqoLdpytOEf8bJWCH3WfYE5QMDBF8MDQ0o1nC1x O8SwF+8vQEkbcbXfPvGEqFYDoe5Eb8e+AXV04jnjrMCvn/A=
X-Google-Smtp-Source: ANB0VdaO6FuNkPfD7hLuZ0thJZFVyIUSSje7S7Kq8KppvWKwc8iEeXTMLIroaRL3ekbvA7LXkeE/Y6Las1SdNWbODtg=
X-Received: by 2002:a2e:5687:: with SMTP id k7-v6mr22852526lje.105.1537375468309;  Wed, 19 Sep 2018 09:44:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:6a19:0:0:0:0:0 with HTTP; Wed, 19 Sep 2018 09:44:27 -0700 (PDT)
In-Reply-To: 
References: 
From: Andy Bierman 
Date: Wed, 19 Sep 2018 09:44:27 -0700
Message-ID: 
To: Douglas Hubler 
Cc: Netconf 
Content-Type: multipart/alternative; boundary="000000000000acf92a05763c1e8b"
Archived-At: 
Subject: Re: [Netconf] RESTCONF/Notif/SSE payload delimiter question
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2018 16:44:33 -0000

--000000000000acf92a05763c1e8b
Content-Type: text/plain; charset="UTF-8"

On Wed, Sep 19, 2018 at 9:38 AM, Douglas Hubler  wrote:

> While implementing client reader for notification events in an SSE stream,
> I believe I need to know where one event payload ends and another event
> payload starts.  I don't believe I can rely on zero bytes left in buffer
> should the events be back-to-back.
>
> While reading RESTCONF RFC
>    https://tools.ietf.org/html/rfc8040#section-6.4
> It mentions a server *could* use a line terminator, but doesn't not
> specify the server *must* use one.
>
> Stream-based XML/JSON reader, while possible, might be putting a burden on
> client readers.
>
>
>
>
You use a blank line for this purpose:

 https://www.w3.org/TR/eventsource/


Andy


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

--000000000000acf92a05763c1e8b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Sep 19, 2018 at 9:38 AM, Douglas Hubler <doug=
las@hubler.us> wrote:
While implementing client reader for no=
tification events in an SSE stream, I believe I need to know where one even=
t payload ends and another event payload starts.=C2=A0 I don't believe =
I can rely on zero bytes left in buffer should the events be back-to-back.<=
/div>

While reading RESTCONF RFC
=C2=A0 =C2=A0ht=
tps://tools.ietf.org/html/rfc8040#section-6.4
It mentions a se=
rver *could* use a line terminator, but doesn't not specify the server =
*must* use one.=C2=A0=C2=A0

Stream-based XML/JSON =
reader, while possible, might be putting a burden on client readers.
<=
div>


<=
div>
You use a blank line for this purpose:



Andy
=




_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--000000000000acf92a05763c1e8b--


From nobody Wed Sep 19 12:32:57 2018
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 2F086130EBB; Wed, 19 Sep 2018 12:32:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Mahesh Jethanandani 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: Bert Wijnen , Mahesh Jethanandani , iesg-secretary@ietf.org, netconf@ietf.org, Bert Wijnen , mjethanandani@gmail.com, netconf-chairs@ietf.org
Message-ID: <153738557618.21424.10627869889184064835.idtracker@ietfa.amsl.com>
Date: Wed, 19 Sep 2018 12:32:56 -0700
Archived-At: 
Subject: [Netconf] Publication has been requested for draft-ietf-netconf-zerotouch-25
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2018 19:32:56 -0000

Mahesh Jethanandani has requested publication of draft-ietf-netconf-zerotouch-25 as Proposed Standard on behalf of the NETCONF working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/


From nobody Wed Sep 19 15:59:16 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1705C130DCE for ; Wed, 19 Sep 2018 15:59:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_HIGH=-0.01, 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 FoGJ9q6sNdy7 for ; Wed, 19 Sep 2018 15:59:11 -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 446D0130EA0 for ; Wed, 19 Sep 2018 15:59:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10228; q=dns/txt; s=iport; t=1537397951; x=1538607551; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0Edly1B7H1f5T78FPMMJqzbcwHv42FmbNx7wlSoAOFU=; b=M7q2iv9vRRIuUCv6XP/uwM3KaYBvpP4OtVFZ1Q5lW9Yxh5ejshRUMWsh hMfjIZBDXh/8bxxJA8ppzm6whydNHcv9u3//cDGgl7Pa/YRV8b0ljDp4/ t5ylW+KnC3ni7tXj30ciqLp3KT0At55b6d+Etl9jLlRwz+mFMUu4CX2fC Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzAQAe1KJb/5hdJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYFTgVsqZX8oCoNplEaCDYM9lQkLGAuESQIXgyQhNxUBAwE?= =?us-ascii?q?BAgEBAm0cDIU4AQEBAQIBIxFDAgULAgEIDgcDAgIJGgMCAgIwFAEQAgQOAQQ?= =?us-ascii?q?IARaCN0yBeQgPpHmBLooUgQuJYheBQT+BEoMShGgdM4JHglcCiC2ULAkCiUW?= =?us-ascii?q?GUx+BQ4dThgSUSAIRFIElMyKBVXAVgycJghwXEYhIhT0BbwEOjDCBHgEB?=
X-IronPort-AV: E=Sophos;i="5.53,395,1531785600"; d="scan'208";a="174254625"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2018 22:59:10 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w8JMx9ac018968 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Sep 2018 22:59:10 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 19 Sep 2018 18:59: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.1395.000; Wed, 19 Sep 2018 18:59:09 -0400
From: "Eric Voit (evoit)" 
To: Martin Bjorklund 
CC: "douglas@hubler.us" , "andy@yumaworks.com" , "j.schoenwaelder@jacobs-university.de" , "netconf@ietf.org" 
Thread-Topic: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
Thread-Index: AQHUSpBZpYtwPWXE1k2ur9Y/QhScQaTs+hAAgAKoIwCAAAD0gIAFUEkAgAG9N4CAAAwmAIAAICCA//++5KCAANjAgIAAa7UQ
Date: Wed, 19 Sep 2018 22:59:09 +0000
Message-ID: <1f83e10a61fc4a89bf5e1264566a3e29@XCH-RTP-013.cisco.com>
References: <20180918.214022.2268667197465086195.mbj@tail-f.com>  <48e4aac958d142669f4032737cdc4373@XCH-RTP-013.cisco.com> <20180919.083805.1103902318002046181.mbj@tail-f.com>
In-Reply-To: <20180919.083805.1103902318002046181.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.234]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: 
Subject: Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2018 22:59:14 -0000

PiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kLCBTZXB0ZW1iZXIgMTksIDIwMTggMjozOCBBTQ0KPiAN
Cj4gSGksDQo+IA0KPiAiRXJpYyBWb2l0IChldm9pdCkiIDxldm9pdEBjaXNjby5jb20+IHdyb3Rl
Og0KPiA+IEhpIERvdWdsYXMsDQo+ID4NCj4gPiBGcm9tOiBEb3VnbGFzIEh1YmxlciwgU2VwdGVt
YmVyIDE4LCAyMDE4IDU6MzUgUE0NCj4gPg0KPiA+DQo+ID4gT24gVHVlLCBTZXAgMTgsIDIwMTgg
YXQgMzo0MCBQTSBNYXJ0aW4gQmpvcmtsdW5kDQo+ID4gPG1iakB0YWlsLWYuY29tPG1haWx0bzpt
YmpAdGFpbC1mLmNvbT4+IHdyb3RlOg0KPiA+IFNvIGl0IHNlZW1zIHlvdSBzdXBwb3J0IG15IHBv
aW50IHRvIG1ha2UgdGhpcyBkcmFmdCB1c2UgU1NFLiAgVGhlbiBpZg0KPiA+IHlvdSB1c2UgSFRU
UC8yIHlvdSAodGhlIGNsaWVudCkgY2FuIHNpbXBseSBjcmVhdGUgb25lIEhUVFAvMiBzdHJlYW0N
Cj4gPiBwZXIgbm90aWZpY2F0aW9uIHN0cmVhbS4gIFRoaXMganVzdCBmYWxscyBvdXQgZm9yIGZy
ZWUgd2l0aCBIVFRQLzIuDQo+ID4NCj4gPiB5ZXMsIHdpdGggY2F2ZWF0IHRoYXQgSSBoYXZlbid0
IGF0dGVtcHRlZCBhY3R1YWwgaW1wbGVtZW50YXRpb24geWV0Lg0KPiA+DQo+ID4gPEVyaWM+IEFn
cmVlIHRoYXQgU1NFIG92ZXIgSFRUUDIgc2hvdWxkIHdvcmsuICBIb3dldmVyIHRvIG1lIHVzaW5n
IFNTRQ0KPiA+IGhlcmUgc2VlbXMgcmVkdW5kYW50IGFzIEhUVFAyIHByb3ZpZGVzIHRoZSBuZWNl
c3NhcnkgbWVjaGFuaXNtcy4NCj4gDQo+IEVyaWMsIGNhbiB5b3UgZXhwbGFpbiBob3cgdGhpcyB3
b3VsZCB3b3JrIHcvbyBTU0U/ICBXaGljaCBtZWNoYW5pc20gaW4NCj4gSFRUUC8yIGFyZSB5b3Ug
cmVmZXJyaW5nIHRvPw0KDQpBZnRlciBhbiBIVFRQMiBPSywgdGhlIEhUVFAyIHNlcnZlciBoYXMg
dGhlIGFiaWxpdHkgdG8gZm9yd2FyZCBhbiB1bmJvdW5kZWQgbnVtYmVyIG9mIEhUVFAyIERhdGEg
RnJhbWVzIG9uIHRoZSBIVFRQMiBzdHJlYW0uICBUaGUgc3RyZWFtIGlzIG5vdCBjb25zaWRlcmVk
IGNvbXBsZXRlIHVudGlsIGFuIEVORF9TVFJFQU0gaXMgcGFzc2VkLiAgIChOb3RlIHRoaXMgaXMg
aW5kZXBlbmRlbnQgb2YgYW55dGhpbmcgcmVnYXJkaW5nIEhUVFAyJ3MgUFVTSF9QUk9NSVNFLikN
Cg0KWW91IGNhbiBzZWUgYW4gZXhhbXBsZSBmbG93IGluIEZpZ3VyZSAxIG9mIGRyYWZ0LWlldGYt
bmV0Y29uZi1yZXN0Y29uZi1ub3RpZi4gIEF0IElFVEYgOTcgd2UgYXNrZWQgZm9yIHNvbWUgRmVl
ZGJhY2sgb24gdGhpcyBwcm9wb3NhbC4gDQpodHRwOi8vd3d3LnZvaXQub3JnL0lFVEYvU3Vic2Ny
aXB0aW9ucy1ORVRDT05GLUlFVEY5Ny5wcHQgKHNlZSBzbGlkZSAxNCkuDQpCdXQgSSBhbSBub3Qg
c3VyZSBob3cgbXVjaCBlZmZvcnQgdGhlIFdHIHNob3VsZCBwbGFjZSBoZXJlLiAgIFRoZSB3b3Jr
IGhlcmUgaXMgc2V2ZXJhbCB5ZWFycyBvbGQsIGFuZCB0aGUgbWFya2V0IGhhcyBtb3ZlZCBzdWJz
dGFudGlhbGx5IHNpbmNlIHRoZW4uDQoNCj4gPiBCdXQNCj4gPiBJIHdvbuKAmXQgZ2V0IGluIHRo
ZSB3YXkgaWYgcGVvcGxlIHJlYWxseSBkbyB3YW50IHRvIGdvIGluIHRoaXMNCj4gPiBkaXJlY3Rp
b24uDQo+ID4NCj4gPiA+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgZGV0YWlscyBzdXJyb3VuZGlu
ZyB1c2luZyBhbiBSUEMgdG8gbWFrZSBhDQo+ID4gPiBkeW5hbWljIHN1YnNjcmlwdGlvbi4gIFVu
bGVzcyBpdCdzIG9wdGlvbmFsLCB0aGVuIEkgY2FuIHN0YXJ0IHRvDQo+ID4gPiB1bmRlcnN0YW5k
Lg0KPiA+DQo+ID4gVGhlIGNsaWVudCB3b3VsZCBQT1NUIHRvIHRoZSAicnBjIiBlc3RhYmxpc2gt
c3Vic2NyaXBpb24sIGFuZCBpbiB0aGUNCj4gPiByZXBseSB0byB0aGUgUE9TVCBpcyBhICJsb2Nh
dGlvbiIgbGVhZiAoKikgdGhhdCBjb250YWlucyBhIFVSSS4gIFRoZQ0KPiA+IGNsaWVudCB0aGVu
IEdFVCB0aGlzIFVSSTsgdGhpcyBpcyB0aGUgU1NFIGV2ZW50IHN0cmVhbS4NCj4gPg0KPiA+IEkg
c2VlLiAgQnV0IGlmIGEgY2xpZW50IHJlYWRzIHRoZSBZQU5HIGFzDQo+ID4NCj4gPiAgbW9kdWxl
IG15LW1vZHVsZSB7DQo+ID4gICAgIC4uLg0KPiA+ICAgICBub3RpZmljYXRpb24gbXktZXZlbnQg
ew0KPiA+ICAgICB9DQo+ID4gfQ0KPiA+DQo+ID4gYW5kIGNsaWVudCBrbmV3IGJhc2Ugc3RyZWFt
IFVSSSB3YXM6DQo+ID4NCj4gPiAgICAvcmVzdGNvbmYvbXktc3RyZWFtcw0KPiA+DQo+ID4gQ291
bGRuJ3QgdGhlIGNsaWVudCB0aGVuIGRlZHVjZSBTU0UgVVJMIGFzOg0KPiA+DQo+ID4gIEdFVCAg
L3Jlc3Rjb25mL215LXN0cmVhbXMvbXktbW9kdWxlOm15LWV2ZW50Py4uLg0KPiANCj4gTm8uDQo+
IA0KPiBXaXRoIFJGQyA4MDQwLCB0aGUgU1NFIFVSTCBpcyAic3RhYmxlIiwgYW5kIGlmIHRoZSBj
bGllbnQgaGFzIHJlYWQgaXQgb252ZSwgaXQNCj4gZG9lc24ndCBoYXZlIHRvIHJlYWQgaXQgYWdh
aW4gKG1vZHVsbyBzb21lIGRlZmluaXRpb24gb2YgInN0YWJsZSIpLiAgVGhlIGNsaWVudA0KPiBj
YW4gcGFzcyBhIGZpbHRlciBpbiB0aGUgR0VUIHJlcXVlc3QgZm9yIHRoZSBTU0Ugc3RyZWFtLg0K
PiANCj4gV2l0aCB0aGUgbWVjaGFuaXNtIGluIHRoaXMgZHJhZnQsIHRoZSBTU0UgVVJMIHdpbGwg
dmFyeSBmb3IgZWFjaCByZXF1ZXN0IHRoYXQNCj4gaGFzIGEgZGlmZmVyZW50IGZpbHRlciAoYXQg
YSBtaW5pbXVtKSwgc2luY2UgdGhlIGZpbHRlciBpcyBwYXNzZWQgYSBwYXJhbWV0ZXIgdG8NCj4g
ImVzdGFibGlzaC1zdWJzY3JpcHRpb24iIGFuZCB0aGUgU1NFIFVSTCBpcyBzZW50IGJhY2sgaW4g
dGhlIHJlcGx5IHRvICJlc3RhYmxpc2gtDQo+IHN1YnNjcmlwdGlvbiIuICBXaXRoIHRoZSBTU0Ug
VVJMLCB0aGUgc2VydmVyIG1heSBoaWRlIHNvbWUgc3RhdGUgdGhhdA0KPiBjb3JyZXNwb25kcyB0
byB0aGUgZmlsdGVyIHBhcmFtcyBldGMuICAoTk9URSB0aGUgd29yZCAqbWF5KiBpbiB0aGUgcHJl
dmlvdXMNCj4gc2VudGVuY2UuICBBIHNlcnZlciBjb3VsZCBhcyB3ZWxsIHNlbmQgYmFjayBhIFNT
RSBVUkwgd2l0aCB0aGUgZmlsdGVyDQo+IHBhcmFtZXRlcnMgZW1iZWRkZWQgaW4gdGhlDQo+IFVS
TC4uLikNCj4gDQo+IFNvIGluIGdlbmVyYWwsIGEgY2xpZW50IGNhbm5vdCBhc3N1bWUgdGhhdCBp
dCBjYW4gcmUtdXNlIGEgU1NFIFVSTCB0aGF0IHdhcw0KPiByZXR1cm5lZCBmcm9tIGEgY2FsbCB0
byAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIuDQo+IA0KPiA+IFRoZXJlYnkgc2F2aW5nIGEgdHJp
cCB0byBzZXJ2ZXI/DQo+ID4NCj4gPiA8RXJpYz4gWWVzLCBpdCB3b3VsZCBiZSBwb3NzaWJsZSB0
byBzZXQgc29tZXRoaW5nIHVwIHRvIGRlZHVjZSB0aGUNCj4gPiBVUkwuICBkcmFmdC1pZXRmLW5l
dGNvbmYtcmVzdGNvbmYtbm90aWYgZG9lc27igJl0IGN1cnJlbnRseSBhdHRlbXB0IHRoaXMNCj4g
PiBhcyBiZWluZyBhYmxlIHRvIGRlZHVjZSB0aGUgVVJMIGRvZXNu4oCZdCBzdG9wIHRoZSBleHRy
YSB0cmlwIHRvIHRoZQ0KPiA+IHNlcnZlci4NCj4gPg0KPiA+IFRoZSByZWFzb24gaXQgZG9lc27i
gJl0IGdldCByaWQgb2YgdGhlIGV4dHJhIHJvdW5kIHRyaXAgaGFzIHRvIGRvIHdpdGgNCj4gPiBI
VFRQMiBzdHJlYW1zLiAgSWYgd2UgYXJlIGdvaW5nIHRvIHVzZSBIVFRQMiwgdGhlcmUgaXMgc3Rp
bGwgYSBuZWVkIHRvDQo+ID4gaW5pdGlhdGUgdGhlIEdFVCAob3IgUE9TVCkgaW4gYSBzZXBhcmF0
ZSBzdHJlYW0gb3RoZXIgdGhhbiB0aGUgb25lDQo+ID4gYmVpbmcgdXNlZCBmb3IgUkVTVENPTkYg
c2lnbmFsaW5nLg0KPiANCj4gSSBkaXNhZ3JlZS4gIElmIHRoZSBjbGllbnQgd2FudHMgdG8gaGF2
ZSBhIHNlcGFyYXRlIEhUVFAvMiBzdHJlYW0gZm9yIHRoZSBub3RpZnMsDQo+IHRoZW4gaXQgc2hv
dWxkIHN0YXJ0IHN1Y2ggYSBzdHJlYW0uICBJZiB0aGUgY2xpZW50IGRvZXNuJ3Qgd2FudCBhIHNl
cGFyYXRlIEhUVFAvMg0KPiBzdHJlYW0gdGhlbiB0aGF0IHNob3VsZCBiZSBvayB0b28uDQoNClBl
ciB5b3VyIGJlbG93LCBvbmNlIFNTRSBpcyBhcHBsaWVkIGEgc3RyZWFtIGlzIGJsb2NrZWQuICBG
b3IgdGhhdCBzdWJzY3JpcHRpb24sIHlvdSBzdGlsbCBuZWVkIHRvIHN1cHBvcnQgJ21vZGlmeS1z
dWJzY3JpcHRpb24nIGFuZCAnZGVsZXRlLXN1YnNjcmlwdGlvbicgcnBjcy4NCg0KQmV5b25kIHRo
YXQsIG9uZSB0aGluZyB0byBrZWVwIGFuIGV5ZSBvbiBpcyB0aGUgcG90ZW50aWFsIGZvciBidW5k
bGluZyBvZiBldmVudCByZWNvcmRzIGZyb20gZGlmZmVyZW50IHN1YnNjcmlwdGlvbnMgaW50byBh
IHNpbmdsZSB0cmFuc21pdHRhYmxlIG5vdGlmaWNhdGlvbiBtZXNzYWdlLiAgKFNvbWV0aGluZyBs
aWtlIGluIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMuKSAgIEFueXdo
ZXJlIHN1Y2ggYnVuZGxpbmcgb2NjdXJzLCB0aGUgcHVibGlzaGVyIHdpbGwgaGF2ZSB0byB1c2Ug
YSBjb25zaXN0ZW50IEhUVFAyIHN0cmVhbSBhY3Jvc3MgYSBzZXQgb2Ygc3Vic2NyaXB0aW9ucyBp
biBvcmRlciB0byBwcmVzZXJ2ZSBldmVudCByZWNvcmQgb3JkZXJpbmcuICBJbiBhZGRpdGlvbiwg
YWxsIGV2ZW50IHJlY29yZHMgYnVuZGxlZCB3aWxsIGhhdmUgdG8gY29uc2lzdGVudGx5IHVzZSB0
aGUgc2FtZSBEU0NQLg0KDQpOb3RlOiB0aGlzIGlzIGFub3RoZXIgcmVhc29uIHdoeSBpdCBpcyBh
IGdvb2QgaWRlYSB0byB1c2Ugc2VwYXJhdGUgSFRUUDIgc3RyZWFtcyBmb3IgUkVTVENPTkYgc3Vi
c2NyaXB0aW9uIFJQQyBpbnRlcmFjdGlvbnMsIGFuZCBmb3IgdGhlIHN0cmVhbWluZyBvZiBldmVu
dCByZWNvcmRzLg0KDQo+IENvbXBhcmUgdG8gTkVUQ09ORi4gIEhUVFAvMiBzdHJlYW1zIGFyZSBz
aW1pbGFyIHRvIFNTSCBjaGFubmVscy4gIEENCj4gTkVUQ09ORiBjbGllbnQgY2FuIG9wZW4gYSBz
ZXBhcmF0ZSBTU0ggY2hhbm5lbCBmb3IgZWFjaCBzdWJzY3JpcHRpb24sIG9yIGl0DQo+IGNhbiB1
c2UgYSBzaW5nbGUgY2hhbm5lbC4gIFVwIHRvIHRoZSBjbGllbnQuDQoNCkhUVFAyIHN0cmVhbXMg
aGF2ZSBmYXIgbGVzcyBvdmVyaGVhZCwgbG93ZXIgc2V0dXAgbGF0ZW5jeSwgYW5kIG1vcmUgc2Nh
bGFiaWxpdHkgdGhhbiBzZXBhcmF0ZSBTU0ggY2hhbm5lbHMuDQogDQo+ID4gU29tZW9uZSBjb3Vs
ZCB3cml0ZSBhIHNwZWNpZmljYXRpb24gd2hpY2ggZ2V0cyBhcm91bmQgdGhpcyBieSBmb3JjaW5n
DQo+ID4gZXZlcnkgUkVTVENPTkYgdHJhbnNhY3Rpb24gb24gaXRzIG93biBIVFRQMiBzdHJlYW0u
ICBCdXQgbm9ib2R5IGhhcw0KPiA+IHByb3Bvc2VkIHN1Y2ggYSBzcGVjaWZpY2F0aW9uLiAgUGx1
cyB0aGVyZSBhcmUgUW9TIHNjZW5hcmlvcyB3aGVyZSB5b3UNCj4gPiBtaWdodCB3YW50IG11bHRp
cGxlIHN1YnNjcmlwdGlvbnMgb24gdGhlIHNhbWUgSFRUUDIgc3RyZWFtLg0KPiANCj4gSG93IHdv
dWxkIHRoaXMgd29yaz8gIE9uY2UgeW91IHN0YXJ0IFNTRSBvbiBhIHN0cmVhbSwgdGhhdCBzdHJl
YW0gaXMNCj4gImJsb2NrZWQiLCByaWdodD8NCg0KQW5kIHBlciBhYm92ZSwgdGhpcyBpcyBhIGdv
b2QgcmVhc29uIHRvIHNlcGFyYXRlIFJFU1RDT05GIHN1YnNjcmlwdGlvbiBSUENzIGZyb20gdGhl
IEhUVFAyIHN0cmVhbSB1c2VkIGZvciBldmVudHMuICAgKFRoZSB3YXkgaXQgY291bGQgYmUgZG9u
ZSBpcyBoYXZlIG1vZGlmeS1zdWJzY3JpcHRpb24gYW5kIGRlbGV0ZS1zdWJzY3JpcHRpb25zIGNv
bWUgaW4gb24gYSBkaWZmZXJlbnQgc3RyZWFtLCBpbXBhY3RpbmcgdGhlIEhUVFAyIHN0cmVhbSB3
aGVyZSBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIHN0YXJ0ZWQgdGhpbmdzIG9mZi4gIEFnYWluIEkg
YW0gbm90IHJlY29tbWVuZGluZyB0aGlzIGZvciBtdWx0aXBsZSByZWFzb25zLikNCiANCj4gPiBT
byBpZg0KPiA+IHNvbWVvbmUgd2FudGVkIHRoaXMsIHdlIHdvdWxkIHN0aWxsIG5lZWQgdG8gcmVm
aW5lDQo+ID4gZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmIHJlcXVpcmVtZW50cyB3
aXRoIHRoZSBhYmlsaXR5IHRvDQo+ID4gbW9kaWZ5IG9yIGRlbGV0ZSBhbiBleGlzdGluZyBzdWJz
Y3JpcHRpb24gb24gYSBkaWZmZXJlbnQgSFRUUDIgc3RyZWFtLg0KPiANCj4gSXNuJ3QgdGhpcyBo
b3cgaXQgaXMgc3VwcG9zZWQgdG8gd29yaz8gDQoNClllcy4gIE15IHBvaW50IHdhcyB0aGF0IG5v
Ym9keSBoYXMgcHJvcG9zZWQgcmVmaW5pbmcgdGhlIHNwZWMgdG8gZm9yY2luZyBvZiBlYWNoIFJF
U1RDT05GIHRyYW5zYWN0aW9uIG9uIGRpZmZlcmVudCBIVFRQMiBzdHJlYW1zLg0KDQo+IFRoZSBk
cmFmdCBpcyBzaWxlbnQgb24gaG93IHRvIGRlbGV0ZSBhDQo+IHN1YnNjcmlwdGlvbiwgYW5kIGFs
c28gb24gaG93IG1vZGlmeS1zdWJzY3JpcHRpb24gaXMgc3VwcG9zZWQgdG8gd29yay4NCg0KQ2Vy
dGFpbmx5IHRoZXNlIGNhbiBjb21lIGluIG9uIGEgZGlmZmVyZW50IEhUVFAyIHN0cmVhbS4NCiAN
Cj4gVGhlIGRyYWZ0IGlzIGFsc28gc2lsZW50IG9uIHRoZSBsaWZldGltZSBvZiB0aGUgcmVzdWx0
IG9mICJlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIi4NCj4gV2l0aCBORVRDT05GLCB0aGUgc3Vic2Ny
aXB0aW9uIGVuZHMgaWYgdGhlIHNlc3Npb24gZW5kcywgYnV0IGluIFJFU1RDT05GDQo+IHRoZXJl
IGFyZSBubyBzZXNzaW9ucywgc28gaG93IGxvbmcgZG9lcyB0aGUgc3Vic2NyaXB0aW9uIGxpdmUg
YWZ0ZXIgaXQgaGFzIGJlZW4NCj4gY3JlYXRlZD8NCg0KVGhlcmUgYXJlIG1lY2hhbmlzbXMgZGVm
aW5lZC4gIFNlZSANCmRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiwgU2VjdGlvbiAz
LjEuIA0KYW5kDQpkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLCBz
ZWN0aW9ucyAxLjMgJiA1LjMuDQoNCkVyaWMNCg0KPiBOb3RlIHRoYXQgdGhlIGFwcHJvYWNoIGlu
IFJGQyA4MDQwIGlzIGRvZXNuJ3QgaGF2ZSB0aGlzIGlzc3VlLg0KPiANCj4gDQo+IC9tYXJ0aW4N
Cj4gDQo+IA0KPiA+IFRoaXMgY291bGQgYmUgZG9uZSBvZiBjb3Vyc2UsIGJ1dCBzb21lb25lIHdv
dWxkIG5lZWQgdG8gZHJpdmUgdGhlDQo+ID4gZGVmaW5pdGlvbi4NCj4gPg0KPiA+IEVyaWMNCj4g
Pg0KPiA+DQo+ID4gV291bGQgaXQgYmUgd3JvbmcgZm9yIGEgY2xpZW50IHRvIG1ha2UgYW55IGFz
c3VtcHRpb25zPyAgSSByZWFsaXplDQo+ID4gdGhpcyBBU1NVTUVzIGEgdHJhbnNwb3J0IHByb3Rv
Y29sLCBidXQgY291bGQvd291bGQgdGhlcmUgYmUgYQ0KPiA+IG9uZS10aW1lLCBjYXBhYmlsaXR5
IGNoZWNrIHRoZSBjbGllbnQgY291bGQgbWFrZSB0byB0ZXN0IGZvciBhdmFpbGFibGUNCj4gPiB0
cmFuc3BvcnRzPw0KPiA+DQo+ID4gSSByZWFsbHkgYXBwcmVjaWF0ZSB5b3VyIHRpbWUgZXhwbGFp
bmluZywgSSBoYXZlIGJlZW4gZm9sbG93aW5nIHRoZQ0KPiA+IGVtYWlscyBiZXN0IEkgY291bGQg
YnV0IEkgdGhpbmsgc29tZSBiYXNpYyB0aGluZ3MgYXJlIHN0aWxsIGVsdWRpbmcNCj4gPiBtZS4N
Cj4gPg0K


From nobody Wed Sep 19 16:06:30 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D37130DC8 for ; Wed, 19 Sep 2018 16:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham 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 xuNbb0fSsIQT for ; Wed, 19 Sep 2018 16:06:28 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 918ED1274D0 for ; Wed, 19 Sep 2018 16:06:28 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8JN55KS004443; Wed, 19 Sep 2018 16:06:24 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=rTHI3orDnzKWLYa50pZpWi1x0gOk8uXnJByCU3+9bAM=; b=dv4Lz3BFW8ERiiRMNEUY03NtaiX22DPP4fXtEETjj631GsCIBZo3jRk6hwzL8QrPST3Z eevS6khJExb69JDmVqTx1U+bBhtMOfeveJzh1icE+DJ4b1qYf7xJuqXfESGNsCc8d4u7 mzUDcP0A+vMve/BbVEIK2Uu9swR/ftXO0jXrX+QDsMFxP3zCn/U6QBAq1yUgni67u5NF swWzBFGPdHX/uVLQpwFOyT93gC479CoTVrYUrz89KeKyHz6WtGvr0wNmHPVXkUdHuy62 sl9YnktDQ1ynbjzI/5ddMDj27Ae1ApZO4yfFmMKJwUkCj1MQZ6fE8XrDeP00R5K/CSyI +w== 
Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp0112.outbound.protection.outlook.com [216.32.181.112]) by mx0a-00273201.pphosted.com with ESMTP id 2mks09gwn8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 19 Sep 2018 16:06:24 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4874.namprd05.prod.outlook.com (20.176.112.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1164.18; Wed, 19 Sep 2018 23:06:22 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1164.014; Wed, 19 Sep 2018 23:06:21 +0000
From: Kent Watsen 
To: Alexander Clemm , Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImouJGUP0t9tESR9VzM68tuEKTUcIIAgABzP4CAARMGAIAA0q0AgADJvACAIJtvAA==
Date: Wed, 19 Sep 2018 23:06:21 +0000
Message-ID: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net>
References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB59E44@sjceml521-mbs.china.huawei.com> <20180828.100917.925597025431754922.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5B32B@sjceml521-mbs.china.huawei.com> <20180829.150740.1323981906990283714.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5B91A@sjceml521-mbs.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5B91A@sjceml521-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4874; 6:oWD8jxhAGp0raYFuEKPZ+QPseoywu5CnccNiVv/GYX/sWS+bd/u2wHosfnBzVB2ek+Gy66nnLGS7OHO0HHz4/jNJdCNUKVfL8nUborWU700JFvjOSsMzZOp9w/+LEgfbyK41PiP3XwTRNM2tIDpqZ3fMawcdnRAFIkTjYibgbUjU9L3a5yROc4JPkYKxRulD23aQKTXuojdALMZmajarE6LxSQMf0zfwcUiBWRTzmlDYb3VazawYA6eJ+xzlV6QPItFtrfDu7SP+gji2Kcybj83W+HL2cUpy5CM6qj6Ue0HwFlu9Q4BrjsSgUy4/kfOmTmYLbJtvGIwfVGneWCdeuZ3OyzL3Jww9WLeFJl+Ei0bDyzSi7F9JJTptsD/g7H7665Vp4EUBmIsIJTKbv7Gzi1+g9oSGqeTrOPWhKsF7RXI0of5gpkcOgGpFYu1UACveZIgXZHMENjzCf8u+7ZS9zg==; 5:1j6yiYLDx33nGFqg4UYSDHBeAWa+Z9cze4ib5xkTpjzQjdtKt+lIf3IM1r/SZM/XXtgZ4ugNljLCLDJho7S9C66qVPUF8Z+pW5DhjmsXnEsCcoBwWzYZZlhkOAgbe0NuSDZaNmnJ4DLLiYhh8gFAW7YNxLxxxUWpranXupHlhmM=; 7:IpiW9pQ7rPTtTki5SBRgxFiaUI9qhjKx7VhNoSwPPHHSe8MYsXIiaYTMqw0CUY27Yj4/B0ss5yqQRMqU9Bo0ZeAKulG/MND3TZd/uJnFAacSk7EbXNg+m/uL7Alan416Ehfxqdu3g2EefhacsUh0q+p1lTV92NqZFY73gTQyfog9FfS85qMVdh5ig/lKG43WPQuw8wfypTmAhhR1Y+/MWVNzzvZZxaRKPL+e+uib+iHG0TjhFfKFXG4SDv5fHLYj
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 9f7d7784-05c9-49f4-4a89-08d61e848412
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4874; 
x-ms-traffictypediagnostic: DM6PR05MB4874:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051); SRVR:DM6PR05MB4874; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4874; 
x-forefront-prvs: 0800C0C167
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(396003)(39860400002)(376002)(366004)(199004)(189003)(66066001)(2900100001)(186003)(6506007)(5250100002)(6246003)(25786009)(99286004)(4326008)(446003)(68736007)(8676002)(11346002)(6512007)(229853002)(110136005)(58126008)(71190400001)(71200400001)(53936002)(6486002)(102836004)(6436002)(316002)(305945005)(105586002)(26005)(7736002)(86362001)(76176011)(106356001)(33656002)(97736004)(486006)(82746002)(5660300001)(478600001)(81156014)(81166006)(2616005)(36756003)(14454004)(476003)(83716003)(256004)(93886005)(8936002)(558084003)(6116002)(2906002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4874; H:DM6PR05MB4665.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-microsoft-antispam-message-info: Viq8w59rnkA8oJQ2oxgAVmtQxBxoFY7R5oyOdJ5QaBdlVVPzQAkl5f12R+3N6LFT+TrvYMOdAPZSYMviodBtIG/KbY6tg4neAtfa3DX6sT9BnqS+YtXwUWO33nz08/TgqAUYghxxhr9tpYGkAOwWhwKJKgkaJD68DARfoigdfPpGe/cvYfYsCP2Mn2r7ZceQuOwYSLwIBiotSd07JBqtcLIVMulHp1JdpupyGmSZ0b9Q9r3AAW477xYQ2RQ7pVwgaxSffA9FSgdW1ryFltgbPkljJGivyx50Zf2CVYpCbRE8u81SjazdaFSOrFOmMdp4eiHNgY2kjSsVPbG7FhYIjnE8QTbeGFKDGazBJbQir18=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <571550000509E743B7921547E36F9832@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f7d7784-05c9-49f4-4a89-08d61e848412
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2018 23:06:21.8710 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4874
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-19_11:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=800 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809190223
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Sep 2018 23:06:30 -0000

SGkgTWFydGluLA0KDQpJJ20gc3VycHJpc2VkIHRvIHNlZSB0aGF0IHlvdXIgcmV2aWV3IGRvZXNu
J3Qgc3VnZ2VzdCBjaGFuZ2luZyAieXA6cGVyaW9kIiBmcm9tIHlhbmc6dGltZXRpY2tzIHRvIHNl
Y29uZHMuDQoNCllvdSBoYWQgcHJldmlvdXNseSBtYWRlIHRoaXMgc3VnZ2VzdGlvbiBpbiBhbm90
aGVyIHRocmVhZCwgYnV0IGl0J3Mgc3RpbGwgdGltZXRpY2tzIGluIC0xOC4NCg0KS2VudCAvLyBh
bGwgaGF0DQoNCg0KDQoNCg0K


From nobody Thu Sep 20 00:20:19 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED773130E52 for ; Thu, 20 Sep 2018 00:20:17 -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 DN0FsmREqtTO for ; Thu, 20 Sep 2018 00:20:15 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BFD63130DD1 for ; Thu, 20 Sep 2018 00:20:14 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 2750D1AE02C9; Thu, 20 Sep 2018 09:20:12 +0200 (CEST)
Date: Thu, 20 Sep 2018 09:20:11 +0200 (CEST)
Message-Id: <20180920.092011.809234550582033045.mbj@tail-f.com>
To: evoit@cisco.com
Cc: douglas@hubler.us, andy@yumaworks.com, j.schoenwaelder@jacobs-university.de, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1f83e10a61fc4a89bf5e1264566a3e29@XCH-RTP-013.cisco.com>
References: <48e4aac958d142669f4032737cdc4373@XCH-RTP-013.cisco.com> <20180919.083805.1103902318002046181.mbj@tail-f.com> <1f83e10a61fc4a89bf5e1264566a3e29@XCH-RTP-013.cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: [Netconf] SSE and HTTP/2 in restcon-notif [Was: activate-configured-subecription - WGLC subscribed-notifications-16]
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2018 07:20:18 -0000

SGksDQoNCltzdWJqZWN0IGNoYW5nZTsgdGhpcyB0aHJlYWQgaXMgbm93IGFib3V0IFNTRSBhbmQg
SFRUUC8yXQ0KDQoiRXJpYyBWb2l0IChldm9pdCkiIDxldm9pdEBjaXNjby5jb20+IHdyb3RlOg0K
PiA+IEZyb206IE1hcnRpbiBCam9ya2x1bmQsIFNlcHRlbWJlciAxOSwgMjAxOCAyOjM4IEFNDQo+
ID4gDQo+ID4gSGksDQo+ID4gDQo+ID4gIkVyaWMgVm9pdCAoZXZvaXQpIiA8ZXZvaXRAY2lzY28u
Y29tPiB3cm90ZToNCj4gPiA+IEhpIERvdWdsYXMsDQo+ID4gPg0KPiA+ID4gRnJvbTogRG91Z2xh
cyBIdWJsZXIsIFNlcHRlbWJlciAxOCwgMjAxOCA1OjM1IFBNDQo+ID4gPg0KPiA+ID4NCj4gPiA+
IE9uIFR1ZSwgU2VwIDE4LCAyMDE4IGF0IDM6NDAgUE0gTWFydGluIEJqb3JrbHVuZA0KPiA+ID4g
PG1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT4+IHdyb3RlOg0KPiA+ID4gU28g
aXQgc2VlbXMgeW91IHN1cHBvcnQgbXkgcG9pbnQgdG8gbWFrZSB0aGlzIGRyYWZ0IHVzZSBTU0Uu
ICBUaGVuIGlmDQo+ID4gPiB5b3UgdXNlIEhUVFAvMiB5b3UgKHRoZSBjbGllbnQpIGNhbiBzaW1w
bHkgY3JlYXRlIG9uZSBIVFRQLzIgc3RyZWFtDQo+ID4gPiBwZXIgbm90aWZpY2F0aW9uIHN0cmVh
bS4gIFRoaXMganVzdCBmYWxscyBvdXQgZm9yIGZyZWUgd2l0aCBIVFRQLzIuDQo+ID4gPg0KPiA+
ID4geWVzLCB3aXRoIGNhdmVhdCB0aGF0IEkgaGF2ZW4ndCBhdHRlbXB0ZWQgYWN0dWFsIGltcGxl
bWVudGF0aW9uIHlldC4NCj4gPiA+DQo+ID4gPiA8RXJpYz4gQWdyZWUgdGhhdCBTU0Ugb3ZlciBI
VFRQMiBzaG91bGQgd29yay4gIEhvd2V2ZXIgdG8gbWUgdXNpbmcgU1NFDQo+ID4gPiBoZXJlIHNl
ZW1zIHJlZHVuZGFudCBhcyBIVFRQMiBwcm92aWRlcyB0aGUgbmVjZXNzYXJ5IG1lY2hhbmlzbXMu
DQo+ID4gDQo+ID4gRXJpYywgY2FuIHlvdSBleHBsYWluIGhvdyB0aGlzIHdvdWxkIHdvcmsgdy9v
IFNTRT8gIFdoaWNoIG1lY2hhbmlzbSBpbg0KPiA+IEhUVFAvMiBhcmUgeW91IHJlZmVycmluZyB0
bz8NCj4gDQo+IEFmdGVyIGFuIEhUVFAyIE9LLCB0aGUgSFRUUDIgc2VydmVyIGhhcyB0aGUgYWJp
bGl0eSB0byBmb3J3YXJkIGFuDQo+IHVuYm91bmRlZCBudW1iZXIgb2YgSFRUUDIgRGF0YSBGcmFt
ZXMgb24gdGhlIEhUVFAyIHN0cmVhbS4NCg0KQnV0IGl0IG11c3Qgc3RpbGwgYWRoZXJlIHRvIHRo
ZSBub3JtYWwgSFRUUCBzZW1hbnRpY3MuICBJZiB0aGVyZSB3YXMgYQ0KcmVxdWVzdCwgaXQgbmVl
ZHMgdG8gc2VuZCB0aGUgcmVzcG9uc2UuICBJdCBjYW4gc3BsaXQgdGhlIHJlc3BvbnNlDQppbnRv
IHNldmVyYWwgREFUQSBmcmFtZXMgb2YgY291cnNlLiAgQnV0IGl0IGNhbm5vdCBzdGFydCB0byBz
ZW5kDQoib3RoZXIgc3R1ZmYiIGluc3RlYWQgb2YgdGhlIHJlc3BvbnNlLCB3aGljaCBmaWd1cmUg
MSBpbg0KcmVzdGNvbmYtbm90aWYtMDcgcG9zc2libHkgaW1wbGllcy4NCg0KPiBUaGUgc3RyZWFt
DQo+IGlzIG5vdCBjb25zaWRlcmVkIGNvbXBsZXRlIHVudGlsIGFuIEVORF9TVFJFQU0gaXMgcGFz
c2VkLiAgKE5vdGUgdGhpcw0KPiBpcyBpbmRlcGVuZGVudCBvZiBhbnl0aGluZyByZWdhcmRpbmcg
SFRUUDIncyBQVVNIX1BST01JU0UuKQ0KPiANCj4gWW91IGNhbiBzZWUgYW4gZXhhbXBsZSBmbG93
IGluIEZpZ3VyZSAxIG9mDQo+IGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZi4gIEF0
IElFVEYgOTcgd2UgYXNrZWQgZm9yIHNvbWUNCj4gRmVlZGJhY2sgb24gdGhpcyBwcm9wb3NhbC4N
Cj4gaHR0cDovL3d3dy52b2l0Lm9yZy9JRVRGL1N1YnNjcmlwdGlvbnMtTkVUQ09ORi1JRVRGOTcu
cHB0IChzZWUgc2xpZGUNCj4gMTQpLg0KPiBCdXQgSSBhbSBub3Qgc3VyZSBob3cgbXVjaCBlZmZv
cnQgdGhlIFdHIHNob3VsZCBwbGFjZSBoZXJlLiAgVGhlIHdvcmsNCj4gaGVyZSBpcyBzZXZlcmFs
IHllYXJzIG9sZCwgYW5kIHRoZSBtYXJrZXQgaGFzIG1vdmVkIHN1YnN0YW50aWFsbHkNCj4gc2lu
Y2UgdGhlbi4NCg0KU28gZG8gd2UgYWdyZWUgdGhhdCB0aGUgcmVzdGNvbmYtbm90aWYgZHJhZnQg
d2lsbCBiZSB1cGRhdGVkIHRvIHVzZQ0KU1NFIHJlZ2FyZGxlc3Mgb2YgSFRUUCB2ZXJzaW9uPyAg
SWYgdGhlcmUgaXMgYW55IHRleHQgYXQgYWxsIGFib3V0DQpIVFRQLzIsIGl0IHdpbGwgYmUgYW4g
ImltcGxlbWVudGF0aW9uIG5vdGUiIHdoZXJlIGl0IGlzIHJlY29tbWVuZGVkIHRvDQp1c2UgYSBz
ZXBhcmF0ZSBzdHJlYW0gcGVyIHN1YnNjcmlwdGlvbj8NCg0KPiA+ID4gQnV0DQo+ID4gPiBJIHdv
buKAmXQgZ2V0IGluIHRoZSB3YXkgaWYgcGVvcGxlIHJlYWxseSBkbyB3YW50IHRvIGdvIGluIHRo
aXMNCj4gPiA+IGRpcmVjdGlvbi4NCj4gPiA+DQo+ID4gPiA+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0
aGUgZGV0YWlscyBzdXJyb3VuZGluZyB1c2luZyBhbiBSUEMgdG8gbWFrZSBhDQo+ID4gPiA+IGR5
bmFtaWMgc3Vic2NyaXB0aW9uLiAgVW5sZXNzIGl0J3Mgb3B0aW9uYWwsIHRoZW4gSSBjYW4gc3Rh
cnQgdG8NCj4gPiA+ID4gdW5kZXJzdGFuZC4NCj4gPiA+DQo+ID4gPiBUaGUgY2xpZW50IHdvdWxk
IFBPU1QgdG8gdGhlICJycGMiIGVzdGFibGlzaC1zdWJzY3JpcGlvbiwgYW5kIGluIHRoZQ0KPiA+
ID4gcmVwbHkgdG8gdGhlIFBPU1QgaXMgYSAibG9jYXRpb24iIGxlYWYgKCopIHRoYXQgY29udGFp
bnMgYSBVUkkuICBUaGUNCj4gPiA+IGNsaWVudCB0aGVuIEdFVCB0aGlzIFVSSTsgdGhpcyBpcyB0
aGUgU1NFIGV2ZW50IHN0cmVhbS4NCj4gPiA+DQo+ID4gPiBJIHNlZS4gIEJ1dCBpZiBhIGNsaWVu
dCByZWFkcyB0aGUgWUFORyBhcw0KPiA+ID4NCj4gPiA+ICBtb2R1bGUgbXktbW9kdWxlIHsNCj4g
PiA+ICAgICAuLi4NCj4gPiA+ICAgICBub3RpZmljYXRpb24gbXktZXZlbnQgew0KPiA+ID4gICAg
IH0NCj4gPiA+IH0NCj4gPiA+DQo+ID4gPiBhbmQgY2xpZW50IGtuZXcgYmFzZSBzdHJlYW0gVVJJ
IHdhczoNCj4gPiA+DQo+ID4gPiAgICAvcmVzdGNvbmYvbXktc3RyZWFtcw0KPiA+ID4NCj4gPiA+
IENvdWxkbid0IHRoZSBjbGllbnQgdGhlbiBkZWR1Y2UgU1NFIFVSTCBhczoNCj4gPiA+DQo+ID4g
PiAgR0VUICAvcmVzdGNvbmYvbXktc3RyZWFtcy9teS1tb2R1bGU6bXktZXZlbnQ/Li4uDQo+ID4g
DQo+ID4gTm8uDQo+ID4gDQo+ID4gV2l0aCBSRkMgODA0MCwgdGhlIFNTRSBVUkwgaXMgInN0YWJs
ZSIsIGFuZCBpZiB0aGUgY2xpZW50IGhhcyByZWFkIGl0DQo+ID4gb252ZSwgaXQNCj4gPiBkb2Vz
bid0IGhhdmUgdG8gcmVhZCBpdCBhZ2FpbiAobW9kdWxvIHNvbWUgZGVmaW5pdGlvbiBvZiAic3Rh
YmxlIikuDQo+ID4gVGhlIGNsaWVudA0KPiA+IGNhbiBwYXNzIGEgZmlsdGVyIGluIHRoZSBHRVQg
cmVxdWVzdCBmb3IgdGhlIFNTRSBzdHJlYW0uDQo+ID4gDQo+ID4gV2l0aCB0aGUgbWVjaGFuaXNt
IGluIHRoaXMgZHJhZnQsIHRoZSBTU0UgVVJMIHdpbGwgdmFyeSBmb3IgZWFjaA0KPiA+IHJlcXVl
c3QgdGhhdA0KPiA+IGhhcyBhIGRpZmZlcmVudCBmaWx0ZXIgKGF0IGEgbWluaW11bSksIHNpbmNl
IHRoZSBmaWx0ZXIgaXMgcGFzc2VkIGENCj4gPiBwYXJhbWV0ZXIgdG8NCj4gPiAiZXN0YWJsaXNo
LXN1YnNjcmlwdGlvbiIgYW5kIHRoZSBTU0UgVVJMIGlzIHNlbnQgYmFjayBpbiB0aGUgcmVwbHkg
dG8NCj4gPiAiZXN0YWJsaXNoLQ0KPiA+IHN1YnNjcmlwdGlvbiIuICBXaXRoIHRoZSBTU0UgVVJM
LCB0aGUgc2VydmVyIG1heSBoaWRlIHNvbWUgc3RhdGUgdGhhdA0KPiA+IGNvcnJlc3BvbmRzIHRv
IHRoZSBmaWx0ZXIgcGFyYW1zIGV0Yy4gIChOT1RFIHRoZSB3b3JkICptYXkqIGluIHRoZQ0KPiA+
IHByZXZpb3VzDQo+ID4gc2VudGVuY2UuICBBIHNlcnZlciBjb3VsZCBhcyB3ZWxsIHNlbmQgYmFj
ayBhIFNTRSBVUkwgd2l0aCB0aGUgZmlsdGVyDQo+ID4gcGFyYW1ldGVycyBlbWJlZGRlZCBpbiB0
aGUNCj4gPiBVUkwuLi4pDQo+ID4gDQo+ID4gU28gaW4gZ2VuZXJhbCwgYSBjbGllbnQgY2Fubm90
IGFzc3VtZSB0aGF0IGl0IGNhbiByZS11c2UgYSBTU0UgVVJMDQo+ID4gdGhhdCB3YXMNCj4gPiBy
ZXR1cm5lZCBmcm9tIGEgY2FsbCB0byAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIuDQo+ID4gDQo+
ID4gPiBUaGVyZWJ5IHNhdmluZyBhIHRyaXAgdG8gc2VydmVyPw0KPiA+ID4NCj4gPiA+IDxFcmlj
PiBZZXMsIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIHNldCBzb21ldGhpbmcgdXAgdG8gZGVkdWNl
IHRoZQ0KPiA+ID4gVVJMLiAgZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmIGRvZXNu
4oCZdCBjdXJyZW50bHkgYXR0ZW1wdCB0aGlzDQo+ID4gPiBhcyBiZWluZyBhYmxlIHRvIGRlZHVj
ZSB0aGUgVVJMIGRvZXNu4oCZdCBzdG9wIHRoZSBleHRyYSB0cmlwIHRvIHRoZQ0KPiA+ID4gc2Vy
dmVyLg0KPiA+ID4NCj4gPiA+IFRoZSByZWFzb24gaXQgZG9lc27igJl0IGdldCByaWQgb2YgdGhl
IGV4dHJhIHJvdW5kIHRyaXAgaGFzIHRvIGRvIHdpdGgNCj4gPiA+IEhUVFAyIHN0cmVhbXMuICBJ
ZiB3ZSBhcmUgZ29pbmcgdG8gdXNlIEhUVFAyLCB0aGVyZSBpcyBzdGlsbCBhIG5lZWQgdG8NCj4g
PiA+IGluaXRpYXRlIHRoZSBHRVQgKG9yIFBPU1QpIGluIGEgc2VwYXJhdGUgc3RyZWFtIG90aGVy
IHRoYW4gdGhlIG9uZQ0KPiA+ID4gYmVpbmcgdXNlZCBmb3IgUkVTVENPTkYgc2lnbmFsaW5nLg0K
PiA+IA0KPiA+IEkgZGlzYWdyZWUuICBJZiB0aGUgY2xpZW50IHdhbnRzIHRvIGhhdmUgYSBzZXBh
cmF0ZSBIVFRQLzIgc3RyZWFtIGZvcg0KPiA+IHRoZSBub3RpZnMsDQo+ID4gdGhlbiBpdCBzaG91
bGQgc3RhcnQgc3VjaCBhIHN0cmVhbS4gIElmIHRoZSBjbGllbnQgZG9lc24ndCB3YW50IGENCj4g
PiBzZXBhcmF0ZSBIVFRQLzINCj4gPiBzdHJlYW0gdGhlbiB0aGF0IHNob3VsZCBiZSBvayB0b28u
DQo+IA0KPiBQZXIgeW91ciBiZWxvdywgb25jZSBTU0UgaXMgYXBwbGllZCBhIHN0cmVhbSBpcyBi
bG9ja2VkLiAgRm9yIHRoYXQNCj4gc3Vic2NyaXB0aW9uLCB5b3Ugc3RpbGwgbmVlZCB0byBzdXBw
b3J0ICdtb2RpZnktc3Vic2NyaXB0aW9uJyBhbmQNCj4gJ2RlbGV0ZS1zdWJzY3JpcHRpb24nIHJw
Y3MuDQoNCkJ1dCB0aGUgc29sdXRpb24gY2Fubm90IGRlcGVuZCBvbiB0aGUgc3Vic2NyaWJlciBi
ZWluZyBhYmxlIHRvIHNlbmQNCiJkZWxldGUtc3Vic2NyaXB0aW9uIiBvbiB0aGUgc2FtZSB0cmFu
c3BvcnQgc2Vzc2lvbiAoQlRXLCB0aGlzDQpyZXF1aXJlbWVudCBzaG91bGQgYmUgY2xhcmlmaWVk
IGluIHRoZSBZQU5HIGRlZmluaXRpb24gZm9yDQoiZGVsZXRlLXN1YnNjcmlwdGlvbiIgaW4gU04p
LCBzaW5jZSB0aGlzIHdvdWxkIHJ1bGUgb3V0IEhUVFAvMS4xLg0KDQoibW9kaWZ5LXN1YnNjcmlw
dGlvbiIgY2FuIGJlIHNlbnQgb24gYW5vdGhlciBzZXNzaW9uLCBlLmcuLCBhbm90aGVyDQpIVFRQ
LzEuMSBzZXNzaW9uIHRoYXQgaXMgbm90IGRvaW5nIHRoZSBTU0VzLg0KDQpUaGlzIG1ha2VzIG1l
IHdvbmRlci4uLiBpcyAiZGVsZXRlLXN1YnNjcmlwdGlvbiIgcmVhbGx5IG5lY2Vzc2FyeSwgb3IN
CmlzICJraWxsLXN1YnNjcmlwdGlvbiIgc3VmZmljaWVudD8NCg0KPiBCZXlvbmQgdGhhdCwgb25l
IHRoaW5nIHRvIGtlZXAgYW4gZXllIG9uIGlzIHRoZSBwb3RlbnRpYWwgZm9yIGJ1bmRsaW5nDQo+
IG9mIGV2ZW50IHJlY29yZHMgZnJvbSBkaWZmZXJlbnQgc3Vic2NyaXB0aW9ucyBpbnRvIGEgc2lu
Z2xlDQo+IHRyYW5zbWl0dGFibGUgbm90aWZpY2F0aW9uIG1lc3NhZ2UuDQoNCkhvdyB3b3VsZCBh
biBIVFRQIHN1YnNjcmliZXIgZXZlbiByZXF1ZXN0IHRoaXM/DQoNClRoZSBzdWJzY3JpYmVyIHNl
bmRzIGFuIGVzdGFibGlzaC1zdWJzY3JpcHRpb24gYW5kIGdldCBhbiBVUkwgZm9yIHRoYXQNCnN1
YnNjcmlwdGlvbiBiYWNrLg0KDQpUaGVuIGl0IHNlbmRzIGFub3RoZXIgZXN0YWJsaXNoLXN1YnNj
cmlwdGlvbiBhbmQgZ2V0cyBhbm90aGVyIFVSTA0KYmFjay4NCg0KSG93IGNhbiBhIGJ1bmRsZWQg
bWVzc2FnZSBiZSBzZW50IHdoZW4gdGhlcmUgYXJlIHR3byBkaWZmZXJlbnQNCnN1YnNjcmlwdGlv
biByZXNvdXJjZXM/DQoNCg0KPiAoU29tZXRoaW5nIGxpa2UgaW4NCj4gZHJhZnQtaWV0Zi1uZXRj
b25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcy4pICBBbnl3aGVyZSBzdWNoIGJ1bmRsaW5nDQo+IG9j
Y3VycywgdGhlIHB1Ymxpc2hlciB3aWxsIGhhdmUgdG8gdXNlIGEgY29uc2lzdGVudCBIVFRQMiBz
dHJlYW0NCj4gYWNyb3NzIGEgc2V0IG9mIHN1YnNjcmlwdGlvbnMgaW4gb3JkZXIgdG8gcHJlc2Vy
dmUgZXZlbnQgcmVjb3JkDQo+IG9yZGVyaW5nLiAgSW4gYWRkaXRpb24sIGFsbCBldmVudCByZWNv
cmRzIGJ1bmRsZWQgd2lsbCBoYXZlIHRvDQo+IGNvbnNpc3RlbnRseSB1c2UgdGhlIHNhbWUgRFND
UC4NCj4gDQo+IE5vdGU6IHRoaXMgaXMgYW5vdGhlciByZWFzb24gd2h5IGl0IGlzIGEgZ29vZCBp
ZGVhIHRvIHVzZSBzZXBhcmF0ZQ0KPiBIVFRQMiBzdHJlYW1zIGZvciBSRVNUQ09ORiBzdWJzY3Jp
cHRpb24gUlBDIGludGVyYWN0aW9ucywgYW5kIGZvciB0aGUNCj4gc3RyZWFtaW5nIG9mIGV2ZW50
IHJlY29yZHMuDQo+IA0KPiA+IENvbXBhcmUgdG8gTkVUQ09ORi4gIEhUVFAvMiBzdHJlYW1zIGFy
ZSBzaW1pbGFyIHRvIFNTSCBjaGFubmVscy4gIEENCj4gPiBORVRDT05GIGNsaWVudCBjYW4gb3Bl
biBhIHNlcGFyYXRlIFNTSCBjaGFubmVsIGZvciBlYWNoIHN1YnNjcmlwdGlvbiwNCj4gPiBvciBp
dA0KPiA+IGNhbiB1c2UgYSBzaW5nbGUgY2hhbm5lbC4gIFVwIHRvIHRoZSBjbGllbnQuDQo+IA0K
PiBIVFRQMiBzdHJlYW1zIGhhdmUgZmFyIGxlc3Mgb3ZlcmhlYWQsIGxvd2VyIHNldHVwIGxhdGVu
Y3ksIGFuZCBtb3JlDQo+IHNjYWxhYmlsaXR5IHRoYW4gc2VwYXJhdGUgU1NIIGNoYW5uZWxzLg0K
DQpSZWFsbHk/ICBBbiBTU0ggY2hhbm5lbCBpcyBzdXBlciBjaGVhcC4gIFdoeSBkbyB5b3UgdGhp
bmsgdGhhdCBIVFRQLzINCnN0cmVhbXMgaGF2ZSAiZmFyIGxlc3MiIG92ZXJoZWFkPyAgVGhlcmUg
Y2FuIGJlIDJeMzIgY2hhbm5lbHMgaW4gYW4NClNTSCBzZXNzaW9uLCBhbmQgMl4zMSBzdHJlYW1z
IGluIGEgSFRUUC8yIHNlc3Npb24uDQoNCihGb3IgcmVmZXJlbmNlLCBpbiBjYXNlIGl0IHdhc24n
dCBjbGVhcjogUkZDIDQyNTQsIHNlY3Rpb24gNSkNCg0KPiA+ID4gU29tZW9uZSBjb3VsZCB3cml0
ZSBhIHNwZWNpZmljYXRpb24gd2hpY2ggZ2V0cyBhcm91bmQgdGhpcyBieSBmb3JjaW5nDQo+ID4g
PiBldmVyeSBSRVNUQ09ORiB0cmFuc2FjdGlvbiBvbiBpdHMgb3duIEhUVFAyIHN0cmVhbS4gIEJ1
dCBub2JvZHkgaGFzDQo+ID4gPiBwcm9wb3NlZCBzdWNoIGEgc3BlY2lmaWNhdGlvbi4gIFBsdXMg
dGhlcmUgYXJlIFFvUyBzY2VuYXJpb3Mgd2hlcmUgeW91DQo+ID4gPiBtaWdodCB3YW50IG11bHRp
cGxlIHN1YnNjcmlwdGlvbnMgb24gdGhlIHNhbWUgSFRUUDIgc3RyZWFtLg0KPiA+IA0KPiA+IEhv
dyB3b3VsZCB0aGlzIHdvcms/ICBPbmNlIHlvdSBzdGFydCBTU0Ugb24gYSBzdHJlYW0sIHRoYXQg
c3RyZWFtIGlzDQo+ID4gImJsb2NrZWQiLCByaWdodD8NCj4gDQo+IEFuZCBwZXIgYWJvdmUsIHRo
aXMgaXMgYSBnb29kIHJlYXNvbiB0byBzZXBhcmF0ZSBSRVNUQ09ORiBzdWJzY3JpcHRpb24NCj4g
UlBDcyBmcm9tIHRoZSBIVFRQMiBzdHJlYW0gdXNlZCBmb3IgZXZlbnRzLiAgKFRoZSB3YXkgaXQg
Y291bGQgYmUgZG9uZQ0KPiBpcyBoYXZlIG1vZGlmeS1zdWJzY3JpcHRpb24gYW5kIGRlbGV0ZS1z
dWJzY3JpcHRpb25zIGNvbWUgaW4gb24gYQ0KPiBkaWZmZXJlbnQgc3RyZWFtLCBpbXBhY3Rpbmcg
dGhlIEhUVFAyIHN0cmVhbSB3aGVyZQ0KPiBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIHN0YXJ0ZWQg
dGhpbmdzIG9mZi4gIEFnYWluIEkgYW0gbm90DQo+IHJlY29tbWVuZGluZyB0aGlzIGZvciBtdWx0
aXBsZSByZWFzb25zLikNCj4gIA0KPiA+ID4gU28gaWYNCj4gPiA+IHNvbWVvbmUgd2FudGVkIHRo
aXMsIHdlIHdvdWxkIHN0aWxsIG5lZWQgdG8gcmVmaW5lDQo+ID4gPiBkcmFmdC1pZXRmLW5ldGNv
bmYtcmVzdGNvbmYtbm90aWYgcmVxdWlyZW1lbnRzIHdpdGggdGhlIGFiaWxpdHkgdG8NCj4gPiA+
IG1vZGlmeSBvciBkZWxldGUgYW4gZXhpc3Rpbmcgc3Vic2NyaXB0aW9uIG9uIGEgZGlmZmVyZW50
IEhUVFAyIHN0cmVhbS4NCj4gPiANCj4gPiBJc24ndCB0aGlzIGhvdyBpdCBpcyBzdXBwb3NlZCB0
byB3b3JrPyANCj4gDQo+IFllcy4gIE15IHBvaW50IHdhcyB0aGF0IG5vYm9keSBoYXMgcHJvcG9z
ZWQgcmVmaW5pbmcgdGhlIHNwZWMgdG8NCj4gZm9yY2luZyBvZiBlYWNoIFJFU1RDT05GIHRyYW5z
YWN0aW9uIG9uIGRpZmZlcmVudCBIVFRQMiBzdHJlYW1zLg0KPiANCj4gPiBUaGUgZHJhZnQgaXMg
c2lsZW50IG9uIGhvdyB0byBkZWxldGUgYQ0KPiA+IHN1YnNjcmlwdGlvbiwgYW5kIGFsc28gb24g
aG93IG1vZGlmeS1zdWJzY3JpcHRpb24gaXMgc3VwcG9zZWQgdG8gd29yay4NCj4gDQo+IENlcnRh
aW5seSB0aGVzZSBjYW4gY29tZSBpbiBvbiBhIGRpZmZlcmVudCBIVFRQMiBzdHJlYW0uDQo+ICAN
Cj4gPiBUaGUgZHJhZnQgaXMgYWxzbyBzaWxlbnQgb24gdGhlIGxpZmV0aW1lIG9mIHRoZSByZXN1
bHQgb2YNCj4gPiAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIuDQo+ID4gV2l0aCBORVRDT05GLCB0
aGUgc3Vic2NyaXB0aW9uIGVuZHMgaWYgdGhlIHNlc3Npb24gZW5kcywgYnV0IGluDQo+ID4gUkVT
VENPTkYNCj4gPiB0aGVyZSBhcmUgbm8gc2Vzc2lvbnMsIHNvIGhvdyBsb25nIGRvZXMgdGhlIHN1
YnNjcmlwdGlvbiBsaXZlIGFmdGVyIGl0DQo+ID4gaGFzIGJlZW4NCj4gPiBjcmVhdGVkPw0KPiAN
Cj4gVGhlcmUgYXJlIG1lY2hhbmlzbXMgZGVmaW5lZC4gIFNlZSANCj4gZHJhZnQtaWV0Zi1uZXRj
b25mLXJlc3Rjb25mLW5vdGlmLCBTZWN0aW9uIDMuMS4gDQoNClRoaXMgc2VjdGlvbiBzYXlzOg0K
DQogICBXaGVyZSBxdWljaw0KICAgcmVjb2duaXRpb24gb2YgdGhlIGxvc3Mgb2YgYSBwdWJsaXNo
ZXIgaXMgcmVxdWlyZWQsIGEgc3Vic2NyaWJlcg0KICAgU0hPVUxEIGNvbm5lY3Qgb3ZlciBUTFMg
W1JGQzUyNDZdLCBhbmQgdXNlIGEgVExTIGhlYXJ0YmVhdCBbUkZDNjUyMF0NCiAgIHRvIHRyYWNr
IEhUVFAgc2Vzc2lvbiBjb250aW51aXR5LiAgSW4gdGhlIGNhc2Ugd2hlcmUgYSBUTFMgaGVhcnRi
ZWF0DQogICBpcyBpbmNsdWRlZCwgaXQgc2hvdWxkIGJlIHNlbnQganVzdCBmcm9tIHJlY2VpdmVy
IHRvIHB1Ymxpc2hlci4gIExvc3MNCiAgIG9mIHRoZSBoZWFydGJlYXQgTVVTVCByZXN1bHQgaW4g
YW55IHN1YnNjcmlwdGlvbiByZWxhdGVkIFRDUCBzZXNzaW9ucw0KICAgYmV0d2VlbiB0aG9zZSBl
bmRwb2ludHMgYmVpbmcgdG9ybiBkb3duLiAgQSBzdWJzY3JpYmVyIGNhbiB0aGVuDQogICBhdHRl
bXB0IHRvIHJlLWVzdGFibGlzaC4NCg0KVGhpcyBpcyBub3QgY2xlYXIgdG8gbWUuDQoNCkZpcnN0
IGl0IHNheXMgdGhhdCBUTFMgU0hPVUxEIGJlIHVzZWQuICBCdXQgd2l0aCBSRVNUQ09ORiwgVExT
IGlzDQphbHJlYWR5IGEgTVVTVC4NCg0KU2Vjb25kLCBpdCBzYXlzIHRoYXQgaW4gdGhlIGNhc2Ug
b2YgbWlzc2VkIFRMUyBoZWFydGJlYXRzLCAicmVsYXRlZA0KVENQIHNlc3Npb25zIiBhcmUgdG9y
biBkb3duLiAgV2hhdCBhcmUgdGhlc2Ugc2Vzc2lvbnMgKHBsdXJhbCksIGFuZA0Kd2hhdCBleGFj
dGx5IGRvZXMgInJlbGF0ZWQiIG1lYW4/DQoNClRoaXJkLCBpdCBzYXlzIHRoYXQgYSBzdWJzY3Jp
YmVyIGNhbiByZS1lc3RhYmxpc2guICBXaGF0IGNhbiBpdA0KcmUtZXN0YWJsaXNoPyAgUmUtc2Vu
ZCB0aGUgZXN0YWJsaXNoLXN1YnNjcmlwdGlvbj8gIEp1c3QgcmVzZW5kIHRoZQ0KUE9TVCB0byB0
aGUgc3Vic2NyaXB0aW9uIFVSTD8NCg0KVGhlIGZsb3cgaXM6DQoNCg0KICAgIFN1YnNjcmliZXIg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFB1Ymxpc2hlcg0KICAgIC0tLS0tLS0t
LS0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLQ0KDQogICAgICAg
fCBSRVNUQ09ORiBQT1NUIChSUEM6ZXN0YWJsaXNoLXN1YnNjcmlwdGlvbikgICB8DQogICAgICAg
fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58DQogICAgICAg
fCAgICAgICAgICAgICAgICAgICAgICAgICAgSFRUUCAyMDAgT0sgKElELFVSSSl8DQogICAgICAg
fDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQogICAgICAg
fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgKCoq
KikNCiAgICAgICB8ICAgSFRUUCBQT1NUIChVUkkpDQogICAgICAgfCAgICB8LS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICB8ICAgIHwgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhUVFAgMjAwIE9LfA0KDQoNCkFmdGVyIHRoZSBw
dWJsaXNoZXIgaGFzIHNlbnQgYSBVUkkgZm9yIHRoZSBzdWJzY3JpcHRpb24gdG8gdGhlDQpzdWJz
Y3JpYmVyLCB0aGVyZSBpcyBhIGRlbGF5ICgqKiopIHVudGlsIHRoZSBzdWJzY3JpYmVyIGhhcyBz
ZW50IHRoZQ0KbmV3IFBPU1QuICBUaGUgcmVzb3VyY2UgdGhhdCB0aGUgVVJJIHBvaW50cyB0byBp
cyBzdWJzY3JpYmVyLXNwZWNpZmljLA0Kd2hpY2ggbWVhbnMgdGhhdCB0aGUgcHVibGlzaGVyIG1h
eSBoYXZlIGNyZWF0ZWQgc29tZSBhc3NvY2lhdGVkDQpzdGF0ZS4gIFRoaXMgc3RhdGUgd2lsbCBl
dmVudHVhbGx5IGhhdmUgdG8gYmUgZGVzdHJveWVkLiAgV2hlbiBjYW4gdGhlDQpwdWJsaXNoZXIg
c2FmZWx5IGRlc3Ryb3kgdGhpcyBzdGF0ZT8NCg0KRm9yIGV4YW1wbGUsIHdoYXQgaGFwcGVucyBp
ZiB0aGUgbmV3IFBPU1QgbmV2ZXIgYXJyaXZlcz8gIElmIHRoZQ0Kc3Vic2NyaWJlciBsb3NlcyBp
dHMgdHJhbnNwb3J0IHNlc3Npb24sIGNhbiBpdCBzZW5kIGEgbmV3IFBPU1QgdG8gdGhlDQpzYW1l
IFVSTD8gIENhbiBpdCBzZW5kIG11bHRpcGxlIFBPU1RzIHRvIHRoZSBzYW1lIFVSTD8NCg0KPiBh
bmQNCj4gZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucywgc2VjdGlv
bnMgMS4zICYgNS4zLg0KDQpJIGRpZG4ndCBmaW5kIHRoZSBhbnN3ZXJzIHRvIHRoZSBxdWVzdGlv
bnMgYWJvdmUgaW4gdGhlc2Ugc2VjdGlvbnMuDQoNCg0KL21hcnRpbg0KDQoNCj4gDQo+IEVyaWMN
Cj4gDQo+ID4gTm90ZSB0aGF0IHRoZSBhcHByb2FjaCBpbiBSRkMgODA0MCBpcyBkb2Vzbid0IGhh
dmUgdGhpcyBpc3N1ZS4NCj4gPiANCj4gPiANCj4gPiAvbWFydGluDQo+ID4gDQo+ID4gDQo+ID4g
PiBUaGlzIGNvdWxkIGJlIGRvbmUgb2YgY291cnNlLCBidXQgc29tZW9uZSB3b3VsZCBuZWVkIHRv
IGRyaXZlIHRoZQ0KPiA+ID4gZGVmaW5pdGlvbi4NCj4gPiA+DQo+ID4gPiBFcmljDQo+ID4gPg0K
PiA+ID4NCj4gPiA+IFdvdWxkIGl0IGJlIHdyb25nIGZvciBhIGNsaWVudCB0byBtYWtlIGFueSBh
c3N1bXB0aW9ucz8gIEkgcmVhbGl6ZQ0KPiA+ID4gdGhpcyBBU1NVTUVzIGEgdHJhbnNwb3J0IHBy
b3RvY29sLCBidXQgY291bGQvd291bGQgdGhlcmUgYmUgYQ0KPiA+ID4gb25lLXRpbWUsIGNhcGFi
aWxpdHkgY2hlY2sgdGhlIGNsaWVudCBjb3VsZCBtYWtlIHRvIHRlc3QgZm9yIGF2YWlsYWJsZQ0K
PiA+ID4gdHJhbnNwb3J0cz8NCj4gPiA+DQo+ID4gPiBJIHJlYWxseSBhcHByZWNpYXRlIHlvdXIg
dGltZSBleHBsYWluaW5nLCBJIGhhdmUgYmVlbiBmb2xsb3dpbmcgdGhlDQo+ID4gPiBlbWFpbHMg
YmVzdCBJIGNvdWxkIGJ1dCBJIHRoaW5rIHNvbWUgYmFzaWMgdGhpbmdzIGFyZSBzdGlsbCBlbHVk
aW5nDQo+ID4gPiBtZS4NCj4gPiA+DQo=


From nobody Thu Sep 20 00:45:25 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B24130DD1 for ; Thu, 20 Sep 2018 00:45:23 -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 4TEr972A7bJN for ; Thu, 20 Sep 2018 00:45:21 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AA9EC130DE1 for ; Thu, 20 Sep 2018 00:45:21 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id E28971AE02C9; Thu, 20 Sep 2018 09:45:20 +0200 (CEST)
Date: Thu, 20 Sep 2018 09:45:20 +0200 (CEST)
Message-Id: <20180920.094520.798604819426315275.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: alexander.clemm@huawei.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net>
References: <20180829.150740.1323981906990283714.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5B91A@sjceml521-mbs.china.huawei.com> <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2018 07:45:24 -0000

Hi,

Thanks Kent, I missed this one.

Authors, I suggest we change the type for "yp:period" from
"yang:timeticks" to "uint32" with units "seconds".

See the thread starting at
https://mailarchive.ietf.org/arch/msg/netconf/SU1VnBV1Ea5Ae3QzPn_joyyRnZo


/martin


Kent Watsen  wrote:
> Hi Martin,
> 
> I'm surprised to see that your review doesn't suggest changing
> "yp:period" from yang:timeticks to seconds.
> 
> You had previously made this suggestion in another thread, but it's
> still timeticks in -18.
> 
> Kent // all hat
> 
> 
> 
> 
> 


From nobody Thu Sep 20 05:14:17 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46CA130F06 for ; Thu, 20 Sep 2018 05:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 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_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hubler-us.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 641HaSThdBIq for ; Thu, 20 Sep 2018 05:14:12 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 BD585130EC5 for ; Thu, 20 Sep 2018 05:14:12 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id n18-v6so7178685ioa.9 for ; Thu, 20 Sep 2018 05:14:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hubler-us.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=E4xjaApIg13QHLhQBciE6fkyXEW1rNWqAYlBsHotjw4=; b=nCClLm653jBPn/RY5MQ9my+gchtLjzeQC5rOnQjlhBDIHY5mKzhDgOhMlkDhwDfbMM 0Ac2M8tmbVs0lg46wB25Pl+GFdcfDmkM6f4fVLXjE2IxPsa1JmPae2m7XrLyORzxJ5PQ Tq0bQgVblpQ6JCRlxkK/UMScN94rjbPUkBMZm/a0PIka+0GxjxrWoJlX0r4sF1ZPi85m BoZsmlVITqW6LmoTzLz4o9Gkj1XCqCsWTX1xYjIKh9Iz5SICukHP3WbXDcr/trdJJwMU P2PbG9zBZcyhrAeRvw/8DMpOdvzjJXLmgnNzHzzoLO70NL2Xz8IAuK3idt3Zl4n6VhpO fhoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=E4xjaApIg13QHLhQBciE6fkyXEW1rNWqAYlBsHotjw4=; b=NU2jXV/0qGMYU/30z7yWC2GYL1YcMR9X1av1zlAxl+vZR+EOwhqA9y6XxaV+a7QZ0X kTcJM5uLdxdq+S5NmCSHkZj6aGAzaBAK2nKVM5NV+dyeBBSQpSPKdfH07u28Dvb3buKY xUuVtMGYiTc+2naiWx4tPZIl+F3gFdy0Sdr2I2h/bH7x8tRrwLJr2v3UStwsNzgKXwjY Ai2ahnZRyv3IENX0amra/LvDMpsJekkmy5dx4FL0J/uuOKi61mLTjrEpyPuYNxRy9cEf Lqz82A4px2TNqlh8g0vsPCSRCUesHvyfaztvG7FV3UPu/vrcwP8t6q/Rv+BaKVUyFwxG FySw==
X-Gm-Message-State: APzg51BPpwakXPokRE42LuWcLhzh3hpuOE/W1JglxqFJb4AZe4ubZjTK 8GlcyG2mFMZvAL9IdeTEItIe3T6ovr4=
X-Google-Smtp-Source: ANB0VdYMFA5iUBruN61sLsbdOabsZWQ8tv3xIwv4FHLnPTdArSp+nyIaM1aS/37ZDKyYGEdOmgQD1Q==
X-Received: by 2002:a6b:c744:: with SMTP id x65-v6mr32858345iof.208.1537445651732;  Thu, 20 Sep 2018 05:14:11 -0700 (PDT)
Received: from mail-it0-f53.google.com (mail-it0-f53.google.com. [209.85.214.53]) by smtp.gmail.com with ESMTPSA id y21-v6sm8230412ioa.54.2018.09.20.05.14.10 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Sep 2018 05:14:11 -0700 (PDT)
Received: by mail-it0-f53.google.com with SMTP id p79-v6so12791735itp.3 for ; Thu, 20 Sep 2018 05:14:10 -0700 (PDT)
X-Received: by 2002:a24:2e58:: with SMTP id i85-v6mr1758451ita.32.1537445650508;  Thu, 20 Sep 2018 05:14:10 -0700 (PDT)
MIME-Version: 1.0
From: Douglas Hubler 
Date: Thu, 20 Sep 2018 08:13:59 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Netconf 
Content-Type: multipart/alternative; boundary="000000000000dc2fd605764c750b"
Archived-At: 
Subject: [Netconf] Suggestions for interop testing
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2018 12:14:16 -0000

--000000000000dc2fd605764c750b
Content-Type: text/plain; charset="UTF-8"

I have a RESTCONF client/server library for the Go programming language
I've developed over the last 3 years.  I recognize the need to test
adherence to the standards as the library matures.  Does anyone have
suggestions for how I can ensure someone using my library can build a
service that can work with various vendor's management systems?  I'm
looking for suggestions that are approachable for individuals w/o a company
sponsorship (i.e. free with a low barrier of entry).

--000000000000dc2fd605764c750b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I have a RESTCONF client/server library for the Go pr=
ogramming language I've developed over the last 3 years.=C2=A0 I recogn=
ize the need to test adherence to the standards as the library matures.=C2=
=A0 Does anyone have suggestions for how I can ensure=C2=A0someone using my=
 library can build a service that can work with various vendor's manage=
ment systems?=C2=A0 I'm looking for suggestions that are approachable f=
or individuals w/o a company sponsorship (i.e. free with a low barrier of e=
ntry).=C2=A0



--000000000000dc2fd605764c750b--


From nobody Thu Sep 20 11:51:56 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2559130E3D for ; Thu, 20 Sep 2018 11:51: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 hZXwiwWbIS62 for ; Thu, 20 Sep 2018 11:51:52 -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 C2348130E12 for ; Thu, 20 Sep 2018 11:51:52 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E5796618EB895 for ; Thu, 20 Sep 2018 19:51:47 +0100 (IST)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 20 Sep 2018 19:51:48 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.47]) by SJCEML703-CHM.china.huawei.com ([169.254.5.77]) with mapi id 14.03.0415.000; Thu, 20 Sep 2018 11:51:43 -0700
From: Alexander Clemm 
To: Martin Bjorklund , "kwatsen@juniper.net" 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImzU9I4weZMB0iH1L0LVTTudKTT9lwAgAFivoCAAJuIoIABSioAgABMJJCAIVwXgIAAkQAAgABDGrA=
Date: Thu, 20 Sep 2018 18:51:42 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com>
References: <20180829.150740.1323981906990283714.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5B91A@sjceml521-mbs.china.huawei.com> <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com>
In-Reply-To: <20180920.094520.798604819426315275.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.35.96]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2018 18:51:55 -0000

I am about to post -19 but I do not like the suggested change to go from ti=
meticks to seconds.

Seconds is a fairly coarse unit.  I would not be surprised to see requireme=
nts for finer granularity in the future, even more so in virtualization and=
 controller scenarios in which we start to see YANG being used.  There are =
applications that use single second periods today so I think it is entirely=
 conceivable to see need for subsecond support down the line.  To allow per=
iods only in units of seconds would seem to unnecessarily hobble ourselves.=
  Keeping things to timeticks is more futureproof IMHO. =20

--- Alex

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Thursday, September 20, 2018 12:45 AM
> To: kwatsen@juniper.net
> Cc: Alexander Clemm ; netconf@ietf.org
> Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
>=20
> Hi,
>=20
> Thanks Kent, I missed this one.
>=20
> Authors, I suggest we change the type for "yp:period" from "yang:timetick=
s" to
> "uint32" with units "seconds".
>=20
> See the thread starting at
> https://mailarchive.ietf.org/arch/msg/netconf/SU1VnBV1Ea5Ae3QzPn_joyyRnZ
> o
>=20
>=20
> /martin
>=20
>=20
> Kent Watsen  wrote:
> > Hi Martin,
> >
> > I'm surprised to see that your review doesn't suggest changing
> > "yp:period" from yang:timeticks to seconds.
> >
> > You had previously made this suggestion in another thread, but it's
> > still timeticks in -18.
> >
> > Kent // all hat
> >
> >
> >
> >
> >


From nobody Thu Sep 20 13:06:20 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D70130DC1 for ; Thu, 20 Sep 2018 13:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_DKIMWL_WL_MED=-0.01, 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 9eoIglg-IndJ for ; Thu, 20 Sep 2018 13:06:16 -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 A5B22129C6A for ; Thu, 20 Sep 2018 13:06:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19772; q=dns/txt; s=iport; t=1537473976; x=1538683576; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=x8PoQLnzAlwQuKZfZLOJ2W73YY6r1A/BedU+QoMKko0=; b=aWvc3c1V5/gpXxVM+VC8ZefKUrG8mJqFKRNvgN68C5RuIKH+7hYEI2T9 Vxu9Fnddh0mzH2DFrFhD7aSjN+ZU96w64vKmtKTVK2f32TBjDFEkwQEfa vFjbuQbieEbWjFDBM25ri9nuy+FTKEoqvSDsgmtrDhiHWf8WXE+Uw1H2S Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQAY/aNb/4MNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYFSgVwqZX8oCoNplESCDYM9kxEUgWYLGAuESQIXgyshNhY?= =?us-ascii?q?BAwEBAgEBAm0cDIU4AQEBAQIBIwQNQwIFCwIBCA4HAwICCRYEAwICAjAUARA?= =?us-ascii?q?CBA4BBAgBEgSCN0yBeQgPo3h7M4oLgQuJZBeBQT+BEoMShGYCHTOCR4JXAog?= =?us-ascii?q?0Eop/iFpPCQKJR4ZTH4FEh1WBCoR/lE4CERSBJSQLJieBLnAVgycJghwXEYh?= =?us-ascii?q?JhT0BbwEOixcHgSeBHgEB?=
X-IronPort-AV: E=Sophos;i="5.54,281,1534809600"; d="scan'208";a="174437561"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2018 20:06:15 +0000
Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w8KK6EeX024822 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Sep 2018 20:06:15 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 20 Sep 2018 16:06:14 -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.1395.000; Thu, 20 Sep 2018 16:06:14 -0400
From: "Eric Voit (evoit)" 
To: Martin Bjorklund 
CC: "douglas@hubler.us" , "andy@yumaworks.com" , "j.schoenwaelder@jacobs-university.de" , "netconf@ietf.org" , "Reshad Rahman (rrahman)" 
Thread-Topic: SSE and HTTP/2 in restcon-notif [Was: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16]
Thread-Index: AQHUULJj8u4iugmb4USqCBI3N2tZz6T5JtJw
Date: Thu, 20 Sep 2018 20:06:14 +0000
Message-ID: <494e1d8a26594e198e5241b8b5c4070b@XCH-RTP-013.cisco.com>
References: <48e4aac958d142669f4032737cdc4373@XCH-RTP-013.cisco.com> <20180919.083805.1103902318002046181.mbj@tail-f.com> <1f83e10a61fc4a89bf5e1264566a3e29@XCH-RTP-013.cisco.com> <20180920.092011.809234550582033045.mbj@tail-f.com>
In-Reply-To: <20180920.092011.809234550582033045.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.234]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.143, xch-rtp-003.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: 
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif [Was: activate-configured-subecription - WGLC subscribed-notifications-16]
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2018 20:06:19 -0000

SGksDQoNCj4gRnJvbTogTWFydGluIEJqb3JrbHVuZCwgU2VwdGVtYmVyIDIwLCAyMDE4IDM6MjAg
QU0NCj4gDQo+IEhpLA0KPiANCj4gW3N1YmplY3QgY2hhbmdlOyB0aGlzIHRocmVhZCBpcyBub3cg
YWJvdXQgU1NFIGFuZCBIVFRQLzJdDQo+IA0KPiAiRXJpYyBWb2l0IChldm9pdCkiIDxldm9pdEBj
aXNjby5jb20+IHdyb3RlOg0KPiA+ID4gRnJvbTogTWFydGluIEJqb3JrbHVuZCwgU2VwdGVtYmVy
IDE5LCAyMDE4IDI6MzggQU0NCj4gPiA+DQo+ID4gPiBIaSwNCj4gPiA+DQo+ID4gPiAiRXJpYyBW
b2l0IChldm9pdCkiIDxldm9pdEBjaXNjby5jb20+IHdyb3RlOg0KPiA+ID4gPiBIaSBEb3VnbGFz
LA0KPiA+ID4gPg0KPiA+ID4gPiBGcm9tOiBEb3VnbGFzIEh1YmxlciwgU2VwdGVtYmVyIDE4LCAy
MDE4IDU6MzUgUE0NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gT24gVHVlLCBTZXAgMTgsIDIw
MTggYXQgMzo0MCBQTSBNYXJ0aW4gQmpvcmtsdW5kDQo+ID4gPiA+IDxtYmpAdGFpbC1mLmNvbTxt
YWlsdG86bWJqQHRhaWwtZi5jb20+PiB3cm90ZToNCj4gPiA+ID4gU28gaXQgc2VlbXMgeW91IHN1
cHBvcnQgbXkgcG9pbnQgdG8gbWFrZSB0aGlzIGRyYWZ0IHVzZSBTU0UuICBUaGVuDQo+ID4gPiA+
IGlmIHlvdSB1c2UgSFRUUC8yIHlvdSAodGhlIGNsaWVudCkgY2FuIHNpbXBseSBjcmVhdGUgb25l
IEhUVFAvMg0KPiA+ID4gPiBzdHJlYW0gcGVyIG5vdGlmaWNhdGlvbiBzdHJlYW0uICBUaGlzIGp1
c3QgZmFsbHMgb3V0IGZvciBmcmVlIHdpdGggSFRUUC8yLg0KPiA+ID4gPg0KPiA+ID4gPiB5ZXMs
IHdpdGggY2F2ZWF0IHRoYXQgSSBoYXZlbid0IGF0dGVtcHRlZCBhY3R1YWwgaW1wbGVtZW50YXRp
b24geWV0Lg0KPiA+ID4gPg0KPiA+ID4gPiA8RXJpYz4gQWdyZWUgdGhhdCBTU0Ugb3ZlciBIVFRQ
MiBzaG91bGQgd29yay4gIEhvd2V2ZXIgdG8gbWUgdXNpbmcNCj4gPiA+ID4gU1NFIGhlcmUgc2Vl
bXMgcmVkdW5kYW50IGFzIEhUVFAyIHByb3ZpZGVzIHRoZSBuZWNlc3NhcnkgbWVjaGFuaXNtcy4N
Cj4gPiA+DQo+ID4gPiBFcmljLCBjYW4geW91IGV4cGxhaW4gaG93IHRoaXMgd291bGQgd29yayB3
L28gU1NFPyAgV2hpY2ggbWVjaGFuaXNtDQo+ID4gPiBpbg0KPiA+ID4gSFRUUC8yIGFyZSB5b3Ug
cmVmZXJyaW5nIHRvPw0KPiA+DQo+ID4gQWZ0ZXIgYW4gSFRUUDIgT0ssIHRoZSBIVFRQMiBzZXJ2
ZXIgaGFzIHRoZSBhYmlsaXR5IHRvIGZvcndhcmQgYW4NCj4gPiB1bmJvdW5kZWQgbnVtYmVyIG9m
IEhUVFAyIERhdGEgRnJhbWVzIG9uIHRoZSBIVFRQMiBzdHJlYW0uDQo+IA0KPiBCdXQgaXQgbXVz
dCBzdGlsbCBhZGhlcmUgdG8gdGhlIG5vcm1hbCBIVFRQIHNlbWFudGljcy4gIElmIHRoZXJlIHdh
cyBhIHJlcXVlc3QsIGl0DQo+IG5lZWRzIHRvIHNlbmQgdGhlIHJlc3BvbnNlLiAgSXQgY2FuIHNw
bGl0IHRoZSByZXNwb25zZSBpbnRvIHNldmVyYWwgREFUQSBmcmFtZXMNCj4gb2YgY291cnNlLiAg
QnV0IGl0IGNhbm5vdCBzdGFydCB0byBzZW5kICJvdGhlciBzdHVmZiIgaW5zdGVhZCBvZiB0aGUg
cmVzcG9uc2UsDQo+IHdoaWNoIGZpZ3VyZSAxIGluDQo+IHJlc3Rjb25mLW5vdGlmLTA3IHBvc3Np
Ymx5IGltcGxpZXMuDQoNCkFncmVlLiAgIE5vdCBzdXJlIHdoZXJlIHlvdSBzZWUgdGhhdCBpbiBG
aWd1cmUgMS4gICBUaGUgSFRUUDIgT0sgZG9lc24ndCBtZWFuIHRoZSBlbmQgb2YgdGhlIHJlc3Bv
bnNlLiAoUkZDLTc5NTAsIHBhZ2UgNTcuKSAgICAgIEFueSBzdWdnZXN0aW9ucyBvbiBob3cgdG8g
bWFrZSB0aGlzIGNsZWFyZXI/DQogDQo+ID4gVGhlIHN0cmVhbQ0KPiA+IGlzIG5vdCBjb25zaWRl
cmVkIGNvbXBsZXRlIHVudGlsIGFuIEVORF9TVFJFQU0gaXMgcGFzc2VkLiAgKE5vdGUgdGhpcw0K
PiA+IGlzIGluZGVwZW5kZW50IG9mIGFueXRoaW5nIHJlZ2FyZGluZyBIVFRQMidzIFBVU0hfUFJP
TUlTRS4pDQo+ID4NCj4gPiBZb3UgY2FuIHNlZSBhbiBleGFtcGxlIGZsb3cgaW4gRmlndXJlIDEg
b2YNCj4gPiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYuICBBdCBJRVRGIDk3IHdl
IGFza2VkIGZvciBzb21lDQo+ID4gRmVlZGJhY2sgb24gdGhpcyBwcm9wb3NhbC4NCj4gPiBodHRw
Oi8vd3d3LnZvaXQub3JnL0lFVEYvU3Vic2NyaXB0aW9ucy1ORVRDT05GLUlFVEY5Ny5wcHQgKHNl
ZSBzbGlkZQ0KPiA+IDE0KS4NCj4gPiBCdXQgSSBhbSBub3Qgc3VyZSBob3cgbXVjaCBlZmZvcnQg
dGhlIFdHIHNob3VsZCBwbGFjZSBoZXJlLiAgVGhlIHdvcmsNCj4gPiBoZXJlIGlzIHNldmVyYWwg
eWVhcnMgb2xkLCBhbmQgdGhlIG1hcmtldCBoYXMgbW92ZWQgc3Vic3RhbnRpYWxseQ0KPiA+IHNp
bmNlIHRoZW4uDQo+IA0KPiBTbyBkbyB3ZSBhZ3JlZSB0aGF0IHRoZSByZXN0Y29uZi1ub3RpZiBk
cmFmdCB3aWxsIGJlIHVwZGF0ZWQgdG8gdXNlIFNTRQ0KPiByZWdhcmRsZXNzIG9mIEhUVFAgdmVy
c2lvbj8gIElmIHRoZXJlIGlzIGFueSB0ZXh0IGF0IGFsbCBhYm91dCBIVFRQLzIsIGl0IHdpbGwg
YmUgYW4NCj4gImltcGxlbWVudGF0aW9uIG5vdGUiIHdoZXJlIGl0IGlzIHJlY29tbWVuZGVkIHRv
IHVzZSBhIHNlcGFyYXRlIHN0cmVhbSBwZXINCj4gc3Vic2NyaXB0aW9uPw0KDQpJIHdpbGwgbGVh
dmUgdGhhdCB1cCB0byBSZXNoYWQgdG8gZnJhbWUuICBJIHdvbid0IGZpZ2h0IGFnYWluc3QgaXQs
IGFsdGhvdWdoIHRoZXJlIGlzIGludGVycGxheSBoZXJlIHdpdGggc3Vic2NyaXB0aW9uIGJ1bmRs
aW5nIChwZXIgYmVsb3cpLg0KIA0KPiA+ID4gPiBCdXQNCj4gPiA+ID4gSSB3b27igJl0IGdldCBp
biB0aGUgd2F5IGlmIHBlb3BsZSByZWFsbHkgZG8gd2FudCB0byBnbyBpbiB0aGlzDQo+ID4gPiA+
IGRpcmVjdGlvbi4NCj4gPiA+ID4NCj4gPiA+ID4gPiBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIGRl
dGFpbHMgc3Vycm91bmRpbmcgdXNpbmcgYW4gUlBDIHRvIG1ha2UNCj4gPiA+ID4gPiBhIGR5bmFt
aWMgc3Vic2NyaXB0aW9uLiAgVW5sZXNzIGl0J3Mgb3B0aW9uYWwsIHRoZW4gSSBjYW4gc3RhcnQN
Cj4gPiA+ID4gPiB0byB1bmRlcnN0YW5kLg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgY2xpZW50IHdv
dWxkIFBPU1QgdG8gdGhlICJycGMiIGVzdGFibGlzaC1zdWJzY3JpcGlvbiwgYW5kIGluDQo+ID4g
PiA+IHRoZSByZXBseSB0byB0aGUgUE9TVCBpcyBhICJsb2NhdGlvbiIgbGVhZiAoKikgdGhhdCBj
b250YWlucyBhDQo+ID4gPiA+IFVSSS4gIFRoZSBjbGllbnQgdGhlbiBHRVQgdGhpcyBVUkk7IHRo
aXMgaXMgdGhlIFNTRSBldmVudCBzdHJlYW0uDQo+ID4gPiA+DQo+ID4gPiA+IEkgc2VlLiAgQnV0
IGlmIGEgY2xpZW50IHJlYWRzIHRoZSBZQU5HIGFzDQo+ID4gPiA+DQo+ID4gPiA+ICBtb2R1bGUg
bXktbW9kdWxlIHsNCj4gPiA+ID4gICAgIC4uLg0KPiA+ID4gPiAgICAgbm90aWZpY2F0aW9uIG15
LWV2ZW50IHsNCj4gPiA+ID4gICAgIH0NCj4gPiA+ID4gfQ0KPiA+ID4gPg0KPiA+ID4gPiBhbmQg
Y2xpZW50IGtuZXcgYmFzZSBzdHJlYW0gVVJJIHdhczoNCj4gPiA+ID4NCj4gPiA+ID4gICAgL3Jl
c3Rjb25mL215LXN0cmVhbXMNCj4gPiA+ID4NCj4gPiA+ID4gQ291bGRuJ3QgdGhlIGNsaWVudCB0
aGVuIGRlZHVjZSBTU0UgVVJMIGFzOg0KPiA+ID4gPg0KPiA+ID4gPiAgR0VUICAvcmVzdGNvbmYv
bXktc3RyZWFtcy9teS1tb2R1bGU6bXktZXZlbnQ/Li4uDQo+ID4gPg0KPiA+ID4gTm8uDQo+ID4g
Pg0KPiA+ID4gV2l0aCBSRkMgODA0MCwgdGhlIFNTRSBVUkwgaXMgInN0YWJsZSIsIGFuZCBpZiB0
aGUgY2xpZW50IGhhcyByZWFkDQo+ID4gPiBpdCBvbnZlLCBpdCBkb2Vzbid0IGhhdmUgdG8gcmVh
ZCBpdCBhZ2FpbiAobW9kdWxvIHNvbWUgZGVmaW5pdGlvbiBvZg0KPiA+ID4gInN0YWJsZSIpLg0K
PiA+ID4gVGhlIGNsaWVudA0KPiA+ID4gY2FuIHBhc3MgYSBmaWx0ZXIgaW4gdGhlIEdFVCByZXF1
ZXN0IGZvciB0aGUgU1NFIHN0cmVhbS4NCj4gPiA+DQo+ID4gPiBXaXRoIHRoZSBtZWNoYW5pc20g
aW4gdGhpcyBkcmFmdCwgdGhlIFNTRSBVUkwgd2lsbCB2YXJ5IGZvciBlYWNoDQo+ID4gPiByZXF1
ZXN0IHRoYXQgaGFzIGEgZGlmZmVyZW50IGZpbHRlciAoYXQgYSBtaW5pbXVtKSwgc2luY2UgdGhl
IGZpbHRlcg0KPiA+ID4gaXMgcGFzc2VkIGEgcGFyYW1ldGVyIHRvICJlc3RhYmxpc2gtc3Vic2Ny
aXB0aW9uIiBhbmQgdGhlIFNTRSBVUkwgaXMNCj4gPiA+IHNlbnQgYmFjayBpbiB0aGUgcmVwbHkg
dG8NCj4gPiA+ICJlc3RhYmxpc2gtDQo+ID4gPiBzdWJzY3JpcHRpb24iLiAgV2l0aCB0aGUgU1NF
IFVSTCwgdGhlIHNlcnZlciBtYXkgaGlkZSBzb21lIHN0YXRlDQo+ID4gPiB0aGF0IGNvcnJlc3Bv
bmRzIHRvIHRoZSBmaWx0ZXIgcGFyYW1zIGV0Yy4gIChOT1RFIHRoZSB3b3JkICptYXkqIGluDQo+
ID4gPiB0aGUgcHJldmlvdXMgc2VudGVuY2UuICBBIHNlcnZlciBjb3VsZCBhcyB3ZWxsIHNlbmQg
YmFjayBhIFNTRSBVUkwNCj4gPiA+IHdpdGggdGhlIGZpbHRlciBwYXJhbWV0ZXJzIGVtYmVkZGVk
IGluIHRoZQ0KPiA+ID4gVVJMLi4uKQ0KPiA+ID4NCj4gPiA+IFNvIGluIGdlbmVyYWwsIGEgY2xp
ZW50IGNhbm5vdCBhc3N1bWUgdGhhdCBpdCBjYW4gcmUtdXNlIGEgU1NFIFVSTA0KPiA+ID4gdGhh
dCB3YXMgcmV0dXJuZWQgZnJvbSBhIGNhbGwgdG8gImVzdGFibGlzaC1zdWJzY3JpcHRpb24iLg0K
PiA+ID4NCj4gPiA+ID4gVGhlcmVieSBzYXZpbmcgYSB0cmlwIHRvIHNlcnZlcj8NCj4gPiA+ID4N
Cj4gPiA+ID4gPEVyaWM+IFllcywgaXQgd291bGQgYmUgcG9zc2libGUgdG8gc2V0IHNvbWV0aGlu
ZyB1cCB0byBkZWR1Y2UgdGhlDQo+ID4gPiA+IFVSTC4gIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0
Y29uZi1ub3RpZiBkb2VzbuKAmXQgY3VycmVudGx5IGF0dGVtcHQNCj4gPiA+ID4gdGhpcyBhcyBi
ZWluZyBhYmxlIHRvIGRlZHVjZSB0aGUgVVJMIGRvZXNu4oCZdCBzdG9wIHRoZSBleHRyYSB0cmlw
DQo+ID4gPiA+IHRvIHRoZSBzZXJ2ZXIuDQo+ID4gPiA+DQo+ID4gPiA+IFRoZSByZWFzb24gaXQg
ZG9lc27igJl0IGdldCByaWQgb2YgdGhlIGV4dHJhIHJvdW5kIHRyaXAgaGFzIHRvIGRvDQo+ID4g
PiA+IHdpdGgNCj4gPiA+ID4gSFRUUDIgc3RyZWFtcy4gIElmIHdlIGFyZSBnb2luZyB0byB1c2Ug
SFRUUDIsIHRoZXJlIGlzIHN0aWxsIGENCj4gPiA+ID4gbmVlZCB0byBpbml0aWF0ZSB0aGUgR0VU
IChvciBQT1NUKSBpbiBhIHNlcGFyYXRlIHN0cmVhbSBvdGhlciB0aGFuDQo+ID4gPiA+IHRoZSBv
bmUgYmVpbmcgdXNlZCBmb3IgUkVTVENPTkYgc2lnbmFsaW5nLg0KPiA+ID4NCj4gPiA+IEkgZGlz
YWdyZWUuICBJZiB0aGUgY2xpZW50IHdhbnRzIHRvIGhhdmUgYSBzZXBhcmF0ZSBIVFRQLzIgc3Ry
ZWFtDQo+ID4gPiBmb3IgdGhlIG5vdGlmcywgdGhlbiBpdCBzaG91bGQgc3RhcnQgc3VjaCBhIHN0
cmVhbS4gIElmIHRoZSBjbGllbnQNCj4gPiA+IGRvZXNuJ3Qgd2FudCBhIHNlcGFyYXRlIEhUVFAv
MiBzdHJlYW0gdGhlbiB0aGF0IHNob3VsZCBiZSBvayB0b28uDQo+ID4NCj4gPiBQZXIgeW91ciBi
ZWxvdywgb25jZSBTU0UgaXMgYXBwbGllZCBhIHN0cmVhbSBpcyBibG9ja2VkLiAgRm9yIHRoYXQN
Cj4gPiBzdWJzY3JpcHRpb24sIHlvdSBzdGlsbCBuZWVkIHRvIHN1cHBvcnQgJ21vZGlmeS1zdWJz
Y3JpcHRpb24nIGFuZA0KPiA+ICdkZWxldGUtc3Vic2NyaXB0aW9uJyBycGNzLg0KPiANCj4gQnV0
IHRoZSBzb2x1dGlvbiBjYW5ub3QgZGVwZW5kIG9uIHRoZSBzdWJzY3JpYmVyIGJlaW5nIGFibGUg
dG8gc2VuZCAiZGVsZXRlLQ0KPiBzdWJzY3JpcHRpb24iIG9uIHRoZSBzYW1lIHRyYW5zcG9ydCBz
ZXNzaW9uIChCVFcsIHRoaXMgcmVxdWlyZW1lbnQgc2hvdWxkIGJlDQo+IGNsYXJpZmllZCBpbiB0
aGUgWUFORyBkZWZpbml0aW9uIGZvciAiZGVsZXRlLXN1YnNjcmlwdGlvbiIgaW4gU04pLCBzaW5j
ZSB0aGlzDQo+IHdvdWxkIHJ1bGUgb3V0IEhUVFAvMS4xLg0KDQpUd2Vha2VkIGl0IHRvICJ1c2lu
ZyBhIHRyYW5zcG9ydCBzZXNzaW9uIGNvbm5lY3RpbmcgdG8gdGhlIHN1YnNjcmliZXIuIg0KDQo+
ICJtb2RpZnktc3Vic2NyaXB0aW9uIiBjYW4gYmUgc2VudCBvbiBhbm90aGVyIHNlc3Npb24sIGUu
Zy4sIGFub3RoZXINCj4gSFRUUC8xLjEgc2Vzc2lvbiB0aGF0IGlzIG5vdCBkb2luZyB0aGUgU1NF
cy4NCj4gDQo+IFRoaXMgbWFrZXMgbWUgd29uZGVyLi4uIGlzICJkZWxldGUtc3Vic2NyaXB0aW9u
IiByZWFsbHkgbmVjZXNzYXJ5LCBvciBpcyAia2lsbC0NCj4gc3Vic2NyaXB0aW9uIiBzdWZmaWNp
ZW50Pw0KPg0KPiA+IEJleW9uZCB0aGF0LCBvbmUgdGhpbmcgdG8ga2VlcCBhbiBleWUgb24gaXMg
dGhlIHBvdGVudGlhbCBmb3IgYnVuZGxpbmcNCj4gPiBvZiBldmVudCByZWNvcmRzIGZyb20gZGlm
ZmVyZW50IHN1YnNjcmlwdGlvbnMgaW50byBhIHNpbmdsZQ0KPiA+IHRyYW5zbWl0dGFibGUgbm90
aWZpY2F0aW9uIG1lc3NhZ2UuDQo+IA0KPiBIb3cgd291bGQgYW4gSFRUUCBzdWJzY3JpYmVyIGV2
ZW4gcmVxdWVzdCB0aGlzPw0KDQpJdCB3b3VsZG4ndCBiZSBkZXRlcm1pbmVkIGJ5IHRoZSBzdWJz
Y3JpYmVyIGF0IGFsbC4gIEl0IHdvdWxkIGJlIHVwIHRvIHRoZSBwdWJsaXNoZXIgdG8gZGV0ZXJt
aW5lIHdoYXQgZ2V0cyBidW5kbGVkIG9yIG5vdC4gICBJZiBzb21lb25lIHdhbnRzIHRvIGNyZWF0
ZSBzaWduYWxpbmcgdG8gbWFuaXB1bGF0ZSB3aGF0IGNvdWxkIGJlIGJ1bmRsZWQsIGl0IHdvdWxk
IHJlcXVpcmUgYXVnbWVudGF0aW9ucyB0byBTTidzIGVzdGFibGlzaC1zdWJzY3JpcHRpb24gUlBD
IHBhcmFtZXRlcnMuDQoNCj4gVGhlIHN1YnNjcmliZXIgc2VuZHMgYW4gZXN0YWJsaXNoLXN1YnNj
cmlwdGlvbiBhbmQgZ2V0IGFuIFVSTCBmb3IgdGhhdA0KPiBzdWJzY3JpcHRpb24gYmFjay4NCj4g
DQo+IFRoZW4gaXQgc2VuZHMgYW5vdGhlciBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIGFuZCBnZXRz
IGFub3RoZXIgVVJMIGJhY2suDQo+IA0KPiBIb3cgY2FuIGEgYnVuZGxlZCBtZXNzYWdlIGJlIHNl
bnQgd2hlbiB0aGVyZSBhcmUgdHdvIGRpZmZlcmVudCBzdWJzY3JpcHRpb24NCj4gcmVzb3VyY2Vz
Pw0KDQpJZiBidW5kbGluZyBpcyBzdXBwb3J0ZWQsIHlvdSBpbml0aWFsbHkgc2VuZCBhIFVSTCB0
byBhIHNoYXJlZCBidW5kbGluZyByZXNvdXJjZS4gIFN0cmVhbXMgY2FuIGJlIGFkZGVkIGFuZCBy
ZW1vdmVkIGZyb20gdGhhdCByZXNvdXJjZS4gICBUaGVzZSBwb3NzaWJpbGl0aWVzIGFyZSB0aGUg
a2luZHMgb2YgcmVhc29ucyB3aHkgYSBVUkkgaXMgc2VudCBiYWNrIGFzIHBhcnQgb2YgdGhlIGVz
dGFibGlzaC1zdWJzY3JpcHRpb24gcmVzcG9uc2UgKHJhdGhlciB0aGFuIGl0IGJlaW5nIHdlbGwt
a25vd24pLiAgRnVydGhlciBjbGFyaWZpY2F0aW9ucyBpbiB0aGlzIHNwYWNlIHdpbGwgYmUgbmVl
ZGVkIGFzIHdlIGdldCBkZWVwZXIgaW50byBidW5kbGluZy4NCg0KPiA+IChTb21ldGhpbmcgbGlr
ZSBpbg0KPiA+IGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMuKSAgQW55
d2hlcmUgc3VjaCBidW5kbGluZw0KPiA+IG9jY3VycywgdGhlIHB1Ymxpc2hlciB3aWxsIGhhdmUg
dG8gdXNlIGEgY29uc2lzdGVudCBIVFRQMiBzdHJlYW0NCj4gPiBhY3Jvc3MgYSBzZXQgb2Ygc3Vi
c2NyaXB0aW9ucyBpbiBvcmRlciB0byBwcmVzZXJ2ZSBldmVudCByZWNvcmQNCj4gPiBvcmRlcmlu
Zy4gIEluIGFkZGl0aW9uLCBhbGwgZXZlbnQgcmVjb3JkcyBidW5kbGVkIHdpbGwgaGF2ZSB0bw0K
PiA+IGNvbnNpc3RlbnRseSB1c2UgdGhlIHNhbWUgRFNDUC4NCj4gPg0KPiA+IE5vdGU6IHRoaXMg
aXMgYW5vdGhlciByZWFzb24gd2h5IGl0IGlzIGEgZ29vZCBpZGVhIHRvIHVzZSBzZXBhcmF0ZQ0K
PiA+IEhUVFAyIHN0cmVhbXMgZm9yIFJFU1RDT05GIHN1YnNjcmlwdGlvbiBSUEMgaW50ZXJhY3Rp
b25zLCBhbmQgZm9yIHRoZQ0KPiA+IHN0cmVhbWluZyBvZiBldmVudCByZWNvcmRzLg0KPiA+DQo+
ID4gPiBDb21wYXJlIHRvIE5FVENPTkYuICBIVFRQLzIgc3RyZWFtcyBhcmUgc2ltaWxhciB0byBT
U0ggY2hhbm5lbHMuICBBDQo+ID4gPiBORVRDT05GIGNsaWVudCBjYW4gb3BlbiBhIHNlcGFyYXRl
IFNTSCBjaGFubmVsIGZvciBlYWNoDQo+ID4gPiBzdWJzY3JpcHRpb24sIG9yIGl0IGNhbiB1c2Ug
YSBzaW5nbGUgY2hhbm5lbC4gIFVwIHRvIHRoZSBjbGllbnQuDQo+ID4NCj4gPiBIVFRQMiBzdHJl
YW1zIGhhdmUgZmFyIGxlc3Mgb3ZlcmhlYWQsIGxvd2VyIHNldHVwIGxhdGVuY3ksIGFuZCBtb3Jl
DQo+ID4gc2NhbGFiaWxpdHkgdGhhbiBzZXBhcmF0ZSBTU0ggY2hhbm5lbHMuDQo+IA0KPiBSZWFs
bHk/ICBBbiBTU0ggY2hhbm5lbCBpcyBzdXBlciBjaGVhcC4gIFdoeSBkbyB5b3UgdGhpbmsgdGhh
dCBIVFRQLzIgc3RyZWFtcw0KPiBoYXZlICJmYXIgbGVzcyIgb3ZlcmhlYWQ/ICBUaGVyZSBjYW4g
YmUgMl4zMiBjaGFubmVscyBpbiBhbiBTU0ggc2Vzc2lvbiwgYW5kDQo+IDJeMzEgc3RyZWFtcyBp
biBhIEhUVFAvMiBzZXNzaW9uLg0KPiANCj4gKEZvciByZWZlcmVuY2UsIGluIGNhc2UgaXQgd2Fz
bid0IGNsZWFyOiBSRkMgNDI1NCwgc2VjdGlvbiA1KQ0KPg0KPiA+ID4gPiBTb21lb25lIGNvdWxk
IHdyaXRlIGEgc3BlY2lmaWNhdGlvbiB3aGljaCBnZXRzIGFyb3VuZCB0aGlzIGJ5DQo+ID4gPiA+
IGZvcmNpbmcgZXZlcnkgUkVTVENPTkYgdHJhbnNhY3Rpb24gb24gaXRzIG93biBIVFRQMiBzdHJl
YW0uICBCdXQNCj4gPiA+ID4gbm9ib2R5IGhhcyBwcm9wb3NlZCBzdWNoIGEgc3BlY2lmaWNhdGlv
bi4gIFBsdXMgdGhlcmUgYXJlIFFvUw0KPiA+ID4gPiBzY2VuYXJpb3Mgd2hlcmUgeW91IG1pZ2h0
IHdhbnQgbXVsdGlwbGUgc3Vic2NyaXB0aW9ucyBvbiB0aGUgc2FtZQ0KPiBIVFRQMiBzdHJlYW0u
DQo+ID4gPg0KPiA+ID4gSG93IHdvdWxkIHRoaXMgd29yaz8gIE9uY2UgeW91IHN0YXJ0IFNTRSBv
biBhIHN0cmVhbSwgdGhhdCBzdHJlYW0gaXMNCj4gPiA+ICJibG9ja2VkIiwgcmlnaHQ/DQo+ID4N
Cj4gPiBBbmQgcGVyIGFib3ZlLCB0aGlzIGlzIGEgZ29vZCByZWFzb24gdG8gc2VwYXJhdGUgUkVT
VENPTkYgc3Vic2NyaXB0aW9uDQo+ID4gUlBDcyBmcm9tIHRoZSBIVFRQMiBzdHJlYW0gdXNlZCBm
b3IgZXZlbnRzLiAgKFRoZSB3YXkgaXQgY291bGQgYmUgZG9uZQ0KPiA+IGlzIGhhdmUgbW9kaWZ5
LXN1YnNjcmlwdGlvbiBhbmQgZGVsZXRlLXN1YnNjcmlwdGlvbnMgY29tZSBpbiBvbiBhDQo+ID4g
ZGlmZmVyZW50IHN0cmVhbSwgaW1wYWN0aW5nIHRoZSBIVFRQMiBzdHJlYW0gd2hlcmUNCj4gPiBl
c3RhYmxpc2gtc3Vic2NyaXB0aW9uIHN0YXJ0ZWQgdGhpbmdzIG9mZi4gIEFnYWluIEkgYW0gbm90
DQo+ID4gcmVjb21tZW5kaW5nIHRoaXMgZm9yIG11bHRpcGxlIHJlYXNvbnMuKQ0KPiA+DQo+ID4g
PiA+IFNvIGlmDQo+ID4gPiA+IHNvbWVvbmUgd2FudGVkIHRoaXMsIHdlIHdvdWxkIHN0aWxsIG5l
ZWQgdG8gcmVmaW5lDQo+ID4gPiA+IGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiBy
ZXF1aXJlbWVudHMgd2l0aCB0aGUgYWJpbGl0eSB0bw0KPiA+ID4gPiBtb2RpZnkgb3IgZGVsZXRl
IGFuIGV4aXN0aW5nIHN1YnNjcmlwdGlvbiBvbiBhIGRpZmZlcmVudCBIVFRQMiBzdHJlYW0uDQo+
ID4gPg0KPiA+ID4gSXNuJ3QgdGhpcyBob3cgaXQgaXMgc3VwcG9zZWQgdG8gd29yaz8NCj4gPg0K
PiA+IFllcy4gIE15IHBvaW50IHdhcyB0aGF0IG5vYm9keSBoYXMgcHJvcG9zZWQgcmVmaW5pbmcg
dGhlIHNwZWMgdG8NCj4gPiBmb3JjaW5nIG9mIGVhY2ggUkVTVENPTkYgdHJhbnNhY3Rpb24gb24g
ZGlmZmVyZW50IEhUVFAyIHN0cmVhbXMuDQo+ID4NCj4gPiA+IFRoZSBkcmFmdCBpcyBzaWxlbnQg
b24gaG93IHRvIGRlbGV0ZSBhIHN1YnNjcmlwdGlvbiwgYW5kIGFsc28gb24gaG93DQo+ID4gPiBt
b2RpZnktc3Vic2NyaXB0aW9uIGlzIHN1cHBvc2VkIHRvIHdvcmsuDQo+ID4NCj4gPiBDZXJ0YWlu
bHkgdGhlc2UgY2FuIGNvbWUgaW4gb24gYSBkaWZmZXJlbnQgSFRUUDIgc3RyZWFtLg0KPiA+DQo+
ID4gPiBUaGUgZHJhZnQgaXMgYWxzbyBzaWxlbnQgb24gdGhlIGxpZmV0aW1lIG9mIHRoZSByZXN1
bHQgb2YNCj4gPiA+ICJlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIi4NCj4gPiA+IFdpdGggTkVUQ09O
RiwgdGhlIHN1YnNjcmlwdGlvbiBlbmRzIGlmIHRoZSBzZXNzaW9uIGVuZHMsIGJ1dCBpbg0KPiA+
ID4gUkVTVENPTkYgdGhlcmUgYXJlIG5vIHNlc3Npb25zLCBzbyBob3cgbG9uZyBkb2VzIHRoZSBz
dWJzY3JpcHRpb24NCj4gPiA+IGxpdmUgYWZ0ZXIgaXQgaGFzIGJlZW4gY3JlYXRlZD8NCj4gPg0K
PiA+IFRoZXJlIGFyZSBtZWNoYW5pc21zIGRlZmluZWQuICBTZWUNCj4gPiBkcmFmdC1pZXRmLW5l
dGNvbmYtcmVzdGNvbmYtbm90aWYsIFNlY3Rpb24gMy4xLg0KPiANCj4gVGhpcyBzZWN0aW9uIHNh
eXM6DQo+IA0KPiAgICBXaGVyZSBxdWljaw0KPiAgICByZWNvZ25pdGlvbiBvZiB0aGUgbG9zcyBv
ZiBhIHB1Ymxpc2hlciBpcyByZXF1aXJlZCwgYSBzdWJzY3JpYmVyDQo+ICAgIFNIT1VMRCBjb25u
ZWN0IG92ZXIgVExTIFtSRkM1MjQ2XSwgYW5kIHVzZSBhIFRMUyBoZWFydGJlYXQgW1JGQzY1MjBd
DQo+ICAgIHRvIHRyYWNrIEhUVFAgc2Vzc2lvbiBjb250aW51aXR5LiAgSW4gdGhlIGNhc2Ugd2hl
cmUgYSBUTFMgaGVhcnRiZWF0DQo+ICAgIGlzIGluY2x1ZGVkLCBpdCBzaG91bGQgYmUgc2VudCBq
dXN0IGZyb20gcmVjZWl2ZXIgdG8gcHVibGlzaGVyLiAgTG9zcw0KPiAgICBvZiB0aGUgaGVhcnRi
ZWF0IE1VU1QgcmVzdWx0IGluIGFueSBzdWJzY3JpcHRpb24gcmVsYXRlZCBUQ1Agc2Vzc2lvbnMN
Cj4gICAgYmV0d2VlbiB0aG9zZSBlbmRwb2ludHMgYmVpbmcgdG9ybiBkb3duLiAgQSBzdWJzY3Jp
YmVyIGNhbiB0aGVuDQo+ICAgIGF0dGVtcHQgdG8gcmUtZXN0YWJsaXNoLg0KPiANCj4gVGhpcyBp
cyBub3QgY2xlYXIgdG8gbWUuDQo+IA0KPiBGaXJzdCBpdCBzYXlzIHRoYXQgVExTIFNIT1VMRCBi
ZSB1c2VkLiAgQnV0IHdpdGggUkVTVENPTkYsIFRMUyBpcyBhbHJlYWR5IGENCj4gTVVTVC4NCg0K
VGhlIHNlY3Rpb24gcHJldmlvdXNseSB3YXMgc3VwcG9ydGluZyBIVFRQMiBvbmx5IGNvbmZpZ3Vy
ZWQgc3Vic2NyaXB0aW9ucy4gICBVcGRhdGVzIGFyZSBuZWVkZWQgZm9yIHBvaW50cyBsaWtlIHRo
aXMuDQoNCj4gU2Vjb25kLCBpdCBzYXlzIHRoYXQgaW4gdGhlIGNhc2Ugb2YgbWlzc2VkIFRMUyBo
ZWFydGJlYXRzLCAicmVsYXRlZCBUQ1Agc2Vzc2lvbnMiDQo+IGFyZSB0b3JuIGRvd24uICBXaGF0
IGFyZSB0aGVzZSBzZXNzaW9ucyAocGx1cmFsKSwgYW5kIHdoYXQgZXhhY3RseSBkb2VzDQo+ICJy
ZWxhdGVkIiBtZWFuPw0KDQpUaGlzIHNob3VsZCBiZSBzaW5ndWxhci4gIFJlbGF0ZWQgbWVhbnMg
dHJhbnNpdGluZy4NCiANCj4gVGhpcmQsIGl0IHNheXMgdGhhdCBhIHN1YnNjcmliZXIgY2FuIHJl
LWVzdGFibGlzaC4gIFdoYXQgY2FuIGl0IHJlLWVzdGFibGlzaD8gIFJlLQ0KPiBzZW5kIHRoZSBl
c3RhYmxpc2gtc3Vic2NyaXB0aW9uPyAgSnVzdCByZXNlbmQgdGhlIFBPU1QgdG8gdGhlIHN1YnNj
cmlwdGlvbiBVUkw/DQoNClRleHQgbmVlZHMgdG8gYmUgdXBkYXRlZCB0byBzYXkgImVzdGFibGlz
aC1zdWJzY3JpcHRpb24iLiANCg0KPiBUaGUgZmxvdyBpczoNCj4gDQo+IA0KPiAgICAgU3Vic2Ny
aWJlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUHVibGlzaGVyDQo+ICAgICAt
LS0tLS0tLS0tICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0NCj4g
DQo+ICAgICAgICB8IFJFU1RDT05GIFBPU1QgKFJQQzplc3RhYmxpc2gtc3Vic2NyaXB0aW9uKSAg
IHwNCj4gICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0+fA0KPiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgSFRUUCAyMDAgT0sgKElE
LFVSSSl8DQo+ICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLXwNCj4gICAgICAgIHwNCj4gICAgICAoKioqKQ0KPiAgICAgICAgfCAgIEhUVFAgUE9T
VCAoVVJJKQ0KPiAgICAgICAgfCAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tPnwNCj4gICAgICAgIHwgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgSFRUUCAyMDAgT0t8DQo+IA0KPiANCj4gQWZ0ZXIgdGhlIHB1Ymxpc2hlciBoYXMg
c2VudCBhIFVSSSBmb3IgdGhlIHN1YnNjcmlwdGlvbiB0byB0aGUgc3Vic2NyaWJlciwgdGhlcmUN
Cj4gaXMgYSBkZWxheSAoKioqKSB1bnRpbCB0aGUgc3Vic2NyaWJlciBoYXMgc2VudCB0aGUgbmV3
IFBPU1QuICBUaGUgcmVzb3VyY2UgdGhhdA0KPiB0aGUgVVJJIHBvaW50cyB0byBpcyBzdWJzY3Jp
YmVyLXNwZWNpZmljLCB3aGljaCBtZWFucyB0aGF0IHRoZSBwdWJsaXNoZXIgbWF5DQo+IGhhdmUg
Y3JlYXRlZCBzb21lIGFzc29jaWF0ZWQgc3RhdGUuICBUaGlzIHN0YXRlIHdpbGwgZXZlbnR1YWxs
eSBoYXZlIHRvIGJlDQo+IGRlc3Ryb3llZC4gIFdoZW4gY2FuIHRoZSBwdWJsaXNoZXIgc2FmZWx5
IGRlc3Ryb3kgdGhpcyBzdGF0ZT8NCg0KQ2FzZXMgaW5jbHVkZToNCi0gZGVsZXRlLXN1YnNjcmlw
dGlvbiBycGMNCi0ga2lsbC1zdWJzY3JpcHRpb24gcnBjDQotIGxvc3Mgb2YgVExTIGhlYXJ0YmVh
dA0KLSBpbmFiaWxpdHkgdG8gZGVsaXZlciBzZXF1ZW50aWFsIHNldHMgb2Ygbm90aWZpY2F0aW9u
IG1lc3NhZ2VzDQogICAgICJGb3IgY29ubmVjdGlvbmxlc3Mgb3Igc3RhdGVsZXNzIHRyYW5zcG9y
dHMgbGlrZQ0KICAgICAgSFRUUCwgYSBsYWNrIG9mIHJlY2VpcHQgYWNrbm93bGVkZ21lbnQgb2Yg
YSBzZXF1ZW50aWFsIHNldCBvZg0KICAgICAgbm90aWZpY2F0aW9uIG1lc3NhZ2VzIGFuZC9vciBr
ZWVwLWFsaXZlcyBjYW4gYmUgdXNlZCB0byB0cmlnZ2VyIGENCiAgICAgIHRlcm1pbmF0aW9uIG9m
IGEgZHluYW1pYyBzdWJzY3JpcHRpb24uICIgICAocGVyIFNOIDEuMykNCi0gIiBBIHB1Ymxpc2hl
ciBNQVkgdGVybWluYXRlIGEgZHluYW1pYyBzdWJzY3JpcHRpb24gYXQgYW55IHRpbWUuIiAgIChw
ZXIgU04gMS4zKQ0KDQo+IEZvciBleGFtcGxlLCB3aGF0IGhhcHBlbnMgaWYgdGhlIG5ldyBQT1NU
IG5ldmVyIGFycml2ZXM/DQoNClRoZW4gaXQgd2lsbCBmYWlsIHRvIGRlbGl2ZXIgYSBzZXF1ZW50
aWFsIHNldCBvZiBub3RpZmljYXRpb24gbWVzc2FnZXMNCg0KPiBJZiB0aGUgc3Vic2NyaWJlcg0K
PiBsb3NlcyBpdHMgdHJhbnNwb3J0IHNlc3Npb24sIGNhbiBpdCBzZW5kIGEgbmV3IFBPU1QgdG8g
dGhlIHNhbWUgVVJMPyAgQ2FuIGl0DQo+IHNlbmQgbXVsdGlwbGUgUE9TVHMgdG8gdGhlIHNhbWUg
VVJMPw0KDQpBZ3JlZSB0aGUgdGV4dCBjYW4gYmUgZW5oYW5jZWQgdG8gY292ZXIgeW91ciBwb2lu
dHMgYWJvdmUuICBJIGhhZCBiZWVuIGFzc3VtaW5nIHRoaXMgd291bGQgbm90IGJlIHRoZSBjYXNl
LiAgQnV0IEkgaGF2ZW4ndCB0aG91Z2h0IGRlZXBseSBhYm91dCBpdC4NCiANCkVyaWMNCg0KPiA+
IGFuZA0KPiA+IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMsIHNl
Y3Rpb25zIDEuMyAmIDUuMy4NCj4gDQo+IEkgZGlkbid0IGZpbmQgdGhlIGFuc3dlcnMgdG8gdGhl
IHF1ZXN0aW9ucyBhYm92ZSBpbiB0aGVzZSBzZWN0aW9ucy4NCj4gDQo+IA0KPiAvbWFydGluDQo+
IA0KPiANCj4gPg0KPiA+IEVyaWMNCj4gPg0KPiA+ID4gTm90ZSB0aGF0IHRoZSBhcHByb2FjaCBp
biBSRkMgODA0MCBpcyBkb2Vzbid0IGhhdmUgdGhpcyBpc3N1ZS4NCj4gPiA+DQo+ID4gPg0KPiA+
ID4gL21hcnRpbg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+IFRoaXMgY291bGQgYmUgZG9uZSBvZiBj
b3Vyc2UsIGJ1dCBzb21lb25lIHdvdWxkIG5lZWQgdG8gZHJpdmUgdGhlDQo+ID4gPiA+IGRlZmlu
aXRpb24uDQo+ID4gPiA+DQo+ID4gPiA+IEVyaWMNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4g
V291bGQgaXQgYmUgd3JvbmcgZm9yIGEgY2xpZW50IHRvIG1ha2UgYW55IGFzc3VtcHRpb25zPyAg
SSByZWFsaXplDQo+ID4gPiA+IHRoaXMgQVNTVU1FcyBhIHRyYW5zcG9ydCBwcm90b2NvbCwgYnV0
IGNvdWxkL3dvdWxkIHRoZXJlIGJlIGENCj4gPiA+ID4gb25lLXRpbWUsIGNhcGFiaWxpdHkgY2hl
Y2sgdGhlIGNsaWVudCBjb3VsZCBtYWtlIHRvIHRlc3QgZm9yDQo+ID4gPiA+IGF2YWlsYWJsZSB0
cmFuc3BvcnRzPw0KPiA+ID4gPg0KPiA+ID4gPiBJIHJlYWxseSBhcHByZWNpYXRlIHlvdXIgdGlt
ZSBleHBsYWluaW5nLCBJIGhhdmUgYmVlbiBmb2xsb3dpbmcNCj4gPiA+ID4gdGhlIGVtYWlscyBi
ZXN0IEkgY291bGQgYnV0IEkgdGhpbmsgc29tZSBiYXNpYyB0aGluZ3MgYXJlIHN0aWxsDQo+ID4g
PiA+IGVsdWRpbmcgbWUuDQo+ID4gPiA+DQo=


From nobody Thu Sep 20 14:23:39 2018
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 91905127333; Thu, 20 Sep 2018 14:23:31 -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.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <153747861154.5270.11129069923552839360@ietfa.amsl.com>
Date: Thu, 20 Sep 2018 14:23:31 -0700
Archived-At: 
Subject: [Netconf] I-D Action: draft-ietf-netconf-crypto-types-01.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2018 21:23:31 -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
        Author          : Kent Watsen
	Filename        : draft-ietf-netconf-crypto-types-01.txt
	Pages           : 29
	Date            : 2018-09-20

Abstract:
   This document defines YANG identities and typedefs 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-01
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-01


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

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


From nobody Thu Sep 20 14:40:23 2018
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 6954C130EBF; Thu, 20 Sep 2018 14:40:13 -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.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <153747961334.5376.17355200419729700602@ietfa.amsl.com>
Date: Thu, 20 Sep 2018 14:40:13 -0700
Archived-At: 
Subject: [Netconf] I-D Action: draft-ietf-netconf-trust-anchors-01.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2018 21:40:21 -0000

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

        Title           : YANG Data Model for Global Trust Anchors
        Author          : Kent Watsen
	Filename        : draft-ietf-netconf-trust-anchors-01.txt
	Pages           : 15
	Date            : 2018-09-20

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  "2018-09-20" --> 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-01
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-trust-anchors-01


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

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


From nobody Thu Sep 20 15:48:38 2018
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 C6B78129AB8; Thu, 20 Sep 2018 15:48:27 -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.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <153748370776.5219.8854969457526582582@ietfa.amsl.com>
Date: Thu, 20 Sep 2018 15:48:27 -0700
Archived-At: 
Subject: [Netconf] I-D Action: draft-ietf-netconf-keystore-06.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2018 22:48:28 -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-06.txt
	Pages           : 24
	Date            : 2018-09-20

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-06
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-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 Thu Sep 20 17:03:33 2018
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 51D69124D68; Thu, 20 Sep 2018 17:03:31 -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.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <153748821129.5331.6236441767845013630@ietfa.amsl.com>
Date: Thu, 20 Sep 2018 17:03:31 -0700
Archived-At: 
Subject: [Netconf] I-D Action: draft-ietf-netconf-ssh-client-server-07.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Sep 2018 00:03: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           : YANG Groupings for SSH Clients and SSH Servers
        Authors         : Kent Watsen
                          Gary Wu
	Filename        : draft-ietf-netconf-ssh-client-server-07.txt
	Pages           : 38
	Date            : 2018-09-20

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-07
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-07


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

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


From nobody Thu Sep 20 18:12:22 2018
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 B0FE612DD85; Thu, 20 Sep 2018 18:12:14 -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.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <153749233467.5305.543204247870362018@ietfa.amsl.com>
Date: Thu, 20 Sep 2018 18:12:14 -0700
Archived-At: 
Subject: [Netconf] I-D Action: draft-ietf-netconf-tls-client-server-07.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Sep 2018 01:12: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 Groupings for TLS Clients and TLS Servers
        Authors         : Kent Watsen
                          Gary Wu
	Filename        : draft-ietf-netconf-tls-client-server-07.txt
	Pages           : 30
	Date            : 2018-09-20

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-07
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tls-client-server-07


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

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


From nobody Thu Sep 20 19:10:09 2018
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 0E15E130E4E; Thu, 20 Sep 2018 19:10: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.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <153749580798.5335.18042988299002806575@ietfa.amsl.com>
Date: Thu, 20 Sep 2018 19:10:08 -0700
Archived-At: 
Subject: [Netconf] I-D Action: draft-ietf-netconf-netconf-client-server-07.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Sep 2018 02:10:08 -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-07.txt
	Pages           : 57
	Date            : 2018-09-20

Abstract:
   This document defines two YANG modules, one module to configure a
   NETCONF client and the other module to configure a NETCONF server.
   Both modules support both the SSH and TLS transport protocols, and
   support both standard NETCONF and NETCONF Call Home connections.

Editorial Note (To be removed by RFC Editor)

   This draft contains many placeholder values that need to be replaced
   with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  No other RFC
   Editor instructions are specified elsewhere in this document.

   This document contains references to other drafts in progress, both
   in the Normative References section, as well as in body text
   throughout.  Please update the following references to reflect their
   final RFC assignments:

   o  I-D.ietf-netconf-keystore

   o  I-D.ietf-netconf-ssh-client-server

   o  I-D.ietf-netconf-tls-client-server

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements:

   o  "XXXX" --> the assigned RFC value for this draft

   o  "YYYY" --> the assigned RFC value for I-D.ietf-netconf-ssh-client-
      server

   o  "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-tls-client-
      server

   Artwork in this document contains placeholder values for the date of
   publication of this draft.  Please apply the following replacement:

   o  "2018-09-20" --> the publication date of this draft

   The following Appendix section is to be removed prior to publication:

   o  Appendix A.  Change Log


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-07
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-client-server-07


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

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


From nobody Thu Sep 20 19:25:51 2018
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 F0A16128B14; Thu, 20 Sep 2018 19:25:40 -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.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <153749674094.5305.12709689676807647195@ietfa.amsl.com>
Date: Thu, 20 Sep 2018 19:25:40 -0700
Archived-At: 
Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-client-server-07.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Sep 2018 02:25:41 -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-07.txt
	Pages           : 39
	Date            : 2018-09-20

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.


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-07
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-client-server-07


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

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


From nobody Thu Sep 20 19:57:01 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EB41271FF for ; Thu, 20 Sep 2018 19:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham 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 n1iL5yL5-UmE for ; Thu, 20 Sep 2018 19:56:57 -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 6C5A2124D68 for ; Thu, 20 Sep 2018 19:56:57 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8L2tKve028532 for ; Thu, 20 Sep 2018 19:56:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=kAeKQzZWAv1hvgyeIQxE3UlKizjG3tzh2ZwoOwR1Tkw=; b=KoSsAb1VMKk7WOEYRDejf0CVtujZ6uwG4IaqK/erlbhwrTGFh2n9UpgBSJETOxoQ21pa FUb0L/QRYuwI81QwzwwhiAsgJHLE4pJ2+qApvNT4nbEPulSP9TjwR87+mGIOKSwxyre3 pkt0yKwZPngmCL+GJ4JJafc5D48j7cyA9+f0QKAmaGNsBq9BNLLjJoWR83MvPhCLC8Hn a28drHAnOYOdu2TJbusvXoSNt6Ky72wQ/jj9HUH3HEN2BP3QWilxFhvwKc6KzcSiDNX1 72EXtLnTHbtAnTInpTGmkJGLV2jBteWJjkM4mMnDyXIDLqY5pDRChg3k4zLscbISOIWH uw== 
Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0178.outbound.protection.outlook.com [216.32.181.178]) by mx0b-00273201.pphosted.com with ESMTP id 2mmkkwrfem-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 20 Sep 2018 19:56:56 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB5099.namprd05.prod.outlook.com (20.177.223.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.10; Fri, 21 Sep 2018 02:56:53 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1164.014; Fri, 21 Sep 2018 02:56:53 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: updates to the client/server drafts
Thread-Index: AQHUUVbAvgWl9XKJDky/TADn8k/2zg==
Date: Fri, 21 Sep 2018 02:56:53 +0000
Message-ID: <1B690DF4-4174-41C2-8E85-C18DAAD01B54@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB5099; 6:SYh+Ui94g8/NJO/rRkB0lNVT8QFOe4kpWh5a7iWqH2GLp7nJTRZXmgE7ptlYTrWyqBsSpSqpWdZH2vsk05QwipOtJz6q7ZreSvkX8jMUV+BMiizbgsWGzMv+WtkyWuPZLhLD1R+WG7sMcGrE4txe/RPBWm5Zd+bzb3Hkj4zK8PNgF1tnz0hw/6njVAMSpoXAKA085Ss53wKghfMiC+yJ+LHczO3BE5SwCCu05EGfGb+twLKjpHnP4JcMVOLQZYY2geUu1n9UaasQAMo7Mto3irSKZzMUzaQsDZPmg85WisikIgAhv2K+jqNGSeWxw6Xkh9UJ3MyPUoMxW3sNiriLP4subyllrrqMahbenOBUlUEw33Rm79gh0X3Jrb27YVOlQMLy2qlak7o/48SjAG7ZBnMvjLXI4vPOCoOYJxsPl5M85AgH3ErVN4Ctf1Q4SQQlxe+YvgbExJf6osKJ+EMyyQ==; 5:UWoBsmZx+0USTfyeR1zUAikqJkbrj9qd6xuA46Ndb0xoHqy9utKVP0gq7ioOKSChEv9sHHdGyWRAonp31L0Ndxru5+CiqMTsGZPWjYF552SEA0tW8k9SyR8Hcho6GvonO8g4ECrd504X8jrtOHWAOXv5u++KHjwcf27g1n8496Y=; 7:rTUmbgyzqr4CdXWiFHzRE5qt/Cqw2AQPVGjgTAL2EiwsiUmuDgyQSvV35b1Xg/PN/TfUtluoK7HNB+4KFSjPPJ0HzuiVcZqyULJtoN6FBIS8oxnrM3TfQ/1y2U2k0e3nfe+UFMnXbQw7UTiin1NUqCsYhwE/SmVdXQ+iyzPHS5FyuD4Lc6zDA6lhEPwmO2mdYN+fTOYyQFE1CPWwdaZd4Ku+YQm/DyfrB2JE9jfW+3Q++wF4Ln5oFgeR9n9VE52Y
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 05185fae-7c31-4955-620c-08d61f6de2f5
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB5099; 
x-ms-traffictypediagnostic: DM6PR05MB5099:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(17755550239193);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231355)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(201708071742011)(7699051); SRVR:DM6PR05MB5099; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB5099; 
x-forefront-prvs: 0802ADD973
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(366004)(346002)(376002)(54534003)(199004)(189003)(1730700003)(81156014)(81166006)(6506007)(15650500001)(71190400001)(102836004)(71200400001)(53936002)(26005)(33656002)(6512007)(8936002)(186003)(6486002)(5640700003)(2351001)(6436002)(68736007)(2900100001)(7736002)(86362001)(5250100002)(305945005)(2501003)(82746002)(6916009)(97736004)(83716003)(8676002)(36756003)(105586002)(66066001)(6116002)(3846002)(99286004)(478600001)(5660300001)(2616005)(476003)(25786009)(106356001)(486006)(14454004)(2906002)(316002)(256004)(58126008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5099; H:DM6PR05MB4665.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-microsoft-antispam-message-info: OFDFx/X4pftKaPFvmsjpGiZXVQJsAJmd+JIDhFQBbngtZ2+htWZ/SBdwpZ1VNYqt7v4YZbeM/biaJPrubV0nfAt4E1fhbZO8m8Dozi1Mc96aXXDIFy/LQi1Ixsm40wt/m9/zBMmMIAtmjvI8wXxi2/4hTB0cgQFXaALjRDc9QlqAQpIq9I74RelF+4ZFSNuRd00ChszK6TWXErJylYKtBLqEydNBGsnnSX2cYtRAnHzbv8xMpPYdQEiaI8HtOmkMT5DiJcVkxXsAHvPPmcXq/G1dIGnTueFTYUmt6ClEVW3pfj8oR/bZYzXZS5MTCdnTCJMtPH9bmUiOxfrRWfYuv8aXoNKhSzCNsIFlAF5tSx0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <55AF2098042AE0489D989B8328511AEF@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 05185fae-7c31-4955-620c-08d61f6de2f5
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2018 02:56:53.8251 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5099
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-20_13:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809210028
Archived-At: 
Subject: [Netconf] updates to the client/server drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Sep 2018 02:57:00 -0000

DQpVcGRhdGVkIHRoZSBzdWl0ZSBvZiBkcmFmdHMuDQoNCklzc3VlcyBmcm9tIElFVEYgMTAyIG5v
dCB5ZXQgYWRkcmVzc2VkIGFyZToNCiAtIFNob3VsZCBhbGdvcml0aG0gaWRlbnRpdGllcyBiZSBt
b3ZlZCBmcm9tIGlldGYtW3NzaC90bHNdLWNvbW1vbg0KICAgdG8gY3J5cHRvLXR5cGVzPyAoc29t
ZSBwcm9ncmVzcyBoZXJlLCBidXQgbm90aGluZyB0byByZXBvcnQgeWV0KQ0KIC0gQWRkIHN1cHBv
cnQgZm9yIFRDUCBLZWVwYWxpdmVzPyAgKHRoaXMgbmVlZHMgbW9yZSBkaXNjdXNzaW9uKQ0KDQpO
b3RlIHRoYXQgZm9yIHRoZSBpc3N1ZSAiU2hvdWxkIHNvbWUgb2YgS2V5c3RvcmUncyBncm91cGlu
Z3MgYmUgDQptb3ZlZCB0byBjcnlwdG8tdHlwZXM/IiwgSSBqdXN0IHdlbnQgYWhlYWQgYW5kIGRp
ZCBpdC4gIE15IGlkZWENCmlzIHRoYXQgdGhlcmUgaXMgbm8gd2F5IHdlJ2xsIGtub3cgdW5sZXNz
IHdlIHRyeSwgc28gSSBkaWQuICBJZg0Kd2UgZG9uJ3QgbGlrZSBpdCwgd2UgY2FuIHB1dCBpdCBi
YWNrLiAgW1BsZWFzZSByZXZpZXchXQ0KDQpDaGFuZ2VzIG1hZGUgZGlzY3Vzc2VkIHBvc3QtMTAy
IGluY2x1ZGU6DQogIC0gcmVmYWN0b3JpbmcgdGhlIHNzaC90bHMgY2xpZW50L3NlcnZlciBncm91
cGluZ3MgKHBlciBCYWxhenMpDQogIC0gcmVwbGFjaW5nIHJlY29ubmVjdC10aW1lb3V0IHdpdGgg
cGVyaW9kL2FuY2hvci10aW1lIChwZXIgTWFydGluKQ0KDQpDaGFuZ2VzIE5PVCBtYWRlIGRpc2N1
c3NlZCBwb3N0LTEwMiBpbmNsdWRlOg0KICAtIGFkZGluZyBhbiAib24tZGVtYW5kIiBjb25uZWN0
aW9uLXR5cGUuIFRoaXMgbmVlZHMgbW9yZSANCiAgICBkaXNjdXNzaW9uLg0KDQpDaGFuZ2VzIG1h
ZGUgdGhvdWdoIE5PVCBkaXNjdXNzZWQ6DQogIC0gcmVtb3ZlZCB0aGUgIm9uLWRlbWFuZCIgb3B0
aW9uIGZvciB0aGUgcGVyaW9kaWMgY29ubmVjdGlvbg0KICAgIHR5cGUuICBUaGlzIGlzIHJlbGF0
ZWQgdG8gdGhlIGFib3ZlIG5vbi1jaGFuZ2UuICBCYXNpY2FsbHksDQogICAgd2UgbmVlZCB0byB0
aGluayBoYXJkZXIgYWJvdXQgb24tZGVtYW5kIGNvbm5lY3Rpb25zIGFuZA0KICAgIGhvdyB0aGV5
IHJlbGF0ZSB0byB0aGUgImNhbGwtaG9tZS1yZWFzb24iIGlkZWEgdGhhdCB3YXMNCiAgICBkaXNj
dXNzZWQgc29tZS4NCg0KVGhlIHBlci1kcmFmdCBDaGFuZ2UgTG9ncyBhcmUgbGlzdGVkIGJlbG93
Lg0KDQpjcnlwdG8tdHlwZXM6DQogICBvICBNb3ZlZCBncm91cGluZ3MgZnJvbSB0aGUgZHJhZnQt
aWV0Zi1uZXRjb25mLWtleXN0b3JlIGhlcmUuDQoNCnRydXN0LWFuY2hvcnM6DQogICBvICBBZGRl
ZCBmZWF0dXJlcyAieDUwOS1jZXJ0aWZpY2F0ZXMiIGFuZCAic3NoLWhvc3Qta2V5cyIuDQogICBv
ICBBZGRlZCBuYWNtOmRlZmF1bHQtZGVueS13cml0ZSB0byAidHJ1c3QtYW5jaG9ycyIgY29udGFp
bmVyLg0KDQprZXlzdG9yZToNCiAgIG8gIEFkZGVkIGZlYXR1cmUgImxvY2FsLWtleXMtc3VwcG9y
dGVkIg0KICAgbyAgQWRkZWQgbmFjbTpkZWZhdWx0LWRlbnktYWxsIGFuZCBuYWNtOmRlZmF1bHQt
ZGVueS13cml0ZQ0KICAgbyAgUmVuYW1lZCBnZW5lcmF0ZS1hc3ltbWV0cmljLWtleSB0byBnZW5l
cmF0ZS1oaWRkZW4ta2V5DQogICBvICBBZGRlZCBhbiBpbnN0YWxsLWhpZGRlbi1rZXkgYWN0aW9u
DQogICBvICBNb3ZlZCBhY3Rpb25zIGluc2lkZSBmbyB0aGUgImFzeW1tZXRyaWMta2V5IiBjb250
YWluZXINCiAgIG8gIE1vdmVkIHNvbWUgZ3JvdXBpbmdzIHRvIGRyYWZ0LWlldGYtbmV0Y29uZi1j
cnlwdG8tdHlwZXMNCg0Kc3NoLWNsaWVudC1zZXJ2ZXI6DQogICBvICBmYWN0b3JlZCB0aGUgc3No
LVtjbGllbnR8c2VydmVyXS1ncm91cGluZ3MgaW50byBtb3JlIHJldXNhYmxlDQogICAgICBncm91
cGluZ3MuDQogICBvICBhZGRlZCBpZi1mZWF0dXJlIHN0YXRlbWVudHMgZm9yIHRoZSBuZXcgInNz
aC1ob3N0LWtleXMiIGFuZA0KICAgICAgIng1MDktY2VydGlmaWNhdGVzIiBmZWF0dXJlcyBkZWZp
bmVkIGluIGRyYWZ0LWlldGYtbmV0Y29uZi10cnVzdC0NCiAgICAgIGFuY2hvcnMuDQoNCnRscy1j
bGllbnQtc2VydmVyOg0KICAgbyAgZmFjdG9yZWQgdGhlIHRscy1bY2xpZW50fHNlcnZlcl0tZ3Jv
dXBpbmdzIGludG8gbW9yZSByZXVzYWJsZQ0KICAgICAgZ3JvdXBpbmdzLg0KICAgbyAgYWRkZWQg
aWYtZmVhdHVyZSBzdGF0ZW1lbnRzIGZvciB0aGUgbmV3ICJ4NTA5LWNlcnRpZmljYXRlcyINCiAg
ICAgIGZlYXR1cmUgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLW5ldGNvbmYtdHJ1c3QtYW5jaG9ycy4N
Cg0KbmV0Y29uZi1jbGllbnQtc2VydmVyOg0KICAgbyAgUmVtb3ZlZCAiaWRsZS10aW1lb3V0IiBm
cm9tICJwZXJzaXN0ZW50IiBjb25uZWN0aW9uIGNvbmZpZy4NCiAgIG8gIEFkZGVkICJyYW5kb20t
c2VsZWN0aW9uIiBmb3IgcmVjb25uZWN0aW9uLXN0cmF0ZWd5J3MgInN0YXJ0cy13aXRoIg0KICAg
ICAgZW51bS4NCiAgIG8gIFJlcGxhY2VkICJjb25uZWN0aW9uLXR5cGUiIGNob2ljZSBkZWZhdWx0
IChwZXJzaXN0ZW50KSB3aXRoDQogICAgICAibWFuZGF0b3J5IHRydWUiLg0KICAgbyAgUmVkdWNl
ZCB0aGUgcGVyaW9kaWMtY29ubmVjdGlvbidzICJpZGxlLXRpbWVvdXQiIGZyb20gNSB0byAyDQog
ICAgICBtaW51dGVzLg0KICAgbyAgUmVwbGFjZWQgcmVjb25uZWN0LXRpbWVvdXQgd2l0aCBwZXJp
b2QvYW5jaG9yLXRpbWUgY29tYm8uDQoNCg0KcmVzdGNvbmYtY2xpZW50LXNlcnZlcjoNCiAgIG8g
IHJlbW92ZWQgImlkbGUtdGltZW91dCIgZnJvbSAicGVyc2lzdGVudCIgY29ubmVjdGlvbiBjb25m
aWcuDQogICBvICBBZGRlZCAicmFuZG9tLXNlbGVjdGlvbiIgZm9yIHJlY29ubmVjdGlvbi1zdHJh
dGVneSdzICJzdGFydHMtd2l0aCINCiAgICAgIGVudW0uDQogICBvICBSZXBsYWNlZCAiY29ubmVj
dGlvbi10eXBlIiBjaG9pY2UgZGVmYXVsdCAocGVyc2lzdGVudCkgd2l0aA0KICAgICAgIm1hbmRh
dG9yeSB0cnVlIi4NCiAgIG8gIFJlZHVjZWQgdGhlIHBlcmlvZGljLWNvbm5lY3Rpb24ncyAiaWRs
ZS10aW1lb3V0IiBmcm9tIDUgdG8gMg0KICAgICAgbWludXRlcy4NCiAgIG8gIFJlcGxhY2VkIHJl
Y29ubmVjdC10aW1lb3V0IHdpdGggcGVyaW9kL2FuY2hvci10aW1lIGNvbWJvLg0KDQoNCg0KS2Vu
dCAvLyBjb250cmlidXRvcg0KDQoNCg0K


From nobody Fri Sep 21 12:11:37 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7BB130DEE for ; Fri, 21 Sep 2018 12:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_HIGH=-0.01, 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 Hsy7sAk9X4rU for ; Fri, 21 Sep 2018 12:11:32 -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 A6F22130E42 for ; Fri, 21 Sep 2018 12:11:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21820; q=dns/txt; s=iport; t=1537557092; x=1538766692; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0EgY+jPwlM1l+NkTP7hPdsrbnOyxkjHFUwfFZUyA4Xw=; b=jwclR/PXgDFQqFOlfrv9v8/tTicdnvUpiP3dcg+UVpf+EBUkjZxx+pof aEhiZId4tLXxnEEQnkHXxiotYCJRyw7CgGzOFVERKvQoa+I5dXFVcdH/A e7oL5cEnvw6yizDPis85Fo93dp0y7ShPbYlNaEkaemOl0F69RYCNdTJZM A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DuAAD2QaVb/4kNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBU4FcKmV/KAqDaZRAgg2DPZMSFIFmCxgLCYRAAheDLyE?= =?us-ascii?q?2FgEDAQECAQECbRwMhTgBAQEBAgEjBA1DAhACAQgVAwICCRYEAwICAjAUARA?= =?us-ascii?q?CBAENAQQJEgSCN0sBgXkID6MgezOKCYELiWUXgUE/gRInH4JMhGYCFgcQI4J?= =?us-ascii?q?HMYImAog2EosHiFxPCQKJSIZfF4FFh1eBDYR/lFoCERSBJSQJKCeBLnAVZQG?= =?us-ascii?q?CQQmCHBcRiEmFPQFvAQ6BB4ptB4EnAYEdAQE?=
X-IronPort-AV: E=Sophos;i="5.54,286,1534809600"; d="scan'208";a="174964458"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2018 19:11:31 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id w8LJBVCj013530 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Sep 2018 19:11:31 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 21 Sep 2018 14:11:30 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Fri, 21 Sep 2018 14:11:30 -0500
From: "Reshad Rahman (rrahman)" 
To: "Eric Voit (evoit)" , Martin Bjorklund 
CC: "douglas@hubler.us" , "andy@yumaworks.com" , "j.schoenwaelder@jacobs-university.de" , "netconf@ietf.org" 
Thread-Topic: SSE and HTTP/2 in restcon-notif [Was: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16]
Thread-Index: AQHUUR1ilTVOXqC/9Uuqu7PUScrtoaT7LFWA
Date: Fri, 21 Sep 2018 19:11:30 +0000
Message-ID: 
References: <48e4aac958d142669f4032737cdc4373@XCH-RTP-013.cisco.com> <20180919.083805.1103902318002046181.mbj@tail-f.com> <1f83e10a61fc4a89bf5e1264566a3e29@XCH-RTP-013.cisco.com> <20180920.092011.809234550582033045.mbj@tail-f.com> <494e1d8a26594e198e5241b8b5c4070b@XCH-RTP-013.cisco.com>
In-Reply-To: <494e1d8a26594e198e5241b8b5c4070b@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.149]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: 
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif [Was: activate-configured-subecription - WGLC subscribed-notifications-16]
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Sep 2018 19:11:36 -0000

SGksDQoNCg0K77u/T24gMjAxOC0wOS0yMCwgNDowNiBQTSwgIkVyaWMgVm9pdCAoZXZvaXQpIiA8
ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCg0KICAgIEhpLA0KICAgIA0KICAgID4gRnJvbTogTWFy
dGluIEJqb3JrbHVuZCwgU2VwdGVtYmVyIDIwLCAyMDE4IDM6MjAgQU0NCiAgICA+IA0KICAgID4g
SGksDQogICAgPiANCiAgICA+IFtzdWJqZWN0IGNoYW5nZTsgdGhpcyB0aHJlYWQgaXMgbm93IGFi
b3V0IFNTRSBhbmQgSFRUUC8yXQ0KICAgID4gDQogICAgPiAiRXJpYyBWb2l0IChldm9pdCkiIDxl
dm9pdEBjaXNjby5jb20+IHdyb3RlOg0KICAgID4gPiA+IEZyb206IE1hcnRpbiBCam9ya2x1bmQs
IFNlcHRlbWJlciAxOSwgMjAxOCAyOjM4IEFNDQogICAgPiA+ID4NCiAgICA+ID4gPiBIaSwNCiAg
ICA+ID4gPg0KICAgID4gPiA+ICJFcmljIFZvaXQgKGV2b2l0KSIgPGV2b2l0QGNpc2NvLmNvbT4g
d3JvdGU6DQogICAgPiA+ID4gPiBIaSBEb3VnbGFzLA0KICAgID4gPiA+ID4NCiAgICA+ID4gPiA+
IEZyb206IERvdWdsYXMgSHVibGVyLCBTZXB0ZW1iZXIgMTgsIDIwMTggNTozNSBQTQ0KICAgID4g
PiA+ID4NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiBPbiBUdWUsIFNlcCAxOCwgMjAxOCBhdCAz
OjQwIFBNIE1hcnRpbiBCam9ya2x1bmQNCiAgICA+ID4gPiA+IDxtYmpAdGFpbC1mLmNvbTxtYWls
dG86bWJqQHRhaWwtZi5jb20+PiB3cm90ZToNCiAgICA+ID4gPiA+IFNvIGl0IHNlZW1zIHlvdSBz
dXBwb3J0IG15IHBvaW50IHRvIG1ha2UgdGhpcyBkcmFmdCB1c2UgU1NFLiAgVGhlbg0KICAgID4g
PiA+ID4gaWYgeW91IHVzZSBIVFRQLzIgeW91ICh0aGUgY2xpZW50KSBjYW4gc2ltcGx5IGNyZWF0
ZSBvbmUgSFRUUC8yDQogICAgPiA+ID4gPiBzdHJlYW0gcGVyIG5vdGlmaWNhdGlvbiBzdHJlYW0u
ICBUaGlzIGp1c3QgZmFsbHMgb3V0IGZvciBmcmVlIHdpdGggSFRUUC8yLg0KICAgID4gPiA+ID4N
CiAgICA+ID4gPiA+IHllcywgd2l0aCBjYXZlYXQgdGhhdCBJIGhhdmVuJ3QgYXR0ZW1wdGVkIGFj
dHVhbCBpbXBsZW1lbnRhdGlvbiB5ZXQuDQogICAgPiA+ID4gPg0KICAgID4gPiA+ID4gPEVyaWM+
IEFncmVlIHRoYXQgU1NFIG92ZXIgSFRUUDIgc2hvdWxkIHdvcmsuICBIb3dldmVyIHRvIG1lIHVz
aW5nDQogICAgPiA+ID4gPiBTU0UgaGVyZSBzZWVtcyByZWR1bmRhbnQgYXMgSFRUUDIgcHJvdmlk
ZXMgdGhlIG5lY2Vzc2FyeSBtZWNoYW5pc21zLg0KICAgID4gPiA+DQogICAgPiA+ID4gRXJpYywg
Y2FuIHlvdSBleHBsYWluIGhvdyB0aGlzIHdvdWxkIHdvcmsgdy9vIFNTRT8gIFdoaWNoIG1lY2hh
bmlzbQ0KICAgID4gPiA+IGluDQogICAgPiA+ID4gSFRUUC8yIGFyZSB5b3UgcmVmZXJyaW5nIHRv
Pw0KICAgID4gPg0KICAgID4gPiBBZnRlciBhbiBIVFRQMiBPSywgdGhlIEhUVFAyIHNlcnZlciBo
YXMgdGhlIGFiaWxpdHkgdG8gZm9yd2FyZCBhbg0KICAgID4gPiB1bmJvdW5kZWQgbnVtYmVyIG9m
IEhUVFAyIERhdGEgRnJhbWVzIG9uIHRoZSBIVFRQMiBzdHJlYW0uDQogICAgPiANCiAgICA+IEJ1
dCBpdCBtdXN0IHN0aWxsIGFkaGVyZSB0byB0aGUgbm9ybWFsIEhUVFAgc2VtYW50aWNzLiAgSWYg
dGhlcmUgd2FzIGEgcmVxdWVzdCwgaXQNCiAgICA+IG5lZWRzIHRvIHNlbmQgdGhlIHJlc3BvbnNl
LiAgSXQgY2FuIHNwbGl0IHRoZSByZXNwb25zZSBpbnRvIHNldmVyYWwgREFUQSBmcmFtZXMNCiAg
ICA+IG9mIGNvdXJzZS4gIEJ1dCBpdCBjYW5ub3Qgc3RhcnQgdG8gc2VuZCAib3RoZXIgc3R1ZmYi
IGluc3RlYWQgb2YgdGhlIHJlc3BvbnNlLA0KICAgID4gd2hpY2ggZmlndXJlIDEgaW4NCiAgICA+
IHJlc3Rjb25mLW5vdGlmLTA3IHBvc3NpYmx5IGltcGxpZXMuDQogICAgDQogICAgQWdyZWUuICAg
Tm90IHN1cmUgd2hlcmUgeW91IHNlZSB0aGF0IGluIEZpZ3VyZSAxLiAgIFRoZSBIVFRQMiBPSyBk
b2Vzbid0IG1lYW4gdGhlIGVuZCBvZiB0aGUgcmVzcG9uc2UuIChSRkMtNzk1MCwgcGFnZSA1Ny4p
ICAgICAgQW55IHN1Z2dlc3Rpb25zIG9uIGhvdyB0byBtYWtlIHRoaXMgY2xlYXJlcj8NCiAgICAg
DQogICAgPiA+IFRoZSBzdHJlYW0NCiAgICA+ID4gaXMgbm90IGNvbnNpZGVyZWQgY29tcGxldGUg
dW50aWwgYW4gRU5EX1NUUkVBTSBpcyBwYXNzZWQuICAoTm90ZSB0aGlzDQogICAgPiA+IGlzIGlu
ZGVwZW5kZW50IG9mIGFueXRoaW5nIHJlZ2FyZGluZyBIVFRQMidzIFBVU0hfUFJPTUlTRS4pDQog
ICAgPiA+DQogICAgPiA+IFlvdSBjYW4gc2VlIGFuIGV4YW1wbGUgZmxvdyBpbiBGaWd1cmUgMSBv
Zg0KICAgID4gPiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYuICBBdCBJRVRGIDk3
IHdlIGFza2VkIGZvciBzb21lDQogICAgPiA+IEZlZWRiYWNrIG9uIHRoaXMgcHJvcG9zYWwuDQog
ICAgPiA+IGh0dHA6Ly93d3cudm9pdC5vcmcvSUVURi9TdWJzY3JpcHRpb25zLU5FVENPTkYtSUVU
Rjk3LnBwdCAoc2VlIHNsaWRlDQogICAgPiA+IDE0KS4NCiAgICA+ID4gQnV0IEkgYW0gbm90IHN1
cmUgaG93IG11Y2ggZWZmb3J0IHRoZSBXRyBzaG91bGQgcGxhY2UgaGVyZS4gIFRoZSB3b3JrDQog
ICAgPiA+IGhlcmUgaXMgc2V2ZXJhbCB5ZWFycyBvbGQsIGFuZCB0aGUgbWFya2V0IGhhcyBtb3Zl
ZCBzdWJzdGFudGlhbGx5DQogICAgPiA+IHNpbmNlIHRoZW4uDQogICAgPiANCiAgICA+IFNvIGRv
IHdlIGFncmVlIHRoYXQgdGhlIHJlc3Rjb25mLW5vdGlmIGRyYWZ0IHdpbGwgYmUgdXBkYXRlZCB0
byB1c2UgU1NFDQogICAgPiByZWdhcmRsZXNzIG9mIEhUVFAgdmVyc2lvbj8gIElmIHRoZXJlIGlz
IGFueSB0ZXh0IGF0IGFsbCBhYm91dCBIVFRQLzIsIGl0IHdpbGwgYmUgYW4NCiAgICA+ICJpbXBs
ZW1lbnRhdGlvbiBub3RlIiB3aGVyZSBpdCBpcyByZWNvbW1lbmRlZCB0byB1c2UgYSBzZXBhcmF0
ZSBzdHJlYW0gcGVyDQogICAgPiBzdWJzY3JpcHRpb24/DQogICAgDQogICAgSSB3aWxsIGxlYXZl
IHRoYXQgdXAgdG8gUmVzaGFkIHRvIGZyYW1lLiAgSSB3b24ndCBmaWdodCBhZ2FpbnN0IGl0LCBh
bHRob3VnaCB0aGVyZSBpcyBpbnRlcnBsYXkgaGVyZSB3aXRoIHN1YnNjcmlwdGlvbiBidW5kbGlu
ZyAocGVyIGJlbG93KS4NCg0KPFJSPiBJJ20gb2sgd2l0aCB0aGF0LiAgDQoNClJlZ2FyZHMsDQpS
ZXNoYWQuDQogICAgIA0KICAgID4gPiA+ID4gQnV0DQogICAgPiA+ID4gPiBJIHdvbuKAmXQgZ2V0
IGluIHRoZSB3YXkgaWYgcGVvcGxlIHJlYWxseSBkbyB3YW50IHRvIGdvIGluIHRoaXMNCiAgICA+
ID4gPiA+IGRpcmVjdGlvbi4NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiA+IEkgZG9uJ3QgdW5k
ZXJzdGFuZCB0aGUgZGV0YWlscyBzdXJyb3VuZGluZyB1c2luZyBhbiBSUEMgdG8gbWFrZQ0KICAg
ID4gPiA+ID4gPiBhIGR5bmFtaWMgc3Vic2NyaXB0aW9uLiAgVW5sZXNzIGl0J3Mgb3B0aW9uYWws
IHRoZW4gSSBjYW4gc3RhcnQNCiAgICA+ID4gPiA+ID4gdG8gdW5kZXJzdGFuZC4NCiAgICA+ID4g
PiA+DQogICAgPiA+ID4gPiBUaGUgY2xpZW50IHdvdWxkIFBPU1QgdG8gdGhlICJycGMiIGVzdGFi
bGlzaC1zdWJzY3JpcGlvbiwgYW5kIGluDQogICAgPiA+ID4gPiB0aGUgcmVwbHkgdG8gdGhlIFBP
U1QgaXMgYSAibG9jYXRpb24iIGxlYWYgKCopIHRoYXQgY29udGFpbnMgYQ0KICAgID4gPiA+ID4g
VVJJLiAgVGhlIGNsaWVudCB0aGVuIEdFVCB0aGlzIFVSSTsgdGhpcyBpcyB0aGUgU1NFIGV2ZW50
IHN0cmVhbS4NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiBJIHNlZS4gIEJ1dCBpZiBhIGNsaWVu
dCByZWFkcyB0aGUgWUFORyBhcw0KICAgID4gPiA+ID4NCiAgICA+ID4gPiA+ICBtb2R1bGUgbXkt
bW9kdWxlIHsNCiAgICA+ID4gPiA+ICAgICAuLi4NCiAgICA+ID4gPiA+ICAgICBub3RpZmljYXRp
b24gbXktZXZlbnQgew0KICAgID4gPiA+ID4gICAgIH0NCiAgICA+ID4gPiA+IH0NCiAgICA+ID4g
PiA+DQogICAgPiA+ID4gPiBhbmQgY2xpZW50IGtuZXcgYmFzZSBzdHJlYW0gVVJJIHdhczoNCiAg
ICA+ID4gPiA+DQogICAgPiA+ID4gPiAgICAvcmVzdGNvbmYvbXktc3RyZWFtcw0KICAgID4gPiA+
ID4NCiAgICA+ID4gPiA+IENvdWxkbid0IHRoZSBjbGllbnQgdGhlbiBkZWR1Y2UgU1NFIFVSTCBh
czoNCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiAgR0VUICAvcmVzdGNvbmYvbXktc3RyZWFtcy9t
eS1tb2R1bGU6bXktZXZlbnQ/Li4uDQogICAgPiA+ID4NCiAgICA+ID4gPiBOby4NCiAgICA+ID4g
Pg0KICAgID4gPiA+IFdpdGggUkZDIDgwNDAsIHRoZSBTU0UgVVJMIGlzICJzdGFibGUiLCBhbmQg
aWYgdGhlIGNsaWVudCBoYXMgcmVhZA0KICAgID4gPiA+IGl0IG9udmUsIGl0IGRvZXNuJ3QgaGF2
ZSB0byByZWFkIGl0IGFnYWluIChtb2R1bG8gc29tZSBkZWZpbml0aW9uIG9mDQogICAgPiA+ID4g
InN0YWJsZSIpLg0KICAgID4gPiA+IFRoZSBjbGllbnQNCiAgICA+ID4gPiBjYW4gcGFzcyBhIGZp
bHRlciBpbiB0aGUgR0VUIHJlcXVlc3QgZm9yIHRoZSBTU0Ugc3RyZWFtLg0KICAgID4gPiA+DQog
ICAgPiA+ID4gV2l0aCB0aGUgbWVjaGFuaXNtIGluIHRoaXMgZHJhZnQsIHRoZSBTU0UgVVJMIHdp
bGwgdmFyeSBmb3IgZWFjaA0KICAgID4gPiA+IHJlcXVlc3QgdGhhdCBoYXMgYSBkaWZmZXJlbnQg
ZmlsdGVyIChhdCBhIG1pbmltdW0pLCBzaW5jZSB0aGUgZmlsdGVyDQogICAgPiA+ID4gaXMgcGFz
c2VkIGEgcGFyYW1ldGVyIHRvICJlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIiBhbmQgdGhlIFNTRSBV
UkwgaXMNCiAgICA+ID4gPiBzZW50IGJhY2sgaW4gdGhlIHJlcGx5IHRvDQogICAgPiA+ID4gImVz
dGFibGlzaC0NCiAgICA+ID4gPiBzdWJzY3JpcHRpb24iLiAgV2l0aCB0aGUgU1NFIFVSTCwgdGhl
IHNlcnZlciBtYXkgaGlkZSBzb21lIHN0YXRlDQogICAgPiA+ID4gdGhhdCBjb3JyZXNwb25kcyB0
byB0aGUgZmlsdGVyIHBhcmFtcyBldGMuICAoTk9URSB0aGUgd29yZCAqbWF5KiBpbg0KICAgID4g
PiA+IHRoZSBwcmV2aW91cyBzZW50ZW5jZS4gIEEgc2VydmVyIGNvdWxkIGFzIHdlbGwgc2VuZCBi
YWNrIGEgU1NFIFVSTA0KICAgID4gPiA+IHdpdGggdGhlIGZpbHRlciBwYXJhbWV0ZXJzIGVtYmVk
ZGVkIGluIHRoZQ0KICAgID4gPiA+IFVSTC4uLikNCiAgICA+ID4gPg0KICAgID4gPiA+IFNvIGlu
IGdlbmVyYWwsIGEgY2xpZW50IGNhbm5vdCBhc3N1bWUgdGhhdCBpdCBjYW4gcmUtdXNlIGEgU1NF
IFVSTA0KICAgID4gPiA+IHRoYXQgd2FzIHJldHVybmVkIGZyb20gYSBjYWxsIHRvICJlc3RhYmxp
c2gtc3Vic2NyaXB0aW9uIi4NCiAgICA+ID4gPg0KICAgID4gPiA+ID4gVGhlcmVieSBzYXZpbmcg
YSB0cmlwIHRvIHNlcnZlcj8NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiA8RXJpYz4gWWVzLCBp
dCB3b3VsZCBiZSBwb3NzaWJsZSB0byBzZXQgc29tZXRoaW5nIHVwIHRvIGRlZHVjZSB0aGUNCiAg
ICA+ID4gPiA+IFVSTC4gIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiBkb2VzbuKA
mXQgY3VycmVudGx5IGF0dGVtcHQNCiAgICA+ID4gPiA+IHRoaXMgYXMgYmVpbmcgYWJsZSB0byBk
ZWR1Y2UgdGhlIFVSTCBkb2VzbuKAmXQgc3RvcCB0aGUgZXh0cmEgdHJpcA0KICAgID4gPiA+ID4g
dG8gdGhlIHNlcnZlci4NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiBUaGUgcmVhc29uIGl0IGRv
ZXNu4oCZdCBnZXQgcmlkIG9mIHRoZSBleHRyYSByb3VuZCB0cmlwIGhhcyB0byBkbw0KICAgID4g
PiA+ID4gd2l0aA0KICAgID4gPiA+ID4gSFRUUDIgc3RyZWFtcy4gIElmIHdlIGFyZSBnb2luZyB0
byB1c2UgSFRUUDIsIHRoZXJlIGlzIHN0aWxsIGENCiAgICA+ID4gPiA+IG5lZWQgdG8gaW5pdGlh
dGUgdGhlIEdFVCAob3IgUE9TVCkgaW4gYSBzZXBhcmF0ZSBzdHJlYW0gb3RoZXIgdGhhbg0KICAg
ID4gPiA+ID4gdGhlIG9uZSBiZWluZyB1c2VkIGZvciBSRVNUQ09ORiBzaWduYWxpbmcuDQogICAg
PiA+ID4NCiAgICA+ID4gPiBJIGRpc2FncmVlLiAgSWYgdGhlIGNsaWVudCB3YW50cyB0byBoYXZl
IGEgc2VwYXJhdGUgSFRUUC8yIHN0cmVhbQ0KICAgID4gPiA+IGZvciB0aGUgbm90aWZzLCB0aGVu
IGl0IHNob3VsZCBzdGFydCBzdWNoIGEgc3RyZWFtLiAgSWYgdGhlIGNsaWVudA0KICAgID4gPiA+
IGRvZXNuJ3Qgd2FudCBhIHNlcGFyYXRlIEhUVFAvMiBzdHJlYW0gdGhlbiB0aGF0IHNob3VsZCBi
ZSBvayB0b28uDQogICAgPiA+DQogICAgPiA+IFBlciB5b3VyIGJlbG93LCBvbmNlIFNTRSBpcyBh
cHBsaWVkIGEgc3RyZWFtIGlzIGJsb2NrZWQuICBGb3IgdGhhdA0KICAgID4gPiBzdWJzY3JpcHRp
b24sIHlvdSBzdGlsbCBuZWVkIHRvIHN1cHBvcnQgJ21vZGlmeS1zdWJzY3JpcHRpb24nIGFuZA0K
ICAgID4gPiAnZGVsZXRlLXN1YnNjcmlwdGlvbicgcnBjcy4NCiAgICA+IA0KICAgID4gQnV0IHRo
ZSBzb2x1dGlvbiBjYW5ub3QgZGVwZW5kIG9uIHRoZSBzdWJzY3JpYmVyIGJlaW5nIGFibGUgdG8g
c2VuZCAiZGVsZXRlLQ0KICAgID4gc3Vic2NyaXB0aW9uIiBvbiB0aGUgc2FtZSB0cmFuc3BvcnQg
c2Vzc2lvbiAoQlRXLCB0aGlzIHJlcXVpcmVtZW50IHNob3VsZCBiZQ0KICAgID4gY2xhcmlmaWVk
IGluIHRoZSBZQU5HIGRlZmluaXRpb24gZm9yICJkZWxldGUtc3Vic2NyaXB0aW9uIiBpbiBTTiks
IHNpbmNlIHRoaXMNCiAgICA+IHdvdWxkIHJ1bGUgb3V0IEhUVFAvMS4xLg0KICAgIA0KICAgIFR3
ZWFrZWQgaXQgdG8gInVzaW5nIGEgdHJhbnNwb3J0IHNlc3Npb24gY29ubmVjdGluZyB0byB0aGUg
c3Vic2NyaWJlci4iDQogICAgDQogICAgPiAibW9kaWZ5LXN1YnNjcmlwdGlvbiIgY2FuIGJlIHNl
bnQgb24gYW5vdGhlciBzZXNzaW9uLCBlLmcuLCBhbm90aGVyDQogICAgPiBIVFRQLzEuMSBzZXNz
aW9uIHRoYXQgaXMgbm90IGRvaW5nIHRoZSBTU0VzLg0KICAgID4gDQogICAgPiBUaGlzIG1ha2Vz
IG1lIHdvbmRlci4uLiBpcyAiZGVsZXRlLXN1YnNjcmlwdGlvbiIgcmVhbGx5IG5lY2Vzc2FyeSwg
b3IgaXMgImtpbGwtDQogICAgPiBzdWJzY3JpcHRpb24iIHN1ZmZpY2llbnQ/DQogICAgPg0KICAg
ID4gPiBCZXlvbmQgdGhhdCwgb25lIHRoaW5nIHRvIGtlZXAgYW4gZXllIG9uIGlzIHRoZSBwb3Rl
bnRpYWwgZm9yIGJ1bmRsaW5nDQogICAgPiA+IG9mIGV2ZW50IHJlY29yZHMgZnJvbSBkaWZmZXJl
bnQgc3Vic2NyaXB0aW9ucyBpbnRvIGEgc2luZ2xlDQogICAgPiA+IHRyYW5zbWl0dGFibGUgbm90
aWZpY2F0aW9uIG1lc3NhZ2UuDQogICAgPiANCiAgICA+IEhvdyB3b3VsZCBhbiBIVFRQIHN1YnNj
cmliZXIgZXZlbiByZXF1ZXN0IHRoaXM/DQogICAgDQogICAgSXQgd291bGRuJ3QgYmUgZGV0ZXJt
aW5lZCBieSB0aGUgc3Vic2NyaWJlciBhdCBhbGwuICBJdCB3b3VsZCBiZSB1cCB0byB0aGUgcHVi
bGlzaGVyIHRvIGRldGVybWluZSB3aGF0IGdldHMgYnVuZGxlZCBvciBub3QuICAgSWYgc29tZW9u
ZSB3YW50cyB0byBjcmVhdGUgc2lnbmFsaW5nIHRvIG1hbmlwdWxhdGUgd2hhdCBjb3VsZCBiZSBi
dW5kbGVkLCBpdCB3b3VsZCByZXF1aXJlIGF1Z21lbnRhdGlvbnMgdG8gU04ncyBlc3RhYmxpc2gt
c3Vic2NyaXB0aW9uIFJQQyBwYXJhbWV0ZXJzLg0KICAgIA0KICAgID4gVGhlIHN1YnNjcmliZXIg
c2VuZHMgYW4gZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiBhbmQgZ2V0IGFuIFVSTCBmb3IgdGhhdA0K
ICAgID4gc3Vic2NyaXB0aW9uIGJhY2suDQogICAgPiANCiAgICA+IFRoZW4gaXQgc2VuZHMgYW5v
dGhlciBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIGFuZCBnZXRzIGFub3RoZXIgVVJMIGJhY2suDQog
ICAgPiANCiAgICA+IEhvdyBjYW4gYSBidW5kbGVkIG1lc3NhZ2UgYmUgc2VudCB3aGVuIHRoZXJl
IGFyZSB0d28gZGlmZmVyZW50IHN1YnNjcmlwdGlvbg0KICAgID4gcmVzb3VyY2VzPw0KICAgIA0K
ICAgIElmIGJ1bmRsaW5nIGlzIHN1cHBvcnRlZCwgeW91IGluaXRpYWxseSBzZW5kIGEgVVJMIHRv
IGEgc2hhcmVkIGJ1bmRsaW5nIHJlc291cmNlLiAgU3RyZWFtcyBjYW4gYmUgYWRkZWQgYW5kIHJl
bW92ZWQgZnJvbSB0aGF0IHJlc291cmNlLiAgIFRoZXNlIHBvc3NpYmlsaXRpZXMgYXJlIHRoZSBr
aW5kcyBvZiByZWFzb25zIHdoeSBhIFVSSSBpcyBzZW50IGJhY2sgYXMgcGFydCBvZiB0aGUgZXN0
YWJsaXNoLXN1YnNjcmlwdGlvbiByZXNwb25zZSAocmF0aGVyIHRoYW4gaXQgYmVpbmcgd2VsbC1r
bm93bikuICBGdXJ0aGVyIGNsYXJpZmljYXRpb25zIGluIHRoaXMgc3BhY2Ugd2lsbCBiZSBuZWVk
ZWQgYXMgd2UgZ2V0IGRlZXBlciBpbnRvIGJ1bmRsaW5nLg0KICAgIA0KICAgID4gPiAoU29tZXRo
aW5nIGxpa2UgaW4NCiAgICA+ID4gZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNz
YWdlcy4pICBBbnl3aGVyZSBzdWNoIGJ1bmRsaW5nDQogICAgPiA+IG9jY3VycywgdGhlIHB1Ymxp
c2hlciB3aWxsIGhhdmUgdG8gdXNlIGEgY29uc2lzdGVudCBIVFRQMiBzdHJlYW0NCiAgICA+ID4g
YWNyb3NzIGEgc2V0IG9mIHN1YnNjcmlwdGlvbnMgaW4gb3JkZXIgdG8gcHJlc2VydmUgZXZlbnQg
cmVjb3JkDQogICAgPiA+IG9yZGVyaW5nLiAgSW4gYWRkaXRpb24sIGFsbCBldmVudCByZWNvcmRz
IGJ1bmRsZWQgd2lsbCBoYXZlIHRvDQogICAgPiA+IGNvbnNpc3RlbnRseSB1c2UgdGhlIHNhbWUg
RFNDUC4NCiAgICA+ID4NCiAgICA+ID4gTm90ZTogdGhpcyBpcyBhbm90aGVyIHJlYXNvbiB3aHkg
aXQgaXMgYSBnb29kIGlkZWEgdG8gdXNlIHNlcGFyYXRlDQogICAgPiA+IEhUVFAyIHN0cmVhbXMg
Zm9yIFJFU1RDT05GIHN1YnNjcmlwdGlvbiBSUEMgaW50ZXJhY3Rpb25zLCBhbmQgZm9yIHRoZQ0K
ICAgID4gPiBzdHJlYW1pbmcgb2YgZXZlbnQgcmVjb3Jkcy4NCiAgICA+ID4NCiAgICA+ID4gPiBD
b21wYXJlIHRvIE5FVENPTkYuICBIVFRQLzIgc3RyZWFtcyBhcmUgc2ltaWxhciB0byBTU0ggY2hh
bm5lbHMuICBBDQogICAgPiA+ID4gTkVUQ09ORiBjbGllbnQgY2FuIG9wZW4gYSBzZXBhcmF0ZSBT
U0ggY2hhbm5lbCBmb3IgZWFjaA0KICAgID4gPiA+IHN1YnNjcmlwdGlvbiwgb3IgaXQgY2FuIHVz
ZSBhIHNpbmdsZSBjaGFubmVsLiAgVXAgdG8gdGhlIGNsaWVudC4NCiAgICA+ID4NCiAgICA+ID4g
SFRUUDIgc3RyZWFtcyBoYXZlIGZhciBsZXNzIG92ZXJoZWFkLCBsb3dlciBzZXR1cCBsYXRlbmN5
LCBhbmQgbW9yZQ0KICAgID4gPiBzY2FsYWJpbGl0eSB0aGFuIHNlcGFyYXRlIFNTSCBjaGFubmVs
cy4NCiAgICA+IA0KICAgID4gUmVhbGx5PyAgQW4gU1NIIGNoYW5uZWwgaXMgc3VwZXIgY2hlYXAu
ICBXaHkgZG8geW91IHRoaW5rIHRoYXQgSFRUUC8yIHN0cmVhbXMNCiAgICA+IGhhdmUgImZhciBs
ZXNzIiBvdmVyaGVhZD8gIFRoZXJlIGNhbiBiZSAyXjMyIGNoYW5uZWxzIGluIGFuIFNTSCBzZXNz
aW9uLCBhbmQNCiAgICA+IDJeMzEgc3RyZWFtcyBpbiBhIEhUVFAvMiBzZXNzaW9uLg0KICAgID4g
DQogICAgPiAoRm9yIHJlZmVyZW5jZSwgaW4gY2FzZSBpdCB3YXNuJ3QgY2xlYXI6IFJGQyA0MjU0
LCBzZWN0aW9uIDUpDQogICAgPg0KICAgID4gPiA+ID4gU29tZW9uZSBjb3VsZCB3cml0ZSBhIHNw
ZWNpZmljYXRpb24gd2hpY2ggZ2V0cyBhcm91bmQgdGhpcyBieQ0KICAgID4gPiA+ID4gZm9yY2lu
ZyBldmVyeSBSRVNUQ09ORiB0cmFuc2FjdGlvbiBvbiBpdHMgb3duIEhUVFAyIHN0cmVhbS4gIEJ1
dA0KICAgID4gPiA+ID4gbm9ib2R5IGhhcyBwcm9wb3NlZCBzdWNoIGEgc3BlY2lmaWNhdGlvbi4g
IFBsdXMgdGhlcmUgYXJlIFFvUw0KICAgID4gPiA+ID4gc2NlbmFyaW9zIHdoZXJlIHlvdSBtaWdo
dCB3YW50IG11bHRpcGxlIHN1YnNjcmlwdGlvbnMgb24gdGhlIHNhbWUNCiAgICA+IEhUVFAyIHN0
cmVhbS4NCiAgICA+ID4gPg0KICAgID4gPiA+IEhvdyB3b3VsZCB0aGlzIHdvcms/ICBPbmNlIHlv
dSBzdGFydCBTU0Ugb24gYSBzdHJlYW0sIHRoYXQgc3RyZWFtIGlzDQogICAgPiA+ID4gImJsb2Nr
ZWQiLCByaWdodD8NCiAgICA+ID4NCiAgICA+ID4gQW5kIHBlciBhYm92ZSwgdGhpcyBpcyBhIGdv
b2QgcmVhc29uIHRvIHNlcGFyYXRlIFJFU1RDT05GIHN1YnNjcmlwdGlvbg0KICAgID4gPiBSUENz
IGZyb20gdGhlIEhUVFAyIHN0cmVhbSB1c2VkIGZvciBldmVudHMuICAoVGhlIHdheSBpdCBjb3Vs
ZCBiZSBkb25lDQogICAgPiA+IGlzIGhhdmUgbW9kaWZ5LXN1YnNjcmlwdGlvbiBhbmQgZGVsZXRl
LXN1YnNjcmlwdGlvbnMgY29tZSBpbiBvbiBhDQogICAgPiA+IGRpZmZlcmVudCBzdHJlYW0sIGlt
cGFjdGluZyB0aGUgSFRUUDIgc3RyZWFtIHdoZXJlDQogICAgPiA+IGVzdGFibGlzaC1zdWJzY3Jp
cHRpb24gc3RhcnRlZCB0aGluZ3Mgb2ZmLiAgQWdhaW4gSSBhbSBub3QNCiAgICA+ID4gcmVjb21t
ZW5kaW5nIHRoaXMgZm9yIG11bHRpcGxlIHJlYXNvbnMuKQ0KICAgID4gPg0KICAgID4gPiA+ID4g
U28gaWYNCiAgICA+ID4gPiA+IHNvbWVvbmUgd2FudGVkIHRoaXMsIHdlIHdvdWxkIHN0aWxsIG5l
ZWQgdG8gcmVmaW5lDQogICAgPiA+ID4gPiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90
aWYgcmVxdWlyZW1lbnRzIHdpdGggdGhlIGFiaWxpdHkgdG8NCiAgICA+ID4gPiA+IG1vZGlmeSBv
ciBkZWxldGUgYW4gZXhpc3Rpbmcgc3Vic2NyaXB0aW9uIG9uIGEgZGlmZmVyZW50IEhUVFAyIHN0
cmVhbS4NCiAgICA+ID4gPg0KICAgID4gPiA+IElzbid0IHRoaXMgaG93IGl0IGlzIHN1cHBvc2Vk
IHRvIHdvcms/DQogICAgPiA+DQogICAgPiA+IFllcy4gIE15IHBvaW50IHdhcyB0aGF0IG5vYm9k
eSBoYXMgcHJvcG9zZWQgcmVmaW5pbmcgdGhlIHNwZWMgdG8NCiAgICA+ID4gZm9yY2luZyBvZiBl
YWNoIFJFU1RDT05GIHRyYW5zYWN0aW9uIG9uIGRpZmZlcmVudCBIVFRQMiBzdHJlYW1zLg0KICAg
ID4gPg0KICAgID4gPiA+IFRoZSBkcmFmdCBpcyBzaWxlbnQgb24gaG93IHRvIGRlbGV0ZSBhIHN1
YnNjcmlwdGlvbiwgYW5kIGFsc28gb24gaG93DQogICAgPiA+ID4gbW9kaWZ5LXN1YnNjcmlwdGlv
biBpcyBzdXBwb3NlZCB0byB3b3JrLg0KICAgID4gPg0KICAgID4gPiBDZXJ0YWlubHkgdGhlc2Ug
Y2FuIGNvbWUgaW4gb24gYSBkaWZmZXJlbnQgSFRUUDIgc3RyZWFtLg0KICAgID4gPg0KICAgID4g
PiA+IFRoZSBkcmFmdCBpcyBhbHNvIHNpbGVudCBvbiB0aGUgbGlmZXRpbWUgb2YgdGhlIHJlc3Vs
dCBvZg0KICAgID4gPiA+ICJlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIi4NCiAgICA+ID4gPiBXaXRo
IE5FVENPTkYsIHRoZSBzdWJzY3JpcHRpb24gZW5kcyBpZiB0aGUgc2Vzc2lvbiBlbmRzLCBidXQg
aW4NCiAgICA+ID4gPiBSRVNUQ09ORiB0aGVyZSBhcmUgbm8gc2Vzc2lvbnMsIHNvIGhvdyBsb25n
IGRvZXMgdGhlIHN1YnNjcmlwdGlvbg0KICAgID4gPiA+IGxpdmUgYWZ0ZXIgaXQgaGFzIGJlZW4g
Y3JlYXRlZD8NCiAgICA+ID4NCiAgICA+ID4gVGhlcmUgYXJlIG1lY2hhbmlzbXMgZGVmaW5lZC4g
IFNlZQ0KICAgID4gPiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYsIFNlY3Rpb24g
My4xLg0KICAgID4gDQogICAgPiBUaGlzIHNlY3Rpb24gc2F5czoNCiAgICA+IA0KICAgID4gICAg
V2hlcmUgcXVpY2sNCiAgICA+ICAgIHJlY29nbml0aW9uIG9mIHRoZSBsb3NzIG9mIGEgcHVibGlz
aGVyIGlzIHJlcXVpcmVkLCBhIHN1YnNjcmliZXINCiAgICA+ICAgIFNIT1VMRCBjb25uZWN0IG92
ZXIgVExTIFtSRkM1MjQ2XSwgYW5kIHVzZSBhIFRMUyBoZWFydGJlYXQgW1JGQzY1MjBdDQogICAg
PiAgICB0byB0cmFjayBIVFRQIHNlc3Npb24gY29udGludWl0eS4gIEluIHRoZSBjYXNlIHdoZXJl
IGEgVExTIGhlYXJ0YmVhdA0KICAgID4gICAgaXMgaW5jbHVkZWQsIGl0IHNob3VsZCBiZSBzZW50
IGp1c3QgZnJvbSByZWNlaXZlciB0byBwdWJsaXNoZXIuICBMb3NzDQogICAgPiAgICBvZiB0aGUg
aGVhcnRiZWF0IE1VU1QgcmVzdWx0IGluIGFueSBzdWJzY3JpcHRpb24gcmVsYXRlZCBUQ1Agc2Vz
c2lvbnMNCiAgICA+ICAgIGJldHdlZW4gdGhvc2UgZW5kcG9pbnRzIGJlaW5nIHRvcm4gZG93bi4g
IEEgc3Vic2NyaWJlciBjYW4gdGhlbg0KICAgID4gICAgYXR0ZW1wdCB0byByZS1lc3RhYmxpc2gu
DQogICAgPiANCiAgICA+IFRoaXMgaXMgbm90IGNsZWFyIHRvIG1lLg0KICAgID4gDQogICAgPiBG
aXJzdCBpdCBzYXlzIHRoYXQgVExTIFNIT1VMRCBiZSB1c2VkLiAgQnV0IHdpdGggUkVTVENPTkYs
IFRMUyBpcyBhbHJlYWR5IGENCiAgICA+IE1VU1QuDQogICAgDQogICAgVGhlIHNlY3Rpb24gcHJl
dmlvdXNseSB3YXMgc3VwcG9ydGluZyBIVFRQMiBvbmx5IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9u
cy4gICBVcGRhdGVzIGFyZSBuZWVkZWQgZm9yIHBvaW50cyBsaWtlIHRoaXMuDQogICAgDQogICAg
PiBTZWNvbmQsIGl0IHNheXMgdGhhdCBpbiB0aGUgY2FzZSBvZiBtaXNzZWQgVExTIGhlYXJ0YmVh
dHMsICJyZWxhdGVkIFRDUCBzZXNzaW9ucyINCiAgICA+IGFyZSB0b3JuIGRvd24uICBXaGF0IGFy
ZSB0aGVzZSBzZXNzaW9ucyAocGx1cmFsKSwgYW5kIHdoYXQgZXhhY3RseSBkb2VzDQogICAgPiAi
cmVsYXRlZCIgbWVhbj8NCiAgICANCiAgICBUaGlzIHNob3VsZCBiZSBzaW5ndWxhci4gIFJlbGF0
ZWQgbWVhbnMgdHJhbnNpdGluZy4NCiAgICAgDQogICAgPiBUaGlyZCwgaXQgc2F5cyB0aGF0IGEg
c3Vic2NyaWJlciBjYW4gcmUtZXN0YWJsaXNoLiAgV2hhdCBjYW4gaXQgcmUtZXN0YWJsaXNoPyAg
UmUtDQogICAgPiBzZW5kIHRoZSBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uPyAgSnVzdCByZXNlbmQg
dGhlIFBPU1QgdG8gdGhlIHN1YnNjcmlwdGlvbiBVUkw/DQogICAgDQogICAgVGV4dCBuZWVkcyB0
byBiZSB1cGRhdGVkIHRvIHNheSAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIuIA0KICAgIA0KICAg
ID4gVGhlIGZsb3cgaXM6DQogICAgPiANCiAgICA+IA0KICAgID4gICAgIFN1YnNjcmliZXIgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFB1Ymxpc2hlcg0KICAgID4gICAgIC0tLS0t
LS0tLS0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLQ0KICAgID4g
DQogICAgPiAgICAgICAgfCBSRVNUQ09ORiBQT1NUIChSUEM6ZXN0YWJsaXNoLXN1YnNjcmlwdGlv
bikgICB8DQogICAgPiAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLT58DQogICAgPiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgSFRU
UCAyMDAgT0sgKElELFVSSSl8DQogICAgPiAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQogICAgPiAgICAgICAgfA0KICAgID4gICAgICAoKioq
KQ0KICAgID4gICAgICAgIHwgICBIVFRQIFBPU1QgKFVSSSkNCiAgICA+ICAgICAgICB8ICAgIHwt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KICAgID4gICAg
ICAgIHwgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSFRUUCAyMDAgT0t8
DQogICAgPiANCiAgICA+IA0KICAgID4gQWZ0ZXIgdGhlIHB1Ymxpc2hlciBoYXMgc2VudCBhIFVS
SSBmb3IgdGhlIHN1YnNjcmlwdGlvbiB0byB0aGUgc3Vic2NyaWJlciwgdGhlcmUNCiAgICA+IGlz
IGEgZGVsYXkgKCoqKikgdW50aWwgdGhlIHN1YnNjcmliZXIgaGFzIHNlbnQgdGhlIG5ldyBQT1NU
LiAgVGhlIHJlc291cmNlIHRoYXQNCiAgICA+IHRoZSBVUkkgcG9pbnRzIHRvIGlzIHN1YnNjcmli
ZXItc3BlY2lmaWMsIHdoaWNoIG1lYW5zIHRoYXQgdGhlIHB1Ymxpc2hlciBtYXkNCiAgICA+IGhh
dmUgY3JlYXRlZCBzb21lIGFzc29jaWF0ZWQgc3RhdGUuICBUaGlzIHN0YXRlIHdpbGwgZXZlbnR1
YWxseSBoYXZlIHRvIGJlDQogICAgPiBkZXN0cm95ZWQuICBXaGVuIGNhbiB0aGUgcHVibGlzaGVy
IHNhZmVseSBkZXN0cm95IHRoaXMgc3RhdGU/DQogICAgDQogICAgQ2FzZXMgaW5jbHVkZToNCiAg
ICAtIGRlbGV0ZS1zdWJzY3JpcHRpb24gcnBjDQogICAgLSBraWxsLXN1YnNjcmlwdGlvbiBycGMN
CiAgICAtIGxvc3Mgb2YgVExTIGhlYXJ0YmVhdA0KICAgIC0gaW5hYmlsaXR5IHRvIGRlbGl2ZXIg
c2VxdWVudGlhbCBzZXRzIG9mIG5vdGlmaWNhdGlvbiBtZXNzYWdlcw0KICAgICAgICAgIkZvciBj
b25uZWN0aW9ubGVzcyBvciBzdGF0ZWxlc3MgdHJhbnNwb3J0cyBsaWtlDQogICAgICAgICAgSFRU
UCwgYSBsYWNrIG9mIHJlY2VpcHQgYWNrbm93bGVkZ21lbnQgb2YgYSBzZXF1ZW50aWFsIHNldCBv
Zg0KICAgICAgICAgIG5vdGlmaWNhdGlvbiBtZXNzYWdlcyBhbmQvb3Iga2VlcC1hbGl2ZXMgY2Fu
IGJlIHVzZWQgdG8gdHJpZ2dlciBhDQogICAgICAgICAgdGVybWluYXRpb24gb2YgYSBkeW5hbWlj
IHN1YnNjcmlwdGlvbi4gIiAgIChwZXIgU04gMS4zKQ0KICAgIC0gIiBBIHB1Ymxpc2hlciBNQVkg
dGVybWluYXRlIGEgZHluYW1pYyBzdWJzY3JpcHRpb24gYXQgYW55IHRpbWUuIiAgIChwZXIgU04g
MS4zKQ0KICAgIA0KICAgID4gRm9yIGV4YW1wbGUsIHdoYXQgaGFwcGVucyBpZiB0aGUgbmV3IFBP
U1QgbmV2ZXIgYXJyaXZlcz8NCiAgICANCiAgICBUaGVuIGl0IHdpbGwgZmFpbCB0byBkZWxpdmVy
IGEgc2VxdWVudGlhbCBzZXQgb2Ygbm90aWZpY2F0aW9uIG1lc3NhZ2VzDQogICAgDQogICAgPiBJ
ZiB0aGUgc3Vic2NyaWJlcg0KICAgID4gbG9zZXMgaXRzIHRyYW5zcG9ydCBzZXNzaW9uLCBjYW4g
aXQgc2VuZCBhIG5ldyBQT1NUIHRvIHRoZSBzYW1lIFVSTD8gIENhbiBpdA0KICAgID4gc2VuZCBt
dWx0aXBsZSBQT1NUcyB0byB0aGUgc2FtZSBVUkw/DQogICAgDQogICAgQWdyZWUgdGhlIHRleHQg
Y2FuIGJlIGVuaGFuY2VkIHRvIGNvdmVyIHlvdXIgcG9pbnRzIGFib3ZlLiAgSSBoYWQgYmVlbiBh
c3N1bWluZyB0aGlzIHdvdWxkIG5vdCBiZSB0aGUgY2FzZS4gIEJ1dCBJIGhhdmVuJ3QgdGhvdWdo
dCBkZWVwbHkgYWJvdXQgaXQuDQogICAgIA0KICAgIEVyaWMNCiAgICANCiAgICA+ID4gYW5kDQog
ICAgPiA+IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMsIHNlY3Rp
b25zIDEuMyAmIDUuMy4NCiAgICA+IA0KICAgID4gSSBkaWRuJ3QgZmluZCB0aGUgYW5zd2VycyB0
byB0aGUgcXVlc3Rpb25zIGFib3ZlIGluIHRoZXNlIHNlY3Rpb25zLg0KICAgID4gDQogICAgPiAN
CiAgICA+IC9tYXJ0aW4NCiAgICA+IA0KICAgID4gDQogICAgPiA+DQogICAgPiA+IEVyaWMNCiAg
ICA+ID4NCiAgICA+ID4gPiBOb3RlIHRoYXQgdGhlIGFwcHJvYWNoIGluIFJGQyA4MDQwIGlzIGRv
ZXNuJ3QgaGF2ZSB0aGlzIGlzc3VlLg0KICAgID4gPiA+DQogICAgPiA+ID4NCiAgICA+ID4gPiAv
bWFydGluDQogICAgPiA+ID4NCiAgICA+ID4gPg0KICAgID4gPiA+ID4gVGhpcyBjb3VsZCBiZSBk
b25lIG9mIGNvdXJzZSwgYnV0IHNvbWVvbmUgd291bGQgbmVlZCB0byBkcml2ZSB0aGUNCiAgICA+
ID4gPiA+IGRlZmluaXRpb24uDQogICAgPiA+ID4gPg0KICAgID4gPiA+ID4gRXJpYw0KICAgID4g
PiA+ID4NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiBXb3VsZCBpdCBiZSB3cm9uZyBmb3IgYSBj
bGllbnQgdG8gbWFrZSBhbnkgYXNzdW1wdGlvbnM/ICBJIHJlYWxpemUNCiAgICA+ID4gPiA+IHRo
aXMgQVNTVU1FcyBhIHRyYW5zcG9ydCBwcm90b2NvbCwgYnV0IGNvdWxkL3dvdWxkIHRoZXJlIGJl
IGENCiAgICA+ID4gPiA+IG9uZS10aW1lLCBjYXBhYmlsaXR5IGNoZWNrIHRoZSBjbGllbnQgY291
bGQgbWFrZSB0byB0ZXN0IGZvcg0KICAgID4gPiA+ID4gYXZhaWxhYmxlIHRyYW5zcG9ydHM/DQog
ICAgPiA+ID4gPg0KICAgID4gPiA+ID4gSSByZWFsbHkgYXBwcmVjaWF0ZSB5b3VyIHRpbWUgZXhw
bGFpbmluZywgSSBoYXZlIGJlZW4gZm9sbG93aW5nDQogICAgPiA+ID4gPiB0aGUgZW1haWxzIGJl
c3QgSSBjb3VsZCBidXQgSSB0aGluayBzb21lIGJhc2ljIHRoaW5ncyBhcmUgc3RpbGwNCiAgICA+
ID4gPiA+IGVsdWRpbmcgbWUuDQogICAgPiA+ID4gPg0KICAgIA0KDQo=


From nobody Fri Sep 21 22:28:15 2018
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 8327A12D7EA; Fri, 21 Sep 2018 22:28:06 -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.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <153759408647.20246.17527055537644187185@ietfa.amsl.com>
Date: Fri, 21 Sep 2018 22:28:06 -0700
Archived-At: 
Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-push-19.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Sep 2018 05:28:07 -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 Datastore Subscription
        Authors         : Alexander Clemm
                          Eric Voit
                          Alberto Gonzalez Prieto
                          Ambika Prasad Tripathy
                          Einar Nilsen-Nygaard
                          Andy Bierman
                          Balazs Lengyel
	Filename        : draft-ietf-netconf-yang-push-19.txt
	Pages           : 57
	Date            : 2018-09-21

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.

   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-19
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-push-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 Fri Sep 21 22:30:02 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FEE130DE7; Fri, 21 Sep 2018 22:29:58 -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 uZ6JCGKKCs4o; Fri, 21 Sep 2018 22:29:56 -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 04CED12D7EA; Fri, 21 Sep 2018 22:29:55 -0700 (PDT)
Received: from LAPTOPR7T053C2 ([24.6.143.61]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LaDv6-1fN9H51ChS-00m1To;  Sat, 22 Sep 2018 07:29:53 +0200
From: "Alexander Clemm" 
To: , 
References: <153759408669.20246.13278866253821052076.idtracker@ietfa.amsl.com>
In-Reply-To: <153759408669.20246.13278866253821052076.idtracker@ietfa.amsl.com>
Date: Fri, 21 Sep 2018 22:29:51 -0700
Message-ID: <004601d45235$4a834c10$df89e430$@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: AQEZwEfFIidQd9nIic9102xMEUpcIaZw6Z5A
Content-Language: en-us
X-Provags-ID: V03:K1:5Svnnw7DJ+HyqSZGow7F+VAkxBznsyj8pbs+xkzS4DwBk5vt6mo H6uok3EfOT1jpKiQNj8YD6ll7KxNtinYzOIhv76dnSZT93OF9NoWhYHJQ+2tSjtyWBVcwSw F7YBRX/lLtO+tWVyaYTzSxOSIxaxT9RazOh1ISkWYyXk4vZ3gka/uNVES7+gqYagiN4Z8bz 9EEyGx2t61PVzGo5/V1+g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:CFWFSSmoWHs=:9vmanXMS72ACNYgGejKCra 9aR+1Ks+9eC3jgYG6t6WbxpzYVUFCOVZGVx6Df/tuIZsegaPc+XEMkgMdqsJ3uFtYbAZjz4OJ u79a+RcLSoTzZtBe9d1KimRH4fIRjADkM+vXIxu058KtYTV9eXjJew/+3+hiFySpX37Us0iPK Jcp2oigsp22B+xiSx3EGdF5UGsfff9slE3Jrhxx3oAWLFBfWNsHuqd4l8jpSZUcVu03Eyk+6P vzJxwcbys1zYpeMyK99oUoWAmV3EYgAf99E0BWzGJW/xCOmskbqbhaGfodbqCFiMSW/ahqj7/ NVSlPLuhoQkJPwqx9EHA7qiCtL3JGx2picsmVs7oJGGujKCv3oYjmn2UMnJAbVCSMIuvK/JL8 JNg1Vk7m1ziaVM7lxbmB0OlHrGCz6TRSptrAdOv0Hx2cxvbMVZs1G0jTzLcvXhiw8KRn+wi35 wurixNYPOu77dQ8XV1K0aRTL34+p+DMho13I2TRk34qu/3B3aT7CDXuM5FnTrxk6Nw+sxt/UT LGpVelnkL3Xxx5X9kUQ8T2imS+/jbrk1Zg3j5UEuZd12E5s8p2FD/2PNXpz9Qa8TY8gSv6+M2 0ms+eLmoFRTLmB4n5gHLRE0ZwHjPbxMrmMHa1Pr+f8+TecQFDO+vOb6HaFsjNAZ9F6RXIfskY BYFhTm1e02u4VnQRXG0bTbRh+SbtL+LP+hBGM0e2VRMszQl4CQw8gtQ0ioq3phikde3np7D8j iss6IzF1aVXJxgUU
Archived-At: 
Subject: [Netconf] FW: New Version Notification for draft-ietf-netconf-yang-push-19.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Sep 2018 05:29:59 -0000

Hi,

Just FYI, we just posted a new revision which has the WGLC incorporated, =
per the mail threads.  Thank you for all the valuable input!

--- Alex

-----Original Message-----
From: internet-drafts@ietf.org =20
Sent: Friday, September 21, 2018 10:28 PM
To: Alberto Gonzalez Prieto ; Andy Bierman =
; Alexander Clemm ; Balazs Lengyel =
; Alberto Prieto ; =
Ambika Tripathy ; Eric Voit ; =
Ambika Prasad Tripathy ; Einar Nilsen-Nygaard =

Subject: New Version Notification for =
draft-ietf-netconf-yang-push-19.txt


A new version of I-D, draft-ietf-netconf-yang-push-19.txt
has been successfully submitted by Alexander Clemm and posted to the =
IETF repository.

Name:		draft-ietf-netconf-yang-push
Revision:	19
Title:		YANG Datastore Subscription
Document date:	2018-09-21
Group:		netconf
Pages:		57
URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-netconf-yang-push-19.txt
Status:         =
https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/
Htmlized:       =
https://tools.ietf.org/html/draft-ietf-netconf-yang-push-19
Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push
Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-yang-push-19

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.

   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.

                                                                         =
        =20


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

The IETF Secretariat



From nobody Sat Sep 22 10:52:11 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62E4130E42 for ; Sat, 22 Sep 2018 10:52:09 -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 c0abP8MZLAZG for ; Sat, 22 Sep 2018 10:52:08 -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 17A51130E3F for ; Sat, 22 Sep 2018 10:52:08 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 4F266B818D0; Sat, 22 Sep 2018 10:52:03 -0700 (PDT)
To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, ibagdona@gmail.com, warren@kumari.net, kwatsen@juniper.net, mjethanandani@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: andy@yumaworks.com, netconf@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20180922175203.4F266B818D0@rfc-editor.org>
Date: Sat, 22 Sep 2018 10:52:03 -0700 (PDT)
Archived-At: 
Subject: [Netconf] [Editorial Errata Reported] RFC8040 (5504)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Sep 2018 17:52:10 -0000

The following errata report has been submitted for RFC8040,
"RESTCONF Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5504

--------------------------------------
Type: Editorial
Reported by: Andy Bierman 

Section: 8.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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
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 Sun Sep 23 17:07:14 2018
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 22C25124BE5; Sun, 23 Sep 2018 17:07:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari 
To: "The IESG" 
Cc: draft-ietf-netconf-nmda-netconf@ietf.org, Mahesh Jethanandani , netconf-chairs@ietf.org, mjethanandani@gmail.com, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153774762713.29234.13520591093910263393.idtracker@ietfa.amsl.com>
Date: Sun, 23 Sep 2018 17:07:07 -0700
Archived-At: 
Subject: [Netconf] Warren Kumari's No Objection on draft-ietf-netconf-nmda-netconf-06: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2018 00:07:07 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-netconf-nmda-netconf-06: 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-nmda-netconf/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'll be honest -- I was expecting this review to be long, annoying and
unpleasant. It is documenting changes to some fundamental bits, and on matters
where I always feel like I *should( have more expertise / knowledge... and so I
set aside time on a flight to be able to focus on this....

It turns out to have been a very well, clearly written and understandable
document...

I only have a *minor* suggestion:
"3.1.1.3.  Example: Retrieving an entire subtree from 

The following example shows the  version of the
    example shown in Section 7.1 of [RFC6241].
"

Seeing that this is an introductory example, I think that it would be nice to
make it clearer that this filters users subtree; it is clear once reading the
example, but knowing what it is supposed to be demonstrating before seeing it
might be nice...

I did say it was a minor comment!



From nobody Sun Sep 23 23:38:34 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB93130E2A for ; Sun, 23 Sep 2018 23:38:32 -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 uPY3IyP5I6CL for ; Sun, 23 Sep 2018 23:38:30 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 77DE1130DD8 for ; Sun, 23 Sep 2018 23:38:30 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 6E7A01AE0388; Mon, 24 Sep 2018 08:38:26 +0200 (CEST)
Date: Mon, 24 Sep 2018 08:38:25 +0200 (CEST)
Message-Id: <20180924.083825.213911774233311578.mbj@tail-f.com>
To: rfc-editor@rfc-editor.org
Cc: andy@yumaworks.com, kwatsen@juniper.net, ibagdona@gmail.com, warren@kumari.net, mjethanandani@gmail.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20180922175203.4F266B818D0@rfc-editor.org>
References: <20180922175203.4F266B818D0@rfc-editor.org>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] [Editorial Errata Reported] RFC8040 (5504)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2018 06:38:33 -0000

Hi,

This errata should be accepted; however it is for secion B.3.8, not
8.3.8.


/martin



RFC Errata System  wrote:
> The following errata report has been submitted for RFC8040,
> "RESTCONF Protocol".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5504
> 
> --------------------------------------
> Type: Editorial
> Reported by: Andy Bierman 
> 
> Section: 8.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.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> 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 Mon Sep 24 00:36:20 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902F8130DE1 for ; Mon, 24 Sep 2018 00:36:18 -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 FjDNQlFkCQeY for ; Mon, 24 Sep 2018 00:36:16 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A3FC9130DDD for ; Mon, 24 Sep 2018 00:36:16 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 8637A1AE0388; Mon, 24 Sep 2018 09:36:12 +0200 (CEST)
Date: Mon, 24 Sep 2018 09:36:12 +0200 (CEST)
Message-Id: <20180924.093612.1791958587714330227.mbj@tail-f.com>
To: alexander.clemm@huawei.com
Cc: kwatsen@juniper.net, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com>
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2018 07:36:19 -0000

Alexander Clemm  wrote:
> I am about to post -19 but I do not like the suggested change to go
> from timeticks to seconds.
> 
> Seconds is a fairly coarse unit.  I would not be surprised to see
> requirements for finer granularity in the future, even more so in
> virtualization and controller scenarios in which we start to see YANG
> being used.  There are applications that use single second periods
> today so I think it is entirely conceivable to see need for subsecond
> support down the line.  To allow periods only in units of seconds
> would seem to unnecessarily hobble ourselves.  Keeping things to
> timeticks is more futureproof IMHO.

Ok.


/martin



> 
> --- Alex
> 
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > Sent: Thursday, September 20, 2018 12:45 AM
> > To: kwatsen@juniper.net
> > Cc: Alexander Clemm ; netconf@ietf.org
> > Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
> > 
> > Hi,
> > 
> > Thanks Kent, I missed this one.
> > 
> > Authors, I suggest we change the type for "yp:period" from
> > "yang:timeticks" to
> > "uint32" with units "seconds".
> > 
> > See the thread starting at
> > https://mailarchive.ietf.org/arch/msg/netconf/SU1VnBV1Ea5Ae3QzPn_joyyRnZ
> > o
> > 
> > 
> > /martin
> > 
> > 
> > Kent Watsen  wrote:
> > > Hi Martin,
> > >
> > > I'm surprised to see that your review doesn't suggest changing
> > > "yp:period" from yang:timeticks to seconds.
> > >
> > > You had previously made this suggestion in another thread, but it's
> > > still timeticks in -18.
> > >
> > > Kent // all hat
> > >
> > >
> > >
> > >
> > >
> 


From nobody Mon Sep 24 00:36:43 2018
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 A67BB130E77; Mon, 24 Sep 2018 00:36:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov 
To: "The IESG" 
Cc: draft-ietf-netconf-nmda-restconf@ietf.org, Mahesh Jethanandani , netconf-chairs@ietf.org, mjethanandani@gmail.com, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153777458966.28052.8513670008966367067.idtracker@ietfa.amsl.com>
Date: Mon, 24 Sep 2018 00:36:29 -0700
Archived-At: 
Subject: [Netconf] Alexey Melnikov's No Objection on draft-ietf-netconf-nmda-restconf-04: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2018 07:36:36 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-netconf-nmda-restconf-04: 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-nmda-restconf/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In Section 3.2.1:

   Servers are not required to support all values in the "with-defaults"
   query parameter on the operational state datastore.  If a request is
   made using a value that is not supported, then the error handling
   behavior is as described in ([RFC8040], Section 4.8.9).

This seems to be pointless, considering that the server already advertises
support for the "with-defaults" capability. Can you maybe elaborate on which
values are hard to implement (and thus likely not to be implemented)?



From nobody Mon Sep 24 00:38:59 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B629A130E21 for ; Mon, 24 Sep 2018 00:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1YpRLEjpiiLf for ; Mon, 24 Sep 2018 00:38:56 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 21B5B130DDD for ; Mon, 24 Sep 2018 00:38:56 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 21F121AE0446; Mon, 24 Sep 2018 09:38:55 +0200 (CEST)
Date: Mon, 24 Sep 2018 09:38:54 +0200 (CEST)
Message-Id: <20180924.093854.961961481600027709.mbj@tail-f.com>
To: ludwig@clemm.org
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <004601d45235$4a834c10$df89e430$@clemm.org>
References: <153759408669.20246.13278866253821052076.idtracker@ietfa.amsl.com> <004601d45235$4a834c10$df89e430$@clemm.org>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] FW: New Version Notification for draft-ietf-netconf-yang-push-19.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2018 07:38:59 -0000

Hi,

Thanks for this update.  I checked the new version with my comments.
Technically, all my comments are addressed, but there are some mostly
editorial issues left:


o  In the abstract, the same paragraph occurs twice.


o  Figure 2:

  OLD:

     

  NEW:

       


o  Figure 6:

  OLD:

          |  +--ro ypatch:yang-patch
          |     +--ro patch-id        string
          |     +--ro ypatch:comment?    string
          |     +--ro ypatch:edit* [edit-id]
          |        +--ro ypatch:edit-id      string
          |        +--ro ypatch:operation    enumeration
          |        +--ro ypatch:target       target-resource-offset
          |        +--ro ypatch:point?       target-resource-offset
          |        +--ro ypatch:where?       enumeration
          |        +--ro ypatch:value?


  NEW:

          |  +--ro yang-patch
          |     +--ro patch-id        string
          |     +--ro comment?        string
          |     +--ro edit* [edit-id]
          |        +--ro edit-id      string
          |        +--ro operation    enumeration
          |        +--ro target       target-resource-offset
          |        +--ro point?       target-resource-offset
          |        +--ro where?       enumeration
          |        +--ro value?


o  Section 3.1

  OLD

         +  No sync on start: defines whether or not a complete push-

  NEWL

         +  Sync on start: defines whether or not a complete push-



o  Section 3.9

  The text says:

   In addition, a publisher MAY choose
   to terminate a dynamic subscription or suspend a configured receiver
   when the authorization privileges of a receiver change, or the access
   controls for subscribed objects change.  In that case, the publisher
   SHOULD include the error identity "unchanging-selection" as reason
   when sending the "subscription-terminated" notification.

 The first sentence says that a publisher can (i) terminate or (ii)
 suspend.  The second sentence details what to do for case (i), but
 not case (ii).

 In my original comment on this issue in my WGLC review for -17 I
 suggested:

   Maybe you meant that the error identity "unchanging-selection"
   SHOULD be sent in an "subscription-terminated" notification or
   "subscription-suspended" notification, respectively.

   If so, the "unchanging-selection" identity should probably also
   derive from "sn:subscription-suspended-reason".


o  Section 3.11.1

  s/the the/the/



o  Section 4.4.1

  In my previous review, I asked you to remove the error-app-tag, but
  this was wrong.  See
  https://mailarchive.ietf.org/arch/msg/netconf/cDeV6YFfVvCMxgHTZdeFqas04b8.

  So, please put back the text about error-app-tag, so that YP aligns
  with SN.

  (Ditto for 4.4.2)


o  Section 5

  The YANG module is not consistently indented.  Before sending this
  to the RFC editor, I suggest you run the module through pyang -f
  yang --keep-comments.  Also, I suggest you run the result through
  pyang --max-line-length 69.  This simplifies the job of the RFC
  editor.


o  General

  I think you might have changed "identifier" to "id" a bit
  aggressively in the document.   For example you changed:

      leaf filter-id {
        type string;
        description
          "An identifier to differentiate between selection filters.";


  to

      leaf filter-id {
        type string;
        description
          "An id to differentiate between selection filters.";


 There are a few of these.




/martin


"Alexander Clemm"  wrote:
> Hi,
> 
> Just FYI, we just posted a new revision which has the WGLC
> incorporated, per the mail threads.  Thank you for all the valuable
> input!
> 
> --- Alex
> 
> -----Original Message-----
> From: internet-drafts@ietf.org  
> Sent: Friday, September 21, 2018 10:28 PM
> To: Alberto Gonzalez Prieto ; Andy Bierman
> ; Alexander Clemm ; Balazs
> Lengyel ; Alberto Prieto
> ; Ambika Tripathy ; Eric
> Voit ; Ambika Prasad Tripathy ;
> Einar Nilsen-Nygaard 
> Subject: New Version Notification for
> draft-ietf-netconf-yang-push-19.txt
> 
> 
> A new version of I-D, draft-ietf-netconf-yang-push-19.txt
> has been successfully submitted by Alexander Clemm and posted to the
> IETF repository.
> 
> Name:		draft-ietf-netconf-yang-push
> Revision:	19
> Title:		YANG Datastore Subscription
> Document date:	2018-09-21
> Group:		netconf
> Pages:		57
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-netconf-yang-push-19.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/
> Htmlized: https://tools.ietf.org/html/draft-ietf-netconf-yang-push-19
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-push-19
> 
> 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.
> 
>    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.
> 
>                                                                                   
> 
> 
> 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.
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 


From nobody Mon Sep 24 08:30:43 2018
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 6399B130EA7; Mon, 24 Sep 2018 08:30:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Carlos Pignataro 
To: 
Cc: ietf@ietf.org, draft-ietf-netconf-nmda-netconf.all@ietf.org, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153780302935.28098.7130277650324518153@ietfa.amsl.com>
Date: Mon, 24 Sep 2018 08:30:29 -0700
Archived-At: 
Subject: [Netconf] Opsdir telechat review of draft-ietf-netconf-nmda-netconf-06
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2018 15:30:30 -0000

Reviewer: Carlos Pignataro
Review result: Ready

I reviewed this document on behalf of the opsdir, and believe is Ready.


From nobody Mon Sep 24 11:16:17 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D901130F53 for ; Mon, 24 Sep 2018 11:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham 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 sKfcsvHa3jtL for ; Mon, 24 Sep 2018 11:16:12 -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 87718130EF7 for ; Mon, 24 Sep 2018 11:16:12 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8OIE24I010950; Mon, 24 Sep 2018 11:15:59 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=LSQNrOHyOWBQuC8+0jnk5CmKPYVXHrj8IjJxituAwu8=; b=XQn6w9aKfomuHI2gHUs7f+qA8EAAYJN4eegh8Bp6UxeQQMkI9lpo1tiTcgFhldFh5vKU BJzT7C9C0p3kYKIhvzO/008tQp1gvpKyTUkICA+RagD/MwrdN2ZHB1elt1vKwnmFS33F fTlCVgRZfP8MnY3bo4xgAZHxJ3NmMZhp2FbNJFLztB8Ga2+oPqApqQM6EgH3LBiIfAzf CWrErYHDqjiPxyLyMhd/UNgUOYqU1bedRLfUsdiQBG1Sfji8xeMl5USyZE7tRNzFmEiA bdFB2BR//MAN7AiAfFJJmU11Yzl/n+DZuFJcoXj00yT1piwoOII/X7jhUr8GUIFh2bMu Zg== 
Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp0052.outbound.protection.outlook.com [216.32.181.52]) by mx0b-00273201.pphosted.com with ESMTP id 2mpxsg0uk6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 24 Sep 2018 11:15:58 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4041.namprd05.prod.outlook.com (20.176.71.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.14; Mon, 24 Sep 2018 18:15:56 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%3]) with mapi id 15.20.1185.014; Mon, 24 Sep 2018 18:15:56 +0000
From: Kent Watsen 
To: Martin Bjorklund , "alexander.clemm@huawei.com" 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImouJGUP0t9tESR9VzM68tuEKTUcIIAgABzP4CAARMGAIAA0q0AgADJvACAIJtvAIAA1BAAgAC6LgCABYyYAIAAb66A
Date: Mon, 24 Sep 2018 18:15:56 +0000
Message-ID: 
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>
In-Reply-To: <20180924.093612.1791958587714330227.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4041; 6:9KHGm3CGknOtmo/a7AshFIAm3FHV+PPkYP45LbuTvORMDmRB/+HZeuP/Cm5BjuGfjCfViYClr71tY9GYv0A3WmGfgLINofH/RrHXPMpF1amEP+TI7H5Z88ZdZ/NDmcEWh1s/DXCoPMGJL6VmdcVwR0gXcfvh9I5pwSwOhzXl8LDsq9ko4TrszXMR7gPLTdCTVFW8cdnGhICejGG7oU1FS3hy5k4Q98dgYdig10Dbc/s7udJeihiRbUeJnf5v/EqlUr+U10/OUFfFYN6NV/lRytdX937fraUtFaAf7XVBLXjLqA/c/MrujNdva1SvZSW7aVo2ISROHzF2xxgYB/1y1QqsDIrYE14+GQAlca8Yy8CAHD55m81la7B5w3aKADMmj2Dh2C6u+RM/Z9C/8l6ozBF/ZqXfWflj4xvY1bKRiUaDoa2zXp4Xyk8w8dMfbzNBzE4kgPm0B8KgUE67irzI4Q==; 5:WEZriq/J4W+WyOQRUiQNyMkihUGFB3PHldJF1FYw+Uuf4iSYltJatOsYrHph3CN3/XthCxd9dkBJmOfE/BXoX8Jc0j2hlbizyL15NCyLxZH5TGrKfED7ebTUtRReJpEHQ5scGWfoHk/01T3aTl8UifPWHCjeX8IwgMpkTDQmU/k=; 7:5solQB7mxuxGcJYMgmr2UKN4UL0gUQA3R9TcFeYSTbt0diJaO6bwfju/b9oCbsuX2xZ8NgyAX0fIVDd2TJCBn0p+SFAMpzT+WB9is66Ok8DKi4fKV/PqbbKnHifvggpM0lF7Lnr0hiH5mO9EIgLBhzQhvx9gNaj7h1zSTKm42VmM4im0/Qyu9k19GNbu7uY5/Wtj1w86giHuErKVH6olFWPlaGOm9nu4AshwH98BmgL13uyGe1/dpHc+m7YEvFk2
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: f0523b8c-7af3-4acb-ac2d-08d62249c5d0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4041; 
x-ms-traffictypediagnostic: DM6PR05MB4041:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(278428928389397)(50582790962513);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149066)(150027)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(201708071742011)(7699051); SRVR:DM6PR05MB4041; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4041; 
x-forefront-prvs: 0805EC9467
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(376002)(396003)(366004)(346002)(199004)(189003)(51444003)(6246003)(36756003)(82746002)(305945005)(256004)(7736002)(58126008)(6116002)(4326008)(3846002)(93886005)(110136005)(11346002)(476003)(2616005)(14454004)(486006)(6506007)(446003)(26005)(6486002)(186003)(6512007)(86362001)(76176011)(229853002)(33656002)(5660300001)(2900100001)(53936002)(99286004)(68736007)(102836004)(6436002)(105586002)(478600001)(8676002)(81166006)(2906002)(66066001)(2501003)(5250100002)(316002)(25786009)(71200400001)(8936002)(83716004)(97736004)(81156014)(106356001)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4041; H:DM6PR05MB4665.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-microsoft-antispam-message-info: OLtHhRVVPF8g4g4IQ9Wld7Hc7TrqguYup1aTprQNBeklOkFKytcyyEvLlmn+Rzg+5Trn//5lTX1KxsuG2aZho32SAJkLNgz6ZdE0TbwDw6c+IMa+bzGpglOvw/mX711wYei/I0DrRTbgamdRvYzLFCZjRGrrIV7IIvGPlUWG/S0JNtjNGNJ5fHS9xpTcQUd3Xt+j5+DElRPbKWyvtxn/sI4skyV3zsEpw/aj+M+uq4aeaYDyf1X4mDkNCsuBgtc13daBuDrZyRgTb1Ldh3MmDiddrx9gsDNgcv6hi3N4c4ZOpqPmkNQOyWkP6SzeIhoBMWiF+sXAVsTQ9pHDKQfyaUJAieIdv6LJqIX999kZFsE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <826CB44D0A96184C81C576E4A89F5F0C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: f0523b8c-7af3-4acb-ac2d-08d62249c5d0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2018 18:15:56.5154 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4041
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-24_11:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809240174
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2018 18:16:15 -0000

DQoNCj5BbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPiB3cm90ZToN
Cj4+IEkgYW0gYWJvdXQgdG8gcG9zdCAtMTkgYnV0IEkgZG8gbm90IGxpa2UgdGhlIHN1Z2dlc3Rl
ZCBjaGFuZ2UgdG8gZ28NCj4+IGZyb20gdGltZXRpY2tzIHRvIHNlY29uZHMuDQo+PiANCj4+IFNl
Y29uZHMgaXMgYSBmYWlybHkgY29hcnNlIHVuaXQuICBJIHdvdWxkIG5vdCBiZSBzdXJwcmlzZWQg
dG8gc2VlDQo+PiByZXF1aXJlbWVudHMgZm9yIGZpbmVyIGdyYW51bGFyaXR5IGluIHRoZSBmdXR1
cmUsIGV2ZW4gbW9yZSBzbyBpbg0KPj4gdmlydHVhbGl6YXRpb24gYW5kIGNvbnRyb2xsZXIgc2Nl
bmFyaW9zIGluIHdoaWNoIHdlIHN0YXJ0IHRvIHNlZSBZQU5HDQo+PiBiZWluZyB1c2VkLiAgVGhl
cmUgYXJlIGFwcGxpY2F0aW9ucyB0aGF0IHVzZSBzaW5nbGUgc2Vjb25kIHBlcmlvZHMNCj4+IHRv
ZGF5IHNvIEkgdGhpbmsgaXQgaXMgZW50aXJlbHkgY29uY2VpdmFibGUgdG8gc2VlIG5lZWQgZm9y
IHN1YnNlY29uZA0KPj4gc3VwcG9ydCBkb3duIHRoZSBsaW5lLiAgVG8gYWxsb3cgcGVyaW9kcyBv
bmx5IGluIHVuaXRzIG9mIHNlY29uZHMNCj4+IHdvdWxkIHNlZW0gdG8gdW5uZWNlc3NhcmlseSBo
b2JibGUgb3Vyc2VsdmVzLiAgS2VlcGluZyB0aGluZ3MgdG8NCj4+IHRpbWV0aWNrcyBpcyBtb3Jl
IGZ1dHVyZXByb29mIElNSE8uDQo+DQo+IE9rLg0KDQpJIGFncmVlIHRoYXQgc2Vjb25kcyBpcyB0
b28gY291cnNlLiBIdW5kcmVkdGhzIG9mIGEgc2Vjb25kIGlzIG1heWJlIHRvbw0KZmluZSwgYnV0
IEkgd29uJ3QgY29tcGxhaW4uICBUaGF0IHNhaWQsIEkgdGhpbmsgdGhhdCBpdCBtaWdodCBiZSBh
bg0KdW5jb21tb24gc2NlbmFyaW8gYW5kIHRoYXQgaGF2aW5nIGh1bmRyZWR0aHMgb2YgYSBzZWNv
bmQgd2lsbCBsaWtlbHkNCnJlc3VsdCBpbiB2ZXJ5IGxhcmdlIG51bWJlcnMuDQoNCkZXSVcsIHlh
bmc6dGltZXRpY2tzIGRvZXNuJ3Qgc2VlbSBhcyBpbnR1aXRpdmUgYXMgInVuaXRzIiAtIGZvciBl
eGFtcGxlOg0KDQogICAgICAgICAgbGVhZiBwZXJpb2Qgew0KLSAgICAgICAgICAgdHlwZSB5YW5n
OnRpbWV0aWNrczsNCisgICAgICAgICAgIHR5cGUgdWludDE2Ow0KKyAgICAgICAgICAgdW5pdHMg
Ikh1bmRyZWR0aHMgb2YgYSBzZWNvbmQiOw0KICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7DQog
ICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAiRHVyYXRpb24gb2YgdGltZSB3
aGljaCBzaG91bGQgb2NjdXIgYmV0d2VlbiBwZXJpb2RpYw0KICAgICAgICAgICAgICAgcHVzaCB1
cGRhdGVzLiI7DQogICAgICAgICAgfQ0KDQpBdCBsZWFzdCBJIGtub3cgd2hhdCB0aGlzIG1lYW5z
IHJpZ2h0IGF3YXkuICBJIHdhcyBob3BpbmcgdG8gZmluZCBhbiBleGFtcGxlDQppbiAtMTkgaWxs
dXN0cmF0aW5nIGl0cyB1c2UsIGJ1dCBpdCdzIG5vbmUgaXMgcHJlc2VudC4gIA0KDQpCVFcsIEkg
bm90ZSB0aGF0IFJGQyA2OTkxIHNheXM6DQoNCiAgICAgICAgIFdoZW4gYSBzY2hlbWENCiAgICAg
ICAgIG5vZGUgaXMgZGVmaW5lZCB0aGF0IHVzZXMgdGhpcyB0eXBlLCB0aGUgZGVzY3JpcHRpb24g
b2YNCiAgICAgICAgIHRoZSBzY2hlbWEgbm9kZSBpZGVudGlmaWVzIGJvdGggb2YgdGhlIHJlZmVy
ZW5jZSBlcG9jaHMuDQoNCldoaWNoIEkgZG9uJ3Qgc2VlIGluIC0xOS4NCg0KV291bGQgaXQgbWFr
ZSBzZW5zZSB0byB1c2UgYSAyLXR1cGxlPyAgU29tZXRoaW5nIGxpa2U6DQoNCiAgICAgICAgICBs
ZWFmIHBlcmlvZCB7DQogICAgICAgICAgICB0eXBlIHVpbnQxNjsNCiAgICAgICAgICAgIG1hbmRh
dG9yeSB0cnVlOw0KICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgIkR1cmF0
aW9uIG9mIHRpbWUgd2hpY2ggc2hvdWxkIG9jY3VyIGJldHdlZW4gcGVyaW9kaWMNCiAgICAgICAg
ICAgICAgIHB1c2ggdXBkYXRlcy4iOw0KICAgICAgICAgIH0NCiAgICAgICAgICBsZWFmIHBlcmlv
ZC11bml0cyB7DQogICAgICAgICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgICAgICAgICAg
ZW51bSBodW5kcmVkdGhzOw0KICAgICAgICAgICAgICBlbnVtIHRlbnRoczsNCiAgICAgICAgICAg
ICAgZW51bSBzZWNvbmRzOw0KICAgICAgICAgICAgICBlbnVtIG1pbnV0ZXM7DQogICAgICAgICAg
ICAgIGVudW0gaG91cnM7DQogICAgICAgICAgICB9DQogICAgICAgICAgICBtYW5kYXRvcnkgdHJ1
ZTsNCiAgICAgICAgICB9DQoNCg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0K


From nobody Mon Sep 24 11:44:52 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEC7130EF7 for ; Mon, 24 Sep 2018 11:44:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-0.01] 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 Mc0wJuapSlpj for ; Mon, 24 Sep 2018 11:44:48 -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 70FE2130E8B for ; Mon, 24 Sep 2018 11:44:47 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id y71-v6so2787765lje.9 for ; Mon, 24 Sep 2018 11:44:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qorlpmX0cWQClTyvZqOT+7eHu42ojNcYCRZa/r1J9r0=; b=ujO2rLavofsKrNLUF08Ca7GN7fPP6cn3wLkiAKm7iJcYhglMs+eNrt9r78UJt7ubu7 xI3PQtEFHOZaJv6YoNF3wtXr58Gg82b7c5ohXZhtkGdruxRjSSIxX8TgPj6iIOucEh5E FGV2Cdk2fK6x+FVN8wGATMt+2peTHvnhRCtTK64u3QqMT3zyrvZvb7dr4Gwp0zFR64QK rwRVAaSRYlJPv366k5hqfo1nRMCOx6glLoDmON828TlRrZnIQWpnWjVbcSUrwAFB/vMD AMVEskDnM4JLSvvo+V4q8zmCr4KRwzM2pQD1yJl0y4t75XhJolnTKaskpF/PqGdvkC5a XDmA==
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=qorlpmX0cWQClTyvZqOT+7eHu42ojNcYCRZa/r1J9r0=; b=PfLmtkJznVQzi2JWwObqS8oDuHcjYWYF7gXYimtxVue1vnfDbItr/iKqjnFS+5Fq5J l1h4jyGkNlcd2aMy/KWjgEF2Y/FmikN5uliEP0CLJr4nn+NqsC1uECc5WkZy/+bcfWYq l8B7xebYTtWL94kuOBDdiZN/lqmFX7swu6P18RrQGGp9e9Uugb4m1wN43HASLfB2qatr cOjsB5LY45doZMlaapCJLufgql/8e+pcUM5we5ydWpBLGNTQ/B3fnQvr22wr8jmDxMqu gSdzHLoExHNdKrpk9W/YMfwE/mwWrY+qkOJxG5uW9aC9o80u6Alc6eI7OPuHiLpT4V5J ZglA==
X-Gm-Message-State: ABuFfohlEzGgHgtv1NNCHTAI0RVO6Pcg0POfZizaGHDfLPRlweJJ/grn FjTX4e+k+G2Dg2DIMJhpaacpHZF9K3ODDZSktJuqqfg5
X-Google-Smtp-Source: ACcGV60ALt87A1dFjzraO/MX6M/t/I0T8qEhBWtlWZy6uibFF8HLYp0137QMB2GjQ99c9VsoNQNofirFjX2K957k9C8=
X-Received: by 2002:a2e:4401:: with SMTP id r1-v6mr89892lja.21.1537814685325;  Mon, 24 Sep 2018 11:44:45 -0700 (PDT)
MIME-Version: 1.0
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com> 
In-Reply-To: 
From: Andy Bierman 
Date: Mon, 24 Sep 2018 11:44:33 -0700
Message-ID: 
To: Kent Watsen 
Cc: Martin Bjorklund , Alexander Clemm , Netconf 
Content-Type: multipart/alternative; boundary="0000000000000cb1e20576a26254"
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2018 18:44:51 -0000

--0000000000000cb1e20576a26254
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 24, 2018 at 11:16 AM Kent Watsen  wrote:

>
>
> >Alexander Clemm  wrote:
> >> I am about to post -19 but I do not like the suggested change to go
> >> from timeticks to seconds.
> >>
> >> Seconds is a fairly coarse unit.  I would not be surprised to see
> >> requirements for finer granularity in the future, even more so in
> >> virtualization and controller scenarios in which we start to see YANG
> >> being used.  There are applications that use single second periods
> >> today so I think it is entirely conceivable to see need for subsecond
> >> support down the line.  To allow periods only in units of seconds
> >> would seem to unnecessarily hobble ourselves.  Keeping things to
> >> timeticks is more futureproof IMHO.
> >
> > Ok.
>
> I agree that seconds is too course. Hundredths of a second is maybe too
> fine, but I won't complain.  That said, I think that it might be an
> uncommon scenario and that having hundredths of a second will likely
> result in very large numbers.
>
>
IMO the current definition is sufficient and further delays in this work
are not justified.

Andy


> FWIW, yang:timeticks doesn't seem as intuitive as "units" - for example:
>
>           leaf period {
> -           type yang:timeticks;
> +           type uint16;
> +           units "Hundredths of a second";
>             mandatory true;
>             description
>               "Duration of time which should occur between periodic
>                push updates.";
>           }
>
> At least I know what this means right away.  I was hoping to find an
> example
> in -19 illustrating its use, but it's none is present.
>
> BTW, I note that RFC 6991 says:
>
>          When a schema
>          node is defined that uses this type, the description of
>          the schema node identifies both of the reference epochs.
>
> Which I don't see in -19.
>
> Would it make sense to use a 2-tuple?  Something like:
>
>           leaf period {
>             type uint16;
>             mandatory true;
>             description
>               "Duration of time which should occur between periodic
>                push updates.";
>           }
>           leaf period-units {
>             type enumeration {
>               enum hundredths;
>               enum tenths;
>               enum seconds;
>               enum minutes;
>               enum hours;
>             }
>             mandatory true;
>           }
>
>
>
> Kent // contributor
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--0000000000000cb1e20576a26254
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon=
, Sep 24, 2018 at 11:16 AM Kent Watsen <kwatsen@juniper.net> wrote:




>Alexander Clemm <alexander.clemm@huawei.com> wrote:

>> I am about to post -19 but I do not like the suggested change to g=
o

>> from timeticks to seconds.

>> 

>> Seconds is a fairly coarse unit.=C2=A0 I would not be surprised to=
 see

>> requirements for finer granularity in the future, even more so in<=
br>
>> virtualization and controller scenarios in which we start to see Y=
ANG

>> being used.=C2=A0 There are applications that use single second pe=
riods

>> today so I think it is entirely conceivable to see need for subsec=
ond

>> support down the line.=C2=A0 To allow periods only in units of sec=
onds

>> would seem to unnecessarily hobble ourselves.=C2=A0 Keeping things=
 to

>> timeticks is more futureproof IMHO.

>

> Ok.



I agree that seconds is too course. Hundredths of a second is maybe too

fine, but I won't complain.=C2=A0 That said, I think that it might be a=
n

uncommon scenario and that having hundredths of a second will likely

result in very large numbers.



IMO the current definition is sufficie=
nt and further delays in this work are not justified.

<=
div>Andy
=C2=A0

FWIW, yang:timeticks doesn't seem as intuitive as "units" - f=
or example:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf period {

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type yang:timeticks;

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint16;

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0units "Hundredths of a secon=
d";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Duration of time whi=
ch should occur between periodic

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0push updates.";=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }



At least I know what this means right away.=C2=A0 I was hoping to find an e=
xample

in -19 illustrating its use, but it's none is present.=C2=A0 



BTW, I note that RFC 6991 says:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When a schema

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0node is defined that uses this type, the =
description of

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the schema node identifies both of the re=
ference epochs.



Which I don't see in -19.



Would it make sense to use a 2-tuple?=C2=A0 Something like:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf period {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint16;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Duration of time whi=
ch should occur between periodic

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0push updates.";=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf period-units {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumeration {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum hundredths;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum tenths;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum seconds;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum minutes;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum hours;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }







Kent // contributor





_______________________________________________

Netconf mailing list

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




--0000000000000cb1e20576a26254--


From nobody Mon Sep 24 12:01:43 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE0013121A for ; Mon, 24 Sep 2018 12:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 lLgcHejnhFmO for ; Mon, 24 Sep 2018 12:01:32 -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 8E8CD13124B for ; Mon, 24 Sep 2018 12:01:04 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 236A2E2C32891; Mon, 24 Sep 2018 20:01:01 +0100 (IST)
Received: from LHREML523-MBX.china.huawei.com ([169.254.7.228]) by lhreml706-cah.china.huawei.com ([10.201.108.47]) with mapi id 14.03.0399.000;  Mon, 24 Sep 2018 20:00:55 +0100
From: "Yutianpeng (Tim)" 
To: Kent Watsen , Martin Bjorklund , Alexander Clemm 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImzU9I4weZMB0iH1L0LVTTudKTT9lwAgADcoYCAARMGAIAA0q0AgADJvACAIN5/gIAAkQAAgAC6LgCABYyYAIAAsr4AgAAYUNA=
Date: Mon, 24 Sep 2018 19:00:56 +0000
Message-ID: <35FF0D51C8DAB54B95B0426331F984FF5205D540@lhreml523-mbx.china.huawei.com>
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.203.126.98]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2018 19:01:41 -0000

Personally I don't think we need to introduce complexity on this. I prefer =
use standard timeticks which also keep flexibility.
For the functionality mentioned with seconds, hours, etc, it is very simple=
 with any of the program language nowadays.

Assume we use java and the value we get from yang-push is (yang_timestamp)
Then we can have a code sample as below:
//
long yang_timestamp =3D 100000000;
Timestamp time =3D new Timestamp(yang_timestamp);
System.out.println( (time.getHours()) );
System.out.println( (time.getMinutes()) );
//

These logic should be implemented by the program language itself,  not usin=
g none-standard yang data types.
And it is not difficult at all as there are implementations for all data ty=
pes supported.
Hope it helps.

Thanks,
Tim

-----Original Message-----
From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: 24 September 2018 19:16
To: Martin Bjorklund ; Alexander Clemm 
Cc: netconf@ietf.org
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17



>Alexander Clemm  wrote:
>> I am about to post -19 but I do not like the suggested change to go=20
>> from timeticks to seconds.
>>=20
>> Seconds is a fairly coarse unit.  I would not be surprised to see=20
>> requirements for finer granularity in the future, even more so in=20
>> virtualization and controller scenarios in which we start to see YANG=20
>> being used.  There are applications that use single second periods=20
>> today so I think it is entirely conceivable to see need for subsecond=20
>> support down the line.  To allow periods only in units of seconds=20
>> would seem to unnecessarily hobble ourselves.  Keeping things to=20
>> timeticks is more futureproof IMHO.
>
> Ok.

I agree that seconds is too course. Hundredths of a second is maybe too fin=
e, but I won't complain.  That said, I think that it might be an uncommon s=
cenario and that having hundredths of a second will likely result in very l=
arge numbers.

FWIW, yang:timeticks doesn't seem as intuitive as "units" - for example:

          leaf period {
-           type yang:timeticks;
+           type uint16;
+           units "Hundredths of a second";
            mandatory true;
            description
              "Duration of time which should occur between periodic
               push updates.";
          }

At least I know what this means right away.  I was hoping to find an exampl=
e in -19 illustrating its use, but it's none is present. =20

BTW, I note that RFC 6991 says:

         When a schema
         node is defined that uses this type, the description of
         the schema node identifies both of the reference epochs.

Which I don't see in -19.

Would it make sense to use a 2-tuple?  Something like:

          leaf period {
            type uint16;
            mandatory true;
            description
              "Duration of time which should occur between periodic
               push updates.";
          }
          leaf period-units {
            type enumeration {
              enum hundredths;
              enum tenths;
              enum seconds;
              enum minutes;
              enum hours;
            }
            mandatory true;
          }



Kent // contributor


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


From nobody Mon Sep 24 15:01:20 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A583B131127 for ; Mon, 24 Sep 2018 15:01:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 BtPuL69fZsbh for ; Mon, 24 Sep 2018 15:01:00 -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 C1F6D130E60 for ; Mon, 24 Sep 2018 15:00:59 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6001918EF82AB for ; Mon, 24 Sep 2018 23:00:55 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 24 Sep 2018 23:00:56 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.47]) by SJCEML701-CHM.china.huawei.com ([169.254.3.87]) with mapi id 14.03.0415.000; Mon, 24 Sep 2018 15:00:50 -0700
From: Alexander Clemm 
To: Mahesh Jethanandani , Netconf 
Thread-Topic: [Netconf] IPR poll for draft-lengyel-netconf-notification-capabilities
Thread-Index: AQHULte1XBJGH5MBS0Kx7yCRNDm8VaUARjZw
Date: Mon, 24 Sep 2018 22:00:49 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB69B5D@sjceml521-mbx.china.huawei.com>
References: <730F9BDA-5A24-4F16-8FAC-250459E0418C@gmail.com>
In-Reply-To: <730F9BDA-5A24-4F16-8FAC-250459E0418C@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.35.92]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] IPR poll for draft-lengyel-netconf-notification-capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2018 22:01:03 -0000

Hi,

I am not aware of IPR related to this draft.

--- Alex

> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh
> Jethanandani
> Sent: Tuesday, August 07, 2018 10:22 PM
> To: Netconf 
> Subject: [Netconf] IPR poll for draft-lengyel-netconf-notification-capabi=
lities
>=20
> This mail starts the IPR poll for draft-lengyel-netconf-notification-capa=
bilities.
>=20
> Are you aware of any IPR that applies to this draft? If so, has this IPR =
been
> disclosed in compliance with IETF IPR rules? Note, you do not have to be =
an
> author or a contributor to make everyone aware of an IPR. See RFC 3669, 3=
979,
> 4879 and 5378 for details.
>=20
> If you are listed as an author on the document, or as a contributor, plea=
se
> respond to this e-mail, indicating whether or not you are aware of any re=
levant
> IPRs. The response needs to be send to the NETCONF mailing list. The docu=
ment
> will not advance to the next stage until a response has been received fro=
m all
> the authors and any contributors.
>=20
> Thanks.
>=20
> Mahesh & Kent.
> Mahesh Jethanandani
> mjethanandani@gmail.com
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Mon Sep 24 15:22:46 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BCC131173 for ; Mon, 24 Sep 2018 15:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaiyfvZVD8Mq for ; Mon, 24 Sep 2018 15:22:36 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 D9AD1131222 for ; Mon, 24 Sep 2018 15:22:35 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id g2-v6so1935828pgu.11 for ; Mon, 24 Sep 2018 15:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:date:references:to:in-reply-to:message-id;  bh=vmlYRKl2fFXUNzCE53UEr6pVHNqEnu1r4py/MAtobeM=; b=rGdTWu5Ew/LgTF9mWdaLlzbMriHTgpiYR+mtj9NnKAQKuuNj82VvJ+JEJrHy1wD8cL QPOkxm/lgaL9NySWOsDESOFIzOEKQ4V+O8zJTfFR47hpwrslfWV3Fn5MlD6cCfTRFemJ X1fCYPAg1d4Yr0BD+HmGzFkSBPCicW/wUvstL1P+qi5mZ7MPcUGKXAJTZFrJ1TpQbFcs OeL48zIBuLJizWxnS69pY2eutPQFyWNwXaJYPR/VHPXokne1fJcNHDqnSIN7tJz5uhCT P0Tv7HITGLfLFADnKyUkisEFNhfiQ1YeH/xnCiKCOwFHES3QJWfMLHWOXOPBRMH89IHv 3n7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=vmlYRKl2fFXUNzCE53UEr6pVHNqEnu1r4py/MAtobeM=; b=UV5S8opKV1U4tBfO5kURrxDsS7FK3RT1gIS+QgR8VpRVH8f7bTS+bJVf/2QgJlulJe R7vnf54sjJPzysUsuOJNkZshCU2OUR2bIRtyGG9qIYCzD7Ua9+c0M6FuSyOI36Et0m00 RaHR7PkUcRteG8srXWMjWEOznUIwGpp6ZkKhCMR5PxVETne9z5yLrPWC6ZnSr/n/3J2S J8tbLfgDFTqb8R6jZwRdzC3kn8dv4MAKax/54U6ClsMcctJicgm4O0mKUXpDMRE8TvN1 Q/PZAvIlJq5ZCNzbNA+KFhDsH1ei9i6y8qgnbKoVzOcqGZ08P4I+5rGxkaGsapePhaW0 BwFQ==
X-Gm-Message-State: ABuFfog4C2uXbOcyhd5w1qjZaTkc0DPyhDX7Jsx8CfH28A8XGoCjOvf0 ZBlVvisE/PYsnppjylk4T12+mON+
X-Google-Smtp-Source: ACcGV627W3CjnPAxHURVMo0//im3RVYrkK3nsPrke91om3ZVMj590PItJ4wEJNuFa1qCqiW4+lurKQ==
X-Received: by 2002:a62:4613:: with SMTP id t19-v6mr708861pfa.118.1537827754990;  Mon, 24 Sep 2018 15:22:34 -0700 (PDT)
Received: from [10.52.174.170] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id l26-v6sm399823pfg.161.2018.09.24.15.22.33 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Sep 2018 15:22:34 -0700 (PDT)
From: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary="Apple-Mail=_057F3B59-C0E3-49CA-8587-2463A00FCB41"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 24 Sep 2018 15:22:33 -0700
References: 
To: Netconf 
In-Reply-To: 
Message-Id: <6619C41D-F3CA-4FE6-8EE8-9FD5A3458D3C@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [Netconf] WG adoption poll for draft-lengyel-netconf-notification-capabilities-02
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2018 22:22:39 -0000

--Apple-Mail=_057F3B59-C0E3-49CA-8587-2463A00FCB41
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The in-room support for this draft was strong.=20

The on list support for the draft, however, has been tepid. This might =
be because we, as chairs, were not clear on whether folks need to =
reiterate in-room support on the mailing list. We are going to assume =
that the in-room support will translate to the mailing list.

With that in mind, the document is adopted, unless there is a strong =
objection. Please note that there was an additional concern within the =
WG taking on new work. Priority will be given to the current set of =
adopted drafts.

Authors, please post the draft with the content same as the current =
draft, and with the name change to =
draft-ietf-netconf-notification-capabilities.

Thanks

> On Aug 7, 2018, at 7:39 PM, Mahesh Jethanandani =
 wrote:
>=20
> In the NETCONF 102 WG meeting, authors presented the following =
document, and asked for WG adoption.
>=20
> =
https://tools.ietf.org/html/draft-lengyel-netconf-notification-capabilitie=
s-02 =

>=20
> This starts an adoption poll for the above draft. Please indicate your =
support or objection to the adoption poll. If objecting, please state =
your reasons by responding on this thread.
>=20
> Thanks.
>=20
> Mahesh & Kent.
>=20

Mahesh & Kent



--Apple-Mail=_057F3B59-C0E3-49CA-8587-2463A00FCB41
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


The in-room support for this =
draft was strong. 

The on list support for the draft, however, has been tepid. =
This might be because we, as chairs, were not clear on whether folks =
need to reiterate in-room support on the mailing list. We are going to =
assume that the in-room support will translate to the mailing =
list.

With =
that in mind, the document is adopted, unless there is a strong =
objection. Please note that there was an additional concern within the =
WG taking on new work. Priority will be given to the current set of =
adopted drafts.

Authors, please post the draft with the content same as the =
current draft, and with the name change to =
draft-ietf-netconf-notification-capabilities.

Thanks

On Aug =
7, 2018, at 7:39 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

In the =
NETCONF 102 WG meeting, authors presented the following document, and =
asked for WG adoption.

https://tools.ietf.org/html/draft-lengyel-netconf-notification-=
capabilities-02

This starts an adoption poll for the above draft. Please =
indicate your support or objection to the adoption poll. If objecting, =
please state your reasons by responding on this thread.

Thanks.



Mahesh & Kent.









Mahesh & Kent






=

--Apple-Mail=_057F3B59-C0E3-49CA-8587-2463A00FCB41--


From nobody Mon Sep 24 18:25:53 2018
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 66995131166; Mon, 24 Sep 2018 18:25:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach 
To: "The IESG" 
Cc: draft-ietf-netconf-nmda-restconf@ietf.org, Mahesh Jethanandani , netconf-chairs@ietf.org, mjethanandani@gmail.com, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153783874541.31291.9358251378810314164.idtracker@ietfa.amsl.com>
Date: Mon, 24 Sep 2018 18:25:45 -0700
Archived-At: 
Subject: [Netconf] Adam Roach's No Objection on draft-ietf-netconf-nmda-restconf-04: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2018 01:25:46 -0000

Adam Roach has entered the following ballot position for
draft-ietf-netconf-nmda-restconf-04: 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-nmda-restconf/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to everyone who worked on this mechanism.

I agree with Alexey's general point that implementors could benefit from
guidance regarding the "with-defaults" values, as the current mechanism
requires a potentially cumbersome process of probing for support of
desired functionality.

Beyond that, I have only a handful of minor comments.

---------------------------------------------------------------------------

§3.1:

>  The  path component is encoded as an "identity" according
>  to the JSON encoding rules for identities, defined in Section 4 of
>  [RFC7951].

I don't find anything in section 4 of RFC 7951 that indicates encoding for an
"identity." Should this text say "identityref" instead? And if that's the
intention, it seems that pointing to section 6.8 would be more direct than
pointing to section 4.

---------------------------------------------------------------------------

§5:

>  This documents extends the RESTCONF protocol by introducing new
>  datastore resources.  The lowest RESTCONF layer is HTTPS, and the
>  mandatory-to-implement secure transport is TLS [RFC5246].

Unless this mechanism relies on some behavior that is different between TLS 1.2
and TLS 1.3, please update this reference to RFC 8446.

Nit: "This document extends..."
                   ^

>  The security constraints for the base RESTCONF protocol (see
>  Section 12 of [RFC8040] apply to the new RESTCONF datastore resources
>  defined in this document.

Nit: Missing a closing parenthesis.



From nobody Tue Sep 25 02:00:55 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6518131260 for ; Tue, 25 Sep 2018 02:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.188
X-Spam-Level: ***
X-Spam-Status: No, score=3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 MsUKQ9lEhIcN for ; Tue, 25 Sep 2018 02:00:52 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF7913125B for ; Tue, 25 Sep 2018 02:00:51 -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=M6OYjY+ivqOjb962S9VWBEgjbp+UTTO20UM/m/PPf5s=; b=KhW97nFEV8kuqm7P7aYFhDICruWenkArRJ146V9F+IziV3h8p2+QROvQE1VIZBMFhg5ixJDO0gNoMy6UVzbC35b4YChgURRtQY7I/nGo8GeZ8h0R/FhclxRHyAp4ukjpNJ8uPVEUtZi3Gy9ZDBRgskNpssC7w2e1nHXVSBn2puw=
Received: from VI1PR07MB0831.eurprd07.prod.outlook.com (10.161.107.154) by VI1PR07MB3151.eurprd07.prod.outlook.com (10.175.243.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1164.15; Tue, 25 Sep 2018 09:00:48 +0000
Received: from VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db]) by VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db%12]) with mapi id 15.20.1185.014; Tue, 25 Sep 2018 09:00:48 +0000
From: tom petch 
To: Kent Watsen , Martin Bjorklund , "alexander.clemm@huawei.com" 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUVK5AE/XTnvbPM0W59DOLk74sgg==
Date: Tue, 25 Sep 2018 09:00:48 +0000
Message-ID: <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com> 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: CWLP265CA0247.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:25::19) To VI1PR07MB0831.eurprd07.prod.outlook.com (2a01:111:e400:508e::26)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [81.131.229.47]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB3151; 6:gvI2ChWLzWMG6k/4D1jeg+ik3n2pexcVipNOs61OEqwAkoDDgmdrNeLc+KDfQX7kHHOLt3YV/+76TcTFMiv/1H8ZOZz30CPrgKMs8VozgWZNuW2ecfioAaRBD+Z7gNTagmsxelSqd+W1LuxdmzSqxmikTZC8H7rOrzTU4KS6B4LzP6ZKI6yHbHaEwzCrawFDJMVEL62yhlQCjxwNQJJxdRhUR3fLYRI6iihwfzi5qNAGgsLl+FqzQZKPy/6Jjno39PRncrlExAmih/dFX48qtaS4WgiOkwpih90L+S0BEboqzPdlWq2ymNEcSsaUzHHL+/cDP5TMgY+QAUWYRF7VkCTu++b0hE5zKmZGZqnAbNnpA40oLQJ0LQ5fa7GvkErWRiO22CpKYv2ZlyLh39i8J4WmvXIBjSod0WHjOnSt1YxMiXLcnAszaA1X0g6GCGBxoCCMxloR6Cz3BjZl6uBrxw==; 5:7bYAM1LsRNrAbyicPzdGvCf6JBgFN6I+9JjDeAC3Qoyy+P00+EGAh/SkWYLNJOoe9XiLSTBlvZElgT0ICkMjnzipgAZQI7i1zQuUNh+MzmG6ZHM9zr8Koexj1J2KiVpMFDSq2r0NPSulU/2iiJjB3sBbmX5zPpcqzKHiCVy5hy4=; 7:12C5VCvAVyH6avVfFrOxFMIkvHDGCf6xL1m4IdyKkdz3VAODpiPAcX0/Sr86QWUdXbHV2keUeGr65ZeouSlIwXQzTZIKhFNIMao3bo1oxpEEy6NnnLpCEINknts/84/b84U+COn1i5CE/g6X++iG2LQlClcvmg280dqsnHiBGi+WKxR6xzLEhYYImG8wZM8obF4C/RVrNMi8c7qAdpealeuNDhh9fjszUPJvokit8t24KW3xDpjtl3W1K1+bRTJU
x-ms-office365-filtering-correlation-id: b0e809d2-9f19-4bfd-453f-08d622c562d9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB3151; 
x-ms-traffictypediagnostic: VI1PR07MB3151:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(278428928389397)(138986009662008)(50582790962513); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231355)(944501410)(52105095)(6055026)(149066)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051); SRVR:VI1PR07MB3151; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB3151; 
x-forefront-prvs: 08062C429B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(376002)(346002)(366004)(136003)(13464003)(189003)(199004)(51444003)(5250100002)(6246003)(186003)(2501003)(25786009)(7736002)(4326008)(305945005)(256004)(8676002)(105586002)(106356001)(446003)(486006)(476003)(66066001)(14496001)(93886005)(5660300001)(1941001)(2900100001)(97736004)(33896004)(86362001)(6116002)(3846002)(26005)(86152003)(6306002)(9686003)(6512007)(110136005)(99286004)(102836004)(84392002)(76176011)(53936002)(52116002)(316002)(44736005)(68736007)(966005)(229853002)(1556002)(8936002)(6486002)(386003)(14454004)(71200400001)(81156014)(81166006)(6506007)(2906002)(71190400001)(478600001)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3151; H:VI1PR07MB0831.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-microsoft-antispam-message-info: yzh+0qaoAg8f8levqn9U53T+mMWQr+EPIOI5gkoV92VOY7UOPX4E6VooJ4N++82Y8GMC241+aXMiX1CtPcJVypLG66hn8D3XO0Xum7YSDbBvSztim4KKdPzAPw5E1DDRLm1kABWnV2LDsy9L87+SzdbFG1sumoxGD/cxNLdKu6ngMylffMu1M45u42Mp+z2Oeb11C6W5v71au4pGyzc3rs3TsZJJ+UKA+Bcq5TL1NwzotzLVbAqxWLlSiz2YNLz3o1ezh4YWpOMjKR4W9zwxlUNnui51LHipgjcZ94eoyqyKQ3De9On/uGHIDVvT4oyjkB2yQooqo8RM6l7RCRLWUQrwBPzquhstRx6BHqh2dCA=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b0e809d2-9f19-4bfd-453f-08d622c562d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2018 09:00:48.7936 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3151
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2018 09:00:55 -0000

----- Original Message -----
From: "Kent Watsen" 
Sent: Monday, September 24, 2018 7:15 PM

> >Alexander Clemm  wrote:
> >> I am about to post -19 but I do not like the suggested change to go
> >> from timeticks to seconds.
> >>
> >> Seconds is a fairly coarse unit.  I would not be surprised to see
> >> requirements for finer granularity in the future, even more so in
> >> virtualization and controller scenarios in which we start to see
YANG
> >> being used.  There are applications that use single second periods
> >> today so I think it is entirely conceivable to see need for
subsecond
> >> support down the line.  To allow periods only in units of seconds
> >> would seem to unnecessarily hobble ourselves.  Keeping things to
> >> timeticks is more futureproof IMHO.
> >
> > Ok.
>
> I agree that seconds is too course. Hundredths of a second is maybe
too
> fine, but I won't complain.  That said, I think that it might be an
> uncommon scenario and that having hundredths of a second will likely
> result in very large numbers.
>
> FWIW, yang:timeticks doesn't seem as intuitive as "units" - for
example:

Kent

It may depend where you come from.  As RFC6991 points out, timeticks is
designed to be compatible with SMI TimeTicks and so will likely to be
familiar,  expected even, for those who have been at this for, say, 10
years or more.

Tom Petch

>           leaf period {
> -           type yang:timeticks;
> +           type uint16;
> +           units "Hundredths of a second";
>             mandatory true;
>             description
>               "Duration of time which should occur between periodic
>                push updates.";
>           }
>
> At least I know what this means right away.  I was hoping to find an
example
> in -19 illustrating its use, but it's none is present.
>
> BTW, I note that RFC 6991 says:
>
>          When a schema
>          node is defined that uses this type, the description of
>          the schema node identifies both of the reference epochs.
>
> Which I don't see in -19.
>
> Would it make sense to use a 2-tuple?  Something like:
>
>           leaf period {
>             type uint16;
>             mandatory true;
>             description
>               "Duration of time which should occur between periodic
>                push updates.";
>           }
>           leaf period-units {
>             type enumeration {
>               enum hundredths;
>               enum tenths;
>               enum seconds;
>               enum minutes;
>               enum hours;
>             }
>             mandatory true;
>           }
>
>
>
> Kent // contributor
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Tue Sep 25 09:57:09 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F877130E22 for ; Tue, 25 Sep 2018 09:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvHt6IUPOoCy for ; Tue, 25 Sep 2018 09:57:04 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E76130E1A for ; Tue, 25 Sep 2018 09:57:04 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id x16-v6so16027492ljd.12 for ; Tue, 25 Sep 2018 09:57:04 -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=UtCPte9Q0ZIrBz5/cXth3t2uwnS4JB9MYXaTwPOMpoE=; b=gGSDNDGSZAEREAFWzoFBjcIkARTdAK2FMIP3vBG08KFtM/4sW68W8XGswoCe1HMXUE iX6c44p6mbrcwLig8XpqYGvasaoVHWJx691bietM4ueUB1oNsmeD+uzzN9OUC0sh5Yyl lezn9tLlEzZK1NRJ17brPzmI9cBlpEup030mxVN3S7WEoap/CbFmHp6VUbfoKdgCsZHh uWh6qGXFLD+QC+OX+6Nm7vvnWlSZyf4ahOj7itg0AEVQXn3pVC+SRgj37zj92BB8+KeN f8Uc1b2bc7FuzhEEpJjBW6RhTj8HW8gNC8WKYVH4Iyv0vdpVWD461Dc3v/UqKIrdoDe2 hVxA==
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=UtCPte9Q0ZIrBz5/cXth3t2uwnS4JB9MYXaTwPOMpoE=; b=MlcBqWXluWXxsEAScXq8qYxjMExWO+4pVLlVWMEaCWGwZT+UTvIP0pWb5hRGYoAdbp dkQjvONsou2Wa6q4acPXbYAS6G/vx/cFod2495JeiYsaFEDBn7AsAO+OQYGNxQuAgfKt YL0mU+5sNjsYTThKSr30+3bJgrenYKIOJoaJ6heV+/Pqv9yYgPBOT+shy5A/1s8Qa6Qt 5h/OHCjZDaJJ8BkeNowo9OzQWCm0XKgMx5evg1Z/8U59zHQuOpM4eq+EMOsjgYpxrhz/ wqdXJ87ho/QK6VDHfviCfp9SzknE/vlyRodiCZliaP4IgUNxyBXa1AFnB4pyDM3qsM5M /fvA==
X-Gm-Message-State: ABuFfogPU44Z7o1oXM9aABEC5Pwstrz9U5kDT8gGRAbdf2rMc0Z7CF7y 1owe84fIufaSSSVaeEx77axZlWgSjGxXD9HDlPGEMhQmWl4=
X-Google-Smtp-Source: ACcGV61PaL0CcqE7wMFiF70loN99fzmRrb7LLeX8x8nfRUnlznpYmOV7LYMvW/bP3ys6TxrFP6ZBRsqzyCNCRDDXKcU=
X-Received: by 2002:a2e:4401:: with SMTP id r1-v6mr1612286lja.21.1537894622294;  Tue, 25 Sep 2018 09:57:02 -0700 (PDT)
MIME-Version: 1.0
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>
In-Reply-To: <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>
From: Andy Bierman 
Date: Tue, 25 Sep 2018 09:56:50 -0700
Message-ID: 
To: "t.petch" 
Cc: Kent Watsen , Martin Bjorklund ,  Alexander Clemm , Netconf 
Content-Type: multipart/alternative; boundary="000000000000aa0f390576b4fec8"
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2018 16:57:08 -0000

--000000000000aa0f390576b4fec8
Content-Type: text/plain; charset="UTF-8"

On Tue, Sep 25, 2018 at 2:01 AM tom petch  wrote:

> ----- Original Message -----
> From: "Kent Watsen" 
> Sent: Monday, September 24, 2018 7:15 PM
>
> > >Alexander Clemm  wrote:
> > >> I am about to post -19 but I do not like the suggested change to go
> > >> from timeticks to seconds.
> > >>
> > >> Seconds is a fairly coarse unit.  I would not be surprised to see
> > >> requirements for finer granularity in the future, even more so in
> > >> virtualization and controller scenarios in which we start to see
> YANG
> > >> being used.  There are applications that use single second periods
> > >> today so I think it is entirely conceivable to see need for
> subsecond
> > >> support down the line.  To allow periods only in units of seconds
> > >> would seem to unnecessarily hobble ourselves.  Keeping things to
> > >> timeticks is more futureproof IMHO.
> > >
> > > Ok.
> >
> > I agree that seconds is too course. Hundredths of a second is maybe
> too
> > fine, but I won't complain.  That said, I think that it might be an
> > uncommon scenario and that having hundredths of a second will likely
> > result in very large numbers.
> >
> > FWIW, yang:timeticks doesn't seem as intuitive as "units" - for
> example:
>
> Kent
>
> It may depend where you come from.  As RFC6991 points out, timeticks is
> designed to be compatible with SMI TimeTicks and so will likely to be
> familiar,  expected even, for those who have been at this for, say, 10
> years or more.
>
>

Or even 30 years!
https://tools.ietf.org/html/rfc1065

I do not understand the motivation for using uint16.
This would limit the maximum period to 655.35 seconds.


> Tom Petch
>

Andy


>
> >           leaf period {
> > -           type yang:timeticks;
> > +           type uint16;
> > +           units "Hundredths of a second";
> >             mandatory true;
> >             description
> >               "Duration of time which should occur between periodic
> >                push updates.";
> >           }
> >
> > At least I know what this means right away.  I was hoping to find an
> example
> > in -19 illustrating its use, but it's none is present.
> >
> > BTW, I note that RFC 6991 says:
> >
> >          When a schema
> >          node is defined that uses this type, the description of
> >          the schema node identifies both of the reference epochs.
> >
> > Which I don't see in -19.
> >
> > Would it make sense to use a 2-tuple?  Something like:
> >
> >           leaf period {
> >             type uint16;
> >             mandatory true;
> >             description
> >               "Duration of time which should occur between periodic
> >                push updates.";
> >           }
> >           leaf period-units {
> >             type enumeration {
> >               enum hundredths;
> >               enum tenths;
> >               enum seconds;
> >               enum minutes;
> >               enum hours;
> >             }
> >             mandatory true;
> >           }
> >
> >
> >
> > Kent // contributor
> >
> >
> > _______________________________________________
> > 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
>

--000000000000aa0f390576b4fec8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, Sep 25, 2018 at 2:01 AM tom petch <ietfc@btconnect.com> wrote:
----- Original Message -----

From: "Kent Watsen" <kwatsen@juniper.net>

Sent: Monday, September 24, 2018 7:15 PM



> >Alexander Clemm <alexander.clemm@huawei.com> wrote:

> >> I am about to post -19 but I do not like the suggested change=
 to go

> >> from timeticks to seconds.

> >>

> >> Seconds is a fairly coarse unit.=C2=A0 I would not be surpris=
ed to see

> >> requirements for finer granularity in the future, even more s=
o in

> >> virtualization and controller scenarios in which we start to =
see

YANG

> >> being used.=C2=A0 There are applications that use single seco=
nd periods

> >> today so I think it is entirely conceivable to see need for
subsecond

> >> support down the line.=C2=A0 To allow periods only in units o=
f seconds

> >> would seem to unnecessarily hobble ourselves.=C2=A0 Keeping t=
hings to

> >> timeticks is more futureproof IMHO.

> >

> > Ok.

>

> I agree that seconds is too course. Hundredths of a second is maybe
too

> fine, but I won't complain.=C2=A0 That said, I think that it might=
 be an

> uncommon scenario and that having hundredths of a second will likely
> result in very large numbers.

>

> FWIW, yang:timeticks doesn't seem as intuitive as "units"=
; - for

example:



Kent



It may depend where you come from.=C2=A0 As RFC6991 points out, timeticks i=
s

designed to be compatible with SMI TimeTicks and so will likely to be

familiar,=C2=A0 expected even, for those who have been at this for, say, 10=


years or more.




Or even 30 years!
=


I do not understand the motivati=
on for using uint16.
This would limit the maximum period to 655.3=
5 seconds.
=C2=A0

Tom Petch

Andy
=C2=A0



>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf period {

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type yang:timeticks;

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint16;

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0units "Hundredths of a =
second";

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Duration o=
f time which should occur between periodic

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 push updates.&q=
uot;;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

>

> At least I know what this means right away.=C2=A0 I was hoping to find=
 an

example

> in -19 illustrating its use, but it's none is present.

>

> BTW, I note that RFC 6991 says:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When a schema

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 node is defined that uses this type,=
 the description of

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the schema node identifies both of t=
he reference epochs.

>

> Which I don't see in -19.

>

> Would it make sense to use a 2-tuple?=C2=A0 Something like:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf period {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint16;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Duration o=
f time which should occur between periodic

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 push updates.&q=
uot;;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf period-units {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum hundredths;=


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum tenths;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum seconds;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum minutes;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum hours;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

>

>

>

> Kent // contributor

>

>

> _______________________________________________

> Netconf mailing list

> Netconf@ietf.org=


> https://www.ietf.org/mailman/listinfo/netconf<=
br>


_______________________________________________

Netconf mailing list

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




--000000000000aa0f390576b4fec8--


From nobody Tue Sep 25 10:45:07 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C47912777C for ; Tue, 25 Sep 2018 10:45: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 h8ebNJHx3e-n for ; Tue, 25 Sep 2018 10:45:00 -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 508E51274D0 for ; Tue, 25 Sep 2018 10:45:00 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 079D5A2461FC3 for ; Tue, 25 Sep 2018 18:44:54 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 25 Sep 2018 18:44:56 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.47]) by SJCEML701-CHM.china.huawei.com ([169.254.3.87]) with mapi id 14.03.0415.000; Tue, 25 Sep 2018 10:44:53 -0700
From: Alexander Clemm 
To: Andy Bierman , t.petch 
CC: Kent Watsen , Martin Bjorklund , Netconf 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImzU9I4weZMB0iH1L0LVTTudKUB7cYA//+XPjA=
Date: Tue, 25 Sep 2018 17:44:52 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB69F9F@sjceml521-mbx.china.huawei.com>
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.35.95]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB69F9Fsjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2018 17:45:05 -0000

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

V2Ugc2hvdWxkIHN0YXkgd2l0aCB1aW50MzIuDQp1aW50MTYgd291bGQgbWVhbiBqdXN0IHVuZGVy
IDExIG1pbnV0ZXMg4oCTIHRvbyBzaG9ydCBpbWhvLg0KLS0tIEFsZXgNCg0KRnJvbTogQW5keSBC
aWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KU2VudDogVHVlc2RheSwgU2VwdGVt
YmVyIDI1LCAyMDE4IDk6NTcgQU0NClRvOiB0LnBldGNoIDxpZXRmY0BidGNvbm5lY3QuY29tPg0K
Q2M6IEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PjsgTWFydGluIEJqb3JrbHVuZCA8
bWJqQHRhaWwtZi5jb20+OyBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWku
Y29tPjsgTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0g
bWJqJ3MgV0dMQyByZXZpZXcgb2YgeWFuZy1wdXNoLTE3DQoNCg0KT24gVHVlLCBTZXAgMjUsIDIw
MTggYXQgMjowMSBBTSB0b20gcGV0Y2ggPGlldGZjQGJ0Y29ubmVjdC5jb208bWFpbHRvOmlldGZj
QGJ0Y29ubmVjdC5jb20+PiB3cm90ZToNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZy
b206ICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVu
aXBlci5uZXQ+Pg0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTggNzoxNSBQTQ0KDQo+
ID5BbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPG1haWx0bzphbGV4
YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT4+IHdyb3RlOg0KPiA+PiBJIGFtIGFib3V0IHRvIHBvc3Qg
LTE5IGJ1dCBJIGRvIG5vdCBsaWtlIHRoZSBzdWdnZXN0ZWQgY2hhbmdlIHRvIGdvDQo+ID4+IGZy
b20gdGltZXRpY2tzIHRvIHNlY29uZHMuDQo+ID4+DQo+ID4+IFNlY29uZHMgaXMgYSBmYWlybHkg
Y29hcnNlIHVuaXQuICBJIHdvdWxkIG5vdCBiZSBzdXJwcmlzZWQgdG8gc2VlDQo+ID4+IHJlcXVp
cmVtZW50cyBmb3IgZmluZXIgZ3JhbnVsYXJpdHkgaW4gdGhlIGZ1dHVyZSwgZXZlbiBtb3JlIHNv
IGluDQo+ID4+IHZpcnR1YWxpemF0aW9uIGFuZCBjb250cm9sbGVyIHNjZW5hcmlvcyBpbiB3aGlj
aCB3ZSBzdGFydCB0byBzZWUNCllBTkcNCj4gPj4gYmVpbmcgdXNlZC4gIFRoZXJlIGFyZSBhcHBs
aWNhdGlvbnMgdGhhdCB1c2Ugc2luZ2xlIHNlY29uZCBwZXJpb2RzDQo+ID4+IHRvZGF5IHNvIEkg
dGhpbmsgaXQgaXMgZW50aXJlbHkgY29uY2VpdmFibGUgdG8gc2VlIG5lZWQgZm9yDQpzdWJzZWNv
bmQNCj4gPj4gc3VwcG9ydCBkb3duIHRoZSBsaW5lLiAgVG8gYWxsb3cgcGVyaW9kcyBvbmx5IGlu
IHVuaXRzIG9mIHNlY29uZHMNCj4gPj4gd291bGQgc2VlbSB0byB1bm5lY2Vzc2FyaWx5IGhvYmJs
ZSBvdXJzZWx2ZXMuICBLZWVwaW5nIHRoaW5ncyB0bw0KPiA+PiB0aW1ldGlja3MgaXMgbW9yZSBm
dXR1cmVwcm9vZiBJTUhPLg0KPiA+DQo+ID4gT2suDQo+DQo+IEkgYWdyZWUgdGhhdCBzZWNvbmRz
IGlzIHRvbyBjb3Vyc2UuIEh1bmRyZWR0aHMgb2YgYSBzZWNvbmQgaXMgbWF5YmUNCnRvbw0KPiBm
aW5lLCBidXQgSSB3b24ndCBjb21wbGFpbi4gIFRoYXQgc2FpZCwgSSB0aGluayB0aGF0IGl0IG1p
Z2h0IGJlIGFuDQo+IHVuY29tbW9uIHNjZW5hcmlvIGFuZCB0aGF0IGhhdmluZyBodW5kcmVkdGhz
IG9mIGEgc2Vjb25kIHdpbGwgbGlrZWx5DQo+IHJlc3VsdCBpbiB2ZXJ5IGxhcmdlIG51bWJlcnMu
DQo+DQo+IEZXSVcsIHlhbmc6dGltZXRpY2tzIGRvZXNuJ3Qgc2VlbSBhcyBpbnR1aXRpdmUgYXMg
InVuaXRzIiAtIGZvcg0KZXhhbXBsZToNCg0KS2VudA0KDQpJdCBtYXkgZGVwZW5kIHdoZXJlIHlv
dSBjb21lIGZyb20uICBBcyBSRkM2OTkxIHBvaW50cyBvdXQsIHRpbWV0aWNrcyBpcw0KZGVzaWdu
ZWQgdG8gYmUgY29tcGF0aWJsZSB3aXRoIFNNSSBUaW1lVGlja3MgYW5kIHNvIHdpbGwgbGlrZWx5
IHRvIGJlDQpmYW1pbGlhciwgIGV4cGVjdGVkIGV2ZW4sIGZvciB0aG9zZSB3aG8gaGF2ZSBiZWVu
IGF0IHRoaXMgZm9yLCBzYXksIDEwDQp5ZWFycyBvciBtb3JlLg0KDQoNCk9yIGV2ZW4gMzAgeWVh
cnMhDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMTA2NQ0KDQpJIGRvIG5vdCB1bmRl
cnN0YW5kIHRoZSBtb3RpdmF0aW9uIGZvciB1c2luZyB1aW50MTYuDQpUaGlzIHdvdWxkIGxpbWl0
IHRoZSBtYXhpbXVtIHBlcmlvZCB0byA2NTUuMzUgc2Vjb25kcy4NCg0KVG9tIFBldGNoDQoNCkFu
ZHkNCg0KDQo+ICAgICAgICAgICBsZWFmIHBlcmlvZCB7DQo+IC0gICAgICAgICAgIHR5cGUgeWFu
Zzp0aW1ldGlja3M7DQo+ICsgICAgICAgICAgIHR5cGUgdWludDE2Ow0KPiArICAgICAgICAgICB1
bml0cyAiSHVuZHJlZHRocyBvZiBhIHNlY29uZCI7DQo+ICAgICAgICAgICAgIG1hbmRhdG9yeSB0
cnVlOw0KPiAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICAgICAgICJEdXJhdGlv
biBvZiB0aW1lIHdoaWNoIHNob3VsZCBvY2N1ciBiZXR3ZWVuIHBlcmlvZGljDQo+ICAgICAgICAg
ICAgICAgIHB1c2ggdXBkYXRlcy4iOw0KPiAgICAgICAgICAgfQ0KPg0KPiBBdCBsZWFzdCBJIGtu
b3cgd2hhdCB0aGlzIG1lYW5zIHJpZ2h0IGF3YXkuICBJIHdhcyBob3BpbmcgdG8gZmluZCBhbg0K
ZXhhbXBsZQ0KPiBpbiAtMTkgaWxsdXN0cmF0aW5nIGl0cyB1c2UsIGJ1dCBpdCdzIG5vbmUgaXMg
cHJlc2VudC4NCj4NCj4gQlRXLCBJIG5vdGUgdGhhdCBSRkMgNjk5MSBzYXlzOg0KPg0KPiAgICAg
ICAgICBXaGVuIGEgc2NoZW1hDQo+ICAgICAgICAgIG5vZGUgaXMgZGVmaW5lZCB0aGF0IHVzZXMg
dGhpcyB0eXBlLCB0aGUgZGVzY3JpcHRpb24gb2YNCj4gICAgICAgICAgdGhlIHNjaGVtYSBub2Rl
IGlkZW50aWZpZXMgYm90aCBvZiB0aGUgcmVmZXJlbmNlIGVwb2Nocy4NCj4NCj4gV2hpY2ggSSBk
b24ndCBzZWUgaW4gLTE5Lg0KPg0KPiBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIHVzZSBhIDItdHVw
bGU/ICBTb21ldGhpbmcgbGlrZToNCj4NCj4gICAgICAgICAgIGxlYWYgcGVyaW9kIHsNCj4gICAg
ICAgICAgICAgdHlwZSB1aW50MTY7DQo+ICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOw0KPiAg
ICAgICAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICAgICAgICJEdXJhdGlvbiBvZiB0aW1l
IHdoaWNoIHNob3VsZCBvY2N1ciBiZXR3ZWVuIHBlcmlvZGljDQo+ICAgICAgICAgICAgICAgIHB1
c2ggdXBkYXRlcy4iOw0KPiAgICAgICAgICAgfQ0KPiAgICAgICAgICAgbGVhZiBwZXJpb2QtdW5p
dHMgew0KPiAgICAgICAgICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4gICAgICAgICAgICAgICBl
bnVtIGh1bmRyZWR0aHM7DQo+ICAgICAgICAgICAgICAgZW51bSB0ZW50aHM7DQo+ICAgICAgICAg
ICAgICAgZW51bSBzZWNvbmRzOw0KPiAgICAgICAgICAgICAgIGVudW0gbWludXRlczsNCj4gICAg
ICAgICAgICAgICBlbnVtIGhvdXJzOw0KPiAgICAgICAgICAgICB9DQo+ICAgICAgICAgICAgIG1h
bmRhdG9yeSB0cnVlOw0KPiAgICAgICAgICAgfQ0KPg0KPg0KPg0KPiBLZW50IC8vIGNvbnRyaWJ1
dG9yDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5l
dGNvbmZAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bmV0Y29uZg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZA
aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYN
Cg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I
eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k
ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93
ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x
DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9
DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk
bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+
DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0
YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi
b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9
IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+V2Ugc2hvdWxkIHN0YXkgd2l0aCB1aW50MzIuJm5ic3A7DQo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+dWludDE2IHdvdWxkIG1lYW4ganVzdCB1bmRlciAxMSBtaW51dGVzIOKAkyB0b28g
c2hvcnQgaW1oby4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLS0gQWxleDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K
PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx
LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFuZHkg
Qmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU
dWVzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTggOTo1NyBBTTxicj4NCjxiPlRvOjwvYj4gdC5wZXRj
aCAmbHQ7aWV0ZmNAYnRjb25uZWN0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEtlbnQgV2F0c2Vu
ICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0OzsgTWFydGluIEJqb3JrbHVuZCAmbHQ7bWJqQHRh
aWwtZi5jb20mZ3Q7OyBBbGV4YW5kZXIgQ2xlbW0gJmx0O2FsZXhhbmRlci5jbGVtbUBodWF3ZWku
Y29tJmd0OzsgTmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUmU6IFtOZXRjb25mXSBtYmoncyBXR0xDIHJldmlldyBvZiB5YW5nLXB1c2gtMTc8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgU2VwIDI1LCAyMDE4IGF0IDI6
MDEgQU0gdG9tIHBldGNoICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbSI+
aWV0ZmNAYnRjb25uZWN0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND
QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp
bi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206
MTIuMHB0Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPg0KRnJvbTogJnF1b3Q7S2Vu
dCBXYXRzZW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0IiB0
YXJnZXQ9Il9ibGFuayI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyPg0KU2VudDogTW9u
ZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTggNzoxNSBQTTxicj4NCjxicj4NCiZndDsgJmd0O0FsZXhh
bmRlciBDbGVtbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29t
IiB0YXJnZXQ9Il9ibGFuayI+YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90
ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7IEkgYW0gYWJvdXQgdG8gcG9zdCAtMTkgYnV0IEkgZG8gbm90
IGxpa2UgdGhlIHN1Z2dlc3RlZCBjaGFuZ2UgdG8gZ288YnI+DQomZ3Q7ICZndDsmZ3Q7IGZyb20g
dGltZXRpY2tzIHRvIHNlY29uZHMuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn
dDsgU2Vjb25kcyBpcyBhIGZhaXJseSBjb2Fyc2UgdW5pdC4mbmJzcDsgSSB3b3VsZCBub3QgYmUg
c3VycHJpc2VkIHRvIHNlZTxicj4NCiZndDsgJmd0OyZndDsgcmVxdWlyZW1lbnRzIGZvciBmaW5l
ciBncmFudWxhcml0eSBpbiB0aGUgZnV0dXJlLCBldmVuIG1vcmUgc28gaW48YnI+DQomZ3Q7ICZn
dDsmZ3Q7IHZpcnR1YWxpemF0aW9uIGFuZCBjb250cm9sbGVyIHNjZW5hcmlvcyBpbiB3aGljaCB3
ZSBzdGFydCB0byBzZWU8YnI+DQpZQU5HPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBiZWluZyB1c2VkLiZu
YnNwOyBUaGVyZSBhcmUgYXBwbGljYXRpb25zIHRoYXQgdXNlIHNpbmdsZSBzZWNvbmQgcGVyaW9k
czxicj4NCiZndDsgJmd0OyZndDsgdG9kYXkgc28gSSB0aGluayBpdCBpcyBlbnRpcmVseSBjb25j
ZWl2YWJsZSB0byBzZWUgbmVlZCBmb3I8YnI+DQpzdWJzZWNvbmQ8YnI+DQomZ3Q7ICZndDsmZ3Q7
IHN1cHBvcnQgZG93biB0aGUgbGluZS4mbmJzcDsgVG8gYWxsb3cgcGVyaW9kcyBvbmx5IGluIHVu
aXRzIG9mIHNlY29uZHM8YnI+DQomZ3Q7ICZndDsmZ3Q7IHdvdWxkIHNlZW0gdG8gdW5uZWNlc3Nh
cmlseSBob2JibGUgb3Vyc2VsdmVzLiZuYnNwOyBLZWVwaW5nIHRoaW5ncyB0bzxicj4NCiZndDsg
Jmd0OyZndDsgdGltZXRpY2tzIGlzIG1vcmUgZnV0dXJlcHJvb2YgSU1ITy48YnI+DQomZ3Q7ICZn
dDs8YnI+DQomZ3Q7ICZndDsgT2suPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBhZ3JlZSB0aGF0IHNl
Y29uZHMgaXMgdG9vIGNvdXJzZS4gSHVuZHJlZHRocyBvZiBhIHNlY29uZCBpcyBtYXliZTxicj4N
CnRvbzxicj4NCiZndDsgZmluZSwgYnV0IEkgd29uJ3QgY29tcGxhaW4uJm5ic3A7IFRoYXQgc2Fp
ZCwgSSB0aGluayB0aGF0IGl0IG1pZ2h0IGJlIGFuPGJyPg0KJmd0OyB1bmNvbW1vbiBzY2VuYXJp
byBhbmQgdGhhdCBoYXZpbmcgaHVuZHJlZHRocyBvZiBhIHNlY29uZCB3aWxsIGxpa2VseTxicj4N
CiZndDsgcmVzdWx0IGluIHZlcnkgbGFyZ2UgbnVtYmVycy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBG
V0lXLCB5YW5nOnRpbWV0aWNrcyBkb2Vzbid0IHNlZW0gYXMgaW50dWl0aXZlIGFzICZxdW90O3Vu
aXRzJnF1b3Q7IC0gZm9yPGJyPg0KZXhhbXBsZTo8YnI+DQo8YnI+DQpLZW50PGJyPg0KPGJyPg0K
SXQgbWF5IGRlcGVuZCB3aGVyZSB5b3UgY29tZSBmcm9tLiZuYnNwOyBBcyBSRkM2OTkxIHBvaW50
cyBvdXQsIHRpbWV0aWNrcyBpczxicj4NCmRlc2lnbmVkIHRvIGJlIGNvbXBhdGlibGUgd2l0aCBT
TUkgVGltZVRpY2tzIGFuZCBzbyB3aWxsIGxpa2VseSB0byBiZTxicj4NCmZhbWlsaWFyLCZuYnNw
OyBleHBlY3RlZCBldmVuLCBmb3IgdGhvc2Ugd2hvIGhhdmUgYmVlbiBhdCB0aGlzIGZvciwgc2F5
LCAxMDxicj4NCnllYXJzIG9yIG1vcmUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9yIGV2ZW4gMzAgeWVhcnMhPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMTA2NSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL3JmYzEwNjU8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIG1vdGl2YXRpb24gZm9yIHVzaW5n
IHVpbnQxNi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlRoaXMgd291bGQgbGltaXQgdGhlIG1heGltdW0gcGVyaW9kIHRvIDY1NS4zNSBzZWNvbmRz
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w
cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5Ub20gUGV0Y2g8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx
dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw
YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow
aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7bGVhZiBwZXJpb2Qgezxicj4NCiZndDsgLSZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZSB5YW5nOnRpbWV0aWNrczs8YnI+DQom
Z3Q7ICYjNDM7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBlIHVp
bnQxNjs8YnI+DQomZ3Q7ICYjNDM7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDt1bml0cyAmcXVvdDtIdW5kcmVkdGhzIG9mIGEgc2Vjb25kJnF1b3Q7Ozxicj4NCiZndDsm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDttYW5kYXRvcnkg
dHJ1ZTs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ZGVzY3JpcHRpb248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O0R1cmF0aW9uIG9mIHRpbWUgd2hpY2ggc2hv
dWxkIG9jY3VyIGJldHdlZW4gcGVyaW9kaWM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwdXNoIHVwZGF0ZXMuJnF1b3Q7Ozxi
cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQom
Z3Q7PGJyPg0KJmd0OyBBdCBsZWFzdCBJIGtub3cgd2hhdCB0aGlzIG1lYW5zIHJpZ2h0IGF3YXku
Jm5ic3A7IEkgd2FzIGhvcGluZyB0byBmaW5kIGFuPGJyPg0KZXhhbXBsZTxicj4NCiZndDsgaW4g
LTE5IGlsbHVzdHJhdGluZyBpdHMgdXNlLCBidXQgaXQncyBub25lIGlzIHByZXNlbnQuPGJyPg0K
Jmd0Ozxicj4NCiZndDsgQlRXLCBJIG5vdGUgdGhhdCBSRkMgNjk5MSBzYXlzOjxicj4NCiZndDs8
YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBXaGVuIGEgc2NoZW1h
PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbm9kZSBpcyBkZWZp
bmVkIHRoYXQgdXNlcyB0aGlzIHR5cGUsIHRoZSBkZXNjcmlwdGlvbiBvZjxicj4NCiZndDsmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBzY2hlbWEgbm9kZSBpZGVudGlmaWVz
IGJvdGggb2YgdGhlIHJlZmVyZW5jZSBlcG9jaHMuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hpY2gg
SSBkb24ndCBzZWUgaW4gLTE5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFdvdWxkIGl0IG1ha2Ugc2Vu
c2UgdG8gdXNlIGEgMi10dXBsZT8mbmJzcDsgU29tZXRoaW5nIGxpa2U6PGJyPg0KJmd0Ozxicj4N
CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xlYWYgcGVyaW9k
IHs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7dHlwZSB1aW50MTY7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO21hbmRhdG9yeSB0cnVlOzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXNjcmlwdGlvbjxicj4NCiZndDsmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7
RHVyYXRpb24gb2YgdGltZSB3aGljaCBzaG91bGQgb2NjdXIgYmV0d2VlbiBwZXJpb2RpYzxicj4N
CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7IHB1c2ggdXBkYXRlcy4mcXVvdDs7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwO2xlYWYgcGVyaW9kLXVuaXRzIHs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZSBlbnVtZXJhdGlvbiB7PGJyPg0K
Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDtlbnVtIGh1bmRyZWR0aHM7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtlbnVtIHRlbnRoczs8YnI+DQomZ3Q7Jm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2VudW0gc2Vjb25k
czs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO2VudW0gbWludXRlczs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2VudW0gaG91cnM7PGJyPg0KJmd0OyZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7Jm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWFuZGF0b3J5IHRy
dWU7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxi
cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgS2VudCAvLyBjb250cmlidXRv
cjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+
DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
TmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48YnI+DQo8YnI+DQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFp
bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5OZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvcD4N
CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB69F9Fsjceml521mbxchi_--


From nobody Tue Sep 25 10:51:41 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2726212785F for ; Tue, 25 Sep 2018 10:51: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, 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 GcHXn-jleBub for ; Tue, 25 Sep 2018 10:51:35 -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 0D2031277CC for ; Tue, 25 Sep 2018 10:51:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18532; q=dns/txt; s=iport; t=1537897895; x=1539107495; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=n8dfg3SZp2MjucfouakwHf3BW0FcFYMwuF8yBCaS6Zk=; b=X5Kz4RnIdFK5BI36xGBM3PvRLLAZMZlirRrTUNY+54SYj3ftFbBAuckG 0suK7A5ZW/K3Du03lpbg1htChLJxZb3YCrEFrg1Q3zwBT7ZIX4mLEgtAS NO1pBMLl/Yra4x2NWE3R7DsBvJEyL/B5bu7NloLyyXbHm8btfRiu92DbY s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAAC6dKpb/51dJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUoEWd2V/KAqDapRCgg2REoU8gXoLGAEKhANGAheDTyE?= =?us-ascii?q?1FwEDAQECAQECbRwMhTgBAQEBAgEBASEKQQsFBwQCAQgVAQInAwICAiULFBE?= =?us-ascii?q?CBAENBQiDGoEdXAgPpBaBLooUBYp6F4FBP4ESgxKDGwEBA4E4PR+CS4JXAoh?= =?us-ascii?q?0hHaFdYhRTwkChkGJXh+PLIt6iGgCERSBJR8DM4FVcBU7gmyCJReIWoU+b4t?= =?us-ascii?q?IgS2BHgEB?=
X-IronPort-AV: E=Sophos;i="5.54,303,1534809600";  d="scan'208,217";a="460386346"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2018 17:51:33 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w8PHpXQe016306 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Sep 2018 17:51:33 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 25 Sep 2018 13:51:32 -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.1395.000; Tue, 25 Sep 2018 13:51:32 -0400
From: "Eric Voit (evoit)" 
To: Andy Bierman , "t.petch" 
CC: Netconf 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUVPDUPLguyzPPBUeA9Mav+IS/2aUBQatQ
Date: Tue, 25 Sep 2018 17:51:32 +0000
Message-ID: <31256be990c44570a18bc1dd6c5a7595@XCH-RTP-013.cisco.com>
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net> 
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.235]
Content-Type: multipart/alternative; boundary="_000_31256be990c44570a18bc1dd6c5a7595XCHRTP013ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2018 17:51:39 -0000

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

RnJvbTogQW5keSBCaWVybWFuLCBTZXB0ZW1iZXIgMjUsIDIwMTggMTI6NTcgUE0NCg0KT24gVHVl
LCBTZXAgMjUsIDIwMTggYXQgMjowMSBBTSB0b20gcGV0Y2ggPGlldGZjQGJ0Y29ubmVjdC5jb208
bWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb20+PiB3cm90ZToNCi0tLS0tIE9yaWdpbmFsIE1lc3Nh
Z2UgLS0tLS0NCkZyb206ICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRv
Omt3YXRzZW5AanVuaXBlci5uZXQ+Pg0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTgg
NzoxNSBQTQ0KDQo+ID5BbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29t
PG1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT4+IHdyb3RlOg0KPiA+PiBJIGFtIGFi
b3V0IHRvIHBvc3QgLTE5IGJ1dCBJIGRvIG5vdCBsaWtlIHRoZSBzdWdnZXN0ZWQgY2hhbmdlIHRv
IGdvDQo+ID4+IGZyb20gdGltZXRpY2tzIHRvIHNlY29uZHMuDQo+ID4+DQo+ID4+IFNlY29uZHMg
aXMgYSBmYWlybHkgY29hcnNlIHVuaXQuICBJIHdvdWxkIG5vdCBiZSBzdXJwcmlzZWQgdG8gc2Vl
DQo+ID4+IHJlcXVpcmVtZW50cyBmb3IgZmluZXIgZ3JhbnVsYXJpdHkgaW4gdGhlIGZ1dHVyZSwg
ZXZlbiBtb3JlIHNvIGluDQo+ID4+IHZpcnR1YWxpemF0aW9uIGFuZCBjb250cm9sbGVyIHNjZW5h
cmlvcyBpbiB3aGljaCB3ZSBzdGFydCB0byBzZWUNCllBTkcNCj4gPj4gYmVpbmcgdXNlZC4gIFRo
ZXJlIGFyZSBhcHBsaWNhdGlvbnMgdGhhdCB1c2Ugc2luZ2xlIHNlY29uZCBwZXJpb2RzDQo+ID4+
IHRvZGF5IHNvIEkgdGhpbmsgaXQgaXMgZW50aXJlbHkgY29uY2VpdmFibGUgdG8gc2VlIG5lZWQg
Zm9yDQpzdWJzZWNvbmQNCj4gPj4gc3VwcG9ydCBkb3duIHRoZSBsaW5lLiAgVG8gYWxsb3cgcGVy
aW9kcyBvbmx5IGluIHVuaXRzIG9mIHNlY29uZHMNCj4gPj4gd291bGQgc2VlbSB0byB1bm5lY2Vz
c2FyaWx5IGhvYmJsZSBvdXJzZWx2ZXMuICBLZWVwaW5nIHRoaW5ncyB0bw0KPiA+PiB0aW1ldGlj
a3MgaXMgbW9yZSBmdXR1cmVwcm9vZiBJTUhPLg0KPiA+DQo+ID4gT2suDQo+DQo+IEkgYWdyZWUg
dGhhdCBzZWNvbmRzIGlzIHRvbyBjb3Vyc2UuIEh1bmRyZWR0aHMgb2YgYSBzZWNvbmQgaXMgbWF5
YmUNCnRvbw0KPiBmaW5lLCBidXQgSSB3b24ndCBjb21wbGFpbi4gIFRoYXQgc2FpZCwgSSB0aGlu
ayB0aGF0IGl0IG1pZ2h0IGJlIGFuDQo+IHVuY29tbW9uIHNjZW5hcmlvIGFuZCB0aGF0IGhhdmlu
ZyBodW5kcmVkdGhzIG9mIGEgc2Vjb25kIHdpbGwgbGlrZWx5DQo+IHJlc3VsdCBpbiB2ZXJ5IGxh
cmdlIG51bWJlcnMuDQo+DQo+IEZXSVcsIHlhbmc6dGltZXRpY2tzIGRvZXNuJ3Qgc2VlbSBhcyBp
bnR1aXRpdmUgYXMgInVuaXRzIiAtIGZvcg0KZXhhbXBsZToNCg0KS2VudA0KDQpJdCBtYXkgZGVw
ZW5kIHdoZXJlIHlvdSBjb21lIGZyb20uICBBcyBSRkM2OTkxIHBvaW50cyBvdXQsIHRpbWV0aWNr
cyBpcw0KZGVzaWduZWQgdG8gYmUgY29tcGF0aWJsZSB3aXRoIFNNSSBUaW1lVGlja3MgYW5kIHNv
IHdpbGwgbGlrZWx5IHRvIGJlDQpmYW1pbGlhciwgIGV4cGVjdGVkIGV2ZW4sIGZvciB0aG9zZSB3
aG8gaGF2ZSBiZWVuIGF0IHRoaXMgZm9yLCBzYXksIDEwDQp5ZWFycyBvciBtb3JlLg0KDQoNCk9y
IGV2ZW4gMzAgeWVhcnMhDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMTA2NQ0KDQpJ
IGRvIG5vdCB1bmRlcnN0YW5kIHRoZSBtb3RpdmF0aW9uIGZvciB1c2luZyB1aW50MTYuDQpUaGlz
IHdvdWxkIGxpbWl0IHRoZSBtYXhpbXVtIHBlcmlvZCB0byA2NTUuMzUgc2Vjb25kcy4NCg0KPGVy
aWM+IEN1cnJlbnQgZGVmaW5pdGlvbiBzdXBwb3J0cyB1cCB0byAyNDggZGF5cy4gIFdoaWNoIGxv
b2tzIHN1ZmZpY2llbnQgYXQgdGhpcyBwb2ludCB0byBtZS4NCg0KRXJpYw0KDQpUb20gUGV0Y2gN
Cg0KQW5keQ0KDQoNCj4gICAgICAgICAgIGxlYWYgcGVyaW9kIHsNCj4gLSAgICAgICAgICAgdHlw
ZSB5YW5nOnRpbWV0aWNrczsNCj4gKyAgICAgICAgICAgdHlwZSB1aW50MTY7DQo+ICsgICAgICAg
ICAgIHVuaXRzICJIdW5kcmVkdGhzIG9mIGEgc2Vjb25kIjsNCj4gICAgICAgICAgICAgbWFuZGF0
b3J5IHRydWU7DQo+ICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAgICAgIkR1
cmF0aW9uIG9mIHRpbWUgd2hpY2ggc2hvdWxkIG9jY3VyIGJldHdlZW4gcGVyaW9kaWMNCj4gICAg
ICAgICAgICAgICAgcHVzaCB1cGRhdGVzLiI7DQo+ICAgICAgICAgICB9DQo+DQo+IEF0IGxlYXN0
IEkga25vdyB3aGF0IHRoaXMgbWVhbnMgcmlnaHQgYXdheS4gIEkgd2FzIGhvcGluZyB0byBmaW5k
IGFuDQpleGFtcGxlDQo+IGluIC0xOSBpbGx1c3RyYXRpbmcgaXRzIHVzZSwgYnV0IGl0J3Mgbm9u
ZSBpcyBwcmVzZW50Lg0KPg0KPiBCVFcsIEkgbm90ZSB0aGF0IFJGQyA2OTkxIHNheXM6DQo+DQo+
ICAgICAgICAgIFdoZW4gYSBzY2hlbWENCj4gICAgICAgICAgbm9kZSBpcyBkZWZpbmVkIHRoYXQg
dXNlcyB0aGlzIHR5cGUsIHRoZSBkZXNjcmlwdGlvbiBvZg0KPiAgICAgICAgICB0aGUgc2NoZW1h
IG5vZGUgaWRlbnRpZmllcyBib3RoIG9mIHRoZSByZWZlcmVuY2UgZXBvY2hzLg0KPg0KPiBXaGlj
aCBJIGRvbid0IHNlZSBpbiAtMTkuDQo+DQo+IFdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gdXNlIGEg
Mi10dXBsZT8gIFNvbWV0aGluZyBsaWtlOg0KPg0KPiAgICAgICAgICAgbGVhZiBwZXJpb2Qgew0K
PiAgICAgICAgICAgICB0eXBlIHVpbnQxNjsNCj4gICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7
DQo+ICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAgICAgIkR1cmF0aW9uIG9m
IHRpbWUgd2hpY2ggc2hvdWxkIG9jY3VyIGJldHdlZW4gcGVyaW9kaWMNCj4gICAgICAgICAgICAg
ICAgcHVzaCB1cGRhdGVzLiI7DQo+ICAgICAgICAgICB9DQo+ICAgICAgICAgICBsZWFmIHBlcmlv
ZC11bml0cyB7DQo+ICAgICAgICAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KPiAgICAgICAgICAg
ICAgIGVudW0gaHVuZHJlZHRoczsNCj4gICAgICAgICAgICAgICBlbnVtIHRlbnRoczsNCj4gICAg
ICAgICAgICAgICBlbnVtIHNlY29uZHM7DQo+ICAgICAgICAgICAgICAgZW51bSBtaW51dGVzOw0K
PiAgICAgICAgICAgICAgIGVudW0gaG91cnM7DQo+ICAgICAgICAgICAgIH0NCj4gICAgICAgICAg
ICAgbWFuZGF0b3J5IHRydWU7DQo+ICAgICAgICAgICB9DQo+DQo+DQo+DQo+IEtlbnQgLy8gY29u
dHJpYnV0b3INCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZzxtYWls
dG86TmV0Y29uZkBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9uZXRjb25mDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0
Y29uZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0
Y29uZg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx
MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv
bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8
L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0
IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo
YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi
IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+IEFuZHkgQmllcm1hbiwgU2VwdGVtYmVyIDI1LCAyMDE4IDEyOjU3
IFBNPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgU2VwIDI1LCAyMDE4IGF0IDI6
MDEgQU0gdG9tIHBldGNoICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbSI+
aWV0ZmNAYnRjb25uZWN0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND
QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+LS0tLS0gT3JpZ2lu
YWwgTWVzc2FnZSAtLS0tLTxicj4NCkZyb206ICZxdW90O0tlbnQgV2F0c2VuJnF1b3Q7ICZsdDs8
YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmt3YXRz
ZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDI0LCAy
MDE4IDc6MTUgUE08YnI+DQo8YnI+DQomZ3Q7ICZndDtBbGV4YW5kZXIgQ2xlbW0gJmx0OzxhIGhy
ZWY9Im1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFs
ZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0
OyBJIGFtIGFib3V0IHRvIHBvc3QgLTE5IGJ1dCBJIGRvIG5vdCBsaWtlIHRoZSBzdWdnZXN0ZWQg
Y2hhbmdlIHRvIGdvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBmcm9tIHRpbWV0aWNrcyB0byBzZWNvbmRz
Ljxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFNlY29uZHMgaXMgYSBmYWly
bHkgY29hcnNlIHVuaXQuJm5ic3A7IEkgd291bGQgbm90IGJlIHN1cnByaXNlZCB0byBzZWU8YnI+
DQomZ3Q7ICZndDsmZ3Q7IHJlcXVpcmVtZW50cyBmb3IgZmluZXIgZ3JhbnVsYXJpdHkgaW4gdGhl
IGZ1dHVyZSwgZXZlbiBtb3JlIHNvIGluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB2aXJ0dWFsaXphdGlv
biBhbmQgY29udHJvbGxlciBzY2VuYXJpb3MgaW4gd2hpY2ggd2Ugc3RhcnQgdG8gc2VlPGJyPg0K
WUFORzxicj4NCiZndDsgJmd0OyZndDsgYmVpbmcgdXNlZC4mbmJzcDsgVGhlcmUgYXJlIGFwcGxp
Y2F0aW9ucyB0aGF0IHVzZSBzaW5nbGUgc2Vjb25kIHBlcmlvZHM8YnI+DQomZ3Q7ICZndDsmZ3Q7
IHRvZGF5IHNvIEkgdGhpbmsgaXQgaXMgZW50aXJlbHkgY29uY2VpdmFibGUgdG8gc2VlIG5lZWQg
Zm9yPGJyPg0Kc3Vic2Vjb25kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBzdXBwb3J0IGRvd24gdGhlIGxp
bmUuJm5ic3A7IFRvIGFsbG93IHBlcmlvZHMgb25seSBpbiB1bml0cyBvZiBzZWNvbmRzPGJyPg0K
Jmd0OyAmZ3Q7Jmd0OyB3b3VsZCBzZWVtIHRvIHVubmVjZXNzYXJpbHkgaG9iYmxlIG91cnNlbHZl
cy4mbmJzcDsgS2VlcGluZyB0aGluZ3MgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7IHRpbWV0aWNrcyBp
cyBtb3JlIGZ1dHVyZXByb29mIElNSE8uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9r
Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEkgYWdyZWUgdGhhdCBzZWNvbmRzIGlzIHRvbyBjb3Vyc2Uu
IEh1bmRyZWR0aHMgb2YgYSBzZWNvbmQgaXMgbWF5YmU8YnI+DQp0b288YnI+DQomZ3Q7IGZpbmUs
IGJ1dCBJIHdvbid0IGNvbXBsYWluLiZuYnNwOyBUaGF0IHNhaWQsIEkgdGhpbmsgdGhhdCBpdCBt
aWdodCBiZSBhbjxicj4NCiZndDsgdW5jb21tb24gc2NlbmFyaW8gYW5kIHRoYXQgaGF2aW5nIGh1
bmRyZWR0aHMgb2YgYSBzZWNvbmQgd2lsbCBsaWtlbHk8YnI+DQomZ3Q7IHJlc3VsdCBpbiB2ZXJ5
IGxhcmdlIG51bWJlcnMuPGJyPg0KJmd0Ozxicj4NCiZndDsgRldJVywgeWFuZzp0aW1ldGlja3Mg
ZG9lc24ndCBzZWVtIGFzIGludHVpdGl2ZSBhcyAmcXVvdDt1bml0cyZxdW90OyAtIGZvcjxicj4N
CmV4YW1wbGU6PGJyPg0KPGJyPg0KS2VudDxicj4NCjxicj4NCkl0IG1heSBkZXBlbmQgd2hlcmUg
eW91IGNvbWUgZnJvbS4mbmJzcDsgQXMgUkZDNjk5MSBwb2ludHMgb3V0LCB0aW1ldGlja3MgaXM8
YnI+DQpkZXNpZ25lZCB0byBiZSBjb21wYXRpYmxlIHdpdGggU01JIFRpbWVUaWNrcyBhbmQgc28g
d2lsbCBsaWtlbHkgdG8gYmU8YnI+DQpmYW1pbGlhciwmbmJzcDsgZXhwZWN0ZWQgZXZlbiwgZm9y
IHRob3NlIHdobyBoYXZlIGJlZW4gYXQgdGhpcyBmb3IsIHNheSwgMTA8YnI+DQp5ZWFycyBvciBt
b3JlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5PciBldmVuIDMwIHllYXJzITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL3JmYzEwNjUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMxMDY1PC9hPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5v
dCB1bmRlcnN0YW5kIHRoZSBtb3RpdmF0aW9uIGZvciB1c2luZyB1aW50MTYuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHdvdWxkIGxpbWl0
IHRoZSBtYXhpbXVtIHBlcmlvZCB0byA2NTUuMzUgc2Vjb25kcy48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6NS4yNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmx0O2VyaWMmZ3Q7
IEN1cnJlbnQgZGVmaW5pdGlvbiBzdXBwb3J0cyB1cCB0byAyNDggZGF5cy4mbmJzcDsgV2hpY2gg
bG9va3Mgc3VmZmljaWVudCBhdCB0aGlzIHBvaW50IHRvIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlRvbSBQZXRjaDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj
Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7bGVhZiBwZXJpb2Qgezxicj4NCiZndDsgLSZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZSB5YW5nOnRpbWV0aWNrczs8YnI+DQomZ3Q7ICYj
NDM7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBlIHVpbnQxNjs8
YnI+DQomZ3Q7ICYjNDM7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1
bml0cyAmcXVvdDtIdW5kcmVkdGhzIG9mIGEgc2Vjb25kJnF1b3Q7Ozxicj4NCiZndDsmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDttYW5kYXRvcnkgdHJ1ZTs8
YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ZGVzY3JpcHRpb248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O0R1cmF0aW9uIG9mIHRpbWUgd2hpY2ggc2hvdWxkIG9j
Y3VyIGJldHdlZW4gcGVyaW9kaWM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwdXNoIHVwZGF0ZXMuJnF1b3Q7Ozxicj4NCiZn
dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7PGJy
Pg0KJmd0OyBBdCBsZWFzdCBJIGtub3cgd2hhdCB0aGlzIG1lYW5zIHJpZ2h0IGF3YXkuJm5ic3A7
IEkgd2FzIGhvcGluZyB0byBmaW5kIGFuPGJyPg0KZXhhbXBsZTxicj4NCiZndDsgaW4gLTE5IGls
bHVzdHJhdGluZyBpdHMgdXNlLCBidXQgaXQncyBub25lIGlzIHByZXNlbnQuPGJyPg0KJmd0Ozxi
cj4NCiZndDsgQlRXLCBJIG5vdGUgdGhhdCBSRkMgNjk5MSBzYXlzOjxicj4NCiZndDs8YnI+DQom
Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBXaGVuIGEgc2NoZW1hPGJyPg0K
Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbm9kZSBpcyBkZWZpbmVkIHRo
YXQgdXNlcyB0aGlzIHR5cGUsIHRoZSBkZXNjcmlwdGlvbiBvZjxicj4NCiZndDsmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBzY2hlbWEgbm9kZSBpZGVudGlmaWVzIGJvdGgg
b2YgdGhlIHJlZmVyZW5jZSBlcG9jaHMuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hpY2ggSSBkb24n
dCBzZWUgaW4gLTE5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8g
dXNlIGEgMi10dXBsZT8mbmJzcDsgU29tZXRoaW5nIGxpa2U6PGJyPg0KJmd0Ozxicj4NCiZndDsm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xlYWYgcGVyaW9kIHs8YnI+
DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHlw
ZSB1aW50MTY7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO21hbmRhdG9yeSB0cnVlOzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXNjcmlwdGlvbjxicj4NCiZndDsmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7RHVyYXRp
b24gb2YgdGltZSB3aGljaCBzaG91bGQgb2NjdXIgYmV0d2VlbiBwZXJpb2RpYzxicj4NCiZndDsm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHB1
c2ggdXBkYXRlcy4mcXVvdDs7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7fTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO2xlYWYgcGVyaW9kLXVuaXRzIHs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZSBlbnVtZXJhdGlvbiB7PGJyPg0KJmd0OyZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtlbnVt
IGh1bmRyZWR0aHM7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDtlbnVtIHRlbnRoczs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2VudW0gc2Vjb25kczs8YnI+
DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwO2VudW0gbWludXRlczs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2VudW0gaG91cnM7PGJyPg0KJmd0OyZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7Jm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWFuZGF0b3J5IHRydWU7PGJy
Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZn
dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgS2VudCAvLyBjb250cmlidXRvcjxicj4N
CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCiZndDsgTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7
IDxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+TmV0Y29u
ZkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBs
aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij5OZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_31256be990c44570a18bc1dd6c5a7595XCHRTP013ciscocom_--


From nobody Tue Sep 25 12:12:49 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E1A12D7F8 for ; Tue, 25 Sep 2018 12:12:48 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 PZuPVsUH0YK5 for ; Tue, 25 Sep 2018 12:12:45 -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 7CFE0128CF3 for ; Tue, 25 Sep 2018 12:12:45 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8PHnxw1017943; Tue, 25 Sep 2018 10:52:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=PpbYb4uXvMUj6r+Pd6xRVSBYU7bCwiOaNcbFtG8T4gw=; b=ytXMVwzm9szPDRdlJB9tDtXkiFkIr19KfOeH19cMQ6k9/qCHVZTX1WKa/ed+Ye7j5DYv I2jlg+ouDOOpDGnChV96Gk9hwwT1xwYc5Ki2gr8Kwkr/73HXbiel94PkGay4MR+jpgrY jEXI5I2ePOzHqw3eim5BW5EdZFIiFoz/bsx1d/eUSLH++0hoI4Vk0PhfNWFPbitenjD+ 9DpP/T4IJwa4cCIx9Ey7zcyf3teQNDuxlT2H8z+7G8mfnJ3WSs2n84AXoEkiZdsyfx+q xIZ8dr9HpMwGMb2MYodsuS4vbPDMQqWmbWSLaeP+srqnEWKICdKaX0S8bxWSKzbw21jA Tw== 
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0015.outbound.protection.outlook.com [216.32.181.15]) by mx0b-00273201.pphosted.com with ESMTP id 2mqq5urd2a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 25 Sep 2018 10:52:27 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4828.namprd05.prod.outlook.com (20.176.111.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1164.15; Tue, 25 Sep 2018 17:52:25 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%3]) with mapi id 15.20.1185.014; Tue, 25 Sep 2018 17:52:25 +0000
From: Kent Watsen 
To: Andy Bierman , t.petch 
CC: Martin Bjorklund , Alexander Clemm , Netconf 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImouJGUP0t9tESR9VzM68tuEKUBeG0A///MeoA=
Date: Tue, 25 Sep 2018 17:52:25 +0000
Message-ID: <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net>
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4828; 6:GlLCPUBcqAQuhKqPbQOhnBuJRU7bNTWjrk+a4s5T2CGYV4bJBmNGQmpEoOxDrKfaNOtwF4hwfdsHiOZKa4SmjKBwy5yGGSCOS+WwinuS/w3jdrE96RSsMg1EAoeLAvy3xlGI427SWb0grvZ4VQUo6w2J592/JNZIUgSf6EqTOTuPEQ44/1Bsn2Oxpxk29xuv1HbrSe6azGh7234S6w8HXlAMxuyZDzUjRJk/Bm6KNQec45YRofXNuFMgiUqZ0vla2H3HU7++1hTUmrSmaPKo8LsRHVcgn9ZxtUdXWWTRlDcSwHSExKMCsW9CvDv+l3fFq/P4wJ/EI1U8t6Z8RePWPA3F+kkCzTXwhdQbarOWhMhT9NUfe1ksHD7pPydZFSE+rjO0ymKA1/uLKkaRXiZCaKl5QaY/E6CLfYUIazx9KEEpvkCVh3sd15PZ5heEWHaDyi42vQHaUqTb3Emm9UO6pA==; 5:041yVGrnqDbDyq4gUd/Nhy1kvSwmZDdm1Hhzhhz6hz4S9CGyX+xQAm9UsEKPz62OAY93qbCXHcDkBtpPvIVXHyusUfv4vhGBP9/PEVGew5rQGYYV8+sYjOv8zYeIOMh7kFZ2DXdd6jguylMGkz80dIclrWNPkE+IE0vKc2mVBqg=; 7:lDOmJDptuvOEDwx//NhFloi2CrRR9nALd88F5MugaPqjixG8aD4Jew4q9+2sho08I4TsNi21GycJiXcaPbxUywMEPMdOKYdv++jlsZZAYM38x8ZllWwFcJg6Oy/U3YcRF5eLTxKv5iprSuzXgyhZkcHAHfom/bGdsTNsdqbGPJ9FVv2lta8Bd8xkZnvBO5Js8J7RmIlk3OlxHwGuFKJRdXTgH89Mjnm/aQlPL4Kctu4gTiVDrkXYlZy6Zma54Er5
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 703d5e25-b627-4dc4-ced8-08d6230fa74a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4828; 
x-ms-traffictypediagnostic: DM6PR05MB4828:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149066)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991041); SRVR:DM6PR05MB4828; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4828; 
x-forefront-prvs: 08062C429B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(136003)(366004)(39860400002)(189003)(199004)(93886005)(14454004)(2900100001)(6116002)(3846002)(478600001)(6512007)(54896002)(6306002)(25786009)(53936002)(6246003)(68736007)(8936002)(81166006)(81156014)(4326008)(71200400001)(71190400001)(6506007)(86362001)(83716004)(34290500001)(256004)(76176011)(14444005)(8676002)(66066001)(5250100002)(54906003)(105586002)(82746002)(486006)(26005)(316002)(58126008)(102836004)(110136005)(446003)(11346002)(476003)(2616005)(229853002)(36756003)(97736004)(7736002)(5660300001)(99286004)(33656002)(186003)(106356001)(6486002)(6436002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4828; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: J6cye7DJU/gpjUw0X4rreT3xstP3cb5jkfk+wS37fXTBw57nAO4QtUTi19uMu5an1vjgyhLdHvANRzQcOc38fgOnXsBrH7zRNhzttXdBeVrG6isI54qOEsThlJrs+B20mdoKzqgZuqegXO9x0aSU8zNjSk4ykZCSE9BrOxYvvyIjyVA8GsOG9xNglAuhOPFMOB9c2k4CY0u5QjNS4cnINM73qEJ02kaFvyVUKZye7dAs0W8bu/m/D0Qb+9B32HRxP/iD4ppedf85AvIpez0wiQwohPVu8mSZjjZwqMjOrk9JbFXIJjG8h+AwHlG3kBVHfdThGz9TfkmmmSGlkT4616nqiqvjF+c+pWbeRO894nY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_674F5961D9564BD18AD044FE68150070junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 703d5e25-b627-4dc4-ced8-08d6230fa74a
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2018 17:52:25.6901 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4828
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-25_10:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809250176
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2018 19:12:48 -0000

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

DQo+IEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIG1vdGl2YXRpb24gZm9yIHVzaW5nIHVpbnQxNi4N
Cj4gVGhpcyB3b3VsZCBsaW1pdCB0aGUgbWF4aW11bSBwZXJpb2QgdG8gNjU1LjM1IHNlY29uZHMu
DQoNClRoYXQgd2FzIGEgdHlwbyAtIGl0IHNob3VsZCd2ZSBiZWVuIHVpbnQzMi4gIEZXSVcsIHdo
ZW4gSSBhZGRlZCB0aGUNCiJhbmNob3ItdGltZSIgdG8gdGhlIFtuZXRjb250L3Jlc3Rjb25mXS1j
bGllbnQtc2VydmVyIGRyYWZ0cywgSSB1c2VkICJwZXJpb2QiDQp3aXRoICJ0eXBlIHVpbnQxNiIg
YW5kICJ1bml0cyBtaW51dGVzIiwgd2hpY2ggaXMgd2hlcmUgdWludDE2IGNhbWUgZnJvbS4NCg0K
SSBzdGlsbCB0aGluayByZXBsYWNpbmcgInR5cGUgeWFuZzp0aW1ldGlja3MiIHdpdGggInR5cGUg
dW5pdDMyIiBhbmQgInVuaXRzDQpodW5kcmVkdGhzIG9mIGEgc2VjIiBpcyBtb3JlIGludHVpdGl2
ZSwgYXM6DQogIC0gbm8gbmVlZCB0byBsb29rIHVwIHdoYXQgYSB0aW1ldGljayBpcy4NCiAgLSBu
byBuZWVkIHRvIHVuZGVyc3RhbmQgd2h5IHRoZSB0d28gImVwb2NoIiB0aW1lcyBhcmVuJ3QgZG9j
dW1lbnRlZA0KICAgIGluIFlQLCBhcyByZXF1aXJlZCg/KSBieSBSRkMgNjk5MS4NCiAgLSBtb3Jl
IGNsb3NlbHkgYWxpZ25zIHdpdGggdGhlIFtuZXRjb250L3Jlc3Rjb25mXS1jbGllbnQtc2VydmVy
IGRyYWZ0cw0KDQpCdXQgaXQgd2FzIGp1c3QgYSBzdWdnZXN0aW9uLg0KDQpJIGFncmVlIHdpdGgg
dGhlIGNvbW1lbnQgdGhhdCBzb2Z0d2FyZSBjYW4gZWFzaWx5IGNvbnZlcnQgaHVuZHJlZHRocyBv
ZiBhDQpzZWNvbmQgdmFsdWVzIHRvIHRoaW5ncyBsaWtlICJtaW51dGVzIiBvciAiaG91cnMiLCBi
dXQgaG93IHdvdWxkIGl0IGtub3cNCndoZW4gdG8gZG8gc28/ICAgRXZlbiBpZiB0aGUgVUkgd2Fz
IGNsZXZlciBlbm91Z2ggdG8gZW5hYmxlIGFuIGFkbWluIHRvDQplbnRlciB0aGUgdmFsdWUgdXNp
bmcgdHdvIGZpZWxkcyAodmFsdWUgKyB1bml0cykgYW5kIHRoZSBzb2Z0d2FyZSBpbnRlcm5hbGx5
DQpjb252ZXJ0ZWQgdG8gaHVuZHJlZHRocyBvZiBhIHNlY29uZCwgaXQgZG9lc24ndCBoZWxwIGxh
dGVyIHdoZW4gYW5vdGhlciBVSQ0Kd2FudHMgdG8gbG9va3MgYXQgdGhlIHZhbHVlLCB1bmxlc3Mg
d2UgZXhwZWN0IGl0IHRvIHN0ZXAgdGhyb3VnaCBhIGJ1bmNoIG9mDQpjb21tb25seS11c2VkIHVu
aXRzIHVudGlsIGZpbmRpbmcgb25lIHRoYXQgZml0cyBuaWNlbHkuDQoNCkZXSVcsIHdlIGhhZCBh
IHNpbWlsYXIgZGlzY3Vzc2lvbiBhIGxvbmcgdGltZSBiYWNrIHdpdGggdGhlIG5ldGNvbmYtc2Vy
dmVyDQpkcmFmdCBidXQsIGF0IHRoYXQgdGltZSwgdGhlIG1pbmltdW0gZGVzaWduZWQgZ3JhbnVs
YXJpdHkgd2FzICJzZWNvbmRzIiwNCndoaWNoIHNlZW1lZCBva2F5IHNpbmNlIG1vc3QgcGVvcGxl
IGFyZSBwcmV0dHkgZmFtaWxpYXIgd2l0aCBob3cgc2Vjb25kcw0KY29udmVydCB0byBtaW51dGVz
IG9yIGhvdXJzIG9yIGRheXMuDQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0K

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj
b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u
Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mZ3Q7IEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIG1vdGl2YXRpb24gZm9y
IHVzaW5nIHVpbnQxNi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZndDsgVGhpcyB3b3VsZCBsaW1pdCB0aGUgbWF4aW11bSBwZXJpb2QgdG8gNjU1
LjM1IHNlY29uZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQg
d2FzIGEgdHlwbyAtIGl0IHNob3VsZCd2ZSBiZWVuIHVpbnQzMi4mbmJzcDsgRldJVywgd2hlbiBJ
IGFkZGVkIHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDth
bmNob3ItdGltZSZxdW90OyB0byB0aGUgW25ldGNvbnQvcmVzdGNvbmZdLWNsaWVudC1zZXJ2ZXIg
ZHJhZnRzLCBJIHVzZWQgJnF1b3Q7cGVyaW9kJnF1b3Q7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPndpdGggJnF1b3Q7dHlwZSB1aW50MTYmcXVvdDsgYW5kICZxdW90O3Vu
aXRzIG1pbnV0ZXMmcXVvdDssIHdoaWNoIGlzIHdoZXJlIHVpbnQxNiBjYW1lIGZyb20uPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkkgc3RpbGwgdGhpbmsgcmVwbGFjaW5nICZxdW90O3R5cGUgeWFu
Zzp0aW1ldGlja3MmcXVvdDsgd2l0aCAmcXVvdDt0eXBlIHVuaXQzMiZxdW90OyBhbmQgJnF1b3Q7
dW5pdHMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aHVuZHJlZHRocyBv
ZiBhIHNlYyZxdW90OyBpcyBtb3JlIGludHVpdGl2ZSwgYXM6PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgLSBubyBuZWVkIHRvIGxvb2sgdXAgd2hhdCBhIHRpbWV0
aWNrIGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0gbm8g
bmVlZCB0byB1bmRlcnN0YW5kIHdoeSB0aGUgdHdvICZxdW90O2Vwb2NoJnF1b3Q7IHRpbWVzIGFy
ZW4ndCBkb2N1bWVudGVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDsmbmJzcDsgJm5ic3A7aW4gWVAsIGFzIHJlcXVpcmVkKD8pIGJ5IFJGQyA2OTkxLjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0gbW9yZSBjbG9zZWx5IGFsaWdu
cyB3aXRoIHRoZSBbbmV0Y29udC9yZXN0Y29uZl0tY2xpZW50LXNlcnZlciBkcmFmdHM8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+QnV0IGl0IHdhcyBqdXN0IGEgc3VnZ2VzdGlvbi48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIHRoZSBjb21tZW50IHRoYXQgc29mdHdhcmUgY2Fu
IGVhc2lseSBjb252ZXJ0IGh1bmRyZWR0aHMgb2YgYQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5zZWNvbmQgdmFsdWVzIHRvIHRoaW5ncyBsaWtlICZxdW90O21pbnV0ZXMm
cXVvdDsgb3IgJnF1b3Q7aG91cnMmcXVvdDssIGJ1dCBob3cgd291bGQgaXQga25vdzxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hlbiB0byBkbyBzbz8mbmJzcDsmbmJzcDsg
RXZlbiBpZiB0aGUgVUkgd2FzIGNsZXZlciBlbm91Z2ggdG8gZW5hYmxlIGFuIGFkbWluIHRvDQo8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmVudGVyIHRoZSB2YWx1ZSB1c2lu
ZyB0d28gZmllbGRzICh2YWx1ZSAmIzQzOyB1bml0cykgYW5kIHRoZSBzb2Z0d2FyZSBpbnRlcm5h
bGx5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jb252ZXJ0ZWQgdG8gaHVu
ZHJlZHRocyBvZiBhIHNlY29uZCwgaXQgZG9lc24ndCBoZWxwIGxhdGVyIHdoZW4gYW5vdGhlciBV
STxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2FudHMgdG8gbG9va3MgYXQg
dGhlIHZhbHVlLCB1bmxlc3Mgd2UgZXhwZWN0IGl0IHRvIHN0ZXAgdGhyb3VnaCBhIGJ1bmNoIG9m
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jb21tb25seS11c2VkIHVuaXRz
IHVudGlsIGZpbmRpbmcgb25lIHRoYXQgZml0cyBuaWNlbHkuJm5ic3A7IDxvOnA+DQo8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkZXSVcsIHdlIGhhZCBhIHNpbWlsYXIgZGlzY3Vzc2lvbiBhIGxvbmcgdGlt
ZSBiYWNrIHdpdGggdGhlIG5ldGNvbmYtc2VydmVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5kcmFmdCBidXQsIGF0IHRoYXQgdGltZSwgdGhlIG1pbmltdW0gZGVzaWduZWQg
Z3JhbnVsYXJpdHkgd2FzICZxdW90O3NlY29uZHMmcXVvdDssDQo8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPndoaWNoIHNlZW1lZCBva2F5IHNpbmNlIG1vc3QgcGVvcGxlIGFy
ZSBwcmV0dHkgZmFtaWxpYXIgd2l0aCBob3cgc2Vjb25kczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Y29udmVydCB0byBtaW51dGVzIG9yIGhvdXJzIG9yIGRheXMuJm5ic3A7
IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZW50IC8vIGNvbnRyaWJ1dG9yPG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_674F5961D9564BD18AD044FE68150070junipernet_--


From nobody Tue Sep 25 13:48:09 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD61130DC8 for ; Tue, 25 Sep 2018 13:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 REDPBn_vPN1i for ; Tue, 25 Sep 2018 13:48:04 -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 40CA5124C04 for ; Tue, 25 Sep 2018 13:48:04 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id AA7293A270011 for ; Tue, 25 Sep 2018 21:47:57 +0100 (IST)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 25 Sep 2018 21:47:59 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.47]) by SJCEML702-CHM.china.huawei.com ([169.254.4.89]) with mapi id 14.03.0415.000; Tue, 25 Sep 2018 13:47:53 -0700
From: Alexander Clemm 
To: Kent Watsen , Andy Bierman , t.petch 
CC: Martin Bjorklund , Netconf 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImzU9I4weZMB0iH1L0LVTTudKUB7cYAgAAPiID//7pOoA==
Date: Tue, 25 Sep 2018 20:47:52 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6A205@sjceml521-mbx.china.huawei.com>
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net>
In-Reply-To: <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.35.95]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB6A205sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2018 20:48:07 -0000

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

SSB0aGluayB0aW1ldGlja3MgYXJlIGZhaXJseSBmYW1pbGFyIHRvIG1vc3QgcGVvcGxlLiAgQWxz
bywgSSB0aGluayBhIFVJIHVzZWQgYnkgaHVtYW5zIHRvIG1hbnVhbGx5IGNvbmZpZ3VyZSBzdWJz
Y3JpcHRpb25zIHdpbGwgYmUgb25seSBhIGNvcm5lciBjYXNlOyBpbiB0aGUgdmFzdCBtYWpvcml0
eSBvZiBjYXNlcyBJIHdvdWxkIGV4cGVjdCB0aGlzIHRvIGJlIGNvbnN1bWVkIGJ5IGFwcGxpY2F0
aW9ucyBhbmQgZmxvdy10aHJvdWdoIGludGVyZmFjZXMuDQotLS1BbGV4DQoNCkZyb206IEtlbnQg
V2F0c2VuIFttYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldF0NClNlbnQ6IFR1ZXNkYXksIFNlcHRl
bWJlciAyNSwgMjAxOCAxMDo1MiBBTQ0KVG86IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3Mu
Y29tPjsgdC5wZXRjaCA8aWV0ZmNAYnRjb25uZWN0LmNvbT4NCkNjOiBNYXJ0aW4gQmpvcmtsdW5k
IDxtYmpAdGFpbC1mLmNvbT47IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdl
aS5jb20+OyBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtOZXRjb25m
XSBtYmoncyBXR0xDIHJldmlldyBvZiB5YW5nLXB1c2gtMTcNCg0KDQo+IEkgZG8gbm90IHVuZGVy
c3RhbmQgdGhlIG1vdGl2YXRpb24gZm9yIHVzaW5nIHVpbnQxNi4NCj4gVGhpcyB3b3VsZCBsaW1p
dCB0aGUgbWF4aW11bSBwZXJpb2QgdG8gNjU1LjM1IHNlY29uZHMuDQoNClRoYXQgd2FzIGEgdHlw
byAtIGl0IHNob3VsZCd2ZSBiZWVuIHVpbnQzMi4gIEZXSVcsIHdoZW4gSSBhZGRlZCB0aGUNCiJh
bmNob3ItdGltZSIgdG8gdGhlIFtuZXRjb250L3Jlc3Rjb25mXS1jbGllbnQtc2VydmVyIGRyYWZ0
cywgSSB1c2VkICJwZXJpb2QiDQp3aXRoICJ0eXBlIHVpbnQxNiIgYW5kICJ1bml0cyBtaW51dGVz
Iiwgd2hpY2ggaXMgd2hlcmUgdWludDE2IGNhbWUgZnJvbS4NCg0KSSBzdGlsbCB0aGluayByZXBs
YWNpbmcgInR5cGUgeWFuZzp0aW1ldGlja3MiIHdpdGggInR5cGUgdW5pdDMyIiBhbmQgInVuaXRz
DQpodW5kcmVkdGhzIG9mIGEgc2VjIiBpcyBtb3JlIGludHVpdGl2ZSwgYXM6DQogIC0gbm8gbmVl
ZCB0byBsb29rIHVwIHdoYXQgYSB0aW1ldGljayBpcy4NCiAgLSBubyBuZWVkIHRvIHVuZGVyc3Rh
bmQgd2h5IHRoZSB0d28gImVwb2NoIiB0aW1lcyBhcmVuJ3QgZG9jdW1lbnRlZA0KICAgIGluIFlQ
LCBhcyByZXF1aXJlZCg/KSBieSBSRkMgNjk5MS4NCiAgLSBtb3JlIGNsb3NlbHkgYWxpZ25zIHdp
dGggdGhlIFtuZXRjb250L3Jlc3Rjb25mXS1jbGllbnQtc2VydmVyIGRyYWZ0cw0KDQpCdXQgaXQg
d2FzIGp1c3QgYSBzdWdnZXN0aW9uLg0KDQpJIGFncmVlIHdpdGggdGhlIGNvbW1lbnQgdGhhdCBz
b2Z0d2FyZSBjYW4gZWFzaWx5IGNvbnZlcnQgaHVuZHJlZHRocyBvZiBhDQpzZWNvbmQgdmFsdWVz
IHRvIHRoaW5ncyBsaWtlICJtaW51dGVzIiBvciAiaG91cnMiLCBidXQgaG93IHdvdWxkIGl0IGtu
b3cNCndoZW4gdG8gZG8gc28/ICAgRXZlbiBpZiB0aGUgVUkgd2FzIGNsZXZlciBlbm91Z2ggdG8g
ZW5hYmxlIGFuIGFkbWluIHRvDQplbnRlciB0aGUgdmFsdWUgdXNpbmcgdHdvIGZpZWxkcyAodmFs
dWUgKyB1bml0cykgYW5kIHRoZSBzb2Z0d2FyZSBpbnRlcm5hbGx5DQpjb252ZXJ0ZWQgdG8gaHVu
ZHJlZHRocyBvZiBhIHNlY29uZCwgaXQgZG9lc24ndCBoZWxwIGxhdGVyIHdoZW4gYW5vdGhlciBV
SQ0Kd2FudHMgdG8gbG9va3MgYXQgdGhlIHZhbHVlLCB1bmxlc3Mgd2UgZXhwZWN0IGl0IHRvIHN0
ZXAgdGhyb3VnaCBhIGJ1bmNoIG9mDQpjb21tb25seS11c2VkIHVuaXRzIHVudGlsIGZpbmRpbmcg
b25lIHRoYXQgZml0cyBuaWNlbHkuDQoNCkZXSVcsIHdlIGhhZCBhIHNpbWlsYXIgZGlzY3Vzc2lv
biBhIGxvbmcgdGltZSBiYWNrIHdpdGggdGhlIG5ldGNvbmYtc2VydmVyDQpkcmFmdCBidXQsIGF0
IHRoYXQgdGltZSwgdGhlIG1pbmltdW0gZGVzaWduZWQgZ3JhbnVsYXJpdHkgd2FzICJzZWNvbmRz
IiwNCndoaWNoIHNlZW1lZCBva2F5IHNpbmNlIG1vc3QgcGVvcGxlIGFyZSBwcmV0dHkgZmFtaWxp
YXIgd2l0aCBob3cgc2Vjb25kcw0KY29udmVydCB0byBtaW51dGVzIG9yIGhvdXJzIG9yIGRheXMu
DQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6d2luZG93dGV4
dDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJ
dmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv
cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl
OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv
cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy
NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh
cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+
DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv
bG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp
diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRpbWV0aWNrcyBhcmUgZmFpcmx5IGZhbWlsYXIg
dG8gbW9zdCBwZW9wbGUuJm5ic3A7IEFsc28sIEkgdGhpbmsgYSBVSSB1c2VkIGJ5IGh1bWFucyB0
byBtYW51YWxseSBjb25maWd1cmUgc3Vic2NyaXB0aW9ucyB3aWxsIGJlIG9ubHkgYSBjb3JuZXIg
Y2FzZTsgaW4gdGhlDQogdmFzdCBtYWpvcml0eSBvZiBjYXNlcyBJIHdvdWxkIGV4cGVjdCB0aGlz
IHRvIGJlIGNvbnN1bWVkIGJ5IGFwcGxpY2F0aW9ucyBhbmQgZmxvdy10aHJvdWdoIGludGVyZmFj
ZXMuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLS1BbGV4PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gS2VudCBXYXRz
ZW4gW21haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNk
YXksIFNlcHRlbWJlciAyNSwgMjAxOCAxMDo1MiBBTTxicj4NCjxiPlRvOjwvYj4gQW5keSBCaWVy
bWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7OyB0LnBldGNoICZsdDtpZXRmY0BidGNvbm5l
Y3QuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFydGluIEJqb3JrbHVuZCAmbHQ7bWJqQHRhaWwt
Zi5jb20mZ3Q7OyBBbGV4YW5kZXIgQ2xlbW0gJmx0O2FsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29t
Jmd0OzsgTmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUmU6IFtOZXRjb25mXSBtYmoncyBXR0xDIHJldmlldyBvZiB5YW5nLXB1c2gtMTc8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jmd0OyBJIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSBtb3RpdmF0aW9uIGZvciB1c2luZyB1
aW50MTYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mZ3Q7IFRoaXMgd291bGQgbGltaXQgdGhlIG1heGltdW0gcGVyaW9kIHRvIDY1NS4zNSBzZWNv
bmRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHdhcyBhIHR5
cG8gLSBpdCBzaG91bGQndmUgYmVlbiB1aW50MzIuJm5ic3A7IEZXSVcsIHdoZW4gSSBhZGRlZCB0
aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7YW5jaG9yLXRp
bWUmcXVvdDsgdG8gdGhlIFtuZXRjb250L3Jlc3Rjb25mXS1jbGllbnQtc2VydmVyIGRyYWZ0cywg
SSB1c2VkICZxdW90O3BlcmlvZCZxdW90Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj53aXRoICZxdW90O3R5cGUgdWludDE2JnF1b3Q7IGFuZCAmcXVvdDt1bml0cyBtaW51
dGVzJnF1b3Q7LCB3aGljaCBpcyB3aGVyZSB1aW50MTYgY2FtZSBmcm9tLjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5JIHN0aWxsIHRoaW5rIHJlcGxhY2luZyAmcXVvdDt0eXBlIHlhbmc6dGltZXRp
Y2tzJnF1b3Q7IHdpdGggJnF1b3Q7dHlwZSB1bml0MzImcXVvdDsgYW5kICZxdW90O3VuaXRzDQo8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmh1bmRyZWR0aHMgb2YgYSBzZWMm
cXVvdDsgaXMgbW9yZSBpbnR1aXRpdmUsIGFzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7IC0gbm8gbmVlZCB0byBsb29rIHVwIHdoYXQgYSB0aW1ldGljayBpcy48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAtIG5vIG5lZWQgdG8g
dW5kZXJzdGFuZCB3aHkgdGhlIHR3byAmcXVvdDtlcG9jaCZxdW90OyB0aW1lcyBhcmVuJ3QgZG9j
dW1lbnRlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7
ICZuYnNwO2luIFlQLCBhcyByZXF1aXJlZCg/KSBieSBSRkMgNjk5MS48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAtIG1vcmUgY2xvc2VseSBhbGlnbnMgd2l0aCB0
aGUgW25ldGNvbnQvcmVzdGNvbmZdLWNsaWVudC1zZXJ2ZXIgZHJhZnRzPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkJ1dCBpdCB3YXMganVzdCBhIHN1Z2dlc3Rpb24uPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkkgYWdyZWUgd2l0aCB0aGUgY29tbWVudCB0aGF0IHNvZnR3YXJlIGNhbiBlYXNpbHkg
Y29udmVydCBodW5kcmVkdGhzIG9mIGENCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+c2Vjb25kIHZhbHVlcyB0byB0aGluZ3MgbGlrZSAmcXVvdDttaW51dGVzJnF1b3Q7IG9y
ICZxdW90O2hvdXJzJnF1b3Q7LCBidXQgaG93IHdvdWxkIGl0IGtub3c8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPndoZW4gdG8gZG8gc28/Jm5ic3A7Jm5ic3A7IEV2ZW4gaWYg
dGhlIFVJIHdhcyBjbGV2ZXIgZW5vdWdoIHRvIGVuYWJsZSBhbiBhZG1pbiB0bw0KPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5lbnRlciB0aGUgdmFsdWUgdXNpbmcgdHdvIGZp
ZWxkcyAodmFsdWUgJiM0MzsgdW5pdHMpIGFuZCB0aGUgc29mdHdhcmUgaW50ZXJuYWxseTxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29udmVydGVkIHRvIGh1bmRyZWR0aHMg
b2YgYSBzZWNvbmQsIGl0IGRvZXNuJ3QgaGVscCBsYXRlciB3aGVuIGFub3RoZXIgVUk8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndhbnRzIHRvIGxvb2tzIGF0IHRoZSB2YWx1
ZSwgdW5sZXNzIHdlIGV4cGVjdCBpdCB0byBzdGVwIHRocm91Z2ggYSBidW5jaCBvZjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29tbW9ubHktdXNlZCB1bml0cyB1bnRpbCBm
aW5kaW5nIG9uZSB0aGF0IGZpdHMgbmljZWx5LiZuYnNwOyA8bzpwPg0KPC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5GV0lXLCB3ZSBoYWQgYSBzaW1pbGFyIGRpc2N1c3Npb24gYSBsb25nIHRpbWUgYmFjayB3
aXRoIHRoZSBuZXRjb25mLXNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+ZHJhZnQgYnV0LCBhdCB0aGF0IHRpbWUsIHRoZSBtaW5pbXVtIGRlc2lnbmVkIGdyYW51bGFy
aXR5IHdhcyAmcXVvdDtzZWNvbmRzJnF1b3Q7LA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj53aGljaCBzZWVtZWQgb2theSBzaW5jZSBtb3N0IHBlb3BsZSBhcmUgcHJldHR5
IGZhbWlsaWFyIHdpdGggaG93IHNlY29uZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPmNvbnZlcnQgdG8gbWludXRlcyBvciBob3VycyBvciBkYXlzLiZuYnNwOyA8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+S2VudCAvLyBjb250cmlidXRvcjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB6A205sjceml521mbxchi_--


From nobody Tue Sep 25 14:19:41 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A2F1277BB for ; Tue, 25 Sep 2018 14:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 GFrpx0T9fNat for ; Tue, 25 Sep 2018 14:19:37 -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 5420E130DC6 for ; Tue, 25 Sep 2018 14:19:36 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8PLJSwP020721; Tue, 25 Sep 2018 14:19:28 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=0dHAVTNRcjWsURiZUIXCwW43TayCIylYfIG9CIdBpuk=; b=PYcoKoaROJV3n7HIWUxsMkLAuEqh3OwetWAl154pNjn4+asGV2W1up3PZlL3tMNuEHdW UHemeWYfcTHAsxfqfbQeXon26h5cjZuYTwCzlbFcEOoVyuh7kXx28TY3DH4Ucof4g1eD 3/STKJLAgi9RBB0shy7mDAdfoCRZIgI6KILOcJi+3lvQG/kWNG+OJhJT1kNeaFNx6a0w kZwfbiKtsVTTKKOYm6Jn9EcLK2wnkc7ruck/IO6cRlxiLbAU5C17qpJxxUYsUhadcEdP aUu6X1BH9ksmKIb6kn2CIh+1djhQNmxdCJRzqt2by6W5L6JAyV6F4dTTaDFy6R+MiZtM lQ== 
Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp0088.outbound.protection.outlook.com [216.32.180.88]) by mx0b-00273201.pphosted.com with ESMTP id 2mqv9fg1w5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 25 Sep 2018 14:19:28 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4076.namprd05.prod.outlook.com (20.176.72.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.12; Tue, 25 Sep 2018 21:19:26 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%3]) with mapi id 15.20.1185.014; Tue, 25 Sep 2018 21:19:26 +0000
From: Kent Watsen 
To: Alexander Clemm , Andy Bierman , t.petch 
CC: Martin Bjorklund , Netconf 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImouJGUP0t9tESR9VzM68tuEKUBeG0A///MeoCAAHQTAP//xcOA
Date: Tue, 25 Sep 2018 21:19:26 +0000
Message-ID: <9EC8B411-34A3-4E68-B4B7-41376F4FC2D7@juniper.net>
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6A205@sjceml521-mbx.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6A205@sjceml521-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4076; 6:SKytsLpnVAKw/u/82nMSjVlV5sSTIGG+FveM9IkP27paIghwdmk/YIOPW7VtM7r/nPScAIPbZv7js4YHbv11rzsVdSpdF5R7U6IkVgBoJlLDCbfjcQtArtfEFg7+tfZiYSCRCLzI6uhAr57Y4+tG2QWXRlAwPw+xlIi0tqgqX7Hq6tLcdiGCA9DlGsjLbWT3HmJPhyT4HRqxURpDtq8jSysKKxj665eOditlfezzj3IP9tOLGt007ULydtrX7eeip/QXvLbbkIfXemVfVHPUrXxjl9Jf6PugJHBs91xBg9tDP8bXyRMy3Xqivimaa+O9L2NmNOb5XvSiVs7CB537EXYjmkFZ6YRPJBGvJpvUYxoU60XIFnX0HtB6Jj72a9WTIgQbZ5gCj2ofUhrNQzOc6tpw7b7VM9XXXibsQqt0/Ycdt0Za5KFvVVYR86f0m1rk4gmZDB6PYOOXhzLcExfgHA==; 5:4alMQEqlLvyJR7BDosY2EOd+m6JpI+FsfaB4BEcbhjDbPxgGcwpyfCPwS4SuNEbCcitS3QdJ89ENyWeEr/m/50CudSw41VzxrJqXtoL+Oxq+kALYrro+fhSBnKK9hwyQLG5yfiKIg44VROEkGk8hU3XZokFcaZ6jMzGD9JHdrh8=; 7:2eLMChuUbWBPx1KYAfPLD3ZvEG/wJ9IAelOjnw8o3NvGRcf0kTN/KXHJJnzE0VzPKXRClwws8MkAJoyQPQpeKecpcPHo+zMZhUUubxefzCza06dN0CvgsdeOaNW44Svm8XRw1+cb8CQOq+Hy2GQ3Ab9emxWGz9yHWSIFVE1smEPU3pEJlWGnp40hwTMAH+3N9rsJ8RGMl/H/wxkcBhP/8JIulQDCJxYcBYh5et3uBxO7jHLEWeWj9+ZWhRH7Ptn4
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 0690eb75-bf7a-474a-d4f4-08d6232c92af
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4076; 
x-ms-traffictypediagnostic: DM6PR05MB4076:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(50582790962513)(278428928389397)(138986009662008)(178726229863574)(219612443155931)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149066)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051); SRVR:DM6PR05MB4076; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4076; 
x-forefront-prvs: 08062C429B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(376002)(366004)(136003)(39860400002)(199004)(189003)(81156014)(186003)(99286004)(476003)(26005)(53546011)(102836004)(2616005)(71200400001)(58126008)(54906003)(110136005)(66066001)(6506007)(71190400001)(316002)(82746002)(93886005)(11346002)(2900100001)(446003)(83716004)(486006)(34290500001)(229853002)(6306002)(2906002)(6436002)(54896002)(3846002)(236005)(6116002)(5660300001)(6512007)(76176011)(6486002)(5250100002)(25786009)(68736007)(4326008)(53936002)(7736002)(86362001)(256004)(14444005)(8936002)(6246003)(478600001)(36756003)(33656002)(81166006)(106356001)(105586002)(97736004)(14454004)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4076; H:DM6PR05MB4665.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-microsoft-antispam-message-info: 4tugg2oi+UDI+e3wlytoLK2EQE1m/IXdYOrcmAcm52mABPorrdLa6tZmP3mUMc/TJYgyliMbr9IDy5wcNQyF4orIn+muyPkgCYLAheY4gDTezMDejevjBzC1qxgeJq9xlmgdXbzI5b73Z+9aAWEzuQNyOdKxrb6JVwrO932E4fZUlQA5qNWQN7FX0PSSK4l2DDJhFpf1SFIRcR3Jq/OWBzCZcS4gwe8d8LsH7eEd6zyw/qLyZ7oa//94rHvRW/raduzIvz5MAXOkwFxw9KR1SUQq9QKL5MKKvgsjvJj2cC112NxNJ9ymMT/KTIbOMuMSAIvndsqkV0vZbwh1mTXsXAOj+kGw1nfSQxbgK+MB38w=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_9EC8B41134A34E68B4B741376F4FC2D7junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 0690eb75-bf7a-474a-d4f4-08d6232c92af
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2018 21:19:26.5408 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4076
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-25_11:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809250209
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2018 21:19:41 -0000

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

dGhhdCdzIGEgZ29vZCBwb2ludCwgYSBVSSB3b3VsZG4ndCBiZSB1c2VkIGZvciBtb3JlIHRoYW4g
YSBoYW5kZnVsIG9mIHN1YnNjcmlwdGlvbnMuDQoNCi9rdw0KDQoNCk9uIDkvMjUvMTgsIDQ6NDcg
UE0sICJBbGV4YW5kZXIgQ2xlbW0iIDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbTxtYWlsdG86
YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSSB0aGluayB0aW1ldGlja3Mg
YXJlIGZhaXJseSBmYW1pbGFyIHRvIG1vc3QgcGVvcGxlLiAgQWxzbywgSSB0aGluayBhIFVJIHVz
ZWQgYnkgaHVtYW5zIHRvIG1hbnVhbGx5IGNvbmZpZ3VyZSBzdWJzY3JpcHRpb25zIHdpbGwgYmUg
b25seSBhIGNvcm5lciBjYXNlOyBpbiB0aGUgdmFzdCBtYWpvcml0eSBvZiBjYXNlcyBJIHdvdWxk
IGV4cGVjdCB0aGlzIHRvIGJlIGNvbnN1bWVkIGJ5IGFwcGxpY2F0aW9ucyBhbmQgZmxvdy10aHJv
dWdoIGludGVyZmFjZXMuDQotLS1BbGV4DQoNCkZyb206IEtlbnQgV2F0c2VuIFttYWlsdG86a3dh
dHNlbkBqdW5pcGVyLm5ldF0NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyNSwgMjAxOCAxMDo1
MiBBTQ0KVG86IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPjsgdC5wZXRjaCA8aWV0
ZmNAYnRjb25uZWN0LmNvbT4NCkNjOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT47
IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+OyBOZXRjb25mIDxu
ZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBtYmoncyBXR0xDIHJldmll
dyBvZiB5YW5nLXB1c2gtMTcNCg0KDQo+IEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIG1vdGl2YXRp
b24gZm9yIHVzaW5nIHVpbnQxNi4NCj4gVGhpcyB3b3VsZCBsaW1pdCB0aGUgbWF4aW11bSBwZXJp
b2QgdG8gNjU1LjM1IHNlY29uZHMuDQoNClRoYXQgd2FzIGEgdHlwbyAtIGl0IHNob3VsZCd2ZSBi
ZWVuIHVpbnQzMi4gIEZXSVcsIHdoZW4gSSBhZGRlZCB0aGUNCiJhbmNob3ItdGltZSIgdG8gdGhl
IFtuZXRjb250L3Jlc3Rjb25mXS1jbGllbnQtc2VydmVyIGRyYWZ0cywgSSB1c2VkICJwZXJpb2Qi
DQp3aXRoICJ0eXBlIHVpbnQxNiIgYW5kICJ1bml0cyBtaW51dGVzIiwgd2hpY2ggaXMgd2hlcmUg
dWludDE2IGNhbWUgZnJvbS4NCg0KSSBzdGlsbCB0aGluayByZXBsYWNpbmcgInR5cGUgeWFuZzp0
aW1ldGlja3MiIHdpdGggInR5cGUgdW5pdDMyIiBhbmQgInVuaXRzDQpodW5kcmVkdGhzIG9mIGEg
c2VjIiBpcyBtb3JlIGludHVpdGl2ZSwgYXM6DQogIC0gbm8gbmVlZCB0byBsb29rIHVwIHdoYXQg
YSB0aW1ldGljayBpcy4NCiAgLSBubyBuZWVkIHRvIHVuZGVyc3RhbmQgd2h5IHRoZSB0d28gImVw
b2NoIiB0aW1lcyBhcmVuJ3QgZG9jdW1lbnRlZA0KICAgIGluIFlQLCBhcyByZXF1aXJlZCg/KSBi
eSBSRkMgNjk5MS4NCiAgLSBtb3JlIGNsb3NlbHkgYWxpZ25zIHdpdGggdGhlIFtuZXRjb250L3Jl
c3Rjb25mXS1jbGllbnQtc2VydmVyIGRyYWZ0cw0KDQpCdXQgaXQgd2FzIGp1c3QgYSBzdWdnZXN0
aW9uLg0KDQpJIGFncmVlIHdpdGggdGhlIGNvbW1lbnQgdGhhdCBzb2Z0d2FyZSBjYW4gZWFzaWx5
IGNvbnZlcnQgaHVuZHJlZHRocyBvZiBhDQpzZWNvbmQgdmFsdWVzIHRvIHRoaW5ncyBsaWtlICJt
aW51dGVzIiBvciAiaG91cnMiLCBidXQgaG93IHdvdWxkIGl0IGtub3cNCndoZW4gdG8gZG8gc28/
ICAgRXZlbiBpZiB0aGUgVUkgd2FzIGNsZXZlciBlbm91Z2ggdG8gZW5hYmxlIGFuIGFkbWluIHRv
DQplbnRlciB0aGUgdmFsdWUgdXNpbmcgdHdvIGZpZWxkcyAodmFsdWUgKyB1bml0cykgYW5kIHRo
ZSBzb2Z0d2FyZSBpbnRlcm5hbGx5DQpjb252ZXJ0ZWQgdG8gaHVuZHJlZHRocyBvZiBhIHNlY29u
ZCwgaXQgZG9lc24ndCBoZWxwIGxhdGVyIHdoZW4gYW5vdGhlciBVSQ0Kd2FudHMgdG8gbG9va3Mg
YXQgdGhlIHZhbHVlLCB1bmxlc3Mgd2UgZXhwZWN0IGl0IHRvIHN0ZXAgdGhyb3VnaCBhIGJ1bmNo
IG9mDQpjb21tb25seS11c2VkIHVuaXRzIHVudGlsIGZpbmRpbmcgb25lIHRoYXQgZml0cyBuaWNl
bHkuDQoNCkZXSVcsIHdlIGhhZCBhIHNpbWlsYXIgZGlzY3Vzc2lvbiBhIGxvbmcgdGltZSBiYWNr
IHdpdGggdGhlIG5ldGNvbmYtc2VydmVyDQpkcmFmdCBidXQsIGF0IHRoYXQgdGltZSwgdGhlIG1p
bmltdW0gZGVzaWduZWQgZ3JhbnVsYXJpdHkgd2FzICJzZWNvbmRzIiwNCndoaWNoIHNlZW1lZCBv
a2F5IHNpbmNlIG1vc3QgcGVvcGxlIGFyZSBwcmV0dHkgZmFtaWxpYXIgd2l0aCBob3cgc2Vjb25k
cw0KY29udmVydCB0byBtaW51dGVzIG9yIGhvdXJzIG9yIGRheXMuDQoNCktlbnQgLy8gY29udHJp
YnV0b3INCg0K

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh
bWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3
aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUg
bm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw
bHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRh
bnQ7DQoJY29sb3I6d2luZG93dGV4dDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVj
b3JhdGlvbjpub25lIG5vbmU7DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5tc29J
bnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJ
dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh
Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp
biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMi
IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj50
aGF0J3MgYSBnb29kIHBvaW50LCBhIFVJIHdvdWxkbid0IGJlIHVzZWQgZm9yIG1vcmUgdGhhbiBh
IGhhbmRmdWwgb2Ygc3Vic2NyaXB0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OkNhbGlicmkiPi9rdzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA5LzI1LzE4LCA0OjQ3IFBNLCAmcXVvdDtBbGV4YW5k
ZXIgQ2xlbW0mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2Vp
LmNvbSI+YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+SSB0
aGluayB0aW1ldGlja3MgYXJlIGZhaXJseSBmYW1pbGFyIHRvIG1vc3QgcGVvcGxlLiZuYnNwOyBB
bHNvLCBJIHRoaW5rIGEgVUkgdXNlZCBieSBodW1hbnMgdG8gbWFudWFsbHkgY29uZmlndXJlIHN1
YnNjcmlwdGlvbnMgd2lsbCBiZSBvbmx5IGEgY29ybmVyIGNhc2U7IGluIHRoZSB2YXN0IG1ham9y
aXR5DQogb2YgY2FzZXMgSSB3b3VsZCBleHBlY3QgdGhpcyB0byBiZSBjb25zdW1lZCBieSBhcHBs
aWNhdGlvbnMgYW5kIGZsb3ctdGhyb3VnaCBpbnRlcmZhY2VzLiAmbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPi0tLUFsZXg8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiBLZW50IFdhdHNl
biBbbWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2Rh
eSwgU2VwdGVtYmVyIDI1LCAyMDE4IDEwOjUyIEFNPGJyPg0KPGI+VG86PC9iPiBBbmR5IEJpZXJt
YW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDs7IHQucGV0Y2ggJmx0O2lldGZjQGJ0Y29ubmVj
dC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYXJ0aW4gQmpvcmtsdW5kICZsdDttYmpAdGFpbC1m
LmNvbSZndDs7IEFsZXhhbmRlciBDbGVtbSAmbHQ7YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20m
Z3Q7OyBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i
PiBSZTogW05ldGNvbmZdIG1iaidzIFdHTEMgcmV2aWV3IG9mIHlhbmctcHVzaC0xNzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJIGRvIG5vdCB1bmRl
cnN0YW5kIHRoZSBtb3RpdmF0aW9uIGZvciB1c2luZyB1aW50MTYuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFRoaXMgd291bGQgbGltaXQg
dGhlIG1heGltdW0gcGVyaW9kIHRvIDY1NS4zNSBzZWNvbmRzLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHdhcyBhIHR5cG8gLSBpdCBzaG91bGQndmUgYmVlbiB1
aW50MzIuJm5ic3A7IEZXSVcsIHdoZW4gSSBhZGRlZCB0aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7YW5jaG9yLXRpbWUmcXVvdDsgdG8gdGhlIFtuZXRjb250
L3Jlc3Rjb25mXS1jbGllbnQtc2VydmVyIGRyYWZ0cywgSSB1c2VkICZxdW90O3BlcmlvZCZxdW90
Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aXRoICZxdW90O3R5cGUg
dWludDE2JnF1b3Q7IGFuZCAmcXVvdDt1bml0cyBtaW51dGVzJnF1b3Q7LCB3aGljaCBpcyB3aGVy
ZSB1aW50MTYgY2FtZSBmcm9tLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN0aWxsIHRoaW5r
IHJlcGxhY2luZyAmcXVvdDt0eXBlIHlhbmc6dGltZXRpY2tzJnF1b3Q7IHdpdGggJnF1b3Q7dHlw
ZSB1bml0MzImcXVvdDsgYW5kICZxdW90O3VuaXRzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPmh1bmRyZWR0aHMgb2YgYSBzZWMmcXVvdDsgaXMgbW9yZSBpbnR1aXRpdmUs
IGFzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0gbm8gbmVl
ZCB0byBsb29rIHVwIHdoYXQgYSB0aW1ldGljayBpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOyAtIG5vIG5lZWQgdG8gdW5kZXJzdGFuZCB3aHkgdGhlIHR3byAm
cXVvdDtlcG9jaCZxdW90OyB0aW1lcyBhcmVuJ3QgZG9jdW1lbnRlZDxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7ICZuYnNwO2luIFlQLCBhcyByZXF1aXJl
ZCg/KSBieSBSRkMgNjk5MS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOyAtIG1vcmUgY2xvc2VseSBhbGlnbnMgd2l0aCB0aGUgW25ldGNvbnQvcmVzdGNvbmZdLWNs
aWVudC1zZXJ2ZXIgZHJhZnRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBpdCB3YXMganVz
dCBhIHN1Z2dlc3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgd2l0aCB0aGUg
Y29tbWVudCB0aGF0IHNvZnR3YXJlIGNhbiBlYXNpbHkgY29udmVydCBodW5kcmVkdGhzIG9mIGEN
CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2Vjb25kIHZhbHVlcyB0byB0
aGluZ3MgbGlrZSAmcXVvdDttaW51dGVzJnF1b3Q7IG9yICZxdW90O2hvdXJzJnF1b3Q7LCBidXQg
aG93IHdvdWxkIGl0IGtub3c8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndo
ZW4gdG8gZG8gc28/Jm5ic3A7Jm5ic3A7IEV2ZW4gaWYgdGhlIFVJIHdhcyBjbGV2ZXIgZW5vdWdo
IHRvIGVuYWJsZSBhbiBhZG1pbiB0bw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5lbnRlciB0aGUgdmFsdWUgdXNpbmcgdHdvIGZpZWxkcyAodmFsdWUgJiM0MzsgdW5pdHMp
IGFuZCB0aGUgc29mdHdhcmUgaW50ZXJuYWxseTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Y29udmVydGVkIHRvIGh1bmRyZWR0aHMgb2YgYSBzZWNvbmQsIGl0IGRvZXNuJ3Qg
aGVscCBsYXRlciB3aGVuIGFub3RoZXIgVUk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPndhbnRzIHRvIGxvb2tzIGF0IHRoZSB2YWx1ZSwgdW5sZXNzIHdlIGV4cGVjdCBpdCB0
byBzdGVwIHRocm91Z2ggYSBidW5jaCBvZjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Y29tbW9ubHktdXNlZCB1bml0cyB1bnRpbCBmaW5kaW5nIG9uZSB0aGF0IGZpdHMgbmlj
ZWx5LiZuYnNwOyA8bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GV0lXLCB3ZSBoYWQgYSBzaW1p
bGFyIGRpc2N1c3Npb24gYSBsb25nIHRpbWUgYmFjayB3aXRoIHRoZSBuZXRjb25mLXNlcnZlcjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZHJhZnQgYnV0LCBhdCB0aGF0IHRp
bWUsIHRoZSBtaW5pbXVtIGRlc2lnbmVkIGdyYW51bGFyaXR5IHdhcyAmcXVvdDtzZWNvbmRzJnF1
b3Q7LA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aGljaCBzZWVtZWQg
b2theSBzaW5jZSBtb3N0IHBlb3BsZSBhcmUgcHJldHR5IGZhbWlsaWFyIHdpdGggaG93IHNlY29u
ZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNvbnZlcnQgdG8gbWludXRl
cyBvciBob3VycyBvciBkYXlzLiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VudCAv
LyBjb250cmlidXRvcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_9EC8B41134A34E68B4B741376F4FC2D7junipernet_--


From nobody Tue Sep 25 14:31:54 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C32A130DCA for ; Tue, 25 Sep 2018 14:31:52 -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 h7MXBMUxqWp7 for ; Tue, 25 Sep 2018 14:31:49 -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 2D55C130DD0 for ; Tue, 25 Sep 2018 14:31:49 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7D2A1E21; Tue, 25 Sep 2018 23:31:47 +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 WRs-G5tp1RLh; Tue, 25 Sep 2018 23:31:47 +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, 25 Sep 2018 23:31:47 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3DA6020035; Tue, 25 Sep 2018 23:31:47 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LphUojAgbBYo; Tue, 25 Sep 2018 23:31:46 +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 "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id DCFF620031; Tue, 25 Sep 2018 23:31:46 +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.1415.2; Tue, 25 Sep 2018 23:31:46 +0200
Received: by anna.localdomain (Postfix, from userid 501) id A5E722551463; Tue, 25 Sep 2018 23:31:45 +0200 (CEST)
Date: Tue, 25 Sep 2018 23:31:45 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
CC: Netconf 
Message-ID: <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , Netconf 
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net>
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] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2018 21:31:52 -0000

On Tue, Sep 25, 2018 at 05:52:25PM +0000, Kent Watsen wrote:
> 
> I still think replacing "type yang:timeticks" with "type unit32" and "units
> hundredths of a sec" is more intuitive, as:
>   - no need to look up what a timetick is.
>   - no need to understand why the two "epoch" times aren't documented
>     in YP, as required(?) by RFC 6991.
>   - more closely aligns with the [netcont/restconf]-client-server drafts

It seems the type you want for the 'period' leafs in your ID is not
timeticks but an equivalent of RFC 2579's TimeInterval:

TimeInterval ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "A period of time, measured in units of 0.01 seconds."
    SYNTAX       INTEGER (0..2147483647)

I am somewhat surprised we do not have something matching the
TimeInterval TC in RFC 6991, I do not recall why.

The TimeTicks TC (and hence the timeticks YANG type) represents time
that ticks. The classic example is sysUpTime - sysUpTime has a new
value whenever you read it since it constantly ticks. Hence, the
timeticks type is pretty useless for configuration objects.

If you roll your own type, perhaps you want a type like this:

  type centiseconds {
    type uint32;
    description
      "A period of time, measured in units of 0.01 seconds.";
  }

With this, you would get something more descriptive:

          leaf period {
            type centiseconds;
            mandatory true;
            description
              "Duration of time which should occur between periodic
               push updates.";
          }

/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 Sep 25 15:11:42 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45386130DDA for ; Tue, 25 Sep 2018 15:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v4nVmc9-vjk for ; Tue, 25 Sep 2018 15:11:38 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB4F1277BB for ; Tue, 25 Sep 2018 15:11:38 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id j25-v6so3253651ljg.2 for ; Tue, 25 Sep 2018 15:11:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=OS+bdluSlEHabb0fvO9XAjyNxyEFq9W2Wb8jUlqoRsM=; b=yQuT6d2O3CVGCJdSWQPuS4Q08PnX34KNe52gCTxW+ldgw/m5iDR6HbBagQL1J6L6rh NJMHcWJKt4kcLVj1LBrOuEeTE4YKLCWIQNzMi6lQk1N7HATaeFh6FVi8sSgR88ZjXGCl ArneAoF3c4EMZsD9Yp+/0zztUGVxCerEM0x/mdqxlVV6mdad15huN2tLbGAw0KxPstBb 2GApzFF+OEMRbvCsVyYbdtH985BhQoFip9QTajYQFDszH056ZVQYnpj9jKdxWANhXQVn XtkpNfeVmUuAKJPlY9zelcn8JEGuUHbOWKo43RNgsoh5K47KNZZHBgtD5OuCRx406l9p PCgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=OS+bdluSlEHabb0fvO9XAjyNxyEFq9W2Wb8jUlqoRsM=; b=VU2wYJx4Lur2MLEoNiuegrymsiV4TBiar2n3R2zWnpO1WUMRUxwfCNU4qvv+1TBUbk Labs2IWslebvJr3iwB1bOd9fVUMR1vTI8Bkqo4Y8bayyOpzd/SyEpDhH+uX2+RQfZZ5y k9G+WtQOiIh9GMITr0ihwWISAc1BMvnFQ17wKx/h0eqdc5pZIQQL3/Jarp6nHPAjbqzK Mqartj2ZBn+BhXCR1t+1azt7kmoOZXOMy7UZcERzWlYE7875izYuyYCk5rkPU7G7q0Id VJeegNQtvxw2ixtsgV36me91OG9rTZcU9RLLjVuNk24/1m6n1wqwKDdqxX1boO6BODV7 hB7Q==
X-Gm-Message-State: ABuFfog/eBgrVMWeeLjmeOZmB/bYJlyqaEkEyD85Rps/f6dCOlUZlYEd Ol4HwlTZ9qzYAPeMvrAUZbFm5FBoR+VICighxhop0A==
X-Google-Smtp-Source: ACcGV61Tpb8f2B3J2WuXPa9YNhcsqezZ1LG3sQ0uSOfkP/O/Gpspf0vUadi07obbMtftBZXV+MGZsboTYB7347k4J7E=
X-Received: by 2002:a2e:9c89:: with SMTP id x9-v6mr2445783lji.110.1537913496036;  Tue, 25 Sep 2018 15:11:36 -0700 (PDT)
MIME-Version: 1.0
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net> <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Tue, 25 Sep 2018 15:11:24 -0700
Message-ID: 
To: Juergen Schoenwaelder , Kent Watsen , Netconf 
Content-Type: multipart/alternative; boundary="000000000000a082e80576b963cb"
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2018 22:11:41 -0000

--000000000000a082e80576b963cb
Content-Type: text/plain; charset="UTF-8"

On Tue, Sep 25, 2018 at 2:32 PM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Tue, Sep 25, 2018 at 05:52:25PM +0000, Kent Watsen wrote:
> >
> > I still think replacing "type yang:timeticks" with "type unit32" and
> "units
> > hundredths of a sec" is more intuitive, as:
> >   - no need to look up what a timetick is.
> >   - no need to understand why the two "epoch" times aren't documented
> >     in YP, as required(?) by RFC 6991.
> >   - more closely aligns with the [netcont/restconf]-client-server drafts
>
> It seems the type you want for the 'period' leafs in your ID is not
> timeticks but an equivalent of RFC 2579's TimeInterval:
>
> TimeInterval ::= TEXTUAL-CONVENTION
>     STATUS       current
>     DESCRIPTION
>             "A period of time, measured in units of 0.01 seconds."
>     SYNTAX       INTEGER (0..2147483647)
>
> I am somewhat surprised we do not have something matching the
> TimeInterval TC in RFC 6991, I do not recall why.
>
> The TimeTicks TC (and hence the timeticks YANG type) represents time
> that ticks. The classic example is sysUpTime - sysUpTime has a new
> value whenever you read it since it constantly ticks. Hence, the
> timeticks type is pretty useless for configuration objects.
>
> If you roll your own type, perhaps you want a type like this:
>
>   type centiseconds {
>     type uint32;
>     description
>       "A period of time, measured in units of 0.01 seconds.";
>   }
>
>

I like this approach, but maybe it would be better to follow the timeticks
example

   typedef time-interval {
      type uint32;
      units "hundredths of a second";  // ?
      description
          "A period of time, measured in units of 0.01 seconds.";
       reference
            "RFC 2579: Textual Conventions for SMIv2";
   }

Andy



> With this, you would get something more descriptive:
>
>           leaf period {
>             type centiseconds;
>             mandatory true;
>             description
>               "Duration of time which should occur between periodic
>                push updates.";
>           }
>
> /js
>
> --
> 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
>

--000000000000a082e80576b963cb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, Sep 25, 2018 at 2:32 PM Juergen Schoenwaelder <j.schoenwaelder@jacobs-un=
iversity.de> wrote:
On Tue, Sep 25, 2018 at 05:52:25PM +0000, Kent Watsen wrote:

> 

> I still think replacing "type yang:timeticks" with "typ=
e unit32" and "units

> hundredths of a sec" is more intuitive, as:

>=C2=A0 =C2=A0- no need to look up what a timetick is.

>=C2=A0 =C2=A0- no need to understand why the two "epoch" time=
s aren't documented

>=C2=A0 =C2=A0 =C2=A0in YP, as required(?) by RFC 6991.

>=C2=A0 =C2=A0- more closely aligns with the [netcont/restconf]-client-s=
erver drafts



It seems the type you want for the 'period' leafs in your ID is not=


timeticks but an equivalent of RFC 2579's TimeInterval:



TimeInterval ::=3D TEXTUAL-CONVENTION

=C2=A0 =C2=A0 STATUS=C2=A0 =C2=A0 =C2=A0 =C2=A0current

=C2=A0 =C2=A0 DESCRIPTION

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "A period of time, measured =
in units of 0.01 seconds."

=C2=A0 =C2=A0 SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2=A0INTEGER (0..2147483647)



I am somewhat surprised we do not have something matching the

TimeInterval TC in RFC 6991, I do not recall why.



The TimeTicks TC (and hence the timeticks YANG type) represents time

that ticks. The classic example is sysUpTime - sysUpTime has a new

value whenever you read it since it constantly ticks. Hence, the

timeticks type is pretty useless for configuration objects.



If you roll your own type, perhaps you want a type like this:



=C2=A0 type centiseconds {

=C2=A0 =C2=A0 type uint32;

=C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 "A period of time, measured in units of 0.01 seco=
nds.";

=C2=A0 }




I like this approach, b=
ut maybe it would be better to follow the timeticks example

<=
/div>
=C2=A0 =C2=A0typedef time-interval {
=C2=A0 =C2=A0 =C2=
=A0 type uint32;
=C2=A0 =C2=A0 =C2=A0 units "hundredths of a=
 second"; =C2=A0// ?
=C2=A0 =C2=A0 =C2=A0 description
<=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "A period of time, measured in =
units of 0.01 seconds.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0referenc=
e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "RFC 2579: Textu=
al Conventions for SMIv2";
=C2=A0 =C2=A0}

Andy

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

With this, you would get something more descriptive:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf period {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type centiseconds;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Duration of time whi=
ch should occur between periodic

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0push updates.";=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }



/js



-- 

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>



_______________________________________________

Netconf mailing list

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




--000000000000a082e80576b963cb--


From nobody Tue Sep 25 15:18:57 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C2E126DBF for ; Tue, 25 Sep 2018 15:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 fJIXPX6DuNlD for ; Tue, 25 Sep 2018 15:18:54 -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 340D51277BB for ; Tue, 25 Sep 2018 15:18:53 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8PM91UJ026708; Tue, 25 Sep 2018 15:18:53 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=29YrYJWJJ+4ZbcffKkGJwDOGeH3/FTPx826ChBd1BIs=; b=Hk5tPYvd/1F+wz/0q/oqsY7ZxQMhs8xzW2uqgJnPc3ZZBaiszZDdW8n82LGY9siSuvOD ccoaNoPyj0yF32N7wE87a47Dv2Yl0MAcJneKrjQdFqfdamHepMvC2UjNF75gFK91W8qD uAKbHE8X4dcjMpQuGktJe54CPvwo1EjIi12zM5uk5PE+8dBzZKgEx2EHXrOoJa1Cz13K qBb1PJWhBK4eMxNBnIm+6WZOQdpGi2AJlfTALbit9cW1YRQT16T0ptFrMFCyxDsrwVPa zRu44ZFZvwNLbFjSzMaGwERXa0koc6Z8Es8AvbI1dP4shFrbag+0oDSdA3WYvN19W8Xd ZQ== 
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0017.outbound.protection.outlook.com [216.32.180.17]) by mx0b-00273201.pphosted.com with ESMTP id 2mqwck81s0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 25 Sep 2018 15:18:53 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB3979.namprd05.prod.outlook.com (20.176.66.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.10; Tue, 25 Sep 2018 22:18:50 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%3]) with mapi id 15.20.1185.014; Tue, 25 Sep 2018 22:18:51 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder 
CC: Netconf 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImouJGUP0t9tESR9VzM68tuEKUBeG0A///MeoCAAIBWgP//yhkA
Date: Tue, 25 Sep 2018 22:18:50 +0000
Message-ID: <5ED013C2-0D95-4B09-B0F5-D715DD58BE45@juniper.net>
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net> <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB3979; 6:rZreZYPJkXaTGP12CzOTSOmvJtYnRZKeGRpxAtadzyQsHVVapCbhsOJw81bjvlYlCu+tsSctl1sWZpVaj9H+F0Z9KZksqeE8b3MUd2xO2No9eHvN7Vduxz6OaZEMBNx0B876nI5k9XKB69+0/NwULZ06yFbwXfIXH/e34lX0/qaUqOdW8G1q+4CITuv5gyiYIz6WFBEpPCO261Iyn4oxsYVqAkaw7fATHsPweK/OFg2+6cK6ziyv1tkUEGi/u7FuF25mn2opvZvziW042SvSRPF3uEqW+Q+rvLHmv+GYbFJYco2YHFZ7/wek9LmqFKkESB2WX3bPXcoZOtdEU/nT6tbBUkPqxRZowkx457wVMZFBCZCrYB7ko+OHDg7fjnDqefrbcn4aJiwJXf0lDNk6LBEhZsTE83gaB+JXjK77RFWA38efv4Lwevd2SVbEKODqPG2z60wfNyhAM3ZMakXIiA==; 5:ogmHrMU2bOfUKdLWszCPORJ4Khb7LtVKwo42fGKhXX5rPRLIE3pcX3017DatWixHmGSmsIkwU9+7iiglVAyWob6NaGqCEcHeZpl8WGjSBETHOjndGoUMehW88GGgAUlEC+hFPy9fVyfhgfR8qshQQu6lsVfzCpPTf5cyrAl2dOo=; 7:HL1AJI3dg1wjWnAOHULyRH5ScJT6dq0sYYq6PBbypKTgR7UzC5m8T5qRUkmh3b5JV6ICbuzUFJl3JOimwz0X2a3wRPp7Fr0447N607RqVsembnAD2y6/8zGqnHpwSR9g7hptHCa5m+VU3y48EVRMdV9nyEs+SHBN0RzC6rDE4JFBKoKTmvOTOqAZUCWw66uaE3rC1tk4U7GGrpdod+GB730HyVVZKtksR4nhS8aYEhLTfqJ0iyNTggDd26GP9flP
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 010e987d-f5f0-4020-0fe0-08d62334df3d
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB3979; 
x-ms-traffictypediagnostic: DM6PR05MB3979:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(149066)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991041); SRVR:DM6PR05MB3979; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB3979; 
x-forefront-prvs: 08062C429B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(346002)(136003)(376002)(189003)(199004)(256004)(8676002)(105586002)(229853002)(68736007)(86362001)(316002)(66066001)(5250100002)(83716004)(99286004)(34290500001)(14454004)(36756003)(478600001)(6506007)(93886005)(76176011)(102836004)(97736004)(58126008)(2906002)(6116002)(3846002)(53936002)(6246003)(82746002)(7736002)(6512007)(71190400001)(71200400001)(446003)(6916009)(11346002)(476003)(33656002)(486006)(81156014)(81166006)(2900100001)(2616005)(186003)(6436002)(6486002)(25786009)(305945005)(106356001)(26005)(8936002)(5660300001)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB3979; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: dIwNv4X0QFyxPm0zROyTNGFxfwH9WF24dnT2tpUK2eodJQCZ27TVB+oC2UGQ+T3n/V92zsDtwj4KUbd/BWc9GhuPN/1FLuyJL0Lzd075L1XdAdYcWD1HlPaSv5WM4xwXPMfm1HBX0d+7Yq+zWS1zTrQfCXKGVYh50puTh6xjEfXTxumeSIQidRgjKnrkf4dEt92ZjGSzGBpxp2phtj3r+1pA9yaVWdDapyxvebvvuyu68kDPoKLNl9gxhWQUoAPj7QN8pgnByunQed6migii4kZnll30CT6oRdc1PSOUt0vQqOPaoBEFN3M4/EL++W8OQFQQOzPsgpiKRVSfT8nfb+qNcvklaOPzPO2gY/Gko2c=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <23BAC0F19E3CB14086CF6408CD5B889E@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 010e987d-f5f0-4020-0fe0-08d62334df3d
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2018 22:18:50.9315 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB3979
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-25_11:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=987 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809250218
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2018 22:18:56 -0000

DQoNCj4gSXQgc2VlbXMgdGhlIHR5cGUgeW91IHdhbnQgZm9yIHRoZSAncGVyaW9kJyBsZWFmcyBp
biB5b3VyIElEIGlzIG5vdA0KPiB0aW1ldGlja3MgYnV0IGFuIGVxdWl2YWxlbnQgb2YgUkZDIDI1
NzkncyBUaW1lSW50ZXJ2YWw6DQo+DQo+IFRpbWVJbnRlcnZhbCA6Oj0gVEVYVFVBTC1DT05WRU5U
SU9ODQo+ICAgIFNUQVRVUyAgICAgICBjdXJyZW50DQo+ICAgIERFU0NSSVBUSU9ODQo+ICAgICAg
ICAgICAgIkEgcGVyaW9kIG9mIHRpbWUsIG1lYXN1cmVkIGluIHVuaXRzIG9mIDAuMDEgc2Vjb25k
cy4iDQo+ICAgIFNZTlRBWCAgICAgICBJTlRFR0VSICgwLi4yMTQ3NDgzNjQ3KQ0KPg0KPiBJIGFt
IHNvbWV3aGF0IHN1cnByaXNlZCB3ZSBkbyBub3QgaGF2ZSBzb21ldGhpbmcgbWF0Y2hpbmcgdGhl
DQo+IFRpbWVJbnRlcnZhbCBUQyBpbiBSRkMgNjk5MSwgSSBkbyBub3QgcmVjYWxsIHdoeS4NCg0K
DQpJIGFsc28gdGhvdWdodCB0aGF0IG1heWJlIHRoZXJlIHNob3VsZCBiZSBzb21ldGhpbmcgYmV0
dGVyLiAgSSBoYWQgDQpzZWFyY2hlZCBSRkMgNjk5MSBmb3IgImR1cmF0aW9uIiB0aGlua2luZyBh
Ym91dCB4c2Q6ZHVyYXRpb24uDQoNCg0KDQo+IElmIHlvdSByb2xsIHlvdXIgb3duIHR5cGUsIHBl
cmhhcHMgeW91IHdhbnQgYSB0eXBlIGxpa2UgdGhpczoNCj4NCj4gIHR5cGUgY2VudGlzZWNvbmRz
IHsNCj4gICAgdHlwZSB1aW50MzI7DQo+ICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgIkEgcGVyaW9k
IG9mIHRpbWUsIG1lYXN1cmVkIGluIHVuaXRzIG9mIDAuMDEgc2Vjb25kcy4iOw0KPiAgfQ0KDQpC
dXQgdGhlbiBieSB0aGF0IHRva2VuLCBzaG91bGQgd2UgaGF2ZSB0eXBlcyBmb3Igc2Vjb25kcywg
bWludXRlcywNCmhvdXJzLCBldGMuIHRvbz8gIFRoaXMgbWlnaHQgYWN0dWFsbHkgYmUgbmljZSB0
byBoYXZlLCBidXQgcGVyaGFwcw0KcGFydCBvZiBhIHJmYzY5OTFiaXMgaW5zdGVhZD8gIA0KDQpU
aGlzIGlzIHdoeSBJIHdhcyB0aGlua2luZyB0byB1c2UgdGhlICJ1bml0cyIgc3RhdGVtZW50Og0K
DQogICAgICAgICBsZWFmIHBlcmlvZCB7DQogICAgICAgICAgICB0eXBlIHVuaXQzMjsNCiAgICAg
ICAgICAgIHVuaXRzICJIdW5kcmVkdGhzIG9mIGEgc2Vjb25kLiI7DQogICAgICAgICAgICBtYW5k
YXRvcnkgdHJ1ZTsNCiAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICJEdXJh
dGlvbiBvZiB0aW1lIHdoaWNoIHNob3VsZCBvY2N1ciBiZXR3ZWVuIHBlcmlvZGljDQogICAgICAg
ICAgICAgICBwdXNoIHVwZGF0ZXMuIjsNCiAgICAgICAgICB9DQoNCg0KDQoNCg0K


From nobody Tue Sep 25 15:37:11 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1908A1277BB for ; Tue, 25 Sep 2018 15:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6e7-mlM_8ND for ; Tue, 25 Sep 2018 15:37:07 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12677126F72 for ; Tue, 25 Sep 2018 15:37:06 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id C88DAE2D; Wed, 26 Sep 2018 00:37: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 2EcPvWTSoTsA; Wed, 26 Sep 2018 00:37: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; Wed, 26 Sep 2018 00:37:04 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A92AC20035; Wed, 26 Sep 2018 00:37:04 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NarslpW8wygI; Wed, 26 Sep 2018 00:37:04 +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 "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 4F8A320031; Wed, 26 Sep 2018 00:37:04 +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.1415.2; Wed, 26 Sep 2018 00:37:03 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 8DB18255165E; Wed, 26 Sep 2018 00:37:03 +0200 (CEST)
Date: Wed, 26 Sep 2018 00:37:03 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
CC: Netconf 
Message-ID: <20180925223703.afcjgmpsla4jkkfc@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , Netconf 
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net> <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de> <5ED013C2-0D95-4B09-B0F5-D715DD58BE45@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5ED013C2-0D95-4B09-B0F5-D715DD58BE45@juniper.net>
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] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2018 22:37:09 -0000

On Tue, Sep 25, 2018 at 10:18:50PM +0000, Kent Watsen wrote:
> 
> > If you roll your own type, perhaps you want a type like this:
> >
> >  type centiseconds {
> >    type uint32;
> >    description
> >      "A period of time, measured in units of 0.01 seconds.";
> >  }
> 
> But then by that token, should we have types for seconds, minutes,
> hours, etc. too?  This might actually be nice to have, but perhaps
> part of a rfc6991bis instead?

Likely.
 
> This is why I was thinking to use the "units" statement:
> 
>          leaf period {
>             type unit32;
>             units "Hundredths of a second.";
>             mandatory true;
>             description
>               "Duration of time which should occur between periodic
>                push updates.";
>           }

Well, the whole point of a type definition is that you do not have
to repeat things multiple times and you can be sure you always have
exactly the same.

By giving a type a good name (but good may be subjective), you also
get information into derived artefacts such as tree diagrams. Compare
these three versions:

  +---w yp:periodic!
     +---w yp:period         yang:timeticks
     +---w yp:anchor-time?   yang:date-and-time

vs

  +---w yp:periodic!
     +---w yp:period         uint32
     +---w yp:anchor-time?   yang:date-and-time

vs

  +---w yp:periodic!
     +---w yp:period         centiseconds
     +---w yp:anchor-time?   yang:date-and-time

A centiseconds type could (of course) still have a suitable units
statement. Anyway, timeticks seems to be semantically wrong.

/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 Sep 25 18:26:04 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A61130E00 for ; Tue, 25 Sep 2018 18:26:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 zrKGnnxkqBwy for ; Tue, 25 Sep 2018 18:26:00 -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 70DDA130DFE for ; Tue, 25 Sep 2018 18:26:00 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A7442773B7CC7; Wed, 26 Sep 2018 02:25:56 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 26 Sep 2018 02:25:58 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0399.000; Wed, 26 Sep 2018 09:25:55 +0800
From: Qin Wu 
To: Kent Watsen , Juergen Schoenwaelder 
CC: Netconf 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImyZPENQ2zHlkefbN/9krMXIaUA8lEAgAAPiICAAD1IgIAADScAgAC3DFA=
Date: Wed, 26 Sep 2018 01:25:54 +0000
Message-ID: 
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net> <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de> <5ED013C2-0D95-4B09-B0F5-D715DD58BE45@juniper.net>
In-Reply-To: <5ED013C2-0D95-4B09-B0F5-D715DD58BE45@juniper.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 01:26:02 -0000

DQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1i
b3VuY2VzQGlldGYub3JnXSC0+rHtIEtlbnQgV2F0c2VuDQq3osvNyrG85DogMjAxOMTqOdTCMjbI
1SA2OjE5DQrK1bz+yMs6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0Ks63LzTogTmV0Y29uZg0K1vfM
4jogUmU6IFtOZXRjb25mXSBtYmoncyBXR0xDIHJldmlldyBvZiB5YW5nLXB1c2gtMTcNCg0KDQoN
Cj4+IEl0IHNlZW1zIHRoZSB0eXBlIHlvdSB3YW50IGZvciB0aGUgJ3BlcmlvZCcgbGVhZnMgaW4g
eW91ciBJRCBpcyBub3QgDQo+PiB0aW1ldGlja3MgYnV0IGFuIGVxdWl2YWxlbnQgb2YgUkZDIDI1
NzkncyBUaW1lSW50ZXJ2YWw6DQo+Pg0KPj4gVGltZUludGVydmFsIDo6PSBURVhUVUFMLUNPTlZF
TlRJT04NCj4+ICAgIFNUQVRVUyAgICAgICBjdXJyZW50DQo+PiAgICBERVNDUklQVElPTg0KPj4g
ICAgICAgICAgICAiQSBwZXJpb2Qgb2YgdGltZSwgbWVhc3VyZWQgaW4gdW5pdHMgb2YgMC4wMSBz
ZWNvbmRzLiINCj4+ICAgIFNZTlRBWCAgICAgICBJTlRFR0VSICgwLi4yMTQ3NDgzNjQ3KQ0KPj4N
Cj4+IEkgYW0gc29tZXdoYXQgc3VycHJpc2VkIHdlIGRvIG5vdCBoYXZlIHNvbWV0aGluZyBtYXRj
aGluZyB0aGUgDQo+PiBUaW1lSW50ZXJ2YWwgVEMgaW4gUkZDIDY5OTEsIEkgZG8gbm90IHJlY2Fs
bCB3aHkuDQoNCg0KPkkgYWxzbyB0aG91Z2h0IHRoYXQgbWF5YmUgdGhlcmUgc2hvdWxkIGJlIHNv
bWV0aGluZyBiZXR0ZXIuICBJIGhhZCBzZWFyY2hlZCBSRkMgNjk5MSBmb3IgImR1cmF0aW9uIiB0
aGlua2luZyBhYm91dCB4c2Q6ZHVyYXRpb24uDQoNCg0KDQo+PiBJZiB5b3Ugcm9sbCB5b3VyIG93
biB0eXBlLCBwZXJoYXBzIHlvdSB3YW50IGEgdHlwZSBsaWtlIHRoaXM6DQo+Pg0KPj4gIHR5cGUg
Y2VudGlzZWNvbmRzIHsNCj4+ICAgIHR5cGUgdWludDMyOw0KPj4gICAgZGVzY3JpcHRpb24NCj4+
ICAgICAgIkEgcGVyaW9kIG9mIHRpbWUsIG1lYXN1cmVkIGluIHVuaXRzIG9mIDAuMDEgc2Vjb25k
cy4iOw0KPj4gIH0NCg0KPj5CdXQgdGhlbiBieSB0aGF0IHRva2VuLCBzaG91bGQgd2UgaGF2ZSB0
eXBlcyBmb3Igc2Vjb25kcywgbWludXRlcywNCj4+aG91cnMsIGV0Yy4gdG9vPyAgVGhpcyBtaWdo
dCBhY3R1YWxseSBiZSBuaWNlIHRvIGhhdmUsIGJ1dCBwZXJoYXBzDQo+PnBhcnQgb2YgYSByZmM2
OTkxYmlzIGluc3RlYWQ/ICANCg0KDQpbUWluXTogVG8gYWRkcmVzcyB0aGlzLCBvbmUgc29sdXRp
b24gd2UgcHJvcG9zZWQgaW4gZHJhZnQtaWV0Zi1saW1lLXlhbmctY29ubmVjdGlvbmxlc3Mtb2Ft
LTE4Og0KSXMgdG8gZGVmaW5lIGlldGYtbGltZS10aW1lLXR5cGVzIHdoaWNoIGNhbiBiZSByZXVz
ZWQgaW4gb3RoZXIgbW9kdWxlcy4gSW4gaWV0Zi1saW1lLXRpbWUtdHlwZXMsIHdlIGRlZmluZQ0K
ZGVmaW5lIHRpbWUtdW5pdC10eXBlIGFzIGlkZW50aXR5LiANCkJ1dCBtYXliZSB0eXBlZGVmIGlz
IGV2ZW4gYmV0dGVyIHNpbmNlIGJvdGggdGltZS11bml0IGFuZCB2YWx1ZSBhcmUgZGVmaW5lZCBp
biBvbmUuDQoNCj5UaGlzIGlzIHdoeSBJIHdhcyB0aGlua2luZyB0byB1c2UgdGhlICJ1bml0cyIg
c3RhdGVtZW50Og0KDQo+ICAgICAgICAgbGVhZiBwZXJpb2Qgew0KPiAgICAgICAgICAgIHR5cGUg
dW5pdDMyOw0KPiAgICAgICAgICAgIHVuaXRzICJIdW5kcmVkdGhzIG9mIGEgc2Vjb25kLiI7DQo+
ICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7DQo+ICAgICAgICAgICAgZGVzY3JpcHRpb24NCj4g
ICAgICAgICAgICAgICJEdXJhdGlvbiBvZiB0aW1lIHdoaWNoIHNob3VsZCBvY2N1ciBiZXR3ZWVu
IHBlcmlvZGljDQo+ICAgICAgICAgICAgICAgcHVzaCB1cGRhdGVzLiI7DQo+ICAgICAgICAgIH0N
Cg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Ck5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg==


From nobody Tue Sep 25 18:50:19 2018
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 B6B3A126BED; Tue, 25 Sep 2018 18:50:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk 
To: "The IESG" 
Cc: draft-ietf-netconf-nmda-restconf@ietf.org, Mahesh Jethanandani , netconf-chairs@ietf.org, mjethanandani@gmail.com, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153792661674.5041.18055003441008769454.idtracker@ietfa.amsl.com>
Date: Tue, 25 Sep 2018 18:50:16 -0700
Archived-At: 
Subject: [Netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-nmda-restconf-04: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 01:50:17 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netconf-nmda-restconf-04: 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-nmda-restconf/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The RFC 8040 security considerations are probably adequate for the new datastores.

I noticed the same issue with "identity" that Adam did, though my tentative conclusion
was that these are the more generic "identifier".



From nobody Tue Sep 25 23:32:12 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4945130E0A for ; Tue, 25 Sep 2018 23:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGHOx9qIn_9K for ; Tue, 25 Sep 2018 23:32:08 -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 7B2DE130DFD for ; Tue, 25 Sep 2018 23:32:08 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 02581E2D; Wed, 26 Sep 2018 08:32:07 +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 Muo7RXq4gJA1; Wed, 26 Sep 2018 08:32:06 +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, 26 Sep 2018 08:32:06 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFC5520035; Wed, 26 Sep 2018 08:32:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NAWDh5DXs_9f; Wed, 26 Sep 2018 08:32:06 +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 "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 8F6ED20031; Wed, 26 Sep 2018 08:32:06 +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.1415.2; Wed, 26 Sep 2018 08:32:06 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 97CC92551D27; Wed, 26 Sep 2018 08:32:05 +0200 (CEST)
Date: Wed, 26 Sep 2018 08:32:05 +0200
From: Juergen Schoenwaelder 
To: Qin Wu 
CC: Kent Watsen , Netconf 
Message-ID: <20180926063205.occ7oo5jxfnblvg5@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Qin Wu , Kent Watsen , Netconf 
References: <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net> <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de> <5ED013C2-0D95-4B09-B0F5-D715DD58BE45@juniper.net> 
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] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 06:32:12 -0000

On Wed, Sep 26, 2018 at 01:25:54AM +0000, Qin Wu wrote:
> 
> To address this, one solution we proposed in draft-ietf-lime-yang-connectionless-oam-18:
> Is to define ietf-lime-time-types which can be reused in other modules. In ietf-lime-time-types, we define
> define time-unit-type as identity. 
> But maybe typedef is even better since both time-unit and value are defined in one.
>

The good old practice was to think about the number range that makes
sense and then to use a numeric type with a suitable unit that covers
the number range.

I wonder whether you really need a uint32 range of hours in the OAM
models. Note that a single uint64 of nanoseconds would give you up to
584 years. If oam models do indeed need delay values that range from
nanoseconds to hundreds of years, I would rather go with a single
uint64 instead of a combination of an uint32 and a unit identifier.

/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 Sep 26 01:00:44 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6D6130E1A for ; Wed, 26 Sep 2018 01:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Au8bsEfF3aBf for ; Wed, 26 Sep 2018 01:00:36 -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 6148E130DC2 for ; Wed, 26 Sep 2018 01:00:36 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 5867C65BCF225; Wed, 26 Sep 2018 09:00:31 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 26 Sep 2018 09:00:32 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0399.000; Wed, 26 Sep 2018 16:00:26 +0800
From: Qin Wu 
To: Juergen Schoenwaelder 
CC: Kent Watsen , Netconf 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImyZPENQ2zHlkefbN/9krMXIaUA8lEAgAAPiICAAD1IgIAADScAgAC3DFD//9LEgIAAnV4w
Date: Wed, 26 Sep 2018 08:00:26 +0000
Message-ID: 
References: <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net> <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de> <5ED013C2-0D95-4B09-B0F5-D715DD58BE45@juniper.net>  <20180926063205.occ7oo5jxfnblvg5@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180926063205.occ7oo5jxfnblvg5@anna.jacobs.jacobs-university.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 08:00:43 -0000

LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRv
Omouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0gDQq3osvNyrG85DogMjAxOMTq
OdTCMjbI1SAxNDozMg0KytW8/sjLOiBRaW4gV3UNCrOty806IEtlbnQgV2F0c2VuOyBOZXRjb25m
DQrW98ziOiBSZTogW05ldGNvbmZdIG1iaidzIFdHTEMgcmV2aWV3IG9mIHlhbmctcHVzaC0xNw0K
DQpPbiBXZWQsIFNlcCAyNiwgMjAxOCBhdCAwMToyNTo1NEFNICswMDAwLCBRaW4gV3Ugd3JvdGU6
DQo+IA0KPiBUbyBhZGRyZXNzIHRoaXMsIG9uZSBzb2x1dGlvbiB3ZSBwcm9wb3NlZCBpbiBkcmFm
dC1pZXRmLWxpbWUteWFuZy1jb25uZWN0aW9ubGVzcy1vYW0tMTg6DQo+IElzIHRvIGRlZmluZSBp
ZXRmLWxpbWUtdGltZS10eXBlcyB3aGljaCBjYW4gYmUgcmV1c2VkIGluIG90aGVyIA0KPiBtb2R1
bGVzLiBJbiBpZXRmLWxpbWUtdGltZS10eXBlcywgd2UgZGVmaW5lIGRlZmluZSB0aW1lLXVuaXQt
dHlwZSBhcyBpZGVudGl0eS4NCj4gQnV0IG1heWJlIHR5cGVkZWYgaXMgZXZlbiBiZXR0ZXIgc2lu
Y2UgYm90aCB0aW1lLXVuaXQgYW5kIHZhbHVlIGFyZSBkZWZpbmVkIGluIG9uZS4NCj4NCg0KVGhl
IGdvb2Qgb2xkIHByYWN0aWNlIHdhcyB0byB0aGluayBhYm91dCB0aGUgbnVtYmVyIHJhbmdlIHRo
YXQgbWFrZXMgc2Vuc2UgYW5kIHRoZW4gdG8gdXNlIGEgbnVtZXJpYyB0eXBlIHdpdGggYSBzdWl0
YWJsZSB1bml0IHRoYXQgY292ZXJzIHRoZSBudW1iZXIgcmFuZ2UuDQoNCkkgd29uZGVyIHdoZXRo
ZXIgeW91IHJlYWxseSBuZWVkIGEgdWludDMyIHJhbmdlIG9mIGhvdXJzIGluIHRoZSBPQU0gbW9k
ZWxzLiANCgkNCltRaW5dOiBub3QgbmVjZXNzYXJ5IGZvciBPQU0gbW9kZWwsIGJ1dCBJdCBtYXkg
YmUgdXNlZCBpbiBzb21lIG90aGVyIG1vZGVscyB0aGF0IHJlcXVpcmUgdW5pbnQzMiByYW5nZSBv
ZiBob3Vycy4NCg0KTm90ZSB0aGF0IGEgc2luZ2xlIHVpbnQ2NCBvZiBuYW5vc2Vjb25kcyB3b3Vs
ZCBnaXZlIHlvdSB1cCB0bw0KNTg0IHllYXJzLiBJZiBvYW0gbW9kZWxzIGRvIGluZGVlZCBuZWVk
IGRlbGF5IHZhbHVlcyB0aGF0IHJhbmdlIGZyb20gbmFub3NlY29uZHMgdG8gaHVuZHJlZHMgb2Yg
eWVhcnMsIEkgd291bGQgcmF0aGVyIGdvIHdpdGggYSBzaW5nbGUNCnVpbnQ2NCBpbnN0ZWFkIG9m
IGEgY29tYmluYXRpb24gb2YgYW4gdWludDMyIGFuZCBhIHVuaXQgaWRlbnRpZmllci4NCg0KW1Fp
bl06IE5vdCBhZHZvY2F0aW5nIHVzaW5nIHN1Y2ggY29tYmluYXRpb24sIGp1c3QgcG9pbnQgb3V0
IHN1Y2ggY29tbW9uIHR5cGUgYXJlIGFsc28gbmVlZGVkIGluIHNvbWUgb3RoZXIgbW9kZWxzLCB0
aGF0J3Mgd2h5IGEgc2VwYXJhdGUgaWV0Zi1saW1lLXRpbWUtdHlwZXMgd2FzIGRlZmluZWQuDQoN
Ci9qcw0KDQotLSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZl
cnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1
cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEw
MyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo=


From nobody Wed Sep 26 01:04:30 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0FA130E0E; Wed, 26 Sep 2018 01:04:29 -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 9eeqkLF6SdWi; Wed, 26 Sep 2018 01:04: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 A93D3130DC2; Wed, 26 Sep 2018 01:04:27 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 8426F1AE0473; Wed, 26 Sep 2018 10:04:26 +0200 (CEST)
Date: Wed, 26 Sep 2018 10:04:26 +0200 (CEST)
Message-Id: <20180926.100426.890145768104475235.mbj@tail-f.com>
To: adam@nostrum.com
Cc: iesg@ietf.org, draft-ietf-netconf-nmda-restconf@ietf.org, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <153783874541.31291.9358251378810314164.idtracker@ietfa.amsl.com>
References: <153783874541.31291.9358251378810314164.idtracker@ietfa.amsl.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Netconf] Adam Roach's No Objection on draft-ietf-netconf-nmda-restconf-04: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 08:04:29 -0000

Hi,

Adam Roach  wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-netconf-nmda-restconf-04: 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 th=
is
> 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-nmda-restconf/
> =

> =

> =

> ---------------------------------------------------------------------=
-
> COMMENT:
> ---------------------------------------------------------------------=
-
> =

> Thanks to everyone who worked on this mechanism.
> =

> I agree with Alexey's general point that implementors could benefit f=
rom
> guidance regarding the "with-defaults" values, as the current mechani=
sm
> requires a potentially cumbersome process of probing for support of
> desired functionality.

I will reply to Alexey's email.

> Beyond that, I have only a handful of minor comments.
> =

> ---------------------------------------------------------------------=
------
> =

> =A73.1:
> =

> >  The  path component is encoded as an "identity" accordi=
ng
> >  to the JSON encoding rules for identities, defined in Section 4 of=

> >  [RFC7951].
> =

> I don't find anything in section 4 of RFC 7951 that indicates encodin=
g for an
> "identity." Should this text say "identityref" instead? And if that's=
 the
> intention, it seems that pointing to section 6.8 would be more direct=
 than
> pointing to section 4.

Yes.  I suggest changing the reference and adding a clarification:

OLD:

   The  path component is encoded as an "identity" according=

   to the JSON encoding rules for identities, defined in Section 4 of
   [RFC7951].  Such an identity MUST be derived from the "datastore"
   identity defined in the "ietf-datastores" YANG module [RFC8342].

NEW:

   The  path component is encoded as an "identityref"
   according to the JSON encoding rules for identities, defined in
   Section 6.8 of [RFC7951].  The namespace-qualified form MUST be used=
.=

   Such an identity MUST be derived from the "datastore" identity
   defined in the "ietf-datastores" YANG module [RFC8342].

> ---------------------------------------------------------------------=
------
> =

> =A75:
> =

> >  This documents extends the RESTCONF protocol by introducing new
> >  datastore resources.  The lowest RESTCONF layer is HTTPS, and the
> >  mandatory-to-implement secure transport is TLS [RFC5246].
> =

> Unless this mechanism relies on some behavior that is different
> between TLS 1.2
> and TLS 1.3, please update this reference to RFC 8446.

Ok.  This update needs to go into the security-considerations-template
that is used for documents with YANG modules.

> Nit: "This document extends..."
>                    ^

Fixed.

> >  The security constraints for the base RESTCONF protocol (see
> >  Section 12 of [RFC8040] apply to the new RESTCONF datastore resour=
ces
> >  defined in this document.
> =

> Nit: Missing a closing parenthesis.

Fixed.


Thanks for the review!



/martin


From nobody Wed Sep 26 01:05:32 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15B2130E0E; Wed, 26 Sep 2018 01:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vcvN-cKbY61A; Wed, 26 Sep 2018 01:05:29 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 14F03130DC2; Wed, 26 Sep 2018 01:05:29 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 10AF61B039F2; Wed, 26 Sep 2018 10:05:28 +0200 (CEST)
Date: Wed, 26 Sep 2018 10:05:27 +0200 (CEST)
Message-Id: <20180926.100527.466579893535200802.mbj@tail-f.com>
To: kaduk@mit.edu
Cc: iesg@ietf.org, draft-ietf-netconf-nmda-restconf@ietf.org, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <153792661674.5041.18055003441008769454.idtracker@ietfa.amsl.com>
References: <153792661674.5041.18055003441008769454.idtracker@ietfa.amsl.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-nmda-restconf-04: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 08:05:31 -0000

Benjamin Kaduk  wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-netconf-nmda-restconf-04: 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-nmda-restconf/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> The RFC 8040 security considerations are probably adequate for the new
> datastores.
> 
> I noticed the same issue with "identity" that Adam did, though my
> tentative conclusion
> was that these are the more generic "identifier".

See my reply to Adam's email; I have clarified that we mean
"identityref", and updated the reference.


/martin


From nobody Wed Sep 26 02:28:55 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3FE130E70 for ; Wed, 26 Sep 2018 02:28: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, 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 F4lU4bAoGUfD for ; Wed, 26 Sep 2018 02:28:46 -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 2C4F9130EB4 for ; Wed, 26 Sep 2018 02:28:46 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E0B3FE15; Wed, 26 Sep 2018 11:28:44 +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 vvUk8MmGQGMs; Wed, 26 Sep 2018 11:28:44 +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, 26 Sep 2018 11:28:44 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A38E620035; Wed, 26 Sep 2018 11:28:44 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZfwTXu351DgS; Wed, 26 Sep 2018 11:28:44 +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 "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 596E020031; Wed, 26 Sep 2018 11:28:44 +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.1415.2; Wed, 26 Sep 2018 11:28:43 +0200
Received: by anna.localdomain (Postfix, from userid 501) id ACF1925521AE; Wed, 26 Sep 2018 11:28:43 +0200 (CEST)
Date: Wed, 26 Sep 2018 11:28:43 +0200
From: Juergen Schoenwaelder 
To: Qin Wu 
CC: Kent Watsen , Netconf 
Message-ID: <20180926092843.lzvxnh3ajnamfqxa@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Qin Wu , Kent Watsen , Netconf 
References: <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net> <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de> <5ED013C2-0D95-4B09-B0F5-D715DD58BE45@juniper.net>  <20180926063205.occ7oo5jxfnblvg5@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 09:28:54 -0000

On Wed, Sep 26, 2018 at 08:00:26AM +0000, Qin Wu wrote:
> I wonder whether you really need a uint32 range of hours in the OAM models. 
> 	
> [Qin]: not necessary for OAM model, but It may be used in some other models that require unint32 range of hours.

Authors may not want to depend on ietf-lime-time-types for generic
types for time periods, nor am I sure the solution there is a simple
solution.

Perhaps its time to see whether it makes sense to spin an update of
RFC 6991 to add definitions that are apparently missing. Aftert 5
years this may be a reasonable thing to do. We should not hold off
work because of this but we may allow authors to transition to common
definitions if what they do now is compatible with a common solution
underway. I would be willing to allocate some of my time to an update
of RFC 6991 if the WG believes this is useful.

/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 Sep 26 02:58:17 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8516E130E84 for ; Wed, 26 Sep 2018 02:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 esX2k-NJz0ba for ; Wed, 26 Sep 2018 02:58:09 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D109130E94 for ; Wed, 26 Sep 2018 02:58:09 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9F3D391EAA23B; Wed, 26 Sep 2018 10:57:59 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 26 Sep 2018 10:58:00 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0399.000; Wed, 26 Sep 2018 17:57:58 +0800
From: Qin Wu 
To: Juergen Schoenwaelder 
CC: Kent Watsen , Netconf 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImyZPENQ2zHlkefbN/9krMXIaUA8lEAgAAPiICAAD1IgIAADScAgAC3DFD//9LEgIAAnV4w//+T/ICAAI1w0A==
Date: Wed, 26 Sep 2018 09:57:57 +0000
Message-ID: 
References: <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net> <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de> <5ED013C2-0D95-4B09-B0F5-D715DD58BE45@juniper.net>  <20180926063205.occ7oo5jxfnblvg5@anna.jacobs.jacobs-university.de>  <20180926092843.lzvxnh3ajnamfqxa@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180926092843.lzvxnh3ajnamfqxa@anna.jacobs.jacobs-university.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 09:58:16 -0000

LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRv
Omouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0gDQq3osvNyrG85DogMjAxOMTq
OdTCMjbI1SAxNzoyOQ0KytW8/sjLOiBRaW4gV3UNCrOty806IEtlbnQgV2F0c2VuOyBOZXRjb25m
DQrW98ziOiBSZTogW05ldGNvbmZdIG1iaidzIFdHTEMgcmV2aWV3IG9mIHlhbmctcHVzaC0xNw0K
DQpPbiBXZWQsIFNlcCAyNiwgMjAxOCBhdCAwODowMDoyNkFNICswMDAwLCBRaW4gV3Ugd3JvdGU6
DQo+IEkgd29uZGVyIHdoZXRoZXIgeW91IHJlYWxseSBuZWVkIGEgdWludDMyIHJhbmdlIG9mIGhv
dXJzIGluIHRoZSBPQU0gbW9kZWxzLiANCj4gCQ0KPiBbUWluXTogbm90IG5lY2Vzc2FyeSBmb3Ig
T0FNIG1vZGVsLCBidXQgSXQgbWF5IGJlIHVzZWQgaW4gc29tZSBvdGhlciBtb2RlbHMgdGhhdCBy
ZXF1aXJlIHVuaW50MzIgcmFuZ2Ugb2YgaG91cnMuDQoNCkF1dGhvcnMgbWF5IG5vdCB3YW50IHRv
IGRlcGVuZCBvbiBpZXRmLWxpbWUtdGltZS10eXBlcyBmb3IgZ2VuZXJpYyB0eXBlcyBmb3IgdGlt
ZSBwZXJpb2RzLCBub3IgYW0gSSBzdXJlIHRoZSBzb2x1dGlvbiB0aGVyZSBpcyBhIHNpbXBsZSBz
b2x1dGlvbi4NCg0KW1Fpbl06IHdvcmtzIGZvciBtZS4NCg0KUGVyaGFwcyBpdHMgdGltZSB0byBz
ZWUgd2hldGhlciBpdCBtYWtlcyBzZW5zZSB0byBzcGluIGFuIHVwZGF0ZSBvZiBSRkMgNjk5MSB0
byBhZGQgZGVmaW5pdGlvbnMgdGhhdCBhcmUgYXBwYXJlbnRseSBtaXNzaW5nLiBBZnRlcnQgNSB5
ZWFycyB0aGlzIG1heSBiZSBhIHJlYXNvbmFibGUgdGhpbmcgdG8gZG8uIFdlIHNob3VsZCBub3Qg
aG9sZCBvZmYgd29yayBiZWNhdXNlIG9mIHRoaXMgYnV0IHdlIG1heSBhbGxvdyBhdXRob3JzIHRv
IHRyYW5zaXRpb24gdG8gY29tbW9uIGRlZmluaXRpb25zIGlmIHdoYXQgdGhleSBkbyBub3cgaXMg
Y29tcGF0aWJsZSB3aXRoIGEgY29tbW9uIHNvbHV0aW9uIHVuZGVyd2F5LiBJIHdvdWxkIGJlIHdp
bGxpbmcgdG8gYWxsb2NhdGUgc29tZSBvZiBteSB0aW1lIHRvIGFuIHVwZGF0ZSBvZiBSRkMgNjk5
MSBpZiB0aGUgV0cgYmVsaWV2ZXMgdGhpcyBpcyB1c2VmdWwuDQoNCltRaW5dOiBJIHRoaW5rIGl0
IGlzIHVzZWZ1bC4NCg0KL2pzDQoNCi0tIA0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAg
ICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3
ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCkZheDogICAr
NDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRl
Lz4NCg==


From nobody Wed Sep 26 03:06:30 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A042E130E2A for ; Wed, 26 Sep 2018 03:06:28 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv_yRWrzQTlz for ; Wed, 26 Sep 2018 03:06:22 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23234130E18 for ; Wed, 26 Sep 2018 03:06:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1081; q=dns/txt; s=iport; t=1537956382; x=1539165982; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=fvrOLs6OfLqxIZDWCKA0hCSvOk4RB50LcW3MOnlIBRU=; b=WTl8o+yNLx+KVxlrc2s9jo4bklYdrKjKxnRmIHfia1sCSx1aKpDkKps6 kUnYL8JgZ4ECxgvFvURxVvUd++ocVhdKtBB/GjdfwKK79FqRW/2oeI5q4 z+vEr78ptorsNlJrmPqZ54SrCDa5jW16OcLMkyqfE8PXK/oX9ZDRM5tL6 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAABxWatb/xbLJq1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBU4NeEoQciHSNMC2WT4F6C4RsAoQaNhYBAwEBAgEBAm0?= =?us-ascii?q?ohTkBBSMVUQsOCgICJgICVwYBDAgBAReDBoIConGBLoR3hSSBC4oGgUE/gRI?= =?us-ascii?q?ngmuHf4JXAo5AjkcJkCcGF4FGhzOGO4hwhhKGD4FJAi+BVTMaCBsVgyiQVD6?= =?us-ascii?q?NcgEB?=
X-IronPort-AV: E=Sophos;i="5.54,305,1534809600";  d="scan'208";a="6806410"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2018 10:06:20 +0000
Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w8QA6JOH015626; Wed, 26 Sep 2018 10:06:20 GMT
To: Qin Wu , Kent Watsen , Netconf 
References: <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net> <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de> <5ED013C2-0D95-4B09-B0F5-D715DD58BE45@juniper.net>  <20180926063205.occ7oo5jxfnblvg5@anna.jacobs.jacobs-university.de>  <20180926092843.lzvxnh3ajnamfqxa@anna.jacobs.jacobs-university.de>
From: Robert Wilton 
Message-ID: 
Date: Wed, 26 Sep 2018 11:06:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180926092843.lzvxnh3ajnamfqxa@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 10:06:29 -0000

Hi Juergen,

Yes, I think that updating RFC 6991 would be useful, if there are types 
missing.

Thanks,
Rob


On 26/09/2018 10:28, Juergen Schoenwaelder wrote:
> On Wed, Sep 26, 2018 at 08:00:26AM +0000, Qin Wu wrote:
>> I wonder whether you really need a uint32 range of hours in the OAM models.
>> 	
>> [Qin]: not necessary for OAM model, but It may be used in some other models that require unint32 range of hours.
> Authors may not want to depend on ietf-lime-time-types for generic
> types for time periods, nor am I sure the solution there is a simple
> solution.
>
> Perhaps its time to see whether it makes sense to spin an update of
> RFC 6991 to add definitions that are apparently missing. Aftert 5
> years this may be a reasonable thing to do. We should not hold off
> work because of this but we may allow authors to transition to common
> definitions if what they do now is compatible with a common solution
> underway. I would be willing to allocate some of my time to an update
> of RFC 6991 if the WG believes this is useful.
>
> /js
>


From nobody Wed Sep 26 03:45:36 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94105130E71 for ; Wed, 26 Sep 2018 03:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 5jKR51bGMEvk for ; Wed, 26 Sep 2018 03:45:32 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 60363130E53 for ; Wed, 26 Sep 2018 03:45:31 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 510E118202D9; Wed, 26 Sep 2018 12:53:08 +0200 (CEST)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 07CF01820057 for ; Wed, 26 Sep 2018 12:53:07 +0200 (CEST)
From: Ladislav Lhotka 
To: Netconf 
Date: Wed, 26 Sep 2018 12:45:26 +0200
Message-ID: <87lg7osfjt.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: [Netconf] {+restconf}/data vs 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 10:45:35 -0000

Hi,

draft-ietf-netconf-nmda-restconf is silent about the relationship
between the {+restconf}/data and the  datastore, and it cannot
be deduced from RFC 8040 either, because it only says in sec. 3.3.1:

   This mandatory resource [{+restconf}/data] represents the combined
   configuration and state data resources that can be accessed by a
   client.

I think this is a serious omission.

Regarding draft-lhotka-netconf-restconf-transactions-00, I received a
lot of criticism for changing the semantics of
{+restconf}/data. However, I don't think it was the case: according to
the above definition, it seems perfectly OK if {+restconf}/data
represents combined configuration **from ** and state data.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Sep 26 03:58:36 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16EB130EA2 for ; Wed, 26 Sep 2018 03:58:18 -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 nWGcsSbBurRZ for ; Wed, 26 Sep 2018 03:58: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 B853E130E7F for ; Wed, 26 Sep 2018 03:58: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 5D96468F; Wed, 26 Sep 2018 12:58: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 0TVpz60oUvET; Wed, 26 Sep 2018 12:58: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, 26 Sep 2018 12:58:15 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 468D020035; Wed, 26 Sep 2018 12:58:15 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QzMSzO1uuKPh; Wed, 26 Sep 2018 12:58:14 +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 "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id EBCA220031; Wed, 26 Sep 2018 12:58: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.1415.2; Wed, 26 Sep 2018 12:58:14 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 0419D2552571; Wed, 26 Sep 2018 12:58:13 +0200 (CEST)
Date: Wed, 26 Sep 2018 12:58:13 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
CC: Netconf 
Message-ID: <20180926105813.5o47jfszwefzwloa@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Ladislav Lhotka , Netconf 
References: <87lg7osfjt.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87lg7osfjt.fsf@nic.cz>
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] {+restconf}/data vs 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 10:58:23 -0000

On Wed, Sep 26, 2018 at 12:45:26PM +0200, Ladislav Lhotka wrote:
> Hi,
> 
> draft-ietf-netconf-nmda-restconf is silent about the relationship
> between the {+restconf}/data and the  datastore, and it cannot
> be deduced from RFC 8040 either, because it only says in sec. 3.3.1:
> 
>    This mandatory resource [{+restconf}/data] represents the combined
>    configuration and state data resources that can be accessed by a
>    client.
> 
> I think this is a serious omission.

We are not changing {+restconf}/data.
 
> Regarding draft-lhotka-netconf-restconf-transactions-00, I received a
> lot of criticism for changing the semantics of
> {+restconf}/data. However, I don't think it was the case: according to
> the above definition, it seems perfectly OK if {+restconf}/data
> represents combined configuration **from ** and state data.

Perhaps people had the impression that your proposal changes
{+restconf}/data or that it should work with the NMDA solution.

/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 Sep 26 04:04:06 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2D0130E81 for ; Wed, 26 Sep 2018 04:04:04 -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 nDU3kCmGE1A9 for ; Wed, 26 Sep 2018 04:04:03 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 14E26130E7F for ; Wed, 26 Sep 2018 04:04:03 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 9C90B1AE02BE; Wed, 26 Sep 2018 13:04:01 +0200 (CEST)
Date: Wed, 26 Sep 2018 13:04:00 +0200 (CEST)
Message-Id: <20180926.130400.328479331143716638.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <87lg7osfjt.fsf@nic.cz>
References: <87lg7osfjt.fsf@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] {+restconf}/data vs 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 11:04:05 -0000

Ladislav Lhotka  wrote:
> Hi,
> 
> draft-ietf-netconf-nmda-restconf is silent about the relationship
> between the {+restconf}/data and the  datastore, and it cannot
> be deduced from RFC 8040 either, because it only says in sec. 3.3.1:
> 
>    This mandatory resource [{+restconf}/data] represents the combined
>    configuration and state data resources that can be accessed by a
>    client.
> 
> I think this is a serious omission.

draft-ietf-netconf-nmda-restconf doesn't change {+restconf}/data.  It
works as before.  See RFC 8040 section 1.4 for relationship to
.

> Regarding draft-lhotka-netconf-restconf-transactions-00, I received a
> lot of criticism for changing the semantics of
> {+restconf}/data. However, I don't think it was the case: according to
> the above definition, it seems perfectly OK if {+restconf}/data
> represents combined configuration **from ** and state data.

This would violate section 1.4 of RFC 8040, at least if the RESTCONF
server is co-located with a NETCONF server.



/martin


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


From nobody Wed Sep 26 04:10:59 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780CB130E7F for ; Wed, 26 Sep 2018 04:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpPzdyn3eQ8L for ; Wed, 26 Sep 2018 04:10:55 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62396130E53 for ; Wed, 26 Sep 2018 04:10:55 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::404]) by mail.nic.cz (Postfix) with ESMTPSA id 98F3062995; Wed, 26 Sep 2018 13:10:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1537960253; bh=YRAZMhwyAOvv159Gf13ki7p1cx7rjUh4qbk0cg5oLGU=; h=From:To:Date; b=EhrJH7hORvE7r4Gn/+kjgkcixGbADvvt/EO2oj3+tU2sj3VQO8YWotdN3dE34foZT JiEtC5tp00CtnLO5pT+bEtnPlqgxZL4aHrAAjTFFxCtg7HeFvqa4my150vVKLqhL3S rowgffVGFevOkOKC49c6N9tFDsng5WDOXz2GSfHc=
Message-ID: <620e0bb5a40c29809e7a47a0fd69b694db76d3db.camel@nic.cz>
From: Ladislav Lhotka 
To: Juergen Schoenwaelder 
Cc: Netconf 
Date: Wed, 26 Sep 2018 13:10:53 +0200
In-Reply-To: <20180926105813.5o47jfszwefzwloa@anna.jacobs.jacobs-university.de>
References: <87lg7osfjt.fsf@nic.cz> <20180926105813.5o47jfszwefzwloa@anna.jacobs.jacobs-university.de>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [Netconf] {+restconf}/data vs 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 11:10:58 -0000

On Wed, 2018-09-26 at 12:58 +0200, Juergen Schoenwaelder wrote:
> On Wed, Sep 26, 2018 at 12:45:26PM +0200, Ladislav Lhotka wrote:
> > Hi,
> > 
> > draft-ietf-netconf-nmda-restconf is silent about the relationship
> > between the {+restconf}/data and the  datastore, and it cannot
> > be deduced from RFC 8040 either, because it only says in sec. 3.3.1:
> > 
> >    This mandatory resource [{+restconf}/data] represents the combined
> >    configuration and state data resources that can be accessed by a
> >    client.
> > 
> > I think this is a serious omission.
> 
> We are not changing {+restconf}/data.

My point is that it is unclear what {+restconf}/data really is: "the combined
configuration and state data resources" is too vague given that several
configuration datastores may be present.

>  
> > Regarding draft-lhotka-netconf-restconf-transactions-00, I received a
> > lot of criticism for changing the semantics of
> > {+restconf}/data. However, I don't think it was the case: according to
> > the above definition, it seems perfectly OK if {+restconf}/data
> > represents combined configuration **from ** and state data.
> 
> Perhaps people had the impression that your proposal changes
> {+restconf}/data or that it should work with the NMDA solution.

I am arguing that I did NOT change {+restconf}/data, I just made its definition
more precise.

If configuration resources under {+restconf}/data are expected to be identical
to those under {+restconf}/ds/ietf-datastores:running, then draft-ietf-netconf-
nmda-restconf should say so.

Lada

> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Sep 26 04:25:11 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2241B130E84 for ; Wed, 26 Sep 2018 04:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yPaNQ_JADgX for ; Wed, 26 Sep 2018 04:25:06 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB019130E74 for ; Wed, 26 Sep 2018 04:25:06 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::404]) by mail.nic.cz (Postfix) with ESMTPSA id 30A9F6059E; Wed, 26 Sep 2018 13:25:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1537961105; bh=9S9bZaT+VZqgxKedEB51rv6Ot+1AySCea9QHYGYad7k=; h=From:To:Date; b=FBa5DJBUW9wxmxDyn0i90EYQ+fW924oDastdRkrWGXnFYI//3VHsOAO1PcFir50NT XfcCZ5NBInc+4sJdWOQrBNYJLpuCGFpGJylzndeZN8uL3OS9Udck84MFw/CqSLf4ye U23TRngEjMOsHp5wfR3xPGSJbASXm0PAvpuOFIuM=
Message-ID: <59d2b505319a874964436ab8c488a6d4f3a59fe9.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: netconf@ietf.org
Date: Wed, 26 Sep 2018 13:25:04 +0200
In-Reply-To: <20180926.130400.328479331143716638.mbj@tail-f.com>
References: <87lg7osfjt.fsf@nic.cz> <20180926.130400.328479331143716638.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [Netconf] {+restconf}/data vs 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 11:25:09 -0000

On Wed, 2018-09-26 at 13:04 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Hi,
> > 
> > draft-ietf-netconf-nmda-restconf is silent about the relationship
> > between the {+restconf}/data and the  datastore, and it cannot
> > be deduced from RFC 8040 either, because it only says in sec. 3.3.1:
> > 
> >    This mandatory resource [{+restconf}/data] represents the combined
> >    configuration and state data resources that can be accessed by a
> >    client.
> > 
> > I think this is a serious omission.
> 
> draft-ietf-netconf-nmda-restconf doesn't change {+restconf}/data.  It
> works as before.  See RFC 8040 section 1.4 for relationship to
> .

Sec. 1.4 is about coexistence with NETCONF, whereas draft-lhotka-netconf-
restconf-transactions facilitates the use of RESTCONF *without* NETCONF.

> 
> > Regarding draft-lhotka-netconf-restconf-transactions-00, I received a
> > lot of criticism for changing the semantics of
> > {+restconf}/data. However, I don't think it was the case: according to
> > the above definition, it seems perfectly OK if {+restconf}/data
> > represents combined configuration **from ** and state data.
> 
> This would violate section 1.4 of RFC 8040, at least if the RESTCONF
> server is co-located with a NETCONF server.

In fact, the use of the staging datastore makes sense only if  is not
writable and  not supported (or not used, at least). Moreover,
NETCONF server needn't be present at all.

Lada 

> 
> 
> 
> /martin
> 
> 
> > 
> > Lada
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Sep 26 04:32:48 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7015130E84 for ; Wed, 26 Sep 2018 04:32:46 -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 0Z1E_dTog27A for ; Wed, 26 Sep 2018 04:32:44 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8151512426A for ; Wed, 26 Sep 2018 04:32:44 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 9F0741AE02BE; Wed, 26 Sep 2018 13:32:43 +0200 (CEST)
Date: Wed, 26 Sep 2018 13:32:42 +0200 (CEST)
Message-Id: <20180926.133242.469987738646017624.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <59d2b505319a874964436ab8c488a6d4f3a59fe9.camel@nic.cz>
References: <87lg7osfjt.fsf@nic.cz> <20180926.130400.328479331143716638.mbj@tail-f.com> <59d2b505319a874964436ab8c488a6d4f3a59fe9.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] {+restconf}/data vs 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 11:32:47 -0000

Ladislav Lhotka  wrote:
> On Wed, 2018-09-26 at 13:04 +0200, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > Hi,
> > > 
> > > draft-ietf-netconf-nmda-restconf is silent about the relationship
> > > between the {+restconf}/data and the  datastore, and it cannot
> > > be deduced from RFC 8040 either, because it only says in sec. 3.3.1:
> > > 
> > >    This mandatory resource [{+restconf}/data] represents the combined
> > >    configuration and state data resources that can be accessed by a
> > >    client.
> > > 
> > > I think this is a serious omission.
> > 
> > draft-ietf-netconf-nmda-restconf doesn't change {+restconf}/data.  It
> > works as before.  See RFC 8040 section 1.4 for relationship to
> > .
> 
> Sec. 1.4 is about coexistence with NETCONF, whereas draft-lhotka-netconf-
> restconf-transactions facilitates the use of RESTCONF *without* NETCONF.

As I wrote in my reply to the adoption poll, I think that a staging
datastore would be useful also for NETCONF.  As such, I think it would
be unfortunate to do a solution that is just for RESTCONF, and even
worse, doesn't work if the RESTCONF server is co-located with a
NETCONF server.

> > > Regarding draft-lhotka-netconf-restconf-transactions-00, I received a
> > > lot of criticism for changing the semantics of
> > > {+restconf}/data. However, I don't think it was the case: according to
> > > the above definition, it seems perfectly OK if {+restconf}/data
> > > represents combined configuration **from ** and state data.
> > 
> > This would violate section 1.4 of RFC 8040, at least if the RESTCONF
> > server is co-located with a NETCONF server.
> 
> In fact, the use of the staging datastore makes sense only if  is not
> writable and  not supported (or not used, at least). Moreover,
> NETCONF server needn't be present at all.


/martin


> 
> Lada 
> 
> > 
> > 
> > 
> > /martin
> > 
> > 
> > > 
> > > Lada
> > > 
> > > -- 
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> > > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 


From nobody Wed Sep 26 04:40:02 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28790130E84; Wed, 26 Sep 2018 04:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.196
X-Spam-Level: ***
X-Spam-Status: No, score=3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, 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 X8nVXLJgP5Zi; Wed, 26 Sep 2018 04:39:58 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0120.outbound.protection.outlook.com [104.47.2.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC00C130E18; Wed, 26 Sep 2018 04:39:57 -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=0pfJ6PMgy1LpIyr1ZNLIHmJFZ6mKeDpSvgv/6yz+IdU=; b=dAhQ7i56KCfeW5HX6cPhaefNRZNVhUbaQk3aJXbvQLIJiJaJeIopQk4ee9/qFC5pQ14mgb9wot4X6ngv7OeXfZrDMbnsugnpZwKu2cHYagmFebdSwK060uk4hGqT2bbmxON/GZNOy0Tj+Vmcuwz2DuMLRkENuYtLdjQjr2nU3YY=
Received: from VI1PR07MB0831.eurprd07.prod.outlook.com (10.161.107.154) by VI1PR07MB4415.eurprd07.prod.outlook.com (20.176.7.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.13; Wed, 26 Sep 2018 11:39:55 +0000
Received: from VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db]) by VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db%12]) with mapi id 15.20.1185.014; Wed, 26 Sep 2018 11:39:55 +0000
From: tom petch 
To: Kent Watsen , Netconf , Robert Wilton 
CC: "netmod@ietf.org" 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUVK5AE/XTnvbPM0W59DOLk74sgg==
Date: Wed, 26 Sep 2018 11:39:54 +0000
Message-ID: <046001d4558d$91dfcce0$4001a8c0@gateway.2wire.net>
References: <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net> <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de> <5ED013C2-0D95-4B09-B0F5-D715DD58BE45@juniper.net>  <20180926063205.occ7oo5jxfnblvg5@anna.jacobs.jacobs-university.de>  <20180926092843.lzvxnh3ajnamfqxa@anna.jacobs.jacobs-university.de> 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: AM6PR06CA0005.eurprd06.prod.outlook.com (2603:10a6:20b:14::18) To VI1PR07MB0831.eurprd07.prod.outlook.com (2a01:111:e400:508e::26)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [81.131.229.47]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4415; 6:hOOUoobFyRRarws/IFgV/ngkcbFLwZXwgs+bOg5WAhe1bV6JiknlARw6gGYnKFEnUwHwMCW95N8gYmHV+Hc5qiQayosnJ1dAUbnXbepG2xK9oKS9MmwecmiEVi5urfjF2aaWToh0trz3Sgd+DyzLHMLr9qERTUtyUI1jo8lBNhKy9vgyq++rdgRzTRPAaPy4ovD1Ur2bj+25RoqC3lhWy4nkbhoWztpMMqcX1l8rfEVJKBYGWxOjDTuZc3Ng7P1jpF7js12RXzkzpg+VsAAczS7y0xmr43+j3pyRyGa9kb0P1IFg4xIt1d9QS49tMamZvStaMk+gvELugmSdlBBhqZyP8fDgnkcdjDfEl4NBfptffLsK8/iqDn9++e8qwqiaIkx7dcPBZ0xvHtoLcqOx77wF3LSUwatu//X7pdHeYOaKLHSTUBt/2tc6teSYUjmlhW8JaiBgqUA6xebmpSfHLg==; 5:nh2sgmNSGTlGYDRHDP4r8S4DpPJYyELKvNgHrE4qFhDrWS1Ie3szoDO2nW2BPVOJmiyOweGK9lkWHTjb1WhfoDLfEa+7jJzYozm3hGJ+pTUeUgS64GmVB9q8nw3+duEbOk3nVgajRIFNNDIgHYX7mXmEbDq+Sw9zZK5jmIS9SEA=; 7:fpdJyuhS+nxNdRuN3pSUA2AHVUOc/bBbAk1+GoOFn/ELFlwTLg8Ku4cb8A+ZMWB6oGgcvovKbH+1mC9hzhcDoYaP1IGeURsErOw7ObzkTlRjqJvbCaYenqXzeTxA31fUoAT0JZCkuuK6JT0CivIs9ogbbo8PHPCVclPZD7gEoXOYWFhN+nSX210l7Ju9eGdBcFpcNgdu39zC7zR0/gqb462Y3c6W33SK7sv2EQqgDdq78Rpi+5EJrMggm6S5M45y
x-ms-office365-filtering-correlation-id: 5639b211-365c-4712-91fa-08d623a4c71b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB4415; 
x-ms-traffictypediagnostic: VI1PR07MB4415:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014)(50582790962513)(138986009662008); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(201708071742011)(7699051); SRVR:VI1PR07MB4415; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4415; 
x-forefront-prvs: 08076ABC99
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(376002)(39860400002)(396003)(366004)(13464003)(51444003)(189003)(199004)(5660300001)(4326008)(86362001)(186003)(53546011)(33896004)(76176011)(26005)(6506007)(386003)(102836004)(2906002)(34290500001)(14496001)(305945005)(93886005)(14444005)(478600001)(5250100002)(256004)(1556002)(68736007)(1941001)(14454004)(966005)(3846002)(6116002)(52116002)(25786009)(316002)(44736005)(6486002)(81156014)(81166006)(6436002)(110136005)(8936002)(6306002)(9686003)(6512007)(86152003)(53936002)(66066001)(106356001)(8676002)(486006)(446003)(476003)(84392002)(71200400001)(105586002)(6246003)(7736002)(71190400001)(99286004)(2900100001)(97736004)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4415; H:VI1PR07MB0831.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-microsoft-antispam-message-info: lUk8rqCAm6daej4teAeuRBKOPzFLcYaiCFTxdz2TZr58ueJMb3JK0ygroJY7xFJG9MD0zdS4hdaGOaQ6J1Yy3XEGB50mWGYbl0SLiansDTXOmTOj7pdsX1vtNGGzFYGDbGLyN9KzBYPI9/Kjh+6s38kFMjRqMT0MusBJzcMuSF96nhRAR72WU8iXXvB/L9ZoFHHBlUpGrdp5ZahBh6G3P/TMqX/dYGc7n4EkJzJ8NPACYsvlE+HaOoVMuXUa2Y+wDL7wyqaYssbx7QIcipkd9iwHPUaf+u0yPccQcTzqjGvrcWEZGGt1XjDKVaZW1d0T/Su502R75W8pOAorL8OlH2QjCftSPAuUssktQbmr3Pk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5639b211-365c-4712-91fa-08d623a4c71b
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2018 11:39:54.9161 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4415
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 11:40:00 -0000

----- Original Message -----
From: "Robert Wilton" 
To: "Qin Wu" ; "Kent Watsen" ;
"Netconf" 
Sent: Wednesday, September 26, 2018 11:06 AM

> Hi Juergen,
>
> Yes, I think that updating RFC 6991 would be useful, if there are
types
> missing.


Give us a clue!

And isn't this one one for the netmod WG (a list that is pleasantly
quiet currently) ?

Tom Petch

> Thanks,
> Rob
>
>
> On 26/09/2018 10:28, Juergen Schoenwaelder wrote:
> > On Wed, Sep 26, 2018 at 08:00:26AM +0000, Qin Wu wrote:
> >> I wonder whether you really need a uint32 range of hours in the OAM
models.
> >>
> >> [Qin]: not necessary for OAM model, but It may be used in some
other models that require unint32 range of hours.
> > Authors may not want to depend on ietf-lime-time-types for generic
> > types for time periods, nor am I sure the solution there is a simple
> > solution.
> >
> > Perhaps its time to see whether it makes sense to spin an update of
> > RFC 6991 to add definitions that are apparently missing. Aftert 5
> > years this may be a reasonable thing to do. We should not hold off
> > work because of this but we may allow authors to transition to
common
> > definitions if what they do now is compatible with a common solution
> > underway. I would be willing to allocate some of my time to an
update
> > of RFC 6991 if the WG believes this is useful.
> >
> > /js
> >
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Wed Sep 26 05:02:26 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8692E1252B7 for ; Wed, 26 Sep 2018 05:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcRHaRNtS1UW for ; Wed, 26 Sep 2018 05:02:22 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6CF130E94 for ; Wed, 26 Sep 2018 05:02:21 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::404]) by mail.nic.cz (Postfix) with ESMTPSA id 877B760162; Wed, 26 Sep 2018 14:02:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1537963339; bh=HcxmBTHOtT2p4aeiGNxf+1myu6b+zPmJjaWTW70AI6A=; h=From:To:Date; b=TWHYphgdT5xWqg1aB5gGvFnlzJfZXmgrYMBdKnKYeng0UPa17Ngzqetw+fY5vW5l2 vkLUTVy+an39njB9itw/TgO5efT7UreAe0gigPtW/vBNPKYiLXRNKtSdv0Sq/ypcpw ovGv2VsYfTDb3/DMur32Spg2SLybvL64dSDrtwpc=
Message-ID: <6972ffe5927fe9665d8c1e5fcf0837be55a07c99.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: netconf@ietf.org
Date: Wed, 26 Sep 2018 14:02:19 +0200
In-Reply-To: <20180926.133242.469987738646017624.mbj@tail-f.com>
References: <87lg7osfjt.fsf@nic.cz> <20180926.130400.328479331143716638.mbj@tail-f.com> <59d2b505319a874964436ab8c488a6d4f3a59fe9.camel@nic.cz> <20180926.133242.469987738646017624.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [Netconf] {+restconf}/data vs 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 12:02:24 -0000

On Wed, 2018-09-26 at 13:32 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Wed, 2018-09-26 at 13:04 +0200, Martin Bjorklund wrote:
> > > Ladislav Lhotka  wrote:
> > > > Hi,
> > > > 
> > > > draft-ietf-netconf-nmda-restconf is silent about the relationship
> > > > between the {+restconf}/data and the  datastore, and it cannot
> > > > be deduced from RFC 8040 either, because it only says in sec. 3.3.1:
> > > > 
> > > >    This mandatory resource [{+restconf}/data] represents the combined
> > > >    configuration and state data resources that can be accessed by a
> > > >    client.
> > > > 
> > > > I think this is a serious omission.
> > > 
> > > draft-ietf-netconf-nmda-restconf doesn't change {+restconf}/data.  It
> > > works as before.  See RFC 8040 section 1.4 for relationship to
> > > .
> > 
> > Sec. 1.4 is about coexistence with NETCONF, whereas draft-lhotka-netconf-
> > restconf-transactions facilitates the use of RESTCONF *without* NETCONF.
> 
> As I wrote in my reply to the adoption poll, I think that a staging
> datastore would be useful also for NETCONF.  As such, I think it would
> be unfortunate to do a solution that is just for RESTCONF, and even
> worse, doesn't work if the RESTCONF server is co-located with a
> NETCONF server.

Section 1.4 assumes only two options for client's edits: either to 
(with :writable-running) or to . The staging datastore adds a new
option that is essentially incompatible with those two.

I support adding the staging datastore to NETCONF as well but the datastore
relationships need to be clarified. Specifically, I don't see any reason why
sec. 1.4 of RFC 8040 cannot be updated to say:

   Otherwise, if the device supports :staging, all edits to
   configuration nodes in {+restconf}/data are performed in the
   staging configuration datastore.

Lada

> 
> > > > Regarding draft-lhotka-netconf-restconf-transactions-00, I received a
> > > > lot of criticism for changing the semantics of
> > > > {+restconf}/data. However, I don't think it was the case: according to
> > > > the above definition, it seems perfectly OK if {+restconf}/data
> > > > represents combined configuration **from ** and state data.
> > > 
> > > This would violate section 1.4 of RFC 8040, at least if the RESTCONF
> > > server is co-located with a NETCONF server.
> > 
> > In fact, the use of the staging datastore makes sense only if  is
> not
> > writable and  not supported (or not used, at least). Moreover,
> > NETCONF server needn't be present at all.
> 
> 
> /martin
> 
> 
> > 
> > Lada 
> > 
> > > 
> > > 
> > > 
> > > /martin
> > > 
> > > 
> > > > 
> > > > Lada
> > > > 
> > > > -- 
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > Netconf@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Sep 26 05:24:57 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5502130E7E for ; Wed, 26 Sep 2018 05:24:55 -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 9aB9jg4J_d-A for ; Wed, 26 Sep 2018 05:24: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 939031252B7 for ; Wed, 26 Sep 2018 05:24:52 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 417C31AE02BE; Wed, 26 Sep 2018 14:24:51 +0200 (CEST)
Date: Wed, 26 Sep 2018 14:24:50 +0200 (CEST)
Message-Id: <20180926.142450.596442494013109121.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <6972ffe5927fe9665d8c1e5fcf0837be55a07c99.camel@nic.cz>
References: <59d2b505319a874964436ab8c488a6d4f3a59fe9.camel@nic.cz> <20180926.133242.469987738646017624.mbj@tail-f.com> <6972ffe5927fe9665d8c1e5fcf0837be55a07c99.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] {+restconf}/data vs 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 12:24:56 -0000

Ladislav Lhotka  wrote:
> On Wed, 2018-09-26 at 13:32 +0200, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > On Wed, 2018-09-26 at 13:04 +0200, Martin Bjorklund wrote:
> > > > Ladislav Lhotka  wrote:
> > > > > Hi,
> > > > > 
> > > > > draft-ietf-netconf-nmda-restconf is silent about the relationship
> > > > > between the {+restconf}/data and the  datastore, and it cannot
> > > > > be deduced from RFC 8040 either, because it only says in sec. 3.3.1:
> > > > > 
> > > > >    This mandatory resource [{+restconf}/data] represents the combined
> > > > >    configuration and state data resources that can be accessed by a
> > > > >    client.
> > > > > 
> > > > > I think this is a serious omission.
> > > > 
> > > > draft-ietf-netconf-nmda-restconf doesn't change {+restconf}/data.  It
> > > > works as before.  See RFC 8040 section 1.4 for relationship to
> > > > .
> > > 
> > > Sec. 1.4 is about coexistence with NETCONF, whereas draft-lhotka-netconf-
> > > restconf-transactions facilitates the use of RESTCONF *without* NETCONF.
> > 
> > As I wrote in my reply to the adoption poll, I think that a staging
> > datastore would be useful also for NETCONF.  As such, I think it would
> > be unfortunate to do a solution that is just for RESTCONF, and even
> > worse, doesn't work if the RESTCONF server is co-located with a
> > NETCONF server.
> 
> Section 1.4 assumes only two options for client's edits: either to 
> (with :writable-running) or to . The staging datastore adds a new
> option that is essentially incompatible with those two.
> 
> I support adding the staging datastore to NETCONF as well but the datastore
> relationships need to be clarified.

Agreed.

> Specifically, I don't see any reason why
> sec. 1.4 of RFC 8040 cannot be updated to say:
> 
>    Otherwise, if the device supports :staging, all edits to
>    configuration nodes in {+restconf}/data are performed in the
>    staging configuration datastore.

But your draft also requires the client to send an additional "commit"
rpc, which means that an old client that communicates with a server
that happens to implement staging won't work as expected.



/martin



> 
> Lada
> 
> > 
> > > > > Regarding draft-lhotka-netconf-restconf-transactions-00, I received a
> > > > > lot of criticism for changing the semantics of
> > > > > {+restconf}/data. However, I don't think it was the case: according to
> > > > > the above definition, it seems perfectly OK if {+restconf}/data
> > > > > represents combined configuration **from ** and state data.
> > > > 
> > > > This would violate section 1.4 of RFC 8040, at least if the RESTCONF
> > > > server is co-located with a NETCONF server.
> > > 
> > > In fact, the use of the staging datastore makes sense only if  is
> > not
> > > writable and  not supported (or not used, at least). Moreover,
> > > NETCONF server needn't be present at all.
> > 
> > 
> > /martin
> > 
> > 
> > > 
> > > Lada 
> > > 
> > > > 
> > > > 
> > > > 
> > > > /martin
> > > > 
> > > > 
> > > > > 
> > > > > Lada
> > > > > 
> > > > > -- 
> > > > > Ladislav Lhotka
> > > > > Head, CZ.NIC Labs
> > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > 
> > > > > _______________________________________________
> > > > > Netconf mailing list
> > > > > Netconf@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netconf
> > > > > 
> > > -- 
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 


From nobody Wed Sep 26 05:36:27 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6350120072; Wed, 26 Sep 2018 05:36:25 -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 7RRlIIOEcNTN; Wed, 26 Sep 2018 05:36:24 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9C0130E7E; Wed, 26 Sep 2018 05:36:24 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 1E0211AE02BE; Wed, 26 Sep 2018 14:36:23 +0200 (CEST)
Date: Wed, 26 Sep 2018 14:36:22 +0200 (CEST)
Message-Id: <20180926.143622.787516255799864354.mbj@tail-f.com>
To: aamelnikov@fastmail.fm
Cc: iesg@ietf.org, draft-ietf-netconf-nmda-restconf@ietf.org, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <153777458966.28052.8513670008966367067.idtracker@ietfa.amsl.com>
References: <153777458966.28052.8513670008966367067.idtracker@ietfa.amsl.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] Alexey Melnikov's No Objection on draft-ietf-netconf-nmda-restconf-04: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 12:36:26 -0000

Hi,

Alexey Melnikov  wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-netconf-nmda-restconf-04: 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-nmda-restconf/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In Section 3.2.1:
> 
>    Servers are not required to support all values in the "with-defaults"
>    query parameter on the operational state datastore.  If a request is
>    made using a value that is not supported, then the error handling
>    behavior is as described in ([RFC8040], Section 4.8.9).
> 
> This seems to be pointless, considering that the server already advertises
> support for the "with-defaults" capability. Can you maybe elaborate on which
> values are hard to implement (and thus likely not to be implemented)?

Yes you are right.  After discussing this with my co-authors, we
suggest that we simply remove this paragraph.


/martin


From nobody Wed Sep 26 05:39:43 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF471130E95 for ; Wed, 26 Sep 2018 05:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khpKNMtOekRJ for ; Wed, 26 Sep 2018 05:39:39 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1743120072 for ; Wed, 26 Sep 2018 05:39:38 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::404]) by mail.nic.cz (Postfix) with ESMTPSA id 054D6601FC; Wed, 26 Sep 2018 14:39:37 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1537965577; bh=tJEHs66P3bQHZiOIA4neiW6G8vfBUnUetwZejKc1FLM=; h=From:To:Date; b=gSSaO6erVirxm2axT9d6EJuuNnmoMghzBTkFwYyaJoyJXnFjx4J+Fa39mbCeNWC/k rKHUBKOOoakqV+ReTjIr/Zjss/fBuLUREZRHPYJrmOD9o7+Ci+X6MjAWJ7jADUYOEr MRiOPV+VQYOXzvCQSG6Cf+CQd6GLWJ2j8/qzAJAQ=
Message-ID: <52dd97d5adf40040d8b707c882dc6081a2a8965a.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: netconf@ietf.org
Date: Wed, 26 Sep 2018 14:39:36 +0200
In-Reply-To: <20180926.142450.596442494013109121.mbj@tail-f.com>
References: <59d2b505319a874964436ab8c488a6d4f3a59fe9.camel@nic.cz> <20180926.133242.469987738646017624.mbj@tail-f.com> <6972ffe5927fe9665d8c1e5fcf0837be55a07c99.camel@nic.cz> <20180926.142450.596442494013109121.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [Netconf] {+restconf}/data vs 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 12:39:42 -0000

On Wed, 2018-09-26 at 14:24 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Wed, 2018-09-26 at 13:32 +0200, Martin Bjorklund wrote:
> > > Ladislav Lhotka  wrote:
> > > > On Wed, 2018-09-26 at 13:04 +0200, Martin Bjorklund wrote:
> > > > > Ladislav Lhotka  wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > draft-ietf-netconf-nmda-restconf is silent about the relationship
> > > > > > between the {+restconf}/data and the  datastore, and it
> cannot
> > > > > > be deduced from RFC 8040 either, because it only says in sec. 3.3.1:
> > > > > > 
> > > > > >    This mandatory resource [{+restconf}/data] represents the
> combined
> > > > > >    configuration and state data resources that can be accessed by a
> > > > > >    client.
> > > > > > 
> > > > > > I think this is a serious omission.
> > > > > 
> > > > > draft-ietf-netconf-nmda-restconf doesn't change {+restconf}/data.  It
> > > > > works as before.  See RFC 8040 section 1.4 for relationship to
> > > > > .
> > > > 
> > > > Sec. 1.4 is about coexistence with NETCONF, whereas draft-lhotka-
> netconf-
> > > > restconf-transactions facilitates the use of RESTCONF *without* NETCONF.
> > > 
> > > As I wrote in my reply to the adoption poll, I think that a staging
> > > datastore would be useful also for NETCONF.  As such, I think it would
> > > be unfortunate to do a solution that is just for RESTCONF, and even
> > > worse, doesn't work if the RESTCONF server is co-located with a
> > > NETCONF server.
> > 
> > Section 1.4 assumes only two options for client's edits: either to 
> > (with :writable-running) or to . The staging datastore adds a new
> > option that is essentially incompatible with those two.
> > 
> > I support adding the staging datastore to NETCONF as well but the datastore
> > relationships need to be clarified.
> 
> Agreed.
> 
> > Specifically, I don't see any reason why
> > sec. 1.4 of RFC 8040 cannot be updated to say:
> > 
> >    Otherwise, if the device supports :staging, all edits to
> >    configuration nodes in {+restconf}/data are performed in the
> >    staging configuration datastore.
> 
> But your draft also requires the client to send an additional "commit"
> rpc, which means that an old client that communicates with a server
> that happens to implement staging won't work as expected.

This is true. One way to work around this (Rob's suggestion) is to require the
user to explicitly start the "staging mode" with an operation (such as "clone"
or "checkout"). Until then, all edits would be as specified in Sec. 1.4.

Lada

> 
> 
> 
> /martin
> 
> 
> 
> > 
> > Lada
> > 
> > > 
> > > > > > Regarding draft-lhotka-netconf-restconf-transactions-00, I received
> a
> > > > > > lot of criticism for changing the semantics of
> > > > > > {+restconf}/data. However, I don't think it was the case: according
> to
> > > > > > the above definition, it seems perfectly OK if {+restconf}/data
> > > > > > represents combined configuration **from ** and state data.
> > > > > 
> > > > > This would violate section 1.4 of RFC 8040, at least if the RESTCONF
> > > > > server is co-located with a NETCONF server.
> > > > 
> > > > In fact, the use of the staging datastore makes sense only if 
> is
> > > not
> > > > writable and  not supported (or not used, at least).
> Moreover,
> > > > NETCONF server needn't be present at all.
> > > 
> > > 
> > > /martin
> > > 
> > > 
> > > > 
> > > > Lada 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > /martin
> > > > > 
> > > > > 
> > > > > > 
> > > > > > Lada
> > > > > > 
> > > > > > -- 
> > > > > > Ladislav Lhotka
> > > > > > Head, CZ.NIC Labs
> > > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Netconf mailing list
> > > > > > Netconf@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/netconf
> > > > > > 
> > > > -- 
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Sep 26 05:43:35 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155B9130E95 for ; Wed, 26 Sep 2018 05:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DRYnqhwX-J9M for ; Wed, 26 Sep 2018 05:43:30 -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 3CD9C120072 for ; Wed, 26 Sep 2018 05:43:30 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D91B3E2C; Wed, 26 Sep 2018 14:43:28 +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 8UXdRD-feNo2; Wed, 26 Sep 2018 14:43:28 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 26 Sep 2018 14:43:28 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA1A620036; Wed, 26 Sep 2018 14:43:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id s-VacIi_WZ0h; Wed, 26 Sep 2018 14:43:28 +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 "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 36A8620035; Wed, 26 Sep 2018 14:43:28 +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.1415.2; Wed, 26 Sep 2018 14:43:27 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 86F3F2552DA4; Wed, 26 Sep 2018 14:43:27 +0200 (CEST)
Date: Wed, 26 Sep 2018 14:43:27 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
CC: Netconf 
Message-ID: <20180926124327.3aho22r47l5vv4yt@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Ladislav Lhotka , Netconf 
References: <87lg7osfjt.fsf@nic.cz> <20180926105813.5o47jfszwefzwloa@anna.jacobs.jacobs-university.de> <620e0bb5a40c29809e7a47a0fd69b694db76d3db.camel@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <620e0bb5a40c29809e7a47a0fd69b694db76d3db.camel@nic.cz>
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] {+restconf}/data vs 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 12:43:33 -0000

On Wed, Sep 26, 2018 at 01:10:53PM +0200, Ladislav Lhotka wrote:
> On Wed, 2018-09-26 at 12:58 +0200, Juergen Schoenwaelder wrote:
> > On Wed, Sep 26, 2018 at 12:45:26PM +0200, Ladislav Lhotka wrote:
> > > Hi,
> > > 
> > > draft-ietf-netconf-nmda-restconf is silent about the relationship
> > > between the {+restconf}/data and the  datastore, and it cannot
> > > be deduced from RFC 8040 either, because it only says in sec. 3.3.1:
> > > 
> > >    This mandatory resource [{+restconf}/data] represents the combined
> > >    configuration and state data resources that can be accessed by a
> > >    client.
> > > 
> > > I think this is a serious omission.
> > 
> > We are not changing {+restconf}/data.
> 
> My point is that it is unclear what {+restconf}/data really is: "the combined
> configuration and state data resources" is too vague given that several
> configuration datastores may be present.
>

Well, {+restconf}/data is whatever RFC 8040 says it is. We are not
changing it. If you want to interact with an NMDA datastore, then
there is a defined way to do so.

> > > Regarding draft-lhotka-netconf-restconf-transactions-00, I received a
> > > lot of criticism for changing the semantics of
> > > {+restconf}/data. However, I don't think it was the case: according to
> > > the above definition, it seems perfectly OK if {+restconf}/data
> > > represents combined configuration **from ** and state data.
> > 
> > Perhaps people had the impression that your proposal changes
> > {+restconf}/data or that it should work with the NMDA solution.
> 
> I am arguing that I did NOT change {+restconf}/data, I just made its
> definition more precise.

Making something more precise may be seen by others as changes. Within
the NMDA work, we quickly discovered that the only backwards
compatible way to introduce NMDA to RESTCONF is to expose NMDA
datastores as new resources instead of trying to give an existing
resource a different meaning.
 
> If configuration resources under {+restconf}/data are expected to be
> identical to those under {+restconf}/ds/ietf-datastores:running,
> then draft-ietf-netconf- nmda-restconf should say so.

NMDA does not say what {+restconf}/data is because RFC 8040 defines
what {+restconf}/data is. Among other things, RFC 8040 says this:

      By default, RESTCONF
      methods access a unified view of the underlying datastore
      implementation on the server.

So {+restconf}/data is most likely not the same as
{+restconf}/ds/ietf-datastores:running.

/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 Sep 26 07:56:34 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5944130F44 for ; Wed, 26 Sep 2018 07:56:28 -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 4xOOXAPuwQxI for ; Wed, 26 Sep 2018 07:56:26 -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 6BBC3130F1C for ; Wed, 26 Sep 2018 07:56:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2272; q=dns/txt; s=iport; t=1537973764; x=1539183364; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cMSWcSDpNBYSC98uKq2MgNeLaVsIxlG/3SE5hzitqgU=; b=l3Y3yK513JFGAbsCmujniwul744DmothZJXBqWDcHndpyhtJuYYhSnWM b+LWEtvwpvUUFzuSMILsJWuGiRH7IgrjVZ2Ap/P+EZipJ57sWa0GE8SQ+ 11DDB8BO+2OdwUUYCXwxD40uUSneTddmAShNmKxsy815VgR8oaXgftOv0 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAACFnatb/4gNJK1XAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVGBXy9lfygKg2qIFYwxgWglgz2TEoF6CxgLCYN6RgI?= =?us-ascii?q?Xg2YhNBgBAwEBAgEBAm0cDIU5AQEBAwEBIRE6Cw4CAgEIDgIIAgImAgICGQw?= =?us-ascii?q?LFRACBAENBRuDBgGCAQ+jI4EuihAFBYEGiXAXgUE/gRInDBOCTIMbAQGBYRc?= =?us-ascii?q?KGQ2COjGCJgKdBwkCkCsXgUaNbohwi3oCERSBJR04J4EucBU7KgGCQYY1hGG?= =?us-ascii?q?FPm+BFosPAYEdAQE?=
X-IronPort-AV: E=Sophos;i="5.54,306,1534809600"; d="scan'208";a="460827773"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2018 14:56:03 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id w8QEu2fK028643 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2018 14:56:03 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Sep 2018 09:56:02 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Wed, 26 Sep 2018 09:56:02 -0500
From: "Reshad Rahman (rrahman)" 
To: Juergen Schoenwaelder , Qin Wu 
CC: Netconf 
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImsuTOQ+mtPeEmuDqwHWlbymKUBzD8AgAAPiICAAD1IgIAADScAgAA0RACAAFWMgIAAGK8AgAAYq4CAABhkgA==
Date: Wed, 26 Sep 2018 14:56:02 +0000
Message-ID: 
References: <20180924.093612.1791958587714330227.mbj@tail-f.com>  <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net>  <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net> <20180925213145.r72ybqbuv5qy4dct@anna.jacobs.jacobs-university.de> <5ED013C2-0D95-4B09-B0F5-D715DD58BE45@juniper.net>  <20180926063205.occ7oo5jxfnblvg5@anna.jacobs.jacobs-university.de>  <20180926092843.lzvxnh3ajnamfqxa@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180926092843.lzvxnh3ajnamfqxa@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.40]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: 
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 14:56:32 -0000

SGksDQoNCg0K77u/T24gMjAxOC0wOS0yNiwgNToyOSBBTSwgIk5ldGNvbmYgb24gYmVoYWxmIG9m
IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh
bGYgb2Ygai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KICAg
IE9uIFdlZCwgU2VwIDI2LCAyMDE4IGF0IDA4OjAwOjI2QU0gKzAwMDAsIFFpbiBXdSB3cm90ZToN
CiAgICA+IEkgd29uZGVyIHdoZXRoZXIgeW91IHJlYWxseSBuZWVkIGEgdWludDMyIHJhbmdlIG9m
IGhvdXJzIGluIHRoZSBPQU0gbW9kZWxzLiANCiAgICA+IAkNCiAgICA+IFtRaW5dOiBub3QgbmVj
ZXNzYXJ5IGZvciBPQU0gbW9kZWwsIGJ1dCBJdCBtYXkgYmUgdXNlZCBpbiBzb21lIG90aGVyIG1v
ZGVscyB0aGF0IHJlcXVpcmUgdW5pbnQzMiByYW5nZSBvZiBob3Vycy4NCiAgICANCiAgICBBdXRo
b3JzIG1heSBub3Qgd2FudCB0byBkZXBlbmQgb24gaWV0Zi1saW1lLXRpbWUtdHlwZXMgZm9yIGdl
bmVyaWMNCiAgICB0eXBlcyBmb3IgdGltZSBwZXJpb2RzLCBub3IgYW0gSSBzdXJlIHRoZSBzb2x1
dGlvbiB0aGVyZSBpcyBhIHNpbXBsZQ0KICAgIHNvbHV0aW9uLg0KICAgIA0KICAgIFBlcmhhcHMg
aXRzIHRpbWUgdG8gc2VlIHdoZXRoZXIgaXQgbWFrZXMgc2Vuc2UgdG8gc3BpbiBhbiB1cGRhdGUg
b2YNCiAgICBSRkMgNjk5MSB0byBhZGQgZGVmaW5pdGlvbnMgdGhhdCBhcmUgYXBwYXJlbnRseSBt
aXNzaW5nLiBBZnRlcnQgNQ0KICAgIHllYXJzIHRoaXMgbWF5IGJlIGEgcmVhc29uYWJsZSB0aGlu
ZyB0byBkby4gV2Ugc2hvdWxkIG5vdCBob2xkIG9mZg0KICAgIHdvcmsgYmVjYXVzZSBvZiB0aGlz
IGJ1dCB3ZSBtYXkgYWxsb3cgYXV0aG9ycyB0byB0cmFuc2l0aW9uIHRvIGNvbW1vbg0KICAgIGRl
ZmluaXRpb25zIGlmIHdoYXQgdGhleSBkbyBub3cgaXMgY29tcGF0aWJsZSB3aXRoIGEgY29tbW9u
IHNvbHV0aW9uDQogICAgdW5kZXJ3YXkuIEkgd291bGQgYmUgd2lsbGluZyB0byBhbGxvY2F0ZSBz
b21lIG9mIG15IHRpbWUgdG8gYW4gdXBkYXRlDQogICAgb2YgUkZDIDY5OTEgaWYgdGhlIFdHIGJl
bGlldmVzIHRoaXMgaXMgdXNlZnVsLg0KDQo8UlI+IEkgYmVsaWV2ZSB0aGlzIGlzIHVzZWZ1bC4g
T25lIGRlZmluaXRpb24gd2hpY2ggaXMgbWlzc2luZyBpcyBkYXRlICh3ZSBkaXNjdXNzZWQgdGhp
cyBvbiBZRCBhbGlhcyBpbiBNYXJjaCkuDQoNClJlZ2FyZHMsDQpSZXNoYWQuDQogICAgDQogICAg
L2pzDQogICAgDQogICAgLS0gDQogICAgSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBK
YWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCiAgICBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4
NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQogICAgRmF4
OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNp
dHkuZGUvPg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQogICAgTmV0Y29uZiBtYWlsaW5nIGxpc3QNCiAgICBOZXRjb25mQGlldGYub3Jn
DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQogICAg
DQoNCg==


From nobody Wed Sep 26 10:52:29 2018
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 489E3128766; Wed, 26 Sep 2018 10:52:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk 
To: "The IESG" 
Cc: draft-ietf-netconf-nmda-netconf@ietf.org, Mahesh Jethanandani , netconf-chairs@ietf.org, mjethanandani@gmail.com, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153798433929.21634.492484619504901988.idtracker@ietfa.amsl.com>
Date: Wed, 26 Sep 2018 10:52:19 -0700
Archived-At: 
Subject: [Netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-nmda-netconf-06: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 17:52:19 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netconf-nmda-netconf-06: 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-nmda-netconf/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the well-written document!

I only had one comment, namely that Sections 3.1.1.1 and 3.1.2 end with text that
certain behavior for non-8342 datastores "SHOULD be defined by the specification
for the datastore", and it wasn't entirely clear to me that the 2119 SHOULD was
necessary (since it would be attempting to constrain the behavior of future specifications,
which is always a bit dicey since they could just update this specification to remove
the constraint anyway).



From nobody Wed Sep 26 14:08:31 2018
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 EE6F812F1AB; Wed, 26 Sep 2018 14:08:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper 
To: "The IESG" 
Cc: draft-ietf-netconf-nmda-restconf@ietf.org, Mahesh Jethanandani , netconf-chairs@ietf.org, mjethanandani@gmail.com, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153799610397.21672.18066366208423632685.idtracker@ietfa.amsl.com>
Date: Wed, 26 Sep 2018 14:08:23 -0700
Archived-At: 
Subject: [Netconf] Alissa Cooper's No Objection on draft-ietf-netconf-nmda-restconf-04: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 21:08:24 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-netconf-nmda-restconf-04: 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-nmda-restconf/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please apply the changes resulting from the Gen-ART review: either removing or
clarifying the text about 'ds-ephemeral', adding clarifying text about GET, and
adding the missing ')' in Section 5.



From nobody Wed Sep 26 14:09:36 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2D41294D7; Wed, 26 Sep 2018 14:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=KALRunFq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dS0pnLuh
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpU5dV5Pkc-U; Wed, 26 Sep 2018 14:09:31 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7BC12F1AB; Wed, 26 Sep 2018 14:09:28 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3098021F9B; Wed, 26 Sep 2018 17:09:27 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 26 Sep 2018 17:09:27 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=qSWLpXP2EQ+o5wGx41bfa5qvXO0qT PJvk8VcGr0xqtE=; b=KALRunFqepbtxpfLf3hyXoJZwEO/dzefCgXYikwylT+Fe hnb6I3Dj2Py42bD9+8TeHsMuCRmqMXAGsaBW0DGCWqgJj8/zTqGUv7ngKkJ3N++Q JeOetyuX0Q46AZoOft4SAO93PHrxCeswOODLbPWUGHM/eIY4OmLir6o5Ka4midh/ LmfSIes3tiUYGC+PceeZ4sC6rsiBvvraqOr+NnZRGmwZUUulcZRHtG71IHw7OKWQ 09owYDISeEGFTaji60J1b3ZchqodA436MEsXYOoTZmK4wpiBhwstgglsp1JzmDEW 3G+UVj1RvUHJeW46sAdD2HedUVQKPWCSUopSMWyEw==
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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=qSWLpX P2EQ+o5wGx41bfa5qvXO0qTPJvk8VcGr0xqtE=; b=dS0pnLuhiV5rH7gO4bVPMK cTHqb4xfWal6av2yDlzd4OKuDq2XZR2+/rogE3RTg78w7mYMHRhHgHeC1Bww8Ww+ 31evROpEP7bI0qHvRaIi9sLFxtDOKS1qgkYcTPF2f70L0V6gA+KA0FNL3NxOW/aN JdbuEuFCfBD33saqYmIdD7/QKj7yCze3kU0jlklshAQ0qMq5UZBM45tt+yVlH1fQ Kkbbq08DwKQ9wopypYi6qIoHq8Nc4xqDj6DsNJDGg9UllbP1CA1ymYcD+P6Mc9fD j46ZV2W0RU/HmYA+6914nqMhXE637AH7ZRNB+4qyPtho0dCDVRraL/tZMHoXJoVw ==
X-ME-Proxy:      
X-ME-Sender: 
Received: from [10.154.183.69] (unknown [128.107.241.173]) by mail.messagingengine.com (Postfix) with ESMTPA id 17776E47C2; Wed, 26 Sep 2018 17:09:26 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper 
In-Reply-To: <153021527663.18602.3527119969520295546@ietfa.amsl.com>
Date: Wed, 26 Sep 2018 14:09:23 -0700
Cc: gen-art , draft-ietf-netconf-nmda-restconf.all@ietf.org,  netconf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <03F784DC-6913-4D07-9371-127A240C41F3@cooperw.in>
References: <153021527663.18602.3527119969520295546@ietfa.amsl.com>
To: Russ Housley 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [Netconf] [Gen-art] Genart last call review of draft-ietf-netconf-nmda-restconf-04
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 21:09:34 -0000

Russ, thanks for your review. I have flagged it in my No Objection =
ballot since the edits have not been applied yet.

Alissa

> On Jun 28, 2018, at 3:47 PM, Russ Housley  =
wrote:
>=20
> Reviewer: Russ Housley
> Review result: Ready with Nits
>=20
> 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.
>=20
> For more information, please see the FAQ at
> .
>=20
> Document: draft-ietf-netconf-nmda-restconf-04
> Reviewer: Russ Housley
> Review Date: 2018-06-28
> IETF LC End Date: 2018-07-09
> IESG Telechat date: unknown
>=20
> Summary: Ready
>=20
>=20
> Major Concerns:
>=20
> None.
>=20
>=20
> Minor Concerns:
>=20
> The last paragraph of Section 3.1 says:
>=20
>   If a server implements the example datastore "ds-ephemeral" in the
>   module "example-ds-ephemeral", it would implement the resource
>   {+restconf}/ds/example-ds-ephemeral:ds-ephemeral.
>=20
> It is unclear to me why this datastore is not included in the bullets
> at the beginning of the section.  Obviously, it is optional to
> implement, but so are two of the datastores that are included in
> the list.
>=20
> The last bullet of Section 3.2 says that [RFC8040], Section 3.5.4,
> paragraph 3 does not apply when interacting with any resource under
> {+restconf}/ds.  The referenced paragraph says:
>=20
>   If the target of a GET method is a data node that represents a leaf
>   or leaf-list that has a default value and the leaf or leaf-list has
>   not been instantiated yet, the server MUST return the default value
>   or values that are in use by the server.  In this case, the server
>   MUST ignore its "basic-mode", described in Section 4.8.9, and return
>   the default value.
>=20
> I suspect that this paragraph does not apply because the leaf and
> leaf-list will always be instantiated.  A sentence to say one way or
> the other would be useful to the implementer.
>=20
>=20
> Nits:
>=20
> There is a missing ')' in the last paragraph of Section 5.
>=20
>=20
>=20
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


From nobody Wed Sep 26 14:25:02 2018
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 AF4581294D7; Wed, 26 Sep 2018 14:24:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper 
To: "The IESG" 
Cc: draft-ietf-netconf-nmda-netconf@ietf.org, Mahesh Jethanandani , netconf-chairs@ietf.org, mjethanandani@gmail.com, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153799709271.21513.8889825674655634750.idtracker@ietfa.amsl.com>
Date: Wed, 26 Sep 2018 14:24:52 -0700
Archived-At: 
Subject: [Netconf] Alissa Cooper's No Objection on draft-ietf-netconf-nmda-netconf-06: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 21:24:53 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-netconf-nmda-netconf-06: 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-nmda-netconf/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with the conclusion in the thread about the Gen-ART review that the
fact that a NETCONF server implementing NMDA (RFC 8342) has to implement this
update to RFC 6241 should be made more clear. I don't think the normative
requirements discussed on clients need to be added though.



From nobody Wed Sep 26 14:25:45 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5270712F1A2; Wed, 26 Sep 2018 14:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=VZbORg4E; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tA7G3WHq
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ciBpovb4dmv; Wed, 26 Sep 2018 14:25:34 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC22612F1AB; Wed, 26 Sep 2018 14:25:31 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 93DBB21F1A; Wed, 26 Sep 2018 17:25:30 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 26 Sep 2018 17:25:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ZaLjK0w5FTb2aMrw1FsdzyTiYnUkg pVQ9eb1vlcTBBs=; b=VZbORg4EVx7aiNd64dDTSDJ9pPwTvagvVOR61g6Z5hMiU 4PGnJCkatOZba5bzqJTmfBZ8bb8aYql98XcmVW3SmvaK9ptWfI8bxYpXf2EDyg8k nKC3D9qUd0gLOg+qrGMIKlKYKKhTGH6WxwOWnNnkadWa/qQR6sux1JaYmj9lQ/IL xt4h66uB6544mI53HBElNFLpGWLJFbIdh5Yv2KcemurTJ/9RyWygY09MK9ApO39n K5JYEAal1zWLeuqG1Da7dh+gvxvtokBjBMiA0CGXn3GT1JXYdMt9/ca8zFJQs1EG WuRquddWQ2AfaICsZT7srjosxA228lIQwgUeLBZhA==
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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ZaLjK0 w5FTb2aMrw1FsdzyTiYnUkgpVQ9eb1vlcTBBs=; b=tA7G3WHqpyfNkcad5nCYUV XnJjzsRI5MgjSrs3pRwjgQgYKAR9beq3OdJdY+T7/9l4HXVM+DohkxiBxT9IBfMO 8jefhFP/dSJjxuipEaj5t9e8p+55mUtFIe9TMxQ3/qoK79ixKlYts7fupmj7iWNG fISE3tyKuzBhpRJQZkrQRf8jNsKLycCQlbczGODZ/LWT+n2tuMriiqkZKy+qJ8LY PO67J15GKakdFopVgbK066HgviVSg2YKar08FDkWsQRPoRvZI5FnGHui6BLDzA1a gonUx5qsAYY/LHt1BCEYYqncRIRu8ZZ7u3YnqrhAYWT0JLj74DbGwSapnon7y95Q ==
X-ME-Proxy:      
X-ME-Sender: 
Received: from [10.154.183.69] (unknown [128.107.241.173]) by mail.messagingengine.com (Postfix) with ESMTPA id C66B1E44DF; Wed, 26 Sep 2018 17:25:29 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper 
In-Reply-To: <20180716105513.5457wkuu4cb6gtdd@anna.jacobs.jacobs-university.de>
Date: Wed, 26 Sep 2018 14:25:28 -0700
Cc: gen-art , draft-ietf-netconf-nmda-netconf.all@ietf.org,  netconf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0047A04B-A30D-464F-BFD3-545806F486AB@cooperw.in>
References: <153122128332.25153.10473559847025784058@ietfa.amsl.com> <20180716105513.5457wkuu4cb6gtdd@anna.jacobs.jacobs-university.de>
To: Christer Holmberg 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [Netconf] [Gen-art] Genart last call review of draft-ietf-netconf-nmda-netconf-06
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2018 21:25:36 -0000

Christer, thanks for your review. I have flagged your first comment in =
my No Objection ballot since it seems like a good point to clarify.

Alissa

> On Jul 16, 2018, at 6:55 AM, Juergen Schoenwaelder =
 wrote:
>=20
> On Tue, Jul 10, 2018 at 04:14:43AM -0700, Christer Holmberg wrote:
>>=20
>> Minor issues:
>>=20
>> Sometimes, when a draft updates an existing RFC, people ask whether
>> implementations not implementing the draft are still compliant with =
the updated
>> RFC. Based on discussions, the consensus seems to be that existing
>> implementations are still compliant, and if one wants to mandate the =
new
>> features a bis is needed. I would just like to confirm whether that =
applies
>> also to this draft. If so, perhaps a note indicating that would be =
useful, in
>> order to avoid discussions in future?
>=20
> An existing NETCONF server not implementing NMDA is still compliant to
> the RFC 6241. However, a NETCONF server implementing NMDA (RFC 8342)
> has to implement this update to RFC 6241. Do you want to have this
> stated more explicitly? (We will have the same for RESTCONF and the
> NMDA update of RESTCONF.)
>=20
>> Related to that, it would also be good to have an interoperability
>> statement, saying that implementations that implement the draft will
>> still work with implementations that do not.
>=20
> This primarily concerns clients: They need to be able to fallback to
> using  instead of  and  instead of
>  if they communicate with a non NMDA NETCONF server. I am
> not sure whether this is a "SHOULD be able to fallback" or a "MUST be
> able to fallback".
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


From nobody Wed Sep 26 20:44:41 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06709124C04 for ; Wed, 26 Sep 2018 20:44:40 -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, 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 p81x9cg2bR-J for ; Wed, 26 Sep 2018 20:44:37 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C373130FC1 for ; Wed, 26 Sep 2018 20:44:34 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7623FC1B77D33; Thu, 27 Sep 2018 04:44:29 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 27 Sep 2018 04:44:30 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0399.000; Thu, 27 Sep 2018 11:44:25 +0800
From: Qin Wu 
To: Ladislav Lhotka , Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] {+restconf}/data vs 
Thread-Index: AQHUVYaZn5HU8OONKUG66edIR0CUn6UB4BcAgAAF4wCAAAIiAIAACEaAgAAGSwCAAAQgAIABgh0Q
Date: Thu, 27 Sep 2018 03:44:25 +0000
Message-ID: 
References: <59d2b505319a874964436ab8c488a6d4f3a59fe9.camel@nic.cz> <20180926.133242.469987738646017624.mbj@tail-f.com> <6972ffe5927fe9665d8c1e5fcf0837be55a07c99.camel@nic.cz> <20180926.142450.596442494013109121.mbj@tail-f.com> <52dd97d5adf40040d8b707c882dc6081a2a8965a.camel@nic.cz>
In-Reply-To: <52dd97d5adf40040d8b707c882dc6081a2a8965a.camel@nic.cz>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] {+restconf}/data vs 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2018 03:44:40 -0000

LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5j
ZXNAaWV0Zi5vcmddILT6se0gTGFkaXNsYXYgTGhvdGthDQq3osvNyrG85DogMjAxOMTqOdTCMjbI
1SAyMDo0MA0KytW8/sjLOiBNYXJ0aW4gQmpvcmtsdW5kDQqzrcvNOiBuZXRjb25mQGlldGYub3Jn
DQrW98ziOiBSZTogW05ldGNvbmZdIHsrcmVzdGNvbmZ9L2RhdGEgdnMgPHJ1bm5pbmc+DQoNCk9u
IFdlZCwgMjAxOC0wOS0yNiBhdCAxNDoyNCArMDIwMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToN
Cj4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPiBPbiBXZWQsIDIw
MTgtMDktMjYgYXQgMTM6MzIgKzAyMDAsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4gPiBM
YWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+ID4gPiBPbiBXZWQsIDIw
MTgtMDktMjYgYXQgMTM6MDQgKzAyMDAsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4gPiA+
ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPiA+ID4gPiA+IEhp
LA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1yZXN0
Y29uZiBpcyBzaWxlbnQgYWJvdXQgdGhlIA0KPiA+ID4gPiA+ID4gcmVsYXRpb25zaGlwIGJldHdl
ZW4gdGhlIHsrcmVzdGNvbmZ9L2RhdGEgYW5kIHRoZSA8cnVubmluZz4gDQo+ID4gPiA+ID4gPiBk
YXRhc3RvcmUsIGFuZCBpdA0KPiBjYW5ub3QNCj4gPiA+ID4gPiA+IGJlIGRlZHVjZWQgZnJvbSBS
RkMgODA0MCBlaXRoZXIsIGJlY2F1c2UgaXQgb25seSBzYXlzIGluIHNlYy4gMy4zLjE6DQo+ID4g
PiA+ID4gPiANCj4gPiA+ID4gPiA+ICAgIFRoaXMgbWFuZGF0b3J5IHJlc291cmNlIFt7K3Jlc3Rj
b25mfS9kYXRhXSByZXByZXNlbnRzIHRoZQ0KPiBjb21iaW5lZA0KPiA+ID4gPiA+ID4gICAgY29u
ZmlndXJhdGlvbiBhbmQgc3RhdGUgZGF0YSByZXNvdXJjZXMgdGhhdCBjYW4gYmUgYWNjZXNzZWQg
YnkgYQ0KPiA+ID4gPiA+ID4gICAgY2xpZW50Lg0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBJ
IHRoaW5rIHRoaXMgaXMgYSBzZXJpb3VzIG9taXNzaW9uLg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+
IGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25mIGRvZXNuJ3QgY2hhbmdlIA0KPiA+ID4g
PiA+IHsrcmVzdGNvbmZ9L2RhdGEuICBJdCB3b3JrcyBhcyBiZWZvcmUuICBTZWUgUkZDIDgwNDAg
c2VjdGlvbiANCj4gPiA+ID4gPiAxLjQgZm9yIHJlbGF0aW9uc2hpcCB0byA8cnVubmluZz4uDQo+
ID4gPiA+IA0KPiA+ID4gPiBTZWMuIDEuNCBpcyBhYm91dCBjb2V4aXN0ZW5jZSB3aXRoIE5FVENP
TkYsIHdoZXJlYXMgDQo+ID4gPiA+IGRyYWZ0LWxob3RrYS0NCj4gbmV0Y29uZi0NCj4gPiA+ID4g
cmVzdGNvbmYtdHJhbnNhY3Rpb25zIGZhY2lsaXRhdGVzIHRoZSB1c2Ugb2YgUkVTVENPTkYgKndp
dGhvdXQqIE5FVENPTkYuDQo+ID4gPiANCj4gPiA+IEFzIEkgd3JvdGUgaW4gbXkgcmVwbHkgdG8g
dGhlIGFkb3B0aW9uIHBvbGwsIEkgdGhpbmsgdGhhdCBhIA0KPiA+ID4gc3RhZ2luZyBkYXRhc3Rv
cmUgd291bGQgYmUgdXNlZnVsIGFsc28gZm9yIE5FVENPTkYuICBBcyBzdWNoLCBJIA0KPiA+ID4g
dGhpbmsgaXQgd291bGQgYmUgdW5mb3J0dW5hdGUgdG8gZG8gYSBzb2x1dGlvbiB0aGF0IGlzIGp1
c3QgZm9yIA0KPiA+ID4gUkVTVENPTkYsIGFuZCBldmVuIHdvcnNlLCBkb2Vzbid0IHdvcmsgaWYg
dGhlIFJFU1RDT05GIHNlcnZlciBpcyANCj4gPiA+IGNvLWxvY2F0ZWQgd2l0aCBhIE5FVENPTkYg
c2VydmVyLg0KPiA+IA0KPiA+IFNlY3Rpb24gMS40IGFzc3VtZXMgb25seSB0d28gb3B0aW9ucyBm
b3IgY2xpZW50J3MgZWRpdHM6IGVpdGhlciB0byANCj4gPiA8cnVubmluZz4gKHdpdGggOndyaXRh
YmxlLXJ1bm5pbmcpIG9yIHRvIDxjYW5kaWRhdGU+LiBUaGUgc3RhZ2luZyANCj4gPiBkYXRhc3Rv
cmUgYWRkcyBhIG5ldyBvcHRpb24gdGhhdCBpcyBlc3NlbnRpYWxseSBpbmNvbXBhdGlibGUgd2l0
aCB0aG9zZSB0d28uDQo+ID4gDQo+ID4gSSBzdXBwb3J0IGFkZGluZyB0aGUgc3RhZ2luZyBkYXRh
c3RvcmUgdG8gTkVUQ09ORiBhcyB3ZWxsIGJ1dCB0aGUgDQo+ID4gZGF0YXN0b3JlIHJlbGF0aW9u
c2hpcHMgbmVlZCB0byBiZSBjbGFyaWZpZWQuDQo+IA0KPiBBZ3JlZWQuDQo+IA0KPiA+IFNwZWNp
ZmljYWxseSwgSSBkb24ndCBzZWUgYW55IHJlYXNvbiB3aHkgc2VjLiAxLjQgb2YgUkZDIDgwNDAg
Y2Fubm90IA0KPiA+IGJlIHVwZGF0ZWQgdG8gc2F5Og0KPiA+IA0KPiA+ICAgIE90aGVyd2lzZSwg
aWYgdGhlIGRldmljZSBzdXBwb3J0cyA6c3RhZ2luZywgYWxsIGVkaXRzIHRvDQo+ID4gICAgY29u
ZmlndXJhdGlvbiBub2RlcyBpbiB7K3Jlc3Rjb25mfS9kYXRhIGFyZSBwZXJmb3JtZWQgaW4gdGhl
DQo+ID4gICAgc3RhZ2luZyBjb25maWd1cmF0aW9uIGRhdGFzdG9yZS4NCj4gDQo+IEJ1dCB5b3Vy
IGRyYWZ0IGFsc28gcmVxdWlyZXMgdGhlIGNsaWVudCB0byBzZW5kIGFuIGFkZGl0aW9uYWwgImNv
bW1pdCINCj4gcnBjLCB3aGljaCBtZWFucyB0aGF0IGFuIG9sZCBjbGllbnQgdGhhdCBjb21tdW5p
Y2F0ZXMgd2l0aCBhIHNlcnZlciANCj4gdGhhdCBoYXBwZW5zIHRvIGltcGxlbWVudCBzdGFnaW5n
IHdvbid0IHdvcmsgYXMgZXhwZWN0ZWQuDQoNClRoaXMgaXMgdHJ1ZS4gT25lIHdheSB0byB3b3Jr
IGFyb3VuZCB0aGlzIChSb2IncyBzdWdnZXN0aW9uKSBpcyB0byByZXF1aXJlIHRoZSB1c2VyIHRv
IGV4cGxpY2l0bHkgc3RhcnQgdGhlICJzdGFnaW5nIG1vZGUiIHdpdGggYW4gb3BlcmF0aW9uIChz
dWNoIGFzICJjbG9uZSINCm9yICJjaGVja291dCIpLiBVbnRpbCB0aGVuLCBhbGwgZWRpdHMgd291
bGQgYmUgYXMgc3BlY2lmaWVkIGluIFNlYy4gMS40Lg0KDQpMYWRhDQoNCltRaW5dOiBDbG9uZSBv
cGVyYXRpb24gaXMgc2ltaWxhciB0byBIVFRQIEdFVCwgYnV0IHJlcXVpcmVzIGRvd25sb2FkaW5n
IGFuZCBjcmVhdGUgYSBsb2NhbCBjb3B5IGluIHRoZSBjbGllbnQgc2lkZSwNCkkgYW0gd29uZGVy
aW5nIHdoeSBub3QgY3JlYXRlIHByaXZhdGUgYXJlYSBpbiB0aGUgcnVubmluZyBkYXRhc3RvcmUg
b2YgdGhlIHNlcnZlciBzaWRlPw0KPiANCj4gDQo+IA0KPiAvbWFydGluDQo+IA0KPiANCj4gDQo+
ID4gDQo+ID4gTGFkYQ0KPiA+IA0KPiA+ID4gDQo+ID4gPiA+ID4gPiBSZWdhcmRpbmcgZHJhZnQt
bGhvdGthLW5ldGNvbmYtcmVzdGNvbmYtdHJhbnNhY3Rpb25zLTAwLCBJIA0KPiA+ID4gPiA+ID4g
cmVjZWl2ZWQNCj4gYQ0KPiA+ID4gPiA+ID4gbG90IG9mIGNyaXRpY2lzbSBmb3IgY2hhbmdpbmcg
dGhlIHNlbWFudGljcyBvZiANCj4gPiA+ID4gPiA+IHsrcmVzdGNvbmZ9L2RhdGEuIEhvd2V2ZXIs
IEkgZG9uJ3QgdGhpbmsgaXQgd2FzIHRoZSBjYXNlOiANCj4gPiA+ID4gPiA+IGFjY29yZGluZw0K
PiB0bw0KPiA+ID4gPiA+ID4gdGhlIGFib3ZlIGRlZmluaXRpb24sIGl0IHNlZW1zIHBlcmZlY3Rs
eSBPSyBpZiANCj4gPiA+ID4gPiA+IHsrcmVzdGNvbmZ9L2RhdGEgcmVwcmVzZW50cyBjb21iaW5l
ZCBjb25maWd1cmF0aW9uICoqZnJvbSA8c3RhZ2luZz4qKiBhbmQgc3RhdGUgZGF0YS4NCj4gPiA+
ID4gPiANCj4gPiA+ID4gPiBUaGlzIHdvdWxkIHZpb2xhdGUgc2VjdGlvbiAxLjQgb2YgUkZDIDgw
NDAsIGF0IGxlYXN0IGlmIHRoZSANCj4gPiA+ID4gPiBSRVNUQ09ORiBzZXJ2ZXIgaXMgY28tbG9j
YXRlZCB3aXRoIGEgTkVUQ09ORiBzZXJ2ZXIuDQo+ID4gPiA+IA0KPiA+ID4gPiBJbiBmYWN0LCB0
aGUgdXNlIG9mIHRoZSBzdGFnaW5nIGRhdGFzdG9yZSBtYWtlcyBzZW5zZSBvbmx5IGlmIA0KPiA+
ID4gPiA8cnVubmluZz4NCj4gaXMNCj4gPiA+IG5vdA0KPiA+ID4gPiB3cml0YWJsZSBhbmQgPGNh
bmRpZGF0ZT4gbm90IHN1cHBvcnRlZCAob3Igbm90IHVzZWQsIGF0IGxlYXN0KS4NCj4gTW9yZW92
ZXIsDQo+ID4gPiA+IE5FVENPTkYgc2VydmVyIG5lZWRuJ3QgYmUgcHJlc2VudCBhdCBhbGwuDQo+
ID4gPiANCj4gPiA+IA0KPiA+ID4gL21hcnRpbg0KPiA+ID4gDQo+ID4gPiANCj4gPiA+ID4gDQo+
ID4gPiA+IExhZGENCj4gPiA+ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4g
DQo+ID4gPiA+ID4gL21hcnRpbg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4g
DQo+ID4gPiA+ID4gPiBMYWRhDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IC0tDQo+ID4gPiA+
ID4gPiBMYWRpc2xhdiBMaG90a2ENCj4gPiA+ID4gPiA+IEhlYWQsIENaLk5JQyBMYWJzDQo+ID4g
PiA+ID4gPiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4gPiA+ID4gPiA+IA0KPiA+
ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gPiA+ID4gPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gPiBOZXRjb25mQGll
dGYub3JnDQo+ID4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldGNvbmYNCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiAtLQ0KPiA+ID4gPiBMYWRpc2xhdiBMaG90
a2ENCj4gPiA+ID4gSGVhZCwgQ1ouTklDIExhYnMNCj4gPiA+ID4gUEdQIEtleSBJRDogMHhCOEY5
MkIwOEE5Rjc2QzY3DQo+ID4gPiA+IA0KPiA+IC0tDQo+ID4gTGFkaXNsYXYgTGhvdGthDQo+ID4g
SGVhZCwgQ1ouTklDIExhYnMNCj4gPiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4g
PiANCi0tDQpMYWRpc2xhdiBMaG90a2ENCkhlYWQsIENaLk5JQyBMYWJzDQpQR1AgS2V5IElEOiAw
eEI4RjkyQjA4QTlGNzZDNjcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg==


From nobody Thu Sep 27 10:44:48 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0528130EF0; Thu, 27 Sep 2018 10:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ruclvp_GDiNc; Thu, 27 Sep 2018 10:44:35 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 381B0130EEE; Thu, 27 Sep 2018 10:44:35 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 9C5C11AE0472; Thu, 27 Sep 2018 19:44:31 +0200 (CEST)
Date: Thu, 27 Sep 2018 19:44:31 +0200 (CEST)
Message-Id: <20180927.194431.112236859070325254.mbj@tail-f.com>
To: kaduk@mit.edu
Cc: iesg@ietf.org, draft-ietf-netconf-nmda-netconf@ietf.org, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <153798433929.21634.492484619504901988.idtracker@ietfa.amsl.com>
References: <153798433929.21634.492484619504901988.idtracker@ietfa.amsl.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-nmda-netconf-06: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2018 17:44:38 -0000

Hi,

Benjamin Kaduk  wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-netconf-nmda-netconf-06: 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-nmda-netconf/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for the well-written document!
> 
> I only had one comment, namely that Sections 3.1.1.1 and 3.1.2 end
> with text that
> certain behavior for non-8342 datastores "SHOULD be defined by the
> specification
> for the datastore", and it wasn't entirely clear to me that the 2119
> SHOULD was
> necessary (since it would be attempting to constrain the behavior of
> future specifications,
> which is always a bit dicey since they could just update this
> specification to remove
> the constraint anyway).

I'm ok with changing this to "should".  The point that we want to make
is that future datastores need to consider if/how "with-defaults" apply
to them.


/martin


From nobody Thu Sep 27 11:49:10 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662F3130F0E for ; Thu, 27 Sep 2018 11:49:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Dqe8Q2j6Ncl7 for ; Thu, 27 Sep 2018 11:49:06 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 82EE3130F06 for ; Thu, 27 Sep 2018 11:49:06 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8RImwsP030824; Thu, 27 Sep 2018 11:49:04 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=LBO8CKSIKN6SPP8L3y2OwmLbZw+aFliB0h2w7ryY01k=; b=17D6vrAyvYT5SOEjASstOk7DgvWtd/RFxLfMsIZJytveCJGwzQWt5PHgaf8OzrHrwfWx I5Gr8UGhRdt6wWFNFTLhSy9BBeS+wnu36LDNpcEcdsFelZtWe2cHSGCvpdsTG3apb+qU xF1Xx5aeR32E5DhQfAo1bVP8N5Tqeeec21hEBNmBJr4KkDzDVvNQVouQYA5t41RbC/fQ 4hX6sqm9ovAGNVak4dsaD6sBtMtv9SWX+IjyROImNB6QTGYzNPmeiSFX0kQ5eimxDxyQ ur0M0/o43b6A3w+Z9Qm8saAk/IgS50CZXTWtQcBOHGJCPv2xFAMGruHhDxs8X7OEWrPp +A== 
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0024.outbound.protection.outlook.com [216.32.180.24]) by mx0a-00273201.pphosted.com with ESMTP id 2mrt089a8w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Sep 2018 11:49:04 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4649.namprd05.prod.outlook.com (20.176.109.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.10; Thu, 27 Sep 2018 18:49:01 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%3]) with mapi id 15.20.1185.014; Thu, 27 Sep 2018 18:49:01 +0000
From: Kent Watsen 
To: "Reshad Rahman (rrahman)" , "Eric Voit (evoit)" , Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] SSE and HTTP/2 in restcon-notif 
Thread-Index: AQHUVpLBkBpJSSIQbkWRq5O8cMUK2Q==
Date: Thu, 27 Sep 2018 18:49:01 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4649; 6:63WUU0N1GnZCSnCea7PZSBKhPRcAESZdau1RmXv9zHM9za2/btORwdbJXsFzVyxt+sfh56HPaHOA7fz7oHq68VkCX0Z92I7+hWz3UM/3xnkPk2BznqZOPH/hrVAZUkRwXDAqMK35xkRYhdWrwXzvyz7ZpJ8OUjuu45SQKpC8ehx6wVZ9r+d54DaHtxTFzqJudq/03+qKlqsF8m1Af758lm15H628LWqQ68KYwKBTLEuQnlj3KuRO1JQDJ6r07VhP5VpV7NkckOLN2HXfT0U+Ov2CEl+V38TdfhzBoZQ6JdAWeEmGOF7MGz1DFuSAUegU57DvYJIToHnmsy67+NcZwlD+DFklt0SnmnHg2e9DZksQ4MsBc2XjY3pGbuSuhh28hXXFxjdM9Wml7cLdLYYjMbeGod1isjddkovw1B1ByySzgzaa2ARexuG8OxBE5rrP2g5PqQVa2INMmmXn8ek3yg==; 5:qhHfZRXL4JuMiZBPgP+Z4g7q2on2iecgc5Izq8sqG8QOaM4yPCeqqVQWgvUicaT1TlumzuoiLY+ERZo5sG7Or6v/sr1+tAqROljgCXA16r7eGFGjRFJpoyR6HqZjegdzJCDBr04jbtT1SFBOtBbjJOgiyu3Bst0Om+j5A5qjvKw=; 7:rHHjGFNuSmyXUyeOd4JwQ64NP1hUY9t+XALzxf9Cijch0Bso/U1Gw4YnsFKSY6chxuRa4nQPfRqfaaOVvtmAQXeUacdUMzIcFmZzwWqRULQONMJu1P9C7BSIZXvCdcBvE1rhpA5PgObhMmh12AeEW+RinKk/fnAwDSjn5DKrrUeoks8S8xKB60/30ci/rKh+XcadNCDcJ+BxK9HpgZU5dMsRI1Iobxj+uT2K38jF5ki87BqGsYWRy7X8ZvCzaPPz
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 71870937-7f1d-4872-6d09-08d624a9e427
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4649; 
x-ms-traffictypediagnostic: DM6PR05MB4649:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051); SRVR:DM6PR05MB4649; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4649; 
x-forefront-prvs: 0808323E97
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(346002)(376002)(366004)(39860400002)(396003)(136003)(189003)(199004)(486006)(5660300001)(2900100001)(2616005)(71200400001)(14444005)(316002)(97736004)(256004)(82746002)(81166006)(81156014)(476003)(7736002)(6116002)(3846002)(83716004)(71190400001)(86362001)(305945005)(25786009)(6486002)(229853002)(8936002)(68736007)(36756003)(26005)(5250100002)(105586002)(58126008)(4326008)(6506007)(6436002)(102836004)(53936002)(6512007)(186003)(2906002)(99286004)(8676002)(6246003)(106356001)(14454004)(33656002)(110136005)(478600001)(66066001)(4743002)(34290500001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4649; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: ZrMi1uGtKiP2G7VcGz+fWsL+Rw1OlJwXHOmdQt50sk5d+2XKfqngiQKlqcnaQRhm12eENMtZN8zOBWnvjpK/EASHmTRmMCBQQ1cwWvaznuKiEmpa9dc9SQ0nEG/AvCWKimzDA4W4/gY+EfdXbe0BZR44g1hC3sVp44qO1VOTljJAcjDSfXtYMzSOi8oiUI8sRQlFvyxiOUC8Y2+ho2gi1+PmW4ozsc+B/mlM5uu328DME1pwiYyrg3YxJoQ5PqaRYjTUOLp3TTevtkbb0aDSf5DXM5Sdf0lMf+F+d3T1RYKI1kcKiRJneS7gzjiAIvGKHYI7vTOOOvcU1/YOi3QFkhzQc1rxj9mXfsX+7xeEhaY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 71870937-7f1d-4872-6d09-08d624a9e427
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2018 18:49:01.4740 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4649
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-27_09:, , 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-1807170000 definitions=main-1809270174
Archived-At: 
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2018 18:49:08 -0000

DQo8Y2hhaXIgcGxlYT4NCiAgQ2FuIHdlIHRyeSB0byBoYXZlIGEgTGFzdCBDYWxsIHdvcnRoeSB2
ZXJzaW9uIG9uIHRoZSByZXN0Y29uLW5vdGlmIA0KICBkcmFmdCBieSBtaWQgbmV4dCB3ZWVrPyAg
VGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIExhc3QgQ2FsbCBib3RoIA0KICBOTiArIFJOIHRvZ2V0
aGVyIGlmIHBvc3NpYmxlLi4uDQo8L2NoYWlyIHBsZWE+DQoNCg0KQXMgSSB1bmRlcnN0YW5kIGl0
LCB0aGVyZSBhcmUgdGhyZWUgaXNzdWVzIChhbnkgb3RoZXJzPykgYXMgZm9sbG93czoNCg0KMSkg
U1NFDQoNCiAgIEFjdHVhbGx5LCB3aXRoIFJlc2hhZCdzIGxhc3QgcmVzcG9uc2UsIHRoaXMgbWF5
IG5vdCBiZSBhbiBpc3N1ZQ0KICAgYW55bW9yZS4gIEp1c3QgaW4gY2FzZSwgSSBhbHNvIGZlZWwg
dGhhdCB0aGUgKnJlc3Rjb25mKi1ub3RpZiBkcmFmdA0KICAgbmVlZHMgdG8gYWxpZ24gYXMgY2xv
c2VseSBhcyBwb3NzaWJsZSB0byB0aGUgUkZDIDgwNDAgbm90aWZpY2F0aW9uIA0KICAgc29sdXRp
b24uICBJZGVhbGx5LCB3ZSBqdXN0IHVzZSBTU0Ugb3V0cmlnaHQgYW5kIHdlJ3JlIGRvbmUuDQoN
CjIpIEhUVFAvMg0KDQogICBOb3Qgc3VyZSB3aGVyZSB0aGlzIGxhbmRlZCwgYnV0IG15IHRob3Vn
aHRzIGFyZSB0aGlzIGRyYWZ0IG5lZWRzIHRvDQogICBzdXBwb3J0IGJvdGggMS4xIGFuZCAyLjAu
ICBJIGVudmlzaW9uIHRoZSB2YXJpYXRpb24gYmVpbmcgcmVsYXRpdmVseQ0KICAgbWlub3IsIHNv
bWV0aGluZyBhbG9uZyB0aGUgbGluZSBvZjogDQoNCiAgICAgaWYgMS4xLCB0aGVuIFNTRS4NCiAg
ICAgaWYgMi4wLCBjbGllbnQgTUFZIG9wZW4gYSBzdHJlYW0gZmlyc3QuDQoNCjMpIHJlc291cmNl
IFVSSXMNCg0KICAgVGhpcyBpcyBsaWtlbHkgd2hlcmUgd2UgbmVlZCB0byBzcGVuZCB0aGUgbW9z
dCB0aW1lLiBXZSBrbm93IHRoYXQgDQogICBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIHJldHVybnMg
YSBkeW5hbWljYWxseSBjcmVhdGVkIFVSSSwgY29tcGFyYWJsZQ0KICAgdG8gd2hhdCBhIGNsaWVu
dCBtaWdodCBnZXQgZnJvbSBpZXRmLXJlc3Rjb25mLW1vbml0b3Jpbmc6cmVzdGNvbmYtc3RhdGVc
DQogICAvc3RyZWFtcy9zdHJlYW0vYWNjZXNzL2xvY2F0aW9uLiAgQXJlIHRoZXJlIGp1c3QgdHdv
IGlzc3Vlcz8NCg0KICAgYSkgaG93IGRvZXMgdGhlIHNlcnZlciBlbnN1cmUgb25seSBzYWlkIGNs
aWVudCBhY2Nlc3NlcyB0aGUgcmVzb3VyY2U/DQoNCiAgIGIpIGhvdyBkb2VzIHRoZSBzZXJ2ZXIg
a25vdyB3aGVuIGl0J3Mgb2theSB0byByZWNsYWltIHRoZSByZXNvdXJjZSwgDQogICAgICB3aGVu
IGEgY2xpZW50IGRvZXNuJ3QgImRlbGV0ZSIgb3IgImtpbGwiIHRoZSBzdWJzY3JpcHRpb24/DQoN
Cg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0KDQoNCg==


From nobody Thu Sep 27 13:49:00 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1D5130E76 for ; Thu, 27 Sep 2018 13:48:58 -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 uIncZxwj87Gq for ; Thu, 27 Sep 2018 13:48:56 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A66E9130DC1 for ; Thu, 27 Sep 2018 13:48:56 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 783541AE046A; Thu, 27 Sep 2018 22:48:54 +0200 (CEST)
Date: Thu, 27 Sep 2018 22:48:54 +0200 (CEST)
Message-Id: <20180927.224854.1626742691261140238.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: rrahman=40cisco.com@dmarc.ietf.org, evoit@cisco.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2018 20:48:59 -0000

Hi,

Kent Watsen  wrote:
> 
> 
>   Can we try to have a Last Call worthy version on the restcon-notif 
>   draft by mid next week?  The chairs would like to Last Call both 
>   NN + RN together if possible...
> 
> 
> 
> As I understand it, there are three issues (any others?) as follows:
> 
> 1) SSE
> 
>    Actually, with Reshad's last response, this may not be an issue
>    anymore.  Just in case, I also feel that the *restconf*-notif draft
>    needs to align as closely as possible to the RFC 8040 notification 
>    solution.  Ideally, we just use SSE outright and we're done.

+1

> 2) HTTP/2
> 
>    Not sure where this landed, but my thoughts are this draft needs to
>    support both 1.1 and 2.0.

Why?  I don't really understand why restconf-notif, or RESTCONF for
that matter, need special handling for HTTP/2.  Won't RESTCONF "just
work" with HTTP/2?

>    I envision the variation being relatively
>    minor, something along the line of: 
> 
>      if 1.1, then SSE.
>      if 2.0, client MAY open a stream first.
> 
> 3) resource URIs
> 
>    This is likely where we need to spend the most time. We know that 
>    establish-subscription returns a dynamically created URI, comparable
>    to what a client might get from ietf-restconf-monitoring:restconf-state\
>    /streams/stream/access/location.

But it is not quite comparable.  In the 8040 solution, the location
url is static, and then query parameters are provided by the client
in the POST to the SSE location.  Thus, the server can free any
resources associated with the filter when the connection is
terminated.


> Are there just two issues?
> 
>    a) how does the server ensure only said client accesses the resource?

The server cannot know this.  I guess it can verify the username.  But
does it matter?

>    b) how does the server know when it's okay to reclaim the resource, 
>       when a client doesn't "delete" or "kill" the subscription?

Yes this is not clear.


/martin




From nobody Thu Sep 27 14:04:04 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0751130DEA for ; Thu, 27 Sep 2018 14:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.956
X-Spam-Level: 
X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 mad7EKdc-Iwa for ; Thu, 27 Sep 2018 14:04:01 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7497C12DD85 for ; Thu, 27 Sep 2018 14:04:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2710; q=dns/txt; s=iport; t=1538082241; x=1539291841; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p6qWQa7nw0R+Un13hYgahXOmX/bFg06torLlj5rkKHk=; b=TXYGDBKXU6Tr5vN8ZwEjwRg137uqBhXdSof60XDewj8DPGJPtWF+EYzK LNAgjr6ncB/XkcTMM4u42PHrAy+Iza7jeAfkNOx0vPqfs0NpJhKx2ivsm JwRm/cz5hqBTXQaI6Aoso6N19xvwymsD+PCUF4DtTOAfbchkNjfdBO/Vy Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAAApRa1b/4cNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYIOZn8oCoNqiBWOGYNikxWBeguEbAIXg3AhNBgBAwE?= =?us-ascii?q?BAgEBAm0ohTkGIxFFEAIBCA4MAgkdAgICMBUQAgQBDQUbgwYBggGjfIEuig6?= =?us-ascii?q?BC4lzF4FBP4E5DBOCFzWEaC0jgkcxgiYCnREJApAsF486lHMCERSBJR04gVV?= =?us-ascii?q?wFWUBgkGCJReOGG+NEoEfAQE?=
X-IronPort-AV: E=Sophos;i="5.54,312,1534809600"; d="scan'208";a="177803582"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2018 21:04:00 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w8RL40A7011807 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Sep 2018 21:04:00 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Sep 2018 16:03:59 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Thu, 27 Sep 2018 16:03:59 -0500
From: "Reshad Rahman (rrahman)" 
To: Kent Watsen , "Eric Voit (evoit)" ,  Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] SSE and HTTP/2 in restcon-notif 
Thread-Index: AQHUVpLBkBpJSSIQbkWRq5O8cMUK2aUErtaA
Date: Thu, 27 Sep 2018 21:03:59 +0000
Message-ID: <90F5045B-B1F6-48C8-9569-2BD4EE7A384F@cisco.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.249.158]
Content-Type: text/plain; charset="utf-8"
Content-ID: <661D799879C4654F9C4C4D8D6475D08F@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: 
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2018 21:04:03 -0000

SGkgS2VudCwNCg0KDQrvu79PbiAyMDE4LTA5LTI3LCAyOjQ5IFBNLCAiS2VudCBXYXRzZW4iIDxr
d2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KICAgIA0KICAgIDxjaGFpciBwbGVhPg0KICAg
ICAgQ2FuIHdlIHRyeSB0byBoYXZlIGEgTGFzdCBDYWxsIHdvcnRoeSB2ZXJzaW9uIG9uIHRoZSBy
ZXN0Y29uLW5vdGlmIA0KICAgICAgZHJhZnQgYnkgbWlkIG5leHQgd2Vlaz8gIFRoZSBjaGFpcnMg
d291bGQgbGlrZSB0byBMYXN0IENhbGwgYm90aCANCiAgICAgIE5OICsgUk4gdG9nZXRoZXIgaWYg
cG9zc2libGUuLi4NCiAgICA8L2NoYWlyIHBsZWE+DQoNCjxSUj4gSSB3aWxsIHN0cml2ZSB0byBk
byBzbywgbm8gcHJvbWlzZXMuLi4gICAgDQogICAgDQogICAgQXMgSSB1bmRlcnN0YW5kIGl0LCB0
aGVyZSBhcmUgdGhyZWUgaXNzdWVzIChhbnkgb3RoZXJzPykgYXMgZm9sbG93czoNCiAgICANCiAg
ICAxKSBTU0UNCiAgICANCiAgICAgICBBY3R1YWxseSwgd2l0aCBSZXNoYWQncyBsYXN0IHJlc3Bv
bnNlLCB0aGlzIG1heSBub3QgYmUgYW4gaXNzdWUNCiAgICAgICBhbnltb3JlLiAgSnVzdCBpbiBj
YXNlLCBJIGFsc28gZmVlbCB0aGF0IHRoZSAqcmVzdGNvbmYqLW5vdGlmIGRyYWZ0DQogICAgICAg
bmVlZHMgdG8gYWxpZ24gYXMgY2xvc2VseSBhcyBwb3NzaWJsZSB0byB0aGUgUkZDIDgwNDAgbm90
aWZpY2F0aW9uIA0KICAgICAgIHNvbHV0aW9uLiAgSWRlYWxseSwgd2UganVzdCB1c2UgU1NFIG91
dHJpZ2h0IGFuZCB3ZSdyZSBkb25lLg0KPFJSPiBZZXMsIHRoYXQncyB0aGUgcGxhbi4NCiAgICAN
CiAgICAyKSBIVFRQLzINCiAgICANCiAgICAgICBOb3Qgc3VyZSB3aGVyZSB0aGlzIGxhbmRlZCwg
YnV0IG15IHRob3VnaHRzIGFyZSB0aGlzIGRyYWZ0IG5lZWRzIHRvDQogICAgICAgc3VwcG9ydCBi
b3RoIDEuMSBhbmQgMi4wLiAgSSBlbnZpc2lvbiB0aGUgdmFyaWF0aW9uIGJlaW5nIHJlbGF0aXZl
bHkNCiAgICAgICBtaW5vciwgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lIG9mOiANCiAgICANCiAg
ICAgICAgIGlmIDEuMSwgdGhlbiBTU0UuDQogICAgICAgICBpZiAyLjAsIGNsaWVudCBNQVkgb3Bl
biBhIHN0cmVhbSBmaXJzdC4NCjxSUj4gSSB0aG91Z2h0IHRoZSBhZ3JlZW1lbnQgd2FzIHRvIGhh
dmUgbm8gaHR0cDIgaW4gdGhlIHNwZWMsIGV4Y2VwdCBtYXliZSBhcyBhbiBpbmZvcm1hdGlvbmFs
IG5vdGUuIFJGQzgwNDAgZG9lc24ndCBtZW50aW9uIGh0dHAyIGF0IGFsbC4gDQogICAgDQogICAg
MykgcmVzb3VyY2UgVVJJcw0KICAgIA0KICAgICAgIFRoaXMgaXMgbGlrZWx5IHdoZXJlIHdlIG5l
ZWQgdG8gc3BlbmQgdGhlIG1vc3QgdGltZS4gV2Uga25vdyB0aGF0IA0KICAgICAgIGVzdGFibGlz
aC1zdWJzY3JpcHRpb24gcmV0dXJucyBhIGR5bmFtaWNhbGx5IGNyZWF0ZWQgVVJJLCBjb21wYXJh
YmxlDQogICAgICAgdG8gd2hhdCBhIGNsaWVudCBtaWdodCBnZXQgZnJvbSBpZXRmLXJlc3Rjb25m
LW1vbml0b3Jpbmc6cmVzdGNvbmYtc3RhdGVcDQogICAgICAgL3N0cmVhbXMvc3RyZWFtL2FjY2Vz
cy9sb2NhdGlvbi4gIEFyZSB0aGVyZSBqdXN0IHR3byBpc3N1ZXM/DQogICAgDQogICAgICAgYSkg
aG93IGRvZXMgdGhlIHNlcnZlciBlbnN1cmUgb25seSBzYWlkIGNsaWVudCBhY2Nlc3NlcyB0aGUg
cmVzb3VyY2U/DQogICAgDQogICAgICAgYikgaG93IGRvZXMgdGhlIHNlcnZlciBrbm93IHdoZW4g
aXQncyBva2F5IHRvIHJlY2xhaW0gdGhlIHJlc291cmNlLCANCiAgICAgICAgICB3aGVuIGEgY2xp
ZW50IGRvZXNuJ3QgImRlbGV0ZSIgb3IgImtpbGwiIHRoZSBzdWJzY3JpcHRpb24/DQoNCjxSUj4g
SSBkb24ndCBrbm93LiBFcmljLCBoYXZlIHRoZXNlIGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBwYXN0
Pw0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KICAgIA0KICAgIA0KICAgIA0KICAgIEtlbnQgLy8gY29u
dHJpYnV0b3INCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCg0K


From nobody Thu Sep 27 14:28:29 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EDE1292F1 for ; Thu, 27 Sep 2018 14:28:28 -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 4Pk-FB7IM6vH for ; Thu, 27 Sep 2018 14:28:26 -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 4CFE6127332 for ; Thu, 27 Sep 2018 14:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3946; q=dns/txt; s=iport; t=1538083706; x=1539293306; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=d9jpB0HDmx72WwtkYaQVZs5bP9NjMo4J1DXqDpLkYSg=; b=MdmynLvG91Ct9HqoaZXxTVtR5bGSt0nquHYVXBw+0uc5K5AaiimEFwvg umz7q3afcTQkZt7Se8XHJYmD8WQKGu6Goi+AAfgEKoyMJF1qx10EWr8/C KGxQq7QaIN3JiQK0ItvLglr1J38gbtG3fnKR6IzZz7p3UJHU9zIjoYgbp k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAADGSq1b/4UNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYIOZn8oCoNqiBWOPoM9kxWBeguEbAIXg3AhNBgBAwE?= =?us-ascii?q?BAgEBAm0ohTgBAQEBAgEjEUUFCwIBCBUDAgIJHQICAjAVEAIEAQ0FCBODB4F?= =?us-ascii?q?5CKJNgTqBLooOgQuJcxeBQT+DbzWEaC0jgkeCVwJ8nBUJApAkH486lHMCERS?= =?us-ascii?q?BJR04gVVwFYMngiUXjhcBb40TgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,312,1534809600"; d="scan'208";a="458497100"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2018 21:28:25 +0000
Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w8RLSOIT021869 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Sep 2018 21:28:25 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Sep 2018 17:28:24 -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.1395.000; Thu, 27 Sep 2018 17:28:24 -0400
From: "Eric Voit (evoit)" 
To: "Reshad Rahman (rrahman)" , Kent Watsen , Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] SSE and HTTP/2 in restcon-notif 
Thread-Index: AQHUVpLBkBpJSSIQbkWRq5O8cMUK2aUErtaA///xPUA=
Date: Thu, 27 Sep 2018 21:28:24 +0000
Message-ID: <78634ca7fead4c36be0e0eea489b6aac@XCH-RTP-013.cisco.com>
References:  <90F5045B-B1F6-48C8-9569-2BD4EE7A384F@cisco.com>
In-Reply-To: <90F5045B-B1F6-48C8-9569-2BD4EE7A384F@cisco.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.234]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.144, xch-rtp-004.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: 
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2018 21:28:28 -0000

PiBGcm9tOiBSZXNoYWQgUmFobWFuLCBTZXB0ZW1iZXIgMjcsIDIwMTggNTowNCBQTQ0KPiANCj4g
SGkgS2VudCwNCj4gDQo+IA0KPiDvu79PbiAyMDE4LTA5LTI3LCAyOjQ5IFBNLCAiS2VudCBXYXRz
ZW4iIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gDQo+IA0KPiAgICAgPGNoYWlyIHBs
ZWE+DQo+ICAgICAgIENhbiB3ZSB0cnkgdG8gaGF2ZSBhIExhc3QgQ2FsbCB3b3J0aHkgdmVyc2lv
biBvbiB0aGUgcmVzdGNvbi1ub3RpZg0KPiAgICAgICBkcmFmdCBieSBtaWQgbmV4dCB3ZWVrPyAg
VGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIExhc3QgQ2FsbCBib3RoDQo+ICAgICAgIE5OICsgUk4g
dG9nZXRoZXIgaWYgcG9zc2libGUuLi4NCj4gICAgIDwvY2hhaXIgcGxlYT4NCj4gDQo+IDxSUj4g
SSB3aWxsIHN0cml2ZSB0byBkbyBzbywgbm8gcHJvbWlzZXMuLi4NCj4gDQo+ICAgICBBcyBJIHVu
ZGVyc3RhbmQgaXQsIHRoZXJlIGFyZSB0aHJlZSBpc3N1ZXMgKGFueSBvdGhlcnM/KSBhcyBmb2xs
b3dzOg0KPiANCj4gICAgIDEpIFNTRQ0KPiANCj4gICAgICAgIEFjdHVhbGx5LCB3aXRoIFJlc2hh
ZCdzIGxhc3QgcmVzcG9uc2UsIHRoaXMgbWF5IG5vdCBiZSBhbiBpc3N1ZQ0KPiAgICAgICAgYW55
bW9yZS4gIEp1c3QgaW4gY2FzZSwgSSBhbHNvIGZlZWwgdGhhdCB0aGUgKnJlc3Rjb25mKi1ub3Rp
ZiBkcmFmdA0KPiAgICAgICAgbmVlZHMgdG8gYWxpZ24gYXMgY2xvc2VseSBhcyBwb3NzaWJsZSB0
byB0aGUgUkZDIDgwNDAgbm90aWZpY2F0aW9uDQo+ICAgICAgICBzb2x1dGlvbi4gIElkZWFsbHks
IHdlIGp1c3QgdXNlIFNTRSBvdXRyaWdodCBhbmQgd2UncmUgZG9uZS4NCj4gPFJSPiBZZXMsIHRo
YXQncyB0aGUgcGxhbi4NCj4gDQo+ICAgICAyKSBIVFRQLzINCj4gDQo+ICAgICAgICBOb3Qgc3Vy
ZSB3aGVyZSB0aGlzIGxhbmRlZCwgYnV0IG15IHRob3VnaHRzIGFyZSB0aGlzIGRyYWZ0IG5lZWRz
IHRvDQo+ICAgICAgICBzdXBwb3J0IGJvdGggMS4xIGFuZCAyLjAuICBJIGVudmlzaW9uIHRoZSB2
YXJpYXRpb24gYmVpbmcgcmVsYXRpdmVseQ0KPiAgICAgICAgbWlub3IsIHNvbWV0aGluZyBhbG9u
ZyB0aGUgbGluZSBvZjoNCj4gDQo+ICAgICAgICAgIGlmIDEuMSwgdGhlbiBTU0UuDQo+ICAgICAg
ICAgIGlmIDIuMCwgY2xpZW50IE1BWSBvcGVuIGEgc3RyZWFtIGZpcnN0Lg0KPiA8UlI+IEkgdGhv
dWdodCB0aGUgYWdyZWVtZW50IHdhcyB0byBoYXZlIG5vIGh0dHAyIGluIHRoZSBzcGVjLCBleGNl
cHQgbWF5YmUNCj4gYXMgYW4gaW5mb3JtYXRpb25hbCBub3RlLiBSRkM4MDQwIGRvZXNuJ3QgbWVu
dGlvbiBodHRwMiBhdCBhbGwuDQo+IA0KPiAgICAgMykgcmVzb3VyY2UgVVJJcw0KPiANCj4gICAg
ICAgIFRoaXMgaXMgbGlrZWx5IHdoZXJlIHdlIG5lZWQgdG8gc3BlbmQgdGhlIG1vc3QgdGltZS4g
V2Uga25vdyB0aGF0DQo+ICAgICAgICBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIHJldHVybnMgYSBk
eW5hbWljYWxseSBjcmVhdGVkIFVSSSwgY29tcGFyYWJsZQ0KPiAgICAgICAgdG8gd2hhdCBhIGNs
aWVudCBtaWdodCBnZXQgZnJvbSBpZXRmLXJlc3Rjb25mLW1vbml0b3Jpbmc6cmVzdGNvbmYtc3Rh
dGVcDQo+ICAgICAgICAvc3RyZWFtcy9zdHJlYW0vYWNjZXNzL2xvY2F0aW9uLiAgQXJlIHRoZXJl
IGp1c3QgdHdvIGlzc3Vlcz8NCj4gDQo+ICAgICAgICBhKSBob3cgZG9lcyB0aGUgc2VydmVyIGVu
c3VyZSBvbmx5IHNhaWQgY2xpZW50IGFjY2Vzc2VzIHRoZSByZXNvdXJjZT8NCg0KV2l0aCBIVFRQ
MiwgeW91IGNhbiByZXF1aXJlIHRoYXQgdGhlIHNhbWUgSFRUUCBzZXNzaW9uIGJlIHVzZWQgYXMg
d2FzIHVzZWQgZm9yIHRoZSBSRVNUQ09ORiBzaWduYWxpbmcuICAgRm9yIEhUVFAgMS4xLCBwZXJo
YXBzIHRoZXJlIGNvdWxkIGJlIHNvbWUgY29tcGFyaXNvbiBvZiB0aGUgYWNjZXNzIGNyZWRlbnRp
YWxzIHVzZWQgYWNyb3NzIGluZGVwZW5kZW50IFRMUyBzZXNzaW9ucz8gIA0KDQo+ICAgICAgICBi
KSBob3cgZG9lcyB0aGUgc2VydmVyIGtub3cgd2hlbiBpdCdzIG9rYXkgdG8gcmVjbGFpbSB0aGUg
cmVzb3VyY2UsDQo+ICAgICAgICAgICB3aGVuIGEgY2xpZW50IGRvZXNuJ3QgImRlbGV0ZSIgb3Ig
ImtpbGwiIHRoZSBzdWJzY3JpcHRpb24/DQo+IA0KPiA8UlI+IEkgZG9uJ3Qga25vdy4gRXJpYywg
aGF2ZSB0aGVzZSBiZWVuIGRpc2N1c3NlZCBpbiB0aGUgcGFzdD8NCg0KVGhpcyB3YXMgZGlzY3Vz
c2VkIGVhcmxpZXIgaW4gdGhlIHRocmVhZC4gIEJhc2ljYWxseSBlbmRpbmcgdGhlIHN1YnNjcmlw
dGlvbiBjYW4gYmUgZG9uZSBieToNCg0KLSBkZWxldGUtc3Vic2NyaXB0aW9uIHJwYw0KLSBraWxs
LXN1YnNjcmlwdGlvbiBycGMNCi0gbG9zcyBvZiBUTFMgaGVhcnRiZWF0DQotIGluYWJpbGl0eSB0
byBkZWxpdmVyIHNlcXVlbnRpYWwgc2V0cyBvZiBub3RpZmljYXRpb24gbWVzc2FnZXMNCiAgICAg
IkZvciBjb25uZWN0aW9ubGVzcyBvciBzdGF0ZWxlc3MgdHJhbnNwb3J0cyBsaWtlDQogICAgICBI
VFRQLCBhIGxhY2sgb2YgcmVjZWlwdCBhY2tub3dsZWRnbWVudCBvZiBhIHNlcXVlbnRpYWwgc2V0
IG9mDQogICAgICBub3RpZmljYXRpb24gbWVzc2FnZXMgYW5kL29yIGtlZXAtYWxpdmVzIGNhbiBi
ZSB1c2VkIHRvIHRyaWdnZXIgYQ0KICAgICAgdGVybWluYXRpb24gb2YgYSBkeW5hbWljIHN1YnNj
cmlwdGlvbi4gIiAgIChwZXIgU04gMS4zKQ0KLSAiIEEgcHVibGlzaGVyIE1BWSB0ZXJtaW5hdGUg
YSBkeW5hbWljIHN1YnNjcmlwdGlvbiBhdCBhbnkgdGltZS4iICAgKHBlciBTTiAxLjMpDQoNCkVy
aWMNCg0KPiBSZWdhcmRzLA0KPiBSZXNoYWQuDQo+IA0KPiANCj4gDQo+ICAgICBLZW50IC8vIGNv
bnRyaWJ1dG9yDQo+IA0KPiANCj4gDQo+IA0KPiANCg0K


From nobody Thu Sep 27 14:33:39 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5645D130E8F for ; Thu, 27 Sep 2018 14:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 qPlWZuxpGrIL for ; Thu, 27 Sep 2018 14:33:34 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 9EA56130F1C for ; Thu, 27 Sep 2018 14:33:33 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id g89-v6so3361639lfl.5 for ; Thu, 27 Sep 2018 14:33:33 -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=+ITM2pg4YQJqgDJ7dRjwFGvOsiLOSRFGyrlTTgcn6QI=; b=jFM+Q/9YDaTd//HUUSdJ1y6KsIMSHHX8tYvlFZMjBxTsF56I5YG0dn4/MToanWzCqP RtVfUOx9JUb6G3I+Fb/L/nxt4QnkCEthtENd70LT7Uu44Y/jUfBEQiZo2PLqOozyWaED c7T39yo3HUi+t9PbfJ8PQ5kAVdgbEE14UYsBkd3YIz4DXPTWfQwtX7jArJ6+zbcNGGs0 isdD+897kWssodEm6sXzTXISOlh4GwLz5YQe/Y9tFxmrGu8PEA/gA7V1g5YuPjjHi+NR /5+C3daszBF9HIF+fnmzjsPINpFLpa6YMeze9yJIHuoboERavRdCa58f6qUCJ1BmNI1h 2v/A==
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=+ITM2pg4YQJqgDJ7dRjwFGvOsiLOSRFGyrlTTgcn6QI=; b=I/MwF8suw7lRciACa5hoANXJlENyuT2zVnxM/QqjvBKYG32NAzxKjtMNH+n5mzv0QR 9Bgs2wQDXfFobhWkP5VZN8oEjMc+XWr3+nq3jhVsZVfF5QoMo9mAgpHyucSQH49kea7s Q0xLXSiSDr4fb+tQek4QjCh34QVgJ9gO913WmtdfrkHD28mIYcHrwpJugJh8u1na6rDD pfwB0UeFoy8SngM4y67oCszHG24TGR0D0F+235Zhcyjm8vDLjDL+EO8o98OFLp5COWBu ntyahoi8p2IcK19sMf44L60Qw/yuJyVl+KVdU6LUGvrJ2vUCMyJUNsZqHBv4/vdIcznb 7Brg==
X-Gm-Message-State: ABuFfoiX/hHcgsK6zaXyez/RvEf4NJ9BQetrNYczK15COf8KIxr5ixbP HhMJtli//uv7Wm/l0SIHQaO7f5ml4T9zUqMo0QZutQ==
X-Google-Smtp-Source: ACcGV62fcHQVOYvlJDrsXopTRwbx4OrK+Y3imz3Ab3M5LL0EG7FJNOdrlrpcMUN8DYo7OWG8G41Euy+skDsTiGUz23w=
X-Received: by 2002:a19:3bcf:: with SMTP id d76-v6mr8296722lfl.126.1538084011535;  Thu, 27 Sep 2018 14:33:31 -0700 (PDT)
MIME-Version: 1.0
References:  <20180927.224854.1626742691261140238.mbj@tail-f.com>
In-Reply-To: <20180927.224854.1626742691261140238.mbj@tail-f.com>
From: Andy Bierman 
Date: Thu, 27 Sep 2018 14:33:20 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Kent Watsen , Netconf ,  rrahman=40cisco.com@dmarc.ietf.org
Content-Type: multipart/alternative; boundary="00000000000024832e0576e117bf"
Archived-At: 
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2018 21:33:37 -0000

--00000000000024832e0576e117bf
Content-Type: text/plain; charset="UTF-8"

On Thu, Sep 27, 2018 at 1:49 PM Martin Bjorklund  wrote:

> Hi,
>
> Kent Watsen  wrote:
> >
> > 
> >   Can we try to have a Last Call worthy version on the restcon-notif
> >   draft by mid next week?  The chairs would like to Last Call both
> >   NN + RN together if possible...
> > 
> >
> >
> > As I understand it, there are three issues (any others?) as follows:
> >
> > 1) SSE
> >
> >    Actually, with Reshad's last response, this may not be an issue
> >    anymore.  Just in case, I also feel that the *restconf*-notif draft
> >    needs to align as closely as possible to the RFC 8040 notification
> >    solution.  Ideally, we just use SSE outright and we're done.
>
> +1
>

+1


>
> > 2) HTTP/2
> >
> >    Not sure where this landed, but my thoughts are this draft needs to
> >    support both 1.1 and 2.0.
>
> Why?  I don't really understand why restconf-notif, or RESTCONF for
> that matter, need special handling for HTTP/2.  Won't RESTCONF "just
> work" with HTTP/2?


Agreed


>
>
>    I envision the variation being relatively
> >    minor, something along the line of:
> >
> >      if 1.1, then SSE.
> >      if 2.0, client MAY open a stream first.
> >
> > 3) resource URIs
> >
> >    This is likely where we need to spend the most time. We know that
> >    establish-subscription returns a dynamically created URI, comparable
> >    to what a client might get from
> ietf-restconf-monitoring:restconf-state\
> >    /streams/stream/access/location.
>
> But it is not quite comparable.  In the 8040 solution, the location
> url is static, and then query parameters are provided by the client
> in the POST to the SSE location.  Thus, the server can free any
> resources associated with the filter when the connection is
> terminated.
>
>

The RESTCONF procedure starts with the client
examining /restconf-state/streams to determine stream and its location URL
How does this monitoring information relate to the new solution?
I assume both the old and new procedures can be supported by the same
server.
Is it just ignored for a new subscription?

Since all SSE data is always media type test/event-stream, each stream
entry indicates
its secondary encoding format. This leaf is type string, and only 'xml' and
'json' are supported
in RFC 8040. The establish-subscription RPC has its own leaf for this
purpose.



>
> > Are there just two issues?
> >
> >    a) how does the server ensure only said client accesses the resource?
>
> The server cannot know this.  I guess it can verify the username.  But
> does it matter?
>


It matters if the server wants to pre-check the subscription for NACM issues
when it is created.

I want to make sure the same username is used, and only 1 session
is doing a GET on the subscription resource.



>
> >    b) how does the server know when it's okay to reclaim the resource,
> >       when a client doesn't "delete" or "kill" the subscription?
>
> Yes this is not clear.
>
>

Note that the RESTCONF solution avoids this problem because
only the GET on the SSE URI causes resources to be allocated for a
subscription.

One solution proposal:
  - use a timeout and if the client does not connect within that time, the
subscription
    will be suspended or deleted.
 - if the client terminates the SSE GET then either suspend or terminate
the subscription



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

--00000000000024832e0576e117bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu=
, Sep 27, 2018 at 1:49 PM Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,



Kent Watsen <kw=
atsen@juniper.net> wrote:

> 

> <chair plea>

>=C2=A0 =C2=A0Can we try to have a Last Call worthy version on the restc=
on-notif 

>=C2=A0 =C2=A0draft by mid next week?=C2=A0 The chairs would like to Las=
t Call both 

>=C2=A0 =C2=A0NN + RN together if possible...

> </chair plea>

> 

> 

> As I understand it, there are three issues (any others?) as follows:
> 

> 1) SSE

> 

>=C2=A0 =C2=A0 Actually, with Reshad's last response, this may not b=
e an issue

>=C2=A0 =C2=A0 anymore.=C2=A0 Just in case, I also feel that the *restco=
nf*-notif draft

>=C2=A0 =C2=A0 needs to align as closely as possible to the RFC 8040 not=
ification 

>=C2=A0 =C2=A0 solution.=C2=A0 Ideally, we just use SSE outright and we&=
#39;re done.



+1

+1
=C2=A0



> 2) HTTP/2

> 

>=C2=A0 =C2=A0 Not sure where this landed, but my thoughts are this draf=
t needs to

>=C2=A0 =C2=A0 support both 1.1 and 2.0.



Why?=C2=A0 I don't really understand why restconf-notif, or RESTCONF fo=
r

that matter, need special handling for HTTP/2.=C2=A0 Won't RESTCONF &qu=
ot;just

work" with HTTP/2?

Agreed
=
=C2=A0
=C2=A0

>=C2=A0 =C2=A0 I envision the variation being relatively

>=C2=A0 =C2=A0 minor, something along the line of: 

> 

>=C2=A0 =C2=A0 =C2=A0 if 1.1, then SSE.

>=C2=A0 =C2=A0 =C2=A0 if 2.0, client MAY open a stream first.

> 

> 3) resource URIs

> 

>=C2=A0 =C2=A0 This is likely where we need to spend the most time. We k=
now that 

>=C2=A0 =C2=A0 establish-subscription returns a dynamically created URI,=
 comparable

>=C2=A0 =C2=A0 to what a client might get from ietf-restconf-monitoring:=
restconf-state\

>=C2=A0 =C2=A0 /streams/stream/access/location.



But it is not quite comparable.=C2=A0 In the 8040 solution, the location
url is static, and then query parameters are provided by the client

in the POST to the SSE location.=C2=A0 Thus, the server can free any

resources associated with the filter when the connection is

terminated.




The RESTCONF procedure =
starts with the client
examining /restconf-state/streams to deter=
mine stream and its location URL
How does this monitoring informa=
tion relate to the new solution?
I assume both the old and new pr=
ocedures can be supported by the same server.
Is it just ignored =
for a new subscription?

Since all SSE data is alwa=
ys media type test/event-stream, each stream entry indicates
its =
secondary encoding format. This leaf is type string, and only 'xml'=
 and 'json' are supported
in RFC 8040. The establish-subs=
cription RPC has its own leaf for this purpose.

=
=C2=A0



> Are there just two issues?

> 

>=C2=A0 =C2=A0 a) how does the server ensure only said client accesses t=
he resource?



The server cannot know this.=C2=A0 I guess it can verify the username.=C2=
=A0 But

does it matter?


It matte=
rs if the server wants to pre-check the subscription for NACM issues
<=
div>when it is created.

I want to make sure the sa=
me username is used, and only 1 session
is doing a GET on the sub=
scription resource.

=C2=A0



>=C2=A0 =C2=A0 b) how does the server know when it's okay to reclaim=
 the resource, 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0when a client doesn't "delete"=
 or "kill" the subscription?



Yes this is not clear.




Note that the RESTCONF =
solution avoids this problem because
only the GET on the SSE URI =
causes resources to be allocated for a subscription.

One solution proposal:
=C2=A0 - use a timeout and if the clien=
t does not connect within that time, the subscription
=C2=A0 =C2=
=A0 will be suspended or deleted.=C2=A0
=C2=A0- if the client ter=
minates the SSE GET then either suspend or terminate the subscription
=






/martin







_______________________________________________

Netconf mailing list

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




--00000000000024832e0576e117bf--


From nobody Thu Sep 27 15:38:19 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B95D129C6A for ; Thu, 27 Sep 2018 15:38:18 -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=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 HVcWWobt9eTJ for ; Thu, 27 Sep 2018 15:38:15 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 89C2F127332 for ; Thu, 27 Sep 2018 15:38:15 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8RLdTwR006128 for ; Thu, 27 Sep 2018 14:43:50 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=LaD0vo/YEVeUSH7Og+VgfjhR08Re8TYMjWvo2BTu2II=; b=jHrmER1YPzcRgm1DT2Bv2KiWDmL5hMxTqUSS+Nfy1zfr8NzB+5yq1b6mpL5kQZ8hdnMJ EC6AjJb0UlZ/bJcYzy01eNkREaQk7kAQ5GJlYkO4pViXOX1fJbN+crE09SluRaA+CXYH wj4RIYt/nPIeQhGH20WfqIt9yBMJOE2qt+gZnA5h00LEdhAEs/J8RKEoPPtQQfaR+cys EU/ZT6ut2dBQso8uLCjBqKa3aEKlSM0q1kIYMgS5I5g+v600Ko32lTzujFsFkJ+xPfAT mvIrNvCjWCTUe4xPU/CFZi1H+JM/eezezT6qg+eqfKXMVnIeIxpxM+ILYO4IDBquKQm8 cA== 
Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp0080.outbound.protection.outlook.com [216.32.180.80]) by mx0a-00273201.pphosted.com with ESMTP id 2ms5fmr62f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 27 Sep 2018 14:43:50 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4218.namprd05.prod.outlook.com (20.176.72.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.8; Thu, 27 Sep 2018 21:43:48 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%3]) with mapi id 15.20.1185.014; Thu, 27 Sep 2018 21:43:48 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: Last Call on subscribed-notifications-16
Thread-Index: AQHURXCTPStqdu9N8EO45sjCvX2XlaUEiGgA
Date: Thu, 27 Sep 2018 21:43:48 +0000
Message-ID: 
References: <7AC66C1A-9E8A-42C2-B577-0B129E67568D@juniper.net>
In-Reply-To: <7AC66C1A-9E8A-42C2-B577-0B129E67568D@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.2.180910
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4218; 6:zA2vT9bR8DCAHnub+p5VZ88txxum/9uI1+qUA45u8mKvgHptByRPMT5i5saZgDoIvEkTrADiII35MUD3tXCVQ10vW7tNCeWd8FVeVt1ehwHzv85/kgxNKrlMLpc698okhq8nMW8Xys2hYDZFMggsIyEeKl2PnImD2eUFRFuYB1GzbbczpinxDpjVJxuNQCmErCwjuSIZK0TUxIrmQ/wQvvd5zcW5llkvJKrmlzpkrJIPVt8xYpO+jqDzh1MZ1HXVNZ7SLj43eANhKkDJCD9NR6eb/cYonj/MuK/BDqOT5VLuQBd7OMO1/6mDniSXpJJehTxIpZW2OjmqylpadtLwkub1bLjOarjelzODFL2Jf0/1nrDN1ZkB4Sxo6VPIIaIa/VOltoxj04mMBQE6umT68egjEJptjLKwvTxz1x40yNAvOsfChvHmo+cIG36Zc8NeGXKYJtXej/B2FGbIUNFVjQ==; 5:yLvT1oZnPRFCTx5DyWE8nX866QZgybO2kwsLzw+jp/uuH9pJ2aPd+UVMoRMvQ/9t7WPRmwLTNvqFZdu3fzmkNR7nXLdeR6hJaGpIg5aSacefxMdFpD+acpb6e8JFZXFsvkOuExnIcNwQX7Hluh1x069e5WzfA6kvl/In6ReSFzs=; 7:cy43Dwb79IlW1BXESGbWx9kR4ZhCmPKR378wd1NFrDKbww/ufsxjHQ+cXLrRdp0ccxAzlJxLT7BZ5R3zNAaTwvbLs59MVvKEfkP7mj8x1wxLS70yybEDluI9wVIBf1+qrl9KTHbPa1va45tuwT2cVc9wEz9PVftoYvJhFLc7c2tFl4TcfiAsw64+atl4kOTt8D1UgifJ1l/e96X/BvqQZ2LoDmRuJzI4pZ7Z2a8U+sq7UNoh9MaKwxB8ep/tnIA0
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: cbdd5af4-a6b2-4dd2-bba2-08d624c24f0b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4218; 
x-ms-traffictypediagnostic: DM6PR05MB4218:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(120809045254105);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(201708071742011)(7699051); SRVR:DM6PR05MB4218; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4218; 
x-forefront-prvs: 0808323E97
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(366004)(346002)(376002)(13464003)(189003)(199004)(5660300001)(316002)(6506007)(33656002)(26005)(76176011)(102836004)(5250100002)(2501003)(34290500001)(3846002)(486006)(25786009)(2900100001)(68736007)(6116002)(186003)(6916009)(53936002)(36756003)(14454004)(476003)(2906002)(6512007)(15650500001)(6306002)(229853002)(478600001)(2351001)(6486002)(106356001)(66066001)(14444005)(256004)(105586002)(83716004)(7736002)(5640700003)(305945005)(71200400001)(71190400001)(82746002)(6246003)(6436002)(81156014)(8936002)(2616005)(81166006)(446003)(8676002)(86362001)(58126008)(99286004)(966005)(97736004)(1730700003)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4218; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: OC4XcXU55tpDTJAgEqa0nDjfl9pM7juj+oy5hYWOEVE65Wm9M5VeHR07m1lJbIaA7B9eJ+SJr/ZbQLaFQub+QYcqNUPnOp4/+hMph8++Jjhyat3F8Z0adK00Fl+96/pU188vw47KwHUmiKsi8qV+UeizwZJoDvFn/sLHCHXgjQ5ZUE18C7a+vwKYyxBdsBAhSBFf4/jAXJhkmBAlNP9Dwdxyb7uTy8aDxbVlOcC7yQatoZn8WPuvJ6g2AILy+KBZDB0l3ohtho573PmKmdxBGE10N47pSNGMZUsQB/bnenOUkrb271S7qpJMhOr6aUjIFJPMpdR5OyVwF9xJ+z2RsJ5QXkYa+uLH51yJhvNLIOY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <11FF1DA7B6B3E444AE3A95C970BFE044@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: cbdd5af4-a6b2-4dd2-bba2-08d624c24f0b
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2018 21:43:48.6678 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4218
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-27_10:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809270201
Archived-At: 
Subject: Re: [Netconf] Last Call on subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2018 22:38:18 -0000

VGhpcyBtZXNzYWdlIHN1Y2Nlc3NmdWxseSBjb25jbHVkZXMgdGhlIExhc3QgQ2FsbCBvbiBzdWJz
Y3JpYmVkLW5vdGlmaWNhdGlvbnMNCnN0YXJ0ZWQgb24gU2VwIDV0aC4gVGhlIGRyYWZ0IHJlY2Vp
dmVkIHNpZ25pZmljYW50IHJldmlld3MgZnJvbSBUaW0sIE1hcnRpbiwgDQphbmQgQW5keSwgYW5k
IHJlY2VpdmVkIHBhc3NpbmcgcmV2aWV3cyBmcm9tIG90aGVycy4gIFRoYW5rIHlvdSBhbGwgZm9y
IHRoYXQuDQogDQpBdXRob3JzLCBwbGVhc2UgYmUgc3VyZSBjbG9zZSBhbnkgcmVtYWluaW5nIGFj
dGl2ZSB0aHJlYWRzLCBhbmQgdGhlbiBwb3N0IGENCi0xNyBmb3Igc2hlcGhlcmQgcmV2aWV3LiAg
UGxlYXNlIGFsc28gZW5zdXJlIHRoYXQgLTE3IHBhc3NlcyBhbGwgdmFsaWRhdGlvbg0KdG9vbHMg
KGUuZy4sIGlkbml0cywgeWFuZyB2YWxpZGF0b3JzLCBpbnN0YW5jZSBkb2N1bWVudCB2YWxpZGF0
b3JzKSBhbmQgdGhhdA0KdGhlIHRyZWUgZGlhZ3JhbXMgYXJlIGNvcnJlY3QuDQoNClRoYW5rcywN
CktlbnQgKGFuZCBNYWhlc2gpDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KVGhp
cyBtZXNzYWdlIHN0YXJ0cyBhIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2Ny
aWJlZC1ub3RpZmljYXRpb25zLTE2Og0KDQogIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLTE2DQoNClRoaXMgbWFy
a3MgdGhlIHNlY29uZCBvZiB0aGUgbGFzdCBjYWxscyBvbiB0aGUgeWFuZyBwdXNoIHN1aXRlIG9m
IGRyYWZ0cy4NCkFzIGV4cGxhaW5lZCBiZWZvcmUsIGdpdmVuIHRoZSBzaXplIGFuZCBudW1iZXIg
b2YgZG9jdW1lbnRzLCB0aGUgY2hhaXJzDQpkZWNpZGVkIHRvIGJyZWFrIHRoZSByZXZpZXdzIHVw
IGludG8gcGllY2VzIHNvIGFzIHRvIGdldCBmb2N1cyBvbiBlYWNoDQppbiB0dXJuLiAgV2UgYXJl
IGNob29zaW5nIHRvIGdvIHRvcC1kb3duLCBzdGFydGluZyB3aXRoIHlhbmctcHVzaCBhbmQNCmVu
ZGluZyB3aXRoIHRoZSAibm90aWYiIGRyYWZ0cy4gIFdlIHBsYW4gdG8gc3VibWl0IHRoZSBkcmFm
dHMgZm9yIA0KcHVibGljYXRpb24gd2hlbiB0aGV5IGFyZSByZWFkeSBhcyBhIGNvbGxlY3RpdmUu
ICBUaGUgZ29hbCBpcyB0byBkbyANCmFsbCB0aGlzIHByaW9yIHRvIElFVEYgMTAzLg0KDQpXaGls
ZSBpdCdzIGFsd2F5cyBuaWNlIHRvIHJlY2VpdmUgbWVzc2FnZXMgb2Ygc3VwcG9ydCwgYXQgdGhp
cyB0aW1lLCB0aGUNCnF1ZXN0aW9uIGlzbid0IHNvIG11Y2ggaWYgdGhlIHdvcmtpbmcgZ3JvdXAg
c3VwcG9ydHMgdGhlIHdvcmsgdGhhbiBpZg0KdGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIHByb2dy
ZXNzLiAgVGhlIGNoYWlycyBuZWVkIHRvIHNlZSByZXZpZXdzIHRoYXQNCmluZGljYXRlIHRob3Jv
dWdoIGVuZC10by1lbmQgcmVhZGluZyBvZiB0aGUgdGV4dC4gIE9mIGNvdXJzZSwgaWYgdGhlcmUN
CmFyZSBhbnkgb2JqZWN0aW9ucywgdGhlc2Ugc2hvdWxkIGJlIGJyb3VnaHQgZm9yd2FyZCBub3cg
YXMgd2VsbC4NCg0KVGhlIGN1cnJlbnQgdmVyc2lvbiAoLTE2KSBvZiB0aGlzIGRyYWZ0IHdhcyBw
dWJsaXNoZWQgb24gQXVnIDE1dGgsIGFib3V0DQp0aHJlZSB3ZWVrcyBhZnRlciBJRVRGIDEwMi4g
IFRoZSBkYXRhdHJhY2tlciBwYWdlIGZvciB0aGUgZHJhZnQgaXMgaGVyZToNCmh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlm
aWNhdGlvbnMuDQoNCg0KVGhhbmtzLA0KS2VudCAoYW5kIE1haGVzaCkNCg0KDQoNCg==


From nobody Thu Sep 27 15:56:03 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87EC130E03 for ; Thu, 27 Sep 2018 15:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 F0u4edw3yOJS for ; Thu, 27 Sep 2018 15:55:59 -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 79DFF130DE4 for ; Thu, 27 Sep 2018 15:55:59 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8RMtumN001026; Thu, 27 Sep 2018 15:55:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=RY1gJzdOwwX4hffgCulsCDwKFUsbk3e5+rtdmB75CxM=; b=K0d6v4lAv1hU1lMZHilq6FkE0C7QYye5mcSXd31+j39LbyTs5T06ItSFiN8QZKSB3sIi 5ffE8UKQ6tHE0jw/U8JmdMx5lBjb0o+LRe1dUpz+5i+LTqg8y0Jnnv0x1ndnc0GAnW3v zpsi1KdtmU74mWHXNAvJc2YBH6dWLNNRLqM/Cy6YaGJJU+8nnWlw1wm4cqmCc1wZGb0O lk8q+5MdqzxsmecapUNrP3fInYYARKLeQbt9O/4qaz3PbMEVUzGBKnkCPuvf3B/7jfa8 oHLwNDHmlwLRFyEcDOZq3mjGFTT9QE6M2U/9RdYQNjmvnuOcbXqbxhzAWd7pkeQMF/Fg 5g== 
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0080.outbound.protection.outlook.com [207.46.163.80]) by mx0b-00273201.pphosted.com with ESMTP id 2ms3ujrhf1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Sep 2018 15:55:57 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4588.namprd05.prod.outlook.com (20.176.79.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.14; Thu, 27 Sep 2018 22:55:54 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%3]) with mapi id 15.20.1185.014; Thu, 27 Sep 2018 22:55:54 +0000
From: Kent Watsen 
To: Andy Bierman , Martin Bjorklund 
CC: Netconf , "rrahman=40cisco.com@dmarc.ietf.org" 
Thread-Topic: [Netconf] SSE and HTTP/2 in restcon-notif
Thread-Index: AQHUVpLBkBpJSSIQbkWRq5O8cMUK2aUEmdsAgAAMawD//9QCgA==
Date: Thu, 27 Sep 2018 22:55:54 +0000
Message-ID: 
References:  <20180927.224854.1626742691261140238.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.2.180910
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4588; 6:iNFAQT5qLov8Ch7rPBmYVBRuj4shJRlJJIl2Rs8ysck+1/3DmuX6jHsezdzIzVwn2RiYCO86YS3OCvHyPtNiLQ1BR+0N0ZYsfoUjtfHXzDSH6m08BE1LNMf6bPQFCOqQMQGjRYTyNbzj+dsFQPghA/+J5gRpexipDnRaV8e73HLvevUMcXn9G9fivjLdUSmtyBVWpMns6Mk+Awe/tCE9ophahK/3gncPL0uKzM5Gkfr0vrQe07alJQURB5ZXg3MyhlXH03fRjwp6i1ClSHcaDJL0tLjs55yrmbb6cNaTxLz6aSXPzjmW0ZUOUG9PhoxAybbT2MNmMoI1NrLqEWVYGBi49bVztdQI57ywJSkP/2K8FSxd9p5b0CWt4PhxkvGO4Pi38McpVDvQJTFmu67A6WLI4JQIr/T4c0mqmOtgrzFg4aVct9arp7VhLa6Fcdn5WtrNIAZ+OBaBHvB84pWR2w==; 5:PqKOksdCXqemyT9PneSD0f0j3ZASmE9YpBlvvwnWhLOm+5v6SwK0a8TjilHrofcQsLb+Hs0Yf82HogrXutW0MHZhIIKSNf5N9P8Ztsq1KoUMXp39/johYZmKZqcggy+b8QgQ8AGgo7Z+eyzBhuxjfVKX586QOQ7TmWdvVpTpoAE=; 7:ZAc/kKvlX4pg3hq96HqS9sKdw4jYZ/GsEOi79ZEbRnQOOJ+00kgQBFZEok+H9oXprpRrYPeMeySKs34qOGDyCqBs8sbjS4hVK0VYHDXH6SthnbHBOOxTac1DMDu+vGDdxEy5WZPqqsevMJ8JNOj5+Itnb5wEOwRkM0x2ZKHvDWH6/KcD/7CDP/gTk80Kg6+z6Bzjerz/VKc022oqxboc9zHQMuSalTiA9L0Pjz4HFXQ/EUqtnNgtW1qdyhF1Cwdu
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: a6deea95-f54f-44f1-6898-08d624cc6192
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4588; 
x-ms-traffictypediagnostic: DM6PR05MB4588:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991041); SRVR:DM6PR05MB4588; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4588; 
x-forefront-prvs: 0808323E97
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(376002)(396003)(366004)(346002)(189003)(199004)(2616005)(6246003)(82746002)(54906003)(68736007)(478600001)(58126008)(110136005)(25786009)(8936002)(316002)(2906002)(6436002)(34290500001)(81156014)(4326008)(6116002)(33656002)(6506007)(3846002)(99286004)(76176011)(81166006)(8676002)(305945005)(14454004)(446003)(71200400001)(71190400001)(229853002)(5250100002)(105586002)(186003)(11346002)(256004)(6512007)(53936002)(6486002)(86362001)(97736004)(486006)(5660300001)(102836004)(83716004)(2900100001)(26005)(7736002)(106356001)(66066001)(476003)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4588; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: O8JVp5Y20ChYSO09rjBEomXfyMaEsEihn5BvQJcWcVx3oJUdMKt1zPfwGtCxuDCc3KMEPYpMIaiXdXjdh7VnBwduBxrRqcS8FvTQBz3XChKSZm7ERESwrX52SocsXYQOH3G9EsAVXMwD2cbm2FqVmNY5ouL39++h8CPjNZTpt6QtyfvLpaunBpghZbPVwthVHMh7c/SA8HtVIsPgXpShPl3GC1QX7xapeI3D99f7KAXwo8cqvphWtDdyC3wpj7kg+oB5VjcTB4XCr0U8SqNzEs2o7XuyccuxVYrL4G8Es5wd63tQotE8tLKGMVzHYOQisKIl8/Y+kt4K18ftUY6DrFGRzpWF1k2uH/vn+fOLWtM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <71C1EC35407F094D8D4AB0148D77244C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: a6deea95-f54f-44f1-6898-08d624cc6192
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2018 22:55:54.7010 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4588
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-27_10:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809270213
Archived-At: 
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2018 22:56:02 -0000

DQo+PiAyKSBIVFRQLzINCj4+wqANCj4+wqAgwqAgTm90IHN1cmUgd2hlcmUgdGhpcyBsYW5kZWQs
IGJ1dCBteSB0aG91Z2h0cyBhcmUgdGhpcyBkcmFmdCBuZWVkcw0KPj7CoCDCoCB0byBzdXBwb3J0
IGJvdGggMS4xIGFuZCAyLjAuDQo+DQo+IFdoeT/CoCBJIGRvbid0IHJlYWxseSB1bmRlcnN0YW5k
IHdoeSByZXN0Y29uZi1ub3RpZiwgb3IgUkVTVENPTkYgZm9yDQo+IHRoYXQgbWF0dGVyLCBuZWVk
IHNwZWNpYWwgaGFuZGxpbmcgZm9yIEhUVFAvMi7CoCBXb24ndCBSRVNUQ09ORiAianVzdA0KPiB3
b3JrIiB3aXRoIEhUVFAvMj8NCj4NCj4gQWdyZWVkDQoNCkl0IHNlZW1zIHRoYXQgd2UncmUgYWxs
IGluIGFncmVlbWVudCAtIFJOIHNob3VsZCB3b3JrIGZvciBib3RoIDEuMQ0KYW5kIDIuMC4gIFVu
Y2xlYXIgd2h5IHRoaXMgY2F1c2VkIGEgc3Rpci4gDQoNClN0aWxsLCBJIHRob3VnaHQgdGhlcmUg
d2FzIGEgcGVyY2VpdmVkIGNvbW1vbiBjYXNlIGZvciBhIGNsaWVudCB0bw0KYmUgYWJsZSB0byB1
c2UgYW5vdGhlciBIVFRQLzIgc3RyZWFtIHRvIGNvbGxlY3QgbG9ncy4gIElmIHRoZSBjbGllbnQN
CmNhbiBkbyB0aGlzIGFscmVhZHkgYW5kIGl0J3MgY29tcGxldGVseSB0cmFuc3BhcmVudCB0byB0
aGUgc2VydmVyLA0KdGhlbiBoYXZpbmcgYSBzdGF0ZW1lbnQganVzdCBzYXlpbmcgdGhhdCB3b3Vs
ZCBiZSBnb29kLiAgVGhpcyBpcw0Kd2hhdCBteSBjb21tZW50IHdhcyBhYm91dC4NCg0KQlRXLCBT
ZWN0aW9uIDMuMSByZWdhcmRzIGhvdyBhIFJFU1RDT05GIGNsaWVudCBjYW4gcHJvbW90ZSBIVFRQ
IDEuMQ0KdG8gSFRUUCAyLjAuICBJdCBsb29rcyBsaWtlIGEgZ29vZCBhcHByb2FjaCwgYnV0IHNo
b3VsZCB0aGUgdGV4dCBiZSANCmluIGFub3RoZXIgZG9jdW1lbnQsIGlmIGl0J3Mgbm90IHNwZWNp
ZmljIHRvIFJOPyAgDQoNCktlbnQgLy8gY29udHJpYnV0b3INCiANCg0K


From nobody Thu Sep 27 16:23:46 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE12130E7D for ; Thu, 27 Sep 2018 16:23:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dPwROlUZ6WE for ; Thu, 27 Sep 2018 16:23:43 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A47130DE4 for ; Thu, 27 Sep 2018 16:23:43 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A777FE21; Fri, 28 Sep 2018 01:23:41 +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 HsMuApJ2daRo; Fri, 28 Sep 2018 01:23:40 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 28 Sep 2018 01:23:41 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6765720035; Fri, 28 Sep 2018 01:23:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id atKc2XDOUo6U; Fri, 28 Sep 2018 01:23:41 +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 "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id F05E220031; Fri, 28 Sep 2018 01:23:40 +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.1415.2; Fri, 28 Sep 2018 01:23:40 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 475053000BB2B0; Fri, 28 Sep 2018 01:23:39 +0200 (CEST)
Date: Fri, 28 Sep 2018 01:23:39 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
CC: Andy Bierman , Martin Bjorklund , Netconf , "rrahman=40cisco.com@dmarc.ietf.org" 
Message-ID: <20180927232339.3c5ous2xj3jhtu4p@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , Andy Bierman , Martin Bjorklund , Netconf , "rrahman=40cisco.com@dmarc.ietf.org" 
References:  <20180927.224854.1626742691261140238.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: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2018 23:23:46 -0000

On Thu, Sep 27, 2018 at 10:55:54PM +0000, Kent Watsen wrote:
> 
> BTW, Section 3.1 regards how a RESTCONF client can promote HTTP 1.1
> to HTTP 2.0.  It looks like a good approach, but should the text be 
> in another document, if it's not specific to RN?  
>

The text should be removed. How HTTP/2 sessions are started is defined
in section 3 of RFC 7540.

/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 Sep 27 18:34:41 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB8A130DD2 for ; Thu, 27 Sep 2018 18:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.157
X-Spam-Level: 
X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 L94Bz5DuTe4k for ; Thu, 27 Sep 2018 18:34:37 -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 D8167130DCA for ; Thu, 27 Sep 2018 18:34:36 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8S1Xsgc000696; Thu, 27 Sep 2018 18:34:34 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=NkMjyX8BgGrqLqnHr84KjPDMmP111+1Lu3VHw6/ekLg=; b=R+xnSkhcA7dy5xzVgFNY9kDJdvg2XqitH8QsvpdneVgg8dghhCOeYQwHpKwLF+nqXAyn mNrFlJU2Cp65bzGHh/EzAEZc6voIkQZTFacB7/K0wyBpHix6Tb1uhk3qC1IvbGVxfxCH 90rQo4wfEeG3IwFPfagEPa8hoqUOVj+PFGEZJmdfHAQwywLewt9a4RlqFBBM960tzeDE 0JKy2MRw4JIOsh3FsNs0WPpGMN9HWwESlNryZ5hwFVNXUmT6YmQbqKiWFNfElV8kljMR IfiTj4eZZJGhA9yUe81RslMQNxpkfbRlkD+wmWFAOxejyLeAeJU9K8rsB2Q55PPq0nQO gw== 
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0024.outbound.protection.outlook.com [216.32.181.24]) by mx0b-00273201.pphosted.com with ESMTP id 2ms9ucr2e9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Sep 2018 18:34:34 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4619.namprd05.prod.outlook.com (20.176.109.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.16; Fri, 28 Sep 2018 01:34:32 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%3]) with mapi id 15.20.1185.014; Fri, 28 Sep 2018 01:34:32 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder 
CC: Andy Bierman , Martin Bjorklund , Netconf , "rrahman=40cisco.com@dmarc.ietf.org" 
Thread-Topic: [Netconf] SSE and HTTP/2 in restcon-notif
Thread-Index: AQHUVpLBkBpJSSIQbkWRq5O8cMUK2aUEmdsAgAAMawD//9QCgIAAStCA///hgoA=
Date: Fri, 28 Sep 2018 01:34:32 +0000
Message-ID: <067FCC27-2310-4205-8A9A-3418FAFF28C7@juniper.net>
References:  <20180927.224854.1626742691261140238.mbj@tail-f.com>   <20180927232339.3c5ous2xj3jhtu4p@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180927232339.3c5ous2xj3jhtu4p@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.2.180910
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4619; 6:8Nd1pR0c3PC81XoIIgj5/Mn2toGJL6qVD6Ivi52Ryw1jW4Qxfme2cM6BeSamavx22TXzWRrVnRkqBig4vKDxqEK4VoS/bew8SpgNVF3RgKzhFz71KySHvQZ9D0wyxR4h7kK0jImAv7EbGOlx4MSQSmph8CQCaAmzrdkelTi6cU4hvWxNmcWjxKCmstC+Bwn9gOsNDZO/w1vMDaN+jsWLf93sAoIrmon1eBNta3Y8fKxzom5uDGiPnWj0MbZL2UX3vzEBNcOG6yqivBHmU70fk/rM5uO3gWZ25vvXKLWNMYlGzzULMEpaB+oM8GBloG3PV+oknbYGWWKRm/GAyQrAcpqh9UqVqHO0W9Dkf57+9sHlVlwx3cMhSSiJZyJ4kEVnk2SaPivWpojUxDfBMZQHQy2y7x1CeSasCPgNar+O+f9lQbZr5sERVzSQfeIpFRfNjRp9vzPwy45GmBjGLXld8Q==; 5:pd9+N9N5cWVhjtjqmAjMvddusC4aEnkbDwtoxPnip+gZW/Og3lxopJJgJ5it24nAY7NJ/xMd4xjTPQShBPzAplvadNP08qUrPwtASMIzAwKREc657cC2gj/tyenHmUU66SrgDrjzzvWmzW1o5PXdZS2oe2tA8ZKqXms9CtiADjo=; 7:CZGbLWdVtZD2yT7pVHTQIk6wJoK/Ax7Klnbth/eko16g5Hi8fMfh3ZxOZ9qu69aspHATCYwcYRLSRwChZDGNQoc/FMxmtIvz1itJf51ZmSiWAdNnp2hr5vdV0EDlS3bcFVJ7X8f0/tPGoh4s9gGKyeAUwifeBZ53HnBUVCql+dqcNabrd/d6+gG4lLSD7en4ad14k8RYjPIJVqwDVCH9CB7iGJYJ4Uu7BWoKVcslOIiqcdaHfTohnDoI84B5nljg
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 2d6e4a38-b6e9-4558-53df-08d624e28a88
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4619; 
x-ms-traffictypediagnostic: DM6PR05MB4619:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231355)(944501410)(52105095)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991041); SRVR:DM6PR05MB4619; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4619; 
x-forefront-prvs: 0809C12563
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(366004)(136003)(396003)(199004)(189003)(58126008)(66066001)(54906003)(2906002)(6506007)(76176011)(2900100001)(478600001)(82746002)(256004)(14444005)(105586002)(99286004)(93886005)(186003)(36756003)(4326008)(102836004)(25786009)(106356001)(68736007)(5660300001)(26005)(33656002)(6916009)(6512007)(81166006)(81156014)(6246003)(97736004)(8676002)(3846002)(83716004)(8936002)(14454004)(71200400001)(53936002)(71190400001)(486006)(34290500001)(11346002)(2616005)(6486002)(476003)(86362001)(446003)(229853002)(6116002)(6436002)(5250100002)(7736002)(305945005)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4619; H:DM6PR05MB4665.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-microsoft-antispam-message-info: 064Inxj8fUKQ2Px3orlaSHyEUpCoLdPWCYrgozyTYziEf9b14Y8iqwU5Kh4j0muFYaN9in01G7GDFdKlsLIVhs1wDPaPJaCEH1XTEZSmCOW+jaLoPqS0XQ5lTFQ4Kyvk8DRA/1gesP+yBYvjnl9+jDgKe6PBqlY9v1FWoOdLjCCD4OXouvQHRq5nmFOwnCDGyJk55OEAuAOo0A3JYqkf31cGyzGXPCN0CRX48/v/5VzaMEIsWEqipSpxh65WgY0I/h6d/P/1lFTIIv6zAX+RORZLDf30ne3ikfFYKqBhzao1c/LP8D13eVxgfAfswkbaF8sxyIV2o/iFZHWXQM4fdeEFbGP3GktnFmBJfE+ul0w=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <014E5BBB61A1814D9265AD2098C2CA84@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d6e4a38-b6e9-4558-53df-08d624e28a88
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2018 01:34:32.3496 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4619
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-27_10:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809280015
Archived-At: 
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2018 01:34:38 -0000

DQoNCg0KPiBUaGUgdGV4dCBzaG91bGQgYmUgcmVtb3ZlZC4gSG93IEhUVFAvMiBzZXNzaW9ucyBh
cmUgc3RhcnRlZCBpcyBkZWZpbmVkDQo+IGluIHNlY3Rpb24gMyBvZiBSRkMgNzU0MC4NCg0KUGVy
ZmVjdC4gIFRoaXMgYXBwbGllcyB0byBhbGwgUkVTVENPTkYgY29ubmVjdGlvbnMuIExvb2tpbmcg
bW9yZSBhdCANCnRoZSBmaXJzdCBwYXJhZ3JhcGgsIHRoZSBmaXJzdCBzZW50ZW5jZSBzYXlzOg0K
DQogICBGb3IgYSBkeW5hbWljIHN1YnNjcmlwdGlvbiwgd2hlcmUgYW4gSFRUUCBjbGllbnQgc2Vz
c2lvbiBkb2Vzbid0DQogICBhbHJlYWR5IGV4aXN0LCBhIG5ldyBjbGllbnQgc2Vzc2lvbiBpcyBp
bml0aWF0ZWQgZnJvbSB0aGUgc3Vic2NyaWJlci4NCg0KQnV0IHRoaXMgaXNuJ3QgcXVpdGUgcmln
aHQuICBEeW5hbWljIHN1YnNjcmlwdGlvbnMsIGF0IGxlYXN0IGZvciB0aGlzDQpkcmFmdCBhcmUg
YWx3YXlzIG9uIHRvcCBvZiBhIFJFU1RDT05GIGNvbm5lY3Rpb24uICBQdXQgdG9nZXRoZXIsIHRo
ZQ0KZmlyc3QgcGFyYWdyYXBoIHNob3VsZCBjaGFuZ2UgYXM6DQoNCk9MRDoNCiAgIEZvciBhIGR5
bmFtaWMgc3Vic2NyaXB0aW9uLCB3aGVyZSBhbiBIVFRQIGNsaWVudCBzZXNzaW9uIGRvZXNuJ3QN
CiAgIGFscmVhZHkgZXhpc3QsIGEgbmV3IGNsaWVudCBzZXNzaW9uIGlzIGluaXRpYXRlZCBmcm9t
IHRoZSBzdWJzY3JpYmVyLg0KICAgSWYgdGhlIHN1YnNjcmliZXIgaXMgdW5zdXJlIGlmIEhUVFAy
IGlzIHN1cHBvcnRlZCBieSB0aGUgcHVibGlzaGVyLA0KICAgSFRUUDEuMSB3aWxsIGJlIHVzZWQg
Zm9yIGluaXRpYWwgbWVzc2FnZXMsIGFuZCB0aGVzZSBtZXNzYWdlcyB3aWxsDQogICBpbmNsdWRl
IGFuIEhUVFAgdmVyc2lvbiB1cGdyYWRlIHJlcXVlc3QgYXMgcGVyIFtSRkM3MjMwXSwNCiAgIFNl
Y3Rpb24gNi43LiAgSWYgYSBwdWJsaXNoZXIgcmVzcG9uc2UgaW5kaWNhdGVzIHRoYXQgSFRUUDIg
aXMNCiAgIHN1cHBvcnRlZCwgSFRUUDIgd2lsbCBiZSB1c2VkIGJldHdlZW4gc3Vic2NyaWJlciBh
bmQgcHVibGlzaGVyIGZvcg0KICAgZnV0dXJlIEhUVFAgaW50ZXJhY3Rpb25zIGFzIHBlciBbUkZD
NzU0MF0uDQpORVc6DQogICBEeW5hbWljIHN1YnNjcmlwdGlvbnMgYXJlIGVzdGFibGlzaGVkIHVz
aW5nIHRoZSBSRVNUQ09ORiBwcm90b2NvbA0KICAgW1JGQzgwNDBdLiAgU2VjdGlvbiAyIG9mIFJG
QyA4MDQwIGRlc2NyaWJlcyB0aGUgdHJhbnNwb3J0IHByb3RvY29sDQogICBmb3IgUkVTVENPTkYu
DQoNCkFsc28sIHdoaWxlIGxvb2tpbmcgYXQgU2VjdGlvbiAzLjEsIHRoZSBzZWNvbmQgc2VudGVu
Y2Ugc2F5czoNCg0KICAgQSBzdWJzY3JpYmVyIFNIT1VMRCBlc3RhYmxpc2ggdGhlIEhUVFAgc2Vz
c2lvbiBvdmVyIFRMUyBbUkZDNTI0Nl0NCiAgIEluIG9yZGVyIHRvIHNlY3VyZSB0aGUgY29udGVu
dCBpbiB0cmFuc2l0Lg0KDQpUaGlzIHNlbnRlbmNlIHNob3VsZCBiZSByZW1vdmVkLCBSRVNUQ09O
RiByZXF1aXJlcyBUTFMuICBJIGltYWdpbmUNCnRoaXMgYmVpbmcgYSBob2xkb3ZlciBmcm9tIGJl
Zm9yZSwgYnV0IGFub3RoZXIgbm90aWYgZHJhZnQgbmVlZHMgdG8NCmJlIHdyaXR0ZW4gaWYgd2Fu
dGluZyB0byBzdXBwb3J0IEhUVFAtYmFzZWQgbm90aWZpY2F0aW9ucyB3aXRob3V0DQpyZXF1aXJp
bmcgVExTLCBvciBldmVuIFJFU1RDT05GLg0KDQpTaW1pbGFybHksIHRoZSAzcmQgcGFyYWdyYXBo
IHJlZ2FyZHMgYSBzY2VuYXJpbyB3aGVyZSBUTFMgbWlnaHQgbm90DQpiZSBpbiB1c2UsIHdoaWNo
IHdvbid0IGV2ZXIgaGFwcGVuLiAgRm9yIHRoaXMgcmVhc29uLCB0aGUgZmlyc3QgaGFsZg0Kb2Yg
dGhpcyBwYXJhZ3JhcGggc2hvdWxkIGJlIHJlbW92ZWQuDQoNCktlbnQgLy8gY29udHJpYnV0b3IN
Cg0KDQoNCg==


From nobody Thu Sep 27 20:01:35 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B765C130DD9; Thu, 27 Sep 2018 20:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 b6QNCJBb0L_r; Thu, 27 Sep 2018 20:01:29 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7218D130DC4; Thu, 27 Sep 2018 20:01:29 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 8C839573D4FE2; Fri, 28 Sep 2018 04:01:24 +0100 (IST)
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 28 Sep 2018 04:01:25 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.22]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0399.000; Fri, 28 Sep 2018 11:01:13 +0800
From: Rohit R Ranade 
To: Netconf , "draft-ietf-netconf-nmda-netconf@ietf.org" 
Thread-Topic: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf
Thread-Index: AdP5cHGIUfFqVxlzSpC0uX7jp7wZ7gAETTEAAIolOQAAAYmwAAGVpb+AAC3FYYAAEkICwP//ifkAgAiE3AD//wYVAIALDdkA/2vKUMA=
Date: Fri, 28 Sep 2018 03:01:13 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BC4DC52@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB4569@dggeml510-mbx.china.huawei.com>  <20180604.121748.1873023460220711310.mbj@tail-f.com> <224028b2-59c5-6859-0e2a-331ed48121ec@cisco.com>  <20180613102721.tnqufeommaojdwm2@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BBBD928@dggeml510-mbx.china.huawei.com> <20180613120742.7xfgwy66jq6qxsmf@anna.jacobs.jacobs-university.de> <8AEB4F37-A148-428F-A5C0-1AB836F0733E@juniper.net> <991B70D8B4112A4699D5C00DDBBF878A6BBC062A@dggeml510-mbx.china.huawei.com> <20180625080714.kg2h66mxc7kpgtgs@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180625080714.kg2h66mxc7kpgtgs@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2018 03:01:34 -0000

SGkgQWxsLA0KDQpDYW4gd2UgYWRkIHRoZSBiZWxvdyBjaGFuZ2UgdG8gdGhlIGlldGYtbmV0Y29u
Zi1ubWRhLW5ldGNvbmYgZHJhZnQgPyANCg0KV2l0aCBSZWdhcmRzLA0KUm9oaXQgUiBSYW5hZGUN
Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRl
ciBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0gDQpTZW50OiAy
NSBKdW5lIDIwMTggMTM6MzcNClRvOiBSb2hpdCBSIFJhbmFkZSA8cm9oaXRycmFuYWRlQGh1YXdl
aS5jb20+DQpDYzogS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+OyBNYWhlc2ggSmV0
aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT47IE5ldGNvbmYgPG5ldGNvbmZAaWV0
Zi5vcmc+OyBkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1uZXRjb25mQGlldGYub3JnDQpTdWJqZWN0
OiBSZTogW05ldGNvbmZdIEVkaXRvcmlhbCBjaGFuZ2UtMiBmb3IgZHJhZnQtaWV0Zi1uZXRjb25m
LW5tZGEtbmV0Y29uZg0KDQpUaGlzIHNlZW1zIHRvIGJlIGNvcnJlY3QgYXMgZmFyIGFzIEkgY2Fu
IHRlbGwuIEkgYW0gbm90IHN1cmUgd2hhdCBleGFjdGx5IHRoZSBjaGFuZ2VzIGFyZSAoaS5lLiwg
d2hlcmUgdGhpcyBpcyBzdXBwb3NlZCB0byBnbykgYW5kIEkgdGhpbmsgdGhlIGRvY3VtZW50IHNo
ZXBoZXJlZCBzaG91bGQgcHJvYmFibHkgY29vcmRpbmF0ZSB0aGlzIGFzIHdlIGFyZSBub3cgbW92
aW5nIHRvIElFVEYgbGFzdCBjYWxsIChvbmNlIHRoZSBkZXRhaWxzIGhhdmUgYmVlbiB3b3JrZWQg
b3V0LCB3ZSBjb3VsZCBmb3IgZXhhbXBsZSB0cmVhdCB0aGlzIGFzIElFVEYgbGFzdCBjYWxsIGNv
bW1lbnQpLg0KDQovanMNCg0KT24gVHVlLCBKdW4gMTksIDIwMTggYXQgMDU6MjU6MzdBTSArMDAw
MCwgUm9oaXQgUiBSYW5hZGUgd3JvdGU6DQo+IEkgYWdyZWUgd2l0aCBKdWVyZ2VuJ3MgY29tbWVu
dHMuIE9ubHkgZXhjZXB0aW9uIGlzIHRoYXQgImludGVuZGVkIiBmb3IgIiBuZWdhdGVkLW9yaWdp
bi1maWx0ZXIiIHdpbGwgYmUgcXVhbGlmaWVkIGJ5IHRoZSBpZXRmLW9yaWdpbiBuYW1lc3BhY2Uu
DQo+IFBsZWFzZSBmaW5kIHRoZSB1cGRhdGVkIGV4YW1wbGUuDQo+IA0KPiAgICA8cnBjIG1lc3Nh
Z2UtaWQ9IjEwMSINCj4gICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj
b25mOmJhc2U6MS4wIj4NCj4gICAgICA8Z2V0LWRhdGEgeG1sbnM9InVybjppZXRmOnBhcmFtczp4
bWw6bnM6eWFuZzppZXRmLW5ldGNvbmYtbm1kYSINCj4gICAgICAgICAgICAgICAgeG1sbnM6ZHM9
InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLWRhdGFzdG9yZXMiDQo+ICAgICAgICAg
ICAgICAgIHhtbG5zOm9yPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1vcmlnaW4i
Pg0KPiAgICAgICAgPGRhdGFzdG9yZT5kczpydW5uaW5nPC9kYXRhc3RvcmU+DQo+ICAgICAgICA8
c3VidHJlZS1maWx0ZXI+DQo+ICAgICAgICAgIDxiZ3AgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNv
bS9ucy9leGFtcGxlIi8+DQo+ICAgICAgIDwvc3VidHJlZS1maWx0ZXI+DQo+ICAgICAgICA8bmVn
YXRlZC1vcmlnaW4tZmlsdGVyPm9yOmludGVuZGVkPC9uZWdhdGVkLW9yaWdpbi1maWx0ZXI+DQo+
ICAgICAgICA8d2l0aC1vcmlnaW4vPg0KPiAgICAgIDwvZ2V0LWRhdGE+DQo+ICAgIDwvcnBjPg0K
PiANCj4gICAgPHJwYy1yZXBseSBtZXNzYWdlLWlkPSIxMDEiDQo+ICAgICAgICAgeG1sbnM9InVy
bjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQo+ICAgICAgPGRhdGEgeG1s
bnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLW5ldGNvbmYtbm1kYSI+DQo+ICAg
ICAgIDxiZ3AgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ucy9leGFtcGxlIiANCj4gICAgICAg
ICAgIHhtbG5zOm9yPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1vcmlnaW4iDQo+
ICAgICAgICAgICBvcjpvcmlnaW49Im9yOmludGVuZGVkIj4NCj4gICAgICAgIDxwZWVyPg0KPiAg
ICAgICAgICA8bmFtZT4yMDAxOmRiODo6MjozPC9uYW1lPg0KPiAgICAgICAgICA8bG9jYWwtYXMg
b3I6b3JpZ2luPSJvcjpkZWZhdWx0Ij42NDUwMTwvbG9jYWwtYXM+DQo+ICAgICAgICAgIDxwZWVy
LWFzIG9yOm9yaWdpbj0ib3I6ZGVmYXVsdCI+NjQ1MDI8L3BlZXItYXM+DQo+ICAgICAgICAgIDxs
b2NhbC1wb3J0IG9yOm9yaWdpbj0ib3I6c3lzdGVtIj42MDc5NDwvbG9jYWwtcG9ydD4NCj4gICAg
ICAgICAgPHJlbW90ZS1wb3J0IG9yOm9yaWdpbj0ib3I6ZGVmYXVsdCI+MTc5PC9yZW1vdGUtcG9y
dD4NCj4gICAgICAgICAgPHN0YXRlPmVzdGFibGlzaGVkPC9zdGF0ZT4NCj4gICAgICAgIDwvcGVl
cj4NCj4gICAgICAgPC9iZ3A+DQo+ICAgICAgPC9kYXRhPg0KPiAgICA8L3JwYy1yZXBseT4NCj4g
DQo+IA0KPiBXaXRoIFJlZ2FyZHMsDQo+IFJvaGl0IFIgUmFuYWRlDQo+IA0KPiAtLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBLZW50IFdhdHNlbiBbbWFpbHRvOmt3YXRzZW5AanVu
aXBlci5uZXRdDQo+IFNlbnQ6IDE5IEp1bmUgMjAxOCAwMzo0Mw0KPiBUbzogSnVlcmdlbiBTY2hv
ZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+OyANCj4gUm9o
aXQgUiBSYW5hZGUgPHJvaGl0cnJhbmFkZUBodWF3ZWkuY29tPg0KPiBDYzogTWFoZXNoIEpldGhh
bmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+OyBOZXRjb25mIA0KPiA8bmV0Y29uZkBp
ZXRmLm9yZz47IGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLW5ldGNvbmZAaWV0Zi5vcmcNCj4gU3Vi
amVjdDogUmU6IFtOZXRjb25mXSBFZGl0b3JpYWwgY2hhbmdlLTIgZm9yIA0KPiBkcmFmdC1pZXRm
LW5ldGNvbmYtbm1kYS1uZXRjb25mDQo+IA0KPiBMZXQncyBjb25jbHVkZSB0aGlzIHRocmVhZCBh
bmQgcHVzaCBhbiB1cGRhdGUgKG9yIHVwZGF0cmVzKSB0byBHaXRIdWIsIHNvIHRoZSB1cGRhdGUg
ZG9lc24ndCBnZXQgbG9zdCBhcyB3ZSBoZWFkIGludG8gdGhlIElFU0cgTEMuDQo+IA0KPiBUd28g
aXRlbXM6DQo+ICAgLSAib3JpZ2luLWZpbHRlciIgcGFyYW1ldGVyDQo+ICAgLSA8Z2V0LWRhdGE+
IHVzYWdlIGV4YW1wbGUNCj4gDQo+IEtlbnQgYW5kIE1haGVzaA0KPiANCj4gDQo+ID09PT09IG9y
aWdpbmFsIG1lc3NhZ2UgPT09PT0NCj4gDQo+IFllcywgZm9yIGJncCB0aGVyZSBpcyBubyBuYW1l
c3BhY2UgZGVmaW5lZCBpbiB0aGUgZXhhbXBsZSBpbiBSRkMgODM0Mi4gVXNpbmcgaWV0Zi1uZXRj
b25mLW5tZGEgY2xlYXJseSBpcyBtaXNsZWFkaW5nLCBhIGZpY3Rpb25hbCBleGFtcGxlIG5hbWVz
cGFjZSB3aWxsIGJlIGJldHRlci4NCj4gDQo+IEkgdGhpbmsgdGhlIGxleGljYWwgcmVwcmVzZW50
YXRpb24gb2YgdGhlIHZhbHVlICdpbnRlbmRlZCcgcmVxdWlyZXMgdG8gYmUgbmFtZXNwYWNlIHF1
YWxpZmllZCwgaS5lLiAnZHM6aW50ZW5kZWQnLg0KPiANCj4gVGhlIHdpdGgtb3JpZ2luIGlzIGRl
ZmluZWQgdG8gYmUgb2YgdHlwZSBlbXB0eSAtIHRoZXJlIGlzIG5vICd0cnVlJw0KPiB2YWx1ZSBv
ciBzb21ldGhpbmcgbGlrZSB0aGF0LCBpdHMganVzdCA8d2l0aC1vcmlnaW4vPi4NCj4gDQo+IC9q
cw0KPiANCj4gT24gV2VkLCBKdW4gMTMsIDIwMTggYXQgMTE6MjA6MjFBTSArMDAwMCwgUm9oaXQg
UiBSYW5hZGUgd3JvdGU6DQo+ID4gSGkgSnVlcmdlbiwNCj4gPiANCj4gPiBDYW4geW91IHBsZWFz
ZSBpZGVudGlmeSB0aGUgbmFtZXNwYWNlcyB3aGljaCBhcmUgbm90IE9LIHNvIHRoYXQgd2UgY2Fu
IGZpeCB0aGVtLiANCj4gPiBGb3Igd2FudCBvZiBhIG5hbWVzcGFjZSBmb3IgImJncCIsIEkgcmUt
dXNlZCB0aGUgaWV0Zi1uZXRjb25mLW5tZGEgbmFtZXNwYWNlIGFzIGl0IGlzIGp1c3QgYW4gZXhh
bXBsZS4gV2UgY2FuIHVzZSB0aGUgImh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92
Mi91cmw/dT1odHRwLTNBX19leGFtcGxlLmNvbV9uc19leGFtcGxlJmQ9RHdJRGFRJmM9SEFrWXVo
NjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBv
T0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1FaGZoU3JvbHFrNlJpT2JUZmtIM0ZNY1JfdXY4
akdELVNXVG9PM21xeG84JnM9dG0tRHJGU1ZyUmtNekFILURpV0VDck5CYldoU21iS25CYXVLZHp4
M0otayZlPSIgbmFtZXNwYWNlIGluc3RlYWQuDQo+ID4gDQo+ID4gV2l0aCBSZWdhcmRzLA0KPiA+
IFJvaGl0IFIgUmFuYWRlDQo+ID4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g
PiBGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgSnVlcmdlbiANCj4gPiBTY2hvZW53YWVsZGVyDQo+ID4gU2VudDogMTMgSnVuZSAyMDE4
IDE1OjU3DQo+ID4gVG86IE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwu
Y29tPg0KPiA+IENjOiBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPjsNCj4gPiBkcmFmdC1pZXRm
LW5ldGNvbmYtbm1kYS1uZXRjb25mQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtOZXRjb25m
XSBFZGl0b3JpYWwgY2hhbmdlLTIgZm9yIA0KPiA+IGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLW5l
dGNvbmYNCj4gPiANCj4gPiBJIGFtIG5vdCBzdXJlIGFuIGV4YW1wbGUgaXMgbmVlZGVkIGJ1dCBp
ZiB3ZSBpbmNsdWRlIG9uZSwgd2UgbmVlZCBvbmUgd2hpY2ggaXMgY29ycmVjdC4gSSB0aGluayB0
aGUgbmFtZXNwYWNlcyBhcmUgYSBiaXQgbWVzc2VkIHVwIGluIFJvaGl0J3MgZXhhbXBsZS4NCj4g
PiANCj4gPiAvanMNCj4gPiANCj4gPiBPbiBUdWUsIEp1biAxMiwgMjAxOCBhdCAwODozNjo0N0FN
IC0wNDAwLCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOg0KPiA+ID4gSGF2ZSB0aGUgYXV0aG9y
cyBhZ3JlZWQgb24gdGhlIGZpbmFsIHNldCBvZiBlZGl0cyBmb3IgdGhpcyBkb2N1bWVudD8gSG93
IGFib3V0IHRoZSBleGFtcGxlIHRoYXQgUm9oaXQgbWVudGlvbmVkIGluIHRoZSBvcmlnaW5hbCBl
LW1haWw/DQo+ID4gPiANCj4gPiA+ID4gT24gSnVuIDQsIDIwMTgsIGF0IDc6MDEgQU0sIFJvYmVy
dCBXaWx0b24gPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4gPiA+ID4gDQo+ID4gPiA+IA0K
PiA+ID4gPiANCj4gPiA+ID4gT24gMDQvMDYvMjAxOCAxMToxNywgTWFydGluIEJqb3JrbHVuZCB3
cm90ZToNCj4gPiA+ID4+IEhpDQo+ID4gPiA+PiANCj4gPiA+ID4+IFR3byBjb21tZW50cyBpbmxp
bmUuDQo+ID4gPiA+PiANCj4gPiA+ID4+IFJvYmVydCBXaWx0b24gPHJ3aWx0b25AY2lzY28uY29t
PiB3cm90ZToNCj4gPiA+ID4+PiBIaSBSb2hpdCwgYXV0aG9ycywNCj4gPiA+ID4+PiANCj4gPiA+
ID4+PiBJIHRoaW5rIHRoYXQgdGhlc2UgYXJlIHZhbGlkIGNsYXJpZmljYXRpb25zLiBJJ3ZlIHJl
d29yZGVkIA0KPiA+ID4gPj4+IHRoZW0gc2xpZ2h0bHksIGFuZCBtb3ZlZCB0aGUgYW5jZXN0b3Ig
bm9kZSB0ZXh0IHRvIHRoZSBZQU5HIA0KPiA+ID4gPj4+IG1vZHVsZSBpbnN0ZWFkLiAgSSBhbHNv
IHRoaW5rIHRoYXQgdGhlIGFuY2VzdG9yIG5vZGUgdGV4dCANCj4gPiA+ID4+PiBnZW5lcmljYWxs
eSBjb3ZlcnMgdGhlIGNvbmZpZyBmaWx0ZXIgY2xhcmlmaWNhdGlvbiB0aGF0IHlvdSByYWlzZWQg
cHJldmlvdXNseS4NCj4gPiA+ID4+PiANCj4gPiA+ID4+PiBIZW5jZSwgSSBwcm9wb3NlIHRoZSBm
b2xsb3dpbmcgZGlmZiB0byB0aGUgTkVUQ09ORiBOTURBIGRyYWZ0Og0KPiA+ID4gPj4+IA0KPiA+
ID4gPj4+IHJ3aWx0b25AcndpbHRvbi1sbng6fi9uZXRjb25mLXdnL25ldGNvbmYtbm1kYSQgZ2l0
IGRpZmYgDQo+ID4gPiA+Pj4gLS1zdGFnZWQgZGlmZiAtLWdpdCBhL2lldGYtbmV0Y29uZi1ubWRh
LnlhbmcgDQo+ID4gPiA+Pj4gYi9pZXRmLW5ldGNvbmYtbm1kYS55YW5nIGluZGV4IGYyOTI5Yjku
LjcyYTY3NGEgMTAwNjQ0DQo+ID4gPiA+Pj4gLS0tIGEvaWV0Zi1uZXRjb25mLW5tZGEueWFuZw0K
PiA+ID4gPj4+ICsrKyBiL2lldGYtbmV0Y29uZi1ubWRhLnlhbmcNCj4gPiA+ID4+PiBAQCAtMTA1
LDYgKzEwNSw5IEBAIG1vZHVsZSBpZXRmLW5ldGNvbmYtbm1kYSB7DQo+ID4gPiA+Pj4gICAgICAg
ICBieSBnZXQtZGF0YSBtdXN0IHNhdGlzZnkgYWxsIGZpbHRlcnMsIGkuZS4sIHRoZSBmaWx0ZXIN
Cj4gPiA+ID4+PiAgICAgICAgIGNyaXRlcmlhIGFyZSBsb2dpY2FsbHkgQU5EZWQuDQo+ID4gPiA+
Pj4gDQo+ID4gPiA+Pj4gKyAgICAgICBBbnkgYW5jZXN0b3Igbm9kZXMgKGluY2x1ZGluZyBsaXN0
IGtleXMpIG9mIG5vZGVzIG1hdGNoZWQgYnkNCj4gPiA+ID4+PiArICAgICAgIHRoZSBmaWx0ZXIg
YXJlIGluY2x1ZGVkIGluIHRoZSByZXNwb25zZS4NCj4gPiA+ID4+PiArDQo+ID4gPiA+Pj4gICAg
ICAgICBUaGUgJ3dpdGgtb3JpZ2luJyBwYXJhbWV0ZXIgaXMgb25seSB2YWxpZCBmb3IgYW4gb3Bl
cmF0aW9uYWwNCj4gPiA+ID4+PiAgICAgICAgIGRhdGFzdG9yZS4gSWYgJ3dpdGgtb3JpZ2luJyBp
cyB1c2VkIHdpdGggYW4gaW52YWxpZCBkYXRhc3RvcmUsDQo+ID4gPiA+Pj4gICAgICAgICB0aGVu
IHRoZSBzZXJ2ZXIgTVVTVCByZXR1cm4gYW4gPHJwYy1lcnJvcj4gZWxlbWVudCANCj4gPiA+ID4+
PiB3aXRoIGFuIEBAIC0xOTMsNyArMTk2LDcgQEAgbW9kdWxlIGlldGYtbmV0Y29uZi1ubWRhIHsN
Cj4gPiA+ID4+PiAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ID4gPiA+Pj4gICAgICAgICAgICAg
ICJGaWx0ZXIgYmFzZWQgb24gdGhlICdvcmlnaW4nIGFubm90YXRpb24uICBBIG5vZGUgbWF0Y2hl
cw0KPiA+ID4gPj4+ICAgICAgICAgICAgICAgdGhlIGZpbHRlciBpZiBpdHMgJ29yaWdpbicgYW5u
b3RhdGlvbiBpcyBub3QgZGVyaXZlZA0KPiA+ID4gPj4+IC0gICAgICAgICAgICAgZnJvbSBhbmQg
bm90IGVxdWFsIHRvIGFsbCBvZiB0aGUgZ2l2ZW4gZmlsdGVyIHZhbHVlcy4iOw0KPiA+ID4gPj4+
ICsgICAgICAgICAgICAgZnJvbSBhbmQgbm90IGVxdWFsIHRvIGFueSBvZiB0aGUgZ2l2ZW4gZmls
dGVyIA0KPiA+ID4gPj4+ICsgdmFsdWVzLiI7DQo+ID4gPiA+Pj4gICAgICAgICAgfQ0KPiA+ID4g
Pj4+ICAgICAgICB9DQo+ID4gPiA+Pj4gDQo+ID4gPiA+Pj4gZGlmZiAtLWdpdCBhL25tZGEtbmV0
Y29uZi5vcmcgYi9ubWRhLW5ldGNvbmYub3JnIGluZGV4DQo+ID4gPiA+Pj4gZTQ0ZTJjNy4uMTAw
ZTE3MyAxMDA2NDQNCj4gPiA+ID4+PiAtLS0gYS9ubWRhLW5ldGNvbmYub3JnDQo+ID4gPiA+Pj4g
KysrIGIvbm1kYS1uZXRjb25mLm9yZw0KPiA+ID4gPj4+IEBAIC0xMjksMTQgKzEyOSwxNyBAQCBU
aGUgImNvbmZpZy1maWx0ZXIiIHBhcmFtZXRlciBjYW4gYmUgDQo+ID4gPiA+Pj4gdXNlZCB0byBy
ZXRyaWV2ZSBvbmx5ICJjb25maWcgIHRydWUiIG9yICJjb25maWcgZmFsc2UiIG5vZGVzLg0KPiA+
ID4gPj4+IA0KPiA+ID4gPj4+ICBUaGUgIm9yaWdpbi1maWx0ZXIiIHBhcmFtZXRlciwgd2hpY2gg
Y2FuIGJlIHByZXNlbnQgbXVsdGlwbGUgDQo+ID4gPiA+Pj4gdGltZXMsIC1zZWxlY3RzIG5vZGVz
IG1hdGNoaW5nIGFueSBvZiB0aGUgZ2l2ZW4gdmFsdWVzLiBUaGUgDQo+ID4gPiA+Pj4gLSJuZWdh
dGVkLW9yaWdpbi1maWx0ZXIiLCB3aGljaCBjYW4gYmUgcHJlc2VudCBtdWx0aXBsZSB0aW1lcywg
DQo+ID4gPiA+Pj4gc2VsZWN0cyAtbm9kZXMgdGhhdCBkbyBub3QgbWF0Y2ggYWxsIGdpdmVuIHZh
bHVlcy4gVGhlICJvcmlnaW4tZmlsdGVyIg0KPiA+ID4gPj4+IC1hbmQgIm5lZ2F0ZWQtb3JpZ2lu
LWZpbHRlciIgcGFyYW1ldGVycyBjYW5ub3QgYmUgdXNlZCB0b2dldGhlci4NCj4gPiA+ID4+PiAr
c2VsZWN0cyBub2RlcyB3aXRoIG9yaWdpbnMgbWF0Y2hpbmcsIG9yIGRlcml2ZWQgZnJvbSwgYW55
IG9mIA0KPiA+ID4gPj4+ICt0aGUNCj4gPiA+ID4+PiBnaXZlbg0KPiA+ID4gPj4gSSB3b3VsZCBw
cmVmZXI6DQo+ID4gPiA+PiANCj4gPiA+ID4+ICBzZWxlY3RzIG5vZGVzIHdpdGggb3JpZ2lucyBl
cXVhbCB0bywgb3IgZGVyaXZlZCBmcm9tLCBhbnkgb2YgDQo+ID4gPiA+PiB0aGUgZ2l2ZW4NCj4g
PiA+ID4+IA0KPiA+ID4gPj4gDQo+ID4gPiA+PiBJTU8sIHRoZSB0ZXJtICJtYXRjaCIgaW4gdGhl
IG9yaWdpbmFsIHRleHQgbWVhbnMgImVxdWFsIHRvIG9yIA0KPiA+ID4gPj4gZGVyaXZlZC1mcm9t
IiwgYXMgZXhwbGFpbmVkIGluIHRoZSBkYXRhIG1vZGVsLg0KPiA+ID4gPj4gDQo+ID4gPiA+PiBU
aGUgdGVybSAibWF0Y2giIGlzIHByb2JsZW1hdGljIHVubGVzcyBpdCBpcyBleHBsYWluZWQsIGIv
YyANCj4gPiA+ID4+IHNvbWUgcGVvcGxlIHdpbGwgdGhpbmsgaXQgbWVhbnMgImVxdWFsIHRvIi4g
IChOb29uZSB3aWxsIHRoaW5rIA0KPiA+ID4gPj4gdGhhdCAibWF0Y2hlcyB0aGUgcmVndWxhciBl
eHByZXNzaW9uIiBtZWFucyAiZXF1YWwgdG8gdGhlIA0KPiA+ID4gPj4gcmVndWxhciBleHByZXNz
aW9uIiB0aG91Z2guLi4pDQo+ID4gPiA+PiANCj4gPiA+ID4+IENvbmNsdXNpb246IGFsd2F5cyBh
dm9pZCB0aGUgdGVybSAibWF0Y2giLg0KPiA+ID4gPiBPSy4NCj4gPiA+ID4gDQo+ID4gPiA+PiAN
Cj4gPiA+ID4+PiArdmFsdWVzLiBUaGUgIm5lZ2F0ZWQtb3JpZ2luLWZpbHRlciIsIHdoaWNoIGNh
biBiZSBwcmVzZW50IA0KPiA+ID4gPj4+ICttdWx0aXBsZSB0aW1lcywgc2VsZWN0cyBub2RlcyB3
aXRoIG9yaWdpbnMgdGhhdCBkbyBub3QgbWF0Y2gsIA0KPiA+ID4gPj4+ICthbmQgYXJlIG5vdCBk
ZXJpdmVkIGZyb20sIGFueSBvZiB0aGUgZ2l2ZW4gdmFsdWVzLiBUaGUgDQo+ID4gPiA+Pj4gKyJv
cmlnaW4tZmlsdGVyIiBhbmQgIm5lZ2F0ZWQtb3JpZ2luLWZpbHRlciIgcGFyYW1ldGVycyBjYW5u
b3QgYmUgdXNlZCB0b2dldGhlci4NCj4gPiA+ID4+PiANCj4gPiA+ID4+PiAgVGhlICJtYXgtZGVw
dGgiIHBhcmFtZXRlciBjYW4gYmUgdXNlZCBieSB0aGUgY2xpZW50IHRvIGxpbWl0IA0KPiA+ID4g
Pj4+IHRoZSBudW1iZXIgb2Ygc3ViLXRyZWUgbGV2ZWxzIHRoYXQgYXJlIHJldHVybmVkIGluIHRo
ZSByZXBseS4NCj4gPiA+ID4+PiANCj4gPiA+ID4+PiBOb3RlIHRvIHRoZSBhdXRob3JzLCBmb3Ig
dGhlIG5lZ2F0aXZlLW9yaWdpbi1maWx0ZXIsIEkndmUgYWxzbyANCj4gPiA+ID4+PiBjaGFuZ2Vk
ICJhbGwiIHRvICJhbnkiICh3aGljaCBjaGFuZ2VzIHRoZSBzZW1hbnRpY3MsIGJ1dCBJIA0KPiA+
ID4gPj4+IHRoaW5rIGl0IHdhcyB3cm9uZyBiZWZvcmUpLg0KPiA+ID4gPj4gQWdyZWUgdGhhdCAi
YW55IiBpcyBjb3JyZWN0Lg0KPiA+ID4gPj4gDQo+ID4gPiA+PiBCdXQgZG9lcyBpdCByZWFsbHkg
Y2hhbmdlIHRoZSBzZW1hbnRpY3M/ICAiYWxsIiBzb3VuZHMgcXVpdGUgDQo+ID4gPiA+PiBvZGQs
IGJ1dCBpc24ndCB0aGUgZW5kIHJlc3VsdCB0aGUgc2FtZT8NCj4gPiA+ID4gSSB0aGluayB0aGF0
IGl0IGlzIGNvbmZ1c2luZywgYW5kIHByb2JhYmx5IGRlcGVuZHMgb24gaG93IHlvdSByZWFkIGl0
Lg0KPiA+ID4gPiANCj4gPiA+ID4gQnV0LCBpZiB5b3UgYXJlIE9LIHdpdGggImFueSIgdGhlbiBJ
IHRoaW5rIHRoYXQgcmVhZHMgYmV0dGVyIGFuZCBpcyBtb3JlIGludHVpdGl2ZS4NCj4gPiA+ID4g
DQo+ID4gPiA+IFRoYW5rcywNCj4gPiA+ID4gUm9iDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+
ID4gDQo+ID4gPiA+PiANCj4gPiA+ID4+IA0KPiA+ID4gPj4gL21hcnRpbg0KPiA+ID4gPj4gDQo+
ID4gPiA+PiANCj4gPiA+ID4+PiBTaW1pbGFyIHVwZGF0ZXMgd2lsbCBuZWVkIHRvIGFsc28gYmUg
ZG9uZSB0byBSRVNUQ09ORiwgYnV0IA0KPiA+ID4gPj4+IGxldCdzIGFncmVlIHRoZSBORVRDT05G
IHRleHQgZmlyc3QuDQo+ID4gPiA+Pj4gDQo+ID4gPiA+Pj4gVGhhbmtzLA0KPiA+ID4gPj4+IFJv
Yg0KPiA+ID4gPj4+IA0KPiA+ID4gPj4+IA0KPiA+ID4gPj4+IE9uIDAxLzA2LzIwMTggMTA6MTAs
IFJvaGl0IFIgUmFuYWRlIHdyb3RlOg0KPiA+ID4gPj4+PiBIaSBBbGwsDQo+ID4gPiA+Pj4+IA0K
PiA+ID4gPj4+PiBTZWN0aW9uIDMuMS4xDQo+ID4gPiA+Pj4+IA0KPiA+ID4gPj4+PiBPTEQ6DQo+
ID4gPiA+Pj4+IA0KPiA+ID4gPj4+PiAgICBUaGUgIm9yaWdpbi1maWx0ZXIiIHBhcmFtZXRlciwg
d2hpY2ggY2FuIGJlIHByZXNlbnQgDQo+ID4gPiA+Pj4+IG11bHRpcGxlIHRpbWVzLA0KPiA+ID4g
Pj4+PiANCj4gPiA+ID4+Pj4gICAgc2VsZWN0cyBub2RlcyBtYXRjaGluZyBhbnkgb2YgdGhlIGdp
dmVuIHZhbHVlcy4gIFRoZQ0KPiA+ID4gPj4+PiANCj4gPiA+ID4+Pj4gIm5lZ2F0ZWQtb3JpZ2lu
LWZpbHRlciIsIHdoaWNoIGNhbiBiZSBwcmVzZW50IG11bHRpcGxlIHRpbWVzLCANCj4gPiA+ID4+
Pj4gc2VsZWN0cw0KPiA+ID4gPj4+PiANCj4gPiA+ID4+Pj4gICAgbm9kZXMgdGhhdCBkbyBub3Qg
bWF0Y2ggYWxsIGdpdmVuIHZhbHVlcy4NCj4gPiA+ID4+Pj4gDQo+ID4gPiA+Pj4+IE5FVzoNCj4g
PiA+ID4+Pj4gDQo+ID4gPiA+Pj4+IFRoZSAib3JpZ2luLWZpbHRlciIgcGFyYW1ldGVyLCB3aGlj
aCBjYW4gYmUgcHJlc2VudCBtdWx0aXBsZSANCj4gPiA+ID4+Pj4gdGltZXMsDQo+ID4gPiA+Pj4+
IA0KPiA+ID4gPj4+PiAgICBzZWxlY3RzIG5vZGVzIHdoaWNoIGFyZSBkZXJpdmVkIGZyb20gb3Ig
bWF0Y2hpbmcgYW55IG9mIA0KPiA+ID4gPj4+PiB0aGUgZ2l2ZW4gdmFsdWVzLiAgVGhlDQo+ID4g
PiA+Pj4+IA0KPiA+ID4gPj4+PiAibmVnYXRlZC1vcmlnaW4tZmlsdGVyIiwgd2hpY2ggY2FuIGJl
IHByZXNlbnQgbXVsdGlwbGUgdGltZXMsIA0KPiA+ID4gPj4+PiBzZWxlY3RzDQo+ID4gPiA+Pj4+
IA0KPiA+ID4gPj4+PiAgICBub2RlcyB3aGljaCBhcmUgbm90IGRlcml2ZWQgZnJvbSBhbmQgZG8g
bm90IG1hdGNoIGFsbCBnaXZlbiB2YWx1ZXMuDQo+ID4gPiA+Pj4+IA0KPiA+ID4gPj4+PiBXaGVu
IGEgZGF0YS1ub2RlIG1hdGNoaW5nIHRoZSBmaWx0ZXIgaXMgc2VsZWN0ZWQsIHRoZSANCj4gPiA+
ID4+Pj4gY29uZmlndXJhdGlvbiBhbmNlc3RvcnMNCj4gPiA+ID4+Pj4gDQo+ID4gPiA+Pj4+IChp
ZiBhbnkpIGFuZCBsaXN0IGtleSBsZWFmcyAoaWYgYW55KSwgZXZlbiBpZiB0aGV5IGRvIG5vdCAN
Cj4gPiA+ID4+Pj4gbWF0Y2ggdGhlIGZpbHRlciwgYXJlIGFsc28gcmV0dXJuZWQuDQo+ID4gPiA+
Pj4+IA0KPiA+ID4gPj4+PiBDb25zaWRlciB0d28gb3JpZ2lucyBzdWNoIGFzIOKAnGxlYXJuZWTi
gJ0gYW5kIOKAnGRlcml2ZWQtZnJvbS1sZWFybmVk4oCdLg0KPiA+ID4gPj4+PiANCj4gPiA+ID4+
Pj4g4oCcZGVyaXZlZC1mcm9tLWxlYXJuZWTigJ0gaXMgZGVyaXZlZCBmcm9tIGxlYXJuZWQgb3Jp
Z2luLg0KPiA+ID4gPj4+PiANCj4gPiA+ID4+Pj4gVXNpbmcgdGhlIG9yaWdpbiBmaWx0ZXJzIGl0
IGlzIG5vdCBwb3NzaWJsZSB0byBnZXQgbm9kZXMgDQo+ID4gPiA+Pj4+IGJlbG9uZ2luZyB0byDi
gJxsZWFybmVk4oCdDQo+ID4gPiA+Pj4+IA0KPiA+ID4gPj4+PiBvbmx5IGFzIHRoZSBub2RlcyBv
ZiBkZXJpdmVkIG9yaWdpbiBhcmUgYXV0b21hdGljYWxseSBzZWxlY3RlZC4NCj4gPiA+ID4+Pj4g
DQo+ID4gPiA+Pj4+IE5vdGVzOg0KPiA+ID4gPj4+PiANCj4gPiA+ID4+Pj4gVGhlIHRleHQgaW4g
My4xLjEgZGlkIG5vdCBpbmNsdWRlIHRoZSDigJxkZXJpdmVkLWZyb23igJ0gbG9naWMgDQo+ID4g
PiA+Pj4+IGZvciBzZWxlY3Rpb24gLCB3aGlsZSBpbiB0aGUgZGF0YS1tb2RlbCBkZWZpbml0aW9u
IGl0IHdhcyBwcmVzZW50Lg0KPiA+ID4gPj4+PiANCj4gPiA+ID4+Pj4gIFdlIGNhbiBhbHNvIGFk
ZCBjbGFyaWZpY2F0aW9uIGFib3V0IHRoZSBhbmNlc3RvciBhbmQga2V5IA0KPiA+ID4gPj4+PiBi
ZWluZyBvdXRwdXQsIGV2ZW4gaWYgdGhvdWdoIHRoZXkgZG8gbWF0Y2ggdGhlIGZpbHRlciwgc2lu
Y2UgDQo+ID4gPiA+Pj4+IHRoZSBsZWFmDQo+ID4gPiA+Pj4+IA0KPiA+ID4gPj4+PiBtYXRjaGVz
IHRoZSBmaWx0ZXIuDQo+ID4gPiA+Pj4+IA0KPiA+ID4gPj4+PiBFeGFtcGxlIDogV2UgY2FuIHVz
ZSB0aGUgUkZDIDgzNDIgQXBwZW5kaXggQy4yIEJHUCBFeGFtcGxlDQo+ID4gPiA+Pj4+IA0KPiA+
ID4gPj4+PiAgICA8cnBjIG1lc3NhZ2UtaWQ9IjEwMSINCj4gPiA+ID4+Pj4gDQo+ID4gPiA+Pj4+
IHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiPg0KPiA+ID4g
Pj4+PiANCj4gPiA+ID4+Pj4gICAgICA8Z2V0LWRhdGEgeG1sbnM9InVybjppZXRmOnBhcmFtczp4
bWw6bnM6eWFuZzppZXRmLW5ldGNvbmYtbm1kYSINCj4gPiA+ID4+Pj4gDQo+ID4gPiA+Pj4+IHht
bG5zOmRzPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1kYXRhc3RvcmVzIj4NCj4g
PiA+ID4+Pj4gDQo+ID4gPiA+Pj4+IDxkYXRhc3RvcmU+ZHM6cnVubmluZzwvZGF0YXN0b3JlPg0K
PiA+ID4gPj4+PiANCj4gPiA+ID4+Pj4gPHN1YnRyZWUtZmlsdGVyPg0KPiA+ID4gPj4+PiANCj4g
PiA+ID4+Pj4gICAgICAgICAgPGJncA0KPiA+ID4gPj4+PiB4bWxucz0idXJuOmlldGY6cGFyYW1z
OnhtbDpuczp5YW5nOmlldGYtbmV0Y29uZi1ubWRhIi8+DQo+ID4gPiA+Pj4+IA0KPiA+ID4gPj4+
PiAgICAgICA8L3N1YnRyZWUtZmlsdGVyPg0KPiA+ID4gPj4+PiANCj4gPiA+ID4+Pj4gPG5lZ2F0
ZWQtb3JpZ2luLWZpbHRlcj5pbnRlbmRlZDwvbmVnYXRlZC1vcmlnaW4tZmlsdGVyPg0KPiA+ID4g
Pj4+PiANCj4gPiA+ID4+Pj4gPHdpdGgtb3JpZ2luPnRydWU8L3dpdGgtb3JpZ2luPg0KPiA+ID4g
Pj4+PiANCj4gPiA+ID4+Pj4gICAgICA8L2dldC1kYXRhPg0KPiA+ID4gPj4+PiANCj4gPiA+ID4+
Pj4gPC9ycGM+DQo+ID4gPiA+Pj4+IA0KPiA+ID4gPj4+PiAgICA8cnBjLXJlcGx5IG1lc3NhZ2Ut
aWQ9IjEwMSINCj4gPiA+ID4+Pj4gDQo+ID4gPiA+Pj4+IHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6
eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiPg0KPiA+ID4gPj4+PiANCj4gPiA+ID4+Pj4gICAgICA8
ZGF0YQ0KPiA+ID4gPj4+PiB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYt
bmV0Y29uZi1ubWRhIj4NCj4gPiA+ID4+Pj4gDQo+ID4gPiA+Pj4+ICAgICAgIDxiZ3AgeG1sbnM6
b3I9InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLW9yaWdpbiINCj4gPiA+ID4+Pj4g
DQo+ID4gPiA+Pj4+IG9yOm9yaWdpbj0ib3I6aW50ZW5kZWQiPg0KPiA+ID4gPj4+PiANCj4gPiA+
ID4+Pj4gICAgICAgIDxwZWVyPg0KPiA+ID4gPj4+PiANCj4gPiA+ID4+Pj4gPG5hbWU+MjAwMTpk
Yjg6OjI6MzwvbmFtZT4NCj4gPiA+ID4+Pj4gDQo+ID4gPiA+Pj4+ICAgICAgICAgIDxsb2NhbC1h
cyBvcjpvcmlnaW49Im9yOmRlZmF1bHQiPjY0NTAxPC9sb2NhbC1hcz4NCj4gPiA+ID4+Pj4gDQo+
ID4gPiA+Pj4+ICAgICAgICAgIDxwZWVyLWFzIG9yOm9yaWdpbj0ib3I6ZGVmYXVsdCI+NjQ1MDI8
L3BlZXItYXM+DQo+ID4gPiA+Pj4+IA0KPiA+ID4gPj4+PiAgICAgICAgICA8bG9jYWwtcG9ydCBv
cjpvcmlnaW49Im9yOnN5c3RlbSI+NjA3OTQ8L2xvY2FsLXBvcnQ+DQo+ID4gPiA+Pj4+IA0KPiA+
ID4gPj4+PiAgICAgICAgICA8cmVtb3RlLXBvcnQgDQo+ID4gPiA+Pj4+IG9yOm9yaWdpbj0ib3I6
ZGVmYXVsdCI+MTc5PC9yZW1vdGUtcG9ydD4NCj4gPiA+ID4+Pj4gDQo+ID4gPiA+Pj4+IDxzdGF0
ZT5lc3RhYmxpc2hlZDwvc3RhdGU+DQo+ID4gPiA+Pj4+IA0KPiA+ID4gPj4+PiAgICAgICAgPC9w
ZWVyPg0KPiA+ID4gPj4+PiANCj4gPiA+ID4+Pj4gICAgICAgPC9iZ3A+DQo+ID4gPiA+Pj4+IA0K
PiA+ID4gPj4+PiAgICAgIDwvZGF0YT4NCj4gPiA+ID4+Pj4gDQo+ID4gPiA+Pj4+ICAgIDwvcnBj
LXJlcGx5Pg0KPiA+ID4gPj4+PiANCj4gPiA+ID4+Pj4gV2l0aCBSZWdhcmRzLA0KPiA+ID4gPj4+
PiANCj4gPiA+ID4+Pj4gUm9oaXQgUiBSYW5hZGUNCj4gPiA+ID4+Pj4gDQo+ID4gPiA+Pj4+IA0K
PiA+ID4gPj4+PiANCj4gPiA+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj4gPiA+ID4+Pj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4+
Pj4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+ID4gPj4+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zw
b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmDQo+ID4gPiA+Pj4+IC5vIA0KPiA+
ID4gPj4+PiByZ19tYWlsbWFuX2xpc3RpbmZvX25ldGNvbmYmZD1Ed0lEYVEmYz1IQWtZdWg2M3Jz
dWhyNlNjYmZoMFVqDQo+ID4gPiA+Pj4+IEJYIA0KPiA+ID4gPj4+PiBlTUstbmRiM3ZvRFRYY1d6
b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKDQo+ID4gPiA+Pj4+
IGRjIA0KPiA+ID4gPj4+PiBabyZtPUVoZmhTcm9scWs2UmlPYlRma0gzRk1jUl91djhqR0QtU1dU
b08zbXF4bzgmcz1QRkJsZU1yUXlCDQo+ID4gPiA+Pj4+IFdfIC04ZGRPVkN0S2ZqdGVJeFV6NTZR
ZjA4aGlRQnpRM0kmZT0NCj4gPiA+ID4gDQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+
ID4gPiA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m
cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcg0KPiA+ID4gPiBnXyANCj4g
PiA+ID4gbWFpbG1hbl9saXN0aW5mb19uZXRjb25mJmQ9RHdJRGFRJmM9SEFrWXVoNjNyc3VocjZT
Y2JmaDBVakJYZU1LLQ0KPiA+ID4gPiBuZCANCj4gPiA+ID4gYjN2b0RUWGNXem9DSSZyPTl6a1Aw
eG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1FaA0KPiA+ID4gPiBmaCAN
Cj4gPiA+ID4gU3JvbHFrNlJpT2JUZmtIM0ZNY1JfdXY4akdELVNXVG9PM21xeG84JnM9UEZCbGVN
clF5QldfLThkZE9WQ3RLZg0KPiA+ID4gPiBqdA0KPiA+ID4gPiBlSXhVejU2UWYwOGhpUUJ6UTNJ
JmU9DQo+ID4gPiANCj4gPiA+IE1haGVzaCBKZXRoYW5hbmRhbmkNCj4gPiA+IG1qZXRoYW5hbmRh
bmlAZ21haWwuY29tDQo+ID4gPiANCj4gPiANCj4gPiAtLSANCj4gPiBKdWVyZ2VuIFNjaG9lbndh
ZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiA+IFBob25l
OiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8
IEdlcm1hbnkNCj4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3Vy
bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5qYWNvYnMtMkR1
bml2ZXJzaXR5LmRlXyZkPUR3SURhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIz
dm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pv
Jm09RWhmaFNyb2xxazZSaU9iVGZrSDNGTWNSX3V2OGpHRC1TV1RvTzNtcXhvOCZzPVZaaDAtR2da
NkdwS25aaGRpMDltZXp6eVBBNjJXRUhVZDV3UFliVVZDSTQmZT0+DQo+ID4gDQo+ID4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBOZXRjb25mIG1h
aWxpbmcgbGlzdA0KPiA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBodHRwczovL3VybGRlZmVuc2Uu
cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYQ0KPiA+IGls
IA0KPiA+IG1hbl9saXN0aW5mb19uZXRjb25mJmQ9RHdJRGFRJmM9SEFrWXVoNjNyc3VocjZTY2Jm
aDBVakJYZU1LLW5kYjN2b0RUDQo+ID4gWGMgDQo+ID4gV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQ
b09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09RWhmaFNyb2xxazZSaU8NCj4gPiBiVCANCj4g
PiBma0gzRk1jUl91djhqR0QtU1dUb08zbXF4bzgmcz1QRkJsZU1yUXlCV18tOGRkT1ZDdEtmanRl
SXhVejU2UWYwOGhpUQ0KPiA+IEJ6DQo+ID4gUTNJJmU9DQo+IA0KPiAtLSANCj4gSnVlcmdlbiBT
Y2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4g
UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJl
bWVuIHwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczov
L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5qYWNvYnMt
MkR1bml2ZXJzaXR5LmRlXyZkPUR3SURhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1u
ZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpk
Y1pvJm09RWhmaFNyb2xxazZSaU9iVGZrSDNGTWNSX3V2OGpHRC1TV1RvTzNtcXhvOCZzPVZaaDAt
R2daNkdwS25aaGRpMDltZXp6eVBBNjJXRUhVZDV3UFliVVZDSTQmZT0+DQo+IA0KPiANCg0KLS0g
DQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1l
biBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwg
Mjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8
aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K


From nobody Thu Sep 27 20:25:52 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE0F130D7A for ; Thu, 27 Sep 2018 20:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.956
X-Spam-Level: 
X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfK8gn3RaFh0 for ; Thu, 27 Sep 2018 20:25:48 -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 79C4C12777C for ; Thu, 27 Sep 2018 20:25:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4744; q=dns/txt; s=iport; t=1538105148; x=1539314748; h=from:to:subject:date:message-id:mime-version; bh=xdWTDbJgsmsmNEYfuUXCWlcqmHCdMSJy9Hoe7x4ks6E=; b=lAjBrdF6GwmyrmDL+zpsoQ6NUYPBsMyKEYoReaoOP38GDHvYaNiYSWWY TBY7NM9Tb4u6NwdQ51lkbkqWAUYxHyrBtygiOW9uPBA9RTIzfrWhY2syC c9uzg2sDkRRUZzFMPAqJajswqjjx5JTlRcO2beaw+bHEPSmc1kbtHbxc3 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAAChnq1b/40NJK1bGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUYEXd2Z/MoNqiBWMM4FokTuFP4F6C4UFg3AhNBgBAwEBAgEBAm0?= =?us-ascii?q?dC4ViCl4BDD4CBDAnBIM0AYEdZKMmgS6Ed4Udin4XgUE/gTkME4IXgXaGPjG?= =?us-ascii?q?CJgKNc4V5iSoJApAsF48+lHcCERSBJR04J4EucBU7KgGCQoIwjiONJYEfAQE?=
X-IronPort-AV: E=Sophos;i="5.54,313,1534809600";  d="scan'208,217";a="458495493"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2018 03:25:47 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w8S3Pllg012146 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 28 Sep 2018 03:25:47 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Sep 2018 22:25:46 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Thu, 27 Sep 2018 22:25:46 -0500
From: "Reshad Rahman (rrahman)" 
To: "netconf@ietf.org" 
Thread-Topic: Section 3.5.3 of RFC8040
Thread-Index: AQHUVtryYV1t6t1lOUS+yyL8KN+brQ==
Date: Fri, 28 Sep 2018 03:25:46 +0000
Message-ID: <007EA2C8-2236-4C7E-98C7-0CF9B855487F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.249.158]
Content-Type: multipart/alternative; boundary="_000_007EA2C822364C7E98C70CF9B855487Fciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: 
Subject: [Netconf] Section 3.5.3 of RFC8040
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2018 03:25:50 -0000

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

SGksDQoNCkluIHRoZSBVUkkgYmVsb3csIG1heWJlIGJlY2F1c2UgaXTigJlzIGdldHRpbmcgbGF0
ZSBidXQgSSBpbml0aWFsbHkgdGhvdWdodCBpbnN0YW5jZS12YWx1ZSB3YXMgYWN0dWFsbHkgcGFy
dCBvZiB0aGUgVVJJLCB3aHkgd2FzbuKAmXQgPD4gdXNlZD8NCg0KRm9yIHRoZSBhYm92ZSBZQU5H
IGRlZmluaXRpb24sIGEgdGFyZ2V0IHJlc291cmNlIFVSSSBmb3IgbGVhZi1saXN0ICJZIiB3b3Vs
ZCBiZSBlbmNvZGVkIGFzIGZvbGxvd3M6DQovcmVzdGNvbmYvZGF0YS9leGFtcGxlLXRvcDp0b3Av
WT1pbnN0YW5jZS12YWx1ZQ0KDQpSZWdhcmRzLA0KUmVzaGFkLg0K

--_000_007EA2C822364C7E98C70CF9B855487Fciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <10C0DA3542033945BCDF99CD5007C2C2@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIFwoQm9keSBD
U1wpIjsNCglwYW5vc2UtMToyIDIgNiAzIDUgNCA1IDIgMyA0O30NCi8qIFN0eWxlIERlZmluaXRp
b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp
bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu
aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRp
b246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6
d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0K
Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy
LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2
LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i
MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi
IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs
YW5nPSJFTi1DQSIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkluIHRoZSBVUkkgYmVsb3cs
IG1heWJlIGJlY2F1c2UgaXTigJlzIGdldHRpbmcgbGF0ZSBidXQgSSBpbml0aWFsbHkgdGhvdWdo
dCBpbnN0YW5jZS12YWx1ZSB3YXMgYWN0dWFsbHkgcGFydCBvZiB0aGUgVVJJLCB3aHkgd2FzbuKA
mXQgJmx0OyZndDsgdXNlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gb3Ig
dGhlIGFib3ZlIFlBTkcgZGVmaW5pdGlvbiwgYSB0YXJnZXQgcmVzb3VyY2UgVVJJIGZvciBsZWFm
LWxpc3QgJnF1b3Q7WSZxdW90OyB3b3VsZCBiZSBlbmNvZGVkIGFzIGZvbGxvd3M6PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi9yZXN0Y29uZi9k
YXRhL2V4YW1wbGUtdG9wOnRvcC9ZPWluc3RhbmNlLXZhbHVlPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5S
ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIj5SZXNoYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jv
ZHk+DQo8L2h0bWw+DQo=

--_000_007EA2C822364C7E98C70CF9B855487Fciscocom_--


From nobody Thu Sep 27 20:40:36 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A75130DD3 for ; Thu, 27 Sep 2018 20:40: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 83VFvZQvr5CK for ; Thu, 27 Sep 2018 20:40:32 -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 4C6051271FF for ; Thu, 27 Sep 2018 20:40:32 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 83E92721ECD70 for ; Fri, 28 Sep 2018 04:40:28 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 28 Sep 2018 04:40:29 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0399.000; Fri, 28 Sep 2018 11:40:25 +0800
From: Qin Wu 
To: Andy Bierman , Martin Bjorklund 
CC: Netconf , "rrahman=40cisco.com@dmarc.ietf.org" 
Thread-Topic: [Netconf] SSE and HTTP/2 in restcon-notif
Thread-Index: AQHUVpLBkBpJSSIQbkWRq5O8cMUK2aUEE78AgAAMagCAAOrQgA==
Date: Fri, 28 Sep 2018 03:40:25 +0000
Message-ID: 
References:  <20180927.224854.1626742691261140238.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B055E63nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2018 03:40:35 -0000

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

DQo+ICAgIEkgZW52aXNpb24gdGhlIHZhcmlhdGlvbiBiZWluZyByZWxhdGl2ZWx5DQo+ICAgIG1p
bm9yLCBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmUgb2Y6DQo+DQo+ICAgICAgaWYgMS4xLCB0aGVu
IFNTRS4NCj4gICAgICBpZiAyLjAsIGNsaWVudCBNQVkgb3BlbiBhIHN0cmVhbSBmaXJzdC4NCj4N
Cj4gMykgcmVzb3VyY2UgVVJJcw0KPg0KPiAgICBUaGlzIGlzIGxpa2VseSB3aGVyZSB3ZSBuZWVk
IHRvIHNwZW5kIHRoZSBtb3N0IHRpbWUuIFdlIGtub3cgdGhhdA0KPiAgICBlc3RhYmxpc2gtc3Vi
c2NyaXB0aW9uIHJldHVybnMgYSBkeW5hbWljYWxseSBjcmVhdGVkIFVSSSwgY29tcGFyYWJsZQ0K
PiAgICB0byB3aGF0IGEgY2xpZW50IG1pZ2h0IGdldCBmcm9tIGlldGYtcmVzdGNvbmYtbW9uaXRv
cmluZzpyZXN0Y29uZi1zdGF0ZVwNCj4gICAgL3N0cmVhbXMvc3RyZWFtL2FjY2Vzcy9sb2NhdGlv
bi4NCg0KQnV0IGl0IGlzIG5vdCBxdWl0ZSBjb21wYXJhYmxlLiAgSW4gdGhlIDgwNDAgc29sdXRp
b24sIHRoZSBsb2NhdGlvbg0KdXJsIGlzIHN0YXRpYywgYW5kIHRoZW4gcXVlcnkgcGFyYW1ldGVy
cyBhcmUgcHJvdmlkZWQgYnkgdGhlIGNsaWVudA0KaW4gdGhlIFBPU1QgdG8gdGhlIFNTRSBsb2Nh
dGlvbi4gIFRodXMsIHRoZSBzZXJ2ZXIgY2FuIGZyZWUgYW55DQpyZXNvdXJjZXMgYXNzb2NpYXRl
ZCB3aXRoIHRoZSBmaWx0ZXIgd2hlbiB0aGUgY29ubmVjdGlvbiBpcw0KdGVybWluYXRlZC4NCg0K
DQpUaGUgUkVTVENPTkYgcHJvY2VkdXJlIHN0YXJ0cyB3aXRoIHRoZSBjbGllbnQNCmV4YW1pbmlu
ZyAvcmVzdGNvbmYtc3RhdGUvc3RyZWFtcyB0byBkZXRlcm1pbmUgc3RyZWFtIGFuZCBpdHMgbG9j
YXRpb24gVVJMDQpIb3cgZG9lcyB0aGlzIG1vbml0b3JpbmcgaW5mb3JtYXRpb24gcmVsYXRlIHRv
IHRoZSBuZXcgc29sdXRpb24/DQpJIGFzc3VtZSBib3RoIHRoZSBvbGQgYW5kIG5ldyBwcm9jZWR1
cmVzIGNhbiBiZSBzdXBwb3J0ZWQgYnkgdGhlIHNhbWUgc2VydmVyLg0KSXMgaXQganVzdCBpZ25v
cmVkIGZvciBhIG5ldyBzdWJzY3JpcHRpb24/DQoNClNpbmNlIGFsbCBTU0UgZGF0YSBpcyBhbHdh
eXMgbWVkaWEgdHlwZSB0ZXN0L2V2ZW50LXN0cmVhbSwgZWFjaCBzdHJlYW0gZW50cnkgaW5kaWNh
dGVzDQppdHMgc2Vjb25kYXJ5IGVuY29kaW5nIGZvcm1hdC4gVGhpcyBsZWFmIGlzIHR5cGUgc3Ry
aW5nLCBhbmQgb25seSAneG1sJyBhbmQgJ2pzb24nIGFyZSBzdXBwb3J0ZWQNCmluIFJGQyA4MDQw
LiBUaGUgZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiBSUEMgaGFzIGl0cyBvd24gbGVhZiBmb3IgdGhp
cyBwdXJwb3NlLg0KDQoNCltRaW5dOiBJIGFtIGxvc3QsIHNob3VsZCByZXNvdXJjZSBVUklzIHJl
dHVybmVkIGJ5IGVzdGFibGlzaC1zdWJzY3JpcHRpb24gc2FtZSBhcyBsb2NhdGlvbiBVUkwgb2J0
YWluZWQgZnJvbQ0KaWV0Zi1yZXN0Y29uZi1tb25pdG9yaW5nOnJlc3Rjb25mLXN0YXRlXC9zdHJl
YW1zL3N0cmVhbS9hY2Nlc3MvbG9jYXRpb24uDQpNeSB1bmRlcnN0YW5kaW5nIGlzIGlmIFNTRSBp
cyBzdXBwb3J0ZWQsIGxldOKAmXMgc2F5IEhUVFAgMS4xLCB3ZSB3aWxsIHVzZSBsb2NhdGlvbiBV
UkwgcmV0dXJuZWQgZnJvbQ0KaWV0Zi1yZXN0Y29uZi1tb25pdG9yaW5nOnJlc3Rjb25mLXN0YXRl
XC9zdHJlYW1zL3N0cmVhbS9hY2Nlc3MvbG9jYXRpb24NCmFzIGlucHV0IHBhcmFtZXRlciB0byB0
cmlnZ2VyIFNTRS4gSW4gY2FzZSBvZiBTU0UgYmVpbmcgc3VwcG9ydGVkLCBIVFRQIEdFVChVUkkp
IGlzIG5vdCBuZWVkZWQgPyB3cm9uZz8NCkJ1dCBpZiBTU0UgaXMgbm90IHN1cHBvcnRlZCwgbGV0
4oCZcyBzYXkgSFRUUC8yLCBsb2NhdGlvbiBVUkwgaXMgbm90IG5lZWRlZC4gSFRUUCBQT1NUKFVS
SSkgaXMgcmVxdWlyZWQuDQpQbGVhc2UgY29ycmVjdCBtZSwgaWYgSSBhbSB3cm9uZy4NCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp
dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls
U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN
Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt
IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm
dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl
ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jm5ic3A7ICZuYnNw
OyBJIGVudmlzaW9uIHRoZSB2YXJpYXRpb24gYmVpbmcgcmVsYXRpdmVseTxicj4NCiZndDsmbmJz
cDsgJm5ic3A7IG1pbm9yLCBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmUgb2Y6IDxicj4NCiZndDsg
PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IGlmIDEuMSwgdGhlbiBTU0UuPGJyPg0KJmd0
OyZuYnNwOyAmbmJzcDsgJm5ic3A7IGlmIDIuMCwgY2xpZW50IE1BWSBvcGVuIGEgc3RyZWFtIGZp
cnN0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAzKSByZXNvdXJjZSBVUklzPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7Jm5ic3A7ICZuYnNwOyBUaGlzIGlzIGxpa2VseSB3aGVyZSB3ZSBuZWVkIHRvIHNwZW5k
IHRoZSBtb3N0IHRpbWUuIFdlIGtub3cgdGhhdCA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBlc3Rh
Ymxpc2gtc3Vic2NyaXB0aW9uIHJldHVybnMgYSBkeW5hbWljYWxseSBjcmVhdGVkIFVSSSwgY29t
cGFyYWJsZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHRvIHdoYXQgYSBjbGllbnQgbWlnaHQgZ2V0
IGZyb20gaWV0Zi1yZXN0Y29uZi1tb25pdG9yaW5nOnJlc3Rjb25mLXN0YXRlXDxicj4NCiZndDsm
bmJzcDsgJm5ic3A7IC9zdHJlYW1zL3N0cmVhbS9hY2Nlc3MvbG9jYXRpb24uPGJyPg0KPGJyPg0K
QnV0IGl0IGlzIG5vdCBxdWl0ZSBjb21wYXJhYmxlLiZuYnNwOyBJbiB0aGUgODA0MCBzb2x1dGlv
biwgdGhlIGxvY2F0aW9uPGJyPg0KdXJsIGlzIHN0YXRpYywgYW5kIHRoZW4gcXVlcnkgcGFyYW1l
dGVycyBhcmUgcHJvdmlkZWQgYnkgdGhlIGNsaWVudDxicj4NCmluIHRoZSBQT1NUIHRvIHRoZSBT
U0UgbG9jYXRpb24uJm5ic3A7IFRodXMsIHRoZSBzZXJ2ZXIgY2FuIGZyZWUgYW55PGJyPg0KcmVz
b3VyY2VzIGFzc29jaWF0ZWQgd2l0aCB0aGUgZmlsdGVyIHdoZW4gdGhlIGNvbm5lY3Rpb24gaXM8
YnI+DQp0ZXJtaW5hdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgUkVTVENPTkYg
cHJvY2VkdXJlIHN0YXJ0cyB3aXRoIHRoZSBjbGllbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ZXhh
bWluaW5nIC9yZXN0Y29uZi1zdGF0ZS9zdHJlYW1zIHRvIGRldGVybWluZSBzdHJlYW0gYW5kIGl0
cyBsb2NhdGlvbiBVUkw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SG93IGRvZXMgdGhpcyBtb25pdG9y
aW5nIGluZm9ybWF0aW9uIHJlbGF0ZSB0byB0aGUgbmV3IHNvbHV0aW9uPzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIj5JIGFzc3VtZSBib3RoIHRoZSBvbGQgYW5kIG5ldyBwcm9jZWR1cmVzIGNhbiBiZSBz
dXBwb3J0ZWQgYnkgdGhlIHNhbWUgc2VydmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JcyBpdCBq
dXN0IGlnbm9yZWQgZm9yIGEgbmV3IHN1YnNjcmlwdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNpbmNlIGFsbCBTU0UgZGF0YSBpcyBhbHdheXMg
bWVkaWEgdHlwZSB0ZXN0L2V2ZW50LXN0cmVhbSwgZWFjaCBzdHJlYW0gZW50cnkgaW5kaWNhdGVz
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPml0cyBzZWNvbmRhcnkgZW5jb2RpbmcgZm9ybWF0LiBUaGlz
IGxlYWYgaXMgdHlwZSBzdHJpbmcsIGFuZCBvbmx5ICd4bWwnIGFuZCAnanNvbicgYXJlIHN1cHBv
cnRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5pbiBSRkMgODA0MC4gVGhlIGVzdGFibGlzaC1zdWJz
Y3JpcHRpb24gUlBDIGhhcyBpdHMgb3duIGxlYWYgZm9yIHRoaXMgcHVycG9zZS48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5bUWluXTogSSBhbSBsb3N0LCBzaG91bGQgcmVzb3VyY2UgVVJJ
cyByZXR1cm5lZCBieSBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIHNhbWUgYXMgbG9jYXRpb24gVVJM
IG9idGFpbmVkIGZyb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PmlldGYtcmVzdGNvbmYtbW9uaXRvcmluZzpyZXN0Y29uZi1zdGF0ZVwvc3RyZWFtcy9zdHJlYW0v
YWNjZXNzL2xvY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+TXkgdW5kZXJzdGFuZGluZyBpcyBpZiBTU0UgaXMgc3VwcG9ydGVkLCBsZXTigJlzIHNheSBI
VFRQIDEuMSwgd2Ugd2lsbCB1c2UgbG9jYXRpb24gVVJMIHJldHVybmVkIGZyb20NCjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+aWV0Zi1yZXN0Y29uZi1tb25pdG9y
aW5nOnJlc3Rjb25mLXN0YXRlXC9zdHJlYW1zL3N0cmVhbS9hY2Nlc3MvbG9jYXRpb248bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFzIGlucHV0IHBhcmFtZXRlciB0
byB0cmlnZ2VyIFNTRS4gSW4gY2FzZSBvZiBTU0UgYmVpbmcgc3VwcG9ydGVkLCBIVFRQIEdFVChV
UkkpIGlzIG5vdCBuZWVkZWQgPyB3cm9uZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkJ1dCBpZiBTU0UgaXMgbm90IHN1cHBvcnRlZCwgbGV04oCZcyBzYXkgSFRU
UC8yLCBsb2NhdGlvbiBVUkwgaXMgbm90IG5lZWRlZC4gSFRUUCBQT1NUKFVSSSkgaXMgcmVxdWly
ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2UgY29y
cmVjdCBtZSwgaWYgSSBhbSB3cm9uZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_B8F9A780D330094D99AF023C5877DABA9B055E63nkgeml513mbxchi_--


From nobody Fri Sep 28 10:20:41 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495E2130E3C; Fri, 28 Sep 2018 10:20:40 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qACqJ-N0n55c; Fri, 28 Sep 2018 10:20:36 -0700 (PDT)
Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 C8853127148; Fri, 28 Sep 2018 10:20:36 -0700 (PDT)
Received: by mail-pf1-x442.google.com with SMTP id a23-v6so4735088pfi.12; Fri, 28 Sep 2018 10:20:36 -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=LyNdt7AFediRQHmWbYcgjttXb8FRkR4fAYBa9ro37JM=; b=vCtXoQQuzE5ZGshwaVcLK4IZ9dwI6jWcPUPaPEOHjARf1wetz8upT/FaeoqlTPDjxP 0pUJdRV1pIHe197S6xoT+zfZrZgJ8fWH2X8OYnX/iiqtfbRZpY6JEg/LxN0iQtvPMb3G iJ6izzyXSWVetKPEwNs7Vgkm7FJCjd7aOO4uUB+fvxrqqvIC14v/CfzNadScDTjQJsv3 eAJDYdbhpTJwddGXo9EH6HIizk7vPxHsZ98+t+f27zS9J4wA8vmbdton2sFVoD7673tA KlGxYXtr9rdnlM2HVi1UN5HTtnxOstqCvPPLidHTW7Jjs+/aC29YsDJkig8Sulal06qD wDHA==
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=LyNdt7AFediRQHmWbYcgjttXb8FRkR4fAYBa9ro37JM=; b=AD4wU9TDLteY/o3Z2++6YIfuj5M52q/wPc1X2uBQZxSvW11d61CIgnEvAcMXa3tL87 v+DVsazkZYnPKmWLG5/04TbhJNFBAfxcDYLz8u/0MRgbgpqEhe9DwUMm2I0S1i5L6Qvx UlnT8Bc33h2JQP2QE/pwYTTN8ZJS1VjUed/EI2B1q7XtSFw7cziYjHfaMBpBmoRumY6t 3l0FkmtciWHkfwz1C4SxcJMnVj7kuoOtC9Q4TKkYTBAZ4a6Gyi7/6ChDbbUyHan/rAec aSTUF5wa/kRooZ99SyUH8vnZSKkGIQNv3whvtCSnqE4cXGEhP/wymYdFjCwCIvWvw6vZ Gugw==
X-Gm-Message-State: ABuFfojhVY0EBizRPbZ7QcEXBiLVz0IdJeztoorFULFDbwTYRR3829YS 63+2B5Y5vW9tF5phix+S3IQ=
X-Google-Smtp-Source: ACcGV63dw9xNPIh+RMhnH4tiHMPOQnls2N3WaoU68xquY+DGcJuMEhUz7w4155B2ipe3sAqkVsW5ng==
X-Received: by 2002:a17:902:830b:: with SMTP id bd11-v6mr17186213plb.249.1538155236098;  Fri, 28 Sep 2018 10:20:36 -0700 (PDT)
Received: from [10.52.174.170] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id v2-v6sm8226600pgf.58.2018.09.28.10.20.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 10:20:35 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mahesh Jethanandani 
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BC4DC52@dggeml510-mbx.china.huawei.com>
Date: Fri, 28 Sep 2018 10:20:33 -0700
Cc: Netconf , "draft-ietf-netconf-nmda-netconf@ietf.org" ,  Kent Watsen 
Content-Transfer-Encoding: quoted-printable
Message-Id: <5697D7E2-F4E8-4A3E-8E9B-E1B1C73B122B@gmail.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB4569@dggeml510-mbx.china.huawei.com>  <20180604.121748.1873023460220711310.mbj@tail-f.com> <224028b2-59c5-6859-0e2a-331ed48121ec@cisco.com>  <20180613102721.tnqufeommaojdwm2@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BBBD928@dggeml510-mbx.china.huawei.com> <20180613120742.7xfgwy66jq6qxsmf@anna.jacobs.jacobs-university.de> <8AEB4F37-A148-428F-A5C0-1AB836F0733E@juniper.net> <991B70D8B4112A4699D5C00DDBBF878A6BBC062A@dggeml510-mbx.china.huawei.com> <20180625080714.kg2h66mxc7kpgtgs@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BC4DC52@dggeml510-mbx.china.huawei.com>
To: Rohit R Ranade 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2018 17:20:40 -0000

Hi Rohit,

I believe we were past LC and into the IESG queue by the time consensus =
was reached here. Therefore, we had held off making the changes, and =
make them as part of IESG review. That time would be now.

There was consensus on the change in text in Section 3.1.1, in the =
description statements in the model, and a request by chairs to upload =
the changes to GitHub. On the example, there was consensus, after it was =
fixed for namespace, but there was an open question of where to place =
the example. I had suggested Appendix, but I am open to anywhere else. =
Can we get agreement on it?

Thanks.

> On Sep 27, 2018, at 8:01 PM, Rohit R Ranade  =
wrote:
>=20
> Hi All,
>=20
> Can we add the below change to the ietf-netconf-nmda-netconf draft ?=20=

>=20
> With Regards,
> Rohit R Ranade
>=20
> -----Original Message-----
> From: Juergen Schoenwaelder =
[mailto:j.schoenwaelder@jacobs-university.de]=20
> Sent: 25 June 2018 13:37
> To: Rohit R Ranade 
> Cc: Kent Watsen ; Mahesh Jethanandani =
; Netconf ; =
draft-ietf-netconf-nmda-netconf@ietf.org
> Subject: Re: [Netconf] Editorial change-2 for =
draft-ietf-netconf-nmda-netconf
>=20
> This seems to be correct as far as I can tell. I am not sure what =
exactly the changes are (i.e., where this is supposed to go) and I think =
the document shephered should probably coordinate this as we are now =
moving to IETF last call (once the details have been worked out, we =
could for example treat this as IETF last call comment).
>=20
> /js
>=20
> On Tue, Jun 19, 2018 at 05:25:37AM +0000, Rohit R Ranade wrote:
>> I agree with Juergen's comments. Only exception is that "intended" =
for " negated-origin-filter" will be qualified by the ietf-origin =
namespace.
>> Please find the updated example.
>>=20
>>   >        xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>     >               xmlns:ds=3D"urn:ietf:params:xml:ns:yang:ietf-datastores"
>>               xmlns:or=3D"urn:ietf:params:xml:ns:yang:ietf-origin">
>>       ds:running
>>       
>>         
>>      
>>       or:intended
>>       
>>     
>>   
>>=20
>>   >        xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>     
>>      >          xmlns:or=3D"urn:ietf:params:xml:ns:yang:ietf-origin"
>>          or:origin=3D"or:intended">
>>       
>>         2001:db8::2:3
>>         64501
>>         64502
>>         60794
>>         179
>>         established
>>       
>>      
>>     
>>   
>>=20
>>=20
>> With Regards,
>> Rohit R Ranade
>>=20
>> -----Original Message-----
>> From: Kent Watsen [mailto:kwatsen@juniper.net]
>> Sent: 19 June 2018 03:43
>> To: Juergen Schoenwaelder ;=20
>> Rohit R Ranade 
>> Cc: Mahesh Jethanandani ; Netconf=20
>> ; draft-ietf-netconf-nmda-netconf@ietf.org
>> Subject: Re: [Netconf] Editorial change-2 for=20
>> draft-ietf-netconf-nmda-netconf
>>=20
>> Let's conclude this thread and push an update (or updatres) to =
GitHub, so the update doesn't get lost as we head into the IESG LC.
>>=20
>> Two items:
>>  - "origin-filter" parameter
>>  -  usage example
>>=20
>> Kent and Mahesh
>>=20
>>=20
>> =3D=3D=3D=3D=3D original message =3D=3D=3D=3D=3D
>>=20
>> Yes, for bgp there is no namespace defined in the example in RFC =
8342. Using ietf-netconf-nmda clearly is misleading, a fictional example =
namespace will be better.
>>=20
>> I think the lexical representation of the value 'intended' requires =
to be namespace qualified, i.e. 'ds:intended'.
>>=20
>> The with-origin is defined to be of type empty - there is no 'true'
>> value or something like that, its just .
>>=20
>> /js
>>=20
>> On Wed, Jun 13, 2018 at 11:20:21AM +0000, Rohit R Ranade wrote:
>>> Hi Juergen,
>>>=20
>>> Can you please identify the namespaces which are not OK so that we =
can fix them.=20
>>> For want of a namespace for "bgp", I re-used the ietf-netconf-nmda =
namespace as it is just an example. We can use the =
"https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__example.com_ns_exam=
ple&d=3DDwIDaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xn=
JUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DEhfhSrolqk6RiObTfkH3FMcR_uv8jGD-S=
WToO3mqxo8&s=3Dtm-DrFSVrRkMzAH-DiWECrNBbWhSmbKnBauKdzx3J-k&e=3D" =
namespace instead.
>>>=20
>>> With Regards,
>>> Rohit R Ranade
>>>=20
>>> -----Original Message-----
>>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen=20=

>>> Schoenwaelder
>>> Sent: 13 June 2018 15:57
>>> To: Mahesh Jethanandani 
>>> Cc: Netconf ;
>>> draft-ietf-netconf-nmda-netconf@ietf.org
>>> Subject: Re: [Netconf] Editorial change-2 for=20
>>> draft-ietf-netconf-nmda-netconf
>>>=20
>>> I am not sure an example is needed but if we include one, we need =
one which is correct. I think the namespaces are a bit messed up in =
Rohit's example.
>>>=20
>>> /js
>>>=20
>>> On Tue, Jun 12, 2018 at 08:36:47AM -0400, Mahesh Jethanandani wrote:
>>>> Have the authors agreed on the final set of edits for this =
document? How about the example that Rohit mentioned in the original =
e-mail?
>>>>=20
>>>>> On Jun 4, 2018, at 7:01 AM, Robert Wilton  =
wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 04/06/2018 11:17, Martin Bjorklund wrote:
>>>>>> Hi
>>>>>>=20
>>>>>> Two comments inline.
>>>>>>=20
>>>>>> Robert Wilton  wrote:
>>>>>>> Hi Rohit, authors,
>>>>>>>=20
>>>>>>> I think that these are valid clarifications. I've reworded=20
>>>>>>> them slightly, and moved the ancestor node text to the YANG=20
>>>>>>> module instead.  I also think that the ancestor node text=20
>>>>>>> generically covers the config filter clarification that you =
raised previously.
>>>>>>>=20
>>>>>>> Hence, I propose the following diff to the NETCONF NMDA draft:
>>>>>>>=20
>>>>>>> rwilton@rwilton-lnx:~/netconf-wg/netconf-nmda$ git diff=20
>>>>>>> --staged diff --git a/ietf-netconf-nmda.yang=20
>>>>>>> b/ietf-netconf-nmda.yang index f2929b9..72a674a 100644
>>>>>>> --- a/ietf-netconf-nmda.yang
>>>>>>> +++ b/ietf-netconf-nmda.yang
>>>>>>> @@ -105,6 +105,9 @@ module ietf-netconf-nmda {
>>>>>>>        by get-data must satisfy all filters, i.e., the filter
>>>>>>>        criteria are logically ANDed.
>>>>>>>=20
>>>>>>> +       Any ancestor nodes (including list keys) of nodes =
matched by
>>>>>>> +       the filter are included in the response.
>>>>>>> +
>>>>>>>        The 'with-origin' parameter is only valid for an =
operational
>>>>>>>        datastore. If 'with-origin' is used with an invalid =
datastore,
>>>>>>>        then the server MUST return an  element=20
>>>>>>> with an @@ -193,7 +196,7 @@ module ietf-netconf-nmda {
>>>>>>>           description
>>>>>>>             "Filter based on the 'origin' annotation.  A node =
matches
>>>>>>>              the filter if its 'origin' annotation is not =
derived
>>>>>>> -             from and not equal to all of the given filter =
values.";
>>>>>>> +             from and not equal to any of the given filter=20
>>>>>>> + values.";
>>>>>>>         }
>>>>>>>       }
>>>>>>>=20
>>>>>>> diff --git a/nmda-netconf.org b/nmda-netconf.org index
>>>>>>> e44e2c7..100e173 100644
>>>>>>> --- a/nmda-netconf.org
>>>>>>> +++ b/nmda-netconf.org
>>>>>>> @@ -129,14 +129,17 @@ The "config-filter" parameter can be=20
>>>>>>> used to retrieve only "config  true" or "config false" nodes.
>>>>>>>=20
>>>>>>> The "origin-filter" parameter, which can be present multiple=20
>>>>>>> times, -selects nodes matching any of the given values. The=20
>>>>>>> -"negated-origin-filter", which can be present multiple times,=20=

>>>>>>> selects -nodes that do not match all given values. The =
"origin-filter"
>>>>>>> -and "negated-origin-filter" parameters cannot be used together.
>>>>>>> +selects nodes with origins matching, or derived from, any of=20
>>>>>>> +the
>>>>>>> given
>>>>>> I would prefer:
>>>>>>=20
>>>>>> selects nodes with origins equal to, or derived from, any of=20
>>>>>> the given
>>>>>>=20
>>>>>>=20
>>>>>> IMO, the term "match" in the original text means "equal to or=20
>>>>>> derived-from", as explained in the data model.
>>>>>>=20
>>>>>> The term "match" is problematic unless it is explained, b/c=20
>>>>>> some people will think it means "equal to".  (Noone will think=20
>>>>>> that "matches the regular expression" means "equal to the=20
>>>>>> regular expression" though...)
>>>>>>=20
>>>>>> Conclusion: always avoid the term "match".
>>>>> OK.
>>>>>=20
>>>>>>=20
>>>>>>> +values. The "negated-origin-filter", which can be present=20
>>>>>>> +multiple times, selects nodes with origins that do not match,=20=

>>>>>>> +and are not derived from, any of the given values. The=20
>>>>>>> +"origin-filter" and "negated-origin-filter" parameters cannot =
be used together.
>>>>>>>=20
>>>>>>> The "max-depth" parameter can be used by the client to limit=20
>>>>>>> the number of sub-tree levels that are returned in the reply.
>>>>>>>=20
>>>>>>> Note to the authors, for the negative-origin-filter, I've also=20=

>>>>>>> changed "all" to "any" (which changes the semantics, but I=20
>>>>>>> think it was wrong before).
>>>>>> Agree that "any" is correct.
>>>>>>=20
>>>>>> But does it really change the semantics?  "all" sounds quite=20
>>>>>> odd, but isn't the end result the same?
>>>>> I think that it is confusing, and probably depends on how you read =
it.
>>>>>=20
>>>>> But, if you are OK with "any" then I think that reads better and =
is more intuitive.
>>>>>=20
>>>>> Thanks,
>>>>> Rob
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> /martin
>>>>>>=20
>>>>>>=20
>>>>>>> Similar updates will need to also be done to RESTCONF, but=20
>>>>>>> let's agree the NETCONF text first.
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>> Rob
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 01/06/2018 10:10, Rohit R Ranade wrote:
>>>>>>>> Hi All,
>>>>>>>>=20
>>>>>>>> Section 3.1.1
>>>>>>>>=20
>>>>>>>> OLD:
>>>>>>>>=20
>>>>>>>>   The "origin-filter" parameter, which can be present=20
>>>>>>>> multiple times,
>>>>>>>>=20
>>>>>>>>   selects nodes matching any of the given values.  The
>>>>>>>>=20
>>>>>>>> "negated-origin-filter", which can be present multiple times,=20=

>>>>>>>> selects
>>>>>>>>=20
>>>>>>>>   nodes that do not match all given values.
>>>>>>>>=20
>>>>>>>> NEW:
>>>>>>>>=20
>>>>>>>> The "origin-filter" parameter, which can be present multiple=20
>>>>>>>> times,
>>>>>>>>=20
>>>>>>>>   selects nodes which are derived from or matching any of=20
>>>>>>>> the given values.  The
>>>>>>>>=20
>>>>>>>> "negated-origin-filter", which can be present multiple times,=20=

>>>>>>>> selects
>>>>>>>>=20
>>>>>>>>   nodes which are not derived from and do not match all given =
values.
>>>>>>>>=20
>>>>>>>> When a data-node matching the filter is selected, the=20
>>>>>>>> configuration ancestors
>>>>>>>>=20
>>>>>>>> (if any) and list key leafs (if any), even if they do not=20
>>>>>>>> match the filter, are also returned.
>>>>>>>>=20
>>>>>>>> Consider two origins such as =E2=80=9Clearned=E2=80=9D and =
=E2=80=9Cderived-from-learned=E2=80=9D.
>>>>>>>>=20
>>>>>>>> =E2=80=9Cderived-from-learned=E2=80=9D is derived from learned =
origin.
>>>>>>>>=20
>>>>>>>> Using the origin filters it is not possible to get nodes=20
>>>>>>>> belonging to =E2=80=9Clearned=E2=80=9D
>>>>>>>>=20
>>>>>>>> only as the nodes of derived origin are automatically selected.
>>>>>>>>=20
>>>>>>>> Notes:
>>>>>>>>=20
>>>>>>>> The text in 3.1.1 did not include the =E2=80=9Cderived-from=E2=80=
=9D logic=20
>>>>>>>> for selection , while in the data-model definition it was =
present.
>>>>>>>>=20
>>>>>>>> We can also add clarification about the ancestor and key=20
>>>>>>>> being output, even if though they do match the filter, since=20
>>>>>>>> the leaf
>>>>>>>>=20
>>>>>>>> matches the filter.
>>>>>>>>=20
>>>>>>>> Example : We can use the RFC 8342 Appendix C.2 BGP Example
>>>>>>>>=20
>>>>>>>>   >>>>>>>=20
>>>>>>>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>>>>>=20
>>>>>>>>     >>>>>>>=20
>>>>>>>> xmlns:ds=3D"urn:ietf:params:xml:ns:yang:ietf-datastores">
>>>>>>>>=20
>>>>>>>> ds:running
>>>>>>>>=20
>>>>>>>> 
>>>>>>>>=20
>>>>>>>>         >>>>>>> xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"/>
>>>>>>>>=20
>>>>>>>>      
>>>>>>>>=20
>>>>>>>> intended
>>>>>>>>=20
>>>>>>>> true
>>>>>>>>=20
>>>>>>>>     
>>>>>>>>=20
>>>>>>>> 
>>>>>>>>=20
>>>>>>>>   >>>>>>>=20
>>>>>>>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>>>>>=20
>>>>>>>>     >>>>>>> xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
>>>>>>>>=20
>>>>>>>>      >>>>>>>=20
>>>>>>>> or:origin=3D"or:intended">
>>>>>>>>=20
>>>>>>>>       
>>>>>>>>=20
>>>>>>>> 2001:db8::2:3
>>>>>>>>=20
>>>>>>>>         64501
>>>>>>>>=20
>>>>>>>>         64502
>>>>>>>>=20
>>>>>>>>         60794
>>>>>>>>=20
>>>>>>>>         >>>>>>> or:origin=3D"or:default">179
>>>>>>>>=20
>>>>>>>> established
>>>>>>>>=20
>>>>>>>>       
>>>>>>>>=20
>>>>>>>>      
>>>>>>>>=20
>>>>>>>>     
>>>>>>>>=20
>>>>>>>>   
>>>>>>>>=20
>>>>>>>> With Regards,
>>>>>>>>=20
>>>>>>>> Rohit R Ranade
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> Netconf mailing list
>>>>>>>> Netconf@ietf.org
>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf
>>>>>>>> .o=20
>>>>>>>> rg_mailman_listinfo_netconf&d=3DDwIDaQ&c=3DHAkYuh63rsuhr6Scbfh0Uj=

>>>>>>>> BX=20
>>>>>>>> eMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJ
>>>>>>>> dc=20
>>>>>>>> Zo&m=3DEhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=3DPFBleMrQyB=

>>>>>>>> W_ -8ddOVCtKfjteIxUz56Qf08hiQBzQ3I&e=3D
>>>>>=20
>>>>> _______________________________________________
>>>>> Netconf mailing list
>>>>> Netconf@ietf.org
>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.or
>>>>> g_=20
>>>>> mailman_listinfo_netconf&d=3DDwIDaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-=

>>>>> nd=20
>>>>> b3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DEh=

>>>>> fh=20
>>>>> Srolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=3DPFBleMrQyBW_-8ddOVCtKf
>>>>> jt
>>>>> eIxUz56Qf08hiQBzQ3I&e=3D
>>>>=20
>>>> Mahesh Jethanandani
>>>> mjethanandani@gmail.com
>>>>=20
>>>=20
>>> --=20
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>>> Fax:   +49 421 200 3103         =

>>>=20
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma=

>>> il=20
>>> man_listinfo_netconf&d=3DDwIDaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3vo=
DT
>>> Xc=20
>>> WzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DEhfhSrolqk6R=
iO
>>> bT=20
>>> fkH3FMcR_uv8jGD-SWToO3mqxo8&s=3DPFBleMrQyBW_-8ddOVCtKfjteIxUz56Qf08hiQ=

>>> Bz
>>> Q3I&e=3D
>>=20
>> --=20
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>> Fax:   +49 421 200 3103         =

>>=20
>>=20
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Fri Sep 28 13:45:05 2018
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 CDC58127B92; Fri, 28 Sep 2018 13:45:02 -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.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <153816750274.27098.7178343205573160826@ietfa.amsl.com>
Date: Fri, 28 Sep 2018 13:45:02 -0700
Archived-At: 
Subject: [Netconf] I-D Action: draft-ietf-netconf-subscribed-notifications-17.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2018 20:45:03 -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           : Customized Subscriptions to a Publisher's Event Streams
        Authors         : Eric Voit
                          Alexander Clemm
                          Alberto Gonzalez Prieto
                          Einar Nilsen-Nygaard
                          Ambika Prasad Tripathy
	Filename        : draft-ietf-netconf-subscribed-notifications-17.txt
	Pages           : 77
	Date            : 2018-09-28

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-17
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-subscribed-notifications-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-subscribed-notifications-17


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

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


From nobody Fri Sep 28 14:06:55 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59D8127B92 for ; Fri, 28 Sep 2018 14:06:53 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAmCyXX0fLJG for ; Fri, 28 Sep 2018 14:06:52 -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 3A2C1127133 for ; Fri, 28 Sep 2018 14:06:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3929; q=dns/txt; s=iport; t=1538168811; x=1539378411; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UJuDnDjiZJvyi9LtwVHHyViVtnZ9L5xZiv+W9vfnVjs=; b=jC6cfZ3zQiFT8S/bpf7kHKrhafdKP69uQIYv7n6sg8BOPuV1E9pNNE73 rSaiKxu+kY8Oe1iBSzafqTEjbYHiHWe/fJ1jkV3OvfjlgDLdJuzDqgN1B l+SlwYWj+E0M8VglsoOz6/r3WwhetHAslNCyhCCov3Zhwlxuo9NkW/ogu 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAADtlq5b/5FdJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYIOZn8oCot/jDGCDZZWgXoLGA2EAUYCg3shNBgBAwE?= =?us-ascii?q?BAgEBAm0cDIU4AQEBAQMBATg0CQIMBAIBCA4DBAEBDhEQJwsdCAIEDgUIgxq?= =?us-ascii?q?CAQ+mEoQzB4VPBYp+F4FBP4QkgxsBAQIBAYc1Aog6lGMJAoZBiWUfgUeEWok?= =?us-ascii?q?niHeDD4h2AhEUgSUdOIFVcBU7gmyLFoU+b4p6K4EBgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,316,1534809600"; d="scan'208";a="456916572"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2018 21:06:48 +0000
Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w8SL6mWi017703 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Sep 2018 21:06:48 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 28 Sep 2018 17:06:47 -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.1395.000; Fri, 28 Sep 2018 17:06:47 -0400
From: "Eric Voit (evoit)" 
To: Kent Watsen 
CC: "netconf@ietf.org" , "Einar Nilsen-Nygaard (einarnn)" 
Thread-Topic: Last Call on subscribed-notifications-16
Thread-Index: AQHURXCTPStqdu9N8EO45sjCvX2XlaUEiGgAgAHF1kA=
Date: Fri, 28 Sep 2018 21:06:47 +0000
Message-ID: 
References: <7AC66C1A-9E8A-42C2-B577-0B129E67568D@juniper.net> 
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.234]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.147, xch-rtp-007.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: 
Subject: Re: [Netconf] Last Call on subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2018 21:06:54 -0000

Posted.    (Note that 5 YANG errors appear due to a long-outstanding bug wi=
thin yanglint.  Details on that bug below.)

I will post the NETCONF-Notif update which includes comments from the SN re=
view as soon as instance validations are done on the examples.

Eric


-----Original Message-----
From: Eric Voit (evoit)=20
Sent: Friday, January 19, 2018 4:58 PM
To: rkrejci@cesnet.cz
Subject: RE: FW: [Netconf] Updates to subscription drafts posted

Hi Radek,

When do you think a fix might be available?

Eric

> -----Original Message-----
> From: Benoit Claise (bclaise)
> Sent: Tuesday, January 9, 2018 2:32 AM
> To: Eric Voit (evoit) 
> Cc: Martin Bjorklund ; Einar Nilsen-Nygaard (einarnn)=20
> ; rkrejci@cesnet.cz; Benoit Claise (bclaise)=20
> 
> Subject: Re: FW: [Netconf] Updates to subscription drafts posted
>=20
> Including Radek for yanglint.
>=20
> Regards, B.
> > Hi Benoit,
> >
> > Attached is a YANG file showing a bug in yanglint.   The error is that
> yanglint reports "The leafref leaf is config but refers to a non-config l=
eaf".
> This occurs even though the leaf is marked "require-instance false".
> >
> > Note this error only appears when the leafref is defined within a group=
ing.
> It does not occur when the leafref is defined directly within a data node=
.
> >
> > Where do we get these issue addressed?   I suspect I can't upload a new
> subscribed-notifications draft without this being fixed.
> >
> > Eric
> >


> -----Original Message-----
> From: Netconf  On Behalf Of Kent Watsen
> Sent: Thursday, September 27, 2018 5:44 PM
> To: netconf@ietf.org
> Subject: Re: [Netconf] Last Call on subscribed-notifications-16
>=20
> This message successfully concludes the Last Call on subscribed-notificat=
ions
> started on Sep 5th. The draft received significant reviews from Tim, Mart=
in,
> and Andy, and received passing reviews from others.  Thank you all for th=
at.
>=20
> Authors, please be sure close any remaining active threads, and then post=
 a
> -17 for shepherd review.  Please also ensure that -17 passes all validati=
on tools
> (e.g., idnits, yang validators, instance document validators) and that th=
e tree
> diagrams are correct.
>=20
> Thanks,
> Kent (and Mahesh)
>=20
>=20
> -----Original Message-----
>=20
> This message starts a Last Call on draft-ietf-netconf-subscribed-notifica=
tions-16:
>=20
>   https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications=
-16
>=20
> This marks the second of the last calls on the yang push suite of drafts.
> As explained before, given the size and number of documents, the chairs
> decided to break the reviews up into pieces so as to get focus on each in=
 turn.
> We are choosing to go top-down, starting with yang-push and ending with t=
he
> "notif" drafts.  We plan to submit the drafts for publication when they a=
re
> ready as a collective.  The goal is to do all this prior to IETF 103.
>=20
> While it's always nice to receive messages of support, at this time, the =
question
> isn't so much if the working group supports the work than if the document=
 is
> ready to progress.  The chairs need to see reviews that indicate thorough=
 end-
> to-end reading of the text.  Of course, if there are any objections, thes=
e should
> be brought forward now as well.
>=20
> The current version (-16) of this draft was published on Aug 15th, about =
three
> weeks after IETF 102.  The datatracker page for the draft is here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notificati=
ons.
>=20
>=20
> Thanks,
> Kent (and Mahesh)
>=20
>=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Sat Sep 29 11:00:39 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4240130E3F for ; Sat, 29 Sep 2018 11:00: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, 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 pjdnBWhxFalJ for ; Sat, 29 Sep 2018 11:00:35 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741BE1286D9 for ; Sat, 29 Sep 2018 11:00:34 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id g89-v6so7153035lfl.5 for ; Sat, 29 Sep 2018 11:00:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iu7LwCCbv6Z2pt9L0PmYAYn0FCfKMnk6K+GOpxsq7Jw=; b=E4D5G2JuN23onqwQ3bk6TwuO8uh6N3YByTB3CyqutY3JUt3iqo95t78pBHKa7cKWun +Ev4CG7R98BWvHSDh6R8GBjOKlsMQfUU/T9eAqbHy8SKpK6+KlBAYRIxXgYPBCy/jkZU EHJNH68TDDU/AsnHIlhDKxIrug5WD85llNqqBZDJ5YygFqakhGhGZ6IKyO9Bkj0u6jnp vk532OieQUNPVA2nXUZUX29TwIe3RsEYAj+lu8o+h2dufukz7FuTWnMetCnL2jSzjdsx YAbgevFeK+RS6jcUHz2fuYeJKxrrTUjhK3bVzdpuDNs8Pfgl7Qi3+YphqrZhoiTtB1XR kfZA==
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=iu7LwCCbv6Z2pt9L0PmYAYn0FCfKMnk6K+GOpxsq7Jw=; b=bDUVtr7/FR5wlqT1t1X6xE5IJHF91NTyifA1YW/r+0XFgKTEXYECn7Zc+fo8Cmais7 1VceKeTuKNAZ7PWJhPZTUwVhtMRmoebHgwVkalUlkk7fKPeZ8D+/aqNAQeMbQAGP3ySU 4ERPc5b7XfS1fSKlZaQOe+JWkVTLBgGBY2Vj1LntCYmf9USWrxZ5ABdgjPLxNlaZ/1C0 9oxOKgGvrnyO9Joxucw4aR/LN8w1RkJgwuy4z8ipBbgharZTM1DmuasrOHSbz+oQlWkU agK0N9FU+zEAQ9SfoyX54CmKXzbctzMgUbADfoNFXSGEkHJZELXjAWzkU2tfFhq50cTg 03Sg==
X-Gm-Message-State: ABuFfogi5PTz32HBg9iuMovMMsF1I7xgbGVCCyR3MNgtaC2Qzyw9MpjC 9FfBRNw7wdb7kthEWejISw0Dyr1IjqY9coI7wWkTAg==
X-Google-Smtp-Source: ACcGV63+knxPjgz63t5+R8KgeCOb9djopc4NW2y5NmRU/wGVZ+SnfrNCIOoH/snBjjQvY+vdbULj6pMk7wyf4ZJDWb4=
X-Received: by 2002:a19:3bcf:: with SMTP id d76-v6mr1828319lfl.126.1538244032514;  Sat, 29 Sep 2018 11:00:32 -0700 (PDT)
MIME-Version: 1.0
References:  <20180927.224854.1626742691261140238.mbj@tail-f.com>  
In-Reply-To: 
From: Andy Bierman 
Date: Sat, 29 Sep 2018 11:00:20 -0700
Message-ID: 
To: Qin Wu 
Cc: Martin Bjorklund , Netconf , rrahman=40cisco.com@dmarc.ietf.org
Content-Type: multipart/alternative; boundary="00000000000022df540577065939"
Archived-At: 
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2018 18:00:38 -0000

--00000000000022df540577065939
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 27, 2018 at 8:40 PM Qin Wu  wrote:

>
>
> >    I envision the variation being relatively
> >    minor, something along the line of:
> >
> >      if 1.1, then SSE.
> >      if 2.0, client MAY open a stream first.
> >
> > 3) resource URIs
> >
> >    This is likely where we need to spend the most time. We know that
> >    establish-subscription returns a dynamically created URI, comparable
> >    to what a client might get from
> ietf-restconf-monitoring:restconf-state\
> >    /streams/stream/access/location.
>
> But it is not quite comparable.  In the 8040 solution, the location
> url is static, and then query parameters are provided by the client
> in the POST to the SSE location.  Thus, the server can free any
> resources associated with the filter when the connection is
> terminated.
>
>
>
>
>
> The RESTCONF procedure starts with the client
>
> examining /restconf-state/streams to determine stream and its location UR=
L
>
> How does this monitoring information relate to the new solution?
>
> I assume both the old and new procedures can be supported by the same
> server.
>
> Is it just ignored for a new subscription?
>
>
>
> Since all SSE data is always media type test/event-stream, each stream
> entry indicates
>
> its secondary encoding format. This leaf is type string, and only 'xml'
> and 'json' are supported
>
> in RFC 8040. The establish-subscription RPC has its own leaf for this
> purpose.
>
>
>
>
>
> [Qin]: I am lost, should resource URIs returned by establish-subscription
> same as location URL obtained from
>
> ietf-restconf-monitoring:restconf-state\/streams/stream/access/location.
>
> My understanding is if SSE is supported, let=E2=80=99s say HTTP 1.1, we w=
ill use
> location URL returned from
>
> ietf-restconf-monitoring:restconf-state\/streams/stream/access/location
>
> as input parameter to trigger SSE. In case of SSE being supported, HTTP
> GET(URI) is not needed ? wrong?
>
> But if SSE is not supported, let=E2=80=99s say HTTP/2, location URL is no=
t needed.
> HTTP POST(URI) is required.
>
> Please correct me, if I am wrong.
>
>
>


I think sec 3.2 Discovery says use a different /streams container
https://tools.ietf.org/html/draft-ietf-netconf-restconf-notif-07#section-3.=
2

There should be a sub-section added in sec. 3 about coexistence between
RFC 8040 notifications and this document. Obviously vendors need the option
of supporting both in the same server.

How do they interact, starting with the 2 different /streams data models.

It should also be clear in this draft that the "uri" leaf contents are
implementation-specific
and MAY be predictable by a client application. Query parameters MAY be
defined
for use with the GET operation on this uri.


Andy

--00000000000022df540577065939
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Sep 27, 2018 at 8:40 PM Qin Wu <bill.wu@huawei.com> wrote:

















=C2=A0






&g=
t;=C2=A0 =C2=A0 I envision the variation being relatively

>=C2=A0 =C2=A0 minor, something along the line of: 

> 

>=C2=A0 =C2=A0 =C2=A0 if 1.1, then SSE.

>=C2=A0 =C2=A0 =C2=A0 if 2.0, client MAY open a stream first.

> 

> 3) resource URIs

> 

>=C2=A0 =C2=A0 This is likely where we need to spend the most time. We k=
now that 

>=C2=A0 =C2=A0 establish-subscription returns a dynamically created URI,=
 comparable

>=C2=A0 =C2=A0 to what a client might get from ietf-restconf-monitoring:=
restconf-state\

>=C2=A0 =C2=A0 /streams/stream/access/location.



But it is not quite comparable.=C2=A0 In the 8040 solution, the location
url is static, and then query parameters are provided by the client

in the POST to the SSE location.=C2=A0 Thus, the server can free any

resources associated with the filter when the connection is

terminated.






=C2=A0






=C2=A0






The RESTCONF procedure starts w=
ith the client






examining /restconf-state/strea=
ms to determine stream and its location URL






How does this monitoring inform=
ation relate to the new solution?






I assume both the old and new p=
rocedures can be supported by the same server.






Is it just ignored for a new su=
bscription?






=C2=A0






Since all SSE data is always me=
dia type test/event-stream, each stream entry indicates






its secondary encoding format. =
This leaf is type string, and only 'xml' and 'json' are sup=
ported






in RFC 8040. The establish-subs=
cription RPC has its own leaf for this purpose.


=C2=A0=



=C2=A0=



[Qin]: I am lost, should re=
source URIs returned by establish-subscription same as location URL obtaine=
d from


ietf-restconf-monitoring:re=
stconf-state\/streams/stream/access/location.


My understanding is if SSE =
is supported, let=E2=80=99s say HTTP 1.1, we will use location URL returned=
 from



ietf-restconf-monitoring:re=
stconf-state\/streams/stream/access/location


as input parameter to trigg=
er SSE. In case of SSE being supported, HTTP GET(URI) is not needed ? wrong=
?


But if SSE is not supported=
, let=E2=80=99s say HTTP/2, location URL is not needed. HTTP POST(URI) is r=
equired.


Please correct me, if I am =
wrong.


=C2=A0


=
I think sec 3.2 Discovery says use a different /streams container
https://tools.ietf.org/html/draft-ietf-netconf-restconf-noti=
f-07#section-3.2

There should be a sub-section=
 added in sec. 3 about coexistence between
RFC 8040 notifications=
 and this document. Obviously vendors need the option
of supporti=
ng both in the same server.

How do they interact, =
starting with the 2 different /streams data models.

It should also be clear in this draft that the "uri" leaf conte=
nts are implementation-specific
and MAY be predictable by a clien=
t application. Query parameters MAY be defined
for use with the G=
ET operation on this uri.


Andy



=C2=A0
=


--00000000000022df540577065939--


From nobody Sun Sep 30 02:35:39 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CB5126DBF for ; Sun, 30 Sep 2018 02:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 0DH-FL9NtfCD for ; Sun, 30 Sep 2018 02:35:35 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13BA6130DF0 for ; Sun, 30 Sep 2018 02:35:35 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 49766731DF14F for ; Sun, 30 Sep 2018 10:35:29 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sun, 30 Sep 2018 10:35:31 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0399.000; Sun, 30 Sep 2018 17:35:26 +0800
From: Qin Wu 
To: Netconf 
Thread-Topic: I-D Action: draft-wu-netconf-restconf-factory-restore-02.txt
Thread-Index: AQHUTBXK9RQ3MUl1GEOIlzNCP3NiF6UIqOZg
Date: Sun, 30 Sep 2018 09:35:26 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Sep 2018 09:35:38 -0000

di0oMDIpIGhhcyBiZWVuIHBvc3RlZCB0byBhZGRyZXNzZWQgY29tbWVudHMgZGlzY3Vzc2lvbiBv
biB0aGUgbGlzdC4NClRoZSBkaWZmIGlzOg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91
cmwyPWRyYWZ0LXd1LW5ldGNvbmYtcmVzdGNvbmYtZmFjdG9yeS1yZXN0b3JlLTAyDQpZb3VyIHJl
dmlldyBhbmQgaW5wdXQgYXJlIHdlbGNvbWUuDQoNCi1RaW4NCi0tLS0t08q8/tStvP4tLS0tLQ0K
t6K8/sjLOiBJLUQtQW5ub3VuY2UgW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9y
Z10gtPqx7SBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCreiy83KsbzkOiAyMDE4xOo51MIxNMjV
IDE4OjI4DQrK1bz+yMs6IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0K1vfM4jogSS1EIEFjdGlvbjog
ZHJhZnQtd3UtbmV0Y29uZi1yZXN0Y29uZi1mYWN0b3J5LXJlc3RvcmUtMDIudHh0DQoNCg0KQSBO
ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt
RHJhZnRzIGRpcmVjdG9yaWVzLg0KDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogRmFjdG9y
eSBkZWZhdWx0IFNldHRpbmcgQ2FwYWJpbGl0eQ0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBR
aW4gV3UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgWWUgTml1DQoJRmlsZW5hbWUgICAgICAg
IDogZHJhZnQtd3UtbmV0Y29uZi1yZXN0Y29uZi1mYWN0b3J5LXJlc3RvcmUtMDIudHh0DQoJUGFn
ZXMgICAgICAgICAgIDogMTENCglEYXRlICAgICAgICAgICAgOiAyMDE4LTA5LTE0DQoNCkFic3Ry
YWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGNhcGFiaWxpdHkgYmFzZWQgZXh0ZW5zaW9u
IHRvIE5FVENPTkYgYW5kDQogICBSRVNUQ09ORiBwcm90b2NvbCB0aGF0IGFsbG93cyBhIGNsaWVu
dCB0byBjb25maWd1cmUgbmV3bHkgZGVwbG95ZWQNCiAgIGRldmljZXMgd2l0aCBqdXN0IGl0cyBw
cmVjb25maWd1cmVkIGluaXRpYWwgc3RhdGUgKGkuZS4sIGZhY3RvcnkNCiAgIGRlZmF1bHQgc2V0
dGluZ3MpIGR1cmluZyB6ZXJvIHRvdWNoIGJvb3RzdHJhcHBpbmcgcHJvY2VzcyBvciByZXNldA0K
ICAgdGhlIGRldmljZSB3aXRoIHRoZSBjb250ZW50IG9mIGZhY3RvcnkgZGVmYXVsdCBzZXR0aW5n
IGNvbmZpZ3VyYXRpb24uDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y
IHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13
dS1uZXRjb25mLXJlc3Rjb25mLWZhY3RvcnktcmVzdG9yZS8NCg0KVGhlcmUgYXJlIGFsc28gaHRt
bGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LXd1LW5ldGNvbmYtcmVzdGNvbmYtZmFjdG9yeS1yZXN0b3JlLTAyDQpodHRwczovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXd1LW5ldGNvbmYtcmVzdGNvbmYtZmFj
dG9yeS1yZXN0b3JlLTAyDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2
YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13dS1u
ZXRjb25mLXJlc3Rjb25mLWZhY3RvcnktcmVzdG9yZS0wMg0KDQoNClBsZWFzZSBub3RlIHRoYXQg
aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np
b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0
b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh
bm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj
dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yIGZ0cDovL2Z0cC5pZXRm
Lm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo=


From nobody Sun Sep 30 06:03:48 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC767130DF3 for ; Sun, 30 Sep 2018 06:03: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, 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 uUw4C4-IEbkD for ; Sun, 30 Sep 2018 06:03:43 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFB7130DD0 for ; Sun, 30 Sep 2018 06:03:43 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 825A927; Sun, 30 Sep 2018 15:03:41 +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 Fo14AtxEZ4w2; Sun, 30 Sep 2018 15:03:38 +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; Sun, 30 Sep 2018 15:03:41 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36A6120036; Sun, 30 Sep 2018 15:03:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 44pPmxc6t0_E; Sun, 30 Sep 2018 15:03:40 +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 "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id AA82820035; Sun, 30 Sep 2018 15:03:40 +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.1415.2; Sun, 30 Sep 2018 15:03:39 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 9CCA23000C07E5; Sun, 30 Sep 2018 15:03:39 +0200 (CEST)
Date: Sun, 30 Sep 2018 15:03:39 +0200
From: Juergen Schoenwaelder 
To: Qin Wu 
CC: Netconf 
Message-ID: <20180930130339.i5cvwi2y5xoyjlef@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Qin Wu , Netconf 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Sep 2018 13:03:47 -0000

On Sun, Sep 30, 2018 at 09:35:26AM +0000, Qin Wu wrote:
> v-(02) has been posted to addressed comments discussion on the list.
> The diff is:
> https://www.ietf.org/rfcdiff?url2=draft-wu-netconf-restconf-factory-restore-02
> Your review and input are welcome.
>

   This document introduces a new datastore resource named 'Factory
   default setting' that represents datastore with its preconfigured
   initial state.  This datastore resource is available using the
   following resource path:

This is backwards terminology wise. You introduce a new datastore and
then that datastore automatically maps to a RESTCONF resource, not the
other way round. You should not mix datastore definition and protocol
specifics like the RESTCONF resource path.

I am also not sure what exactly the factory-default datastore
contains. It sounds like simple static data but in reality many
devices do some probing of hardware to determine what the "factory
default" is, i.e., factory-default is not necessarily static.

Why do we need a capability identifier?

   i.e.,a new  XML element is added to the input for
   the  , operations.

I think this is wrong and not needed for get-data. And if NMDA is a
prerequisite for this, then we do not need to talk about get-config.

   For  operation, the server MUST reset the target
   datastore to factory default setting according to the value of this
   element and return  element in the NETCONF  messages
   in success case.

If you include a RESTCONF example, make sure it is correct.

Appendix A of RFC 8342 provides guidelines how to define new
datastores. Should they not be followed?

The text says factory-default but the YANG module and the RESTCONF
example define / use .

I do not understand the reset operation (nor I am convinced yet that
copy-config is the right thing necessarily):

    rpc reset {
      nacm:default-deny-all;
      description
        "Request to reset the device to factory default setting
         and make configuration update to take effect.
         A server SHOULD send an rpc reply to the client before
         reset the device.";
    }

What is 'make configuration update to take effect.' How are the
various datastores modified if I invoke 'reset'? How do copy-config
and reset relate to each other? Why is reset nacm:default-deny-all
while copy-config etc. are 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 Sun Sep 30 23:53:03 2018
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C02A130DD5; Sun, 30 Sep 2018 23:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Trhjpuo3ax1g; Sun, 30 Sep 2018 23:52:51 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D1951130934; Sun, 30 Sep 2018 23:52:50 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 32EAA1AE03DD; Mon,  1 Oct 2018 08:52:46 +0200 (CEST)
Date: Mon, 01 Oct 2018 08:52:45 +0200 (CEST)
Message-Id: <20181001.085245.2170268582776994010.mbj@tail-f.com>
To: alissa@cooperw.in
Cc: christer.holmberg@ericsson.com, gen-art@ietf.org, draft-ietf-netconf-nmda-netconf.all@ietf.org, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <0047A04B-A30D-464F-BFD3-545806F486AB@cooperw.in>
References: <153122128332.25153.10473559847025784058@ietfa.amsl.com> <20180716105513.5457wkuu4cb6gtdd@anna.jacobs.jacobs-university.de> <0047A04B-A30D-464F-BFD3-545806F486AB@cooperw.in>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] [Gen-art] Genart last call review of draft-ietf-netconf-nmda-netconf-06
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Oct 2018 06:52:53 -0000

Hi,

Alissa Cooper  wrote:
> Christer, thanks for your review. I have flagged your first comment in
> my No Objection ballot since it seems like a good point to clarify.
> 
> Alissa
> 
> > On Jul 16, 2018, at 6:55 AM, Juergen Schoenwaelder
> >  wrote:
> > 
> > On Tue, Jul 10, 2018 at 04:14:43AM -0700, Christer Holmberg wrote:
> >> 
> >> Minor issues:
> >> 
> >> Sometimes, when a draft updates an existing RFC, people ask whether
> >> implementations not implementing the draft are still compliant with
> >> the updated
> >> RFC. Based on discussions, the consensus seems to be that existing
> >> implementations are still compliant, and if one wants to mandate the
> >> new
> >> features a bis is needed. I would just like to confirm whether that
> >> applies
> >> also to this draft. If so, perhaps a note indicating that would be
> >> useful, in
> >> order to avoid discussions in future?
> > 
> > An existing NETCONF server not implementing NMDA is still compliant to
> > the RFC 6241. However, a NETCONF server implementing NMDA (RFC 8342)
> > has to implement this update to RFC 6241. Do you want to have this
> > stated more explicitly? (We will have the same for RESTCONF and the
> > NMDA update of RESTCONF.)

How about:

OLD:

   An NMDA-compliant NETCONF server MUST support the operational state
   datastore and it MUST implement at least revision 201X-XX-XX of the
   "ietf-yang-library" module defined in [I-D.ietf-netconf-rfc7895bis].

NEW:

   An NMDA-compliant NETCONF server MUST implement the module
   "ietf-netconf-nmda" defined in this document, MUST support the
   operational state datastore, and it MUST implement at least revision
   201X-XX-XX of the "ietf-yang-library" module defined in
   [I-D.ietf-netconf-rfc7895bis].



/martin




> > 
> >> Related to that, it would also be good to have an interoperability
> >> statement, saying that implementations that implement the draft will
> >> still work with implementations that do not.
> > 
> > This primarily concerns clients: They need to be able to fallback to
> > using  instead of  and  instead of
> >  if they communicate with a non NMDA NETCONF server. I am
> > not sure whether this is a "SHOULD be able to fallback" or a "MUST be
> > able to fallback".
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
> > 
> > _______________________________________________
> > Gen-art mailing list
> > Gen-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/gen-art
>