From nobody Wed Aug 5 15:13:32 2020 Return-Path: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1263A0522 for ; Wed, 5 Aug 2020 15:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CEMZ4Dc61wl for ; Wed, 5 Aug 2020 15:13:30 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06A533A0474 for ; Wed, 5 Aug 2020 15:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596665608; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=3dIe80nNVoQ+6mHALsKY2RKlagFzIwIGSTAZF19xAQI=; b=LWw64mPm/ntrPuJmoHFAFWgZWEjXmr0hSnXhz3w2v4fjinPDGQHMDvu09wvmNZOA SrahwCXRlJ8jNIUvcHOzfNBGhNbZlKb6dwh+FZZWJUY2c9d7ZCTfiQ2EYkpm0XDg0K8 Amq1CY8LoMVd8Sak/ibOzfFguBH3q32Xdw+tPIHU= From: Kent Watsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> Date: Wed, 5 Aug 2020 22:13:28 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.05-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Regarding 108 adoption hums X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 22:13:31 -0000 NETCONF WG, The Chairs & AD discussed the results of the various adoption hums = conducted during the 108 meeting. There is a sense that the results = didn=E2=80=99t adequately determine if the drafts should be adopted. In = particular, it wasn=E2=80=99t clear if the hums reflected a general = desire to solve the problem or support for the particular draft. As such, we=E2=80=99ve decided to send subsequent emails for each draft, = or set of drafts if appropriate, to solicit input on following = questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? NETCONF Chairs From nobody Wed Aug 5 15:14:06 2020 Return-Path: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381663A0528 for ; Wed, 5 Aug 2020 15:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WWLDhi2yQrP for ; Wed, 5 Aug 2020 15:14:03 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1AA3A0474 for ; Wed, 5 Aug 2020 15:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596665641; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=WaeUDPF+TXzJBq0ye+GW5Fzl/9qaLt0G3Cmv5Ze8+eU=; b=IXNimHqtSRXbGMjf6vEtM1rBEW/ZG9eKPKAdNaqtOIeP9mldayknvu0Hps7kcqcy Fkq1j7mV8FGuIcqCxVViwV2BviDrs1LvSfENkd4XMdBkBXlS50qvdRhJPwgwJh5EHii mxFcGFFckSoSWmZ1neBNCk+tEaCONwkCqP76ZMYw= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> Date: Wed, 5 Aug 2020 22:14:01 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.05-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 22:14:04 -0000 NETCONF WG, Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft: Title: UDP-based Transport for Configured Subscriptions Link: https://tools.ietf.org/html/draft-unyte-netconf-udp-notif Abstract: This document describes an UDP-based notification mechanism to collect data from networking devices. A shim header is proposed = to facilitate the streaming of data directly from line cards to a collector. The objective is to rely on a lightweight approach to allow for higher frequency and better transit performance compared = to already established notification mechanisms. In particular, please discuss adoption-suitability as it regards to the = following questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? PS: this message is itself not an adoption poll, but rather an attempt = to gauge interest/support for a potential future adoption poll. NETCONF Chairs From nobody Wed Aug 5 15:14:22 2020 Return-Path: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952673A0474 for ; Wed, 5 Aug 2020 15:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLLNirJ_JFs6 for ; Wed, 5 Aug 2020 15:14:19 -0700 (PDT) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4FC3A0522 for ; Wed, 5 Aug 2020 15:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596665658; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=/OnnG8dGFPebJFULsJI53Wn+LUY2/mEVfyEajUkLI6I=; b=Sb0ECt36NK0A1QbZ/PikZ3vI7uu1rBtrYgn1P6EStWh4/4YLer6NapKYqhHQ3pjv J7dnOC2r0C2xz77Pz0MFwNzzMTz51iZYT4TmMIwz5az9hB42h06S8cI4Kt43yboDSOx dZabHGcwjlOdd6nX+yxlzMsmuU1lk7pmk+3a6aLY= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_0CD24FA4-3F2D-4238-8A96-FC6898DC5C8E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> Date: Wed, 5 Aug 2020 22:14:18 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.05-54.240.48.110 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 22:14:21 -0000 --Apple-Mail=_0CD24FA4-3F2D-4238-8A96-FC6898DC5C8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NETCONF WG, Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft: Title: Subscription to Distributed Notifications Link: = https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif Abstract: This documents describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription = is still maintained at the route processor in a distributed = forwarding system. In particular, please discuss adoption-suitability as it regards to the = following questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? PS: this message is itself not an adoption poll, but rather an attempt = to gauge interest/support for a potential future adoption poll. NETCONF Chairs --Apple-Mail=_0CD24FA4-3F2D-4238-8A96-FC6898DC5C8E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii NETCONF WG,

Per the previous email sent moments = ago, the chairs would like to solicit input on the following = draft:

   Title: Subscription to Distributed = Notifications
  =  Link: https://tools.ietf.org/html/draft-unyte-netconf-distributed-not= if
  =  Abstract:

      This documents describes = extensions to the YANG notifications
      subscription to allow = metrics being published directly from
      processors on line cards = to target receivers, while subscription is
      still maintained at the = route processor in a distributed forwarding
      = system.


In particular, please = discuss adoption-suitability as it regards to the following = questions:

    1) is the problem important for the NETCONF WG = to solve?
    2) is the draft a suitable basis = for the work?


PS: this message = is itself not an adoption poll, but rather an attempt to gauge = interest/support for a potential future adoption poll.

NETCONF Chairs
= --Apple-Mail=_0CD24FA4-3F2D-4238-8A96-FC6898DC5C8E-- From nobody Wed Aug 5 15:17:41 2020 Return-Path: <01000173c0b384f3-c7f261da-cea4-480d-a696-38a436c43c16-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2C03A058F for ; Wed, 5 Aug 2020 15:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2b7z_RjFvrOZ for ; Wed, 5 Aug 2020 15:17:38 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7E33A052C for ; Wed, 5 Aug 2020 15:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596665857; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=CDRpI1nWI0NzHg7EwON9R2t/DL7EzYcXKkTfcrNIOAE=; b=hwPC4WouzX5hbhHGVHBNyHtlVcsCo/KDZfOQeJ5lGQVpEpQ1h8DLOwPoWZrZmrX9 VLne+q5ob0lU5r2BGjCsWYZ+3clIJdQr6+fQJhUL/swqWI9ZMTnSJjxLASk5OMjrjwY nxuL1pQG+9wF1xBKLek16olHxnHXmfzcsarVjqIc= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_C191AC41-72B3-41FB-B845-510816B4B2F3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000173c0b384f3-c7f261da-cea4-480d-a696-38a436c43c16-000000@us-east-1.amazonses.com> Date: Wed, 5 Aug 2020 22:17:37 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.05-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 22:17:40 -0000 --Apple-Mail=_C191AC41-72B3-41FB-B845-510816B4B2F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NETCONF WG, Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft: Title: Telemetry Data Export capability Link: = https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities Abstract: This document proposes a YANG module for telemetry data export capability which augments system Capabilities model and provides additional telemetry data export attributes associated with system capability for transport dependent capability negotiation. In particular, please discuss adoption-suitability as it regards to the = following questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? PS: this message is itself not an adoption poll, but rather an attempt = to gauge interest/support for a potential future adoption poll. NETCONF Chairs= --Apple-Mail=_C191AC41-72B3-41FB-B845-510816B4B2F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
NETCONF WG,

Per = the previous email sent moments ago, the chairs would like to solicit = input on the following draft:

  =  Title: Telemetry Data Export capability
   Link: https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities
  =  Abstract:

      This document proposes a = YANG module for telemetry data export
      capability which augments = system Capabilities model and provides
      additional telemetry data = export attributes associated with system
      capability for transport = dependent capability negotiation.


In particular, = please discuss adoption-suitability as it regards to the following = questions:

    1) is the = problem important for the NETCONF WG to solve?
  =   2) is the draft a suitable basis for the work?


PS: this message is itself not an adoption = poll, but rather an attempt to gauge interest/support for a potential = future adoption poll.

NETCONF = Chairs
= --Apple-Mail=_C191AC41-72B3-41FB-B845-510816B4B2F3-- From nobody Wed Aug 5 15:17:54 2020 Return-Path: <01000173c0b39fd1-1bd0309b-e56f-4378-b33a-08e9b56a068c-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319F13A0787 for ; Wed, 5 Aug 2020 15:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUbyXKIHFmV7 for ; Wed, 5 Aug 2020 15:17:45 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA3B3A07D4 for ; Wed, 5 Aug 2020 15:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596665864; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=tBTssl2kbdW97VjxEGNFXxaJpHLuHAYdh2jUnbIvcIU=; b=VB0+6U49oH9dtIBSTvnVjxv2z/3KetFQ+GemmxDIVLl1sIZn8LrRSQw2IlkDz5FA 762p2VMsf+Hgo37EdwLSonJrltcINU5Kx0WHE2PghkvbecQenldXtM/fcalmpNgP+I+ ntlsfGf5p0r6Adib0CU/awt4+I1qCAh2+Qu+uIq4= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_A4CA9F25-8D2D-44E8-8355-1C869C2A0F10" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000173c0b39fd1-1bd0309b-e56f-4378-b33a-08e9b56a068c-000000@us-east-1.amazonses.com> Date: Wed, 5 Aug 2020 22:17:44 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.05-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 22:17:54 -0000 --Apple-Mail=_A4CA9F25-8D2D-44E8-8355-1C869C2A0F10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NETCONF WG, Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft: Title: Self-explanation data Node tag capability Link: = https://tools.ietf.org/html/draft-tao-netconf-notif-node-tag-capabilities Abstract: Before a client application subscribes to updates from a = datastore, server capabilities related to "Subscription to YANG Datastores" = can be advertised using YANG Instance Data format. These server capabilities can be documented at implement time or reported at = run- time. This document proposes a YANG module for self-explanation data = Node tag capability which augments system capabilities model and = provide additional self-explanation data node attributes associated with = node selectors within per-node capabilities. In particular, please discuss adoption-suitability as it regards to the = following questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? PS: this message is itself not an adoption poll, but rather an attempt = to gauge interest/support for a potential future adoption poll. NETCONF Chairs= --Apple-Mail=_A4CA9F25-8D2D-44E8-8355-1C869C2A0F10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
NETCONF WG,

Per = the previous email sent moments ago, the chairs would like to solicit = input on the following draft:

  =  Title: Self-explanation data Node tag capability
   Link: https://tools.ietf.org/html/draft-tao-netconf-notif-node-tag-capabilities
  =  Abstract:

      = Before a client application subscribes to updates from a = datastore,
  =     server capabilities related to "Subscription to YANG = Datastores" can
  =     be advertised using YANG Instance Data format.  These = server
  =     capabilities can be documented at implement time or = reported at run-
      time.

      This document proposes a = YANG module for self-explanation data Node
      tag capability which = augments system capabilities model and provide
      additional = self-explanation data node attributes associated with = node
  =     selectors within per-node = capabilities.


In particular, please discuss adoption-suitability as it = regards to the following questions:

    1) is the problem important for the NETCONF WG = to solve?
    2) is the draft a suitable basis = for the work?


PS: this message = is itself not an adoption poll, but rather an attempt to gauge = interest/support for a potential future adoption poll.

NETCONF Chairs
= --Apple-Mail=_A4CA9F25-8D2D-44E8-8355-1C869C2A0F10-- From nobody Wed Aug 5 15:18:43 2020 Return-Path: <01000173c0b44d61-4df9b67b-47f9-46f5-9c91-6e00f466a5c5-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A3E3A076C for ; Wed, 5 Aug 2020 15:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9t3IxRSPy5h for ; Wed, 5 Aug 2020 15:18:39 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3AA3A058F for ; Wed, 5 Aug 2020 15:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596665908; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=9G4qjPbWTknKPUpZEC97kaHaBh1n66C/iyJAh/4J84k=; b=EJkVVt3CB9DesxgDpEqXCBOYgeFJ+Ik+PrUXimazyntRM+0Ld6u9Wdntn+4m6gPp 2tYhSDy1FHKIsYVUdmlqYDODwMrwFe77USzRqJPfFlU6dQMQetlFmcMh8E19Zzk13uc a+4voR5CNbhz+VkIwiQE4l6JOpJo4vX8tKA0MP1c= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_B33CEAED-9279-4057-A806-38F6BA85D8D4" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000173c0b44d61-4df9b67b-47f9-46f5-9c91-6e00f466a5c5-000000@us-east-1.amazonses.com> Date: Wed, 5 Aug 2020 22:18:28 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.05-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Adoption-suitability for draft-wang-netconf-adaptive-subscription X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 22:18:41 -0000 --Apple-Mail=_B33CEAED-9279-4057-A806-38F6BA85D8D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NETCONF WG, Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft: Title: Adaptive Subscription to YANG Notification Link: = https://tools.ietf.org/html/draft-wang-netconf-adaptive-subscription Abstract: This document defines a YANG data model and associated mechanism enabling subscriber's adaptive subscriptions to a publisher's = event streams at various different period intervals with which to report updates. Applying these elements allows both subscriber and publisher to automatically adjust the volume of telemetry traffic sent from publisher to the receivers. In particular, please discuss adoption-suitability as it regards to the = following questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? PS: this message is itself not an adoption poll, but rather an attempt = to gauge interest/support for a potential future adoption poll. NETCONF Chairs --Apple-Mail=_B33CEAED-9279-4057-A806-38F6BA85D8D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii NETCONF WG,

Per the previous email sent moments = ago, the chairs would like to solicit input on the following = draft:

   Title: Adaptive Subscription to YANG = Notification
  =  Link: https://tools.ietf.org/html/draft-wang-netconf-adaptive-subscri= ption
  =  Abstract:

      This document defines a = YANG data model and associated mechanism
      enabling subscriber's = adaptive subscriptions to a publisher's event
      streams at various = different period intervals with which to report
      updates.  Applying = these elements allows both subscriber and
      publisher to = automatically adjust the volume of telemetry = traffic
  =     sent from publisher to the = receivers.


In = particular, please discuss adoption-suitability as it regards to the = following questions:

    1) is the problem important for the NETCONF WG = to solve?
    2) is the draft a suitable basis = for the work?


PS: this = message is itself not an adoption poll, but rather an attempt to gauge = interest/support for a potential future adoption poll.

NETCONF Chairs
= --Apple-Mail=_B33CEAED-9279-4057-A806-38F6BA85D8D4-- From nobody Wed Aug 5 15:18:46 2020 Return-Path: <01000173c0b45676-dc00a30e-1234-45d2-ba20-131c9467110d-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9AE3A058F for ; Wed, 5 Aug 2020 15:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0T0bUhAxS2Tx for ; Wed, 5 Aug 2020 15:18:39 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2062B3A0598 for ; Wed, 5 Aug 2020 15:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596665911; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=KkGLiSsPk69oaLa7kRJjczHsBollSAS0djPW0UPcc9U=; b=YiPyqlw2u2BaFs8Cia6rx1Xr0jjWzooXtdUr2hpkZIYNHlpAGw2GiUUbumYqC1qI UoCMbrLUlYlynvY6V1Jia8cwbNUpP6aKiHrsM1Yp0BX4c3GO9XLkOS8yL99MyqDJy0z ZZocfkZChyjAGleBCKzkNv2iJ2VnefxjcpsT98wU= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_A9223BD5-58DF-4A7E-AFEF-48581043DF1D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000173c0b45676-dc00a30e-1234-45d2-ba20-131c9467110d-000000@us-east-1.amazonses.com> Date: Wed, 5 Aug 2020 22:18:31 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.05-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Adoption-suitability for draft-wang-netconf-bulk-subscribed-notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 22:18:41 -0000 --Apple-Mail=_A9223BD5-58DF-4A7E-AFEF-48581043DF1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NETCONF WG, Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft: Title: Bulk Subscription to YANG Event Notification Link: = https://tools.ietf.org/html/draft-wang-netconf-bulk-subscribed-notificatio= ns Abstract: This document defines a YANG data model and associated mechanism = that allows subscriber applications to bulk subscribe to publishers' = event streams based on bundle group information such as bundle size and bundle latency. This allows the publishers to report multiple notifications in a single bundling message. In particular, please discuss adoption-suitability as it regards to the = following questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? PS: this message is itself not an adoption poll, but rather an attempt = to gauge interest/support for a potential future adoption poll. NETCONF Chairs= --Apple-Mail=_A9223BD5-58DF-4A7E-AFEF-48581043DF1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

NETCONF WG,

Per the previous email sent moments = ago, the chairs would like to solicit input on the following = draft:

   Title: Bulk Subscription to = YANG Event Notification
   Link: https://tools.ietf.org/html/draft-wang-netconf-bulk-subscribed-notifications<= br class=3D"">  =  Abstract:

      = This document defines a YANG data model and associated mechanism = that
  =     allows subscriber applications to bulk subscribe to = publishers' event
      streams based on bundle group = information such as bundle size and
      bundle latency. =  This allows the publishers to report = multiple
  =     notifications in a single bundling = message.


In particular, please discuss adoption-suitability as it = regards to the following questions:

    1) is the problem important for the NETCONF WG = to solve?
    2) is the draft a suitable basis = for the work?


PS: this message = is itself not an adoption poll, but rather an attempt to gauge = interest/support for a potential future adoption poll.

NETCONF Chairs
= --Apple-Mail=_A9223BD5-58DF-4A7E-AFEF-48581043DF1D-- From nobody Wed Aug 5 15:19:14 2020 Return-Path: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD813A058F for ; Wed, 5 Aug 2020 15:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Juu82tLrjDqA for ; Wed, 5 Aug 2020 15:19:11 -0700 (PDT) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044923A064A for ; Wed, 5 Aug 2020 15:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596665949; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=qZRWHaf8QO4HcCh9jF1pyzOotZnzAdH5swuLLrgyfR4=; b=KQeOzNxCt/+jpJiH9s4V1EQZVMuuaAimckEJISKVDoILAZNWJok/hCtlewaTwryb GPNEp83t9bkIsg3PxEfBwg+uyDuiXrOJ0BK6iz1DN8CaY3wmzgyoGF9QUEv23VX4j0e TSJZfMmDsO13qjwelVP44m9L6oIOu+kDYAVYQEEU= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_226BDA9D-BC2E-4892-8C1C-86CDF1B5C1AD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> Date: Wed, 5 Aug 2020 22:19:09 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.05-54.240.48.110 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 22:19:13 -0000 --Apple-Mail=_226BDA9D-BC2E-4892-8C1C-86CDF1B5C1AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NETCONF WG, Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft: Title: Conveying a CSR in an SZTP Bootstrapping Request Link: https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr Abstract: This draft extends the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. In particular, please discuss adoption-suitability as it regards to the = following questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? PS: this message is itself not an adoption poll, but rather an attempt = to gauge interest/support for a potential future adoption poll. NETCONF Chairs= --Apple-Mail=_226BDA9D-BC2E-4892-8C1C-86CDF1B5C1AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

NETCONF WG,

Per the previous email sent moments = ago, the chairs would like to solicit input on the following = draft:

   Title: Conveying a CSR in = an SZTP Bootstrapping Request
   Link: https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr
  =  Abstract:

      This draft extends the = "get-bootstrapping-data" RPC defined in
      = RFC 8572 to include an optional = certificate signing request (CSR),
      enabling a bootstrapping device to = additionally obtain an identity
      certificate (e.g., an LDevID, from IEEE = 802.1AR) as part of the
      "onboarding information" response = provided in the RPC-reply.


In particular, please discuss adoption-suitability as it = regards to the following questions:

    1) is the problem important for the NETCONF WG = to solve?
    2) is the draft a suitable basis = for the work?


PS: this message = is itself not an adoption poll, but rather an attempt to gauge = interest/support for a potential future adoption poll.

NETCONF Chairs
= --Apple-Mail=_226BDA9D-BC2E-4892-8C1C-86CDF1B5C1AD-- From nobody Thu Aug 6 19:54:52 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56A13A0D37 for ; Thu, 6 Aug 2020 19:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHxpA82zZzf4 for ; Thu, 6 Aug 2020 19:54:49 -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 33ECE3A0D36 for ; Thu, 6 Aug 2020 19:54:49 -0700 (PDT) Received: from lhreml716-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 91474A3A7F590E9959ED for ; Fri, 7 Aug 2020 03:54:46 +0100 (IST) Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml716-chm.china.huawei.com (10.201.108.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 7 Aug 2020 03:54:45 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 7 Aug 2020 10:54:43 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Fri, 7 Aug 2020 10:54:43 +0800 From: Tianran Zhou To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] Regarding 108 adoption hums Thread-Index: AQHWa3W0/zcfmCeL8EOO/Z5e6RwUCakr9FrQ Date: Fri, 7 Aug 2020 02:54:43 +0000 Message-ID: References: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> In-Reply-To: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.128] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Regarding 108 adoption hums X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 02:54:51 -0000 SGkgS2VudCwgTWFoZXNoIGFuZCBSb2JlcnQsDQoNCkkgYW0ganVzdCB0aGlua2luZywgYXJlIHRo ZXNlIHF1ZXN0aW9ucyByZWR1bmRhbnQgdG8gdGhlIEFkb3B0aW9uIGNhbGw/DQpJdCBzZWVtcyB0 aGUgc2ltaWxhciBxdWVzdGlvbnMgYXMgc3VwcG9zZWQgdG8gYmUgYXNrZWQgaW4gdGhlIGFkb3B0 aW9uIGNhbGwuDQoNCkJlc3QsDQpUaWFucmFuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEtlbnQgV2F0c2VuDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDYsIDIwMjAgNjox MyBBTQ0KVG86IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFtuZXRjb25mXSBSZWdhcmRpbmcg MTA4IGFkb3B0aW9uIGh1bXMNCg0KDQpORVRDT05GIFdHLA0KDQoNClRoZSBDaGFpcnMgJiBBRCBk aXNjdXNzZWQgdGhlIHJlc3VsdHMgb2YgdGhlIHZhcmlvdXMgYWRvcHRpb24gaHVtcyBjb25kdWN0 ZWQgZHVyaW5nIHRoZSAxMDggbWVldGluZy4gIFRoZXJlIGlzIGEgc2Vuc2UgdGhhdCB0aGUgcmVz dWx0cyBkaWRu4oCZdCBhZGVxdWF0ZWx5IGRldGVybWluZSBpZiB0aGUgZHJhZnRzIHNob3VsZCBi ZSBhZG9wdGVkLiAgSW4gcGFydGljdWxhciwgaXQgd2FzbuKAmXQgY2xlYXIgaWYgdGhlIGh1bXMg cmVmbGVjdGVkIGEgZ2VuZXJhbCBkZXNpcmUgdG8gc29sdmUgdGhlIHByb2JsZW0gb3Igc3VwcG9y dCBmb3IgdGhlIHBhcnRpY3VsYXIgZHJhZnQuDQoNCkFzIHN1Y2gsIHdl4oCZdmUgZGVjaWRlZCB0 byBzZW5kIHN1YnNlcXVlbnQgZW1haWxzIGZvciBlYWNoIGRyYWZ0LCBvciBzZXQgb2YgZHJhZnRz IGlmIGFwcHJvcHJpYXRlLCB0byBzb2xpY2l0IGlucHV0IG9uIGZvbGxvd2luZyBxdWVzdGlvbnM6 DQoNCiAgICAxKSBpcyB0aGUgcHJvYmxlbSBpbXBvcnRhbnQgZm9yIHRoZSBORVRDT05GIFdHIHRv IHNvbHZlPw0KICAgIDIpIGlzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJhc2lzIGZvciB0aGUgd29y az8NCg0KDQpORVRDT05GIENoYWlycw0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Fri Aug 7 01:59:22 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788033A0DC2 for ; Fri, 7 Aug 2020 01:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a9qSVJUr1po for ; Fri, 7 Aug 2020 01:59:19 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 5CEE43A0D9B for ; Fri, 7 Aug 2020 01:59:18 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0778xGrG004219; Fri, 7 Aug 2020 09:59:16 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9810622042; Fri, 7 Aug 2020 09:59:16 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 831B122046; Fri, 7 Aug 2020 09:59:16 +0100 (BST) Received: from LAPTOPK7AS653V ([84.51.134.26]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0778xFcs020628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Aug 2020 09:59:16 +0100 Reply-To: From: "Adrian Farrel" To: "'Kent Watsen'" , References: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> In-Reply-To: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> Date: Fri, 7 Aug 2020 09:59:15 +0100 Organization: Old Dog Consulting Message-ID: <00cf01d66c99$07392530$15ab6f90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIfQ7LOfcJkMW7q4E+Bn+YyMkBLjqiap2dA Content-Language: en-gb X-Originating-IP: 84.51.134.26 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25588.005 X-TM-AS-Result: No--12.814-10.0-31-10 X-imss-scan-details: No--12.814-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25588.005 X-TMASE-Result: 10--12.814200-10.000000 X-TMASE-MatchedRID: vbSD0OnL8/LxIbpQ8BhdbLlRS/TbY0kCIiTd2l7lf6Fj21c8aH+7Q2ly s1PDhWLozi5dYQjfWjmfpYxFCGmlCzX6PE8rwd6hGfTCsR61MuG5I3Jkp5qIPlAoBBK61Bhcy6i gHaxqQh9xDIUEUHVbUEgAAZdl5uIbUjaMAvB33L3begPiArwouovkwJz527bYH1Ag+/MaFnfJUF bx9STuk0btwy1ZOZ0ck9yCAJhmQwW/c+D5WJtQZljEXwwRC1JsicCHz0eydvRWvpVGJ7EisS8G2 Ltt4jDGAWMdzSV1IwZRfJLIyxbVcRG5EWWx2rjOo23GGZFBKAzOo//J/EA1QUYza41dGqxS1BQt 3e1Ue9fZ+HMpGtt/U+8kPAX6Mdwaye9S6P4htXa1PiMh4ZF39QVyeo9hM9SHpjtcfbwefVGjxYy RBa/qJQOkBnb8H8GW0KkIUsNMdlTdB/CxWTRRu25FeHtsUoHurEahVcfiF+EtwoMBxHwqA3Po3P vRRj7eV1Bu7BMx6DE+kK598Yf3Mg== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [netconf] Regarding 108 adoption hums X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 08:59:22 -0000 Hi chairs, I think this is an interesting approach to determining whether there is = interest in a number of drafts at the same time, and I agree with you = that a hum at a working group meeting means nothing without confirming = the opinion on the mailing list. But I'm worried that you may be introducing yet another piece of process = into how we process documents. The adoption poll, itself, is not necessary if it is obvious to the = chairs that a draft is within charter and has support [RFC7221]. But in = addition to the poll, we also have somehow introduced an IPR poll at = adoption time (while I can see the merits of being explicit about IPR, = and we have seen one or two people attempt to wriggle out of their = responsibilities, it seems unnecessary to serialize the two calls). Now = you appear to be introducing an additional step to test "adoption = suitability". Can I urge you (strongly? :-) to consider the responses to you adoption = suitability tests and, if they are solid, to move straight to adoption = without making the working group go though a prolonged series of polls. = We would, I think, prefer to get on with the work! Best, Adrian -----Original Message----- From: netconf On Behalf Of Kent Watsen Sent: 05 August 2020 23:13 To: netconf@ietf.org Subject: [netconf] Regarding 108 adoption hums NETCONF WG, The Chairs & AD discussed the results of the various adoption hums = conducted during the 108 meeting. There is a sense that the results = didn=E2=80=99t adequately determine if the drafts should be adopted. In = particular, it wasn=E2=80=99t clear if the hums reflected a general = desire to solve the problem or support for the particular draft. As such, we=E2=80=99ve decided to send subsequent emails for each draft, = or set of drafts if appropriate, to solicit input on following = questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? NETCONF Chairs _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Aug 7 02:16:00 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCF13A0DF9 for ; Fri, 7 Aug 2020 02:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRqpC5nNLWse for ; Fri, 7 Aug 2020 02:15:55 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3853A0DF7 for ; Fri, 7 Aug 2020 02:15:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GWDgAsGy1f/xoBYJlggQmBTAGDFoE?= =?us-ascii?q?zCoQqkReaJYFeCwsBAQEBAQEBAQEGAQEYCwoCBAEBAoQGRAKCNgEkOQUNAhA?= =?us-ascii?q?BAQYBAQEBAQYEAgKGRQxDFgGCeYEDAQEBAQEBAQEBAQEBAQEBAQEBARYCQ1U?= =?us-ascii?q?SAR4BAQEBAwEBIQ8BBTYXBAkCEQQBAQECAiYCAicgCAgGAQwGAgEBgyIBgns?= =?us-ascii?q?FC5hUmwR2gTKFUoNlgToGgQ4rhk6GPw+BTD+BEScPglo+glwBAYFGgzCCYAS?= =?us-ascii?q?Se6J9KQeBW4EKgQkEC5huBQoekVMGjjCSK58wAgQCCQIVgWuBek0kT4JpUBc?= =?us-ascii?q?CDZckhURyNwIGAQcBAQMJfIxcgXgBgRABAQ?= X-IPAS-Result: =?us-ascii?q?A2GWDgAsGy1f/xoBYJlggQmBTAGDFoEzCoQqkReaJYFeC?= =?us-ascii?q?wsBAQEBAQEBAQEGAQEYCwoCBAEBAoQGRAKCNgEkOQUNAhABAQYBAQEBAQYEA?= =?us-ascii?q?gKGRQxDFgGCeYEDAQEBAQEBAQEBAQEBAQEBAQEBARYCQ1USAR4BAQEBAwEBI?= =?us-ascii?q?Q8BBTYXBAkCEQQBAQECAiYCAicgCAgGAQwGAgEBgyIBgnsFC5hUmwR2gTKFU?= =?us-ascii?q?oNlgToGgQ4rhk6GPw+BTD+BEScPglo+glwBAYFGgzCCYASSe6J9KQeBW4EKg?= =?us-ascii?q?QkEC5huBQoekVMGjjCSK58wAgQCCQIVgWuBek0kT4JpUBcCDZckhURyNwIGA?= =?us-ascii?q?QcBAQMJfIxcgXgBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,445,1589234400"; d="scan'208";a="23541744" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Aug 2020 11:15:51 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiEQAsGy1f/1lIDI1gHgEBCxIMQIF?= =?us-ascii?q?MAYInbwNUMCwKhCqRF5olgWkLAQMBAQEBAQYBARgLCgIEAQGECEQCgjQCJDk?= =?us-ascii?q?FDQIQAQEFAQEBAgEGBG2FXAxDFgGFFwEBAQQBASEPAQU2FwQJAhEEAQEBAgI?= =?us-ascii?q?mAgInIAgIBgEMBgIBAYMiAYMAC5hUmwR2gTKFUoNlgToGgQ4rhk6GPw+BTD+?= =?us-ascii?q?BEScPglo+glwBAYFGgzCCYASSe6J9KQeBW4EKgQkEC5huBQoekVMGjjCSK58?= =?us-ascii?q?wAgQCCQIVgWsigVdNJE+CaVAXAg2XJIVEQTE3AgYBBwEBAwl8jFyBeAGBEAE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.75,445,1589234400"; d="scan'208";a="88035930" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Aug 2020 11:15:48 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 0779Fmp6009566 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Fri, 7 Aug 2020 11:15:48 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 7 Aug 2020 11:15:43 +0200 To: , "'Kent Watsen'" , References: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> <00cf01d66c99$07392530$15ab6f90$@olddog.co.uk> From: Henk Birkholz Message-ID: Date: Fri, 7 Aug 2020 11:15:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <00cf01d66c99$07392530$15ab6f90$@olddog.co.uk> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [netconf] Regarding 108 adoption hums X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 09:15:58 -0000 Hi chairs, hi list, I have to admit that I am also tad bit puzzled by this procedure, I am afraid. If this this would be a WGLC instead of a WGA, I'd be inclined to support a more fine grained gateway procedure. But presenting the session output as "the results didn’t adequately determine if the drafts should be adopted" seems to be a bit off. Why not ask for discrete concerns about adoption motions for specific contributions instead of this (rather surprising) reset? Viele Grüße, Henk On 07.08.20 10:59, Adrian Farrel wrote: > Hi chairs, > > I think this is an interesting approach to determining whether there is interest in a number of drafts at the same time, and I agree with you that a hum at a working group meeting means nothing without confirming the opinion on the mailing list. > > But I'm worried that you may be introducing yet another piece of process into how we process documents. > > The adoption poll, itself, is not necessary if it is obvious to the chairs that a draft is within charter and has support [RFC7221]. But in addition to the poll, we also have somehow introduced an IPR poll at adoption time (while I can see the merits of being explicit about IPR, and we have seen one or two people attempt to wriggle out of their responsibilities, it seems unnecessary to serialize the two calls). Now you appear to be introducing an additional step to test "adoption suitability". > > Can I urge you (strongly? :-) to consider the responses to you adoption suitability tests and, if they are solid, to move straight to adoption without making the working group go though a prolonged series of polls. We would, I think, prefer to get on with the work! > > Best, > Adrian > > -----Original Message----- > From: netconf On Behalf Of Kent Watsen > Sent: 05 August 2020 23:13 > To: netconf@ietf.org > Subject: [netconf] Regarding 108 adoption hums > > > NETCONF WG, > > > The Chairs & AD discussed the results of the various adoption hums conducted during the 108 meeting. There is a sense that the results didn’t adequately determine if the drafts should be adopted. In particular, it wasn’t clear if the hums reflected a general desire to solve the problem or support for the particular draft. > > As such, we’ve decided to send subsequent emails for each draft, or set of drafts if appropriate, to solicit input on following questions: > > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? > > > NETCONF Chairs > > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Fri Aug 7 02:17:23 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916873A0DF8 for ; Fri, 7 Aug 2020 02:17:21 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfJyLWergICz for ; Fri, 7 Aug 2020 02:17:19 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F1A3A0DF7 for ; Fri, 7 Aug 2020 02:17:18 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 211D07D; Fri, 7 Aug 2020 11:17:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 55dfJGJVsHMe; Fri, 7 Aug 2020 11:17:16 +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 "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 7 Aug 2020 11:17:16 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id C07C520154; Fri, 7 Aug 2020 11:17:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id 2P4NjGLbNYeB; Fri, 7 Aug 2020 11:17:16 +0200 (CEST) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 4AC7F200E4; Fri, 7 Aug 2020 11:17:16 +0200 (CEST) Date: Fri, 7 Aug 2020 11:17:15 +0200 From: Juergen Schoenwaelder To: Adrian Farrel Cc: 'Kent Watsen' , netconf@ietf.org Message-ID: <20200807091715.vzglsinbh76ox6kz@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Adrian Farrel , 'Kent Watsen' , netconf@ietf.org References: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> <00cf01d66c99$07392530$15ab6f90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <00cf01d66c99$07392530$15ab6f90$@olddog.co.uk> X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] Regarding 108 adoption hums X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 09:17:22 -0000 Adrian, technical discussion of the drafts on the mailing list would help more than having process meta-discussions. It is good to know who (other than the authors) is volunteering to substantially review the drafts, is willing to contribute to the discussions of any issues, and is planning to implement the technology defined in the drafts as this will likely help the chairs to make a decision. /js On Fri, Aug 07, 2020 at 09:59:15AM +0100, Adrian Farrel wrote: > Hi chairs, >=20 > I think this is an interesting approach to determining whether there is= interest in a number of drafts at the same time, and I agree with you th= at a hum at a working group meeting means nothing without confirming the = opinion on the mailing list. >=20 > But I'm worried that you may be introducing yet another piece of proces= s into how we process documents. >=20 > The adoption poll, itself, is not necessary if it is obvious to the cha= irs that a draft is within charter and has support [RFC7221]. But in addi= tion to the poll, we also have somehow introduced an IPR poll at adoption= time (while I can see the merits of being explicit about IPR, and we hav= e seen one or two people attempt to wriggle out of their responsibilities= , it seems unnecessary to serialize the two calls). Now you appear to be = introducing an additional step to test "adoption suitability". >=20 > Can I urge you (strongly? :-) to consider the responses to you adoption= suitability tests and, if they are solid, to move straight to adoption w= ithout making the working group go though a prolonged series of polls. We= would, I think, prefer to get on with the work! >=20 > Best, > Adrian >=20 > -----Original Message----- > From: netconf On Behalf Of Kent Watsen > Sent: 05 August 2020 23:13 > To: netconf@ietf.org > Subject: [netconf] Regarding 108 adoption hums >=20 >=20 > NETCONF WG, >=20 >=20 > The Chairs & AD discussed the results of the various adoption hums cond= ucted during the 108 meeting. There is a sense that the results didn=E2=80= =99t adequately determine if the drafts should be adopted. In particular= , it wasn=E2=80=99t clear if the hums reflected a general desire to solve= the problem or support for the particular draft. >=20 > As such, we=E2=80=99ve decided to send subsequent emails for each draft= , or set of drafts if appropriate, to solicit input on following question= s: >=20 > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? >=20 >=20 > NETCONF Chairs >=20 >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=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 Aug 7 02:28:04 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCB43A0E1E for ; Fri, 7 Aug 2020 02:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92attF7VQ1PG for ; Fri, 7 Aug 2020 02:28:00 -0700 (PDT) Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (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 A64583A0E0F for ; Fri, 7 Aug 2020 02:27:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GLDQD3HS1f/xmnZsBgHgEBCxIMQIF?= =?us-ascii?q?MgxeBMwqEKpByJZolgWAJCwEBAQEBAQEBAQYBARgLCgIEAQEChAZEAoI3ASQ?= =?us-ascii?q?4EwIQAQEGAQEBAQEGBAIChkUMQxYBgnmBAwEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BFQJDPBkSAR4BAQEBAgEBASEPAQU2EAcECQIRBAEBAQICJgICJyAICAYBDAY?= =?us-ascii?q?CAQGDIgGCXCAEC5hYmwR2gTKEOwGBFoNfgToGgQ4qAYZOhj8PgUw/gREnDAO?= =?us-ascii?q?CWj6CXAEBgUaDMIJgBJJ7on0pB4FbgQqBCQQLh0mRJQUKHoJ8iVSFAwaOMJI?= =?us-ascii?q?rijqUdgIEAgkCFYFqgXtNJE+CaVAXAg2SEIUUhURyNwIGAQcBAQMJfIxcgXg?= =?us-ascii?q?BgRABAQ?= X-IPAS-Result: =?us-ascii?q?A2GLDQD3HS1f/xmnZsBgHgEBCxIMQIFMgxeBMwqEKpByJ?= =?us-ascii?q?ZolgWAJCwEBAQEBAQEBAQYBARgLCgIEAQEChAZEAoI3ASQ4EwIQAQEGAQEBA?= =?us-ascii?q?QEGBAIChkUMQxYBgnmBAwEBAQEBAQEBAQEBAQEBAQEBAQEBFQJDPBkSAR4BA?= =?us-ascii?q?QEBAgEBASEPAQU2EAcECQIRBAEBAQICJgICJyAICAYBDAYCAQGDIgGCXCAEC?= =?us-ascii?q?5hYmwR2gTKEOwGBFoNfgToGgQ4qAYZOhj8PgUw/gREnDAOCWj6CXAEBgUaDM?= =?us-ascii?q?IJgBJJ7on0pB4FbgQqBCQQLh0mRJQUKHoJ8iVSFAwaOMJIrijqUdgIEAgkCF?= =?us-ascii?q?YFqgXtNJE+CaVAXAg2SEIUUhURyNwIGAQcBAQMJfIxcgXgBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,445,1589234400"; d="scan'208";a="19522050" Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Aug 2020 11:27:56 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWDQAVHi1f/1lIDI1gHgEBCxIMQIF?= =?us-ascii?q?MgihvA1QwLAqEKpByJZolgWkLAQMBAQEBAQYBARgLCgIEAQGECEQCgjUCJDg?= =?us-ascii?q?TAhABAQUBAQECAQYEbYVcDEMWAYUXAQEBAwEBASEPAQU2EAcECQIRBAEBAQI?= =?us-ascii?q?CJgICJyAICAYBDAYCAQGDIgGCXCQLmFmbBHaBMoQ7AYEWg1+BOgaBDioBhk6?= =?us-ascii?q?GPw+BTD+BEScMA4JaPoJcAQGBRoMwgmAEknuifSkHgVuBCoEJBAuHSZElBQo?= =?us-ascii?q?egnyJVIUDBo4wkiuKOpR2AgQCCQIVgWojgVdNJE+CaVAXAg2SEIUUhURBMTc?= =?us-ascii?q?CBgEHAQEDCXyMXIF4AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,445,1589234400"; d="scan'208";a="87794797" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Aug 2020 11:27:53 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 0779RqGm009912 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Fri, 7 Aug 2020 11:27:52 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 7 Aug 2020 11:27:47 +0200 To: , "'Kent Watsen'" , References: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> <00cf01d66c99$07392530$15ab6f90$@olddog.co.uk> <20200807091959.fywbuyfdifxb747k@anna.jacobs.jacobs-university.de> From: Henk Birkholz Message-ID: Date: Fri, 7 Aug 2020 11:27:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200807091959.fywbuyfdifxb747k@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [netconf] Regarding 108 adoption hums X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 09:28:03 -0000 Hi Jürgen, piano is 3/5 stars. I think that is a typical moderate agreement (not an enthusiastic one, but we are talking about NETCONF here). Two contested hums that compete with say 2/5 and 3/5 results should be discussed further. In a standard IETF session room hum, I think 3/5 would never have had any opposition at all. Please think of the hum results as a star rating with all its pros and cons: > https://xkcd.com/937/ If interest shows to be "an empty promise" this will certainly show in the WG as an adopted item. My impression was that the content is appropriate and that there is an established baseline for support. Viele Grüße, Henk On 07.08.20 11:19, Juergen Schoenwaelder wrote: > Henk, > > as far as I recall, all hums were 'piano' and given the new humming > tool, nobody really knows what a 'piano' result really means. And as > you know, all WG decisions are taken on the mailing list - so I do > not see anything wrong with asking the mailing list. > > /js > > On Fri, Aug 07, 2020 at 11:15:42AM +0200, Henk Birkholz wrote: >> Hi chairs, >> hi list, >> >> I have to admit that I am also tad bit puzzled by this procedure, I am >> afraid. If this this would be a WGLC instead of a WGA, I'd be inclined to >> support a more fine grained gateway procedure. But presenting the session >> output as "the results didn’t adequately determine if the drafts should be >> adopted" seems to be a bit off. Why not ask for discrete concerns about >> adoption motions for specific contributions instead of this (rather >> surprising) reset? >> >> Viele Grüße, >> >> Henk >> >> >> On 07.08.20 10:59, Adrian Farrel wrote: >>> Hi chairs, >>> >>> I think this is an interesting approach to determining whether there is interest in a number of drafts at the same time, and I agree with you that a hum at a working group meeting means nothing without confirming the opinion on the mailing list. >>> >>> But I'm worried that you may be introducing yet another piece of process into how we process documents. >>> >>> The adoption poll, itself, is not necessary if it is obvious to the chairs that a draft is within charter and has support [RFC7221]. But in addition to the poll, we also have somehow introduced an IPR poll at adoption time (while I can see the merits of being explicit about IPR, and we have seen one or two people attempt to wriggle out of their responsibilities, it seems unnecessary to serialize the two calls). Now you appear to be introducing an additional step to test "adoption suitability". >>> >>> Can I urge you (strongly? :-) to consider the responses to you adoption suitability tests and, if they are solid, to move straight to adoption without making the working group go though a prolonged series of polls. We would, I think, prefer to get on with the work! >>> >>> Best, >>> Adrian >>> >>> -----Original Message----- >>> From: netconf On Behalf Of Kent Watsen >>> Sent: 05 August 2020 23:13 >>> To: netconf@ietf.org >>> Subject: [netconf] Regarding 108 adoption hums >>> >>> >>> NETCONF WG, >>> >>> >>> The Chairs & AD discussed the results of the various adoption hums conducted during the 108 meeting. There is a sense that the results didn’t adequately determine if the drafts should be adopted. In particular, it wasn’t clear if the hums reflected a general desire to solve the problem or support for the particular draft. >>> >>> As such, we’ve decided to send subsequent emails for each draft, or set of drafts if appropriate, to solicit input on following questions: >>> >>> 1) is the problem important for the NETCONF WG to solve? >>> 2) is the draft a suitable basis for the work? >>> >>> >>> NETCONF Chairs >>> >>> >>> >>> >>> _______________________________________________ >>> netconf mailing list >>> netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> _______________________________________________ >>> netconf mailing list >>> netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > From nobody Fri Aug 7 02:28:18 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222383A0E46 for ; Fri, 7 Aug 2020 02:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 yJHdqiFYPRBI for ; Fri, 7 Aug 2020 02:28:09 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5E13A0E04 for ; Fri, 7 Aug 2020 02:20:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id C368C814; Fri, 7 Aug 2020 11:20:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id GWJ_AZ05yyaK; Fri, 7 Aug 2020 11:20:00 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 7 Aug 2020 11:20:00 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6651E20154; Fri, 7 Aug 2020 11:20:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id 19AnUxaO0fY7; Fri, 7 Aug 2020 11:20:00 +0200 (CEST) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id E9FC2200E4; Fri, 7 Aug 2020 11:19:59 +0200 (CEST) Date: Fri, 7 Aug 2020 11:19:59 +0200 From: Juergen Schoenwaelder To: Henk Birkholz Cc: adrian@olddog.co.uk, 'Kent Watsen' , netconf@ietf.org Message-ID: <20200807091959.fywbuyfdifxb747k@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Henk Birkholz , adrian@olddog.co.uk, 'Kent Watsen' , netconf@ietf.org References: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> <00cf01d66c99$07392530$15ab6f90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] Regarding 108 adoption hums X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 09:28:17 -0000 Henk, as far as I recall, all hums were 'piano' and given the new humming tool, nobody really knows what a 'piano' result really means. And as you know, all WG decisions are taken on the mailing list - so I do not see anything wrong with asking the mailing list. /js On Fri, Aug 07, 2020 at 11:15:42AM +0200, Henk Birkholz wrote: > Hi chairs, > hi list, >=20 > I have to admit that I am also tad bit puzzled by this procedure, I am > afraid. If this this would be a WGLC instead of a WGA, I'd be inclined = to > support a more fine grained gateway procedure. But presenting the sessi= on > output as "the results didn=E2=80=99t adequately determine if the draft= s should be > adopted" seems to be a bit off. Why not ask for discrete concerns about > adoption motions for specific contributions instead of this (rather > surprising) reset? >=20 > Viele Gr=C3=BC=C3=9Fe, >=20 > Henk >=20 >=20 > On 07.08.20 10:59, Adrian Farrel wrote: > > Hi chairs, > >=20 > > I think this is an interesting approach to determining whether there = is interest in a number of drafts at the same time, and I agree with you = that a hum at a working group meeting means nothing without confirming th= e opinion on the mailing list. > >=20 > > But I'm worried that you may be introducing yet another piece of proc= ess into how we process documents. > >=20 > > The adoption poll, itself, is not necessary if it is obvious to the c= hairs that a draft is within charter and has support [RFC7221]. But in ad= dition to the poll, we also have somehow introduced an IPR poll at adopti= on time (while I can see the merits of being explicit about IPR, and we h= ave seen one or two people attempt to wriggle out of their responsibiliti= es, it seems unnecessary to serialize the two calls). Now you appear to b= e introducing an additional step to test "adoption suitability". > >=20 > > Can I urge you (strongly? :-) to consider the responses to you adopti= on suitability tests and, if they are solid, to move straight to adoption= without making the working group go though a prolonged series of polls. = We would, I think, prefer to get on with the work! > >=20 > > Best, > > Adrian > >=20 > > -----Original Message----- > > From: netconf On Behalf Of Kent Watsen > > Sent: 05 August 2020 23:13 > > To: netconf@ietf.org > > Subject: [netconf] Regarding 108 adoption hums > >=20 > >=20 > > NETCONF WG, > >=20 > >=20 > > The Chairs & AD discussed the results of the various adoption hums co= nducted during the 108 meeting. There is a sense that the results didn=E2= =80=99t adequately determine if the drafts should be adopted. In particu= lar, it wasn=E2=80=99t clear if the hums reflected a general desire to so= lve the problem or support for the particular draft. > >=20 > > As such, we=E2=80=99ve decided to send subsequent emails for each dra= ft, or set of drafts if appropriate, to solicit input on following questi= ons: > >=20 > > 1) is the problem important for the NETCONF WG to solve? > > 2) is the draft a suitable basis for the work? > >=20 > >=20 > > NETCONF Chairs > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > >=20 > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Aug 7 02:30:49 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E983A0DFE for ; Fri, 7 Aug 2020 02:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfygHNvmWN2j for ; Fri, 7 Aug 2020 02:30:46 -0700 (PDT) Received: from mail-edgeDD24.fraunhofer.de (mail-edgeDD24.fraunhofer.de [192.102.167.24]) (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 E63423A10F3 for ; Fri, 7 Aug 2020 02:29:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EeFABkpYde/xmnZsBmhGpvVS80hBG?= =?us-ascii?q?OeYFkLZlggWcKAQEBAQEBAQEBBgEBLQIEAQGERAKCRyQ4EwIQAQEGAQEBAQE?= =?us-ascii?q?FBAICaYVihkYBBSMVNhsLGAICJgICRxAGAQwIAQGDIoJ9BK9DgTKFS4NngT6?= =?us-ascii?q?BDiqMMQ+BTD+BOA+CWj6ENYMrgl4EkH+HIZhyB4FJd3wElh8jgjsBjHkFjEa?= =?us-ascii?q?PMpwdAgQCCQIVgWkjgVdNJE+Cak8YDZxnghuNGQGBDwEB?= X-IPAS-Result: =?us-ascii?q?A2EeFABkpYde/xmnZsBmhGpvVS80hBGOeYFkLZlggWcKA?= =?us-ascii?q?QEBAQEBAQEBBgEBLQIEAQGERAKCRyQ4EwIQAQEGAQEBAQEFBAICaYVihkYBB?= =?us-ascii?q?SMVNhsLGAICJgICRxAGAQwIAQGDIoJ9BK9DgTKFS4NngT6BDiqMMQ+BTD+BO?= =?us-ascii?q?A+CWj6ENYMrgl4EkH+HIZhyB4FJd3wElh8jgjsBjHkFjEaPMpwdAgQCCQIVg?= =?us-ascii?q?WkjgVdNJE+Cak8YDZxnghuNGQGBDwEB?= X-IronPort-AV: E=Sophos;i="5.72,341,1580770800"; d="scan'208";a="33483174" Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeDD24.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Aug 2020 11:29:52 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuGwAVHi1f/1lIDI1ggQmBTIE8Amp?= =?us-ascii?q?yVDA2hCqII4h0mhITgWkLAQMBAQEBAQYBAS0CBAEBhEwCgjUCJDwCDQIQAQE?= =?us-ascii?q?FAQEBAgEGBG2FaIVyAQUjFTYbCxgCAiYCAkcQBgEMCAEBgyKDAbRegTKFUoN?= =?us-ascii?q?fgUCBDigDAYZNhj8PgUw/gTgPglo+hCSDMIJgBJJ7iB6aXykHgVuBCoEJBAu?= =?us-ascii?q?YbgUKHoJqAY5oBo4wkiufMAIEAgkCFYIBDIFXTSRPgmpPFwINnGhBaAIGCAE?= =?us-ascii?q?BAwl8jlQBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,445,1589234400"; d="scan'208";a="87794996" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Aug 2020 11:29:47 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 0779Tl8H010019 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Fri, 7 Aug 2020 11:29:47 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 7 Aug 2020 11:29:42 +0200 To: , "'Kent Watsen'" , References: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> <00cf01d66c99$07392530$15ab6f90$@olddog.co.uk> <20200807091959.fywbuyfdifxb747k@anna.jacobs.jacobs-university.de> From: Henk Birkholz Message-ID: Date: Fri, 7 Aug 2020 11:29:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200807091959.fywbuyfdifxb747k@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [netconf] Regarding 108 adoption hums X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 09:30:48 -0000 Oh, and I fully agree with the quote below! The scope and phrasing is what leaves me puzzled. An ask about concerns with the 3/5 results would be the thing I am expecting - not a reset. On 07.08.20 11:19, Juergen Schoenwaelder wrote: > I do > not see anything wrong with asking the mailing list. > > /js From nobody Fri Aug 7 04:02:55 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C243A03EE for ; Fri, 7 Aug 2020 04:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr8zNnzp-GfR for ; Fri, 7 Aug 2020 04:02:51 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 6DFB03A02BE for ; Fri, 7 Aug 2020 04:02:50 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 077B2m0f006330; Fri, 7 Aug 2020 12:02:48 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 75F9D22042; Fri, 7 Aug 2020 12:02:48 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 6AB422204C; Fri, 7 Aug 2020 12:02:48 +0100 (BST) Received: from LAPTOPK7AS653V ([84.51.134.26]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 077B2lha014989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Aug 2020 12:02:47 +0100 Reply-To: From: "Adrian Farrel" To: "'Juergen Schoenwaelder'" Cc: "'Kent Watsen'" , References: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> <00cf01d66c99$07392530$15ab6f90$@olddog.co.uk> <20200807091715.vzglsinbh76ox6kz@anna.jacobs.jacobs-university.de> In-Reply-To: <20200807091715.vzglsinbh76ox6kz@anna.jacobs.jacobs-university.de> Date: Fri, 7 Aug 2020 12:02:45 +0100 Organization: Old Dog Consulting Message-ID: <00f601d66caa$48a34cb0$d9e9e610$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIfQ7LOfcJkMW7q4E+Bn+YyMkBLjgFaXx9lAqoAokGoeqmFYA== Content-Language: en-gb X-Originating-IP: 84.51.134.26 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25588.006 X-TM-AS-Result: No--26.133-10.0-31-10 X-imss-scan-details: No--26.133-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25588.006 X-TMASE-Result: 10--26.133400-10.000000 X-TMASE-MatchedRID: gTucSmrmRMPxIbpQ8BhdbPs3IjAeeG13X6zb82IV74xPvOpmjDN2kqFJ S1sWNSLSxCzeyr1FvOh4PdoKtYMuFzdU4n9N9PJifd/PCz/+9ZNgFto/VVnNJbZ25/Upg4v8Lgx JDGqZkvtvq3XPcoHERNr/0ptVz43S7DLY2FGw/Ju7B1QwzOcQDxmyTBaqiJvcwEgSPNlM5Q3frA EUZTjrwQA7oUjYa94XgJi+Usjj25q8Sm0lAaO40E4eFUkH5CFcrXkuON8pnlEjlnxOIeMfMLMfF DCa+KZ3Cr1jbh1tiICPWx38Q1qIm0HGTQqAQaePsTzXVHVB9VoHgh3sKJBzP/Alhlr8vzcdxz/7 xR5HMMmWuDQn8z1dtFUaM2+FCeWgk3+L/4zTFEO3RxL+7EfzsO1Rl5KFghC5sLigDA/FpvXhmoE MFHeqoU7cZiUSJRJ90xFqKxIY+r/U4DVIniQ5EVIWq0PbCp4xfYrr1p9yfCpTbQ95zRbWVq2b9f o4bSy/xr8KUaVS9sRVbf24SO+TiBG5EWWx2rjOo23GGZFBKAzOo//J/EA1QUYza41dGqxS1BQt3 e1Ue9fZ+HMpGtt/U+8kPAX6MdwaemzGG4qDPanCtSG/SQAC8ZLQR37yyvyaePCTOtgd+EN/JBbY s3u5sbgEDngN0nGItXiO16Do7SavvxILmKK/HIMbH85DUZXy/W9MYGK5mu1TZDOrzlZ+cHQdJ7X fU86e4kYXbobxJbLnIzRzWS2P0w== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [netconf] Regarding 108 adoption hums X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 11:02:54 -0000 Yes to everything you say, Juergen. And, indeed, this is often what an adoption poll is intended to measure. Just saying that (per 7221) you can know these things without a poll, = and (perhaps) your test of adoption suitability will collect exactly = this information so that a further poll will not be necessary. Best, Adrian (who hopes that WG participants will respond carefully to the = seven separate requests for info) -----Original Message----- From: Juergen Schoenwaelder =20 Sent: 07 August 2020 10:17 To: Adrian Farrel Cc: 'Kent Watsen' ; netconf@ietf.org Subject: Re: [netconf] Regarding 108 adoption hums Adrian, technical discussion of the drafts on the mailing list would help more than having process meta-discussions. It is good to know who (other than the authors) is volunteering to substantially review the drafts, is willing to contribute to the discussions of any issues, and is planning to implement the technology defined in the drafts as this will likely help the chairs to make a decision. /js On Fri, Aug 07, 2020 at 09:59:15AM +0100, Adrian Farrel wrote: > Hi chairs, >=20 > I think this is an interesting approach to determining whether there = is interest in a number of drafts at the same time, and I agree with you = that a hum at a working group meeting means nothing without confirming = the opinion on the mailing list. >=20 > But I'm worried that you may be introducing yet another piece of = process into how we process documents. >=20 > The adoption poll, itself, is not necessary if it is obvious to the = chairs that a draft is within charter and has support [RFC7221]. But in = addition to the poll, we also have somehow introduced an IPR poll at = adoption time (while I can see the merits of being explicit about IPR, = and we have seen one or two people attempt to wriggle out of their = responsibilities, it seems unnecessary to serialize the two calls). Now = you appear to be introducing an additional step to test "adoption = suitability". >=20 > Can I urge you (strongly? :-) to consider the responses to you = adoption suitability tests and, if they are solid, to move straight to = adoption without making the working group go though a prolonged series = of polls. We would, I think, prefer to get on with the work! >=20 > Best, > Adrian >=20 > -----Original Message----- > From: netconf On Behalf Of Kent Watsen > Sent: 05 August 2020 23:13 > To: netconf@ietf.org > Subject: [netconf] Regarding 108 adoption hums >=20 >=20 > NETCONF WG, >=20 >=20 > The Chairs & AD discussed the results of the various adoption hums = conducted during the 108 meeting. There is a sense that the results = didn=E2=80=99t adequately determine if the drafts should be adopted. In = particular, it wasn=E2=80=99t clear if the hums reflected a general = desire to solve the problem or support for the particular draft. >=20 > As such, we=E2=80=99ve decided to send subsequent emails for each = draft, or set of drafts if appropriate, to solicit input on following = questions: >=20 > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? >=20 >=20 > NETCONF Chairs >=20 >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=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 Aug 7 04:12:45 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2463A0764 for ; Fri, 7 Aug 2020 04:12: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCWoSgNIPUa4 for ; Fri, 7 Aug 2020 04:12:41 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80129.outbound.protection.outlook.com [40.107.8.129]) (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 4A6D33A073D for ; Fri, 7 Aug 2020 04:12:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eENGiVtBVPYo4VPIQvSCVKZoY6aPxYVYhaNoWrn1eTiibb4NuLBiTywhU0vjr7OGJcRok7o0ISLe8Dk0VSJZj97GMdkTwSdKPcp1YVxiZ6dHA0pmAZ4iJIdIDgHQ607J7+oJQfkRnrfYwezHCmCCFRRbodPxDQLW49TjLkEYXihQaWGV/EHpfx4U4Z1CRoUcmFyhPgk4QX3Mm54Am2B3oGd5uTVHUHq4uhUk85baPNxvzG+6ljP/5kB1cqniSXIR3uRSYM2tzidhCe8D1VGPmraRC0NhwaMf3kJJpwcGpzYem+/R7MnfRg8peJkTKeRRoilq08Vs0Ruxwb3wJ30nuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rr2rc5DWV5URcdFrOUCg4h/iAGu5y5gHZA/dOqhf3M4=; b=fDfY1T/4qxUo+qCKc/tzddTq8xR3hJEk9T+/oyavnUyJpVKRYkSMCtEw623MiJ0/uDdgJkElg9I3SHiRaskHAiKviEsGD3wwTBdMa2TxKlc9t5kqU2WfAn+vHNLq1YCe07HnpjLfuObTHq4HMB5Nwl7Hs0vtYyGEMYpJAz8r8/CQ+3+RPBcrYa8ONLn409kFjAnLD9fTMghZkxj3i2cKzJm+nzgJpOTCl0qbtB4xaarv0vfmdXOd7rkOuKqWpAnVWm2Gj2lUwrp5kgvryBT98v4prYUH7betYa2rP2INGKcLqCR1rzdOGozYruul7XR9JopDlNjSRjTfN2hj4RmjOA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rr2rc5DWV5URcdFrOUCg4h/iAGu5y5gHZA/dOqhf3M4=; b=CtKF427jYpZO1UtK4vnYuI1J7yRsHiKEdIcWI0Az3mUbPLaJ9x1CxXWOkCg6ezPV0DPpnfBmlA03Nv4Tsc3cULmRkLuT3CWB6p7QN+dsvJM469kEgzq5O5uqeml1AOGq0YSeZpqRM7EVxUfbS3943OtojQPkwQOPgMWjFJG17Do= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM7PR07MB6706.eurprd07.prod.outlook.com (2603:10a6:20b:1a6::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.12; Fri, 7 Aug 2020 11:12:38 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::b570:437a:db46:400a]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::b570:437a:db46:400a%9]) with mapi id 15.20.3283.007; Fri, 7 Aug 2020 11:12:38 +0000 From: tom petch To: 'Juergen Schoenwaelder' , "adrian@olddog.co.uk" CC: "netconf@ietf.org" Thread-Topic: [netconf] Regarding 108 adoption hums Thread-Index: AQHWbJkG/zcfmCeL8EOO/Z5e6RwUCaksXeKAgAAdeoCAAAHKLA== Date: Fri, 7 Aug 2020 11:12:38 +0000 Message-ID: References: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> <00cf01d66c99$07392530$15ab6f90$@olddog.co.uk> <20200807091715.vzglsinbh76ox6kz@anna.jacobs.jacobs-university.de>, <00f601d66caa$48a34cb0$d9e9e610$@olddog.co.uk> In-Reply-To: <00f601d66caa$48a34cb0$d9e9e610$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [81.131.229.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d0b19f89-53ae-4c70-c131-08d83ac2cb9c x-ms-traffictypediagnostic: AM7PR07MB6706: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ss4jmGY2SrQ0h/v6LL6xRRpoj+gGdiCZ1rrV6GFJPj2IHWRMFbYzEZyDO7rHjqLyDUvtjLYC77RHkNFdOCqTw1ETXjA1VSrFqK5WMZCO8MnF9VXXSUaG6xEloGCIdHYiCI8uYQ8k65giDyBaCNJiuocWjtp1xhlIoHNNARgmtGK16zozX+5tyMnLiSaQwJbiWz0g2XPqi6CCVCGRnqJsrLmo4XbtL4bnf5kqQ85T34HFfbM65/2EGNIWY7ZjaiiYbTFQlM5j2WyVZFmGbvsnc+kLsn/25hjmmSd39w4scaaqlByF8ypAvodhJV7+7pcci2/rnB757kinBBvVOHOAqhEfa0Sl8sg0duUGROHHGXT3BT/abUeOBSB9L1LddjSrOtK2CTJTxyYwqRzgBKtxeg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(136003)(346002)(396003)(39860400002)(366004)(83080400001)(4326008)(110136005)(2906002)(478600001)(966005)(316002)(83380400001)(86362001)(8676002)(8936002)(5660300002)(52536014)(7696005)(66476007)(66556008)(64756008)(66446008)(9686003)(76116006)(33656002)(91956017)(66946007)(71200400001)(53546011)(6506007)(55016002)(26005)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 0E0AsiF7DZKaiTmoNyUg0fqhAMoh4zAEXu86TxOItKhzoLAppqXGIssDqrQCmYdERKuWcqbHDt7ei9fP6wWitN28aHBTuiy5d6cByUhy+D3y6L8Xa71mjrAFAVQN1ij1GSR1o6iL7VH4SWFU7NZf2k34VIvZamXmy8kmS5wbV7BnMtkSsylVvSBxwzPbV7z+CxBW6kELUf42nUKEVwGIiLM7KBojwGUcYwfE/4nDjjKVI9vjAUE/a8cHaVJGLxsWCv+6A6X2W4w8YPIInxiBhAEW8O/dwcnJEhjQfGv4TYEgFytprQkPaa16d/NBt4TA0sRSpu10ThQVDnZs4ruGcceLK2Kr6anLDTtDCpF2rJE8rSFBa3ecPL7mv1GrwJ5RNKnaF4fmI2AobL5pZxoIuoBcsQipm3lfNCOzUZGWIo63nrdZrIEQCoABThq/jH45xIMci4Ub43k1yunYYKl8hPidcAX79X7Pl3RRulLFabtDPYz35/s/CyrlGeJgtCqQRBWycgToPjMXrBSZzwt8C6UmTxnvZ4rxFBdUxj/2pwbzekk7ORhOrVV0od2xh29/miMIvLHXxwz66iGuMuTJqrMS/VmxOwP7ztRmGey1Woe1SgQSc9PZ1lww5WrxcRSkIDL98mTsyNZkQdxfe5plMg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d0b19f89-53ae-4c70-c131-08d83ac2cb9c X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2020 11:12:38.6233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zfAabrcwMT9/j/hvqhfeKWKK8+UuWJIFOlyX45G4/B362mFJ7C2xfBbKIW6EoezKaIUzU3qdIHIHdvIu593XQQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6706 Archived-At: Subject: Re: [netconf] Regarding 108 adoption hums X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 11:12:44 -0000 From: netconf on behalf of Adrian Farrel =0A= Sent: 07 August 2020 12:02=0A= =0A= Yes to everything you say, Juergen.=0A= =0A= And, indeed, this is often what an adoption poll is intended to measure.=0A= =0A= Just saying that (per 7221) you can know these things without a poll, and (= perhaps) your test of adoption suitability will collect exactly this inform= ation so that a further poll will not be necessary.=0A= =0A= =0A= My left field view is to oppose adoption regardless. The WG has some nine = I-D comprising over 400pp dating in some cases back four years. I think th= at it the WG has any energy then at least some of these need to get to the = IESG before the WG considers more work. Indeed I know of an AD who once ch= anged the WG charter to stop any more work being taken on until the existin= g work had progressed.=0A= =0A= Tom Petch=0A= =0A= Best,=0A= Adrian (who hopes that WG participants will respond carefully to the seven = separate requests for info)=0A= =0A= -----Original Message-----=0A= From: Juergen Schoenwaelder =0A= Sent: 07 August 2020 10:17=0A= To: Adrian Farrel =0A= Cc: 'Kent Watsen' ; netconf@ietf.org=0A= Subject: Re: [netconf] Regarding 108 adoption hums=0A= =0A= Adrian,=0A= =0A= technical discussion of the drafts on the mailing list would help more=0A= than having process meta-discussions. It is good to know who (other=0A= than the authors) is volunteering to substantially review the drafts,=0A= is willing to contribute to the discussions of any issues, and is=0A= planning to implement the technology defined in the drafts as this=0A= will likely help the chairs to make a decision.=0A= =0A= /js=0A= =0A= On Fri, Aug 07, 2020 at 09:59:15AM +0100, Adrian Farrel wrote:=0A= > Hi chairs,=0A= >=0A= > I think this is an interesting approach to determining whether there is i= nterest in a number of drafts at the same time, and I agree with you that a= hum at a working group meeting means nothing without confirming the opinio= n on the mailing list.=0A= >=0A= > But I'm worried that you may be introducing yet another piece of process = into how we process documents.=0A= >=0A= > The adoption poll, itself, is not necessary if it is obvious to the chair= s that a draft is within charter and has support [RFC7221]. But in addition= to the poll, we also have somehow introduced an IPR poll at adoption time = (while I can see the merits of being explicit about IPR, and we have seen o= ne or two people attempt to wriggle out of their responsibilities, it seems= unnecessary to serialize the two calls). Now you appear to be introducing = an additional step to test "adoption suitability".=0A= >=0A= > Can I urge you (strongly? :-) to consider the responses to you adoption s= uitability tests and, if they are solid, to move straight to adoption witho= ut making the working group go though a prolonged series of polls. We would= , I think, prefer to get on with the work!=0A= >=0A= > Best,=0A= > Adrian=0A= >=0A= > -----Original Message-----=0A= > From: netconf On Behalf Of Kent Watsen=0A= > Sent: 05 August 2020 23:13=0A= > To: netconf@ietf.org=0A= > Subject: [netconf] Regarding 108 adoption hums=0A= >=0A= >=0A= > NETCONF WG,=0A= >=0A= >=0A= > The Chairs & AD discussed the results of the various adoption hums conduc= ted during the 108 meeting. There is a sense that the results didn=92t ade= quately determine if the drafts should be adopted. In particular, it wasn= =92t clear if the hums reflected a general desire to solve the problem or s= upport for the particular draft.=0A= >=0A= > As such, we=92ve decided to send subsequent emails for each draft, or set= of drafts if appropriate, to solicit input on following questions:=0A= >=0A= > 1) is the problem important for the NETCONF WG to solve?=0A= > 2) is the draft a suitable basis for the work?=0A= >=0A= >=0A= > NETCONF Chairs=0A= >=0A= >=0A= >=0A= >=0A= > _______________________________________________=0A= > netconf mailing list=0A= > netconf@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/netconf=0A= >=0A= > _______________________________________________=0A= > netconf mailing list=0A= > netconf@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/netconf=0A= =0A= --=0A= Juergen Schoenwaelder Jacobs University Bremen gGmbH=0A= Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany=0A= Fax: +49 421 200 3103 =0A= =0A= _______________________________________________=0A= netconf mailing list=0A= netconf@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netconf=0A= From nobody Fri Aug 7 13:15:49 2020 Return-Path: <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCBC3A08E2 for ; Fri, 7 Aug 2020 13:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9p5EoM9R1Gz for ; Fri, 7 Aug 2020 13:15:46 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7083A046E for ; Fri, 7 Aug 2020 13:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596831345; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=yug7PSQUtr2UfzNxSNNQ65Vc3qxtnwmHv6OydYg9/Og=; b=T6eX8mBegCLEADgQ5hwSPGYYJ7X6knxwHNxPoBZm7X4u+ttAbyN50k35WdlDJt00 RSM+Pz8glLcRJSSfkgm8u7k1BSAyUAE7qUFzu1ju2lUg9Ix+c3mbYsSoK+yDOjgq47Z Qo1XaFUXu1VCtVztC2w9oCR/Yb26A3mUxDyCWW1w= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_44258DED-442A-40AF-9A75-4A75E4D713A3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 7 Aug 2020 20:15:44 +0000 References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> Message-ID: <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.07-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 20:15:48 -0000 --Apple-Mail=_44258DED-442A-40AF-9A75-4A75E4D713A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [as a contributor] > 1) is the problem important for the NETCONF WG to solve? I believe that it is important to enable publishers to send = notifications using a UDP-based transport. This belief is based on my = experience from when at Juniper dealing with very high-end firewalls = with enormous log output. I believe that the NETCONF WG is the appropriate WG for this work, = having defined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN). > 2) is the draft a suitable basis for the work? I have read the current version of the draft and find it to be a = reasonable start. Presuming the =E2=80=9Creceiver-instances=E2=80=9D augmentation defined = in = https://tools.ietf.org/html/draft-ietf-netconf-https-notif-04#section-3 = = takes off, the module defined in this draft should be updated to augment = into it instead. I appreciate Section 5 (Applicability) noting that the UDP-transport is = primarily for the data plane (not the control plane), as it doesn=E2=80=99= t matter so much if data plane notifications are lost. This addresses = (I think) the issue that Rob Shakir raised before: = https://datatracker.ietf.org/doc/minutes-103-netconf = (search for = =E2=80=9CRob S=E2=80=9D). That said, it is unclear to me how a receiver = could configure this while, e.g., configuring control plane = notifications to be sent via a TCP-based transport such as = =E2=80=9Chttps-notif=E2=80=9D. 3) regarding Juergen=E2=80=99s questions: a) I am willing to substantially review the drafts. b) I am willing to contribute to the discussion of any issue. c) I do NOT plan to implement the technology defined. Kent= --Apple-Mail=_44258DED-442A-40AF-9A75-4A75E4D713A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[as a contributor]

   1) is the problem = important for the NETCONF WG to solve?

I = believe that it is important to enable publishers to send notifications = using a UDP-based transport.   This belief is based on my = experience from when at Juniper dealing with very high-end firewalls = with enormous log output.

I = believe that the NETCONF WG is the appropriate WG = for this work, having defined RFC 8639 (SN), RFC = 8640 (NN), and RFC 8650 (RN).


   2) is the draft a suitable = basis for the work?

I have read the current version of the draft = and find it to be a reasonable start.

Presuming the =E2=80=9Creceiver-instances= =E2=80=9D augmentation defined in https://tools.ietf.org/html/draft-ietf-netconf-https-notif-04#s= ection-3 takes off, the module defined in this draft should be = updated to augment into it instead.

I appreciate Section 5 = (Applicability) noting that the UDP-transport is primarily for the data = plane (not the control plane), as it doesn=E2=80=99t matter so much if = data plane notifications are lost.  This addresses (I think) the = issue that Rob Shakir raised before: https://datatracker.ietf.org/doc/minutes-103-netconf (= search for =E2=80=9CRob S=E2=80=9D).  That said, it is unclear to = me how a receiver could configure this while, e.g., configuring control = plane notifications to be sent via a TCP-based transport such as = =E2=80=9Chttps-notif=E2=80=9D.


3) regarding Juergen=E2=80=99s questions:

  a) I am willing to substantially review the = drafts.
  b) I am willing to contribute to the = discussion of any issue.
  c) I do NOT plan to = implement the technology defined.



Kent
= --Apple-Mail=_44258DED-442A-40AF-9A75-4A75E4D713A3-- From nobody Fri Aug 7 13:16:07 2020 Return-Path: <01000173ca90e445-85996493-cdee-40cc-b98b-83347f2c800c-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8943A091B for ; Fri, 7 Aug 2020 13:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdOtu9cUjvhr for ; Fri, 7 Aug 2020 13:16:02 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BEE3A09F6 for ; Fri, 7 Aug 2020 13:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596831360; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=G3PIPxFa5hnkIn7l7VKaODv88irtcnfMypJr8TkVQ2E=; b=i3OSOZyG9OGeGTreCLU5cGh0Ed8x+dslfXTV0XKLJjXGmUnt8RPjM1Bgqn+Kh+4/ TAcP2cnHGeibRtgXaCmBNYQcKk4w2tIi1uIlfkEQ44sPefK3dsIIjcc4SL/FgXYfbiZ 2fMAIPryp8poZfheTFXj0cUQITaNJbyRWELSwe8k= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_0F9ECAA7-2D62-4544-BC3B-CA1D6A9C9180" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 7 Aug 2020 20:16:00 +0000 References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> Message-ID: <01000173ca90e445-85996493-cdee-40cc-b98b-83347f2c800c-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.07-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 20:16:05 -0000 --Apple-Mail=_0F9ECAA7-2D62-4544-BC3B-CA1D6A9C9180 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [as a contributor] > 1) is the problem important for the NETCONF WG to solve? I believe that it is important to enable publishers to send = notifications directly from line cards. This belief is based on my = experience from when at Juniper dealing with very high-end firewalls = with enormous log output. I believe that the NETCONF WG is the appropriate WG for this work, = having defined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN). > 2) is the draft a suitable basis for the work? I have read the current version of the draft and find it to be a = reasonable start. Presuming the ability to use a transport outside of SN, as described by = http-motif, is maintained, it may be useful if this draft could describe = how to do that also. That said, if all equipment having a multiplicity = of publisher-agents will uses SN, then this isn=E2=80=99t needed. = [Note: the =E2=80=9Chttps-notif=E2=80=9D draft=E2=80=99s intention is to = enable simple implementations, e.g., no multiplicity of = publisher-agents.] 3) regarding Juergen=E2=80=99s questions: a) I am willing to substantially review the drafts. b) I am willing to contribute to the discussion of any issue. c) I do NOT plan to implement the technology defined. Kent --Apple-Mail=_0F9ECAA7-2D62-4544-BC3B-CA1D6A9C9180 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[as a = contributor]

    1) is the = problem important for the NETCONF WG to = solve?

I believe that it is important to enable = publishers to send notifications directly from line cards.   This = belief is based on my experience from when at Juniper dealing with very = high-end firewalls with enormous log output.

I believe that the NETCONF WG is the appropriate WG for this work, = having defined RFC 8639 (SN), RFC 8640 (NN), and RFC = 8650 (RN).


    2) is the draft a suitable basis = for the work?

I have read the current version of the draft and find = it to be a reasonable start.

Presuming the ability to use a = transport outside of SN, as described by http-motif, is maintained, it may be useful = if this draft could describe how to do that also.  That said, = if all equipment having a multiplicity of publisher-agents = will uses SN, then this isn=E2=80=99t needed.  [Note: = the =E2=80=9Chttps-notif=E2=80=9D draft=E2=80=99s intention is to = enable simple implementations, e.g., no multiplicity of publisher-agents.]




3) = regarding Juergen=E2=80=99s questions:

  a) I am willing to substantially review the = drafts.
  b) I am willing to contribute to the = discussion of any issue.
  c) I do NOT plan to = implement the technology defined.



Kent

= --Apple-Mail=_0F9ECAA7-2D62-4544-BC3B-CA1D6A9C9180-- From nobody Fri Aug 7 14:02:05 2020 Return-Path: <01000173cabb057c-4236d605-0617-411c-a237-cd60f7545b79-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272873A0AB6 for ; Fri, 7 Aug 2020 14:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9y6cFmrwt-8 for ; Fri, 7 Aug 2020 14:02:02 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4B93A0AB0 for ; Fri, 7 Aug 2020 14:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596834121; h=From:Message-Id:Content-Type:Mime-Version:Date:Subject:In-Reply-To:To:References:Feedback-ID; bh=nXbAiI00+XMwUrtuAwu/KDMWQbh+BoEQvafo0PwiSO0=; b=WCl1pGwR77iJZ5vGn/rezJU3JqVFRd6irgawS3w2y43+fuYxI035mRQAcvd0rJob xIw2MQk2oq37H1wTv4j8ss45coX9KRgrLlGBADyPH0qtPySgAbTJpbj0uVk0UUs08yW SHi1iNJBfQ/MGAGVuOW0kw6J+Exs3Cbw9aKXNi0Q= From: Kent Watsen Message-ID: <01000173cabb057c-4236d605-0617-411c-a237-cd60f7545b79-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_06E2940F-2F20-481D-B790-D43F485694BA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 7 Aug 2020 21:02:01 +0000 In-Reply-To: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> To: "netconf@ietf.org" References: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.07-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 21:02:04 -0000 --Apple-Mail=_06E2940F-2F20-481D-B790-D43F485694BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [as a contributor and co-author] Per the request below: 1) is the problem important for the NETCONF WG to solve? I believe that it is important to enable the SZTP bootstrapping process = to be able to configure an LDevID certificate. As the presentation = mentioned, it is the ONLY way to enable use cases whereby the device = must join a dynamically-provisioned network slice. The ability to do = this was requested by a 3rd-party (my co-authors may have more to say = about this). And I believe that the NETCONF WG is the appropriate WG for this work, = having defined RFC 8572 (SZTP). 2) is the draft a suitable basis for the work? I believe the current version of the draft is a more than a reasonable = start. I would say that it's practically ready for Last Call (all = sections were filled in), but I=E2=80=99m aware that my co-authors = believe that one or two more CSR-types should be added to reflect = real-world CA deployments. 3) regarding Juergen=E2=80=99s questions: a) I am willing to substantially review the drafts. b) I am willing to contribute to the discussion of any issue. c) I plan to implement the technology defined. Kent > NETCONF WG, >=20 > Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft: >=20 > Title: Conveying a CSR in an SZTP Bootstrapping Request > Link: https://tools.ietf.org/html/ = draft-kwatsen-netconf-sztp-csr > Abstract: >=20 > This draft extends the "get-bootstrapping-data" RPC defined in > RFC 8572 to include an optional certificate signing request = (CSR), > enabling a bootstrapping device to additionally obtain an = identity > certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the > "onboarding information" response provided in the RPC-reply. >=20 >=20 > In particular, please discuss adoption-suitability as it regards to = the following questions: >=20 > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? >=20 >=20 > PS: this message is itself not an adoption poll, but rather an attempt = to gauge interest/support for a potential future adoption poll. >=20 > NETCONF Chairs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_06E2940F-2F20-481D-B790-D43F485694BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [as = a contributor and co-author]


Per the request = below:

1) is = the problem important for the NETCONF WG to solve?

I believe that it = is important to enable the SZTP bootstrapping process to be able to = configure an LDevID certificate.  As the presentation mentioned, it = is the ONLY way to enable use cases whereby the device must join a = dynamically-provisioned network slice.  The ability to do this was = requested by a 3rd-party (my co-authors may have more to say about = this).

And I believe that the = NETCONF WG is the appropriate WG for this work, having defined RFC 8572 = (SZTP).


2) is the draft a = suitable basis for the work?

I = believe the current version of the draft is a more than a reasonable = start.  I would say that it's practically ready for Last = Call (all sections were filled in), but I=E2=80=99m aware that my = co-authors believe that one or two more CSR-types should be added to = reflect real-world CA deployments.


3) regarding Juergen=E2=80=99s questions:

  a) I am willing to substantially review the = drafts.
  b) I am willing to contribute to the = discussion of any issue.
  c) I plan to implement the = technology defined.


Kent


NETCONF = WG,

Per the previous email = sent moments ago, the chairs would like to solicit input on the = following draft:

  =  Title: Conveying a CSR in an SZTP Bootstrapping = Request
   Link: https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr
   Abstract:

      = This draft extends the "get-bootstrapping-data" RPC defined = in
      = RFC 8572 to include an optional certificate signing request = (CSR),
      enabling a bootstrapping = device to additionally obtain an identity
      certificate (e.g., an LDevID, from IEEE = 802.1AR) as part of the
  =     "onboarding information" response provided in the = RPC-reply.


In particular, please discuss = adoption-suitability as it regards to the following = questions:

    1) is the problem important for the = NETCONF WG to solve?
    2) is the draft a = suitable basis for the work?


PS: this message is itself = not an adoption poll, but rather an attempt to gauge interest/support = for a potential future adoption poll.

NETCONF= = Chairs
____________________________________________= ___
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

= --Apple-Mail=_06E2940F-2F20-481D-B790-D43F485694BA-- From nobody Fri Aug 7 16:13:32 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF7C3A0985 for ; Fri, 7 Aug 2020 16:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJJnyE3zHEUr for ; Fri, 7 Aug 2020 16:13:29 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 253BD3A08E1 for ; Fri, 7 Aug 2020 16:13:28 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id v9so3844515ljk.6 for ; Fri, 07 Aug 2020 16:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8Zgyr1yq4t0MKNG+XoJM9T+ZUKa3xqzXX0/Lhh8ROWI=; b=w/b2hT950Z9jGCYOj6691w7GwDEI+fS+y82JwzL9D4M3EQdSbF/zkxEKaCWDiP71qO EWrdujMZiv8jlDgYK+LaWEciB5K/l+n1AIxeUzeIbFD8kIzQJZKzQPWA9UPm3MEYLIAD Iipv74wrQ9YidBothAREVomRszWbBzfEcK5eFLT0I0ZFR1+cmsow28OSRAM6nvw7iUXP RY9qq42gBC5w1gPaQchgiKQrtle2EU9nuWimV6Phq9Cq881SgL8wsiEZGvklpdId5Snq UK38jO+VIjO4br++fAJToo4Z54NkOejLG+VsgJ+jY4nGi8RDafmC2Cq7LTWnHCFNSriq 3CpQ== 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=8Zgyr1yq4t0MKNG+XoJM9T+ZUKa3xqzXX0/Lhh8ROWI=; b=g0bp41WCwpbU7T4paQ6reRakv4QmhIWakTyU3v1i6GPBl8jYZTXEYam/dfJiBNR96P GTrdxPS53re4JyAHuVJcu2METFNj+GWgAupoVspC4CUuTLcOoCj0Ezulq9hiTAXQr/+Q wUvM7PyyyPjPPN0Ye/afINRGsu9EdRTNhHfJ4DrSDlcB6CcBRvNrU7Y8QNZzyo+4slKM awADWPnDn0fkB+91T/O6edBXzwureKwdxoTSf0g9TnrWGluU9bxQ3rwF8d+U7syZZdp+ Nw2Yx1MUAw357ptq9P8VtE2EiB0S5lbR/aB2EBwd+R5uvP1dIlkJrRLdjgaQxcMfvCVP zVhA== X-Gm-Message-State: AOAM532wjmDMogmO37AlHqTnnj9r+Jg7MiEEb+sVNm5G0vzGSHJE6VXF YT4nep4ydhAZD5VAVdC9HfcJpZ4VRcnnc5BulmpTXmAX X-Google-Smtp-Source: ABdhPJx07+pB9ak8DoOeLx1kGc7EDeitSMDrhh3WEWbqiDVXpH7fJRjLtIdKgbckW4W6BuWhnNXC2p/yQREY6/9EVn8= X-Received: by 2002:a2e:9dd0:: with SMTP id x16mr7008015ljj.144.1596842007008; Fri, 07 Aug 2020 16:13:27 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> <00cf01d66c99$07392530$15ab6f90$@olddog.co.uk> <20200807091715.vzglsinbh76ox6kz@anna.jacobs.jacobs-university.de> In-Reply-To: <20200807091715.vzglsinbh76ox6kz@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Fri, 7 Aug 2020 16:13:16 -0700 Message-ID: To: Juergen Schoenwaelder , Adrian Farrel , Kent Watsen , Netconf Content-Type: multipart/alternative; boundary="00000000000097346905ac51c050" Archived-At: Subject: Re: [netconf] Regarding 108 adoption hums X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 23:13:31 -0000 --00000000000097346905ac51c050 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Fri, Aug 7, 2020 at 2:17 AM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Adrian, > > technical discussion of the drafts on the mailing list would help more > than having process meta-discussions. It is good to know who (other > than the authors) is volunteering to substantially review the drafts, > is willing to contribute to the discussions of any issues, and is > planning to implement the technology defined in the drafts as this > will likely help the chairs to make a decision. > IMO it makes more sense to discuss what problems the NETCONF/NETMOD WGs should be solving, rather than adoption of solutions to problems. The WG should be finishing up configured notifications. Try to standardize binary telemetry instead of just leaving placeholders for proprietary vendor solutions. Your questions are most relevant because we do not have any clear definitio= n or "support" or "oppose" for adoption of a draft. Support often means "I am happy for you to work on this draft". The culture of the IETF creates a strong bias against anybody actually opposing adoption of anything. Usual attitude: "Let people experiment. Maybe they will come up with something good in the end." If only the co-authors support, and nobody opposes, then the work will get stuck. Often WGs adopt after such a poll outcome and act surprised a year later when the draft goes nowhere. Andy > /js > > On Fri, Aug 07, 2020 at 09:59:15AM +0100, Adrian Farrel wrote: > > Hi chairs, > > > > I think this is an interesting approach to determining whether there is > interest in a number of drafts at the same time, and I agree with you tha= t > a hum at a working group meeting means nothing without confirming the > opinion on the mailing list. > > > > But I'm worried that you may be introducing yet another piece of proces= s > into how we process documents. > > > > The adoption poll, itself, is not necessary if it is obvious to the > chairs that a draft is within charter and has support [RFC7221]. But in > addition to the poll, we also have somehow introduced an IPR poll at > adoption time (while I can see the merits of being explicit about IPR, an= d > we have seen one or two people attempt to wriggle out of their > responsibilities, it seems unnecessary to serialize the two calls). Now y= ou > appear to be introducing an additional step to test "adoption suitability= ". > > > > Can I urge you (strongly? :-) to consider the responses to you adoption > suitability tests and, if they are solid, to move straight to adoption > without making the working group go though a prolonged series of polls. W= e > would, I think, prefer to get on with the work! > > > > Best, > > Adrian > > > > -----Original Message----- > > From: netconf On Behalf Of Kent Watsen > > Sent: 05 August 2020 23:13 > > To: netconf@ietf.org > > Subject: [netconf] Regarding 108 adoption hums > > > > > > NETCONF WG, > > > > > > The Chairs & AD discussed the results of the various adoption hums > conducted during the 108 meeting. There is a sense that the results didn= =E2=80=99t > adequately determine if the drafts should be adopted. In particular, it > wasn=E2=80=99t clear if the hums reflected a general desire to solve the = problem or > support for the particular draft. > > > > As such, we=E2=80=99ve decided to send subsequent emails for each draft= , or set > of drafts if appropriate, to solicit input on following questions: > > > > 1) is the problem important for the NETCONF WG to solve? > > 2) is the draft a suitable basis for the work? > > > > > > NETCONF Chairs > > > > > > > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --00000000000097346905ac51c050 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,


On Fri, Aug 7, 2020 at 2:17 AM Juer= gen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Adrian,

technical discussion of the drafts on the mailing list would help more
than having process meta-discussions. It is good to know who (other
than the authors) is volunteering to substantially review the drafts,
is willing to contribute to the discussions of any issues, and is
planning to implement the technology defined in the drafts as this
will likely help the chairs to make a decision.


IMO it makes more sense to discuss what problems th= e NETCONF/NETMOD WGs
should be solving, rather than adoption of s= olutions=C2=A0to problems. The WG should be
finishing up configur= ed notifications. Try to standardize binary telemetry instead
of = just leaving placeholders for proprietary vendor solutions.

<= /div>
Your questions are most relevant because we do not have any clear= definition
or "support" or "oppose" for adop= tion of a draft.
Support often means "I am happy for you to = work on this draft".
The culture of the IETF creates a stron= g bias against anybody actually
opposing adoption of anything. Us= ual attitude: "Let people experiment. Maybe they will
come u= p with something good in the end."

If only th= e co-authors support, and nobody opposes, then the work will get stuck.
Often WGs adopt after such a poll outcome and act surprised=C2=A0a y= ear later when
the draft goes nowhere.

<= br>
Andy



<= br>


/js

On Fri, Aug 07, 2020 at 09:59:15AM +0100, Adrian Farrel wrote:
> Hi chairs,
>
> I think this is an interesting approach to determining whether there i= s interest in a number of drafts at the same time, and I agree with you tha= t a hum at a working group meeting means nothing without confirming the opi= nion on the mailing list.
>
> But I'm worried that you may be introducing yet another piece of p= rocess into how we process documents.
>
> The adoption poll, itself, is not necessary if it is obvious to the ch= airs that a draft is within charter and has support [RFC7221]. But in addit= ion to the poll, we also have somehow introduced an IPR poll at adoption ti= me (while I can see the merits of being explicit about IPR, and we have see= n one or two people attempt to wriggle out of their responsibilities, it se= ems unnecessary to serialize the two calls). Now you appear to be introduci= ng an additional step to test "adoption suitability".
>
> Can I urge you (strongly? :-) to consider the responses to you adoptio= n suitability tests and, if they are solid, to move straight to adoption wi= thout making the working group go though a prolonged series of polls. We wo= uld, I think, prefer to get on with the work!
>
> Best,
> Adrian
>
> -----Original Message-----
> From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
> Sent: 05 August 2020 23:13
> To: netconf@ietf= .org
> Subject: [netconf] Regarding 108 adoption hums
>
>
> NETCONF WG,
>
>
> The Chairs & AD discussed the results of the various adoption hums= conducted during the 108 meeting.=C2=A0 There is a sense that the results = didn=E2=80=99t adequately determine if the drafts should be adopted.=C2=A0 = In particular, it wasn=E2=80=99t clear if the hums reflected a general desi= re to solve the problem or support for the particular draft.
>
> As such, we=E2=80=99ve decided to send subsequent emails for each draf= t, or set of drafts if appropriate, to solicit input on following questions= :
>
>=C2=A0 =C2=A0 =C2=A01) is the problem important for the NETCONF WG to s= olve?
>=C2=A0 =C2=A0 =C2=A02) is the draft a suitable basis for the work?
>
>
> NETCONF Chairs
>
>
>
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org=
> https://www.ietf.org/mailman/listinfo/netconf<= br> >
> _______________________________________________
> netconf mailing list
> netconf@ietf.org=
> https://www.ietf.org/mailman/listinfo/netconf<= br>
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--00000000000097346905ac51c050-- From nobody Fri Aug 7 17:51:16 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5423A0E36 for ; Fri, 7 Aug 2020 17:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5tLXSEQBLtf for ; Fri, 7 Aug 2020 17:51:12 -0700 (PDT) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 D5FD63A0953 for ; Fri, 7 Aug 2020 17:51:12 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id ha11so1866694pjb.1 for ; Fri, 07 Aug 2020 17:51:12 -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=zk6/Mkj369LhuD2Bbak/vH6prNaB3jS6uDsodNuFonY=; b=XMEWtDKURdRiortf0POAuUMF7kU7PoIMmEshwBbRHOycBYK4dXGifdxqH0T/3yiEva eElZoCmyd+7FIl/xQPCwxHlxFh+OKChZ6ieriHoSv8G7E/O33OgTNztGgwMRyHovMsXm 1f/7ugZom4ikX9gTFU04hzcfCmLbNzZ0dFPnRNu1tFHarfC86r98MdmM73EIFaT41XD7 gSVrG+Dbh6JYepCv2Af9VrtAWQ3vEj0t9A3p1cSyBQc4Djn9a6Dv6kCgyQKRei5ncOGi EleqamOizaJBgTUThN/AfgvCGV5kksKm77JG3EuHehAC+i+b25BKvffz3AkxYva3a/B9 lFOA== 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=zk6/Mkj369LhuD2Bbak/vH6prNaB3jS6uDsodNuFonY=; b=MoLHHJ7v/niUKQAEjnNhSH4ZP2xTTnbDnZUY6XyHyf2xobE/lVDB5jnOtdCQp/tnnI 7L6kP25uK5a07aA/mMiqwVGSz7KuOdDsjTYaUbTvGh5cDAd2omT1Eb3BRNUIj3p0RPio Nb9o7DnSDqsh77BP5XEm4oKuAbx+qIf5Frz74QlMClU2A6PgI+zjxoljwf255vwdGjmj I3Eemy35yWTfcL4ybhvXGX0zxYE9I6XtJv3O7sVwhcDdXFpXZFo43yBN5dSS1sFN1P9T Dvwtkeh1BKwB6TUdNvmWoK/b1sOerrKxzgqyXklItZmV7nYSlBe9fYTEQ2Nc+37YJmwo IOTQ== X-Gm-Message-State: AOAM532ZrgSnfaYqUucWu+0QmSOLaPg17XEjSa+iW0hWearQAvIvz33F dZKXIeAkyIVVCL1GtguI4TNKMU/b X-Google-Smtp-Source: ABdhPJx1uut/KNcc12f8ayyC8/dlVi1zzvYUnax3xKyqlmSFH1z3kM1PB1t6VobX+q3wNRABAzdmng== X-Received: by 2002:a17:90a:fca:: with SMTP id 68mr15104257pjz.12.1596847871710; Fri, 07 Aug 2020 17:51:11 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:80d4:b3f6:f7e0:2acf? ([2601:647:5600:5020:80d4:b3f6:f7e0:2acf]) by smtp.gmail.com with ESMTPSA id w15sm10139442pjk.13.2020.08.07.17.51.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Aug 2020 17:51:09 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <721B3690-34A3-418D-82E2-7F153A71CA21@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F653195D-F02D-4C33-81DA-C32D1AEDCE0D" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\)) Date: Fri, 7 Aug 2020 17:51:08 -0700 In-Reply-To: To: Netconf References: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> <00cf01d66c99$07392530$15ab6f90$@olddog.co.uk> <20200807091715.vzglsinbh76ox6kz@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.9.6) Archived-At: Subject: Re: [netconf] Regarding 108 adoption hums X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 00:51:15 -0000 --Apple-Mail=_F653195D-F02D-4C33-81DA-C32D1AEDCE0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 7, 2020, at 4:13 PM, Andy Bierman wrote: >=20 > Hi, >=20 >=20 > On Fri, Aug 7, 2020 at 2:17 AM Juergen Schoenwaelder = > wrote: > Adrian, >=20 > technical discussion of the drafts on the mailing list would help more > than having process meta-discussions. It is good to know who (other > than the authors) is volunteering to substantially review the drafts, > is willing to contribute to the discussions of any issues, and is > planning to implement the technology defined in the drafts as this > will likely help the chairs to make a decision. >=20 >=20 > IMO it makes more sense to discuss what problems the NETCONF/NETMOD = WGs > should be solving, rather than adoption of solutions to problems. Precisely.=20 Coming out of the meeting, it was not clear to us (the chairs, at = least), whether the problem the drafts were describing are issues the WG = wanted to see solved. We are hoping that the individual e-mails on the = drafts trigger the kind of technical discussion that leads us to get a = gauge of what the WG thinks are the problems they want to see solved, or = not solved. As Juergen suggests, when responding, it would be great to = see who, outside the pool of authors, is willing to review the drafts, = contribute to the discussion of the draft, and is planning to implement = the draft.=20 For us it will also answer the process question of whether the drafts = should be adopted or not, in which case we can skip the adoption poll. > The WG should be > finishing up configured notifications. Try to standardize binary = telemetry instead > of just leaving placeholders for proprietary vendor solutions. Good point. While we are at it, we should discuss whether these are = problems WG should be working on. >=20 > Your questions are most relevant because we do not have any clear = definition > or "support" or "oppose" for adoption of a draft. > Support often means "I am happy for you to work on this draft". > The culture of the IETF creates a strong bias against anybody actually > opposing adoption of anything. Usual attitude: "Let people experiment. = Maybe they will > come up with something good in the end." >=20 > If only the co-authors support, and nobody opposes, then the work will = get stuck. > Often WGs adopt after such a poll outcome and act surprised a year = later when > the draft goes nowhere. >=20 >=20 > Andy >=20 >=20 >=20 >=20 >=20 >=20 > /js >=20 > On Fri, Aug 07, 2020 at 09:59:15AM +0100, Adrian Farrel wrote: > > Hi chairs, > >=20 > > I think this is an interesting approach to determining whether there = is interest in a number of drafts at the same time, and I agree with you = that a hum at a working group meeting means nothing without confirming = the opinion on the mailing list. > >=20 > > But I'm worried that you may be introducing yet another piece of = process into how we process documents. > >=20 > > The adoption poll, itself, is not necessary if it is obvious to the = chairs that a draft is within charter and has support [RFC7221]. But in = addition to the poll, we also have somehow introduced an IPR poll at = adoption time (while I can see the merits of being explicit about IPR, = and we have seen one or two people attempt to wriggle out of their = responsibilities, it seems unnecessary to serialize the two calls). Now = you appear to be introducing an additional step to test "adoption = suitability". > >=20 > > Can I urge you (strongly? :-) to consider the responses to you = adoption suitability tests and, if they are solid, to move straight to = adoption without making the working group go though a prolonged series = of polls. We would, I think, prefer to get on with the work! > >=20 > > Best, > > Adrian > >=20 > > -----Original Message----- > > From: netconf > On Behalf Of Kent Watsen > > Sent: 05 August 2020 23:13 > > To: netconf@ietf..org > > Subject: [netconf] Regarding 108 adoption hums > >=20 > >=20 > > NETCONF WG, > >=20 > >=20 > > The Chairs & AD discussed the results of the various adoption hums = conducted during the 108 meeting. There is a sense that the results = didn=E2=80=99t adequately determine if the drafts should be adopted. In = particular, it wasn=E2=80=99t clear if the hums reflected a general = desire to solve the problem or support for the particular draft. > >=20 > > As such, we=E2=80=99ve decided to send subsequent emails for each = draft, or set of drafts if appropriate, to solicit input on following = questions: > >=20 > > 1) is the problem important for the NETCONF WG to solve? > > 2) is the draft a suitable basis for the work? > >=20 > >=20 > > NETCONF Chairs > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf = > >=20 > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf = >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_F653195D-F02D-4C33-81DA-C32D1AEDCE0D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 7, 2020, at 4:13 PM, Andy Bierman <andy@yumaworks.com> = wrote:

Hi,


On Fri, Aug 7, 2020 at 2:17 AM Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Adrian,

technical discussion of the drafts on the = mailing list would help more
than having process = meta-discussions. It is good to know who (other
than the = authors) is volunteering to substantially review the drafts,
is willing to contribute to the discussions of any issues, = and is
planning to implement the technology defined in the = drafts as this
will likely help the chairs to make a = decision.


IMO = it makes more sense to discuss what problems the NETCONF/NETMOD = WGs
should be solving, rather than adoption of = solutions to problems. =

Precisely. 

Coming out of the meeting, it was not clear to us = (the chairs, at least), whether the problem the drafts were describing = are issues the WG wanted to see solved. We are hoping that the = individual e-mails on the drafts trigger the kind of technical = discussion that leads us to get a gauge of what the WG thinks are the = problems they want to see solved, or not solved. As Juergen suggests, = when responding, it would be great to see who, outside the pool of = authors, is willing to review the drafts, contribute to the discussion = of the draft, and is planning to implement the = draft. 

For us it will also = answer the process question of whether the drafts should be adopted or = not, in which case we can skip the adoption poll.

The WG = should be
finishing up configured notifications. = Try to standardize binary telemetry instead
of just = leaving placeholders for proprietary vendor = solutions.

Good point. While we are at it, we should discuss = whether these are problems WG should be working on.


Your questions are most relevant = because we do not have any clear definition
or = "support" or "oppose" for adoption of a draft.
Support often means "I am happy for you to work on this = draft".
The culture of the IETF creates a strong = bias against anybody actually
opposing adoption of = anything. Usual attitude: "Let people experiment. Maybe they = will
come up with something good in the = end."

If only = the co-authors support, and nobody opposes, then the work will get = stuck.
Often WGs adopt after such a poll outcome = and act surprised a year later when
the draft = goes nowhere.


Andy






/js

On = Fri, Aug 07, 2020 at 09:59:15AM +0100, Adrian Farrel wrote:
> Hi chairs,
> 
> I think = this is an interesting approach to determining whether there is interest = in a number of drafts at the same time, and I agree with you that a hum = at a working group meeting means nothing without confirming the opinion = on the mailing list.
> 
> But I'm = worried that you may be introducing yet another piece of process into = how we process documents.
> 
> The = adoption poll, itself, is not necessary if it is obvious to the chairs = that a draft is within charter and has support [RFC7221]. But in = addition to the poll, we also have somehow introduced an IPR poll at = adoption time (while I can see the merits of being explicit about IPR, = and we have seen one or two people attempt to wriggle out of their = responsibilities, it seems unnecessary to serialize the two calls). Now = you appear to be introducing an additional step to test "adoption = suitability".
> 
> Can I = urge you (strongly? :-) to consider the responses to you adoption = suitability tests and, if they are solid, to move straight to adoption = without making the working group go though a prolonged series of polls. = We would, I think, prefer to get on with the work!
> 
> = Best,
> Adrian
> 
> = -----Original Message-----
> From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
> Sent: 05 August 2020 23:13
> To: netconf@ietf..org
> Subject: [netconf] = Regarding 108 adoption hums
> 
> 
> NETCONF = WG,
> 
> 
> The = Chairs & AD discussed the results of the various adoption hums = conducted during the 108 meeting.  There is a sense that the = results didn=E2=80=99t adequately determine if the drafts should be = adopted.  In particular, it wasn=E2=80=99t clear if the hums = reflected a general desire to solve the problem or support for the = particular draft.
> 
> As = such, we=E2=80=99ve decided to send subsequent emails for each draft, or = set of drafts if appropriate, to solicit input on following = questions:
> 
>  =    1) is the problem important for the NETCONF WG to solve?
>     2) is the draft a suitable basis for = the work?
> 
> 
> NETCONF = Chairs
> 
> 
> 
> 
> = _______________________________________________
> = netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen = Schoenwaelder           Jacobs University = Bremen gGmbH
Phone: +49 421 200 3587      =    Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103        =  <https://www.jacobs-university.de/>
_______________________________________________
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

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_F653195D-F02D-4C33-81DA-C32D1AEDCE0D-- From nobody Sat Aug 8 09:18:54 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4409B3A0929 for ; Sat, 8 Aug 2020 09:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 2GBJHjLnb5Gt for ; Sat, 8 Aug 2020 09:18:51 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2C23A0912 for ; Sat, 8 Aug 2020 09:18:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 87489300B7D for ; Sat, 8 Aug 2020 12:18:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UsOAnSRijqZH for ; Sat, 8 Aug 2020 12:18:46 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id D7A9C300AA4 for ; Sat, 8 Aug 2020 12:18:46 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_4F4738BC-AF93-4824-9598-0170CC83D6D4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Sat, 8 Aug 2020 12:18:48 -0400 References: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> <01000173cabb057c-4236d605-0617-411c-a237-cd60f7545b79-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <01000173cabb057c-4236d605-0617-411c-a237-cd60f7545b79-000000@email.amazonses.com> Message-Id: <802E95DD-AFD4-434F-B38C-E37A02242AAA@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 16:18:53 -0000 --Apple-Mail=_4F4738BC-AF93-4824-9598-0170CC83D6D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > NETCONF WG, >=20 > Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft: >=20 > Title: Conveying a CSR in an SZTP Bootstrapping Request > Link: https://tools.ietf.org/html/ = draft-kwatsen-netconf-sztp-csr > Abstract: >=20 > This draft extends the "get-bootstrapping-data" RPC defined in > RFC 8572 to include an optional certificate signing request = (CSR), > enabling a bootstrapping device to additionally obtain an = identity > certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the > "onboarding information" response provided in the RPC-reply. >=20 >=20 > In particular, please discuss adoption-suitability as it regards to = the following questions: >=20 > 1) is the problem important for the NETCONF WG to solve? I believe that it is important to configure an LDevID certificate as = part of the bootstrap, and authentication based on the IDevID seems like = the most pragmatic way to do so. > 2) is the draft a suitable basis for the work? As a co-author I am biased; however, I think this is a good start at the = work to be done. I am aware of one implementation that is underway. If adopted, I am willing to continue to work on the document as a = co-author. Russ --Apple-Mail=_4F4738BC-AF93-4824-9598-0170CC83D6D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

NETCONF WG,

Per the previous email sent moments ago, the chairs would = like to solicit input on the following draft:

   Title: Conveying a CSR in = an SZTP Bootstrapping Request
   Link: https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr
   Abstract:

      = This draft extends the "get-bootstrapping-data" RPC defined = in
      = RFC 8572 to include an optional certificate signing request = (CSR),
      enabling a bootstrapping = device to additionally obtain an identity
      certificate (e.g., an LDevID, from IEEE = 802.1AR) as part of the
  =     "onboarding information" response provided in the = RPC-reply.


In particular, please discuss = adoption-suitability as it regards to the following = questions:

    1) is the problem important for the = NETCONF WG to solve?

I believe that it is = important to configure an LDevID certificate as part of the bootstrap, = and authentication based on the IDevID seems like the most pragmatic way = to do so.

    2) is the draft a suitable basis for the = work?

As a co-author I am biased; however, I think this is a = good start at the work to be done.  I am aware of one = implementation that is underway.

If adopted, I am willing to continue to = work on the document as a co-author.

Russ


= --Apple-Mail=_4F4738BC-AF93-4824-9598-0170CC83D6D4-- From nobody Mon Aug 10 00:31:01 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25ED3A0895 for ; Mon, 10 Aug 2020 00:30:59 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.395 X-Spam-Level: X-Spam-Status: No, score=0.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=1.5, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=foxmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnR7ZjHc8ksI for ; Mon, 10 Aug 2020 00:30:56 -0700 (PDT) Received: from qq.com (out203-205-221-231.mail.qq.com [203.205.221.231]) (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 E7E663A1410 for ; Mon, 10 Aug 2020 00:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1597044642; bh=f1hQnU841ppPcRiZTKp0SJCPdfjgQ7k50DDgk5sPfAE=; h=Date:From:To:Cc:Subject:References; b=EfZ03pRiaBsOi0aonmsmPxbmwVmehOaCyF+AbCU00K0qro2Pz2c7mOf1LJOkRB89X sCV2yx68f2IUZjv/x3iDdJtSP3lSa2r4P/yP4E3hVNBGfH5WRgd792c3MdYYOexwIm +pI2HCDBU+GozAGPlX1AGHvv3udCRMv0GKM7gaH4= Received: from cmcc-PC ([221.130.253.135]) by newxmesmtplogicsvrszc8.qq.com (NewEsmtp) with SMTP id 7A88C8CE; Mon, 10 Aug 2020 15:30:40 +0800 X-QQ-mid: xmsmtpt1597044640tkp4g3vkz Message-ID: X-QQ-XMAILINFO: McXBXMazpRh64NiMYY+Z3JDiG8MFccpcWZEasbPt6QFbMfFUIpE/i/jFQFp3pn +Hie3Sblf66KSVLdmPXA6ydUmh3CeH2h14rfoV99l3a02v83M4jVg78jMdhLkFZTLTtVj8wC9nPm KhQc6YZr4DdpW/chlUV66igmqhIT3L550vPv1rkJK/p8NaP2OCeSsaah3HNSi+XcH3H5jflY7zCq JT+vAeC9W0K1y8S2+1wpbgAUdD0J9I0yQ+tSZ8SufjjGquoxeNcbqxMUD4dpI7p0k1riuoKCY1dz 3wyhGfceHFEl3IaBsUiiNTiW231Z62bLy+REZjSKSiVB75HJkPvN99A7DT29Xdh7zAvERv3FBob+ cu6o6QjB7BBQtK6aA7LNVleaM5Mv01YDkKrW5fShzWcGFcU3VBs7ycWEYLpEriHzLhAstXjLIY5B IH/UuFnGGezYTFi15eOFalT0KN69TcwXgnHq2+wwceRPAYUIVbsyu4aBwgayEx8LAsJqWg97QkyT k5fRxzoCpRWDgMtCyU7l3Uer6u68/2yGSRrmlmYnbvQXa4EkppUADF40kD9exmh20ewDFLKD6Zz9 iN/2bxotNgipV2d8OocZ7myPQu0JIZ37CtHOTFbJEVYN1fq7urIB8YQKBiTOWNF6NlQK2+YbrW5w tFGmZW7j6nqUpGbrneRMYbcNyrpNbc9QCXuxy9nC4r+JuQM3g2FNCPExjWfmngbsPwsm/Y3PqQCx uDDfRGXBKSqM6wkUuGEhhQa/llArMZDVNj Date: Mon, 10 Aug 2020 15:32:54 +0800 From: "duzongpeng@foxmail.com" To: "Kent Watsen" Cc: "netconf@ietf.org" , duzongpeng References: <01000173c0b384f3-c7f261da-cea4-480d-a696-38a436c43c16-000000@us-east-1.amazonses.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.16.188[cn] Mime-Version: 1.0 Message-ID: <202008101532532534567@foxmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart834378467830_=----" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 07:31:00 -0000 This is a multi-part message in MIME format. ------=_001_NextPart834378467830_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIENoYWlycw0KDQogICAgSSB3b3VsZCBsaWtlIHRvIGNvbnRyaWJ1dGUgdG8gdGhlIGRyYWZ0 LiANCg0KICAgIDEpIGlzIHRoZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cg dG8gc29sdmU/DQogDQpJIGJlbGlldmUgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdG8gZW5hYmxlIHN1 YnNjcmliZXIgYW5kIHB1Ymxpc2hlciB0byBhZ3JlZSB1cG9uIHRyYW5zcG9ydCBwcm90b2NvbCAo ZS5nLiwgVENQLCBVRFApLCBlbmNvZGluZyBmb3JtYXQgKGUuZy4sYmluYXJ5IGVuY29kaW5nLHht bCwganNvbiksIGVuY3J5cHRpb24sIGNvbXByZXNzaW9uIG1vZGUgdG8gYmUgdXNlZA0KYW5kIGFs bG93IHRoZSBjbGllbnQgdG8gc2VsZWN0IHNwZWNpZmljIHRyYW5zcG9ydCBwcm90b2NvbCwgZW5j b2RpbmcgZm9ybWF0LGV0YyB3aGVuIHN1YnNjcmliaW5nIGRhdGFzdG9yZSBub2RlIHVwZGF0ZS4N CkFuZCBJIGFsc28gYmVsaWV2ZSB0aGF0IHRoZSBORVRDT05GIFdHIGlzIHRoZSBhcHByb3ByaWF0 ZSBXRyBmb3IgdGhpcyB3b3JrLiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFi aWxpdGllcyBwcm92aWRlcyBhIGdvb2QgYmFzaXMgZm9yIHNlcnZlciBjYXBhYmlsaXRpZXMgYWR2 ZXJ0aXNlbWVudC4NCkFkZGl0aW9uIGRhdGEgZXhwb3J0IGNhcGFiaWxpdHkgY2FuIGJlIGJ1aWx0 IG9uIHRvcCBvZiBpdC4NCiANCiAgICAyKSBpcyB0aGUgZHJhZnQgYSBzdWl0YWJsZSBiYXNpcyBm b3IgdGhlIHdvcms/DQogDQpJIGhhdmUgcmVhZCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRy YWZ0IGFuZCBiZWxpZXZlIGl0IGhhcyBiZWVuIGluIGdvb2Qgc2hhcGUgYW5kIHNlcnZlZCBhcyBh IHJlYXNvbmFibGUgZ29vZCBzdGFydGluZyBwb2ludC4NCklmIHRoaXMgd29yayBnZXRzIGFkb3B0 ZWQsIEkgYW0gd2lsbGluZyB0byByZXZpZXcgdGhpcyB3b3JrIGFzIGNvbnRyaWJ1dG9yIGFuZCBj b250cmlidXRlIHRvIGFueSBkaXNjdXNzaW9uIG5lZWRlZCBhbmQNCndlIGFyZSBpbnRlcmVzdGVk IHRvIGltcGxlbWVudCBhbmQgcGxhbiB0byBkZXBsb3kgdGhpcyB0ZWNobm9sb2d5Lg0KDQoNCkJl c3QgUmVnYXJkcw0KWm9uZ3BlbmcgRHUNCg0KDQoNCmR1em9uZ3BlbmdAZm94bWFpbC5jb20gJiBk dXpvbmdwZW5nQGNoaW5hbW9iaWxlLmNvbQ0KIA0KRnJvbTogS2VudCBXYXRzZW4NCkRhdGU6IDIw MjAtMDgtMDYgMDY6MTcNClRvOiBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBbbmV0Y29uZl0g QWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0LXRhby1uZXRjb25mLWRhdGEtZXhwb3J0LWNh cGFiaWxpdGllcw0KDQpORVRDT05GIFdHLA0KDQpQZXIgdGhlIHByZXZpb3VzIGVtYWlsIHNlbnQg bW9tZW50cyBhZ28sIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBzb2xpY2l0IGlucHV0IG9uIHRo ZSBmb2xsb3dpbmcgZHJhZnQ6DQoNCiAgIFRpdGxlOiBUZWxlbWV0cnkgRGF0YSBFeHBvcnQgY2Fw YWJpbGl0eQ0KICAgTGluazogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRhby1u ZXRjb25mLWRhdGEtZXhwb3J0LWNhcGFiaWxpdGllcw0KICAgQWJzdHJhY3Q6DQoNCiAgICAgIFRo aXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBZQU5HIG1vZHVsZSBmb3IgdGVsZW1ldHJ5IGRhdGEgZXhw b3J0DQogICAgICBjYXBhYmlsaXR5IHdoaWNoIGF1Z21lbnRzIHN5c3RlbSBDYXBhYmlsaXRpZXMg bW9kZWwgYW5kIHByb3ZpZGVzDQogICAgICBhZGRpdGlvbmFsIHRlbGVtZXRyeSBkYXRhIGV4cG9y dCBhdHRyaWJ1dGVzIGFzc29jaWF0ZWQgd2l0aCBzeXN0ZW0NCiAgICAgIGNhcGFiaWxpdHkgZm9y IHRyYW5zcG9ydCBkZXBlbmRlbnQgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbi4NCg0KDQpJbiBwYXJ0 aWN1bGFyLCBwbGVhc2UgZGlzY3VzcyBhZG9wdGlvbi1zdWl0YWJpbGl0eSBhcyBpdCByZWdhcmRz IHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOg0KDQogICAgMSkgaXMgdGhlIHByb2JsZW0gaW1w b3J0YW50IGZvciB0aGUgTkVUQ09ORiBXRyB0byBzb2x2ZT8NCiAgICAyKSBpcyB0aGUgZHJhZnQg YSBzdWl0YWJsZSBiYXNpcyBmb3IgdGhlIHdvcms/DQoNCg0KUFM6IHRoaXMgbWVzc2FnZSBpcyBp dHNlbGYgbm90IGFuIGFkb3B0aW9uIHBvbGwsIGJ1dCByYXRoZXIgYW4gYXR0ZW1wdCB0byBnYXVn ZSBpbnRlcmVzdC9zdXBwb3J0IGZvciBhIHBvdGVudGlhbCBmdXR1cmUgYWRvcHRpb24gcG9sbC4N Cg0KTkVUQ09ORiBDaGFpcnMNCg== ------=_001_NextPart834378467830_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable = =0A
Hi, Chairs

=
    I would like to contribute to the = draft. 

    1) = is the problem important for the NETCONF&nbs= p;WG to solve?
 
I believe that it&nbs= p;is important to enable subscriber and publ= isher to agree upon transport protocol (e.g.= , TCP, UDP), encoding format (e.g.,binary en= coding,xml, json), encryption, compression mode t= o be used
and allow the client to se= lect specific transport protocol, encoding format= ,etc when subscribing datastore node update.
A= nd I also believe that the NETCONF WG&n= bsp;is the appropriate WG for this work.&nbs= p;draft-ietf-netconf-notification-capabilities provides a g= ood basis for server capabilities advertisement.<= br>Addition data export capability can be bu= ilt on top of it.
 
    = ;2) is the draft a suitable basis for&n= bsp;the work?
 
I have read the latest=  version of the draft and believe it&nb= sp;has been in good shape and served as=  a reasonable good starting point.
If thi= s work gets adopted, I am willing to&nb= sp;review this work as contributor and contr= ibute to any discussion needed and
we are=  interested to implement and plan to de= ploy this technology.


Best Regard= s
Zongpeng Du

=0A
=0A
d= uzongpeng@foxmail.com = & duzongpeng@chinamob= ile.com
=0A
 
From: = ;Kent Watsen
Date= : 2020-08-06 06:17
Subject: [= netconf] Adoption-suitability for draft-tao-netconf-data-export-capabiliti= es
=0A
NETCONF WG,

Per the previous email sent m= oments ago, the chairs would like to solicit input on the following draft:=

   Title: Telemetry Data Export capability
<= font color=3D"#000000" class=3D"">   Link: https://tools.ietf.org/html/dra= ft-tao-netconf-data-export-capabilities
   Abstract:

    &nbs= p; This document proposes a YANG module for telemetry data export
      capability= which augments system Capabilities model and provides
=
      additional telemetry d= ata export attributes associated with system
      capability for transport depende= nt capability negotiation.


In particular, please discuss adoption-suitability as it regard= s to the following questions:

  &nb= sp; 1) is the problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the work?


PS: this message is itself not an adoption poll, bu= t rather an attempt to gauge interest/support for a potential future adopt= ion poll.

NETCONF Chairs
=0A
------=_001_NextPart834378467830_=------ . From nobody Mon Aug 10 01:06:35 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFAC3A0D7C for ; Mon, 10 Aug 2020 01:06:34 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.395 X-Spam-Level: X-Spam-Status: No, score=0.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=1.5, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=foxmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJLXHT_1u-At for ; Mon, 10 Aug 2020 01:06:32 -0700 (PDT) Received: from qq.com (out203-205-251-88.mail.qq.com [203.205.251.88]) (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 A2D723A09E0 for ; Mon, 10 Aug 2020 01:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1597046779; bh=XJJgrUDHoW3D/IXECEeEsOn0CQTvNJvGjuHgb+LpchU=; h=Date:From:To:Cc:Subject:References; b=uzMSC0gFjnbqLJYmTqKIaTkyex2dz9zBwK4nmd0ASbU5ou9/upd9+HXlijFwg6Myz PupK6LOMWegNEQYp6DlXJSYFcEzrPZxbSrPyLYXTwMLkRmPazZDtd7cVrjPxbgTEmb PufHM+zmyGRr494wH4HfIgULVDu3DhqMUju9eYPk= Received: from cmcc-PC ([221.130.253.135]) by newxmesmtplogicsvrsza6.qq.com (NewEsmtp) with SMTP id 1910CC93; Mon, 10 Aug 2020 16:06:17 +0800 X-QQ-mid: xmsmtpt1597046777tm8xqkw4w Message-ID: X-QQ-XMAILINFO: MCieeIuk/bPLWif32+Fxz+NDESoHB9L47PWGAHVghcdQhjkXjC1wWL2XqkRbge 876tZtzhDKm1cmFYXpSp1ZqyVHckrUCO812EQmUkVpT2L5vgBkwVhE2Aywa10RmhXz0SZGUYuj5i YBzcApSMwwDJAkMHZe4NuFVccUfTO38bd7F4uYARpvXDiRRMisWkCT5cZ/RVuH5ct4LABe99An0g Ewmg5S9HNs/2omcdQntw5wisuItH5ql69wzdsHdJ2WMDXmXjD8z9UWIx6iwo7g4csldPh6cTdO4F Z7R1O5wNrnijEt4AKcfy4j7JamInoZxJTu1fDuj2n+HC9dpPG94zC2UlbpMpjciym5h4tyaiiXEo ceFU1YuUNKZd+u1e6PSha8r8/GI0uvNLEErqOR1HbZmORp/h+xBMGWY97Vlq9FRUiP4XpDZ+LqNE nFL2RNoFHnOz5nDMLGOfd7GMGZwQonEKs0IlStIBY4PJafLm6bEEqexLY2lPoSDm7OtlvG6R8gah Ijzo4Fq7+yXmWYlSwtrnnUJtn7Y1WfIr/YfK5yIrOSWltPjnsIokFKGSKW/Mpxc2Q+x/RCSmf2Qc I8BSOhtwt/7IqqGdyWKb/6gJ3SIrPqVXWyIPio3RHRu895mEJ1vwpxVjwMd14+sRdqqL9oGx6DLt 3O6z6NF7MNlvaeybJPREx2UYcrf+JntRa9qZVGHL9hSwoyhlG3abU1BSUCfRvLFuHBmHt28V8WUf UJ3JccajQY+v/GNrwm6p7Y3/6IaIYyjOgFi33/bbW3v00= Date: Mon, 10 Aug 2020 16:08:30 +0800 From: "duzongpeng@foxmail.com" To: "Kent Watsen" Cc: "netconf@ietf.org" , duzongpeng References: <01000173c0b44d61-4df9b67b-47f9-46f5-9c91-6e00f466a5c5-000000@us-east-1.amazonses.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.16.188[cn] Mime-Version: 1.0 Message-ID: <2020081016082979688613@foxmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart238440573422_=----" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-wang-netconf-adaptive-subscription X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 08:06:34 -0000 This is a multi-part message in MIME format. ------=_001_NextPart238440573422_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksIENoYWlycw0KDQogICAgSSB3b3VsZCBsaWtlIHRvIGNvbnRyaWJ1dGUgdG8gdGhlIGRyYWZ0 LiANCg0KICAgIDEpIGlzIHRoZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cg dG8gc29sdmU/DQoNCkkgYmVsaWV2ZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBhZGp1c3QgdGhl IHZvbHVtZSBvZiB0ZWxlbWV0cnkgdHJhZmZpYyBzZW50IGZyb20gcHVibGlzaGVyIHRvIHRoZSBy ZWNlaXZlcnMgYmFzZWQgb24gc2l0dWF0aW9uIGNoYW5nZXMgQWRhcHRpdmUgc3Vic2NyaXB0aW9u IGRyYWZ0DQplbmFibGVzIHZhcmlvdXMgc3Vic2NyaXB0aW9uIHBvbGljeSBiYXNlZCBvbiB0aHJl c2hvbGQgc3VwcG9ydCwgdGltZXItZXZlbnQtc3VwcG9ydCBhbmQgc3VwcG9ydCBtdWx0aXBsZSB1 cGRhdGUgaW50ZXJ2YWwsIGNhbiBlZmZlY3RpdmVseSBlbGltaW5hdGUgZGF0YSBjb2xsZWN0aW9u IA0KcGVyZm9ybWFuY2UgYm90dGxlbmVjayBvbiB0aGUgZGV2aWNlLg0KQW5kIEkgYWxzbyBiZWxp ZXZlIHRoYXQgdGhlIE5FVENPTkYgV0cgaXMgdGhlIGFwcHJvcHJpYXRlIFdHIGZvciB0aGlzIHdv cmsuIFJGQzg2MzkgYW5kIFJGQzg2NDAgcHJvdmlkZSBhIGdvb2QgYmFzaXMgZm9yIHRoaXMgd29y ay4NCg0KICAgIDIpIGlzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJhc2lzIGZvciB0aGUgd29yaz8N Cg0KSSBoYXZlIHJlYWQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBhbmQgYmVsaWV2 ZSBpdCBoYXMgYmVlbiBpbiBnb29kIHNoYXBlIGFuZCBzZXJ2ZWQgYXMgYSByZWFzb25hYmxlIGdv b2Qgc3RhcnRpbmcgcG9pbnQuDQpJIGhhdmUgYmVlbiBhd2FyZSBvbmUgaW1wbGVtZW50YXRpb24g b25nb2luZy4gT25lIHdoaXRlIHBhcGVyIGhhcyBiZWVuIHBsYW5uZWQgZm9yIHB1YmxpY2F0aW9u IHRvIG1ha2UgdGhlIHdob2xlIGNvbW11bml0eSBiZW5lZml0IGZyb20gaXQuDQpJZiB0aGlzIHdv cmsgZ2V0cyBhZG9wdGVkLCBJIGFtIHdpbGxpbmcgdG8gcmV2aWV3IHRoaXMgd29yayBhcyBjb250 cmlidXRvciBhbmQgY29udHJpYnV0ZSB0byBhbnkgZGlzY3Vzc2lvbiBuZWVkZWQgYW5kIA0Kd2Ug YXJlIGludGVyZXN0ZWQgdG8gaW1wbGVtZW50IGFuZCBwbGFuIHRvIGRlcGxveSB0aGlzIHRlY2hu b2xvZ3kuDQoNCg0KQmVzdCBSZWdhcmRzDQpab25ncGVuZyBEdQ0KDQoNCg0KDQpkdXpvbmdwZW5n QGZveG1haWwuY29tICYgZHV6b25ncGVuZ0BjaGluYW1vYmlsZS5jb20NCiANCkZyb206IEtlbnQg V2F0c2VuDQpEYXRlOiAyMDIwLTA4LTA2IDA2OjE4DQpUbzogbmV0Y29uZkBpZXRmLm9yZw0KU3Vi amVjdDogW25ldGNvbmZdIEFkb3B0aW9uLXN1aXRhYmlsaXR5IGZvciBkcmFmdC13YW5nLW5ldGNv bmYtYWRhcHRpdmUtc3Vic2NyaXB0aW9uDQpORVRDT05GIFdHLA0KDQpQZXIgdGhlIHByZXZpb3Vz IGVtYWlsIHNlbnQgbW9tZW50cyBhZ28sIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBzb2xpY2l0 IGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQ6DQoNCiAgIFRpdGxlOiBBZGFwdGl2ZSBTdWJz Y3JpcHRpb24gdG8gWUFORyBOb3RpZmljYXRpb24NCiAgIExpbms6IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC13YW5nLW5ldGNvbmYtYWRhcHRpdmUtc3Vic2NyaXB0aW9uDQogICBB YnN0cmFjdDoNCg0KICAgICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVs IGFuZCBhc3NvY2lhdGVkIG1lY2hhbmlzbQ0KICAgICAgZW5hYmxpbmcgc3Vic2NyaWJlcidzIGFk YXB0aXZlIHN1YnNjcmlwdGlvbnMgdG8gYSBwdWJsaXNoZXIncyBldmVudA0KICAgICAgc3RyZWFt cyBhdCB2YXJpb3VzIGRpZmZlcmVudCBwZXJpb2QgaW50ZXJ2YWxzIHdpdGggd2hpY2ggdG8gcmVw b3J0DQogICAgICB1cGRhdGVzLiAgQXBwbHlpbmcgdGhlc2UgZWxlbWVudHMgYWxsb3dzIGJvdGgg c3Vic2NyaWJlciBhbmQNCiAgICAgIHB1Ymxpc2hlciB0byBhdXRvbWF0aWNhbGx5IGFkanVzdCB0 aGUgdm9sdW1lIG9mIHRlbGVtZXRyeSB0cmFmZmljDQogICAgICBzZW50IGZyb20gcHVibGlzaGVy IHRvIHRoZSByZWNlaXZlcnMuDQoNCg0KSW4gcGFydGljdWxhciwgcGxlYXNlIGRpc2N1c3MgYWRv cHRpb24tc3VpdGFiaWxpdHkgYXMgaXQgcmVnYXJkcyB0byB0aGUgZm9sbG93aW5nIHF1ZXN0aW9u czoNCg0KICAgIDEpIGlzIHRoZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cg dG8gc29sdmU/DQogICAgMikgaXMgdGhlIGRyYWZ0IGEgc3VpdGFibGUgYmFzaXMgZm9yIHRoZSB3 b3JrPw0KDQoNClBTOiB0aGlzIG1lc3NhZ2UgaXMgaXRzZWxmIG5vdCBhbiBhZG9wdGlvbiBwb2xs LCBidXQgcmF0aGVyIGFuIGF0dGVtcHQgdG8gZ2F1Z2UgaW50ZXJlc3Qvc3VwcG9ydCBmb3IgYSBw b3RlbnRpYWwgZnV0dXJlIGFkb3B0aW9uIHBvbGwuDQoNCk5FVENPTkYgQ2hhaXJzDQo= ------=_001_NextPart238440573422_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Hi, Chairs

    I would like to contr= ibute to the draft. 

    1) is the problem important for the N= ETCONF WG to solve?

I believe that it is importan= t to adjust the volume of telemetry traffic sent from publisher to the rec= eivers based on situation changes Adaptive subscription draft
en= ables various subscription policy based on threshold support, timer-event-= support and support multiple update interval, can effectively eliminate da= ta collection 
performance bottleneck on the device.
<= div>And I also believe that the NETCONF WG is the appropriate WG for this = work. RFC8639 and RFC8640 provide a good basis for this work.
    2) is the draft a suitable basis for the work?<= /div>

I have read the latest version of the draft and b= elieve it has been in good shape and served as a reasonable good starting = point.
I have been aware one implementation ongoing. One white p= aper has been planned for publication to make the whole community benefit = from it.
If this work gets adopted, I am willing to review this = work as contributor and contribute to any discussion needed and 
we are interested to implement and plan to deploy this technology.

Best Regards
Zongpeng Du

=0A

=0A
=
duzongpeng@foxmail.com & duzon= gpeng@chinamobile.com
=0A
 
Fr= om: Kent Watsen
=
Date: 2020-08-06 06:18
Subject= : [netconf] Adoption-suitability for draft-wang-netconf-adaptive-= subscription
=0ANETCONF WG,

Per the previous email sent moments ago, the chair= s would like to solicit input on the following draft:

   Title: Adaptive Su= bscription to YANG Notification
   Link: https://tools.ietf.org/html/dra= ft-wang-netconf-adaptive-subscription
   Abstract:

      This document defin= es a YANG data model and associated mechanism
      enabling subscriber's adaptive = subscriptions to a publisher's event
      streams at various different period inte= rvals with which to report
      updates.  Applying these elements allows b= oth subscriber and
 = ;     publisher to automatically adjust the volume of telemetry = traffic
    =   sent from publisher to the receivers.


In partic= ular, please discuss adoption-suitability as it regards to the following q= uestions:

    1) is the = problem important for the NETCONF WG to solve?
   = 2) is the draft a suitable basis for the work?


PS: this message is itself not an adoption poll, but rat= her an attempt to gauge interest/support for a potential future adoption p= oll.

NETCONF Chairs
=0A ------=_001_NextPart238440573422_=------ . From nobody Mon Aug 10 01:08:28 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C7D3A09E0 for ; Mon, 10 Aug 2020 01:08:26 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.395 X-Spam-Level: X-Spam-Status: No, score=0.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=1.5, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=foxmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jdd7CsHi-xW9 for ; Mon, 10 Aug 2020 01:08:23 -0700 (PDT) Received: from qq.com (out203-205-251-27.mail.qq.com [203.205.251.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9133A0807 for ; Mon, 10 Aug 2020 01:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1597046896; bh=vq4N2Qd4p+tn4dzZOUpk/fO8lmpdKshemE7YW5y+xl4=; h=Date:From:To:Cc:Subject:References; b=bkncOzQTFlk20LXkBRZokTSvjgByHqEamgmioOzKfRbPh6zl7yMAd/SG2iINA2su7 n+mGw3djH+aCnefuyrMRrzUiqq1qT5/DdvQNkU1Sunek9WQVH7gSJAN1PyYGMpIZpB FCUIZh/6wFgvITrvSkq0Qc2lFO0FpdZAA8A8/2s4= Received: from cmcc-PC ([221.130.253.135]) by newxmesmtplogicsvrsza5.qq.com (NewEsmtp) with SMTP id 20DB808A; Mon, 10 Aug 2020 16:08:13 +0800 X-QQ-mid: xmsmtpt1597046893tb1rajgo2 Message-ID: X-QQ-XMAILINFO: NRRSkgP6RcOlY+Z5uAqPF1Jv+ohv/WUPT3PcIR/rTG+b36kjVTXqhzX8altxWB 9zJujKeZi7JU6EDnc93AfR+nKkZfiUi1sfh4uXtJ1fDFxrUi1PokQuIWkoACFHSE4DzDvme3RcGy JB4edxWBhWetk399LdrcLpAxwq83vj7L62d/L9xRUI5gShwC6b5yD6oTJ+B/q3I0AuIKplu6zetL k35G4DxCxnQ8l8RsAjrSzUaXuTNRqyMdanihQs9IS1Z0on96tv3LdA7A7nR7wYCBlQVFr31tLWzs N8ZLgELph9yvxV/qlDeaSvFotJH6f+i5+tqsSFeEFj0GRuaWVlMDSKqpO2rkub4scQnpmxugrvvl UxnU6OXVB8e2fVqudmCtcShYCoXXVCJxZVEzEO3Ji7fdzeiIuIIwFxfZg1l0unb9CM/IRWVmYYlr 1VJcruA1Tfy9J4UA8LdQsLWFiNLhT/Hk8aN88kJ740CP/V7gMbITW9RsXJmXj14diK5jAZVYzpse Q2wR0/33Q3PBNar2uCgAt4pSaqN1V4gVKA9M65xHlYE/eJ2Xsv7SgvMB1cekuFhnR+3kiPU0CA40 eYY34l25esjQ92i6qsgh6wQm+J446k1CoG9CCErMdEl5QL/gXHrVgehbG6I78UyxJNr7JFC8WGcD 2Qg7l+xq6EeG+YDh6rvH9Qb0a6M+adT6dhaidjD5ggzCesFIlJoSurY7gHLnAYAA6PMkknrZ0vN2 crb/OyUg5BwBhXaWmdX5jTOXPXgUQLoyKycvxqngsigBX8HGo5aRaMCA== Date: Mon, 10 Aug 2020 16:10:27 +0800 From: "duzongpeng@foxmail.com" To: "Kent Watsen" Cc: "netconf@ietf.org" , duzongpeng References: <01000173c0b45676-dc00a30e-1234-45d2-ba20-131c9467110d-000000@us-east-1.amazonses.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.16.188[cn] Mime-Version: 1.0 Message-ID: <2020081016102633273315@foxmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart337600482385_=----" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-wang-netconf-bulk-subscribed-notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 08:08:26 -0000 This is a multi-part message in MIME format. ------=_001_NextPart337600482385_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksIENoYWlycw0KDQogICAgSSB3b3VsZCBsaWtlIHRvIGNvbnRyaWJ1dGUgdG8gdGhlIGRyYWZ0 LiANCg0KICAgIDEpIGlzIHRoZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cg dG8gc29sdmU/DQoNCkkgYmVsaWV2ZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBhbGxvdyB0aGUg cHVibGlzaGVycyB0byB1bmRlcnN0YW5kIHdoaWNoIHNwZWNpZmljIHN1YnNjcmlwdGlvbnMgY2Fu IGJlIGJ1bmRsZWQgdG9nZXRoZXIgYW5kIHdoaWNoIG5vdC4NCkJ1bGsgU3Vic2NyaXB0aW9uIGNh biB3b3JrIHRvZ2V0aGVyIFtJLUQuaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlc10g YW5kIGFsbG93IHRoZSBwdWJsaXNoZXJzIHRvIHJlcG9ydCBtdWx0aXBsZSBub3RpZmljYXRpb24g aW4gYSBzaW5nbGUgYnVuZGxpbmcgbWVzc2FnZS4NCkFuZCBJIGFsc28gYmVsaWV2ZSB0aGF0IHRo ZSBORVRDT05GIFdHIGlzIHRoZSBhcHByb3ByaWF0ZSBXRyBmb3IgdGhpcyB3b3JrLiBSRkM4NjM5 IGFuZCBSRkM4NjQwIHByb3ZpZGUgYSBnb29kIGJhc2lzIGZvciB0aGlzIHdvcmsuDQoNCiAgICAy KSBpcyB0aGUgZHJhZnQgYSBzdWl0YWJsZSBiYXNpcyBmb3IgdGhlIHdvcms/DQoNCkkgaGF2ZSBy ZWFkIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQgYW5kIGJlbGlldmUgaXQgaGFzIGJl ZW4gaW4gZ29vZCBzaGFwZSBhbmQgc2VydmVkIGFzIGEgcmVhc29uYWJsZSBnb29kIHN0YXJ0aW5n IHBvaW50Lg0KT25lIHdoaXRlIHBhcGVyIGhhcyBiZWVuIHBsYW5uZWQgZm9yIHB1YmxpY2F0aW9u IHRvIG1ha2UgdGhlIHdob2xlIGNvbW11bml0eSBiZW5lZml0IGZyb20gaXQuDQpJZiB0aGlzIHdv cmsgZ2V0cyBhZG9wdGVkLCBJIGFtIHdpbGxpbmcgdG8gcmV2aWV3IHRoaXMgd29yayBhcyBjb250 cmlidXRvciBhbmQgY29udHJpYnV0ZSB0byBhbnkgZGlzY3Vzc2lvbiBuZWVkZWQuDQoNCg0KQmVz dCBSZWdhcmRzDQpab25ncGVuZyBEdQ0KDQoNCg0KZHV6b25ncGVuZ0Bmb3htYWlsLmNvbSAmIGR1 em9uZ3BlbmdAY2hpbmFtb2JpbGUuY29tDQogDQpGcm9tOiBLZW50IFdhdHNlbg0KRGF0ZTogMjAy MC0wOC0wNiAwNjoxOA0KVG86IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFtuZXRjb25mXSBB ZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQtd2FuZy1uZXRjb25mLWJ1bGstc3Vic2NyaWJl ZC1ub3RpZmljYXRpb25zDQoNCk5FVENPTkYgV0csDQoNClBlciB0aGUgcHJldmlvdXMgZW1haWwg c2VudCBtb21lbnRzIGFnbywgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIHNvbGljaXQgaW5wdXQg b24gdGhlIGZvbGxvd2luZyBkcmFmdDoNCg0KICAgVGl0bGU6IEJ1bGsgU3Vic2NyaXB0aW9uIHRv IFlBTkcgRXZlbnQgTm90aWZpY2F0aW9uDQogICBMaW5rOiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtd2FuZy1uZXRjb25mLWJ1bGstc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zDQog ICBBYnN0cmFjdDoNCg0KICAgICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1v ZGVsIGFuZCBhc3NvY2lhdGVkIG1lY2hhbmlzbSB0aGF0DQogICAgICBhbGxvd3Mgc3Vic2NyaWJl ciBhcHBsaWNhdGlvbnMgdG8gYnVsayBzdWJzY3JpYmUgdG8gcHVibGlzaGVycycgZXZlbnQNCiAg ICAgIHN0cmVhbXMgYmFzZWQgb24gYnVuZGxlIGdyb3VwIGluZm9ybWF0aW9uIHN1Y2ggYXMgYnVu ZGxlIHNpemUgYW5kDQogICAgICBidW5kbGUgbGF0ZW5jeS4gIFRoaXMgYWxsb3dzIHRoZSBwdWJs aXNoZXJzIHRvIHJlcG9ydCBtdWx0aXBsZQ0KICAgICAgbm90aWZpY2F0aW9ucyBpbiBhIHNpbmds ZSBidW5kbGluZyBtZXNzYWdlLg0KDQoNCkluIHBhcnRpY3VsYXIsIHBsZWFzZSBkaXNjdXNzIGFk b3B0aW9uLXN1aXRhYmlsaXR5IGFzIGl0IHJlZ2FyZHMgdG8gdGhlIGZvbGxvd2luZyBxdWVzdGlv bnM6DQoNCiAgICAxKSBpcyB0aGUgcHJvYmxlbSBpbXBvcnRhbnQgZm9yIHRoZSBORVRDT05GIFdH IHRvIHNvbHZlPw0KICAgIDIpIGlzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJhc2lzIGZvciB0aGUg d29yaz8NCg0KDQpQUzogdGhpcyBtZXNzYWdlIGlzIGl0c2VsZiBub3QgYW4gYWRvcHRpb24gcG9s bCwgYnV0IHJhdGhlciBhbiBhdHRlbXB0IHRvIGdhdWdlIGludGVyZXN0L3N1cHBvcnQgZm9yIGEg cG90ZW50aWFsIGZ1dHVyZSBhZG9wdGlvbiBwb2xsLg0KDQpORVRDT05GIENoYWlycw0K ------=_001_NextPart337600482385_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Hi, Chairs

  &n= bsp; I would like to contribute to the&= nbsp;draft. 

    1) is the problem important fo= r the NETCONF WG to solve?

I believe that it is i= mportant to allow the publishers to understand which specific subscription= s can be bundled together and which not.
Bulk Subscription can w= ork together [I-D.ietf-netconf-notification-messages] and allow the publis= hers to report multiple notification in a single bundling message.
And I also believe that the NETCONF WG is the appropriate WG for this w= ork. RFC8639 and RFC8640 provide a good basis for this work.
    2) is the draft a suitable basis for the work?

I have read the latest version of the draft and be= lieve it has been in good shape and served as a reasonable good starting p= oint.
One white paper has been planned for publication to make t= he whole community benefit from it.
If this work gets adopted, I= am willing to review this work as contributor and contribute to any discu= ssion needed.


Best Regards
Zongpeng Du=0A

=0A
duzongpeng@foxm= ail.com & duzongpeng@chinamobile.com=
=0A
&= nbsp;
Date: 2020-= 08-06 06:18
Subject: [netconf] Adoptio= n-suitability for draft-wang-netconf-bulk-subscribed-notifications
=0A

NETCONF WG,

Per the previous = email sent moments ago, the chairs would like to solicit input on the foll= owing draft:

   Title: Bulk Subscription to YANG Event Notification<= /font>
   Link= : https://tools.ietf.o= rg/html/draft-wa= ng-netconf-bulk-subscribed-notifications
   Abstract:
=
      This document defines a YANG data model and ass= ociated mechanism that
&= nbsp;     allows subscriber applications to bulk subscribe to pu= blishers' event
  &= nbsp;   streams based on bundle group information such as bundle size= and
     = ; bundle latency.  This allows the publishers to report multiple
      notific= ations in a single bundling message.


In particular, please discuss adoption-suitabil= ity as it regards to the following questions:

<= /div>
    1) is the problem important for the NETCONF WG to solv= e?
    2) is the draft a suitable basis for the wo= rk?


PS: this message is itself not an a= doption poll, but rather an attempt to gauge interest/support for a potent= ial future adoption poll.

NETCONF Chairs
=0A ------=_001_NextPart337600482385_=------ . From nobody Mon Aug 10 01:56:55 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0452A3A1486 for ; Mon, 10 Aug 2020 01:56:47 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.395 X-Spam-Level: X-Spam-Status: No, score=0.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=1.5, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=foxmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPB_jcgazNg7 for ; Mon, 10 Aug 2020 01:56:44 -0700 (PDT) Received: from qq.com (out203-205-251-26.mail.qq.com [203.205.251.26]) (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 0FE2C3A0EA4 for ; Mon, 10 Aug 2020 01:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1597049791; bh=X67G3sMIVZPOjKw/2QVV5z55xmGXNU+C4coUt52YV3Y=; h=Date:From:To:Cc:Subject; b=qe436vRJosmvxeDjGTFiX1LiO4SGCNIv6ZVEz0SnEAFReqnQxZthUYdgmf0U9xens 7Gb/AAklI/8eYxGlmUXF/9OdTJu/aShjL8SF5gKJnZYz1SFY0noi8XdpMU84XxmtCO 43jAljuZEw49dq3wLNhT3GqIRodWmqsn9yJmTOLc= Received: from cmcc-PC ([221.130.253.135]) by newxmesmtplogicsvrszc8.qq.com (NewEsmtp) with SMTP id E1D0DC4D; Mon, 10 Aug 2020 16:56:29 +0800 X-QQ-mid: xmsmtpt1597049789thnrhwnzp Message-ID: X-QQ-XMAILINFO: MB+SFuOmSM04TjWW/7l+hIPcD78BOSLiXzBy6PfYgo+0hWHxiFRmkHAXomjh1n 5ad1StMu5wrf8ZVivX4AYXXAvlGFs8k5fFPi6xcMlUkqx8CgvkIkAmEWY3r1PQJIuckbTGZu3W67 dAQA7llJfNJu0fBZcutJDQE6pGPZdkyXiAzJCK76NrtCaDv/56VRXFTcd0Hud3RqKyOv14KDyaUk yJHOm4nD7Pr4h8tkVXEMxr4xNGShommIaOByNDH7nkt6exzDQzZ4OQaWRrW+U5viLXyMiqNtvpw3 CYfzqjfQhPDyv49GaYItT10XYXwpGKKnuMZS5CZgoniV261Tf2LlQzx5ODyMUXQKMT2CeEATk9BB DyV3wnijlhvdE7myTkz/XJu1cQB7VwTbypH4OQcXlszFtnzHculLYPSeEr8mj7EseUMQwhRaIQdh MQREIGestTjhv98NpWsJeJnZ3dAuAzcuYyXjOaP7oOuHPC2aWob6OAXqUzt5Hy+mUIkuYweernUa e915eO1T9GmabZwLEQwq/T7U2wwLe3tRwAM8GhpSD5tmSIfTEhREEWSflLmOWJvS4G2xbdXgpXT4 gmzaWzQF5tXP4ZKsaNeHfl+UMel2Z7G51hflTXd83tMjBe173aF52cZ6GuBl4hU/a8R0WMwDf9Co 7163Xg0LlXcTQXvAl/Y41JnLxxcw3edtP+XCFxFvwPya+FGHnDxgufV7t+ZCOxPzjCI8WiXscqFC 3cl15dLB5ohNcWBuiHcZb4O0glYW616fZfQ5gxXOmox01TN5XGr4O4ig== Date: Mon, 10 Aug 2020 16:58:42 +0800 From: "duzongpeng@foxmail.com" To: "Kent Watsen" Cc: "netconf@ietf.org" , duzongpeng X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.16.188[cn] Mime-Version: 1.0 Message-ID: <2020081016584181017018@foxmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart766183077165_=----" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 08:56:54 -0000 This is a multi-part message in MIME format. ------=_001_NextPart766183077165_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksIENoYWlycw0KDQogICAgSSB3b3VsZCBsaWtlIHRvIGNvbnRyaWJ1dGUgdG8gdGhlIGRyYWZ0 LiANCg0KICAgIDEpIGlzIHRoZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cg dG8gc29sdmU/DQoNCkkgYmVsaWV2ZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBjYXB0dXJlIGNo YXJhY3RlcmlzdGljcyBkYXRhIG9yIEtQSSBkYXRhIGZvciBzZXJ2aWNlIGFzc3VyYW5jZSBhcHBs aWNhdGlvbiBhbmQgcmVkdWNlIHRoZSBhbW91bnQgb2YgDQp1bm5lY2Vzc2FyeSBkYXRhIHRvIGJl IHN0cmVhbWVkIG91dCB0byB0aGUgZGVzdGluYXRpb24uIFRlbGVtZXRyeSBkYXRhIHRhZ2dpbmcg Y2FwYWJpbGl0eSBkcmFmdCBwcm92aWRlcyB0ZWxlbWV0cnkgZGF0YSBjbGFzc2lmaWNhdGlvbiBh bmQgDQpoZWxwIHRoZSBjbGllbnQgb25seSBmZXRjaCBjaGFyYWN0ZXJpc3RpY3MgZGF0YS4NCkFu ZCBJIGFsc28gYmVsaWV2ZSB0aGF0IHRoZSBORVRDT05GIFdHIGlzIHRoZSBhcHByb3ByaWF0ZSBX RyBmb3IgdGhpcyB3b3JrLiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxp dGllcyBwcm92aWRlcyBhIGdvb2QgYmFzaXMgZm9yIHNlcnZlciBjYXBhYmlsaXRpZXMgYWR2ZXJ0 aXNlbWVudCBhbmQgaGFzIGFscmVhZHkgc3RhYmxlIGZvciBwdWJsaWNhdGlvbi4NClRlbGVtZXRy eSBkYXRhIHRhZ2dpbmcgY2FwYWJpbGl0eSBjYW4gYmUgYnVpbHQgb24gdG9wIG9mIGl0Lg0KDQog ICAgMikgaXMgdGhlIGRyYWZ0IGEgc3VpdGFibGUgYmFzaXMgZm9yIHRoZSB3b3JrPw0KDQpJIGhh dmUgcmVhZCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGFuZCBiZWxpZXZlIGl0IGhh cyBiZWVuIGluIGdvb2Qgc2hhcGUgYW5kIHNlcnZlZCBhcyBhIHJlYXNvbmFibGUgZ29vZCBzdGFy dGluZyBwb2ludC4NCkkgaGF2ZSBiZWVuIGF3YXJlIG9uZSBpbXBsZW1lbnRhdGlvbiBoYXMgYmVl biBkZW1vbnN0cmF0ZWQgbGFzdCB5ZWFyIGluIElFVEYgaGFja2F0aG9uLg0KSWYgdGhpcyB3b3Jr IGdldHMgYWRvcHRlZCwgSSBhbSB3aWxsaW5nIHRvIHJldmlldyB0aGlzIHdvcmsgYXMgY29udHJp YnV0b3IgYW5kIGNvbnRyaWJ1dGUgdG8gYW55IGRpc2N1c3Npb24gbmVlZGVkIGFuZCANCndlIGFy ZSBpbnRlcmVzdGVkIHRvIGltcGxlbWVudCBhbmQgcGxhbiB0byBkZXBsb3kgdGhpcyB0ZWNobm9s b2d5Lg0KDQoNCkJlc3QgUmVnYXJkcw0KWm9uZ3BlbmcgRHUNCg0KDQoNCmR1em9uZ3BlbmdAZm94 bWFpbC5jb20gJiBkdXpvbmdwZW5nQGNoaW5hbW9iaWxlLmNvbQ0KIA0KRnJvbTogS2VudCBXYXRz ZW4NCkRhdGU6IDIwMjAtMDgtMDYgMDY6MTcNClRvOiBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0 OiBbbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0LXRhby1uZXRjb25mLW5v dGlmLW5vZGUtdGFnLWNhcGFiaWxpdGllcw0KDQpORVRDT05GIFdHLA0KDQpQZXIgdGhlIHByZXZp b3VzIGVtYWlsIHNlbnQgbW9tZW50cyBhZ28sIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBzb2xp Y2l0IGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQ6DQoNCiAgIFRpdGxlOiBTZWxmLWV4cGxh bmF0aW9uIGRhdGEgTm9kZSB0YWcgY2FwYWJpbGl0eQ0KICAgTGluazogaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXRhby1uZXRjb25mLW5vdGlmLW5vZGUtdGFnLWNhcGFiaWxpdGll cw0KICAgQWJzdHJhY3Q6DQoNCiAgICAgIEJlZm9yZSBhIGNsaWVudCBhcHBsaWNhdGlvbiBzdWJz Y3JpYmVzIHRvIHVwZGF0ZXMgZnJvbSBhIGRhdGFzdG9yZSwNCiAgICAgIHNlcnZlciBjYXBhYmls aXRpZXMgcmVsYXRlZCB0byAiU3Vic2NyaXB0aW9uIHRvIFlBTkcgRGF0YXN0b3JlcyIgY2FuDQog ICAgICBiZSBhZHZlcnRpc2VkIHVzaW5nIFlBTkcgSW5zdGFuY2UgRGF0YSBmb3JtYXQuICBUaGVz ZSBzZXJ2ZXINCiAgICAgIGNhcGFiaWxpdGllcyBjYW4gYmUgZG9jdW1lbnRlZCBhdCBpbXBsZW1l bnQgdGltZSBvciByZXBvcnRlZCBhdCBydW4tDQogICAgICB0aW1lLg0KDQogICAgICBUaGlzIGRv Y3VtZW50IHByb3Bvc2VzIGEgWUFORyBtb2R1bGUgZm9yIHNlbGYtZXhwbGFuYXRpb24gZGF0YSBO b2RlDQogICAgICB0YWcgY2FwYWJpbGl0eSB3aGljaCBhdWdtZW50cyBzeXN0ZW0gY2FwYWJpbGl0 aWVzIG1vZGVsIGFuZCBwcm92aWRlDQogICAgICBhZGRpdGlvbmFsIHNlbGYtZXhwbGFuYXRpb24g ZGF0YSBub2RlIGF0dHJpYnV0ZXMgYXNzb2NpYXRlZCB3aXRoIG5vZGUNCiAgICAgIHNlbGVjdG9y cyB3aXRoaW4gcGVyLW5vZGUgY2FwYWJpbGl0aWVzLg0KDQoNCkluIHBhcnRpY3VsYXIsIHBsZWFz ZSBkaXNjdXNzIGFkb3B0aW9uLXN1aXRhYmlsaXR5IGFzIGl0IHJlZ2FyZHMgdG8gdGhlIGZvbGxv d2luZyBxdWVzdGlvbnM6DQoNCiAgICAxKSBpcyB0aGUgcHJvYmxlbSBpbXBvcnRhbnQgZm9yIHRo ZSBORVRDT05GIFdHIHRvIHNvbHZlPw0KICAgIDIpIGlzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJh c2lzIGZvciB0aGUgd29yaz8NCg0KDQpQUzogdGhpcyBtZXNzYWdlIGlzIGl0c2VsZiBub3QgYW4g YWRvcHRpb24gcG9sbCwgYnV0IHJhdGhlciBhbiBhdHRlbXB0IHRvIGdhdWdlIGludGVyZXN0L3N1 cHBvcnQgZm9yIGEgcG90ZW50aWFsIGZ1dHVyZSBhZG9wdGlvbiBwb2xsLg0KDQpORVRDT05GIENo YWlycw0K ------=_001_NextPart766183077165_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Hi, Chairs

=     I would like to contribute to the draf= t. 

=     1) is the problem important for&nbs= p;the NETCONF WG to solve?

I believe = that it is important to capture characterist= ics data or KPI data for service assura= nce application and reduce the amount of&nbs= p;
unnecessary data to be streamed out to=  the destination. Telemetry data tagging cap= ability draft provides telemetry data classificat= ion and 
help the client only fetch = characteristics data.
And I also believe that&= nbsp;the NETCONF WG is the appropriate WG&nb= sp;for this work. draft-ietf-netconf-notification-capabilit= ies provides a good basis for server ca= pabilities advertisement and has already stable&n= bsp;for publication.
Telemetry data tagging capabil= ity can be built on top of it.

&= nbsp;   2) is the draft a suitable=  basis for the work?

I have read = ;the latest version of the draft and be= lieve it has been in good shape and&nbs= p;served as a reasonable good starting point= .
I have been aware one implementation ha= s been demonstrated last year in IETF h= ackathon.
If this work gets adopted, I am=  willing to review this work as contrib= utor and contribute to any discussion needed=  and 
we are interested to implement = ;and plan to deploy this technology.

Best Regards
Zongpeng Du
=0A=

=0A
= duzongpeng@foxmail.co= m & duzongpeng@chinamobile.com
<= /span>
=0A
 <= /div>
Date: 2020-08-06&= nbsp;06:17
Subject: [netconf] Adoption-suit= ability for draft-tao-netconf-notif-node-tag-capabilities
=0A
NETCONF WG,

Per the previou= s email sent moments ago, the chairs would like to solicit input on the fo= llowing draft:

   Title: Self-explanation data Node tag capability
   Link:= https://tools.ietf.or= g/html/draft-tao= -netconf-notif-node-tag-capabilities
   Abstract:

=       Before a client application subscribes to updates fro= m a datastore,
  &n= bsp;   server capabilities related to "Subscription to YANG Datastore= s" can
    &nb= sp; be advertised using YANG Instance Data format.  These server
      capabil= ities can be documented at implement time or reported at run-
      time.

      This document prop= oses a YANG module for self-explanation data Node
      tag capability which augmen= ts system capabilities model and provide
      additional self-explanation data nod= e attributes associated with node
      selectors within per-node capabilities.


In particul= ar, please discuss adoption-suitability as it regards to the following que= stions:

    1) is the problem i= mportant for the NETCONF WG to solve?
    2) is th= e draft a suitable basis for the work?


= PS: this message is itself not an adoption poll, but rather an attempt to = gauge interest/support for a potential future adoption poll.

NETCONF Chairs
= =0A
=0A ------=_001_NextPart766183077165_=------ . From nobody Mon Aug 10 02:36:16 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9272C3A145F for ; Mon, 10 Aug 2020 02:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTBRPIWuAf8E for ; Mon, 10 Aug 2020 02:36:13 -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 663F93A0BC9 for ; Mon, 10 Aug 2020 02:36:13 -0700 (PDT) Received: from lhreml708-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 9317499BE982194B1558; Mon, 10 Aug 2020 10:36:10 +0100 (IST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 10 Aug 2020 10:36:09 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 10 Aug 2020 17:36:00 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Mon, 10 Aug 2020 17:36:00 +0800 From: Tianran Zhou To: Andy Bierman , Juergen Schoenwaelder , Adrian Farrel , Kent Watsen , Netconf Thread-Topic: [netconf] Regarding 108 adoption hums Thread-Index: AQHWa3W0/zcfmCeL8EOO/Z5e6RwUCakr1QWAgAAFB4CAAOmVAIAEVCng Date: Mon, 10 Aug 2020 09:36:00 +0000 Message-ID: References: <01000173c0afb995-d6003a0a-edbd-4113-b3e6-9092d30ec2a7-000000@us-east-1.amazonses.com> <00cf01d66c99$07392530$15ab6f90$@olddog.co.uk> <20200807091715.vzglsinbh76ox6kz@anna.jacobs.jacobs-university.de> 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.108.243.128] Content-Type: multipart/alternative; boundary="_000_cacf1f0b19ec4b4bac34d42ab9bae254huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Regarding 108 adoption hums X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 09:36:16 -0000 --_000_cacf1f0b19ec4b4bac34d42ab9bae254huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIG5vdCBmdW5jdGlvbiBhcyBhIHJ1YmJlciBzdGFtcCBm b3IgcHJvcHJpZXRhcnkgc29sdXRpb25zIGFuZCBhY2FkZW1pYyB3b3JrLg0KV2Ugc2hvdWxkIG5v dCBhc2sgZm9yIHRoZSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uLCBpZiB0aGUgc29sdXRpb24gZG9l cyBub3QgaGF2ZSByZXF1aXJlbWVudC4NCkkgc3Ryb25nbHkgc3VnZ2VzdCB0aGUgQ2hhaXJzIGFu ZCB0aGUgQURzIHRvIHNldCBhIGhpZ2ggYmFyIHRvIG9ubHkgYWRvcHQgc29sdXRpb25zIHdpdGgg YXQgbGVhc3QgdHdvIGltcGxlbWVudGF0aW9ucy4NCg0KVGlhbnJhbg0KDQpGcm9tOiBuZXRjb25m IFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5keSBCaWVy bWFuDQpTZW50OiBTYXR1cmRheSwgQXVndXN0IDgsIDIwMjAgNzoxMyBBTQ0KVG86IEp1ZXJnZW4g U2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPjsgQWRy aWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az47IEtlbnQgV2F0c2VuIDxrZW50K2lldGZA d2F0c2VuLm5ldD47IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25l dGNvbmZdIFJlZ2FyZGluZyAxMDggYWRvcHRpb24gaHVtcw0KDQpIaSwNCg0KDQpPbiBGcmksIEF1 ZyA3LCAyMDIwIGF0IDI6MTcgQU0gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p dmVyc2l0eS5kZT4+IHdyb3RlOg0KQWRyaWFuLA0KDQp0ZWNobmljYWwgZGlzY3Vzc2lvbiBvZiB0 aGUgZHJhZnRzIG9uIHRoZSBtYWlsaW5nIGxpc3Qgd291bGQgaGVscCBtb3JlDQp0aGFuIGhhdmlu ZyBwcm9jZXNzIG1ldGEtZGlzY3Vzc2lvbnMuIEl0IGlzIGdvb2QgdG8ga25vdyB3aG8gKG90aGVy DQp0aGFuIHRoZSBhdXRob3JzKSBpcyB2b2x1bnRlZXJpbmcgdG8gc3Vic3RhbnRpYWxseSByZXZp ZXcgdGhlIGRyYWZ0cywNCmlzIHdpbGxpbmcgdG8gY29udHJpYnV0ZSB0byB0aGUgZGlzY3Vzc2lv bnMgb2YgYW55IGlzc3VlcywgYW5kIGlzDQpwbGFubmluZyB0byBpbXBsZW1lbnQgdGhlIHRlY2hu b2xvZ3kgZGVmaW5lZCBpbiB0aGUgZHJhZnRzIGFzIHRoaXMNCndpbGwgbGlrZWx5IGhlbHAgdGhl IGNoYWlycyB0byBtYWtlIGEgZGVjaXNpb24uDQoNCg0KSU1PIGl0IG1ha2VzIG1vcmUgc2Vuc2Ug dG8gZGlzY3VzcyB3aGF0IHByb2JsZW1zIHRoZSBORVRDT05GL05FVE1PRCBXR3MNCnNob3VsZCBi ZSBzb2x2aW5nLCByYXRoZXIgdGhhbiBhZG9wdGlvbiBvZiBzb2x1dGlvbnMgdG8gcHJvYmxlbXMu IFRoZSBXRyBzaG91bGQgYmUNCmZpbmlzaGluZyB1cCBjb25maWd1cmVkIG5vdGlmaWNhdGlvbnMu IFRyeSB0byBzdGFuZGFyZGl6ZSBiaW5hcnkgdGVsZW1ldHJ5IGluc3RlYWQNCm9mIGp1c3QgbGVh dmluZyBwbGFjZWhvbGRlcnMgZm9yIHByb3ByaWV0YXJ5IHZlbmRvciBzb2x1dGlvbnMuDQoNCllv dXIgcXVlc3Rpb25zIGFyZSBtb3N0IHJlbGV2YW50IGJlY2F1c2Ugd2UgZG8gbm90IGhhdmUgYW55 IGNsZWFyIGRlZmluaXRpb24NCm9yICJzdXBwb3J0IiBvciAib3Bwb3NlIiBmb3IgYWRvcHRpb24g b2YgYSBkcmFmdC4NClN1cHBvcnQgb2Z0ZW4gbWVhbnMgIkkgYW0gaGFwcHkgZm9yIHlvdSB0byB3 b3JrIG9uIHRoaXMgZHJhZnQiLg0KVGhlIGN1bHR1cmUgb2YgdGhlIElFVEYgY3JlYXRlcyBhIHN0 cm9uZyBiaWFzIGFnYWluc3QgYW55Ym9keSBhY3R1YWxseQ0Kb3Bwb3NpbmcgYWRvcHRpb24gb2Yg YW55dGhpbmcuIFVzdWFsIGF0dGl0dWRlOiAiTGV0IHBlb3BsZSBleHBlcmltZW50LiBNYXliZSB0 aGV5IHdpbGwNCmNvbWUgdXAgd2l0aCBzb21ldGhpbmcgZ29vZCBpbiB0aGUgZW5kLiINCg0KSWYg b25seSB0aGUgY28tYXV0aG9ycyBzdXBwb3J0LCBhbmQgbm9ib2R5IG9wcG9zZXMsIHRoZW4gdGhl IHdvcmsgd2lsbCBnZXQgc3R1Y2suDQpPZnRlbiBXR3MgYWRvcHQgYWZ0ZXIgc3VjaCBhIHBvbGwg b3V0Y29tZSBhbmQgYWN0IHN1cnByaXNlZCBhIHllYXIgbGF0ZXIgd2hlbg0KdGhlIGRyYWZ0IGdv ZXMgbm93aGVyZS4NCg0KDQpBbmR5DQoNCg0KDQoNCg0KDQovanMNCg0KT24gRnJpLCBBdWcgMDcs IDIwMjAgYXQgMDk6NTk6MTVBTSArMDEwMCwgQWRyaWFuIEZhcnJlbCB3cm90ZToNCj4gSGkgY2hh aXJzLA0KPg0KPiBJIHRoaW5rIHRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgYXBwcm9hY2ggdG8gZGV0 ZXJtaW5pbmcgd2hldGhlciB0aGVyZSBpcyBpbnRlcmVzdCBpbiBhIG51bWJlciBvZiBkcmFmdHMg YXQgdGhlIHNhbWUgdGltZSwgYW5kIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBhIGh1bSBhdCBhIHdv cmtpbmcgZ3JvdXAgbWVldGluZyBtZWFucyBub3RoaW5nIHdpdGhvdXQgY29uZmlybWluZyB0aGUg b3BpbmlvbiBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KPg0KPiBCdXQgSSdtIHdvcnJpZWQgdGhhdCB5 b3UgbWF5IGJlIGludHJvZHVjaW5nIHlldCBhbm90aGVyIHBpZWNlIG9mIHByb2Nlc3MgaW50byBo b3cgd2UgcHJvY2VzcyBkb2N1bWVudHMuDQo+DQo+IFRoZSBhZG9wdGlvbiBwb2xsLCBpdHNlbGYs IGlzIG5vdCBuZWNlc3NhcnkgaWYgaXQgaXMgb2J2aW91cyB0byB0aGUgY2hhaXJzIHRoYXQgYSBk cmFmdCBpcyB3aXRoaW4gY2hhcnRlciBhbmQgaGFzIHN1cHBvcnQgW1JGQzcyMjFdLiBCdXQgaW4g YWRkaXRpb24gdG8gdGhlIHBvbGwsIHdlIGFsc28gaGF2ZSBzb21laG93IGludHJvZHVjZWQgYW4g SVBSIHBvbGwgYXQgYWRvcHRpb24gdGltZSAod2hpbGUgSSBjYW4gc2VlIHRoZSBtZXJpdHMgb2Yg YmVpbmcgZXhwbGljaXQgYWJvdXQgSVBSLCBhbmQgd2UgaGF2ZSBzZWVuIG9uZSBvciB0d28gcGVv cGxlIGF0dGVtcHQgdG8gd3JpZ2dsZSBvdXQgb2YgdGhlaXIgcmVzcG9uc2liaWxpdGllcywgaXQg c2VlbXMgdW5uZWNlc3NhcnkgdG8gc2VyaWFsaXplIHRoZSB0d28gY2FsbHMpLiBOb3cgeW91IGFw cGVhciB0byBiZSBpbnRyb2R1Y2luZyBhbiBhZGRpdGlvbmFsIHN0ZXAgdG8gdGVzdCAiYWRvcHRp b24gc3VpdGFiaWxpdHkiLg0KPg0KPiBDYW4gSSB1cmdlIHlvdSAoc3Ryb25nbHk/IDotKSB0byBj b25zaWRlciB0aGUgcmVzcG9uc2VzIHRvIHlvdSBhZG9wdGlvbiBzdWl0YWJpbGl0eSB0ZXN0cyBh bmQsIGlmIHRoZXkgYXJlIHNvbGlkLCB0byBtb3ZlIHN0cmFpZ2h0IHRvIGFkb3B0aW9uIHdpdGhv dXQgbWFraW5nIHRoZSB3b3JraW5nIGdyb3VwIGdvIHRob3VnaCBhIHByb2xvbmdlZCBzZXJpZXMg b2YgcG9sbHMuIFdlIHdvdWxkLCBJIHRoaW5rLCBwcmVmZXIgdG8gZ2V0IG9uIHdpdGggdGhlIHdv cmshDQo+DQo+IEJlc3QsDQo+IEFkcmlhbg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBuZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldGNv bmYtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBLZW50IFdhdHNlbg0KPiBTZW50OiAw NSBBdWd1c3QgMjAyMCAyMzoxMw0KPiBUbzogbmV0Y29uZkBpZXRmLi5vcmc8bWFpbHRvOm5ldGNv bmZAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtuZXRjb25mXSBSZWdhcmRpbmcgMTA4IGFkb3B0aW9u IGh1bXMNCj4NCj4NCj4gTkVUQ09ORiBXRywNCj4NCj4NCj4gVGhlIENoYWlycyAmIEFEIGRpc2N1 c3NlZCB0aGUgcmVzdWx0cyBvZiB0aGUgdmFyaW91cyBhZG9wdGlvbiBodW1zIGNvbmR1Y3RlZCBk dXJpbmcgdGhlIDEwOCBtZWV0aW5nLiAgVGhlcmUgaXMgYSBzZW5zZSB0aGF0IHRoZSByZXN1bHRz IGRpZG7igJl0IGFkZXF1YXRlbHkgZGV0ZXJtaW5lIGlmIHRoZSBkcmFmdHMgc2hvdWxkIGJlIGFk b3B0ZWQuICBJbiBwYXJ0aWN1bGFyLCBpdCB3YXNu4oCZdCBjbGVhciBpZiB0aGUgaHVtcyByZWZs ZWN0ZWQgYSBnZW5lcmFsIGRlc2lyZSB0byBzb2x2ZSB0aGUgcHJvYmxlbSBvciBzdXBwb3J0IGZv ciB0aGUgcGFydGljdWxhciBkcmFmdC4NCj4NCj4gQXMgc3VjaCwgd2XigJl2ZSBkZWNpZGVkIHRv IHNlbmQgc3Vic2VxdWVudCBlbWFpbHMgZm9yIGVhY2ggZHJhZnQsIG9yIHNldCBvZiBkcmFmdHMg aWYgYXBwcm9wcmlhdGUsIHRvIHNvbGljaXQgaW5wdXQgb24gZm9sbG93aW5nIHF1ZXN0aW9uczoN Cj4NCj4gICAgIDEpIGlzIHRoZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cg dG8gc29sdmU/DQo+ICAgICAyKSBpcyB0aGUgZHJhZnQgYSBzdWl0YWJsZSBiYXNpcyBmb3IgdGhl IHdvcms/DQo+DQo+DQo+IE5FVENPTkYgQ2hhaXJzDQo+DQo+DQo+DQo+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldGNvbmYgbWFpbGluZyBs aXN0DQo+IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRjb25mIG1haWxpbmcg bGlzdA0KPiBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KLS0NCkp1ZXJnZW4g U2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQ aG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVt ZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3 dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpuZXRjb25mIG1haWxpbmcgbGlzdA0KbmV0Y29uZkBpZXRmLm9y ZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZg0K --_000_cacf1f0b19ec4b4bac34d42ab9bae254huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQg OTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgd29ya2luZyBncm91cCBzaG91bGQgbm90IGZ1bmN0aW9u IGFzIGEgcnViYmVyIHN0YW1wIGZvciBwcm9wcmlldGFyeSBzb2x1dGlvbnMgYW5kIGFjYWRlbWlj IHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlIHNob3VsZCBub3QgYXNrIGZvciB0aGUgd29ya2lu ZyBncm91cCBhZG9wdGlvbiwgaWYgdGhlIHNvbHV0aW9uIGRvZXMgbm90IGhhdmUgcmVxdWlyZW1l bnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgc3Ryb25nbHkgc3VnZ2VzdCB0aGUgQ2hhaXJzIGFuZCB0 aGUgQURzIHRvIHNldCBhIGhpZ2ggYmFyIHRvIG9ubHkgYWRvcHQgc29sdXRpb25zIHdpdGggYXQg bGVhc3QgdHdvIGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRpYW5yYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5keSBCaWVybWFuPGJyPg0KPGI+ U2VudDo8L2I+IFNhdHVyZGF5LCBBdWd1c3QgOCwgMjAyMCA3OjEzIEFNPGJyPg0KPGI+VG86PC9i PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy c2l0eS5kZSZndDs7IEFkcmlhbiBGYXJyZWwgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7OyBL ZW50IFdhdHNlbiAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0OzsgTmV0Y29uZiAmbHQ7 bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRjb25mXSBS ZWdhcmRpbmcgMTA4IGFkb3B0aW9uIGh1bXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIEZyaSwgQXVnIDcsIDIwMjAgYXQgMjoxNyBBTSBKdWVyZ2VuIFNjaG9lbndh ZWxkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp dHkuZGUiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QWRyaWFuLDxicj4NCjxicj4NCnRlY2huaWNhbCBkaXNjdXNzaW9uIG9mIHRoZSBkcmFmdHMg b24gdGhlIG1haWxpbmcgbGlzdCB3b3VsZCBoZWxwIG1vcmU8YnI+DQp0aGFuIGhhdmluZyBwcm9j ZXNzIG1ldGEtZGlzY3Vzc2lvbnMuIEl0IGlzIGdvb2QgdG8ga25vdyB3aG8gKG90aGVyPGJyPg0K dGhhbiB0aGUgYXV0aG9ycykgaXMgdm9sdW50ZWVyaW5nIHRvIHN1YnN0YW50aWFsbHkgcmV2aWV3 IHRoZSBkcmFmdHMsPGJyPg0KaXMgd2lsbGluZyB0byBjb250cmlidXRlIHRvIHRoZSBkaXNjdXNz aW9ucyBvZiBhbnkgaXNzdWVzLCBhbmQgaXM8YnI+DQpwbGFubmluZyB0byBpbXBsZW1lbnQgdGhl IHRlY2hub2xvZ3kgZGVmaW5lZCBpbiB0aGUgZHJhZnRzIGFzIHRoaXM8YnI+DQp3aWxsIGxpa2Vs eSBoZWxwIHRoZSBjaGFpcnMgdG8gbWFrZSBhIGRlY2lzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8gaXQgbWFrZXMg bW9yZSBzZW5zZSB0byBkaXNjdXNzIHdoYXQgcHJvYmxlbXMgdGhlIE5FVENPTkYvTkVUTU9EIFdH czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2hv dWxkIGJlIHNvbHZpbmcsIHJhdGhlciB0aGFuIGFkb3B0aW9uIG9mIHNvbHV0aW9ucyZuYnNwO3Rv IHByb2JsZW1zLiBUaGUgV0cgc2hvdWxkIGJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5maW5pc2hpbmcgdXAgY29uZmlndXJlZCBub3RpZmljYXRp b25zLiBUcnkgdG8gc3RhbmRhcmRpemUgYmluYXJ5IHRlbGVtZXRyeSBpbnN0ZWFkPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vZiBqdXN0IGxlYXZp bmcgcGxhY2Vob2xkZXJzIGZvciBwcm9wcmlldGFyeSB2ZW5kb3Igc29sdXRpb25zLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3VyIHF1ZXN0 aW9ucyBhcmUgbW9zdCByZWxldmFudCBiZWNhdXNlIHdlIGRvIG5vdCBoYXZlIGFueSBjbGVhciBk ZWZpbml0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5vciAmcXVvdDtzdXBwb3J0JnF1b3Q7IG9yICZxdW90O29wcG9zZSZxdW90OyBmb3IgYWRv cHRpb24gb2YgYSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlN1cHBvcnQgb2Z0ZW4gbWVhbnMgJnF1b3Q7SSBhbSBoYXBweSBmb3IgeW91 IHRvIHdvcmsgb24gdGhpcyBkcmFmdCZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjdWx0dXJlIG9mIHRoZSBJRVRGIGNyZWF0ZXMg YSBzdHJvbmcgYmlhcyBhZ2FpbnN0IGFueWJvZHkgYWN0dWFsbHk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9wcG9zaW5nIGFkb3B0aW9uIG9mIGFu eXRoaW5nLiBVc3VhbCBhdHRpdHVkZTogJnF1b3Q7TGV0IHBlb3BsZSBleHBlcmltZW50LiBNYXli ZSB0aGV5IHdpbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmNvbWUgdXAgd2l0aCBzb21ldGhpbmcgZ29vZCBpbiB0aGUgZW5kLiZxdW90OzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBvbmx5 IHRoZSBjby1hdXRob3JzIHN1cHBvcnQsIGFuZCBub2JvZHkgb3Bwb3NlcywgdGhlbiB0aGUgd29y ayB3aWxsIGdldCBzdHVjay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9mdGVuIFdHcyBhZG9wdCBhZnRlciBzdWNoIGEgcG9sbCBvdXRjb21lIGFu ZCBhY3Qgc3VycHJpc2VkJm5ic3A7YSB5ZWFyIGxhdGVyIHdoZW48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBkcmFmdCBnb2VzIG5vd2hlcmUu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCi9qczxicj4NCjxicj4NCk9uIEZyaSwgQXVnIDA3LCAyMDIw IGF0IDA5OjU5OjE1QU0gJiM0MzswMTAwLCBBZHJpYW4gRmFycmVsIHdyb3RlOjxicj4NCiZndDsg SGkgY2hhaXJzLDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHRoaW5rIHRoaXMgaXMgYW4gaW50ZXJl c3RpbmcgYXBwcm9hY2ggdG8gZGV0ZXJtaW5pbmcgd2hldGhlciB0aGVyZSBpcyBpbnRlcmVzdCBp biBhIG51bWJlciBvZiBkcmFmdHMgYXQgdGhlIHNhbWUgdGltZSwgYW5kIEkgYWdyZWUgd2l0aCB5 b3UgdGhhdCBhIGh1bSBhdCBhIHdvcmtpbmcgZ3JvdXAgbWVldGluZyBtZWFucyBub3RoaW5nIHdp dGhvdXQgY29uZmlybWluZyB0aGUgb3BpbmlvbiBvbiB0aGUgbWFpbGluZyBsaXN0Ljxicj4NCiZn dDsgPGJyPg0KJmd0OyBCdXQgSSdtIHdvcnJpZWQgdGhhdCB5b3UgbWF5IGJlIGludHJvZHVjaW5n IHlldCBhbm90aGVyIHBpZWNlIG9mIHByb2Nlc3MgaW50byBob3cgd2UgcHJvY2VzcyBkb2N1bWVu dHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBhZG9wdGlvbiBwb2xsLCBpdHNlbGYsIGlzIG5v dCBuZWNlc3NhcnkgaWYgaXQgaXMgb2J2aW91cyB0byB0aGUgY2hhaXJzIHRoYXQgYSBkcmFmdCBp cyB3aXRoaW4gY2hhcnRlciBhbmQgaGFzIHN1cHBvcnQgW1JGQzcyMjFdLiBCdXQgaW4gYWRkaXRp b24gdG8gdGhlIHBvbGwsIHdlIGFsc28gaGF2ZSBzb21laG93IGludHJvZHVjZWQgYW4gSVBSIHBv bGwgYXQgYWRvcHRpb24gdGltZSAod2hpbGUgSSBjYW4gc2VlIHRoZSBtZXJpdHMgb2YgYmVpbmcN CiBleHBsaWNpdCBhYm91dCBJUFIsIGFuZCB3ZSBoYXZlIHNlZW4gb25lIG9yIHR3byBwZW9wbGUg YXR0ZW1wdCB0byB3cmlnZ2xlIG91dCBvZiB0aGVpciByZXNwb25zaWJpbGl0aWVzLCBpdCBzZWVt cyB1bm5lY2Vzc2FyeSB0byBzZXJpYWxpemUgdGhlIHR3byBjYWxscykuIE5vdyB5b3UgYXBwZWFy IHRvIGJlIGludHJvZHVjaW5nIGFuIGFkZGl0aW9uYWwgc3RlcCB0byB0ZXN0ICZxdW90O2Fkb3B0 aW9uIHN1aXRhYmlsaXR5JnF1b3Q7Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBDYW4gSSB1cmdlIHlv dSAoc3Ryb25nbHk/IDotKSB0byBjb25zaWRlciB0aGUgcmVzcG9uc2VzIHRvIHlvdSBhZG9wdGlv biBzdWl0YWJpbGl0eSB0ZXN0cyBhbmQsIGlmIHRoZXkgYXJlIHNvbGlkLCB0byBtb3ZlIHN0cmFp Z2h0IHRvIGFkb3B0aW9uIHdpdGhvdXQgbWFraW5nIHRoZSB3b3JraW5nIGdyb3VwIGdvIHRob3Vn aCBhIHByb2xvbmdlZCBzZXJpZXMgb2YgcG9sbHMuIFdlIHdvdWxkLCBJIHRoaW5rLCBwcmVmZXIg dG8gZ2V0IG9uIHdpdGgNCiB0aGUgd29yayE8YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVzdCw8YnI+ DQomZ3Q7IEFkcmlhbjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCiZndDsgRnJvbTogbmV0Y29uZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBLZW50IFdhdHNlbjxicj4NCiZndDsgU2VudDogMDUgQXVn dXN0IDIwMjAgMjM6MTM8YnI+DQomZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi4ub3JnPC9hPjxicj4NCiZndDsgU3Vi amVjdDogW25ldGNvbmZdIFJlZ2FyZGluZyAxMDggYWRvcHRpb24gaHVtczxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IE5FVENPTkYgV0csPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgVGhlIENoYWlycyAmYW1wOyBBRCBkaXNjdXNzZWQgdGhlIHJlc3VsdHMgb2YgdGhlIHZh cmlvdXMgYWRvcHRpb24gaHVtcyBjb25kdWN0ZWQgZHVyaW5nIHRoZSAxMDggbWVldGluZy4mbmJz cDsgVGhlcmUgaXMgYSBzZW5zZSB0aGF0IHRoZSByZXN1bHRzIGRpZG7igJl0IGFkZXF1YXRlbHkg ZGV0ZXJtaW5lIGlmIHRoZSBkcmFmdHMgc2hvdWxkIGJlIGFkb3B0ZWQuJm5ic3A7IEluIHBhcnRp Y3VsYXIsIGl0IHdhc27igJl0IGNsZWFyIGlmIHRoZSBodW1zIHJlZmxlY3RlZCBhIGdlbmVyYWwN CiBkZXNpcmUgdG8gc29sdmUgdGhlIHByb2JsZW0gb3Igc3VwcG9ydCBmb3IgdGhlIHBhcnRpY3Vs YXIgZHJhZnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFzIHN1Y2gsIHdl4oCZdmUgZGVjaWRlZCB0 byBzZW5kIHN1YnNlcXVlbnQgZW1haWxzIGZvciBlYWNoIGRyYWZ0LCBvciBzZXQgb2YgZHJhZnRz IGlmIGFwcHJvcHJpYXRlLCB0byBzb2xpY2l0IGlucHV0IG9uIGZvbGxvd2luZyBxdWVzdGlvbnM6 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsxKSBpcyB0aGUgcHJvYmxl bSBpbXBvcnRhbnQgZm9yIHRoZSBORVRDT05GIFdHIHRvIHNvbHZlPzxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOzIpIGlzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJhc2lzIGZvciB0aGUgd29y az88YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBORVRDT05GIENoYWlyczxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbmV0Y29uZiBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48YnI+ DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7IG5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVm PSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi5v cmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PGJyPg0KPGJyPg0KLS0gPGJyPg0KSnVlcmdlbiBTY2hv ZW53YWVsZGVyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtKYWNvYnMg VW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8YnI+DQpQaG9uZTogJiM0Mzs0OSA0MjEgMjAwIDM1ODcm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJy ZW1lbiB8IEdlcm1hbnk8YnI+DQpGYXg6Jm5ic3A7ICZuYnNwOyYjNDM7NDkgNDIxIDIwMCAzMTAz Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwczovL3d3 dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5qYWNv YnMtdW5pdmVyc2l0eS5kZS88L2E+Jmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNv bmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_cacf1f0b19ec4b4bac34d42ab9bae254huaweicom_-- From nobody Mon Aug 10 12:37:49 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EEA3A0C58 for ; Mon, 10 Aug 2020 12:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUzKMzZtwehG for ; Mon, 10 Aug 2020 12:37:46 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C073A0C56 for ; Mon, 10 Aug 2020 12:37:46 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id w14so10916986ljj.4 for ; Mon, 10 Aug 2020 12:37:45 -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=M125yB44sdG6Q1J/APwQuGzk5oEKrYgGL6T9Mn5PeLA=; b=ClJuHBkt723/92plDQN00cMnMXHeuRGC9yxItKSPYiuMRzOYJ889eSfGk4qWk/U6hy 6EGL/WuyyUJDpFDrDHwkgkof1NccMS2DxiLDaeEp2K376gR/NzZEotOgtjXC4OrrdnrH sicw7eaweCqbTNsPh+vJTIQMw09NNbiCcnePb8KBEJnm9BSzD+PQ8UZCOfJprP+uiJUm QAx4sHj3WxdK21ZJitriiIBeTgaCnNbvs4H3M08OZ4oaWFxSJ/+PgQnERWZxg31iwbiY JMcOQJhgmHchaDoD0t6Y0llXXNeuhiT6hGG874To5qKGeqjFbTIwmF44M76lnVorfuZC xovg== 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=M125yB44sdG6Q1J/APwQuGzk5oEKrYgGL6T9Mn5PeLA=; b=BQxScVMTRFvWopD0RQa++C24g38SA1u9Si9R8M47x7Q9e6XzAms5QS8tJT+K1qxzIb 3c8Wkm8RgqAxhGnRgP5wJexvTiI4EUwoBtHWFFJPCKekVv3otbk32cxt1TcJzvXkdWsN dkTlYxF/NvYQ4+GJcHGoHVHbqrAvU2+YdJyYrFVTRmlyG/7zdbsQU9k1o9IA0f6B81Fy 8zAQjQMhRbtPtz8UnHnmxosgQffSB18A1GBRtboqVbiA4a2KvTUJqm7Dkdg9Pou5OwvN jwzW1jL+ZDt6eaJivixedxq93bI1xw+Gex/Cz7O+qv6ZTVrUWtGuL874dypR+m9enkiO M0tA== X-Gm-Message-State: AOAM533GJlAgKhhdQq5rZ3OYTJ94fQmjLf40jnBA1Sw7bGRArrw1Oj2E uK1viEEHZ7eEuwHBPtzg1l1m9Rwr6gExZ4AtSPw7YQ== X-Google-Smtp-Source: ABdhPJy85KhjHDAFo3dgJPxgl6VtxU9yR6qd45pl9gnrpWJWiRV/2hxpJVug68561C92GOiOynGLsNphyukDod7JcO0= X-Received: by 2002:a2e:99d5:: with SMTP id l21mr1216500ljj.320.1597088264077; Mon, 10 Aug 2020 12:37:44 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> In-Reply-To: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> From: Andy Bierman Date: Mon, 10 Aug 2020 12:37:33 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a7df9e05ac8b16ba" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:37:48 -0000 --000000000000a7df9e05ac8b16ba Content-Type: text/plain; charset="UTF-8" Hi, I am trying to understand the NETCONF WG plan for UDP transport of notifications. The WG was developing a UDP draft already I think, and it was dropped. https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-05 Since the WG dropped this problem and work item already, why should it reverse that decision and start over with a new solution? Andy On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen wrote: > NETCONF WG, > > Per the previous email sent moments ago, the chairs would like to solicit > input on the following draft: > > Title: UDP-based Transport for Configured Subscriptions > Link: https://tools.ietf.org/html/draft-unyte-netconf-udp-notif > Abstract: > > This document describes an UDP-based notification mechanism to > collect data from networking devices. A shim header is proposed to > facilitate the streaming of data directly from line cards to a > collector. The objective is to rely on a lightweight approach to > allow for higher frequency and better transit performance compared to > already established notification mechanisms. > > > In particular, please discuss adoption-suitability as it regards to the > following questions: > > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? > > > PS: this message is itself not an adoption poll, but rather an attempt to > gauge interest/support for a potential future adoption poll. > > NETCONF Chairs > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000a7df9e05ac8b16ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am trying to understand the NETCO= NF WG plan for UDP transport of notifications.

The= WG was developing a UDP draft already I think, and it was dropped.
https://tools.ietf.org/html/draft-ietf-netconf-udp-= pub-channel-05

Since the WG dropped this p= roblem and work item already, why should it reverse that decision
and start over with a new solution?


Andy


On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen <<= a href=3D"mailto:kent%2Bietf@watsen.net" target=3D"_blank">kent+ietf@watsen= .net> wrote:
NETCONF WG,

Per the previous email sent moments ago, the chairs would like to solicit i= nput on the following draft:

=C2=A0 =C2=A0Title: UDP-based Transport for Configured Subscriptions
=C2=A0 =C2=A0Link: https://tools.ietf.org/h= tml/draft-unyte-netconf-udp-notif
=C2=A0 =C2=A0Abstract:

=C2=A0 =C2=A0 =C2=A0 This document describes an UDP-based notification mech= anism to
=C2=A0 =C2=A0 =C2=A0 collect data from networking devices.=C2=A0 A shim hea= der is proposed to
=C2=A0 =C2=A0 =C2=A0 facilitate the streaming of data directly from line ca= rds to a
=C2=A0 =C2=A0 =C2=A0 collector.=C2=A0 The objective is to rely on a lightwe= ight approach to
=C2=A0 =C2=A0 =C2=A0 allow for higher frequency and better transit performa= nce compared to
=C2=A0 =C2=A0 =C2=A0 already established notification mechanisms.


In particular, please discuss adoption-suitability as it regards to the fol= lowing questions:

=C2=A0 =C2=A0 1) is the problem important for the NETCONF WG to solve?
=C2=A0 =C2=A0 2) is the draft a suitable basis for the work?


PS: this message is itself not an adoption poll, but rather an attempt to g= auge interest/support for a potential future adoption poll.

NETCONF Chairs

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000a7df9e05ac8b16ba-- From nobody Mon Aug 10 12:38:58 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647843A0C64 for ; Mon, 10 Aug 2020 12:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoleslZ3rDYj for ; Mon, 10 Aug 2020 12:38:55 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 571F93A0C5B for ; Mon, 10 Aug 2020 12:38:55 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id w14so10920394ljj.4 for ; Mon, 10 Aug 2020 12:38:55 -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=lbW8fVwfrHZ2GH5HU4vUwfyqQcVqq4UOuPLUJPl631c=; b=UIjtv4fXuKUM0H4WJpr5fActpaxn7Pygn8FHVFAKlMr2nfmGwx18Hoa8s2BqHy8UKn yKZg5XssYpMfCWMEopwvFgyh2kM9BZPCCdv3mJmgJwboPIB8pSwpfJJYemoNzvWhYblI 3bAZ7/KGDLAfquoNxEJgKdeotqXT8RvA0YjxZKpWnoPzKEotR+xT6r7SvecbiD49Sqlr j8UYhBcTK5tCCW0+tKZ0TSYxqfDxT82E7RMGjU3A8Z8wpwvDo+W9qcGhT8ivUQLV0hEc 5aOSZQrk42biEsxgEPL6AggLb5VFP6uT/CCS7Y8YXGolDA/v1LjfHgNuAPUuSkWeRGuh qExw== 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=lbW8fVwfrHZ2GH5HU4vUwfyqQcVqq4UOuPLUJPl631c=; b=doPg/mEt+vPoB3RW71Ml8y8vdVlwIYve1FtD8GpOU5DUR8hMd1v0qTAFklINizZhd1 NoVeVWTFt85CcqWhBD5dkSN/UTNbA3ivKiC28FI1B+j+8ScXDU24RKQkJ9AtglCS/S42 NrYkkkPMjh6YuOjXMPkHQdWG38ejquNgRtk9XGQjRe4tMK/ggvwUcAqRmwq+m7nzxDvI J/x8T3EaabGDaiuc5oy4w7/60kQDrncYyzKS/uOXPfoM7X5TXaZlXnkJUJyeIo+8XOFd XKMFGkFcJuTGx/1fSMJyPi0Sca2o/KLresuoro/HIG30SLI2r7AFb0DtS4cJUlKPjrOq rPMQ== X-Gm-Message-State: AOAM532RSbC0kbM04c5hFm/SgqAG45/ZeGcyGQ4hb5z64YKJtMUiuiKX ALAXEv4HPU1vvaaqQduokYwGRD1H7Kgw1odh23Mt/g== X-Google-Smtp-Source: ABdhPJxEvC29cm8qYJhmoXprC/DSR+f1HRXCuSH4w0k7UntY5+5gHxLXr1/VjrLnpNuEFN292NFrjfnWopooPM/zwWI= X-Received: by 2002:a2e:9dd0:: with SMTP id x16mr1262505ljj.144.1597088333392; Mon, 10 Aug 2020 12:38:53 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> In-Reply-To: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> From: Andy Bierman Date: Mon, 10 Aug 2020 12:38:42 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c98b5505ac8b1a43" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:38:57 -0000 --000000000000c98b5505ac8b1a43 Content-Type: text/plain; charset="UTF-8" Hi, I am trying to understand what problem this draft attempts to solve. It appears from the solution proposal is that the problem to be solved is the lack of message generator identifiers associated with configured subscriptions. These identifiers could presumably help a client understand some implementation details related to a subscription. The solution seems to rely on the message-generator-id field in the notification message (which does not exist in current RFCs). I do not understand why the client needs this feature. Andy On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen wrote: > NETCONF WG, > > Per the previous email sent moments ago, the chairs would like to solicit > input on the following draft: > > Title: Subscription to Distributed Notifications > Link: https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif > Abstract: > > This documents describes extensions to the YANG notifications > subscription to allow metrics being published directly from > processors on line cards to target receivers, while subscription is > still maintained at the route processor in a distributed forwarding > system. > > > In particular, please discuss adoption-suitability as it regards to the > following questions: > > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? > > > PS: this message is itself not an adoption poll, but rather an attempt to > gauge interest/support for a potential future adoption poll. > > NETCONF Chairs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000c98b5505ac8b1a43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am trying to understand what prob= lem this draft attempts to solve.
It appears from the solution pr= oposal is that the problem to be solved is
the lack of message ge= nerator identifiers associated with configured subscriptions.
The= se identifiers could presumably help a client understand some implementatio= n details
related=C2=A0to a subscription.=C2=A0 The solution seem= s to rely on the message-generator-id
field in the notification m= essage (which does not exist in current RFCs).

I d= o not understand why the client needs this feature.


Andy


On Wed, Aug 5, 2020 at 3:14 PM Ke= nt Watsen <k= ent+ietf@watsen.net> wrote:
NETCONF WG,=

Per the previous email sent moments ago, the chairs w= ould like to solicit input on the following draft:

=C2=A0 =C2=A0Tit= le:=C2=A0Subscription to Distributed Notifications
=C2=A0 =C2=A0Link: https://too= ls.ietf.org/html/draft-unyte-netconf-distributed-notif=C2=A0 =C2=A0Abstract:

=
=C2=A0 =C2=A0 =C2=A0 This documents desc= ribes extensions to the YANG notifications
=C2=A0 =C2=A0 =C2=A0 subscription to allow metrics be= ing published directly from
=C2=A0 =C2=A0 =C2=A0 processors on line cards to target receivers, w= hile subscription is
= =C2=A0 =C2=A0 =C2=A0 still maintained at the route processor in a distribut= ed forwarding
=C2=A0 = =C2=A0 =C2=A0 system.


In particular, please discuss adoption-suitabil= ity as it regards to the following questions:

=C2=A0 =C2= =A0 1) is the problem important for the NETCONF WG to solve?
=C2=A0 =C2= =A0 2) is the draft a suitable basis for the work?


PS: this message is itself not an adoption poll, but r= ather an attempt to gauge interest/support for a potential future adoption = poll.

NETCONF Chairs
__________________________= _____________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000c98b5505ac8b1a43-- From nobody Mon Aug 10 12:39:23 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5AF3A0CA4 for ; Mon, 10 Aug 2020 12:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEbApyGRC7sN for ; Mon, 10 Aug 2020 12:39:19 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5483A0C9C for ; Mon, 10 Aug 2020 12:39:18 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id v9so10921699ljk.6 for ; Mon, 10 Aug 2020 12:39:18 -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=kw1kQwroDwpAqF3aJz4tsw5jb7HZsCEcIf7ZO69PJNw=; b=bpqSeKKa450cr64E3SbiamkOPiC8sLsxVE06xEbjLNJbbc+wLndKmt4Y/5F1sRNIlf eSWyed+Go+gD035r5ArT8yUx0NVzL+duzDHffsb5PJ9IqBcxLsK9jSH3fXFL3KA0l6AZ fPyC56jDteoKMh7yt/VY6GgTjSsL6DOhYAsTVu0PlT+2uqsjvnBLOAdFW4LOrI0oyg8M oVIuoO9haw2qqjXGOcFthjhGYh32Tdw+Vu6d73MV3xAMkT2sYMrxYykwPP/4ouDC9FNd JpZ9uxLctcqKx7cQOh/tUW+7rrXJN/8xC6XO41KCsU3VjMbebssE8uLcVWSKHIPD5UT1 MutA== 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=kw1kQwroDwpAqF3aJz4tsw5jb7HZsCEcIf7ZO69PJNw=; b=Wnxr0rPrL3o7I3NCUhQo2Ux4KIBmXXYOUWAODFrxm4SHy/3AsN9vHQ6Q2oVEdFtrhH Vp/sRn8uC7ENQcjB+oqJJMr3RQTShpPo+WOj+ZmqTRbQWh5PBV5H54WRm39+oHVfp/7x VR/yjPE/QEjy0pc4E0VY5HtH+kjobZdrYJyjGSN/OLZRNr1Egt39xcUyL2kTa1D5Vbj4 d2RYui5uCBDsIkps/MsREqYtvMif5oy7wQXjw+1chqLCEkto9e0KfG6akKlEBU+B37Qg omocwjZwtugA/Ijoh9VAQXG0EbI84UiBb3n4BlNErojbZXIb2XBhHYR2hiuWzJEzbuTd 1J+Q== X-Gm-Message-State: AOAM533gO6mTnIRqF2C/ROqBhVQOv9QZdG9IgdnP/FMHaRhGDSVumwVv XWA9SZu2d2YUTiVzt+uDZ4Tq1uTHomcowsmqlLKxVA== X-Google-Smtp-Source: ABdhPJycq4ucfv4myuPr9C6wD9Mfl9ktgZWpx7DMS8hNd+pIE4aqyRmPZxcD8dtMYQBEWyN7KnFpQlR5Wp5tiKyd0Ik= X-Received: by 2002:a2e:9d17:: with SMTP id t23mr1279339lji.456.1597088356298; Mon, 10 Aug 2020 12:39:16 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b384f3-c7f261da-cea4-480d-a696-38a436c43c16-000000@us-east-1.amazonses.com> In-Reply-To: <01000173c0b384f3-c7f261da-cea4-480d-a696-38a436c43c16-000000@us-east-1.amazonses.com> From: Andy Bierman Date: Mon, 10 Aug 2020 12:39:05 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="00000000000027337c05ac8b1c51" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:39:22 -0000 --00000000000027337c05ac8b1c51 Content-Type: text/plain; charset="UTF-8" Hi, I am trying to understand the problem this draft is attempting to solve. The premise seems to be that the error handling and "hints" mechanism in RFC 8639 and RFC 8641 do not work and the client needs to retrieve extensive monitoring info to determine how to setup notifications on the server. In theory this data could be used to prevent an to be returned for or IMO the current approach is much better than this proposed approach. The server can provide the hints based on the exact request from the client. The static "per-node" monitoring data can be quite large, and yet not provide the correct answer for a specific combination of subscription parameters. Andy On Wed, Aug 5, 2020 at 3:17 PM Kent Watsen wrote: > > NETCONF WG, > > Per the previous email sent moments ago, the chairs would like to solicit > input on the following draft: > > Title: Telemetry Data Export capability > Link: https://tools.ietf.org/html/ > draft-tao-netconf-data-export-capabilities > Abstract: > > This document proposes a YANG module for telemetry data export > capability which augments system Capabilities model and provides > additional telemetry data export attributes associated with system > capability for transport dependent capability negotiation. > > > In particular, please discuss adoption-suitability as it regards to the > following questions: > > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? > > > PS: this message is itself not an adoption poll, but rather an attempt to > gauge interest/support for a potential future adoption poll. > > NETCONF Chairs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --00000000000027337c05ac8b1c51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am trying to understand the probl= em this draft is attempting to solve.
The premise seems to be tha= t the error handling and "hints" mechanism=C2=A0
in RFC= 8639 and RFC 8641 do not work and the client needs to retrieve
e= xtensive monitoring info to determine how to setup notifications on the ser= ver.
In theory this data could be used to prevent an <rpc-erro= r> to be returned
for <establish_subscription> or <ed= it-config>

IMO the current approach is much bet= ter than this proposed approach.
The server can provide the hints= based on the exact request from the client.
The static "per= -node" monitoring data can be quite large, and yet not provide
the correct answer for a specific combination of subscription parameters= .


Andy

On Wed, = Aug 5, 2020 at 3:17 PM Kent Watsen <kent+ietf@watsen.net> wrote:

NETCONF WG,

Per the previous ema= il sent moments ago, the chairs would like to solicit input on the followin= g draft:

=C2=A0 =C2=A0Title:=C2=A0Telemetry Data Export capabilit= y
=C2=A0 =C2=A0Link: https://tools.ietf.org/html/= draft-tao-netconf-data-export-c= apabilities
=C2=A0 =C2=A0Abstract:=

=C2=A0 =C2=A0 =C2=A0 This d= ocument proposes a YANG module for telemetry data export
=C2=A0 =C2=A0 =C2=A0 capability which a= ugments system Capabilities model and provides
=C2=A0 =C2=A0 =C2=A0 additional telemetry data ex= port attributes associated with system
=C2=A0 =C2=A0 =C2=A0 capability for transport dependent = capability negotiation.


In particular, please discuss adoption= -suitability as it regards to the following questions:

=C2=A0 = =C2=A0 1) is the problem important for the NETCONF WG to solve?
=C2=A0 = =C2=A0 2) is the draft a suitable basis for the work?


PS: this message is itself not an adoption poll, bu= t rather an attempt to gauge interest/support for a potential future adopti= on poll.

NETCONF Chairs
_____________________= __________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--00000000000027337c05ac8b1c51-- From nobody Mon Aug 10 12:39:40 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD6C3A0C86 for ; Mon, 10 Aug 2020 12:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qntXpVmTb6qm for ; Mon, 10 Aug 2020 12:39:32 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 0704E3A0C99 for ; Mon, 10 Aug 2020 12:39:31 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id b11so5354301lfe.10 for ; Mon, 10 Aug 2020 12:39:31 -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=dKWaU6PQG19x7RQ4BtJ5KVDemUyZFGlT497+i/br5Og=; b=VP5J/TW92AvjcIXeEyDNScx12TipeUieewZzrRKJmDTwBOhFPedEjncyaSmEXZisbb ErKcNp9Gl/zZx+nXsh05aWH3REoJ0+zOn/KURz2zwL2GzByp1NfvF3lVb7vd++/swpyP bX9qS0YzqPVUnNz0BAMaIa6Nn0Y88wkV2LOwfdvmn/bDnosRVCIEWUENwrDAipq48fQL pTB9cP893+1FDIwlKmusywNqSYP4gdKtFHMEKohNvgOdjbx0u5qSVRaEorOjuGwmcjUW uaQ5yp/tHgf8rbsYtOM0q0xTiZSnNJPujIdxv/yBTV0gE3lPsYfWD9CiKYB9+MGAmySj dWOA== 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=dKWaU6PQG19x7RQ4BtJ5KVDemUyZFGlT497+i/br5Og=; b=mMED4+9LOkefDu44/BKw23EiUb+eNK1zs566AUNQriKyF2NKfb40nE87REZGaLZ0M6 X50O0/VB8SgTJ/DexHpq8/QmUGD0O490MliXhNsuvt6rUap9njOIzOT8v2kXtbsG606D eau7BS09a6HDMvZ8+LkZ/GuVmmkDAOHZitc9pcao6oPIHJXUrF4MBQlUCo6zM+H+B3VF gRgoeFdgsynCsLBl+FahjXE5HCDoG5ckJeGLmLfygcAHwQrt5SUJULH0tlC0n2lQa6Za 4FNEVKHXTM/VcNuqZE/YImDHMDP5hMKAZ2fXN0wCSoiYnhIkTm50EmEgHCNLWqW4yP9Z /4gg== X-Gm-Message-State: AOAM5302kBmflu6qDw57+rHCoyjOafq+bvZfXY0dM3xpO+BHkuUkmupE qod+ObrqA/aCQxgugqjOc8fXC7RtoTPfzTSfZvu37qVnTEg= X-Google-Smtp-Source: ABdhPJw/oGYPLRXlPiLhmV6s1ad007FztCCNEx/2YgJYW8yjty7s6mR5e6J9AEL3g0IS6dosS5DWYCkbKscEaF//9VU= X-Received: by 2002:a05:6512:330c:: with SMTP id k12mr1305236lfe.151.1597088369955; Mon, 10 Aug 2020 12:39:29 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b39fd1-1bd0309b-e56f-4378-b33a-08e9b56a068c-000000@us-east-1.amazonses.com> In-Reply-To: <01000173c0b39fd1-1bd0309b-e56f-4378-b33a-08e9b56a068c-000000@us-east-1.amazonses.com> From: Andy Bierman Date: Mon, 10 Aug 2020 12:39:19 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f7714205ac8b1cf9" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:39:39 -0000 --000000000000f7714205ac8b1cf9 Content-Type: text/plain; charset="UTF-8" Hi, I am trying to understand the problem statement in this draft. It seems to be a way to assign various tags to data node objects. It uses the tags type from ietf-module-tags, which implies that modules and nodes share the same set of tags. There is also an assumption that the error/hints mechanism in RFC 8639 and 8641 do not work and this significant amount of proposed metadata could be used to avoid receiving an for an or request. IMO the current approach is sufficient and new mechanisms are not needed. Andy On Wed, Aug 5, 2020 at 3:18 PM Kent Watsen wrote: > > NETCONF WG, > > Per the previous email sent moments ago, the chairs would like to solicit > input on the following draft: > > Title: Self-explanation data Node tag capability > Link: https://tools.ietf.org/html/ > draft-tao-netconf-notif-node-tag-capabilities > Abstract: > > Before a client application subscribes to updates from a datastore, > server capabilities related to "Subscription to YANG Datastores" can > be advertised using YANG Instance Data format. These server > capabilities can be documented at implement time or reported at run- > time. > > This document proposes a YANG module for self-explanation data Node > tag capability which augments system capabilities model and provide > additional self-explanation data node attributes associated with node > selectors within per-node capabilities. > > > In particular, please discuss adoption-suitability as it regards to the > following questions: > > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? > > > PS: this message is itself not an adoption poll, but rather an attempt to > gauge interest/support for a potential future adoption poll. > > NETCONF Chairs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000f7714205ac8b1cf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am trying to understand the probl= em statement in this draft.
It seems to be a way to assign variou= s tags to data node objects.
It uses the tags type from ietf-modu= le-tags, which implies that modules and nodes
share the same set = of tags.

There is also an assumption that the erro= r/hints mechanism in RFC 8639 and 8641
do not work and this signi= ficant amount of proposed metadata could be used to avoid
receivi= ng an <rpc-error> for an <establish-subscription> or <edit-c= onfig> request.

IMO the current approach is suf= ficient and new mechanisms are not needed.

Andy


On Wed, Aug 5, 2020 at 3:18 PM Kent Watsen <kent+ietf@watsen.net&= gt; wrote:
=
NETCONF WG,

Per the previous email sent moments ago, the chairs would like to soli= cit input on the following draft:
=C2=A0 =C2=A0Title:=C2=A0Self-exp= lanation data Node tag capability
=C2=A0 =C2=A0Link: https://tools.ietf.org/html/draft-tao-netconf-notif-node-tag-= capabilities
=C2=A0 =C2=A0Abstract= :

=C2=A0 =C2=A0 = =C2=A0 Before a client application subscribes to updates from a datastore,<= /span>
=C2=A0 =C2=A0 =C2=A0 = server capabilities related to "Subscription to YANG Datastores" = can
=C2=A0 =C2=A0 =C2= =A0 be advertised using YANG Instance Data format.=C2=A0 These server
=C2=A0 =C2=A0 =C2=A0 capab= ilities can be documented at implement time or reported at run-
=C2=A0 =C2=A0 =C2=A0 time.

=C2=A0 =C2=A0 =C2=A0 This document propose= s a YANG module for self-explanation data Node
=C2=A0 =C2=A0 =C2=A0 tag capability which augment= s system capabilities model and provide
=C2=A0 =C2=A0 =C2=A0 additional self-explanation data no= de attributes associated with node
=C2=A0 =C2=A0 =C2=A0 selectors within per-node capabilities.<= /span>


In particular, please discuss adoption-suitability as it= regards to the following questions:

=C2=A0 =C2=A0 1) is the pro= blem important for the NETCONF WG to solve?
=C2=A0 =C2=A0 2) is the draf= t a suitable basis for the work?

<= br>PS: this message is itself not an adoption poll, but rather an attempt t= o gauge interest/support for a potential future adoption poll.

NETCO= NF Chairs
__________________________________________= _____
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000f7714205ac8b1cf9-- From nobody Mon Aug 10 12:39:56 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8EE3A0C7B for ; Mon, 10 Aug 2020 12:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jB8R1jzfpw1W for ; Mon, 10 Aug 2020 12:39:45 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8799A3A0C6F for ; Mon, 10 Aug 2020 12:39:45 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id g6so10877705ljn.11 for ; Mon, 10 Aug 2020 12:39:45 -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=FiRcbOv4QTUkQFDsemdCJM7gotsKEZBeloP/GqI/l/g=; b=pcT4Tnw4ZcdxSAGzw31/mGnUvWHBIa6hAWQ//6wKw3QtdPvoNG0ZJzRFWnKTXI51wJ Csrd91mCz0WETkV9eyzT97yx3PXLko0GfNTIkgXJBjJx4DH4RoCQeNpoF27Iwf/mnntS 5/gN8FcNQLv+yvuxYnwZQX3LKeE/rEUxJvmafLvr0jur8M3xwahe3CkBTILNb6/xMz7a mEhbEBEsICo2XX7AKCWabt/mubPh/FeDOo08jZPbOkvBmbzIW06PQ1M7DQdSj+qj1Rxb 5VJwbzA8mp7rH/wGtF811V4ijAQ9OjB3fBkvs8du9MGzVUXW3IAwCxFQ440uGj7TgM79 2ufg== 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=FiRcbOv4QTUkQFDsemdCJM7gotsKEZBeloP/GqI/l/g=; b=OMqjJLwB/cA6zJ9FaR8DtyTFaTQ4abC4BUAiLWdiqodk4wB8vRtgANJAKNIgmdNBrq BIMkKpCLY/8b7VWNfhQF1jabGJDH+htJlVwsVl0iSmijM+ecSEjFiS1iZpxQARef7Vvo n+C3IBP01+Mcv9ah1vUgvSw4KsIzt8YuNrd94G0w+H02YVSMZpxMaMhLqAUvZC1BmA6X gkFTTPMn2fv8lijkrtdKlFnW3mImXtz9n2sAgYBhlY+IriwjWaPJtpPsQHs9Dkfdj5Ml u77P6w+ZhNZuEb1cYvK2xLNHnqEaTFEsqMFtAyKkYW5RiAzHzhIP5MI7uAjT75reQkN6 n/ZQ== X-Gm-Message-State: AOAM531lZqMSmqtUzqxfx7STz62YiBpSFB6MOi+2zGiucS9q+Nf5JU3s kFcxQdf+p3MZpjAGyzNpEbEKXtQgZdoD/l6Ck4GlTg== X-Google-Smtp-Source: ABdhPJx09HfqlNpu5umYUtAhzOio86fT5E3dHKJOaXAYBMvL+0aVej4DxgfVIMHnvEC7O9Beu7UsgcHWTxXkA2Sj8Ec= X-Received: by 2002:a2e:1418:: with SMTP id u24mr1287952ljd.120.1597088383596; Mon, 10 Aug 2020 12:39:43 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b44d61-4df9b67b-47f9-46f5-9c91-6e00f466a5c5-000000@us-east-1.amazonses.com> In-Reply-To: <01000173c0b44d61-4df9b67b-47f9-46f5-9c91-6e00f466a5c5-000000@us-east-1.amazonses.com> From: Andy Bierman Date: Mon, 10 Aug 2020 12:39:32 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c7b2ca05ac8b1daa" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-wang-netconf-adaptive-subscription X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:39:55 -0000 --000000000000c7b2ca05ac8b1daa Content-Type: text/plain; charset="UTF-8" Hi, I am trying to understand the problem statement in this draft. It appears to propose a complex self-monitoring system so that YANG Push subscriptions can change their parameters on the fly to adapt to changing network conditions. E.g. lower the 'period' parameter when conditions are right, to produce more push-update records than normal. The problem is somewhat interesting. The filtering mechanisms in YANG Push are really awful and there is a need to improve both filter and trigger mechanisms. I don't think this draft offers a reasonable solution, but I encourage further experimentation. Prove it works in real products then maybe it will be ready for standardization. Andy On Wed, Aug 5, 2020 at 3:18 PM Kent Watsen wrote: > NETCONF WG, > > Per the previous email sent moments ago, the chairs would like to solicit > input on the following draft: > > Title: Adaptive Subscription to YANG Notification > Link: > https://tools.ietf.org/html/draft-wang-netconf-adaptive-subscription > Abstract: > > This document defines a YANG data model and associated mechanism > enabling subscriber's adaptive subscriptions to a publisher's event > streams at various different period intervals with which to report > updates. Applying these elements allows both subscriber and > publisher to automatically adjust the volume of telemetry traffic > sent from publisher to the receivers. > > > In particular, please discuss adoption-suitability as it regards to the > following questions: > > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? > > > PS: this message is itself not an adoption poll, but rather an attempt to > gauge interest/support for a potential future adoption poll. > > NETCONF Chairs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000c7b2ca05ac8b1daa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am trying to understand the probl= em statement in this draft.
It appears to propose a complex self-= monitoring system so that YANG Push
subscriptions can change thei= r parameters on the fly to adapt to
changing network conditions. = E.g. lower the 'period' parameter when
conditions are rig= ht, to produce more push-update records than normal.

The problem is somewhat interesting.
The filtering mechanisms = in YANG Push are really awful and there is a need
to improve both= filter and trigger mechanisms.=C2=A0 I don't think this draft offers
a reasonable solution, but I encourage further experimentation.
Prove it works in real products then maybe it will be ready for sta= ndardization.


Andy


On Wed, Aug 5, 2020 at 3:18 PM Kent Watsen <kent+ietf@watsen.net> wrote:
=
NETCONF WG,

Per the previous e= mail sent moments ago, the chairs would like to solicit input on the follow= ing draft:

=C2=A0 =C2=A0Title:=C2=A0Adaptive Subscription to YANG N= otification
=C2=A0 =C2=A0Li= nk: https://tools.ietf.org/html/draft-wang-netconf-= adaptive-subscription
= =C2=A0 =C2=A0Abstract:

=C2=A0 =C2=A0 =C2=A0 This document defines a YANG data model and associ= ated mechanism
=C2=A0= =C2=A0 =C2=A0 enabling subscriber's adaptive subscriptions to a publis= her's event
=C2= =A0 =C2=A0 =C2=A0 streams at various different period intervals with which = to report
=C2=A0 =C2= =A0 =C2=A0 updates.=C2=A0 Applying these elements allows both subscriber an= d
=C2=A0 =C2=A0 =C2= =A0 publisher to automatically adjust the volume of telemetry traffic
=C2=A0 =C2=A0 =C2=A0 sent = from publisher to the receivers.


In particular, p= lease discuss adoption-suitability as it regards to the following questions= :

=C2=A0 =C2=A0 1) is the problem important for the NET= CONF WG to solve?
=C2=A0 =C2=A0 2) is the draft a suitable basis for the= work?


PS: this message is itself not an adoption poll, but rath= er an attempt to gauge interest/support for a potential future adoption pol= l.

NETCONF Chairs
_____________________________= __________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000c7b2ca05ac8b1daa-- From nobody Mon Aug 10 12:40:33 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4113A0C6E for ; Mon, 10 Aug 2020 12:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOMyGRrjNDw1 for ; Mon, 10 Aug 2020 12:40:23 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 B8F3D3A0C8F for ; Mon, 10 Aug 2020 12:40:22 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id i80so5348205lfi.13 for ; Mon, 10 Aug 2020 12:40:22 -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=QqUrM0JTcUxvZqRgNKoY462Ci50IkT2LGKmC1ytiuUQ=; b=v4IO9TQKS0lAg01th2skoy7t9Tv/8kuaxs8ypiBDWhxNkadxhXhpgTt8tz0tqPiPJM qTVOOKrQ2bX3fp/ILlguEbktuIh/NkeA0TB2o87wrvDDar6CGtBqv0hEtaGPXODVQJiG Ef1yLaZNubdLwKAiYcjDkm0gQBYWdpqBq8A4+AB+CjNMSqw4qmSqM+/eZfweUnfJ/IFH Ezywif1XF7osWrX04ll8mXfg/kta0qCUUafAOD0NpqfmuwUNBeJQGZfZr9UaBXAwFFrL HozoysIszebAyxF8Z43xl1qQyYadnD6SeA77R5WR+EY9gjurLmq2jTIJWLFzyKnTDa79 Kntw== 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=QqUrM0JTcUxvZqRgNKoY462Ci50IkT2LGKmC1ytiuUQ=; b=BRjbHqAYFm/ESnuz350fqvyABxPZcJ+JbHNrGogBl3h3tDIFu30XEyxc6G8Ae7V1NN TfUZbkJEMV4sE1O8lIPS5jq0lySX5KFmNSidVv4xJRP+kI+7whVSo9s0HNjrVZKzTba1 FyyvaO/rV3Tscyw4ehYXDgUQcwJ2JweCptcAD1jjqYy/8N4iYAncytQSWa2wMg+m5/bD w6afcsTqabYAYVzVSuNlt0ZgAr73yRDu8jKM1yNE7JTR+brhVkHLxjbZ89/ZSxdATo6A s1+zmYXOqwtqKoqvUr7QjTWP1fQYbsJsT0N9V7RwnNac4EOugbCUrcvYxLcrK8VVBW3P weNA== X-Gm-Message-State: AOAM532NIBZKKCUm0t0LfFtmc8Uc1LGpSN/TNbOLvOd47PvHoWXyO/s0 9+f5qAz6Owh+fOG/7dD8Pp1M9bD6AzXwu7KyPM1ARThl0Sg= X-Google-Smtp-Source: ABdhPJwsofXx+RuFN0gj4gKGsDfyEhXt8+wLdaVtVrVQowjbmBRDiHlCYCK+bBJBORdamVBjgiNYObAPKrOlw/YcYHg= X-Received: by 2002:a05:6512:1055:: with SMTP id c21mr1324420lfb.84.1597088420825; Mon, 10 Aug 2020 12:40:20 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b45676-dc00a30e-1234-45d2-ba20-131c9467110d-000000@us-east-1.amazonses.com> In-Reply-To: <01000173c0b45676-dc00a30e-1234-45d2-ba20-131c9467110d-000000@us-east-1.amazonses.com> From: Andy Bierman Date: Mon, 10 Aug 2020 12:40:10 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ffa83a05ac8b1f00" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-wang-netconf-bulk-subscribed-notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:40:32 -0000 --000000000000ffa83a05ac8b1f00 Content-Type: text/plain; charset="UTF-8" Hi, I am trying to understand the problem statement in this draft. It seems to be that RFC 8639 does not provide enough configuration capability to specify how notifications from different subscriptions should be bundled together into a single message. There is no discussion of why bundling notifications needs to be standardized, or what benefits it provides over the current RFC 5277 notification message definition. This approach seems to add a lot of complexity without adding much benefit. Andy On Wed, Aug 5, 2020 at 3:19 PM Kent Watsen wrote: > > NETCONF WG, > > Per the previous email sent moments ago, the chairs would like to solicit > input on the following draft: > > Title: Bulk Subscription to YANG Event Notification > Link: https://tools.ietf.org/html/ > draft-wang-netconf-bulk-subscribed-notifications > Abstract: > > This document defines a YANG data model and associated mechanism that > allows subscriber applications to bulk subscribe to publishers' event > streams based on bundle group information such as bundle size and > bundle latency. This allows the publishers to report multiple > notifications in a single bundling message. > > > In particular, please discuss adoption-suitability as it regards to the > following questions: > > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? > > > PS: this message is itself not an adoption poll, but rather an attempt to > gauge interest/support for a potential future adoption poll. > > NETCONF Chairs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000ffa83a05ac8b1f00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am trying to understand the probl= em statement in this draft.
It seems to be that RFC 8639 does not= provide enough configuration capability
to specify how notificat= ions from different subscriptions should be bundled
together into= a single message.=C2=A0 There is no discussion of why bundling
n= otifications needs to be standardized, or what benefits it provides over
the current RFC 5277 notification message definition.
This approach seems to add a lot of complexity without adding m= uch benefit.

Andy


On Wed, Aug = 5, 2020 at 3:19 PM Kent Watsen <kent+ietf@watsen.net> wrote:

NETCONF WG,
Per the previo= us email sent moments ago, the chairs would like to solicit input on the fo= llowing draft:

=C2=A0 =C2=A0Title:=C2=A0Bulk Subscription to YANG E= vent Notification
=C2=A0 =C2=A0Li= nk: https://tool= s.ietf.org/html/draft-wang-netconf-bulk-subscribed-notifications<= /span>
=C2=A0 =C2=A0Abstract:
<= br>
=C2=A0 =C2=A0 =C2=A0 This d= ocument defines a YANG data model and associated mechanism that
=C2=A0 =C2=A0 =C2=A0 allows subs= criber applications to bulk subscribe to publishers' event
=C2=A0 =C2=A0 =C2=A0 streams base= d on bundle group information such as bundle size and
=C2=A0 =C2=A0 =C2=A0 bundle latency.=C2=A0= This allows the publishers to report multiple
=C2=A0 =C2=A0 =C2=A0 notifications in a single bu= ndling message.

=
In particular, please discuss adoption-s= uitability as it regards to the following questions:

=C2=A0 =C2= =A0 1) is the problem important for the NETCONF WG to solve?
=C2=A0 =C2= =A0 2) is the draft a suitable basis for the work?


PS: this message is itself not an adoption poll, but r= ather an attempt to gauge interest/support for a potential future adoption = poll.

NETCONF Chairs
________________________= _______________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000ffa83a05ac8b1f00-- From nobody Mon Aug 10 12:40:47 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231CF3A0C9B for ; Mon, 10 Aug 2020 12:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcMHJA7i8O3k for ; Mon, 10 Aug 2020 12:40:37 -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 806493A0C61 for ; Mon, 10 Aug 2020 12:40:36 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id i19so5366846lfj.8 for ; Mon, 10 Aug 2020 12:40:36 -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=bFkf1gLmwplz29U5ycp5U49drDVxHSvLTht1yTMD5hQ=; b=MRvYCktYyytYWm7srsO8BsB3SRTdE8rvwf2BeCkH84enLsVyAyb+8hioZ/OMcy793d UOYUw9SZwdJWVhGv04nr9rHFHR5QcYEzv7LhdthNV228VKCUCv0tpXXAfbDLBDp61jDE qw6WQdYPg/QwoJGJbIMWAOQpX/BSDy1LydQ5wpRcP+bEs9dDMtf/WEdV+02As+MX7TZ/ 7nbv9dZV4hsVDeklFQAsqHwu0anEdivK6MSfZYxvPrQv5qfuSI6CYSO60gahVCDbcLgG 6dMqZ+70qZJnNCUFjWgKTGZuOCA3uNM2BKc+bxzkoTWcV9mpws3Bm/wmEZ6vcTQMJcfG Iorw== 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=bFkf1gLmwplz29U5ycp5U49drDVxHSvLTht1yTMD5hQ=; b=lO/1Vx8GiNFAmIZjvW8yDnsqlw4kaqxCy01F1QphmukrfocfuBYrwjw9AwLLgdYvGH lwy+aRQd3Pa2k07zaCpYbS0S+B1VJaGZrPnqmL0ZcVAQF8i2+kPCeydU+JmIFFYcGdcR lsLsIftoXdK+hPTbMjgMr1RMYDq0iqYDkr3dbl1DUhxc9suG2C1+2uVLAD9rqk7z83Du x/hhjLnD1sqMwNLVbUy/cHC6v+l1cV61Iug05PiGXEk4wm0GDGQtuHka+ZG/4QiqwK0p QzlIjICx0+51QrvEskGANcH48rkTHmdo38BXX8A9+Y5NQZFDHJNIocNuYESzkuGut9zM ICNg== X-Gm-Message-State: AOAM5313q3SS/HYiRLBvuEMzCsF6h5JmEapK7wzuyXY6Nk+OKOTIhlAb 3k2h9kNmAITclAgVtxmD2OsDzekw2mVCv2Ir6X0GnJ34Lqg= X-Google-Smtp-Source: ABdhPJy3GVgqthR84uQgvzFSiUF/d4c5eKcCkcSmsV1Nkzjle14rHGMZf93SLAQDPW3HS16D1Qv6Vu0v1YbzdETMXm0= X-Received: by 2002:ac2:561b:: with SMTP id v27mr1342673lfd.22.1597088434534; Mon, 10 Aug 2020 12:40:34 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> In-Reply-To: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> From: Andy Bierman Date: Mon, 10 Aug 2020 12:40:23 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d10b3605ac8b20db" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:40:46 -0000 --000000000000d10b3605ac8b20db Content-Type: text/plain; charset="UTF-8" Hi, I am trying to understand the problem addressed in this draft. It appears to be a well-constrained enhancement to SZTP to provide more data in the get-bootstrapping-info RPC. It is not clear that NETCONF WG is the right place for this draft, but given the co-authors involved I think it will get sufficient security area review. I am willing to review the draft (wrt/ RESTCONF related issues). I may implement it in the future, but no plans now. Andy On Wed, Aug 5, 2020 at 3:19 PM Kent Watsen wrote: > > NETCONF WG, > > Per the previous email sent moments ago, the chairs would like to solicit > input on the following draft: > > Title: Conveying a CSR in an SZTP Bootstrapping Request > Link: https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr > Abstract: > > This draft extends the "get-bootstrapping-data" RPC defined in > RFC 8572 to include an optional certificate signing request (CSR), > enabling a bootstrapping device to additionally obtain an identity > certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the > "onboarding information" response provided in the RPC-reply. > > > In particular, please discuss adoption-suitability as it regards to the > following questions: > > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? > > > PS: this message is itself not an adoption poll, but rather an attempt to > gauge interest/support for a potential future adoption poll. > > NETCONF Chairs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000d10b3605ac8b20db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am trying to understand the probl= em addressed in this draft.
It appears to be a well-constrained e= nhancement to SZTP to provide
more data in the get-bootstrapping-= info RPC.

It is not clear that NETCONF WG is the r= ight place for this draft, but
given the co-authors involved I th= ink it will get sufficient security area review.

I= am willing to review the draft (wrt/ RESTCONF related issues).
I= may implement it in the future, but no plans now.


Andy





On Wed, Aug 5, 2020 at 3:19 PM Kent Watsen <kent+ietf@watsen.net> wro= te:
NETCONF WG,

Per the previous email sent moments ago, the chairs would like t= o solicit input on the following draft:

=C2=A0 =C2=A0Title:=C2=A0Co= nveying a CSR in an=C2=A0SZT= P Bootstrapping Request
=C2=A0 =C2=A0Lin= k: https://tools= .ietf.org/html/draft-kwatsen-netconf-sztp-csr
=C2=A0 =C2=A0Abstract:

=C2=A0 =C2=A0 =C2=A0 This draft extends the "get-bo= otstrapping-data" RPC defined in
=C2=A0 =C2=A0 =C2=A0 RFC=C2=A08572=C2=A0to = include an optional certificate signing request (CSR),
=C2=A0 =C2=A0 =C2=A0 enabling a bootstrapping device t= o additionally obtain an identity
=C2=A0 =C2=A0 =C2=A0 certificate (e.g., an LDevID, from IEEE 8= 02.1AR) as part of the
=C2=A0 =C2=A0 =C2=A0 "onboarding information" response provided= in the RPC-reply.

In particular, please discuss adoption-suit= ability as it regards to the following questions:

=C2=A0 =C2=A0 = 1) is the problem important for the NETCONF WG to solve?
=C2=A0 =C2=A0 2= ) is the draft a suitable basis for the work?


PS: this message is itself not an adoption poll, but rather= an attempt to gauge interest/support for a potential future adoption poll.=

NETCONF Chairs
_____________________________= __________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000d10b3605ac8b20db-- From nobody Mon Aug 10 14:47:21 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C643A0D84 for ; Mon, 10 Aug 2020 14:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ko4Ij-7xcS7P for ; Mon, 10 Aug 2020 14:47:17 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 E09013A0D78 for ; Mon, 10 Aug 2020 14:47:17 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id o13so5693390pgf.0 for ; Mon, 10 Aug 2020 14:47:17 -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=uZPnF56P7zJQfqSAXZTWrV62rPHgEG97SQYgyA5124k=; b=hQf946Q4M6kGxRK54d55PaXRVhSvl3BvHAhVaMaF7evOtG0pkzFCMgzmdbSAxr5eqI lii/CNLgEOscN1WUCjcP1S6vQuvGwNZoGWSkJZqNnwqQDP7rhQeuPfHgD2RH28/jFmzP p2cYV9BCX3ph+/XvQnMBFa65UlKF4Hk58M7ZBz7cOLoJmdUeu143NE4sKNWO0o+kiuKD Qe758YV9rGaR+rI6v+d2VEP+fSEgD1hcYQePPGg24/qTyfyc7PdurjARvflwRiyiWD8P iyz6uWSgkiiLUMgtX6niPzbIRLcQkkuQkB/44tq1KA6oCFjY3v8jg72+HBVtp33vW+cb CcjA== 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=uZPnF56P7zJQfqSAXZTWrV62rPHgEG97SQYgyA5124k=; b=CpNo9s7/n41STYhjLpV6j0r0SvLKUW1nsN5Kh3Atwip061s3L8N+1dxLv/asFqczs3 9B87/+DrpyJc/qOCH4Lqt4o86Rv2fMbK3EVzrXSxaOTRvGU4VUUXKYvryW5FEaeCqSKf WhYtcls+KSG+IjKFf0VzNeoGrGlJYuBqLwFGrlpga6pNUpQP1Gie7mTjSr2IsRh5BJ1O eDH1A/2t/yXvFXxTXK6eyVOZG0tUl7jv3FSlfDe/ZvMVjVaQIw6O7Qb8JbGkOfPxua+q WuAGKXxsCcXxkOEoVnzV+TLcwpaF2QB0fbdWURycJ8aqxXuVAC9z+aOM2iYdt6lqxIXv n1aw== X-Gm-Message-State: AOAM530OVwWLCzb4jw/jqOPCDSXhHsRVRH6yKx5Isr7fkTugmwXvkOb/ 7+5AazA9ntmc5/GalztjbSFBZkeF X-Google-Smtp-Source: ABdhPJz+EIJquowvX0OzT3wwl2XqYEhmhqGxoH8fFeqUM3iezlOQhIDFlFQ4c5U0SdhBjC+ffPcGBQ== X-Received: by 2002:a62:18ce:: with SMTP id 197mr2969738pfy.85.1597096037207; Mon, 10 Aug 2020 14:47:17 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:89a1:175d:59c8:8fe? ([2601:647:5600:5020:89a1:175d:59c8:8fe]) by smtp.gmail.com with ESMTPSA id 5sm14248986pfw.25.2020.08.10.14.47.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2020 14:47:15 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C08F1399-00A6-4CD0-B2C6-E0FE8918BC22" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\)) Date: Mon, 10 Aug 2020 14:47:14 -0700 In-Reply-To: Cc: "netconf@ietf.org" To: Andy Bierman References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> X-Mailer: Apple Mail (2.3445.9.6) Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 21:47:20 -0000 --Apple-Mail=_C08F1399-00A6-4CD0-B2C6-E0FE8918BC22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Andy, > On Aug 10, 2020, at 12:37 PM, Andy Bierman wrote: >=20 > Hi, >=20 > I am trying to understand the NETCONF WG plan for UDP transport of = notifications. >=20 > The WG was developing a UDP draft already I think, and it was dropped. > https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-05 = In IETF 103, there was extensive discussion on = draft-ietf-netconf-udp-pub-channel, with questions raised about the = scope of the draft. In IETF 105 and 106, our guidance (see meeting = minutes) was to repurpose the draft for a UDP notification channel, = which the WG would then ultimately adopt. This draft satisfies that = request. To clarify this further, the datatracker marks the new draft as = a replacement for the draft-ietf-netconf-udp-pub-channel. Mahesh & Kent (as co-chair) >=20 > Since the WG dropped this problem and work item already, why should it = reverse that decision > and start over with a new solution? >=20 >=20 > Andy >=20 >=20 > On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen > wrote: > NETCONF WG, >=20 > Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft: >=20 > Title: UDP-based Transport for Configured Subscriptions > Link: https://tools.ietf.org/html/draft-unyte-netconf-udp-notif = > Abstract: >=20 > This document describes an UDP-based notification mechanism to > collect data from networking devices. A shim header is proposed = to > facilitate the streaming of data directly from line cards to a > collector. The objective is to rely on a lightweight approach = to > allow for higher frequency and better transit performance = compared to > already established notification mechanisms. >=20 >=20 > In particular, please discuss adoption-suitability as it regards to = the following questions: >=20 > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? >=20 >=20 > PS: this message is itself not an adoption poll, but rather an attempt = to gauge interest/support for a potential future adoption poll. >=20 > NETCONF Chairs >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_C08F1399-00A6-4CD0-B2C6-E0FE8918BC22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Andy,

On Aug 10, 2020, at 12:37 PM, Andy Bierman = <andy@yumaworks.com> wrote:

Hi,

I am = trying to understand the NETCONF WG plan for UDP transport of = notifications.

The WG was developing a UDP draft already I think, and it was = dropped.
https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-= 05

In IETF 103, there was extensive discussion on = draft-ietf-netconf-udp-pub-channel, with questions raised about the = scope of the draft. In IETF 105 and 106, our guidance (see meeting = minutes) was to repurpose the draft for a UDP notification channel, = which the WG would then ultimately adopt. This draft satisfies that = request. To clarify this further, the datatracker marks the new draft as = a replacement for the draft-ietf-netconf-udp-pub-channel.

Mahesh & Kent (as co-chair)


Since the WG dropped this problem and work item already, why = should it reverse that decision
and start over with = a new solution?


Andy


On Wed, Aug = 5, 2020 at 3:14 PM Kent Watsen <kent+ietf@watsen..net> wrote:
NETCONF WG,

Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft:

   Title: UDP-based Transport for Configured Subscriptions
   Link: https://tools.ietf.org/html/draft-unyte-netconf-udp-notif    Abstract:

      This document describes an UDP-based notification = mechanism to
      collect data from networking devices.  A shim = header is proposed to
      facilitate the streaming of data directly from line = cards to a
      collector.  The objective is to rely on a = lightweight approach to
      allow for higher frequency and better transit = performance compared to
      already established notification mechanisms.


In particular, please discuss adoption-suitability as it regards to the = following questions:

    1) is the problem important for the NETCONF WG to = solve?
    2) is the draft a suitable basis for the work?


PS: this message is itself not an adoption poll, but rather an attempt = to gauge interest/support for a potential future adoption poll.

NETCONF Chairs

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

= --Apple-Mail=_C08F1399-00A6-4CD0-B2C6-E0FE8918BC22-- From nobody Mon Aug 10 14:58:37 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15FE3A0A68 for ; Mon, 10 Aug 2020 14:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id en6CXrp4WN4Y for ; Mon, 10 Aug 2020 14:58:33 -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 47CE53A0C3D for ; Mon, 10 Aug 2020 14:58:33 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id t11so5806033plr.5 for ; Mon, 10 Aug 2020 14:58:33 -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=l9vO9aB1FLCeQV4Sh3/4d9mG9VJfEQfdxFaOlrL1lpc=; b=Ry6shVfoetPB30XRxIV+Qn5khk1mqEid4wa2YVPVk5Zf813BxhVRjlgter/uTPjc+c pAXRj7F3uU7E/6Cdq5kJRg1hGbBHFx1pPiu8xDuW0ugdUuhL1iH0MT3VVDimOvasP83U WuiZMiQPv3vw3Va/0pgoZl5z5isK5a1MDvgMa0z/zBcoIBYhTBCorNgdAeBY5hfiL4WF jmZauMo/NJoTmRHrBYU2nzg4oIdkC2K4FWKv70xKdUN0O0sY6M5epajmUaW4wyRvvGdD JH2iULs8SjaNfw5/nJHPYiQS8TrCJJP7WZjfYepUx43nQa/h8O6UPe/VBwEKUZBJ33MS /wfQ== 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=l9vO9aB1FLCeQV4Sh3/4d9mG9VJfEQfdxFaOlrL1lpc=; b=jb62Wx1mbME8HrENtYFCkTpVDebbdPzRgY/+OuFg2vFcHqktyQu2iF1BRgd8LXHMcU jDrGhvTwJOeQTvETwiBaHjjxA49OFB1g5p8hP2CJmBKXTCxU85vfWe1LPgSEfRCKVsg8 G9sBL1KifstXnFaxFuTC1948J5sydp1OZczbcltp1YTILRZiJY4m1Nr+1/7+onhKIAYN iI/V2yDIuoVb1Wl0jyMf46PNY1s9apzh8M3g8QmEMlMq8oibKxttWWagxQE0kG8W78Vd qGFDJU7rKLOgn2YDQdR+AcI/Cu2OX+uXEjcBuiGWG4DTbdXu54Zw9qW3SnTfAxSORlVu 2Jpg== X-Gm-Message-State: AOAM532erG00I2EycmOSo8z0/lDNxaaLDYhKv2yJGB+uAXaqA+zlzyKB UKmxOpOZfbe5YnDZFU8hb1k= X-Google-Smtp-Source: ABdhPJxi8IWiTOlN7XkfmnP1Irv9jN6BJakApK9sYVVESsB7c5hAoyzCIee4kf7cLM3TuLohq9xnXA== X-Received: by 2002:a17:902:a9c8:: with SMTP id b8mr26328115plr.2.1597096712724; Mon, 10 Aug 2020 14:58:32 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:89a1:175d:59c8:8fe? ([2601:647:5600:5020:89a1:175d:59c8:8fe]) by smtp.gmail.com with ESMTPSA id y12sm14028578pgi.75.2020.08.10.14.58.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2020 14:58:31 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <0D9FA9D4-043C-4316-A525-261569E81197@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1EDDFBFA-D3D2-4B8D-9B0A-DC86F342CBCD" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\)) Date: Mon, 10 Aug 2020 14:58:31 -0700 In-Reply-To: Cc: "netconf@ietf.org" To: Andy Bierman References: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> X-Mailer: Apple Mail (2.3445.9.6) Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 21:58:35 -0000 --Apple-Mail=_1EDDFBFA-D3D2-4B8D-9B0A-DC86F342CBCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Andy, > On Aug 10, 2020, at 12:40 PM, Andy Bierman wrote: >=20 > Hi, >=20 > I am trying to understand the problem addressed in this draft. > It appears to be a well-constrained enhancement to SZTP to provide > more data in the get-bootstrapping-info RPC. >=20 > It is not clear that NETCONF WG is the right place for this draft, but > given the co-authors involved I think it will get sufficient security = area review. The charter for NETCONF WG includes ZTP, and this comes as a natural = extension of that item. Every WG and draft has to address security = considerations, which this draft tries to do, and the co-authors, who = are security experts, have agreed to review the draft. Therefore, I feel = that NETCONF WG would be a natural place for this draft to progress. >=20 > I am willing to review the draft (wrt/ RESTCONF related issues). > I may implement it in the future, but no plans now. >=20 >=20 > Andy >=20 >=20 >=20 >=20 >=20 > On Wed, Aug 5, 2020 at 3:19 PM Kent Watsen > wrote: >=20 > NETCONF WG, >=20 > Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft: >=20 > Title: Conveying a CSR in an SZTP Bootstrapping Request > Link: https://tools..ietf.org/html/ = draft-kwatsen-netconf-sztp-csr > Abstract: >=20 > This draft extends the "get-bootstrapping-data" RPC defined in > RFC 8572 to include an optional certificate signing request = (CSR), > enabling a bootstrapping device to additionally obtain an = identity > certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the > "onboarding information" response provided in the RPC-reply. >=20 >=20 > In particular, please discuss adoption-suitability as it regards to = the following questions: >=20 > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? >=20 >=20 > PS: this message is itself not an adoption poll, but rather an attempt = to gauge interest/support for a potential future adoption poll. >=20 > NETCONF Chairs > _______________________________________________ > 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 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_1EDDFBFA-D3D2-4B8D-9B0A-DC86F342CBCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Andy,

On Aug 10, 2020, at 12:40 PM, Andy Bierman = <andy@yumaworks.com> wrote:

Hi,

I am = trying to understand the problem addressed in this draft.
It appears to be a well-constrained enhancement to SZTP to = provide
more data in the get-bootstrapping-info = RPC.

It is not = clear that NETCONF WG is the right place for this draft, but
given the co-authors involved I think it will get sufficient = security area review.

The charter for NETCONF WG includes ZTP, and this comes = as a natural extension of that item. Every WG and draft has to address = security considerations, which this draft tries to do, and the = co-authors, who are security experts, have agreed to review the draft. = Therefore, I feel that NETCONF WG would be a natural place for this = draft to progress.

I am willing to review the draft (wrt/ = RESTCONF related issues).
I may implement it in the = future, but no plans now.


Andy





On Wed, Aug 5, 2020 at 3:19 PM Kent = Watsen <kent+ietf@watsen.net> wrote:

NETCONF = WG,

Per the previous email sent moments ago, the = chairs would like to solicit input on the following draft:

   Title: Conveying a CSR in = an SZTP Bootstrapping = Request
   Link: https://tools..ietf.org/html/draft-kwatsen-netconf-sztp-csr
   Abstract:

      This draft extends the = "get-bootstrapping-data" RPC defined in
      = RFC 8572 to include an optional certificate signing request = (CSR),
  =     enabling a bootstrapping device to additionally obtain an = identity
      certificate (e.g., an LDevID, from IEEE = 802.1AR) as part of the
      "onboarding = information" response provided in the RPC-reply.


In particular, please discuss adoption-suitability as it = regards to the following questions:

    = 1) is the problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the = work?


PS: = this message is itself not an adoption poll, but rather an attempt to = gauge interest/support for a potential future adoption poll.

NETCONF = Chairs
____________________________________________= ___
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

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_1EDDFBFA-D3D2-4B8D-9B0A-DC86F342CBCD-- From nobody Mon Aug 10 18:40:49 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6199D3A0EAC for ; Mon, 10 Aug 2020 18:40:48 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.395 X-Spam-Level: X-Spam-Status: No, score=0.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=1.5, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=foxmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfOH0dg_JU1Z for ; Mon, 10 Aug 2020 18:40:45 -0700 (PDT) Received: from qq.com (out203-205-221-249.mail.qq.com [203.205.221.249]) (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 1B7F33A0EA6 for ; Mon, 10 Aug 2020 18:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1597110033; bh=GOLs3bBIRp55PVEBpYGtgrd0g+/Xs38iPgKMiGyau5M=; h=Date:From:To:Cc:Subject:References; b=A7mnEVlkq9gZ1Khf/z3tsu45xxDZvTPQIiSP16Ge90A4TBaYBvBdCIWjyWUWqGSyT WLFkCYiEt6VVFg1k8Lq9vfK+LS582/baJQVndFgxiHetD5SosgYPx0Ib15M/nypUNJ QXblUF38dqgV8pcuEU+o5vR3V0HukPr/Uu0JZ9+c= Received: from cmcc-PC ([221.130.253.135]) by newxmesmtplogicsvrszb6.qq.com (NewEsmtp) with SMTP id A1F27447; Tue, 11 Aug 2020 09:40:31 +0800 X-QQ-mid: xmsmtpt1597110031t33yi6u8c Message-ID: X-QQ-XMAILINFO: NbcURrUi841Mdm4F7pz0EPqcRDYj1q4Nd2IwiGwk9Iw7SqUd+BaLUuS0KeHPOw upCSRnkdaE5GFw+yGbi7hEiMe/xZNREBMLIHsxBpL5FIA7nR50OnFqeHM5Nc2ouvpdiV2XjN4EpW bqvrBNOEP+2wICjCjf/3+pC8PppxWzuukJwlhzl0QIvyI6num5feFp9+oxTtirqBRCBCJEV+6Rib c+ZD2UGksFRUCVFq0xLXcmEXN70Iv93dMGMP8sdEPIdPOz0lKh95PYXKmV87ybX/UM/6XHrVpeAY 6GycTF8+A0lGqTqYdtBXi2NuKi+Kbs0/yQXywJeb7gQMMlm+KIIEJda4bMR9GDDuJJqoHZZLl+++ E/BAB8G2Br6IgCrIrPOfqkiJ9NGayl3NmAVUYH0Sd51iwf3CSrgITzJeEczELzE3y4WPGwSvAnbo kR/0mfEoSWRaaWrHiRQICWuGxE3KvBCB3ZYQZ1iIHJ10xpRquJaH4fs+aXi2lt3FEag86aZgUXCm S4mzGn94hl9tIa+GjCiNFYK7xk+RkxM463N4OWmhHuhi7uuk4kfkgNnJTBZMFel4mDHUkMoGme2/ KFq0Z0Z4SKlpCKJen3fruO3FrkqaicJAEbuVQm8YVMrCADT35QKEJk3IkpKIIzR7w7T/E6MWuxLq 84bTMrwmZFNmbd1K9czjFzmNZbyT0A38B6h39738jaRKw6uW7Y6vwJaO2f04l/hVEi18711Ex1kD kA+dukx/j31u+hZHrc1IdScO529qHlyTaX Date: Tue, 11 Aug 2020 09:42:45 +0800 From: "duzongpeng@foxmail.com" To: "Andy Bierman" , "Kent Watsen" Cc: "netconf@ietf.org" References: <01000173c0b44d61-4df9b67b-47f9-46f5-9c91-6e00f466a5c5-000000@us-east-1.amazonses.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.16.188[cn] Mime-Version: 1.0 Message-ID: <2020081109424438815622@foxmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart215586084164_=----" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-wang-netconf-adaptive-subscription X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 01:40:48 -0000 This is a multi-part message in MIME format. ------=_001_NextPart215586084164_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIEFuZHkNCg0KICAgIEkgYW0gaW50ZXJlc3RlZCBpbiB0aGUgbWVjaGluaXNtLCB0b28uIA0K ICAgIFRoZSBtZWNoZW5pc20gY2FuIGJlIHNlZW4gYXMgYSBtb3JlIGludGVsbGlnZW50IG5lZ29j aWF0aW9uIGJldHdlZW4gdGhlIHNlcnZlciBhbmQgdGhlIGNsaWVudC4NCg0KQmVzdCBSZWdhcmRz DQpab25ncGVuZyBEdQ0KDQoNCg0KZHV6b25ncGVuZ0Bmb3htYWlsLmNvbSAmIGR1em9uZ3BlbmdA Y2hpbmFtb2JpbGUuY29tDQogDQpGcm9tOiBBbmR5IEJpZXJtYW4NCkRhdGU6IDIwMjAtMDgtMTEg MDM6MzkNClRvOiBLZW50IFdhdHNlbg0KQ0M6IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0LXdhbmctbmV0Y29uZi1h ZGFwdGl2ZS1zdWJzY3JpcHRpb24NCkhpLA0KDQpJIGFtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRo ZSBwcm9ibGVtIHN0YXRlbWVudCBpbiB0aGlzIGRyYWZ0Lg0KSXQgYXBwZWFycyB0byBwcm9wb3Nl IGEgY29tcGxleCBzZWxmLW1vbml0b3Jpbmcgc3lzdGVtIHNvIHRoYXQgWUFORyBQdXNoDQpzdWJz Y3JpcHRpb25zIGNhbiBjaGFuZ2UgdGhlaXIgcGFyYW1ldGVycyBvbiB0aGUgZmx5IHRvIGFkYXB0 IHRvDQpjaGFuZ2luZyBuZXR3b3JrIGNvbmRpdGlvbnMuIEUuZy4gbG93ZXIgdGhlICdwZXJpb2Qn IHBhcmFtZXRlciB3aGVuDQpjb25kaXRpb25zIGFyZSByaWdodCwgdG8gcHJvZHVjZSBtb3JlIHB1 c2gtdXBkYXRlIHJlY29yZHMgdGhhbiBub3JtYWwuDQoNClRoZSBwcm9ibGVtIGlzIHNvbWV3aGF0 IGludGVyZXN0aW5nLg0KVGhlIGZpbHRlcmluZyBtZWNoYW5pc21zIGluIFlBTkcgUHVzaCBhcmUg cmVhbGx5IGF3ZnVsIGFuZCB0aGVyZSBpcyBhIG5lZWQNCnRvIGltcHJvdmUgYm90aCBmaWx0ZXIg YW5kIHRyaWdnZXIgbWVjaGFuaXNtcy4gIEkgZG9uJ3QgdGhpbmsgdGhpcyBkcmFmdCBvZmZlcnMN CmEgcmVhc29uYWJsZSBzb2x1dGlvbiwgYnV0IEkgZW5jb3VyYWdlIGZ1cnRoZXIgZXhwZXJpbWVu dGF0aW9uLg0KUHJvdmUgaXQgd29ya3MgaW4gcmVhbCBwcm9kdWN0cyB0aGVuIG1heWJlIGl0IHdp bGwgYmUgcmVhZHkgZm9yIHN0YW5kYXJkaXphdGlvbi4NCg0KDQpBbmR5DQoNCg0KT24gV2VkLCBB dWcgNSwgMjAyMCBhdCAzOjE4IFBNIEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4g d3JvdGU6DQpORVRDT05GIFdHLA0KDQpQZXIgdGhlIHByZXZpb3VzIGVtYWlsIHNlbnQgbW9tZW50 cyBhZ28sIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBzb2xpY2l0IGlucHV0IG9uIHRoZSBmb2xs b3dpbmcgZHJhZnQ6DQoNCiAgIFRpdGxlOiBBZGFwdGl2ZSBTdWJzY3JpcHRpb24gdG8gWUFORyBO b3RpZmljYXRpb24NCiAgIExpbms6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13 YW5nLW5ldGNvbmYtYWRhcHRpdmUtc3Vic2NyaXB0aW9uDQogICBBYnN0cmFjdDoNCg0KICAgICAg VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIGFuZCBhc3NvY2lhdGVkIG1l Y2hhbmlzbQ0KICAgICAgZW5hYmxpbmcgc3Vic2NyaWJlcidzIGFkYXB0aXZlIHN1YnNjcmlwdGlv bnMgdG8gYSBwdWJsaXNoZXIncyBldmVudA0KICAgICAgc3RyZWFtcyBhdCB2YXJpb3VzIGRpZmZl cmVudCBwZXJpb2QgaW50ZXJ2YWxzIHdpdGggd2hpY2ggdG8gcmVwb3J0DQogICAgICB1cGRhdGVz LiAgQXBwbHlpbmcgdGhlc2UgZWxlbWVudHMgYWxsb3dzIGJvdGggc3Vic2NyaWJlciBhbmQNCiAg ICAgIHB1Ymxpc2hlciB0byBhdXRvbWF0aWNhbGx5IGFkanVzdCB0aGUgdm9sdW1lIG9mIHRlbGVt ZXRyeSB0cmFmZmljDQogICAgICBzZW50IGZyb20gcHVibGlzaGVyIHRvIHRoZSByZWNlaXZlcnMu DQoNCg0KSW4gcGFydGljdWxhciwgcGxlYXNlIGRpc2N1c3MgYWRvcHRpb24tc3VpdGFiaWxpdHkg YXMgaXQgcmVnYXJkcyB0byB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczoNCg0KICAgIDEpIGlzIHRo ZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cgdG8gc29sdmU/DQogICAgMikg aXMgdGhlIGRyYWZ0IGEgc3VpdGFibGUgYmFzaXMgZm9yIHRoZSB3b3JrPw0KDQoNClBTOiB0aGlz IG1lc3NhZ2UgaXMgaXRzZWxmIG5vdCBhbiBhZG9wdGlvbiBwb2xsLCBidXQgcmF0aGVyIGFuIGF0 dGVtcHQgdG8gZ2F1Z2UgaW50ZXJlc3Qvc3VwcG9ydCBmb3IgYSBwb3RlbnRpYWwgZnV0dXJlIGFk b3B0aW9uIHBvbGwuDQoNCk5FVENPTkYgQ2hhaXJzDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K ------=_001_NextPart215586084164_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Hi, = Andy

    I am interested in the mechinis= m, too. 
    The mechenism can be seen as a= more intelligent negociation between the server and the client.

Best Regards
Zongpeng Du
=0A

=0A
duzongpeng@= foxmail.com & = ;duzongpeng@chinamobile.com
=0A
 
Date: 20= 20-08-11 03:39
Subject: Re: [n= etconf] Adoption-suitability for draft-wang-netconf-adaptive-subscription<= /div>
Hi,

I am trying to understand the problem stat= ement in this draft.
It appears to propose a complex self-monito= ring system so that YANG Push
subscriptions can change their par= ameters on the fly to adapt to
changing network conditions. E.g.= lower the 'period' parameter when
conditions are right, to prod= uce more push-update records than normal.

The pro= blem is somewhat interesting.
The filtering mechanisms in YANG P= ush are really awful and there is a need
to improve both filter = and trigger mechanisms.  I don't think this draft offers
a = reasonable solution, but I encourage further experimentation.
Pr= ove it works in real products then maybe it will be ready for standardizat= ion.


Andy


On = Wed, Aug 5, 2020 at 3:18 PM Kent Watsen <kent+ietf@watsen.net> wrote:
NETCONF WG,

Per the previous em= ail sent moments ago, the chairs would like to solicit input on the follow= ing draft:

   Title: Adaptive Subscription to YANG= Notification
   = ;Link: https://tools.ietf.org/html/draft-wang-net= conf-adaptive-subscription
   Abstract:

      This document defines a YANG data model and = associated mechanism
      enabling subscriber's adaptive subscriptions to a pu= blisher's event
&nbs= p;     streams at various different period intervals with which = to report
  &nb= sp;   updates.  Applying these elements allows both subscriber a= nd
    &nb= sp; publisher to automatically adjust the volume of telemetry traffic
      sen= t from publisher to the receivers.


In particula= r, please discuss adoption-suitability as it regards to the following ques= tions:

    1) is the problem important for th= e NETCONF WG to solve?
    2) is the draft a suitable basis f= or the work?


PS: this message is itself not an adoption poll, b= ut rather an attempt to gauge interest/support for a potential future adop= tion poll.

NETCONF Chairs
____________________= ___________________________
=0Anetconf mailing list
=0Anetconf@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/netconf
=0A
=0A
=0A ------=_001_NextPart215586084164_=------ . From nobody Mon Aug 10 19:04:42 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38AC3A0EC2 for ; Mon, 10 Aug 2020 19:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7b5jdpdNN8gC for ; Mon, 10 Aug 2020 19:04:39 -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 AA6403A0ED9 for ; Mon, 10 Aug 2020 19:04:38 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id v15so5780707lfg.6 for ; Mon, 10 Aug 2020 19:04: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 :cc; bh=00x5uqhTLKzrSXiDJLidLAGeJsgA1T1CRL3PI0wEbEY=; b=jpqNDv3KCySbPCGTycag73F1cO+MVHj4U6XxhuZqwW+sSFU+obWyfjC+53FL4BDVYl /xHx8z3uLj5XVHavMT7uctuJlOswQ2nmyjITHW3jltqpAvVDx07Ke5zH+5cOWr1x/L9G /y1GJ6FeAgjaqboUFrtTF24v7qdST+XfcCq90Byli9zc8hCE8IUbgi2QADRSGb+nQbeV 3c6rxSp7UB7ac3N99dIhla8oubhaIdIC4JyHA4Bm1NUAqErTkdC5IhkISFsqBJq1R/nS QxpI/wAUT//zz3UVbOUMzFvTnf0jwRKsqTZevzICIfDdV7Pe455Zzt3AVMlNZIA529NE /grQ== 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=00x5uqhTLKzrSXiDJLidLAGeJsgA1T1CRL3PI0wEbEY=; b=on8eD539EnbPPV9SdfFSX35fc9xj0PFxpywMwX8docqoD2ipAXBhZ9Z0ZPu0T7dXVl fjGkx17K3yxIskpvWxomf5iiDPJ/GRh1QSeerEWEHxJyL6WzFWyZdO2u8l1A1DYEahhB KmW2qvlzXl9usvYdzlo/pauhFowZ3A4K7DY2ia4zX7Z+cIbvOf06o1AMtSI7dyC7lfrc HiQGGthD4sUqFknbpFW8v7/5Vdo+8dYiIB62ewGFN3TUGPMcJ1xiMYL9HU9gkllI+4OO B7/TjuIe16lDS555myPKMkyR32OYjR77mLnagkAVzEjjFEi3GqdAyQ/twf9IbIWdUHdv xqhw== X-Gm-Message-State: AOAM5322WEpGRugcXneGiYOQoeKDv2eBWdysfQuNQ0w6rR5M+GEWcKfk xRVBWXHDvb3XL6r6j7akHk5i2KRnILYZeWjesO/waw== X-Google-Smtp-Source: ABdhPJxmUciW57Yo/pfX4czZaPFyh8LZCi6oqbs4GLjrwQViNtDH3GS9wwd0fOvKj7M58dCfmtot/8WTNChTnlm6L/8= X-Received: by 2002:a05:6512:3253:: with SMTP id c19mr1900623lfr.139.1597111476822; Mon, 10 Aug 2020 19:04:36 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b44d61-4df9b67b-47f9-46f5-9c91-6e00f466a5c5-000000@us-east-1.amazonses.com> In-Reply-To: From: Andy Bierman Date: Mon, 10 Aug 2020 19:04:25 -0700 Message-ID: To: "duzongpeng@foxmail.com" Cc: Kent Watsen , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003e3b2f05ac907eeb" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-wang-netconf-adaptive-subscription X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 02:04:41 -0000 --0000000000003e3b2f05ac907eeb Content-Type: text/plain; charset="UTF-8" On Mon, Aug 10, 2020 at 6:40 PM duzongpeng@foxmail.com < duzongpeng@foxmail.com> wrote: > Hi, Andy > > I am interested in the mechinism, too. > The mechenism can be seen as a more intelligent negociation between > the server and the client. > > The draft describes some use-cases for an "ECA Framework". The challenge is how to move client programming logic to the server in a workable solution. Simplistic solutions that allow 1 counter to be checked, etc. are not good enough. Robust solutions that are simple enough to be useful are hard to design and standardize. Obviously the client can poll the server and issue a or to change the push parameters, then change the parameters back again when the special mode is no longer needed. If the network is up, and not too busy, and the latency does not cause events to be missed. IMO, only a generalized ECA solution makes business sense, because it is too complex to duplicate over and over in ad-hoc ways for each point solution. Best Regards > Zongpeng Du > > Andy > ------------------------------ > duzongpeng@foxmail.com & duzongpeng@chinamobile.com > > > *From:* Andy Bierman > *Date:* 2020-08-11 03:39 > *To:* Kent Watsen > *CC:* netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-wang-netconf-adaptive-subscription > Hi, > > I am trying to understand the problem statement in this draft. > It appears to propose a complex self-monitoring system so that YANG Push > subscriptions can change their parameters on the fly to adapt to > changing network conditions. E.g. lower the 'period' parameter when > conditions are right, to produce more push-update records than normal. > > The problem is somewhat interesting. > The filtering mechanisms in YANG Push are really awful and there is a need > to improve both filter and trigger mechanisms. I don't think this draft > offers > a reasonable solution, but I encourage further experimentation. > Prove it works in real products then maybe it will be ready for > standardization. > > > Andy > > > On Wed, Aug 5, 2020 at 3:18 PM Kent Watsen wrote: > >> NETCONF WG, >> >> Per the previous email sent moments ago, the chairs would like to solicit >> input on the following draft: >> >> Title: Adaptive Subscription to YANG Notification >> Link: >> https://tools.ietf.org/html/draft-wang-netconf-adaptive-subscription >> Abstract: >> >> This document defines a YANG data model and associated mechanism >> enabling subscriber's adaptive subscriptions to a publisher's event >> streams at various different period intervals with which to report >> updates. Applying these elements allows both subscriber and >> publisher to automatically adjust the volume of telemetry traffic >> sent from publisher to the receivers. >> >> >> In particular, please discuss adoption-suitability as it regards to the >> following questions: >> >> 1) is the problem important for the NETCONF WG to solve? >> 2) is the draft a suitable basis for the work? >> >> >> PS: this message is itself not an adoption poll, but rather an attempt to >> gauge interest/support for a potential future adoption poll. >> >> NETCONF Chairs >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > --0000000000003e3b2f05ac907eeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 10, 2020 at 6:40 PM duzongpeng@foxmail.com <duzongpeng@foxmail.com> wrote:
Hi, Andy

=C2=A0 =C2=A0 I am interested in t= he mechinism, too.=C2=A0
=C2=A0 =C2=A0 The mechenism can be seen as a= more intelligent negociation between the server and the client.

=

The draft describes som= e use-cases for an "ECA Framework".
The challenge is ho= w to move client programming logic to the server in a workable solution.
Simplistic solutions that allow 1 counter to be checked, etc. are n= ot good enough.
Robust solutions that are simple enough to be use= ful are hard to design and standardize.=C2=A0

Obvi= ously the client can poll the server and issue a <modify-subscription>= ;
or <edit-config> to change the push parameters, then chan= ge the parameters back
again when the special mode is no longer n= eeded. If the network is up, and not too busy,
and the latency do= es not cause events to be missed.=C2=A0

IMO, only a generalized ECA solution makes business sense, because it is t= oo complex
to duplicate over and over in ad-hoc ways for each poi= nt solution.


Best Regards
Zongpeng Du



Andy
=C2=A0
=C2=A0
From:=C2=A0Andy Bierman
Date:=C2=A02020-08-11=C2=A003:39
To:=C2=A0Kent Watsen
CC:=C2=A0net= conf@ietf.org
Subject:=C2=A0Re: [netconf] Adoption-sui= tability for draft-wang-netconf-adaptive-subscription
Hi,

I am trying to understand the problem st= atement in this draft.
It appears to propose a complex self-monit= oring system so that YANG Push
subscriptions can change their par= ameters on the fly to adapt to
changing network conditions. E.g. = lower the 'period' parameter when
conditions are right, t= o produce more push-update records than normal.

Th= e problem is somewhat interesting.
The filtering mechanisms in YA= NG Push are really awful and there is a need
to improve both filt= er and trigger mechanisms.=C2=A0 I don't think this draft offers
<= div>a reasonable solution, but I encourage further experimentation.
Prove it works in real products then maybe it will be ready for standard= ization.


Andy

<= /div>
O= n Wed, Aug 5, 2020 at 3:18 PM Kent Watsen <kent+ietf@watsen.net> wrote:
NETCONF WG,

Per the previous email = sent moments ago, the chairs would like to solicit input on the following d= raft:

=C2=A0 =C2=A0Title:=C2=A0Adaptive Subscription to YANG Notifi= cation
=C2=A0 =C2=A0Link: <= a href=3D"https://tools.ietf.org/html/draft-wang-netconf-adaptive-subscript= ion" target=3D"_blank">https://tools.ietf.org/html/draft-wang-netconf-adapt= ive-subscription
=C2=A0 = =C2=A0Abstract:

=C2= =A0 =C2=A0 =C2=A0 This document defines a YANG data model and associated me= chanism
=C2=A0 =C2=A0= =C2=A0 enabling subscriber's adaptive subscriptions to a publisher'= ;s event
=C2=A0 =C2= =A0 =C2=A0 streams at various different period intervals with which to repo= rt
=C2=A0 =C2=A0 =C2= =A0 updates.=C2=A0 Applying these elements allows both subscriber and
=C2=A0 =C2=A0 =C2=A0 publi= sher to automatically adjust the volume of telemetry traffic<= /div>
=C2=A0 =C2=A0 =C2=A0 sent from publ= isher to the receivers.

In particular, please dis= cuss adoption-suitability as it regards to the following questions:<= /font>

=C2=A0 =C2=A0 1) is the problem important for the NETCONF WG to = solve?
=C2=A0 =C2=A0 2) is the draft a suitable basis for the work?
<= br>
PS: this message is itself not an adoption poll, but rather an attem= pt to gauge interest/support for a potential future adoption poll.

N= ETCONF Chairs
________________________________________= _______
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--0000000000003e3b2f05ac907eeb-- From nobody Mon Aug 10 19:09:17 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23AD3A0ECF for ; Mon, 10 Aug 2020 19:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCVcaJ7MBIvx for ; Mon, 10 Aug 2020 19:09:14 -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 DEA483A0EC2 for ; Mon, 10 Aug 2020 19:09:13 -0700 (PDT) Received: from lhreml726-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 71E8D401E26BDA7AFF70 for ; Tue, 11 Aug 2020 03:09:11 +0100 (IST) Received: from lhreml726-chm.china.huawei.com (10.201.108.77) by lhreml726-chm.china.huawei.com (10.201.108.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 03:09:11 +0100 Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml726-chm.china.huawei.com (10.201.108.77) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 11 Aug 2020 03:09:10 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.234]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0487.000; Tue, 11 Aug 2020 10:09:06 +0800 From: Qin Wu To: Andy Bierman , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities Thread-Index: AdZveVGk4XmdPOMeTNuJrLeH7HLIGQ== Date: Tue, 11 Aug 2020 02:09:06 +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.164.151.108] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD8FAC16dggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 02:09:16 -0000 --_000_B8F9A780D330094D99AF023C5877DABAAD8FAC16dggeml511mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 5Y+R5Lu25Lq6OiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSDku6Po oaggQW5keSBCaWVybWFuDQrlj5HpgIHml7bpl7Q6IDIwMjDlubQ45pyIMTHml6UgMzozOQ0K5pS2 5Lu25Lq6OiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQrmioTpgIE6IG5ldGNv bmZAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBm b3IgZHJhZnQtdGFvLW5ldGNvbmYtZGF0YS1leHBvcnQtY2FwYWJpbGl0aWVzDQoNCkhpLA0KDQpJ IGFtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtIHRoaXMgZHJhZnQgaXMgYXR0ZW1w dGluZyB0byBzb2x2ZS4NClRoZSBwcmVtaXNlIHNlZW1zIHRvIGJlIHRoYXQgdGhlIGVycm9yIGhh bmRsaW5nIGFuZCAiaGludHMiIG1lY2hhbmlzbQ0KaW4gUkZDIDg2MzkgYW5kIFJGQyA4NjQxIGRv IG5vdCB3b3JrDQpbUWluXTogVGhlIGRhdGEgZXhwb3J0IGNhcGFiaWxpdGllcyBpcyBub3QgZGVz aWduZWQgdG8gcmVwbGFjZSBlcnJvciBoYW5kbGluZyBhbmQgaXMgcG9zaXRpb25lZCBhcyBjYXBh YmlsaXR5IG5lZ290aWF0aW9uIGFuZCB1c2VkIGJlZm9yZSBuZXRjb25mIGNvbm5lY3Rpb24gdG8g YmUgc2V0dXAsICB0aGV5IGFyZSBjb21wbGVtZW50YXJ5LA0KZXJyb3IgaGFuZGxpbmcgd2lsbCBi ZSB0aGUgbGFzdCByZXNvcnQNCldoZW4gZHluYW1pYyBzdWJzY3JpcHRpb24gcmVxdWVzdCBpcyBk ZWNsaW5lZCBvciByZWplY3RlZC4gRXJyb3IgaGFuZGxpbmcgaXMgb25seSBhcHBsaWNhYmxlIHRv IGR5bmFtaWMgc3Vic2NyaXB0aW9uDQpiYXNlZCBvbiBzZWN0aW9uIDMuMiBvZiBSRkM4NjQxLg0K DQpPdXIgYXJndW1lbnQgaXMgd2h5IG5vdCBwcmV2ZW50IHRoZSBwcm9ibGVtIHRvIGhhcHBlbiBp biB0aGUgZmlyc3QgcGxhY2UgaW5zdGVhZCBvZiB3YWl0aW5nIGZvciB0aGUgc2VydmVyIG1ha2lu ZyBtaXN0YWtlIGFuZCByZW1lZHkgaXQuDQpPbmUgb2YgcHJpbmNpcGxlIHNldCBieSBSRkM4NjQx IGlzOg0KbWluaW1pemUgdGhlIG51bWJlciBvZiBzdWJzY3JpcHRpb24gaXRlcmF0aW9ucyBiZXR3 ZWVuIHN1YnNjcmliZXIgYW5kIHB1Ymxpc2hlciwgZGlzY291cmFnZSBSYW5kb20gZ3Vlc3Npbmcg b2YgZGlmZmVyZW50IHBhcmFtZXRlcnMgYnkgYSBzdWJzY3JpYmVyLg0KDQpUaGUgc29sdXRpb24g YmVpbmcgcHJvdmlkZWQgaXMgZ2VuZXJpYywgdGFyZ2V0ZWQgdG8gYWRkcmVzcyB0aGlzIGNoYWxs ZW5nZSwgbm90IG9ubHkgYXBwbGljYWJsZSB0byBkeW5hbWljIHN1YnNjcmlwdGlvbiwgYnV0IGFs c28gY29uZmlndXJlZCBzdWJzY3JpcHRpb24uDQoNCmFuZCB0aGUgY2xpZW50IG5lZWRzIHRvIHJl dHJpZXZlDQpleHRlbnNpdmUgbW9uaXRvcmluZyBpbmZvIHRvIGRldGVybWluZSBob3cgdG8gc2V0 dXAgbm90aWZpY2F0aW9ucyBvbiB0aGUgc2VydmVyLg0KDQpJbiB0aGVvcnkgdGhpcyBkYXRhIGNv dWxkIGJlIHVzZWQgdG8gcHJldmVudCBhbiA8cnBjLWVycm9yPiB0byBiZSByZXR1cm5lZA0KZm9y IDxlc3RhYmxpc2hfc3Vic2NyaXB0aW9uPiBvciA8ZWRpdC1jb25maWc+DQoNCg0KSU1PIHRoZSBj dXJyZW50IGFwcHJvYWNoIGlzIG11Y2ggYmV0dGVyIHRoYW4gdGhpcyBwcm9wb3NlZCBhcHByb2Fj aC4NClRoZSBzZXJ2ZXIgY2FuIHByb3ZpZGUgdGhlIGhpbnRzIGJhc2VkIG9uIHRoZSBleGFjdCBy ZXF1ZXN0IGZyb20gdGhlIGNsaWVudC4NCltRaW5dOiBJdCBtYXkgYmUgbGF0ZSwgc3RpbGwgcmVx dWlyZSBtdWx0aXBsZSBzdWJzY3JpcHRpb24gaXRlcmF0aW9ucyBiZXR3ZWVuIHN1YnNjcmliZXIg YW5kIHB1Ymxpc2hlci4gQnV0IGRhdGEgZXhwb3J0IGhhcyBubyBpbnRlbnRpb24gdG8gcmVwbGFj ZSBpdC4gRXJyb3IgaGFuZGxpbmcgaGF2ZSBpdHMgdmFsdWUgaW4gbWFueSBkaWZmZXJlbnQgY2Fz ZXMuDQpUaGUgc3RhdGljICJwZXItbm9kZSIgbW9uaXRvcmluZyBkYXRhIGNhbiBiZSBxdWl0ZSBs YXJnZSwgYW5kIHlldCBub3QgcHJvdmlkZQ0KdGhlIGNvcnJlY3QgYW5zd2VyIGZvciBhIHNwZWNp ZmljIGNvbWJpbmF0aW9uIG9mIHN1YnNjcmlwdGlvbiBwYXJhbWV0ZXJzLi4NCg0KW1Fpbl06IEl0 IGlzIHNlcnZlciBjYXBhYmlsaXR5IGV4cG9zdXJlLCBjaGVjayBlYXJseSBpbXBsYW50YXRpb24g dGltZSBpbmZvcm1hdGlvbiBvZiB0aGUgY2FwYWJpbGl0eSB3aGF0IHRoZSBzZXJ2ZXIgc3VwcG9y dCAoZS5nLiwgR1JQQyB0cmFuc3BvcnQsIFRDUCBzdXBwb3J0LCBVRFAgdHJhbnNwb3J0IHN1cHBv cnQpLA0Kbm90IHRhcmdldGVkIHRvIGtlZXAgdHJhY2sgb2YgZHluYW1pYyBjaGFuZ2UgZGF0YS4N ClRoZXNlIGNhcGFiaWxpdGllcyBzZWxkb20gY2hhbmdlLiBJbiBhZGRpdGlvbiwgdG8gYWxsb3cg dGhlIGNsaWVudCBjb21wb3NlIHZhcmlvdXMgZGlmZmVyZW50IHN1YnNjcmlwdGlvbiBwb2xpY3kg KGUuZy4sIGFkYXB0aXZlIHN1YnNjcmlwdGlvbiksIHdlIHJlcXVpcmUgdGhlIHNlcnZlciB0byBp bmRpY2F0ZSB3aGV0aGVyIHNwZWNpZmljIGRhdGEgb2JqZWN0IHN1cHBvcnRzDQpUaHJlc2hvbGRz IGhhbmRsaW5nLg0KVGhpcyBpcyBtaXNzaW5nIHBpZWNlcyB0byBzdXBwb3J0IGV2ZW50IGJhc2Vk IHRlbGVtZXRyeSBzb2x1dGlvbi4NCg0KQW5keQ0KDQoNCk9uIFdlZCwgQXVnIDUsIDIwMjAgYXQg MzoxNyBQTSBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ8bWFpbHRvOmtlbnQlMkJp ZXRmQHdhdHNlbi4ubmV0Pj4gd3JvdGU6DQoNCk5FVENPTkYgV0csDQoNClBlciB0aGUgcHJldmlv dXMgZW1haWwgc2VudCBtb21lbnRzIGFnbywgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIHNvbGlj aXQgaW5wdXQgb24gdGhlIGZvbGxvd2luZyBkcmFmdDoNCg0KICAgVGl0bGU6IFRlbGVtZXRyeSBE YXRhIEV4cG9ydCBjYXBhYmlsaXR5DQogICBMaW5rOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtdGFvLW5ldGNvbmYtZGF0YS1leHBvcnQtY2FwYWJpbGl0aWVzDQogICBBYnN0cmFj dDoNCiAgICAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBZQU5HIG1vZHVsZSBmb3IgdGVsZW1l dHJ5IGRhdGEgZXhwb3J0DQogICAgICBjYXBhYmlsaXR5IHdoaWNoIGF1Z21lbnRzIHN5c3RlbSBD YXBhYmlsaXRpZXMgbW9kZWwgYW5kIHByb3ZpZGVzDQogICAgICBhZGRpdGlvbmFsIHRlbGVtZXRy eSBkYXRhIGV4cG9ydCBhdHRyaWJ1dGVzIGFzc29jaWF0ZWQgd2l0aCBzeXN0ZW0NCiAgICAgIGNh cGFiaWxpdHkgZm9yIHRyYW5zcG9ydCBkZXBlbmRlbnQgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbi4N Cg0KDQpJbiBwYXJ0aWN1bGFyLCBwbGVhc2UgZGlzY3VzcyBhZG9wdGlvbi1zdWl0YWJpbGl0eSBh cyBpdCByZWdhcmRzIHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOg0KDQogICAgMSkgaXMgdGhl IHByb2JsZW0gaW1wb3J0YW50IGZvciB0aGUgTkVUQ09ORiBXRyB0byBzb2x2ZT8NCiAgICAyKSBp cyB0aGUgZHJhZnQgYSBzdWl0YWJsZSBiYXNpcyBmb3IgdGhlIHdvcms/DQoNCg0KUFM6IHRoaXMg bWVzc2FnZSBpcyBpdHNlbGYgbm90IGFuIGFkb3B0aW9uIHBvbGwsIGJ1dCByYXRoZXIgYW4gYXR0 ZW1wdCB0byBnYXVnZSBpbnRlcmVzdC9zdXBwb3J0IGZvciBhIHBvdGVudGlhbCBmdXR1cmUgYWRv cHRpb24gcG9sbC4NCg0KTkVUQ09ORiBDaGFpcnMNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpuZXRjb25mIG1haWxpbmcgbGlzdA0KbmV0Y29uZkBpZXRm Lm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZg0K --_000_B8F9A780D330094D99AF023C5877DABAAD8FAC16dggeml511mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8 jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg 6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkeS7tuS6ujxzcGFuIGxh bmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5z LXNlcmlmIj4gbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10NCjwvc3Bh bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Luj6KGoIDwvc3Bhbj4NCjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPkFuZHkgQmllcm1hbjxicj4NCjwvc3Bhbj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssc2Fucy1zZXJpZiI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+ PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiAyMDIwPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mb hem7kSZxdW90OyxzYW5zLXNlcmlmIj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+ODwvc3Bhbj7mnIg8 c3BhbiBsYW5nPSJFTi1VUyI+MTE8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDM6Mzk8 YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIj4gS2VudCBXYXRzZW4gJmx0O2tlbnQmIzQzO2lldGZAd2F0c2VuLm5l dCZndDs8YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gbmV0Y29uZkBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvp opg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTog W25ldGNvbmZdIEFkb3B0aW9uLXN1aXRhYmlsaXR5IGZvciBkcmFmdC10YW8tbmV0Y29uZi1kYXRh LWV4cG9ydC1jYXBhYmlsaXRpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGks PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBhbSB0cnlpbmcgdG8g dW5kZXJzdGFuZCB0aGUgcHJvYmxlbSB0aGlzIGRyYWZ0IGlzIGF0dGVtcHRpbmcgdG8gc29sdmUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBwcmVtaXNlIHNlZW1zIHRvIGJlIHRoYXQgdGhlIGVy cm9yIGhhbmRsaW5nIGFuZCAmcXVvdDtoaW50cyZxdW90OyBtZWNoYW5pc20mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+aW4gUkZDIDg2MzkgYW5kIFJGQyA4NjQxIGRvIG5vdCB3b3JrIDxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPltRaW5dOiBUaGUgZGF0YSBleHBvcnQgY2FwYWJpbGl0aWVzIGlzIG5vdCBkZXNpZ25l ZCB0byByZXBsYWNlIGVycm9yIGhhbmRsaW5nIGFuZCBpcyBwb3NpdGlvbmVkIGFzIGNhcGFiaWxp dHkgbmVnb3RpYXRpb24gYW5kIHVzZWQgYmVmb3JlIG5ldGNvbmYNCiBjb25uZWN0aW9uIHRvIGJl IHNldHVwLCAmbmJzcDt0aGV5IGFyZSBjb21wbGVtZW50YXJ5LCA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPmVycm9yIGhhbmRsaW5nIHdpbGwgYmUgdGhlIGxhc3QgcmVzb3J0PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaGVuIGR5bmFtaWMgc3Vic2NyaXB0aW9uIHJlcXVl c3QgaXMgZGVjbGluZWQgb3IgcmVqZWN0ZWQuIEVycm9yIGhhbmRsaW5nIGlzIG9ubHkgYXBwbGlj YWJsZSB0byBkeW5hbWljIHN1YnNjcmlwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+YmFzZWQgb24gc2VjdGlvbiAzLjIgb2YgUkZDODY0MS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PdXIgYXJn dW1lbnQgaXMgd2h5IG5vdCBwcmV2ZW50IHRoZSBwcm9ibGVtIHRvIGhhcHBlbiBpbiB0aGUgZmly c3QgcGxhY2UgaW5zdGVhZCBvZiB3YWl0aW5nIGZvciB0aGUgc2VydmVyIG1ha2luZyBtaXN0YWtl IGFuZCByZW1lZHkgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbmUgb2YgcHJp bmNpcGxlIHNldCBieSBSRkM4NjQxIGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ bWluaW1pemUgdGhlIG51bWJlciBvZiBzdWJzY3JpcHRpb24gaXRlcmF0aW9ucyBiZXR3ZWVuIHN1 YnNjcmliZXIgYW5kIHB1Ymxpc2hlciwgZGlzY291cmFnZSBSYW5kb20gZ3Vlc3Npbmcgb2YgZGlm ZmVyZW50IHBhcmFtZXRlcnMgYnkgYSBzdWJzY3JpYmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgc29sdXRp b24gYmVpbmcgcHJvdmlkZWQgaXMgZ2VuZXJpYywgdGFyZ2V0ZWQgdG8gYWRkcmVzcyB0aGlzIGNo YWxsZW5nZSwgbm90IG9ubHkgYXBwbGljYWJsZSB0byBkeW5hbWljIHN1YnNjcmlwdGlvbiwgYnV0 IGFsc28gY29uZmlndXJlZCBzdWJzY3JpcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+YW5kIHRoZSBjbGllbnQgbmVlZHMgdG8gcmV0cmlldmU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+ZXh0ZW5zaXZlIG1vbml0b3JpbmcgaW5mbyB0byBkZXRlcm1pbmUgaG93 IHRvIHNldHVwIG5vdGlmaWNhdGlvbnMgb24gdGhlIHNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiB0aGVvcnkgdGhpcyBk YXRhIGNvdWxkIGJlIHVzZWQgdG8gcHJldmVudCBhbiAmbHQ7cnBjLWVycm9yJmd0OyB0byBiZSBy ZXR1cm5lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5mb3IgJmx0O2VzdGFibGlzaF9zdWJzY3JpcHRp b24mZ3Q7IG9yICZsdDtlZGl0LWNvbmZpZyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPklNTyB0aGUgY3VycmVudCBhcHByb2FjaCBpcyBtdWNoIGJldHRlciB0aGFuIHRo aXMgcHJvcG9zZWQgYXBwcm9hY2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBzZXJ2ZXIgY2Fu IHByb3ZpZGUgdGhlIGhpbnRzIGJhc2VkIG9uIHRoZSBleGFjdCByZXF1ZXN0IGZyb20gdGhlIGNs aWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaW5dOiBJdCBtYXkgYmUgbGF0 ZSwgc3RpbGwgcmVxdWlyZSBtdWx0aXBsZSBzdWJzY3JpcHRpb24gaXRlcmF0aW9ucyBiZXR3ZWVu IHN1YnNjcmliZXIgYW5kIHB1Ymxpc2hlci4gQnV0IGRhdGEgZXhwb3J0IGhhcyBubyBpbnRlbnRp b24gdG8gcmVwbGFjZQ0KIGl0LiBFcnJvciBoYW5kbGluZyBoYXZlIGl0cyB2YWx1ZSBpbiBtYW55 IGRpZmZlcmVudCBjYXNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHN0YXRpYyAmcXVvdDtw ZXItbm9kZSZxdW90OyBtb25pdG9yaW5nIGRhdGEgY2FuIGJlIHF1aXRlIGxhcmdlLCBhbmQgeWV0 IG5vdCBwcm92aWRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRoZSBjb3JyZWN0IGFuc3dlciBmb3Ig YSBzcGVjaWZpYyBjb21iaW5hdGlvbiBvZiBzdWJzY3JpcHRpb24gcGFyYW1ldGVycy4uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+W1Fpbl06IEl0IGlzIHNlcnZlciBjYXBhYmlsaXR5IGV4cG9zdXJlLCBjaGVj ayBlYXJseSBpbXBsYW50YXRpb24gdGltZSBpbmZvcm1hdGlvbiBvZiB0aGUgY2FwYWJpbGl0eSB3 aGF0IHRoZSBzZXJ2ZXIgc3VwcG9ydCAoZS5nLiwgR1JQQyB0cmFuc3BvcnQsDQogVENQIHN1cHBv cnQsIFVEUCB0cmFuc3BvcnQgc3VwcG9ydCksIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+bm90IHRhcmdldGVkIHRvIGtlZXAgdHJhY2sgb2YgZHluYW1pYyBjaGFuZ2UgZGF0YS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZXNlIGNhcGFiaWxpdGllcyBzZWxkb20gY2hh bmdlLiBJbiBhZGRpdGlvbiwgdG8gYWxsb3cgdGhlIGNsaWVudCBjb21wb3NlIHZhcmlvdXMgZGlm ZmVyZW50IHN1YnNjcmlwdGlvbiBwb2xpY3kgKGUuZy4sIGFkYXB0aXZlIHN1YnNjcmlwdGlvbiks IHdlDQogcmVxdWlyZSB0aGUgc2VydmVyIHRvIGluZGljYXRlIHdoZXRoZXIgc3BlY2lmaWMgZGF0 YSBvYmplY3Qgc3VwcG9ydHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRocmVzaG9s ZHMgaGFuZGxpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIGlzIG1pc3Np bmcgcGllY2VzIHRvIHN1cHBvcnQgZXZlbnQgYmFzZWQgdGVsZW1ldHJ5IHNvbHV0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9u IFdlZCwgQXVnIDUsIDIwMjAgYXQgMzoxNyBQTSBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmtlbnQlMkJpZXRmQHdhdHNlbi4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+a2VudCYjNDM7aWV0 ZkB3YXRzZW4ubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+TkVUQ09ORiBXRyw8 YnI+DQo8YnI+DQpQZXIgdGhlIHByZXZpb3VzIGVtYWlsIHNlbnQgbW9tZW50cyBhZ28sIHRoZSBj aGFpcnMgd291bGQgbGlrZSB0byBzb2xpY2l0IGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQ6 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 ICZuYnNwO1RpdGxlOiZuYnNwO1RlbGVtZXRyeSBEYXRhIEV4cG9ydCBjYXBhYmlsaXR5PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7TGluazoNCjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvPC9hPmRyYWZ0LXRhby1uZXRjb25mLWRhdGEtZXhwb3J0LWNhcGFiaWxp dGllczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsgJm5ic3A7QWJzdHJhY3Q6PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhpcyBkb2N1bWVudCBwcm9w b3NlcyBhIFlBTkcgbW9kdWxlIGZvciB0ZWxlbWV0cnkgZGF0YSBleHBvcnQ8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyAmbmJzcDsgJm5ic3A7IGNhcGFiaWxpdHkgd2hpY2ggYXVnbWVudHMgc3lzdGVtIENhcGFi aWxpdGllcyBtb2RlbCBhbmQgcHJvdmlkZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7 IGFkZGl0aW9uYWwgdGVsZW1ldHJ5IGRhdGEgZXhwb3J0IGF0dHJpYnV0ZXMgYXNzb2NpYXRlZCB3 aXRoIHN5c3RlbTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY2FwYWJpbGl0eSBmb3Ig dHJhbnNwb3J0IGRlcGVuZGVudCBjYXBhYmlsaXR5IG5lZ290aWF0aW9uLjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48YnI+DQpJbiBwYXJ0aWN1bGFyLCBwbGVhc2UgZGlzY3VzcyBhZG9wdGlvbi1z dWl0YWJpbGl0eSBhcyBpdCByZWdhcmRzIHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7ICZuYnNwOyAxKSBpcyB0aGUgcHJvYmxlbSBpbXBvcnRhbnQgZm9yIHRoZSBORVRDT05GIFdH IHRvIHNvbHZlPzxicj4NCiZuYnNwOyAmbmJzcDsgMikgaXMgdGhlIGRyYWZ0IGEgc3VpdGFibGUg YmFzaXMgZm9yIHRoZSB3b3JrPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxicj4NCjxicj4NClBTOiB0aGlzIG1lc3NhZ2UgaXMgaXRzZWxmIG5vdCBhbiBhZG9wdGlv biBwb2xsLCBidXQgcmF0aGVyIGFuIGF0dGVtcHQgdG8gZ2F1Z2UgaW50ZXJlc3Qvc3VwcG9ydCBm b3IgYSBwb3RlbnRpYWwgZnV0dXJlIGFkb3B0aW9uIHBvbGwuPGJyPg0KPGJyPg0KTkVUQ09ORiBD aGFpcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldGNvbmYgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5uZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABAAD8FAC16dggeml511mbschi_-- From nobody Mon Aug 10 19:10:50 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0325F3A0EDF for ; Mon, 10 Aug 2020 19:10: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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCbpo-KUNN8c for ; Mon, 10 Aug 2020 19:10:47 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDD43A0EE2 for ; Mon, 10 Aug 2020 19:10:46 -0700 (PDT) Received: from lhreml725-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 85DFF4C283F0D1E09775 for ; Tue, 11 Aug 2020 03:10:45 +0100 (IST) Received: from lhreml725-chm.china.huawei.com (10.201.108.76) by lhreml725-chm.china.huawei.com (10.201.108.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 03:10:45 +0100 Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml725-chm.china.huawei.com (10.201.108.76) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 11 Aug 2020 03:10:44 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.234]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0487.000; Tue, 11 Aug 2020 10:10:39 +0800 From: Qin Wu To: Andy Bierman , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities Thread-Index: AdZvgKDDrRFiNBN5S662w/6KCddT4w== Date: Tue, 11 Aug 2020 02:10:38 +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.164.151.108] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD8FAC2Edggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 02:10:49 -0000 --_000_B8F9A780D330094D99AF023C5877DABAAD8FAC2Edggeml511mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 5Y+R5Lu25Lq6OiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSDku6Po oaggQW5keSBCaWVybWFuDQrlj5HpgIHml7bpl7Q6IDIwMjDlubQ45pyIMTHml6UgMzozOQ0K5pS2 5Lu25Lq6OiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQrmioTpgIE6IG5ldGNv bmZAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBm b3IgZHJhZnQtdGFvLW5ldGNvbmYtbm90aWYtbm9kZS10YWctY2FwYWJpbGl0aWVzDQoNCkhpLA0K DQpJIGFtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBpbiB0aGlz IGRyYWZ0Lg0KSXQgc2VlbXMgdG8gYmUgYSB3YXkgdG8gYXNzaWduIHZhcmlvdXMgdGFncyB0byBk YXRhIG5vZGUgb2JqZWN0cy4NCkl0IHVzZXMgdGhlIHRhZ3MgdHlwZSBmcm9tIGlldGYtbW9kdWxl LXRhZ3MsIHdoaWNoIGltcGxpZXMgdGhhdCBtb2R1bGVzIGFuZCBub2Rlcw0Kc2hhcmUgdGhlIHNh bWUgc2V0IG9mIHRhZ3MuDQpbUWluXTogSXQgaXMgbm90IHRoZSBnb2FsIHRvIHNoYXJlIHRoZSBz YW1lIHNldCBvZiB0YWdzIGZvciBtb2R1bGUgYW5kIG5vZGVzLCBub2RlcyBjb3VsZA0KSGF2ZSB0 aGVpciBvd24gdGFncyBhbmQgdXNlZCB0byB0YWcgbWFuYWdlbWVudCBhbmQgb3BlcmF0aW9uIGRh dGEgb3IgdGVsZW1ldHJ5IGRhdGEgZGVmaW5lZCB3aXRoaW4gdGhlIG1vZHVsZSAsIGl0IGlzIGRh dGEgbm9kZSBsZXZlbCB0YWcsIG5vdCBtb2R1bGUgbGV2ZWwgdGFnLg0KSWYgdGhpcyB3aWxsIGJl IHRoZSBpc3N1ZSwgd2UgY2FuIGRlZmluZSB0YWcgc2VwYXJhdGVseS4NClRoZXJlIGlzIGFsc28g YW4gYXNzdW1wdGlvbiB0aGF0IHRoZSBlcnJvci9oaW50cyBtZWNoYW5pc20gaW4gUkZDIDg2Mzkg YW5kIDg2NDENCmRvIG5vdCB3b3JrIGFuZCB0aGlzIHNpZ25pZmljYW50IGFtb3VudCBvZiBwcm9w b3NlZCBtZXRhZGF0YSBjb3VsZCBiZSB1c2VkIHRvIGF2b2lkDQpyZWNlaXZpbmcgYW4gPHJwYy1l cnJvcj4gZm9yIGFuIDxlc3RhYmxpc2gtc3Vic2NyaXB0aW9uPiBvciA8ZWRpdC1jb25maWc+IHJl cXVlc3QuDQoNCltRaW5dOiBTZWUgY2xhcmlmaWNhdGlvbiBmb3IgZGF0YSBleHBvcnQgY2FwYWJp bGl0eSBkcmFmdCwgaXQgaXMgZGVzaWduZWQgYXMgc2VydmVyIGNhcGFiaWxpdHkgZXhwb3N1cmUs IG5vdCB0YXJnZXRlZCB0byByZXBsYWNlIGVycm9yIGhhbmRsaW5nICBmb3IgPGVzdGFibGlzaC1z dWJzY3JpcHRpb24+IGFuZCA8ZWRpdC1jb25maWc+Lg0KVGhleSBhcmUgdXNlZCBhdCBkaWZmZXJl bnQgcGhhc2UuIFRoZSBiaWcgZGlmZmVyZW50IHdpdGggRGF0YSBleHBvcnQgY2FwYWJpbGl0eSwg aXMgaXQgZG9lc27igJl0IHRlbGwgdGhlIGNsaWVudCBob3cgdG8gc2VsZWN0IHRyYW5zcG9ydCBw cm90b2NvbCwgZW5jb2RpbmcsIHNlY3VyaXR5IHNjaGVtZSwgZXRjLCBpdCB0ZWxscyB0aGUgY2xp ZW50DQpXaGljaCBkYXRhIG9iamVjdCBpcyBjaGFyYWN0ZXJpc3RpY3MgZGF0YSBvciBLUEkgZGF0 YSwgd2hpY2ggaGVscCBhdm9pZCBmZXRjaCBub2lzZSBkYXRhIGZyb20gdGhlIGRhdGEgc291cmNl IGFuZCBwcm92aWRlIGNvbXByZWhlbnNpdmUgdmlldyBvZiB0aGUgbmV0d29yayBxdWFsaXR5IG9y IG5ldHdvcmsgaGVhbHRoDQpmcm9tIGRpZmZlcmVudCBhbmdsZXMuDQoNCklNTyB0aGUgY3VycmVu dCBhcHByb2FjaCBpcyBzdWZmaWNpZW50IGFuZCBuZXcgbWVjaGFuaXNtcyBhcmUgbm90IG5lZWRl ZC4NCg0KQW5keQ0KDQoNCk9uIFdlZCwgQXVnIDUsIDIwMjAgYXQgMzoxOCBQTSBLZW50IFdhdHNl biA8a2VudCtpZXRmQHdhdHNlbi5uZXQ8bWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5uZXQ+PiB3 cm90ZToNCg0KTkVUQ09ORiBXRywNCg0KUGVyIHRoZSBwcmV2aW91cyBlbWFpbCBzZW50IG1vbWVu dHMgYWdvLCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gc29saWNpdCBpbnB1dCBvbiB0aGUgZm9s bG93aW5nIGRyYWZ0Og0KDQogICBUaXRsZTogU2VsZi1leHBsYW5hdGlvbiBkYXRhIE5vZGUgdGFn IGNhcGFiaWxpdHkNCiAgIExpbms6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10 YW8tbmV0Y29uZi1ub3RpZi1ub2RlLXRhZy1jYXBhYmlsaXRpZXMNCiAgIEFic3RyYWN0Og0KICAg ICAgQmVmb3JlIGEgY2xpZW50IGFwcGxpY2F0aW9uIHN1YnNjcmliZXMgdG8gdXBkYXRlcyBmcm9t IGEgZGF0YXN0b3JlLA0KICAgICAgc2VydmVyIGNhcGFiaWxpdGllcyByZWxhdGVkIHRvICJTdWJz Y3JpcHRpb24gdG8gWUFORyBEYXRhc3RvcmVzIiBjYW4NCiAgICAgIGJlIGFkdmVydGlzZWQgdXNp bmcgWUFORyBJbnN0YW5jZSBEYXRhIGZvcm1hdC4gIFRoZXNlIHNlcnZlcg0KICAgICAgY2FwYWJp bGl0aWVzIGNhbiBiZSBkb2N1bWVudGVkIGF0IGltcGxlbWVudCB0aW1lIG9yIHJlcG9ydGVkIGF0 IHJ1bi0NCiAgICAgIHRpbWUuDQoNCiAgICAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBZQU5H IG1vZHVsZSBmb3Igc2VsZi1leHBsYW5hdGlvbiBkYXRhIE5vZGUNCiAgICAgIHRhZyBjYXBhYmls aXR5IHdoaWNoIGF1Z21lbnRzIHN5c3RlbSBjYXBhYmlsaXRpZXMgbW9kZWwgYW5kIHByb3ZpZGUN CiAgICAgIGFkZGl0aW9uYWwgc2VsZi1leHBsYW5hdGlvbiBkYXRhIG5vZGUgYXR0cmlidXRlcyBh c3NvY2lhdGVkIHdpdGggbm9kZQ0KICAgICAgc2VsZWN0b3JzIHdpdGhpbiBwZXItbm9kZSBjYXBh YmlsaXRpZXMuDQoNCg0KSW4gcGFydGljdWxhciwgcGxlYXNlIGRpc2N1c3MgYWRvcHRpb24tc3Vp dGFiaWxpdHkgYXMgaXQgcmVnYXJkcyB0byB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczoNCg0KICAg IDEpIGlzIHRoZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cgdG8gc29sdmU/ DQogICAgMikgaXMgdGhlIGRyYWZ0IGEgc3VpdGFibGUgYmFzaXMgZm9yIHRoZSB3b3JrPw0KDQoN ClBTOiB0aGlzIG1lc3NhZ2UgaXMgaXRzZWxmIG5vdCBhbiBhZG9wdGlvbiBwb2xsLCBidXQgcmF0 aGVyIGFuIGF0dGVtcHQgdG8gZ2F1Z2UgaW50ZXJlc3Qvc3VwcG9ydCBmb3IgYSBwb3RlbnRpYWwg ZnV0dXJlIGFkb3B0aW9uIHBvbGwuDQoNCk5FVENPTkYgQ2hhaXJzDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5l dGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== --_000_B8F9A780D330094D99AF023C5877DABAAD8FAC2Edggeml511mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiBuZXRjb25m IFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmIj7ku6PooaggPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZiI+QW5keSBCaWVybWFuPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IDIwMjA8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWYiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj44PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVT Ij4xMTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMzozOTxicj4NCjwvc3Bhbj48Yj7m lLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBLZW50IFdhdHNlbiAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0Ozxicj4NCjwvc3Bh bj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBuZXRjb25mQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbbmV0Y29uZl0gQWRvcHRp b24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0LXRhby1uZXRjb25mLW5vdGlmLW5vZGUtdGFnLWNhcGFi aWxpdGllczxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRo ZSBwcm9ibGVtIHN0YXRlbWVudCBpbiB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5J dCBzZWVtcyB0byBiZSBhIHdheSB0byBhc3NpZ24gdmFyaW91cyB0YWdzIHRvIGRhdGEgbm9kZSBv YmplY3RzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JdCB1c2VzIHRoZSB0YWdzIHR5cGUgZnJvbSBp ZXRmLW1vZHVsZS10YWdzLCB3aGljaCBpbXBsaWVzIHRoYXQgbW9kdWxlcyBhbmQgbm9kZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+c2hhcmUgdGhlIHNhbWUgc2V0IG9mIHRhZ3MuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUWluXTogSXQgaXMgbm90IHRoZSBn b2FsIHRvIHNoYXJlIHRoZSBzYW1lIHNldCBvZiB0YWdzIGZvciBtb2R1bGUgYW5kIG5vZGVzLCBu b2RlcyBjb3VsZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGF2ZSB0aGVpciBvd24g dGFncyBhbmQgdXNlZCB0byB0YWcgbWFuYWdlbWVudCBhbmQgb3BlcmF0aW9uIGRhdGEgb3IgdGVs ZW1ldHJ5IGRhdGEgZGVmaW5lZCB3aXRoaW4gdGhlIG1vZHVsZSAsIGl0IGlzIGRhdGEgbm9kZSBs ZXZlbCB0YWcsIG5vdCBtb2R1bGUNCiBsZXZlbCB0YWcuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JZiB0aGlzIHdpbGwgYmUgdGhlIGlzc3VlLCB3ZSBjYW4gZGVmaW5lIHRhZyBzZXBh cmF0ZWx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGVyZSBpcyBhbHNvIGFuIGFzc3VtcHRpb24g dGhhdCB0aGUgZXJyb3IvaGludHMgbWVjaGFuaXNtIGluIFJGQyA4NjM5IGFuZCA4NjQxPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPmRvIG5vdCB3b3JrIGFuZCB0aGlzIHNpZ25pZmljYW50IGFtb3VudCBv ZiBwcm9wb3NlZCBtZXRhZGF0YSBjb3VsZCBiZSB1c2VkIHRvIGF2b2lkPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPnJlY2VpdmluZyBhbiAmbHQ7cnBjLWVycm9yJmd0OyBmb3IgYW4gJmx0O2VzdGFibGlz aC1zdWJzY3JpcHRpb24mZ3Q7IG9yICZsdDtlZGl0LWNvbmZpZyZndDsgcmVxdWVzdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+W1Fpbl06IFNlZSBjbGFyaWZpY2F0aW9uIGZvciBkYXRhIGV4cG9y dCBjYXBhYmlsaXR5IGRyYWZ0LCBpdCBpcyBkZXNpZ25lZCBhcyBzZXJ2ZXIgY2FwYWJpbGl0eSBl eHBvc3VyZSwgbm90IHRhcmdldGVkIHRvIHJlcGxhY2UgZXJyb3IgaGFuZGxpbmcmbmJzcDsNCiBm b3IgJmx0O2VzdGFibGlzaC1zdWJzY3JpcHRpb24mZ3Q7IGFuZCAmbHQ7ZWRpdC1jb25maWcmZ3Q7 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhleSBhcmUgdXNlZCBhdCBkaWZmZXJl bnQgcGhhc2UuIFRoZSBiaWcgZGlmZmVyZW50IHdpdGggRGF0YSBleHBvcnQgY2FwYWJpbGl0eSwg aXMgaXQgZG9lc27igJl0IHRlbGwgdGhlIGNsaWVudCBob3cgdG8gc2VsZWN0IHRyYW5zcG9ydCBw cm90b2NvbCwNCiBlbmNvZGluZywgc2VjdXJpdHkgc2NoZW1lLCBldGMsIGl0IHRlbGxzIHRoZSBj bGllbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoaWNoIGRhdGEgb2JqZWN0IGlz IGNoYXJhY3RlcmlzdGljcyBkYXRhIG9yIEtQSSBkYXRhLCB3aGljaCBoZWxwIGF2b2lkIGZldGNo IG5vaXNlIGRhdGEgZnJvbSB0aGUgZGF0YSBzb3VyY2UgYW5kIHByb3ZpZGUgY29tcHJlaGVuc2l2 ZSB2aWV3IG9mIHRoZQ0KIG5ldHdvcmsgcXVhbGl0eSBvciBuZXR3b3JrIGhlYWx0aCA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmZyb20gZGlmZmVyZW50IGFuZ2xlcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JTU8gdGhl IGN1cnJlbnQgYXBwcm9hY2ggaXMgc3VmZmljaWVudCBhbmQgbmV3IG1lY2hhbmlzbXMgYXJlIG5v dCBuZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5BbmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gV2VkLCBBdWcgNSwgMjAyMCBhdCAzOjE4IFBN IEtlbnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a2VudCUyQmlldGZAd2F0c2VuLm5ldCIg dGFyZ2V0PSJfYmxhbmsiPmtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldDwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPk5FVENPTkYgV0csPGJyPg0KPGJyPg0KUGVyIHRoZSBwcmV2aW91cyBl bWFpbCBzZW50IG1vbWVudHMgYWdvLCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gc29saWNpdCBp bnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtUaXRsZTombmJzcDtTZWxmLWV4cGxh bmF0aW9uIGRhdGEgTm9kZSB0YWcgY2FwYWJpbGl0eTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7ICZuYnNwO0xpbms6DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sLzwvYT5k cmFmdC10YW8tbmV0Y29uZi1ub3RpZi1ub2RlLXRhZy1jYXBhYmlsaXRpZXM8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNw O0Fic3RyYWN0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBCZWZvcmUgYSBjbGllbnQgYXBwbGljYXRpb24g c3Vic2NyaWJlcyB0byB1cGRhdGVzIGZyb20gYSBkYXRhc3RvcmUsPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyBzZXJ2ZXIgY2FwYWJpbGl0aWVzIHJlbGF0ZWQgdG8gJnF1b3Q7U3Vic2Ny aXB0aW9uIHRvIFlBTkcgRGF0YXN0b3JlcyZxdW90OyBjYW48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJz cDsgJm5ic3A7IGJlIGFkdmVydGlzZWQgdXNpbmcgWUFORyBJbnN0YW5jZSBEYXRhIGZvcm1hdC4m bmJzcDsgVGhlc2Ugc2VydmVyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBjYXBhYmls aXRpZXMgY2FuIGJlIGRvY3VtZW50ZWQgYXQgaW1wbGVtZW50IHRpbWUgb3IgcmVwb3J0ZWQgYXQg cnVuLTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdGltZS48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGlzIGRvY3VtZW50 IHByb3Bvc2VzIGEgWUFORyBtb2R1bGUgZm9yIHNlbGYtZXhwbGFuYXRpb24gZGF0YSBOb2RlPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB0YWcgY2FwYWJpbGl0eSB3aGljaCBhdWdtZW50 cyBzeXN0ZW0gY2FwYWJpbGl0aWVzIG1vZGVsIGFuZCBwcm92aWRlPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyBhZGRpdGlvbmFsIHNlbGYtZXhwbGFuYXRpb24gZGF0YSBub2RlIGF0dHJp YnV0ZXMgYXNzb2NpYXRlZCB3aXRoIG5vZGU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7 IHNlbGVjdG9ycyB3aXRoaW4gcGVyLW5vZGUgY2FwYWJpbGl0aWVzLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxicj4NCkluIHBhcnRpY3VsYXIsIHBsZWFzZSBkaXNjdXNzIGFkb3B0 aW9uLXN1aXRhYmlsaXR5IGFzIGl0IHJlZ2FyZHMgdG8gdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsgJm5ic3A7IDEpIGlzIHRoZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENP TkYgV0cgdG8gc29sdmU/PGJyPg0KJm5ic3A7ICZuYnNwOyAyKSBpcyB0aGUgZHJhZnQgYSBzdWl0 YWJsZSBiYXNpcyBmb3IgdGhlIHdvcms/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PGJyPg0KPGJyPg0KUFM6IHRoaXMgbWVzc2FnZSBpcyBpdHNlbGYgbm90IGFuIGFk b3B0aW9uIHBvbGwsIGJ1dCByYXRoZXIgYW4gYXR0ZW1wdCB0byBnYXVnZSBpbnRlcmVzdC9zdXBw b3J0IGZvciBhIHBvdGVudGlhbCBmdXR1cmUgYWRvcHRpb24gcG9sbC48YnI+DQo8YnI+DQpORVRD T05GIENoYWlyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0Y29uZiBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B8F9A780D330094D99AF023C5877DABAAD8FAC2Edggeml511mbschi_-- From nobody Mon Aug 10 19:11:42 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDDB3A0EF9 for ; Mon, 10 Aug 2020 19:11: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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ezz7Tfntpkd7 for ; Mon, 10 Aug 2020 19:11:38 -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 13D1A3A0EE6 for ; Mon, 10 Aug 2020 19:11:37 -0700 (PDT) Received: from lhreml703-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A755B91153718F14120A for ; Tue, 11 Aug 2020 03:11:35 +0100 (IST) Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 11 Aug 2020 03:11:35 +0100 Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Tue, 11 Aug 2020 03:11:34 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.234]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Tue, 11 Aug 2020 10:11:31 +0800 From: Qin Wu To: Andy Bierman , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-wang-netconf-bulk-subscribed-notifications Thread-Index: AdZvgj7LaTzaNxwMRmWVgYQUe3VBdQ== Date: Tue, 11 Aug 2020 02:11:31 +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.164.151.108] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD8FAC44dggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-wang-netconf-bulk-subscribed-notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 02:11:41 -0000 --_000_B8F9A780D330094D99AF023C5877DABAAD8FAC44dggeml511mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 5Y+R5Lu25Lq6OiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSDku6Po oaggQW5keSBCaWVybWFuDQrlj5HpgIHml7bpl7Q6IDIwMjDlubQ45pyIMTHml6UgMzo0MA0K5pS2 5Lu25Lq6OiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQrmioTpgIE6IG5ldGNv bmZAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBm b3IgZHJhZnQtd2FuZy1uZXRjb25mLWJ1bGstc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zDQoNCkhp LA0KDQpJIGFtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBpbiB0 aGlzIGRyYWZ0Lg0KSXQgc2VlbXMgdG8gYmUgdGhhdCBSRkMgODYzOSBkb2VzIG5vdCBwcm92aWRl IGVub3VnaCBjb25maWd1cmF0aW9uIGNhcGFiaWxpdHkNCnRvIHNwZWNpZnkgaG93IG5vdGlmaWNh dGlvbnMgZnJvbSBkaWZmZXJlbnQgc3Vic2NyaXB0aW9ucyBzaG91bGQgYmUgYnVuZGxlZA0KdG9n ZXRoZXIgaW50byBhIHNpbmdsZSBtZXNzYWdlLg0KDQpbUWluXTpDb3JyZWN0LCBJIHRoaW5rIGl0 IGlzIGltcG9ydGFudCB0byBkZWZpbmUgY3JpdGVyaWEgdG8gY2xhc3NpZnkgc3Vic2NyaXB0aW9u IGFuZCBpbmRpY2F0ZSB0byB0aGUgc2VydmVyIHdoaWNoIHNwZWNpZmljIHN1YnNjcmlwdGlvbiBh c3NvY2lhdGVkIHdpdGggdGhlIG5vdGlmaWNhdGlvbiBzaG91bGQgYmUgYnVuZGxlZCB0b2dldGhl cg0KYmVmb3JlIGJ1bmRsaW5nIG11bHRpcGxlIG5vdGlmaWNhdGlvbiBpbiBhIHNpbmdsZSB0cmFu c3BvcnQgbWVzc2FnZS4gVGhhdOKAmXMgd2h5IHdlIHByb3Bvc2VkIHR3byBtb2RlbHMsIGkuZS4s IGJ1bGsgc3Vic2NyaXB0aW9uIG1vZGVsIGJ1bGsgbm90aWZpY2F0aW9uIG1vZGVsLA0KYnVsayBz dWJzY3JpcHRpb24gbW9kZWwgZGVmaW5lIGFkZGl0aW9uYWwgc3Vic2NyaXB0aW9uIGNvbmZpZ3Vy YXRpb24gKGUuZy4sIGJ1bmRsZS1sYXRlbmN5LCBidW5kbGUtc2l6ZSlhbmQgb25lIG5ldyBSUEMg dG8gaW5kaWNhdGUgdGhlIHNldmVyIHdoaWNoIHN1YnNjcmlwdGlvbiBjYW4gYmUgYnVuZGxlZCB0 b2dldGhlciBhbmQgd2hpY2ggbm90Lg0KVGhlIHNlY29uZCBtb2RlbCBpcyBidWxrIG5vdGlmaWNh dGlvbiBtb2RlbCwgd2hpY2ggaXMgdXNlZCBieSB0aGUgc2VydmVyIHRvIGluZGljYXRlIHRvIHRo ZSBjbGllbnQgYWJvdXQgdGhlIGdyb3VwIGlkIGFuZCBjb21wcmVzc2lvbiBtb2RlLg0KVGhlcmUg aXMgbm8gZGlzY3Vzc2lvbiBvZiB3aHkgYnVuZGxpbmcNCm5vdGlmaWNhdGlvbnMgbmVlZHMgdG8g YmUgc3RhbmRhcmRpemVkLCBvciB3aGF0IGJlbmVmaXRzIGl0IHByb3ZpZGVzIG92ZXINCnRoZSBj dXJyZW50IFJGQyA1Mjc3IG5vdGlmaWNhdGlvbiBtZXNzYWdlIGRlZmluaXRpb24uDQpbUWluXTog SSB0aGluayB0aGUgc2Vjb25kIG1vZGVsIG9uIGJ1bGsgbm90aWZpY2F0aW9uIGlzIGRlYmF0YWJs ZSwgaW4gb3VyIG9waW5pb24sIGl0IGlzIG5vIGhhcm0gdG8gaGF2ZSB0aGlzIG1vZGVsIHRvIHRl bGwNClRoZSBjbGllbnQgYWJvdXQgdGhlIGdyb3VwLWlkIGZvciBzZXZlcmFsIHN1YnNjcmlwdGlv biB0byBiZSBidW5kbGVkIHRvZ2V0aGVyLCBidXQgaXQgbWF5IGJlIHJlZHVuZGFudCB3aXRoIHRo ZSBjdXJyZW50IFJGQzUyNzcuIFRocm91Z2ggb2ZmbGluZSBkaXNjdXNzaW9uLCBFcmljIGFsc28g ZXhwcmVzc2VkIHRoZSBzaW1pbGFyIG9waW5pb24gb24gdGhlIHNlY29uZCBtb2RlbC4NCklmIHRo aXMgaXMgYWdyZWVtZW50LCB3ZSBjYW4gcmVtb3ZlIHRoZSBzZWNvbmQgbW9kZWwuDQpUaGlzIGFw cHJvYWNoIHNlZW1zIHRvIGFkZCBhIGxvdCBvZiBjb21wbGV4aXR5IHdpdGhvdXQgYWRkaW5nIG11 Y2ggYmVuZWZpdC4NCg0KQW5keQ0KDQoNCk9uIFdlZCwgQXVnIDUsIDIwMjAgYXQgMzoxOSBQTSBL ZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ8bWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNl bi5uZXQ+PiB3cm90ZToNCg0KTkVUQ09ORiBXRywNCg0KUGVyIHRoZSBwcmV2aW91cyBlbWFpbCBz ZW50IG1vbWVudHMgYWdvLCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gc29saWNpdCBpbnB1dCBv biB0aGUgZm9sbG93aW5nIGRyYWZ0Og0KDQogICBUaXRsZTogQnVsayBTdWJzY3JpcHRpb24gdG8g WUFORyBFdmVudCBOb3RpZmljYXRpb24NCiAgIExpbms6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC13YW5nLW5ldGNvbmYtYnVsay1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMNCiAg IEFic3RyYWN0Og0KICAgICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVs IGFuZCBhc3NvY2lhdGVkIG1lY2hhbmlzbSB0aGF0DQogICAgICBhbGxvd3Mgc3Vic2NyaWJlciBh cHBsaWNhdGlvbnMgdG8gYnVsayBzdWJzY3JpYmUgdG8gcHVibGlzaGVycycgZXZlbnQNCiAgICAg IHN0cmVhbXMgYmFzZWQgb24gYnVuZGxlIGdyb3VwIGluZm9ybWF0aW9uIHN1Y2ggYXMgYnVuZGxl IHNpemUgYW5kDQogICAgICBidW5kbGUgbGF0ZW5jeS4gIFRoaXMgYWxsb3dzIHRoZSBwdWJsaXNo ZXJzIHRvIHJlcG9ydCBtdWx0aXBsZQ0KICAgICAgbm90aWZpY2F0aW9ucyBpbiBhIHNpbmdsZSBi dW5kbGluZyBtZXNzYWdlLg0KDQoNCkluIHBhcnRpY3VsYXIsIHBsZWFzZSBkaXNjdXNzIGFkb3B0 aW9uLXN1aXRhYmlsaXR5IGFzIGl0IHJlZ2FyZHMgdG8gdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6 DQoNCiAgICAxKSBpcyB0aGUgcHJvYmxlbSBpbXBvcnRhbnQgZm9yIHRoZSBORVRDT05GIFdHIHRv IHNvbHZlPw0KICAgIDIpIGlzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJhc2lzIGZvciB0aGUgd29y az8NCg0KDQpQUzogdGhpcyBtZXNzYWdlIGlzIGl0c2VsZiBub3QgYW4gYWRvcHRpb24gcG9sbCwg YnV0IHJhdGhlciBhbiBhdHRlbXB0IHRvIGdhdWdlIGludGVyZXN0L3N1cHBvcnQgZm9yIGEgcG90 ZW50aWFsIGZ1dHVyZSBhZG9wdGlvbiBwb2xsLg0KDQpORVRDT05GIENoYWlycw0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldGNvbmYgbWFpbGluZyBs aXN0DQpuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo= --_000_B8F9A780D330094D99AF023C5877DABAAD8FAC44dggeml511mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiBuZXRjb25m IFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmIj7ku6PooaggPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZiI+QW5keSBCaWVybWFuPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IDIwMjA8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWYiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj44PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVT Ij4xMTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMzo0MDxicj4NCjwvc3Bhbj48Yj7m lLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBLZW50IFdhdHNlbiAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0Ozxicj4NCjwvc3Bh bj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBuZXRjb25mQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbbmV0Y29uZl0gQWRvcHRp b24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0LXdhbmctbmV0Y29uZi1idWxrLXN1YnNjcmliZWQtbm90 aWZpY2F0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFtIHRyeWluZyB0byB1bmRlcnN0YW5k IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBpbiB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5JdCBzZWVtcyB0byBiZSB0aGF0IFJGQyA4NjM5IGRvZXMgbm90IHByb3ZpZGUgZW5vdWdoIGNv bmZpZ3VyYXRpb24gY2FwYWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj50byBzcGVjaWZ5IGhv dyBub3RpZmljYXRpb25zIGZyb20gZGlmZmVyZW50IHN1YnNjcmlwdGlvbnMgc2hvdWxkIGJlIGJ1 bmRsZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dG9nZXRoZXIgaW50byBhIHNpbmdsZSBtZXNzYWdl LiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltR aW5dOkNvcnJlY3QsIEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIGRlZmluZSBjcml0ZXJpYSB0 byBjbGFzc2lmeSBzdWJzY3JpcHRpb24gYW5kIGluZGljYXRlIHRvIHRoZSBzZXJ2ZXIgd2hpY2gg c3BlY2lmaWMgc3Vic2NyaXB0aW9uIGFzc29jaWF0ZWQNCiB3aXRoIHRoZSBub3RpZmljYXRpb24g c2hvdWxkIGJlIGJ1bmRsZWQgdG9nZXRoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PmJlZm9yZSBidW5kbGluZyBtdWx0aXBsZSBub3RpZmljYXRpb24gaW4gYSBzaW5nbGUgdHJhbnNw b3J0IG1lc3NhZ2UuIFRoYXTigJlzIHdoeSB3ZSBwcm9wb3NlZCB0d28gbW9kZWxzLCBpLmUuLCBi dWxrIHN1YnNjcmlwdGlvbiBtb2RlbCBidWxrIG5vdGlmaWNhdGlvbg0KIG1vZGVsLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YnVsayBzdWJzY3JpcHRpb24gbW9kZWwgZGVmaW5lIGFk ZGl0aW9uYWwgc3Vic2NyaXB0aW9uIGNvbmZpZ3VyYXRpb24gKGUuZy4sIGJ1bmRsZS1sYXRlbmN5 LCBidW5kbGUtc2l6ZSlhbmQgb25lIG5ldyBSUEMgdG8gaW5kaWNhdGUgdGhlIHNldmVyIHdoaWNo DQogc3Vic2NyaXB0aW9uIGNhbiBiZSBidW5kbGVkIHRvZ2V0aGVyIGFuZCB3aGljaCBub3QuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgc2Vjb25kIG1vZGVsIGlzIGJ1bGsgbm90 aWZpY2F0aW9uIG1vZGVsLCB3aGljaCBpcyB1c2VkIGJ5IHRoZSBzZXJ2ZXIgdG8gaW5kaWNhdGUg dG8gdGhlIGNsaWVudCBhYm91dCB0aGUgZ3JvdXAgaWQgYW5kIGNvbXByZXNzaW9uIG1vZGUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlRoZXJlIGlzIG5vIGRpc2N1c3Npb24gb2Ygd2h5IGJ1bmRsaW5nPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPm5vdGlmaWNhdGlvbnMgbmVlZHMgdG8gYmUgc3RhbmRhcmRpemVkLCBvciB3aGF0IGJl bmVmaXRzIGl0IHByb3ZpZGVzIG92ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dGhlIGN1cnJlbnQg UkZDIDUyNzcgbm90aWZpY2F0aW9uIG1lc3NhZ2UgZGVmaW5pdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaW5dOiBJIHRoaW5rIHRoZSBzZWNvbmQg bW9kZWwgb24gYnVsayBub3RpZmljYXRpb24gaXMgZGViYXRhYmxlLCBpbiBvdXIgb3Bpbmlvbiwg aXQgaXMgbm8gaGFybSB0byBoYXZlIHRoaXMgbW9kZWwgdG8gdGVsbDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VGhlIGNsaWVudCBhYm91dCB0aGUgZ3JvdXAtaWQgZm9yIHNldmVyYWwg c3Vic2NyaXB0aW9uIHRvIGJlIGJ1bmRsZWQgdG9nZXRoZXIsIGJ1dCBpdCBtYXkgYmUgcmVkdW5k YW50IHdpdGggdGhlIGN1cnJlbnQgUkZDNTI3Ny4gVGhyb3VnaCBvZmZsaW5lDQogZGlzY3Vzc2lv biwgRXJpYyBhbHNvIGV4cHJlc3NlZCB0aGUgc2ltaWxhciBvcGluaW9uIG9uIHRoZSBzZWNvbmQg bW9kZWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB0aGlzIGlzIGFncmVlbWVu dCwgd2UgY2FuIHJlbW92ZSB0aGUgc2Vjb25kIG1vZGVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGlzIGFwcHJvYWNoIHNlZW1zIHRvIGFkZCBhIGxvdCBvZiBjb21wbGV4aXR5IHdpdGhvdXQgYWRk aW5nIG11Y2ggYmVuZWZpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBXZWQsIEF1ZyA1LCAyMDIwIGF0 IDM6MTkgUE0gS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprZW50JTJCaWV0ZkB3YXRz ZW4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+TkVUQ09ORiBXRyw8YnI+DQo8 YnI+DQpQZXIgdGhlIHByZXZpb3VzIGVtYWlsIHNlbnQgbW9tZW50cyBhZ28sIHRoZSBjaGFpcnMg d291bGQgbGlrZSB0byBzb2xpY2l0IGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQ6PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNw O1RpdGxlOiZuYnNwO0J1bGsgU3Vic2NyaXB0aW9uIHRvIFlBTkcgRXZlbnQgTm90aWZpY2F0aW9u PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7TGluazoNCjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvPC9hPmRyYWZ0LXdhbmctbmV0Y29uZi1idWxrLXN1YnNjcmli ZWQtbm90aWZpY2F0aW9uczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7QWJzdHJhY3Q6PC9zcGFuPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7 IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBhbmQgYXNzb2NpYXRlZCBt ZWNoYW5pc20gdGhhdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYWxsb3dzIHN1YnNj cmliZXIgYXBwbGljYXRpb25zIHRvIGJ1bGsgc3Vic2NyaWJlIHRvIHB1Ymxpc2hlcnMnIGV2ZW50 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBzdHJlYW1zIGJhc2VkIG9uIGJ1bmRsZSBn cm91cCBpbmZvcm1hdGlvbiBzdWNoIGFzIGJ1bmRsZSBzaXplIGFuZDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgYnVuZGxlIGxhdGVuY3kuJm5ic3A7IFRoaXMgYWxsb3dzIHRoZSBwdWJs aXNoZXJzIHRvIHJlcG9ydCBtdWx0aXBsZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg bm90aWZpY2F0aW9ucyBpbiBhIHNpbmdsZSBidW5kbGluZyBtZXNzYWdlLjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPjxicj4NCkluIHBhcnRpY3VsYXIsIHBsZWFzZSBkaXNjdXNzIGFk b3B0aW9uLXN1aXRhYmlsaXR5IGFzIGl0IHJlZ2FyZHMgdG8gdGhlIGZvbGxvd2luZyBxdWVzdGlv bnM6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsgJm5ic3A7IDEpIGlzIHRoZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5F VENPTkYgV0cgdG8gc29sdmU/PGJyPg0KJm5ic3A7ICZuYnNwOyAyKSBpcyB0aGUgZHJhZnQgYSBz dWl0YWJsZSBiYXNpcyBmb3IgdGhlIHdvcms/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PGJyPg0KPGJyPg0KUFM6IHRoaXMgbWVzc2FnZSBpcyBpdHNlbGYgbm90IGFu IGFkb3B0aW9uIHBvbGwsIGJ1dCByYXRoZXIgYW4gYXR0ZW1wdCB0byBnYXVnZSBpbnRlcmVzdC9z dXBwb3J0IGZvciBhIHBvdGVudGlhbCBmdXR1cmUgYWRvcHRpb24gcG9sbC48YnI+DQo8YnI+DQpO RVRDT05GIENoYWlyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0Y29uZiBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_B8F9A780D330094D99AF023C5877DABAAD8FAC44dggeml511mbschi_-- From nobody Mon Aug 10 19:34:32 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288373A0EEA for ; Mon, 10 Aug 2020 19:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_gyp-Q56b_G for ; Mon, 10 Aug 2020 19:34: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 00B7B3A0DF7 for ; Mon, 10 Aug 2020 19:34:29 -0700 (PDT) Received: from lhreml719-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 76D3329E96A7E9F65ACB for ; Tue, 11 Aug 2020 03:34:27 +0100 (IST) Received: from lhreml719-chm.china.huawei.com (10.201.108.70) by lhreml719-chm.china.huawei.com (10.201.108.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 03:34:26 +0100 Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml719-chm.china.huawei.com (10.201.108.70) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 11 Aug 2020 03:34:26 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.234]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0487.000; Tue, 11 Aug 2020 10:34:22 +0800 From: Qin Wu To: Andy Bierman , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-wang-netconf-adaptive-subscription Thread-Index: AdZvhfX1gq2ykwPUQ5qu3a8I9wZYeA== Date: Tue, 11 Aug 2020 02:34:22 +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.164.151.108] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD8FACB0dggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-wang-netconf-adaptive-subscription X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 02:34:31 -0000 --_000_B8F9A780D330094D99AF023C5877DABAAD8FACB0dggeml511mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keToNCkkgZnVsbHkgYWdyZWUgdGhlcmUgaXMgbGltaXRhdGlvbiBmb3IgdGhlIGN1cnJlbnQg ZmlsdGVyIGFuZCB0cmlnZ2VyIG1lY2hhbmlzbXMgd2hlbiB3ZSBpbXBsZW1lbnQgWUFORyBwdXNo IG1lY2hhbmlzbSBpbiBvdXIgcHJvZHVjdHMuDQpXZSBkbyBpbXBsZW1lbnQgdGhpcyBmZWF0dXJl IGluIG91ciBwcm9kdWN0Lg0KV2Ugc2VlIGEgbG90IG9mIHNpbWlsYXIgaW1wbGVtZW50YXRpb25z IHdoaWNoIHRyeSB0byBhZGRyZXNzIHNvbWUgb2YgdGhlc2UgY2hhbGxlbmdlcywgZS5nLiwgYWRh cHRpdmUgc2FtcGxpbmcgaW1wbGVtZW50ZWQNCmJ5IE1pY3Jvc29mdCBpbiBBenVyZSwgRXZlbnQg YmFzZWQgdGVsZW1ldHJ5IHByb3Bvc2VkIGJ5IG1hbnkgZGlmZmVyZW50IHZlbmRvcnMsDQpJIGFt IGhvcGluZyB3ZSBuZWVkIHRvIGtlZXAgb24gd29ya2luZyBvbiBFQ0EgbW9kZWwgYW5kIGFsaWdu IHRoaXMgZHJhZnQgd2l0aCBFQ0EuICBsb3cgaGFuZ2luZyBmcnVpdCBpcyBub3QgZmFyIGZyb20g dXMsOi0pLg0KSSBhbHNvIGhvcGUgd2hvIGFyZSBpbnRlcmVzdGVkIHRvIHRhY2tsZSB0aGlzIGlz c3VlIGNhbiBqb2luIGFuZCB3b3JrIHRvZ2V0aGVyLiBXZSBuZWVkIHRvIHNlZWsgY29tbW9uIGdy b3VuZCB3aGlsZSByZXNlcnZpbmcgZGlmZmVyZW5jZXMuDQoNCi1RaW4NCuWPkeS7tuS6ujogbmV0 Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEFuZHkgQmllcm1h bg0K5Y+R6YCB5pe26Ze0OiAyMDIw5bm0OOaciDEx5pelIDM6NDANCuaUtuS7tuS6ujogS2VudCBX YXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0Pg0K5oqE6YCBOiBuZXRjb25mQGlldGYub3JnDQrk uLvpopg6IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0LXdhbmct bmV0Y29uZi1hZGFwdGl2ZS1zdWJzY3JpcHRpb24NCg0KSGksDQoNCkkgYW0gdHJ5aW5nIHRvIHVu ZGVyc3RhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGluIHRoaXMgZHJhZnQuDQpJdCBhcHBlYXJz IHRvIHByb3Bvc2UgYSBjb21wbGV4IHNlbGYtbW9uaXRvcmluZyBzeXN0ZW0gc28gdGhhdCBZQU5H IFB1c2gNCnN1YnNjcmlwdGlvbnMgY2FuIGNoYW5nZSB0aGVpciBwYXJhbWV0ZXJzIG9uIHRoZSBm bHkgdG8gYWRhcHQgdG8NCmNoYW5naW5nIG5ldHdvcmsgY29uZGl0aW9ucy4gRS5nLiBsb3dlciB0 aGUgJ3BlcmlvZCcgcGFyYW1ldGVyIHdoZW4NCmNvbmRpdGlvbnMgYXJlIHJpZ2h0LCB0byBwcm9k dWNlIG1vcmUgcHVzaC11cGRhdGUgcmVjb3JkcyB0aGFuIG5vcm1hbC4NCg0KVGhlIHByb2JsZW0g aXMgc29tZXdoYXQgaW50ZXJlc3RpbmcuDQpUaGUgZmlsdGVyaW5nIG1lY2hhbmlzbXMgaW4gWUFO RyBQdXNoIGFyZSByZWFsbHkgYXdmdWwgYW5kIHRoZXJlIGlzIGEgbmVlZA0KdG8gaW1wcm92ZSBi b3RoIGZpbHRlciBhbmQgdHJpZ2dlciBtZWNoYW5pc21zLiAgSSBkb24ndCB0aGluayB0aGlzIGRy YWZ0IG9mZmVycw0KYSByZWFzb25hYmxlIHNvbHV0aW9uLCBidXQgSSBlbmNvdXJhZ2UgZnVydGhl ciBleHBlcmltZW50YXRpb24uDQpQcm92ZSBpdCB3b3JrcyBpbiByZWFsIHByb2R1Y3RzIHRoZW4g bWF5YmUgaXQgd2lsbCBiZSByZWFkeSBmb3Igc3RhbmRhcmRpemF0aW9uLg0KDQoNCkFuZHkNCg0K DQpPbiBXZWQsIEF1ZyA1LCAyMDIwIGF0IDM6MTggUE0gS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3 YXRzZW4ubmV0PG1haWx0bzprZW50JTJCaWV0ZkB3YXRzZW4ubmV0Pj4gd3JvdGU6DQpORVRDT05G IFdHLA0KDQpQZXIgdGhlIHByZXZpb3VzIGVtYWlsIHNlbnQgbW9tZW50cyBhZ28sIHRoZSBjaGFp cnMgd291bGQgbGlrZSB0byBzb2xpY2l0IGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQ6DQoN CiAgIFRpdGxlOiBBZGFwdGl2ZSBTdWJzY3JpcHRpb24gdG8gWUFORyBOb3RpZmljYXRpb24NCiAg IExpbms6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YW5nLW5ldGNvbmYtYWRh cHRpdmUtc3Vic2NyaXB0aW9uDQogICBBYnN0cmFjdDoNCiAgICAgIFRoaXMgZG9jdW1lbnQgZGVm aW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBhbmQgYXNzb2NpYXRlZCBtZWNoYW5pc20NCiAgICAgIGVu YWJsaW5nIHN1YnNjcmliZXIncyBhZGFwdGl2ZSBzdWJzY3JpcHRpb25zIHRvIGEgcHVibGlzaGVy J3MgZXZlbnQNCiAgICAgIHN0cmVhbXMgYXQgdmFyaW91cyBkaWZmZXJlbnQgcGVyaW9kIGludGVy dmFscyB3aXRoIHdoaWNoIHRvIHJlcG9ydA0KICAgICAgdXBkYXRlcy4gIEFwcGx5aW5nIHRoZXNl IGVsZW1lbnRzIGFsbG93cyBib3RoIHN1YnNjcmliZXIgYW5kDQogICAgICBwdWJsaXNoZXIgdG8g YXV0b21hdGljYWxseSBhZGp1c3QgdGhlIHZvbHVtZSBvZiB0ZWxlbWV0cnkgdHJhZmZpYw0KICAg ICAgc2VudCBmcm9tIHB1Ymxpc2hlciB0byB0aGUgcmVjZWl2ZXJzLg0KDQoNCkluIHBhcnRpY3Vs YXIsIHBsZWFzZSBkaXNjdXNzIGFkb3B0aW9uLXN1aXRhYmlsaXR5IGFzIGl0IHJlZ2FyZHMgdG8g dGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6DQoNCiAgICAxKSBpcyB0aGUgcHJvYmxlbSBpbXBvcnRh bnQgZm9yIHRoZSBORVRDT05GIFdHIHRvIHNvbHZlPw0KICAgIDIpIGlzIHRoZSBkcmFmdCBhIHN1 aXRhYmxlIGJhc2lzIGZvciB0aGUgd29yaz8NCg0KDQpQUzogdGhpcyBtZXNzYWdlIGlzIGl0c2Vs ZiBub3QgYW4gYWRvcHRpb24gcG9sbCwgYnV0IHJhdGhlciBhbiBhdHRlbXB0IHRvIGdhdWdlIGlu dGVyZXN0L3N1cHBvcnQgZm9yIGEgcG90ZW50aWFsIGZ1dHVyZSBhZG9wdGlvbiBwb2xsLg0KDQpO RVRDT05GIENoYWlycw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm5ldGNvbmYgbWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRj b25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj b25mDQo= --_000_B8F9A780D330094D99AF023C5877DABAAD8FACB0dggeml511mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZHk6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGZ1bGx5IGFncmVlIHRoZXJlIGlzIGxpbWl0YXRpb24g Zm9yIHRoZSBjdXJyZW50IGZpbHRlciBhbmQgdHJpZ2dlciBtZWNoYW5pc21zIHdoZW4gd2UgaW1w bGVtZW50IFlBTkcgcHVzaCBtZWNoYW5pc20gaW4gb3VyIHByb2R1Y3RzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+V2UgZG8gaW1wbGVtZW50IHRoaXMgZmVhdHVyZSBpbiBvdXIgcHJv ZHVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlIHNlZSBhIGxvdCBvZiBzaW1p bGFyIGltcGxlbWVudGF0aW9ucyB3aGljaCB0cnkgdG8gYWRkcmVzcyBzb21lIG9mIHRoZXNlIGNo YWxsZW5nZXMsIGUuZy4sIGFkYXB0aXZlIHNhbXBsaW5nIGltcGxlbWVudGVkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5ieSBNaWNyb3NvZnQgaW4gQXp1cmUsIEV2ZW50IGJhc2VkIHRl bGVtZXRyeSBwcm9wb3NlZCBieSBtYW55IGRpZmZlcmVudCB2ZW5kb3JzLA0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFtIGhvcGluZyB3ZSBuZWVkIHRvIGtlZXAgb24gd29ya2lu ZyBvbiBFQ0EgbW9kZWwgYW5kIGFsaWduIHRoaXMgZHJhZnQgd2l0aCBFQ0EuICZuYnNwO2xvdyBo YW5naW5nIGZydWl0IGlzIG5vdCBmYXIgZnJvbSB1cyw6LSkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JIGFsc28gaG9wZSB3aG8gYXJlIGludGVyZXN0ZWQgdG8gdGFja2xlIHRoaXMg aXNzdWUgY2FuIGpvaW4gYW5kIHdvcmsgdG9nZXRoZXIuIFdlIG5lZWQgdG8gc2VlayBjb21tb24g Z3JvdW5kIHdoaWxlIHJlc2VydmluZyBkaWZmZXJlbmNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LVFpbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5z LXNlcmlmIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IG5ldGNvbmYgW21haWx0bzpuZXRjb25m LWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuS7o+ih qCA8L3NwYW4+DQo8L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj5BbmR5IEJp ZXJtYW48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkemAgeaXtumXtDxz cGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OyxzYW5zLXNlcmlmIj4gMjAyMDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5bm0PHNwYW4g bGFuZz0iRU4tVVMiPjg8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjExPC9zcGFuPuaXpTxz cGFuIGxhbmc9IkVOLVVTIj4NCiAzOjQwPGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxh bmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEtlbnQgV2F0c2VuICZs dDtrZW50JiM0MztpZXRmQHdhdHNlbi5uZXQmZ3Q7PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFu IGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IG5ldGNvbmZAaWV0 Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBm b3IgZHJhZnQtd2FuZy1uZXRjb25mLWFkYXB0aXZlLXN1YnNjcmlwdGlvbjxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5JIGFtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBp biB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JdCBhcHBlYXJzIHRvIHByb3Bvc2Ug YSBjb21wbGV4IHNlbGYtbW9uaXRvcmluZyBzeXN0ZW0gc28gdGhhdCBZQU5HIFB1c2g8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+c3Vic2NyaXB0aW9ucyBjYW4gY2hhbmdlIHRoZWlyIHBhcmFtZXRlcnMg b24gdGhlIGZseSB0byBhZGFwdCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5jaGFuZ2luZyBuZXR3 b3JrIGNvbmRpdGlvbnMuIEUuZy4gbG93ZXIgdGhlICdwZXJpb2QnIHBhcmFtZXRlciB3aGVuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPmNvbmRpdGlvbnMgYXJlIHJpZ2h0LCB0byBwcm9kdWNlIG1vcmUg cHVzaC11cGRhdGUgcmVjb3JkcyB0aGFuIG5vcm1hbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBwcm9ibGVtIGlzIHNvbWV3aGF0IGludGVyZXN0 aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZmlsdGVyaW5nIG1lY2hhbmlzbXMgaW4gWUFO RyBQdXNoIGFyZSByZWFsbHkgYXdmdWwgYW5kIHRoZXJlIGlzIGEgbmVlZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj50byBpbXByb3ZlIGJvdGggZmlsdGVyIGFuZCB0cmlnZ2VyIG1lY2hhbmlzbXMuJm5i c3A7IEkgZG9uJ3QgdGhpbmsgdGhpcyBkcmFmdCBvZmZlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ YSByZWFzb25hYmxlIHNvbHV0aW9uLCBidXQgSSBlbmNvdXJhZ2UgZnVydGhlciBleHBlcmltZW50 YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlByb3ZlIGl0IHdvcmtzIGluIHJlYWwgcHJvZHVj dHMgdGhlbiBtYXliZSBpdCB3aWxsIGJlIHJlYWR5IGZvciBzdGFuZGFyZGl6YXRpb24uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFdlZCwgQXVnIDUsIDIw MjAgYXQgMzoxOCBQTSBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbnQlMkJpZXRm QHdhdHNlbi5uZXQiIHRhcmdldD0iX2JsYW5rIj5rZW50JiM0MztpZXRmQHdhdHNlbi5uZXQ8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+TkVUQ09ORiBXRyw8YnI+DQo8YnI+DQpQZXIgdGhlIHByZXZpb3VzIGVtYWlsIHNl bnQgbW9tZW50cyBhZ28sIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBzb2xpY2l0IGlucHV0IG9u IHRoZSBmb2xsb3dpbmcgZHJhZnQ6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO1RpdGxlOiZuYnNwO0FkYXB0aXZlIFN1YnNjcmlw dGlvbiB0byBZQU5HIE5vdGlmaWNhdGlvbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7ICZuYnNwO0xpbms6DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtd2FuZy1uZXRjb25mLWFkYXB0aXZlLXN1YnNjcmlwdGlvbiIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhbmctbmV0Y29uZi1hZGFwdGl2 ZS1zdWJzY3JpcHRpb248L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtBYnN0cmFjdDo8L3NwYW4+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoaXMgZG9jdW1l bnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBhbmQgYXNzb2NpYXRlZCBtZWNoYW5pc208L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVuYWJsaW5nIHN1YnNjcmliZXIncyBhZGFwdGl2 ZSBzdWJzY3JpcHRpb25zIHRvIGEgcHVibGlzaGVyJ3MgZXZlbnQ8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAm bmJzcDsgJm5ic3A7IHN0cmVhbXMgYXQgdmFyaW91cyBkaWZmZXJlbnQgcGVyaW9kIGludGVydmFs cyB3aXRoIHdoaWNoIHRvIHJlcG9ydDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdXBk YXRlcy4mbmJzcDsgQXBwbHlpbmcgdGhlc2UgZWxlbWVudHMgYWxsb3dzIGJvdGggc3Vic2NyaWJl ciBhbmQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHB1Ymxpc2hlciB0byBhdXRvbWF0 aWNhbGx5IGFkanVzdCB0aGUgdm9sdW1lIG9mIHRlbGVtZXRyeSB0cmFmZmljPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyBzZW50IGZyb20gcHVibGlzaGVyIHRvIHRoZSByZWNlaXZlcnMu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5JbiBwYXJ0aWN1bGFyLCBwbGVhc2UgZGlzY3VzcyBhZG9wdGlvbi1zdWl0YWJp bGl0eSBhcyBpdCByZWdhcmRzIHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOjwvc3Bhbj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7IDEpIGlzIHRoZSBwcm9i bGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cgdG8gc29sdmU/PGJyPg0KJm5ic3A7ICZu YnNwOyAyKSBpcyB0aGUgZHJhZnQgYSBzdWl0YWJsZSBiYXNpcyBmb3IgdGhlIHdvcms/PGJyPg0K PGJyPg0KPGJyPg0KUFM6IHRoaXMgbWVzc2FnZSBpcyBpdHNlbGYgbm90IGFuIGFkb3B0aW9uIHBv bGwsIGJ1dCByYXRoZXIgYW4gYXR0ZW1wdCB0byBnYXVnZSBpbnRlcmVzdC9zdXBwb3J0IGZvciBh IHBvdGVudGlhbCBmdXR1cmUgYWRvcHRpb24gcG9sbC48YnI+DQo8YnI+DQpORVRDT05GIENoYWly czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRjb25mQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABAAD8FACB0dggeml511mbschi_-- From nobody Mon Aug 10 19:39:28 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498D23A0EF5 for ; Mon, 10 Aug 2020 19:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvVPGcob3r9Z for ; Mon, 10 Aug 2020 19:39: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 175D93A0EE7 for ; Mon, 10 Aug 2020 19:39:24 -0700 (PDT) Received: from lhreml716-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B97B383B9830C20458FE; Tue, 11 Aug 2020 03:39:18 +0100 (IST) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml716-chm.china.huawei.com (10.201.108.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 03:39:18 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 10:39:15 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Tue, 11 Aug 2020 10:39:15 +0800 From: Tianran Zhou To: Mahesh Jethanandani , Andy Bierman CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif Thread-Index: AQHWa3XJ0mBLbRaES02VUjy2aRVTDKkxPlqAgAAkPACAANHOgA== Date: Tue, 11 Aug 2020 02:39:15 +0000 Message-ID: References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.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.108.243.128] Content-Type: multipart/alternative; boundary="_000_ec828c2e12b2460094988d84721dd7b9huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 02:39:26 -0000 --_000_ec828c2e12b2460094988d84721dd7b9huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, Thanks Mahesh for the clarification from the chairs perspective. And here is my clarification from the co-author perspective. We implemented the previous solution, and contributed it to IETF. But we dropped the solution because no customer has interest about this at = that time. I do not want to waste the WG time. We restart the draft because now several operators and customers have real = requirements and use cases, and would like to work on this solution. We reconstructed the solution with inputs, and would like to implement it t= o align with the changes. We would also like to share and contribute to the community. Cheers, Tianran From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh Jethana= ndani Sent: Tuesday, August 11, 2020 5:47 AM To: Andy Bierman Cc: netconf@ietf.org Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-not= if Hi Andy, On Aug 10, 2020, at 12:37 PM, Andy Bierman > wrote: Hi, I am trying to understand the NETCONF WG plan for UDP transport of notifica= tions. The WG was developing a UDP draft already I think, and it was dropped. https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-05 In IETF 103, there was extensive discussion on draft-ietf-netconf-udp-pub-c= hannel, with questions raised about the scope of the draft. In IETF 105 and= 106, our guidance (see meeting minutes) was to repurpose the draft for a U= DP notification channel, which the WG would then ultimately adopt. This dra= ft satisfies that request. To clarify this further, the datatracker marks t= he new draft as a replacement for the draft-ietf-netconf-udp-pub-channel. Mahesh & Kent (as co-chair) Since the WG dropped this problem and work item already, why should it reve= rse that decision and start over with a new solution? Andy On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen > wrote: NETCONF WG, Per the previous email sent moments ago, the chairs would like to solicit i= nput on the following draft: Title: UDP-based Transport for Configured Subscriptions Link: https://tools.ietf.org/html/draft-unyte-netconf-udp-notif Abstract: This document describes an UDP-based notification mechanism to collect data from networking devices. A shim header is proposed to facilitate the streaming of data directly from line cards to a collector. The objective is to rely on a lightweight approach to allow for higher frequency and better transit performance compared to already established notification mechanisms. In particular, please discuss adoption-suitability as it regards to the fol= lowing questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? PS: this message is itself not an adoption poll, but rather an attempt to g= auge interest/support for a potential future adoption poll. NETCONF Chairs _______________________________________________ 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 --_000_ec828c2e12b2460094988d84721dd7b9huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 

Thanks Mahesh for the clarification f= rom the chairs perspective.

 

And here is my clarification from the= co-author perspective.

We implemented the previous solution,= and contributed it to IETF.

But we dropped the solution because n= o customer has interest about this at that time. I do not want to waste the= WG time.

 

We restart the draft because now seve= ral operators and customers have real requirements and use cases, and would= like to work on this solution.    

We reconstructed the solution with in= puts, and would like to implement it to align with the changes.

We would also like to share and contr= ibute to the community.

 

Cheers,

Tianran

 

From: netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of Mahesh Jethanandani
Sent: Tuesday, August 11, 2020 5:47 AM
To: Andy Bierman <andy@yumaworks.com>
Cc: netconf@ietf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

 

Hi Andy,



On Aug 10, 2020, at 12:37 PM, Andy Bierman <andy@yumaworks.com> wrote:

 

Hi,

 

I am trying to understand the NETCONF WG plan for UD= P transport of notifications.

 

The WG was developing a UDP draft already I think, a= nd it was dropped.

 

In IETF 103, there was extensive discussion on draft= -ietf-netconf-udp-pub-channel, with questions raised about the scope of the= draft. In IETF 105 and 106, our guidance (see meeting minutes) was to repu= rpose the draft for a UDP notification channel, which the WG would then ultimately adopt. This draft satisfies th= at request. To clarify this further, the datatracker marks the new draft as= a replacement for the draft-ietf-netconf-udp-pub-channel.

 

Mahesh & Kent (as co-chair)



 

Since the WG dropped this problem and work item alre= ady, why should it reverse that decision

and start over with a new solution?

 

 

Andy

 

 

On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen <kent+ietf@watsen= ..net> wrote:

NETCONF WG,

Per the previous email sent moments ago, the chairs would like to solicit i= nput on the following draft:

   Title: UDP-based Transport for Configured Subscriptions
   Link: https://tools.ietf.org/html/draft-unyte-netconf-udp-notif
   Abstract:

      This document describes an UDP-based notification mech= anism to
      collect data from networking devices.  A shim hea= der is proposed to
      facilitate the streaming of data directly from line ca= rds to a
      collector.  The objective is to rely on a lightwe= ight approach to
      allow for higher frequency and better transit performa= nce compared to
      already established notification mechanisms.


In particular, please discuss adoption-suitability as it regards to the fol= lowing questions:

    1) is the problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the work?


PS: this message is itself not an adoption poll, but rather an attempt to g= auge interest/support for a potential future adoption poll.

NETCONF Chairs

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

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

 

--_000_ec828c2e12b2460094988d84721dd7b9huaweicom_-- From nobody Mon Aug 10 20:28:11 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498263A088A for ; Mon, 10 Aug 2020 20:28: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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2EMFzRe2_Tx for ; Mon, 10 Aug 2020 20:28: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 3F0D13A0881 for ; Mon, 10 Aug 2020 20:28:08 -0700 (PDT) Received: from lhreml734-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 5C59BB30A63654A83C98 for ; Tue, 11 Aug 2020 04:28:05 +0100 (IST) Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by lhreml734-chm.china.huawei.com (10.201.108.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 04:28:04 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 11:28:02 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Tue, 11 Aug 2020 11:28:02 +0800 From: Tianran Zhou To: Andy Bierman , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif Thread-Index: AQHWa3XT/yp90Vv9H0i3R7lOe+hPQ6kxPqwAgAEGkBA= Date: Tue, 11 Aug 2020 03:28:02 +0000 Message-ID: References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.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.108.243.128] Content-Type: multipart/alternative; boundary="_000_e7ccc6495dd34c4fae15a1697ccd1af5huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 03:28:10 -0000 --_000_e7ccc6495dd34c4fae15a1697ccd1af5huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldy4NCkJhc2ljYWxseSB5b3VyIHVuZGVy c3RhbmRpbmcgaXMgY29ycmVjdC4NClRoZSBiYWNrZ3JvdW5kIGlzIGFib3V0IHRoZSBkaXN0cmli dXRlZCBub3RpZiwgd2hpY2ggdGhlIGdsb2JhbCBzdWJzY3JpcHRpb24gd2lsbCBiZSBkZWNvbXBv c2VkIHRvIHNldmVyYWwgY29tcG9uZW50IHN1YnNjcmlwdGlvbnMuDQpBbmQgdGhlIGNsaWVudCBu ZWVkIHRvIGNvbXBvc2UgdGhlIGRhdGEgZnJvbSBtdWx0aXBsZSBwdWJsaXNoZXJzLiBJdCBuZWVk IHRvIGtub3cgaWYgYWxsIHRoZSBwaWVjZXMgb2Ygb25lIGRhdGEgYXJlIHJlY2VpdmVkLg0KQ3Vy cmVudCBzb2x1dGlvbiBkZXBlbmRzIG9uIGlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2Fn ZXMuIEkganVzdCBmb3VuZCBpdOKAmXMgZXhwaXJlZCENCkkgd291bGQgbGlrZSB0byBkaXNjdXNz IHdpdGggYXV0aG9ycyBhYm91dCB0aGUgcGxhbiBvbiB0aGF0IGRyYWZ0LiBGb3J0dW5hdGVseSB5 b3UgYXJlIG9uZSBjb2F1dGhvci4gQ291bGQgeW91IHBsZWFzZSBoZWxwIG9uIHRoZSBhbnN3ZXI/ DQpPdGhlcndpc2UsIHdlIGNhbiBzZWVrIG90aGVyIHdheS4NCg0KQmVzdCwNClRpYW5yYW4NCg0K RnJvbTogbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEFuZHkgQmllcm1hbg0KU2VudDogVHVlc2RheSwgQXVndXN0IDExLCAyMDIwIDM6MzkgQU0N ClRvOiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQpDYzogbmV0Y29uZkBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJh ZnQtdW55dGUtbmV0Y29uZi1kaXN0cmlidXRlZC1ub3RpZg0KDQpIaSwNCg0KSSBhbSB0cnlpbmcg dG8gdW5kZXJzdGFuZCB3aGF0IHByb2JsZW0gdGhpcyBkcmFmdCBhdHRlbXB0cyB0byBzb2x2ZS4N Ckl0IGFwcGVhcnMgZnJvbSB0aGUgc29sdXRpb24gcHJvcG9zYWwgaXMgdGhhdCB0aGUgcHJvYmxl bSB0byBiZSBzb2x2ZWQgaXMNCnRoZSBsYWNrIG9mIG1lc3NhZ2UgZ2VuZXJhdG9yIGlkZW50aWZp ZXJzIGFzc29jaWF0ZWQgd2l0aCBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMuDQpUaGVzZSBpZGVu dGlmaWVycyBjb3VsZCBwcmVzdW1hYmx5IGhlbHAgYSBjbGllbnQgdW5kZXJzdGFuZCBzb21lIGlt cGxlbWVudGF0aW9uIGRldGFpbHMNCnJlbGF0ZWQgdG8gYSBzdWJzY3JpcHRpb24uICBUaGUgc29s dXRpb24gc2VlbXMgdG8gcmVseSBvbiB0aGUgbWVzc2FnZS1nZW5lcmF0b3ItaWQNCmZpZWxkIGlu IHRoZSBub3RpZmljYXRpb24gbWVzc2FnZSAod2hpY2ggZG9lcyBub3QgZXhpc3QgaW4gY3VycmVu dCBSRkNzKS4NCg0KSSBkbyBub3QgdW5kZXJzdGFuZCB3aHkgdGhlIGNsaWVudCBuZWVkcyB0aGlz IGZlYXR1cmUuDQoNCg0KQW5keQ0KDQoNCk9uIFdlZCwgQXVnIDUsIDIwMjAgYXQgMzoxNCBQTSBL ZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ8bWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNl bi5uZXQ+PiB3cm90ZToNCk5FVENPTkYgV0csDQoNClBlciB0aGUgcHJldmlvdXMgZW1haWwgc2Vu dCBtb21lbnRzIGFnbywgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIHNvbGljaXQgaW5wdXQgb24g dGhlIGZvbGxvd2luZyBkcmFmdDoNCg0KICAgVGl0bGU6IFN1YnNjcmlwdGlvbiB0byBEaXN0cmli dXRlZCBOb3RpZmljYXRpb25zDQogICBMaW5rOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtdW55dGUtbmV0Y29uZi1kaXN0cmlidXRlZC1ub3RpZg0KICAgQWJzdHJhY3Q6DQogICAg ICBUaGlzIGRvY3VtZW50cyBkZXNjcmliZXMgZXh0ZW5zaW9ucyB0byB0aGUgWUFORyBub3RpZmlj YXRpb25zDQogICAgICBzdWJzY3JpcHRpb24gdG8gYWxsb3cgbWV0cmljcyBiZWluZyBwdWJsaXNo ZWQgZGlyZWN0bHkgZnJvbQ0KICAgICAgcHJvY2Vzc29ycyBvbiBsaW5lIGNhcmRzIHRvIHRhcmdl dCByZWNlaXZlcnMsIHdoaWxlIHN1YnNjcmlwdGlvbiBpcw0KICAgICAgc3RpbGwgbWFpbnRhaW5l ZCBhdCB0aGUgcm91dGUgcHJvY2Vzc29yIGluIGEgZGlzdHJpYnV0ZWQgZm9yd2FyZGluZw0KICAg ICAgc3lzdGVtLg0KDQoNCkluIHBhcnRpY3VsYXIsIHBsZWFzZSBkaXNjdXNzIGFkb3B0aW9uLXN1 aXRhYmlsaXR5IGFzIGl0IHJlZ2FyZHMgdG8gdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6DQoNCiAg ICAxKSBpcyB0aGUgcHJvYmxlbSBpbXBvcnRhbnQgZm9yIHRoZSBORVRDT05GIFdHIHRvIHNvbHZl Pw0KICAgIDIpIGlzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJhc2lzIGZvciB0aGUgd29yaz8NCg0K DQpQUzogdGhpcyBtZXNzYWdlIGlzIGl0c2VsZiBub3QgYW4gYWRvcHRpb24gcG9sbCwgYnV0IHJh dGhlciBhbiBhdHRlbXB0IHRvIGdhdWdlIGludGVyZXN0L3N1cHBvcnQgZm9yIGEgcG90ZW50aWFs IGZ1dHVyZSBhZG9wdGlvbiBwb2xsLg0KDQpORVRDT05GIENoYWlycw0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldGNvbmYgbWFpbGluZyBsaXN0DQpu ZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo= --_000_e7ccc6495dd34c4fae15a1697ccd1af5huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQg OTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB5b3VyIHJldmlldy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ QmFzaWNhbGx5IHlvdXIgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0Lg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlRoZSBiYWNrZ3JvdW5kIGlzIGFib3V0IHRoZSBkaXN0cmlidXRlZCBub3RpZiwgd2hpY2gg dGhlIGdsb2JhbCBzdWJzY3JpcHRpb24gd2lsbCBiZSBkZWNvbXBvc2VkIHRvIHNldmVyYWwgY29t cG9uZW50IHN1YnNjcmlwdGlvbnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kIHRoZSBjbGllbnQg bmVlZCB0byBjb21wb3NlIHRoZSBkYXRhIGZyb20gbXVsdGlwbGUgcHVibGlzaGVycy4gSXQgbmVl ZCB0byBrbm93IGlmIGFsbCB0aGUgcGllY2VzIG9mIG9uZSBkYXRhIGFyZSByZWNlaXZlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Q3VycmVudCBzb2x1dGlvbiBkZXBlbmRzIG9uIGlldGYtbmV0Y29uZi1u b3RpZmljYXRpb24tbWVzc2FnZXMuIEkganVzdCBmb3VuZCBpdOKAmXMgZXhwaXJlZCE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SSB3b3VsZCBsaWtlIHRvIGRpc2N1c3Mgd2l0aCBhdXRob3JzIGFib3V0IHRo ZSBwbGFuIG9uIHRoYXQgZHJhZnQuIEZvcnR1bmF0ZWx5IHlvdSBhcmUgb25lIGNvYXV0aG9yLiBD b3VsZCB5b3UgcGxlYXNlIGhlbHAgb24gdGhlIGFuc3dlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T3Ro ZXJ3aXNlLCB3ZSBjYW4gc2VlayBvdGhlciB3YXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5CZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaWFucmFuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IG5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMTEs IDIwMjAgMzozOSBBTTxicj4NCjxiPlRvOjwvYj4gS2VudCBXYXRzZW4gJmx0O2tlbnQmIzQzO2ll dGZAd2F0c2VuLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJh ZnQtdW55dGUtbmV0Y29uZi1kaXN0cmlidXRlZC1ub3RpZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBhbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB3aGF0IHByb2JsZW0gdGhpcyBkcmFm dCBhdHRlbXB0cyB0byBzb2x2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl0IGFwcGVhcnMgZnJvbSB0aGUgc29sdXRpb24gcHJvcG9zYWwgaXMg dGhhdCB0aGUgcHJvYmxlbSB0byBiZSBzb2x2ZWQgaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBsYWNrIG9mIG1lc3NhZ2UgZ2VuZXJhdG9y IGlkZW50aWZpZXJzIGFzc29jaWF0ZWQgd2l0aCBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVzZSBp ZGVudGlmaWVycyBjb3VsZCBwcmVzdW1hYmx5IGhlbHAgYSBjbGllbnQgdW5kZXJzdGFuZCBzb21l IGltcGxlbWVudGF0aW9uIGRldGFpbHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnJlbGF0ZWQmbmJzcDt0byBhIHN1YnNjcmlwdGlvbi4mbmJzcDsg VGhlIHNvbHV0aW9uIHNlZW1zIHRvIHJlbHkgb24gdGhlIG1lc3NhZ2UtZ2VuZXJhdG9yLWlkPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5maWVsZCBp biB0aGUgbm90aWZpY2F0aW9uIG1lc3NhZ2UgKHdoaWNoIGRvZXMgbm90IGV4aXN0IGluIGN1cnJl bnQgUkZDcykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgZG8gbm90IHVuZGVyc3RhbmQgd2h5IHRoZSBjbGllbnQgbmVlZHMgdGhpcyBmZWF0 dXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBXZWQsIEF1ZyA1LCAyMDIwIGF0IDM6MTQgUE0gS2VudCBXYXRzZW4gJmx0Ozxh IGhyZWY9Im1haWx0bzprZW50JTJCaWV0ZkB3YXRzZW4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+a2Vu dCYjNDM7aWV0ZkB3YXRzZW4ubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5ORVRDT05GIFdHLDxicj4NCjxicj4NClBlciB0aGUgcHJldmlvdXMgZW1h aWwgc2VudCBtb21lbnRzIGFnbywgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIHNvbGljaXQgaW5w dXQgb24gdGhlIGZvbGxvd2luZyBkcmFmdDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtUaXRsZTombmJzcDtTdWJzY3Jp cHRpb24gdG8gRGlzdHJpYnV0ZWQgTm90aWZpY2F0aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO0xpbms6DQo8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdW55dGUtbmV0Y29uZi1kaXN0cmlidXRl ZC1ub3RpZiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXVueXRlLW5ldGNvbmYtZGlzdHJpYnV0ZWQtbm90aWY8L2E+PC9zcGFuPjxicj4NCjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO0Fic3RyYWN0Ojwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoaXMgZG9jdW1lbnRzIGRlc2NyaWJlcyBleHRl bnNpb25zIHRvIHRoZSBZQU5HIG5vdGlmaWNhdGlvbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHN1YnNjcmlwdGlvbiB0byBhbGxvdyBtZXRyaWNzIGJl aW5nIHB1Ymxpc2hlZCBkaXJlY3RseSBmcm9tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyBwcm9jZXNzb3JzIG9uIGxpbmUgY2FyZHMgdG8gdGFyZ2V0IHJl Y2VpdmVycywgd2hpbGUgc3Vic2NyaXB0aW9uIGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyBzdGlsbCBtYWludGFpbmVkIGF0IHRoZSByb3V0ZSBwcm9j ZXNzb3IgaW4gYSBkaXN0cmlidXRlZCBmb3J3YXJkaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBzeXN0ZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KSW4gcGFydGljdWxhciwgcGxl YXNlIGRpc2N1c3MgYWRvcHRpb24tc3VpdGFiaWxpdHkgYXMgaXQgcmVnYXJkcyB0byB0aGUgZm9s bG93aW5nIHF1ZXN0aW9uczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAxKSBpcyB0aGUgcHJvYmxlbSBp bXBvcnRhbnQgZm9yIHRoZSBORVRDT05GIFdHIHRvIHNvbHZlPzxicj4NCiZuYnNwOyAmbmJzcDsg MikgaXMgdGhlIGRyYWZ0IGEgc3VpdGFibGUgYmFzaXMgZm9yIHRoZSB3b3JrPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KUFM6IHRoaXMgbWVzc2FnZSBpcyBpdHNlbGYg bm90IGFuIGFkb3B0aW9uIHBvbGwsIGJ1dCByYXRoZXIgYW4gYXR0ZW1wdCB0byBnYXVnZSBpbnRl cmVzdC9zdXBwb3J0IGZvciBhIHBvdGVudGlhbCBmdXR1cmUgYWRvcHRpb24gcG9sbC48YnI+DQo8 YnI+DQpORVRDT05GIENoYWlyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_e7ccc6495dd34c4fae15a1697ccd1af5huaweicom_-- From nobody Mon Aug 10 21:10:39 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26313A0A6E for ; Mon, 10 Aug 2020 21:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id merP-rxArsYn for ; Mon, 10 Aug 2020 21:10:34 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 9A1973A0A69 for ; Mon, 10 Aug 2020 21:10:34 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id m71so6503827pfd.1 for ; Mon, 10 Aug 2020 21:10:34 -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=y8ngufFEpd4nppikn29TtxZfYW4MpS08AtFEbao42Dg=; b=Ftf3fvxIqA+v+njg2OthHiglHUll0Z7EwxNypfIPNKAwe4x2hJDeerdPSqj3wEG+rG GXbOSD2jVwSv/KUq0hrsvN3FZxRFb2+jCMNsKj/4RKFL/RqyBlhGXyWT7iB2K0TSSSPK 9BR5BYdAHV2c/Nq4q+WSJHBLKOKxks7dCaeo7So7xP3EmNJF5gjKn3QrI7hdKLPB+7KX EQzdBEGqHu8fH4qu3bL3KF1BS5SZco/wiT7qcoSb6kF+w9aWYvDsBiTAtiU+93okd3gd ShzNsHhizqHcON2y+iC01DukX67DtywEKgw8G2EHTlVgB8DuES6LqlQNxsxRZ96+9BI/ BsLQ== 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=y8ngufFEpd4nppikn29TtxZfYW4MpS08AtFEbao42Dg=; b=DB8QwYSrzEn8yy4R4JtzhVsdzXgrafcFFb+lDGtT3nFnA8FtQosCcqgdlQ41sHVtD2 o0LvcMAhNa8pjUPC9iXmDpgMEjuSK2vJbo+v5JO6HVDEGw5HiGTG+RU5qE4+jPE9kzgG sDNP9amJezZD/foI3f3e5C2QmRUmd62101KhMfFgwVx20y6P4GlR0GanT0CzcRcfXZTh dGdq+msDgEmwMS30lOu1TYa1WMMQ+Ffwbvscd5yC74b9eDxWRnTX0H8Kd/AXtwiiTg2n Yq5DP5mO/EvFjd3NHdzWL1MIFAGiIUOCPne7tz8XdfOIo/KelNHYkRxYteWtgOIAtXGo 57/Q== X-Gm-Message-State: AOAM5322Af7tBmXE9ek9As5cbhQGFnLX6Sv1ujz0dr+lHqlciYEJxmxK MPURGLiF14I8knK6Y7eP9WA= X-Google-Smtp-Source: ABdhPJzVPP6HcC3L0zyntWoVcHU+2WKgUe9UjK8W9YzdqEXRLGjnOo6Z1ToY0K3fheaKcHRNUpJX8Q== X-Received: by 2002:a63:2542:: with SMTP id l63mr23895779pgl.418.1597119034096; Mon, 10 Aug 2020 21:10:34 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:89a1:175d:59c8:8fe? ([2601:647:5600:5020:89a1:175d:59c8:8fe]) by smtp.gmail.com with ESMTPSA id b23sm16601100pfo.12.2020.08.10.21.10.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2020 21:10:33 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <968A196C-62F0-4127-8CD0-BB7BDB3F900C@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_28551F1D-1345-431A-92C7-6EB0942ED48C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\)) Date: Mon, 10 Aug 2020 21:10:32 -0700 In-Reply-To: Cc: "netconf@ietf.org" To: Tianran Zhou References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> X-Mailer: Apple Mail (2.3445.9.6) Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 04:10:38 -0000 --Apple-Mail=_28551F1D-1345-431A-92C7-6EB0942ED48C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tianran, > On Aug 10, 2020, at 8:28 PM, Tianran Zhou = wrote: >=20 > Current solution depends on ietf-netconf-notification-messages. I just = found it=E2=80=99s expired! In IETF 108, the chairs mentioned that this draft is on hold till = https-notif draft goes into publication, at which time it will also go = for publication. Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_28551F1D-1345-431A-92C7-6EB0942ED48C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Tianran,

On Aug 10, 2020, at 8:28 PM, Tianran Zhou = <zhoutianran@huawei.com> wrote:

Current solution depends on = ietf-netconf-notification-messages. I just found it=E2=80=99s = expired!

In IETF 108, = the chairs mentioned that this draft is on hold till https-notif draft = goes into publication, at which time it will also go for = publication.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_28551F1D-1345-431A-92C7-6EB0942ED48C-- From nobody Mon Aug 10 21:23:00 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420D93A0B30 for ; Mon, 10 Aug 2020 21:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3D6f3sc1nzcL for ; Mon, 10 Aug 2020 21:22:57 -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 4CC363A0B10 for ; Mon, 10 Aug 2020 21:22:57 -0700 (PDT) Received: from lhreml726-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 8A1A1F9B783C3C7B8FA6; Tue, 11 Aug 2020 05:22:52 +0100 (IST) Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by lhreml726-chm.china.huawei.com (10.201.108.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 05:22:51 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 12:22:49 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Tue, 11 Aug 2020 12:22:49 +0800 From: Tianran Zhou To: Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif Thread-Index: AQHWa3XT/yp90Vv9H0i3R7lOe+hPQ6kxPqwAgAEGkBD//4hxAIAAiQlw Date: Tue, 11 Aug 2020 04:22:49 +0000 Message-ID: References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> <968A196C-62F0-4127-8CD0-BB7BDB3F900C@gmail.com> In-Reply-To: <968A196C-62F0-4127-8CD0-BB7BDB3F900C@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.128] Content-Type: multipart/alternative; boundary="_000_d1bd6e66a32546aa8046b1b50e0536b1huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 04:22:59 -0000 --_000_d1bd6e66a32546aa8046b1b50e0536b1huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFoZXNoLA0KVGhhbmtzIGZvciB5b3VyIGNsYXJpZmljYXRpb24uDQpJIGFtIHNvcnJ5IEkg ZGlkIG5vdCBrbm93IHRoaXMuDQpTbyBJIHRoaW5rIHdlIGNhbiBzdGlsbCBkZXBlbmQgb24gaWV0 Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcy4gUmlnaHQ/DQoNCkNoZWVycywNClRpYW5y YW4NCg0KRnJvbTogTWFoZXNoIEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21h aWwuY29tXQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDExLCAyMDIwIDEyOjExIFBNDQpUbzogVGlh bnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPg0KQ2M6IG5ldGNvbmZAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0LXVu eXRlLW5ldGNvbmYtZGlzdHJpYnV0ZWQtbm90aWYNCg0KSGkgVGlhbnJhbiwNCg0KDQpPbiBBdWcg MTAsIDIwMjAsIGF0IDg6MjggUE0sIFRpYW5yYW4gWmhvdSA8emhvdXRpYW5yYW5AaHVhd2VpLmNv bTxtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpDdXJyZW50IHNvbHV0 aW9uIGRlcGVuZHMgb24gaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcy4gSSBqdXN0 IGZvdW5kIGl04oCZcyBleHBpcmVkIQ0KDQpJbiBJRVRGIDEwOCwgdGhlIGNoYWlycyBtZW50aW9u ZWQgdGhhdCB0aGlzIGRyYWZ0IGlzIG9uIGhvbGQgdGlsbCBodHRwcy1ub3RpZiBkcmFmdCBnb2Vz IGludG8gcHVibGljYXRpb24sIGF0IHdoaWNoIHRpbWUgaXQgd2lsbCBhbHNvIGdvIGZvciBwdWJs aWNhdGlvbi4NCg0KVGhhbmtzLg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5p QGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQo= --_000_d1bd6e66a32546aa8046b1b50e0536b1huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgTWFoZXNo LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SSBhbSBzb3JyeSBJIGRpZCBub3Qga25vdyB0aGlzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5TbyBJIHRoaW5rIHdlIGNhbiBzdGlsbCBkZXBlbmQgb24NCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+aWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcy4g UmlnaHQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRpYW5yYW48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWFoZXNo IEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KPGJyPg0KPGI+ U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCAxMSwgMjAyMCAxMjoxMSBQTTxicj4NCjxiPlRvOjwv Yj4gVGlhbnJhbiBaaG91ICZsdDt6aG91dGlhbnJhbkBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldGNvbmZd IEFkb3B0aW9uLXN1aXRhYmlsaXR5IGZvciBkcmFmdC11bnl0ZS1uZXRjb25mLWRpc3RyaWJ1dGVk LW5vdGlmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkg VGlhbnJhbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEF1ZyAxMCwgMjAyMCwgYXQgODoyOCBQTSwgVGlhbnJhbiBaaG91ICZsdDs8YSBocmVmPSJtYWls dG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbSI+emhvdXRpYW5yYW5AaHVhd2VpLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Q3VycmVudCBzb2x1dGlvbiBkZXBlbmRzIG9uIGlldGYtbmV0 Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMuIEkganVzdCBmb3VuZCBpdOKAmXMgZXhwaXJlZCE8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SW4gSUVURiAxMDgsIHRoZSBjaGFpcnMgbWVudGlvbmVkIHRoYXQgdGhpcyBk cmFmdCBpcyBvbiBob2xkIHRpbGwgaHR0cHMtbm90aWYgZHJhZnQgZ29lcyBpbnRvIHB1YmxpY2F0 aW9uLCBhdCB3aGljaCB0aW1lIGl0IHdpbGwgYWxzbyBnbyBmb3IgcHVibGljYXRpb24uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1haGVzaCBKZXRo YW5hbmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFu aUBnbWFpbC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_d1bd6e66a32546aa8046b1b50e0536b1huaweicom_-- From nobody Mon Aug 10 23:22:35 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF283A0CB3 for ; Mon, 10 Aug 2020 23:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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 TOjWCAiHnh6c for ; Mon, 10 Aug 2020 23:22:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 401D93A0C9B for ; Mon, 10 Aug 2020 23:22:31 -0700 (PDT) Received: from [172.16.0.44] ([73.189.160.186]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MRnRf-1kGgE03ajB-00Sv2m; Tue, 11 Aug 2020 08:22:30 +0200 To: Kent Watsen , "netconf@ietf.org" References: <01000173c0b45676-dc00a30e-1234-45d2-ba20-131c9467110d-000000@us-east-1.amazonses.com> From: Alexander L Clemm Message-ID: Date: Mon, 10 Aug 2020 23:22:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <01000173c0b45676-dc00a30e-1234-45d2-ba20-131c9467110d-000000@us-east-1.amazonses.com> Content-Type: multipart/alternative; boundary="------------A18023ECD6EAEF1970294689" Content-Language: en-US X-Provags-ID: V03:K1:EGqxibV6bSUhGwCNfD1if5J2Af7imYGvzX7EBUqUgSuT67BSp8K XgPvPscUlkzRFF/0i5o/cZIBpMZxu3Kpsx4eRLNHMBbacqG82bL9geTjPxGGVmOM4mHXdMZ t04JEY3CJfBUan1GCv4IFlaf5kOCl27Py4Ip7Tnb+DNMaFD3kjHFCYLVK0qfeaeayxr3s4E SswITHbtUhjBGaU80x1ig== X-UI-Out-Filterresults: notjunk:1;V03:K0:EFGIheZydv8=:Weg6Z1jFXTo89APqbieGAw epwWgoCbjgD0QvTYyGjVtiZ0VtLqcj12hV/ose2Td7V2+ZLop1YQiLVQYE2LP8OSgb6ThPCC7 +lK+eA7sjSIfxriR7Eslu2wjnkU8OqMnjkXnsB66QHp2Xj4phhUcJtUNMoTONCPhTCCLNp6fH yXZXsc3qwzVp57nSe7lqsxkPE92iwf/9HfTgEvbapnvKQEHELsS4tuH+iSXEqMVCwpCN3LAoJ lQpoUCIv75QIMFESrz5KozSSkz96rYPyXpR7KZcuNE6dA7NnpcObiZ+LpmYifVTnWdji3nabO SSAH28tsCy86iZlEhLG/e1PYJZCLp/XSdlD6EkRyZ4ub8h91bQXKNWV+rVFqR31y1bjickeU9 YtYMzqNJQr/yMa8RNAOcemEyDnVzh5hPtLFo1fV44K0yP1nHEQdqi6q7sCq8+GPzh24SCb2hz Q+IIWd6p8mq+2IhJgGTVq+Mhl5Yuf+QDvPBfxgaz6ifRfGzoH4nci34GyICbFHy1xosrH/6mD xCF6I8dE+Lve2OcUvGEppDKTjLnfNNtYIBYBDhETN25PpvnzJupKF1lx4wxH1ywbwPYjMQSGr TpKZo/AsdvWJ+z+9yI5Gw7c2jLMxXomU0oonSnhY+RiwKJwYxHfLf2w48fEusj5zFB0D8dw9U KdTfASO6jBlNLm2rSIITolSJWisD+qJTSxL3YJvGaicA4EbcatcwM5NweaKw7RqUff9nrhOdf 3DdtE8fTDV06sBB1YiwLGvdSzqhcj8i1iE3IithPa78utWrSqDXZnnp8jzjLTh3fu6Awy1w85 dlrVOR9TMlMf4GDqQ1YBDgmC+4/ckDMVes2mSl3xrkS3+LetBd86MoxDM16CYcOMuqv5X5a Archived-At: Subject: [netconf] Adoption-suitable vs adoption (Re: Adoption-suitability for draft-wang-netconf-bulk-subscribed-notifications) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 06:22:34 -0000 This is a multi-part message in MIME format. --------------A18023ECD6EAEF1970294689 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi, I am not quite sure about the purpose of these adoption-suitability polls (not just for this but for the various other drafts) and was wondering about the rationale for it.  It seems to me to be redundant with anactual adoption call - do we foresee situations where a draft is adoption-suitable but would not actually be adopted?  If a draft is deemed to not yet be adoption-suitable, is there any difference to the draft not yet being adopted?  What is expected to happen in the interim state or time period between when a draft is deemed "adoption-suitable" until it actually gets adopted?  Thanks --- Alex On 8/5/2020 3:18 PM, Kent Watsen wrote: > > NETCONF WG, > > Per the previous email sent moments ago, the chairs would like to > solicit input on the following draft: > >    Title: Bulk Subscription to YANG Event Notification >    Link: > https://tools.ietf.org/html/draft-wang-netconf-bulk-subscribed-notifications >    Abstract: > >       This document defines a YANG data model and associated mechanism > that >       allows subscriber applications to bulk subscribe to publishers' > event >       streams based on bundle group information such as bundle size and >       bundle latency.  This allows the publishers to report multiple >       notifications in a single bundling message. > > > In particular, please discuss adoption-suitability as it regards to > the following questions: > >     1) is the problem important for the NETCONF WG to solve? >     2) is the draft a suitable basis for the work? > > > PS: this message is itself not an adoption poll, but rather an attempt > to gauge interest/support for a potential future adoption poll. > > NETCONF Chairs > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------A18023ECD6EAEF1970294689 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi,

I am not quite sure about the purpose of these adoption-suitability polls (not just for this but for the various other drafts) and was wondering about the rationale for it.  It seems to me to be redundant with anactual adoption call - do we foresee situations where a draft is adoption-suitable but would not actually be adopted?  If a draft is deemed to not yet be adoption-suitable, is there any difference to the draft not yet being adopted?  What is expected to happen in the interim state or time period between when a draft is deemed "adoption-suitable" until it actually gets adopted? 

Thanks

--- Alex

On 8/5/2020 3:18 PM, Kent Watsen wrote:

NETCONF WG,

Per the previous email sent moments ago, the chairs would like to solicit input on the following draft:

   Title: Bulk Subscription to YANG Event Notification
   Link: https://tools.ietf.org/html/draft-wang-netconf-bulk-subscribed-notifications
   Abstract:

      This document defines a YANG data model and associated mechanism that
      allows subscriber applications to bulk subscribe to publishers' event
      streams based on bundle group information such as bundle size and
      bundle latency.  This allows the publishers to report multiple
      notifications in a single bundling message.


In particular, please discuss adoption-suitability as it regards to the following questions:

    1) is the problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the work?


PS: this message is itself not an adoption poll, but rather an attempt to gauge interest/support for a potential future adoption poll.

NETCONF Chairs

_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
--------------A18023ECD6EAEF1970294689-- From nobody Tue Aug 11 04:10:33 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FCE3A0FA8 for ; Tue, 11 Aug 2020 04:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOF50S9Lt0G0 for ; Tue, 11 Aug 2020 04:10: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 DDBA73A0FA7 for ; Tue, 11 Aug 2020 04:10:28 -0700 (PDT) Received: from lhreml721-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 36A79DE209F5BF7E338D for ; Tue, 11 Aug 2020 12:10:24 +0100 (IST) Received: from dggeme702-chm.china.huawei.com (10.1.199.98) by lhreml721-chm.china.huawei.com (10.201.108.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 12:10:23 +0100 Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme702-chm.china.huawei.com (10.1.199.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 11 Aug 2020 19:10:21 +0800 Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1913.007; Tue, 11 Aug 2020 19:10:21 +0800 From: "Wubo (lana)" To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities Thread-Index: AdZvtJ0vWgensLp3RCq6eyZ+MPcrHA== Date: Tue, 11 Aug 2020 11:10:21 +0000 Message-ID: <19459f2761bd4571a3ebe8e35c567e29@huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.123.74] Content-Type: multipart/alternative; boundary="_000_19459f2761bd4571a3ebe8e35c567e29huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 11:10:31 -0000 --_000_19459f2761bd4571a3ebe8e35c567e29huaweicom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQoxKSBpcyB0aGUgcHJvYmxlbSBpbXBvcnRhbnQgZm9yIHRoZSBORVRDT05GIFdH IHRvIHNvbHZlPw0KDQpZZXMsIEkgdGhpbmsgdGhlIGV4dGVuZGVkIHBlci1ub2RlIG5vdGlmaWNh dGlvbiBjYXBhYmlsaXR5IGluIHRoaXMgZHJhZnQsIGluY2x1ZGluZyB0aW1lci1iYXNlZC10cmln Z2VyIGFuZCB0aHJlc2hvbGQtYmFzZWQgdHJpZ2dlciwNCmNvdWxkIGNvbXBsZW1lbnQgUkZDODY0 MSBleGlzdGluZyBnZW5lcmljIHRyaWdnZXIgbWVjaGFuaXNtLg0KQW5kIEkgYmVsaWV2ZSB0aGF0 IHRoZSBORVRDT05GIFdHIGlzIHRoZSBhcHByb3ByaWF0ZSBXRyBmb3IgdGhpcyB3b3JrLCBzaW5j ZSB0aGVzZSBjYXBhYmlsaXR5IGV4dGVuZHMgZnJvbSBub3RpZmljYXRpb24gY2FwYWJpbGl0eSBt b2RlbA0KZGVmaW5lZCBpbiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxp dGllcywgd2hpY2ggcHJvdmlkZXMgYSBnb29kIGJhc2lzIGZvciBzZXJ2ZXIgY2FwYWJpbGl0aWVz IGFkdmVydGlzZW1lbnQuDQoNCjIpIGlzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJhc2lzIGZvciB0 aGUgd29yaz8NCg0KSSBoYXZlIHJldmlld2VkIHRoZSBkcmFmdCBhbmQgaXQgcHJvdmlkZXMgYSBn b29kIGJhc2lzLiBJZiB0aGlzIHdvcmsgZ2V0cyBhZG9wdGVkLCBJIGFtIGhhcHB5IHRvIHJldmll dyBhbnkgdmVyc2lvbiBvZiB0aGlzIHdvcmsNCmFuZCBjb250cmlidXRlIHRvIGFueSBkaXNjdXNz aW9uIGFuZCBoZWxwIG1vdmUgdGhpcyB3b3JrIGZvcndhcmQuDQoNCkJlc3QgcmVnYXJkcywNCkJv DQoNCreivP7IyzogbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gtPqx 7SBLZW50IFdhdHNlbg0Kt6LLzcqxvOQ6IDIwMjDE6jjUwjbI1SA2OjE4DQrK1bz+yMs6IG5ldGNv bmZAaWV0Zi5vcmcNCtb3zOI6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJh ZnQtdGFvLW5ldGNvbmYtZGF0YS1leHBvcnQtY2FwYWJpbGl0aWVzDQoNCg0KTkVUQ09ORiBXRywN Cg0KUGVyIHRoZSBwcmV2aW91cyBlbWFpbCBzZW50IG1vbWVudHMgYWdvLCB0aGUgY2hhaXJzIHdv dWxkIGxpa2UgdG8gc29saWNpdCBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0Og0KDQogICBU aXRsZTogVGVsZW1ldHJ5IERhdGEgRXhwb3J0IGNhcGFiaWxpdHkNCiAgIExpbms6IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10YW8tbmV0Y29uZi1kYXRhLWV4cG9ydC1jYXBhYmls aXRpZXMNCiAgIEFic3RyYWN0Og0KICAgICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIFlBTkcg bW9kdWxlIGZvciB0ZWxlbWV0cnkgZGF0YSBleHBvcnQNCiAgICAgIGNhcGFiaWxpdHkgd2hpY2gg YXVnbWVudHMgc3lzdGVtIENhcGFiaWxpdGllcyBtb2RlbCBhbmQgcHJvdmlkZXMNCiAgICAgIGFk ZGl0aW9uYWwgdGVsZW1ldHJ5IGRhdGEgZXhwb3J0IGF0dHJpYnV0ZXMgYXNzb2NpYXRlZCB3aXRo IHN5c3RlbQ0KICAgICAgY2FwYWJpbGl0eSBmb3IgdHJhbnNwb3J0IGRlcGVuZGVudCBjYXBhYmls aXR5IG5lZ290aWF0aW9uLg0KDQoNCkluIHBhcnRpY3VsYXIsIHBsZWFzZSBkaXNjdXNzIGFkb3B0 aW9uLXN1aXRhYmlsaXR5IGFzIGl0IHJlZ2FyZHMgdG8gdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6 DQoNCiAgICAxKSBpcyB0aGUgcHJvYmxlbSBpbXBvcnRhbnQgZm9yIHRoZSBORVRDT05GIFdHIHRv IHNvbHZlPw0KICAgIDIpIGlzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJhc2lzIGZvciB0aGUgd29y az8NCg0KDQpQUzogdGhpcyBtZXNzYWdlIGlzIGl0c2VsZiBub3QgYW4gYWRvcHRpb24gcG9sbCwg YnV0IHJhdGhlciBhbiBhdHRlbXB0IHRvIGdhdWdlIGludGVyZXN0L3N1cHBvcnQgZm9yIGEgcG90 ZW50aWFsIGZ1dHVyZSBhZG9wdGlvbiBwb2xsLg0KDQpORVRDT05GIENoYWlycw0K --_000_19459f2761bd4571a3ebe8e35c567e29huaweicom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 

1) is the problem impo= rtant for the NETCONF WG to solve?

 

Yes, I think the exten= ded per-node notification capability in this draft, including timer-based-t= rigger and threshold-based trigger,

could complement RFC86= 41 existing generic trigger mechanism.

And I believe that the= NETCONF WG is the appropriate WG for this work, since these capability ext= ends from notification capability model

defined in draft-ietf-= netconf-notification-capabilities, which provides a good basis for server c= apabilities advertisement.

 

2) is the draft a suit= able basis for the work?

I have reviewed the dr= aft and it provides a good basis. If this work gets adopted, I am happy to = review any version of this work

and contribute to any = discussion and help move this work forward.

 

Best regards,

Bo

 

=B7=A2=BC=FE=C8=CB: netconf [mailt= o:netconf-bounces@ietf.org] =B4=FA=B1=ED Kent Watsen
=B7=A2=CB=CD=CA=B1=BC=E4:<= /span> 2020=C4=EA8=D4=C26=C8=D5 6:18
=CA=D5=BC=FE=C8=CB: netconf@ietf.org
=D6=F7=CC=E2: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabili= ties

 

 

NETCONF W= G,

Per the previous email sent moments ago, the chairs would like to solicit i= nput on the following draft:<= /p>

&nbs= p;

  &n= bsp;Title: Telemetry Data Export capability

   Link: https:= //tools.ietf.org/html/draft-tao-netconf-data-export-capabilities
   Abstract:=

  &n= bsp;   This document proposes a YANG module for telemetry data export<= /span>

  &n= bsp;   capability which augments system Capabilities model and provide= s

  &n= bsp;   additional telemetry data export attributes associated with sys= tem

  &n= bsp;   capability for transport dependent capability negotiation.

 


In particular, please discuss adoption-suitability as it regards to the fol= lowing questions:

&nbs= p;

  &n= bsp; 1) is the problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the work?



PS: this message is itself not an adoption poll, but rather an attempt to g= auge interest/support for a potential future adoption poll.

NETCONF Chairs

--_000_19459f2761bd4571a3ebe8e35c567e29huaweicom_-- From nobody Tue Aug 11 11:10:35 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1B03A081C for ; Tue, 11 Aug 2020 11:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_8N85gfNvCA for ; Tue, 11 Aug 2020 11:10:30 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A30C3A080C for ; Tue, 11 Aug 2020 11:10:29 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id w14so14582666ljj.4 for ; Tue, 11 Aug 2020 11:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/TAZkQxNrDKoLx3z8PvajXe3hG/4hF5GHpnt4HaSjZE=; b=Ykh+wZqA/Ouv4hzRHIq1ISyRWykSxWSlV6lTbGOUvX8Jp9TtS0J771bQNVuTWrJHYB nsfdNtERFPVlWTInIrrGzb+xIywQGD9m1X2Zs15+Kkg10BNokD5hs72ntwmJIUD80i+m KJF3cvrd/JrclMU3gOESDGkxmJhgeoiOIblWE1xdvxIwmExGVxGhWsoNtABg4BcyTyDb Qi8KRS5/YB68M8CALZ7jJ5hPNgBm66YVEgFna1zEolT/div8lLQoN28PZvWGDK6Yajqb pp0OODgcDSslQLHBRnTrjONTtAXzTvL/Ion+2mfmxGC7yRKFzxp8XEAzMJlo25T2EByN g/9w== 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=/TAZkQxNrDKoLx3z8PvajXe3hG/4hF5GHpnt4HaSjZE=; b=WWBl8dASzS2pL9Uvn4hn2G538wT/yc8ZGMZKJol8N5kiOrHzV3QHrBXzpmUN1+0YjZ cCyMbxT1E9PSYGNB9S2PvhowQiqSX2k3IOa4GwZmVdvTTWGtaeV2algqS2YcOXM9hd2f g3e7+2AijA7cEbU/wXb3aFgBUnfkW+gEdSKtQfYBV+86WRaWZ0i/MGTFhcIx+yqAoLP0 yotZXnLUEEQa/9WjdWbsR/FoFS/Oncoci8u2qOnM8gULHA+cYIhPXJwpMLfF+MsZSK25 RqIPiKGkKipEG9tM3lZzCxi3a/lig8eiaKUe0GXbuZZC1X03AYy8QganCz0CIFPqh/0p w+VQ== X-Gm-Message-State: AOAM531ThleczCTqYTf7E2YKVRUclVayAiGMFNPCOQpfLEUNrTpcZXeT e7Ic/RZw8bgUZsjRLhH0vTh1zHzusLTkoy5qdV27eg== X-Google-Smtp-Source: ABdhPJwMb5rLXP2BVr6ia/Wk63tl9/ZbaHXf2nf/lYBAOr5OFJ0UNrEbf6cCXBtQ49rU6E6XfLwurJSsWzdob68rdc4= X-Received: by 2002:a2e:b619:: with SMTP id r25mr3872488ljn.220.1597169428000; Tue, 11 Aug 2020 11:10:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Tue, 11 Aug 2020 11:10:17 -0700 Message-ID: To: Qin Wu Cc: Kent Watsen , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000670a7705ac9dfc7b" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 18:10:33 -0000 --000000000000670a7705ac9dfc7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 10, 2020 at 7:09 PM Qin Wu wrote: > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* netconf [mailto:netconf-bounces@ietf.org] = *=E4=BB=A3=E8=A1=A8 *Andy Bierman > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2020=E5=B9=B48=E6=9C=8811=E6=97= =A5 3:39 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Kent Watsen > *=E6=8A=84=E9=80=81:* netconf@ietf.org > *=E4=B8=BB=E9=A2=98:* Re: [netconf] Adoption-suitability for > draft-tao-netconf-data-export-capabilities > > > > Hi, > > > > I am trying to understand the problem this draft is attempting to solve. > > The premise seems to be that the error handling and "hints" mechanism > > in RFC 8639 and RFC 8641 do not work > > [Qin]: The data export capabilities is not designed to replace error > handling and is positioned as capability negotiation and used before > netconf connection to be setup, they are complementary, > > error handling will be the last resort > > When dynamic subscription request is declined or rejected. Error handling > is only applicable to dynamic subscription > > based on section 3.2 of RFC8641. > > > > Our argument is why not prevent the problem to happen in the first place > instead of waiting for the server making mistake and remedy it. > > One of principle set by RFC8641 is: > > minimize the number of subscription iterations between subscriber and > publisher, discourage Random guessing of different parameters by a > subscriber. > > > > The solution being provided is generic, targeted to address this > challenge, not only applicable to dynamic subscription, but also configur= ed > subscription. > > IMO the solution approach does not scale well. There is very little value for too much complexity. A set of capabilities for every possible data node that can be used with YANG Push will be very large. Any yet, that is still mostly useless, since it is very likely that the particular instances of the data node affect the push capabilities. The filter used in the subscription will have a huge impact on the capabilities. Take the most obvious entry -- for the "interface" list. It is very likely that the type of interface, or firmware revision of the line card, or any of a 1000 proprietary details could change the push parameters supported for that interface. There are also very vendor-specific capabilities that impose an implementation design. This is way out of scope. Example below: Does this mean all vendors need to change their server code so it has a set limit per update, based on some new concept you made up called sensor groups?? leaf max-nodes-per-sensor-group { type uint32 { range "1..max"; } description "Maximum number of selected data nodes that can be sent per sensor group."; } leaf max-sensor-group-per-update { type uint32 { range "1..max"; } description "Maximum number of sensor groups that can be sent in an update."; } Andy > > and the client needs to retrieve > > extensive monitoring info to determine how to setup notifications on the > server. > > > > In theory this data could be used to prevent an to be returne= d > > for or > > > > > > IMO the current approach is much better than this proposed approach. > > The server can provide the hints based on the exact request from the > client. > > [Qin]: It may be late, still require multiple subscription iterations > between subscriber and publisher. But data export has no intention to > replace it. Error handling have its value in many different cases. > > The static "per-node" monitoring data can be quite large, and yet not > provide > > the correct answer for a specific combination of subscription parameters.= . > > > > [Qin]: It is server capability exposure, check early implantation time > information of the capability what the server support (e.g., GRPC > transport, TCP support, UDP transport support), > > not targeted to keep track of dynamic change data. > > These capabilities seldom change. In addition, to allow the client compos= e > various different subscription policy (e.g., adaptive subscription), we > require the server to indicate whether specific data object supports > > Thresholds handling. > > This is missing pieces to support event based telemetry solution. > > > > Andy > > > > > > On Wed, Aug 5, 2020 at 3:17 PM Kent Watsen > wrote: > > > > NETCONF WG, > > Per the previous email sent moments ago, the chairs would like to solicit > input on the following draft: > > > > Title: Telemetry Data Export capability > > Link: https://tools.ietf.org/html/ > draft-tao-netconf-data-export-capabilities > Abstract: > > This document proposes a YANG module for telemetry data export > > capability which augments system Capabilities model and provides > > additional telemetry data export attributes associated with system > > capability for transport dependent capability negotiation. > > > > > In particular, please discuss adoption-suitability as it regards to the > following questions: > > > > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? > > > > PS: this message is itself not an adoption poll, but rather an attempt to > gauge interest/support for a potential future adoption poll. > > NETCONF Chairs > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --000000000000670a7705ac9dfc7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 10, 2020 at 7:09 PM Qin W= u <bill.wu@huawei.com> wrot= e:

=E5=8F=91=E4=BB=B6=E4=BA=BA: netconf = [mailto:netco= nf-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Andy Bierman
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B48=E6=9C=8811=E6=97=A5 3:39
=E6=94=B6=E4=BB=B6=E4=BA=BA: Kent Watsen <kent+ietf@watsen.net>
=E6=8A=84=E9=80=81: netconf@ietf.= org
=E4=B8=BB=E9=A2=98: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-expor= t-capabilities

=C2=A0

Hi,

=C2=A0

I am trying to understand the p= roblem this draft is attempting to solve.

The premise seems to be that th= e error handling and "hints" mechanism=C2=A0=

in RFC 8639 and RFC 8641 do not= work

[Qin]: The data export capa= bilities is not designed to replace error handling and is positioned as cap= ability negotiation and used before netconf connection to be setup, =C2=A0they are complementary,

error handling will be the = last resort

When dynamic subscription r= equest is declined or rejected. Error handling is only applicable to dynami= c subscription

based on section 3.2 of RFC= 8641.

=C2=A0=

Our argument is why not pre= vent the problem to happen in the first place instead of waiting for the se= rver making mistake and remedy it.

One of principle set by RFC= 8641 is:

minimize the number of subs= cription iterations between subscriber and publisher, discourage Random gue= ssing of different parameters by a subscriber.

=C2=A0=

The solution being provided= is generic, targeted to address this challenge, not only applicable to dyn= amic subscription, but also configured subscription.



IMO the solu= tion approach does not scale well.
There is very little value for= too much complexity.

A set of capabilities for ev= ery possible data node that can be used with YANG Push
will be ve= ry large. Any yet, that is still mostly useless, since it is very likely th= at
the particular instances of the data node affect the push capa= bilities.
The filter used in the subscription will have a huge im= pact on the capabilities.

Take the most obvious en= try -- for the "interface" list.=C2=A0 It is very likely that the=
type of interface, or firmware revision of the line card, or any= of a 1000 proprietary
details could change the push parameters s= upported for that interface.
=C2=A0
There are also very= vendor-specific capabilities that impose an implementation design.
This is way out of scope. Example below: Does this mean all vendors need= to change their server code
so it has a set limit per update, ba= sed on some new concept you made up called sensor groups??


     leaf max-nodes-per-sensor-group {
        type uint32 {
          range "1..max";
        }
        description
          "Maximum number of selected data nodes that can be sent
           per sensor group.";
      }
      leaf max-sensor-group-per-update {
        type uint32 {
          range "1..max";
        }
        description
          "Maximum number of sensor groups that can be sent
           in an update.";
      }


Andy


<= div>

=C2=A0

and the client needs to retriev= e

extensive monitoring info to de= termine how to setup notifications on the server.

=C2=A0=

In theory this data could be us= ed to prevent an <rpc-error> to be returned

for <establish_subscription&= gt; or <edit-config>

= =C2=A0

=C2=A0=

IMO the current approach is muc= h better than this proposed approach.

The server can provide the hint= s based on the exact request from the client.

[Qin]: It may be late, stil= l require multiple subscription iterations between subscriber and publisher= . But data export has no intention to replace it. Error handling have its value in many different cases.

The static "per-node"= monitoring data can be quite large, and yet not provide

the correct answer for a specif= ic combination of subscription parameters..

=C2=A0

[Qin]: It is server capabil= ity exposure, check early implantation time information of the capability w= hat the server support (e.g., GRPC transport, TCP support, UDP transport support),

not targeted to keep track = of dynamic change data.

These capabilities seldom c= hange. In addition, to allow the client compose various different subscript= ion policy (e.g., adaptive subscription), we require the server to indicate whether specific data object supports

Thresholds handling.=

This is missing pieces to s= upport event based telemetry solution.

=C2=A0

Andy

=C2=A0

=C2=A0

On Wed, Aug 5, 2020 at 3:17 PM = Kent Watsen <kent+ietf@watsen.net> wrote:

=C2=A0

NETCONF W= G,

Per the previous email sent moments ago, the chairs would like to solicit i= nput on the following draft:

= =C2=A0

=C2=A0 = =C2=A0Title:=C2=A0Telemetry Data Export capability

=C2=A0 =C2=A0Link: https://tools.ie= tf.org/html/draft-tao-netconf-data-export-capabilities
=C2=A0 =C2=A0Abstract:

=C2=A0 = =C2=A0 =C2=A0 This document proposes a YANG module for telemetry data expor= t

=C2=A0 = =C2=A0 =C2=A0 capability which augments system Capabilities model and provi= des

=C2=A0 = =C2=A0 =C2=A0 additional telemetry data export attributes associated with s= ystem

=C2=A0 = =C2=A0 =C2=A0 capability for transport dependent capability negotiation.

=C2=A0


In particular, please discuss adoption-suitability as it regards to the fol= lowing questions:

= =C2=A0

=C2=A0 = =C2=A0 1) is the problem important for the NETCONF WG to solve?
=C2=A0 =C2=A0 2) is the draft a suitable basis for the work?<= /span>



PS: this message is itself not an adoption poll, but rather an attempt to g= auge interest/support for a potential future adoption poll.

NETCONF Chairs

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

--000000000000670a7705ac9dfc7b-- From nobody Tue Aug 11 20:44:07 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47EC3A07C8 for ; Tue, 11 Aug 2020 20:44:05 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.395 X-Spam-Level: X-Spam-Status: No, score=0.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=1.5, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=foxmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZhyk68c4313 for ; Tue, 11 Aug 2020 20:44:00 -0700 (PDT) Received: from qq.com (out203-205-221-146.mail.qq.com [203.205.221.146]) (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 C9F9D3A0EDD for ; Tue, 11 Aug 2020 20:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1597203811; bh=fAKuRYmxAuBbDKOvZBirHDVeTW2mc7t4bWWlnqJe/x4=; h=Date:From:To:Cc:Subject:References; b=eUeOV4I1MM/t+53w8fXDXyrlt9eCuzTubeZ+lfhMap5BUuz539/rHIL4UyFTfGTLC 6muuPEiafmUA+DVMqrOeSHKL3H+A1l1B3gv+iUFy1wN2nuJaDo7mvDDF/rmuzxJB1F 4cyHEl9rwqmqujU7dWdLXw7NKDiIFs6KoLTiC7ZI= Received: from cmcc-PC ([221.130.253.135]) by newxmesmtplogicsvrszc9.qq.com (NewEsmtp) with SMTP id ADCAD26B; Wed, 12 Aug 2020 11:43:28 +0800 X-QQ-mid: xmsmtpt1597203808twnhjbw6w Message-ID: X-QQ-XMAILINFO: OJmJwEl4zPMRAdu/gW34UUowwZmHX6CS3ygP142/f+0ed9nELTuCLO7shr0PVD LYsQ2gkUzcDXoXQmyjDSKoRHboMGbiOtDgTri01b9ypnaYbKLmPn8F8d1n7n3aBA4s01NyHU86C9 Gdx2glWO5fL5Ufuuwz70FoT8lVxaXBZvWIbucnM/TkO7sYwis5/iR8H318WaB8GGpM59OnH5eoXx 58cysqLA80jeWcjtDW1KEJI+2oLPKqLMWtgEjCSZOXiFQJuDO2EbV3KxLhk1LAM5rKmKXg9RpTj5 p/Oygd2ZPW3uaXUtv0V5krBfDabQTpbKMKMIe7WLQStrVbLPRXT+WvzzSMr9HIy8QevMMg4LwQ6/ w8h7yizphHZnYmxxdPYwETV+6sbfeYpd57uEUzemEXXnt1xS6rdNEtMhsXEpLYYUuAJeltSu6u/a ZouGOIHrCXoA0XdTt1odizuZti37qfQPR7zQiRaKklM+dvoscll/yMTBngaQgHUdkjJgcOCwRR2g VfJ5obnHBl+NbCyubQK/qBAxbhfwpdRXBKF7QV4Clrox1o28j2ranq3xJ0ddACz5d9zeW5YguEFq gR2ymhvuskMhn9S9MsMhm1iZNgPVEp9oZcBjUBANhA7UCupzUftsv7jmvmMplLkHXCEwTyn8X9eH aj7PBLv3XKn8c/XMsl/wos0hBTK3sDb7RxkCyyApxe6z5h9r2iT8WV81bXg84C11CApVk0BaCgyZ U4hZaw1+BFPai24QKgTE0hqkrVyZmjeG04 Date: Wed, 12 Aug 2020 11:45:42 +0800 From: "duzongpeng@foxmail.com" To: "Kent Watsen" , "netconf@ietf.org" Cc: duzongpeng References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.16.188[cn] Mime-Version: 1.0 Message-ID: <2020081211454128151826@foxmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart761000025715_=----" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 03:44:06 -0000 This is a multi-part message in MIME format. ------=_001_NextPart761000025715_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGkgV0csDQoNCldpdGggcmVnYXJkIHRvIHRoZSAyIHF1ZXN0aW9uczoNCg0KICAgIDEpIGlzIHRo ZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cgdG8gc29sdmU/DQoNCkkgdGhp bmsgdGhlIFVEUCB0cmFuc3BvcnQgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIGlzIHZhbHVh YmxlIGZvciB0aGUgTkVUQ09ORiBXRy4gSXQncyB1c2VmdWwgaW4gYXQgbGVhc3QgdHdvIHNjZW5h cmlvcyBpbiBjYXJyaWVyIG5ldHdvcmsuDQpPbmUgaXMgZm9yIGNvcmUgZGV2aWNlcyB3aXRoIGxh cmdlIGFtb3VudCBvZiBkYXRhIHRvIGV4cG9ydC4gVGhlIFVEUCB0cmFuc3BvcnQgdG9nZXRoZXIg d2l0aCBkaXN0cmlidXRlZCBleHBvcnRpbmcgbWVjaGFuaXNtIGNvdWxkIHJlbGlldmUgdGhlIGRl dmljZSB3b3JrIGxvYWQuDQpUaGUgc2Vjb25kIGlzIHdoZW4gdGhlIGNvbGxlY3RvciB3YW50IHRv IGNvbGxlY3QgZGF0YSBmcm9tIGxhcmdlIGFtb3VudCBvZiBkZXZpY2VzLCBlLmcuLCB0aGUgZGV2 aWNlcyBhdCB0aGUgZWRnZS4gVGhlIHByb3Bvc2VkIHNvbHV0aW9uIGNhbiBtYWtlIHRoZSBjb2xs ZWN0b3IncyBsaWZlIGVhc2llci4NCg0KICAgIDIpIGlzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJh c2lzIGZvciB0aGUgd29yaz8NCg0KSSd2ZSByZWFkIGRvY3VtZW50LiBJIGJlbGlldmUgaXQncyBh IGdvb2QgYmFzaXMgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIGNvbnRpbnVlLg0KDQoNCg0KDQpk dXpvbmdwZW5nQGZveG1haWwuY29tICYgZHV6b25ncGVuZ0BjaGluYW1vYmlsZS5jb20NCiANCkZy b206IEtlbnQgV2F0c2VuDQpEYXRlOiAyMDIwLTA4LTA2IDA2OjE0DQpUbzogbmV0Y29uZkBpZXRm Lm9yZw0KU3ViamVjdDogW25ldGNvbmZdIEFkb3B0aW9uLXN1aXRhYmlsaXR5IGZvciBkcmFmdC11 bnl0ZS1uZXRjb25mLXVkcC1ub3RpZg0KTkVUQ09ORiBXRywNCiANClBlciB0aGUgcHJldmlvdXMg ZW1haWwgc2VudCBtb21lbnRzIGFnbywgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIHNvbGljaXQg aW5wdXQgb24gdGhlIGZvbGxvd2luZyBkcmFmdDoNCiANCiAgIFRpdGxlOiBVRFAtYmFzZWQgVHJh bnNwb3J0IGZvciBDb25maWd1cmVkIFN1YnNjcmlwdGlvbnMNCiAgIExpbms6IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC11bnl0ZS1uZXRjb25mLXVkcC1ub3RpZg0KICAgQWJzdHJh Y3Q6DQogDQogICAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBVRFAtYmFzZWQgbm90aWZp Y2F0aW9uIG1lY2hhbmlzbSB0bw0KICAgICAgY29sbGVjdCBkYXRhIGZyb20gbmV0d29ya2luZyBk ZXZpY2VzLiAgQSBzaGltIGhlYWRlciBpcyBwcm9wb3NlZCB0bw0KICAgICAgZmFjaWxpdGF0ZSB0 aGUgc3RyZWFtaW5nIG9mIGRhdGEgZGlyZWN0bHkgZnJvbSBsaW5lIGNhcmRzIHRvIGENCiAgICAg IGNvbGxlY3Rvci4gIFRoZSBvYmplY3RpdmUgaXMgdG8gcmVseSBvbiBhIGxpZ2h0d2VpZ2h0IGFw cHJvYWNoIHRvDQogICAgICBhbGxvdyBmb3IgaGlnaGVyIGZyZXF1ZW5jeSBhbmQgYmV0dGVyIHRy YW5zaXQgcGVyZm9ybWFuY2UgY29tcGFyZWQgdG8NCiAgICAgIGFscmVhZHkgZXN0YWJsaXNoZWQg bm90aWZpY2F0aW9uIG1lY2hhbmlzbXMuDQogDQogDQpJbiBwYXJ0aWN1bGFyLCBwbGVhc2UgZGlz Y3VzcyBhZG9wdGlvbi1zdWl0YWJpbGl0eSBhcyBpdCByZWdhcmRzIHRvIHRoZSBmb2xsb3dpbmcg cXVlc3Rpb25zOg0KIA0KICAgIDEpIGlzIHRoZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5F VENPTkYgV0cgdG8gc29sdmU/DQogICAgMikgaXMgdGhlIGRyYWZ0IGEgc3VpdGFibGUgYmFzaXMg Zm9yIHRoZSB3b3JrPw0KIA0KIA0KUFM6IHRoaXMgbWVzc2FnZSBpcyBpdHNlbGYgbm90IGFuIGFk b3B0aW9uIHBvbGwsIGJ1dCByYXRoZXIgYW4gYXR0ZW1wdCB0byBnYXVnZSBpbnRlcmVzdC9zdXBw b3J0IGZvciBhIHBvdGVudGlhbCBmdXR1cmUgYWRvcHRpb24gcG9sbC4NCiANCk5FVENPTkYgQ2hh aXJzDQogDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K ------=_001_NextPart761000025715_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable = =0A
Hi WG,
 
With rega= rd to the 2 questions for this draft: 
    1) is the problem = important for the NETCONF WG to solve?
&n= bsp;
I think it=E2=80=99s valuable for the&nbs= p;WG to solve. As mentioned in the othe= r mail, for core devices with large amo= unt of data to export,  distributed exp= orting mechanism could relieve the device wo= rk load.
Directly export from the line ca= rds can avoid the bottle neck when expo= rting data from mainboard.
 
2) is the=  draft a suitable basis for the work? 
Yes. I=E2=80=99ve read this document = and think it=E2=80=99s a good basis for = ;the work.
=0A

=0A
duzongpeng@foxmail.com & duzongpe= ng@chinamobile.com
=0A
 
Fro= m: Kent Watsen
<= div>Date: 2020-08-06 06:14
Subject:=  [netconf] Adoption-suitability for draft-unyte-netconf-distribut= ed-notif
= =0ANETCONF WG,
=0A
=0APer the previous email sent moments ago, the = chairs would like to solicit input on the following draft:=0A

=0A
=0A
   Title:&nb= sp;Subscription to Distributed Notifications=0A
   Link:=0A=0Ahttps://tools.iet= f.org/html/draft-unyte-netconf-distributed-notif
=0A   Abstract:
=0A
=0A
=      = This documents describes extensions to the YANG notifications
=0A
      subscripti= on to allow metrics being published directly from
=0A      processors on line cards= to target receivers, while subscription is
=0A
      still maintained at the route = processor in a distributed forwarding
=0A
      system.
=0A=0A

=0A
=0A
=0AIn particular, pl= ease discuss adoption-suitability as it regards to the following questions= :
=0A

=0A
=0A
    1) is the= problem important for the NETCONF WG to solve?
=0A  &n= bsp; 2) is the draft a suitable basis for the work?
=0A

=0A
=0APS: this message is itself not an adoption poll, but= rather an attempt to gauge interest/support for a potential future adopti= on poll.
=0A
=0ANETCONF Chairs
= =0A
=0A
=0A
=0A ------=_001_NextPart554416480187_=------ . From nobody Tue Aug 11 21:10:42 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240F13A0F1A for ; Tue, 11 Aug 2020 21:10: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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJiThfQqH2vh for ; Tue, 11 Aug 2020 21:10: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 775C13A0F0F for ; Tue, 11 Aug 2020 21:10:37 -0700 (PDT) Received: from lhreml709-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id EAB77F3AD646C33FEDA9 for ; Wed, 12 Aug 2020 05:10:32 +0100 (IST) Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 12 Aug 2020 05:10:32 +0100 Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Wed, 12 Aug 2020 05:10:32 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.234]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Wed, 12 Aug 2020 12:10:28 +0800 From: Qin Wu To: Andy Bierman CC: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities Thread-Index: AdZwV1YcWPgLrGpwQAqxiw25SWb4Pw== Date: Wed, 12 Aug 2020 04:10:28 +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.164.150.232] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD900F4Bdggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 04:10:40 -0000 --_000_B8F9A780D330094D99AF023C5877DABAAD900F4Bdggeml511mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 5Y+R5Lu25Lq6OiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQrlj5Hp gIHml7bpl7Q6IDIwMjDlubQ45pyIMTLml6UgMjoxMA0K5pS25Lu25Lq6OiBRaW4gV3UgPGJpbGwu d3VAaHVhd2VpLmNvbT4NCuaKhOmAgTogS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0 PjsgbmV0Y29uZkBpZXRmLm9yZw0K5Li76aKYOiBSZTogW25ldGNvbmZdIEFkb3B0aW9uLXN1aXRh YmlsaXR5IGZvciBkcmFmdC10YW8tbmV0Y29uZi1kYXRhLWV4cG9ydC1jYXBhYmlsaXRpZXMNCg0K DQoNCk9uIE1vbiwgQXVnIDEwLCAyMDIwIGF0IDc6MDkgUE0gUWluIFd1IDxiaWxsLnd1QGh1YXdl aS5jb208bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4+IHdyb3RlOg0K5Y+R5Lu25Lq6OiBuZXRj b25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5j ZXNAaWV0Zi5vcmc+XSDku6PooaggQW5keSBCaWVybWFuDQrlj5HpgIHml7bpl7Q6IDIwMjDlubQ4 5pyIMTHml6UgMzozOQ0K5pS25Lu25Lq6OiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5u ZXQ8bWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5uZXQ+Pg0K5oqE6YCBOiBuZXRjb25mQGlldGYu b3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0K5Li76aKYOiBSZTogW25ldGNvbmZdIEFkb3B0 aW9uLXN1aXRhYmlsaXR5IGZvciBkcmFmdC10YW8tbmV0Y29uZi1kYXRhLWV4cG9ydC1jYXBhYmls aXRpZXMNCg0KSGksDQoNCkkgYW0gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0gdGhp cyBkcmFmdCBpcyBhdHRlbXB0aW5nIHRvIHNvbHZlLg0KVGhlIHByZW1pc2Ugc2VlbXMgdG8gYmUg dGhhdCB0aGUgZXJyb3IgaGFuZGxpbmcgYW5kICJoaW50cyIgbWVjaGFuaXNtDQppbiBSRkMgODYz OSBhbmQgUkZDIDg2NDEgZG8gbm90IHdvcmsNCltRaW5dOiBUaGUgZGF0YSBleHBvcnQgY2FwYWJp bGl0aWVzIGlzIG5vdCBkZXNpZ25lZCB0byByZXBsYWNlIGVycm9yIGhhbmRsaW5nIGFuZCBpcyBw b3NpdGlvbmVkIGFzIGNhcGFiaWxpdHkgbmVnb3RpYXRpb24gYW5kIHVzZWQgYmVmb3JlIG5ldGNv bmYgY29ubmVjdGlvbiB0byBiZSBzZXR1cCwgIHRoZXkgYXJlIGNvbXBsZW1lbnRhcnksDQplcnJv ciBoYW5kbGluZyB3aWxsIGJlIHRoZSBsYXN0IHJlc29ydA0KV2hlbiBkeW5hbWljIHN1YnNjcmlw dGlvbiByZXF1ZXN0IGlzIGRlY2xpbmVkIG9yIHJlamVjdGVkLiBFcnJvciBoYW5kbGluZyBpcyBv bmx5IGFwcGxpY2FibGUgdG8gZHluYW1pYyBzdWJzY3JpcHRpb24NCmJhc2VkIG9uIHNlY3Rpb24g My4yIG9mIFJGQzg2NDEuDQoNCk91ciBhcmd1bWVudCBpcyB3aHkgbm90IHByZXZlbnQgdGhlIHBy b2JsZW0gdG8gaGFwcGVuIGluIHRoZSBmaXJzdCBwbGFjZSBpbnN0ZWFkIG9mIHdhaXRpbmcgZm9y IHRoZSBzZXJ2ZXIgbWFraW5nIG1pc3Rha2UgYW5kIHJlbWVkeSBpdC4NCk9uZSBvZiBwcmluY2lw bGUgc2V0IGJ5IFJGQzg2NDEgaXM6DQptaW5pbWl6ZSB0aGUgbnVtYmVyIG9mIHN1YnNjcmlwdGlv biBpdGVyYXRpb25zIGJldHdlZW4gc3Vic2NyaWJlciBhbmQgcHVibGlzaGVyLCBkaXNjb3VyYWdl IFJhbmRvbSBndWVzc2luZyBvZiBkaWZmZXJlbnQgcGFyYW1ldGVycyBieSBhIHN1YnNjcmliZXIu DQoNClRoZSBzb2x1dGlvbiBiZWluZyBwcm92aWRlZCBpcyBnZW5lcmljLCB0YXJnZXRlZCB0byBh ZGRyZXNzIHRoaXMgY2hhbGxlbmdlLCBub3Qgb25seSBhcHBsaWNhYmxlIHRvIGR5bmFtaWMgc3Vi c2NyaXB0aW9uLCBidXQgYWxzbyBjb25maWd1cmVkIHN1YnNjcmlwdGlvbi4NCg0KDQpJTU8gdGhl IHNvbHV0aW9uIGFwcHJvYWNoIGRvZXMgbm90IHNjYWxlIHdlbGwuDQpUaGVyZSBpcyB2ZXJ5IGxp dHRsZSB2YWx1ZSBmb3IgdG9vIG11Y2ggY29tcGxleGl0eS4NCg0KW1Fpbl06IEkgcmVzcGVjdGZ1 bGx5IGRpc2FncmVlLCA7LSksZXJyb3IgaGFuZGxpbmcgZG9lc27igJl0IHByb3ZpZGUgdGhlIGNs aWVudCBhbnkgaGludCBhYm91dCB3aGljaCB0cmFuc3BvcnQgcHJvdG9jb2wsIHdoaWNoIHNlY3Vy aXR5IHNjaGVtZXMgeW91IHNob3VsZCB1c2UuDQpXZSBzZWUgZHJhZnQtaWV0Zi1uZXRjb25mLW5v dGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMTMgcHJvdmlkZXMgc2VydmVyIGNhcGFiaWxpdHkgYWR2 ZXJ0aXNlbWVudCB3aGljaCBzZXJ2ZSBhcyBhIGdvb2QgYmFzaXMgZm9yIHRoaXMgZHJhZnQgYW5k IGNhbiBiZSB1c2VkIG5vdCBvbmx5IGF0IGltcGxlbWVudGF0aW9uIHRpbWUgYnV0IGFsc28gcnVu IHRpbWUuDQpXZSBhbHNvIHNlZSBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYtMDQgcHJv dmlkZXMgUmVjZWl2ZXIgQ2FwYWJpbGl0aWVzIGxlYXJuaW5nLg0KDQpJIGFsc28gcmVtZW1iZXIg bm90aWZpY2F0aW9uIGNhcGFiaWxpdHkgbW9kZWwgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLW5ldGNv bmYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGllcy0xMyBoYXMgYmVlbiByZWZhY3RvcmVkIHRvIG1h a2UgaXQgbW9yZSBnZW5lcmljIG1vdGl2YXRlZCBieSBzb21lIG5ldyBjYXBhYmlsaXR5IGRyYWZ0 cyBhbmQgdGhlcmVmb3JlIGNhbiBiZSB1c2VkIHRvIGFjY29tbW9kYXRlDQpPdGhlciBjYXBhYmls aXRpZXMgZXh0ZW5zaW9uLiBUaGlzIGhlbHBzIHByb3ZpZGUgdGVsZW1ldHJ5IGF1dG9tYXRpb24g c29sdXRpb24uDQoNCkEgc2V0IG9mIGNhcGFiaWxpdGllcyBmb3IgZXZlcnkgcG9zc2libGUgZGF0 YSBub2RlIHRoYXQgY2FuIGJlIHVzZWQgd2l0aCBZQU5HIFB1c2gNCndpbGwgYmUgdmVyeSBsYXJn ZS4gQW55IHlldCwgdGhhdCBpcyBzdGlsbCBtb3N0bHkgdXNlbGVzcywgc2luY2UgaXQgaXMgdmVy eSBsaWtlbHkgdGhhdA0KdGhlIHBhcnRpY3VsYXIgaW5zdGFuY2VzIG9mIHRoZSBkYXRhIG5vZGUg YWZmZWN0IHRoZSBwdXNoIGNhcGFiaWxpdGllcy4NClRoZSBmaWx0ZXIgdXNlZCBpbiB0aGUgc3Vi c2NyaXB0aW9uIHdpbGwgaGF2ZSBhIGh1Z2UgaW1wYWN0IG9uIHRoZSBjYXBhYmlsaXRpZXMuDQoN Cg0KVGFrZSB0aGUgbW9zdCBvYnZpb3VzIGVudHJ5IC0tIGZvciB0aGUgImludGVyZmFjZSIgbGlz dC4gIEl0IGlzIHZlcnkgbGlrZWx5IHRoYXQgdGhlDQp0eXBlIG9mIGludGVyZmFjZSwgb3IgZmly bXdhcmUgcmV2aXNpb24gb2YgdGhlIGxpbmUgY2FyZCwgb3IgYW55IG9mIGEgMTAwMCBwcm9wcmll dGFyeQ0KZGV0YWlscyBjb3VsZCBjaGFuZ2UgdGhlIHB1c2ggcGFyYW1ldGVycyBzdXBwb3J0ZWQg Zm9yIHRoYXQgaW50ZXJmYWNlLg0KDQpbUWluXTogSW4gcmVhbGl0eSwgd2UgY2FuIG5vdCBhc3N1 bWUgYWxsIGRhdGEgb2JqZWN0cyBkZWZpbmVkIGluIHRoZSBZQU5HIGRhdGEgbW9kZWxzIHN1cHBv cnQgdGhyZXNob2xkIGhhbmRsaW5nIGNhcGFiaWxpdHkNCmUuZy4sIG9ubHkgaW50ZWdlciBidWls dC1pbiB0eXBlIGRhdGEgb2JqZWN0IHN1cHBvcnQgdGhyZXNob2xkIGhhbmRsaW5nLA0KYW5vdGhl ciBleGFtcGxlcywgd2UgbWF5IG5lZWQgdG8gc3VwcHJlc3MgcmVkdW5kYW50IGRhdGEgdmFsdWUg cmVwb3J0aW5nLCBzbyB3ZSBtYXkgaW5kaWNhdGUgdG8gdGhlIGNsaWVudCB3aGljaCBzZXQgb2Yg ZGF0YSBvYmplY3QgaGFzIHJlZHVuZGFudCBzdXBwcmVzcyBjYXBhYmlsaXR5Lg0KRm9yIHNvbWUg ZGF0YSBvYmplY3QsIHRoZXkgbWF5IHN1cHBvcnQgdGltZXIgYmFzZWQgdHJpZ2dlciwgd2UgYWxz byBuZWVkIHRvIGluZGljYXRlIHRoZW0gdG8gdGhlIGNsaWVudC4NCg0KVGhlcmUgYXJlIGFsc28g dmVyeSB2ZW5kb3Itc3BlY2lmaWMgY2FwYWJpbGl0aWVzIHRoYXQgaW1wb3NlIGFuIGltcGxlbWVu dGF0aW9uIGRlc2lnbi4NClRoaXMgaXMgd2F5IG91dCBvZiBzY29wZS4gRXhhbXBsZSBiZWxvdzog RG9lcyB0aGlzIG1lYW4gYWxsIHZlbmRvcnMgbmVlZCB0byBjaGFuZ2UgdGhlaXIgc2VydmVyIGNv ZGUNCnNvIGl0IGhhcyBhIHNldCBsaW1pdCBwZXIgdXBkYXRlLCBiYXNlZCBvbiBzb21lIG5ldyBj b25jZXB0IHlvdSBtYWRlIHVwIGNhbGxlZCBzZW5zb3IgZ3JvdXBzPz8NCg0KDQpbUWluXTogVGhl c2UgdHdvIHBhcmFtZXRlcnMgYXJlIGRlYmF0YWJsZSwgU2ltaWxhciB0byBtYXgtbm9kZXMtcGVy LXVwZGF0ZSBkZWZpbmVkIGluIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJp bGl0aWVzLTEzOg0KbWF4LW5vZGVzLXBlci1zZW5zb3ItZ3JvdXAgYW5kIG1heC1zZW5zb3ItZ3Jv dXAtcGVyLXVwZGF0ZSBhcmUgdHdvIG9wdGlvbmFsIHBhcmFtZXRlcnMuIFRoZSByZWFzb24gdG8g aW50cm9kdWNlIHRoZXNlIHR3byBwYXJhbWV0ZXJzIGlzDQp0byBhbGlnbiB3aXRoIGdOTUkgaW1w bGVtZW50YXRpb24sIHdoaWNoIGhhcyBzZW5zb3IgZ3JvdXAgY29uY2VwdCwgd2UgdGhpbmsgaXQg aXMgdXNlZnVsLCB0aGF04oCZcyB3aHkgd2UgYWRkIHRoZW0uDQpCdXQgdGhleSBjYW4gYmUgdGFr ZW4gb3V0IGlmIHRoZXkgaW50cm9kdWNlIGNvbXBsZXhpdHkuDQoNCg0KICAgICBsZWFmIG1heC1u b2Rlcy1wZXItc2Vuc29yLWdyb3VwIHsNCg0KICAgICAgICB0eXBlIHVpbnQzMiB7DQoNCiAgICAg ICAgICByYW5nZSAiMS4ubWF4IjsNCg0KICAgICAgICB9DQoNCiAgICAgICAgZGVzY3JpcHRpb24N Cg0KICAgICAgICAgICJNYXhpbXVtIG51bWJlciBvZiBzZWxlY3RlZCBkYXRhIG5vZGVzIHRoYXQg Y2FuIGJlIHNlbnQNCg0KICAgICAgICAgICBwZXIgc2Vuc29yIGdyb3VwLiI7DQoNCiAgICAgIH0N Cg0KICAgICAgbGVhZiBtYXgtc2Vuc29yLWdyb3VwLXBlci11cGRhdGUgew0KDQogICAgICAgIHR5 cGUgdWludDMyIHsNCg0KICAgICAgICAgIHJhbmdlICIxLi5tYXgiOw0KDQogICAgICAgIH0NCg0K ICAgICAgICBkZXNjcmlwdGlvbg0KDQogICAgICAgICAgIk1heGltdW0gbnVtYmVyIG9mIHNlbnNv ciBncm91cHMgdGhhdCBjYW4gYmUgc2VudA0KDQogICAgICAgICAgIGluIGFuIHVwZGF0ZS4iOw0K DQogICAgICB9DQoNCltRaW5dOldoYXQgZG8gd2UgZGVmaW5lIGZvciBtYXgtbm9kZXMtcGVyLXNl bnNvci1ncm91cCBhbmQgbWF4LXNlbnNvci1ncm91cC1wZXItdXBkYXRlLCBpcyBwZXIgc3lzdGVt IGNhcGFiaWxpdHksIG5vdCBwZXIgbm9kZSBjYXBhYmlsaXR5LiBZb3UgZG9u4oCZdCBuZWVkIHRv IGV4cGVjdCBlYWNoIG5vZGUgdG8gc3VwcG9ydCBzdWNoIGNhcGFiaWxpdHkuDQoNCkZvciBwZXIg bm9kZSBjYXBhYmlsaXR5LCB3ZSBvbmx5IGRlZmluZSB0aHJlZSBwYXJhbWV0ZXJzLCBjb3VudGVy IHRocmVzaG9sZCBzdXBwb3J0LCB0aW1lciBiYXNlZCB0cmlnZ2VyIHN1cHBvcnQgYW5kIHN1cHBy ZXNzIHJlZHVuZGFudCBzdXBwb3J0Lg0KV2hpY2ggaGVscCB5b3UgZGVzaWduIGFwcHJvcHJpYXRl IHN1YnNjcmlwdGlvbiBwb2xpY3kgYW5kIHNlbmQgaXQgdGhyb3VnaCBzdWJzY3JpcHRpb24gcmVx dWVzdC4NCg0KQW5keQ0KDQoNCg0KYW5kIHRoZSBjbGllbnQgbmVlZHMgdG8gcmV0cmlldmUNCmV4 dGVuc2l2ZSBtb25pdG9yaW5nIGluZm8gdG8gZGV0ZXJtaW5lIGhvdyB0byBzZXR1cCBub3RpZmlj YXRpb25zIG9uIHRoZSBzZXJ2ZXIuDQoNCkluIHRoZW9yeSB0aGlzIGRhdGEgY291bGQgYmUgdXNl ZCB0byBwcmV2ZW50IGFuIDxycGMtZXJyb3I+IHRvIGJlIHJldHVybmVkDQpmb3IgPGVzdGFibGlz aF9zdWJzY3JpcHRpb24+IG9yIDxlZGl0LWNvbmZpZz4NCg0KDQpJTU8gdGhlIGN1cnJlbnQgYXBw cm9hY2ggaXMgbXVjaCBiZXR0ZXIgdGhhbiB0aGlzIHByb3Bvc2VkIGFwcHJvYWNoLg0KVGhlIHNl cnZlciBjYW4gcHJvdmlkZSB0aGUgaGludHMgYmFzZWQgb24gdGhlIGV4YWN0IHJlcXVlc3QgZnJv bSB0aGUgY2xpZW50Lg0KW1Fpbl06IEl0IG1heSBiZSBsYXRlLCBzdGlsbCByZXF1aXJlIG11bHRp cGxlIHN1YnNjcmlwdGlvbiBpdGVyYXRpb25zIGJldHdlZW4gc3Vic2NyaWJlciBhbmQgcHVibGlz aGVyLiBCdXQgZGF0YSBleHBvcnQgaGFzIG5vIGludGVudGlvbiB0byByZXBsYWNlIGl0LiBFcnJv ciBoYW5kbGluZyBoYXZlIGl0cyB2YWx1ZSBpbiBtYW55IGRpZmZlcmVudCBjYXNlcy4NClRoZSBz dGF0aWMgInBlci1ub2RlIiBtb25pdG9yaW5nIGRhdGEgY2FuIGJlIHF1aXRlIGxhcmdlLCBhbmQg eWV0IG5vdCBwcm92aWRlDQp0aGUgY29ycmVjdCBhbnN3ZXIgZm9yIGEgc3BlY2lmaWMgY29tYmlu YXRpb24gb2Ygc3Vic2NyaXB0aW9uIHBhcmFtZXRlcnMuLg0KDQpbUWluXTogSXQgaXMgc2VydmVy IGNhcGFiaWxpdHkgZXhwb3N1cmUsIGNoZWNrIGVhcmx5IGltcGxhbnRhdGlvbiB0aW1lIGluZm9y bWF0aW9uIG9mIHRoZSBjYXBhYmlsaXR5IHdoYXQgdGhlIHNlcnZlciBzdXBwb3J0IChlLmcuLCBH UlBDIHRyYW5zcG9ydCwgVENQIHN1cHBvcnQsIFVEUCB0cmFuc3BvcnQgc3VwcG9ydCksDQpub3Qg dGFyZ2V0ZWQgdG8ga2VlcCB0cmFjayBvZiBkeW5hbWljIGNoYW5nZSBkYXRhLg0KVGhlc2UgY2Fw YWJpbGl0aWVzIHNlbGRvbSBjaGFuZ2UuIEluIGFkZGl0aW9uLCB0byBhbGxvdyB0aGUgY2xpZW50 IGNvbXBvc2UgdmFyaW91cyBkaWZmZXJlbnQgc3Vic2NyaXB0aW9uIHBvbGljeSAoZS5nLiwgYWRh cHRpdmUgc3Vic2NyaXB0aW9uKSwgd2UgcmVxdWlyZSB0aGUgc2VydmVyIHRvIGluZGljYXRlIHdo ZXRoZXIgc3BlY2lmaWMgZGF0YSBvYmplY3Qgc3VwcG9ydHMNClRocmVzaG9sZHMgaGFuZGxpbmcu DQpUaGlzIGlzIG1pc3NpbmcgcGllY2VzIHRvIHN1cHBvcnQgZXZlbnQgYmFzZWQgdGVsZW1ldHJ5 IHNvbHV0aW9uLg0KDQpBbmR5DQoNCg0KT24gV2VkLCBBdWcgNSwgMjAyMCBhdCAzOjE3IFBNIEtl bnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldDxtYWlsdG86a2VudCUyQmlldGZAd2F0c2Vu Li5uZXQ+PiB3cm90ZToNCg0KTkVUQ09ORiBXRywNCg0KUGVyIHRoZSBwcmV2aW91cyBlbWFpbCBz ZW50IG1vbWVudHMgYWdvLCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gc29saWNpdCBpbnB1dCBv biB0aGUgZm9sbG93aW5nIGRyYWZ0Og0KDQogICBUaXRsZTogVGVsZW1ldHJ5IERhdGEgRXhwb3J0 IGNhcGFiaWxpdHkNCiAgIExpbms6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10 YW8tbmV0Y29uZi1kYXRhLWV4cG9ydC1jYXBhYmlsaXRpZXMNCiAgIEFic3RyYWN0Og0KICAgICAg VGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIFlBTkcgbW9kdWxlIGZvciB0ZWxlbWV0cnkgZGF0YSBl eHBvcnQNCiAgICAgIGNhcGFiaWxpdHkgd2hpY2ggYXVnbWVudHMgc3lzdGVtIENhcGFiaWxpdGll cyBtb2RlbCBhbmQgcHJvdmlkZXMNCiAgICAgIGFkZGl0aW9uYWwgdGVsZW1ldHJ5IGRhdGEgZXhw b3J0IGF0dHJpYnV0ZXMgYXNzb2NpYXRlZCB3aXRoIHN5c3RlbQ0KICAgICAgY2FwYWJpbGl0eSBm b3IgdHJhbnNwb3J0IGRlcGVuZGVudCBjYXBhYmlsaXR5IG5lZ290aWF0aW9uLg0KDQoNCkluIHBh cnRpY3VsYXIsIHBsZWFzZSBkaXNjdXNzIGFkb3B0aW9uLXN1aXRhYmlsaXR5IGFzIGl0IHJlZ2Fy ZHMgdG8gdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6DQoNCiAgICAxKSBpcyB0aGUgcHJvYmxlbSBp bXBvcnRhbnQgZm9yIHRoZSBORVRDT05GIFdHIHRvIHNvbHZlPw0KICAgIDIpIGlzIHRoZSBkcmFm dCBhIHN1aXRhYmxlIGJhc2lzIGZvciB0aGUgd29yaz8NCg0KDQpQUzogdGhpcyBtZXNzYWdlIGlz IGl0c2VsZiBub3QgYW4gYWRvcHRpb24gcG9sbCwgYnV0IHJhdGhlciBhbiBhdHRlbXB0IHRvIGdh dWdlIGludGVyZXN0L3N1cHBvcnQgZm9yIGEgcG90ZW50aWFsIGZ1dHVyZSBhZG9wdGlvbiBwb2xs Lg0KDQpORVRDT05GIENoYWlycw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm5ldGNvbmYgbWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYub3JnPG1haWx0 bzpuZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mDQo= --_000_B8F9A780D330094D99AF023C5877DABAAD900F4Bdggeml511mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTo rr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IEFuZHkgQmllcm1hbiBbbWFpbHRv OmFuZHlAeXVtYXdvcmtzLmNvbV0NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp ZiI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiAyMDIwPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5z LXNlcmlmIj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+ODwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1V UyI+MTI8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDI6MTA8YnI+DQo8L3NwYW4+PGI+ 5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4gUWluIFd1ICZsdDtiaWxsLnd1QGh1YXdlaS5jb20mZ3Q7PGJyPg0KPC9zcGFuPjxiPuaKhOmA gTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEtlbnQg V2F0c2VuICZsdDtrZW50JiM0MztpZXRmQHdhdHNlbi5uZXQmZ3Q7OyBuZXRjb25mQGlldGYub3Jn PGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyI+IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRy YWZ0LXRhby1uZXRjb25mLWRhdGEtZXhwb3J0LWNhcGFiaWxpdGllczxvOnA+PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+T24gTW9uLCBBdWcgMTAsIDIwMjAgYXQgNzowOSBQTSBRaW4gV3UgJmx0 OzxhIGhyZWY9Im1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20iPmJpbGwud3VAaHVhd2VpLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZiI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPg0KIG5ldGNvbmYgW21haWx0bzo8YSBocmVm PSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+ 5Luj6KGoIDwvc3Bhbj4NCjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPkFu ZHkgQmllcm1hbjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R6YCB5pe2 6Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWYiPiAyMDIwPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lubQ8 c3BhbiBsYW5nPSJFTi1VUyI+ODwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MTE8L3NwYW4+ 5pelDQo8c3BhbiBsYW5nPSJFTi1VUyI+MzozOTxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3Bh biBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBLZW50IFdhdHNl biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5uZXQiIHRhcmdldD0iX2Js YW5rIj5rZW50JiM0MztpZXRmQHdhdHNlbi5uZXQ8L2E+Jmd0Ozxicj4NCjwvc3Bhbj48Yj7mioTp gIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiA8YSBo cmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbmV0Y29uZkBp ZXRmLm9yZzwvYT48YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJp bGl0eSBmb3IgZHJhZnQtdGFvLW5ldGNvbmYtZGF0YS1leHBvcnQtY2FwYWJpbGl0aWVzPC9zcGFu Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFtIHRy eWluZyB0byB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtIHRoaXMgZHJhZnQgaXMgYXR0ZW1wdGluZyB0 byBzb2x2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgcHJlbWlzZSBzZWVtcyB0byBiZSB0 aGF0IHRoZSBlcnJvciBoYW5kbGluZyBhbmQgJnF1b3Q7aGludHMmcXVvdDsgbWVjaGFuaXNtJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+aW4gUkZDIDg2MzkgYW5kIFJGQyA4NjQxIGRvIG5v dCB3b3JrDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1Fpbl06IFRoZSBkYXRh IGV4cG9ydCBjYXBhYmlsaXRpZXMgaXMgbm90IGRlc2lnbmVkIHRvIHJlcGxhY2UgZXJyb3IgaGFu ZGxpbmcgYW5kIGlzIHBvc2l0aW9uZWQNCiBhcyBjYXBhYmlsaXR5IG5lZ290aWF0aW9uIGFuZCB1 c2VkIGJlZm9yZSBuZXRjb25mIGNvbm5lY3Rpb24gdG8gYmUgc2V0dXAsICZuYnNwO3RoZXkgYXJl IGNvbXBsZW1lbnRhcnksDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5lcnJvciBoYW5kbGluZyB3aWxsIGJlIHRoZSBsYXN0IHJlc29y dDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPldoZW4gZHluYW1pYyBzdWJzY3JpcHRpb24gcmVxdWVzdCBpcyBkZWNsaW5lZCBvciByZWpl Y3RlZC4gRXJyb3IgaGFuZGxpbmcgaXMgb25seSBhcHBsaWNhYmxlDQogdG8gZHluYW1pYyBzdWJz Y3JpcHRpb248L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5iYXNlZCBvbiBzZWN0aW9uIDMuMiBvZiBSRkM4NjQxLg0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ T3VyIGFyZ3VtZW50IGlzIHdoeSBub3QgcHJldmVudCB0aGUgcHJvYmxlbSB0byBoYXBwZW4gaW4g dGhlIGZpcnN0IHBsYWNlIGluc3RlYWQgb2Ygd2FpdGluZw0KIGZvciB0aGUgc2VydmVyIG1ha2lu ZyBtaXN0YWtlIGFuZCByZW1lZHkgaXQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T25lIG9mIHByaW5jaXBsZSBzZXQgYnkgUkZDODY0 MSBpczo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5taW5pbWl6ZSB0aGUgbnVtYmVyIG9mIHN1YnNjcmlwdGlvbiBpdGVyYXRpb25zIGJl dHdlZW4gc3Vic2NyaWJlciBhbmQgcHVibGlzaGVyLCBkaXNjb3VyYWdlDQogUmFuZG9tIGd1ZXNz aW5nIG9mIGRpZmZlcmVudCBwYXJhbWV0ZXJzIGJ5IGEgc3Vic2NyaWJlci48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5U aGUgc29sdXRpb24gYmVpbmcgcHJvdmlkZWQgaXMgZ2VuZXJpYywgdGFyZ2V0ZWQgdG8gYWRkcmVz cyB0aGlzIGNoYWxsZW5nZSwgbm90IG9ubHkgYXBwbGljYWJsZQ0KIHRvIGR5bmFtaWMgc3Vic2Ny aXB0aW9uLCBidXQgYWxzbyBjb25maWd1cmVkIHN1YnNjcmlwdGlvbi48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPklNTyB0aGUgc29sdXRpb24gYXBwcm9hY2ggZG9lcyBub3Qgc2NhbGUgd2Vs bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlcmUgaXMgdmVyeSBsaXR0bGUgdmFsdWUgZm9yIHRv byBtdWNoIGNvbXBsZXhpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaW5dOiBJIHJlc3Bl Y3RmdWxseSBkaXNhZ3JlZSwgOy0pLGVycm9yIGhhbmRsaW5nIGRvZXNu4oCZdCBwcm92aWRlIHRo ZSBjbGllbnQgYW55IGhpbnQgYWJvdXQgd2hpY2ggdHJhbnNwb3J0IHByb3RvY29sLCB3aGljaCBz ZWN1cml0eSBzY2hlbWVzIHlvdQ0KIHNob3VsZCB1c2UuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5XZSBzZWUgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRp ZXMtMTMgcHJvdmlkZXMgc2VydmVyIGNhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVudCB3aGljaCBzZXJ2 ZSBhcyBhIGdvb2QgYmFzaXMgZm9yIHRoaXMgZHJhZnQgYW5kIGNhbg0KIGJlIHVzZWQgbm90IG9u bHkgYXQgaW1wbGVtZW50YXRpb24gdGltZSBidXQgYWxzbyBydW4gdGltZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPldlIGFsc28gc2VlIGRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1u b3RpZi0wNCBwcm92aWRlcyBSZWNlaXZlciBDYXBhYmlsaXRpZXMgbGVhcm5pbmcuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkkgYWxzbyByZW1lbWJlciBub3RpZmljYXRpb24gY2FwYWJpbGl0eSBtb2RlbCBkZWZpbmVk IGluIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0aWVzLTEzIGhhcyBi ZWVuIHJlZmFjdG9yZWQgdG8gbWFrZSBpdCBtb3JlIGdlbmVyaWMNCiBtb3RpdmF0ZWQgYnkgc29t ZSBuZXcgY2FwYWJpbGl0eSBkcmFmdHMgYW5kIHRoZXJlZm9yZSBjYW4gYmUgdXNlZCB0byBhY2Nv bW1vZGF0ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PdGhlciBjYXBhYmlsaXRp ZXMgZXh0ZW5zaW9uLiBUaGlzIGhlbHBzIHByb3ZpZGUgdGVsZW1ldHJ5IGF1dG9tYXRpb24gc29s dXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+QSBzZXQgb2YgY2FwYWJpbGl0aWVzIGZvciBldmVyeSBwb3NzaWJsZSBkYXRhIG5v ZGUgdGhhdCBjYW4gYmUgdXNlZCB3aXRoIFlBTkcgUHVzaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj53 aWxsIGJlIHZlcnkgbGFyZ2UuIEFueSB5ZXQsIHRoYXQgaXMgc3RpbGwgbW9zdGx5IHVzZWxlc3Ms IHNpbmNlIGl0IGlzIHZlcnkgbGlrZWx5IHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dGhlIHBh cnRpY3VsYXIgaW5zdGFuY2VzIG9mIHRoZSBkYXRhIG5vZGUgYWZmZWN0IHRoZSBwdXNoIGNhcGFi aWxpdGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGZpbHRlciB1c2VkIGluIHRoZSBzdWJz Y3JpcHRpb24gd2lsbCBoYXZlIGEgaHVnZSBpbXBhY3Qgb24gdGhlIGNhcGFiaWxpdGllcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRha2UgdGhl IG1vc3Qgb2J2aW91cyBlbnRyeSAtLSBmb3IgdGhlICZxdW90O2ludGVyZmFjZSZxdW90OyBsaXN0 LiZuYnNwOyBJdCBpcyB2ZXJ5IGxpa2VseSB0aGF0IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj50 eXBlIG9mIGludGVyZmFjZSwgb3IgZmlybXdhcmUgcmV2aXNpb24gb2YgdGhlIGxpbmUgY2FyZCwg b3IgYW55IG9mIGEgMTAwMCBwcm9wcmlldGFyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5kZXRhaWxz IGNvdWxkIGNoYW5nZSB0aGUgcHVzaCBwYXJhbWV0ZXJzIHN1cHBvcnRlZCBmb3IgdGhhdCBpbnRl cmZhY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaW5dOiBJbiByZWFsaXR5LCB3ZSBjYW4g bm90IGFzc3VtZSBhbGwgZGF0YSBvYmplY3RzIGRlZmluZWQgaW4gdGhlIFlBTkcgZGF0YSBtb2Rl bHMgc3VwcG9ydCB0aHJlc2hvbGQgaGFuZGxpbmcgY2FwYWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+ZS5nLiwgb25seSBpbnRlZ2VyIGJ1aWx0LWluIHR5cGUgZGF0YSBvYmpl Y3Qgc3VwcG9ydCB0aHJlc2hvbGQgaGFuZGxpbmcsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPmFub3RoZXIgZXhhbXBsZXMsIHdlIG1heSBuZWVkIHRvIHN1cHByZXNzIHJlZHVuZGFu dCBkYXRhIHZhbHVlIHJlcG9ydGluZywgc28gd2UgbWF5IGluZGljYXRlIHRvIHRoZSBjbGllbnQg d2hpY2ggc2V0IG9mIGRhdGEgb2JqZWN0IGhhcyByZWR1bmRhbnQNCiBzdXBwcmVzcyBjYXBhYmls aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Rm9yIHNvbWUgZGF0YSBvYmplY3Qs IHRoZXkgbWF5IHN1cHBvcnQgdGltZXIgYmFzZWQgdHJpZ2dlciwgd2UgYWxzbyBuZWVkIHRvIGlu ZGljYXRlIHRoZW0gdG8gdGhlIGNsaWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGVyZSBhcmUgYWxzbyB2ZXJ5IHZlbmRvci1z cGVjaWZpYyBjYXBhYmlsaXRpZXMgdGhhdCBpbXBvc2UgYW4gaW1wbGVtZW50YXRpb24gZGVzaWdu LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIGlzIHdheSBvdXQgb2Ygc2NvcGUuIEV4YW1wbGUg YmVsb3c6IERvZXMgdGhpcyBtZWFuIGFsbCB2ZW5kb3JzIG5lZWQgdG8gY2hhbmdlIHRoZWlyIHNl cnZlciBjb2RlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnNvIGl0IGhhcyBhIHNldCBsaW1pdCBwZXIg dXBkYXRlLCBiYXNlZCBvbiBzb21lIG5ldyBjb25jZXB0IHlvdSBtYWRlIHVwIGNhbGxlZCBzZW5z b3IgZ3JvdXBzPz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5bUWluXTogVGhlc2UgdHdvIHBhcmFtZXRlcnMgYXJlIGRlYmF0YWJs ZSwgU2ltaWxhciB0byBtYXgtbm9kZXMtcGVyLXVwZGF0ZSBkZWZpbmVkIGluIGRyYWZ0LWlldGYt bmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0aWVzLTEzOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+bWF4LW5vZGVzLXBlci1zZW5zb3ItZ3JvdXAgYW5kIG1heC1zZW5zb3ItZ3Jv dXAtcGVyLXVwZGF0ZSBhcmUgdHdvIG9wdGlvbmFsIHBhcmFtZXRlcnMuIFRoZSByZWFzb24gdG8g aW50cm9kdWNlIHRoZXNlIHR3byBwYXJhbWV0ZXJzIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj50byBhbGlnbiB3aXRoIGdOTUkgaW1wbGVtZW50YXRpb24sIHdoaWNoIGhhcyBzZW5z b3IgZ3JvdXAgY29uY2VwdCwgd2UgdGhpbmsgaXQgaXMgdXNlZnVsLCB0aGF04oCZcyB3aHkgd2Ug YWRkIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CdXQgdGhleSBjYW4gYmUg dGFrZW4gb3V0IGlmIHRoZXkgaW50cm9kdWNlIGNvbXBsZXhpdHkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5 bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIG1heC1u b2Rlcy1wZXItc2Vuc29yLWdyb3VwIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSB1aW50MzIgezxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByYW5nZSAmcXVvdDsxLi5tYXgmcXVvdDs7PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJnF1b3Q7TWF4aW11bSBudW1iZXIgb2Ygc2VsZWN0ZWQgZGF0YSBub2RlcyB0aGF0IGNh biBiZSBzZW50PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBlciBzZW5zb3IgZ3Jv dXAuJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgbWF4LXNlbnNvci1ncm91cC1wZXItdXBkYXRlIHs8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgdHlwZSB1aW50MzIgezxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByYW5n ZSAmcXVvdDsxLi5tYXgmcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVz Y3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7TWF4aW11bSBudW1iZXIg b2Ygc2Vuc29yIGdyb3VwcyB0aGF0IGNhbiBiZSBzZW50PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGluIGFuIHVwZGF0ZS4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltR aW5dOldoYXQgZG8gd2UgZGVmaW5lIGZvciBtYXgtbm9kZXMtcGVyLXNlbnNvci1ncm91cCBhbmQg bWF4LXNlbnNvci1ncm91cC1wZXItdXBkYXRlLCBpcyBwZXIgc3lzdGVtIGNhcGFiaWxpdHksIG5v dCBwZXIgbm9kZSBjYXBhYmlsaXR5LiBZb3UgZG9u4oCZdA0KIG5lZWQgdG8gZXhwZWN0IGVhY2gg bm9kZSB0byBzdXBwb3J0IHN1Y2ggY2FwYWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Rm9yIHBlciBub2Rl IGNhcGFiaWxpdHksIHdlIG9ubHkgZGVmaW5lIHRocmVlIHBhcmFtZXRlcnMsIGNvdW50ZXIgdGhy ZXNob2xkIHN1cHBvcnQsIHRpbWVyIGJhc2VkIHRyaWdnZXIgc3VwcG9ydCBhbmQgc3VwcHJlc3Mg cmVkdW5kYW50IHN1cHBvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaGljaCBo ZWxwIHlvdSBkZXNpZ24gYXBwcm9wcmlhdGUgc3Vic2NyaXB0aW9uIHBvbGljeSBhbmQgc2VuZCBp dCB0aHJvdWdoIHN1YnNjcmlwdGlvbiByZXF1ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5hbmQgdGhlIGNs aWVudCBuZWVkcyB0byByZXRyaWV2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPmV4dGVuc2l2ZSBt b25pdG9yaW5nIGluZm8gdG8gZGV0ZXJtaW5lIGhvdyB0byBzZXR1cCBub3RpZmljYXRpb25zIG9u IHRoZSBzZXJ2ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SW4gdGhlb3J5IHRo aXMgZGF0YSBjb3VsZCBiZSB1c2VkIHRvIHByZXZlbnQgYW4gJmx0O3JwYy1lcnJvciZndDsgdG8g YmUgcmV0dXJuZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5mb3IgJmx0O2VzdGFibGlzaF9zdWJz Y3JpcHRpb24mZ3Q7IG9yICZsdDtlZGl0LWNvbmZpZyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj5JTU8gdGhlIGN1cnJlbnQgYXBwcm9hY2ggaXMgbXVjaCBiZXR0ZXIg dGhhbiB0aGlzIHByb3Bvc2VkIGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBz ZXJ2ZXIgY2FuIHByb3ZpZGUgdGhlIGhpbnRzIGJhc2VkIG9uIHRoZSBleGFjdCByZXF1ZXN0IGZy b20gdGhlIGNsaWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1Fpbl06IEl0 IG1heSBiZSBsYXRlLCBzdGlsbCByZXF1aXJlIG11bHRpcGxlIHN1YnNjcmlwdGlvbiBpdGVyYXRp b25zIGJldHdlZW4gc3Vic2NyaWJlcg0KIGFuZCBwdWJsaXNoZXIuIEJ1dCBkYXRhIGV4cG9ydCBo YXMgbm8gaW50ZW50aW9uIHRvIHJlcGxhY2UgaXQuIEVycm9yIGhhbmRsaW5nIGhhdmUgaXRzIHZh bHVlIGluIG1hbnkgZGlmZmVyZW50IGNhc2VzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHN0YXRpYyAmcXVvdDtwZXItbm9kZSZxdW90OyBtb25p dG9yaW5nIGRhdGEgY2FuIGJlIHF1aXRlIGxhcmdlLCBhbmQgeWV0IG5vdCBwcm92aWRlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+dGhlIGNvcnJlY3QgYW5zd2VyIGZvciBhIHNwZWNpZmljIGNvbWJp bmF0aW9uIG9mIHN1YnNjcmlwdGlvbiBwYXJhbWV0ZXJzLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ W1Fpbl06IEl0IGlzIHNlcnZlciBjYXBhYmlsaXR5IGV4cG9zdXJlLCBjaGVjayBlYXJseSBpbXBs YW50YXRpb24gdGltZSBpbmZvcm1hdGlvbiBvZg0KIHRoZSBjYXBhYmlsaXR5IHdoYXQgdGhlIHNl cnZlciBzdXBwb3J0IChlLmcuLCBHUlBDIHRyYW5zcG9ydCwgVENQIHN1cHBvcnQsIFVEUCB0cmFu c3BvcnQgc3VwcG9ydCksDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5ub3QgdGFyZ2V0ZWQgdG8ga2VlcCB0cmFjayBvZiBkeW5hbWlj IGNoYW5nZSBkYXRhLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoZXNlIGNhcGFiaWxpdGllcyBzZWxkb20gY2hhbmdlLiBJbiBhZGRp dGlvbiwgdG8gYWxsb3cgdGhlIGNsaWVudCBjb21wb3NlIHZhcmlvdXMgZGlmZmVyZW50DQogc3Vi c2NyaXB0aW9uIHBvbGljeSAoZS5nLiwgYWRhcHRpdmUgc3Vic2NyaXB0aW9uKSwgd2UgcmVxdWly ZSB0aGUgc2VydmVyIHRvIGluZGljYXRlIHdoZXRoZXIgc3BlY2lmaWMgZGF0YSBvYmplY3Qgc3Vw cG9ydHM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UaHJlc2hvbGRzIGhhbmRsaW5nLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgbWlzc2luZyBwaWVjZXMgdG8g c3VwcG9ydCBldmVudCBiYXNlZCB0ZWxlbWV0cnkgc29sdXRpb24uPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5BbmR5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gV2VkLCBBdWcgNSwgMjAyMCBhdCAzOjE3IFBNIEtlbnQg V2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a2VudCUyQmlldGZAd2F0c2VuLi5uZXQiIHRhcmdl dD0iX2JsYW5rIj5rZW50JiM0MztpZXRmQHdhdHNlbi5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPk5FVENP TkYgV0csPGJyPg0KPGJyPg0KUGVyIHRoZSBwcmV2aW91cyBlbWFpbCBzZW50IG1vbWVudHMgYWdv LCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gc29saWNpdCBpbnB1dCBvbiB0aGUgZm9sbG93aW5n IGRyYWZ0Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtUaXRsZTombmJzcDtU ZWxlbWV0cnkgRGF0YSBFeHBvcnQgY2FwYWJpbGl0eTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO0xpbms6DQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sLzwvYT5kcmFmdC10YW8tbmV0Y29uZi1kYXRhLWV4cG9ydC1jYXBh YmlsaXRpZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7ICZuYnNwO0Fic3RyYWN0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhpcyBkb2N1bWVu dCBwcm9wb3NlcyBhIFlBTkcgbW9kdWxlIGZvciB0ZWxlbWV0cnkgZGF0YSBleHBvcnQ8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY2FwYWJpbGl0eSB3aGljaCBhdWdtZW50cyBzeXN0 ZW0gQ2FwYWJpbGl0aWVzIG1vZGVsIGFuZCBwcm92aWRlczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyBhZGRpdGlvbmFsIHRlbGVtZXRyeSBkYXRhIGV4cG9ydCBhdHRyaWJ1dGVzIGFz c29jaWF0ZWQgd2l0aCBzeXN0ZW08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY2Fw YWJpbGl0eSBmb3IgdHJhbnNwb3J0IGRlcGVuZGVudCBjYXBhYmlsaXR5IG5lZ290aWF0aW9uLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KSW4gcGFydGljdWxhciwgcGxlYXNlIGRp c2N1c3MgYWRvcHRpb24tc3VpdGFiaWxpdHkgYXMgaXQgcmVnYXJkcyB0byB0aGUgZm9sbG93aW5n IHF1ZXN0aW9uczo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsg MSkgaXMgdGhlIHByb2JsZW0gaW1wb3J0YW50IGZvciB0aGUgTkVUQ09ORiBXRyB0byBzb2x2ZT88 YnI+DQombmJzcDsgJm5ic3A7IDIpIGlzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJhc2lzIGZvciB0 aGUgd29yaz88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KUFM6IHRoaXMgbWVzc2FnZSBpcyBpdHNl bGYgbm90IGFuIGFkb3B0aW9uIHBvbGwsIGJ1dCByYXRoZXIgYW4gYXR0ZW1wdCB0byBnYXVnZSBp bnRlcmVzdC9zdXBwb3J0IGZvciBhIHBvdGVudGlhbCBmdXR1cmUgYWRvcHRpb24gcG9sbC48YnI+ DQo8YnI+DQpORVRDT05GIENoYWlyczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRjb25mQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B8F9A780D330094D99AF023C5877DABAAD900F4Bdggeml511mbschi_-- From nobody Thu Aug 13 08:01:10 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C6C3A0D0B for ; Thu, 13 Aug 2020 08:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=eh/IXHMu; dkim=pass (1024-bit key) header.d=juniper.net header.b=gtGQUygA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6AtXrZxdiVn for ; Thu, 13 Aug 2020 08:01:05 -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 6CACF3A0CEF for ; Thu, 13 Aug 2020 08:01:05 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07DEwYec020079; Thu, 13 Aug 2020 08:01: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 : mime-version; s=PPS1017; bh=PP79jv8SHmsIBkF0JAYMi9jUNAv1inVdtfNeWNG15m4=; b=eh/IXHMu/Ev4QraobkrjFzwTYZLcB+w3dk7wPZR21IiOiWSfwdW7K+wQMjeShQsGup11 eu8TYM4+tKqowizr6D0AMfmcTEbTEVVhKjUxMY/q4ktRYlVR5UsKfjHfVBPqyDxLdNUG +zMplazR4XZlncrkPjvAMmLqZIiNG6FwJZfz5J40zLJ+OvEbcwG8J/oNd6cz3Ovp4Zm7 +FusW08xJFt6V/46J9XJmWvBI9yRHhY5yTDxac5eLNX/62kR4lOyoTRfBwKITDJxS3W4 lDz3DQ6DoohSb8axQIyu5ja/hGo7j6Aeh/tG/DHZjHNYS6Z82wujauK/ftlBb70n2XTH 8w== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2051.outbound.protection.outlook.com [104.47.45.51]) by mx0a-00273201.pphosted.com with ESMTP id 32vdgujm6s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 08:01:02 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CMtlEql8Er2zGoB0ZoqlLgbgpDKuXduRv/P9mtJqreZCBRP4qqu2IHyWE/IYnC14JDd+4GwpdvpPxK9BvJZRXR9a7uHDEV1MeJcyf74fpjFt55u5LozIVLGEEB/2OYTYy6mPo09QTnQiqgQ0aAw6XLcymvuMhxsoy/9wNT899Cz6rrjjq5zBc4oRnT+9E4iLiQ3muTMliLsyRF2tBeQSG1bbFD5KL2lN7uMSVWI/Nr9uMm/UvYjQPjsj/X7TYr5Z95ZqxhQE37liMthqnDGv30tDTR9jZf3N8qQFmKh3Tq9n48iLMknPOKgP+TecyBWB+HazWRgZjuiQxE1SskeV5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PP79jv8SHmsIBkF0JAYMi9jUNAv1inVdtfNeWNG15m4=; b=Udru4HCT7bOqgsw+Jn14mCYdejajVoKdsjwchY45MeL03UPz8rD+YdivFsZ/bIQp99POde91p50K9iDx3eBPL+6LpNa4pRIQjBwRKg17d0P5tEJUg7xuCw2/XzXILYpQ8CnE7IStpvNMGhNXxD8kwEZUA+xpdF8KwZEDKNPkpfnDkphBj2stCKq646jSXs2WY/rdS/NpJYwL+sIrpxFhACeFB/4xr1SZGT+OJOw6sYplQ8D7L+TH+ThnX95Zq5nLc3nsR4T3F9NESpKg4XnYFIoIAxuc4eNypgljk/uycYFneKFoQ3j/0JSWVj+xOaxNaElX/tNhhfPO3vk725ojrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PP79jv8SHmsIBkF0JAYMi9jUNAv1inVdtfNeWNG15m4=; b=gtGQUygAYanGnU6FjUBkaS82dDu+pyp3lFIhH5FKKN+0ZUvHSswJNwx/qquGhYSkhvA5ws5vF4I24rtX72yM5qyGSInN6LljiyI6d8YAUCEFdEqiFgTIWr4Cdke16jAWCm9LFWhF0cgVqk5N58MSuiyeOqYjyHnCMYc4CQq/2Ds= Received: from DM6PR05MB6889.namprd05.prod.outlook.com (2603:10b6:5:204::22) by DM6PR05MB5578.namprd05.prod.outlook.com (2603:10b6:5:5d::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.10; Thu, 13 Aug 2020 15:00:59 +0000 Received: from DM6PR05MB6889.namprd05.prod.outlook.com ([fe80::f5ae:e4dc:9e61:d5f5]) by DM6PR05MB6889.namprd05.prod.outlook.com ([fe80::f5ae:e4dc:9e61:d5f5%5]) with mapi id 15.20.3283.015; Thu, 13 Aug 2020 15:00:59 +0000 From: Guy Fedorkow To: "netconf@ietf.org" CC: "kent+ietf@watsen.net" , Mark Baushke , William Bellingrath Thread-Topic: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr Thread-Index: AQHWb2FSNnSQJH5E4USOKHG5nn+ORqk2JIag Date: Thu, 13 Aug 2020 15:00:59 +0000 Message-ID: References: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> <01000173da613477-58693b0e-d2d2-4642-b9ae-111bc920b801-000000@email.amazonses.com> In-Reply-To: <01000173da613477-58693b0e-d2d2-4642-b9ae-111bc920b801-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-13T15:00:56Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=38a46858-5ed2-4e81-a5bd-b037378dfcdc; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 98be7a79-131b-45c5-54e9-08d83f99b079 x-ms-traffictypediagnostic: DM6PR05MB5578: x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr,ExtFwd x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jcvdg02kP7sQC3GE2zPswcmKq3zOyoWDFoi3NACIhzHWE+N+4DKJRbR+3iaRoPKpcSXB3WQLL1S+3JA371hWYDIZdyn1V+/z6mDBHqeJj6fwpSLkmcwee365+qczqgpHxNQaNTDa/udRZa9MKr/xyCGXPEw3sG05iu3F9he42QFBa/NRwNvTm0LurwjDBCmr6Hpdo3szVHMpKkCa0SpxdXIOoYZiy3jXpIokmqfqYJ7MLcmXK6f7ijvuhWu8rnTbMOJI4eMSM4JHYmbv6Ot9hrIn7iQKJGAU3MjtZYvUdFnglNnEECFFAJ1uwz7YV6/1q1P8NX1EEIlAtOwqiO8TEpK7fC74lgxKZU5IW2R2oxmrCedqHZZ9DO80ZnYHkSBk0yov4RBHO9yRShc3WJSpXw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6889.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(136003)(346002)(366004)(396003)(186003)(966005)(2906002)(478600001)(166002)(6506007)(86362001)(7696005)(6916009)(83380400001)(26005)(99936003)(107886003)(71200400001)(66556008)(55016002)(66446008)(64756008)(66476007)(66616009)(76116006)(66946007)(9686003)(33656002)(54906003)(8676002)(5660300002)(52536014)(316002)(8936002)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: xIM6wPw+b+TgqCwS5nFzlaiCIR1IF5C5UTUfPUECgk76xtIau173yJlhv9zAE60GOOdK3cj9neJ6EL73ig0qlPJUchiTWVMGB9TJ8MsyZdIMH/3m+K8NxoUQpWepLJc5wxajmmpOSXsknV2SWQ1qbo/14Gm0X7UOXG4xEI2zu2qKJ/9T48KX4X+FMPY024Cs/w8H8YiYrhbv/AeTM4I4eayC7V3BLEEA5bn0VMZM0lLOTQYBynNXGpm9IjPnyaDFFRcZIDMXKcuKg3l3XxIWMgDVIKXJgnfA44F2ADeZ99AyXuWMfojxYjFYrGr/acF0EkQEYviBNq4/E6OIl10cavPlxUNz2P/X1XtsSY5vu1I9USH+GPeufas56gNDlv24EtmDeco8ofqcpR0pNUNxd8owwvq/aswqu8VWv/NRn5rSI9z1mtKDZQ3bNpgukkGaapbhLVNZPYOXGA36kWoRgWCvjgWppckX8vTkdVGipEU6dl7DJZo7aBfnc9g5WqSPpdXDlGVA0bZnEox1W8XjXzjh/Xd7IeD54BGS87G+ZAj12xZ5bL/BRV2ggDNyIiGCjKvshRYK7vzzEx/XgQi0ZiBf3XzMM1E3lXqALucTSJR8sBst6n1zD+pOQ9FuRYRr7Ub28TjoJDibN6/RhdeOkg== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_08CA_01D67161.057A8410" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6889.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98be7a79-131b-45c5-54e9-08d83f99b079 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 15:00:59.4793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LjZRNIb8HbgGY75QU+6kUOPG77Fvj+t+DOyRQIAKAaOXWqlr6MPoxDaRhzj9SqJcXUm3Qwjc0tTUlFTMiWrvLw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5578 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-13_13:2020-08-13, 2020-08-13 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 bulkscore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 phishscore=0 spamscore=0 clxscore=1011 malwarescore=0 suspectscore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008130113 Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 15:01:08 -0000 ------=_NextPart_000_08CA_01D67161.057A8410 Content-Type: multipart/alternative; boundary="----=_NextPart_001_08CB_01D67161.057A8410" ------=_NextPart_001_08CB_01D67161.057A8410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think this work is of value. We've had Local Device ID's defined in 802.1AR for some time, and some organizations interested in using them, but we have not had any way to create an LDevID key, other than ad-hoc manufacturer-defined techniques. This work would give network operators a vendor-independent automated, zero-touch mechanism to create local device identity, and I think the draft outlines a workable approach. I think it should go forward. /guy fedorkow From: Kent Watsen > Subject: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr Date: August 5, 2020 at 6:19:09 PM EDT To: "netconf@ietf.org " > NETCONF WG, Per the previous email sent moments ago, the chairs would like to solicit input on the following draft: Title: Conveying a CSR in an SZTP Bootstrapping Request Link: https://tools.ietf.org/html/ draft-kwatsen-netconf-sztp-csr Abstract: This draft extends the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. In particular, please discuss adoption-suitability as it regards to the following questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? PS: this message is itself not an adoption poll, but rather an attempt to gauge interest/support for a potential future adoption poll. NETCONF Chairs _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf Juniper Business Use Only ------=_NextPart_001_08CB_01D67161.057A8410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

  I = think this work is of value.  We’ve had Local Device = ID’s defined in 802.1AR for some time, and some organizations = interested in using them, but we have not had any way to create an = LDevID key, other than ad-hoc manufacturer-defined = techniques.

  This work would = give network operators a vendor-independent automated, zero-touch = mechanism to create local device identity, and I think the draft = outlines a workable approach.

  = I think it should go forward.

/guy = fedorkow

 

 

 

From: Kent Watsen <kent+ietf@watsen.net><= o:p>

Subject: [netconf] = Adoption-suitability for = draft-kwatsen-netconf-sztp-csr

Date: August 5, 2020 at 6:19:09 = PM EDT

 

 

NETCONF WG,

Per the previous email sent moments = ago, the chairs would like to solicit input on the following draft: =

 

   Title: Conveying a CSR in = an SZTP Bootstrapping Request

   Link: https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr
&nb= sp;  Abstract:

  =     This draft extends the "get-bootstrapping-data" = RPC defined in

  =     RFC 8572 to include an optional certificate = signing request (CSR),

  =     enabling a bootstrapping device to additionally obtain an = identity

    =   certificate (e.g., an LDevID, from IEEE 802.1AR) as part of = the

      = "onboarding information" response provided in the = RPC-reply.

 


In = particular, please discuss adoption-suitability as it regards to the = following questions:

 

    1) is the problem important for the = NETCONF WG to solve?
    2) is the draft a suitable basis = for the work?



PS: = this message is itself not an adoption poll, but rather an attempt to = gauge interest/support for a potential future adoption = poll.

NETCONF Chairs

_______________________________________________
netc= onf mailing list
netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf

 

 

Juniper Business Use = Only

------=_NextPart_001_08CB_01D67161.057A8410-- ------=_NextPart_000_08CA_01D67161.057A8410 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISJTCCBd4w ggPGoAMCAQICEAH9bTD8o8pRqBu8ZA41Ay0wDQYJKoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTEwMDIwMTAwMDAwMFoXDTM4MDExODIzNTk1OVowgYgxCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAgBJlFzYOw9sIs9CsVw12 7c0n00ytUINh4qogTQktZAnczomfzD2p7PbPwdzx07HWezcoEStH2jnGvDoZtF+mvX2do2NCtnby qTsrkfjib9DsFiCQCT7i6HTJGLSR1GJk23+jBvGIGGqQIjy8/hPwhxR79uQfjtTkUcYRZ0YIUcuG FFQ/vDP+fmyc/xadGL1RjjWmp2bIcmfbIWax1Jt4A8BQOujM8Ny8nkz+rwWWNR9XWrf/zvk9tyy2 9lTdyOcSOk2uTIq3XJq0tyA9yn8iNK5+O2hmAUTnAU5GU5szYPeUvlM3kHND8zLDU+/bqv50TmnH a4xgk97Exwzf4TKuzJM7UXiVZ4vuPVb+DNBpDxsP8yUmazNt925H+nND5X4OpWaxKXwyhGNVicQN wZNUMBkTrNN9N6frXTpsNVzbQdcS2qlJC9/YgIoJk2KOtWbPJYjNhLixP6Q5D9kCnusSTJV882sF qV4Wg8y4Z+LoE53MW4LTTLPtW//e5XOsIzstAL81VXQJSdhJWBp/kjbmUZIO8yZ9HE0XvMnsQybQ v0FfQKlERPSZ51eHnlAfV1SoPv10Yy+xUGUJ5lhCLkMaTLTwJUdZ+gQek9QmRkpQgbLevni3/GcV 4clXhB4PY9bpYrrWX1Uu6lzGKAgEJTm4Diup8kyXHAc/DVL17e8vgg8CAwEAAaNCMEAwHQYDVR0O BBYEFFN5v1qqK0rPVIDh2JvAnfKyA2bLMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MA0GCSqGSIb3DQEBDAUAA4ICAQBc1HwNz/cBfUGZZQxzxVKfy/jPmQZ/G9pDFZ+eAlVXlhTxUjwn h5Qo7R86ATeidvxTUMCEm8ZrTrqMIU+ijlVikfNpFdi8iOPEqgv976jpS1UqBiBtVXgpGe5fMFxL JBFV/ySabl4qK+4LTZ9/9wE4lBSVQwcJ+2Cp7hyrEoygml6nmGpZbYs/CPvI0UWvGBVkkBIPcygu xeIkTvxY7PD0Rf4is+svjtLZRWEFwZdvqHZyj4uMNq+/DQXOcY3mpm8fbKZxYsXY0INyDPFnEYkM nBNMcjTfvNVx36px3eG5bIw8El1l2r1XErZDa//l3k1mEVHPma7sF7bocZGM3kn+3TVxohUnlBzP YeMmu2+jZyUhXebdHQsuaBs7gq/sg2eF1JhRdLG5mYCJ/394GVx5SmAukkCuTDcqLMnHYsgOXfc2 W8rgJSUBtN0aB5x3AD/Q3NXsPdT6uz/MhdZvf6kt37kC9/WXmrU12sNnsIdKqSieI47/XCdr4bBP 8wfuAC7UWYfLUkGV6vRH1+5kQVV8jVkCld1incK57loodISlm7eQxwwH3/WJNnQy1ijBsLAL4JxM wxzW/ONptUdGgS+igqvTY0RwxI3/LTO6rY97tXCIrj4Zz0Ao2PzIkLtdmSL1UuZYxR+IMUPuiB3X xo48Q2odpxjefT0W8WL5ypCo/TCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJKoZI hvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtK ZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VS VHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMwMTIz MTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGln byBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkqKtLN nFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfbM3wc caNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+LbnTe ef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmHfpsE kzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMBAAGj ggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy/Ava lNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBHMEWg Q6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlvbkF1 dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVzZXJ0 cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9v Y3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiMAN0X 13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vhNn9d NqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHitcPr 5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDpVRH9 9lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7T2ww C+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI9oKS ChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RIZllX 4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDonM8V/ 2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQz3lC NObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMIIGKzCCBROgAwIBAgIRAPuElTZ4 EhaY10ByhNJltnIwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRl ZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTkwODI0MDAwMDAwWhcNMjIwODIzMjM1OTU5WjCCATcxCzAJBgNVBAYTAlVT MQ4wDAYDVQQREwU5NDA4OTELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVN1bm55dmFsZTEcMBoGA1UE CRMTMTEzMyBJbm5vdmF0aW9uIFdheTEeMBwGA1UEChMVSnVuaXBlciBOZXR3b3JrcywgSW5jMR4w HAYDVQQLExVTb2Z0d2FyZSBFbmdpbmVlciBMYWIxOzA5BgNVBAsTMklzc3VlZCB0aHJvdWdoIEp1 bmlwZXIgTmV0d29ya3MsIEluYyBFLVBLSSBNYW5hZ2VyMR8wHQYDVQQLExZDb3Jwb3JhdGUgU2Vj dXJlIEVtYWlsMRUwEwYDVQQDEwxHdXkgRmVkb3Jrb3cxJDAiBgkqhkiG9w0BCQEWFWdmZWRvcmtv d0BqdW5pcGVyLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL2Fewgz3OFG1Go3 cuoLYIbLNRTSEFgN+GLUaqB6g5VuCf0UTvgARSlxgDmsvE5qwTtb8JOtJ64OylVNvz28uslsfvg4 WCc0InZUo1B6JkgNamxa3HI31h63s5wVm/wZgglg5Dv7WH7gmAPrgeoWpBC2GN1sxWHfcJOi2fzg M5LWst0Iwz4M7vqFsZ77AOkUFDNm5p19Fu8HRjVlsE0fNGieZB5GEiL2CN2YoxyOKrJdqWHNMkK8 Q5owvlDnSR0tb8oJgHDX8EESSo5TDA5zqnva48zFfFWCrOdobNgf1To4uBskX6B+QEmrSNLuSdpK JOHw9IdrPofgpjZCmFwvtS8CAwEAAaOCAc4wggHKMB8GA1UdIwQYMBaAFAnA8vwL2pTbX/4r36iZ Qs/J4K0AMB0GA1UdDgQWBBQPfL+xFDoZAlQisKraMq/Y34eQGjAOBgNVHQ8BAf8EBAMCBaAwDAYD VR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwQAYDVR0gBDkwNzA1Bgwr BgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAg BgNVHREEGTAXgRVnZmVkb3Jrb3dAanVuaXBlci5uZXQwDQYJKoZIhvcNAQELBQADggEBALilLU71 sn7XVNFoUU4MqcHXXFiFiOjCQmq1nqijMa6L4fKm/VX9LZtrsQs3CZTUiHuW2pyLapLVIEXdubNX L877oIVJmeAoSWz1+AYelK6CIpuGUUcGSsXKd4Xl9yOTrmLb7PTjrRpXsWSHJi//jrXTrR/X6M+U TterfzhR5gYPFyvX65Zie9M7k7V2yB3YJJPzT8EtfrJc+eDzYAgiWK8X/ToMZOG7noa/Er8FEARn joL7pKHVOkHTOM9UNaublWlhiUEzzXx9kYPKjgqjAetRo4zh1KBFm9MBlXeigAVBx+BQpP0OdmHb 5vcX3pUR4lkRpnVeLKFR++q6z+bViYAxggRnMIIEYwIBATCBrDCBljELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2Vj dGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAPuElTZ4EhaY10ByhNJltnIwCQYFKw4DAhoFAKCCAo8wGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODEzMTUwMDU3WjAjBgkq hkiG9w0BCQQxFgQUYbGwkAMRISlEThUB/XXoqQFzlnEwga0GCSqGSIb3DQEJDzGBnzCBnDALBgkq hkiG9w0BAQcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCSqGSIb3DQEBCjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBvQYJKwYBBAGCNxAEMYGvMIGs MIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA+4SVNngSFpjXQHKE0mW2 cjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+ MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD7hJU2eBIWmNdAcoTSZbZyMA0GCSqGSIb3DQEBAQUABIIBAE7Kwv1ILDq6vWwSplfj pF8ASLozYMlcjKQ18tF/kq4cY1JGrj7u9/A7cSFy6MJxOrEuQ4omWFQaCMoIKBldQ8MXoAdLD2Ts PDA92X8Pehl+tAX9yOiNngo3a9LuLJNAn5vlXTDIKH1TTcqbcMizqyo+YS7CNPMsNZ880vei06t7 yMMVs3HKcqzKwM7mjDH80LMrYuk2ddQyY6OdpQekPDmNIIndCzCNuyTLcp+gOa9nvDtTTn8Mm9mq bGJu3iqjDg6ejg7SO6SfYX+ofhh6YzthQ95UNTbhr40R7wXFNIs3Bz8JbiOynW7wipA1knT6a0gr HxKgH2vdVel5ljsyZOYAAAAAAAA= ------=_NextPart_000_08CA_01D67161.057A8410-- From nobody Fri Aug 14 10:25:09 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AC83A0E71 for ; Fri, 14 Aug 2020 10:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 iNC18COej69z for ; Fri, 14 Aug 2020 10:25:06 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2104.outbound.protection.outlook.com [40.107.93.104]) (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 4506E3A0E67 for ; Fri, 14 Aug 2020 10:25:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oeab3697zXhvHoGZpjyAy/nf0ijzI+SZ7LA1tqEEVBGknmjsR9myq/4zHCQgof5OosEwfMjOGVy276PNcsH2OMzrJgDdbFQto/8UEg4Q3OC7Cw4nQLk7Pn1QwQpdjLB3qxR3DH8PJ5tqgpUDmnamcE0AIC8GBRB0ivrglFgyGAzf77NEEFMcpBtrOibWf35YxNiCaeuWSH/FzG1RyPOmTnifyvk3gJ8SnFQvpg5sJSYCHGiowocQMsaz/BRu0WD4oIj29A9lmxNfTtauGUzG4H0l0JNeqdwBuaSYjqmIf6lMsIbnb5rEAC9JNRT4wPp5kZYjhAoJPQXjkzysiRArAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z/nH4Vgp9fMMbbIq6WVDAYg8U7yZA6V4qv91iIr1cSM=; b=XWa0IAbHtHfy1F4WzogQBo0q5HPQ9macVkzLRSYWd3V0RQsQBKvv3THSB2KrUBVYIcI7r3pQSEDhv3gsvxhu98q1inWayJnyC/uJLBu1MPYef5wU3n8Jb7jpPl4eIo46NyNOhQrURraIyoqZj/KzerMYd7ktrdVloIuEabtlUaG8o9ebEkmBjqdHcW5i2U4xx3/FuRA6hF20OHLOdW9iDWpOdSek8O7QEoQi7+bUaPWm0o6DK5GLAR7OAQDoGARPexldfX5WhT5bJ3P1q/yp7S3EZhqUHEvqAhWKn+LG7viKGVZYuKAv1CK9ofV6a++5/3Ha3lvnswBK2+yfHcHtOw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z/nH4Vgp9fMMbbIq6WVDAYg8U7yZA6V4qv91iIr1cSM=; b=uDseXacegCvNc+hzJXIcVTF4iQQgKidDxBHUOefJ3s5b67+kd5E5oJZz3u+qu9erwAZdbQ/nAo+mCsTw2B7ETfeo9xXkdNyVksphTwWC7sATo8IHZZKuGHy3F/AyBHPSJLonHGx3UtTvHpt8QFLOO6mPTyiZPkaC2imWYhQMauM= Received: from DM5PR08MB2633.namprd08.prod.outlook.com (2603:10b6:3:ca::21) by DM5PR08MB2633.namprd08.prod.outlook.com (2603:10b6:3:ca::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Fri, 14 Aug 2020 17:25:03 +0000 Received: from DM5PR08MB2633.namprd08.prod.outlook.com ([fe80::6dd9:bee1:e7b5:2238]) by DM5PR08MB2633.namprd08.prod.outlook.com ([fe80::6dd9:bee1:e7b5:2238%8]) with mapi id 15.20.3283.015; Fri, 14 Aug 2020 17:25:01 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netconf@ietf.org" Thread-Topic: netconf-config-change notification & YANG push for ordered-by user list Thread-Index: AdZyX2sUC5WA1FoDRneo88GhsYp6wA== Date: Fri, 14 Aug 2020 17:25:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [174.112.3.120] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6fb94e35-2972-4234-fdba-08d84076f9fe x-ms-traffictypediagnostic: DM5PR08MB2633: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AFKLZaCrpsepAqsCi28JhUcOENfNFafwwn9rbD1agHUJ4k8l/W3BftvXvR8A1w8hzr+p55LxqonJEuPp1G24uk/oSU6YMLv6cTHQUI7odCYRtWugWjGMYCO0l1PBX6arBIwWCs2HLV0WfBcQqViK7gOPf3nGEO4G4AHiMWbq9F5meA9TFNjmIjhkb84IMQZnkPGxIOcEwKGO/hKnLry8Y6L4kFeyNNP8PwyoaLHkprkAzcemIDPwzAGwDUSIfnCAcBgCEvMI5MKw9Hcpb8IbTL4WZe2dfKAczWflt5vy7AyJcdDZYtWb1f8fdfa+5XPGMI9i3dQzxZq967boTxZqJpYz4YYN2dI3uaBymbvUGsdPXLFU36HM3DWbLBxPeG0K x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR08MB2633.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(396003)(136003)(346002)(366004)(7696005)(64756008)(66446008)(6506007)(33656002)(186003)(83380400001)(52536014)(66946007)(76116006)(26005)(15650500001)(5660300002)(8936002)(6916009)(66556008)(66476007)(9686003)(2906002)(8676002)(316002)(86362001)(55016002)(71200400001)(478600001)(19870200002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: d35gQGzSK3eipjOewf6nFIeQPAHX7S1rmke/d3zdTTAKq/JA/rpN2mRxyfNcbX40N0KzTs0XkEnF+FZnn+G3wODuhAdwSp+eBEA3Ly3xypGkxgJp4Cjc63/idBwKctMED4L+TxzZA6bLHqIYIYYovd14bb8cvfgCG4bIwS7teN1IEwoWh8UT9I8TRkAhmdcodQvH6LXy2GgOFB5Sn61zCNMHPyiK0/rntSvO+KPb0yvGNiD/1JsPw0Mr7cZ2q+b/RsHpMdwjfB9ErkMUDvnG4Do3TjW7fZP3N9lZ90l1OFrGmpEede7hwv76yl+PqHaF2IJ3sY8XjWrZrWyAL7rPHAPz25LjweSXjUdGvum7FA9JG3JUTPoyrf1Eir2yb/N65p38Wev8VhxAVrm02OYOXvPo+/RAHNMEex05nhS8Opq1YX3ICkzkc78wrMGpyg7AhzQpLfngHQYv+wDloRhWIuUmF36tEiNbeuKql1C0rjZ85Y/xL7qbsTF+LWYKsK467956ifUoID4RK9PwPVQRS5PeOIA4AJtcc0BLFCLsv7UJMgse+crlWsO7EmG7pY2VftQeciv8dtKqSJI4S6+8YPTDlUZ4vDTLNduIsdezMCcoRMDFZ19UEPX8UgejaAl8MQHO+YDEkAkQtKQkQkgXcw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM5PR08MB26334AC7FE1B5FE0DBCB071B9B400DM5PR08MB2633namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR08MB2633.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6fb94e35-2972-4234-fdba-08d84076f9fe X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 17:25:01.5612 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CDWGjkQPLjCmJ8rV63c38KM2QkWcFsqbNYWNzQ57z5eQYoUetnRy3JAM1uDKLrcAkuFJrYDXv8bwmMLkeY8IFg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2633 Archived-At: Subject: [netconf] netconf-config-change notification & YANG push for ordered-by user list X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 17:25:08 -0000 --_000_DM5PR08MB26334AC7FE1B5FE0DBCB071B9B400DM5PR08MB2633namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, What is the expected output for the RFC 6470 netconf-config-change notifica= tion in the following situation (after the commit) ? Note that the notifica= tion is not an edit-time notification. It is a notification intended to be = sent after a commit (and actual change to the running). Similar question -> what YANG Push notification(s) would we expect if someo= ne had subscribed "on-change" to the running config? A) YANG model list foo { ordered-by user key "foo-name"; leaf foo-name { type string; } leaf bar { type unit16; } } B) initial contents of running foo red { bar 55 } foo blue { bar 66 } foo yellow { bar 77 } C) edit the candidate so it contains this (change the order of blue and red= ) foo blue { bar 66 } foo red { bar 55 } foo yellow { bar 77 } D) commit Questions: Q1) contents of the netconf-config-change notification? Q2) YANG PUSH notifications for an on-change subscription to the running co= nfig? I see that RFC8072 (patch) has a concept of a "move" operation (RFC 6470 / = 6241 doesn't have that). But patch could describe this change in a few diff= erent ways in theory (option 1 seems most ideal, but maybe it depends what = the underlying system will do with the change). OPTION 1: -------------- - operation=3Dmove, target =3D foo red, point =3D foo blue, where =3D after OPTION 2: -------------- - delete foo red - insert foo red after foo blue OPTION 3: ------------- - delete foo blue - insert foo blue before foo red RFC 6470 doesn't really seem to have those semantics. Rgds, Jason --_000_DM5PR08MB26334AC7FE1B5FE0DBCB071B9B400DM5PR08MB2633namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

What is the expected output for= the RFC 6470 netconf-config-change notification in the following situation= (after the commit) ? Note that the notification is not an edit-time notifi= cation. It is a notification intended to be sent after a commit (and actual change to the running).

 

Similar question -> what YAN= G Push notification(s) would we expect if someone had subscribed "on-c= hange" to the running config?

 

A) YANG model=

 

list foo {

   ordered-by user

   key "foo-name= ";

   leaf foo-name { ty= pe string; }

   leaf bar { type un= it16; }

}

 

B) initial contents of running<= o:p>

 

foo red {

    bar 55<= /o:p>

}

foo blue {

    bar 66<= /o:p>

}

foo yellow {<= /p>

    bar 77<= /o:p>

}  

 

C) edit the candidate so it con= tains this (change the order of blue and red)

 

foo blue {

    bar 66<= /o:p>

}

foo red {

    bar 55<= /o:p>

}

foo yellow {<= /p>

    bar 77<= /o:p>

}  

 

D) commit

 

Questions:

Q1) contents of the netconf-con= fig-change notification?

Q2) YANG PUSH notifications for= an on-change subscription to the running config?

 

I see that RFC8072 (patch) has = a concept of a "move" operation (RFC 6470 / 6241 doesn't have tha= t). But patch could describe this change in a few different ways in theory = (option 1 seems most ideal, but maybe it depends what the underlying system will do with the change).

 

OPTION 1:

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

- operation=3Dmove, target =3D = foo red, point =3D foo blue, where =3D after

 

OPTION 2:

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

- delete foo red

- insert foo red after foo blue=

 

OPTION 3:

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

- delete foo blue

- insert foo blue before foo re= d

 

RFC 6470 doesn't really seem to= have those semantics.

 

Rgds,

Jason

 

--_000_DM5PR08MB26334AC7FE1B5FE0DBCB071B9B400DM5PR08MB2633namp_-- From nobody Fri Aug 14 15:08:04 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B9D3A00F7 for ; Fri, 14 Aug 2020 15:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjeA48d3-G4o for ; Fri, 14 Aug 2020 15:08:00 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF5F3A0044 for ; Fri, 14 Aug 2020 15:07:59 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id t23so11481931ljc.3 for ; Fri, 14 Aug 2020 15:07:59 -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=Ot+YVbIrdBCBx54LzQnyOTyJHHjxdS/RpXD1zYI23SU=; b=R8cuaLYTJc/Jvy/wphTRjJ+bfKSVQhnaoH48tM+CVL4br6l8RXN/VjRzQkiZkh1UFX K6It0SqjV7yT9ktQ3VlP0H/IPiwR/8XaWlky0YfNd4NT7EEkNXfLlebZAUbPc8B/Pdzi 358b2MXvsu2jEthMfxdTUE6RGKCkkniRTsL/QMf3B0XFjXDFeIdHXAPk/H90c37sydkb Q/SdrWtsbz2iPXbZgL9bX64t+VhC+Ww+DQW4LE7qEuYpYjJ9/QH5z+QmSEX8F/s3qaYe i9Yo5ANec+uvEpCPW9+l48nDPY9i2Bl+ZufLx+ZV6KUmI9XxmD4gH5wjSqE3JLHLvUlT ZawA== 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=Ot+YVbIrdBCBx54LzQnyOTyJHHjxdS/RpXD1zYI23SU=; b=ES7CUR+VuQzcfJd57gB0YYpuUGR1rdX78obddhAQuvzss4NScBn9i/5Z8qr5IzdCCO Uzgb0C0gh0mAefXm2nnuzvMWuTtdvO22y1rgdJi1Dq0Pqo5U8jzQlJFEB7ffMsV0Ju8g 9a0iVJTehSpXRZ15mXoFOe7I4pGI05B7U5aJVcnr/c7P/kIBDLfGrfDt2n9qKym0zrFw qpu2F6+gHxd4Nx7R1Bzs+/O0qYTHfRH8VZgcyGOp+oLIK2dvae2R+BSh90H6OVgTjh6H gE+iJ0bcTpBRdz9BJrWMMCQdqvxOEKRSWLHU2IzRzQcLz2o7dL1IX12nY43uH6Z9Vg3C 6muQ== X-Gm-Message-State: AOAM532NKr5qNRaSzDpf4g+jAp1ol7iSP4THsm2xOlmDXio9d6TP/uGI v0QCm44i4qX6QXbpBXoSdNBi/kCV15soiiFIP5QbLg== X-Google-Smtp-Source: ABdhPJy7AtKmvoQaM/+Fg8o87ev6vTryIRRZYay3uktBum/ZhiVpIckIRJyVp5de0auQV7YlhfTIQS8xeP29JhDhxHU= X-Received: by 2002:a2e:9d17:: with SMTP id t23mr2180802lji.456.1597442878030; Fri, 14 Aug 2020 15:07:58 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> In-Reply-To: From: Andy Bierman Date: Fri, 14 Aug 2020 15:07:47 -0700 Message-ID: To: Mahesh Jethanandani Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004b62bb05acdda7b5" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 22:08:02 -0000 --0000000000004b62bb05acdda7b5 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 10, 2020 at 2:47 PM Mahesh Jethanandani wrote: > Hi Andy, > > On Aug 10, 2020, at 12:37 PM, Andy Bierman wrote: > > Hi, > > I am trying to understand the NETCONF WG plan for UDP transport of > notifications. > > The WG was developing a UDP draft already I think, and it was dropped. > https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-05 > > > In IETF 103, there was extensive discussion on > draft-ietf-netconf-udp-pub-channel, with questions raised about the scope > of the draft. In IETF 105 and 106, our guidance (see meeting minutes) was > to repurpose the draft for a UDP notification channel, which the WG would > then ultimately adopt. This draft satisfies that request. To clarify this > further, the datatracker marks the new draft as a replacement for the > draft-ietf-netconf-udp-pub-channel. > > I support adoption of this draft. I am willing to work on the document, review it, and implement it. Hopefully the authors will add an example of a notification in each encoding soon. IMO there really should be 1 RFC that combines these documents: draft-unyte-netconf-udp-notif draft-unyte-netconf-distributed-notif draft-ietf-netconf-notification-messages The single source vs. multi-source distinction does not really require separate documents. General one-size-fits-all notification headers are too inefficient to use in a high performance telemetry system. Not sure where notification-messages will ever get used. IMO these 3 documents could be a good protocol, if combined and focused correctly. Mahesh & Kent (as co-chair) > Andy > > > Since the WG dropped this problem and work item already, why should it > reverse that decision > and start over with a new solution? > > > Andy > > > On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen > wrote: > >> NETCONF WG, >> >> Per the previous email sent moments ago, the chairs would like to solicit >> input on the following draft: >> >> Title: UDP-based Transport for Configured Subscriptions >> Link: https://tools.ietf.org/html/draft-unyte-netconf-udp-notif >> Abstract: >> >> This document describes an UDP-based notification mechanism to >> collect data from networking devices. A shim header is proposed to >> facilitate the streaming of data directly from line cards to a >> collector. The objective is to rely on a lightweight approach to >> allow for higher frequency and better transit performance compared >> to >> already established notification mechanisms. >> >> >> In particular, please discuss adoption-suitability as it regards to the >> following questions: >> >> 1) is the problem important for the NETCONF WG to solve? >> 2) is the draft a suitable basis for the work? >> >> >> PS: this message is itself not an adoption poll, but rather an attempt to >> gauge interest/support for a potential future adoption poll. >> >> NETCONF Chairs >> >> _______________________________________________ >> 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 > > > --0000000000004b62bb05acdda7b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 10, 2020 at 2:47 PM Mahes= h Jethanandani <mjethanandani@gmail.com> wrote:
Hi Andy,

On Aug 10, 2020, at 12:37 PM, Andy Bierman <andy@yumaworks.com> wrote:
Hi,

I am trying to understan= d the NETCONF WG plan for UDP transport of notifications.

The WG was developing a UDP draft already I think, and it was dropp= ed.

In IETF 103, there was extensive discussion on draft-ietf-netconf-udp-p= ub-channel, with questions raised about the scope of the draft. In IETF 105= and 106, our guidance (see meeting minutes) was to repurpose the draft for= a UDP notification channel, which the WG would then ultimately adopt. This= draft satisfies that request. To clarify this further, the datatracker mar= ks the new draft as a replacement for the draft-ietf-netconf-udp-pub-channe= l.


I support ado= ption of this draft.
I am willing to work on the document, review= it, and implement it.
Hopefully the authors will add an example = of a notification in each encoding soon.

IMO t= here really should be 1 RFC that combines these documents:

=C2=A0 =C2=A0 =C2=A0draft-unyte-netconf-udp-notif
= =C2=A0 =C2=A0 =C2=A0draft-unyte-netconf-distributed-notif
=C2= =A0 =C2=A0 =C2=A0draft-ietf-netconf-notification-messages
The single source vs. multi-source distinction does not really = require separate documents.
General one-size-fits-all notificatio= n headers are too inefficient to use in
a high performance teleme= try system.=C2=A0 Not sure where notification-messages will ever get used.<= /div>
IMO these 3 documents could be a good protocol, if combined and f= ocused correctly.


Mahesh & Kent (as co-c= hair)


Andy
=
=C2=A0


S= ince the WG dropped this problem and work item already, why should it rever= se that decision
and start over with a new solution?

Andy


On Wed, Aug 5, 2020 = at 3:14 PM Kent Watsen <kent+ietf@watsen..net> wrote:
NETCONF WG,

Per the previous email sent moments ago, the chairs would like to solicit i= nput on the following draft:

=C2=A0 =C2=A0Title: UDP-based Transport for Configured Subscriptions
=C2=A0 =C2=A0Link: https://tools.ietf.org/h= tml/draft-unyte-netconf-udp-notif
=C2=A0 =C2=A0Abstract:

=C2=A0 =C2=A0 =C2=A0 This document describes an UDP-based notification mech= anism to
=C2=A0 =C2=A0 =C2=A0 collect data from networking devices.=C2=A0 A shim hea= der is proposed to
=C2=A0 =C2=A0 =C2=A0 facilitate the streaming of data directly from line ca= rds to a
=C2=A0 =C2=A0 =C2=A0 collector.=C2=A0 The objective is to rely on a lightwe= ight approach to
=C2=A0 =C2=A0 =C2=A0 allow for higher frequency and better transit performa= nce compared to
=C2=A0 =C2=A0 =C2=A0 already established notification mechanisms.


In particular, please discuss adoption-suitability as it regards to the fol= lowing questions:

=C2=A0 =C2=A0 1) is the problem important for the NETCONF WG to solve?
=C2=A0 =C2=A0 2) is the draft a suitable basis for the work?


PS: this message is itself not an adoption poll, but rather an attempt to g= auge interest/support for a potential future adoption poll.

NETCONF Chairs

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

--0000000000004b62bb05acdda7b5-- From nobody Sun Aug 16 03:27:05 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208033A0B39 for ; Sun, 16 Aug 2020 03:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.582 X-Spam-Level: X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 uM1eqcMR9-wD for ; Sun, 16 Aug 2020 03:27:00 -0700 (PDT) Received: from mail.swisscom.com (mailout110.swisscom.com [138.188.166.110]) (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 2DD063A0B34 for ; Sun, 16 Aug 2020 03:26:59 -0700 (PDT) Received: by mail.swisscom.com; Sun, 16 Aug 2020 12:26:47 +0200 Message-ID: <2090004314.1313658.1597573607302@ss007564> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_1313656_1346019717.1597573607302" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cgPflG06WxvkpD9v1g1/5zybwL7R5U9IrYHdgeHk8NkvgX3nswB+FRVtFW4WqJLe7ArFcNfX/iI5n8dOgHmmmypgLKhSmvZ09yGRKo/NwHLChLvUAw7qOxdDFQE/J83S8gAabMtBmXDygXTYmgPaKfo0Y5QXUWx3qIVDVYG0kIwGZ/AkSdxab865TkWygVgc9U1SCuPi0KHtFRrsKNdf5ivVHPT3KRlJrSoaVa4iRn5nE9Mvk+m8vdB5018hicYHs4L/yHx5viN1YUvsNLUxcU6+ITrb0y/nNl2Q3EpruwEjeeFUi2aMcrEn+Vf+pehYhIhWQxRHPDrHFWwicmu7OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aIIrMXvlgEKya6lxKRuisDRvQVl6+jDHFBQAhkUEg3c=; b=jmzulTXP32bq+5fPG+Yfki92d9ix99Fz9owl8r/1gvS1Mo/40W7tTugUK6RiottXcraVNdC96GDrEtP+IQjyby9WFDxcf0MMySs7zReBg34ugouHtZ/jhTWzMJ+JUeq1rOmdbSF6fHXWXz5lPq01ILWUPw0Uz+mG7Dmfo3MYphDxCK6SwBN/ByRSRF8xhd/GnqsbrGEtz574y7nSltRFY9534A/dPRK/kQT2Q+n805qINAxdNrxv2FetNb1aSHEykFUFIBviiw/XAb9BPe/hCX7zRdIRJxaiNR6INapgZEMARGfwxa3Mh/lYaltwxVPHVUpBa+GUL8q1r7L83xmW4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=swisscom.com; dmarc=pass action=none header.from=swisscom.com; dkim=pass header.d=swisscom.com; arc=none From: To: , CC: , , , Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif Thread-Index: AQHWcodX0mBLbRaES02VUjy2aRVTDKk6hC9w Date: Sun, 16 Aug 2020 10:26:44 +0000 References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-08-16T10:26:41.7496918Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=1ab03bcf-c501-4175-b4fc-3af110ad81bc; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; yumaworks.com; dmarc=none action=none header.from=swisscom.com; x-originating-ip: [178.199.12.228] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d5ed3eb3-d198-40d5-dbce-08d841cedff7 x-ms-traffictypediagnostic: ZR0P278MB0122: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CUORWp5zcYsilmC5R6JVfHZq/jAoJhFXQmR91NIkdwSdhESmVhrM8/EqhfTuKU//qJfgeCPZE6krXrfwvi+8MVoBmuZHBmcMhEzXaVJjLo6VmOvl8SYKhDLGC3i5h4ykhYAKGL/EFvXyApyuToC1SgB2k1VjjCMPMua3so2+jxChDCY7vXhCXmHl180zeuveqGgT2VI1ZU+KDD+nIkVmTmaEagdUoUGKEaLYUdAFK8RZyXNIrseJDhCkCAnDN+EBPuCgkcDK7cBOqT0KZlRa6Dc+5hrpxGcXnIrg0yVjak/KAU/ADdsbi4MFwj2T0eeafRcHH9sCTzG8neEXZVM2SoLvTJkHQHXp3ugrtcbok1Ik1bkvdNwqgwjUmwR3F4JAHHNH8tYFQ306y+ldNLR4hg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(136003)(39850400004)(366004)(346002)(9686003)(55016002)(8936002)(66476007)(10300500001)(71200400001)(86362001)(52536014)(66556008)(5660300002)(66446008)(64756008)(76116006)(66946007)(8676002)(966005)(316002)(6506007)(53546011)(26005)(4326008)(2906002)(10290500003)(186003)(166002)(33656002)(7696005)(66574015)(83380400001)(478600001)(110136005)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: WLqHwSM8Xpql7BHz2dv3WBwd0VRHVMe+KwSYb5/WP2iFANFu6Khzp0irbo1AQ6kFKzRP9DYMMcfg5yCv/BMRoyjx0jWSBWnhFobNf78FsPRJtwZMfcDTjT2LEIiSOkLiC51t0mTpbOQ4yguqh40AvWLAW+ZDeJxyLZiLHvQdGeSyRPiDt8043pDnUTR44xwbLLrOBBB/8vvYteN1TrULLWvdbP010SkI4HEetNouA7mDHA08c0PC9tffQxnwdFeCxlpnwdNkNV29IGe5a9ku8C28cXsvYoyjr6fCF0AxceoDYzLhseo4dsCiou0ZWIgF9f0hxI4Th6IPPwMey/MXumR3qLGKqCHWnKEIRT0t0GlW3j4Fz2aEx/HcisVcPpo38eeVwcoNiv+6IMWx8c/5IvA801R0zuk1g4XU8MX2nGcWuqzlOP2sk53MYgAV3EEtXkQRP800c0qmOYNkDxtfzKwmIrVRVWELO6DAtEOYCzRWztBPHtTP4cqK+lO+E+sxS/qM9kUtPT8M+h3iqV1Jbpqnr+T6Sm4SQ9pyE8ON47z0NaaJSUVHDitaKdlo9rIHZsQ/lblXQj4uzn4zPPhzK6xwqN0DE5c8KSy7l6oaI4EjxyzivjVXTTqK5ydlkxjsc+si3z9XOHVlorGN/6mNzg== x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d5ed3eb3-d198-40d5-dbce-08d841cedff7 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2020 10:26:44.8053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YEtagPsiSmFe90S6SbmJS+BLpg401c6azetJAHmDMPvANV+/CpzuYukGR0dsCuM7rh8p56xaZLtvCYYApil9DTdM5oPkY0WSmKKOU8k+OiE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR0P278MB0122 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 10:27:03 -0000 ------=_Part_1313656_1346019717.1597573607302 Content-Type: multipart/alternative; boundary="_000_ZRAP278MB0125F0CD7D31D9E54831982D895E0ZRAP278MB0125CHEP_" Content-Language: en-US --_000_ZRAP278MB0125F0CD7D31D9E54831982D895E0ZRAP278MB0125CHEP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mahesh, Thank you very much for the good summarization. Hi Andy, Thank you very much for the feedback. I am happy to hear that you will revi= ew the document and consider to implement. * Hopefully the authors will add an example of a notification in each e= ncoding soon. Sure, Pierre Fran=E7ois, one of the co-authors and professor at INSA univer= sity and his colleagues already started working on an open-source YANG push= library for the receiver (data-collection) to support udp-notif and distri= buted-notif. We planned to integrate this library into the open-source proj= ect pmacct at IETF 109 hackathon to showcase a working receiver with a firs= t vendor implementation. Further, we are in the evaluation on what environm= ent to build an example open-source publisher which can be taken as referen= ce for other implementations. It would be interesting to understand how we could potentially collaborate.= I think the IETF 109 hackathon would be a good place to work and validate = each other implementation. As we already were doing with BMP (BGP Monitorin= g protocol) in previous IETF hackathons. https://www.ietf.org/proceedings/108/slides/slides-108-grow-ietf-108-hackat= hon-bmp-00. What do you think? Best Wishes Thomas From: netconf On Behalf Of Andy Bierman Sent: Saturday, August 15, 2020 12:08 AM To: Mahesh Jethanandani Cc: netconf@ietf.org Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-not= if On Mon, Aug 10, 2020 at 2:47 PM Mahesh Jethanandani > wrote: Hi Andy, On Aug 10, 2020, at 12:37 PM, Andy Bierman > wrote: Hi, I am trying to understand the NETCONF WG plan for UDP transport of notifica= tions. The WG was developing a UDP draft already I think, and it was dropped. https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-05 In IETF 103, there was extensive discussion on draft-ietf-netconf-udp-pub-c= hannel, with questions raised about the scope of the draft. In IETF 105 and= 106, our guidance (see meeting minutes) was to repurpose the draft for a U= DP notification channel, which the WG would then ultimately adopt. This dra= ft satisfies that request. To clarify this further, the datatracker marks t= he new draft as a replacement for the draft-ietf-netconf-udp-pub-channel. I support adoption of this draft. I am willing to work on the document, review it, and implement it. Hopefully the authors will add an example of a notification in each encodin= g soon. IMO there really should be 1 RFC that combines these documents: draft-unyte-netconf-udp-notif draft-unyte-netconf-distributed-notif draft-ietf-netconf-notification-messages The single source vs. multi-source distinction does not really require sepa= rate documents. General one-size-fits-all notification headers are too inefficient to use i= n a high performance telemetry system. Not sure where notification-messages = will ever get used. IMO these 3 documents could be a good protocol, if combined and focused cor= rectly. Mahesh & Kent (as co-chair) Andy Since the WG dropped this problem and work item already, why should it reve= rse that decision and start over with a new solution? Andy On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen > wrote: NETCONF WG, Per the previous email sent moments ago, the chairs would like to solicit i= nput on the following draft: Title: UDP-based Transport for Configured Subscriptions Link: https://tools.ietf.org/html/draft-unyte-netconf-udp-notif Abstract: This document describes an UDP-based notification mechanism to collect data from networking devices. A shim header is proposed to facilitate the streaming of data directly from line cards to a collector. The objective is to rely on a lightweight approach to allow for higher frequency and better transit performance compared to already established notification mechanisms. In particular, please discuss adoption-suitability as it regards to the fol= lowing questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? PS: this message is itself not an adoption poll, but rather an attempt to g= auge interest/support for a potential future adoption poll. NETCONF Chairs _______________________________________________ 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 --_000_ZRAP278MB0125F0CD7D31D9E54831982D895E0ZRAP278MB0125CHEP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Mahesh,

 =

Thank you very mu= ch for the good summarization.

 =

Hi Andy,

 =

Thank you very mu= ch for the feedback. I am happy to hear that you will review the document a= nd consider to implement.

 =

  • Hopefully the authors will add an example of a n= otification in each encoding soon.

Sure, Pierre Fran=E7ois, one of the co-authors and professor at INSA university and hi= s colleagues already started working on an open-source YANG push library for the receiver (data-collection) to support udp-notif = and distributed-notif. We planned to integrate this library into the open-s= ource project pmacct at IETF 109 hackathon to showcase a working receiver w= ith a first vendor implementation. Further, we are in the evaluation on what environment to build an example = open-source publisher which can be taken as reference for other implementat= ions.

 =

It would be inter= esting to understand how we could potentially collaborate. I think the IETF= 109 hackathon would be a good place to work and validate each other implementation. As we already were doing with BMP (BGP= Monitoring protocol) in previous IETF hackathons.

https://www.ietf.org/proceedings/108/slides/slides-108-grow-ietf-108-= hackathon-bmp-00. What do you think?

 =

Best Wishes<= /o:p>

Thomas=

 

From: netconf <netconf-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: Saturday, August 15, 2020 12:08 AM
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: netconf@ietf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

 

 

 

On Mon, Aug 10, 2020 at 2:47 PM Mahesh Jethanandani = <mjethanand= ani@gmail.com> wrote:

Hi Andy,



On Aug 10, 2020, at 12:37 PM, Andy Bierman <andy@yumaworks.com&g= t; wrote:

 

Hi,

 

I am trying to understand the NETCONF WG plan for UD= P transport of notifications.

 

The WG was developing a UDP draft already I think, a= nd it was dropped.

 

In IETF 103, there was extensive discussion on draft= -ietf-netconf-udp-pub-channel, with questions raised about the scope of the= draft. In IETF 105 and 106, our guidance (see meeting minutes) was to repu= rpose the draft for a UDP notification channel, which the WG would then ultimately adopt. This draft satisfies th= at request. To clarify this further, the datatracker marks the new draft as= a replacement for the draft-ietf-netconf-udp-pub-channel.

 

 

I support adoption of this draft.

I am willing to work on the document, review it, and= implement it.

Hopefully the authors will add an example of a notif= ication in each encoding soon.

 

IMO there really should be 1 RFC that combines these= documents:

 

     draft-unyte-netconf-udp-notif

     draft-unyte-netconf-distributed-= notif

     draft-ietf-netconf-notification-= messages

 

The single source vs. multi-source distinction does = not really require separate documents.

General one-size-fits-all notification headers are t= oo inefficient to use in

a high performance telemetry system.  Not sure = where notification-messages will ever get used.

IMO these 3 documents could be a good protocol, if c= ombined and focused correctly.

 

 

Mahesh & Kent (as co-chair)

 

 

Andy

 



 

Since the WG dropped this problem and work item alre= ady, why should it reverse that decision

and start over with a new solution?

 

 

Andy

 

 

On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen <kent+ietf@watsen..ne= t> wrote:

NETCONF WG,

Per the previous email sent moments ago, the chairs would like to solicit i= nput on the following draft:

   Title: UDP-based Transport for Configured Subscriptions
   Link: https://tools.ietf.org/html/draft-unyte-netconf-udp-notif
   Abstract:

      This document describes an UDP-based notification mech= anism to
      collect data from networking devices.  A shim hea= der is proposed to
      facilitate the streaming of data directly from line ca= rds to a
      collector.  The objective is to rely on a lightwe= ight approach to
      allow for higher frequency and better transit performa= nce compared to
      already established notification mechanisms.


In particular, please discuss adoption-suitability as it regards to the fol= lowing questions:

    1) is the problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the work?


PS: this message is itself not an adoption poll, but rather an attempt to g= auge interest/support for a potential future adoption poll.

NETCONF Chairs

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

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

 

--_000_ZRAP278MB0125F0CD7D31D9E54831982D895E0ZRAP278MB0125CHEP_-- ------=_Part_1313656_1346019717.1597573607302 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIG QTCCBSmgAwIBAgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFs IFNpbHZlciBDQSAyMDE0IC0gRzIyMB4XDTE5MDQxMTE2NDgyOFoXDTIyMDQxMTE2NDgyOFowgYEx CzAJBgNVBAYTAkNIMR4wHAYDVQQKExVTd2lzc2NvbSAoU2Nod2VpeikgQUcxJzAlBgkqhkiG9w0B CQEWGHRob21hcy5ncmFmQHN3aXNzY29tLmNvbTEpMCcGA1UEAxMgU2VjdXJlIE1haWw6IEdhdGV3 YXkgQ2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCITr0/mumt/DE7 c8RDgwoi0IdMVLbGMQ1wzpjZ23C3KaauDnIDCAdgwJCj8H/4hy8Wj/EoKvbnJXc3DN/g5n4MyujX JjsLMo3cMaHqTSql2zKFsdFRnjNtOTEQMVleqnKgeiLwF5M+QpZGhS9T9M4br9PCKBEdwZ+BJRJN XPtxUjJWLh7ueFbMApS5lOryeoZrv9Yi6D5xSGErBuPrzn1ekUMzOfycZ4HcyLaEfzGNgYEax2yS 1/ZcM/qoj7k8e6dskfB6/PkFnf5BfWqwfWtmqn7PRJQQAEmjkJafFZNtvlyJ/ktjpI+pnju1AZaA c+LNL1eT1rwNdesrljxik/plAgMBAAGjggLZMIIC1TAjBgNVHREEHDAagRh0aG9tYXMuZ3JhZkBz d2lzc2NvbS5jb20wDgYDVR0PAQH/BAQDAgSwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQW BBTAJbWmkqWsxJzHeilKdMU8NUhnwzAfBgNVHSMEGDAWgBTwx6MykbXryrVYdxWnTr4aXWFDJTCB /wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2lnbi5uZXQvRjBDN0EzMzI5MUI1 RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTCBqKCBpaCBooaBn2xkYXA6Ly9kaXJlY3Rvcnku c3dpc3NzaWduLm5ldC9DTj1GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1 JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBrBgNVHSAEZDBiMFYGCWCFdAFZAQMBCzBJMEcG CCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1TaWx2 ZXItQ1AtQ1BTLnBkZjAIBgYEAI96AQMwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlho dHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkx QjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVy LXBlcnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVB NzRFQkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQBPAGaURtN/46Vopba1sQJzad0O2JxG 8MwpE2F435dz+BfK/L8DGWN+EmWQV9k/p/IhNLFnj9WhBdd+iuscOT83XDCnUzyYiNqz7bhrQAEm B/87tdMsPhq5wUz5XfpnDcsSiQ1r/Woo+baMSN60QruEZM/be9mFILGOByV8BEwVbZTAiL7cLaOh bxUfQubFvyfOZ1HgJMVyfWizDVvDG2rL6YkWtsIBaVmCYGBqHrX0wSLyHlRNnbqiM2vawqQYme+1 +wxtbGCPPexp3wUBqpJde40Ke1xIpMj8c1kyvtaRM3CBX2p6xl0XHnSrybkJUidmaZnblUM6O18u b28x6Qp3MIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2 ZXIgQ0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNI MRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2 ZXIgQ0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJ obzDg6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDv ALLrEzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2 Yru5aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5r gtmQDAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kV mJyUU8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQX oM3B5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNz c2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCB ooaBn2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIz QkNCNDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAE WjBYMFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3Np Z24uY29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYI KwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2Fk LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0 dHA6Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5 OEZBODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkd aI3KCNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsp onPel/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZ VKIhjfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0 wl+S4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8 u7mOlL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQ wJtEQK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/ mpaG/ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8 N43xHm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4 Fg9q2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uowggW9MIIDpaADAgECAghPG9QvVLsvSzANBgkqhkiG 9w0BAQUFADBHMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhT d2lzc1NpZ24gU2lsdmVyIENBIC0gRzIwHhcNMDYxMDI1MDgzMjQ2WhcNMzYxMDI1MDgzMjQ2WjBH MQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhTd2lzc1NpZ24g U2lsdmVyIENBIC0gRzIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDE8Yd/03gx9zjJ +MOZQ7zH97w3505xukuPpXMdXG6YrgNXrjg3Qy8XPR/IzmgQwXiuGQMrEPoseYP26LlouVXyBESn Ofn8BIse8aJNJ/lhe7q35aITtuthPtBs0eb7+l7tHbSeoDVboZLL8EmS/oUKBT7m2QviT7vclTf8 kekyNSLRHzpOJ4WdsBWUMtphDUdNYEKukkfog1pQWOmKi7ldodzdmUofNme7SOSDtjfrSDqvD2eP FwfoBMrvajGH1MC2+ZRxe2dkuLaRSkJ7ZS4wagz1kO6V5vLNguzZoUrs9rJL5UWF5m14kwQunIJt NqnEMWQfhoMLKvQ1CnjJVc9BsEfpMJ+ZvmGoBoS5KHpfONkbqTiwg39zwcM7SCqCDyGbuMyoNcOE G4OzPr6klWkBOokAeATZyfSZGatWfluLhjkVkaQQLAkygGCzk8AqthgLnX6NSfIQSn/51UYvGZKj macmrLuMPOYOvEcH3HNR8XBkLwj5tEcdMGxE6ik3hZJoZryDOP57OS7TUPAf+15gtqmm+idB8ZsY cvL1hHRKyWfEVK5IZN+M0W6wHeEHjwgemZxx6UzYpfdHEh900VGehvPCoiNAC3PbS6bncwaMwaDp wVmsRvrmL/jPcZxGbbnEFY04eQNFSO/EXdcI7oc5IoayDQ9YQ/dxqUgu/erWHwIDAQABo4GsMIGp MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQXoM3B5EG2Ols7y0Wd vRzCmPqGWDAfBgNVHSMEGDAWgBQXoM3B5EG2Ols7y0WdvRzCmPqGWDBGBgNVHSAEPzA9MDsGCWCF dAFZAQMBATAuMCwGCCsGAQUFBwIBFiBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tLzAN BgkqhkiG9w0BAQUFAAOCAgEAc8aB4CfSLQ/glTDimkF/UCxfX2JhqYZqaRgMdEnWXYTqQVIYb1it UFYgasa9KGlYkdyRETWpOh28GqVgntgff0WRadl+u3hywQYPKs6PhXBhrKDNC7g5KVaEMk6Guz3E KtnXH3Lu/lGhIkGxcQJjGoKwYqteVxIf38vddaDAXXmQjBvgUObeMf6Ye3BfpZDYrfgCtm/TYN1A SyLFPa06ep8aGkeReTO6gtwyaQOWbh9L8HH+42dyoLG/XIvk+pkix4S5G40jlz/tJeDPZbv1YQTv 3R6yWkEiWqGfXSzoW8ltqQwMeKpgxlaPAVoMaLxpGXnEH36XBb/F6SRRXtTVS1Pt2SNaNgNlo8ED rUEw80YbhZCvZbXVseQWW3h1HZd6bVmpKo973sOHiRCZSXN4yD29UTV0KtXxfmkbKrs7vSW4mlo9 cmGQZofuDNZN1BF0C2r+CwP8o1VXif5Ky65bFwXI8o0jMVM40i1qP4K5jQhq915BdG7DEX4HrClg kT84ylcQDb0wL8el5kGg2q4Fh5qgpGVsTAkMibq407nAk4ow+o3lmmsVAU5nqtpiVj6ECGbSxDZ9 pz4Q/Ijg1IDlAL2q804Go3pq+WJy4wlP65sOASPxn7t83NxsEZclsvK0YxTSBipnjIP1zuoH2Jpq HuzkCrsqTOsJYDnOymLYLm4AADGCA90wggPZAgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAkAwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODE2MTAyNjQ3WjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCDkedBn 6oe5/P+4BExh0+Ml7vnIQ+sW/sEJj6AaPOpD/jB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gaUGCSqGSIb3DQEJDzGBlzCBlDALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAKBggqhkiG9w0DAjAKBggqhkiG9w0DAjAHBgUrDgMCBzAKBggqhkiG9w0D AjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgQwDQYJ KoZIhvcNAQELBQAEggEAhNk3VECrZ5ObjsI/uY7mSdmrOBltzdCXbaHyLjODM2olDkLSTdNmfNRk IUyj4bgl4ueZJTU4jyBWPpPKASBkWDBeNifd4vnENzF3JjqUjfztlQpn6vXq+9Mu3h9Krc8mAT+X zrSBPhqjKqojwk+96r76cvuhYYPz4k3uYkO0L1hmu09FXqEVDd7/EE/p/sep8oJOBVKmd8zNzfDs WvD9PD5gN8NAsHkJyCcojyNaV4+oRlvgzQwTcq8ys3Fmrb77og06EPpJlnc3INOon4s7wFBO3oKX UwrvYV279L0iNJCzJnQLE5zfvJUHmwzS6ZZ0b0SBcj0dujSh0Tz+pjTE6wAAAAAAAA== ------=_Part_1313656_1346019717.1597573607302-- From nobody Sun Aug 16 20:23:49 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289793A0866 for ; Sun, 16 Aug 2020 20:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boUm2K7OF81n for ; Sun, 16 Aug 2020 20:23:46 -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 C446E3A0865 for ; Sun, 16 Aug 2020 20:23:45 -0700 (PDT) Received: from lhreml709-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 32B3A889E4105D792505; Mon, 17 Aug 2020 04:23:44 +0100 (IST) Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 17 Aug 2020 04:23:43 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 17 Aug 2020 11:23:40 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Mon, 17 Aug 2020 11:23:40 +0800 From: Tianran Zhou To: Andy Bierman , Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif Thread-Index: AQHWa3XJ0mBLbRaES02VUjy2aRVTDKkxPlqAgAAkPACABk8RgIAD/vmA Date: Mon, 17 Aug 2020 03:23:40 +0000 Message-ID: <1b59196e6b3347e7b6eaf5aa4fa6ffe0@huawei.com> References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.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.108.243.128] Content-Type: multipart/alternative; boundary="_000_1b59196e6b3347e7b6eaf5aa4fa6ffe0huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 03:23:48 -0000 --_000_1b59196e6b3347e7b6eaf5aa4fa6ffe0huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBpbnRlcmVzdC4NClRoZSB0 d28gZHJhZnRzIHdhcyBvbmUgd2hlbiBpdCBmaXJzdCBjYW1lIG91dC4NCiBkcmFmdC11bnl0ZS1u ZXRjb25mLXVkcC1ub3RpZg0KZHJhZnQtdW55dGUtbmV0Y29uZi1kaXN0cmlidXRlZC1ub3RpZg0K V2Ugc3BsaXQgaXQgYmFzZWQgb24gdGhlIFdHIGRpc2N1c3Npb24sIHNvIHRoYXQgdGhlIGRpc3Ry aWJ1dGVkLW5vdGlmIGNhbiBhbHNvIHNlcnZlIHRoZSB0Y3AgYmFzZWQgbm90aWYuDQoNCkN1cnJl bnQgZGlzdHJpYnV0ZWQtbm90aWYgc29sdXRpb24gZGVwZW5kcyBvbiBkcmFmdC1pZXRmLW5ldGNv bmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzLiBCdXQgSSBiZWxpZXZlIGRyYWZ0LWlldGYtbmV0Y29u Zi1ub3RpZmljYXRpb24tbWVzc2FnZXMgdHJpZXMgdG8gc29sdmUgbW9yZSBwcm9ibGVtcyBpbiBh ZGRpdGlvbiB0byBkaXN0cmlidXRlZC1ub3RpZi4NCg0KT24geW91ciBzdWdnZXN0aW9uLCBJIHRo aW5rIHdlIGNhbiB3b3JrIG9uIGFuIHByb2ZpbGUgb3IgYXBwbGljYWJpbGl0eSwgdG8gc2VlIGhv dyB0aGV5IGNhbiB3b3JrIHRvZ2V0aGVyLg0KDQpUaGFua3MsDQpUaWFucmFuDQoNCkZyb206IG5l dGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5 IEJpZXJtYW4NClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMTUsIDIwMjAgNjowOCBBTQ0KVG86IE1h aGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KQ2M6IG5ldGNvbmZA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9y IGRyYWZ0LXVueXRlLW5ldGNvbmYtdWRwLW5vdGlmDQoNCg0KDQpPbiBNb24sIEF1ZyAxMCwgMjAy MCBhdCAyOjQ3IFBNIE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29t PG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdyb3RlOg0KSGkgQW5keSwNCg0KDQpP biBBdWcgMTAsIDIwMjAsIGF0IDEyOjM3IFBNLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtz LmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4gd3JvdGU6DQoNCkhpLA0KDQpJIGFtIHRy eWluZyB0byB1bmRlcnN0YW5kIHRoZSBORVRDT05GIFdHIHBsYW4gZm9yIFVEUCB0cmFuc3BvcnQg b2Ygbm90aWZpY2F0aW9ucy4NCg0KVGhlIFdHIHdhcyBkZXZlbG9waW5nIGEgVURQIGRyYWZ0IGFs cmVhZHkgSSB0aGluaywgYW5kIGl0IHdhcyBkcm9wcGVkLg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi11ZHAtcHViLWNoYW5uZWwtMDUNCg0KSW4gSUVURiAx MDMsIHRoZXJlIHdhcyBleHRlbnNpdmUgZGlzY3Vzc2lvbiBvbiBkcmFmdC1pZXRmLW5ldGNvbmYt dWRwLXB1Yi1jaGFubmVsLCB3aXRoIHF1ZXN0aW9ucyByYWlzZWQgYWJvdXQgdGhlIHNjb3BlIG9m IHRoZSBkcmFmdC4gSW4gSUVURiAxMDUgYW5kIDEwNiwgb3VyIGd1aWRhbmNlIChzZWUgbWVldGlu ZyBtaW51dGVzKSB3YXMgdG8gcmVwdXJwb3NlIHRoZSBkcmFmdCBmb3IgYSBVRFAgbm90aWZpY2F0 aW9uIGNoYW5uZWwsIHdoaWNoIHRoZSBXRyB3b3VsZCB0aGVuIHVsdGltYXRlbHkgYWRvcHQuIFRo aXMgZHJhZnQgc2F0aXNmaWVzIHRoYXQgcmVxdWVzdC4gVG8gY2xhcmlmeSB0aGlzIGZ1cnRoZXIs IHRoZSBkYXRhdHJhY2tlciBtYXJrcyB0aGUgbmV3IGRyYWZ0IGFzIGEgcmVwbGFjZW1lbnQgZm9y IHRoZSBkcmFmdC1pZXRmLW5ldGNvbmYtdWRwLXB1Yi1jaGFubmVsLg0KDQoNCkkgc3VwcG9ydCBh ZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KSSBhbSB3aWxsaW5nIHRvIHdvcmsgb24gdGhlIGRvY3Vt ZW50LCByZXZpZXcgaXQsIGFuZCBpbXBsZW1lbnQgaXQuDQpIb3BlZnVsbHkgdGhlIGF1dGhvcnMg d2lsbCBhZGQgYW4gZXhhbXBsZSBvZiBhIG5vdGlmaWNhdGlvbiBpbiBlYWNoIGVuY29kaW5nIHNv b24uDQoNCklNTyB0aGVyZSByZWFsbHkgc2hvdWxkIGJlIDEgUkZDIHRoYXQgY29tYmluZXMgdGhl c2UgZG9jdW1lbnRzOg0KDQogICAgIGRyYWZ0LXVueXRlLW5ldGNvbmYtdWRwLW5vdGlmDQogICAg IGRyYWZ0LXVueXRlLW5ldGNvbmYtZGlzdHJpYnV0ZWQtbm90aWYNCiAgICAgZHJhZnQtaWV0Zi1u ZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcw0KDQpUaGUgc2luZ2xlIHNvdXJjZSB2cy4gbXVs dGktc291cmNlIGRpc3RpbmN0aW9uIGRvZXMgbm90IHJlYWxseSByZXF1aXJlIHNlcGFyYXRlIGRv Y3VtZW50cy4NCkdlbmVyYWwgb25lLXNpemUtZml0cy1hbGwgbm90aWZpY2F0aW9uIGhlYWRlcnMg YXJlIHRvbyBpbmVmZmljaWVudCB0byB1c2UgaW4NCmEgaGlnaCBwZXJmb3JtYW5jZSB0ZWxlbWV0 cnkgc3lzdGVtLiAgTm90IHN1cmUgd2hlcmUgbm90aWZpY2F0aW9uLW1lc3NhZ2VzIHdpbGwgZXZl ciBnZXQgdXNlZC4NCklNTyB0aGVzZSAzIGRvY3VtZW50cyBjb3VsZCBiZSBhIGdvb2QgcHJvdG9j b2wsIGlmIGNvbWJpbmVkIGFuZCBmb2N1c2VkIGNvcnJlY3RseS4NCg0KDQpNYWhlc2ggJiBLZW50 IChhcyBjby1jaGFpcikNCg0KDQpBbmR5DQoNCg0KDQoNClNpbmNlIHRoZSBXRyBkcm9wcGVkIHRo aXMgcHJvYmxlbSBhbmQgd29yayBpdGVtIGFscmVhZHksIHdoeSBzaG91bGQgaXQgcmV2ZXJzZSB0 aGF0IGRlY2lzaW9uDQphbmQgc3RhcnQgb3ZlciB3aXRoIGEgbmV3IHNvbHV0aW9uPw0KDQoNCkFu ZHkNCg0KDQpPbiBXZWQsIEF1ZyA1LCAyMDIwIGF0IDM6MTQgUE0gS2VudCBXYXRzZW4gPGtlbnQr aWV0ZkB3YXRzZW4uLm5ldDxtYWlsdG86a2VudCUyQmlldGZAd2F0c2VuLm5ldD4+IHdyb3RlOg0K TkVUQ09ORiBXRywNCg0KUGVyIHRoZSBwcmV2aW91cyBlbWFpbCBzZW50IG1vbWVudHMgYWdvLCB0 aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gc29saWNpdCBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRy YWZ0Og0KDQogICBUaXRsZTogVURQLWJhc2VkIFRyYW5zcG9ydCBmb3IgQ29uZmlndXJlZCBTdWJz Y3JpcHRpb25zDQogICBMaW5rOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdW55 dGUtbmV0Y29uZi11ZHAtbm90aWYNCiAgIEFic3RyYWN0Og0KDQogICAgICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBhbiBVRFAtYmFzZWQgbm90aWZpY2F0aW9uIG1lY2hhbmlzbSB0bw0KICAgICAg Y29sbGVjdCBkYXRhIGZyb20gbmV0d29ya2luZyBkZXZpY2VzLiAgQSBzaGltIGhlYWRlciBpcyBw cm9wb3NlZCB0bw0KICAgICAgZmFjaWxpdGF0ZSB0aGUgc3RyZWFtaW5nIG9mIGRhdGEgZGlyZWN0 bHkgZnJvbSBsaW5lIGNhcmRzIHRvIGENCiAgICAgIGNvbGxlY3Rvci4gIFRoZSBvYmplY3RpdmUg aXMgdG8gcmVseSBvbiBhIGxpZ2h0d2VpZ2h0IGFwcHJvYWNoIHRvDQogICAgICBhbGxvdyBmb3Ig aGlnaGVyIGZyZXF1ZW5jeSBhbmQgYmV0dGVyIHRyYW5zaXQgcGVyZm9ybWFuY2UgY29tcGFyZWQg dG8NCiAgICAgIGFscmVhZHkgZXN0YWJsaXNoZWQgbm90aWZpY2F0aW9uIG1lY2hhbmlzbXMuDQoN Cg0KSW4gcGFydGljdWxhciwgcGxlYXNlIGRpc2N1c3MgYWRvcHRpb24tc3VpdGFiaWxpdHkgYXMg aXQgcmVnYXJkcyB0byB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczoNCg0KICAgIDEpIGlzIHRoZSBw cm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cgdG8gc29sdmU/DQogICAgMikgaXMg dGhlIGRyYWZ0IGEgc3VpdGFibGUgYmFzaXMgZm9yIHRoZSB3b3JrPw0KDQoNClBTOiB0aGlzIG1l c3NhZ2UgaXMgaXRzZWxmIG5vdCBhbiBhZG9wdGlvbiBwb2xsLCBidXQgcmF0aGVyIGFuIGF0dGVt cHQgdG8gZ2F1Z2UgaW50ZXJlc3Qvc3VwcG9ydCBmb3IgYSBwb3RlbnRpYWwgZnV0dXJlIGFkb3B0 aW9uIHBvbGwuDQoNCk5FVENPTkYgQ2hhaXJzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpuZXRjb25mIG1haWxpbmcgbGlzdA0KbmV0Y29uZkBpZXRm Lm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm5ldGNvbmYgbWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYub3JnPG1haWx0 bzpuZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mDQoNCg== --_000_1b59196e6b3347e7b6eaf5aa4fa6ffe0huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5I aSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmsg eW91IHZlcnkgbXVjaCBmb3IgeW91ciBpbnRlcmVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIHR3 byBkcmFmdHMgd2FzIG9uZSB3aGVuIGl0IGZpcnN0IGNhbWUgb3V0LiZuYnNwOw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwO2RyYWZ0LXVueXRlLW5ldGNvbmYtdWRwLW5vdGlmPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPmRyYWZ0LXVueXRlLW5ldGNvbmYtZGlzdHJpYnV0ZWQtbm90aWY8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+V2Ugc3BsaXQgaXQgYmFzZWQgb24gdGhlIFdHIGRpc2N1c3Npb24sIHNvIHRoYXQgdGhl IGRpc3RyaWJ1dGVkLW5vdGlmIGNhbiBhbHNvIHNlcnZlIHRoZSB0Y3AgYmFzZWQgbm90aWYuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DdXJyZW50IGRpc3RyaWJ1 dGVkLW5vdGlmIHNvbHV0aW9uIGRlcGVuZHMgb24gZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNh dGlvbi1tZXNzYWdlcy4gQnV0IEkgYmVsaWV2ZSBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0 aW9uLW1lc3NhZ2VzIHRyaWVzIHRvIHNvbHZlDQogbW9yZSBwcm9ibGVtcyBpbiBhZGRpdGlvbiB0 byBkaXN0cmlidXRlZC1ub3RpZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPk9uIHlvdXIgc3VnZ2VzdGlvbiwgSSB0aGluayB3ZSBjYW4gd29yayBvbiBhbiBwcm9m aWxlIG9yIGFwcGxpY2FiaWxpdHksIHRvIHNlZSBob3cgdGhleSBjYW4gd29yayB0b2dldGhlci48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGlhbnJhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJtYW48YnI+DQo8Yj5T ZW50OjwvYj4gU2F0dXJkYXksIEF1Z3VzdCAxNSwgMjAyMCA2OjA4IEFNPGJyPg0KPGI+VG86PC9i PiBNYWhlc2ggSmV0aGFuYW5kYW5pICZsdDttamV0aGFuYW5kYW5pQGdtYWlsLmNvbSZndDs8YnI+ DQo8Yj5DYzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtu ZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0Y29uZi11ZHAt bm90aWY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEF1 ZyAxMCwgMjAyMCBhdCAyOjQ3IFBNIE1haGVzaCBKZXRoYW5hbmRhbmkgJmx0OzxhIGhyZWY9Im1h aWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1qZXRoYW5hbmRh bmlAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQW5keSw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEF1ZyAxMCwgMjAyMCwgYXQgMTI6 MzcgUE0sIEFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIHRyeWluZyB0byB1bmRlcnN0 YW5kIHRoZSBORVRDT05GIFdHIHBsYW4gZm9yIFVEUCB0cmFuc3BvcnQgb2Ygbm90aWZpY2F0aW9u cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIFdHIHdhcyBkZXZlbG9waW5nIGEgVURQIGRyYWZ0IGFscmVhZHkgSSB0aGluaywgYW5kIGl0 IHdhcyBkcm9wcGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bmV0Y29uZi11ZHAtcHViLWNoYW5uZWwtMDUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXVkcC1wdWItY2hhbm5lbC0wNTwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gSUVURiAxMDMsIHRoZXJlIHdhcyBleHRlbnNpdmUgZGlz Y3Vzc2lvbiBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtdWRwLXB1Yi1jaGFubmVsLCB3aXRoIHF1ZXN0 aW9ucyByYWlzZWQgYWJvdXQgdGhlIHNjb3BlIG9mIHRoZSBkcmFmdC4gSW4gSUVURiAxMDUgYW5k IDEwNiwgb3VyIGd1aWRhbmNlIChzZWUgbWVldGluZyBtaW51dGVzKSB3YXMgdG8gcmVwdXJwb3Nl IHRoZSBkcmFmdCBmb3IgYSBVRFAgbm90aWZpY2F0aW9uDQogY2hhbm5lbCwgd2hpY2ggdGhlIFdH IHdvdWxkIHRoZW4gdWx0aW1hdGVseSBhZG9wdC4gVGhpcyBkcmFmdCBzYXRpc2ZpZXMgdGhhdCBy ZXF1ZXN0LiBUbyBjbGFyaWZ5IHRoaXMgZnVydGhlciwgdGhlIGRhdGF0cmFja2VyIG1hcmtzIHRo ZSBuZXcgZHJhZnQgYXMgYSByZXBsYWNlbWVudCBmb3IgdGhlIGRyYWZ0LWlldGYtbmV0Y29uZi11 ZHAtcHViLWNoYW5uZWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN1cHBvcnQgYWRvcHRpb24g b2YgdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgYW0gd2lsbGluZyB0byB3b3JrIG9uIHRoZSBkb2N1bWVudCwgcmV2aWV3IGl0 LCBhbmQgaW1wbGVtZW50IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SG9wZWZ1bGx5IHRoZSBhdXRob3JzIHdpbGwgYWRkIGFuIGV4YW1wbGUg b2YgYSBub3RpZmljYXRpb24gaW4gZWFjaCBlbmNvZGluZyBzb29uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8gdGhlcmUgcmVhbGx5IHNo b3VsZCBiZSAxIFJGQyB0aGF0IGNvbWJpbmVzIHRoZXNlIGRvY3VtZW50czo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAm bmJzcDtkcmFmdC11bnl0ZS1uZXRjb25mLXVkcC1ub3RpZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC11 bnl0ZS1uZXRjb25mLWRpc3RyaWJ1dGVkLW5vdGlmPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWlldGYt bmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNpbmdsZSBzb3VyY2UgdnMuIG11bHRpLXNv dXJjZSBkaXN0aW5jdGlvbiBkb2VzIG5vdCByZWFsbHkgcmVxdWlyZSBzZXBhcmF0ZSBkb2N1bWVu dHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5H ZW5lcmFsIG9uZS1zaXplLWZpdHMtYWxsIG5vdGlmaWNhdGlvbiBoZWFkZXJzIGFyZSB0b28gaW5l ZmZpY2llbnQgdG8gdXNlIGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5hIGhpZ2ggcGVyZm9ybWFuY2UgdGVsZW1ldHJ5IHN5c3RlbS4mbmJzcDsg Tm90IHN1cmUgd2hlcmUgbm90aWZpY2F0aW9uLW1lc3NhZ2VzIHdpbGwgZXZlciBnZXQgdXNlZC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNTyB0 aGVzZSAzIGRvY3VtZW50cyBjb3VsZCBiZSBhIGdvb2QgcHJvdG9jb2wsIGlmIGNvbWJpbmVkIGFu ZCBmb2N1c2VkIGNvcnJlY3RseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1haGVzaCAmYW1wOyBLZW50 IChhcyBjby1jaGFpcik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5jZSB0aGUgV0cgZHJvcHBlZCB0aGlzIHByb2JsZW0gYW5k IHdvcmsgaXRlbSBhbHJlYWR5LCB3aHkgc2hvdWxkIGl0IHJldmVyc2UgdGhhdCBkZWNpc2lvbjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHN0 YXJ0IG92ZXIgd2l0aCBhIG5ldyBzb2x1dGlvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBdWcgNSwgMjAyMCBhdCAz OjE0IFBNIEtlbnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a2VudCUyQmlldGZAd2F0c2Vu Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmtlbnQmIzQzO2lldGZAd2F0c2VuLi5uZXQ8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk5FVENPTkYgV0csPGJyPg0KPGJyPg0KUGVyIHRoZSBwcmV2aW91cyBlbWFpbCBzZW50 IG1vbWVudHMgYWdvLCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gc29saWNpdCBpbnB1dCBvbiB0 aGUgZm9sbG93aW5nIGRyYWZ0Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaXRsZTogVURQLWJh c2VkIFRyYW5zcG9ydCBmb3IgQ29uZmlndXJlZCBTdWJzY3JpcHRpb25zPGJyPg0KJm5ic3A7ICZu YnNwO0xpbms6IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC11bnl0 ZS1uZXRjb25mLXVkcC1ub3RpZiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXVueXRlLW5ldGNvbmYtdWRwLW5vdGlmPC9hPjxicj4NCiZuYnNwOyAm bmJzcDtBYnN0cmFjdDo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBhbiBVRFAtYmFzZWQgbm90aWZpY2F0aW9uIG1lY2hhbmlzbSB0bzxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbGxlY3QgZGF0YSBmcm9tIG5ldHdvcmtpbmcgZGV2aWNl cy4mbmJzcDsgQSBzaGltIGhlYWRlciBpcyBwcm9wb3NlZCB0bzxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IGZhY2lsaXRhdGUgdGhlIHN0cmVhbWluZyBvZiBkYXRhIGRpcmVjdGx5IGZyb20gbGlu ZSBjYXJkcyB0byBhPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29sbGVjdG9yLiZuYnNwOyBU aGUgb2JqZWN0aXZlIGlzIHRvIHJlbHkgb24gYSBsaWdodHdlaWdodCBhcHByb2FjaCB0bzxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFsbG93IGZvciBoaWdoZXIgZnJlcXVlbmN5IGFuZCBiZXR0 ZXIgdHJhbnNpdCBwZXJmb3JtYW5jZSBjb21wYXJlZCB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IGFscmVhZHkgZXN0YWJsaXNoZWQgbm90aWZpY2F0aW9uIG1lY2hhbmlzbXMuPGJyPg0KPGJy Pg0KPGJyPg0KSW4gcGFydGljdWxhciwgcGxlYXNlIGRpc2N1c3MgYWRvcHRpb24tc3VpdGFiaWxp dHkgYXMgaXQgcmVnYXJkcyB0byB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczo8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7IDEpIGlzIHRoZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYg V0cgdG8gc29sdmU/PGJyPg0KJm5ic3A7ICZuYnNwOyAyKSBpcyB0aGUgZHJhZnQgYSBzdWl0YWJs ZSBiYXNpcyBmb3IgdGhlIHdvcms/PGJyPg0KPGJyPg0KPGJyPg0KUFM6IHRoaXMgbWVzc2FnZSBp cyBpdHNlbGYgbm90IGFuIGFkb3B0aW9uIHBvbGwsIGJ1dCByYXRoZXIgYW4gYXR0ZW1wdCB0byBn YXVnZSBpbnRlcmVzdC9zdXBwb3J0IGZvciBhIHBvdGVudGlhbCBmdXR1cmUgYWRvcHRpb24gcG9s bC48YnI+DQo8YnI+DQpORVRDT05GIENoYWlyczxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0Y29uZiBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5l dGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRjb25m QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_1b59196e6b3347e7b6eaf5aa4fa6ffe0huaweicom_-- From nobody Mon Aug 17 20:16:33 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F623A16CC for ; Mon, 17 Aug 2020 20:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfmqeiFJt85S for ; Mon, 17 Aug 2020 20:16:30 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 B27EB3A16D2 for ; Mon, 17 Aug 2020 20:16:30 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id x69so17071936qkb.1 for ; Mon, 17 Aug 2020 20:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=bcAYJbMtv4U2cnqxbxqnQYqU1JPfyk55nER3B6UA8SQ=; b=DwqhntpqbB5sCzL3cVjSidN3cajUC0b1rjmVDBmgQk03wh6jlORnpUKcKjVYMvUgcQ GFOMcn1YpjZRVmvamRrYAco+ydYjuQa2pouma19zLqmOSFrLqmeTsSbIexoNtrkqXTY+ 06J10tvHxmx0TPBQxLJB+aUNWRmtrflAxhgNc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=bcAYJbMtv4U2cnqxbxqnQYqU1JPfyk55nER3B6UA8SQ=; b=rYvji+yYbmPy+gbln1Cq1JxeusB/NgfLTSdKm8eN+j2FKM/8cyaU/ug6ofH2uX1XX3 rDl3z0SQ2PGxkscNCpTOW9/rjPxicoHmPPANQMaGngMLu6seOPAFnQSjLuawnKp9VInO OFkWjPK9LXFhpvIJbKwa7au81PN/B+eYBifqAtZ2Fl/vEb7GmdZ1A9J3cWkYXtBvLMSe RbB3c5BtIx2OF+Meo8MgGwXXSQZvz2JO+l9J7ui5A9aEV2bunGgnfPK0IMLTuX6ovAcP yp9KKfqqg2pWpYu13Q6RFn3BYdq4mSyuCG1nzfkMReJdnxf50QgjqesXWmfkks9cCx/J cSRQ== X-Gm-Message-State: AOAM5318jOEqOuGLDVpsk7g42sFSo1AK1YARzFuTmM3a5YJYdlle8HNI ugowRbTRFTgmgOfEWVw5o0UPwV5jAtYbtg== X-Google-Smtp-Source: ABdhPJyPwq0x9SixtHfESAUXOxlJe7VbxlhgwN8DZt3E22YJlrxPKo3IbD3EsthQmCxrN2B+1eoIPQ== X-Received: by 2002:a37:6583:: with SMTP id z125mr15603958qkb.297.1597720589161; Mon, 17 Aug 2020 20:16:29 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id h55sm22906359qte.16.2020.08.17.20.16.27 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2020 20:16:28 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 17 Aug 2020 23:16:20 -0400 References: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> <01000173cabb057c-4236d605-0617-411c-a237-cd60f7545b79-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <01000173cabb057c-4236d605-0617-411c-a237-cd60f7545b79-000000@email.amazonses.com> Message-Id: <9F62FC91-14A9-4FDB-83F4-6DC2C0C17B6C@sn3rd.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 03:16:32 -0000 > NETCONF WG, > > Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft: > Title: Conveying a CSR in an SZTP Bootstrapping Request > Link: https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr > Abstract: > > This draft extends the "get-bootstrapping-data" RPC defined in > RFC 8572 to include an optional certificate signing request = (CSR), > enabling a bootstrapping device to additionally obtain an = identity > certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the > "onboarding information" response provided in the RPC-reply. > > In particular, please discuss adoption-suitability as it regards to = the following questions: > > 1) is the problem important for the NETCONF WG to solve? My reading of the charter puts this squarely in scope for the WG. = Configuring an LDevID certificate as part of the bootstrap is important = and the most straightforward way to do this is authentication based on = IDevID. > 2) is the draft a suitable basis for the work? I am a wee bit biased as an author I think this is a good a first draft. = It would obviously be good to get some additional eyes on it though. spt From nobody Tue Aug 18 04:14:23 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EC13A08A9 for ; Tue, 18 Aug 2020 04:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JOcLrfxL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=apt4dKVl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok1jZI3wyvxM for ; Tue, 18 Aug 2020 04:14:19 -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 5B7F13A08A5 for ; Tue, 18 Aug 2020 04:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8044; q=dns/txt; s=iport; t=1597749259; x=1598958859; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=nDgMuUK5FqipTumaBNgOZL92iYqsXFL+Yf3bgV7cVKA=; b=JOcLrfxL8aAFndwESW2IDd5Llk/8bzvOXHso/P/HJZ4fc9pl0mMCMM3S V8ZDzjhTF61fsKELDtxd2PTS9Kdb2KD9wT0Eim9gcm5LivOLIOavrvfi6 w8Wr0EU88GrNmIQsIHXqGMliuSjKoVD7CazFzXM8eX8VEyGvqZKNYFhVF k=; IronPort-PHdr: =?us-ascii?q?9a23=3AIoZV7hRP895bmQm5LS8lOsjLadpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNuJ9PtYkOfQ9abtRT9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Nq2Gp4DhUHB?= =?us-ascii?q?jjZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jB?= =?us-ascii?q?DOpyhF?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgCQB2tztf/40NJK1WCR9qgm0vUQd?= =?us-ascii?q?wWC8sCodzA41ak3yEbYFCgREDVQsBAQEMAQEjCgIEAQGETAKCHwIkOBMCAwE?= =?us-ascii?q?BCwEBBQEBAQIBBgRthVwMhXEBAQEBAxIbEwEBOA8CAQgRBAEBLzIdCAIEARI?= =?us-ascii?q?IGoMFgX5NAy4BAwulLQKBOYhhdIE0gwEBAQWFMRiCDgMGgTiCcYouG4FBP4E?= =?us-ascii?q?RQ4JNPoJcAQEDgScBCAoBIyuDHYItj3eJbZxPCoJiiGSRXoMAiVyTR5I7ikS?= =?us-ascii?q?UfAIEAgQFAg4BAQWBaiMqPXBwFRqDClAXAg2SEIUUhUJ0NwIGCgEBAwl8j0Q?= =?us-ascii?q?BgRABAQ?= X-IronPort-AV: E=Sophos;i="5.76,327,1592870400"; d="scan'208,217";a="794395748" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Aug 2020 11:14:17 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 07IBEHlE031448 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Aug 2020 11:14:17 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 06:14:17 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 06:14:16 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 18 Aug 2020 06:14:16 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lZ5fIUxpyjgRrJ/I+brrvRCQhF4qEcTZEdoNnKpFWiEOqCqhFt8z/YoAMD+GJtreTXf9dLc7/ero34Oo/eUsmPYz75r/l8gPrs1Fb2/V+lKmcDkM46gzYX5QwBmmsuM0m8KS3DyaiIkw+w+3lRgksZUrvtSGkA3mQNfBjupcG2O233G+xWX6cv5gY5VG0K318IpC350tGCVJYb+9A07Hn6tKBAKfIQmAjSY8WALQTcBbl/Q/c515svtOyyR0ZnrpugZAD2DrS4zjIi4LSr/uXRwvwJaJMjtKYeBkgkkIv09mx5Nske36T1VMkRibae02wb06dGd10kTpZ8lIp9fjPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tUa6me+uDgRyvNpQ1qZm7yY5JyrkWAbodEgp3vsLGis=; b=cJtuF/1+etyL9xg6GKhjRGszxuACz/B45VCAjtcPLfOx6Ml875a40WmikqyiDVPOFea/Y7V3ZWoq9wGCOJpPpoNUYhT+bs9kAh1YNVbrDQT21JZT/p7CDe1wAa/sEEtvnWdxWUXtwVTeai4blgF/ZAXR00EqoVe/QR/PyeoiJJrbRxKM1SEL0nv2D1PF47VkdJbigs2A+mgxMLvKj7Ue/fUJUObuvE/cuwy/+AKxu/7sZiBx5ZjTxuRdS26DKuXF0Is7KbQDyu8ZA3jfR5EBB2HNmx/jduozL13tPfAIoh6Jl9xCxC7j4wYIMF8UiZqp2343ZdwmPy8DRE4hvRp6qw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tUa6me+uDgRyvNpQ1qZm7yY5JyrkWAbodEgp3vsLGis=; b=apt4dKVlD+N7/xhawrmxgk33kS1xAWHzNbKEhrEL3HerRXn6ZbKel/cmQLyErv+uJ3COOnS6lPCYKsMNgwNI8dIF5jdM4sPOF4Ne9b0J8No/TGZH1q/bRVmRJkNWfHeIXHnSo/E6NrJSUJuK86128kbaJqlz6AdELLg8lm7o6HI= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4333.namprd11.prod.outlook.com (2603:10b6:208:195::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Tue, 18 Aug 2020 11:14:13 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1%3]) with mapi id 15.20.3305.024; Tue, 18 Aug 2020 11:14:13 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr Thread-Index: AQHWa3a+GCK5es9bYUGFhEOKr41nTqk9xtIQ Date: Tue, 18 Aug 2020 11:14:13 +0000 Message-ID: References: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> In-Reply-To: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.15.79.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c31c25d8-9d81-4030-e26c-08d84367d6b1 x-ms-traffictypediagnostic: MN2PR11MB4333: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bHAYJ6ZHWAYHfDjUp2fEX2hYo1jV9Yh1ln0on/pUdPcbkNUvRTnykTbawfg1a4UAoikCQeTPATQL9mxF60BV1ZA4oJojES6jeraZ6ra5JnQegHRBgV9nU5dqN5ecLhMXqG3hK5py1lBH1514BeOp5XfJ9T7ZVw8OMKpet7yEGzf2Cb9APorDmqJpsiBmp0yh8oXF+eqAtU5JFxzBTgG5hi7vLRU2KmvR59V09RwyeVIgmL9NP3b8p9wFzlyyyaQgMhyN4rz8ZTS+PsqeduGW5WDAKu2SIRwoMcaLMQUCQjQRN+d32KVOA2EWUca+mtzR17fyCg0Bi4sAeC7GAuWWKO7dxpihgS+saowE+qBgR1WnCzobEqxtEZDXnnZTaPBezUVwY4rGXLGYdoaddLSCdw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(376002)(346002)(39860400002)(396003)(5660300002)(9326002)(71200400001)(33656002)(966005)(8936002)(478600001)(9686003)(55016002)(52536014)(83380400001)(8676002)(2906002)(110136005)(76116006)(53546011)(6506007)(166002)(86362001)(66946007)(26005)(66556008)(64756008)(316002)(66476007)(186003)(7696005)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: rHtn8ZN0176boCbEUI49rkXBd9y0X2YIX0SDMWbgh9UVFFdV7vOKHKPW6yNtzTlUNc/60i7y6mZTpdAulbmeTh3JNOWrr0UNLsKmUkGpHo2bfaOOsICVjIq8WydWGvZDYMHmVwbypz5qOsqskHAc4gH1Q18HvnEYWSiQHqGCh4UnukrcOdfe/9zzKd206VILS7zkZpD/eJrWt97q343gND4tDbVog86sLFvIn0QtpkExpokxg2bIQBW6c7JOurMKaYQ3vflrM+psK61sVD2KaHt7dA9MTweDesBVwcQ3y9Q289D7ORgL8LrUsBxQFCM9pyD3ViHSlM/z6tA7M6UngbtqXLFLQOzpfdv8yJJAyvrTFdmYwd1QcQIdLv1AwStCPshAGUC5l/Wckjlwig6C4covgWrock3wgxzshpNZ26HhNAfGfD+ylwtDko1F2t6Q7CEhDzsEazEs9lj+uLifFDjXYdEccD6+PeNkX9gYXU+Iayiyqew9K83b0YTdAUPIJw6F4WRyywt3aRP0GUVsWfu9rlNVIwCem9I3C4qzZYvKWvLXwfV7vH0e3APDmnA7IxQSWe2pVepeVhWxUetnboSWhyErMc8b2x825amdSzfeC4DjFTDoHOtuhbjVITwlYvj3M9g6uDPtXwyxtIX9fg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43662E3AEB041DD101281818B55C0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c31c25d8-9d81-4030-e26c-08d84367d6b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2020 11:14:13.3251 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: THvBQN5X/jTvNhn5Ij3BxpUPcbnDLTcembTGxj5zXTQ7AjlbuY7+TtFOvTN8NYYDVFbZTtUQ9cz+ohRBkzZy1w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4333 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 11:14:22 -0000 --_000_MN2PR11MB43662E3AEB041DD101281818B55C0MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I believe that this draft offers a simple and very useful extension to sztp= . It seems to offer a good starting place for this work. I would like to see IETF to work on this, and given NETCONF standardized th= e base draft, this seems a reasonable place to work on this. Regards, Rob [As an individual contributor] From: netconf On Behalf Of Kent Watsen Sent: 05 August 2020 23:19 To: netconf@ietf.org Subject: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr NETCONF WG, Per the previous email sent moments ago, the chairs would like to solicit i= nput on the following draft: Title: Conveying a CSR in an SZTP Bootstrapping Request Link: https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr Abstract: This draft extends the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. In particular, please discuss adoption-suitability as it regards to the fol= lowing questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? PS: this message is itself not an adoption poll, but rather an attempt to g= auge interest/support for a potential future adoption poll. NETCONF Chairs --_000_MN2PR11MB43662E3AEB041DD101281818B55C0MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

&nbs= p;

I believe= that this draft offers a simple and very useful extension to sztp. It seem= s to offer a good starting place for this work.

&nbs= p;

I would l= ike to see IETF to work on this, and given NETCONF standardized the base dr= aft, this seems a reasonable place to work on this.

&nbs= p;

Regards,<= o:p>

Rob<= /o:p>

[As an in= dividual contributor]

&nbs= p;

&nbs= p;

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 05 August 2020 23:19
To: netconf@ietf.org
Subject: [netconf] Adoption-suitability for draft-kwatsen-netconf-sz= tp-csr

 

 

NETCONF WG,

Per the previous email sent moments ago, the chairs would like to solicit i= nput on the following draft:

 =

   Title: = ;Conveying a CSR in an SZTP Bootstrapping Request

   Link: https://tools.ietf.org/html/dr= aft-kwatsen-netconf-sztp-csr
   Abstract:

      Thi= s draft extends the "get-bootstrapping-data" RPC defined in

      RFC=  8572 to include an optional certificate signing request (CSR),

      ena= bling a bootstrapping device to additionally obtain an identity=

      cer= tificate (e.g., an LDevID, from IEEE 802.1AR) as part of the

      &qu= ot;onboarding information" response provided in the RPC-reply.<= o:p>

 


In particular, please discuss adoption-suitability as it regards to the fol= lowing questions:

 =

    1) is the = problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the work?



PS: this message is itself not an adoption poll, but rather an attempt to g= auge interest/support for a potential future adoption poll.

NETCONF Chairs

--_000_MN2PR11MB43662E3AEB041DD101281818B55C0MN2PR11MB4366namp_-- From nobody Tue Aug 18 04:27:49 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF8E3A08D6 for ; Tue, 18 Aug 2020 04:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf8qt82e84rb for ; Tue, 18 Aug 2020 04:27:46 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86B43A08CF for ; Tue, 18 Aug 2020 04:27:46 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 07IBRGDY028280; Tue, 18 Aug 2020 12:27:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=PeQvxeK/zFW06S7oyniS1rU42Pe21clF55pmbL3bQ4E=; b=IBVnufcsPoCzujCJO0DKD7GxMj7/U6p0j5qqypXfeHXw0cgLFIwUrFeyzAdw8BRUWQiD ePwbzvDwz4QP6qufct9U2ngKemWsrr3D+jsiWLR1gLzsvH8qb+USvGvPMrbk2+hSzeMK Mjc7tWF1pJNogSDJE3GhwTi7OLUtRzSdgYKoGQWtv3aD3nf0C+IeHy9sV6RaNrzoy3q1 f62EP4N9mZMkZJTfFdYu7HwHWTRZ1fhenovi6UJUliREte5nZwSqf6ZhGiipx79MGTQ+ BHDXsTZKeOPcYh65AQ2lqQrPVZozg97o8lXPOCvVsjoSzj5VZ72Hr01/h4Otfu/vvBw2 Ew== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 3304n0rw1r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Aug 2020 12:27:46 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 07IBGmXB008052; Tue, 18 Aug 2020 07:27:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 32xb1xjb9q-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Aug 2020 07:27:44 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 07:27:44 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.006; Tue, 18 Aug 2020 07:27:44 -0400 From: "Salz, Rich" To: Sean Turner , "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr Thread-Index: AQHWa3Z3tKu6uBA/6kaw3z7llhGghakteOKAgBAPIgCAAEY8gA== Date: Tue, 18 Aug 2020 11:27:43 +0000 Message-ID: <5A1AF2C6-1934-4EEF-85B4-2C80983D1619@akamai.com> References: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> <01000173cabb057c-4236d605-0617-411c-a237-cd60f7545b79-000000@email.amazonses.com> <9F62FC91-14A9-4FDB-83F4-6DC2C0C17B6C@sn3rd.com> In-Reply-To: <9F62FC91-14A9-4FDB-83F4-6DC2C0C17B6C@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.150] Content-Type: text/plain; charset="utf-8" Content-ID: <11D724F9F8F1C04BBDCA2B34930DE0D4@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-18_07:2020-08-18, 2020-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 mlxscore=0 bulkscore=0 spamscore=0 mlxlogscore=806 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008180079 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-18_07:2020-08-18, 2020-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 suspectscore=0 bulkscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 malwarescore=0 adultscore=0 priorityscore=1501 mlxlogscore=730 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008180082 Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 11:27:48 -0000 SSByZWFkIHRoZSBkcmFmdC4gSSBhbSBhIHNlY3VyaXR5IHBlcnNvbiwgYW5kIGRlc3BpdGUgaGF2 aW5nIGhhZCBzb21lIHBhcnRpY2lwYXRpb24gaW4gTmV0Y29uZiBmb3IgYSB3aGlsZSwgSSBzdGls bCBjb25zaWRlciBteXNlbGYgYSBiZWdpbm5lci4NCg0KVGhlIGNyZWRlbnRpYWxzIG9mIFNlYW4g YW5kIFJ1c3MgYXJlIGltcGVjY2FibGUuIElmIHRoZXkgc2F5ICJ0aGlzIGlzIGEgZ29vZCB3YXkg dG8gYWRkIGNlcnRpZmljYXRlIHJlcXVlc3RzIiB0aGVuLCBmYWN0dWFsbHksIGl0IGlzLiBJIGRv bid0IGhhdmUgdG8gbWVudGlvbiBLZW50J3MgcXVhbGlmaWNhdGlvbnMgaGVyZS4gOikNCg0KSWYg dGhpcyBmaWxscyBhIG5lZWQsIGFuZCBhdCBsZWFzdCB0aGUgYXV0aG9ycyBmZWVsIGl0IGRvZXMs IHRoZW4gdGhlIFdHIHNob3VsZCBhZG9wdCB0aGlzIGRvY3VtZW50LiBJdCBzaG91bGQgcHJvZ3Jl c3MgcHJldHR5IHJhcGlkbHkuIA0KDQo= From nobody Tue Aug 18 05:09:34 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FEA3A094B for ; Tue, 18 Aug 2020 05:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.997, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 L3C2p0r9h_Jo for ; Tue, 18 Aug 2020 05:09:28 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC7E3A092D for ; Tue, 18 Aug 2020 05:09:26 -0700 (PDT) Received: from clientip-124.127.46.2?logid-fd2f4e5c20dd4b518789e32a58626ce8 (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 01BA9280090; Tue, 18 Aug 2020 20:09:19 +0800 (CST) HMM_ATTACHE_NUM: 0000 HMM_SOURCE_IP: wmail.172.18.0.92.2043507644 HMM_SOURCE_TYPE: WEBMAIL Received: from ([172.18.0.99]) by App0021 with ESMTP id fd2f4e5c20dd4b518789e32a58626ce8 for kent+ietf@watsen.net; Tue Aug 18 20:09:20 2020 X-Transaction-ID: fd2f4e5c20dd4b518789e32a58626ce8 X-filter-score: filter<0> X-Real-From: wangw36@chinatelecom.cn X-Receive-IP: 172.18.0.99 X-MEDUSA-Status: 0 Sender: wangw36@chinatelecom.cn Date: Tue, 18 Aug 2020 20:09:19 +0800 (CST) From: =?UTF-8?B?546L5beN?= To: kent+ietf , netconf Message-ID: <1948619766.26418.1597752560318@localhost> MIME-Version: 1.0 Content-type: multipart/mixed; boundary="----=_Part_26416_868492564.1597752559089" HMM_WEBCLN_IP: 172.18.8.21 X-HERMES-SENDMODE: normal X-HERMES-SET: Ir/5xdyPhtw/nKWlnb3tlh2opR3wkHKvQ6wxUNjG5Bw= Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-wang-netconf-adaptive-subscription X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 12:09:32 -0000 ------=_Part_26416_868492564.1597752559089 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+CiA8aGVhZD48L2hlYWQ+CiA8Ym9keT4KICA8cD48YnI+PC9wPiAKICA8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYig1MSw1MSw1MSk7d2hpdGUtc3BhY2U6IG5vcm1h bDtiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LDI1NSwyNTUpOyI+IDxzcGFuIHN0eWxlPSJjb2xv cjogYmxhY2s7Ij5IaSBhbGwsPC9zcGFuPiA8L3A+IAogIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjogcmdiKDUxLDUxLDUxKTt3aGl0ZS1zcGFjZTogbm9ybWFsO2JhY2tncm91bmQt Y29sb3I6IHJnYigyNTUsMjU1LDI1NSk7Ij4gPHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsiPiA8 YnI+IDwvc3Bhbj4gPC9wPiAKICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJn Yig1MSw1MSw1MSk7d2hpdGUtc3BhY2U6IG5vcm1hbDtiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LDI1NSwyNTUpOyI+IDxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7Ij5JIGhhdmUgcmVhZCB0aGlz IGRyYWZ0LCBoZXJlIGlzIG15IGFuc3dlciB0byB0aGUgZm9sbG93aW5nIHR3byBxdWVzdGlvbnM6 PC9zcGFuPiA8L3A+IAogIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDUx LDUxLDUxKTt3aGl0ZS1zcGFjZTogbm9ybWFsO2JhY2tncm91bmQtY29sb3I6IHJnYigyNTUsMjU1 LDI1NSk7Ij4gPHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsiPjEpIGlzIHRoZSBwcm9ibGVtIGlt cG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cgdG8gc29sdmU/PGJyPkkgYmVsaWV2ZSB0aGF0IGl0 IGlzIGltcG9ydGFudCB0byBwcm92aWRlIGFkYXB0aXZlIHNhbXBsaW5nIGFuZCBhbGxvdyB0aGUg c2VydmVyIHN3aXRjaCBzYW1wbGluZyByYXRlLCBpLmUuLGFkanVzdHMgdGhlIHZvbHVtZSBvZiB0 ZWxlbWV0cnkgc2VudCBmcm9tIHRoZSBwdWJsaXNoZXIgdG8gdGhlIHN1YnNjcmliZXIuPGJyPkkg YWxzbyBoYXZlIGJlZW4gYXdhcmUgdGhhdCBNaWNyb3NvZnQgaGFzIGFscmVhZHkgYWRvcHRlZCBh ZGFwdGl2ZSB0ZWxlbWV0cnkgaW4gQVNQLk5FVCBhbmQgQXp1cmUgZnVuY3Rpb24uPGJyPkFuZCBJ IGJlbGlldmUgdGhhdCB0aGUgTkVUQ09ORiBXRyBpcyB0aGUgYXBwcm9wcmlhdGUgV0cgZm9yIHRo aXMgd29yay4gUkZDODYzOSBhbmQgUkZDODY0MCBwcm92aWRlIGEgZ29vZCBiYXNpcyBmb3IgdGhp cyB3b3JrLjwvc3Bhbj4gPC9wPiAKICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6 IHJnYig1MSw1MSw1MSk7d2hpdGUtc3BhY2U6IG5vcm1hbDtiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io MjU1LDI1NSwyNTUpOyI+IDxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7Ij4gPGJyPjIpIGlzIHRo ZSBkcmFmdCBhIHN1aXRhYmxlIGJhc2lzIGZvciB0aGUgd29yaz88YnI+SSBoYXZlIHJldmlld2Vk IHRoZSBkcmFmdCBhbmQgYmVsaWV2ZSBpdCBwcm92aWRlIGEgZ29vZCBiYXNpcyBmb3IgdGhlIHN0 YXJ0aW5nIHBvaW50Ljxicj5JZiB0aGlzIGRyYWZ0IGdldHMgYWRvcHRlZCwgSSBhbSB3aWxsaW5n IHRvIHJldmlldyBhbnkgdmVyc2lvbiBvZiB0aGlzIHdvcmsgYW5kIGNvbnRyaWJ1dGUgdG8gYW55 IGRpc2N1c3Npb24uPC9zcGFuPiA8L3A+IAogIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJj b2xvcjogcmdiKDUxLDUxLDUxKTt3aGl0ZS1zcGFjZTogbm9ybWFsO2JhY2tncm91bmQtY29sb3I6 IHJnYigyNTUsMjU1LDI1NSk7Ij4gPHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsiPiA8YnI+IDwv c3Bhbj4gPC9wPiAKICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYig1MSw1 MSw1MSk7d2hpdGUtc3BhY2U6IG5vcm1hbDtiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LDI1NSwy NTUpOyI+IDxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7Ij5CZXN0IFJlZ2FyZHMsPC9zcGFuPiA8 L3A+IAogIDxwIHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyI+LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTwvcD4gCiAgPHA+V2VpIFdhbmc8L3A+IAogIDxwPkNoaW5hIFRlbGVjb208L3A+ IAogIDxkaXY+CiAgICZuYnNwOwogIDwvZGl2PiAKICA8ZGl2PgogICAmbmJzcDsKICA8L2Rpdj4g CiAgPGRpdiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDEuMHB4IHNvbGlkIHJnYigyMjEsMjIxLDIyMSk7 cGFkZGluZy1sZWZ0OiA1LjBweDttYXJnaW4tbGVmdDogNS4wcHg7Ij4gCiAgIDxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+IAogICAgPGRpdj4gCiAgICAgPGRpdiBzdHlsZT0iYm9yZGVyOiBub25l O2JvcmRlci10b3A6IHNvbGlkIHJnYigyMjUsMjI1LDIyNSkgMS4wcHQ7cGFkZGluZzogMy4wcHQg MC4wY20gMC4wY20gMC4wY207Ij4gCiAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiA8Yj4gPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTEuMHB0OyI+5Y+R5Lu25Lq6PHNwYW4+Ojwvc3Bhbj4gPC9z cGFuPiA8L2I+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExLjBwdDsiPiBuZXRjb25mIFttYWls dG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSA8L3NwYW4+IDxiPiA8c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMS4wcHQ7Ij7ku6PooaggPC9zcGFuPiA8L2I+IDxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExLjBwdDsiPktlbnQgV2F0c2VuPGJyPiA8L3NwYW4+IDxiPiA8c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMS4wcHQ7Ij7lj5HpgIHml7bpl7Q8c3Bhbj46PC9zcGFuPiA8L3NwYW4+IDwvYj4g PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTEuMHB0OyI+IDIwMjA8L3NwYW4+IDxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExLjBwdDsiPuW5tDxzcGFuPjg8L3NwYW4+5pyIPHNwYW4+Njwvc3Bhbj7m l6U8c3Bhbj4gNjoxODxicj4gPC9zcGFuPiA8Yj7mlLbku7bkuro8c3Bhbj46PC9zcGFuPiA8L2I+ IDxzcGFuPiBuZXRjb25mQGlldGYub3JnPGJyPiA8L3NwYW4+IDxiPuS4u+mimDxzcGFuPjo8L3Nw YW4+IDwvYj4gPHNwYW4+IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQt d2FuZy1uZXRjb25mLWFkYXB0aXZlLXN1YnNjcmlwdGlvbiA8L3NwYW4+IDwvc3Bhbj4gPC9wPiAK ICAgICA8L2Rpdj4gCiAgICA8L2Rpdj4gCiAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48L3A+IAog ICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+IDxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7Ij5ORVRD T05GIFdHLDxicj4gPGJyPiBQZXIgdGhlIHByZXZpb3VzIGVtYWlsIHNlbnQgbW9tZW50cyBhZ28s IHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBzb2xpY2l0IGlucHV0IG9uIHRoZSBmb2xsb3dpbmcg ZHJhZnQ6PC9zcGFuPiA8L3A+IAogICAgPGRpdj4gCiAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PC9wPiAKICAgIDwvZGl2PiAKICAgIDxkaXY+IAogICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiA8 c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyI+IFRpdGxlOiBBZGFwdGl2ZSBTdWJzY3JpcHRpb24g dG8gWUFORyBOb3RpZmljYXRpb248L3NwYW4+IDwvcD4gCiAgICAgPGRpdj4gCiAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAxMi4wcHQ7Ij4gPHNwYW4gc3R5 bGU9ImNvbG9yOiBibGFjazsiPiBMaW5rOiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtd2FuZy1uZXRjb25mLWFkYXB0aXZlLXN1YnNjcmlwdGlvbiI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhbmctbmV0Y29uZi1hZGFwdGl2ZS1zdWJzY3JpcHRp b248L2E+PC9zcGFuPiA8c3Bhbj4gPGJyPiA8c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyI+IEFi c3RyYWN0Ojwvc3Bhbj4gPC9zcGFuPiA8L3A+IAogICAgICA8ZGl2PiAKICAgICAgIDxwIGNsYXNz PSJNc29Ob3JtYWwiPiA8c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyI+IFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBhbmQgYXNzb2NpYXRlZCBtZWNoYW5pc208L3NwYW4+ IDwvcD4gCiAgICAgIDwvZGl2PiAKICAgICAgPGRpdj4gCiAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj4gPHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsiPiBlbmFibGluZyBzdWJzY3JpYmVyJ3Mg YWRhcHRpdmUgc3Vic2NyaXB0aW9ucyB0byBhIHB1Ymxpc2hlcidzIGV2ZW50PC9zcGFuPiA8L3A+ IAogICAgICA8L2Rpdj4gCiAgICAgIDxkaXY+IAogICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+ IDxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7Ij4gc3RyZWFtcyBhdCB2YXJpb3VzIGRpZmZlcmVu dCBwZXJpb2QgaW50ZXJ2YWxzIHdpdGggd2hpY2ggdG8gcmVwb3J0PC9zcGFuPiA8L3A+IAogICAg ICA8L2Rpdj4gCiAgICAgIDxkaXY+IAogICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+IDxzcGFu IHN0eWxlPSJjb2xvcjogYmxhY2s7Ij4gdXBkYXRlcy4gQXBwbHlpbmcgdGhlc2UgZWxlbWVudHMg YWxsb3dzIGJvdGggc3Vic2NyaWJlciBhbmQ8L3NwYW4+IDwvcD4gCiAgICAgIDwvZGl2PiAKICAg ICAgPGRpdj4gCiAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4gPHNwYW4gc3R5bGU9ImNvbG9y OiBibGFjazsiPiBwdWJsaXNoZXIgdG8gYXV0b21hdGljYWxseSBhZGp1c3QgdGhlIHZvbHVtZSBv ZiB0ZWxlbWV0cnkgdHJhZmZpYzwvc3Bhbj4gPC9wPiAKICAgICAgPC9kaXY+IAogICAgICA8ZGl2 PiAKICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiA8c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNr OyI+IHNlbnQgZnJvbSBwdWJsaXNoZXIgdG8gdGhlIHJlY2VpdmVycy48L3NwYW4+IDwvcD4gCiAg ICAgIDwvZGl2PiAKICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+IDxzcGFuIHN0eWxlPSJjb2xv cjogYmxhY2s7Ij4gPGJyPiA8L3NwYW4+IDxzcGFuPiA8YnI+IDxzcGFuIHN0eWxlPSJjb2xvcjog YmxhY2s7Ij5JbiBwYXJ0aWN1bGFyLCBwbGVhc2UgZGlzY3VzcyBhZG9wdGlvbi1zdWl0YWJpbGl0 eSBhcyBpdCByZWdhcmRzIHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOjwvc3Bhbj4gPC9zcGFu PiA8L3A+IAogICAgIDwvZGl2PiAKICAgICA8ZGl2PiAKICAgICAgPHAgY2xhc3M9Ik1zb05vcm1h bCI+PC9wPiAKICAgICA8L2Rpdj4gCiAgICAgPGRpdj4gCiAgICAgIDxwIGNsYXNzPSJNc29Ob3Jt YWwiPiA8c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyI+IDEpIGlzIHRoZSBwcm9ibGVtIGltcG9y dGFudCBmb3IgdGhlIE5FVENPTkYgV0cgdG8gc29sdmU/PGJyPiAyKSBpcyB0aGUgZHJhZnQgYSBz dWl0YWJsZSBiYXNpcyBmb3IgdGhlIHdvcms/PGJyPiA8YnI+IDxicj4gUFM6IHRoaXMgbWVzc2Fn ZSBpcyBpdHNlbGYgbm90IGFuIGFkb3B0aW9uIHBvbGwsIGJ1dCByYXRoZXIgYW4gYXR0ZW1wdCB0 byBnYXVnZSBpbnRlcmVzdC9zdXBwb3J0IGZvciBhIHBvdGVudGlhbCBmdXR1cmUgYWRvcHRpb24g cG9sbC48YnI+IDxicj4gTkVUQ09ORiBDaGFpcnMgPC9zcGFuPiA8L3A+IAogICAgIDwvZGl2PiAK ICAgIDwvZGl2PiAKICAgPC9kaXY+IAogIDwvZGl2PiAKICA8c3R5bGU+cC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbCB7DQoJbWFyZ2luOiAwLjBjbTsNCglmb250LXNpemU6 IDEyLjBwdDsNCglmb250LWZhbWlseTogIlRpbWVzIE5ldyBSb21hbiIgLCBzZXJpZjsNCn0NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsgew0KCWNvbG9yOiBibHVlOw0KCXRleHQtZGVjb3JhdGlv bjogdW5kZXJsaW5lOw0KfQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsN Cgljb2xvcjogcHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOw0KfQ0Kc3Bhbi5F bWFpbFN0eWxlMTcgew0KCWZvbnQtZmFtaWx5OiBDYWxpYnJpICwgc2Fucy1zZXJpZjsNCgljb2xv cjogcmdiKDMxLDczLDEyNSk7DQp9DQoqLk1zb0NocERlZmF1bHQgew0KCWZvbnQtc2l6ZTogMTAu MHB0Ow0KfQ0KZGl2LldvcmRTZWN0aW9uMSB7DQoJcGFnZTogV29yZFNlY3Rpb24xOw0KfQ0KPC9z dHlsZT4gCiA8L2JvZHk+CjwvaHRtbD4= ------=_Part_26416_868492564.1597752559089-- From nobody Tue Aug 18 05:35:10 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300003A098E for ; Tue, 18 Aug 2020 05:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.198 X-Spam-Level: X-Spam-Status: No, score=0.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.997, SPF_PASS=-0.001, URIBL_BLOCKED=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 Y-FnRbR1bzMG for ; Tue, 18 Aug 2020 05:35:06 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.223]) by ietfa.amsl.com (Postfix) with ESMTP id EA76A3A092E for ; Tue, 18 Aug 2020 05:35:05 -0700 (PDT) Received: from clientip-124.127.46.2?logid-3c84be8d805141988dab4db217ed8685 (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 57C45280093; Tue, 18 Aug 2020 20:34:57 +0800 (CST) HMM_ATTACHE_NUM: 0000 HMM_SOURCE_IP: wmail.172.18.0.92.2142008794 HMM_SOURCE_TYPE: WEBMAIL Received: from ([172.18.0.99]) by App0021 with ESMTP id 3c84be8d805141988dab4db217ed8685 for kent+ietf@watsen.net; Tue Aug 18 20:34:57 2020 X-Transaction-ID: 3c84be8d805141988dab4db217ed8685 X-filter-score: filter<0> X-Real-From: wangw36@chinatelecom.cn X-Receive-IP: 172.18.0.99 X-MEDUSA-Status: 0 Sender: wangw36@chinatelecom.cn Date: Tue, 18 Aug 2020 20:34:56 +0800 (CST) From: =?UTF-8?B?546L5beN?= To: kent+ietf , netconf Message-ID: <1803942779.26483.1597754097736@localhost> MIME-Version: 1.0 Content-type: multipart/mixed; boundary="----=_Part_26482_1031994797.1597754096515" HMM_WEBCLN_IP: 172.18.8.21 X-HERMES-SENDMODE: normal X-HERMES-SET: Ir/5xdyPhtw/nKWlnb3tlh2opR3wkHKvQ6wxUNjG5Bw= Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 12:35:09 -0000 ------=_Part_26482_1031994797.1597754096515 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+CiA8aGVhZD48L2hlYWQ+CiA8Ym9keT4KICA8cD4mbmJzcDs8L3A+IAogIDxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyI+SGkgYWxsLDwvcD4gCiAg PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7Ij4gPGJyPiA8 L3A+IAogIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyI+ MSkgaXMgdGhlIHByb2JsZW0gaW1wb3J0YW50IGZvciB0aGUgTkVUQ09ORiBXRyB0byBzb2x2ZT88 YnI+SSBiZWxpZXZlIHRoYXQgaXQgaXMgaW1wb3J0YW50IHRvIGNhcHR1cmUgY2hhcmFjdGVyaXN0 aWNzIGRhdGEgb3IgS1BJIGRhdGEgZm9yIHNlcnZpY2UgYXNzdXJhbmNlIGFwcGxpY2F0aW9uIGFu ZCByZWR1Y2UgdGhlIGFtb3VudCBvZiA8YnI+dW5uZWNlc3NhcnkgZGF0YSB0byBiZSBzdHJlYW1l ZCBvdXQgdG8gdGhlIGRlc3RpbmF0aW9uLiBUZWxlbWV0cnkgZGF0YSB0YWdnaW5nIGNhcGFiaWxp dHkgZHJhZnQgcHJvdmlkZXMgdGVsZW1ldHJ5IGRhdGEgY2xhc3NpZmljYXRpb24gYW5kIDxicj5o ZWxwIHRoZSBjbGllbnQgb25seSBmZXRjaCBjaGFyYWN0ZXJpc3RpY3MgZGF0YS48YnI+QW5kIEkg YWxzbyBiZWxpZXZlIHRoYXQgdGhlIE5FVENPTkYgV0cgaXMgdGhlIGFwcHJvcHJpYXRlIFdHIGZv ciB0aGlzIHdvcmsuIDxicj5kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxp dGllcyBkZWZpbmVzIHNlcnZlciBjYXBhYmlsaXRpZXMgYWR2ZXJ0aXNlbWVudCBhbmQgcHJvdmlk ZXMgYSBnb29kIGJhc2lzIGZvciBUZWxlbWV0cnkgZGF0YSB0YWdnaW5nIGNhcGFiaWxpdHkgZHJh ZnQuPC9wPiAKICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0id2hpdGUtc3BhY2U6IG5vcm1h bDsiPiA8YnI+MikgaXMgdGhlIGRyYWZ0IGEgc3VpdGFibGUgYmFzaXMgZm9yIHRoZSB3b3JrPzxi cj5JIGhhdmUgcmV2aWV3IHYtMDIgYW5kIGJlbGlldmUgaXQgcHJvdmlkZXMgYSBzb3VuZCBiYXNp cyBmb3IgdGhpcyB3b3JrLiBBbHNvIGlmIEkgcmVtZW1iZXIgY29ycmVjdCwgdGhlIGRlbW8gb24g dGhpcyBpZGVhIGhhcyBiZWVuIHByZXNlbnRlZCBpbiBvbmUgb2YgaGFja2F0aG9uIGluIGxhc3Qg eWVhci48YnI+SWYgdGhpcyB3b3JrIGdldHMgYWRvcHRlZCwgSSBhbSB3aWxsaW5nIHRvIHJldmll dyBpdCBhbmQgY29udHJpYnV0ZSB0byB0aGUgZGlzY3Vzc2lvbi48L3A+IAogIDxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyI+IDxicj4gPC9wPiAKICA8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsiPkJlc3QgUmVnYXJk cyw8L3A+IAogIDxkaXY+CiAgICZuYnNwOwogIDwvZGl2PiAKICA8cD4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPiA8L3A+IAogIDxwPiBXZWkgV2FuZzwvcD4gCiAgPHA+Q2hpbmEgVGVs ZWNvbTwvcD4gCiAgPHA+IDxicj4gPC9wPiAKICA8ZGl2IHN0eWxlPSJib3JkZXItbGVmdDogMS4w cHggc29saWQgcmdiKDIyMSwyMjEsMjIxKTtwYWRkaW5nLWxlZnQ6IDUuMHB4O21hcmdpbi1sZWZ0 OiA1LjBweDsiPiAKICAgPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4gCiAgICA8ZGl2PiAKICAg ICA8ZGl2IHN0eWxlPSJib3JkZXI6IG5vbmU7Ym9yZGVyLXRvcDogc29saWQgcmdiKDIyNSwyMjUs MjI1KSAxLjBwdDtwYWRkaW5nOiAzLjBwdCAwLjBjbSAwLjBjbSAwLjBjbTsiPiAKICAgICAgPHAg Y2xhc3M9Ik1zb05vcm1hbCI+IDxiPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMS4wcHQ7Ij7l j5Hku7bkuro8c3Bhbj46PC9zcGFuPiA8L3NwYW4+IDwvYj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTEuMHB0OyI+IG5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIDwv c3Bhbj4gPGI+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExLjBwdDsiPuS7o+ihqCA8L3NwYW4+ IDwvYj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTEuMHB0OyI+S2VudCBXYXRzZW48YnI+IDwv c3Bhbj4gPGI+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExLjBwdDsiPuWPkemAgeaXtumXtDxz cGFuPjo8L3NwYW4+IDwvc3Bhbj4gPC9iPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMS4wcHQ7 Ij4gMjAyMDwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTEuMHB0OyI+5bm0PHNwYW4+ ODwvc3Bhbj7mnIg8c3Bhbj42PC9zcGFuPuaXpTxzcGFuPiA2OjE4PGJyPiA8L3NwYW4+IDxiPuaU tuS7tuS6ujxzcGFuPjo8L3NwYW4+IDwvYj4gPHNwYW4+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+IDwv c3Bhbj4gPGI+5Li76aKYPHNwYW4+Ojwvc3Bhbj4gPC9iPiA8c3Bhbj4gW25ldGNvbmZdIEFkb3B0 aW9uLXN1aXRhYmlsaXR5IGZvciBkcmFmdC10YW8tbmV0Y29uZi1ub3RpZi1ub2RlLXRhZy1jYXBh YmlsaXRpZXMgPC9zcGFuPiA8L3NwYW4+IDwvcD4gCiAgICAgPC9kaXY+IAogICAgPC9kaXY+IAog ICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+IDxzcGFuPjwvc3Bhbj4gPC9wPiAKICAgIDxwIGNsYXNz PSJNc29Ob3JtYWwiPiA8c3Bhbj48L3NwYW4+IDwvcD4gCiAgICA8ZGl2PiAKICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj4gPHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsiPk5FVENPTkYgV0csPGJy PiA8YnI+IFBlciB0aGUgcHJldmlvdXMgZW1haWwgc2VudCBtb21lbnRzIGFnbywgdGhlIGNoYWly cyB3b3VsZCBsaWtlIHRvIHNvbGljaXQgaW5wdXQgb24gdGhlIGZvbGxvd2luZyBkcmFmdDo8L3Nw YW4+IDwvcD4gCiAgICAgPGRpdj4gCiAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiA8c3BhbiBz dHlsZT0iY29sb3I6IGJsYWNrOyI+PC9zcGFuPiA8L3A+IAogICAgIDwvZGl2PiAKICAgICA8ZGl2 PiAKICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+IDxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7 Ij4gVGl0bGU6IFNlbGYtZXhwbGFuYXRpb24gZGF0YSBOb2RlIHRhZyBjYXBhYmlsaXR5PC9zcGFu PiA8L3A+IAogICAgICA8ZGl2PiAKICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOiAxMi4wcHQ7Ij4gPHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsiPiBMaW5r OiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvPC9hPmRyYWZ0LXRhby1uZXRjb25mLW5vdGlmLW5vZGUtdGFnLWNhcGFiaWxp dGllczwvc3Bhbj4gPHNwYW4+IDxicj4gPHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsiPiBBYnN0 cmFjdDo8L3NwYW4+IDwvc3Bhbj4gPC9wPiAKICAgICAgIDxkaXY+IAogICAgICAgIDxkaXY+IAog ICAgICAgICA8ZGl2PiAKICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiA8c3BhbiBzdHls ZT0iY29sb3I6IGJsYWNrOyI+IEJlZm9yZSBhIGNsaWVudCBhcHBsaWNhdGlvbiBzdWJzY3JpYmVz IHRvIHVwZGF0ZXMgZnJvbSBhIGRhdGFzdG9yZSw8L3NwYW4+IDwvcD4gCiAgICAgICAgIDwvZGl2 PiAKICAgICAgICAgPGRpdj4gCiAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4gPHNwYW4g c3R5bGU9ImNvbG9yOiBibGFjazsiPiBzZXJ2ZXIgY2FwYWJpbGl0aWVzIHJlbGF0ZWQgdG8gIlN1 YnNjcmlwdGlvbiB0byBZQU5HIERhdGFzdG9yZXMiIGNhbjwvc3Bhbj4gPC9wPiAKICAgICAgICAg PC9kaXY+IAogICAgICAgICA8ZGl2PiAKICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiA8 c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyI+IGJlIGFkdmVydGlzZWQgdXNpbmcgWUFORyBJbnN0 YW5jZSBEYXRhIGZvcm1hdC4gVGhlc2Ugc2VydmVyPC9zcGFuPiA8L3A+IAogICAgICAgICA8L2Rp dj4gCiAgICAgICAgIDxkaXY+IAogICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+IDxzcGFu IHN0eWxlPSJjb2xvcjogYmxhY2s7Ij4gY2FwYWJpbGl0aWVzIGNhbiBiZSBkb2N1bWVudGVkIGF0 IGltcGxlbWVudCB0aW1lIG9yIHJlcG9ydGVkIGF0IHJ1bi08L3NwYW4+IDwvcD4gCiAgICAgICAg IDwvZGl2PiAKICAgICAgICAgPGRpdj4gCiAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4g PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsiPiB0aW1lLjwvc3Bhbj4gPC9wPiAKICAgICAgICAg PC9kaXY+IAogICAgICAgICA8ZGl2PiAKICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiA8 c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyI+IDxicj4gPGJyPiA8L3NwYW4+IDwvcD4gCiAgICAg ICAgIDwvZGl2PiAKICAgICAgICAgPGRpdj4gCiAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFs Ij4gPHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsiPiBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIGEg WUFORyBtb2R1bGUgZm9yIHNlbGYtZXhwbGFuYXRpb24gZGF0YSBOb2RlPC9zcGFuPiA8L3A+IAog ICAgICAgICA8L2Rpdj4gCiAgICAgICAgIDxkaXY+IAogICAgICAgICAgPHAgY2xhc3M9Ik1zb05v cm1hbCI+IDxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7Ij4gdGFnIGNhcGFiaWxpdHkgd2hpY2gg YXVnbWVudHMgc3lzdGVtIGNhcGFiaWxpdGllcyBtb2RlbCBhbmQgcHJvdmlkZTwvc3Bhbj4gPC9w PiAKICAgICAgICAgPC9kaXY+IAogICAgICAgICA8ZGl2PiAKICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiPiA8c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyI+IGFkZGl0aW9uYWwgc2VsZi1l eHBsYW5hdGlvbiBkYXRhIG5vZGUgYXR0cmlidXRlcyBhc3NvY2lhdGVkIHdpdGggbm9kZTwvc3Bh bj4gPC9wPiAKICAgICAgICAgPC9kaXY+IAogICAgICAgICA8ZGl2PiAKICAgICAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiPiA8c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyI+IHNlbGVjdG9ycyB3 aXRoaW4gcGVyLW5vZGUgY2FwYWJpbGl0aWVzLjwvc3Bhbj4gPC9wPiAKICAgICAgICAgPC9kaXY+ IAogICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4gPHNwYW4+PC9zcGFuPiA8L3A+IAogICAg ICAgIDwvZGl2PiAKICAgICAgIDwvZGl2PiAKICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiA8 c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyI+IDxicj4gSW4gcGFydGljdWxhciwgcGxlYXNlIGRp c2N1c3MgYWRvcHRpb24tc3VpdGFiaWxpdHkgYXMgaXQgcmVnYXJkcyB0byB0aGUgZm9sbG93aW5n IHF1ZXN0aW9uczo8L3NwYW4+IDwvcD4gCiAgICAgIDwvZGl2PiAKICAgICAgPGRpdj4gCiAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4gPHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsiPjwvc3Bh bj4gPC9wPiAKICAgICAgPC9kaXY+IAogICAgICA8ZGl2PiAKICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPiA8c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyI+IDEpIGlzIHRoZSBwcm9ibGVtIGlt cG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cgdG8gc29sdmU/PGJyPiAyKSBpcyB0aGUgZHJhZnQg YSBzdWl0YWJsZSBiYXNpcyBmb3IgdGhlIHdvcms/IDwvc3Bhbj4gPC9wPiAKICAgICAgPC9kaXY+ IAogICAgICA8ZGl2PiAKICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPiA8c3BhbiBzdHlsZT0i Y29sb3I6IGJsYWNrOyI+IDxicj4gPGJyPiBQUzogdGhpcyBtZXNzYWdlIGlzIGl0c2VsZiBub3Qg YW4gYWRvcHRpb24gcG9sbCwgYnV0IHJhdGhlciBhbiBhdHRlbXB0IHRvIGdhdWdlIGludGVyZXN0 L3N1cHBvcnQgZm9yIGEgcG90ZW50aWFsIGZ1dHVyZSBhZG9wdGlvbiBwb2xsLjxicj4gPGJyPiBO RVRDT05GIENoYWlycyA8L3NwYW4+IDwvcD4gCiAgICAgIDwvZGl2PiAKICAgICA8L2Rpdj4gCiAg ICA8L2Rpdj4gCiAgIDwvZGl2PiAKICA8L2Rpdj4gCiAgPHN0eWxlPnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwgew0KCW1hcmdpbjogMC4wY207DQoJZm9udC1zaXplOiAx Mi4wcHQ7DQoJZm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iICwgc2VyaWY7DQp9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rIHsNCgljb2xvcjogYmx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsNCn0NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJ Y29sb3I6IHB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsNCn0NCnNwYW4uRW1h aWxTdHlsZTE3IHsNCglmb250LWZhbWlseTogQ2FsaWJyaSAsIHNhbnMtc2VyaWY7DQoJY29sb3I6 IHJnYigzMSw3MywxMjUpOw0KfQ0KKi5Nc29DaHBEZWZhdWx0IHsNCglmb250LXNpemU6IDEwLjBw dDsNCn0NCmRpdi5Xb3JkU2VjdGlvbjEgew0KCXBhZ2U6IFdvcmRTZWN0aW9uMTsNCn0NCjwvc3R5 bGU+IAogPC9ib2R5Pgo8L2h0bWw+ ------=_Part_26482_1031994797.1597754096515-- From nobody Tue Aug 18 05:47:13 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901A43A09A0 for ; Tue, 18 Aug 2020 05:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=S0CxOfJw; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=I4ntu9ru Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqHP0tTEIXAX for ; Tue, 18 Aug 2020 05:47:09 -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 C32CC3A09A3 for ; Tue, 18 Aug 2020 05:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8835; q=dns/txt; s=iport; t=1597754829; x=1598964429; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=WQOFxxxjSRMlKi7b+BpZxnqn/5UMu9H8ItF/34EsZNY=; b=S0CxOfJwiPuKukHUVEOnyyBQl0AxytgUkLpi2jGxU9/yG1CaxbaVW25p D6QoeQXCG7SH5kNflObkrEzfV0Vq4wQ+ntcF6qvgYGbDVWgvp/FS6elgK YtFFi0B9/PjEB3nM7Z+UiEeJUsDMg0/HoTHHGYMhFl59MIvqTvxY0Soi/ o=; IronPort-PHdr: =?us-ascii?q?9a23=3AdV2WrBY7u1jAuGGLzUTXCrz/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD5rS9+lJjazQvryzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsuteFTOuXC0qzgfBk?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvCQBHzTtf/4wNJK1WCR+DVy9RB3B?= =?us-ascii?q?YLywKhC2DRgONWpN8hG2BQoERA1ULAQEBDAEBIwoCBAEBhEwCF4IIAiQ4EwI?= =?us-ascii?q?DAQELAQEFAQEBAgEGBG2FXAyFcQEBAQQSER0BATgPAgEIEQMBAisCAgIwHQg?= =?us-ascii?q?CBAESIoMEAYF+TQMuAQ6lBAKBOYhhdoEygwEBAQWCSoJkGIIOAwaBOIJxg2K?= =?us-ascii?q?GTBuBQT+BESccgk0+glwBAQOBJwEICgFBDYJqM4Itj3eDDIZhi12QcgqCYoh?= =?us-ascii?q?kkT0DHoMAiVyTR5I7ikSUfAIEAgQFAg4BAQWBaiNncHAVGksBgj5QFwINkhC?= =?us-ascii?q?FFIVCdDcCBgoBAQMJfI8IAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.76,327,1592870400"; d="scan'208,217";a="813494530" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Aug 2020 12:47:08 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 07ICl8OE017974 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Aug 2020 12:47:08 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 07:47:07 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 07:47:07 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 18 Aug 2020 08:47:06 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OieJNY47S3BDfE0z4kh6Bp/DjI+Rue1Evnqrgz6ooGhRVEDPfsPPP7OgPaNRNxgLcLcIr6FEWwhDRzbKckmJv03ntNrxg1SqE2BaX0Xas9wo08Eq1cjAlv0PyKYjAgG1yKEm+yTCZFgKthniTXSMUNpbhngPf/d0VNuPi/S3QIgrGbGNWUbqoXjSwRBsPE2FWRaOHQV0ALtRt3IMqRPk5qaRW1092maPu9vEYE4g9PPxg2aNcPPWa7rFERgLSFXaRXaXGMhdyFidkj6gaT6qZUapIHPPkaDKnRjpyv87BONKJy6WNzPQAz+cN+OTY4evr5Aykze3XQ8Aw0GCsDrnhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WQOFxxxjSRMlKi7b+BpZxnqn/5UMu9H8ItF/34EsZNY=; b=izPYOyWG5jN6h8L71NmDKDXoBSeGnD6lC9LCP5798jRLeiudFdH9iiQLqWB/+NWGYp2edksrwGtRVmFOIqYRLepraadqQ8wIlBRMvEt4ler1pnq+9N2Sp8jxDE/rR6vo1D8n/D+vLdKHGZpG9wYc9Fqp2Rr8+5N4VH1yz/yyvsuT5u7+GB72ETO1xtC3Af8VbQmC9ZgcLpPSstwEkJ5III08yRldt+szSwg4ctixqZ1FVKg3dGqM3zTqFziLjz2+OgsNlILpxdaRiI+V/wT0lgxDf+cjFWn2pj10uiTGgcjRFgKlN3Z+VbA0bZIlGxiJsnxhTuEJuoK12oQS1SiMAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WQOFxxxjSRMlKi7b+BpZxnqn/5UMu9H8ItF/34EsZNY=; b=I4ntu9ru1HqRztT3O4o+aGnQ68c7R3G0C+JJk/MawirfARoDJFwDg9sP+8GLgK+JjrHZ7ckaMsSwuvgDuG7f1GGkZCNyTtheHZKKoORq1ivVsYJo7HNBWq+BIYLQpzIfINm+IEVSUsFyJojyW5oWOEhNL+C53ZJfUI9T0Y+UYU4= Received: from BN6PR11MB3875.namprd11.prod.outlook.com (2603:10b6:405:80::37) by BN6PR11MB4130.namprd11.prod.outlook.com (2603:10b6:405:77::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.20; Tue, 18 Aug 2020 12:47:05 +0000 Received: from BN6PR11MB3875.namprd11.prod.outlook.com ([fe80::944a:3c3a:8ca2:1d06]) by BN6PR11MB3875.namprd11.prod.outlook.com ([fe80::944a:3c3a:8ca2:1d06%5]) with mapi id 15.20.3283.028; Tue, 18 Aug 2020 12:47:05 +0000 From: "Reshad Rahman (rrahman)" To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr Thread-Index: AQHWa3a9e5wviUFyWkulXXF8TuVzzKk9oVyA Date: Tue, 18 Aug 2020 12:47:05 +0000 Message-ID: <34A4DADF-3D7C-46B6-952C-385B4A9EABD7@cisco.com> References: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> In-Reply-To: <01000173c0b4ee99-d5627c91-eac2-4ea9-ba1b-b86e37c5293a-000000@us-east-1.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [70.30.102.119] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4d463e58-6d6c-41ee-4955-08d84374cffd x-ms-traffictypediagnostic: BN6PR11MB4130: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: btK1pX5sdmOPmGUebjVREspeaIJ3/98/RhWcb6FyPeMpwXgkBf9xgkFmu/SxgdRLyJZP4XvklVvbwyEm569sn+LMju2A9I817qbwHojNzKO/7RnVe70quWx2gQ+lnQn7yJ798EWnASGR+XxP5q4heIxb1UA5kF12W7q/T2Rxe28fm5OiPJ01YDNdKDDC6dgQFv5KwMATNQnuYTPggnAhopMSx/goIZf/aahBi/veB4Q8OrKw8NZJUD7lUc/QcVPvx+016DC+igWluQg7WbXTfsOaOG+7lcbDB/8R5LHYVeWHjzAh0qBTo5LA0YvPiQDmsluxPHje8i5K3vglzhdJ7yzsznGwMn+bCk+Hq64O7Esghy6nBPIIuzlRPyQ9CzPlXl7vsPrGP9DbMUju0gWLkA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB3875.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(346002)(136003)(396003)(39860400002)(66556008)(66476007)(66946007)(76116006)(91956017)(26005)(8936002)(53546011)(478600001)(186003)(2906002)(83380400001)(33656002)(64756008)(66446008)(6506007)(86362001)(966005)(8676002)(110136005)(2616005)(36756003)(166002)(316002)(5660300002)(71200400001)(6486002)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 4dYp3/wMivfK4NIZCyLkKpkNhm61AqZAqJrzxXC9hJICyzVBtPOvuTwBpfWfFs3PPGTDG6Z0NFzgD7oSxR8p+nMtKFx1kEUWsnzQ2tldvCuu7YieqKeqEORN5lBO8d7YE2tGJDnkTWe4s7B7ocwcUHGN9EsPqa6LURYISzBGlvDVGo/16MR7ns7iRrgou5GdB6rdZFnJcOeJhRwCRg1mr5T62yLmrkgNvuFRmoNmQLXf2XlYqskzo0TyUR5m7750Lcaym9v5hxYwDAK6un/ey53A06Pf8qfBrYbolSg8V7VYuyCk2pwztbXjMvPQD/nA7cxQqpUY205bO2qQzpa5sk9jSBdU72Zg01FUQ9sQu3eBPQ5CjT9dIRq74laVILFnoBtClAWr7du6wa9o6OysHUSh3MgfHrkqy7nxBLzKSkh0hQXLNb5j2Xp2lb2VXDV2YxHYnQoQ6oddhniRQIugByMuJOJgxhj/X4/iwJ7ZaeirgcDVJt6N0bA0ZMf1OuWe0V/48rNOnp1htQhx42wpFLDKacke3i6jPzUHUeuRVZhpqAqnpqEhwHDd0aYSi9QOwbcjBYB5eGZZp8VOInPttM+32aJJO4BFWVGH8LvYGoprv7hXpS0eRwlwD2zbItOQpyzVIdY/d7G1qYsQEaHyFg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_34A4DADF3D7C46B6952C385B4A9EABD7ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB3875.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4d463e58-6d6c-41ee-4955-08d84374cffd X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2020 12:47:05.6066 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nte2arknfc4MfeO2PIdUzy0tfx9lBdfSUzksHlfqKW9WOSD2sThuHSGSmuZStMp5se2LFDhHmkZMJxrxSqxjxw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB4130 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-kwatsen-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 12:47:12 -0000 --_000_34A4DADF3D7C46B6952C385B4A9EABD7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYnkgTkVUQ09ORiBXRy4gVGhlIHBy b2JsZW0gaXMgYW4gaW1wb3J0YW50IG9uZSB0byBzb2x2ZS4NCg0KUmVnYXJkcywNClJlc2hhZC4N Cg0KRnJvbTogbmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Yg S2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0Pg0KRGF0ZTogV2VkbmVzZGF5LCBBdWd1 c3QgNSwgMjAyMCBhdCA2OjIxIFBNDQpUbzogIm5ldGNvbmZAaWV0Zi5vcmciIDxuZXRjb25mQGll dGYub3JnPg0KU3ViamVjdDogW25ldGNvbmZdIEFkb3B0aW9uLXN1aXRhYmlsaXR5IGZvciBkcmFm dC1rd2F0c2VuLW5ldGNvbmYtc3p0cC1jc3INCg0KDQpORVRDT05GIFdHLA0KDQpQZXIgdGhlIHBy ZXZpb3VzIGVtYWlsIHNlbnQgbW9tZW50cyBhZ28sIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBz b2xpY2l0IGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQ6DQoNCiAgIFRpdGxlOiBDb252ZXlp bmcgYSBDU1IgaW4gYW4gU1pUUCBCb290c3RyYXBwaW5nIFJlcXVlc3QNCiAgIExpbms6IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rd2F0c2VuLW5ldGNvbmYtc3p0cC1jc3INCiAg IEFic3RyYWN0Og0KICAgICAgVGhpcyBkcmFmdCBleHRlbmRzIHRoZSAiZ2V0LWJvb3RzdHJhcHBp bmctZGF0YSIgUlBDIGRlZmluZWQgaW4NCiAgICAgIFJGQyA4NTcyIHRvIGluY2x1ZGUgYW4gb3B0 aW9uYWwgY2VydGlmaWNhdGUgc2lnbmluZyByZXF1ZXN0IChDU1IpLA0KICAgICAgZW5hYmxpbmcg YSBib290c3RyYXBwaW5nIGRldmljZSB0byBhZGRpdGlvbmFsbHkgb2J0YWluIGFuIGlkZW50aXR5 DQogICAgICBjZXJ0aWZpY2F0ZSAoZS5nLiwgYW4gTERldklELCBmcm9tIElFRUUgODAyLjFBUikg YXMgcGFydCBvZiB0aGUNCiAgICAgICJvbmJvYXJkaW5nIGluZm9ybWF0aW9uIiByZXNwb25zZSBw cm92aWRlZCBpbiB0aGUgUlBDLXJlcGx5Lg0KDQoNCkluIHBhcnRpY3VsYXIsIHBsZWFzZSBkaXNj dXNzIGFkb3B0aW9uLXN1aXRhYmlsaXR5IGFzIGl0IHJlZ2FyZHMgdG8gdGhlIGZvbGxvd2luZyBx dWVzdGlvbnM6DQoNCiAgICAxKSBpcyB0aGUgcHJvYmxlbSBpbXBvcnRhbnQgZm9yIHRoZSBORVRD T05GIFdHIHRvIHNvbHZlPw0KICAgIDIpIGlzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJhc2lzIGZv ciB0aGUgd29yaz8NCg0KDQpQUzogdGhpcyBtZXNzYWdlIGlzIGl0c2VsZiBub3QgYW4gYWRvcHRp b24gcG9sbCwgYnV0IHJhdGhlciBhbiBhdHRlbXB0IHRvIGdhdWdlIGludGVyZXN0L3N1cHBvcnQg Zm9yIGEgcG90ZW50aWFsIGZ1dHVyZSBhZG9wdGlvbiBwb2xsLg0KDQpORVRDT05GIENoYWlycw0K --_000_34A4DADF3D7C46B6952C385B4A9EABD7ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1l bnQgYnkgTkVUQ09ORiBXRy4gVGhlIHByb2JsZW0gaXMgYW4gaW1wb3J0YW50IG9uZSB0byBzb2x2 ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlc2hhZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPm5ldGNvbmYgJmx0O25ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxm IG9mIEtlbnQgV2F0c2VuICZsdDtrZW50K2lldGZAd2F0c2VuLm5ldCZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+V2VkbmVzZGF5LCBBdWd1c3QgNSwgMjAyMCBhdCA2OjIxIFBNPGJyPg0KPGI+VG86IDwv Yj4mcXVvdDtuZXRjb25mQGlldGYub3JnJnF1b3Q7ICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5bbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRy YWZ0LWt3YXRzZW4tbmV0Y29uZi1zenRwLWNzcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPk5FVENPTkYgV0csPGJyPg0KPGJyPg0KUGVyIHRoZSBwcmV2aW91cyBlbWFpbCBzZW50IG1v bWVudHMgYWdvLCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gc29saWNpdCBpbnB1dCBvbiB0aGUg Zm9sbG93aW5nIGRyYWZ0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO1RpdGxlOiZuYnNwO0NvbnZleWluZyBhIENTUiBp biBhbiZuYnNwO1NaVFAgQm9vdHN0cmFwcGluZyBSZXF1ZXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7TGluazoNCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC8iPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC88L2E+ZHJhZnQta3dhdHNlbi1uZXRjb25mLXN6dHAtY3NyPC9zcGFuPjxicj4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO0Fic3RyYWN0Ojwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoaXMgZHJhZnQgZXh0ZW5kcyB0aGUgJnF1b3Q7Z2V0 LWJvb3RzdHJhcHBpbmctZGF0YSZxdW90OyBSUEMgZGVmaW5lZCBpbjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgUkZDJm5ic3A7ODU3MiZuYnNwO3RvIGlu Y2x1ZGUgYW4gb3B0aW9uYWwgY2VydGlmaWNhdGUgc2lnbmluZyByZXF1ZXN0IChDU1IpLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVuYWJsaW5nIGEgYm9vdHN0cmFw cGluZyBkZXZpY2UgdG8gYWRkaXRpb25hbGx5IG9idGFpbiBhbiBpZGVudGl0eTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY2VydGlmaWNhdGUgKGUuZy4s IGFuIExEZXZJRCwgZnJvbSBJRUVFIDgwMi4xQVIpIGFzIHBhcnQgb2YgdGhlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtvbmJvYXJkaW5nIGlu Zm9ybWF0aW9uJnF1b3Q7IHJlc3BvbnNlIHByb3ZpZGVkIGluIHRoZSBSUEMtcmVwbHkuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48YnI+DQpJbiBwYXJ0aWN1bGFyLCBwbGVhc2UgZGlzY3VzcyBhZG9wdGlvbi1z dWl0YWJpbGl0eSBhcyBpdCByZWdhcmRzIHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsgJm5ic3A7IDEpIGlzIHRoZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENP TkYgV0cgdG8gc29sdmU/PGJyPg0KJm5ic3A7ICZuYnNwOyAyKSBpcyB0aGUgZHJhZnQgYSBzdWl0 YWJsZSBiYXNpcyBmb3IgdGhlIHdvcms/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+ DQo8YnI+DQpQUzogdGhpcyBtZXNzYWdlIGlzIGl0c2VsZiBub3QgYW4gYWRvcHRpb24gcG9sbCwg YnV0IHJhdGhlciBhbiBhdHRlbXB0IHRvIGdhdWdlIGludGVyZXN0L3N1cHBvcnQgZm9yIGEgcG90 ZW50aWFsIGZ1dHVyZSBhZG9wdGlvbiBwb2xsLjxicj4NCjxicj4NCk5FVENPTkYgQ2hhaXJzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_34A4DADF3D7C46B6952C385B4A9EABD7ciscocom_-- From nobody Tue Aug 18 06:42:42 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFCB3A0A38 for ; Tue, 18 Aug 2020 06:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=a7zYXhMO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=yaMC4AWg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wM5p-IOGFC3w for ; Tue, 18 Aug 2020 06:42:38 -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 543DF3A0A2D for ; Tue, 18 Aug 2020 06:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15544; q=dns/txt; s=iport; t=1597758158; x=1598967758; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=hkycSRon7lvDM30TSQAW+iKg1oo5D5psWB1uhmtqLXA=; b=a7zYXhMOb+unb42qEYvNuOEKJQ66IxUm6jzZC4mGxpvrlVqQxO84C1SC Giw9KJ1V6DgmbDQnzgSTS6GbJl2iQHPne2ekT8AZJNOFwsNL4UZwXbPvg EvoupWRRzqqWoZW7mm1NcNmYW11AR3gi2nTTxijW/SqYId9Rqv1t7TzhW o=; IronPort-PHdr: =?us-ascii?q?9a23=3AZ0/Fsx/BkMpLzf9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRKN+vxxl1LPG4PW96EMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iKkOFROFcC4YVDO8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmEADP2Ttf/4cNJK1fHQEBPAEFBQE?= =?us-ascii?q?CAQkBgWGBIS8pKAdwWC8sCoQtg0YDjVmTfIRtglMDVQsBAQEMAQEjCgIEAQG?= =?us-ascii?q?ETAIXgggCJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBBBIRChMBATgPAgE?= =?us-ascii?q?IEQQBASsCAgIwHQgCBAESCBqDBYF+TQMuAQMLpSoCgTmIYXaBMoMBAQEFgTc?= =?us-ascii?q?EDEGDLhiCDgMGgTgBgnCDYoUYgRcdG4FBP4ERQ4JNPoJcAQECAQGBXSuCajO?= =?us-ascii?q?CLZMDhmGcTwqCYohkhXyLYoMAjw6OFZI7gW2IV5R8AgQCBAUCDgEBBYFqIyq?= =?us-ascii?q?BLXAVgyRQFwINgzqKcReBAgEJgkKFFIVCdDcCBgEJAQEDCXyPCAGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,327,1592870400"; d="scan'208,217";a="815417494" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Aug 2020 13:42:37 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 07IDgbVO006541 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Aug 2020 13:42:37 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 08:42:36 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 08:42:36 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 18 Aug 2020 09:42:36 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bJLMg2wAgFLWeDYCJvLi7K51HGD7XOfPoREpTsTxD7X0dJm0/PSG9tyX2JS7iQCJL05vS1+3bvjHvd2bsFCrQ69exCjZVSk2vmW4KvLJxX6IXZFJog7cpEteFouiVHEuCWdBUESMw7JlLvYTp9h7Cq68WfEbzmZFHb3Kt7ZXOnuSBQ42xXznXKRtaJHn7zG42uKgu+gLySgLEDPjg96bvqQQBGNSR7dRnVDIU1aKLkHgXRjDy4QJBlbuWO1pFLO1f+LceUYk/s0++Z/YN7ObZss7MVA2LyJgi3iCL2DWFoQsNgywxTimskS1h0pCuSasQDxfsoprSq5tp89oNg27WA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hkycSRon7lvDM30TSQAW+iKg1oo5D5psWB1uhmtqLXA=; b=H8B1zQZRCV4Gnj/lR6CZrP3l1LOk0Dvu9NpUYCWpl5SqzvDQNU4v9zEyFALR11TlZEjwKCtHEyoqXPppDlpRIEMR9TfznNHOHd3TYOYDzDT9wpvZRu7n197PyF9/ra0l5VCBPmn750lI0jZg1kWhULRNz4qsjP2eaWMKlpbpM2ezhITpthg4OWpUu/6o2+UbyjkA2/5ybVIVZK6RPorMPWyrKmde9/MUz4SI6RhbV8WoFfNz30ES5Sy3Qu+YrH75YCxUNCHcw2E+rbETBvYa05hZNwAwYYcUDlGDwMvKkfC8jiWime4uwJCk67y22QQadzKKeMUkhlmJ2bt03JI93A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hkycSRon7lvDM30TSQAW+iKg1oo5D5psWB1uhmtqLXA=; b=yaMC4AWgIMi1i6V6K35jMpyvQqpIqBEyw7cf9H0gJQGNwmXmlY4i8S3tcvfe+Y/EjzGgR5qHdG5Cu0z4guPcGp6yVcc5lIdy3KQiWCjuUY9S3oT0/rpT4v68sF0ie30uuJKaYfpqF/eTHjwb1+XDHElzSDFZca2SoCgBCD9+C3Y= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4112.namprd11.prod.outlook.com (2603:10b6:208:137::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.22; Tue, 18 Aug 2020 13:42:35 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1%3]) with mapi id 15.20.3305.024; Tue, 18 Aug 2020 13:42:35 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif Thread-Index: AQHWa3Y6avwfNnDrJE+0cgibzhg5G6ktGCIAgBC2KdA= Date: Tue, 18 Aug 2020 13:42:35 +0000 Message-ID: References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.com> In-Reply-To: <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.15.79.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d10187b6-d736-4944-8a5b-08d8437c90ba x-ms-traffictypediagnostic: MN2PR11MB4112: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TgvUvcrGsxwLu2cLurmnkebxOfFdke1OZxg7BhwN43+YUwpaTZ4qkL287zcMCXWQEbL9VNYCvucKYgLPVXO7k/getGvVj730cTkkHFPGAQuqjDykx5r8IU/kDNDBvdGr1ummWFNHUFAp2VfThB1VzfI8ctigSWrfmLdQLPakK1uY0ofK12k2e+wE4qBGOl7iix9+424khKjQQoKSbiMbSAnbM40RD865eqVG5B5w8PPJ3HlLKwTBgy/d4Mh/ND720/T1ghvCE/MgBguh0agodWOEKGXgPAzitQpX9Bdx8rf490Wa4uFiS02EyqHBdIFTvMfpu78eAPKdVGojMT9WMQaQ6efBw64vHmWTcqzanJ1r0ghIBukRqh9UnqWujHMFOzBBL3fKauujl01ILmUwxw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(366004)(396003)(376002)(39860400002)(9326002)(66446008)(76116006)(2906002)(8936002)(166002)(66946007)(71200400001)(110136005)(8676002)(26005)(66476007)(64756008)(9686003)(66556008)(478600001)(966005)(52536014)(7696005)(55016002)(316002)(33656002)(53546011)(6506007)(86362001)(83380400001)(186003)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: rFXiRSN+l950L5r2OW7S38Us5Jr3AxxjfVtVOuos7JCXdoNNrSjgFivityj6yh0yihUVB+9jCp5LZt+rbsI0/uqWQk/tUUy+K2MPLvk5VM0Quj36MdK06sYRSPbbCYJQTkulzbswAdNZ8LAEqnAKK126/ZkRCBPHsG4Z28BRWwc5XY/u0AMDLz80fUG36oTk19UFMo99pP+PHsRRpY+m6tfvfSYzH4YdYl9qfQpp2bV+Vy1itHJa1vS6NnfVzTPRNy8ogOymvBxEHFa1t+4/wNCNZIohQWEXQLRJMU++t6chV65o7ZKw1ip4BhckVLn/YFP22Msb1aL8CougHX5GoEFEJXudoPbVtl+Ox4WDxWxJ5vZOIfkyBu/Knf/n++PonXDBpjamD3JfKYCAjwMb6k/Dmrx2lhuT6YTZQr2dcOzV1dqAYcu1m5fE1W/NY5ko1FG5I6GSKyC7ElH8DdLGDtUuxdKEV36sJtW3f6szeJSVhvcuYAUoZW7F2jASWnWKrOknDK6QxfB1VqybuciOtyv6GSuLdirYH52styDpMJJQ/EH9K6hQp1NZezfkZrd2tqGF7/gi8L7K5m1NVJYWaWshSiVnPyikfuCM35e3ldr6v+hP9rNmfEG24YUccPG8+dUrZk9mDu9HC+pg+dArwQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366A4D447677823320BDC96B55C0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d10187b6-d736-4944-8a5b-08d8437c90ba X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2020 13:42:35.5725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OvPVtzINF6hvGa4xk85nmkqWJBCohcJJDMpVQhVqrgws/bq3bwSkFF/aEMDlXJm9EPFkVT+dVBPcaxWZtr+mUA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4112 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 13:42:41 -0000 --_000_MN2PR11MB4366A4D447677823320BDC96B55C0MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCltBbHNvIGFzIGEgY29udHJpYnV0b3JdDQoNCk15IGNvbW1lbnRzIGFyZSBicm9hZGx5 IHNpbWlsYXIgdG8gS2VudOKAmXMuDQoNCkkgYmVsaWV2ZSB0aGF0IGEgVURQIHRyYW5zcG9ydCBm b3IgZGF0YXBsYW5lIHRlbGVtZXRyeSB3aGVyZSBnZXR0aW5nIGFjY3VyYXRlIGZyZXNoIGRhdGEg cXVpY2tseSBpcyBtb3JlIGltcG9ydGFudCB0aGFuIGdldHRpbmcgZXZlcnkgdXBkYXRlLiAgVGhp cyBpcyBwYXJ0aWN1bGFybHkgdHJ1ZSBpZiBhIHN1YnNlcXVlbnQgbm90aWZpY2F0aW9uIHdpbGwg Y292ZXIgYW55IGxvc3QgdmFsdWVzIGFueXdheSAoZS5nLiBwZXJpb2RpYyBzdGF0aXN0aWNzKS4N Cg0KSSBzdXNwZWN0IHRoYXQgaGF2aW5nIGEgbWVjaGFuaXNtIHRvIGFsbG93IGZvciB0aGUgdGVs ZW1ldHJ5IGRhdGEgYmVpbmcgZW5jcnlwdGVkIGlzIHByb2JhYmx5IGFsc28gaW1wb3J0YW50LiAg SWYgdGhlIFdHIHdlcmUgdG8gYWRvcHQgYSBkcmFmdCB3aXRob3V0IHRoaXMsIHRoZW4gYXMgQmVu b2l0IG1lbnRpb25lZCwgSSB3b3VsZCBoYXZlIHRvIHRlc3QgdGhlIHdhdGVyIHdpdGggdGhlIElF U0cgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhhdCB3b3VsZCBiZSBhY2NlcHRhYmxlLg0KDQpJIGFs c28gbm90ZSB0aGF0IHRoZSBkcmFmdCBhbGxvd3MgZm9yIGEgR1BCIGVuY29kaW5nIG9mIHRoZSB0 ZWxlbWV0cnkgZGF0YSwgYnV0IEnigJltIG5vdCBhd2FyZSBvZiBhbnkgZm9ybWFsIHN0YW5kYXJk IGVuY29kaW5nIG9mIFlBTkcgZGF0YSBpbiBHUEIsIGFuZCB0aGVyZSBpcyBhIGNob2ljZSBiZXR3 ZWVuIHdoZXRoZXIgdGhlIEdQQiBlbmNvZGluZyBpcyBnZW5lcmljIGZvciBhbGwgWUFORyBkYXRh LCBvciBzcGVjaWZpYyBHUEIgZW5jb2RpbmdzIGFyZSB1c2VmdWwgZm9yIHRoZSBzcGVjaWZpYyBk YXRhIHRoYXQgaXMgYmVpbmcgZW5jb2RlZC4NCg0KUmVnYXJkcywNClJvYg0KDQoNCkZyb206IG5l dGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEtlbnQgV2F0c2Vu DQpTZW50OiAwNyBBdWd1c3QgMjAyMCAyMToxNg0KVG86IG5ldGNvbmZAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0LXVueXRlLW5l dGNvbmYtdWRwLW5vdGlmDQoNClthcyBhIGNvbnRyaWJ1dG9yXQ0KDQoNCiAgIDEpIGlzIHRoZSBw cm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cgdG8gc29sdmU/DQoNCkkgYmVsaWV2 ZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBlbmFibGUgcHVibGlzaGVycyB0byBzZW5kIG5vdGlm aWNhdGlvbnMgdXNpbmcgYSBVRFAtYmFzZWQgdHJhbnNwb3J0LiAgIFRoaXMgYmVsaWVmIGlzIGJh c2VkIG9uIG15IGV4cGVyaWVuY2UgZnJvbSB3aGVuIGF0IEp1bmlwZXIgZGVhbGluZyB3aXRoIHZl cnkgaGlnaC1lbmQgZmlyZXdhbGxzIHdpdGggZW5vcm1vdXMgbG9nIG91dHB1dC4NCg0KSSBiZWxp ZXZlIHRoYXQgdGhlIE5FVENPTkYgV0cgaXMgdGhlIGFwcHJvcHJpYXRlIFdHIGZvciB0aGlzIHdv cmssIGhhdmluZyBkZWZpbmVkIFJGQyA4NjM5IChTTiksIFJGQyA4NjQwIChOTiksIGFuZCBSRkMg ODY1MCAoUk4pLg0KDQoNCg0KICAgMikgaXMgdGhlIGRyYWZ0IGEgc3VpdGFibGUgYmFzaXMgZm9y IHRoZSB3b3JrPw0KDQpJIGhhdmUgcmVhZCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFm dCBhbmQgZmluZCBpdCB0byBiZSBhIHJlYXNvbmFibGUgc3RhcnQuDQoNClByZXN1bWluZyB0aGUg 4oCccmVjZWl2ZXItaW5zdGFuY2Vz4oCdIGF1Z21lbnRhdGlvbiBkZWZpbmVkIGluIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYtMDQjc2Vj dGlvbi0zIHRha2VzIG9mZiwgdGhlIG1vZHVsZSBkZWZpbmVkIGluIHRoaXMgZHJhZnQgc2hvdWxk IGJlIHVwZGF0ZWQgdG8gYXVnbWVudCBpbnRvIGl0IGluc3RlYWQuDQoNCkkgYXBwcmVjaWF0ZSBT ZWN0aW9uIDUgKEFwcGxpY2FiaWxpdHkpIG5vdGluZyB0aGF0IHRoZSBVRFAtdHJhbnNwb3J0IGlz IHByaW1hcmlseSBmb3IgdGhlIGRhdGEgcGxhbmUgKG5vdCB0aGUgY29udHJvbCBwbGFuZSksIGFz IGl0IGRvZXNu4oCZdCBtYXR0ZXIgc28gbXVjaCBpZiBkYXRhIHBsYW5lIG5vdGlmaWNhdGlvbnMg YXJlIGxvc3QuICBUaGlzIGFkZHJlc3NlcyAoSSB0aGluaykgdGhlIGlzc3VlIHRoYXQgUm9iIFNo YWtpciByYWlzZWQgYmVmb3JlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9taW51 dGVzLTEwMy1uZXRjb25mIChzZWFyY2ggZm9yIOKAnFJvYiBT4oCdKS4gIFRoYXQgc2FpZCwgaXQg aXMgdW5jbGVhciB0byBtZSBob3cgYSByZWNlaXZlciBjb3VsZCBjb25maWd1cmUgdGhpcyB3aGls ZSwgZS5nLiwgY29uZmlndXJpbmcgY29udHJvbCBwbGFuZSBub3RpZmljYXRpb25zIHRvIGJlIHNl bnQgdmlhIGEgVENQLWJhc2VkIHRyYW5zcG9ydCBzdWNoIGFzIOKAnGh0dHBzLW5vdGlm4oCdLg0K DQoNCjMpIHJlZ2FyZGluZyBKdWVyZ2Vu4oCZcyBxdWVzdGlvbnM6DQoNCiAgYSkgSSBhbSB3aWxs aW5nIHRvIHN1YnN0YW50aWFsbHkgcmV2aWV3IHRoZSBkcmFmdHMuDQogIGIpIEkgYW0gd2lsbGlu ZyB0byBjb250cmlidXRlIHRvIHRoZSBkaXNjdXNzaW9uIG9mIGFueSBpc3N1ZS4NCiAgYykgSSBk byBOT1QgcGxhbiB0byBpbXBsZW1lbnQgdGhlIHRlY2hub2xvZ3kgZGVmaW5lZC4NCg0KDQoNCktl bnQNCg== --_000_MN2PR11MB4366A4D447677823320BDC96B55C0MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPltBbHNvIGFzIGEg Y29udHJpYnV0b3JdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPk15IGNvbW1lbnRzIGFyZSBicm9hZGx5IHNpbWlsYXIgdG8gS2Vu dOKAmXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkkgYmVsaWV2ZSB0aGF0IGEgVURQIHRyYW5zcG9ydCBmb3IgZGF0YXBsYW5l IHRlbGVtZXRyeSB3aGVyZSBnZXR0aW5nIGFjY3VyYXRlIGZyZXNoIGRhdGEgcXVpY2tseSBpcyBt b3JlIGltcG9ydGFudCB0aGFuIGdldHRpbmcgZXZlcnkgdXBkYXRlLiZuYnNwOyBUaGlzIGlzIHBh cnRpY3VsYXJseSB0cnVlIGlmIGEgc3Vic2VxdWVudCBub3RpZmljYXRpb24NCiB3aWxsIGNvdmVy IGFueSBsb3N0IHZhbHVlcyBhbnl3YXkgKGUuZy4gcGVyaW9kaWMgc3RhdGlzdGljcykuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pkkgc3VzcGVjdCB0aGF0IGhhdmluZyBhIG1lY2hhbmlzbSB0byBhbGxvdyBmb3IgdGhlIHRlbGVt ZXRyeSBkYXRhIGJlaW5nIGVuY3J5cHRlZCBpcyBwcm9iYWJseSBhbHNvIGltcG9ydGFudC4mbmJz cDsgSWYgdGhlIFdHIHdlcmUgdG8gYWRvcHQgYSBkcmFmdCB3aXRob3V0IHRoaXMsIHRoZW4gYXMg QmVub2l0IG1lbnRpb25lZCwgSSB3b3VsZCBoYXZlDQogdG8gdGVzdCB0aGUgd2F0ZXIgd2l0aCB0 aGUgSUVTRyB0byBkZXRlcm1pbmUgd2hldGhlciB0aGF0IHdvdWxkIGJlIGFjY2VwdGFibGUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkkgYWxzbyBub3RlIHRoYXQgdGhlIGRyYWZ0IGFsbG93cyBmb3IgYSBHUEIgZW5jb2Rpbmcg b2YgdGhlIHRlbGVtZXRyeSBkYXRhLCBidXQgSeKAmW0gbm90IGF3YXJlIG9mIGFueSBmb3JtYWwg c3RhbmRhcmQgZW5jb2Rpbmcgb2YgWUFORyBkYXRhIGluIEdQQiwgYW5kIHRoZXJlIGlzIGEgY2hv aWNlIGJldHdlZW4gd2hldGhlciB0aGUgR1BCIGVuY29kaW5nDQogaXMgZ2VuZXJpYyBmb3IgYWxs IFlBTkcgZGF0YSwgb3Igc3BlY2lmaWMgR1BCIGVuY29kaW5ncyBhcmUgdXNlZnVsIGZvciB0aGUg c3BlY2lmaWMgZGF0YSB0aGF0IGlzIGJlaW5nIGVuY29kZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPGJyPg0K Um9iPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IG5ldGNvbmYgJmx0O25ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJl aGFsZiBPZiA8L2I+S2VudCBXYXRzZW48YnI+DQo8Yj5TZW50OjwvYj4gMDcgQXVndXN0IDIwMjAg MjE6MTY8YnI+DQo8Yj5Ubzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0 Y29uZi11ZHAtbm90aWY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+W2FzIGEgY29udHJpYnV0b3JdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOzEpIGlzIHRoZSBwcm9ibGVtIGltcG9ydGFudCBmb3IgdGhlIE5FVENPTkYgV0cgdG8g c29sdmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZlIHRoYXQgaXQgaXMgaW1wb3J0YW50 IHRvIGVuYWJsZSBwdWJsaXNoZXJzIHRvIHNlbmQgbm90aWZpY2F0aW9ucyB1c2luZyBhIFVEUC1i YXNlZCB0cmFuc3BvcnQuICZuYnNwOyBUaGlzIGJlbGllZiBpcyBiYXNlZCBvbiBteSBleHBlcmll bmNlIGZyb20gd2hlbiBhdCBKdW5pcGVyIGRlYWxpbmcgd2l0aCB2ZXJ5IGhpZ2gtZW5kIGZpcmV3 YWxscyB3aXRoIGVub3Jtb3VzIGxvZyBvdXRwdXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSBi ZWxpZXZlIHRoYXQgdGhlJm5ic3A7PC9zcGFuPk5FVENPTkYgV0cgaXMgdGhlIGFwcHJvcHJpYXRl IFdHIGZvciB0aGlzIHdvcmssIGhhdmluZyBkZWZpbmVkIFJGQyA4NjM5IChTTiksJm5ic3A7PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SRkMgODY0MCAoTk4pLCBhbmQmbmJzcDs8L3NwYW4+UkZD IDg2NTAgKFJOKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsyKSBpcyB0aGUgZHJhZnQgYSBzdWl0YWJsZSBi YXNpcyBmb3IgdGhlIHdvcms/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgcmVhZCB0aGUgY3VycmVudCB2 ZXJzaW9uIG9mIHRoZSBkcmFmdCBhbmQgZmluZCBpdCB0byBiZSBhIHJlYXNvbmFibGUgc3RhcnQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBy ZXN1bWluZyB0aGUg4oCccmVjZWl2ZXItaW5zdGFuY2Vz4oCdIGF1Z21lbnRhdGlvbiBkZWZpbmVk IGluJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bmV0Y29uZi1odHRwcy1ub3RpZi0wNCNzZWN0aW9uLTMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYtMDQjc2VjdGlvbi0zPC9hPiZuYnNw O3Rha2VzIG9mZiwgdGhlIG1vZHVsZQ0KIGRlZmluZWQgaW4gdGhpcyBkcmFmdCBzaG91bGQgYmUg dXBkYXRlZCB0byBhdWdtZW50IGludG8gaXQgaW5zdGVhZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+SSBhcHByZWNpYXRlIFNlY3Rpb24gNSAoQXBwbGljYWJpbGl0eSkgbm90aW5nIHRo YXQgdGhlIFVEUC10cmFuc3BvcnQgaXMgcHJpbWFyaWx5IGZvciB0aGUgZGF0YSBwbGFuZSAobm90 IHRoZSBjb250cm9sIHBsYW5lKSwgYXMgaXQgZG9lc27igJl0IG1hdHRlciBzbyBtdWNoIGlmIGRh dGEgcGxhbmUgbm90aWZpY2F0aW9ucyBhcmUgbG9zdC4gJm5ic3A7VGhpcyBhZGRyZXNzZXMgKEkN CiB0aGluaykgdGhlIGlzc3VlIHRoYXQgUm9iIFNoYWtpciByYWlzZWQgYmVmb3JlOiA8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9taW51dGVzLTEwMy1uZXRjb25mIj4N Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL21pbnV0ZXMtMTAzLW5ldGNvbmY8L2E+ Jm5ic3A7KHNlYXJjaCBmb3Ig4oCcUm9iIFPigJ0pLiAmbmJzcDtUaGF0IHNhaWQsIGl0IGlzIHVu Y2xlYXIgdG8gbWUgaG93IGEgcmVjZWl2ZXIgY291bGQgY29uZmlndXJlIHRoaXMgd2hpbGUsIGUu Zy4sIGNvbmZpZ3VyaW5nIGNvbnRyb2wgcGxhbmUgbm90aWZpY2F0aW9ucyB0byBiZSBzZW50IHZp YSBhIFRDUC1iYXNlZCB0cmFuc3BvcnQgc3VjaCBhcyDigJxodHRwcy1ub3RpZuKAnS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjMpIHJlZ2FyZGluZyBK dWVyZ2Vu4oCZcyBxdWVzdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyBhKSBJIGFtIHdpbGxpbmcgdG8gc3Vi c3RhbnRpYWxseSByZXZpZXcgdGhlIGRyYWZ0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyBiKSBJIGFtJm5ic3A7d2lsbGluZyB0byBjb250cmlidXRlIHRvIHRoZSBkaXNjdXNz aW9uIG9mIGFueSBpc3N1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyBjKSBJ IGRvIE5PVCZuYnNwO3BsYW4gdG8gaW1wbGVtZW50IHRoZSB0ZWNobm9sb2d5IGRlZmluZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5LZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR11MB4366A4D447677823320BDC96B55C0MN2PR11MB4366namp_-- From nobody Tue Aug 18 09:23:32 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0C73A0E9C for ; Tue, 18 Aug 2020 09:23:31 -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 K0JjsnOQlCr7 for ; Tue, 18 Aug 2020 09:23:27 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id 35EEA3A0E97 for ; Tue, 18 Aug 2020 09:23:24 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.92:47314.1972376415 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-116.232.12.105?logid-e353a56b9e334946bef3eb8056c6d473 (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 2FBCC2800A5; Wed, 19 Aug 2020 00:23:19 +0800 (CST) X-189-SAVE-TO-SEND: 31100443@chinatelecom.cn Received: from ([172.18.0.92]) by App0021 with ESMTP id e353a56b9e334946bef3eb8056c6d473 for netconf@ietf.org; Wed Aug 19 00:23:20 2020 X-Transaction-ID: e353a56b9e334946bef3eb8056c6d473 X-filter-score: filter<0> X-Real-From: zhangy666@chinatelecom.cn X-Receive-IP: 172.18.0.92 X-MEDUSA-Status: 0 Sender: zhangy666@chinatelecom.cn Date: Wed, 19 Aug 2020 00:23:20 +0800 From: "zhangy666@chinatelecom.cn" To: "netconf@ietf.org" X-Priority: 3 X-GUID: 51B0E99C-AA97-4A13-94D8-117C6CCD23C4 X-Has-Attach: no X-Mailer: Foxmail 7.2.16.188[cn] Mime-Version: 1.0 Message-ID: <20200819002320033436105@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart433504405586_=----" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 16:23:32 -0000 This is a multi-part message in MIME format. ------=_001_NextPart433504405586_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgcmVhZCB0aGUgZHJhZnQsIHJlZ2FyZGluZyB0aGUgdHdvIHF1ZXN0aW9u cywgdGhlIGNvbW1lbnRzIGFyZSBhcyBmb2xsb3dzOg0KDQoxLiBJcyB0aGUgcHJvYmxlbSBpbXBv cnRhbnQgZm9yIHRoZSBORVRDT05GIFdHIHRvIHNvbHZlPw0KSSBiZWxpZXZlIHRoYXQgaXQgaXMg aW1wb3J0YW50IHRvIG1pbmltaXplIHRoZSBudW1iZXIgb2Ygc3Vic2NyaXB0aW9uIGl0ZXJhdGlv bnMgYmV0d2VlbiBzdWJzY3JpYmVyIGFuZCBwdWJsaXNoZXIgb24gd2hpY2ggdHJhbnNwb3J0IHBy b3RvY29sLCBlbmNvZGluZywgc2VjdXJpdHkgcGFyYW1ldGVycywgY29tcHJlc3Npb24gc2NoZW1l cyBhcmUgc3VwcG9ydGVkLCB3aGF0IGtpbmQgb2Ygc3Vic2NyaXB0aW9uIHBvbGljeSBjYW4gYmUg Y29tcG9zZWQgYW5kIFJhbmRvbSBndWVzc2luZyBvZiBkaWZmZXJlbnQgcGFyYW1ldGVycyBieSBh IHN1YnNjcmliZXIgaXMgbm90IGRlc2lyYWJsZSBhY2NvcmRpbmcgdG8gUkZDODY0MS4gRGF0YSBl eHBvcnQgYWltIGF0IGFkZHJlc3NpbmcgdGhlc2UgaXNzdWVzLiBJIGJlbGlldmUgdGhhdCB0aGUg TkVUQ09ORiBXRyBpcyB0aGUgYXBwcm9wcmlhdGUgV0cgZm9yIHRoaXMgd29yay4gU2VydmljZSBj YXBhYmlsaXR5IG5vdGlmaWNhdGlvbiBkZWZpbmVkIGluIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3Rp ZmljYXRpb24tY2FwYWJpbGl0aWVzIGhhcyBiZWVuIHJlLWZhY3RvcmVkIHRvIGJlIG1vcmUgZ2Vu ZXJpYyBhbmQgcHJvdmlkZXMgYSBnb29kIGJhc2lzLg0KDQoyLiBJcyB0aGUgZHJhZnQgYSBzdWl0 YWJsZSBiYXNpcyBmb3IgdGhlIHdvcms/DQpJIHRoaW5rIHRoaXMgZHJhZnQgaGFzIGJlZW4gbWF0 dXJlIGVub3VnaCBhbmQgcHJvdmlkZSBhIHNvbGlkIGJhc2lzIGZvciBiZWluZyBtb3ZlZCBmb3J3 YXJkLiBJZiB0aGlzIHdvcmsgZ2V0cyBhZG9wdGVkLCBJIHdpbGwgYmUgZ2xhZCB0byByZXZpZXcg YW55IHVwZGF0ZSBvZiB0aGlzIGRyYWZ0IGFuZCBjb250cmlidXRlIHRvIHJlbGF0ZSBkaXNjdXNz aW9uLg0KDQpJIGJlbGlldmUgaXQgc2hvdWxkIG1vdmUgZm9yd2FyZC4gSWYgdGhlIGRyYWZ0IGdl dHMgYWRvcHRlZCwgSSBhbSB3aWxsaW5nIHRvIGNvbnRyaWJ1dGUgdG8gaXQuDQoNCkJlc3QgcmVn YXJkcywNCg0KDQpZdWFuIFpIQU5HINXF1LAgDQoNCkNoaW5hIFRlbGVjb20gUmVzZWFyY2ggSW5z dGl0dXRlINbQufq159DF0dC+v9S6DQpUZWw6ICs4Ni0xODkxODU4ODk5MA0KRW1haWw6IHpoYW5n eTY2NkBjaGluYXRlbGVjb20uY24NCg== ------=_001_NextPart433504405586_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable =0A
Dear all,

=
I r= ead the draft, regarding the two questions, the comments = are as follows:

1. Is the problem important for the NETCONF WG= to solve?
I believe that = it is important to minimize the number of subscription iterations between = subscriber and publisher on which transport protocol, encoding, security parameters, compression schemes = are supported, what kind of subscription policy can be composed and Random= guessing of different parameters by a subscriber is not desirable according to RFC8641. Data export aim = at addressing these issues. I b= elieve that the NETCONF WG is the appropriate WG for this work. Service ca= pability notification defined in draft-ietf-netconf-notification-capabilit= ies has been re-factored to be = more generic and provides a good basis.

2. Is t= he draft a suitable basis for the work?
I think this draft has been mature enough and provide a soli= d basis for being moved forward. I believe it should move f= orward. If the draft gets adopted, I am willing to contribute to it.

Bes= t regards,
=0A
= Yuan ZHANG = =D5=C5=D4=B0 =

China Telecom Research Institute =D6=D0=B9=FA=B5=E7=D0=C5=D1=D0= =BE=BF=D4=BA
Tel: +86-18918588990
Email: zhangy666@chinatelecom.cn
=0A ------=_001_NextPart433504405586_=------ From nobody Tue Aug 18 09:24:04 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A0E3A0EA4 for ; Tue, 18 Aug 2020 09:24:03 -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 1FuudwPptOrI for ; Tue, 18 Aug 2020 09:24:00 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.223]) by ietfa.amsl.com (Postfix) with ESMTP id 29B453A0EAE for ; Tue, 18 Aug 2020 09:23:52 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.218:21234.1840317111 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-116.232.12.105?logid-9bdd04c15fdb420a9f4a4f3fe13d6f8e (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 5BB442800A1; Wed, 19 Aug 2020 00:23:43 +0800 (CST) X-189-SAVE-TO-SEND: 31100443@chinatelecom.cn Received: from ([172.18.0.218]) by App0025 with ESMTP id 9bdd04c15fdb420a9f4a4f3fe13d6f8e for netconf@ietf.org; Wed Aug 19 00:23:45 2020 X-Transaction-ID: 9bdd04c15fdb420a9f4a4f3fe13d6f8e X-filter-score: filter<0> X-Real-From: zhangy666@chinatelecom.cn X-Receive-IP: 172.18.0.218 X-MEDUSA-Status: 0 Sender: zhangy666@chinatelecom.cn Date: Wed, 19 Aug 2020 00:23:45 +0800 From: "zhangy666@chinatelecom.cn" To: "netconf@ietf.org" X-Priority: 3 X-GUID: C2627684-010A-4266-AAAD-C2CE6AB89B84 X-Has-Attach: no X-Mailer: Foxmail 7.2.16.188[cn] Mime-Version: 1.0 Message-ID: <20200819002344774581107@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart544808438733_=----" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 16:24:03 -0000 This is a multi-part message in MIME format. ------=_001_NextPart544808438733_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsIA0KDQpSZWdhcmRpbmcgdGhlIHR3byBxdWVzdGlvbnMsIHRoZSBjb21tZW50cyBh cmUgYXMgZm9sbG93czoNCg0KMS4gSXMgdGhlIHByb2JsZW0gaW1wb3J0YW50IGZvciB0aGUgTkVU Q09ORiBXRyB0byBzb2x2ZT8NCkkgYmVsaWV2ZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byByZXRy aWV2ZSBkaWZmZXJlbnQgS1BJIGRhdGEgZnJvbSB2YXJpb3VzIGRpZmZlcmVudCBkYXRhIHNvdXJj ZSBhbmQgY29ycmVsYXRlIHRoZW0gdG9nZXRoZXIgYW5kIHByb3ZpZGUgY29tcHJlaGVuc2l2ZSB2 aWV3IG9mIHRoZSBuZXR3b3JrIHF1YWxpdHkgb3IgbmV0d29yayBoZWFsdGggZnJvbSBkaWZmZXJl bnQgYW5nbGVzLiBJbiBhZGRpdGlvbiwgaXQgaXMgaW1wb3J0YW50IHRvIGVsaW1pbmF0ZSBub2lz ZSBkYXRhIHRvIGJlIGV4cG9ydGVkIHRvIHRoZSBtYW5hZ2VtZW50IHBsYW5lLiBUZWxlbWV0cnkg ZGF0YSB0YWdnaW5nIGFuZCBjbGFzc2lmaWNhdGlvbiBpcyBjcnVjaWFsIHRvIGhlbHAgY2FwdHVy ZSBjaGFyYWN0ZXJpc3RpY3MgZGF0YSBhbmQgcmVkdWNlIGFtb3VudCBvZiBzdHJlYW1lZCBkYXRh IHRvIHRoZSBkZXN0aW5hdGlvbi4gQW5kIEkgYWxzbyBiZWxpZXZlIHRoYXQgdGhlIE5FVENPTkYg V0cgaXMgdGhlIGFwcHJvcHJpYXRlIFdHIGZvciB0aGlzIHdvcmsuIGRyYWZ0LWlldGYtbmV0Y29u Zi1ub3RpZmljYXRpb24tY2FwYWJpbGl0aWVzIHNlcGFyYXRlIG5vdGlmaWNhdGlvbiBjYXBhYmls aXR5IG1vZGVsIGludG8gc3lzdGVtIGNhcGFiaWxpdHkgbW9kZWwgYW5kIGlldGYtbm90aWZpY2F0 aW9uLWNhcGFiaWxpdGllcyBtb2RlbCB3aGljaCBzZXJ2ZSBhcyBhIGdvb2QgYmFzaXMgZm9yIHRl bGVtZXRyeSBkYXRhIG5vZGUgY2FwYWJpbGl0aWVzIGRlZmluaXRpb25zLg0KDQoyLiBJcyB0aGUg ZHJhZnQgYSBzdWl0YWJsZSBiYXNpcyBmb3IgdGhlIHdvcms/DQpJIGhhdmUgYmVlbiBhd2FyZSBN RFQgVGVsZW1ldHJ5IHRhZ2dpbmcgSGFja2F0aG9uIHByb2plY3QgaW4gSUVURiAxMDYgd2hpY2gg d2FzIGRlbW9uc3RyYXRlZCBpbiBib3RoIElFVEYgMTA2IEhha2NhdGhvbiBtZWV0aW5nIGFuZCBI YWNrZGVtbyBIYXBweSBIb3VyLiBJIHRoaW5rIHRoaXMgZHJhZnQgaXMgbWF0dXJlIGVub3VnaCBh bmQgcHJvdmlkZSBhIHNvbGlkIGJhc2lzIGZvciBzdGFydGluZyBwb2ludC4gSWYgdGhpcyB3b3Jr IGdldHMgYWRvcHRlZCwgSSB3aWxsIGJlIGdsYWQgdG8gcmV2aWV3IGFueSB1cGRhdGUgb2YgdGhp cyBkcmFmdCBhbmQgY29udHJpYnV0ZSB0byByZWxhdGUgZGlzY3Vzc2lvbi4NCg0KSSBiZWxpZXZl IGl0IHNob3VsZCBtb3ZlIGZvcndhcmQuDQoNCkJlc3QgcmVnYXJkcywNCg0KDQpZdWFuIFpIQU5H INXF1LAgDQoNCkNoaW5hIFRlbGVjb20gUmVzZWFyY2ggSW5zdGl0dXRlINbQufq159DF0dC+v9S6 DQpUZWw6ICs4Ni0xODkxODU4ODk5MA0KRW1haWw6IHpoYW5neTY2NkBjaGluYXRlbGVjb20uY24N Cg== ------=_001_NextPart544808438733_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable =0A
Dear all, 

<= div style=3D"text-align: justify;">
Regard= ing the two questions, the comments are as follows:

1. Is the p= roblem important for the NETCONF WG to solve?
I believe that it is important to retrieve diffe= rent KPI data from various different data source and correlate them togeth= er and provide comprehensive vi= ew of the network quality or network health from different angles. In addi= tion, it is important to eliminate noise data to be exported to the manage= ment plane. Telemetry data tagg= ing and classification is crucial to help capture characteristics data and= reduce amount of streamed data to the destination. And I also believe that the NETCONF WG is the appropr= iate WG for this work. draft-ietf-netconf-notification-capabilities separa= te notification capability model into system capability model and ietf-notification-capabilities model wh= ich serve as a good basis for telemetry data node capabilities definitions= .

2. Is the draft a suitable basis for the work= ?
I have been aware MDT Te= lemetry tagging Hackathon project in IETF 106 which was demonstrated in bo= th IETF 106 Hakcathon meeting and Hackdemo Happy Hour. I think this draft is mature enough and provide a = solid basis for starting point. If this work gets adopted, I will be glad to review any update of this dr= aft and contribute to relate discussion.

I believe it should move forward.

Best regards,
<= hr style=3D"width: 210px; height: 1px;" color=3D"#b5c4df" size=3D"1" align= =3D"left">=0A
Yuan ZHANG <= span style=3D"font-family: =CE=A2=C8=ED=D1=C5=BA=DA; font-size: 10.5pt; li= ne-height: 1.5; background-color: transparent;">=D5=C5=D4=B0 

China= Telecom Research Institute =D6=D0=B9=FA=B5=E7=D0=C5=D1=D0=BE=BF=D4=BA
=
Tel: +8= 6-18918588990
Email: zhangy66= 6@chinatelecom.cn
=0A ------=_001_NextPart544808438733_=------ From nobody Tue Aug 18 09:24:40 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54E83A0EB2 for ; Tue, 18 Aug 2020 09:24:38 -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 kWHjy3HQSYgD for ; Tue, 18 Aug 2020 09:24:37 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.228]) by ietfa.amsl.com (Postfix) with ESMTP id 08E9C3A0EA3 for ; Tue, 18 Aug 2020 09:24:37 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.48:13525.680091297 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-116.232.12.105?logid-acc97f38e48e41008db4a963eeb296c3 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id CC1972800EC; Wed, 19 Aug 2020 00:24:21 +0800 (CST) X-189-SAVE-TO-SEND: 31100443@chinatelecom.cn Received: from ([172.18.0.48]) by App0024 with ESMTP id acc97f38e48e41008db4a963eeb296c3 for netconf@ietf.org; Wed Aug 19 00:24:23 2020 X-Transaction-ID: acc97f38e48e41008db4a963eeb296c3 X-filter-score: filter<0> X-Real-From: zhangy666@chinatelecom.cn X-Receive-IP: 172.18.0.48 X-MEDUSA-Status: 0 Sender: zhangy666@chinatelecom.cn Date: Wed, 19 Aug 2020 00:24:22 +0800 From: "zhangy666@chinatelecom.cn" To: "netconf@ietf.org" References: , X-Priority: 3 X-GUID: 004E92F6-E4C0-44A7-AEA2-108AA06FB2B8 X-Has-Attach: no X-Mailer: Foxmail 7.2.16.188[cn] Mime-Version: 1.0 Message-ID: <20200819002422499442109@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart082256352567_=----" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-wang-netconf-bulk-subscribed-notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 16:24:39 -0000 This is a multi-part message in MIME format. ------=_001_NextPart082256352567_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNClJlZ2FyZGluZyB0aGUgdHdvIHF1ZXN0aW9ucywgdGhlIGNvbW1lbnRzIGFy ZSBhcyBmb2xsb3dzOg0KDQoxLiBJcyB0aGUgcHJvYmxlbSBpbXBvcnRhbnQgZm9yIHRoZSBORVRD T05GIFdHIHRvIHNvbHZlPw0KSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8gZGVmaW5lIGNyaXRl cmlhIHRvIGNsYXNzaWZ5IHN1YnNjcmlwdGlvbiBhbmQgaW5kaWNhdGUgdG8gdGhlIHNlcnZlciB3 aGljaCBzcGVjaWZpYyBzdWJzY3JpcHRpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSBub3RpZmljYXRp b24gc2hvdWxkIGJlIGJ1bmRsZWQgdG9nZXRoZXIgYmVmb3JlIGJ1bmRsaW5nIG11bHRpcGxlIG5v dGlmaWNhdGlvbiBpbiBhIHNpbmdsZSB0cmFuc3BvcnQgbWVzc2FnZS4gQW5kIEkgYmVsaWV2ZSB0 aGF0IHRoZSBORVRDT05GIFdHIGlzIHRoZSBhcHByb3ByaWF0ZSBXRyBmb3IgdGhpcyB3b3JrLiBS RkM4NjM5IGFuZCBSRkM4NjQwIHByb3ZpZGUgYSBnb29kIGJhc2lzIGZvciB0aGlzIHdvcmsuDQoN CjIuIElzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJhc2lzIGZvciB0aGUgd29yaz8NCkkgdGhpbmsg dGhpcyBkcmFmdCBpcyBtYXR1cmUgZW5vdWdoIGFuZCBwcm92aWRlIGEgc29saWQgYmFzaXMgZm9y IHN0YXJ0aW5nIHBvaW50Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCg0KWXVhbiBaSEFORyDlvKDlm60g DQoNCkNoaW5hIFRlbGVjb20gUmVzZWFyY2ggSW5zdGl0dXRlIOS4reWbveeUteS/oeeglOeptumZ og0KVGVsOiArODYtMTg5MTg1ODg5OTANCkVtYWlsOiB6aGFuZ3k2NjZAY2hpbmF0ZWxlY29tLmNu DQo= ------=_001_NextPart082256352567_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
=

Dear all,


Regarding the t= wo questions, the comments are as follows:

1. Is the problem important for the NETCON= F WG to solve?
I think it = is important to define criteria to classify subscription and indicate to t= he server which specific subscription associated with the notification sho= uld be bundled together before = bundling multiple notification in a single transport message. = And I believe that the NETCONF WG is the ap= propriate WG for this work. RFC8639 and RFC8640 provide a good basis for t= his work.

2. Is the draft a suitable basis for = the work?
I think this draft is mature= enough and provide a solid basis for starting point.
=0A
Best regards,
=0A
<= div style=3D"font-size: 13.3333px;">Yuan ZHANG =E5=BC=A0=E5=9B=AD 

China Telecom Research Institute =E4=B8=AD=E5=9B=BD=E7=94=B5=E4=BF=A1=E7=A0=94= =E7=A9=B6=E9=99=A2
<= span style=3D"text-align: justify;">Tel: +86-18918588990
Email: zhangy666@chinatelecom.cn
=0A
=0A<= /div>=0A
=0A
=0A
=0A
=0A ------=_001_NextPart082256352567_=------ From nobody Tue Aug 18 09:24:44 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4303A0EB2 for ; Tue, 18 Aug 2020 09:24:41 -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 FTcrlF9z9mUp for ; Tue, 18 Aug 2020 09:24:40 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id D60DF3A0EB6 for ; Tue, 18 Aug 2020 09:24:39 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.218:40187.889211252 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-116.232.12.105?logid-78b5adeb570848ceb8b8e2cdb5615ed5 (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id A71D62800A7; Wed, 19 Aug 2020 00:24:37 +0800 (CST) X-189-SAVE-TO-SEND: 31100443@chinatelecom.cn Received: from ([172.18.0.218]) by App0025 with ESMTP id 78b5adeb570848ceb8b8e2cdb5615ed5 for netconf@ietf.org; Wed Aug 19 00:24:38 2020 X-Transaction-ID: 78b5adeb570848ceb8b8e2cdb5615ed5 X-filter-score: filter<0> X-Real-From: zhangy666@chinatelecom.cn X-Receive-IP: 172.18.0.218 X-MEDUSA-Status: 0 Sender: zhangy666@chinatelecom.cn Date: Wed, 19 Aug 2020 00:24:39 +0800 From: "zhangy666@chinatelecom.cn" To: "netconf@ietf.org" X-Priority: 3 X-GUID: 8025BB06-B675-4C20-982B-3148AD9EDA68 X-Has-Attach: no X-Mailer: Foxmail 7.2.16.188[cn] Mime-Version: 1.0 Message-ID: <20200819002438832957110@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart458214662827_=----" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-wang-netconf-adaptive-subscription X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 16:24:44 -0000 This is a multi-part message in MIME format. ------=_001_NextPart458214662827_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgcmVhZCB0aGUgZHJhZnQsIHJlZ2FyZGluZyB0aGUgdHdvIHF1ZXN0aW9u cywgdGhlIGNvbW1lbnRzIGFyZSBhcyBmb2xsb3dzOg0KDQoxLiBJcyB0aGUgcHJvYmxlbSBpbXBv cnRhbnQgZm9yIHRoZSBORVRDT05GIFdHIHRvIHNvbHZlPw0KSSBiZWxpZXZlIHRoYXQgaXQgaXMg aW1wb3J0YW50IHRvIGFsbG93cyB0aGUgcHVibGlzaGVyIHRvIGFkanVzdCB0aGUgdm9sdW1lIG9m IHRlbGVtZXRyeSBkYXRhIHNlbnQgdG8gdGhlIHN1YnNjcmliZXJzIGJ5IGNoYW5naW5nIGRhdGEg Y29sbGVjdGlvbiByYXRlIHdoZW4gYm90aCBwdWJsaXNoZXJzIGFuZCBzdWJzY3JpYmVycyBzdXBw b3J0IG11bHRpcGxlIHVwZGF0ZSBpbnRlcnZhbHMgb3IgZGF0YSBjb2xsZWN0aW9uIHJhdGVzLiBU aGlzIHdpbGwgcmVkdWNlIG92ZXJsb2FkIG9uIHRoZSByZWNlaXZlcnMgb24gb25lIGhhbmQsIGdl dHRpbmcgbW9yZSB0ZWxlbWV0cnkgZGF0YSBmb3IgbmV0d29yayBmYWlsdXJlIGRpYWdub3NpcyBv biB0aGUgb3RoZXIgaGFuZC4gQW5kIEkgYmVsaWV2ZSB0aGF0IHRoZSBORVRDT05GIFdHIGlzIHRo ZSBhcHByb3ByaWF0ZSBXRyBmb3IgdGhpcyB3b3JrLiBSRkM4NjM5IGFuZCBSRkM4NjQwIHByb3Zp ZGUgYSBnb29kIGJhc2lzIGZvciB0aGlzIHdvcmsuDQoNCjIuIElzIHRoZSBkcmFmdCBhIHN1aXRh YmxlIGJhc2lzIGZvciB0aGUgd29yaz8NCkkgdGhpbmsgdGhpcyBkcmFmdCBpcyBtYXR1cmUgZW5v dWdoIGFuZCBwcm92aWRlIGEgc29saWQgYmFzaXMgZm9yIHN0YXJ0aW5nIHBvaW50Lg0KDQpCZXN0 IHJlZ2FyZHMsDQoNCg0KWXVhbiBaSEFORyDVxdSwIA0KDQpDaGluYSBUZWxlY29tIFJlc2VhcmNo IEluc3RpdHV0ZSDW0Ln6tefQxdHQvr/Uug0KVGVsOiArODYtMTg5MTg1ODg5OTANCkVtYWlsOiB6 aGFuZ3k2NjZAY2hpbmF0ZWxlY29tLmNuDQo= ------=_001_NextPart458214662827_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable =0A
Dear all,

I read the draft, regarding the two questions, the comments are as follows:

1. Is the problem important for the NETCONF WG= to solve?
I believe that = it is important to allows the publisher to adjust the volume of telemetry = data sent to the subscribers by changing data collection rate when both&nb= sp;publishers and subscribers suppor= t multiple update intervals or data collection rates. This will reduce ove= rload on the receivers on one hand, getting more telemetry data for <= /span>network failure diagnosis on the othe= r hand. And I believe that the = NETCONF WG is the appropriate WG for this work. RFC8639 and RFC8640 provid= e a good basis for this work.

2. Is the draft a= suitable basis for the work?
I think this draft is mature enough and provide a solid basis for star= ting point.

=0A
Best regards,
=0A
Yuan ZHANG =D5=C5=D4=B0 
<= font color=3D"#000080" style=3D"font-size: 13px;">

China Telecom = Research Institute =D6=D0=B9=FA=B5=E7=D0=C5=D1=D0=BE=BF=D4=BA
Tel: +86-189185= 88990
Email: zhangy666@chinate= lecom.cn
=0A ------=_001_NextPart458214662827_=------ From nobody Tue Aug 18 15:18:46 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8BC3A0EDF for ; Tue, 18 Aug 2020 15:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcg3fThH1b40 for ; Tue, 18 Aug 2020 15:18:37 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5E63A0AE5 for ; Tue, 18 Aug 2020 15:18:36 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id 140so11034638lfi.5 for ; Tue, 18 Aug 2020 15:18:36 -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=QatkvoCo0XQfmsI6gg2+WB79+YrszD8axVsPZkl6eW4=; b=WvWgQ2h1eqwwfSErbjLtQ+91rLA8Q4n1wyUImzQE2X508gLDpqF91fKjoyX7poSLMO Dgp6945dkxS1CPd/D6CVDi9x2b+I4PfoZ7dL6XsfN+FlYOUvcbKWKymoVgewQ4mKcPkk wS+sVbHtYZsI/EI/OZdAMZbdz28oRjiIVJYkfrsfqehuOAWQdC4PitBqPGs9a5E9irEk Q8n7lQ431mTbEmtLVExLxCorCRXVfFGG9nr6bhg2GR3brCrSNstdKjPzNXbPMNY9SMBo QXTVX7da+UUwNp8xqQ79u0W71d0muIgxFJEqRdcuUwFBiVcxtPhUoZMmB//LezYdFeLP wIqg== 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=QatkvoCo0XQfmsI6gg2+WB79+YrszD8axVsPZkl6eW4=; b=EAE29nk7fxGBx54qC7L3g0DO6DRxWq/QjM+ys8xKfq8i2f+OHnCFv7xkXRtr0fBNP5 nnZfOgIm3sTEiBg+GIZWUApyGy7+/9Vc2m+sau6wVV8LfA/CyQOfQdBNlOelBeuluzp8 ThEF69Py0ZvkfKoNiXXUbZ3EwL7tuJqeafAVonLzDXec3wDLnEkGgnWbXN+eRTQselel DZS83RKQ6Q8CGFDikW0h08GtVEo3qfGOuB34ZoWgCy8K9CDkvycmgD9/A4rZDUzw6hAg 8DwmQsBXHYHLpz9mMkXWtE4vSPMgpMUu3VY/YMxgIY3eQg0YrEicQ5qJtCamJPHmcCUQ oobg== X-Gm-Message-State: AOAM531lMorgEAjmbp6zPNYHBGQCQSY2CO/99mJK/4TrEmi0dmNn2qv4 OtJ7Cuyf/p91jKeZXtT1xAHwmhPapuAooc7oqzcoQQ== X-Google-Smtp-Source: ABdhPJxTTCh028WpBGYXbRrPgc3qrRcS93Jo/j/8f1xyse+9RUOMxU2RdLFbo10S4BQxIeK/G7Bj1jExGpEwqWKOBlU= X-Received: by 2002:ac2:5338:: with SMTP id f24mr10683820lfh.5.1597789114559; Tue, 18 Aug 2020 15:18:34 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.com> In-Reply-To: From: Andy Bierman Date: Tue, 18 Aug 2020 15:18:22 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: Kent Watsen , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000998bc505ad2e444e" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 22:18:45 -0000 --000000000000998bc505ad2e444e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton) wrote: > Hi, > > > > [Also as a contributor] > > > > My comments are broadly similar to Kent=E2=80=99s. > > > > I believe that a UDP transport for dataplane telemetry where getting > accurate fresh data quickly is more important than getting every update. > This is particularly true if a subsequent notification will cover any los= t > values anyway (e.g. periodic statistics). > > > agreed. There is also the resync-subscription mechanism to help recover from missing data. I suspect that having a mechanism to allow for the telemetry data being > encrypted is probably also important. If the WG were to adopt a draft > without this, then as Benoit mentioned, I would have to test the water wi= th > the IESG to determine whether that would be acceptable. > > I suspect the lack of congestion control might get their attention as well. > > > I also note that the draft allows for a GPB encoding of the telemetry > data, but I=E2=80=99m not aware of any formal standard encoding of YANG d= ata in > GPB, and there is a choice between whether the GPB encoding is generic fo= r > all YANG data, or specific GPB encodings are useful for the specific data > that is being encoded. > > > I was confused by the same thing. Is there a YANG schema for a notification element that is used? Which means the .proto file is hardwired? If not then how does the receiver know what is sent? There are some technical issues that can be addressed if the draft is adopted. > Regards, > Rob > > > Andy > > > *From:* netconf *On Behalf Of *Kent Watsen > *Sent:* 07 August 2020 21:16 > *To:* netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > [as a contributor] > > > > > > 1) is the problem important for the NETCONF WG to solve? > > > > I believe that it is important to enable publishers to send notifications > using a UDP-based transport. This belief is based on my experience from > when at Juniper dealing with very high-end firewalls with enormous log > output. > > > > I believe that the NETCONF WG is the appropriate WG for this work, having > defined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN). > > > > > > 2) is the draft a suitable basis for the work? > > > > I have read the current version of the draft and find it to be a > reasonable start. > > > > Presuming the =E2=80=9Creceiver-instances=E2=80=9D augmentation defined i= n > https://tools.ietf.org/html/draft-ietf-netconf-https-notif-04#section-3 t= akes > off, the module defined in this draft should be updated to augment into i= t > instead. > > > > I appreciate Section 5 (Applicability) noting that the UDP-transport is > primarily for the data plane (not the control plane), as it doesn=E2=80= =99t matter > so much if data plane notifications are lost. This addresses (I think) t= he > issue that Rob Shakir raised before: > https://datatracker.ietf.org/doc/minutes-103-netconf (search for =E2=80= =9CRob > S=E2=80=9D). That said, it is unclear to me how a receiver could configu= re this > while, e.g., configuring control plane notifications to be sent via a > TCP-based transport such as =E2=80=9Chttps-notif=E2=80=9D. > > > > > > 3) regarding Juergen=E2=80=99s questions: > > > > a) I am willing to substantially review the drafts. > > b) I am willing to contribute to the discussion of any issue. > > c) I do NOT plan to implement the technology defined. > > > > > > > > Kent > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000998bc505ad2e444e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 18, 2020 at 6:42 AM Rob W= ilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> wrote:

Hi,

=C2=A0

[Also as a contributor]

=C2=A0

My comments are broadly similar to Kent=E2=80= =99s.

=C2=A0

I believe that a UDP transport for dataplane t= elemetry where getting accurate fresh data quickly is more important than g= etting every update.=C2=A0 This is particularly true if a subsequent notifi= cation will cover any lost values anyway (e.g. periodic statistics).

=C2=A0


agreed.
There is also the resync-subscript= ion mechanism to help recover from missing data.

=

I suspect that having a mechanism to allow for= the telemetry data being encrypted is probably also important.=C2=A0 If th= e WG were to adopt a draft without this, then as Benoit mentioned, I would = have to test the water with the IESG to determine whether that would be accepta= ble.


I suspect the lack of congestion control might get their a= ttention as well.
=C2=A0

=C2=A0

I also note that the draft allows for a GPB en= coding of the telemetry data, but I=E2=80=99m not aware of any formal stand= ard encoding of YANG data in GPB, and there is a choice between whether the= GPB encoding is generic for all YANG data, or specific GPB encodings are useful for the= specific data that is being encoded.

=C2=A0



I was confused by the same thing.
Is there a YANG schema for a notification element that is used?
Which means the .proto file is hardwired?
If not then how d= oes the receiver know what is sent?
There are some technical issu= es that can be addressed if the draft is adopted.

= =C2=A0

Regards,
Rob

=C2=A0


Andy
=C2=A0

=C2=A0

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 07 August 2020 21:16
To: netconf@ie= tf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

[as a contributor]

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A01) is the problem important for th= e NETCONF WG to solve?

=C2=A0

I believe that it is important to enable publishers = to send notifications using a UDP-based transport. =C2=A0 This belief is ba= sed on my experience from when at Juniper dealing with very high-end firewa= lls with enormous log output.

=C2=A0

I believe that the=C2=A0= NETCONF WG is the appropriate WG for this work, having defined RFC 8= 639 (SN),=C2=A0RFC 8640 (NN), and=C2=A0R= FC 8650 (RN).

=C2=A0



=C2=A0=C2=A0=C2=A02) is the draft a suitable basis f= or the work?

=C2=A0

I have read the current version of the draft and fin= d it to be a reasonable start.

=C2=A0

Presuming the =E2=80=9Creceiver-instances=E2=80=9D a= ugmentation defined in=C2=A0https://tools.ietf.o= rg/html/draft-ietf-netconf-https-notif-04#section-3=C2=A0takes off, the= module defined in this draft should be updated to augment into it instead.=

=C2=A0

I appreciate Section 5 (= Applicability) noting that the UDP-transport is primarily for the data plan= e (not the control plane), as it doesn=E2=80=99t matter so much if data pla= ne notifications are lost.=C2=A0 This addresses (I think) the issue that Rob Shakir raised before: https://datatracker.ietf.org/doc/minutes-103-netconf=C2=A0(search for = =E2=80=9CRob S=E2=80=9D).=C2=A0 That said, it is unclear to me how a receiv= er could configure this while, e.g., configuring control plane notification= s to be sent via a TCP-based transport such as =E2=80=9Chttps-notif=E2=80= =9D.

=C2=A0

=C2=A0

3) regarding Juergen=E2= =80=99s questions:

=C2=A0

=C2=A0 a) I am willing t= o substantially review the drafts.

=C2=A0 b) I am=C2=A0will= ing to contribute to the discussion of any issue.

=C2=A0 c) I do NOT=C2=A0= plan to implement the technology defined.

=C2=A0

=C2=A0

=C2=A0

Kent

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000998bc505ad2e444e-- From nobody Wed Aug 19 14:05:50 2020 Return-Path: <01000174088a8930-1f65ed85-fe21-4023-b0c8-314798dd8cba-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC7E3A0E37 for ; Wed, 19 Aug 2020 14:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SunyIUkZq6Lk for ; Wed, 19 Aug 2020 14:05:44 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C123A0E46 for ; Wed, 19 Aug 2020 14:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1597871131; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=eLpHOnrImrIHSzZeEln6irhbb+W6/5vwG4eZ9k9rkSQ=; b=jkwpx5qa3KFLhdsX0OkWtjKeh2NzM96o4jGsKjSA0pVL6jO36dbp5RhpRgQpjCfX nuTBo09ElGL6TYO8bBBNesWmedMtv+UY+3nn52/BudsdlV9iH12N/p2cVcMT1tstJbX hjSXomHCsDfT28Yw+/Sy4hophlp4TdGW03J7lG1M= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_BEB98005-5DCB-4438-9DAB-BABC79CDD1C2" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000174088a8930-1f65ed85-fe21-4023-b0c8-314798dd8cba-000000@email.amazonses.com> Date: Wed, 19 Aug 2020 21:05:31 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.19-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Draft minutes uploaded X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 21:05:46 -0000 --Apple-Mail=_BEB98005-5DCB-4438-9DAB-BABC79CDD1C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Draft minutes from the 108 NETCONF session have been uploaded here: = https://www.ietf.org/proceedings/108/minutes/minutes-108-netconf-02.html = = NETCONF Chairs --Apple-Mail=_BEB98005-5DCB-4438-9DAB-BABC79CDD1C2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Draft minutes from the 108 NETCONF session have been uploaded here:

   https://www.ietf.org/proceedings/108/minutes/minutes-108-netconf-02.html

NETCONF Chairs




--Apple-Mail=_BEB98005-5DCB-4438-9DAB-BABC79CDD1C2-- From nobody Thu Aug 20 07:03:40 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1332A3A0E10; Thu, 20 Aug 2020 07:03:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159793220796.3011.11810586240018882853@ietfa.amsl.com> Date: Thu, 20 Aug 2020 07:03:28 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-crypto-types-18.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 14:03:33 -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 Types and Groupings for Cryptography Author : Kent Watsen Filename : draft-ietf-netconf-crypto-types-18.txt Pages : 56 Date : 2020-08-20 Abstract: This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to 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-18 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 20 14:44:57 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D13803A1439; Thu, 20 Aug 2020 14:44:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159795988878.24401.10732570303667331167@ietfa.amsl.com> Date: Thu, 20 Aug 2020 14:44:48 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-13.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 21:44:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : A YANG Data Model for a Truststore Author : Kent Watsen Filename : draft-ietf-netconf-trust-anchors-13.txt Pages : 39 Date : 2020-08-20 Abstract: This document defines a YANG 1.1 data model for configuring globally- accessible bags of certificates and public keys that can be referenced by other data models for trust. Editorial Note (To be removed by RFC Editor) This draft contains 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: * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "BBBB" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * "2020-08-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * 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-13 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-trust-anchors-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 20 14:45:51 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8B93A1468; Thu, 20 Aug 2020 14:45:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159795994609.28324.3913096612271109764@ietfa.amsl.com> Date: Thu, 20 Aug 2020 14:45:46 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-keystore-20.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 21:45:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : A YANG Data Model for a Keystore Author : Kent Watsen Filename : draft-ietf-netconf-keystore-20.txt Pages : 52 Date : 2020-08-20 Abstract: This document defines a YANG 1.1 module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted or hidden. Asymmetric keys may be associated with certificates. Notifications are sent when certificates are about to expire. Editorial Note (To be removed by RFC Editor) This draft contains 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: * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "CCCC" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * "2020-08-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log 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-20 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 20 14:51:15 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B363A143D; Thu, 20 Aug 2020 14:51: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: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159796027404.25743.6311937912637305708@ietfa.amsl.com> Date: Thu, 20 Aug 2020 14:51:14 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 21:51:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for TCP Clients and TCP Servers Authors : Kent Watsen Michael Scharf Filename : draft-ietf-netconf-tcp-client-server-08.txt Pages : 32 Date : 2020-08-20 Abstract: This document defines three YANG 1.1 [RFC7950] modules to support the configuration of TCP clients and TCP servers, either as standalone or in conjunction with a stack protocol layer specific configurations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-08 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tcp-client-server-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 20 14:59:48 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD17A3A1443; Thu, 20 Aug 2020 14:59:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159796078585.19131.6122196426370132658@ietfa.amsl.com> Date: Thu, 20 Aug 2020 14:59:45 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-ssh-client-server-22.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 21:59:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for SSH Clients and SSH Servers Author : Kent Watsen Filename : draft-ietf-netconf-ssh-client-server-22.txt Pages : 62 Date : 2020-08-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. Editorial Note (To be removed by RFC Editor) This draft contains 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: * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors * "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore * "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server * "EEEE" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * "2020-08-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log 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-22 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-22 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 Aug 20 15:01:00 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F253A1442; Thu, 20 Aug 2020 15:00:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159796085531.27414.6996139477697186996@ietfa.amsl.com> Date: Thu, 20 Aug 2020 15:00:55 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-22.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 22:00:55 -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 Author : Kent Watsen Filename : draft-ietf-netconf-tls-client-server-22.txt Pages : 59 Date : 2020-08-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. Editorial Note (To be removed by RFC Editor) This draft contains 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: * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors * "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore * "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server * "FFFF" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * "2020-08-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log 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-22 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tls-client-server-22 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 Aug 20 15:02:16 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1133A1486; Thu, 20 Aug 2020 15:02: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: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159796092847.27094.1622148965395490763@ietfa.amsl.com> Date: Thu, 20 Aug 2020 15:02:08 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-http-client-server-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 22:02: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 HTTP Clients and HTTP Servers Author : Kent Watsen Filename : draft-ietf-netconf-http-client-server-05.txt Pages : 31 Date : 2020-08-20 Abstract: This document defines two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). Editorial Note (To be removed by RFC Editor) This draft contains 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 (note: not all may be present): * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors * "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore * "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server * "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- client-server * "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- client-server * "GGGG" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * "2020-08-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-http-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-05 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-http-client-server-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 20 15:05:56 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C643A1429; Thu, 20 Aug 2020 15:05:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159796114942.26528.3774302552603082483@ietfa.amsl.com> Date: Thu, 20 Aug 2020 15:05:49 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-client-server-21.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 22:05:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : NETCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-netconf-client-server-21.txt Pages : 58 Date : 2020-08-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 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 (note: not all may be present): * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors * "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore * "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server * "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- client-server * "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- client-server * "GGGG" --> the assigned RFC value for draft-ietf-netconf-http- client-server * "HHHH" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * "2020-08-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * 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-21 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-client-server-21 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 Aug 20 15:07:00 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB5F3A152D; Thu, 20 Aug 2020 15:06:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159796121078.17006.7058371475465714692@ietfa.amsl.com> Date: Thu, 20 Aug 2020 15:06:50 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-restconf-client-server-21.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 22:06:55 -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-21.txt Pages : 55 Date : 2020-08-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. Editorial Note (To be removed by RFC Editor) This draft contains 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 (note: not all may be present): * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors * "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore * "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server * "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- client-server * "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- client-server * "GGGG" --> the assigned RFC value for draft-ietf-netconf-http- client-server * "HHHH" --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * "IIII" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * "2020-08-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix B. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-21 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-client-server-21 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 Aug 20 16:40:52 2020 Return-Path: <010001740e3edf92-8e27bff1-5848-4f88-a836-e71e151f6fc7-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C512C3A14A3 for ; Thu, 20 Aug 2020 16:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHWp9bjdOxFV for ; Thu, 20 Aug 2020 16:40:45 -0700 (PDT) Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6AC3A149F for ; Thu, 20 Aug 2020 16:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1597966835; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=4Zp5F34jqZZsmIWcpJGV3h9q1IOenjOjo58uJCmlWnY=; b=DUe+ShEl9daDmf/8juLWaSOJ6mx5bn5oTdnGL9D3XgmT5VixKkfqA+KaJWdivnle 9NT0Vo+7hunGGdF6uJWD1KY6oUx3DfICXrxGei+I8XnbniGvgS37q/UyRf9BYV5nANm xLxAfYWiNw0bZh8r7ICFw8qepknM4XfZH0dRPZdw= From: Kent Watsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <010001740e3edf92-8e27bff1-5848-4f88-a836-e71e151f6fc7-000000@email.amazonses.com> Date: Thu, 20 Aug 2020 23:40:35 +0000 Cc: Sandra Murphy , =?utf-8?Q?Magnus_Nystr=C3=B6m?= To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.20-54.240.48.95 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Update to collection of drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 23:40:48 -0000 NETCONF + SecDIr, I just updated the collection of drafts to: - address WGLC comments...in the first three drafts. - address issues raised during the 108 session. - address issues raised by SecDIr on the =E2=80=9Ckeystore=E2=80=9D = draft. HIGHLIGHTS: No more FIXMEs! LOWLIGHTS: despite working with the tools team to insure this doesn=E2=80=99= t happen, it is still the case that the references (hyperlinks) are = pointing to the *pervious* version of the referenced document. Please = be sure to always increment the revision number when chasing leads.=20 Details: For crypto-types: * Fixed issues found by the SecDir review of the "keystore" draft. * Added "password-grouping", discussed during the IETF 108 session. For trust-anchors: * Fixed issues found by the SecDir review of the "keystore" draft. For keystore: * Addressed SecDir comments from Magnus Nystroem and Sandra Murphy. For tcp-client-server: * Added missing IANA registration for "ietf-tcp-common=E2=80=9D. * Added "mandatory true" for the "username" and "password=E2=80=9D = leafs. * Added an example of a TCP-client configured to connect via a = proxy. * Fixed issues found by the SecDir review of the "keystore" draft. * Updated the "ietf-tcp-client" module to use the new "password- grouping" grouping from the "crypto-types" module. For ssh-client-server: * Cleaned up the SSH-client examples (i.e., removing FIXMEs) * Fixed issues found by the SecDir review of the "keystore" draft. * Updated the "ietf-ssh-client" module to use the new "password- grouping" grouping from the "crypto-types" module. For tls-client-server: * In both the "client-authentication" and "server-authentication" subtrees, replaced the "psks" node from being a P-container to a leaf of type "empty". * Cleaned up examples (e.g., removed FIXMEs) * Fixed issues found by the SecDir review of the "keystore" draft. * Updated the "psk" sections in the "ietf-tls-client" and "ietf-tls- server" modules to more correctly reflect RFC 4279. For http-client-server: * Fixed titles and a ref in the IANA Considerations section. * Cleaned up examples (e.g., removed FIXMEs). * Fixed issues found by the SecDir review of the "keystore" draft. * Updated the "ietf-http-client" module to use the new "password- grouping" grouping from the "crypto-types" module. For netconf-client-server: * Cleaned up titles in the IANA Considerations section. * Fixed issues found by the SecDir review of the "keystore" draft. For restconf-client-server: * Cleaned up titles in the IANA Considerations section. * Fixed issues found by the SecDir review of the "keystore" draft. K. From nobody Thu Aug 20 17:09:13 2020 Return-Path: <010001740e58ed69-9189c088-85d3-4198-a533-37474ad88521-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A5D3A0F62; Thu, 20 Aug 2020 17:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fz81PllUhIgh; Thu, 20 Aug 2020 17:09:04 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D70D3A081F; Thu, 20 Aug 2020 17:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1597968543; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=vE0wq4x88BgA94VMrRzWX7VH4eX8cz84PSEp9YccyEo=; b=lAEQazD1t5wgIOnh3hERl73V0bWUNKG4ifAk/leG5//Z2qiYzXHZRJa3n/LrZVX9 jh0c31obblyMzkLLQcZRqzQVK/537gzuX4pqqsJ4/VhSAcn+X2KncKauUv7EBKhtpZy 4nsRXs2TyTl2CSnYBPfD/76HKgfGOtd6GITtRPwQ= From: Kent Watsen Message-ID: <010001740e58ed69-9189c088-85d3-4198-a533-37474ad88521-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0348A326-1A9C-4C92-A178-9883E263A74F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 21 Aug 2020 00:09:03 +0000 In-Reply-To: Cc: secdir@ietf.org, "netconf@ietf.org" To: Sandra Murphy References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.21-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] early secdir review of draft-ietf-netconf-keystore-19 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 00:09:11 -0000 --Apple-Mail=_0348A326-1A9C-4C92-A178-9883E263A74F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [+netconf (for visibility) and -keystore.authors (since its just me)] Hi Sandy, This is a massive review. Thank you for that, but it demands a massive = response=E2=80=A6I hope you=E2=80=99re ready for it ;) Before jumping in, I want to clarify something that I=E2=80=99ll also = make a point to add to the Introduction section, which is that the = ietf-keystore YANG module defines a configuration model supporting = existing practices; it does not intend to define new ways for doing = things. For instance, the sections regarding built-in keys, hidden = keys, key-encryption keys, and master keys all attempt to support = existing practices. The point being that, in thinking about what these = sections are saying, trust that this draft isn=E2=80=99t defining new = behavior, and folk's experience with systems is the best guide. Also, note that I did update Section 4 (Encrypting Keys in = Configuration) per Magnus=E2=80=99s review. That update was sent to the = SecDir list on the 10th (with GitHub commit here [1]). While the = section was effectively entirely rewritten, the update essentially = accomplishes just one thing, which is the swap a couple terms as = follows: r/root key/master key/ and r/shared root key/key encryption = key/. Your review precedes this update, but my responses below will, = when appropriate, reflect the current terms. [1] = https://github.com/netconf-wg/keystore/commit/5b3b9f3db0d6b7027ddf5f0e983a= b958e8802251 = PS: I just updated all the drafts with the updates from this email. The = bad news is that the Datatracker is still using the *previous* draft = version for hyperlinks, so be sure to manually increment whenever = opening a referenced document. Thanks, Kent > On Aug 12, 2020, at 9:10 AM, Sandra Murphy wrote: >=20 > This is a requested SECDIR early review of = draft-ietf-netconf-keystore-19, not an IETF Last Call review. >=20 > I have reviewed this document as an early review assigned by the = security directorate, as part of the directorate's ongoing effort to = review documents headed eventually to the IESG. Document editors and WG = chairs should treat these comments just like any other comments. >=20 > I am a neophyte at Yang so any comments I make here should be = understood with that in mind. (The recent mpls and netconf discussion = of the MPLS module reuse of an RPC and the difference between = "destination address" and "local label" have further impressed upon me = just how much I do not know about YANG.) >=20 > Outline of this review is: >=20 > News of draft status > Summary of the draft > General and issue comments > Page-by-page comments and nits >=20 >=20 > News of draft status: > --------------------- >=20 > This document was in WGLC when assigned and it appears that the WGLC = has not yet been decided. >=20 > In the netconf session at IETF108, the wg discussed the need for a raw = password feature, which might end up as a new grouping being added to = the draft-ietf-netconf-crypto-types and therefore might induce changes = to this draft as well. True, it was discussed @108, but that change in crypto-types will not = affect this draft (however, it will affect the tcp-client-server, = ssh-client-server, and http-client-server drafts) > Summary of the draft: > --------------------- >=20 > The draft abstract says: > This document defines a YANG 1.1 module called "ietf-keystore" that > enables centralized configuration of both symmetric and asymmetric > keys. >=20 > Keys may be symmetric or asymmetric, and maybe be of types = "cleartext", "hidden" (as in a TPM), or "encrypted". Keys can be = configured locally (which means within the data model) or as a reference = to a keystore item. One server might have multiple keystores in use at = any one time. >=20 > The document defines groupings that might prove useful for other YANG = modules that import this one. >=20 > The document describes the data model for the keystore and provides = many examples. The descriptions of the data model and examples are = presented in different modes as you read through the document, in tree = diagrams, XML, and text that (surely?) is YANG (I think). I believe the = YANG text is authoritative. True, the YANG module in Section 2.3 is the raison d=E2=80=99=C3=AAtre = for the draft. > For other readers, here's the sequence of description modes. >=20 > Section 2.1 Mostly tree diagram descriptions of the groupings defined = in this document. >=20 > Section 2.2.1-2.2.2 Examples (Keystore Instance and Cert Expiration) = given in XML. >=20 > Section 2.2.3 A module, containing those groupings of Section 2.1 = whose titles' prefixes are "local-or-keystore-", is described in what I = believe would be called YANG (p16-18) and then in a tree diagram = (p19-23). >=20 > Section 2.3 This section describes what I believe to be the normative = Yang module text. Yes, the YANG module in 2.3 is the normative module text for the draft. >=20 > General and issue comments: > --------------------------- >=20 > This document is very well written. The examples were very helpful, = particularly to this reader who was unfamiliar with Yang. I can't = imagine the patience and care it took to keep so many descriptions in = close alignment. My secret is: 1) maintain all YANG modules and examples a stand-alone files. 2) each time building the draft (`make clean; make`), dynamically: a) validate all YANG modules b) validate all examples against the YANG modules c) generate all tree diagrams d) stitch tree-diagrams, examples, and YANG modules into an uber = xml2rfc file This way, everything stays connected and up-to-date. I takes effort to = set up, but it pays for itself over time (not only for the author, but = also for WG participants who might otherwise discover anomalies that = could=E2=80=99ve been caught). > The document describes two new typedefs: asymmetric-key-ref and = symmetric-key-ref. Those typedefs are never further explained. I = believe (based only on the string "ref" in the name and usage as = "keystore-reference") that these are intended to be references to named = items in other parts of the keystore which themselves contain keys. = (Sheesh it takes a lot of words!) And I hope/believe that the = asymmetric-key-ref is to a structure that contains a key-pair. Yes, you got it.=20 FWIW, Section 2.1.2 (Typedefs) says: "The leafrefs refer to symmetric = and asymmetric keys in the keystore. These typedefs are provided = primarily as an aid to downstream modules that import the = "ietf-keystore" module.=E2=80=9D Not good enough? > The text typically says "asymmetric key" without distinguishing = whether it is talking about the public key, the private key, or a = key-pair. Presumably "asymmetric key" means a key-pair and the = implementations of operations know from context which key in the = key-pair is needed. Yes, that is what is intended. Is that nomenclature okay or should = =E2=80=9Ckey-pair=E2=80=9D be postpended throughout? In contrast, note that when referring to asymmetric key halfs, the text = attempts to always call that it out, e.g., =E2=80=9Cthe public half of = the asymmetric key=E2=80=9D. > I am not familiar with the Yang system, so I wonder if there is any = mechanism in Yang's use to check if the assumptions of the data model = are followed. (1) If an asymmetric key is configured with a public key = and a private key that are not a key-pair, where is that caught? (2) If = an asymmetric key and an associated cert are configured, but the public = key part of the structure is not the public key mentioned in the cert, = where is that caught? (3) If the data model says that a component is an = asymmetric-key-ref, but the de-ref'd value is not an asymmetric key (key = type?), where is that caught, like maybe when the value is stored in the = keystore? (Do the questions even make sense?) Yes, the questions (now numbered 1-3) make sense. For #1) I just updated the =E2=80=9Cdescription=E2=80=9D for the " = asymmetric-key-pair-grouping=E2=80=9D in the "ietf-crypto-types=E2=80=9D = module (in draft-ietf-netconf-crypto-types): OLD: "A private key and its associated public key."; NEW: "A private key and its associated public key. Implementations SHOULD ensure that the two keys are a matching pair.=E2=80=9D [Note: =E2=80=9CSHOULD=E2=80=9D is used instead of =E2=80=9CMUST=E2=80=9D = because the fallback is to simply *trust* that the clients never = configure mismatched values.] For #2) Already the description statements for various groupings in the = "ietf-crypto-types=E2=80=9D module have suitable statements: grouping end-entity-cert-grouping { description "An end entity certificate, and a notification for when it is about to (or already has) expire. Implementations SHOULD assert that, where used, the end entity certificate contains the expected public key.=E2=80=9D; } grouping asymmetric-key-pair-with-cert-grouping { description "A private/public key pair and an associated certificate. Implementations SHOULD assert that certificates contain the matching public key.=E2=80=9D; } grouping asymmetric-key-pair-with-certs-grouping { description "A private/public key pair and associated certificates. Implementations SHOULD assert that certificates contain the matching public key.=E2=80=9D; } For #3) There are three parts to this one. =20 3a) First, when configuring a key into the Keystore, I made the = following adjustments: For "symmetric-key-grouping=E2=80=9D: OLD: description "Identifies the symmetric key's format.=E2=80=9D; NEW: description "Identifies the symmetric key's format. Implementations SHOULD ensure that incoming symmetric key value is encoded in the specified format.=E2=80=9D; For "public-key-grouping=E2=80=9D: OLD: description "Identifies the public key's format."; } NEW: description "Identifies the public key's format. Implementations SHOULD ensure that incoming public key value is encoded in the specified format."; } For asymmetric-key-pair-grouping: OLD: description "Identifies the private key's format."; } NEW: description "Identifies the private key's format. Implementations SHOULD ensure that incoming private key value is encoded in the specified format."; } 3b) Second, regarding if a format mismatch can occur, this is not = possible as, e.g., the =E2=80=9Ckey-format=E2=80=9D for the = symmetric-key (see below) uses an =E2=80=9Cidentityref" that indicates = that set values must derive from the "symmetric-key-format=E2=80=9D = (i.e., NOT either the =E2=80=9Cpublic-key-format=E2=80=9D or = =E2=80=9Cprivate-key-format=E2=80=9D identities): leaf key-format { nacm:default-deny-write; type identityref { base symmetric-key-format; } 3c) Third, regarding if the thing referenced is what its supposed to be, = note in the YANG module has this definition: typedef asymmetric-key-ref { type leafref { path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" + "/ks:name"; } Thus, if a configuration points to =E2=80=9Cfoo=E2=80=9D, but no = asymmetric key called =E2=80=9Cfoo=E2=80=9D exists, then a YANG = validation would fail when the configuration is attempted to be set. QUESTION: should these implementation-notes be *moved* into Security = Considerations? One one hand, there=E2=80=99s is best IETF-form but, = on the other hand, there is best YANG-form. =46rom both PoVs, I think = a case can be made but, if no one cares, I=E2=80=99ll leave it be. > Section 3 says > Built-in "encrypted" keys MAY be copied > into other parts of the configuration so long as they maintain their > reference to the other built-in key that encrypted them. >=20 > I could see that built-in keys should be encrypted by other built-in = keys (I don't see what other keys are available at the building-in time = to encrypt them, but proof by "I don't see" is unconvincing). Is that = required? I don't think the data model represents built-in keys as a = distinct type, so I'm not sure the data model could represent the = built-in-ness requirement. Could it ever be that a built-in key could = be encrypted by a non-built-in key? I.e., does something prevent it. =46rom a terminology perspective, equate =E2=80=9Cbuilt-in=E2=80=9D with = =E2=80=9Cgenerated by the manufacturer and/or in the device=E2=80=99s = factory default configuration". To the last question, no, a built-in key cannot be encrypted by a = non-builtin key. That would be putting the cart in front of the horse, = so to speak. But, to the crux of your question, that sentence simply acknowledging = what=E2=80=99s possible. For instance, imagine a device ships with a = *hidden* built-in key called =E2=80=9Cfoo=E2=80=9D and an encrypted = built-in key called =E2=80=9Cbar=E2=80=9D, where bar is encrypted by = foo. Presumably both foo and bar would appear in the Keystore in = and, if a user wanted to use bar as a KEK, they would copy = it into the exact same spot in (i.e., in Keystore, using the = same name, e.g., =E2=80=9Cbar"). This sentence acknowledges that the = key might possibly be renamed =E2=80=9Cbaz=E2=80=9D or possibly be = copied into a =E2=80=9Clocal definition=E2=80=9D somewhere (i.e., not in = Keystore at all). In such cases, the configured-key is still valid so = long as the base64 and the leafref pointing to =E2=80=9Cfoo=E2=80=9D = remain. It=E2=80=99s a corner case that=E2=80=99s unlikely to trigger = in practice, because why would you, though theoretically possible = without a technical reason for a constraint. Makes sense? =20 > Section 4 p34 says "built-in keys MUST be hidden". That really should = be mentioned in Section 3. As mentioned in an email I wrote on Thu (Aug 13th), I don=E2=80=99t = think this MUST is enforceable and so am dialing it back something akin = to a SHOULD or RECOMMENDED via this text: A MEK is commonly a globally-unique built-in (see ) asymmetric key for which the private key, due to its long = lifetime, is hidden=20 () and the=20 public key is contained in an identity certificate (e.g., = IDevID). > Section 3 and 4 about built-in keys and root keys and hidden keys: >=20 > Section 4 p34 says >=20 > The root key SHOULD be a hidden key, i.e., one whose private data has > no presence in or >=20 > and > Given the long lifetime of built-in > keys (see Section 3), built-in keys MUST be hidden. But this last part is no longer a =E2=80=9CMUST=E2=80=9D (see above) > and Section 3 p32 says >=20 > The key characteristic of the built-in keys is that they are provided > by the system, as opposed to configuration. As such, they are > present in . >=20 > So built-in keys must be hidden, which means they are candidates to be = root keys, but they are "present in operational". By the first = sentence, their private data is not in , so the = configuration must use the hidden-private-key or hidden-key key-type for = the secret parts. Yes > By the requirement that built-in keys must be hidden, servers that do = not support hidden keys can not use built-in keys. Correct? Not anymore, since it can=E2=80=99t be enforced. The better statement = might be: "it is highly RECOMMENDED that builtin keys are [permanently] = hidden and, if this is not possible, highly restricted access mechanisms = are used to limit the built-in key's secret data to only highly = authorized clients (e.g., an organization=E2=80=99s crypto officer)." > A hidden root key MAY be either a symmetric key or an asymmetric key. True. Asymmetric is the common case but its possible that a MEK could = be a symmetric key, such that *only* a, e.g., TPM, is able to = encrypt/decrypt certain keys (e.g., KEKs) > Does the same apply to built-in keys? The examples in Section 3 are = all asymmetric keys. Yes (see example in previous response) > Is using a built-in key as a root key advisable in operational = situations? Absolutely. This is commonly done and (I think) recommended by TCG. > Presumably if a root key is not a built-in key and not a hidden key, = then its secret data must be of cleartext-key type. Encrypting the root = key is not possible, there is no other single key available (or it would = be the root key). Has any consideration been given to dual root keys? = I could see that that would be too complex to manage. Your presumptions are correct. There certainly could be more than one = MEK (root key). This model doesn=E2=80=99t constrain that possibility = from being exposed to users. > Section 4.1 p35 >=20 > The use of the root key mentions encrypting with an asymmetric key, = but not signing with an asymmetric key. Are signing and other crypto = services not a part of the netconf view? Signing is using something a device might do to prove to a remote peer = that it originated some data. In the context of the Keystore, it=E2=80=99= s clearly desirable to configure encrypted keys but not clear there is a = need to configure signed keys. At least, I=E2=80=99m unaware of the use = case. Certainly any asymmetric key could be used to sign data, but the = API (i.e., RPCs) enabling that are currently outside the scope of this = document. > Section 4.2 p35 >=20 > Each time a new key is to be configured, it SHOULD be encrypted by > the root key. >=20 > Would it be good to discuss how to configure a root key? If the root = key is not a built-in key and there is no support for a hidden key, then = a cleartext key would be required, correct? An encrypted key would not = be possible because it would require a second key that would have to be = available in the keystore - which means that would be the root key. I added: "How to configure a MEK during the manufacturing process is outside the scope of this document.=E2=80=9D And: "It is highly RECOMMENDED that MEKs are built-in and hidden but, if this is not possible, MEKs highly restricted access mechanisms = SHOULD=20 be used to limit access to the MEK's secret data to only highly=20 authorized clients (e.g., an organization=E2=80=99s crypto = officer). In this case, it is RECOMMENDED that the MEK is not built-in and hence is, effectively, just like a KEK.=E2=80=9D > Section 4.3 p35 Heads up: this is the section that was rewritten based on Magnus=E2=80=99s= review. The =E2=80=9Cshared root key=E2=80=9D is now called =E2=80=9Ckey= encryption key=E2=80=9D (KEK) and the =E2=80=9Croot key=E2=80=9D is now = =E2=80=9Cmaster encryption key=E2=80=9D (MEK) in the -20 version I = shared as an attachment last week. =20 PS: Magnus suggests renaming =E2=80=9CMaster Encryption Key=E2=80=9D to = =E2=80=9CMaster Key=E2=80=9D; I haven=E2=80=99t done this yet hence why = I=E2=80=99m still using the MEK term=E2=80=A6 > This process for migrating a configuration to a new server would also = work for replacing the root key on a server without requiring = re-encrypting all the keystore's encrypted keys. (Mind you, I don't = know how a non-builtin, non-hidden root key is configured from a cold = start.) Yes. > The text calls the key a "shared root key" - but the use in this = process of migrating a configuration does not require that the key be = shared other than between the "first" and "second" servers. I don't see = that there's any reason to share the "shared root key" more widely; each = migration between two servers could use a different "shared root key". Agreed. > "This shared root key would only need to be known to an organization's = crypto officer." -- until it is decrypted in a server for use in = encrypting and decrypting local keys, right? I don't know how YANG = implementations hold the root keys that are constantly in use but = hopefully access is carefully controlled. To your question, right, only the crypto officer and then later the = device itself should ever know the key. Regarding the second part of your comment, please note that the YANG = model isn=E2=80=99t forcing any behavior. =46rom my previous comments = above, I think you see that the draft =E2=80=9Crecommends=E2=80=9D = certain behaviors but, otherwise, enables implementations do present an = interface reflecting a device=E2=80=99s internal behavior. > A key common to all servers in an operational environment has been = found to be unwise because an exposure at one server has a global = impact. The text on p 36 says "The crypto officer can then safely = handoff the encrypted shared key to other administrators responsible for = server installations, including migrations." but that should be taken as = a handoff as necessary at each occasion, not taken as a handoff to all = other servers jointly, at the same time. Agreed. I think that it understood that the shared KEK would be = encrypted for the minimal subset of devices=E2=80=A6presumably just a = single failover device but, perhaps, a set of devices constituting a = cluster. > Section 5.2 p38 >=20 > This section points to the NETCONF protocol's support for mutual = authentication, but in this particular case, I believe that the = mandatory support for confidentiality is very important and should be = mentioned, in particular for the configuration of cleartext keys. Please be aware that this section is following (roughly) the template = defined here: https://tools.ietf.org/html/rfc8407.html#section-3.7.1 = . This template = ware reviewed by previous Security Area ADs . FWIW, the first paragraph says =E2=80=9C=E2=80=A6 Both of these = protocols have mandatory-to-implement secure transport layers (e.g., = SSH, TLS) with mutual authentication.=E2=80=9D, so =E2=80=9Cconfidentialit= y isn=E2=80=99t completely unstated=E2=80=A6. What text would you like to see added here? > I had one puzzle I could never figure out - why the keystore-reference = for the grouping local-or-keystore-asymmetric-key-with-certs-grouping = (Sect 2.1.3.5) is an asymmetric-key-ref type. Other uses of = asymmetric-key-ref are consistent with it being a reference to a key = only, but here I expected the reference would be to a structure that = contains the key and its associated certs. The descriptions in the Sect = 2.3 Yang Module p29 says the grouping contains the cert and its keys. Good catch. Yes, there is some wonkiness here. (Continued in next = comment) > Is the asymmetric-key-ref in some way useable as both a reference to = an asymmetric key and an asymmetric key and its associated certs? Indeed. The reality is that the Keystore only supports the notion of = keys that may have associated certificates. In all cases, the = =E2=80=9Clocal=E2=80=9D definition is as described, but sometimes the = =E2=80=9Ckeystore=E2=80=9D definition is a bit off. =20 The only perfect* mapping is the = =E2=80=9Clocal-or-keystore-asymmetric-key-with-certs-grouping=E2=80=9D = grouping, as that is exactly what the Keystore has in it. =20 The "local-or-keystore-end-entity-cert-with-key-grouping=E2=80=9D isn't = that bad either, as it points to specific cert, which is under a = key=E2=80=A6the only wonkiness is that the key may have other certs = under it too, but it isn=E2=80=99t a big deal. =20 The "local-or-keystore-asymmetric-key-grouping=E2=80=9D is the worst = mapping because, while it does point to a key, the key may have certs = under it. The expectation is that this won=E2=80=99t be a problem in = context because the code is, presumably, only interested in the key (not = the certs), as that is exactly all the code would get if the =E2=80=9Cloca= l=E2=80=9D definition is used. > At first I thought the "associated certs" in the groupings were the = certificate chain certs - the subject cert, the issuer cert, etc. I am = not sure they are - might they be many certificates for the same public = key, perhaps for different algorithms? I think that should be = explained. Each =E2=80=9Ccertificate=E2=80=9D is actually the "end-entity-cert-cms" = CMS structure defined in the =E2=80=9Ccrypto-types=E2=80=9D draft. Each = CMS MAY contain a chain of certs for that end-entity =E2=80=9Ccertificate=E2= =80=9D, in quotes because the =E2=80=9Ccertificate=E2=80=9D can also = include associated issuer certs, as needed for the context. Therefore, that a key may have a multiplicity of associated certs (i.e. = CMSs) is to support things such as: different algorithms, different = Subject/SAN, different Issuers, etc. Makes sense. Happy to make things more clear, can you propose the text you=E2=80=99d = like to see? > Page-by-page comments and nits: > ------------------------------- >=20 > Section 1 p 3 >=20 > there are groupings that defined enabling a key to be either >=20 > Did you mean the past tense here? Or did you mean "define"? Fixed =E2=80=94> "define". > Section 1.1 p 4 >=20 > In the diagram, what is the meaning of the lines - what relationshiop = do they represent - e.g., "refers to", "uses", "augments", something = else? "The relationship between=E2=80=9D =E2=80=94> "The normative dependency = relationship between" > It looks like netconf-client-server has no relationship (whatever = "relationship" is) to http-client-server, restconf-client-sever has no = relationship to ssh-client-server, and http-client-server has no = relationship to keystore or truststore. Is that all correct? Yes. NETCONF doesn=E2=80=99t have an HTTP-based transport. RESTCONF = doesn=E2=80=99t have an SSH-based transport. HTTP may be =E2=80=9Cmixed-i= n=E2=80=9D with TLS to created a protocol stack, but doesn=E2=80=99t = itself depend on TLS. > Section 1.3 p 5 >=20 > This document in compliant with Network Management Datastore > Architecture (NMDA) [RFC8342]. >=20 > RFC8342 is listed in the informative section - what does it mean to be = compliant with an informative reference? r/in compliant/is compliant/ This text is via https://tools.ietf.org/html/rfc8407#section-3.5. It = means that the data model has been developed assuming that there exists = dedicated datastore that contains the =E2=80=9Coperational=E2= =80=9D value for the system as a superset of configured nodes. =20 >=20 > [Std-802.1AR-2009] certificate) are expected to appear in > >=20 > I did not catch that the term was part of R%FC8342, and = went looking for a reference. I found it in many places, like RFC6241. = For those just that unobservant, could you put a citation here to = RFC8342, which I think is the proper reference for that term. Note: = appears later, and a citation to RFC8342 is probably proper = there as well. Yes, I know, probably about as necessary as a reference = to "packet", but it would have spared me, maybe other non-Yang clueful = folk will be reading this also. Quite right - I added a =E2=80=9CTerminology=E2=80=9D section with = references for "=E2=80=9D and =E2=80=9C=E2=80=9D = (RFC 8342), as well as =E2=80=9Cclient" and =E2=80=9Cserver=E2=80=9D = (RFC 6241). > Section 2 p 5 >=20 > This section defines a YANG 1.1 [RFC7950] module that defines a > "keystore" >=20 > Should that be "ietf-keystore"? Or do you mean keystore in a general = sense, in which case I think the quote marks make it look like a name, = not a general sense. (I went looking for a definition of a "keystore", = but that could just be me.) Part of the issue is that the term =E2=80=9Ckeystore" isn=E2=80=99t = defined anywhere. I just added the following in the new = =E2=80=9CTerminology=E2=80=9D section: The term "keystore" is defined in this draft as a mechanism that intends safeguard secrets placed into it for protection. That said, the issue with the paragraph you cite is worse than you point = out, as it cites some but not all notable aspects about the = ietf-keystore module. I just rewrote that paragraph to a simpler = description of the subsections to come. OLD: This section defines a YANG 1.1 = module that defines a "keystore" and groupings supporting downstream modules to reference the keystore or have locally-defined = definitions. NEW: This section defines a YANG 1.1 = module called "ietf-keystore". A high-level overview of the module = is provided in . Examples illustatrating the = module's use=20 are provided in Examples. The = YANG module itself is defined in . > Section 2.1.1. p6 >=20 > The following diagram lists all the "feature" statements defined in >=20 > Everywhere beyond this page it says "tree diagram". RFC8340 is cited = in Section 2.1.3.1, but this is the first use (unless I'm wrong about = the "tree diagram"), so the citation should go here. >=20 > The following diagram lists the "typedef" statements defined in the > The following diagram lists all the "grouping" statements defined in >=20 > diagram -> "tree diagram" The thing that you don=E2=80=99t know is that those diagrams (plus = another that lists the =E2=80=9Cgroupings=E2=80=9D defined in the = document) are NOT RFC8340 tree diagrams, they are using a format I made = up that happens to look like the RFC 8340 diagrams. =20 I recommend the NETMOD WG consider an rfc8340-bis to define the new tree = diagram outputs for a list of features, a list of typedefs, and a list = of groupings. In the meanwhile, I updated this draft to explicitly state that = particular diagrams are not tree diagrams as follows: | The diagram above uses syntax that is similar to but not | defined in [RFC8340]. > Section 2.1.3.3 - 2.1.3.6: >=20 > " offer an option as to if an asymmetric key is defined" - personally, = I would say "as to whether". I don't know if the RFC-Editor (and rfc = style guide) care. Fixed =E2=80=94> replaced all "as to if=E2=80=9D strings to =E2=80=9Cfor = whether=E2=80=9D - better? > "augmented in if, e.g.," - I actually thought this was an editing = error, until heard "augment in" used as a word in the IETF session. Web = search shows "augment in" is a term of art in netconf! But some uses = add a hyphen, which I think is a good idea. Added to the new =E2=80=9CTerminology=E2=80=9D section: =E2=80=9C=E2=80=9D=E2=80=9D The sentence fragments "augmented" and "augmented in" are used herein as = the verbified form of the "augment" statement defined in . =E2=80=9C"=E2=80=9D > reference a asymmetric key in an alternate location. >=20 > a asymmetric -> an asymmetric. A global change might be good, as well = as changing "an symmetric" to "a symmetric". Both fixed - thanks! > Section 2.1.3.4 >=20 > * For the "local-definition" option, the defintion uses the > "asymmetric-key-pair-grouping" grouping discussed in > Section 2.1.3.4 of [I-D.ietf-netconf-crypto-types]. >=20 > It looks to me like it is actually Section 2.1.4.4 of = [I-D.ietf-netconf-crypto-types]. Fixed! =E2=80=9C2.1.3.4=E2=80=9D -> =E2=80=9C2.1.4.5" This is one issue with the new =E2=80=9Crelref=E2=80=9D element in the = xml2rfc v3 syntax, a section number (e.g., =E2=80=9C2.1.3.4=E2=80=9D) = has to be hardcoded, there=E2=80=99s no option to use the =E2=80=9Canchor=E2= =80=9D value, so misalignments may occur unknowingly. > Section 2.1.3.7 p 11 >=20 > * The "keystore-grouping" grouping is defines a keystore instance as >=20 > "is defines" -> "defines" Fixed > * For asymmetric keys, each "asymmetric-key" uses the "asymmetric- > key-pair-with-certs-grouping" grouping discussed Section 2.1.3.10 > of [I-D.ietf-netconf-crypto-types]. >=20 > "discussed" -> "discussed in" Quite right, and I found another like it, fixed both. > Why do none of the asymmetric keys here use a grouping that is the key = only, like the ct:asymmetric-key-pair-grouping used in Sectoin 2.1.3.4 = of this document (discussed in 2.1.4.4 of = [I-D.ietf-netconf-crypto-types]). >=20 > | | +--rw encrypted-private-key > | | +--rw encrypted-by > | | | +--rw (encrypted-by-choice) > | | | +--:(symmetric-key-ref) > | | | | +--rw symmetric-key-ref? leafref > | | | +--:(asymmetric-key-ref) > | | | +--rw asymmetric-key-ref? leafref The section you quoted is for the "encrypted-private-key=E2=80=9D case = of a =E2=80=9Cchoice" statement called "private-key-type=E2=80=9D. This = =E2=80=9Cchoice=E2=80=9D also supports "cleartext-private-key=E2=80=9D, = that is the raw key only, is that what you mean? > Section 2.2.1 p 13 >=20 > The following example illustrates keys in . >=20 > Like I said before, maybe a citation of RFC8340 here. The new Terminology section defines =E2=80=9C" (and = =E2=80=9C) pointing to RFC8342 (NMDA). [PS: RFC 8340 is = for =E2=80=9CTree Diagrams=E2=80=9D] > Section 2.2.3 p 17 has the phrase "following non-normative ". Does = that belong here? Or because this is XML, it can not be confused to be = a normantive Yang module? It was/is a little bit of everything \_o_/ I created a new introduction: These examples assume the existence of an example module called "ex-keystore-usage=E2=80=9D having the namespace "http://example.com/ns/example-keystore-usage". And then changed the line as follows: OLD: The following non-normative module is defined to = illustrate these groupings: NEW: Following is the "ex-keystore-usage" module's YANG = definition:=20 > > > hidden-asymmetric-key ey-ref> > >=20 > The "hidden-asymmetric-key" key appears later in the asymmetric-keys = part of the keystore example on p15. I don't know how to prevent that = forward sort of reference for the readers, or if it is a problem. This is not a problem, as ordering doesn=E2=80=99t matter with = YANG-defined models. =20 > Section 2.2.3 p 18 >=20 > list end-entity-cert-with-key { > key name; > ... > uses ks:local-or-keystore-end-entity-cert-with-key-grouping; > description > "An end-entity certificate, and its associated private key, > that may be configured locally or be a reference to a > specific certificate (and its associated private key) in > the keystore."; >=20 > You can't rely on descriptions, but I see no explicit reference to the = private key in that end-entity cert grouping. That grouping is defined = in Section 2.1.3.6 p 9, and the keystore-reference is an = asymmetric-key-certificate-ref-grouping. That grouping has an = asymmetric-key-ref and a cert. The description above says "and its = associated private key". So is the asymmetric-key-ref a ref to the = private key or to a key pair? Fixed. =E2=80=9Cassociated private key=E2=80=9D -> "associated = asymmetric key" "An end-entity certificate and its associated asymmetric key, that may be configured locally or be a reference to another certificate (and its associated asymmetric key) in the keystore.=E2=80=9D; > Section 2.3 p 25 >=20 > typedef symmetric-key-ref { > type leafref { > path "/ks:keystore/ks:symmetric-keys/ks:symmetric-key" > + "/ks:name"; > } >=20 > Does default-deny-write belong here, or added each time an item is = defined of this type? No, because it is a typedef, and typedefs don=E2=80=99t support = extensions (search RFC 7950 for "typedef-stmt=E2=80=9D and = "extension-stmt=E2=80=9D). > Section 2.3 p 26 >=20 > case asymmetric-key-ref { > leaf asymmetric-key-ref { > type leafref { > path "/ks:keystore/ks:asymmetric-keys/" > + "ks:asymmetric-key/ks:name"; > } > description > "Identifies the asymmetric key used to encrypt this key."; > } >=20 > (a) "the asymmetric key used to encrypt" - the public key part is used = to encrypt, so is the asymmetric key just the public key or a key-pair = where the appropriate part of the key-pair is used according to context? OLD: "Identifies the asymmetric key used to encrypt this key."; NEW: "Identifies the asymmetric key whose public key encrypted the associated key."; > (b) "encrypt this key" - The "this key" part is appropriate if the = assymmetric-key-ref is being used in an encrypted-by-choice structure, = but there are lots of places in this text where the type is not in such = a structure. Is it the case that the uses always resolve to be = encrypting a key? Right, per above, now "the associated key=E2=80=9D and the = =E2=80=9Cdescription" statement for "encrypted-by-choice-grouping=E2=80=9D= now says: "A grouping that defines a choice that can be augmented into the 'encrypted-by' node presented by the 'symmetric-key-grouping' and the 'asymmetric-key-pair-grouping' groupings defined in RFC AAAA.=E2=80=9D; Indicating that the =E2=80=9Cassociated key=E2=80=9D is defined in those = two groupings. Good enough? > (c) "encrypt" - Is it always the case that asymmetric keys in the = keystore will be used to encrypt something? There is no expectation = that the asymmetric key-pair will be used to sign something? An asymmetric-key may be used to sign something, but this module has no = need to do that. For instance, the module doesn=E2=80=99t support the = notion of a =E2=80=9Csigned key=E2=80=9D (a la =E2=80=9Cencrypted = key=E2=80=9D), beyond its support for certificates. This doesn=E2=80=99t = preclude a consuming application from using an asymmetric key to sign = data if needed. > Section 2.3 p27 >=20 > description > "A grouping that expands to allow the symmetric key to be > either stored locally, within the using data model, or be > a reference to a symmetric key stored in the Keystore."; >=20 > The following is wordsmithing the description text, so a = very-nitty-nit. >=20 > ", or be" -> ", or" (the "be" is before the "either", don't need it) >=20 > A reader might be confused as to whether the disjunction was two = disjuncts or three. Fixed, in all four places where =E2=80=9Cor be=E2=80=9D was being used. > I might suggest using "i.e., within the using data store". Maybe also > move the "be" inside the "either or" for scoping > "A grouping that expands to allow the symmetric key to either > be stored locally, i.e., within the using data model, or be > a reference to a symmetric key stored in the Keystore."; Added =E2=80=9Ci.e.,=E2=80=9D > The groupings in this section have a descriptoin of the grouping, a = description of the key case and a description of the choice. I thought = it worked better to place the description of the choice closer to the = "choice local or keystore" rather than at the end. Moved all =E2=80=9Cchoice=E2=80=9D statement descriptions be before the = =E2=80=9Ccase=E2=80=9D statements. > And finally. Descriptions very frequently (always?) conclude with a = "." but they are very frequently not sentences, so the "." is not = necessary. I do not know if the RFC-Editor or the Style manual cares. The descriptions should be sentences. I found only two instances that = were missing an opening article (=E2=80=98A=E2=80=99), which gave the = appearance of not being a sentence=E2=80=A6but you said there were = =E2=80=9Cmany"? > Section 2.3 p 28 >=20 > grouping local-or-keystore-asymmetric-key-with-certs-grouping > ... > case keystore { > if-feature "keystore-supported"; > leaf keystore-reference { > type ks:asymmetric-key-ref; > description > "A reference to an asymmetric-key (and all of its > associated certificates) in the Keystore."; >=20 > An example of my puzzle about the = local-or-keystore-asymmetric-key-with-certs-grouping keystore-reference. = How are the certs to be found if the keystore-reference is to the = asymmetric key only? Or must the asymmetric-key-ref sometimes point = just to a key and sometimes to a key+certs, as needed? An asymmetric key "in the Keystore=E2=80=9D always allows certs to be = associated. I understand that this isn=E2=80=99t true for asymmetric = keys in general. > Section 3 p 31 >=20 > In some implementations, a server may support built-in keys. Built- > in built-in keys >=20 > "Built-in built-in" =3D> "Built-in" Fixed - redundancy removed. > Section 3 p 32 >=20 > In order for the built-in keys (and/or their associated built-in > certificates) to be referenced by configuration, the referenced keys > MUST first be copied into . The keys SHOULD be copied into > using the same "key" values, so that the server can bind > the references to the built-in entries. >=20 > Built-in "hidden" keys cannot be copied into other parts of the > configuration because their private parts are hidden, and therefore > impossible to replicate. >=20 > Section 4 p34 says built-in keys MUST be hidden. So they must be = copied to but they can't be copied? Huh? >=20 OLD: Built-in "hidden" keys cannot be copied into other parts of = the=20 configuration because their private parts are hidden, and = therefore impossible to replicate. Built-in "encrypted" keys MAY be = copied into other parts of the configuration so long as they maintain = their reference to the other built-in key that encrypted them. NEW: In addition to copying keys into the Keystore in = <running>,=20 cleartext and encrypted keys may be copied into other parts of=20= configuration, but they will lose their connection to having = been a built-in value. Note that hidden keys cannot be copied into other parts of the configuration because doing would lose the = key's connection to the built-in key, where the key's secret value = is=20 stored. Built-in "encrypted" keys MAY be copied into other = parts=20 of the configuration so long as the reference to the other = built-in=20 key that encrypted them is maintained. > The keys SHOULD be copied into > using the same "key" values, so that the server can bind > the references to the built-in entries. >=20 > The word "key" is overloaded in this document, like "The key = characteristic of the built-in keys" and "Key Words". Here, the = reference is surely to a required part of the "list" syntax, so no way = to use a different word. Maybe say 'the same list "key" values' or 'the = same values for the list "key" field/node'. Changed "Key characteristic" to "primary characteristic=E2=80=9D. "Key words=E2=80=9D is RFC 2119 language that cannot be altered. OLD: The keys SHOULD be copied into using the same "key" values, so that the server can = bind the references to the built-in entries. NEW: The keys SHOULD be copied into <running> using the same value for the list's "key"=20= substatement, so that the server can bind the references to = the built-in entries. > Built-in "encrypted" keys MAY be copied > into other parts of the configuration so long as they maintain their > reference to the other built-in key that encrypted them. >=20 > (a) Section 4 p34 says "built-in keys MUST be hidden", so is there a = way the hidden built-in keys can be encrypted keys? Under the hood, it is possible that a hidden key is encrypted, but if it = is, that information would be hidden too ;) > (b) So encrypted built-in keys must always be encrypted by other = built-in keys? Is there a way to represent that in the data model? (I = explored this before.) >=20 > MAY be a subset of the built-in keys define in = >=20 > "define" -> "defined" FIXED. > Only the referenced keys need to be copied; that is, the keys in > MAY be a subset of the built-in keys define in > . No keys may be added or changed (with exception to > associating additional certificates to a built-in key); that is, the > keys in MUST be a subset (which includes the whole of the > set) of the built-in keys define in . >=20 > I don't understatnd this part. First it says >=20 > "keys in MAY be a subset of the built-in keys define in = " >=20 > and then >=20 > "keys in MUST be a subset ... of the built-in keys define in = ". >=20 > That is inconsistent, is it intended? >=20 > Does the last sentence mean that if there are built-in keys, no other = keys may be added to the keystore? I don't know what is intended here. Removed the last part: i.e., =E2=80=9Cthe keys in MUST be a = subset (which includes the whole of the set) of the built-in keys define = in ." NEW: Only the referenced keys need to be copied; that is, the keys in <running> MAY be a subset, including the whole of the = set,=20 of the built-in keys defined in <operational>. =20 No new built-in keys may be added nor existing built-in = changed,=20 with exception to associating additional certificates to an=20 existing built-in key. > About "exception to" - I use "exeption to " and "exception for = ". I don't know if the RFC-Editor or the Style manual = cares. =E2=80=9Cexception to=E2=80=9D =E2=80=94> =E2=80=9Cexception for=E2=80=9D > Section 4.1 p34 >=20 > not support hidden keys, then the private data part of key MUST be=20 >=20 > "of key" -> "of the root key" This sentence no longer exists after the rewrite of the section = addressing the comment from Magnus. > Section 4.1 p35 >=20 > If the hidden root key is asymmetric, then the server > SHOULD provide APIs enabling other keys to be both generated and > encrypted by it >=20 > The "both generated and encrypted by it" sounds like keys are being = generated by the root key. I don't think that's generally true. = Section 4.2 separates key generation and key encryption steps. I think = this should be clearer. >=20 > (The mention of other crypto services moved to area before nits.) After addressing the comment from Magnus, the new text is: Implementations SHOULD provide an API that simultaneously = generates and encrypts a key (symmetric or asymmetric) using a KEK. = Thusly newly generated key cleartext values are never known to the administrators generating the keys. Better? > Section 4.2 p35 >=20 > (A discussion of issues, not nits, was moved to area before nits.) >=20 > Section 4.3 p35 >=20 > (A discussion of issues, not nits, was moved to area before nits.) =20 >=20 > Section 5.2 p38 >=20 > (A discussion of issues, not nits, was moved to area before nits.) Okay. > | Please be aware that this module uses the "key" and "private- > | key" nodes from the "ietf-crypto-types" module > | [I-D.ietf-netconf-crypto-types], where said nodes have the NACM > | extension "default-deny-all" set, thus preventing unrestricted > | read-access to the cleartext key values. >=20 > This text missed the change A.19 to add a "cleartext" prefix as in = ietf-netconf-crypto-types. The "cleartext" prefix is present in the = modules, tree-diagrams, XML, etc., but the references in text here did = not change. (Actually, I see several examples in the text in = ietf-netconf-crypto-types where the change was not made, e.g. p 9 says = '- The "key" node can encode any plain-text key value.' where the = preceding tree diagram has a node named "cleartext-key" and older = versions said "key".) I appreciate the discussion of the = default-deny-all in Section 3.5 p42 of ietf-netconf-crypto-types and I = think that a citation here would be warranted and useful. Fixed: prefixed =E2=80=9Ccleartext-=E2=80=9C NEW: Please be aware that this module uses the "cleartext-key" = and=20 "cleartext-private-key" nodes from the "ietf-crypto-types" = module=20 , where = said nodes have the NACM extension "default-deny-all" set, thus = preventing uncontrolled read-access to the cleartext key values. Also fixed a number of missing =E2=80=9Ccleartext-=E2=80=9C prefixes in = the crypto-types draft. > BTW. I don't know the NACM well but could it be said that the = default-deny-all prevents uncontrolled access, but does not necessarily = prevent unrestricted access, because a present but careless access = control might not actually restrict access? Fixed. See =E2=80=9Cuncontrolled=E2=80=9D the the NEW above. > Section 6.2 p 39 >=20 > "the the" -> "the" Fixed (in other documents also) - thanks! > Section 7.2 p40 >=20 > The list of Informative References includes: >=20 > [I-D.ietf-netconf-keystore] > Watsen, K., "A YANG Data Model for a Keystore", Work in > Progress, Internet-Draft, draft-ietf-netconf-keystore-17, > 20 May 2020, netconf-keystore-17>. >=20 > Isn't this a self reference to an earlier version? >=20 > Note: ID nits gives 11 warnings, but all are due to references to = older versions of existing drafts or to future versions not yet = published. The latter case seems to be wrong, and the warning usually = notes > (However, the state information for draft-ietf-netconf-keystore is = not > up-to-date. The last update was unsuccessful) >=20 > I have no idea what that means. The warnings are consistent, so may = be something to watch. Generally speaking, a document should not reference itself! The = self-reference in this document is coming from Section 1.1 (Relation to = other RFCs). The XML feeding this section is from a common snippet of = xml2rfc XML that is stitched into the same spot for each of the = documents in the collection of RFCs-to-be, per the "Relation to other = RFCs=E2=80=9D section. My choices are: 1) Copy-paste the common-text into each document and then customize it = by converting the self-reference to something like =E2=80=9C=E2=80=9D, and the remove the reference from the "Informative = References=E2=80=9D section. or 2) Add an RFC-editor note requesting that customization be made for each = document in the collection. Thoughts? K. >=20 > =E2=80=94Sandy >=20 --Apple-Mail=_0348A326-1A9C-4C92-A178-9883E263A74F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[+netconf = (for visibility) and -keystore.authors (since its just me)]


Hi = Sandy,

This is a = massive review.  Thank you for that, but it demands a massive = response=E2=80=A6I hope you=E2=80=99re ready for it  ;)

Before jumping in, I = want to clarify something that I=E2=80=99ll also make a point to add to = the Introduction section, which is that the ietf-keystore YANG module = defines a configuration model supporting existing practices; it does not = intend to define new ways for doing things.  For instance, the = sections regarding built-in keys, hidden keys, key-encryption keys, and = master keys all attempt to support existing practices.  The point = being that, in thinking about what these sections are saying, trust that = this draft isn=E2=80=99t defining new behavior, and folk's experience = with systems is the best guide.

Also, note that I did update Section 4 = (Encrypting Keys in Configuration) = per Magnus=E2=80=99s review.  That update was sent to the SecDir = list on the 10th (with GitHub commit here [1]).  While the section = was effectively entirely rewritten, the update essentially = accomplishes just one thing, which is the swap a couple terms as = follows: r/root key/master key/ and r/shared root = key/key encryption key/.  Your review precedes this = update, but my responses below will, when appropriate, reflect the current = terms.

[1] https://github.com/netconf-wg/keystore/commit/5b3b9f3db0d6b7027= ddf5f0e983ab958e8802251


PS: I just updated all the drafts with the updates from = this email.  The bad news is that the Datatracker is still = using the *previous* draft version for hyperlinks, so be sure to = manually increment whenever opening a referenced = document.

Thanks,
Kent



On Aug 12, 2020, at 9:10 AM, Sandra Murphy = <sandy@tislabs.com> wrote:

This = is a requested SECDIR early review of draft-ietf-netconf-keystore-19, = not an IETF Last Call review.

I have = reviewed this document as an early review assigned by the security = directorate, as part of the directorate's ongoing effort to review = documents headed eventually to the IESG.  Document editors and WG = chairs should treat these comments just like any other comments.

I am a neophyte at Yang so any comments I make = here should be understood with that in mind.  (The recent mpls and = netconf discussion of the MPLS module reuse of an RPC and the difference = between "destination address" and "local label" have further impressed = upon me just how much I do not know about YANG.)

Outline of this review is:

News = of draft status
Summary of the draft
General = and issue comments
Page-by-page comments and nits


News of draft status:
---------------------

This = document was in WGLC when assigned and it appears that the WGLC has not = yet been decided.

In the netconf session at = IETF108, the wg discussed the need for a raw password feature, which = might end up as a new grouping being added to the = draft-ietf-netconf-crypto-types and therefore might induce changes to = this draft as well.

True, it was discussed @108, but that change in = crypto-types will not affect this draft (however, it will affect the = tcp-client-server, ssh-client-server, and http-client-server = drafts)


Summary of the = draft:
---------------------

The draft abstract says:
 This document = defines a YANG 1.1 module called "ietf-keystore" that
=  enables centralized configuration of both symmetric and = asymmetric
 keys.

Keys = may be symmetric or asymmetric, and maybe be of types "cleartext", = "hidden" (as in a TPM), or "encrypted". Keys can be configured locally = (which means within the data model) or as a reference to a keystore = item.  One server might have multiple keystores in use at any one = time.

The document defines groupings that = might prove useful for other YANG modules that import this one.

The document describes the data model for the = keystore and provides many examples.  The descriptions of the data = model and examples are presented in different modes as you read through = the document, in tree diagrams, XML, and text that (surely?) is YANG (I = think).  I believe the YANG text is authoritative.

True, = the YANG module in Section 2.3 is the raison d=E2=80=99=C3=AAtre = for the draft.



For other readers, here's the sequence of = description modes.

Section 2.1 Mostly tree = diagram descriptions of the groupings defined in this document.

Section 2.2.1-2.2.2 Examples (Keystore = Instance and Cert Expiration) given in XML.

Section 2.2.3 A module, containing those groupings of Section = 2.1 whose titles' prefixes are "local-or-keystore-", is described in = what I believe would be called YANG (p16-18) and then in a tree diagram = (p19-23).

Section 2.3 This section = describes what I believe to be the normative Yang module text.

Yes, = the YANG module in 2.3 is the normative module text for the = draft.



General and issue comments:
---------------------------

This = document is very well written.  The examples were very helpful, = particularly to this reader who was unfamiliar with Yang.  I can't = imagine the patience and care it took to keep so many descriptions in = close alignment.

My secret is:

1)= maintain all YANG modules and examples a stand-alone = files.
2) each time building the draft (`make clean; make`), = dynamically:
      a) validate all YANG = modules
      b) validate all examples against = the YANG modules
      c) generate all tree = diagrams
      d) stitch tree-diagrams, = examples, and YANG modules into an uber xml2rfc file

This way, everything stays connected and = up-to-date.  I takes effort to set up, but it pays for itself over = time (not only for the author, but also for WG participants who might = otherwise discover anomalies that could=E2=80=99ve been = caught).


The document describes two new typedefs: asymmetric-key-ref = and symmetric-key-ref.  Those typedefs are never further explained. =  I believe (based only on the string "ref" in the name and usage as = "keystore-reference") that these are intended to be references to named = items in other parts of the keystore which themselves contain keys. =  (Sheesh it takes a lot of words!) And I hope/believe that the = asymmetric-key-ref is to a structure that contains a key-pair.

Yes, = you got it. 

FWIW, Section = 2.1.2 (Typedefs) says: "The leafrefs refer to symmetric and asymmetric = keys in the keystore.  These typedefs are provided primarily as an = aid to downstream modules that import the "ietf-keystore" module.=E2=80=9D=   Not good enough?


The text typically says "asymmetric key" without = distinguishing whether it is talking about the public key, the private = key, or a key-pair.  Presumably "asymmetric key" means a key-pair = and the implementations of operations know from context which key in the = key-pair is needed.

Yes, that is what is intended.  Is that = nomenclature okay or should =E2=80=9Ckey-pair=E2=80=9D be postpended = throughout?

In contrast, note that = when referring to asymmetric key halfs, the text attempts to always call = that it out, e.g., =E2=80=9Cthe public half of the asymmetric = key=E2=80=9D.


I am not familiar with the Yang system, so I wonder if there = is any mechanism in Yang's use to check if the assumptions of the data = model are followed.  (1) If an asymmetric key is configured with a = public key and a private key that are not a key-pair, where is that = caught?  (2) If an asymmetric key and an associated cert are = configured, but the public key part of the structure is not the public = key mentioned in the cert, where is that caught?  (3) If the data = model says that a component is an asymmetric-key-ref, but the de-ref'd = value is not an asymmetric key (key type?), where is that caught, like = maybe when the value is stored in the keystore?  (Do the questions = even make sense?)

Yes, the questions (now numbered 1-3) make = sense.

For #1) I just updated the = =E2=80=9Cdescription=E2=80=9D for the = " asymmetric-key-pair-grouping=E2=80=9D in the = "ietf-crypto-types=E2=80=9D module (in = draft-ietf-netconf-crypto-types):

OLD:
      "A private key = and its associated public key.";

NEW:
      "A = private key and its associated public key.  Implementations
       SHOULD ensure that the two keys = are a matching pair.=E2=80=9D

[Note: =E2=80=9CSHOULD=E2=80=9D is used instead of = =E2=80=9CMUST=E2=80=9D because the fallback is to simply *trust* that = the clients never configure mismatched values.]

For #2) Already the description statements for = various groupings in the "ietf-crypto-types=E2=80=9D module have = suitable statements:

  grouping end-entity-cert-grouping {
    description
    =   "An end entity certificate, and a notification = for when
       it is about to = (or already has) expire.  Implementations
  =      SHOULD assert that, where used, the end = entity certificate
      =  contains the expected public key.=E2=80=9D;
    = <snip/>
  = }

  grouping asymmetric-key-pair-with-cert-groupin= g {
    description
 =     "A private/public key pair and an = associated certificate.
      =  Implementations SHOULD assert that certificates contain
       the matching public = key.=E2=80=9D;
    = <snip/>
  = }

  grouping asymmetric-key-pair-with-certs= -grouping {
    description
      "A private/public key pair and = associated certificates.
      =  Implementations SHOULD assert that certificates contain
       the matching public = key.=E2=80=9D;
    = <snip/>
  }


For #3) There are three = parts to this one.  

3a) First, = when configuring a key into the Keystore, I made the following = adjustments:

For = "symmetric-key-grouping=E2=80=9D:
  OLD:
  =     description
      =   "Identifies the symmetric key's format.=E2=80=9D;
&n= bsp; NEW:
      description
        "Identifies the symmetric = key's format.  Implementations
    =      SHOULD ensure that incoming symmetric key = value is encoded
         in = the specified format.=E2=80=9D;

For = "public-key-grouping=E2=80=9D:
  OLD:
  =     description
      =   "Identifies the public key's format.";
  =   }
  NEW:
    =   description
      =   "Identifies the public key's format. Implementations = SHOULD
         ensure that = incoming public key value is encoded in the
  =        specified format.";
  =   }

For asymmetric-key-pair-grouping:
&nb= sp; OLD:
      description
        "Identifies the private = key's format.";
    }
  = NEW:
      description
  =       "Identifies the private key's = format.  Implementations SHOULD
    =      ensure that incoming private key value is = encoded in the
        =  specified format.";
    }



3b) Second, regarding if a format mismatch can = occur, this is not possible as, e.g., the =E2=80=9Ckey-format=E2=80=9D = for the symmetric-key (see below) uses an =E2=80=9Cidentityref" that = indicates that set values must derive from the "symmetric-key-format=E2=80=9D (i.e., NOT either = the =E2=80=9Cpublic-key-format=E2=80=9D = or =E2=80=9Cprivate-key-format=E2=80=9D = identities):

  =   leaf key-format {
    =   nacm:default-deny-write;
    =   type identityref {
    =     base symmetric-key-format;
  =     }



3c) Third, regarding if = the thing referenced is what its supposed to be, note in the YANG module = has this definition:

  typedef asymmetric-key-ref {    type leafref {
    =   path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key"<= br class=3D"">         + "/ks:name";
    }

Thus, if a configuration points to =E2=80=9Cfoo=E2=80= =9D, but no asymmetric key called =E2=80=9Cfoo=E2=80=9D exists, then a = YANG validation would fail when the configuration is attempted to be = set.


QUESTION: should these implementation-notes be = *moved* into Security Considerations?    One one hand, = there=E2=80=99s is best IETF-form but, on the other hand, there is best = YANG-form.   =46rom both PoVs, I think a case can be made but, if = no one cares, I=E2=80=99ll leave it be.

Section 3 says
=             &n= bsp;           &nbs= p;  Built-in "encrypted" keys MAY be copied
=  into other parts of the configuration so long as they maintain = their
 reference to the other built-in key that = encrypted them.

I could see that built-in = keys should be encrypted by other built-in keys (I don't see what other = keys are available at the building-in time to encrypt them, but proof by = "I don't see" is unconvincing).  Is that required?  I don't = think the data model represents built-in keys as a distinct type, so I'm = not sure the data model could represent the built-in-ness requirement. =  Could it ever be that a built-in key could be encrypted by a = non-built-in key?  I.e., does something prevent it.

=46rom = a terminology perspective, equate =E2=80=9Cbuilt-in=E2=80=9D with = =E2=80=9Cgenerated by the manufacturer and/or in the device=E2=80=99s = factory default configuration".

To = the last question, no, a built-in key cannot be encrypted by a = non-builtin key.  That would be putting the cart in front of the = horse, so to speak.

But, to the crux = of your question, that sentence simply acknowledging what=E2=80=99s = possible.  For instance, imagine a device ships with a *hidden* = built-in key called =E2=80=9Cfoo=E2=80=9D and an encrypted built-in key = called =E2=80=9Cbar=E2=80=9D, where bar is encrypted by foo.   = Presumably both foo and bar would appear in the Keystore in = <operational> and, if a user wanted to use bar as a KEK, they = would copy it into the exact same spot in <running> (i.e., in = Keystore, using the same name, e.g., =E2=80=9Cbar").  This sentence = acknowledges that the key might possibly be renamed =E2=80=9Cbaz=E2=80=9D = or possibly be copied into a =E2=80=9Clocal definition=E2=80=9D = somewhere (i.e., not in Keystore at all).  In such cases, the = configured-key is still valid so long as the base64 and the leafref = pointing to =E2=80=9Cfoo=E2=80=9D remain.  It=E2=80=99s a corner = case that=E2=80=99s unlikely to trigger in practice, because why would = you, though theoretically possible without a technical reason for a = constraint.  Makes sense?  



Section 4 p34 = says "built-in keys MUST be hidden".  That really should be = mentioned in Section 3.

As mentioned in an email I wrote on Thu (Aug = 13th), I don=E2=80=99t think this MUST is enforceable and so am dialing = it back something akin to a SHOULD or RECOMMENDED via this = text:

          =   A MEK is commonly = a globally-unique built-in = (see <xref target=3D"built-ins"/>)
          =   asymmetric key for which the private key, due to its = long lifetime, is hidden 
        =   =   (<relref section=3D"2.1.4.5." target=3D"I-D.ietf-= netconf-crypto-types"/>) and the 
    =         public key is contained in an = identity certificate (e.g., IDevID).



Section 3 and 4 about built-in keys and root = keys and hidden keys:

Section 4 p34 says

 The root key SHOULD be a hidden key, = i.e., one whose private data has
 no presence in = <running> or <operational>

and =             &n= bsp;           &nbs= p;         Given the long = lifetime of built-in
 keys (see Section 3), built-in = keys MUST be hidden.

But this last part is no longer a =E2=80=9CMUST=E2=80=9D = (see above)

and Section 3 p32 says

 The key characteristic of the built-in = keys is that they are provided
 by the system, as = opposed to configuration.  As such, they are
=  present in <operational>.

So = built-in keys must be hidden, which means they are candidates to be root = keys, but they are "present in operational".  By the first = sentence, their private data is not in <operational>, so the = configuration must use the hidden-private-key or hidden-key key-type for = the secret parts.

Yes

By the requirement that = built-in keys must be hidden, servers that do not support hidden keys = can not use built-in keys.  Correct?

Not = anymore, since it can=E2=80=99t be enforced.  The better statement = might be: "it is highly RECOMMENDED that builtin keys are [permanently] = hidden and, if this is not possible, highly restricted access mechanisms = are used to limit the built-in key's secret data to only highly = authorized clients (e.g., an organization=E2=80=99s crypto = officer)."



 A hidden root key MAY be either a symmetric key or an = asymmetric key.

True.   Asymmetric is the common case but its = possible that a MEK could be a symmetric key, such that *only* a, e.g., = TPM, is able to encrypt/decrypt certain keys (e.g., KEKs)


Does the same apply to built-in keys? =  The examples in Section 3 are all asymmetric keys.

Yes = (see example in previous response)


Is using a built-in key as a root key advisable in = operational situations?

Absolutely.  This is commonly done and (I = think) recommended by TCG.


Presumably if a root key is not a built-in key and not a = hidden key, then its secret data must be of cleartext-key type. =  Encrypting the root key is not possible, there is no other single = key available (or it would be the root key).  Has any consideration = been given to dual root keys?  I could see that that would be too = complex to manage.

Your presumptions are correct.   There = certainly could be more than one MEK (root key).  This model = doesn=E2=80=99t constrain that possibility from being exposed to = users.


Section 4.1 = p35

The use of the root key mentions = encrypting with an asymmetric key, but not signing with an asymmetric = key.  Are signing and other crypto services not a part of the = netconf view?

Signing is using something a device might do to = prove to a remote peer that it originated some data.   In the = context of the Keystore, it=E2=80=99s clearly desirable to configure = encrypted keys but not clear there is a need to configure signed keys. =  At least, I=E2=80=99m unaware of the use case.   Certainly = any asymmetric key could be used to sign data, but the API (i.e., RPCs) = enabling that are currently outside the scope of this = document.



Section 4.2 p35

 Each time = a new key is to be configured, it SHOULD be encrypted by
=  the root key.

Would it be good to = discuss how to configure a root key?  If the root key is not a = built-in key and there is no support for a hidden key, then a cleartext = key would be required, correct?  An encrypted key would not be = possible because it would require a second key that would have to be = available in the keystore - which means that would be the root key.

I = added:

   "How = to configure a MEK during the manufacturing process is = outside
     the scope of = this document.=E2=80=9D

And:

  =    "It is highly RECOMMENDED that MEKs are built-in and = hidden but, if
      this is not = possible, MEKs highly restricted access mechanisms SHOULD 
      be used to limit access to the = MEK's secret data to only highly 
    =   authorized clients (e.g., an organization=E2=80=99s crypt= o officer).  In this
    =   case, it is RECOMMENDED that the MEK is not built-in = and hence is,
      effectively, just like a = KEK.=E2=80=9D


Section 4.3 p35

Heads up: = this is the section that was rewritten based on Magnus=E2=80=99s review. =  The =E2=80=9Cshared root key=E2=80=9D is now called =E2=80=9Ckey = encryption key=E2=80=9D (KEK) and the =E2=80=9Croot key=E2=80=9D is now = =E2=80=9Cmaster encryption key=E2=80=9D (MEK) in the -20 version I = shared as an attachment last week.  

PS: Magnus suggests renaming =E2=80=9CMaster = Encryption Key=E2=80=9D to =E2=80=9CMaster Key=E2=80=9D; I haven=E2=80=99t= done this yet hence why I=E2=80=99m still using the MEK = term=E2=80=A6


This process for migrating a configuration to a new server = would also work for replacing the root key on a server without requiring = re-encrypting all the keystore's encrypted keys.  (Mind you, I = don't know how a non-builtin, non-hidden root key is configured from a = cold start.)

Yes.


The text calls the key a "shared root key" - but the use in = this process of migrating a configuration does not require that the key = be shared other than between the "first" and "second" servers.  I = don't see that there's any reason to share the "shared root key" more = widely; each migration between two servers could use a different "shared = root key".

Agreed.


"This shared root key would only need to be known to an = organization's crypto officer." -- until it is decrypted in a server for = use in encrypting and decrypting local keys, right?  I don't know = how YANG implementations hold the root keys that are constantly in use = but hopefully access is carefully controlled.

To = your question, right, only the crypto officer and then later the device = itself should ever know the key.

Regarding the second part of your comment, please = note that the YANG model isn=E2=80=99t forcing any behavior.  =46rom = my previous comments above, I think you see that the draft = =E2=80=9Crecommends=E2=80=9D certain behaviors but, otherwise, enables = implementations do present an interface reflecting a device=E2=80=99s = internal behavior.


A key common to all servers in an operational environment has = been found to be unwise because an exposure at one server has a global = impact.  The text on p 36 says "The crypto officer can then safely = handoff the encrypted shared key to other administrators responsible for = server installations, including migrations." but that should be taken as = a handoff as necessary at each occasion, not taken as a handoff to all = other servers jointly, at the same time.

Agreed. =  I think that it understood that the shared KEK would be encrypted = for the minimal subset of devices=E2=80=A6presumably just a single = failover device but, perhaps, a set of devices constituting a = cluster.


Section 5.2 = p38

This section points to the NETCONF = protocol's support for mutual authentication, but in this particular = case, I believe that the mandatory support for confidentiality is very = important and should be mentioned, in particular for the configuration = of cleartext keys.

Please be aware that this section is following = (roughly) the template defined here: https://tools.ietf.org/html/rfc8407.html#section-3.7.1. =  This template ware reviewed by previous Security Area ADs = .

FWIW, the first = paragraph says =E2=80=9C=E2=80=A6 Both of these protocols have = mandatory-to-implement secure transport layers (e.g., SSH, TLS) with = mutual authentication.=E2=80=9D, so =E2=80=9Cconfidentiality isn=E2=80=99t= completely unstated=E2=80=A6.

What text would you like to see added = here?


I had one puzzle I could never figure out - why the = keystore-reference for the grouping = local-or-keystore-asymmetric-key-with-certs-grouping (Sect 2.1.3.5) is = an asymmetric-key-ref type.  Other uses of asymmetric-key-ref are = consistent with it being a reference to a key only, but here I expected = the reference would be to a structure that contains the key and its = associated certs.  The descriptions in the Sect 2.3 Yang Module p29 = says the grouping contains the cert and its keys.

Good = catch.  Yes, there is some wonkiness here.  (Continued in next = comment)

Is the asymmetric-key-ref in = some way useable as both a reference to an asymmetric key and an = asymmetric key and its associated certs?

Indeed. =  The reality is that the Keystore only supports the notion of keys = that may have associated certificates.  In all cases, the = =E2=80=9Clocal=E2=80=9D definition is as described, but sometimes the = =E2=80=9Ckeystore=E2=80=9D definition is a bit off. =   

The only perfect* = mapping is the = =E2=80=9Clocal-or-keystore-asymmetric-key-with-certs-grouping=E2=80=9D = grouping, as that is exactly what the Keystore has in it. =  

The "local-or-keystore-end-entity-cert-with-key-grouping=E2=80=9D = isn't that bad either, as it points to specific cert, which is under a = key=E2=80=A6the only wonkiness is that the key may have other certs = under it too, but it isn=E2=80=99t a big deal. =  

The = "local-or-keystore-asymmetric-key-grouping=E2=80=9D is the worst mapping = because, while it does point to a key, the key may have certs under it. =  The expectation is that this won=E2=80=99t be a problem in = context because the code is, presumably, only interested in the key (not = the certs), as that is exactly all the code would get if = the =E2=80=9Clocal=E2=80=9D definition is = used.


At first I thought the "associated certs" in the groupings = were the certificate chain certs - the subject cert, the issuer cert, = etc.  I am not sure they are - might they be many certificates for = the same public key, perhaps for different algorithms?  I think = that should be explained.

Each =E2=80=9Ccertificate=E2=80=9D is actually the = "end-entity-cert-cms" CMS structure defined in the =E2=80=9Ccrypto-types=E2= =80=9D draft.  Each CMS MAY contain a chain of certs for that = end-entity =E2=80=9Ccertificate=E2=80=9D, in quotes because the = =E2=80=9Ccertificate=E2=80=9D can also include associated issuer certs, = as needed for the context.

Therefore, = that a key may have a multiplicity of associated certs (i.e. CMSs) is to = support things such as: different algorithms, different Subject/SAN, = different Issuers, etc.  Makes sense.

Happy to make things more clear, can you propose = the text you=E2=80=99d like to see?




Page-by-page comments and nits:
-------------------------------

Section 1 p 3

 there are = groupings that defined enabling a key to be either

Did you mean the past tense here?  Or did you mean = "define"?

Fixed =E2=80=94> "define".

Section 1.1 p 4

In the diagram, = what is the meaning of the lines - what relationshiop do they represent = - e.g., "refers to", "uses", "augments", something else?

"The = relationship between=E2=80=9D =E2=80=94> "The normative dependency = relationship between"


It looks like = netconf-client-server has no relationship (whatever "relationship" is) = to http-client-server, restconf-client-sever has no relationship to = ssh-client-server, and http-client-server has no relationship to = keystore or truststore.  Is that all correct?

Yes. =  NETCONF doesn=E2=80=99t have an HTTP-based transport. =  RESTCONF doesn=E2=80=99t have an SSH-based transport.  HTTP = may be =E2=80=9Cmixed-in=E2=80=9D with TLS to created a protocol stack, = but doesn=E2=80=99t itself depend on TLS.


Section 1.3 p 5

=  This document in compliant with Network Management Datastore
 Architecture (NMDA) [RFC8342].

RFC8342 is listed in the informative section - what does it = mean to be compliant with an informative reference?

r/in = compliant/is compliant/

This text is = via https://tools.ietf.org/html/rfc8407#section-3.5.   = It means that the data model has been developed assuming that there = exists dedicated <operational> datastore that contains the = =E2=80=9Coperational=E2=80=9D value for the system as a superset of = configured nodes.  



 [Std-802.1AR-2009] certificate) are = expected to appear in
 <operational>

I did not catch that the term = <operational> was part of R%FC8342, and went looking for a = reference.  I found it in many places, like RFC6241.  For = those just that unobservant, could you put a citation here to RFC8342, = which I think is the proper reference for that term.  Note: = <running> appears later, and a citation to RFC8342 is probably = proper there as well.  Yes, I know, probably about as necessary as = a reference to "packet", but it would have spared me, maybe other = non-Yang clueful folk will be reading this also.

Quite = right - I added a =E2=80=9CTerminology=E2=80=9D section with references = for "<running>=E2=80=9D and =E2=80=9C<operational>=E2=80=9D= (RFC 8342), as well as =E2=80=9Cclient" and =E2=80=9Cserver=E2=80=9D = (RFC 6241).



Section 2 p 5

 This = section defines a YANG 1.1 [RFC7950] module that defines a
=  "keystore"

Should that be = "ietf-keystore"?  Or do you mean keystore in a general sense, in = which case I think the quote marks make it look like a name, not a = general sense.  (I went looking for a definition of a "keystore", = but that could just be me.)

Part = of the issue is that the term =E2=80=9Ckeystore" isn=E2=80=99t defined = anywhere. I just added the following in the new =E2=80=9CTerminology=E2=80= =9D section:

 The = term "keystore" is defined in this draft as = a mechanism
         that = intends safeguard secrets placed into it for = protection.

That said, the issue = with the paragraph you cite is worse than you point out, as it cites = some but not all notable aspects about the ietf-keystore module.  I = just rewrote that paragraph to a simpler description of the subsections = to come.

OLD:
  =        This section defines a YANG = 1.1 <xref target=3D"RFC7950"/> module
         that defines a "keystore" = and groupings supporting downstream
    =      modules to reference the keystore or = have locally-defined definitions.

NEW:
         This section = defines a YANG = 1.1 <xref target=3D"RFC7950"/> module
          called "ietf-keystore".  A high-level = overview of the module is provided in
    =       <xref target=3D"overview"/>. = Examples illustatrating the module's use 
  =         are provided = in <xref target=3D"examples">Examples</xref>. The = YANG
          module itself = is defined in <xref target=3D"keystore-yang-module"/>.





Section 2.1.1. =  p6

 The following diagram lists = all the "feature" statements defined in

Everywhere beyond this page it says "tree diagram". =  RFC8340 is cited in Section 2.1.3.1, but this is the first use = (unless I'm wrong about the "tree diagram"), so the citation should go = here.

 The following diagram lists = the "typedef" statements defined in the
 The = following diagram lists all the "grouping" statements defined in

diagram -> "tree diagram"

The = thing that you don=E2=80=99t know is that those diagrams (plus another = that lists the =E2=80=9Cgroupings=E2=80=9D defined in the document) are = NOT RFC8340 tree diagrams, they are using a format I made up that = happens to look like the RFC 8340 diagrams.  

I recommend the NETMOD WG consider an rfc8340-bis = to define the new tree diagram outputs for a list of features, a list of = typedefs, and a list of groupings.

In = the meanwhile, I updated this draft to explicitly state that particular = diagrams are not tree diagrams as follows:

      |  The diagram = above uses syntax that is similar to but not
    =   |  defined in [RFC8340].



Section 2.1.3.3 - 2.1.3.6:

" = offer an option as to if an asymmetric key is defined" - personally, I = would say "as to whether".  I don't know if the RFC-Editor (and rfc = style guide) care.

Fixed =E2=80=94> replaced all "as to if=E2=80=9D = strings to =E2=80=9Cfor whether=E2=80=9D - better?


"augmented in if, e.g.," - I = actually thought this was an editing error, until heard "augment in" = used as a word in the IETF session.  Web search shows "augment in" = is a term of art in netconf!  But some uses add a hyphen, which I = think is a good idea.

Added to the new =E2=80=9CTerminology=E2=80=9D = section:

=E2=80=9C=E2=80=9D=E2=80=9D
The sentence fragments "augmented" and "augmented in" = are used herein as the verbified form of the = "augment" statement defined in = <relref section=3D"7.17" target=3D"RFC7950"/>.
=E2= =80=9C"=E2=80=9D



    reference a = asymmetric key in an alternate location.

a = asymmetric -> an asymmetric.  A global change might be good, as = well as changing "an symmetric" to "a symmetric".

Both fixed = - thanks!


Section = 2.1.3.4

 *  For the = "local-definition" option, the defintion uses the
=     "asymmetric-key-pair-grouping" grouping = discussed in
    Section 2.1.3.4 of = [I-D.ietf-netconf-crypto-types].

It looks = to me like it is actually Section 2.1.4.4 of = [I-D.ietf-netconf-crypto-types].

Fixed! =  =E2=80=9C2.1.3.4=E2=80=9D -> =E2=80=9C2.1.4.5"

This is one issue with the new =E2=80=9Crelref=E2=80= =9D element in the xml2rfc v3 syntax, a section number (e.g., = =E2=80=9C2.1.3.4=E2=80=9D) has to be hardcoded, there=E2=80=99s no = option to use the =E2=80=9Canchor=E2=80=9D value, so misalignments may = occur unknowingly.



Section 2.1.3.7 p 11

 *  The "keystore-grouping" grouping is defines a = keystore instance as

"is defines" -> = "defines"

Fixed


 * =  For asymmetric keys, each "asymmetric-key" uses the = "asymmetric-
=     key-pair-with-certs-grouping" grouping discussed = Section 2.1.3.10
    of = [I-D.ietf-netconf-crypto-types].

"discussed" = -> "discussed in"

Quite right, and I found another like it, fixed = both.


Why do none of = the asymmetric keys here use a grouping that is the key only, like the = ct:asymmetric-key-pair-grouping used in Sectoin 2.1.3.4 of this document = (discussed in 2.1.4.4 of [I-D.ietf-netconf-crypto-types]).

      | =     |     +--rw = encrypted-private-key
=       |     | =        +--rw encrypted-by
      | =     |        | =  +--rw (encrypted-by-choice)
=       |     | =        | =     +--:(symmetric-key-ref)
=       |     | =        |     | =  +--rw symmetric-key-ref?    leafref
=       |     | =        | =     +--:(asymmetric-key-ref)
=       |     | =        | =        +--rw asymmetric-key-ref? =   leafref

The = section you quoted is for the = "encrypted-private-key=E2=80=9D case of a =E2=80=9Cchoice" = statement called "private-key-type=E2=80=9D.  This =E2=80=9Cchoice=E2=80=9D also = supports "cleartext-private-key=E2=80=9D, that is the raw key only, = is that what you mean?


Section 2.2.1 p 13

 The = following example illustrates keys in <running>.

Like I said before, maybe a citation of RFC8340 here.

The new = Terminology section defines =E2=80=9C<running>" = (and =E2=80=9C<operational>) pointing to RFC8342 (NMDA). =  [PS: RFC 8340 is for =E2=80=9CTree Diagrams=E2=80=9D]


Section 2.2.3 p 17 has the = phrase "following non-normative ".  Does that belong here?  Or = because this is XML, it can not be confused to be a normantive Yang = module?

It was/is a little bit of everything   = \_o_/

I created a new = introduction:

= <t>These examples assume the existence of = an example
 module called = "ex-keystore-usage=E2=80=9D having the namespace
 "http://example.com/ns/example-keystore-usage".</t>

And then changed the line as = follows:

OLD:
  =           <t>The following = non-normative module is defined to illustrate these
            =   groupings:</t>
NEW:
  =           <t>Following is the = "ex-keystore-usage" module's YANG definition: 


=       <symmetric-key>
=      <encrypted-by>
=             &n= bsp; <asymmetric-key-ref>hidden-asymmetric-key</asymmetric-k= \
 ey-ref>
=             &l= t;/encrypted-by>

The = "hidden-asymmetric-key" key appears later in the asymmetric-keys part of = the keystore example on p15.  I don't know how to prevent that = forward sort of reference for the readers, or if it is a problem.

This = is not a problem, as ordering doesn=E2=80=99t = matter with YANG-defined models.  


Section 2.2.3 p 18

     list end-entity-cert-with-key = {
       key name;
       ...
=        uses = ks:local-or-keystore-end-entity-cert-with-key-grouping;
=        description
=          "An end-entity = certificate, and its associated private key,
=           that may be = configured locally or be a reference to a
=           specific = certificate (and its associated private key) in
=           the = keystore.";

You can't rely on descriptions, = but I see no explicit reference to the private key in that end-entity = cert grouping.  That grouping is defined in Section 2.1.3.6 p 9, = and the keystore-reference is an = asymmetric-key-certificate-ref-grouping.  That grouping has an = asymmetric-key-ref and a cert.  The description above says "and its = associated private key".  So is the asymmetric-key-ref a ref to the = private key or to a key pair?

Fixed. =  =E2=80=9Cassociated private key=E2=80=9D -> "associated = asymmetric key"

      =   "An end-entity certificate and its = associated asymmetric
        =  key, that may be configured locally or be a reference
         to another = certificate (and its associated asymmetric
  =        key) in the keystore.=E2=80=9D;



Section 2.3 p 25

=    typedef symmetric-key-ref {
=      type leafref {
=        path = "/ks:keystore/ks:symmetric-keys/ks:symmetric-key"
=           + = "/ks:name";
     }

Does default-deny-write belong here, or added = each time an item is defined of this type?

No, because it is a typedef, and = typedefs don=E2=80=99t support extensions (search RFC 7950 for "typedef-stmt=E2=80=9D and "extension-stmt=E2=80=9D).


Section 2.3 p 26

=        case asymmetric-key-ref {
         leaf = asymmetric-key-ref {
=            type = leafref {
=             &n= bsp;path "/ks:keystore/ks:asymmetric-keys/"
=             &n= bsp;     + "ks:asymmetric-key/ks:name";
=            }
=            descript= ion
=             "I= dentifies the asymmetric key used to encrypt this key.";
=          }

(a) "the asymmetric key used to encrypt" - the public key = part is used to encrypt, so is the asymmetric key just the public key or = a key-pair where the appropriate part of the key-pair is used according = to context?

OLD:
          =   "Identifies the asymmetric key used to encrypt this key.";
NEW:
          =  "Identifies the asymmetric key whose public key
    =         encrypted the = associated key.";


(b) "encrypt this key" - The "this key" part is appropriate = if the assymmetric-key-ref is being used in an encrypted-by-choice = structure, but there are lots of places in this text where the type is = not in such a structure.  Is it the case that the uses always = resolve to be encrypting a key?

Right, = per above, now "the associated key=E2=80= =9D and the =E2=80=9Cdescription" statement = for "encrypted-by-choice-grouping=E2=80=9D now = says:

    =   "A grouping that defines a choice that can be augmented = into
       the 'encrypted-by' node = presented by the 'symmetric-key-grouping'
  =      and the 'asymmetric-key-pair-grouping' = groupings defined in
       RFC = AAAA.=E2=80=9D;

Indicating that = the =E2=80=9Cassociated key=E2=80=9D is defined in those two = groupings.  Good enough?


(c) "encrypt" - Is it always = the case that asymmetric keys in the keystore will be used to encrypt = something?  There is no expectation that the asymmetric key-pair = will be used to sign something?

An = asymmetric-key may be used to sign something, but this module has no = need to do that.  For instance, the module doesn=E2=80=99t support = the notion of a =E2=80=9Csigned key=E2=80=9D (a la =E2=80=9Cencrypted = key=E2=80=9D), beyond its support for certificates.  This doesn=E2=80= =99t preclude a consuming application from using an asymmetric key to = sign data if needed.


Section 2.3 = p27

=      description
=        "A grouping that expands to = allow the symmetric key to be
=         either stored locally, = within the using data model, or be
=         a reference to a = symmetric key stored in the Keystore.";

The = following is wordsmithing the description text, so a very-nitty-nit.

", or be" -> ", or"  (the "be" is = before the "either", don't need it)

A = reader might be confused as to whether the disjunction was two disjuncts = or three.

Fixed, in all four places where =E2=80=9Cor be=E2=80= =9D was being used.


I might suggest using "i.e., within the using data store". =  Maybe also
move the "be" inside the "either or" for = scoping
       "A = grouping that expands to allow the symmetric key to either
=         be stored locally, i.e., = within the using data model, or be
=         a reference to a = symmetric key stored in the Keystore.";

Added = =E2=80=9Ci.e.,=E2=80=9D

The groupings = in this section have a descriptoin of the grouping, a description of the = key case and a description of the choice.  I thought it worked = better to place the description of the choice closer to the "choice = local or keystore" rather than at the end.

Moved = all =E2=80=9Cchoice=E2=80=9D statement descriptions be before the = =E2=80=9Ccase=E2=80=9D statements.


And finally. Descriptions very frequently (always?) conclude = with a "." but they are very frequently not sentences, so the "." is not = necessary.  I do not know if the RFC-Editor or the Style manual = cares.

The descriptions should be sentences.  I = found only two instances that were missing an opening article (=E2=80=98A=E2= =80=99), which gave the appearance of not being a sentence=E2=80=A6but = you said there were =E2=80=9Cmany"?


Section 2.3 p 28

=    grouping = local-or-keystore-asymmetric-key-with-certs-grouping
=    ...
=       case keystore {
=          if-feature = "keystore-supported";
=          leaf = keystore-reference {
=            type = ks:asymmetric-key-ref;
=            descript= ion
=             &n= bsp;"A reference to an asymmetric-key (and all of its
=             &n= bsp; associated certificates) in the Keystore.";

An example of my puzzle about the = local-or-keystore-asymmetric-key-with-certs-grouping keystore-reference. =  How are the certs to be found if the keystore-reference is to the = asymmetric key only?  Or must the asymmetric-key-ref sometimes = point just to a key and sometimes to a key+certs, as needed?

An = asymmetric key "in the Keystore=E2=80=9D always allows certs to be = associated.  I understand that this isn=E2=80=99t true for = asymmetric keys in general.



Section 3 p 31

=  In some implementations, a server may support built-in keys. =  Built-
 in built-in keys

"Built-in built-in" =3D> "Built-in"

Fixed = - redundancy removed.


Section 3 p 32

 In order = for the built-in keys (and/or their associated built-in
=  certificates) to be referenced by configuration, the referenced = keys
 MUST first be copied into <running>. The = keys SHOULD be copied into
 <running> using the same "key" = values, so that the server can bind
 the references = to the built-in entries.

=  Built-in "hidden" keys cannot be copied into other parts of the
 configuration because their private parts are hidden, = and therefore
 impossible to replicate.

Section 4 p34 says built-in keys MUST be = hidden.  So they must be copied to <running> but they can't = be copied? Huh?


OLD:
      =   <t>Built-in "hidden" keys cannot be copied = into other parts of the 
      =     configuration because their private parts = are hidden, and therefore
        =   impossible to replicate.  Built-in = "encrypted" keys MAY be copied
      =     into other parts of the configuration so long = as they maintain their
        =   reference to the other built-in key that encrypted = them.</t>
NEW:
    =     <t>In addition to copying keys into the = Keystore in &lt;running&gt;, 
  =         cleartext and encrypted keys may be = copied into other parts of 
      =     configuration, but they will lose = their connection to having been
      =     a built-in value.  Note that hidden keys = cannot be copied into
        =   other parts of the configuration because doing would = lose the key's
        =   connection to the built-in key, where the key's secret = value is 
        =   stored.  Built-in "encrypted" keys MAY be = copied into other parts 
      =     of the configuration so long as the reference = to the other built-in 
      =     key that encrypted them is maintained.</t>



The keys SHOULD be = copied into
 <running> using the same "key" values, so that = the server can bind
 the references to the built-in = entries.

The word "key" is overloaded = in this document, like "The key characteristic of the built-in keys" and = "Key Words".  Here, the reference is surely to a required part of = the "list" syntax, so no way to use a different word.  Maybe say = 'the same list "key" values' or 'the same values for the list "key" = field/node'.

Changed "Key characteristic" to "primary = characteristic=E2=80=9D.

"Key = words=E2=80=9D is RFC 2119 language that cannot be altered.

OLD:
      =     The keys SHOULD be copied into
        =   <running> using the same "key" values, so that = the server can bind
        =   the references to the built-in entries.
NEW:
          The = keys SHOULD be copied
        =   into &lt;running&gt; using the same value = for the list's "key" 
      =     substatement, so that the server can bind = the references to the
        =   built-in entries.


   =          =     Built-in "encrypted" keys MAY be copied
 into other parts of the configuration so long as they = maintain their
 reference to the other built-in key = that encrypted them.

(a) Section 4 p34 says = "built-in keys MUST be hidden", so is there a way the hidden built-in = keys can be encrypted keys?

Under = the hood, it is possible that a hidden key is encrypted, but if it is, = that information would be hidden too ;)

(b) So encrypted built-in keys must always be encrypted by = other built-in keys?  Is there a way to represent that in the data = model?  (I explored this before.)

=  <running> MAY be a subset of the built-in keys define in = <operational>

"define" -> = "defined"

FIXED.



 Only the referenced keys need to be = copied; that is, the keys in
 <running> MAY be = a subset of the built-in keys define in
=  <operational>.  No keys may be added or changed (with = exception to
 associating additional certificates to = a built-in key); that is, the
 keys in = <running> MUST be a subset (which includes the whole of the
 set) of the built-in keys define in = <operational>.

I don't understatnd = this part.  First it says

"keys in = <running> MAY be a subset of the built-in keys define in = <operational>"

and then

"keys in <running> MUST be a subset ... = of the built-in keys define in <operational>".

That is inconsistent, is it intended?

Does the last sentence mean that if there are built-in keys, = no other keys may be added to the keystore?  I don't know what is = intended here.

Removed the = last part: i.e., =E2=80=9Cthe keys in <running> MUST be a subset = (which includes the whole of the set) of the built-in keys define in = <operational>."

NEW:
      =   <t>Only the referenced keys need to be = copied; that is, the keys
        =   in &lt;running&gt; MAY be a subset, = including the whole of the set, 
    =       of the built-in keys defined = in &lt;operational&gt;.</t>  
        <t>No new built-in = keys may be added nor existing built-in changed, 
          with exception to = associating additional certificates to an 
  =         existing built-in key.</t>


About "exception to" - I use "exeption to <rule>" and = "exception for <a special case>".  I don't know if the = RFC-Editor or the Style manual cares.

=E2=80=9Cexc= eption to=E2=80=9D =E2=80=94> =E2=80=9Cexception for=E2=80=9D

Section 4.1 p34

=  not support hidden keys, then the private data part of key MUST be =

"of key" -> "of the root key"

This = sentence no longer exists after the rewrite of the section addressing = the comment from Magnus.


Section 4.1 p35

=             &n= bsp;If the hidden root key is asymmetric, then the server
=  SHOULD provide APIs enabling other keys to be both generated = and
 encrypted by it

The = "both generated and encrypted by it" sounds like keys are being = generated by the root key.  I don't think that's generally true. =  Section 4.2 separates key generation and key encryption steps. =  I think this should be clearer.

(The = mention of other crypto services moved to area before nits.)

After = addressing the comment from Magnus, the new text is:

      =     <t>Implementations SHOULD provide an API = that simultaneously generates
      =       and encrypts a key (symmetric or = asymmetric) using a KEK.  Thusly
  =           newly generated key cleartext = values are never known to the
      =       administrators generating the = keys.</t>

Better?


Section 4.2 p35

(A discussion of = issues, not nits, was moved to area before nits.)

Section 4.3 p35

(A discussion of = issues, not nits, was moved to area before nits.)  
Section 5.2 p38

(A discussion = of issues, not nits, was moved to area before nits.)

Okay.




    |  Please be = aware that this module uses the "key" and "private-
=     |  key" nodes from the "ietf-crypto-types" = module
    | =  [I-D.ietf-netconf-crypto-types], where said nodes have the NACM
    |  extension "default-deny-all" = set, thus preventing unrestricted
=     |  read-access to the cleartext key = values.

This text missed the change A.19 to = add a "cleartext" prefix as in ietf-netconf-crypto-types.  The = "cleartext" prefix is present in the modules, tree-diagrams, XML, etc., = but the references in text here did not change.  (Actually, I see = several examples in the text in ietf-netconf-crypto-types where the = change was not made, e.g. p 9 says  '-  The "key" node can = encode any plain-text key value.' where the preceding tree diagram has a = node named "cleartext-key" and older versions said "key".)  I = appreciate the discussion of the default-deny-all in Section 3.5 p42 of = ietf-netconf-crypto-types and I think that a citation here would be = warranted and useful.

Fixed: prefixed =E2=80=9Ccleartext-=E2=80=9C

NEW:
        =     <t>Please be aware that this module uses = the "cleartext-key" and 
        =       "cleartext-private-key" nodes from the = "ietf-crypto-types" module 
        =       = <xref target=3D"I-D.ietf-netconf-crypto-types"/>, where = said nodes
              = have the NACM extension "default-deny-all" set, = thus preventing
            =   uncontrolled read-access to the cleartext key = values.</t>

Also fixed a number of = missing =E2=80=9Ccleartext-=E2=80=9C prefixes in the crypto-types = draft.


BTW.  I = don't know the NACM well but could it be said that the default-deny-all = prevents uncontrolled access, but does not necessarily prevent = unrestricted access, because a present but careless access control might = not actually restrict access?

Fixed. =  See =E2=80=9Cuncontrolled=E2=80=9D the the NEW = above.


Section 6.2 p = 39

"the the" -> "the"

Fixed = (in other documents also) - thanks!

Section 7.2 = p40

The list of Informative References = includes:

=  [I-D.ietf-netconf-keystore]
=             Wa= tsen, K., "A YANG Data Model for a Keystore", Work in
=             Pr= ogress, Internet-Draft, draft-ietf-netconf-keystore-17,
=             20= May 2020, <https://tools.ietf.org/html/draft-ietf-
=             ne= tconf-keystore-17>.

Isn't this a self = reference to an earlier version?

Note: ID = nits gives 11 warnings, but all are due to references to older versions = of existing drafts or to future versions not yet published.  The = latter case seems to be wrong, and the warning usually notes
   (However, the state information for = draft-ietf-netconf-keystore is not
=    up-to-date.  The last update was unsuccessful)

I have no idea what that means.  The = warnings are consistent, so may be something to watch.

Generally speaking, a document should not = reference itself!  The self-reference in this document is coming = from Section 1.1 (Relation to other RFCs).  The XML feeding this = section is from a common snippet of xml2rfc XML that is stitched into = the same spot for each of the documents in the collection of RFCs-to-be, = per the "Relation to other RFCs=E2=80=9D section.   My choices = are:

1) Copy-paste the common-text = into each document and then customize it by converting the = self-reference to something like =E2=80=9C<this document>=E2=80=9D, = and the remove the reference from the "Informative References=E2=80=9D = section.

or

2) Add an = RFC-editor note requesting that customization be made for each document = in the collection.

Thoughts?


K.


=E2=80=94Sandy

= --Apple-Mail=_0348A326-1A9C-4C92-A178-9883E263A74F-- From nobody Wed Aug 26 01:17:59 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF833A0F3D for ; Wed, 26 Aug 2020 01:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoEt6c06d5Mv for ; Wed, 26 Aug 2020 01:17:55 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4433A1036 for ; Wed, 26 Aug 2020 01:17:55 -0700 (PDT) Received: from lhreml714-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 94BFC62C80A490073BBB for ; Wed, 26 Aug 2020 09:17:53 +0100 (IST) Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by lhreml714-chm.china.huawei.com (10.201.108.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 26 Aug 2020 09:17:52 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 26 Aug 2020 16:17:50 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Wed, 26 Aug 2020 16:17:50 +0800 From: Tianran Zhou To: Andy Bierman , "Rob Wilton (rwilton)" CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif Thread-Index: AQHWa3XJ0mBLbRaES02VUjy2aRVTDKkskgcAgBDbzICAAJAcAIAMIxLg Date: Wed, 26 Aug 2020 08:17:50 +0000 Message-ID: References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.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.108.243.128] Content-Type: multipart/alternative; boundary="_000_c5e76be5eec9490fb6d5246de0ad01b1huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 08:17:58 -0000 --_000_c5e76be5eec9490fb6d5246de0ad01b1huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNClRpYW5yYW4NCg0KRnJvbTogbmV0Y29u ZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHkgQmll cm1hbg0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTksIDIwMjAgNjoxOCBBTQ0KVG86IFJvYiBX aWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPg0KQ2M6 IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFi aWxpdHkgZm9yIGRyYWZ0LXVueXRlLW5ldGNvbmYtdWRwLW5vdGlmDQoNCg0KDQpPbiBUdWUsIEF1 ZyAxOCwgMjAyMCBhdCA2OjQyIEFNIFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uPTQwY2lz Y28uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4+ IHdyb3RlOg0KSGksDQoNCltBbHNvIGFzIGEgY29udHJpYnV0b3JdDQoNCk15IGNvbW1lbnRzIGFy ZSBicm9hZGx5IHNpbWlsYXIgdG8gS2VudOKAmXMuDQoNCkkgYmVsaWV2ZSB0aGF0IGEgVURQIHRy YW5zcG9ydCBmb3IgZGF0YXBsYW5lIHRlbGVtZXRyeSB3aGVyZSBnZXR0aW5nIGFjY3VyYXRlIGZy ZXNoIGRhdGEgcXVpY2tseSBpcyBtb3JlIGltcG9ydGFudCB0aGFuIGdldHRpbmcgZXZlcnkgdXBk YXRlLiAgVGhpcyBpcyBwYXJ0aWN1bGFybHkgdHJ1ZSBpZiBhIHN1YnNlcXVlbnQgbm90aWZpY2F0 aW9uIHdpbGwgY292ZXIgYW55IGxvc3QgdmFsdWVzIGFueXdheSAoZS5nLiBwZXJpb2RpYyBzdGF0 aXN0aWNzKS4NCg0KDQphZ3JlZWQuDQpUaGVyZSBpcyBhbHNvIHRoZSByZXN5bmMtc3Vic2NyaXB0 aW9uIG1lY2hhbmlzbSB0byBoZWxwIHJlY292ZXIgZnJvbSBtaXNzaW5nIGRhdGEuDQoNClt6dHJd IE91ciBpbnRlbnRpb24gb2YgdXNpbmcgVURQIGlzIGZvciBkYXRhIHRoYXQgZG8gbm90IGNhcmUg YWJvdXQgb2NjYXNpb25hbCBsb3NzLiBUeXBpY2FsbHkgZm9yIHBlcmlvZCBkYXRhLCBhbmQgbmV3 IGRhdGEgd2lsbCBhbnl3YXkgY2FtZSBhbmQgdXBkYXRlLg0KRG9lcyB0aGUg4oCccmVzeW5jLXN1 YnNjcmlwdGlvbuKAnSBtZWFuIHRoZSByZXRyYW5zbWlzc2lvbj8gSGVyZSBkbyB5b3Ugd2FudCB0 byBhZGQgdGhlIOKAnHJlc3luYy1zdWJzY3JpcHRpb24gbWVjaGFuaXNt4oCdIHdoZW4gcGFja2V0 IGxvc3MgaXMgZGV0ZWN0ZWQgaW4gdGhpcyBkcmFmdD8NCg0KDQoNCkkgc3VzcGVjdCB0aGF0IGhh dmluZyBhIG1lY2hhbmlzbSB0byBhbGxvdyBmb3IgdGhlIHRlbGVtZXRyeSBkYXRhIGJlaW5nIGVu Y3J5cHRlZCBpcyBwcm9iYWJseSBhbHNvIGltcG9ydGFudC4gIElmIHRoZSBXRyB3ZXJlIHRvIGFk b3B0IGEgZHJhZnQgd2l0aG91dCB0aGlzLCB0aGVuIGFzIEJlbm9pdCBtZW50aW9uZWQsIEkgd291 bGQgaGF2ZSB0byB0ZXN0IHRoZSB3YXRlciB3aXRoIHRoZSBJRVNHIHRvIGRldGVybWluZSB3aGV0 aGVyIHRoYXQgd291bGQgYmUgYWNjZXB0YWJsZS4NCg0KSSBzdXNwZWN0IHRoZSBsYWNrIG9mIGNv bmdlc3Rpb24gY29udHJvbCBtaWdodCBnZXQgdGhlaXIgYXR0ZW50aW9uIGFzIHdlbGwuDQoNClt6 dHJdIFllcywgSSBhZ3JlZSwgYm90aCBzZWN1cml0eSBhbmQgY29uZ2VzdGlvbiBjb25zaWRlcmF0 aW9ucyBuZWVkIHRvIGJlIGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQuIFdlIGhhdmUgc2VjdGlv biA0IGZvciBjb25nZXN0aW9uIGNvbnRyb2wuIERvIHlvdSBoYXZlIGFueSBpZGVhIG9uIHRoaXM/ DQoNCkkgYWxzbyBub3RlIHRoYXQgdGhlIGRyYWZ0IGFsbG93cyBmb3IgYSBHUEIgZW5jb2Rpbmcg b2YgdGhlIHRlbGVtZXRyeSBkYXRhLCBidXQgSeKAmW0gbm90IGF3YXJlIG9mIGFueSBmb3JtYWwg c3RhbmRhcmQgZW5jb2Rpbmcgb2YgWUFORyBkYXRhIGluIEdQQiwgYW5kIHRoZXJlIGlzIGEgY2hv aWNlIGJldHdlZW4gd2hldGhlciB0aGUgR1BCIGVuY29kaW5nIGlzIGdlbmVyaWMgZm9yIGFsbCBZ QU5HIGRhdGEsIG9yIHNwZWNpZmljIEdQQiBlbmNvZGluZ3MgYXJlIHVzZWZ1bCBmb3IgdGhlIHNw ZWNpZmljIGRhdGEgdGhhdCBpcyBiZWluZyBlbmNvZGVkLg0KDQoNCg0KSSB3YXMgY29uZnVzZWQg YnkgdGhlIHNhbWUgdGhpbmcuDQpJcyB0aGVyZSBhIFlBTkcgc2NoZW1hIGZvciBhIG5vdGlmaWNh dGlvbiBlbGVtZW50IHRoYXQgaXMgdXNlZD8NCldoaWNoIG1lYW5zIHRoZSAucHJvdG8gZmlsZSBp cyBoYXJkd2lyZWQ/DQpJZiBub3QgdGhlbiBob3cgZG9lcyB0aGUgcmVjZWl2ZXIga25vdyB3aGF0 IGlzIHNlbnQ/DQpUaGVyZSBhcmUgc29tZSB0ZWNobmljYWwgaXNzdWVzIHRoYXQgY2FuIGJlIGFk ZHJlc3NlZCBpZiB0aGUgZHJhZnQgaXMgYWRvcHRlZC4NCg0KW3p0cl0gSW4gdGhpcyBkcmFmdCB3 ZSBvbmx5IGNvbnNpZGVyIHRvIGluY2x1ZGUgYSBjb2RlIHBvaW50IHRvIGluZGljYXRlIHRoZSBH UEIgZW5jb2RpbmcuIEhvdyB0byBtYXAgWUFORyB0byBHUEIgaXMgb3V0IG9mIHRoZSBzY29wZSBv ZiB0aGlzIGRyYWZ0Lg0KSW4gcHJhY3RpY2UsIHRoZXJlIGFyZSBzZXZlcmFsIHdheXMgaW4gbXkg b3Bpbmlvbi4NCldlIGNhbiBtYXAgWUFORyB0byBwcm90byBmaXJzdGx5LCBhbmQgdGhlIHByb3Rv IGFjdHVhbGx5IGRlc2NyaWJlcyB0aGUgZGF0YSBzdHJ1Y3R1cmUuIEkgdGhpbmsgWUFORyBjYW4g YWxtb3N0IHRyYW5zbGF0ZSB0byBwcm90byAxOjEuDQpXZSBjYW4gYWxzbyBkZXZlbG9wIFlBTkcg dG8gR1BCIGRpcmVjdGx5LCBqdXN0IGxpa2UgWUFORyB0byBYTUwgYW5kIEpTT04uDQpJbiBicmll ZiwgdGhlIHJlY2VpdmVyIGNhbiBzdGlsbCBrbm93IHdoYXQgaXMgc2VudCBieSBZQU5HLg0KDQoN Cg0KUmVnYXJkcywNClJvYg0KDQoNCkFuZHkNCg0KDQpGcm9tOiBuZXRjb25mIDxuZXRjb25mLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFs ZiBPZiBLZW50IFdhdHNlbg0KU2VudDogMDcgQXVndXN0IDIwMjAgMjE6MTYNClRvOiBuZXRjb25m QGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRjb25m XSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0Y29uZi11ZHAtbm90aWYN Cg0KW2FzIGEgY29udHJpYnV0b3JdDQoNCg0KICAgMSkgaXMgdGhlIHByb2JsZW0gaW1wb3J0YW50 IGZvciB0aGUgTkVUQ09ORiBXRyB0byBzb2x2ZT8NCg0KSSBiZWxpZXZlIHRoYXQgaXQgaXMgaW1w b3J0YW50IHRvIGVuYWJsZSBwdWJsaXNoZXJzIHRvIHNlbmQgbm90aWZpY2F0aW9ucyB1c2luZyBh IFVEUC1iYXNlZCB0cmFuc3BvcnQuICAgVGhpcyBiZWxpZWYgaXMgYmFzZWQgb24gbXkgZXhwZXJp ZW5jZSBmcm9tIHdoZW4gYXQgSnVuaXBlciBkZWFsaW5nIHdpdGggdmVyeSBoaWdoLWVuZCBmaXJl d2FsbHMgd2l0aCBlbm9ybW91cyBsb2cgb3V0cHV0Lg0KDQpJIGJlbGlldmUgdGhhdCB0aGUgTkVU Q09ORiBXRyBpcyB0aGUgYXBwcm9wcmlhdGUgV0cgZm9yIHRoaXMgd29yaywgaGF2aW5nIGRlZmlu ZWQgUkZDIDg2MzkgKFNOKSwgUkZDIDg2NDAgKE5OKSwgYW5kIFJGQyA4NjUwIChSTikuDQoNCg0K ICAgMikgaXMgdGhlIGRyYWZ0IGEgc3VpdGFibGUgYmFzaXMgZm9yIHRoZSB3b3JrPw0KDQpJIGhh dmUgcmVhZCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBhbmQgZmluZCBpdCB0byBi ZSBhIHJlYXNvbmFibGUgc3RhcnQuDQoNClByZXN1bWluZyB0aGUg4oCccmVjZWl2ZXItaW5zdGFu Y2Vz4oCdIGF1Z21lbnRhdGlvbiBkZWZpbmVkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYtMDQjc2VjdGlvbi0zIHRha2VzIG9mZiwg dGhlIG1vZHVsZSBkZWZpbmVkIGluIHRoaXMgZHJhZnQgc2hvdWxkIGJlIHVwZGF0ZWQgdG8gYXVn bWVudCBpbnRvIGl0IGluc3RlYWQuDQoNCkkgYXBwcmVjaWF0ZSBTZWN0aW9uIDUgKEFwcGxpY2Fi aWxpdHkpIG5vdGluZyB0aGF0IHRoZSBVRFAtdHJhbnNwb3J0IGlzIHByaW1hcmlseSBmb3IgdGhl IGRhdGEgcGxhbmUgKG5vdCB0aGUgY29udHJvbCBwbGFuZSksIGFzIGl0IGRvZXNu4oCZdCBtYXR0 ZXIgc28gbXVjaCBpZiBkYXRhIHBsYW5lIG5vdGlmaWNhdGlvbnMgYXJlIGxvc3QuICBUaGlzIGFk ZHJlc3NlcyAoSSB0aGluaykgdGhlIGlzc3VlIHRoYXQgUm9iIFNoYWtpciByYWlzZWQgYmVmb3Jl OiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9taW51dGVzLTEwMy1uZXRjb25mIChz ZWFyY2ggZm9yIOKAnFJvYiBT4oCdKS4gIFRoYXQgc2FpZCwgaXQgaXMgdW5jbGVhciB0byBtZSBo b3cgYSByZWNlaXZlciBjb3VsZCBjb25maWd1cmUgdGhpcyB3aGlsZSwgZS5nLiwgY29uZmlndXJp bmcgY29udHJvbCBwbGFuZSBub3RpZmljYXRpb25zIHRvIGJlIHNlbnQgdmlhIGEgVENQLWJhc2Vk IHRyYW5zcG9ydCBzdWNoIGFzIOKAnGh0dHBzLW5vdGlm4oCdLg0KDQoNCjMpIHJlZ2FyZGluZyBK dWVyZ2Vu4oCZcyBxdWVzdGlvbnM6DQoNCiAgYSkgSSBhbSB3aWxsaW5nIHRvIHN1YnN0YW50aWFs bHkgcmV2aWV3IHRoZSBkcmFmdHMuDQogIGIpIEkgYW0gd2lsbGluZyB0byBjb250cmlidXRlIHRv IHRoZSBkaXNjdXNzaW9uIG9mIGFueSBpc3N1ZS4NCiAgYykgSSBkbyBOT1QgcGxhbiB0byBpbXBs ZW1lbnQgdGhlIHRlY2hub2xvZ3kgZGVmaW5lZC4NCg0KDQoNCktlbnQNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRjb25mIG1haWxpbmcgbGlzdA0K bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K --_000_c5e76be5eec9490fb6d5246de0ad01b1huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5I aSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGxlYXNl IHNlZSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5U aWFucmFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IG5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRu ZXNkYXksIEF1Z3VzdCAxOSwgMjAyMCA2OjE4IEFNPGJyPg0KPGI+VG86PC9iPiBSb2IgV2lsdG9u IChyd2lsdG9uKSAmbHQ7cndpbHRvbj00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+ DQo8Yj5DYzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtu ZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0Y29uZi11ZHAt bm90aWY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1 ZyAxOCwgMjAyMCBhdCA2OjQyIEFNIFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDtyd2lsdG9uPTxh IGhyZWY9Im1haWx0bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyI+NDBjaXNjby5jb21AZG1h cmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+W0Fsc28gYXMgYSBjb250cmlidXRvcl08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5NeSBjb21tZW50cyBhcmUgYnJvYWRseSBzaW1pbGFyIHRv IEtlbnTigJlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkkgYmVsaWV2ZSB0aGF0IGEgVURQIHRy YW5zcG9ydCBmb3IgZGF0YXBsYW5lIHRlbGVtZXRyeSB3aGVyZSBnZXR0aW5nIGFjY3VyYXRlIGZy ZXNoIGRhdGEgcXVpY2tseSBpcyBtb3JlIGltcG9ydGFudCB0aGFuIGdldHRpbmcgZXZlcnkgdXBk YXRlLiZuYnNwOyBUaGlzIGlzIHBhcnRpY3VsYXJseQ0KIHRydWUgaWYgYSBzdWJzZXF1ZW50IG5v dGlmaWNhdGlvbiB3aWxsIGNvdmVyIGFueSBsb3N0IHZhbHVlcyBhbnl3YXkgKGUuZy4gcGVyaW9k aWMgc3RhdGlzdGljcykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmFncmVlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZXJlIGlzIGFsc28gdGhlIHJlc3luYy1zdWJzY3JpcHRpb24gbWVjaGFuaXNtIHRvIGhl bHAgcmVjb3ZlciBmcm9tIG1pc3NpbmcgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5benRyXSBPdXIgaW50ZW50aW9uIG9mIHVzaW5n IFVEUCBpcyBmb3IgZGF0YSB0aGF0IGRvIG5vdCBjYXJlIGFib3V0IG9jY2FzaW9uYWwgbG9zcy4g VHlwaWNhbGx5IGZvciBwZXJpb2QgZGF0YSwgYW5kIG5ldyBkYXRhIHdpbGwgYW55d2F5IGNhbWUg YW5kIHVwZGF0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkRvZXMgdGhlIOKAnDwvc3Bhbj5yZXN5bmMtc3Vic2NyaXB0aW9uPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj7igJ0gbWVhbiB0aGUgcmV0cmFuc21pc3Npb24/IEhlcmUgZG8geW91IHdh bnQgdG8gYWRkIHRoZSDigJw8L3NwYW4+cmVzeW5jLXN1YnNjcmlwdGlvbg0KIG1lY2hhbmlzbTxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+4oCdIHdoZW4gcGFja2V0IGxvc3MgaXMgZGV0ZWN0ZWQgaW4gdGhpcyBk cmFmdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiI+SSBzdXNwZWN0IHRoYXQgaGF2aW5nIGEgbWVjaGFuaXNtIHRvIGFs bG93IGZvciB0aGUgdGVsZW1ldHJ5IGRhdGEgYmVpbmcgZW5jcnlwdGVkIGlzIHByb2JhYmx5IGFs c28gaW1wb3J0YW50LiZuYnNwOyBJZiB0aGUgV0cgd2VyZSB0byBhZG9wdCBhIGRyYWZ0IHdpdGhv dXQgdGhpcywgdGhlbg0KIGFzIEJlbm9pdCBtZW50aW9uZWQsIEkgd291bGQgaGF2ZSB0byB0ZXN0 IHRoZSB3YXRlciB3aXRoIHRoZSBJRVNHIHRvIGRldGVybWluZSB3aGV0aGVyIHRoYXQgd291bGQg YmUgYWNjZXB0YWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdXNwZWN0IHRoZSBs YWNrIG9mIGNvbmdlc3Rpb24gY29udHJvbCBtaWdodCBnZXQgdGhlaXIgYXR0ZW50aW9uIGFzIHdl bGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+W3p0cl0gWWVzLCBJIGFncmVlLCBib3RoIHNlY3VyaXR5IGFuZCBjb25nZXN0aW9uIGNvbnNp ZGVyYXRpb25zIG5lZWQgdG8gYmUgZGVzY3JpYmVkIGluIHRoZSBkb2N1bWVudC4gV2UgaGF2ZSBz ZWN0aW9uIDQgZm9yIGNvbmdlc3Rpb24gY29udHJvbC4gRG8geW91IGhhdmUgYW55IGlkZWEgb24g dGhpcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tR0IiPkkgYWxzbyBub3RlIHRoYXQgdGhlIGRyYWZ0IGFsbG93cyBmb3IgYSBHUEIgZW5jb2Rp bmcgb2YgdGhlIHRlbGVtZXRyeSBkYXRhLCBidXQgSeKAmW0gbm90IGF3YXJlIG9mIGFueSBmb3Jt YWwgc3RhbmRhcmQgZW5jb2Rpbmcgb2YgWUFORyBkYXRhIGluIEdQQiwgYW5kIHRoZXJlIGlzDQog YSBjaG9pY2UgYmV0d2VlbiB3aGV0aGVyIHRoZSBHUEIgZW5jb2RpbmcgaXMgZ2VuZXJpYyBmb3Ig YWxsIFlBTkcgZGF0YSwgb3Igc3BlY2lmaWMgR1BCIGVuY29kaW5ncyBhcmUgdXNlZnVsIGZvciB0 aGUgc3BlY2lmaWMgZGF0YSB0aGF0IGlzIGJlaW5nIGVuY29kZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgY29uZnVzZWQgYnkgdGhlIHNhbWUgdGhp bmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J cyB0aGVyZSBhIFlBTkcgc2NoZW1hIGZvciBhIG5vdGlmaWNhdGlvbiBlbGVtZW50IHRoYXQgaXMg dXNlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldoaWNoIG1lYW5zIHRoZSAucHJvdG8gZmlsZSBpcyBoYXJkd2lyZWQ/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBub3QgdGhlbiBob3cgZG9l cyB0aGUgcmVjZWl2ZXIga25vdyB3aGF0IGlzIHNlbnQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgc29tZSB0ZWNobmljYWwgaXNz dWVzIHRoYXQgY2FuIGJlIGFkZHJlc3NlZCBpZiB0aGUgZHJhZnQgaXMgYWRvcHRlZC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5benRyXSBJ biB0aGlzIGRyYWZ0IHdlIG9ubHkgY29uc2lkZXIgdG8gaW5jbHVkZSBhIGNvZGUgcG9pbnQgdG8g aW5kaWNhdGUgdGhlIEdQQiBlbmNvZGluZy4gSG93IHRvIG1hcCBZQU5HIHRvIEdQQiBpcyBvdXQg b2YgdGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JbiBwcmFjdGljZSwgdGhlcmUgYXJlIHNl dmVyYWwgd2F5cyBpbiBteSBvcGluaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2UgY2FuIG1hcCBZQU5HIHRvIHByb3RvIGZp cnN0bHksIGFuZCB0aGUgcHJvdG8gYWN0dWFsbHkgZGVzY3JpYmVzIHRoZSBkYXRhIHN0cnVjdHVy ZS4gSSB0aGluayBZQU5HIGNhbiBhbG1vc3QgdHJhbnNsYXRlIHRvIHByb3RvIDE6MS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldl IGNhbiBhbHNvIGRldmVsb3AgWUFORyB0byBHUEIgZGlyZWN0bHksIGp1c3QgbGlrZSBZQU5HIHRv IFhNTCBhbmQgSlNPTi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkluIGJyaWVmLCB0aGUgcmVjZWl2ZXIgY2FuIHN0aWxsIGtub3cg d2hhdCBpcyBzZW50IGJ5IFlBTkcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5SZWdhcmRzLDxicj4NClJvYjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBuZXRjb25mICZsdDs8YSBocmVmPSJtYWls dG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+S2VudCBXYXRzZW48YnI+ DQo8Yj5TZW50OjwvYj4gMDcgQXVndXN0IDIwMjAgMjE6MTY8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhy ZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29uZkBpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0 YWJpbGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0Y29uZi11ZHAtbm90aWY8c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5bYXMgYSBj b250cmlidXRvcl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7MSkgaXMgdGhlIHByb2JsZW0gaW1wb3J0YW50IGZvciB0aGUgTkVUQ09O RiBXRyB0byBzb2x2ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkkgYmVsaWV2ZSB0aGF0IGl0IGlzIGlt cG9ydGFudCB0byBlbmFibGUgcHVibGlzaGVycyB0byBzZW5kIG5vdGlmaWNhdGlvbnMgdXNpbmcg YSBVRFAtYmFzZWQgdHJhbnNwb3J0LiAmbmJzcDsgVGhpcyBiZWxpZWYgaXMgYmFzZWQgb24gbXkg ZXhwZXJpZW5jZSBmcm9tIHdoZW4gYXQgSnVuaXBlcg0KIGRlYWxpbmcgd2l0aCB2ZXJ5IGhpZ2gt ZW5kIGZpcmV3YWxscyB3aXRoIGVub3Jtb3VzIGxvZyBvdXRwdXQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5J IGJlbGlldmUgdGhhdCB0aGUmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPk5FVENPTkYg V0cgaXMgdGhlIGFwcHJvcHJpYXRlIFdHIGZvciB0aGlzIHdvcmssIGhhdmluZyBkZWZpbmVkIFJG QyA4NjM5IChTTiksJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SRkMNCiA4NjQwIChO TiksIGFuZCZuYnNwOzwvc3Bhbj5SRkMgODY1MCAoUk4pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZu YnNwOyZuYnNwOzIpIGlzIHRoZSBkcmFmdCBhIHN1aXRhYmxlIGJhc2lzIGZvciB0aGUgd29yaz88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiI+SSBoYXZlIHJlYWQgdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQg YW5kIGZpbmQgaXQgdG8gYmUgYSByZWFzb25hYmxlIHN0YXJ0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPlByZXN1bWluZyB0aGUg4oCccmVjZWl2 ZXItaW5zdGFuY2Vz4oCdIGF1Z21lbnRhdGlvbiBkZWZpbmVkIGluJm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0w NCNzZWN0aW9uLTMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmLTA0I3NlY3Rpb24tMzwvYT4mbmJzcDt0YWtl cw0KIG9mZiwgdGhlIG1vZHVsZSBkZWZpbmVkIGluIHRoaXMgZHJhZnQgc2hvdWxkIGJlIHVwZGF0 ZWQgdG8gYXVnbWVudCBpbnRvIGl0IGluc3RlYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+SSBh cHByZWNpYXRlIFNlY3Rpb24gNSAoQXBwbGljYWJpbGl0eSkgbm90aW5nIHRoYXQgdGhlIFVEUC10 cmFuc3BvcnQgaXMgcHJpbWFyaWx5IGZvciB0aGUgZGF0YSBwbGFuZSAobm90IHRoZSBjb250cm9s IHBsYW5lKSwgYXMgaXQgZG9lc27igJl0DQogbWF0dGVyIHNvIG11Y2ggaWYgZGF0YSBwbGFuZSBu b3RpZmljYXRpb25zIGFyZSBsb3N0LiZuYnNwOyBUaGlzIGFkZHJlc3NlcyAoSSB0aGluaykgdGhl IGlzc3VlIHRoYXQgUm9iIFNoYWtpciByYWlzZWQgYmVmb3JlOg0KPGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvbWludXRlcy0xMDMtbmV0Y29uZiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL21pbnV0ZXMtMTAzLW5ldGNvbmY8 L2E+Jm5ic3A7KHNlYXJjaCBmb3Ig4oCcUm9iIFPigJ0pLiZuYnNwOyBUaGF0IHNhaWQsIGl0IGlz IHVuY2xlYXIgdG8gbWUgaG93IGEgcmVjZWl2ZXIgY291bGQgY29uZmlndXJlIHRoaXMgd2hpbGUs IGUuZy4sIGNvbmZpZ3VyaW5nIGNvbnRyb2wNCiBwbGFuZSBub3RpZmljYXRpb25zIHRvIGJlIHNl bnQgdmlhIGEgVENQLWJhc2VkIHRyYW5zcG9ydCBzdWNoIGFzIOKAnGh0dHBzLW5vdGlm4oCdLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+ MykgcmVnYXJkaW5nIEp1ZXJnZW7igJlzIHF1ZXN0aW9uczo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyBhKSBJIGFtIHdpbGxpbmcgdG8gc3Vic3RhbnRpYWxseSByZXZpZXcg dGhlIGRyYWZ0cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IGIpIEkgYW0mbmJzcDt3aWxsaW5nIHRvIGNv bnRyaWJ1dGUgdG8gdGhlIGRpc2N1c3Npb24gb2YgYW55IGlzc3VlLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsgYykgSSBkbyBOT1QmbmJzcDtwbGFuIHRvIGltcGxlbWVudCB0aGUgdGVjaG5vbG9neSBkZWZp bmVkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImNvbG9yOmJsYWNrIj5LZW50PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KbmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_c5e76be5eec9490fb6d5246de0ad01b1huaweicom_-- From nobody Wed Aug 26 01:59:43 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0BA3A10D7 for ; Wed, 26 Aug 2020 01:59: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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_dD1NpyT-7e for ; Wed, 26 Aug 2020 01:59: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 DD6003A10D6 for ; Wed, 26 Aug 2020 01:59:36 -0700 (PDT) Received: from lhreml744-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E89D0FF164D3AA82C92C for ; Wed, 26 Aug 2020 09:59:34 +0100 (IST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 26 Aug 2020 09:59:33 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 26 Aug 2020 16:59:31 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Wed, 26 Aug 2020 16:59:31 +0800 From: Tianran Zhou To: "Rob Wilton (rwilton)" , Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif Thread-Index: AQHWa3XJ0mBLbRaES02VUjy2aRVTDKkskgcAgBDbzICADMHCoA== Date: Wed, 26 Aug 2020 08:59:31 +0000 Message-ID: References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.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.108.243.128] Content-Type: multipart/alternative; boundary="_000_c9aea6429c6c466d80d98899bf38b375huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 08:59:42 -0000 --_000_c9aea6429c6c466d80d98899bf38b375huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iLA0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KUGxlYXNlIHNlZSBpbiBsaW5lLg0K DQpUaWFucmFuDQpGcm9tOiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgUm9iIFdpbHRvbiAocndpbHRvbikNClNlbnQ6IFR1ZXNkYXksIEF1Z3Vz dCAxOCwgMjAyMCA5OjQzIFBNDQpUbzogS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0 PjsgbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0 YWJpbGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0Y29uZi11ZHAtbm90aWYNCg0KSGksDQoNCltBbHNv IGFzIGEgY29udHJpYnV0b3JdDQoNCk15IGNvbW1lbnRzIGFyZSBicm9hZGx5IHNpbWlsYXIgdG8g S2VudOKAmXMuDQoNCkkgYmVsaWV2ZSB0aGF0IGEgVURQIHRyYW5zcG9ydCBmb3IgZGF0YXBsYW5l IHRlbGVtZXRyeSB3aGVyZSBnZXR0aW5nIGFjY3VyYXRlIGZyZXNoIGRhdGEgcXVpY2tseSBpcyBt b3JlIGltcG9ydGFudCB0aGFuIGdldHRpbmcgZXZlcnkgdXBkYXRlLiAgVGhpcyBpcyBwYXJ0aWN1 bGFybHkgdHJ1ZSBpZiBhIHN1YnNlcXVlbnQgbm90aWZpY2F0aW9uIHdpbGwgY292ZXIgYW55IGxv c3QgdmFsdWVzIGFueXdheSAoZS5nLiBwZXJpb2RpYyBzdGF0aXN0aWNzKS4NCg0KW3p0cl0gWWVz LiBTbyB3ZSBkZXNjcmliZWQgdGhpcyBpbiBzZWN0aW9uIDUuIERvIHlvdSB3YW50IHRvIHByb3Bv c2UgbW9yZSB0ZXh0Pw0KDQpJIHN1c3BlY3QgdGhhdCBoYXZpbmcgYSBtZWNoYW5pc20gdG8gYWxs b3cgZm9yIHRoZSB0ZWxlbWV0cnkgZGF0YSBiZWluZyBlbmNyeXB0ZWQgaXMgcHJvYmFibHkgYWxz byBpbXBvcnRhbnQuICBJZiB0aGUgV0cgd2VyZSB0byBhZG9wdCBhIGRyYWZ0IHdpdGhvdXQgdGhp cywgdGhlbiBhcyBCZW5vaXQgbWVudGlvbmVkLCBJIHdvdWxkIGhhdmUgdG8gdGVzdCB0aGUgd2F0 ZXIgd2l0aCB0aGUgSUVTRyB0byBkZXRlcm1pbmUgd2hldGhlciB0aGF0IHdvdWxkIGJlIGFjY2Vw dGFibGUuDQoNClt6dHJdIFdlIHdpbGwgd29yayBvbiBhIGRyYWZ0IHRvIGRlc2NyaWJlIGFib3V0 IHRoZSBlbmNyeXB0aW9uLg0KDQpJIGFsc28gbm90ZSB0aGF0IHRoZSBkcmFmdCBhbGxvd3MgZm9y IGEgR1BCIGVuY29kaW5nIG9mIHRoZSB0ZWxlbWV0cnkgZGF0YSwgYnV0IEnigJltIG5vdCBhd2Fy ZSBvZiBhbnkgZm9ybWFsIHN0YW5kYXJkIGVuY29kaW5nIG9mIFlBTkcgZGF0YSBpbiBHUEIsIGFu ZCB0aGVyZSBpcyBhIGNob2ljZSBiZXR3ZWVuIHdoZXRoZXIgdGhlIEdQQiBlbmNvZGluZyBpcyBn ZW5lcmljIGZvciBhbGwgWUFORyBkYXRhLCBvciBzcGVjaWZpYyBHUEIgZW5jb2RpbmdzIGFyZSB1 c2VmdWwgZm9yIHRoZSBzcGVjaWZpYyBkYXRhIHRoYXQgaXMgYmVpbmcgZW5jb2RlZC4NCg0KW3p0 cl0gSnVzdCB0byBjbGFyaWZ5LCB0aGlzIGRyYWZ0IG9ubHkgY29uc2lkZXIgYSBjb2RlIHBvaW50 IHRvIGluZGljYXRlIHRoZSBHUEIgZW5jb2RpbmcuIFdpdGggdGhpcyBpbmRpY2F0aW9uLCB0aGUg cmVjZWl2ZXIga25vd3MgaG93IHRvIGRlY29kZSB0aGUgbWVzc2FnZS4gWUFORyB0byBHUEIgaXMg b3V0IG9mIHRoZSBzY29wZS4NCldoYXTigJlzIHlvdXIgc3VnZ2VzdGlvbj8gRG8geW91IHN1Z2dl c3QgdXMgbm90IHRvIGluY2x1ZGUgR1BCIGFzIGEgZW5jb2Rpbmc/DQoNClJlZ2FyZHMsDQpSb2IN Cg0KDQpGcm9tOiBuZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldGNv bmYtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBLZW50IFdhdHNlbg0KU2VudDogMDcg QXVndXN0IDIwMjAgMjE6MTYNClRvOiBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3Ig ZHJhZnQtdW55dGUtbmV0Y29uZi11ZHAtbm90aWYNCg0KW2FzIGEgY29udHJpYnV0b3JdDQoNCg0K ICAgMSkgaXMgdGhlIHByb2JsZW0gaW1wb3J0YW50IGZvciB0aGUgTkVUQ09ORiBXRyB0byBzb2x2 ZT8NCg0KSSBiZWxpZXZlIHRoYXQgaXQgaXMgaW1wb3J0YW50IHRvIGVuYWJsZSBwdWJsaXNoZXJz IHRvIHNlbmQgbm90aWZpY2F0aW9ucyB1c2luZyBhIFVEUC1iYXNlZCB0cmFuc3BvcnQuICAgVGhp cyBiZWxpZWYgaXMgYmFzZWQgb24gbXkgZXhwZXJpZW5jZSBmcm9tIHdoZW4gYXQgSnVuaXBlciBk ZWFsaW5nIHdpdGggdmVyeSBoaWdoLWVuZCBmaXJld2FsbHMgd2l0aCBlbm9ybW91cyBsb2cgb3V0 cHV0Lg0KDQpJIGJlbGlldmUgdGhhdCB0aGUgTkVUQ09ORiBXRyBpcyB0aGUgYXBwcm9wcmlhdGUg V0cgZm9yIHRoaXMgd29yaywgaGF2aW5nIGRlZmluZWQgUkZDIDg2MzkgKFNOKSwgUkZDIDg2NDAg KE5OKSwgYW5kIFJGQyA4NjUwIChSTikuDQoNCg0KICAgMikgaXMgdGhlIGRyYWZ0IGEgc3VpdGFi bGUgYmFzaXMgZm9yIHRoZSB3b3JrPw0KDQpJIGhhdmUgcmVhZCB0aGUgY3VycmVudCB2ZXJzaW9u IG9mIHRoZSBkcmFmdCBhbmQgZmluZCBpdCB0byBiZSBhIHJlYXNvbmFibGUgc3RhcnQuDQoNClBy ZXN1bWluZyB0aGUg4oCccmVjZWl2ZXItaW5zdGFuY2Vz4oCdIGF1Z21lbnRhdGlvbiBkZWZpbmVk IGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMt bm90aWYtMDQjc2VjdGlvbi0zIHRha2VzIG9mZiwgdGhlIG1vZHVsZSBkZWZpbmVkIGluIHRoaXMg ZHJhZnQgc2hvdWxkIGJlIHVwZGF0ZWQgdG8gYXVnbWVudCBpbnRvIGl0IGluc3RlYWQuDQoNCkkg YXBwcmVjaWF0ZSBTZWN0aW9uIDUgKEFwcGxpY2FiaWxpdHkpIG5vdGluZyB0aGF0IHRoZSBVRFAt dHJhbnNwb3J0IGlzIHByaW1hcmlseSBmb3IgdGhlIGRhdGEgcGxhbmUgKG5vdCB0aGUgY29udHJv bCBwbGFuZSksIGFzIGl0IGRvZXNu4oCZdCBtYXR0ZXIgc28gbXVjaCBpZiBkYXRhIHBsYW5lIG5v dGlmaWNhdGlvbnMgYXJlIGxvc3QuICBUaGlzIGFkZHJlc3NlcyAoSSB0aGluaykgdGhlIGlzc3Vl IHRoYXQgUm9iIFNoYWtpciByYWlzZWQgYmVmb3JlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9taW51dGVzLTEwMy1uZXRjb25mIChzZWFyY2ggZm9yIOKAnFJvYiBT4oCdKS4gIFRo YXQgc2FpZCwgaXQgaXMgdW5jbGVhciB0byBtZSBob3cgYSByZWNlaXZlciBjb3VsZCBjb25maWd1 cmUgdGhpcyB3aGlsZSwgZS5nLiwgY29uZmlndXJpbmcgY29udHJvbCBwbGFuZSBub3RpZmljYXRp b25zIHRvIGJlIHNlbnQgdmlhIGEgVENQLWJhc2VkIHRyYW5zcG9ydCBzdWNoIGFzIOKAnGh0dHBz LW5vdGlm4oCdLg0KDQoNCjMpIHJlZ2FyZGluZyBKdWVyZ2Vu4oCZcyBxdWVzdGlvbnM6DQoNCiAg YSkgSSBhbSB3aWxsaW5nIHRvIHN1YnN0YW50aWFsbHkgcmV2aWV3IHRoZSBkcmFmdHMuDQogIGIp IEkgYW0gd2lsbGluZyB0byBjb250cmlidXRlIHRvIHRoZSBkaXNjdXNzaW9uIG9mIGFueSBpc3N1 ZS4NCiAgYykgSSBkbyBOT1QgcGxhbiB0byBpbXBsZW1lbnQgdGhlIHRlY2hub2xvZ3kgZGVmaW5l ZC4NCg0KDQoNCktlbnQNCg== --_000_c9aea6429c6c466d80d98899bf38b375huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBSb2IsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRo YW5rcyBmb3IgeW91ciBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UGxlYXNlIHNlZSBpbiBsaW5l LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGlhbnJhbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0Bp ZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+Um9iIFdpbHRvbiAocndpbHRvbik8YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDE4LCAyMDIwIDk6NDMgUE08YnI+DQo8Yj5Ubzo8 L2I+IEtlbnQgV2F0c2VuICZsdDtrZW50JiM0MztpZXRmQHdhdHNlbi5uZXQmZ3Q7OyBuZXRjb25m QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24tc3Vp dGFiaWxpdHkgZm9yIGRyYWZ0LXVueXRlLW5ldGNvbmYtdWRwLW5vdGlmPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5bQWxzbyBhcyBhIGNvbnRyaWJ1dG9yXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pk15IGNvbW1lbnRzIGFyZSBicm9hZGx5IHNpbWlsYXIgdG8gS2VudOKAmXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBiZWxpZXZlIHRoYXQgYSBVRFAgdHJhbnNwb3J0IGZvciBk YXRhcGxhbmUgdGVsZW1ldHJ5IHdoZXJlIGdldHRpbmcgYWNjdXJhdGUgZnJlc2ggZGF0YSBxdWlj a2x5IGlzIG1vcmUgaW1wb3J0YW50IHRoYW4gZ2V0dGluZyBldmVyeSB1cGRhdGUuJm5ic3A7IFRo aXMgaXMgcGFydGljdWxhcmx5IHRydWUgaWYgYSBzdWJzZXF1ZW50DQogbm90aWZpY2F0aW9uIHdp bGwgY292ZXIgYW55IGxvc3QgdmFsdWVzIGFueXdheSAoZS5nLiBwZXJpb2RpYyBzdGF0aXN0aWNz KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+W3p0cl0gWWVzLiBTbyB3ZSBkZXNjcmliZWQgdGhpcyBpbiBzZWN0aW9uIDUuIERvIHlv dSB3YW50IHRvIHByb3Bvc2UgbW9yZSB0ZXh0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+SSBzdXNwZWN0IHRoYXQgaGF2aW5nIGEgbWVjaGFuaXNtIHRvIGFs bG93IGZvciB0aGUgdGVsZW1ldHJ5IGRhdGEgYmVpbmcgZW5jcnlwdGVkIGlzIHByb2JhYmx5IGFs c28gaW1wb3J0YW50LiZuYnNwOyBJZiB0aGUgV0cgd2VyZSB0byBhZG9wdCBhIGRyYWZ0IHdpdGhv dXQgdGhpcywgdGhlbiBhcyBCZW5vaXQgbWVudGlvbmVkLA0KIEkgd291bGQgaGF2ZSB0byB0ZXN0 IHRoZSB3YXRlciB3aXRoIHRoZSBJRVNHIHRvIGRldGVybWluZSB3aGV0aGVyIHRoYXQgd291bGQg YmUgYWNjZXB0YWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+W3p0cl0gV2Ugd2lsbCB3b3JrIG9uIGEgZHJhZnQgdG8gZGVzY3Jp YmUgYWJvdXQgdGhlIGVuY3J5cHRpb24uJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgYWxzbyBub3RlIHRoYXQgdGhlIGRyYWZ0IGFsbG93cyBm b3IgYSBHUEIgZW5jb2Rpbmcgb2YgdGhlIHRlbGVtZXRyeSBkYXRhLCBidXQgSeKAmW0gbm90IGF3 YXJlIG9mIGFueSBmb3JtYWwgc3RhbmRhcmQgZW5jb2Rpbmcgb2YgWUFORyBkYXRhIGluIEdQQiwg YW5kIHRoZXJlIGlzIGEgY2hvaWNlIGJldHdlZW4gd2hldGhlcg0KIHRoZSBHUEIgZW5jb2Rpbmcg aXMgZ2VuZXJpYyBmb3IgYWxsIFlBTkcgZGF0YSwgb3Igc3BlY2lmaWMgR1BCIGVuY29kaW5ncyBh cmUgdXNlZnVsIGZvciB0aGUgc3BlY2lmaWMgZGF0YSB0aGF0IGlzIGJlaW5nIGVuY29kZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Plt6dHJdIEp1c3QgdG8gY2xhcmlmeSwgdGhpcyBkcmFmdCBvbmx5IGNvbnNpZGVyIGEgY29kZSBw b2ludCB0byBpbmRpY2F0ZSB0aGUgR1BCIGVuY29kaW5nLiBXaXRoIHRoaXMgaW5kaWNhdGlvbiwg dGhlIHJlY2VpdmVyIGtub3dzIGhvdyB0byBkZWNvZGUgdGhlIG1lc3NhZ2UuIFlBTkcgdG8gR1BC DQogaXMgb3V0IG9mIHRoZSBzY29wZS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XaGF04oCZcyB5b3VyIHN1Z2dlc3Rpb24/IERvIHlvdSBz dWdnZXN0IHVzIG5vdCB0byBpbmNsdWRlIEdQQiBhcyBhIGVuY29kaW5nPw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxicj4NClJvYjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IG5ldGNvbmYgJmx0OzxhIGhyZWY9 Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPktlbnQgV2F0c2VuPGJyPg0KPGI+U2VudDo8 L2I+IDA3IEF1Z3VzdCAyMDIwIDIxOjE2PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86 bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0 Y29uZi11ZHAtbm90aWY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5bYXMgYSBj b250cmlidXRvcl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7MSkgaXMgdGhlIHByb2JsZW0gaW1wb3J0YW50IGZvciB0aGUgTkVUQ09ORiBXRyB0 byBzb2x2ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SSBiZWxpZXZlIHRoYXQgaXQgaXMgaW1wb3J0YW50IHRv IGVuYWJsZSBwdWJsaXNoZXJzIHRvIHNlbmQgbm90aWZpY2F0aW9ucyB1c2luZyBhIFVEUC1iYXNl ZCB0cmFuc3BvcnQuICZuYnNwOyBUaGlzIGJlbGllZiBpcyBiYXNlZCBvbiBteSBleHBlcmllbmNl IGZyb20gd2hlbiBhdCBKdW5pcGVyIGRlYWxpbmcgd2l0aCB2ZXJ5IGhpZ2gtZW5kIGZpcmV3YWxs cyB3aXRoIGVub3Jtb3VzIGxvZw0KIG91dHB1dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+SSBiZWxpZXZlIHRoYXQg dGhlJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj5ORVRDT05GIFdHIGlzIHRoZSBhcHBy b3ByaWF0ZSBXRyBmb3IgdGhpcyB3b3JrLCBoYXZpbmcgZGVmaW5lZCBSRkMgODYzOSAoU04pLCZu YnNwOzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UkZDIDg2NDAgKE5OKSwgYW5kJm5ic3A7PC9z cGFuPlJGQyA4NjUwIChSTikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj4mbmJzcDsmbmJzcDsmbmJzcDsyKSBpcyB0aGUgZHJhZnQgYSBzdWl0YWJsZSBiYXNpcyBm b3IgdGhlIHdvcms/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+SSBoYXZlIHJlYWQgdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0 aGUgZHJhZnQgYW5kIGZpbmQgaXQgdG8gYmUgYSByZWFzb25hYmxlIHN0YXJ0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+UHJlc3VtaW5nIHRoZSDigJxy ZWNlaXZlci1pbnN0YW5jZXPigJ0gYXVnbWVudGF0aW9uIGRlZmluZWQgaW4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1o dHRwcy1ub3RpZi0wNCNzZWN0aW9uLTMiPjxzcGFuIGxhbmc9IkVOLUdCIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmLTA0I3NlY3Rpb24t Mzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwO3Rha2VzDQogb2ZmLCB0aGUgbW9k dWxlIGRlZmluZWQgaW4gdGhpcyBkcmFmdCBzaG91bGQgYmUgdXBkYXRlZCB0byBhdWdtZW50IGlu dG8gaXQgaW5zdGVhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPkkgYXBwcmVjaWF0ZSBTZWN0aW9uIDUg KEFwcGxpY2FiaWxpdHkpIG5vdGluZyB0aGF0IHRoZSBVRFAtdHJhbnNwb3J0IGlzIHByaW1hcmls eSBmb3IgdGhlIGRhdGEgcGxhbmUgKG5vdCB0aGUgY29udHJvbCBwbGFuZSksIGFzIGl0IGRvZXNu 4oCZdCBtYXR0ZXIgc28gbXVjaCBpZiBkYXRhIHBsYW5lIG5vdGlmaWNhdGlvbnMgYXJlIGxvc3Qu ICZuYnNwO1RoaXMNCiBhZGRyZXNzZXMgKEkgdGhpbmspIHRoZSBpc3N1ZSB0aGF0IFJvYiBTaGFr aXIgcmFpc2VkIGJlZm9yZTogPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL21pbnV0ZXMtMTAzLW5ldGNvbmYiPjxzcGFuIGxhbmc9IkVOLUdCIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9taW51dGVzLTEwMy1uZXRjb25mPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsoc2VhcmNoDQogZm9y IOKAnFJvYiBT4oCdKS4gJm5ic3A7VGhhdCBzYWlkLCBpdCBpcyB1bmNsZWFyIHRvIG1lIGhvdyBh IHJlY2VpdmVyIGNvdWxkIGNvbmZpZ3VyZSB0aGlzIHdoaWxlLCBlLmcuLCBjb25maWd1cmluZyBj b250cm9sIHBsYW5lIG5vdGlmaWNhdGlvbnMgdG8gYmUgc2VudCB2aWEgYSBUQ1AtYmFzZWQgdHJh bnNwb3J0IHN1Y2ggYXMg4oCcaHR0cHMtbm90aWbigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9y OmJsYWNrIj4zKSByZWdhcmRpbmcgSnVlcmdlbuKAmXMgcXVlc3Rpb25zOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyBhKSBJIGFtIHdpbGxpbmcgdG8gc3Vic3RhbnRpYWxs eSByZXZpZXcgdGhlIGRyYWZ0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsgYikgSSBhbSZuYnNwO3dpbGxpbmcgdG8gY29udHJpYnV0ZSB0byB0aGUgZGlz Y3Vzc2lvbiBvZiBhbnkgaXNzdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7IGMpIEkgZG8gTk9UJm5ic3A7cGxhbiB0byBpbXBsZW1lbnQgdGhlIHRlY2hu b2xvZ3kgZGVmaW5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5LZW50PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_c9aea6429c6c466d80d98899bf38b375huaweicom_-- From nobody Wed Aug 26 10:29:16 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FF63A18A4 for ; Wed, 26 Aug 2020 10:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiSK8CcK5LWQ for ; Wed, 26 Aug 2020 10:29:11 -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 120033A18AC for ; Wed, 26 Aug 2020 10:29:09 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id w14so3305660ljj.4 for ; Wed, 26 Aug 2020 10:29:09 -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=NDyvoAB//sL6zxSji9TqVVlJyHfus+J2bPLJkByYdD4=; b=KubWB5zaRzQ9ZgxqAKhPGVUX5ianSGv909Mxsmv6bswlzfmAZfRYQkORtfFxuIR09y 5xmW8DJ7Mkx+u2hrSTdrvCnyiLysL/FdqorSjc7RH+7MXfub2kTfm5+eW/YcPqXvvinA 22lMDD1MJPl+yu1u3QEXDENIQiHrn8nNBQDsfj7ZT4I+HUV2Vqulswp4aZGizFW5KuN1 L6hydA8gYHdFz3U4Eo7qHyrozX9/y2dAW1UbLjV3oW4fFjn3vu5UjXsoYxhZtJ2ckU9m +DnxWs5o1zz3NjCBP0VuiT7i/BWCkDcbtDoWnvkolsKYQyLefrWKW/+myfjQ+VqXAr4B 5lwQ== 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=NDyvoAB//sL6zxSji9TqVVlJyHfus+J2bPLJkByYdD4=; b=g64ZSVrYI4brKJ0Y6eDZECjQHmCTr9/jv90gEFe8d0AHnfj21XCgls9EFmMePuj1q7 ub943YXc7hTFjDgeZKKKITPIyvsn9pBpIiA3kQWjalgEwnNGqT+zUZ9uR9jbNML6bkN0 ydyUoyHNXFV/yyLt8PazUwB8dYTQHIf+1x1Q+ljYTEl46eKBB5u2nA2oXCpPc3OtRNJx /Z8bPFfdy26gMJzuKGFc0isOG4soMSSlo62VKzidy/X6pf9IQaTlNE//RfMStEOWfJIJ uFkJnLGgHAZxoS7CnbPdCUCJFibPmvfK3iNBE53vrMqRo7icHO3s0x59lrhkO2sts5mx tRyA== X-Gm-Message-State: AOAM532tduFQTlnH18qvYYzo+vYmbYFX6oVVfgI3zftLkIvMi61L7eFB A9JTUS/eUK4pUKBqOATT+vMVk0uk9y4A0xDAg35CeA== X-Google-Smtp-Source: ABdhPJzi63SIZY0FeVLq81oXGm4r5m5wZb0vOuNG8ag54B2SGzIWvO1BsY8CLvYptLIgHoD/NEZTmgUtN4oqUBlvhMM= X-Received: by 2002:a2e:9dd0:: with SMTP id x16mr7369979ljj.144.1598462947718; Wed, 26 Aug 2020 10:29:07 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.com> In-Reply-To: From: Andy Bierman Date: Wed, 26 Aug 2020 10:28:56 -0700 Message-ID: To: Tianran Zhou Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002f9b6705adcb28a7" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 17:29:14 -0000 --0000000000002f9b6705adcb28a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou wrote= : > Hi Andy, > > > > Please see inline. > > > > Tianran > > > > *From:* netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Wednesday, August 19, 2020 6:18 AM > *To:* Rob Wilton (rwilton) > *Cc:* netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > > > > > On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton) 40cisco.com@dmarc.ietf.org> wrote: > > Hi, > > > > [Also as a contributor] > > > > My comments are broadly similar to Kent=E2=80=99s. > > > > I believe that a UDP transport for dataplane telemetry where getting > accurate fresh data quickly is more important than getting every update. > This is particularly true if a subsequent notification will cover any los= t > values anyway (e.g. periodic statistics). > > > > > > agreed. > > There is also the resync-subscription mechanism to help recover from > missing data. > > > > [ztr] Our intention of using UDP is for data that do not care about > occasional loss. Typically for period data, and new data will anyway came > and update. > > Does the =E2=80=9Cresync-subscription=E2=80=9D mean the retransmission? H= ere do you want > to add the =E2=80=9Cresync-subscription mechanism=E2=80=9D when packet lo= ss is detected > in this draft? > > > This is explained in RFC 8641 > > > > > I suspect that having a mechanism to allow for the telemetry data being > encrypted is probably also important. If the WG were to adopt a draft > without this, then as Benoit mentioned, I would have to test the water wi= th > the IESG to determine whether that would be acceptable. > > > > I suspect the lack of congestion control might get their attention as wel= l. > > > > [ztr] Yes, I agree, both security and congestion considerations need to b= e > described in the document. We have section 4 for congestion control. Do y= ou > have any idea on this? > no -- I can't solve problems that IETF creates for itself. I think the draft says something like "do not use this protocol if congestion is a concern". > > > I also note that the draft allows for a GPB encoding of the telemetry > data, but I=E2=80=99m not aware of any formal standard encoding of YANG d= ata in > GPB, and there is a choice between whether the GPB encoding is generic fo= r > all YANG data, or specific GPB encodings are useful for the specific data > that is being encoded. > > > > > > > > I was confused by the same thing. > > Is there a YANG schema for a notification element that is used? > > Which means the .proto file is hardwired? > > If not then how does the receiver know what is sent? > > There are some technical issues that can be addressed if the draft is > adopted. > > > > [ztr] In this draft we only consider to include a code point to indicate > the GPB encoding. How to map YANG to GPB is out of the scope of this draf= t. > > In practice, there are several ways in my opinion. > > We can map YANG to proto firstly, and the proto actually describes the > data structure. I think YANG can almost translate to proto 1:1. > > We can also develop YANG to GPB directly, just like YANG to XML and JSON. > > In brief, the receiver can still know what is sent by YANG. > > > > I don't think the protocol should include placeholders for proprietary solutions. Either leave out GPB completely or support it in an interoperable way. More issues: This protocol is not usable by servers that stream data instead of building an entire response in memory. With a streaming design the server doesn't know what will be sent in advance so it sure doesn't know the length in advance. CBOR does a great job of supporting both types of server design. NETCONF and HTTP support chunking, which is used extensively by streaming servers. This draft should mention streaming and explain why it is not supported. The generic wrappers (like gNMI and YANG notification schema) do not handle "anydata" very well at all. The binary payload becomes mostly JSON. Only CBOR+SID handles anydata efficiently. The solution (maybe outside the scope of this protocol) should consider how YANG anydata will be transmitted efficiently and converted from anydata to a real schema correctly by the receiver. > > > > Regards, > Rob > > > > > > Andy > Andy > > > > > *From:* netconf *On Behalf Of *Kent Watsen > *Sent:* 07 August 2020 21:16 > *To:* netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > [as a contributor] > > > > > > 1) is the problem important for the NETCONF WG to solve? > > > > I believe that it is important to enable publishers to send notifications > using a UDP-based transport. This belief is based on my experience from > when at Juniper dealing with very high-end firewalls with enormous log > output. > > > > I believe that the NETCONF WG is the appropriate WG for this work, having > defined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN). > > > > > > 2) is the draft a suitable basis for the work? > > > > I have read the current version of the draft and find it to be a > reasonable start. > > > > Presuming the =E2=80=9Creceiver-instances=E2=80=9D augmentation defined i= n > https://tools.ietf.org/html/draft-ietf-netconf-https-notif-04#section-3 t= akes > off, the module defined in this draft should be updated to augment into i= t > instead. > > > > I appreciate Section 5 (Applicability) noting that the UDP-transport is > primarily for the data plane (not the control plane), as it doesn=E2=80= =99t matter > so much if data plane notifications are lost. This addresses (I think) t= he > issue that Rob Shakir raised before: > https://datatracker.ietf.org/doc/minutes-103-netconf (search for =E2=80= =9CRob > S=E2=80=9D). That said, it is unclear to me how a receiver could configu= re this > while, e.g., configuring control plane notifications to be sent via a > TCP-based transport such as =E2=80=9Chttps-notif=E2=80=9D. > > > > > > 3) regarding Juergen=E2=80=99s questions: > > > > a) I am willing to substantially review the drafts. > > b) I am willing to contribute to the discussion of any issue. > > c) I do NOT plan to implement the technology defined. > > > > > > > > Kent > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --0000000000002f9b6705adcb28a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 26, 2020 at 1:17 AM Tianr= an Zhou <zhoutianran@huawei.co= m> wrote:

Hi Andy,

=C2=A0

Please see inline.

=C2=A0

Tianran

=C2=A0

From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Wednesday, August 19, 2020 6:18 AM
To: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>
Cc: netconf@ie= tf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

=C2=A0

=C2=A0

On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton)= <rwilton=3D40cisco.com@dmarc.ietf.org> wrote:

Hi,

=C2=A0

[Also as a contributor]<= u>

=C2=A0

My comments are broadly similar= to Kent=E2=80=99s.

=C2=A0

I believe that a UDP transport = for dataplane telemetry where getting accurate fresh data quickly is more i= mportant than getting every update.=C2=A0 This is particularly true if a subsequent notification will cover any lost values anyway (e.g. = periodic statistics).

=C2=A0

=C2=A0

agreed.

There is also the resync-subscription mechanism to h= elp recover from missing data.

=C2=A0

[ztr] Our intention of using UDP is for data that do not care abo= ut occasional loss. Typically for period data, and new data will anyway cam= e and update.

Does the =E2=80=9Cresync-subscription=E2=80=9D mean the retransmission?= Here do you want to add the =E2=80=9Cresync-subscription mechanism=E2= =80=9D when packet loss is detected in this draft?

=C2=A0



This is explained in RFC 8641

=C2=A0

=C2=A0

=C2=A0

I suspect that having a mechani= sm to allow for the telemetry data being encrypted is probably also importa= nt.=C2=A0 If the WG were to adopt a draft without this, then as Benoit mentioned, I would have to test the water with the IESG to deter= mine whether that would be acceptable.

=C2=A0

I suspect the lack of congestion control might get t= heir attention as well.

=C2=A0

[ztr] Yes, I agree, both security and congestion considerations n= eed to be described in the document. We have section 4 for congestion contr= ol. Do you have any idea on this?

<= /blockquote>


no -- I can't solve prob= lems that IETF creates for itself.
I think the draft says somethi= ng like "do not use this protocol if congestion is a concern".

=C2=A0

=C2=A0

I also note that the draft allo= ws for a GPB encoding of the telemetry data, but I=E2=80=99m not aware of a= ny formal standard encoding of YANG data in GPB, and there is a choice between whether the GPB encoding is generic for all YANG data, or= specific GPB encodings are useful for the specific data that is being enco= ded.

=C2=A0

=C2=A0

=C2=A0

I was confused by the same thing.

Is there a YANG schema for a notification element th= at is used?

Which means the .proto file is hardwired?<= /u>

If not then how does the receiver know what is sent?=

There are some technical issues that can be addresse= d if the draft is adopted.

=C2=A0

[ztr] In this draft we only consider to include a code point to i= ndicate the GPB encoding. How to map YANG to GPB is out of the scope of thi= s draft.

In practice, there are several ways in my opinion.<= /span>

We can map YANG to proto firstly, and the proto actually describe= s the data structure. I think YANG can almost translate to proto 1:1.

We can also develop YANG to GPB directly, just like YANG to XML a= nd JSON.

In brief, the receiver can still know what is sent by YANG.

=C2=A0



I don't think the protocol should includ= e placeholders for proprietary=C2=A0solutions.
Either leave out G= PB completely or support it in an interoperable way.

More issues:

This protocol is not usable by ser= vers that stream data instead of building an entire response
in m= emory. With a streaming design the server doesn't know what will be sen= t in advance so
it sure doesn't know the length in advance.= =C2=A0 CBOR does a great job of supporting both
types of server d= esign.=C2=A0 NETCONF and HTTP support chunking, which is used extensively b= y
streaming servers. This draft should mention streaming and expl= ain why it is not supported.

The generic wrappers = (like gNMI and YANG notification schema) do not handle "anydata" = very well at all.
The binary payload becomes mostly JSON.=C2=A0 O= nly CBOR+SID handles anydata efficiently.
The solution (maybe out= side the scope of this protocol) should consider how YANG anydata
will be transmitted efficiently and converted from anydata to a real schem= a correctly by the receiver.


=C2=A0<= /u>

=C2=A0

Regards,
Rob

=C2=A0

=C2=A0

Andy

<= div>

Andy
=C2=A0

=

=C2=A0

=C2=A0

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 07 August 2020 21:16
To: netconf@ie= tf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

[as a contributor]

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A01) is the pro= blem important for the NETCONF WG to solve?

=C2=A0

I believe that it is important = to enable publishers to send notifications using a UDP-based transport. =C2= =A0 This belief is based on my experience from when at Juniper dealing with very high-end firewalls with enormous log output.

=C2=A0

I believe= that the=C2=A0NETCONF WG is the appropriate WG= for this work, having defined RFC 8639 (SN),=C2=A0RFC 8640 (NN), and=C2=A0RFC 8650 (RN).

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A02) is the dra= ft a suitable basis for the work?

=C2=A0

I have read the current version= of the draft and find it to be a reasonable start.

=C2=A0

=C2=A0

I appreci= ate Section 5 (Applicability) noting that the UDP-transport is primarily fo= r the data plane (not the control plane), as it doesn=E2=80=99t matter so much if data plane notifications are lost.=C2=A0 This addresses = (I think) the issue that Rob Shakir raised before: https://datatracker.ietf.org/doc/minutes-103-netconf=C2=A0(sear= ch for =E2=80=9CRob S=E2=80=9D).=C2=A0 That said, it is unclear to me how a= receiver could configure this while, e.g., configuring control plane notifications to be sent via a TCP-based transport such as =E2=80=9C= https-notif=E2=80=9D.

=C2=A0

=C2=A0

3) regard= ing Juergen=E2=80=99s questions:<= /span>

=C2=A0

=C2=A0 a)= I am willing to substantially review the drafts.

=C2=A0 b)= I am=C2=A0willing to contribute to the discussion of any issue.

=C2=A0 c)= I do NOT=C2=A0plan to implement the technology defined.

=C2=A0

=C2=A0

=C2=A0

Kent

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

--0000000000002f9b6705adcb28a7-- From nobody Wed Aug 26 18:51:03 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343FB3A0C46 for ; Wed, 26 Aug 2020 18:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGbo05s3sc5F for ; Wed, 26 Aug 2020 18:50:59 -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 AEB7C3A0C43 for ; Wed, 26 Aug 2020 18:50:57 -0700 (PDT) Received: from lhreml738-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 32F3EA98D115ED6EC84B for ; Thu, 27 Aug 2020 02:50:55 +0100 (IST) Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml738-chm.china.huawei.com (10.201.108.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 27 Aug 2020 02:50:54 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 27 Aug 2020 09:50:52 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Thu, 27 Aug 2020 09:50:52 +0800 From: Tianran Zhou To: Andy Bierman CC: "Rob Wilton (rwilton)" , "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif Thread-Index: AQHWa3XJ0mBLbRaES02VUjy2aRVTDKkskgcAgBDbzICAAJAcAIAMIxLggAAetwCAAQUpEA== Date: Thu, 27 Aug 2020 01:50:51 +0000 Message-ID: <07b991b1e32347b58ae4ef968cdffc7f@huawei.com> References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.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.108.243.128] Content-Type: multipart/alternative; boundary="_000_07b991b1e32347b58ae4ef968cdffc7fhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 01:51:01 -0000 --_000_07b991b1e32347b58ae4ef968cdffc7fhuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhhbmtzIGZvciB5b3VyIHJlcGx5IGFuZCBzdWdnZXN0aW9ucy4NCg0KQ2hl ZXJzLA0KVGlhbnJhbg0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jr cy5jb21dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDI3LCAyMDIwIDE6MjkgQU0NClRvOiBUaWFu cmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb20+DQpDYzogUm9iIFdpbHRvbiAocndpbHRv bikgPHJ3aWx0b249NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+OyBuZXRjb25mQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW25ldGNvbmZdIEFkb3B0aW9uLXN1aXRhYmlsaXR5IGZvciBkcmFmdC11 bnl0ZS1uZXRjb25mLXVkcC1ub3RpZg0KDQoNCg0KT24gV2VkLCBBdWcgMjYsIDIwMjAgYXQgMTox NyBBTSBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFu cmFuQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIEFuZHksDQoNClBsZWFzZSBzZWUgaW5saW5lLg0K DQpUaWFucmFuDQoNCkZyb206IG5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBBbmR5IEJp ZXJtYW4NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE5LCAyMDIwIDY6MTggQU0NClRvOiBSb2Ig V2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbj00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWls dG86NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KQ2M6IG5ldGNvbmZAaWV0Zi5vcmc8bWFp bHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldGNvbmZdIEFkb3B0aW9uLXN1 aXRhYmlsaXR5IGZvciBkcmFmdC11bnl0ZS1uZXRjb25mLXVkcC1ub3RpZg0KDQoNCg0KT24gVHVl LCBBdWcgMTgsIDIwMjAgYXQgNjo0MiBBTSBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbj00 MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5v cmc+PiB3cm90ZToNCkhpLA0KDQpbQWxzbyBhcyBhIGNvbnRyaWJ1dG9yXQ0KDQpNeSBjb21tZW50 cyBhcmUgYnJvYWRseSBzaW1pbGFyIHRvIEtlbnTigJlzLg0KDQpJIGJlbGlldmUgdGhhdCBhIFVE UCB0cmFuc3BvcnQgZm9yIGRhdGFwbGFuZSB0ZWxlbWV0cnkgd2hlcmUgZ2V0dGluZyBhY2N1cmF0 ZSBmcmVzaCBkYXRhIHF1aWNrbHkgaXMgbW9yZSBpbXBvcnRhbnQgdGhhbiBnZXR0aW5nIGV2ZXJ5 IHVwZGF0ZS4gIFRoaXMgaXMgcGFydGljdWxhcmx5IHRydWUgaWYgYSBzdWJzZXF1ZW50IG5vdGlm aWNhdGlvbiB3aWxsIGNvdmVyIGFueSBsb3N0IHZhbHVlcyBhbnl3YXkgKGUuZy4gcGVyaW9kaWMg c3RhdGlzdGljcykuDQoNCg0KYWdyZWVkLg0KVGhlcmUgaXMgYWxzbyB0aGUgcmVzeW5jLXN1YnNj cmlwdGlvbiBtZWNoYW5pc20gdG8gaGVscCByZWNvdmVyIGZyb20gbWlzc2luZyBkYXRhLg0KDQpb enRyXSBPdXIgaW50ZW50aW9uIG9mIHVzaW5nIFVEUCBpcyBmb3IgZGF0YSB0aGF0IGRvIG5vdCBj YXJlIGFib3V0IG9jY2FzaW9uYWwgbG9zcy4gVHlwaWNhbGx5IGZvciBwZXJpb2QgZGF0YSwgYW5k IG5ldyBkYXRhIHdpbGwgYW55d2F5IGNhbWUgYW5kIHVwZGF0ZS4NCkRvZXMgdGhlIOKAnHJlc3lu Yy1zdWJzY3JpcHRpb27igJ0gbWVhbiB0aGUgcmV0cmFuc21pc3Npb24/IEhlcmUgZG8geW91IHdh bnQgdG8gYWRkIHRoZSDigJxyZXN5bmMtc3Vic2NyaXB0aW9uIG1lY2hhbmlzbeKAnSB3aGVuIHBh Y2tldCBsb3NzIGlzIGRldGVjdGVkIGluIHRoaXMgZHJhZnQ/DQoNCg0KDQpUaGlzIGlzIGV4cGxh aW5lZCBpbiBSRkMgODY0MQ0KDQpaVFI+IFllcywgSSBsb29rZWQgaW50byBSRkM4NjQxLiBJdOKA mXMgdGhlIHNhbWUgYXMgd2hhdCBJIHVuZGVyc3RhbmQgYXMg4oCccmV0cmFuc21pc3Npb27igJ0u IFR3byBrZXkgcG9pbnRzIG9uIOKAnHJlc3luYy1zdWJzY3JpcHRpb27igJ0gZnJvbSBteSBwZXJz cGVjdGl2ZS4NCjEuIOKAnFRoaXMgUlBDIGlzIHN1cHBvcnRlZCBvbmx5IGZvciBvbi1jaGFuZ2Ug c3Vic2NyaXB0aW9ucyBwcmV2aW91c2x5IGVzdGFibGlzaGVkIHVzaW5nIGFuICJlc3RhYmxpc2gt c3Vic2NyaXB0aW9uIiBSUEMu4oCdDQoyLiDigJxPbiByZWNlaXB0LCBhIHB1Ymxpc2hlciBtdXN0 IGVpdGhlciAoMSkgYWNjZXB0IHRoZSByZXF1ZXN0IGFuZCBxdWlja2x5IGZvbGxvdyB3aXRoIGEg InB1c2gtdXBkYXRlIiBvciDigKbigJ0NCg0KU28sIHdoYXTigJlzIHlvdXIgc3VnZ2VzdGlvbiBo ZXJlPw0KVG8gc3VwcG9ydCB0aGlzPyBPciBub3Qgc3VwcG9ydCB0aGlzIGFuZCBhZGQgdGV4dCBl eHBsaWNpdGx5IGluIHRoZSBkb2N1bWVudC4NCg0KDQpJIHN1c3BlY3QgdGhhdCBoYXZpbmcgYSBt ZWNoYW5pc20gdG8gYWxsb3cgZm9yIHRoZSB0ZWxlbWV0cnkgZGF0YSBiZWluZyBlbmNyeXB0ZWQg aXMgcHJvYmFibHkgYWxzbyBpbXBvcnRhbnQuICBJZiB0aGUgV0cgd2VyZSB0byBhZG9wdCBhIGRy YWZ0IHdpdGhvdXQgdGhpcywgdGhlbiBhcyBCZW5vaXQgbWVudGlvbmVkLCBJIHdvdWxkIGhhdmUg dG8gdGVzdCB0aGUgd2F0ZXIgd2l0aCB0aGUgSUVTRyB0byBkZXRlcm1pbmUgd2hldGhlciB0aGF0 IHdvdWxkIGJlIGFjY2VwdGFibGUuDQoNCkkgc3VzcGVjdCB0aGUgbGFjayBvZiBjb25nZXN0aW9u IGNvbnRyb2wgbWlnaHQgZ2V0IHRoZWlyIGF0dGVudGlvbiBhcyB3ZWxsLg0KDQpbenRyXSBZZXMs IEkgYWdyZWUsIGJvdGggc2VjdXJpdHkgYW5kIGNvbmdlc3Rpb24gY29uc2lkZXJhdGlvbnMgbmVl ZCB0byBiZSBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50LiBXZSBoYXZlIHNlY3Rpb24gNCBmb3Ig Y29uZ2VzdGlvbiBjb250cm9sLiBEbyB5b3UgaGF2ZSBhbnkgaWRlYSBvbiB0aGlzPw0KDQoNCm5v IC0tIEkgY2FuJ3Qgc29sdmUgcHJvYmxlbXMgdGhhdCBJRVRGIGNyZWF0ZXMgZm9yIGl0c2VsZi4N CkkgdGhpbmsgdGhlIGRyYWZ0IHNheXMgc29tZXRoaW5nIGxpa2UgImRvIG5vdCB1c2UgdGhpcyBw cm90b2NvbCBpZiBjb25nZXN0aW9uIGlzIGEgY29uY2VybiIuDQoNCg0KDQpJIGFsc28gbm90ZSB0 aGF0IHRoZSBkcmFmdCBhbGxvd3MgZm9yIGEgR1BCIGVuY29kaW5nIG9mIHRoZSB0ZWxlbWV0cnkg ZGF0YSwgYnV0IEnigJltIG5vdCBhd2FyZSBvZiBhbnkgZm9ybWFsIHN0YW5kYXJkIGVuY29kaW5n IG9mIFlBTkcgZGF0YSBpbiBHUEIsIGFuZCB0aGVyZSBpcyBhIGNob2ljZSBiZXR3ZWVuIHdoZXRo ZXIgdGhlIEdQQiBlbmNvZGluZyBpcyBnZW5lcmljIGZvciBhbGwgWUFORyBkYXRhLCBvciBzcGVj aWZpYyBHUEIgZW5jb2RpbmdzIGFyZSB1c2VmdWwgZm9yIHRoZSBzcGVjaWZpYyBkYXRhIHRoYXQg aXMgYmVpbmcgZW5jb2RlZC4NCg0KDQoNCkkgd2FzIGNvbmZ1c2VkIGJ5IHRoZSBzYW1lIHRoaW5n Lg0KSXMgdGhlcmUgYSBZQU5HIHNjaGVtYSBmb3IgYSBub3RpZmljYXRpb24gZWxlbWVudCB0aGF0 IGlzIHVzZWQ/DQpXaGljaCBtZWFucyB0aGUgLnByb3RvIGZpbGUgaXMgaGFyZHdpcmVkPw0KSWYg bm90IHRoZW4gaG93IGRvZXMgdGhlIHJlY2VpdmVyIGtub3cgd2hhdCBpcyBzZW50Pw0KVGhlcmUg YXJlIHNvbWUgdGVjaG5pY2FsIGlzc3VlcyB0aGF0IGNhbiBiZSBhZGRyZXNzZWQgaWYgdGhlIGRy YWZ0IGlzIGFkb3B0ZWQuDQoNClt6dHJdIEluIHRoaXMgZHJhZnQgd2Ugb25seSBjb25zaWRlciB0 byBpbmNsdWRlIGEgY29kZSBwb2ludCB0byBpbmRpY2F0ZSB0aGUgR1BCIGVuY29kaW5nLiBIb3cg dG8gbWFwIFlBTkcgdG8gR1BCIGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcyBkcmFmdC4NCklu IHByYWN0aWNlLCB0aGVyZSBhcmUgc2V2ZXJhbCB3YXlzIGluIG15IG9waW5pb24uDQpXZSBjYW4g bWFwIFlBTkcgdG8gcHJvdG8gZmlyc3RseSwgYW5kIHRoZSBwcm90byBhY3R1YWxseSBkZXNjcmli ZXMgdGhlIGRhdGEgc3RydWN0dXJlLiBJIHRoaW5rIFlBTkcgY2FuIGFsbW9zdCB0cmFuc2xhdGUg dG8gcHJvdG8gMToxLg0KV2UgY2FuIGFsc28gZGV2ZWxvcCBZQU5HIHRvIEdQQiBkaXJlY3RseSwg anVzdCBsaWtlIFlBTkcgdG8gWE1MIGFuZCBKU09OLg0KSW4gYnJpZWYsIHRoZSByZWNlaXZlciBj YW4gc3RpbGwga25vdyB3aGF0IGlzIHNlbnQgYnkgWUFORy4NCg0KDQoNCkkgZG9uJ3QgdGhpbmsg dGhlIHByb3RvY29sIHNob3VsZCBpbmNsdWRlIHBsYWNlaG9sZGVycyBmb3IgcHJvcHJpZXRhcnkg c29sdXRpb25zLg0KRWl0aGVyIGxlYXZlIG91dCBHUEIgY29tcGxldGVseSBvciBzdXBwb3J0IGl0 IGluIGFuIGludGVyb3BlcmFibGUgd2F5Lg0KDQpaVFI+IFdlIGhhdmUgbm8gcG9zaXRpb24gb24g dGhpcy4gSWYgdGhlIFdHIGFncmVlZCwgd2Ugd291bGQgbGlrZSB0byBsZWF2ZSBvdXQgR1BCLg0K DQpNb3JlIGlzc3VlczoNCg0KVGhpcyBwcm90b2NvbCBpcyBub3QgdXNhYmxlIGJ5IHNlcnZlcnMg dGhhdCBzdHJlYW0gZGF0YSBpbnN0ZWFkIG9mIGJ1aWxkaW5nIGFuIGVudGlyZSByZXNwb25zZQ0K aW4gbWVtb3J5LiBXaXRoIGEgc3RyZWFtaW5nIGRlc2lnbiB0aGUgc2VydmVyIGRvZXNuJ3Qga25v dyB3aGF0IHdpbGwgYmUgc2VudCBpbiBhZHZhbmNlIHNvDQppdCBzdXJlIGRvZXNuJ3Qga25vdyB0 aGUgbGVuZ3RoIGluIGFkdmFuY2UuICBDQk9SIGRvZXMgYSBncmVhdCBqb2Igb2Ygc3VwcG9ydGlu ZyBib3RoDQp0eXBlcyBvZiBzZXJ2ZXIgZGVzaWduLiAgTkVUQ09ORiBhbmQgSFRUUCBzdXBwb3J0 IGNodW5raW5nLCB3aGljaCBpcyB1c2VkIGV4dGVuc2l2ZWx5IGJ5DQpzdHJlYW1pbmcgc2VydmVy cy4gVGhpcyBkcmFmdCBzaG91bGQgbWVudGlvbiBzdHJlYW1pbmcgYW5kIGV4cGxhaW4gd2h5IGl0 IGlzIG5vdCBzdXBwb3J0ZWQuDQoNClpUUj4gSWYgeW91IG1lYW4gYml0IHN0cmVhbWluZyBsaWtl IFRDUCwgSSB0aGluayBVRFAgY2Fubm90IHN1cHBvcnQgdGhpcy4gRG8geW91IGhhdmUgYW55IHBv aW50ZXIgb24gaG93IENCT1IgY2FuIHN1cHBvcnQgdGhlIHN0cmVhbWluZy4gQW5kIGhvdyBORVRD T05GIGFuZCBIVFRQIHN1cHBvcnQgY2h1bmtpbmcuDQpJbiBnZW5lcmFsLCBJIHVuZGVyc3RhbmQg dGhpcyByZXF1aXJlbWVudCB3aXRoIHNtYWxsIG1lbW9yeSBvciBwYXJ0aWFsIGRhdGEuIEJ1dCBk byB5b3UgaGF2ZSBhbnkgcmVhbCBjYXNlIGluIHRoZSBjb250ZXh0IG9mIFlBTkcgcHVzaD8gU28g dGhhdCB3ZSBjYW4gd29yayBvbiBhbiBvcHRpbWFsIGRlc2lnbi4NCg0KVGhlIGdlbmVyaWMgd3Jh cHBlcnMgKGxpa2UgZ05NSSBhbmQgWUFORyBub3RpZmljYXRpb24gc2NoZW1hKSBkbyBub3QgaGFu ZGxlICJhbnlkYXRhIiB2ZXJ5IHdlbGwgYXQgYWxsLg0KVGhlIGJpbmFyeSBwYXlsb2FkIGJlY29t ZXMgbW9zdGx5IEpTT04uICBPbmx5IENCT1IrU0lEIGhhbmRsZXMgYW55ZGF0YSBlZmZpY2llbnRs eS4NClRoZSBzb2x1dGlvbiAobWF5YmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBwcm90b2Nv bCkgc2hvdWxkIGNvbnNpZGVyIGhvdyBZQU5HIGFueWRhdGENCndpbGwgYmUgdHJhbnNtaXR0ZWQg ZWZmaWNpZW50bHkgYW5kIGNvbnZlcnRlZCBmcm9tIGFueWRhdGEgdG8gYSByZWFsIHNjaGVtYSBj b3JyZWN0bHkgYnkgdGhlIHJlY2VpdmVyLg0KDQoNCg0KDQpSZWdhcmRzLA0KUm9iDQoNCg0KQW5k eQ0KDQoNCkFuZHkNCg0KDQoNCkZyb206IG5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEtlbnQgV2F0 c2VuDQpTZW50OiAwNyBBdWd1c3QgMjAyMCAyMToxNg0KVG86IG5ldGNvbmZAaWV0Zi5vcmc8bWFp bHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldGNvbmZdIEFkb3B0aW9uLXN1 aXRhYmlsaXR5IGZvciBkcmFmdC11bnl0ZS1uZXRjb25mLXVkcC1ub3RpZg0KDQpbYXMgYSBjb250 cmlidXRvcl0NCg0KDQogICAxKSBpcyB0aGUgcHJvYmxlbSBpbXBvcnRhbnQgZm9yIHRoZSBORVRD T05GIFdHIHRvIHNvbHZlPw0KDQpJIGJlbGlldmUgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdG8gZW5h YmxlIHB1Ymxpc2hlcnMgdG8gc2VuZCBub3RpZmljYXRpb25zIHVzaW5nIGEgVURQLWJhc2VkIHRy YW5zcG9ydC4gICBUaGlzIGJlbGllZiBpcyBiYXNlZCBvbiBteSBleHBlcmllbmNlIGZyb20gd2hl biBhdCBKdW5pcGVyIGRlYWxpbmcgd2l0aCB2ZXJ5IGhpZ2gtZW5kIGZpcmV3YWxscyB3aXRoIGVu b3Jtb3VzIGxvZyBvdXRwdXQuDQoNCkkgYmVsaWV2ZSB0aGF0IHRoZSBORVRDT05GIFdHIGlzIHRo ZSBhcHByb3ByaWF0ZSBXRyBmb3IgdGhpcyB3b3JrLCBoYXZpbmcgZGVmaW5lZCBSRkMgODYzOSAo U04pLCBSRkMgODY0MCAoTk4pLCBhbmQgUkZDIDg2NTAgKFJOKS4NCg0KDQogICAyKSBpcyB0aGUg ZHJhZnQgYSBzdWl0YWJsZSBiYXNpcyBmb3IgdGhlIHdvcms/DQoNCkkgaGF2ZSByZWFkIHRoZSBj dXJyZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGFuZCBmaW5kIGl0IHRvIGJlIGEgcmVhc29uYWJs ZSBzdGFydC4NCg0KUHJlc3VtaW5nIHRoZSDigJxyZWNlaXZlci1pbnN0YW5jZXPigJ0gYXVnbWVu dGF0aW9uIGRlZmluZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bmV0Y29uZi1odHRwcy1ub3RpZi0wNCNzZWN0aW9uLTMgdGFrZXMgb2ZmLCB0aGUgbW9kdWxlIGRl ZmluZWQgaW4gdGhpcyBkcmFmdCBzaG91bGQgYmUgdXBkYXRlZCB0byBhdWdtZW50IGludG8gaXQg aW5zdGVhZC4NCg0KSSBhcHByZWNpYXRlIFNlY3Rpb24gNSAoQXBwbGljYWJpbGl0eSkgbm90aW5n IHRoYXQgdGhlIFVEUC10cmFuc3BvcnQgaXMgcHJpbWFyaWx5IGZvciB0aGUgZGF0YSBwbGFuZSAo bm90IHRoZSBjb250cm9sIHBsYW5lKSwgYXMgaXQgZG9lc27igJl0IG1hdHRlciBzbyBtdWNoIGlm IGRhdGEgcGxhbmUgbm90aWZpY2F0aW9ucyBhcmUgbG9zdC4gIFRoaXMgYWRkcmVzc2VzIChJIHRo aW5rKSB0aGUgaXNzdWUgdGhhdCBSb2IgU2hha2lyIHJhaXNlZCBiZWZvcmU6IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL21pbnV0ZXMtMTAzLW5ldGNvbmYgKHNlYXJjaCBmb3Ig4oCc Um9iIFPigJ0pLiAgVGhhdCBzYWlkLCBpdCBpcyB1bmNsZWFyIHRvIG1lIGhvdyBhIHJlY2VpdmVy IGNvdWxkIGNvbmZpZ3VyZSB0aGlzIHdoaWxlLCBlLmcuLCBjb25maWd1cmluZyBjb250cm9sIHBs YW5lIG5vdGlmaWNhdGlvbnMgdG8gYmUgc2VudCB2aWEgYSBUQ1AtYmFzZWQgdHJhbnNwb3J0IHN1 Y2ggYXMg4oCcaHR0cHMtbm90aWbigJ0uDQoNCg0KMykgcmVnYXJkaW5nIEp1ZXJnZW7igJlzIHF1 ZXN0aW9uczoNCg0KICBhKSBJIGFtIHdpbGxpbmcgdG8gc3Vic3RhbnRpYWxseSByZXZpZXcgdGhl IGRyYWZ0cy4NCiAgYikgSSBhbSB3aWxsaW5nIHRvIGNvbnRyaWJ1dGUgdG8gdGhlIGRpc2N1c3Np b24gb2YgYW55IGlzc3VlLg0KICBjKSBJIGRvIE5PVCBwbGFuIHRvIGltcGxlbWVudCB0aGUgdGVj aG5vbG9neSBkZWZpbmVkLg0KDQoNCg0KS2VudA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm5ldGNvbmYgbWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYu b3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRjb25mDQo= --_000_07b991b1e32347b58ae4ef968cdffc7fhuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0 IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFuZHksPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgcmVwbHkgYW5kIHN1Z2dlc3Rp b25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaWFucmFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFu ZHlAeXVtYXdvcmtzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDI3 LCAyMDIwIDE6MjkgQU08YnI+DQo8Yj5Ubzo8L2I+IFRpYW5yYW4gWmhvdSAmbHQ7emhvdXRpYW5y YW5AaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFJvYiBXaWx0b24gKHJ3aWx0b24pICZs dDtyd2lsdG9uPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnJmd0OzsgbmV0Y29uZkBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldGNvbmZdIEFkb3B0aW9uLXN1aXRhYmlsaXR5 IGZvciBkcmFmdC11bnl0ZS1uZXRjb25mLXVkcC1ub3RpZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDI2LCAyMDIwIGF0IDE6MTcgQU0gVGlhbnJh biBaaG91ICZsdDs8YSBocmVmPSJtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbSI+emhvdXRp YW5yYW5AaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBBbmR5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBzZWUgaW5saW5lLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRpYW5yYW48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG5ldGNv bmYgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+QW5keSBCaWVybWFuPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDE5 LCAyMDIwIDY6MTggQU08YnI+DQo8Yj5Ubzo8L2I+IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDty d2lsdG9uPTxhIGhyZWY9Im1haWx0bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8 L2I+IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0 Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRjb25mXSBBZG9w dGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0Y29uZi11ZHAtbm90aWY8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgQXVnIDE4 LCAyMDIwIGF0IDY6NDIgQU0gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0O3J3aWx0b249PGEgaHJl Zj0ibWFpbHRvOjQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBj aXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkhp LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPltBbHNvIGFzIGEgY29udHJpYnV0b3JdPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiI+TXkgY29tbWVudHMgYXJlIGJyb2FkbHkgc2ltaWxhciB0byBLZW504oCZ cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5JIGJlbGlldmUgdGhhdCBhIFVEUCB0cmFuc3BvcnQg Zm9yIGRhdGFwbGFuZSB0ZWxlbWV0cnkgd2hlcmUgZ2V0dGluZyBhY2N1cmF0ZSBmcmVzaCBkYXRh IHF1aWNrbHkgaXMgbW9yZSBpbXBvcnRhbnQgdGhhbiBnZXR0aW5nIGV2ZXJ5IHVwZGF0ZS4mbmJz cDsgVGhpcyBpcyBwYXJ0aWN1bGFybHkNCiB0cnVlIGlmIGEgc3Vic2VxdWVudCBub3RpZmljYXRp b24gd2lsbCBjb3ZlciBhbnkgbG9zdCB2YWx1ZXMgYW55d2F5IChlLmcuIHBlcmlvZGljIHN0YXRp c3RpY3MpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YWdy ZWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5UaGVyZSBpcyBhbHNvIHRoZSByZXN5bmMtc3Vic2NyaXB0aW9uIG1lY2hhbmlzbSB0byBoZWxw IHJlY292ZXIgZnJvbSBtaXNzaW5nIGRhdGEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlt6dHJdIE91ciBpbnRlbnRpb24gb2YgdXNp bmcgVURQIGlzIGZvciBkYXRhIHRoYXQgZG8gbm90IGNhcmUgYWJvdXQgb2NjYXNpb25hbCBsb3Nz LiBUeXBpY2FsbHkgZm9yIHBlcmlvZCBkYXRhLCBhbmQNCiBuZXcgZGF0YSB3aWxsIGFueXdheSBj YW1lIGFuZCB1cGRhdGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRvZXMgdGhlIOKAnDwvc3Bhbj5yZXN5bmMtc3Vic2NyaXB0 aW9uPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj7igJ0gbWVhbiB0aGUgcmV0cmFuc21pc3Npb24/DQogSGVyZSBk byB5b3Ugd2FudCB0byBhZGQgdGhlIOKAnDwvc3Bhbj5yZXN5bmMtc3Vic2NyaXB0aW9uIG1lY2hh bmlzbTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+4oCdIHdoZW4gcGFja2V0IGxvc3MgaXMgZGV0ZWN0ZWQgaW4g dGhpcyBkcmFmdD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBleHBsYWluZWQgaW4gUkZDIDg2NDE8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WlRSJmd0OyBZZXMsIEkg bG9va2VkIGludG8gUkZDODY0MS4gSXTigJlzIHRoZSBzYW1lIGFzIHdoYXQgSSB1bmRlcnN0YW5k IGFzIOKAnHJldHJhbnNtaXNzaW9u4oCdLiBUd28ga2V5IHBvaW50cyBvbiDigJxyZXN5bmMtc3Vi c2NyaXB0aW9u4oCdIGZyb20gbXkgcGVyc3BlY3RpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjEuIOKA nFRoaXMgUlBDIGlzIHN1cHBvcnRlZCBvbmx5IGZvciBvbi1jaGFuZ2Ugc3Vic2NyaXB0aW9ucyBw cmV2aW91c2x5IGVzdGFibGlzaGVkIHVzaW5nIGFuICZxdW90O2VzdGFibGlzaC1zdWJzY3JpcHRp b24mcXVvdDsgUlBDLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4yLiDigJxPbiByZWNlaXB0LCBhIHB1 Ymxpc2hlciBtdXN0IGVpdGhlciAoMSkgYWNjZXB0IHRoZSByZXF1ZXN0IGFuZCBxdWlja2x5IGZv bGxvdyB3aXRoIGEgJnF1b3Q7cHVzaC11cGRhdGUmcXVvdDsgb3Ig4oCm4oCdPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Tbywgd2hhdOKAmXMgeW91ciBzdWdnZXN0 aW9uIGhlcmU/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG8gc3VwcG9ydCB0aGlzPyBPciBub3Qgc3Vw cG9ydCB0aGlzIGFuZCBhZGQgdGV4dCBleHBsaWNpdGx5IGluIHRoZSBkb2N1bWVudC4NCjwvc3Bh bj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIj5JIHN1c3BlY3QgdGhhdCBoYXZpbmcgYSBtZWNoYW5pc20gdG8gYWxsb3cgZm9yIHRoZSB0 ZWxlbWV0cnkgZGF0YSBiZWluZyBlbmNyeXB0ZWQgaXMgcHJvYmFibHkgYWxzbyBpbXBvcnRhbnQu Jm5ic3A7IElmIHRoZSBXRyB3ZXJlIHRvIGFkb3B0IGEgZHJhZnQgd2l0aG91dCB0aGlzLCB0aGVu DQogYXMgQmVub2l0IG1lbnRpb25lZCwgSSB3b3VsZCBoYXZlIHRvIHRlc3QgdGhlIHdhdGVyIHdp dGggdGhlIElFU0cgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhhdCB3b3VsZCBiZSBhY2NlcHRhYmxl Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBzdXNwZWN0IHRoZSBsYWNrIG9mIGNv bmdlc3Rpb24gY29udHJvbCBtaWdodCBnZXQgdGhlaXIgYXR0ZW50aW9uIGFzIHdlbGwuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlt6 dHJdIFllcywgSSBhZ3JlZSwgYm90aCBzZWN1cml0eSBhbmQgY29uZ2VzdGlvbiBjb25zaWRlcmF0 aW9ucyBuZWVkIHRvIGJlIGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQuIFdlIGhhdmUgc2VjdGlv bg0KIDQgZm9yIGNvbmdlc3Rpb24gY29udHJvbC4gRG8geW91IGhhdmUgYW55IGlkZWEgb24gdGhp cz88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5u byAtLSBJIGNhbid0IHNvbHZlIHByb2JsZW1zIHRoYXQgSUVURiBjcmVhdGVzIGZvciBpdHNlbGYu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRo aW5rIHRoZSBkcmFmdCBzYXlzIHNvbWV0aGluZyBsaWtlICZxdW90O2RvIG5vdCB1c2UgdGhpcyBw cm90b2NvbCBpZiBjb25nZXN0aW9uIGlzIGEgY29uY2VybiZxdW90Oy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiPkkgYWxzbyBub3RlIHRoYXQgdGhlIGRyYWZ0IGFsbG93cyBmb3IgYSBHUEIgZW5jb2Rpbmcg b2YgdGhlIHRlbGVtZXRyeSBkYXRhLCBidXQgSeKAmW0gbm90IGF3YXJlIG9mIGFueSBmb3JtYWwg c3RhbmRhcmQgZW5jb2Rpbmcgb2YgWUFORyBkYXRhIGluIEdQQiwgYW5kIHRoZXJlIGlzDQogYSBj aG9pY2UgYmV0d2VlbiB3aGV0aGVyIHRoZSBHUEIgZW5jb2RpbmcgaXMgZ2VuZXJpYyBmb3IgYWxs IFlBTkcgZGF0YSwgb3Igc3BlY2lmaWMgR1BCIGVuY29kaW5ncyBhcmUgdXNlZnVsIGZvciB0aGUg c3BlY2lmaWMgZGF0YSB0aGF0IGlzIGJlaW5nIGVuY29kZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB3YXMgY29uZnVzZWQgYnkgdGhlIHNhbWUg dGhpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPklzIHRoZXJlIGEgWUFORyBzY2hlbWEgZm9yIGEgbm90aWZpY2F0aW9uIGVsZW1lbnQgdGhh dCBpcyB1c2VkPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5XaGljaCBtZWFucyB0aGUgLnByb3RvIGZpbGUgaXMgaGFyZHdpcmVkPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiBub3QgdGhl biBob3cgZG9lcyB0aGUgcmVjZWl2ZXIga25vdyB3aGF0IGlzIHNlbnQ/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZXJlIGFyZSBzb21lIHRl Y2huaWNhbCBpc3N1ZXMgdGhhdCBjYW4gYmUgYWRkcmVzc2VkIGlmIHRoZSBkcmFmdCBpcyBhZG9w dGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5benRyXSBJbiB0aGlzIGRyYWZ0IHdlIG9ubHkgY29uc2lkZXIgdG8gaW5jbHVkZSBh IGNvZGUgcG9pbnQgdG8gaW5kaWNhdGUgdGhlIEdQQiBlbmNvZGluZy4gSG93IHRvIG1hcCBZQU5H IHRvIEdQQg0KIGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcyBkcmFmdC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SW4gcHJh Y3RpY2UsIHRoZXJlIGFyZSBzZXZlcmFsIHdheXMgaW4gbXkgb3Bpbmlvbi48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2UgY2Fu IG1hcCBZQU5HIHRvIHByb3RvIGZpcnN0bHksIGFuZCB0aGUgcHJvdG8gYWN0dWFsbHkgZGVzY3Jp YmVzIHRoZSBkYXRhIHN0cnVjdHVyZS4gSSB0aGluayBZQU5HIGNhbiBhbG1vc3QgdHJhbnNsYXRl DQogdG8gcHJvdG8gMToxLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XZSBjYW4gYWxzbyBkZXZlbG9wIFlBTkcgdG8gR1BCIGRp cmVjdGx5LCBqdXN0IGxpa2UgWUFORyB0byBYTUwgYW5kIEpTT04uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkluIGJyaWVmLCB0 aGUgcmVjZWl2ZXIgY2FuIHN0aWxsIGtub3cgd2hhdCBpcyBzZW50IGJ5IFlBTkcuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgZG9uJ3QgdGhpbmsgdGhlIHByb3RvY29sIHNob3VsZCBpbmNsdWRlIHBsYWNlaG9sZGVycyBm b3IgcHJvcHJpZXRhcnkmbmJzcDtzb2x1dGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FaXRoZXIgbGVhdmUgb3V0IEdQQiBjb21wbGV0ZWx5 IG9yIHN1cHBvcnQgaXQgaW4gYW4gaW50ZXJvcGVyYWJsZSB3YXkuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlpUUiZndDsgV2UgaGF2ZSBubyBwb3NpdGlv biBvbiB0aGlzLiBJZiB0aGUgV0cgYWdyZWVkLCB3ZSB3b3VsZCBsaWtlIHRvIGxlYXZlIG91dCBH UEIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1vcmUgaXNzdWVzOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHByb3RvY29sIGlz IG5vdCB1c2FibGUgYnkgc2VydmVycyB0aGF0IHN0cmVhbSBkYXRhIGluc3RlYWQgb2YgYnVpbGRp bmcgYW4gZW50aXJlIHJlc3BvbnNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5pbiBtZW1vcnkuIFdpdGggYSBzdHJlYW1pbmcgZGVzaWduIHRoZSBz ZXJ2ZXIgZG9lc24ndCBrbm93IHdoYXQgd2lsbCBiZSBzZW50IGluIGFkdmFuY2Ugc288bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPml0IHN1cmUgZG9l c24ndCBrbm93IHRoZSBsZW5ndGggaW4gYWR2YW5jZS4mbmJzcDsgQ0JPUiBkb2VzIGEgZ3JlYXQg am9iIG9mIHN1cHBvcnRpbmcgYm90aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+dHlwZXMgb2Ygc2VydmVyIGRlc2lnbi4mbmJzcDsgTkVUQ09ORiBh bmQgSFRUUCBzdXBwb3J0IGNodW5raW5nLCB3aGljaCBpcyB1c2VkIGV4dGVuc2l2ZWx5IGJ5PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zdHJlYW1p bmcgc2VydmVycy4gVGhpcyBkcmFmdCBzaG91bGQgbWVudGlvbiBzdHJlYW1pbmcgYW5kIGV4cGxh aW4gd2h5IGl0IGlzIG5vdCBzdXBwb3J0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlpUUiZndDsgSWYgeW91IG1lYW4gYml0IHN0cmVhbWluZyBsaWtl IFRDUCwgSSB0aGluayBVRFAgY2Fubm90IHN1cHBvcnQgdGhpcy4gRG8geW91IGhhdmUgYW55IHBv aW50ZXIgb24gaG93IENCT1IgY2FuIHN1cHBvcnQgdGhlIHN0cmVhbWluZy4gQW5kIGhvdyBORVRD T05GIGFuZCBIVFRQDQogc3VwcG9ydCBjaHVua2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SW4gZ2Vu ZXJhbCwgSSB1bmRlcnN0YW5kIHRoaXMgcmVxdWlyZW1lbnQgd2l0aCBzbWFsbCBtZW1vcnkgb3Ig cGFydGlhbCBkYXRhLiBCdXQgZG8geW91IGhhdmUgYW55IHJlYWwgY2FzZSBpbiB0aGUgY29udGV4 dCBvZiBZQU5HIHB1c2g/IFNvIHRoYXQgd2UgY2FuIHdvcmsgb24NCiBhbiBvcHRpbWFsIGRlc2ln bi4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBnZW5lcmljIHdyYXBwZXJzIChsaWtl IGdOTUkgYW5kIFlBTkcgbm90aWZpY2F0aW9uIHNjaGVtYSkgZG8gbm90IGhhbmRsZSAmcXVvdDth bnlkYXRhJnF1b3Q7IHZlcnkgd2VsbCBhdCBhbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYmluYXJ5IHBheWxvYWQgYmVjb21lcyBtb3N0 bHkgSlNPTi4mbmJzcDsgT25seSBDQk9SJiM0MztTSUQgaGFuZGxlcyBhbnlkYXRhIGVmZmljaWVu dGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHNvbHV0aW9uIChtYXliZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHByb3RvY29sKSBz aG91bGQgY29uc2lkZXIgaG93IFlBTkcgYW55ZGF0YTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2lsbCBiZSB0cmFuc21pdHRlZCBlZmZpY2llbnRs eSBhbmQgY29udmVydGVkIGZyb20gYW55ZGF0YSB0byBhIHJlYWwgc2NoZW1hIGNvcnJlY3RseSBi eSB0aGUgcmVjZWl2ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPlJlZ2Fy ZHMsPGJyPg0KUm9iPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj5Gcm9tOjwvYj4gbmV0Y29uZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPktlbnQgV2F0c2VuPGJyPg0KPGI+U2VudDo8L2I+ IDA3IEF1Z3VzdCAyMDIwIDIxOjE2PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bmV0 Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRy YWZ0LXVueXRlLW5ldGNvbmYtdWRwLW5vdGlmPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiPlthcyBhIGNvbnRyaWJ1dG9yXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsmbmJzcDsxKSBpcyB0aGUgcHJvYmxlbSBpbXBvcnRh bnQgZm9yIHRoZSBORVRDT05GIFdHIHRvIHNvbHZlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+SSBiZWxp ZXZlIHRoYXQgaXQgaXMgaW1wb3J0YW50IHRvIGVuYWJsZSBwdWJsaXNoZXJzIHRvIHNlbmQgbm90 aWZpY2F0aW9ucyB1c2luZyBhIFVEUC1iYXNlZCB0cmFuc3BvcnQuICZuYnNwOyBUaGlzIGJlbGll ZiBpcyBiYXNlZCBvbiBteSBleHBlcmllbmNlIGZyb20gd2hlbiBhdCBKdW5pcGVyDQogZGVhbGlu ZyB3aXRoIHZlcnkgaGlnaC1lbmQgZmlyZXdhbGxzIHdpdGggZW5vcm1vdXMgbG9nIG91dHB1dC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iY29sb3I6YmxhY2siPkkgYmVsaWV2ZSB0aGF0IHRoZSZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+TkVUQ09ORiBXRyBpcyB0aGUgYXBwcm9wcmlhdGUgV0cgZm9yIHRoaXMgd29yaywg aGF2aW5nIGRlZmluZWQgUkZDIDg2MzkgKFNOKSwmbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPlJGQw0KIDg2NDAgKE5OKSwgYW5kJm5ic3A7PC9zcGFuPlJGQyA4NjUwIChSTikuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7MikgaXMgdGhlIGRyYWZ0IGEgc3VpdGFibGUgYmFz aXMgZm9yIHRoZSB3b3JrPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5JIGhhdmUgcmVhZCB0aGUgY3VycmVudCB2ZXJz aW9uIG9mIHRoZSBkcmFmdCBhbmQgZmluZCBpdCB0byBiZSBhIHJlYXNvbmFibGUgc3RhcnQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+UHJlc3Vt aW5nIHRoZSDigJxyZWNlaXZlci1pbnN0YW5jZXPigJ0gYXVnbWVudGF0aW9uIGRlZmluZWQgaW4m bmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRj b25mLWh0dHBzLW5vdGlmLTA0I3NlY3Rpb24tMyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYtMDQjc2VjdGlv bi0zPC9hPiZuYnNwO3Rha2VzDQogb2ZmLCB0aGUgbW9kdWxlIGRlZmluZWQgaW4gdGhpcyBkcmFm dCBzaG91bGQgYmUgdXBkYXRlZCB0byBhdWdtZW50IGludG8gaXQgaW5zdGVhZC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImNvbG9yOmJsYWNrIj5JIGFwcHJlY2lhdGUgU2VjdGlvbiA1IChBcHBsaWNhYmlsaXR5KSBub3Rp bmcgdGhhdCB0aGUgVURQLXRyYW5zcG9ydCBpcyBwcmltYXJpbHkgZm9yIHRoZSBkYXRhIHBsYW5l IChub3QgdGhlIGNvbnRyb2wgcGxhbmUpLCBhcyBpdCBkb2VzbuKAmXQNCiBtYXR0ZXIgc28gbXVj aCBpZiBkYXRhIHBsYW5lIG5vdGlmaWNhdGlvbnMgYXJlIGxvc3QuJm5ic3A7IFRoaXMgYWRkcmVz c2VzIChJIHRoaW5rKSB0aGUgaXNzdWUgdGhhdCBSb2IgU2hha2lyIHJhaXNlZCBiZWZvcmU6DQo8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9taW51dGVzLTEwMy1uZXRj b25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvbWlu dXRlcy0xMDMtbmV0Y29uZjwvYT4mbmJzcDsoc2VhcmNoIGZvciDigJxSb2IgU+KAnSkuJm5ic3A7 IFRoYXQgc2FpZCwgaXQgaXMgdW5jbGVhciB0byBtZSBob3cgYSByZWNlaXZlciBjb3VsZCBjb25m aWd1cmUgdGhpcyB3aGlsZSwgZS5nLiwgY29uZmlndXJpbmcgY29udHJvbA0KIHBsYW5lIG5vdGlm aWNhdGlvbnMgdG8gYmUgc2VudCB2aWEgYSBUQ1AtYmFzZWQgdHJhbnNwb3J0IHN1Y2ggYXMg4oCc aHR0cHMtbm90aWbigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj4zKSBy ZWdhcmRpbmcgSnVlcmdlbuKAmXMgcXVlc3Rpb25zOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsgYSkgSSBhbSB3aWxsaW5nIHRvIHN1YnN0YW50aWFsbHkgcmV2aWV3 IHRoZSBkcmFmdHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsgYikgSSBhbSZuYnNwO3dpbGxpbmcgdG8gY29udHJpYnV0ZSB0byB0aGUgZGlzY3Vzc2lv biBvZiBhbnkgaXNzdWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsgYykgSSBkbyBOT1QmbmJzcDtwbGFuIHRvIGltcGxlbWVudCB0aGUgdGVjaG5vbG9n eSBkZWZpbmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+S2VudDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5l dGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5uZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_07b991b1e32347b58ae4ef968cdffc7fhuaweicom_-- From nobody Thu Aug 27 12:14:20 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D7C3A1227 for ; Thu, 27 Aug 2020 12:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xye6eVOpAZ_y for ; Thu, 27 Aug 2020 12:14:16 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 D7FFA3A1229 for ; Thu, 27 Aug 2020 12:14:14 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id s9so3522612lfs.4 for ; Thu, 27 Aug 2020 12:14:14 -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=G9iXmbdrvZ6c4j8SnW4dt3NLnu/K7BkgGP+iy/1K/2w=; b=rto1m2z8VNGOn13hZcFDtoqOdDM9CbAnIHNBYV55dA/UADVE5d3R4v/vUXUEti2Aen vxhatqPBPjJI+Ptyuj8pkpFtgyjCivj3FQj1byekH6mgxiEaMR2DArviyg5F2licNYnt 5Xtng8NRU/An9GJdF5YESTSXmU6GpruD+eYHBdTx+dlDKVjDA6hBlDpcJqHBFqno3kop hY+1GbMiyl6S9kLAfSZjgrznNbyUKuiVP4477pub1xFxblvhEnSUg7tm+FkqDIgFci06 9r3qDeD0+l5MDwkKJxsau9LiDiwUSmuRGKcF3M1gjh9YJiwtTlspZfs3MrSUIqv/3BBv iVOw== 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=G9iXmbdrvZ6c4j8SnW4dt3NLnu/K7BkgGP+iy/1K/2w=; b=p1q91OtMg1eGnwEoiCT33da6zbHy/UB4ioBRfnyZxSDcSMQE3zkkveJ8tJ3QbDy2D/ GbxwSenHZ/+QtE85EanSnTfEL0aIGw4PRnD+Mv8oalI6kelaC0tFq/w4pGLfNog2YFjv pKcUvnR58xlw1P3L+msYKoVZC9a9OdfCLrb9MqxftWy6ltrwrpb3N6Jl1+0aubQ4C1a/ AMVqzDNie86IUykIt3Lz7PnjETOsYB3f7fZKtbI4znw9FpA+y6ZXBnCGhZHnsDd+9rZc bAIi5L7K1E7Gm/tQ8OQcg+H5YmLxAV41Dre1DIepXtzbY59d+MySb+DLsCrgutRIr5Sc u1vw== X-Gm-Message-State: AOAM5311mTlWWlM3xOBWpwqPurEQlCdM+rAwzwFd0meUwceCk+MyIZIT 3uSad7IcaxVHgQFlKz8MSr0DD9HdM1j6Pwg7PaIdEA== X-Google-Smtp-Source: ABdhPJwgp8oInTSv7G/nAmiMJCfzWGs/mjkVOVVttxSMaHyIpjywmKPmSjBtgjPiFH4ikUtyUYh9rL4rikNvoNk7AvQ= X-Received: by 2002:a19:3f87:: with SMTP id m129mr10275917lfa.44.1598555652654; Thu, 27 Aug 2020 12:14:12 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.com> <07b991b1e32347b58ae4ef968cdffc7f@huawei.com> In-Reply-To: <07b991b1e32347b58ae4ef968cdffc7f@huawei.com> From: Andy Bierman Date: Thu, 27 Aug 2020 12:14:01 -0700 Message-ID: To: Tianran Zhou Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d4a2de05ade0bda0" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 19:14:19 -0000 --000000000000d4a2de05ade0bda0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2020 at 6:50 PM Tianran Zhou wrote= : > Hi Andy, > > > > Thanks for your reply and suggestions. > > > > Cheers, > > Tianran > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, August 27, 2020 1:29 AM > *To:* Tianran Zhou > *Cc:* Rob Wilton (rwilton) ; > netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > > > > > On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou > wrote: > > Hi Andy, > > > > Please see inline. > > > > Tianran > > > > *From:* netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Wednesday, August 19, 2020 6:18 AM > *To:* Rob Wilton (rwilton) > *Cc:* netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > > > > > On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton) 40cisco.com@dmarc.ietf.org> wrote: > > Hi, > > > > [Also as a contributor] > > > > My comments are broadly similar to Kent=E2=80=99s. > > > > I believe that a UDP transport for dataplane telemetry where getting > accurate fresh data quickly is more important than getting every update. > This is particularly true if a subsequent notification will cover any los= t > values anyway (e.g. periodic statistics). > > > > > > agreed. > > There is also the resync-subscription mechanism to help recover from > missing data. > > > > [ztr] Our intention of using UDP is for data that do not care about > occasional loss. Typically for period data, and new data will anyway came > and update. > > Does the =E2=80=9Cresync-subscription=E2=80=9D mean the retransmission? H= ere do you want > to add the =E2=80=9Cresync-subscription mechanism=E2=80=9D when packet lo= ss is detected > in this draft? > > > > > > > > This is explained in RFC 8641 > > > > ZTR> Yes, I looked into RFC8641. It=E2=80=99s the same as what I understa= nd as > =E2=80=9Cretransmission=E2=80=9D. Two key points on =E2=80=9Cresync-subsc= ription=E2=80=9D from my > perspective. > > 1. =E2=80=9CThis RPC is supported only for on-change subscriptions previo= usly > established using an "establish-subscription" RPC.=E2=80=9D > > 2. =E2=80=9COn receipt, a publisher must either (1) accept the request an= d quickly > follow with a "push-update" or =E2=80=A6=E2=80=9D > > > > So, what=E2=80=99s your suggestion here? > > To support this? Or not support this and add text explicitly in the > document. > Nothing to add to this document. I was just noting that YANG Push does not rely on every push-change-update notification to be delivered. The application layer will re-synch by itself. > > > > I suspect that having a mechanism to allow for the telemetry data being > encrypted is probably also important. If the WG were to adopt a draft > without this, then as Benoit mentioned, I would have to test the water wi= th > the IESG to determine whether that would be acceptable. > > > > I suspect the lack of congestion control might get their attention as wel= l. > > > > [ztr] Yes, I agree, both security and congestion considerations need to b= e > described in the document. We have section 4 for congestion control. Do y= ou > have any idea on this? > > > > > > no -- I can't solve problems that IETF creates for itself. > > I think the draft says something like "do not use this protocol if > congestion is a concern". > > > > > > > > I also note that the draft allows for a GPB encoding of the telemetry > data, but I=E2=80=99m not aware of any formal standard encoding of YANG d= ata in > GPB, and there is a choice between whether the GPB encoding is generic fo= r > all YANG data, or specific GPB encodings are useful for the specific data > that is being encoded. > > > > > > > > I was confused by the same thing. > > Is there a YANG schema for a notification element that is used? > > Which means the .proto file is hardwired? > > If not then how does the receiver know what is sent? > > There are some technical issues that can be addressed if the draft is > adopted. > > > > [ztr] In this draft we only consider to include a code point to indicate > the GPB encoding. How to map YANG to GPB is out of the scope of this draf= t. > > In practice, there are several ways in my opinion. > > We can map YANG to proto firstly, and the proto actually describes the > data structure. I think YANG can almost translate to proto 1:1. > > We can also develop YANG to GPB directly, just like YANG to XML and JSON. > > In brief, the receiver can still know what is sent by YANG. > > > > > > > > I don't think the protocol should include placeholders for > proprietary solutions. > > Either leave out GPB completely or support it in an interoperable way. > > > > ZTR> We have no position on this. If the WG agreed, we would like to leav= e > out GPB. > What about just adding a 32-bit report-id field to the header This is enough. Assignment of the IDs is out of scope. > > > More issues: > > > > This protocol is not usable by servers that stream data instead of > building an entire response > > in memory. With a streaming design the server doesn't know what will be > sent in advance so > > it sure doesn't know the length in advance. CBOR does a great job of > supporting both > > types of server design. NETCONF and HTTP support chunking, which is used > extensively by > > streaming servers. This draft should mention streaming and explain why it > is not supported. > > > > ZTR> If you mean bit streaming like TCP, I think UDP cannot support this. > Do you have any pointer on how CBOR can support the streaming. And how > NETCONF and HTTP support chunking. > > In general, I understand this requirement with small memory or partial > data. But do you have any real case in the context of YANG push? So that = we > can work on an optimal design. > I think it is OK to say that a server is expected to build an entire response and the length needs to be known in advance, if fragmentation is not enabled. A server can stream data OK if UDP fragmentation is enabled. CoAP uses the Block option to support streaming. > > > The generic wrappers (like gNMI and YANG notification schema) do not > handle "anydata" very well at all. > > The binary payload becomes mostly JSON. Only CBOR+SID handles anydata > efficiently. > > The solution (maybe outside the scope of this protocol) should consider > how YANG anydata > > will be transmitted efficiently and converted from anydata to a real > schema correctly by the receiver. > > > > > > > > > > Regards, > Rob > > > > > > Andy > > > > > > Andy > Andy > > > > > > > *From:* netconf *On Behalf Of *Kent Watsen > *Sent:* 07 August 2020 21:16 > *To:* netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > [as a contributor] > > > > > > 1) is the problem important for the NETCONF WG to solve? > > > > I believe that it is important to enable publishers to send notifications > using a UDP-based transport. This belief is based on my experience from > when at Juniper dealing with very high-end firewalls with enormous log > output. > > > > I believe that the NETCONF WG is the appropriate WG for this work, having > defined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN). > > > > > > 2) is the draft a suitable basis for the work? > > > > I have read the current version of the draft and find it to be a > reasonable start. > > > > Presuming the =E2=80=9Creceiver-instances=E2=80=9D augmentation defined i= n > https://tools.ietf.org/html/draft-ietf-netconf-https-notif-04#section-3 t= akes > off, the module defined in this draft should be updated to augment into i= t > instead. > > > > I appreciate Section 5 (Applicability) noting that the UDP-transport is > primarily for the data plane (not the control plane), as it doesn=E2=80= =99t matter > so much if data plane notifications are lost. This addresses (I think) t= he > issue that Rob Shakir raised before: > https://datatracker.ietf.org/doc/minutes-103-netconf (search for =E2=80= =9CRob > S=E2=80=9D). That said, it is unclear to me how a receiver could configu= re this > while, e.g., configuring control plane notifications to be sent via a > TCP-based transport such as =E2=80=9Chttps-notif=E2=80=9D. > > > > > > 3) regarding Juergen=E2=80=99s questions: > > > > a) I am willing to substantially review the drafts. > > b) I am willing to contribute to the discussion of any issue. > > c) I do NOT plan to implement the technology defined. > > > > > > > > Kent > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --000000000000d4a2de05ade0bda0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 26, 2020 at 6:50 PM Tianr= an Zhou <zhoutianran@huawei.co= m> wrote:

Hi Andy,

=C2=A0

Thanks for your reply and suggestions.

=C2=A0

Cheers,

Tianran

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, August 27, 2020 1:29 AM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>; netconf@ietf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

=C2=A0

=C2=A0

On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou <zhoutianran@huawei= .com> wrote:

Hi Andy,

=C2=A0

Please see inline.

=C2=A0

Tianran

=C2=A0

From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Wednesday, August 19, 2020 6:18 AM
To: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>
Cc: netconf@ie= tf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

=C2=A0

=C2=A0

On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton)= <rwilton=3D40cisco.com@dmarc.ietf.org> wrote:

Hi,

=C2=A0

[Also as a contributor]<= u>

=C2=A0

My comments are broadly similar= to Kent=E2=80=99s.

=C2=A0

I believe that a UDP transport = for dataplane telemetry where getting accurate fresh data quickly is more i= mportant than getting every update.=C2=A0 This is particularly true if a subsequent notification will cover any lost values anyway (e.g. = periodic statistics).

=C2=A0

=C2=A0

agreed.

There is also the resync-subscription mechanism to h= elp recover from missing data.

=C2=A0

[ztr] Our intention of using UDP is for data that do not care abo= ut occasional loss. Typically for period data, and new data will anyway came and update.

Does the =E2=80=9Cresync-subscription=E2=80=9D mean the retransmission? Here do you want to add the =E2=80=9Cresync-subscription mechanism<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif">=E2=80=9D when= packet loss is detected in this draft?

=C2=A0

=C2=A0

=C2=A0

This is explained in RFC 8641

=C2=A0

ZTR> Yes, I looked into RFC8641. It=E2=80= =99s the same as what I understand as =E2=80=9Cretransmission=E2=80=9D. Two= key points on =E2=80=9Cresync-subscription=E2=80=9D from my perspective.

1. =E2=80=9CThis RPC is supported only for o= n-change subscriptions previously established using an "establish-subs= cription" RPC.=E2=80=9D

2. =E2=80=9COn receipt, a publisher must eit= her (1) accept the request and quickly follow with a "push-update"= ; or =E2=80=A6=E2=80=9D

=C2=A0

So, what=E2=80=99s your suggestion here?

To support this? Or not support this and add= text explicitly in the document. =C2=A0


=

Nothing to add to this document.
I was just n= oting that YANG Push does not rely on every push-change-update
no= tification to be delivered.=C2=A0 The application layer will re-synch by it= self.


=C2=A0

=C2=A0

I suspect that having a mechani= sm to allow for the telemetry data being encrypted is probably also importa= nt.=C2=A0 If the WG were to adopt a draft without this, then as Benoit mentioned, I would have to test the water with the IESG to deter= mine whether that would be acceptable.

=C2=A0

I suspect the lack of congestion control might get t= heir attention as well.

=C2=A0

[ztr] Yes, I agree, both security and congestion considerations n= eed to be described in the document. We have section 4 for congestion control. Do you have any idea on this?

=C2=A0

=C2=A0

no -- I can't solve problems that IETF creates f= or itself.

I think the draft says something like "do not u= se this protocol if congestion is a concern".

=C2=A0

=C2=A0

=C2=A0

I also note that the draft allo= ws for a GPB encoding of the telemetry data, but I=E2=80=99m not aware of a= ny formal standard encoding of YANG data in GPB, and there is a choice between whether the GPB encoding is generic for all YANG data, or= specific GPB encodings are useful for the specific data that is being enco= ded.

=C2=A0

=C2=A0

=C2=A0

I was confused by the same thing.

Is there a YANG schema for a notification element th= at is used?

Which means the .proto file is hardwired?<= /u>

If not then how does the receiver know what is sent?=

There are some technical issues that can be addresse= d if the draft is adopted.

=C2=A0

[ztr] In this draft we only consider to include a code point to i= ndicate the GPB encoding. How to map YANG to GPB is out of the scope of this draft.

In practice, there are several ways in my opinion.<= u>

We can map YANG to proto firstly, and the proto actually describe= s the data structure. I think YANG can almost translate to proto 1:1.

We can also develop YANG to GPB directly, just like YANG to XML a= nd JSON.

In brief, the receiver can still know what is sent by YANG.

=C2=A0

=C2=A0

=C2=A0

I don't think the protocol should include placeh= olders for proprietary=C2=A0solutions.

Either leave out GPB completely or support it in an = interoperable way.

=C2=A0

ZTR> We have no position on this. If the = WG agreed, we would like to leave out GPB.



What about just add= ing a 32-bit report-id field to the header
This is enough. Assign= ment of the IDs is out of scope.

=C2=A0

=C2=A0

More issues:

=C2=A0

This protocol is not usable by servers that stream d= ata instead of building an entire response

in memory. With a streaming design the server doesn&= #39;t know what will be sent in advance so

it sure doesn't know the length in advance.=C2= =A0 CBOR does a great job of supporting both

types of server design.=C2=A0 NETCONF and HTTP suppo= rt chunking, which is used extensively by

streaming servers. This draft should mention streami= ng and explain why it is not supported.

=C2=A0

ZTR> If you mean bit streaming like TCP, = I think UDP cannot support this. Do you have any pointer on how CBOR can su= pport the streaming. And how NETCONF and HTTP support chunking.

In general, I understand this requirement wi= th small memory or partial data. But do you have any real case in the conte= xt of YANG push? So that we can work on an optimal design.



I think it is OK to say that a server is e= xpected to build an entire response
and the length needs to be kn= own in advance, if fragmentation is not enabled.
A server can str= eam data OK if UDP fragmentation is enabled. CoAP uses the Block option
to support streaming.



=C2=A0

=C2=A0

The generic wrappers (like gNMI and YANG notificatio= n schema) do not handle "anydata" very well at all.=

The binary payload becomes mostly JSON.=C2=A0 Only C= BOR+SID handles anydata efficiently.

The solution (maybe outside the scope of this protoc= ol) should consider how YANG anydata

will be transmitted efficiently and converted from a= nydata to a real schema correctly by the receiver.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Regards,
Rob

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

Andy

<= div>


Andy
=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 07 August 2020 21:16
To: netconf@ie= tf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

[as a contributor]

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A01) is the pro= blem important for the NETCONF WG to solve?

=C2=A0

I believe that it is important = to enable publishers to send notifications using a UDP-based transport. =C2= =A0 This belief is based on my experience from when at Juniper dealing with very high-end firewalls with enormous log output.

=C2=A0

I believe= that the=C2=A0NETCONF WG is the appropriate WG= for this work, having defined RFC 8639 (SN),=C2=A0RFC 8640 (NN), and=C2=A0RFC 8650 (RN).

=C2=A0

= =C2=A0

=C2=A0=C2=A0=C2=A02) is the dra= ft a suitable basis for the work?

=C2=A0

I have read the current version= of the draft and find it to be a reasonable start.

=C2=A0

=C2=A0

I appreci= ate Section 5 (Applicability) noting that the UDP-transport is primarily fo= r the data plane (not the control plane), as it doesn=E2=80=99t matter so much if data plane notifications are lost.=C2=A0 This addresses = (I think) the issue that Rob Shakir raised before: https://datatracker.ietf.org/doc/minutes-103-netconf=C2=A0(sear= ch for =E2=80=9CRob S=E2=80=9D).=C2=A0 That said, it is unclear to me how a= receiver could configure this while, e.g., configuring control plane notifications to be sent via a TCP-based transport such as =E2=80=9C= https-notif=E2=80=9D.

=C2=A0

=C2=A0

3) regard= ing Juergen=E2=80=99s questions:

=C2=A0

=C2=A0 a)= I am willing to substantially review the drafts.

=C2=A0 b)= I am=C2=A0willing to contribute to the discussion of any issue.<= /u>

=C2=A0 c)= I do NOT=C2=A0plan to implement the technology defined.

=C2=A0

=C2=A0

=C2=A0

Kent

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

--000000000000d4a2de05ade0bda0-- From nobody Fri Aug 28 02:01:29 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED23C3A0E56 for ; Fri, 28 Aug 2020 02:01: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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M95lnWjD5DSB for ; Fri, 28 Aug 2020 02:01:25 -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 B4AA33A0E50 for ; Fri, 28 Aug 2020 02:01:24 -0700 (PDT) Received: from lhreml733-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id F08C27E48F4699702100 for ; Fri, 28 Aug 2020 10:01:21 +0100 (IST) Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml733-chm.china.huawei.com (10.201.108.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 28 Aug 2020 10:01:20 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 28 Aug 2020 17:01:18 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Fri, 28 Aug 2020 17:01:18 +0800 From: Tianran Zhou To: Andy Bierman CC: "Rob Wilton (rwilton)" , "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif Thread-Index: AQHWa3XJ0mBLbRaES02VUjy2aRVTDKkskgcAgBDbzICAAJAcAIAMIxLggAAetwCAAQUpEIAAqoiAgAFn/xA= Date: Fri, 28 Aug 2020 09:01:18 +0000 Message-ID: <7b77f6ff39d4430aa549c9b53b902dde@huawei.com> References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.com> <07b991b1e32347b58ae4ef968cdffc7f@huawei.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.108.243.128] Content-Type: multipart/alternative; boundary="_000_7b77f6ff39d4430aa549c9b53b902ddehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 09:01:28 -0000 --_000_7b77f6ff39d4430aa549c9b53b902ddehuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhhbmtzIGFnYWluIGZvciB5b3VyIGZ1cnRoZXIgY29tbWVudHMuDQoNClRp YW5yYW4NCg0KRnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0K U2VudDogRnJpZGF5LCBBdWd1c3QgMjgsIDIwMjAgMzoxNCBBTQ0KVG86IFRpYW5yYW4gWmhvdSA8 emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4NCkNjOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRv bj00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz47IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0LXVueXRlLW5ldGNv bmYtdWRwLW5vdGlmDQoNCg0KDQpPbiBXZWQsIEF1ZyAyNiwgMjAyMCBhdCA2OjUwIFBNIFRpYW5y YW4gWmhvdSA8emhvdXRpYW5yYW5AaHVhd2VpLmNvbTxtYWlsdG86emhvdXRpYW5yYW5AaHVhd2Vp LmNvbT4+IHdyb3RlOg0KSGkgQW5keSwNCg0KVGhhbmtzIGZvciB5b3VyIHJlcGx5IGFuZCBzdWdn ZXN0aW9ucy4NCg0KQ2hlZXJzLA0KVGlhbnJhbg0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0 bzphbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT5dDQpTZW50OiBU aHVyc2RheSwgQXVndXN0IDI3LCAyMDIwIDE6MjkgQU0NClRvOiBUaWFucmFuIFpob3UgPHpob3V0 aWFucmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20+Pg0KQ2M6IFJv YiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPG1h aWx0bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4+OyBuZXRjb25mQGlldGYub3JnPG1haWx0 bzpuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0 YWJpbGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0Y29uZi11ZHAtbm90aWYNCg0KDQoNCk9uIFdlZCwg QXVnIDI2LCAyMDIwIGF0IDE6MTcgQU0gVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWku Y29tPG1haWx0bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSBBbmR5LA0KDQpQ bGVhc2Ugc2VlIGlubGluZS4NCg0KVGlhbnJhbg0KDQpGcm9tOiBuZXRjb25mIFttYWlsdG86bmV0 Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YgQW5keSBCaWVybWFuDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxOSwgMjAy MCA2OjE4IEFNDQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b249NDBjaXNjby5jb21A ZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPj4NCkNjOiBu ZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtu ZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0Y29uZi11ZHAt bm90aWYNCg0KDQoNCk9uIFR1ZSwgQXVnIDE4LCAyMDIwIGF0IDY6NDIgQU0gUm9iIFdpbHRvbiAo cndpbHRvbikgPHJ3aWx0b249NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwY2lz Y28uY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpIaSwNCg0KW0Fsc28gYXMgYSBjb250cmli dXRvcl0NCg0KTXkgY29tbWVudHMgYXJlIGJyb2FkbHkgc2ltaWxhciB0byBLZW504oCZcy4NCg0K SSBiZWxpZXZlIHRoYXQgYSBVRFAgdHJhbnNwb3J0IGZvciBkYXRhcGxhbmUgdGVsZW1ldHJ5IHdo ZXJlIGdldHRpbmcgYWNjdXJhdGUgZnJlc2ggZGF0YSBxdWlja2x5IGlzIG1vcmUgaW1wb3J0YW50 IHRoYW4gZ2V0dGluZyBldmVyeSB1cGRhdGUuICBUaGlzIGlzIHBhcnRpY3VsYXJseSB0cnVlIGlm IGEgc3Vic2VxdWVudCBub3RpZmljYXRpb24gd2lsbCBjb3ZlciBhbnkgbG9zdCB2YWx1ZXMgYW55 d2F5IChlLmcuIHBlcmlvZGljIHN0YXRpc3RpY3MpLg0KDQoNCmFncmVlZC4NClRoZXJlIGlzIGFs c28gdGhlIHJlc3luYy1zdWJzY3JpcHRpb24gbWVjaGFuaXNtIHRvIGhlbHAgcmVjb3ZlciBmcm9t IG1pc3NpbmcgZGF0YS4NCg0KW3p0cl0gT3VyIGludGVudGlvbiBvZiB1c2luZyBVRFAgaXMgZm9y IGRhdGEgdGhhdCBkbyBub3QgY2FyZSBhYm91dCBvY2Nhc2lvbmFsIGxvc3MuIFR5cGljYWxseSBm b3IgcGVyaW9kIGRhdGEsIGFuZCBuZXcgZGF0YSB3aWxsIGFueXdheSBjYW1lIGFuZCB1cGRhdGUu DQpEb2VzIHRoZSDigJxyZXN5bmMtc3Vic2NyaXB0aW9u4oCdIG1lYW4gdGhlIHJldHJhbnNtaXNz aW9uPyBIZXJlIGRvIHlvdSB3YW50IHRvIGFkZCB0aGUg4oCccmVzeW5jLXN1YnNjcmlwdGlvbiBt ZWNoYW5pc23igJ0gd2hlbiBwYWNrZXQgbG9zcyBpcyBkZXRlY3RlZCBpbiB0aGlzIGRyYWZ0Pw0K DQoNCg0KVGhpcyBpcyBleHBsYWluZWQgaW4gUkZDIDg2NDENCg0KWlRSPiBZZXMsIEkgbG9va2Vk IGludG8gUkZDODY0MS4gSXTigJlzIHRoZSBzYW1lIGFzIHdoYXQgSSB1bmRlcnN0YW5kIGFzIOKA nHJldHJhbnNtaXNzaW9u4oCdLiBUd28ga2V5IHBvaW50cyBvbiDigJxyZXN5bmMtc3Vic2NyaXB0 aW9u4oCdIGZyb20gbXkgcGVyc3BlY3RpdmUuDQoxLiDigJxUaGlzIFJQQyBpcyBzdXBwb3J0ZWQg b25seSBmb3Igb24tY2hhbmdlIHN1YnNjcmlwdGlvbnMgcHJldmlvdXNseSBlc3RhYmxpc2hlZCB1 c2luZyBhbiAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIgUlBDLuKAnQ0KMi4g4oCcT24gcmVjZWlw dCwgYSBwdWJsaXNoZXIgbXVzdCBlaXRoZXIgKDEpIGFjY2VwdCB0aGUgcmVxdWVzdCBhbmQgcXVp Y2tseSBmb2xsb3cgd2l0aCBhICJwdXNoLXVwZGF0ZSIgb3Ig4oCm4oCdDQoNClNvLCB3aGF04oCZ cyB5b3VyIHN1Z2dlc3Rpb24gaGVyZT8NClRvIHN1cHBvcnQgdGhpcz8gT3Igbm90IHN1cHBvcnQg dGhpcyBhbmQgYWRkIHRleHQgZXhwbGljaXRseSBpbiB0aGUgZG9jdW1lbnQuDQoNCg0KTm90aGlu ZyB0byBhZGQgdG8gdGhpcyBkb2N1bWVudC4NCkkgd2FzIGp1c3Qgbm90aW5nIHRoYXQgWUFORyBQ dXNoIGRvZXMgbm90IHJlbHkgb24gZXZlcnkgcHVzaC1jaGFuZ2UtdXBkYXRlDQpub3RpZmljYXRp b24gdG8gYmUgZGVsaXZlcmVkLiAgVGhlIGFwcGxpY2F0aW9uIGxheWVyIHdpbGwgcmUtc3luY2gg YnkgaXRzZWxmLg0KDQpaVFI+IEFncmVlZC4gVGhhbmtzLg0KDQoNCkkgc3VzcGVjdCB0aGF0IGhh dmluZyBhIG1lY2hhbmlzbSB0byBhbGxvdyBmb3IgdGhlIHRlbGVtZXRyeSBkYXRhIGJlaW5nIGVu Y3J5cHRlZCBpcyBwcm9iYWJseSBhbHNvIGltcG9ydGFudC4gIElmIHRoZSBXRyB3ZXJlIHRvIGFk b3B0IGEgZHJhZnQgd2l0aG91dCB0aGlzLCB0aGVuIGFzIEJlbm9pdCBtZW50aW9uZWQsIEkgd291 bGQgaGF2ZSB0byB0ZXN0IHRoZSB3YXRlciB3aXRoIHRoZSBJRVNHIHRvIGRldGVybWluZSB3aGV0 aGVyIHRoYXQgd291bGQgYmUgYWNjZXB0YWJsZS4NCg0KSSBzdXNwZWN0IHRoZSBsYWNrIG9mIGNv bmdlc3Rpb24gY29udHJvbCBtaWdodCBnZXQgdGhlaXIgYXR0ZW50aW9uIGFzIHdlbGwuDQoNClt6 dHJdIFllcywgSSBhZ3JlZSwgYm90aCBzZWN1cml0eSBhbmQgY29uZ2VzdGlvbiBjb25zaWRlcmF0 aW9ucyBuZWVkIHRvIGJlIGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQuIFdlIGhhdmUgc2VjdGlv biA0IGZvciBjb25nZXN0aW9uIGNvbnRyb2wuIERvIHlvdSBoYXZlIGFueSBpZGVhIG9uIHRoaXM/ DQoNCg0Kbm8gLS0gSSBjYW4ndCBzb2x2ZSBwcm9ibGVtcyB0aGF0IElFVEYgY3JlYXRlcyBmb3Ig aXRzZWxmLg0KSSB0aGluayB0aGUgZHJhZnQgc2F5cyBzb21ldGhpbmcgbGlrZSAiZG8gbm90IHVz ZSB0aGlzIHByb3RvY29sIGlmIGNvbmdlc3Rpb24gaXMgYSBjb25jZXJuIi4NCg0KDQoNCkkgYWxz byBub3RlIHRoYXQgdGhlIGRyYWZ0IGFsbG93cyBmb3IgYSBHUEIgZW5jb2Rpbmcgb2YgdGhlIHRl bGVtZXRyeSBkYXRhLCBidXQgSeKAmW0gbm90IGF3YXJlIG9mIGFueSBmb3JtYWwgc3RhbmRhcmQg ZW5jb2Rpbmcgb2YgWUFORyBkYXRhIGluIEdQQiwgYW5kIHRoZXJlIGlzIGEgY2hvaWNlIGJldHdl ZW4gd2hldGhlciB0aGUgR1BCIGVuY29kaW5nIGlzIGdlbmVyaWMgZm9yIGFsbCBZQU5HIGRhdGEs IG9yIHNwZWNpZmljIEdQQiBlbmNvZGluZ3MgYXJlIHVzZWZ1bCBmb3IgdGhlIHNwZWNpZmljIGRh dGEgdGhhdCBpcyBiZWluZyBlbmNvZGVkLg0KDQoNCg0KSSB3YXMgY29uZnVzZWQgYnkgdGhlIHNh bWUgdGhpbmcuDQpJcyB0aGVyZSBhIFlBTkcgc2NoZW1hIGZvciBhIG5vdGlmaWNhdGlvbiBlbGVt ZW50IHRoYXQgaXMgdXNlZD8NCldoaWNoIG1lYW5zIHRoZSAucHJvdG8gZmlsZSBpcyBoYXJkd2ly ZWQ/DQpJZiBub3QgdGhlbiBob3cgZG9lcyB0aGUgcmVjZWl2ZXIga25vdyB3aGF0IGlzIHNlbnQ/ DQpUaGVyZSBhcmUgc29tZSB0ZWNobmljYWwgaXNzdWVzIHRoYXQgY2FuIGJlIGFkZHJlc3NlZCBp ZiB0aGUgZHJhZnQgaXMgYWRvcHRlZC4NCg0KW3p0cl0gSW4gdGhpcyBkcmFmdCB3ZSBvbmx5IGNv bnNpZGVyIHRvIGluY2x1ZGUgYSBjb2RlIHBvaW50IHRvIGluZGljYXRlIHRoZSBHUEIgZW5jb2Rp bmcuIEhvdyB0byBtYXAgWUFORyB0byBHUEIgaXMgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGlzIGRy YWZ0Lg0KSW4gcHJhY3RpY2UsIHRoZXJlIGFyZSBzZXZlcmFsIHdheXMgaW4gbXkgb3Bpbmlvbi4N CldlIGNhbiBtYXAgWUFORyB0byBwcm90byBmaXJzdGx5LCBhbmQgdGhlIHByb3RvIGFjdHVhbGx5 IGRlc2NyaWJlcyB0aGUgZGF0YSBzdHJ1Y3R1cmUuIEkgdGhpbmsgWUFORyBjYW4gYWxtb3N0IHRy YW5zbGF0ZSB0byBwcm90byAxOjEuDQpXZSBjYW4gYWxzbyBkZXZlbG9wIFlBTkcgdG8gR1BCIGRp cmVjdGx5LCBqdXN0IGxpa2UgWUFORyB0byBYTUwgYW5kIEpTT04uDQpJbiBicmllZiwgdGhlIHJl Y2VpdmVyIGNhbiBzdGlsbCBrbm93IHdoYXQgaXMgc2VudCBieSBZQU5HLg0KDQoNCg0KSSBkb24n dCB0aGluayB0aGUgcHJvdG9jb2wgc2hvdWxkIGluY2x1ZGUgcGxhY2Vob2xkZXJzIGZvciBwcm9w cmlldGFyeSBzb2x1dGlvbnMuDQpFaXRoZXIgbGVhdmUgb3V0IEdQQiBjb21wbGV0ZWx5IG9yIHN1 cHBvcnQgaXQgaW4gYW4gaW50ZXJvcGVyYWJsZSB3YXkuDQoNClpUUj4gV2UgaGF2ZSBubyBwb3Np dGlvbiBvbiB0aGlzLiBJZiB0aGUgV0cgYWdyZWVkLCB3ZSB3b3VsZCBsaWtlIHRvIGxlYXZlIG91 dCBHUEIuDQoNCg0KV2hhdCBhYm91dCBqdXN0IGFkZGluZyBhIDMyLWJpdCByZXBvcnQtaWQgZmll bGQgdG8gdGhlIGhlYWRlcg0KVGhpcyBpcyBlbm91Z2guIEFzc2lnbm1lbnQgb2YgdGhlIElEcyBp cyBvdXQgb2Ygc2NvcGUuDQoNCiBaVFI+IFNvcnJ5LCBJIGRpZCBub3QgZ2V0IHlvdSBvbiB3aGF0 4oCZcyB0aGlzIDMyLWJpdCByZXBvcnQtaWQ/IFdlIGhhdmUgYSA0IGJpdCBlbmNvZGluZyB0eXBl IGZpZWxkLCB3aGljaCBjYW4gc3VwcG9ydCAxNiBlbmNvZGluZ3MuIFdlIGNhbiBzZXQgdGhpcyBh cyBhIHJlZ2lzdHJ5IGFuZCBkZWZlciB0aGUgYXNzaWdubWVudCBvZiBHUEIuDQoNCg0KDQpNb3Jl IGlzc3VlczoNCg0KVGhpcyBwcm90b2NvbCBpcyBub3QgdXNhYmxlIGJ5IHNlcnZlcnMgdGhhdCBz dHJlYW0gZGF0YSBpbnN0ZWFkIG9mIGJ1aWxkaW5nIGFuIGVudGlyZSByZXNwb25zZQ0KaW4gbWVt b3J5LiBXaXRoIGEgc3RyZWFtaW5nIGRlc2lnbiB0aGUgc2VydmVyIGRvZXNuJ3Qga25vdyB3aGF0 IHdpbGwgYmUgc2VudCBpbiBhZHZhbmNlIHNvDQppdCBzdXJlIGRvZXNuJ3Qga25vdyB0aGUgbGVu Z3RoIGluIGFkdmFuY2UuICBDQk9SIGRvZXMgYSBncmVhdCBqb2Igb2Ygc3VwcG9ydGluZyBib3Ro DQp0eXBlcyBvZiBzZXJ2ZXIgZGVzaWduLiAgTkVUQ09ORiBhbmQgSFRUUCBzdXBwb3J0IGNodW5r aW5nLCB3aGljaCBpcyB1c2VkIGV4dGVuc2l2ZWx5IGJ5DQpzdHJlYW1pbmcgc2VydmVycy4gVGhp cyBkcmFmdCBzaG91bGQgbWVudGlvbiBzdHJlYW1pbmcgYW5kIGV4cGxhaW4gd2h5IGl0IGlzIG5v dCBzdXBwb3J0ZWQuDQoNClpUUj4gSWYgeW91IG1lYW4gYml0IHN0cmVhbWluZyBsaWtlIFRDUCwg SSB0aGluayBVRFAgY2Fubm90IHN1cHBvcnQgdGhpcy4gRG8geW91IGhhdmUgYW55IHBvaW50ZXIg b24gaG93IENCT1IgY2FuIHN1cHBvcnQgdGhlIHN0cmVhbWluZy4gQW5kIGhvdyBORVRDT05GIGFu ZCBIVFRQIHN1cHBvcnQgY2h1bmtpbmcuDQpJbiBnZW5lcmFsLCBJIHVuZGVyc3RhbmQgdGhpcyBy ZXF1aXJlbWVudCB3aXRoIHNtYWxsIG1lbW9yeSBvciBwYXJ0aWFsIGRhdGEuIEJ1dCBkbyB5b3Ug aGF2ZSBhbnkgcmVhbCBjYXNlIGluIHRoZSBjb250ZXh0IG9mIFlBTkcgcHVzaD8gU28gdGhhdCB3 ZSBjYW4gd29yayBvbiBhbiBvcHRpbWFsIGRlc2lnbi4NCg0KDQpJIHRoaW5rIGl0IGlzIE9LIHRv IHNheSB0aGF0IGEgc2VydmVyIGlzIGV4cGVjdGVkIHRvIGJ1aWxkIGFuIGVudGlyZSByZXNwb25z ZQ0KYW5kIHRoZSBsZW5ndGggbmVlZHMgdG8gYmUga25vd24gaW4gYWR2YW5jZSwgaWYgZnJhZ21l bnRhdGlvbiBpcyBub3QgZW5hYmxlZC4NCkEgc2VydmVyIGNhbiBzdHJlYW0gZGF0YSBPSyBpZiBV RFAgZnJhZ21lbnRhdGlvbiBpcyBlbmFibGVkLiBDb0FQIHVzZXMgdGhlIEJsb2NrIG9wdGlvbg0K dG8gc3VwcG9ydCBzdHJlYW1pbmcuDQoNClpUUj4gR290IGl0LiBZZXMsIHRoaXMgZHJhZnQgZW5h YmxlcyBVRFAgZnJhZ21lbnRhdGlvbiB3aGljaCBjYW4gc3VwcG9ydCBkYXRhIHN0cmVhbWluZy4N Cg0KDQoNClRoZSBnZW5lcmljIHdyYXBwZXJzIChsaWtlIGdOTUkgYW5kIFlBTkcgbm90aWZpY2F0 aW9uIHNjaGVtYSkgZG8gbm90IGhhbmRsZSAiYW55ZGF0YSIgdmVyeSB3ZWxsIGF0IGFsbC4NClRo ZSBiaW5hcnkgcGF5bG9hZCBiZWNvbWVzIG1vc3RseSBKU09OLiAgT25seSBDQk9SK1NJRCBoYW5k bGVzIGFueWRhdGEgZWZmaWNpZW50bHkuDQpUaGUgc29sdXRpb24gKG1heWJlIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoaXMgcHJvdG9jb2wpIHNob3VsZCBjb25zaWRlciBob3cgWUFORyBhbnlkYXRh DQp3aWxsIGJlIHRyYW5zbWl0dGVkIGVmZmljaWVudGx5IGFuZCBjb252ZXJ0ZWQgZnJvbSBhbnlk YXRhIHRvIGEgcmVhbCBzY2hlbWEgY29ycmVjdGx5IGJ5IHRoZSByZWNlaXZlci4NCg0KDQoNCg0K UmVnYXJkcywNClJvYg0KDQoNCkFuZHkNCg0KDQpBbmR5DQoNCg0KDQpBbmR5DQoNCg0KDQoNCkZy b206IG5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEtlbnQgV2F0c2VuDQpTZW50OiAwNyBBdWd1c3Qg MjAyMCAyMToxNg0KVG86IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW25ldGNvbmZdIEFkb3B0aW9uLXN1aXRhYmlsaXR5IGZvciBkcmFmdC11 bnl0ZS1uZXRjb25mLXVkcC1ub3RpZg0KDQpbYXMgYSBjb250cmlidXRvcl0NCg0KDQogICAxKSBp cyB0aGUgcHJvYmxlbSBpbXBvcnRhbnQgZm9yIHRoZSBORVRDT05GIFdHIHRvIHNvbHZlPw0KDQpJ IGJlbGlldmUgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdG8gZW5hYmxlIHB1Ymxpc2hlcnMgdG8gc2Vu ZCBub3RpZmljYXRpb25zIHVzaW5nIGEgVURQLWJhc2VkIHRyYW5zcG9ydC4gICBUaGlzIGJlbGll ZiBpcyBiYXNlZCBvbiBteSBleHBlcmllbmNlIGZyb20gd2hlbiBhdCBKdW5pcGVyIGRlYWxpbmcg d2l0aCB2ZXJ5IGhpZ2gtZW5kIGZpcmV3YWxscyB3aXRoIGVub3Jtb3VzIGxvZyBvdXRwdXQuDQoN CkkgYmVsaWV2ZSB0aGF0IHRoZSBORVRDT05GIFdHIGlzIHRoZSBhcHByb3ByaWF0ZSBXRyBmb3Ig dGhpcyB3b3JrLCBoYXZpbmcgZGVmaW5lZCBSRkMgODYzOSAoU04pLCBSRkMgODY0MCAoTk4pLCBh bmQgUkZDIDg2NTAgKFJOKS4NCg0KDQogICAyKSBpcyB0aGUgZHJhZnQgYSBzdWl0YWJsZSBiYXNp cyBmb3IgdGhlIHdvcms/DQoNCkkgaGF2ZSByZWFkIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhl IGRyYWZ0IGFuZCBmaW5kIGl0IHRvIGJlIGEgcmVhc29uYWJsZSBzdGFydC4NCg0KUHJlc3VtaW5n IHRoZSDigJxyZWNlaXZlci1pbnN0YW5jZXPigJ0gYXVnbWVudGF0aW9uIGRlZmluZWQgaW4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0w NCNzZWN0aW9uLTMgdGFrZXMgb2ZmLCB0aGUgbW9kdWxlIGRlZmluZWQgaW4gdGhpcyBkcmFmdCBz aG91bGQgYmUgdXBkYXRlZCB0byBhdWdtZW50IGludG8gaXQgaW5zdGVhZC4NCg0KSSBhcHByZWNp YXRlIFNlY3Rpb24gNSAoQXBwbGljYWJpbGl0eSkgbm90aW5nIHRoYXQgdGhlIFVEUC10cmFuc3Bv cnQgaXMgcHJpbWFyaWx5IGZvciB0aGUgZGF0YSBwbGFuZSAobm90IHRoZSBjb250cm9sIHBsYW5l KSwgYXMgaXQgZG9lc27igJl0IG1hdHRlciBzbyBtdWNoIGlmIGRhdGEgcGxhbmUgbm90aWZpY2F0 aW9ucyBhcmUgbG9zdC4gIFRoaXMgYWRkcmVzc2VzIChJIHRoaW5rKSB0aGUgaXNzdWUgdGhhdCBS b2IgU2hha2lyIHJhaXNlZCBiZWZvcmU6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L21pbnV0ZXMtMTAzLW5ldGNvbmYgKHNlYXJjaCBmb3Ig4oCcUm9iIFPigJ0pLiAgVGhhdCBzYWlk LCBpdCBpcyB1bmNsZWFyIHRvIG1lIGhvdyBhIHJlY2VpdmVyIGNvdWxkIGNvbmZpZ3VyZSB0aGlz IHdoaWxlLCBlLmcuLCBjb25maWd1cmluZyBjb250cm9sIHBsYW5lIG5vdGlmaWNhdGlvbnMgdG8g YmUgc2VudCB2aWEgYSBUQ1AtYmFzZWQgdHJhbnNwb3J0IHN1Y2ggYXMg4oCcaHR0cHMtbm90aWbi gJ0uDQoNCg0KMykgcmVnYXJkaW5nIEp1ZXJnZW7igJlzIHF1ZXN0aW9uczoNCg0KICBhKSBJIGFt IHdpbGxpbmcgdG8gc3Vic3RhbnRpYWxseSByZXZpZXcgdGhlIGRyYWZ0cy4NCiAgYikgSSBhbSB3 aWxsaW5nIHRvIGNvbnRyaWJ1dGUgdG8gdGhlIGRpc2N1c3Npb24gb2YgYW55IGlzc3VlLg0KICBj KSBJIGRvIE5PVCBwbGFuIHRvIGltcGxlbWVudCB0aGUgdGVjaG5vbG9neSBkZWZpbmVkLg0KDQoN Cg0KS2VudA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm5ldGNvbmYgbWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo= --_000_7b77f6ff39d4430aa549c9b53b902ddehuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQW5keSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBhZ2FpbiBmb3IgeW91ciBmdXJ0aGVyIGNvbW1l bnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGlhbnJhbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1c3QgMjgsIDIwMjAgMzoxNCBBTTxicj4NCjxiPlRvOjwv Yj4gVGlhbnJhbiBaaG91ICZsdDt6aG91dGlhbnJhbkBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0O3J3aWx0b249NDBjaXNjby5jb21AZG1hcmMu aWV0Zi5vcmcmZ3Q7OyBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb bmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0LXVueXRlLW5ldGNvbmYtdWRw LW5vdGlmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBB dWcgMjYsIDIwMjAgYXQgNjo1MCBQTSBUaWFucmFuIFpob3UgJmx0OzxhIGhyZWY9Im1haWx0bzp6 aG91dGlhbnJhbkBodWF3ZWkuY29tIj56aG91dGlhbnJhbkBodWF3ZWkuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBBbmR5LDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciByZXBseSBhbmQg c3VnZ2VzdGlvbnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRpYW5yYW48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFuZHkg Qmllcm1hbiBbbWFpbHRvOjwvc3Bhbj48YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29t IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5hbmR5QHl1bWF3b3Jrcy5jb208L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBB dWd1c3QgMjcsIDIwMjAgMToyOSBBTTxicj4NCjxiPlRvOjwvYj4gVGlhbnJhbiBaaG91ICZsdDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnpob3V0aWFucmFuQGh1YXdlaS5jb208L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUm9iIFdpbHRvbiAocndpbHRvbikg Jmx0O3J3aWx0b249PC9zcGFuPjxhIGhyZWY9Im1haWx0bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+NDBjaXNjby5jb21AZG1hcmMu aWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsNCjwvc3Bhbj48YSBocmVm PSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+bmV0Y29uZkBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQt dW55dGUtbmV0Y29uZi11ZHAtbm90aWY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgQXVnIDI2LCAyMDIwIGF0IDE6MTcgQU0gVGlhbnJhbiBa aG91ICZsdDs8YSBocmVmPSJtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnpob3V0aWFucmFuQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkhpIEFuZHksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+UGxlYXNlIHNlZSBpbmxpbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGlhbnJhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gbmV0Y29uZiBbbWFp bHRvOjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5uZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJt YW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMTksIDIwMjAgNjoxOCBBTTxi cj4NCjxiPlRvOjwvYj4gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0O3J3aWx0b249PC9zcGFuPjxh IGhyZWY9Im1haWx0bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpuZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5uZXRj b25mQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW25ldGNvbmZdIEFkb3B0aW9uLXN1aXRhYmlsaXR5IGZvciBkcmFmdC11bnl0ZS1u ZXRjb25mLXVkcC1ub3RpZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gVHVlLCBBdWcgMTgsIDIwMjAgYXQgNjo0MiBBTSBSb2IgV2lsdG9uIChyd2ls dG9uKSAmbHQ7cndpbHRvbj08YSBocmVmPSJtYWlsdG86NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj40MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+W0Fsc28gYXMg YSBjb250cmlidXRvcl08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5NeSBjb21tZW50cyBhcmUgYnJv YWRseSBzaW1pbGFyIHRvIEtlbnTigJlzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkkgYmVsaWV2 ZSB0aGF0IGEgVURQIHRyYW5zcG9ydCBmb3IgZGF0YXBsYW5lIHRlbGVtZXRyeSB3aGVyZSBnZXR0 aW5nIGFjY3VyYXRlIGZyZXNoIGRhdGEgcXVpY2tseSBpcyBtb3JlIGltcG9ydGFudCB0aGFuIGdl dHRpbmcgZXZlcnkgdXBkYXRlLiZuYnNwOyBUaGlzIGlzIHBhcnRpY3VsYXJseQ0KIHRydWUgaWYg YSBzdWJzZXF1ZW50IG5vdGlmaWNhdGlvbiB3aWxsIGNvdmVyIGFueSBsb3N0IHZhbHVlcyBhbnl3 YXkgKGUuZy4gcGVyaW9kaWMgc3RhdGlzdGljcykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5hZ3JlZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZXJlIGlzIGFsc28gdGhlIHJlc3luYy1zdWJzY3Jp cHRpb24gbWVjaGFuaXNtIHRvIGhlbHAgcmVjb3ZlciBmcm9tIG1pc3NpbmcgZGF0YS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W3p0 cl0gT3VyIGludGVudGlvbiBvZiB1c2luZyBVRFAgaXMgZm9yIGRhdGEgdGhhdCBkbyBub3QgY2Fy ZSBhYm91dCBvY2Nhc2lvbmFsIGxvc3MuIFR5cGljYWxseSBmb3IgcGVyaW9kIGRhdGEsIGFuZA0K IG5ldyBkYXRhIHdpbGwgYW55d2F5IGNhbWUgYW5kIHVwZGF0ZS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RG9lcyB0aGUg4oCc PC9zcGFuPnJlc3luYy1zdWJzY3JpcHRpb248c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKAnSBtZWFuIHRoZSBy ZXRyYW5zbWlzc2lvbj8NCiBIZXJlIGRvIHlvdSB3YW50IHRvIGFkZCB0aGUg4oCcPC9zcGFuPnJl c3luYy1zdWJzY3JpcHRpb24gbWVjaGFuaXNtPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igJ0gd2hlbiBwYWNr ZXQgbG9zcyBpcyBkZXRlY3RlZCBpbiB0aGlzIGRyYWZ0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIGlz IGV4cGxhaW5lZCBpbiBSRkMgODY0MTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+WlRSJmd0OyBZZXMsIEkgbG9va2VkIGludG8gUkZDODY0MS4gSXTi gJlzIHRoZSBzYW1lIGFzIHdoYXQgSSB1bmRlcnN0YW5kIGFzIOKAnHJldHJhbnNtaXNzaW9u4oCd LiBUd28ga2V5IHBvaW50cw0KIG9uIOKAnHJlc3luYy1zdWJzY3JpcHRpb27igJ0gZnJvbSBteSBw ZXJzcGVjdGl2ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4xLiDigJxUaGlzIFJQQyBpcyBzdXBwb3J0 ZWQgb25seSBmb3Igb24tY2hhbmdlIHN1YnNjcmlwdGlvbnMgcHJldmlvdXNseSBlc3RhYmxpc2hl ZCB1c2luZyBhbiAmcXVvdDtlc3RhYmxpc2gtc3Vic2NyaXB0aW9uJnF1b3Q7DQogUlBDLuKAnTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjIuIOKAnE9uIHJlY2VpcHQsIGEgcHVibGlzaGVyIG11c3QgZWl0 aGVyICgxKSBhY2NlcHQgdGhlIHJlcXVlc3QgYW5kIHF1aWNrbHkgZm9sbG93IHdpdGggYSAmcXVv dDtwdXNoLXVwZGF0ZSZxdW90Ow0KIG9yIOKApuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvLCB3aGF04oCZcyB5b3VyIHN1Z2dlc3Rpb24gaGVyZT8N Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvIHN1cHBvcnQgdGhpcz8gT3Igbm90IHN1cHBvcnQgdGhp cyBhbmQgYWRkIHRleHQgZXhwbGljaXRseSBpbiB0aGUgZG9jdW1lbnQuDQo8L3NwYW4+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3RoaW5nIHRv IGFkZCB0byB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMganVzdCBub3RpbmcgdGhhdCBZQU5HIFB1c2ggZG9lcyBu b3QgcmVseSBvbiBldmVyeSBwdXNoLWNoYW5nZS11cGRhdGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm5vdGlmaWNhdGlvbiB0byBiZSBkZWxpdmVy ZWQuJm5ic3A7IFRoZSBhcHBsaWNhdGlvbiBsYXllciB3aWxsIHJlLXN5bmNoIGJ5IGl0c2VsZi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlpUUiZndDsgQWdyZWVkLiBUaGFua3MuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiI+SSBzdXNwZWN0IHRoYXQgaGF2aW5nIGEgbWVjaGFuaXNtIHRvIGFsbG93 IGZvciB0aGUgdGVsZW1ldHJ5IGRhdGEgYmVpbmcgZW5jcnlwdGVkIGlzIHByb2JhYmx5IGFsc28g aW1wb3J0YW50LiZuYnNwOyBJZiB0aGUgV0cgd2VyZSB0byBhZG9wdCBhIGRyYWZ0IHdpdGhvdXQg dGhpcywgdGhlbg0KIGFzIEJlbm9pdCBtZW50aW9uZWQsIEkgd291bGQgaGF2ZSB0byB0ZXN0IHRo ZSB3YXRlciB3aXRoIHRoZSBJRVNHIHRvIGRldGVybWluZSB3aGV0aGVyIHRoYXQgd291bGQgYmUg YWNjZXB0YWJsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgc3VzcGVjdCB0aGUg bGFjayBvZiBjb25nZXN0aW9uIGNvbnRyb2wgbWlnaHQgZ2V0IHRoZWlyIGF0dGVudGlvbiBhcyB3 ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5benRyXSBZZXMsIEkgYWdyZWUsIGJvdGggc2VjdXJpdHkgYW5kIGNvbmdlc3Rpb24g Y29uc2lkZXJhdGlvbnMgbmVlZCB0byBiZSBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50LiBXZSBo YXZlIHNlY3Rpb24NCiA0IGZvciBjb25nZXN0aW9uIGNvbnRyb2wuIERvIHlvdSBoYXZlIGFueSBp ZGVhIG9uIHRoaXM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+bm8gLS0gSSBjYW4ndCBzb2x2ZSBwcm9ibGVtcyB0aGF0IElFVEYgY3Jl YXRlcyBmb3IgaXRzZWxmLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JIHRoaW5rIHRoZSBkcmFmdCBzYXlzIHNvbWV0aGluZyBsaWtlICZxdW90 O2RvIG5vdCB1c2UgdGhpcyBwcm90b2NvbCBpZiBjb25nZXN0aW9uIGlzIGEgY29uY2VybiZxdW90 Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiI+SSBhbHNvIG5vdGUgdGhhdCB0aGUgZHJhZnQgYWxsb3dzIGZvciBhIEdQQiBlbmNvZGlu ZyBvZiB0aGUgdGVsZW1ldHJ5IGRhdGEsIGJ1dCBJ4oCZbSBub3QgYXdhcmUgb2YgYW55IGZvcm1h bCBzdGFuZGFyZCBlbmNvZGluZyBvZiBZQU5HIGRhdGEgaW4gR1BCLCBhbmQgdGhlcmUgaXMNCiBh IGNob2ljZSBiZXR3ZWVuIHdoZXRoZXIgdGhlIEdQQiBlbmNvZGluZyBpcyBnZW5lcmljIGZvciBh bGwgWUFORyBkYXRhLCBvciBzcGVjaWZpYyBHUEIgZW5jb2RpbmdzIGFyZSB1c2VmdWwgZm9yIHRo ZSBzcGVjaWZpYyBkYXRhIHRoYXQgaXMgYmVpbmcgZW5jb2RlZC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdhcyBjb25mdXNlZCBieSB0aGUgc2Ft ZSB0aGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SXMgdGhlcmUgYSBZQU5HIHNjaGVtYSBmb3IgYSBub3RpZmljYXRpb24gZWxlbWVudCB0 aGF0IGlzIHVzZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPldoaWNoIG1lYW5zIHRoZSAucHJvdG8gZmlsZSBpcyBoYXJkd2lyZWQ/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIG5vdCB0 aGVuIGhvdyBkb2VzIHRoZSByZWNlaXZlciBrbm93IHdoYXQgaXMgc2VudD88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlcmUgYXJlIHNvbWUg dGVjaG5pY2FsIGlzc3VlcyB0aGF0IGNhbiBiZSBhZGRyZXNzZWQgaWYgdGhlIGRyYWZ0IGlzIGFk b3B0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPlt6dHJdIEluIHRoaXMgZHJhZnQgd2Ugb25seSBjb25zaWRlciB0byBpbmNsdWRl IGEgY29kZSBwb2ludCB0byBpbmRpY2F0ZSB0aGUgR1BCIGVuY29kaW5nLiBIb3cgdG8gbWFwIFlB TkcgdG8gR1BCDQogaXMgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGlzIGRyYWZ0Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JbiBw cmFjdGljZSwgdGhlcmUgYXJlIHNldmVyYWwgd2F5cyBpbiBteSBvcGluaW9uLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XZSBj YW4gbWFwIFlBTkcgdG8gcHJvdG8gZmlyc3RseSwgYW5kIHRoZSBwcm90byBhY3R1YWxseSBkZXNj cmliZXMgdGhlIGRhdGEgc3RydWN0dXJlLiBJIHRoaW5rIFlBTkcgY2FuIGFsbW9zdCB0cmFuc2xh dGUNCiB0byBwcm90byAxOjEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldlIGNhbiBhbHNvIGRldmVsb3AgWUFORyB0byBHUEIg ZGlyZWN0bHksIGp1c3QgbGlrZSBZQU5HIHRvIFhNTCBhbmQgSlNPTi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SW4gYnJpZWYs IHRoZSByZWNlaXZlciBjYW4gc3RpbGwga25vdyB3aGF0IGlzIHNlbnQgYnkgWUFORy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SSBkb24ndCB0aGluayB0aGUgcHJvdG9jb2wgc2hvdWxkIGluY2x1ZGUgcGxhY2Vo b2xkZXJzIGZvciBwcm9wcmlldGFyeSZuYnNwO3NvbHV0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RWl0aGVyIGxlYXZlIG91dCBHUEIg Y29tcGxldGVseSBvciBzdXBwb3J0IGl0IGluIGFuIGludGVyb3BlcmFibGUgd2F5LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WlRSJmd0OyBXZSBo YXZlIG5vIHBvc2l0aW9uIG9uIHRoaXMuIElmIHRoZSBXRyBhZ3JlZWQsIHdlIHdvdWxkIGxpa2Ug dG8gbGVhdmUgb3V0IEdQQi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XaGF0IGFib3V0IGp1c3QgYWRkaW5nIGEgMzItYml0IHJlcG9ydC1pZCBm aWVsZCB0byB0aGUgaGVhZGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGlzIGlzIGVub3VnaC4gQXNzaWdubWVudCBvZiB0aGUgSURzIGlzIG91 dCBvZiBzY29wZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WlRSJmd0 OyBTb3JyeSwgSSBkaWQgbm90IGdldCB5b3Ugb24gd2hhdOKAmXMgdGhpcyAzMi1iaXQgcmVwb3J0 LWlkPyBXZSBoYXZlIGEgNCBiaXQgZW5jb2RpbmcgdHlwZSBmaWVsZCwgd2hpY2ggY2FuIHN1cHBv cnQgMTYgZW5jb2RpbmdzLiBXZSBjYW4gc2V0IHRoaXMgYXMgYSByZWdpc3RyeSBhbmQgZGVmZXIg dGhlIGFzc2lnbm1lbnQgb2YgR1BCLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Nb3JlIGlzc3Vlczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgcHJvdG9jb2wgaXMgbm90IHVzYWJsZSBieSBzZXJ2ZXJz IHRoYXQgc3RyZWFtIGRhdGEgaW5zdGVhZCBvZiBidWlsZGluZyBhbiBlbnRpcmUgcmVzcG9uc2U8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aW4g bWVtb3J5LiBXaXRoIGEgc3RyZWFtaW5nIGRlc2lnbiB0aGUgc2VydmVyIGRvZXNuJ3Qga25vdyB3 aGF0IHdpbGwgYmUgc2VudCBpbiBhZHZhbmNlIHNvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPml0IHN1cmUgZG9lc24ndCBrbm93IHRoZSBsZW5n dGggaW4gYWR2YW5jZS4mbmJzcDsgQ0JPUiBkb2VzIGEgZ3JlYXQgam9iIG9mIHN1cHBvcnRpbmcg Ym90aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij50eXBlcyBvZiBzZXJ2ZXIgZGVzaWduLiZuYnNwOyBORVRDT05GIGFuZCBIVFRQIHN1cHBvcnQg Y2h1bmtpbmcsIHdoaWNoIGlzIHVzZWQgZXh0ZW5zaXZlbHkgYnk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+c3RyZWFtaW5nIHNlcnZlcnMuIFRo aXMgZHJhZnQgc2hvdWxkIG1lbnRpb24gc3RyZWFtaW5nIGFuZCBleHBsYWluIHdoeSBpdCBpcyBu b3Qgc3VwcG9ydGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+WlRSJmd0OyBJZiB5b3UgbWVhbiBiaXQgc3RyZWFtaW5nIGxpa2UgVENQLCBJIHRo aW5rIFVEUCBjYW5ub3Qgc3VwcG9ydCB0aGlzLiBEbyB5b3UgaGF2ZSBhbnkgcG9pbnRlciBvbg0K IGhvdyBDQk9SIGNhbiBzdXBwb3J0IHRoZSBzdHJlYW1pbmcuIEFuZCBob3cgTkVUQ09ORiBhbmQg SFRUUCBzdXBwb3J0IGNodW5raW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluIGdlbmVyYWwsIEkg dW5kZXJzdGFuZCB0aGlzIHJlcXVpcmVtZW50IHdpdGggc21hbGwgbWVtb3J5IG9yIHBhcnRpYWwg ZGF0YS4gQnV0IGRvIHlvdSBoYXZlIGFueSByZWFsDQogY2FzZSBpbiB0aGUgY29udGV4dCBvZiBZ QU5HIHB1c2g/IFNvIHRoYXQgd2UgY2FuIHdvcmsgb24gYW4gb3B0aW1hbCBkZXNpZ24uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBp dCBpcyBPSyB0byBzYXkgdGhhdCBhIHNlcnZlciBpcyBleHBlY3RlZCB0byBidWlsZCBhbiBlbnRp cmUgcmVzcG9uc2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmFuZCB0aGUgbGVuZ3RoIG5lZWRzIHRvIGJlIGtub3duIGluIGFkdmFuY2UsIGlmIGZy YWdtZW50YXRpb24gaXMgbm90IGVuYWJsZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHNlcnZlciBjYW4gc3RyZWFtIGRhdGEgT0sgaWYgVURQ IGZyYWdtZW50YXRpb24gaXMgZW5hYmxlZC4gQ29BUCB1c2VzIHRoZSBCbG9jayBvcHRpb248bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIHN1cHBv cnQgc3RyZWFtaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WlRSJmd0OyBHb3QgaXQuIFll cywgdGhpcyBkcmFmdCBlbmFibGVzIFVEUCBmcmFnbWVudGF0aW9uIHdoaWNoIGNhbiBzdXBwb3J0 IGRhdGEgc3RyZWFtaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBnZW5lcmljIHdyYXBwZXJzIChsaWtl IGdOTUkgYW5kIFlBTkcgbm90aWZpY2F0aW9uIHNjaGVtYSkgZG8gbm90IGhhbmRsZSAmcXVvdDth bnlkYXRhJnF1b3Q7IHZlcnkgd2VsbCBhdCBhbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBiaW5hcnkgcGF5bG9hZCBiZWNvbWVzIG1v c3RseSBKU09OLiZuYnNwOyBPbmx5IENCT1ImIzQzO1NJRCBoYW5kbGVzIGFueWRhdGEgZWZmaWNp ZW50bHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlRoZSBzb2x1dGlvbiAobWF5YmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBwcm90b2Nv bCkgc2hvdWxkIGNvbnNpZGVyIGhvdyBZQU5HIGFueWRhdGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+d2lsbCBiZSB0cmFuc21pdHRlZCBlZmZp Y2llbnRseSBhbmQgY29udmVydGVkIGZyb20gYW55ZGF0YSB0byBhIHJlYWwgc2NoZW1hIGNvcnJl Y3RseSBieSB0aGUgcmVjZWl2ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+UmVnYXJkcyw8YnI+DQpS b2I8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZHk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZHk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj5Gcm9tOjwvYj4gbmV0Y29uZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT4m Z3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPktlbnQgV2F0c2VuPGJyPg0KPGI+U2VudDo8L2I+IDA3 IEF1Z3VzdCAyMDIwIDIxOjE2PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bmV0Y29u ZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0 LXVueXRlLW5ldGNvbmYtdWRwLW5vdGlmPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tR0IiPlthcyBhIGNvbnRyaWJ1dG9yXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsmbmJzcDsxKSBpcyB0aGUgcHJvYmxlbSBpbXBvcnRhbnQg Zm9yIHRoZSBORVRDT05GIFdHIHRvIHNvbHZlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+SSBiZWxpZXZl IHRoYXQgaXQgaXMgaW1wb3J0YW50IHRvIGVuYWJsZSBwdWJsaXNoZXJzIHRvIHNlbmQgbm90aWZp Y2F0aW9ucyB1c2luZyBhIFVEUC1iYXNlZCB0cmFuc3BvcnQuICZuYnNwOyBUaGlzIGJlbGllZiBp cyBiYXNlZCBvbiBteSBleHBlcmllbmNlIGZyb20gd2hlbiBhdCBKdW5pcGVyDQogZGVhbGluZyB3 aXRoIHZlcnkgaGlnaC1lbmQgZmlyZXdhbGxzIHdpdGggZW5vcm1vdXMgbG9nIG91dHB1dC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Y29sb3I6YmxhY2siPkkgYmVsaWV2ZSB0aGF0IHRoZSZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiI+TkVUQ09ORiBXRyBpcyB0aGUgYXBwcm9wcmlhdGUgV0cgZm9yIHRoaXMgd29yaywgaGF2 aW5nIGRlZmluZWQgUkZDIDg2MzkgKFNOKSwmbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlJGQw0KIDg2NDAgKE5OKSwgYW5kJm5ic3A7PC9zcGFuPlJGQyA4NjUwIChSTikuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7MikgaXMgdGhlIGRyYWZ0IGEgc3VpdGFibGUgYmFzaXMg Zm9yIHRoZSB3b3JrPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5JIGhhdmUgcmVhZCB0aGUgY3VycmVudCB2ZXJzaW9u IG9mIHRoZSBkcmFmdCBhbmQgZmluZCBpdCB0byBiZSBhIHJlYXNvbmFibGUgc3RhcnQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+UHJlc3VtaW5n IHRoZSDigJxyZWNlaXZlci1pbnN0YW5jZXPigJ0gYXVnbWVudGF0aW9uIGRlZmluZWQgaW4mbmJz cDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bmV0Y29uZi1odHRwcy1ub3RpZi0wNCNzZWN0aW9uLTMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBs YW5nPSJFTi1HQiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29u Zi1odHRwcy1ub3RpZi0wNCNzZWN0aW9uLTM8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUdCIj4m bmJzcDt0YWtlcw0KIG9mZiwgdGhlIG1vZHVsZSBkZWZpbmVkIGluIHRoaXMgZHJhZnQgc2hvdWxk IGJlIHVwZGF0ZWQgdG8gYXVnbWVudCBpbnRvIGl0IGluc3RlYWQuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpi bGFjayI+SSBhcHByZWNpYXRlIFNlY3Rpb24gNSAoQXBwbGljYWJpbGl0eSkgbm90aW5nIHRoYXQg dGhlIFVEUC10cmFuc3BvcnQgaXMgcHJpbWFyaWx5IGZvciB0aGUgZGF0YSBwbGFuZSAobm90IHRo ZSBjb250cm9sIHBsYW5lKSwgYXMgaXQgZG9lc27igJl0DQogbWF0dGVyIHNvIG11Y2ggaWYgZGF0 YSBwbGFuZSBub3RpZmljYXRpb25zIGFyZSBsb3N0LiZuYnNwOyBUaGlzIGFkZHJlc3NlcyAoSSB0 aGluaykgdGhlIGlzc3VlIHRoYXQgUm9iIFNoYWtpciByYWlzZWQgYmVmb3JlOg0KPC9zcGFuPjxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL21pbnV0ZXMtMTAzLW5ldGNv bmYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1HQiI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvbWludXRlcy0xMDMtbmV0Y29uZjwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7KHNlYXJjaCBmb3Ig4oCcUm9iIFPigJ0p LiZuYnNwOyBUaGF0IHNhaWQsIGl0IGlzIHVuY2xlYXIgdG8NCiBtZSBob3cgYSByZWNlaXZlciBj b3VsZCBjb25maWd1cmUgdGhpcyB3aGlsZSwgZS5nLiwgY29uZmlndXJpbmcgY29udHJvbCBwbGFu ZSBub3RpZmljYXRpb25zIHRvIGJlIHNlbnQgdmlhIGEgVENQLWJhc2VkIHRyYW5zcG9ydCBzdWNo IGFzIOKAnGh0dHBzLW5vdGlm4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFj ayI+MykgcmVnYXJkaW5nIEp1ZXJnZW7igJlzIHF1ZXN0aW9uczo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IGEpIEkgYW0gd2lsbGluZyB0byBzdWJzdGFudGlhbGx5 IHJldmlldyB0aGUgZHJhZnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7IGIpIEkgYW0mbmJzcDt3aWxsaW5nIHRvIGNvbnRyaWJ1dGUgdG8gdGhlIGRp c2N1c3Npb24gb2YgYW55IGlzc3VlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7IGMpIEkgZG8gTk9UJm5ic3A7cGxhbiB0byBpbXBsZW1lbnQgdGhlIHRl Y2hub2xvZ3kgZGVmaW5lZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPktlbnQ8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpuZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7b77f6ff39d4430aa549c9b53b902ddehuaweicom_-- From nobody Mon Aug 31 10:39:53 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50623A17C7 for ; Mon, 31 Aug 2020 10:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9YE7plESMEg for ; Mon, 31 Aug 2020 10:39:50 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C230D3A17C3 for ; Mon, 31 Aug 2020 10:39:49 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id i10so7713742ljn.2 for ; Mon, 31 Aug 2020 10:39:49 -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=g4DFVORu0oqHV8zleiuqMQyKWwsPNmZNYojEzixJ92I=; b=Y9OLogNfy32VMzm3LVx5Ve/rctg3ImAYXvTHAZzZQ/+9FVRvRzKnfdy7+Os6Bl9+d6 FUe4ZlDVLpO9DBDxBEWU3qlmuChKZoKDSLNkQs9ZKZtnTAFlAMTdKpLTV+nIX6EaYaS6 DnUJkotImjb6O++x98VZ27ul4nUVmSasPhnBeic0AKJ9L/4NFV4KaNd9kUF4dAlXXKOo fWV0dK8C6cTA+vEEp6dndtHjzlJ98l6vYFVWD6sJ2CkMytAjMLn/wjAhlnldJ8zc2zVT 3kFmRg+4l2JhoiUSnE5MUEWRQRTd9GChVbYo4MZLKaMom9RPk5C2idIooYjdQPEUXJQA tAaQ== 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=g4DFVORu0oqHV8zleiuqMQyKWwsPNmZNYojEzixJ92I=; b=Wj77TWNvRck/uCgkFc9+1ajj5Wp8SgIOwDRF4fyNy1a8JjZ3VW2uoh5ZQloDlqXZy4 dmTd/gO/J4VcuhjT2/vvUdeTGr6tk3D7CQZ95VsnY4bxa0peeewwTcMbwL1USOQiJgyi I4Dxi9yxZfPwE3hApLmpCZ7kGf5BeN9jJr5G4SrinAu/GkhYx7ljCKSUT6N3rJYozyW9 JgVaO11ST7xQip73WWYKbrVaLKEeDE8fDNPsjR2thFnP63fze1fTfAKqeITEgvMptS2Y yuaj2faoeBnGBOnH5aO0YycRToHFLELiU1+OYm7txDbxSN2Y1OAU6Vqfx7W7QuYQyahl K+Xg== X-Gm-Message-State: AOAM530jA8U9Auz/+dh31IMRCs/alEVrG0N3RWwMHIL0ci0yKiMve2ry Zrcr4KQGAWjVU2y3HqQW5WsqAd5kdwVyY8KJKNd6TQ== X-Google-Smtp-Source: ABdhPJy/lfugjMwE9fLwLU7epujGailHBeoBneyyVJ1+0zOZFLjZqeri3XKbaMKI9lcpRo2f+NB5hdl78qsevli7XWE= X-Received: by 2002:a2e:854c:: with SMTP id u12mr1117722ljj.120.1598895587491; Mon, 31 Aug 2020 10:39:47 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.com> <07b991b1e32347b58ae4ef968cdffc7f@huawei.com> <7b77f6ff39d4430aa549c9b53b902dde@huawei.com> In-Reply-To: <7b77f6ff39d4430aa549c9b53b902dde@huawei.com> From: Andy Bierman Date: Mon, 31 Aug 2020 10:39:36 -0700 Message-ID: To: Tianran Zhou Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000869c8505ae2fe3e8" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 17:39:53 -0000 --000000000000869c8505ae2fe3e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I am still very confused about the content. Not the encoding. That is a separate issue. Sec 2, and 3.1 refer to the "subscription-started" notification and "the NETCONF/RESTCONF notification message". This text seems to imply that the element defined in RFC 527= 7 is used for the content. But sec. 3.4 mentions bundled notifications so maybe not. Usually the application protocol defines the message flows that are expected. This document is a transport protocol for an unspecified application. There is an assumption that publisher and receiver both know the protocol somehow. For GDB, they magically know how to distinguish different proto files. IMO this level of disregard for interoperability is unacceptable for a standard protocol. Andy On Fri, Aug 28, 2020 at 2:01 AM Tianran Zhou wrote= : > Hi Andy, > > > > Thanks again for your further comments. > > > > Tianran > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Friday, August 28, 2020 3:14 AM > *To:* Tianran Zhou > *Cc:* Rob Wilton (rwilton) ; > netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > > > > > On Wed, Aug 26, 2020 at 6:50 PM Tianran Zhou > wrote: > > Hi Andy, > > > > Thanks for your reply and suggestions. > > > > Cheers, > > Tianran > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, August 27, 2020 1:29 AM > *To:* Tianran Zhou > *Cc:* Rob Wilton (rwilton) ; > netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > > > > > On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou > wrote: > > Hi Andy, > > > > Please see inline. > > > > Tianran > > > > *From:* netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Wednesday, August 19, 2020 6:18 AM > *To:* Rob Wilton (rwilton) > *Cc:* netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > > > > > On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton) 40cisco.com@dmarc.ietf.org> wrote: > > Hi, > > > > [Also as a contributor] > > > > My comments are broadly similar to Kent=E2=80=99s. > > > > I believe that a UDP transport for dataplane telemetry where getting > accurate fresh data quickly is more important than getting every update. > This is particularly true if a subsequent notification will cover any los= t > values anyway (e.g. periodic statistics). > > > > > > agreed. > > There is also the resync-subscription mechanism to help recover from > missing data. > > > > [ztr] Our intention of using UDP is for data that do not care about > occasional loss. Typically for period data, and new data will anyway came > and update. > > Does the =E2=80=9Cresync-subscription=E2=80=9D mean the retransmission? H= ere do you want > to add the =E2=80=9Cresync-subscription mechanism=E2=80=9D when packet lo= ss is detected > in this draft? > > > > > > > > This is explained in RFC 8641 > > > > ZTR> Yes, I looked into RFC8641. It=E2=80=99s the same as what I understa= nd as > =E2=80=9Cretransmission=E2=80=9D. Two key points on =E2=80=9Cresync-subsc= ription=E2=80=9D from my > perspective. > > 1. =E2=80=9CThis RPC is supported only for on-change subscriptions previo= usly > established using an "establish-subscription" RPC.=E2=80=9D > > 2. =E2=80=9COn receipt, a publisher must either (1) accept the request an= d quickly > follow with a "push-update" or =E2=80=A6=E2=80=9D > > > > So, what=E2=80=99s your suggestion here? > > To support this? Or not support this and add text explicitly in the > document. > > > > > > Nothing to add to this document. > > I was just noting that YANG Push does not rely on every push-change-updat= e > > notification to be delivered. The application layer will re-synch by > itself. > > > > ZTR> Agreed. Thanks. > > > > > > I suspect that having a mechanism to allow for the telemetry data being > encrypted is probably also important. If the WG were to adopt a draft > without this, then as Benoit mentioned, I would have to test the water wi= th > the IESG to determine whether that would be acceptable. > > > > I suspect the lack of congestion control might get their attention as wel= l. > > > > [ztr] Yes, I agree, both security and congestion considerations need to b= e > described in the document. We have section 4 for congestion control. Do y= ou > have any idea on this? > > > > > > no -- I can't solve problems that IETF creates for itself. > > I think the draft says something like "do not use this protocol if > congestion is a concern". > > > > > > > > I also note that the draft allows for a GPB encoding of the telemetry > data, but I=E2=80=99m not aware of any formal standard encoding of YANG d= ata in > GPB, and there is a choice between whether the GPB encoding is generic fo= r > all YANG data, or specific GPB encodings are useful for the specific data > that is being encoded. > > > > > > > > I was confused by the same thing. > > Is there a YANG schema for a notification element that is used? > > Which means the .proto file is hardwired? > > If not then how does the receiver know what is sent? > > There are some technical issues that can be addressed if the draft is > adopted. > > > > [ztr] In this draft we only consider to include a code point to indicate > the GPB encoding. How to map YANG to GPB is out of the scope of this draf= t. > > In practice, there are several ways in my opinion. > > We can map YANG to proto firstly, and the proto actually describes the > data structure. I think YANG can almost translate to proto 1:1. > > We can also develop YANG to GPB directly, just like YANG to XML and JSON. > > In brief, the receiver can still know what is sent by YANG. > > > > > > > > I don't think the protocol should include placeholders for > proprietary solutions. > > Either leave out GPB completely or support it in an interoperable way. > > > > ZTR> We have no position on this. If the WG agreed, we would like to leav= e > out GPB. > > > > > > What about just adding a 32-bit report-id field to the header > > This is enough. Assignment of the IDs is out of scope. > > > > ZTR> Sorry, I did not get you on what=E2=80=99s this 32-bit report-id? W= e have a > 4 bit encoding type field, which can support 16 encodings. We can set thi= s > as a registry and defer the assignment of GPB. > > > > > > > > More issues: > > > > This protocol is not usable by servers that stream data instead of > building an entire response > > in memory. With a streaming design the server doesn't know what will be > sent in advance so > > it sure doesn't know the length in advance. CBOR does a great job of > supporting both > > types of server design. NETCONF and HTTP support chunking, which is used > extensively by > > streaming servers. This draft should mention streaming and explain why it > is not supported. > > > > ZTR> If you mean bit streaming like TCP, I think UDP cannot support this. > Do you have any pointer on how CBOR can support the streaming. And how > NETCONF and HTTP support chunking. > > In general, I understand this requirement with small memory or partial > data. But do you have any real case in the context of YANG push? So that = we > can work on an optimal design. > > > > > > I think it is OK to say that a server is expected to build an entire > response > > and the length needs to be known in advance, if fragmentation is not > enabled. > > A server can stream data OK if UDP fragmentation is enabled. CoAP uses th= e > Block option > > to support streaming. > > > > ZTR> Got it. Yes, this draft enables UDP fragmentation which can support > data streaming. > > > > > > > > The generic wrappers (like gNMI and YANG notification schema) do not > handle "anydata" very well at all. > > The binary payload becomes mostly JSON. Only CBOR+SID handles anydata > efficiently. > > The solution (maybe outside the scope of this protocol) should consider > how YANG anydata > > will be transmitted efficiently and converted from anydata to a real > schema correctly by the receiver. > > > > > > > > > > Regards, > Rob > > > > > > Andy > > > > > > Andy > > > > > > > > Andy > > > > > > > > > > *From:* netconf *On Behalf Of *Kent Watsen > *Sent:* 07 August 2020 21:16 > *To:* netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > [as a contributor] > > > > > > 1) is the problem important for the NETCONF WG to solve? > > > > I believe that it is important to enable publishers to send notifications > using a UDP-based transport. This belief is based on my experience from > when at Juniper dealing with very high-end firewalls with enormous log > output. > > > > I believe that the NETCONF WG is the appropriate WG for this work, having > defined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN). > > > > > > 2) is the draft a suitable basis for the work? > > > > I have read the current version of the draft and find it to be a > reasonable start. > > > > Presuming the =E2=80=9Creceiver-instances=E2=80=9D augmentation defined i= n > https://tools.ietf.org/html/draft-ietf-netconf-https-notif-04#section-3 t= akes > off, the module defined in this draft should be updated to augment into i= t > instead. > > > > I appreciate Section 5 (Applicability) noting that the UDP-transport is > primarily for the data plane (not the control plane), as it doesn=E2=80= =99t matter > so much if data plane notifications are lost. This addresses (I think) t= he > issue that Rob Shakir raised before: > https://datatracker.ietf.org/doc/minutes-103-netconf (search for =E2=80= =9CRob > S=E2=80=9D). That said, it is unclear to me how a receiver could configu= re this > while, e.g., configuring control plane notifications to be sent via a > TCP-based transport such as =E2=80=9Chttps-notif=E2=80=9D. > > > > > > 3) regarding Juergen=E2=80=99s questions: > > > > a) I am willing to substantially review the drafts. > > b) I am willing to contribute to the discussion of any issue. > > c) I do NOT plan to implement the technology defined. > > > > > > > > Kent > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --000000000000869c8505ae2fe3e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am still very confused= about the content. Not the encoding. That is a separate issue.
S= ec 2, and 3.1 refer to the "subscription-started" notification an= d
"the NETCONF/RESTCONF notification message".

This text seems to imply that the <notification> ele= ment defined in RFC 5277
is used for the content.=C2=A0 But sec. = 3.4 mentions bundled notifications so maybe not.

U= sually the application protocol defines the message flows that are expected= .
This document is a transport protocol for an unspecified applic= ation.=C2=A0 There is
an assumption that publisher and receiver b= oth know the protocol somehow.
For GDB, they magically know how t= o distinguish different proto files.

IMO this leve= l of disregard for interoperability is unacceptable for a standard protocol= .


Andy



On Fri, Aug 28, 2020 at 2:01 AM Tianran Zhou <zhoutianran@huawei.com> wrote:

Hi Andy,

=C2=A0

Thanks again for your further comments.

=C2=A0

Tianran

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Friday, August 28, 2020 3:14 AM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>; netconf@ietf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

=C2=A0

=C2=A0

On Wed, Aug 26, 2020 at 6:50 PM Tianran Zhou <zhoutianran@huawei= .com> wrote:

Hi Andy,

=C2=A0

Thanks for your reply and suggestions.

=C2=A0

Cheers,

Tianran

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, August 27, 2020 1:29 AM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>; netconf@ietf.org=
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

=C2=A0

=C2=A0

On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou <zhoutianran@huawei= .com> wrote:

Hi Andy,

=C2=A0

Please see inline.

=C2=A0

Tianran

=C2=A0

From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Wednesday, August 19, 2020 6:18 AM
To: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>
Cc: netconf@ietf.org= Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

=C2=A0

=C2=A0

On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton)= <rwilton=3D40cisco.com@dmarc.ietf.org> wrote:

Hi,

=C2=A0

[Also as a contributor]<= u>

=C2=A0

My comments are broadly similar= to Kent=E2=80=99s.

=C2=A0

I believe that a UDP transport = for dataplane telemetry where getting accurate fresh data quickly is more i= mportant than getting every update.=C2=A0 This is particularly true if a subsequent notification will cover any lost values anyway (e.g. = periodic statistics).

=C2=A0

=C2=A0

agreed.

There is also the resync-subscription mechanism to h= elp recover from missing data.

=C2=A0

[ztr] Our intention of using UDP is for data that do not care abo= ut occasional loss. Typically for period data, and new data will anyway came and update.

Does the =E2=80=9Cresync-subscription=E2=80=9D mean the retransmission? Here do you want to add the =E2=80=9Cresync-subscription mechanism<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif">=E2=80=9D when= packet loss is detected in this draft?

=C2=A0

=C2=A0

=C2=A0

This is explained in RFC 8641

=C2=A0

ZTR> Yes, I looked into RFC8641. It=E2=80= =99s the same as what I understand as =E2=80=9Cretransmission=E2=80=9D. Two= key points on =E2=80=9Cresync-subscription=E2=80=9D from my perspective.

1. =E2=80=9CThis RPC is supported only for o= n-change subscriptions previously established using an "establish-subs= cription" RPC.=E2=80=9D

2. =E2=80=9COn receipt, a publisher must eit= her (1) accept the request and quickly follow with a "push-update"= ; or =E2=80=A6=E2=80=9D

=C2=A0

So, what=E2=80=99s your suggestion here?

To support this? Or not support this and add= text explicitly in the document. =C2=A0

=C2=A0

=C2=A0

Nothing to add to this document.

I was just noting that YANG Push does not rely on ev= ery push-change-update

notification to be delivered.=C2=A0 The application = layer will re-synch by itself.

=C2=A0

ZTR> Agreed.= Thanks.

=C2=A0

=C2=A0

I suspect that having a mechani= sm to allow for the telemetry data being encrypted is probably also importa= nt.=C2=A0 If the WG were to adopt a draft without this, then as Benoit mentioned, I would have to test the water with the IESG to deter= mine whether that would be acceptable.

=C2=A0

I suspect the lack of congestion control might get t= heir attention as well.

=C2=A0

[ztr] Yes, I agree, both security and congestion considerations n= eed to be described in the document. We have section 4 for congestion control. Do you have any idea on this?

=C2=A0

=C2=A0

no -- I can't solve problems that IETF creates f= or itself.

I think the draft says something like "do not u= se this protocol if congestion is a concern".

=C2=A0

=C2=A0

=C2=A0

I also note that the draft allo= ws for a GPB encoding of the telemetry data, but I=E2=80=99m not aware of a= ny formal standard encoding of YANG data in GPB, and there is a choice between whether the GPB encoding is generic for all YANG data, or= specific GPB encodings are useful for the specific data that is being enco= ded.

=C2=A0

=C2=A0

=C2=A0

I was confused by the same thing.

Is there a YANG schema for a notification element th= at is used?

Which means the .proto file is hardwired?<= /u>

If not then how does the receiver know what is sent?=

There are some technical issues that can be addresse= d if the draft is adopted.

=C2=A0

[ztr] In this draft we only consider to include a code point to i= ndicate the GPB encoding. How to map YANG to GPB is out of the scope of this draft.

In practice, there are several ways in my opinion.<= u>

We can map YANG to proto firstly, and the proto actually describe= s the data structure. I think YANG can almost translate to proto 1:1.

We can also develop YANG to GPB directly, just like YANG to XML a= nd JSON.

In brief, the receiver can still know what is sent by YANG.

=C2=A0

=C2=A0

=C2=A0

I don't think the protocol should include placeh= olders for proprietary=C2=A0solutions.

Either leave out GPB completely or support it in an = interoperable way.

=C2=A0

ZTR> We have no position on this. If the = WG agreed, we would like to leave out GPB.

=C2=A0

=C2=A0

What about just adding a 32-bit report-id field to t= he header

This is enough. Assignment of the IDs is out of scop= e.

=C2=A0

=C2=A0ZTR> S= orry, I did not get you on what=E2=80=99s this 32-bit report-id? We have a = 4 bit encoding type field, which can support 16 encodings. We can set this = as a registry and defer the assignment of GPB.

=C2=A0

=C2=A0

=C2=A0

More issues:

=C2=A0

This protocol is not usable by servers that stream d= ata instead of building an entire response

in memory. With a streaming design the server doesn&= #39;t know what will be sent in advance so

it sure doesn't know the length in advance.=C2= =A0 CBOR does a great job of supporting both

types of server design.=C2=A0 NETCONF and HTTP suppo= rt chunking, which is used extensively by

streaming servers. This draft should mention streami= ng and explain why it is not supported.

=C2=A0

ZTR> If you mean bit streaming like TCP, = I think UDP cannot support this. Do you have any pointer on how CBOR can support the streaming. And how NETCONF and HTTP support chunk= ing.

In general, I understand this requirement wi= th small memory or partial data. But do you have any real case in the context of YANG push? So that we can work on an optimal design= .

=C2=A0

=C2=A0

I think it is OK to say that a server is expected to= build an entire response

and the length needs to be known in advance, if frag= mentation is not enabled.

A server can stream data OK if UDP fragmentation is = enabled. CoAP uses the Block option

to support streaming.

=C2=A0

ZTR> Got it.= Yes, this draft enables UDP fragmentation which can support data streaming= .

=C2=A0

=C2=A0

=C2=A0

The generic wrappers (like gNMI and YANG notificatio= n schema) do not handle "anydata" very well at all.=

The binary payload becomes mostly JSON.=C2=A0 Only C= BOR+SID handles anydata efficiently.

The solution (maybe outside the scope of this protoc= ol) should consider how YANG anydata

will be transmitted efficiently and converted from a= nydata to a real schema correctly by the receiver.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Regards,
Rob

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 07 August 2020 21:16
To: netconf@ie= tf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

[as a contributor]

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A01) is the pro= blem important for the NETCONF WG to solve?

=C2=A0

I believe that it is important = to enable publishers to send notifications using a UDP-based transport. =C2= =A0 This belief is based on my experience from when at Juniper dealing with very high-end firewalls with enormous log output.

=C2=A0

I believe= that the=C2=A0NETCONF WG is the appropriate WG= for this work, having defined RFC 8639 (SN),=C2=A0RFC 8640 (NN), and=C2=A0RFC 8650 (RN).

=C2=A0

= =C2=A0

=C2=A0=C2=A0=C2=A02) is the dra= ft a suitable basis for the work?

=C2=A0

I have read the current version= of the draft and find it to be a reasonable start.

=C2=A0

Presuming the =E2=80=9Creceiver= -instances=E2=80=9D augmentation defined in=C2=A0https://tools.ietf.org/html/draft-ietf-netconf= -https-notif-04#section-3=C2=A0takes off, the module defined in this draft should be updated to augment into it= instead.

=C2=A0

I appreci= ate Section 5 (Applicability) noting that the UDP-transport is primarily fo= r the data plane (not the control plane), as it doesn=E2=80=99t matter so much if data plane notifications are lost.=C2=A0 This addresses = (I think) the issue that Rob Shakir raised before: https://datatracker.ietf.org/doc/minute= s-103-netconf=C2=A0(s= earch for =E2=80=9CRob S=E2=80=9D).=C2=A0 That said, it is unclear to me how a receiver could configure this while, e.g., configuring control pl= ane notifications to be sent via a TCP-based transport such as =E2=80=9Chtt= ps-notif=E2=80=9D.

=C2=A0

=C2=A0

3) regard= ing Juergen=E2=80=99s questions:

=C2=A0

=C2=A0 a)= I am willing to substantially review the drafts.

=C2=A0 b)= I am=C2=A0willing to contribute to the discussion of any issue.<= /u>

=C2=A0 c)= I do NOT=C2=A0plan to implement the technology defined.

=C2=A0

=C2=A0

=C2=A0

Kent

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

--000000000000869c8505ae2fe3e8--