From nobody Fri Jan 3 11:51: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 CC40312009E for ; Fri, 3 Jan 2020 11:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAGYoTbW5VlE for ; Fri, 3 Jan 2020 11:51:03 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 DFB931200A3 for ; Fri, 3 Jan 2020 11:51:03 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id r11so23871567pgf.1 for ; Fri, 03 Jan 2020 11:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=KktNDyEkqZWkHInmgoNcSpXqJzpm9afFHrcHS9zRUAY=; b=q8/FST8e1g7RgwW2AXZs/Df4DgrfuqWWXyQ+Kgd2R3BWRUGhvRU2ag1Phn+B73DIL4 VKOWmZ9/U57fFZaw92L/GwCTmnJxox4Edra5kdz7jFwcJg0RLSbOl8/HDZyRxbcsQ/BJ o8X+cq0iL9az+6c30zl7PaDIeNJw9tMmJUVHcGPxq4G/1lfZjUKzetBqXNSVxrjRKb6E y12R09sSG+vDgdJBY+XCZOp9vam7xai7MP51OCNI9TT7J4IW7SpvjOgNDvIrKI7ixAfc LCmNPUyXdsDlQC/GO0u5YkPAfs0GKJhBf+HdnR5z5x5MRPNZhO9H+sQ6U/coDFQhi3ZH J3Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=KktNDyEkqZWkHInmgoNcSpXqJzpm9afFHrcHS9zRUAY=; b=CjnEPgLkbfUNy6SFwSauiCA29AKtmez6QrCzhPhSVqWcud+vGgwTGteaYfPUqjao1a wr2Yc4ZVvF/TwnYUrT9+Jj5RVdUwOqoypOg8N+WZ8uX2gCjE+zWyheqOPc9flp0xJCZk OjpWlbySPSNnOsj8IHMAUdLtyliYUUriATQlAhL3Z3DlhPnR2ZvXiV0+CtZHL98Qxj+H JG6yVudVdSaB4yN175GsPpc+zAHfYn7IUxg24g5mK8AV1RjJ6j/aVdim72WU1UHVewO7 tmOuOo2l9junJRoZVTaXOYLJwJ3Im56wZ7LBw8y+aCF/C+wU0wZc3urefzzezySRkO4B fR3Q== X-Gm-Message-State: APjAAAUunXhrmX/ovIQa8l/c9IFW1zzNj87tZ4e5ewUmZv2+yKbf/Bnl 2tXvYFzmIODg3X1ztNTIxJQnumBl X-Google-Smtp-Source: APXvYqxvbZFqKZBvW9ATERZl6qtZ3WGowSYwtFaeaF2m9dbVKGCMvg8y+tVYhco68fUt1Wz332irPw== X-Received: by 2002:a62:788a:: with SMTP id t132mr96891376pfc.134.1578081063220; Fri, 03 Jan 2020 11:51:03 -0800 (PST) Received: from [192.168.1.122] (c-73-93-49-153.hsd1.ca.comcast.net. [73.93.49.153]) by smtp.gmail.com with ESMTPSA id 73sm64643874pgc.13.2020.01.03.11.51.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jan 2020 11:51:02 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_3642B294-728D-4BD3-A7F2-EAA2A594D502" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <3B3720FA-5E07-43D9-B2C0-7A3EEC7EAD67@gmail.com> Date: Fri, 3 Jan 2020 11:51:01 -0800 To: Netconf X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [netconf] Draft NETCONF 106 minutes posted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 19:51:06 -0000 --Apple-Mail=_3642B294-728D-4BD3-A7F2-EAA2A594D502 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi WG, The draft minutes for IETF 106 have been posted at the following = location. https://datatracker.ietf.org/doc/minutes-106-netconf/ = If you have any comments/corrections, please let us know. Mahesh & Kent --Apple-Mail=_3642B294-728D-4BD3-A7F2-EAA2A594D502 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi WG,

The draft minutes for IETF 106 have been posted at the following location.


If you have any comments/corrections, please let us know.

Mahesh & Kent


--Apple-Mail=_3642B294-728D-4BD3-A7F2-EAA2A594D502-- From nobody Fri Jan 3 12:08:37 2020 Return-Path: <0100016f6d061466-e249bd11-584c-4a1d-8bbc-ac28d55d90f5-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 EA4F5120099 for ; Fri, 3 Jan 2020 12:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 NqbFw2MwvbAH for ; Fri, 3 Jan 2020 12:08:34 -0800 (PST) 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 1A7C5120045 for ; Fri, 3 Jan 2020 12:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1578082112; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=NsgsgzhDUrojf1SPbpoT3LAfQi1+bO+x5zCoMJPEzV0=; b=Evj3WzawpzOwnnmGjNavTSvmGQ+u+Kqe9sV17In9QIwh5Sbk+ULLY6f9wH4dPMm5 hGUz32jgD1Lsh8D3MwG4z386Srznt8L2st2X9SmbeXTf84zjkaCpnP62F5KWcnGsQi9 fxSE6RkJnxCPyAe3iMqTj7XNxQs2QPfgieuk4hPY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: <20191230031428.77C11F406C5@rfc-editor.org> Date: Fri, 3 Jan 2020 20:08:32 +0000 Cc: ian.farrer@telekom.de, mikael.abrahamsson@t-systems.se, Ignas Bagdonas , Warren Kumari , Mahesh Jethanandani , te.hasegawa2@gmail.com Content-Transfer-Encoding: quoted-printable Message-ID: <0100016f6d061466-e249bd11-584c-4a1d-8bbc-ac28d55d90f5-000000@email.amazonses.com> References: <20191230031428.77C11F406C5@rfc-editor.org> To: Netconf X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.01.03-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Editorial Errata Reported] RFC8572 (5950) X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 03 Jan 2020 20:08:36 -0000 Yes, this errata should be accepted. An obvious typo. Kent // as author > On Dec 29, 2019, at 10:14 PM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC8572, > "Secure Zero Touch Provisioning (SZTP)". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5950 >=20 > -------------------------------------- > Type: Editorial > Reported by: Tetsuya Hasegawa >=20 > Section: 5.1. Initia >=20 > Original Text > ------------- > 7. Devices that support decrypting SZTP artifacts MUST posses the >=20 > Corrected Text > -------------- > 7. Devices that support decrypting SZTP artifacts MUST possess the >=20 > Notes > ----- >=20 >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8572 (draft-ietf-netconf-zerotouch-29) > -------------------------------------- > Title : Secure Zero Touch Provisioning (SZTP) > Publication Date : April 2019 > Author(s) : K. Watsen, I. Farrer, M. Abrahamsson > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG From nobody Fri Jan 3 12:15:42 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 E8584120045; Fri, 3 Jan 2020 12:15:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ibagdona@gmail.com, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157808253991.9004.6225199091140820567.idtracker@ietfa.amsl.com> Date: Fri, 03 Jan 2020 12:15:39 -0800 Archived-At: Subject: [netconf] netconf - New Meeting Session Request for IETF 107 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 20:15:40 -0000 A new meeting session request has just been submitted by Mahesh Jethanandani, a Chair of the netconf working group. --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Mahesh Jethanandani Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 37 Conflicts to Avoid: Chair Conflict: netmod httpbis tcpm idr Technology Overlap: opsarea opsawg Key Participant Conflict: bfd People who must be present: Mahesh Jethanandani Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jan 3 12:16:32 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 DD6B1120045; Fri, 3 Jan 2020 12:16:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ibagdona@gmail.com, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157808258989.9089.9534743277734970686.idtracker@ietfa.amsl.com> Date: Fri, 03 Jan 2020 12:16:29 -0800 Archived-At: Subject: [netconf] netconf - Update to a Meeting Session Request for IETF 107 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 20:16:30 -0000 An update to a meeting session request has just been submitted by Mahesh Jethanandani, a Chair of the netconf working group. --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Mahesh Jethanandani Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: netmod httpbis tcpm idr Technology Overlap: opsarea opsawg Key Participant Conflict: bfd People who must be present: Mahesh Jethanandani Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jan 5 08:53: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 B21641200EB; Sun, 5 Jan 2020 08:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0DLEcWskXak; Sun, 5 Jan 2020 08:53:31 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E794D120018; Sun, 5 Jan 2020 08:53:31 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1E29EF406F7; Sun, 5 Jan 2020 08:53:08 -0800 (PST) To: te.hasegawa2@gmail.com, kent+ietf@watsen.net, ian.farrer@telekom.de, mikael.abrahamsson@t-systems.se X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: warren@kumari.net, iesg@ietf.org, netconf@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200105165308.1E29EF406F7@rfc-editor.org> Date: Sun, 5 Jan 2020 08:53:08 -0800 (PST) Archived-At: Subject: [netconf] [Errata Held for Document Update] RFC8572 (5950) X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 05 Jan 2020 16:53:34 -0000 The following errata report has been held for document update for RFC8572, "Secure Zero Touch Provisioning (SZTP)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5950 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Tetsuya Hasegawa Date Reported: 2019-12-30 Held by: Warren Kumari (Ops AD) (IESG) Section: 5.1. Initia Original Text ------------- 7. Devices that support decrypting SZTP artifacts MUST posses the Corrected Text -------------- 7. Devices that support decrypting SZTP artifacts MUST possess the Notes ----- -------------------------------------- RFC8572 (draft-ietf-netconf-zerotouch-29) -------------------------------------- Title : Secure Zero Touch Provisioning (SZTP) Publication Date : April 2019 Author(s) : K. Watsen, I. Farrer, M. Abrahamsson Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Jan 7 00:28:41 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 12F8B120024; Tue, 7 Jan 2020 00:28:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157838571900.20942.1252382087340522771@ietfa.amsl.com> Date: Tue, 07 Jan 2020 00:28:39 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 08:28:39 -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 : Generic YANG-related System Capabilities and YANG-Push Notification Capabilities Authors : Balazs Lengyel Alexander Clemm Benoit Claise Filename : draft-ietf-netconf-notification-capabilities-09.txt Pages : 24 Date : 2020-01-07 Abstract: This document proposes two YANG modules. The module ietf-system- capabilities provides a structure that can be used to specify any YANG related system capability. The module ietf-notification-capabilities allows a publisher to specify capabilities related to "Subscription to YANG Datastores" (YANG-Push). It proposes to use YANG Instance Data to document this information and make it already available at implementation-time, but also allow it to be reported at run-time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-09 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 7 01:29: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 1F2F912006F for ; Tue, 7 Jan 2020 01:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E24zOLC5O2x6 for ; Tue, 7 Jan 2020 01:29:54 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150074.outbound.protection.outlook.com [40.107.15.74]) (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 8A0D7120019 for ; Tue, 7 Jan 2020 01:29:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CGOZ3PRtTlvLuvita8baYChyQ8d2jLphB4PtjNUZ9Lnhmi+0IWrmWOHHeB+W+WmRKCY/qSVgQ6w6eC3A9Etp4/0qC5az48wHzJFaMHEcc0gWAz1zi//LAJ+8vHgo0ZRsO1EHOGyaBEhB6bXdUOFMZ14kwgZJSS5klK5t6llI9HCanTpapFs8zm4/VTQu5th+v9/1rV1Y3q2a2FxH4AXP2FlVFZ1RQGSTvw0GGsayCQzrSfst9LC6tMCdNx3CLoWKNFKrh0RnazhTeYCKUp3XRIQBh2IECOpJcBwsDp0pdSkNSMrbVF/zKqaS+EaC4yTWGEfE2I8Tz+c8ue/DTciu2g== 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=T36ph0NZi580/20KyI0Fw/chakE+UK+tvll5jW8txcY=; b=gPDUPnjO+H+9nYo+G1AztgYddOS0TzWydIy3vXWN1uybyUjC8Tj16wAc0BsZEdkk6uNa6ndldVh8mjUzJlD2/uepgZY87xwZ37wDW9wTm43AfypDstsPo8TKuIfM9PfO7HXF6NHlVafuAona58fvWJ6Tr/ZA3EiR9DbM/ZHqjdPLLd+6r7dT5ZjBwt9YhSfixnUe3NTM5vjcl26LbQDohuF3IgPGOh5jGewl/rbPaa6GwepJsy63vbepP9VZxkUb2K/cipSrYe+8qntETjuul3JKbRDVmSezGe2RSl6UQ8Q9hHlrrS2058dx6pVxtjdZm0jkeEY71Zm5vCXN8rjaKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T36ph0NZi580/20KyI0Fw/chakE+UK+tvll5jW8txcY=; b=mw9hWPDI4TmU0SWTB7Y2SXDWRMzFY5MzMMg43foqpARndSQkiTn8BKCRKTPkho02eX/YHrh8Ccg82Th4yYNRCKNUguClUgnKFCa91EaC10OcBILOF+RCV19OjAfF95MY8f03dv+TismACwLWC2cMN+dh5f+QO9Ru7Rsittof+FI= Received: from VI1PR07MB4047.eurprd07.prod.outlook.com (52.134.20.154) by VI1PR07MB4125.eurprd07.prod.outlook.com (52.134.21.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.6; Tue, 7 Jan 2020 09:29:51 +0000 Received: from VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686]) by VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686%5]) with mapi id 15.20.2623.008; Tue, 7 Jan 2020 09:29:51 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "netconf@ietf.org" Thread-Topic: FW: New Version Notification for draft-ietf-netconf-notification-capabilities-09.txt Thread-Index: AdXFPQGS7aQNnWudS1GuwL+/l2UqKg== Date: Tue, 7 Jan 2020 09:29:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d5eccc36-6c4e-4725-59f4-08d793542564 x-ms-traffictypediagnostic: VI1PR07MB4125: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(366004)(396003)(39860400002)(136003)(199004)(189003)(66476007)(66446008)(7696005)(64756008)(66946007)(66556008)(9686003)(55016002)(966005)(6506007)(26005)(33656002)(186003)(478600001)(316002)(6916009)(5660300002)(71200400001)(76116006)(81156014)(15650500001)(81166006)(52536014)(9326002)(8936002)(66574012)(86362001)(8676002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4125; H:VI1PR07MB4047.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cnoD6609EDXsmSo15DMrn6gE8rHJK81HyRoCsaYImm5e1xvdhiAVyeSdx+4EdbupoTn7ISBG0PmT5YZM3aaXvBH+KBzYi0xcKtv5cIDuZueq209Gq/Heeo4oUDfCuhL23hqpJYqEbf02Bhu/ytHvVYP3kebSRtIrJ+Roe+KcRSBpsCD4yqD4BdgGsaKSJuXZ+VNjwqBlsQbzdUsE7FJkMpjZ+cDwTAoR9HEai0Y8Ox4L1ek/Oqf41DXmernrkrEv5vP8lOQU05z5mG4kHL9+1DxiZPGiGsAWXOT+E6lDFq0vBJfbbAhSKKZTYLajkoHhWDnjtv4S4ajyDRXayCxJM4gYlT/vWO9yfEngKw9WerGWP27sHwtrJb6OGohybHRmBLzmGio3ZOchHyTtf2xQoKf84usUMaQspWSjYlOb4HBHw5SojpkIZ8zuvoJ55bViAWvsN6wabc4z6rPzotPvCCpNpY/igU/hVloFZ6m3FjQ= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_VI1PR07MB4047E273BCFB8FFB37906C83F03F0VI1PR07MB4047eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d5eccc36-6c4e-4725-59f4-08d793542564 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 09:29:50.8644 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eX7tlW1d6oJ2rRztdW9rQz0xr6R9YSAWYfsWHE1xMkqjJUw0YLqoQn0/AQ8jIHgr3wH8Y4fR6OygdVz230/YA0wA3BbY7ScAU8bJ/SIotWA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4125 Archived-At: Subject: [netconf] FW: New Version Notification for draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 09:29:57 -0000 --_000_VI1PR07MB4047E273BCFB8FFB37906C83F03F0VI1PR07MB4047eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, A new version, draft-ietf-netconf-notification-capabilities-09 is publishe= d. The single real change is that we split the YANG module into two: ietf-syst= em-capabilities for supporting any YANG related system capability and ietf-= notification-capabilities for YANG-Push related capabilities. However this single change, necessitated a number of editorial changes in t= he text. (abstract, introduction, separate chapters for the two modules, up= dated example instance-data, registering 2 YAMs instead of one). We believe the draft is ready for a second round of WG Last Call. Please in= itiate it. regards Balazs [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-09.txt internet-drafts@ietf.org Tue, 07 January 2020 08:28 UTCShow header A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration WG of the IETF. Title : Generic YANG-related System Capabilities and YANG= -Push Notification Capabilities Authors : Balazs Lengyel Alexander Clemm Benoit Claise Filename : draft-ietf-netconf-notification-capabilities-09.t= xt Pages : 24 Date : 2020-01-07 Abstract: This document proposes two YANG modules. The module ietf-system- capabilities provides a structure that can be used to specify any YANG related system capability. The module ietf-notification-capabilities allows a publisher to specify capabilities related to "Subscription to YANG Datastores" (YANG-Push). It proposes to use YANG Instance Data to document this information and make it already available at implementation-time, but also allow it to be reported at run-time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabiliti= es/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-09 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capab= ilities-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-notification-capabil= ities-09 --_000_VI1PR07MB4047E273BCFB8FFB37906C83F03F0VI1PR07MB4047eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

A new version,  draft-ietf-netconf-notificat= ion-capabilities-09 is published.

The single real change is that we split the YANG = module into two: ietf-system-capabilities for supporting any YANG related s= ystem capability and ietf-notification-capabilities for YANG-Push related c= apabilities.

However this single change, necessitated a number= of editorial changes in the text. (abstract, introduction, separate chapte= rs for the two modules, updated example instance-data, registering 2 YAMs i= nstead of one).

We believe the draft is ready for a second round = of WG Last Call. Please initiate it.

regards Balazs

[netconf] I-D Action: draft-ietf-netconf-notification-capabilities-09.t= xt

internet-draft= s@ietf.org Tue, 07 January 2020 08:28 UTCShow header 

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

 
        Title   &nbs=
p;       : Generic YANG-related System Capabi=
lities and YANG-Push Notification Capabilities
        Authors   &n=
bsp;     : Balazs Lengyel
           &nbs=
p;            &=
nbsp; Alexander Clemm
           &nbs=
p;            &=
nbsp; Benoit Claise
        Filename   &=
nbsp;    : draft-ietf-netconf-notification-capabilities-09.t=
xt
        Pages   &nbs=
p;       : 24
        Date    =
;        : 2020-01-07
 
Abstract:
   This document proposes two YANG modules.  The module=
 ietf-system-
   capabilities provides a structure that can be used to spe=
cify any
   YANG related system capability.
 
   The module ietf-notification-capabilities allows a publis=
her to
   specify capabilities related to "Subscription to YAN=
G Datastores"
   (YANG-Push).  It proposes to use YANG Instance Data =
to document this
   information and make it already available at implementati=
on-time, but
   also allow it to be reported at run-time.

 


 


The IETF datatracker status page for this draft is:


https://datatracker.ietf.org/doc/draft-ietf-netconf-no=
tification-capabilities/


 


There are also htmlized versions available at:


https://tools.ietf.org/html/draft-ietf-netconf-notificati=
on-capabilities-09


https://datatracker.ietf.org/doc/html/draft-iet=
f-netconf-notification-capabilities-09


 


A diff from the previous version is available at:


https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ne=
tconf-notification-capabilities-09


 


 


 
--_000_VI1PR07MB4047E273BCFB8FFB37906C83F03F0VI1PR07MB4047eurp_-- From nobody Tue Jan 7 05:04:50 2020 Return-Path: <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-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 DCD4B1200D8 for ; Tue, 7 Jan 2020 05:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 Jhi4ZH2HWpoa for ; Tue, 7 Jan 2020 05:04:46 -0800 (PST) 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 02D7D120044 for ; Tue, 7 Jan 2020 05:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1578402284; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=KnXlUhT+24F5CvSX6gf3IaRS5xWzyS7LGfJjSRfgnqE=; b=Spt+U+Oybxk0S3ZBllDk6uQvMo8kriChfTJJlSyhM7eChvxXCnPMeK3P9d201mE/ E06kLio/T6F5HNl935me9LjN+4uQp1dJMeIDUfnDvMfzH4zltXnB3pJVE7f1bg4dfll O57JjkOSrpuS0tdV04bNGDSVAc0QEE64tSz0SkW8= From: Kent Watsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 7 Jan 2020 13:04:44 +0000 References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> To: NETCONF Working Group In-Reply-To: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> Message-ID: <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.01.07-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 13:04:48 -0000 Dear WG, This is a fairly substantial update that defines a generic = "ietf-system-capabilities=E2=80=99 module and a separate "ietf-notification-capabilities=E2=80=9D module = that augments into it. We could start WGLC #2 now, but it would be good to get a few high-level = reactions from the WG before doing so. Please provide comments as to if you believe the draft is ready for WGLC = #2. Thanks, Kent // as shepherd > On Jan 7, 2020, at 3:28 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version (-09) has been submitted for = draft-ietf-netconf-notification-capabilities: > = https://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-capab= ilities-09.txt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > = https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilit= ies/ >=20 > Diff from previous version: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-notification-capabi= lities-09 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the diff is available at tools.ietf.org. >=20 > IETF Secretariat. >=20 From nobody Tue Jan 7 08:40: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 793961207FC for ; Tue, 7 Jan 2020 08:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NesDTQAt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0jeIs/qw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF0Y4KVU9Kjn for ; Tue, 7 Jan 2020 08:39:59 -0800 (PST) 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 E6F90120884 for ; Tue, 7 Jan 2020 08:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3950; q=dns/txt; s=iport; t=1578415084; x=1579624684; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kTBCsSi578WD75oww0Cj6WvZ/wnUb1mwFHJMBPYgHls=; b=NesDTQAtVudzCnjqYtZxQ5lYQuep4p+f+4vTThn9GKVYvI2YJqqsO9lR haEGoHo4cT7g1Jz+8tN4MfudOV2XvjFKOykyrIaSrjVfDtFMwVUW/M7oW RRUhQcW7ljmgdMSBsS8poidQ61vO4vJhidD2PfNOSoudOGfeGGov78qfc w=; IronPort-PHdr: =?us-ascii?q?9a23=3Asam58x22b+FOwxJesmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1L6KOLtaQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbAwA3sxRe/5xdJa1cChwBAQEBAQc?= =?us-ascii?q?BAREBBAQBAYFrBAEBCwGBU1AFbFggBAsqCoN/g0YDiwVOghGYDYFCgRADVAk?= =?us-ascii?q?BAQEMAQEYCwoCAQGDe0UCF4FSJDcGDgIDDQEBBAEBAQIBBQRthTcMhV4BAQE?= =?us-ascii?q?BAgEBARAREQwBASwJAwQHBAIBCBEEAQEBAgImAgICJQsVCAgCBAESCBMHgwG?= =?us-ascii?q?CRgMOIAECDKFgAoE4iGF1gTKCfgEBBYFJQYMBGIIMCYEOKAGMGBqBQT+BEUe?= =?us-ascii?q?CTD6CZAEBAgEBGIEPDS2DDjKCLJBBnmIKgjaHNY8Cgkd2hweQG45TgUiHDJI?= =?us-ascii?q?NAgQCBAUCDgEBBYFoI4FYcBU7gmwJRxgNjRI4gzuFFIU/dIEojCUBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.69,406,1571702400"; d="scan'208";a="698681769" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jan 2020 16:38:04 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 007Gc3sd006137 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jan 2020 16:38:04 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 10:38:02 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 11:38:01 -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.1473.3 via Frontend Transport; Tue, 7 Jan 2020 11:38:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n9lMQYgfEUDjlvpL9OM6TxlDHURZsNHqx107gURtCZRjPBY1A/jpKTX3OU6Z8X7SK0aq+yP6cvZOpywFB201vf7aAYiul7PD6NsiHGVe5RxHCMPa7oI9T6Steb6jsYqAIvmpnD1mIHAoI1AT4drl2CwvDKBZfXAd89YJ49WEp9t+9KrgH1z9gdSaMyPRmSSJaa7GalOIQ23D+N8jEogYu/sUnHd7YLxl21mUR3clm6QIOqHv36yXLHysWpn1jahRdbeVRYOP2UALzZK+lTqqmNFuc2M0YuqlQM/0bdUIVCUNaBO9pFIjGjDemg053J50kVVqCVQJXCHZrv8P2puaXg== 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=kTBCsSi578WD75oww0Cj6WvZ/wnUb1mwFHJMBPYgHls=; b=Q6xO3su9/Hk1cFKUOhmo8Q+xKmjMenS+bKSe3V0SThtFSycpC2NUzh47InbHKcJP23kg7JaBWG1T2DRXEDfVl+c2Mdvf1sKHi+512kiz20XMg8KWVbPIEp4xuvZNumAPHO90gsO3Jw7zlJZkGE10dysTgikFt1dz9VKN1AzDIoVGPYFa58Q7lM6gcK9S9D5OiVaC754yrCMofiW3RKeujThyTI4D/U8Utp48veOHYvqzZqtY/G+XILX94usXq8mF4H+1QvqOvKxVAVhV6zSRB9Okq+86tP5aD2GV+cGzQVuGVfUJo2/6478NqNfBzmFt46MtIN3PRtsSggZDSxGdHQ== 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=kTBCsSi578WD75oww0Cj6WvZ/wnUb1mwFHJMBPYgHls=; b=0jeIs/qwaz3lCMAGK9HMLb21jRIibZwbzH0ahWplvdg2a0BOd4XTlTjEMNOG40KqmIdwQiSIJ1RSdWJRBHo6lrVoTClXXiPD9isWNqB7AEO1fICMhyY+7cbIbKSER5xHkLVkhv45vzN0NvSti0vlIcC1fgSAZH4OfOyhm1CPZWs= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3646.namprd11.prod.outlook.com (20.178.253.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.15; Tue, 7 Jan 2020 16:38:01 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1%7]) with mapi id 15.20.2602.015; Tue, 7 Jan 2020 16:38:01 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen , NETCONF Working Group Thread-Topic: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt Thread-Index: AQHVxVsSt5Mms9ZtVUqYtH0CGNIWiaffY4HQ Date: Tue, 7 Jan 2020 16:38:01 +0000 Message-ID: References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> In-Reply-To: <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.52] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d5c1301d-b22c-4fe3-dc18-08d7938ff601 x-ms-traffictypediagnostic: MN2PR11MB3646: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(39860400002)(346002)(376002)(189003)(13464003)(199004)(316002)(66574012)(8676002)(9686003)(55016002)(110136005)(81156014)(81166006)(966005)(86362001)(71200400001)(478600001)(8936002)(15650500001)(2906002)(66556008)(66946007)(66476007)(66446008)(64756008)(53546011)(5660300002)(186003)(7696005)(52536014)(33656002)(26005)(6506007)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3646; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3NgaDE0KIKExdAhVTeps0UQQ9WfnbYjLcFcKlUhK/u+/cpfmvvNDZ7PZUn+9ChqeOjnFDFmyolAcO525Np9D9tmNuIdT6rUmVb+yHKxRqNRCkkEm2xSft7HMDWwl4EYNbUDZgIiqQNupzXn3T7DkmJAi1K9dz5KaiinwaEZBs6wXdNGYLHXIL8n2jT6tvcAa27qmlsfNRD8Ozsdo52S5U+AVcSy3XpbFnfsNul5WZDlfwJ0OfOlY6zAaDp/0dkBEzYCm4MRlgkcPxPvZw6hDs05jked5JANDX+CzvjwwI4taf1jVaRp/lpYU5nu/kSgedtX/y17Dn4wBDZNqpzZntPy6GKZfjGswq5+A0qX2yacO7KDDzatGZevGDXx/G0xOpj8Us8db4Ig9JZoaT2t+Kxzhx0a68/dIjPTHotLt/v/iRaeNo/6zXyKKT9+JUd//Vr5CHuJvdfXS2vYIbSwlVppBfxXTb3Rt5rjmlaqsg96QaC4yPyAxl8t6jZBrpyaHdjggrTp2bTj/ecOkeAZy35g0QBkaxL3iul/MKEe1reA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d5c1301d-b22c-4fe3-dc18-08d7938ff601 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 16:38:01.0969 (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: 2Dgj1qp4V8GnSCmgxfg5vR7wUXAoZlrq3OUXqlop/ASVHsCddST+QGQSnVBziE5FGu9YvYBtygRSF/j+eibvjA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3646 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 16:40:01 -0000 SGkgS2VudCwgYWxsLA0KDQpNeSBtYWluIGNvbmNlcm4gd2l0aCB0aGlzIG1vcmUgZ2VuZXJhbCBt b2RlbCBpcyB3aGV0aGVyIHRoaXMgbW9kZWwgaGFzIHRoZSByaWdodCBzdHJ1Y3R1cmUgdG8gZ2Vu ZXJpY2FsbHkgbW9kZWwgZGV2aWNlIGNhcGFiaWxpdGllcy4NCg0KSXQgaXMgb2Z0ZW4gdGhlIGNh c2UgdGhhdCBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgbWlnaHQgZGlmZmVyIGJ5IHRoZSBsaW5lY2Fy ZCB0eXBlIHRoYXQgaGFzIGJlZW4gaW5zZXJ0ZWQgKHdoaWNoIGNhbiBjaGFuZ2UgZHluYW1pY2Fs bHkpLCBhbmQvb3IgdGhlIHR5cGUgb2YgaW50ZXJmYWNlLg0KDQpBcyBpdCBzdGFuZHMsIEkgZG9u J3QgdGhpbmsgdGhhdCB0aGUgY3VycmVudCBtb2RlbCBjYW4gZGVzY3JpYmUgY2FwYWJpbGl0aWVz IGZvciB0aGlzIGNsYXNzIG9mIGRldmljZXM6DQogLSBwZXIgZGF0YXN0b3JlIGNhcGFiaWxpdGll cyBhcmUgbm90IGdyYW51bGFyIGVub3VnaA0KIC0gcGVyIGRhdGFub2RlIGNhcGFiaWxpdGllcyBh cmUgdG9vIGdyYW51bGFyIChlLmcuIHlvdSB3b3VsZCBlbmQgdXAgd2l0aCBzZXBhcmF0ZSBjYXBh YmlsaXRpZXMgZm9yIGVhY2ggaW50ZXJmYWNlLCBhbmQgZXZlbiB0aGVuIHRoZXkgY2FuIG9ubHkg ZGVzY3JpYmUgdGhlIGludGVyZmFjZXMgdGhhdCBleGlzdCwgb3IgbWlnaHQgZXhpc3QpLg0KDQpQ b3NzaWJseSwgaGF2aW5nIGEgeHBhdGggc2VsZWN0b3IgdG8gaWRlbnRpZnkgdGhlIHNldCBvZiBu b2RlcyB0aGF0IHRoZSBjYXBhYmlsaXRpZXMgYXBwbHkgdG8gbWlnaHQgYmUgZmxleGlibGUgZW5v dWdoLCBidXQgdGhpcyB3b3VsZCBncmVhdGx5IGluY3JlYXNlIGNvbXBsZXhpdHkuICBQZXJoYXBz IHNvbWV0aGluZyBsaWtlIGEgdW5pb24gb2YgYSBub2RlIHNlbGVjdG9yIGFuZCB4cGF0aCBzZWxl Y3RvciBjb3VsZCB3b3JrPw0KDQpJIGRvbid0IHdhbnQgdG8gc2xvdyB3b3JrIGRvd24sIGJ1dCBJ IGRvIHF1ZXN0aW9uIHdoZXRoZXIgd2UgYXJlIHJ1c2hpbmcgdG8gYSBnZW5lcmljIGNhcGFiaWxp dHkgc29sdXRpb24gdGhhdCB3b24ndCBiZSBzdWZmaWNpZW50IGZvciBtYW55IGRldmljZXMgb3V0 IHRoZXJlLiAgSGVuY2UgcGFydCBvZiBtZSB3b25kZXJzIHdoZXRoZXIgaXQgbWlnaHQgYmUgYmV0 dGVyIHRvIGdldCB0aGUgb3JpZ2luYWwgbm90aWZpY2F0aW9uIGNhcGFiaWxpdGllcyBkcmFmdCBm aW5pc2hlZCAoYXMgYSB0aW1lIHRvIG1hcmtldCBzb2x1dGlvbiksIGFuZCB0aGVuIGxvb2sgYXQg dGhlIGdlbmVyaWMgY2FwYWJpbGl0aWVzIHJlcXVpcmVtZW50cy9zb2x1dGlvbiB3aXRoIGEgYml0 IGxlc3MgdGltZSBwcmVzc3VyZS4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IG5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIEtlbnQgV2F0c2VuDQpTZW50OiAwNyBKYW51YXJ5IDIwMjAgMTM6MDUNClRvOiBO RVRDT05GIFdvcmtpbmcgR3JvdXAgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25l dGNvbmZdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3Rp ZmljYXRpb24tY2FwYWJpbGl0aWVzLTA5LnR4dA0KDQoNCkRlYXIgV0csDQoNClRoaXMgaXMgYSBm YWlybHkgc3Vic3RhbnRpYWwgdXBkYXRlIHRoYXQgZGVmaW5lcyBhIGdlbmVyaWMgImlldGYtc3lz dGVtLWNhcGFiaWxpdGllc+KAmQ0KbW9kdWxlIGFuZCBhIHNlcGFyYXRlICJpZXRmLW5vdGlmaWNh dGlvbi1jYXBhYmlsaXRpZXPigJ0gbW9kdWxlIHRoYXQgYXVnbWVudHMgaW50byBpdC4NCg0KV2Ug Y291bGQgc3RhcnQgV0dMQyAjMiBub3csIGJ1dCBpdCB3b3VsZCBiZSBnb29kIHRvIGdldCBhIGZl dyBoaWdoLWxldmVsIHJlYWN0aW9ucyBmcm9tIHRoZSBXRyBiZWZvcmUgZG9pbmcgc28uDQoNClBs ZWFzZSBwcm92aWRlIGNvbW1lbnRzIGFzIHRvIGlmIHlvdSBiZWxpZXZlIHRoZSBkcmFmdCBpcyBy ZWFkeSBmb3IgV0dMQyAjMi4NCg0KVGhhbmtzLA0KS2VudCAvLyBhcyBzaGVwaGVyZA0KDQoNCj4g T24gSmFuIDcsIDIwMjAsIGF0IDM6MjggQU0sIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90 ZToNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uICgtMDkpIGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3Ig ZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXM6DQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0 aW9uLWMNCj4gYXBhYmlsaXRpZXMtMDkudHh0DQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNr ZXIgcGFnZSBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYg0KPiBp bGl0aWVzLw0KPiANCj4gRGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb246DQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNh cGENCj4gYmlsaXRpZXMtMDkNCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPiBzdWJtaXNzaW9uIHVudGlsIHRo ZSBkaWZmIGlzIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IElFVEYgU2VjcmV0 YXJpYXQuDQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Tue Jan 7 19:11:13 2020 Return-Path: <0100016f83226d35-4c825571-7fe8-4074-8f6c-d9994e2ed37a-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 E9C8B120041 for ; Tue, 7 Jan 2020 19:11:11 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 jcJ4gbBzfKNQ for ; Tue, 7 Jan 2020 19:11:10 -0800 (PST) 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 A629312002E for ; Tue, 7 Jan 2020 19:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1578453069; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=emfxYQO2C5BcKjgUWFT/SDj1EINaeovJ+5MvGTI9GoA=; b=dBZCxuEC6TIQ6jvp5DJ/LMHJz9LqE5DdI9PTXmXcivu4v2RcIMg0UQkibvQsQMjb FkkCT8pj6S6izd9qgQnvcgy+QuMT9mvDmRzRIaBHUXZiYJ34Xg0jwcr47t0rNyG4am8 CSWe6acFHsf2Y0kik9IRNqdIPXIuqFnWHkrFeuw0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: Date: Wed, 8 Jan 2020 03:11:09 +0000 Cc: NETCONF Working Group Content-Transfer-Encoding: quoted-printable Message-ID: <0100016f83226d35-4c825571-7fe8-4074-8f6c-d9994e2ed37a-000000@email.amazonses.com> References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> To: "Rob Wilton (rwilton)" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.01.08-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 03:11:12 -0000 > On Jan 7, 2020, at 11:38 AM, Rob Wilton (rwilton) = wrote: >=20 > Hi Kent, all, >=20 > My main concern with this more general model is whether this model has = the right structure to generically model device capabilities. >=20 > It is often the case that hardware capabilities might differ by the = linecard type that has been inserted (which can change dynamically), = and/or the type of interface. The base =E2=80=9Csystem-capabilities=E2=80=9D is augmentable. An = augment can be defined someday to provide that behavior? > As it stands, I don't think that the current model can describe = capabilities for this class of devices: > - per datastore capabilities are not granular enough How so? > - per datanode capabilities are too granular (e.g. you would end up = with separate capabilities for each interface, and even then they can = only describe the interfaces that exist, or might exist). Your xpath selector would resolve this, as would a templates (I think). = Maybe we could view this copy/paste-based approach as good enough for = the short term? > Possibly, having a xpath selector to identify the set of nodes that = the capabilities apply to might be flexible enough, but this would = greatly increase complexity. Perhaps something like a union of a node = selector and xpath selector could work? Perhaps the =E2=80=9Cnode-selector=E2=80=9D could be put into a = =E2=80=98choice=E2=80=99 with it being the only descendent, for now, = thus enabling a future extension to define a fancier selector? > I don't want to slow work down, but I do question whether we are = rushing to a generic capability solution that won't be sufficient for = many devices out there. Hence part of me wonders whether it might be = better to get the original notification capabilities draft finished (as = a time to market solution), and then look at the generic capabilities = requirements/solution with a bit less time pressure. The response from previous WGLC was that folks wanted the more generic = solution now. FWIW, when I did this in a past life, I had a get-hardware-inventory = RPC, an offline a hardware-catalog, and an ability to set (either = relative or absolute) capabilities (we called them =E2=80=9Cfeatures=E2=80= =9D) based on the hardware present. Key to the solution was being able = to pull the inventory from a live device and, in lieu of that, to = model/simulate the inventory a device might have (for pre-provisioning). Kent // contributor From nobody Tue Jan 7 20:46: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 2DFB9120043 for ; Tue, 7 Jan 2020 20:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 60j65ZLyNwTa for ; Tue, 7 Jan 2020 20:46:17 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101FC120041 for ; Tue, 7 Jan 2020 20:46:17 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id i23so1413668lfo.7 for ; Tue, 07 Jan 2020 20:46:16 -0800 (PST) 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=Uo0BDh4WdYeTmieCXC25bobI0Pf9Lo0mjPj8X53/vow=; b=fLtMF+wcY/TJoa4AyYlhCAbkRQSZsB+83VItmCNrGgB3aS3WXSkIAwYhSE6HuW6LVY Tz59RwfFv8YF5vEd/Dwqa7kAwl/Ep2USsi/XyKWePP92a6pDfdgOs0eVXQF7IMJfSG1q J3dOHQVo/yQX4irLmwVje2Nh/wiBn5qhd3QqbMAV2rqdgmyciz5vOILchu7BufK5HAT3 n35O9yamrMrW6rXpqtQI/IUiMLQGDO/d6YCVGb4jyrcUSrZADIxC6Xz3YcYdFwskMoDG DqmV2Kzj/1TKcc8RDqrf+XZJc+ZOVph3xF3/Ficf1mrPlgRZb+f9r323LuDVIHOexvKy uaxg== 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=Uo0BDh4WdYeTmieCXC25bobI0Pf9Lo0mjPj8X53/vow=; b=fTEoWn+LPiGNkdwos6UOFrqaxBGv2ELMOagwH4trFzXHtlO8vX2rPJKlq3nKO8pvJI RE4WaFioD5CybcQhfEvpSsO+KqyUM+SZbux1c+CU5/PIULLlFLk78t+reHMpeU0PqSyW xFksKuZ8WsV8pIeNpRefolvg0TimfskzaCLshgcYjQNiiWkKL5l+Z2u1kr11FyNUjR+i u8d4ua9V/Jns4zPe7RVZgq1uTfDmtGzl0Xs85LBsF6i12B0peiSPiE23gJs0IAQnHQ6P 9rv2lf2W/menxwnaYrMIjrBjMTc2wGCR13URPj/tGT1T+LpbIlIkoBhBJ6GuGa63ROlO JHMQ== X-Gm-Message-State: APjAAAWVIw9RfGYCNbOxYwvDKK1dHrHZ2WvSfECXMTaymn9Te2G/q7dd Vr1zDoBEBUauDKE7mz9wW0s/qPbwM8LCtAnm7vt4ew== X-Google-Smtp-Source: APXvYqwWzAe9nnzs9p0t5hv0xBF2jqskunNsWqZxlnvKWF+7ESXtYlk6SYkxwmTBECMIaVF8/UsAC37b86/B37rVOLg= X-Received: by 2002:ac2:430d:: with SMTP id l13mr1827091lfh.112.1578458775136; Tue, 07 Jan 2020 20:46:15 -0800 (PST) MIME-Version: 1.0 References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> In-Reply-To: <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> From: Andy Bierman Date: Tue, 7 Jan 2020 20:46:04 -0800 Message-ID: To: Kent Watsen Cc: NETCONF Working Group Content-Type: multipart/alternative; boundary="00000000000095bc5d059b9992f7" Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 04:46:20 -0000 --00000000000095bc5d059b9992f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I think the new system capabilities module is good enough. The node-instance-identifier type allows a key to be missing, which provides some entry reuse. My concerns are with the notification capabilities module. - notification-support: why is this an enumeration instead of bits? suggest: typedef notification-support { type bits { bit notifications-for-config-changes-supported { description "The publisher is capable of sending notifications for config=3Dtrue nodes, but not for config=3Dfalse nodes for the relevant scope and subscription type." ; } bit notifications-for-state-changes-supported { description "The publisher is capable of sending notifications for config=3Dfalse nodes, but not for config=3Dtrue nodes for the relevant scope and subscription type." ; } } - can the names be shorter (config-changes, state-changes)? these names seem redundant and verbose - update-period this object seems implementation-specific. The description should be less normative and use 2119 language A periodic subscription to the selected data nodes must specify a value that is at least as large or greater than this Suggest: s/must/SHOULD/ - supported-update-period - this is very implementation-specific, especially as a leaf-list instead of a leaf with a range - also has 'must' language that is inappropriate; s/must/SHOULD/ - max-objects-per-update - extremely implementation-specific; Does this assume a server generates updates by counting objects and stopping when this value is reached? - the text is not clear if it means objects or object instances? Do child nodes count as instances? IMO this object should be removed or changes to max. bytes per update (also implementation-specific) - supported-excluded-change-type - this union has overlapping enumeration implied values suggest assigning value -2; and value -1; to none and all enums Andy On Tue, Jan 7, 2020 at 5:04 AM Kent Watsen wrote: > > Dear WG, > > This is a fairly substantial update that defines a generic > "ietf-system-capabilities=E2=80=99 > module and a separate "ietf-notification-capabilities=E2=80=9D module tha= t > augments into it. > > We could start WGLC #2 now, but it would be good to get a few high-level > reactions > from the WG before doing so. > > Please provide comments as to if you believe the draft is ready for WGLC > #2. > > Thanks, > Kent // as shepherd > > > > On Jan 7, 2020, at 3:28 AM, internet-drafts@ietf.org wrote: > > > > > > A new version (-09) has been submitted for > draft-ietf-netconf-notification-capabilities: > > > https://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-capa= bilities-09.txt > > > > > > The IETF datatracker page for this Internet-Draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabili= ties/ > > > > Diff from previous version: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-notification-capab= ilities-09 > > > > Please note that it may take a couple of minutes from the time of > submission > > until the diff is available at tools.ietf.org. > > > > IETF Secretariat. > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --00000000000095bc5d059b9992f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I think the new system capabilities= module is good enough.
The node-instance-identifier type allows = a key to be missing, which provides some entry reuse.

<= div>My concerns are with the notification capabilities module.
=C2=A0 - notification-support:=C2=A0 why is this an enumeratio= n instead of bits?

suggest:

=C2=A0 =C2=A0 =C2=A0typedef notification-support {=C2=A0 =C2=A0 = =C2=A0 =C2=A0 type bits {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bit notific= ations-for-config-changes-supported {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 description "The publisher is capable of sending
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 notifications for config=3Dtrue node= s, but not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for config= =3Dfalse nodes for the relevant scope
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 and subscription type." ;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bit notifications-for-st= ate-changes-supported {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descri= ption "The publisher is capable of sending
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 notifications for config=3Dfalse nodes, but not=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for config=3Dtrue nodes f= or the relevant scope
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a= nd subscription type." ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0- can the names be s= horter (config-changes, state-changes)?
=C2=A0 =C2=A0 these names= seem redundant and verbose

=C2=A0 - update-period=
=C2=A0 =C2=A0 this object seems implementation-specific.=C2=A0
=C2=A0 =C2=A0 The description should be less normative and use 211= 9 language

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 A periodic subscription to the selected data nodes must
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specify a value that is at least as large o= r greater than
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this

=C2=A0 =C2=A0 =C2=A0 Suggest:=C2=A0 s/must/SHOULD/

<= /div>
=C2=A0 - supported-update-period
=C2=A0 =C2=A0 - this i= s very implementation-specific, especially as a leaf-list instead of a
=C2=A0 =C2=A0 =C2=A0 leaf with a range
=C2=A0 =C2=A0 - also= has 'must' language that is inappropriate; s/must/SHOULD/

=C2=A0- max-objects-per-update
=C2=A0 =C2=A0- ex= tremely implementation-specific; Does this assume a server generates update= s
=C2=A0 =C2=A0 =C2=A0by counting objects and stopping when this = value is reached?
=C2=A0 =C2=A0- the text is not clear if it mean= s objects or object instances? Do child nodes count
=C2=A0 =C2=A0= =C2=A0as instances? IMO this object should be removed or changes to max. b= ytes per update
=C2=A0 =C2=A0 =C2=A0(also implementation-specific= )

=C2=A0- supported-excluded-change-type
=C2=A0 =C2=A0- this union has overlapping enumeration implied values
=
=C2=A0 =C2=A0 suggest assigning value -2; and value -1; to none and al= l enums


Andy



On Tue, Jan 7, 2020 at 5:04 AM Kent Watsen <kent+ietf@watsen.net> wrote:

Dear WG,

This is a fairly substantial update that defines a generic "ietf-syste= m-capabilities=E2=80=99
module and a separate "ietf-notification-capabilities=E2=80=9D module = that augments into it.

We could start WGLC #2 now, but it would be good to get a few high-level re= actions
from the WG before doing so.

Please provide comments as to if you believe the draft is ready for WGLC #2= .

Thanks,
Kent // as shepherd


> On Jan 7, 2020, at 3:28 AM, internet-drafts@ietf.org wrote:
>
>
> A new version (-09) has been submitted for draft-ietf-netconf-notifica= tion-capabilities:
> https:/= /www.ietf.org/internet-drafts/draft-ietf-netconf-notification-capabilities-= 09.txt
>
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatrack= er.ietf.org/doc/draft-ietf-netconf-notification-capabilities/
>
> Diff from previous version:
> https://www.= ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-notification-capabilities-09=
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the diff is available at tools.ietf.org.
>
> IETF Secretariat.
>

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--00000000000095bc5d059b9992f7-- From nobody Wed Jan 8 08:19: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 9FB9C120877 for ; Wed, 8 Jan 2020 08:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dKDK6Wq2VRk for ; Wed, 8 Jan 2020 08:19:43 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130075.outbound.protection.outlook.com [40.107.13.75]) (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 9FDFE120868 for ; Wed, 8 Jan 2020 08:19:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i3SXKw4IEs0M3Ednx+4FC3jSpFIsC0iSgWV7zwPlbnsgzlg83KKWSa/mSriXEsu8idLBAY1Kj9swekR48HgG3UTUchDp98HmPhsrZwyAyIDvYId4i34O4ELcmtXGhSBnrzPRcExd7feJ441DhZLWTzBUXDrRwDfDrHPK7b5vPtfEiBRPwv2SZwQFsB/uJwyElaaHEE1gjaeTpH5udzLlPTkJhWgzqnqLfIx5JlHUP+7wXJv4lPJ2W25+QkFCWOCTOwM4mkGDiIfqDbjGZdzPfxw72O2j141EWTeNhY5FVWeB/Cx8CX+eWoOzp6cXtfGZdXyqWRygdcEJQ/EVyoBJUw== 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=VRg79MF4yBjy9CjjcD7YNjacoBzA+NnVZ5zq2fdsFqI=; b=Og4zGqCrsuNd4J14wahuNfGxKtXwZBx29M+4keUEOIkzX7w0Lpha6EcSsrkUdWAJ15SQPCMbkZu28XT/u+Qhva8CtZt5xDoBsmz7q7dAq8reO7VzSWB+gdnuodaCmr2yQr8Gc+PiFfkKWVlqzjl6vAKLeSDSXDyYsW0MJUIjokhmXbFJ7WGQLEcRqvZa5TgRHfSO1JHxz3ZHTW7pt+Mn5E/9JhfntP+z+54LEEBjiLL8NGXuv+EK6tuTkUvNiyXhgO/yXfn/PaTfgP44Pf9cVjmldZiT7v/yrh3Q7wVUNInyKWTl+YAnFfGPIda8kbUK50iN7vU5lMiaI0uMC4BM0g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VRg79MF4yBjy9CjjcD7YNjacoBzA+NnVZ5zq2fdsFqI=; b=KiHdcQT7dv6QIt/3DQsYLNJMd1I9X+YHRAEl2641/8B7s2++wX0v+ilGyj2iMs6GnHMoeV18RGj5yel6Gm9fNYkh1Y4scmT49kux6ysSGrMKEb8JtH9MPJCqo5MYM99uBLRwsDZc7PH6ZmFkYnbS1aSJxD4/fpt20T6ifbFT7ac= Received: from VI1PR07MB4047.eurprd07.prod.outlook.com (52.134.20.154) by VI1PR07MB5568.eurprd07.prod.outlook.com (20.178.14.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.5; Wed, 8 Jan 2020 16:19:38 +0000 Received: from VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686]) by VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686%5]) with mapi id 15.20.2644.006; Wed, 8 Jan 2020 16:19:38 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Kent Watsen , "Rob Wilton (rwilton)" CC: NETCONF Working Group Thread-Topic: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt Thread-Index: AQHVxVsUq6ljVkP3y0ecYCN5b7iLjKffZvCAgACw5YCAANp+cA== Date: Wed, 8 Jan 2020 16:19:38 +0000 Message-ID: References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <0100016f83226d35-4c825571-7fe8-4074-8f6c-d9994e2ed37a-000000@email.amazonses.com> In-Reply-To: <0100016f83226d35-4c825571-7fe8-4074-8f6c-d9994e2ed37a-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 73404266-b743-4d06-67fa-08d794568f36 x-ms-traffictypediagnostic: VI1PR07MB5568: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(346002)(396003)(39860400002)(376002)(189003)(199004)(13464003)(478600001)(110136005)(8676002)(15650500001)(81156014)(86362001)(81166006)(8936002)(33656002)(316002)(71200400001)(52536014)(2906002)(4326008)(66574012)(55016002)(9686003)(85182001)(5660300002)(85202003)(76116006)(186003)(53546011)(66616009)(26005)(6506007)(66556008)(66946007)(66446008)(966005)(7696005)(66476007)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5568; H:VI1PR07MB4047.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jujpxOTbjP1T6jW3vPrpQB6W94WAaZdw29vSTuOJpS721dDJNIcRqYpIOWdY6r3FQE7gdGPNz2u8zjFVrisI2HBlJcfV48/w/kU4db9hON7vr/e7yNLSVUHm3BkYBCeeXV0tvzQjK9mLrw8bnV1kLgNiPMdSG0o76Crd843fYFja3LrXxV9fkYm2bwhCzBCPINGiqrVJvL0rQqTWDVORkm4X0qnOdtJ5Pa/fZCiekhx/Wyb+IM7NT6KwSKSRoS/N1iqfPiF2gyz2ZNEa+2O6bpLUGKZdwz3nmx3bWDOgN+3wU5GNn9PhWhKrQEIYRv85VycfmXnWmNHuZYKvHgArIwqGqiFR1Qx9ywcI8ynx2FNUDFuaHDtQ2GEesbUpNmj7zv0uePi9SmTliyWeFETLV2OrSa+iq5XAbO48+5r40cjsVF8CVyNbHhTU8SUXEHUrekzuYJYIYAQW2YBxuHvxKTBa/tjU8EXuB2ToKt9C5vGeBgDyuolD0vvqIXkiNZTWpq1RL8CYNgLxVWxjmTs2ukh2ZzT5e/+7PYib9DHtbTlETCRhryW4l5DO/4K9SHO6 x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0061_01D5C647.CDBA1640" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 73404266-b743-4d06-67fa-08d794568f36 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 16:19:38.5051 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ivrzat5qNUN/IaVOoOQ47bz894+Ip+XDvS/IprGLld3GCMAdqW0Z134eRE0t1x/xmv1WKZegoBZJA/g0gUnqxM6uhEzfcKWOMJvS6MgdIqU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5568 Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 16:19:53 -0000 ------=_NextPart_000_0061_01D5C647.CDBA1640 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Rob, Kent, Would the following be acceptable? OLD: list per-node-capabilities { key "node-selector"; leaf node-selector { type nacm:node-instance-identifier; NEW: list per-node-capabilities { choice node-selector { leaf node-selector { type nacm:node-instance-identifier; } } Later you can augment in an Xpath filter or a string with '*' and '?' = wildcards or whatever you want. (The list does not need a key as it is config=3Dfalse) Regards Balazs -----Original Message----- From: netconf On Behalf Of Kent Watsen Sent: 2020. janu=C3=A1r 8., szerda 4:11 To: Rob Wilton (rwilton) Cc: NETCONF Working Group Subject: Re: [netconf] New Version Notification - = draft-ietf-netconf-notification-capabilities-09.txt > On Jan 7, 2020, at 11:38 AM, Rob Wilton (rwilton) = wrote: >=20 > Hi Kent, all, >=20 > My main concern with this more general model is whether this model has = the right structure to generically model device capabilities. >=20 > It is often the case that hardware capabilities might differ by the = linecard type that has been inserted (which can change dynamically), = and/or the type of interface. The base =E2=80=9Csystem-capabilities=E2=80=9D is augmentable. An = augment can be defined someday to provide that behavior? > As it stands, I don't think that the current model can describe = capabilities for this class of devices: > - per datastore capabilities are not granular enough How so? > - per datanode capabilities are too granular (e.g. you would end up = with separate capabilities for each interface, and even then they can = only describe the interfaces that exist, or might exist). Your xpath selector would resolve this, as would a templates (I think). = Maybe we could view this copy/paste-based approach as good enough for = the short term? > Possibly, having a xpath selector to identify the set of nodes that = the capabilities apply to might be flexible enough, but this would = greatly increase complexity. Perhaps something like a union of a node = selector and xpath selector could work? Perhaps the =E2=80=9Cnode-selector=E2=80=9D could be put into a = =E2=80=98choice=E2=80=99 with it being the only descendent, for now, = thus enabling a future extension to define a fancier selector? > I don't want to slow work down, but I do question whether we are = rushing to a generic capability solution that won't be sufficient for = many devices out there. Hence part of me wonders whether it might be = better to get the original notification capabilities draft finished (as = a time to market solution), and then look at the generic capabilities = requirements/solution with a bit less time pressure. The response from previous WGLC was that folks wanted the more generic = solution now. FWIW, when I did this in a past life, I had a get-hardware-inventory = RPC, an offline a hardware-catalog, and an ability to set (either = relative or absolute) capabilities (we called them = =E2=80=9Cfeatures=E2=80=9D) based on the hardware present. Key to the = solution was being able to pull the inventory from a live device and, in = lieu of that, to model/simulate the inventory a device might have (for = pre-provisioning). Kent // contributor _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_0061_01D5C647.CDBA1640 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTIwMDEwODE2MTkzN1owIwYJKoZIhvcNAQkEMRYEFEA/pjtQ8qYLdQGwqK1Tq8lDCLweMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQByL+5v0BnQh2s8WV0z1C3TBzI930AKqUggHmJjHy0U7lW2xEEdWXeM S+h8+87OG+0OWpoqeR4euaUG9BfS45SnNB0Az8c0onm+XcjJ0cp6MNIdVVrXVTkaInoKbDXMRax/ nNpcfLm5EGbEqCyCSxsNYIKKR7tt6rdWNc5GHJbyxby4XBdDo+kqaFDYB75p1mPsJJN6RpTNtZ8P io1dbqF6auRJJwHoAAanWI2NrrweemOcBffzL+BSkWr3/zcg2eNveznq2Ek+0qheKcgLZUSwLlrU 538K6ccDFEz9oAcDoz8UGxqJ1T/DyMmzB19/Ps6t/JZbFbibTvoKrZoBNpAmAAAAAAAA ------=_NextPart_000_0061_01D5C647.CDBA1640-- From nobody Thu Jan 9 03:45:02 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 2525712025D for ; Thu, 9 Jan 2020 03:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 t7lGFq3U_xrv for ; Thu, 9 Jan 2020 03:44:59 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6CE12011E for ; Thu, 9 Jan 2020 03:44:59 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 67A501AE0983 for ; Thu, 9 Jan 2020 12:44:55 +0100 (CET) Date: Thu, 09 Jan 2020 12:44:18 +0100 (CET) Message-Id: <20200109.124418.638921574270389971.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 11:45:01 -0000 SGksDQoNCkkgdGhpbmsgdGhpcyBkb2N1bWVudCBpcyBoZWFkaW5nIGluIHRoZSByaWdodCBkaXJl Y3Rpb24uICBIb3dldmVyLCBJDQp0aGluayB3ZSBuZWVkIHRvIGNsYXJpZnkgaG93IHRoZXNlICJz eXN0ZW0gY2FwYWJpbGl0aWVzIiBhcmUgZGlmZmVyZW50DQpmcm9tIE5FVENPTkYgYW5kIFJFU1RD T05GIGNhcGFiaWxpdGllcy4gIEFsc28gZGVmaW5lIHRoZSB0ZXJtcw0KInN5c3RlbSBjYXBhYmls aXR5IiBhbmQgcGVyaGFwcyAicHJvdG9jb2wgY2FwYWJpbGl0eSIgKHRvIG1ha2UgdGhlDQpkaXN0 aW5jdGlvbiBjbGVhcikuICBUaGVuIHVzZSAic3lzdGVtIGNhcGFiaWxpdHkiIGluc3RlYWQgb2Yg anVzdA0KImNhcGFiaWxpdHkiIGluIHRoZSBkb2MuDQoNCkl0IHNheXM6DQoNCiAgICAgICBTeXN0 ZW0gY2FwYWJpbGl0aWVzIG1heSBpbmNsdWRlIGNhcGFiaWxpdGllcyBvZiBhDQogICAgICAgTkVU Q09ORiBvciBSRVNUQ09ORiBzZXJ2ZXIgb3IgYSBub3RpZmljYXRpb24gcHVibGlzaGVyLg0KDQpJ IHRoaW5rIHRoYXQgdGhpcyBpcyBub3QgY29ycmVjdDsgdGhleSBkZXNjcmliZSB0aGUgY2FwYWJp bGl0aWVzIG9mIGENCnNlcnZlciAod2hlcmUgdGhlIHRlcm0gInNlcnZlciIgaXMgYXMgZGVmaW5l ZCBpbiBSRkMgODM0MikuDQoNCg0KVGhlIGRvY3VtZW50IHNheXMgdGhhdCBzeXN0ZW0gY2FwYWJp bGl0aWVzIGNhbiBiZSBzcGVjaWZpZWQgIm9uDQpzeXN0ZW0vcHVibGlzaGVyIGxldmVsLCBkYXRh c3RvcmUgbGV2ZWwgb3IgZm9yIHNwZWNpZmljIGRhdGEgbm9kZXMiLg0KDQpbZWRpdDogczsvcHVi bGlzaGVyOzsgc2luY2UgaXQgaXMgbm93IG1vcmUgZ2VuZXJhbCB0aGFuIG5vdGlmc10NCg0KQnV0 IHlvdSBkb24ndCBhY3R1YWxseSBzcGVjaWZ5IGFueXRoaW5nIG9uIHRoZSBkYXRhc3RvcmUgbGV2 ZWw7IHRoaXMNCmlzIGRvbmUgYnkgZG9pbmcgYSBub3JtYWwgZGF0YSBub2RlIGNhcGFiaWxpdHkg Zm9yIHRoZSByb290IG5vZGUuDQpUaGlzIGlzIG5vdCBleHBsaWNpdGx5IHN0YXRlZCBidXQga2lu ZCBvZiBpbXBsaWVkLiAgSSBzdWdnZXN0IHRoYXQNCnRoaXMgaXMgZWl0aGVyIHJlbW92ZWQsIG9y IG1hZGUgZXhwbGljaXQuDQoNCg0KDQoNCi9tYXJ0aW4NCg0KS2VudCBXYXRzZW4gPGtlbnQraWV0 ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gDQo+IERlYXIgV0csDQo+IA0KPiBUaGlzIGlzIGEgZmFp cmx5IHN1YnN0YW50aWFsIHVwZGF0ZSB0aGF0IGRlZmluZXMgYSBnZW5lcmljDQo+ICJpZXRmLXN5 c3RlbS1jYXBhYmlsaXRpZXPigJkNCj4gbW9kdWxlIGFuZCBhIHNlcGFyYXRlICJpZXRmLW5vdGlm aWNhdGlvbi1jYXBhYmlsaXRpZXPigJ0gbW9kdWxlIHRoYXQNCj4gYXVnbWVudHMgaW50byBpdC4N Cj4gDQo+IFdlIGNvdWxkIHN0YXJ0IFdHTEMgIzIgbm93LCBidXQgaXQgd291bGQgYmUgZ29vZCB0 byBnZXQgYSBmZXcNCj4gaGlnaC1sZXZlbCByZWFjdGlvbnMNCj4gZnJvbSB0aGUgV0cgYmVmb3Jl IGRvaW5nIHNvLg0KPiANCj4gUGxlYXNlIHByb3ZpZGUgY29tbWVudHMgYXMgdG8gaWYgeW91IGJl bGlldmUgdGhlIGRyYWZ0IGlzIHJlYWR5IGZvcg0KPiBXR0xDICMyLg0KPiANCj4gVGhhbmtzLA0K PiBLZW50IC8vIGFzIHNoZXBoZXJkDQo+IA0KPiANCj4gPiBPbiBKYW4gNywgMjAyMCwgYXQgMzoy OCBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiA+IA0KPiA+IA0KPiA+IEEg bmV3IHZlcnNpb24gKC0wOSkgaGFzIGJlZW4gc3VibWl0dGVkIGZvcg0KPiA+IGRyYWZ0LWlldGYt bmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0aWVzOg0KPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFi aWxpdGllcy0wOS50eHQNCj4gPiANCj4gPiANCj4gPiBUaGUgSUVURiBkYXRhdHJhY2tlciBwYWdl IGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0aWVzLw0K PiA+IA0KPiA+IERpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uOg0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFi aWxpdGllcy0wOQ0KPiA+IA0KPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4gc3VibWlzc2lvbg0KPiA+IHVudGls IHRoZSBkaWZmIGlzIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPiANCj4gPiBJRVRG IFNlY3JldGFyaWF0Lg0KPiA+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gbmV0Y29uZkBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Thu Jan 9 08:58: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 72CA7120809 for ; Thu, 9 Jan 2020 08:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRo7IPV26hca for ; Thu, 9 Jan 2020 08:57:51 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70058.outbound.protection.outlook.com [40.107.7.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A9D1200B5 for ; Thu, 9 Jan 2020 08:57:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ktM6lUo35koV9p7wJZ5IHP0HZaqO2icFCFqa6uGib6BPS2Cvrkk32ACUEAFHcUxLIJwNa+cz08wMsUOnAYNqEscecT7gdkGvv5goDZ5MpsdKzpoiuhVM+i1hcZAalehRlcbgDtSLVmHofJI7nVB4gQyjnCORaRcmUWIWoR05rf3UR7XOHsH0h60s82RKvLf8+oVfK2JGlN6mKkTxYOd1o6LIAyjJL0L+k6uFk9vOZ/0Y1ggeMyN31yFhGEoWLJuonb+2C8oEzCINPehDnJocoELBETJ373Zy4LXcl1vDZ59fvqyiF+v1hOaCWt7pNNqciS1hDuA5eZkcbtJV2mnFiA== 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=J8z+VSxgizKQxYk/C0J7sBnJ6MLzHd8/mxayCpVJgN4=; b=AJm4qgzbzokwKl2nWo7W8vuWoI144V0wUwXyvwxNH64kjtFCGEUPaZ+KUWpSatxUqcfIlGZaFU3Zfs62MoROhiBs/39blDOUlWDtMfgKa5BxisczWWpGUZi+E7qRVg85nOekaUAHmXoPn8FTEvMFEJkE4ar6ZUBdoDoMNS2jzAdqqL8CdMFk3jiJxXUjhwRtgJ3ucKFU9nZCgXt7T+4KStEUk0ze4fQlx8TfXkizQfWmEshr8BgOqkoI0o02dMWa3rH6Kqu1niViA4BXEjpEMMr8htxTiYl5nbmldA32pJMz91uYQtxOaL7Nxp2gIRrmfV0vMLP+DtNzwlm00ljUGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J8z+VSxgizKQxYk/C0J7sBnJ6MLzHd8/mxayCpVJgN4=; b=fTxUkkD75tkxUFh0OBv2e02G6zaCQGHa05Lfi0NoCyn7DHXr4WoEOQe+C1TLSnL6E+XLzO59heBvwhn3w5uZmXVIh1smU2JNkF1WDaSoobCpeOiCc1ykkG6cIsHg4bmYG50W4U1HJZhNJtEceQEelw3vkQL2hOGbJYMzrhgPnsk= Received: from VI1PR07MB4047.eurprd07.prod.outlook.com (52.134.20.154) by VI1PR07MB5789.eurprd07.prod.outlook.com (20.178.121.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.5; Thu, 9 Jan 2020 16:57:47 +0000 Received: from VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686]) by VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686%5]) with mapi id 15.20.2644.006; Thu, 9 Jan 2020 16:57:47 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Martin Bjorklund , "netconf@ietf.org" Thread-Topic: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt Thread-Index: AQHVxVsUq6ljVkP3y0ecYCN5b7iLjKfiOYkAgABQqpA= Date: Thu, 9 Jan 2020 16:57:47 +0000 Message-ID: References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <20200109.124418.638921574270389971.mbj@tail-f.com> In-Reply-To: <20200109.124418.638921574270389971.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0b46ca67-2728-4440-e540-08d795250dec x-ms-traffictypediagnostic: VI1PR07MB5789: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(366004)(346002)(39860400002)(396003)(13464003)(189003)(199004)(51444003)(66574012)(33656002)(86362001)(186003)(110136005)(81166006)(81156014)(85182001)(85202003)(55016002)(71200400001)(966005)(478600001)(6506007)(26005)(53546011)(2906002)(66446008)(15650500001)(9686003)(316002)(8676002)(5660300002)(52536014)(66476007)(66616009)(66556008)(7696005)(76116006)(64756008)(66946007)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5789; H:VI1PR07MB4047.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: r/hu0astP7uU3d4MjHJ2h51KlT6AwsJDIom7ajJ92aHdl3vgIfHomGvLJgxjDuA93dp+Ug8j17bqD6ezUhg4iOtU94JXz4XXE589jWT4GSOPbaUOGg82tha/YNoS6XQSl+fPIAYxWNHxVHv0nkI+A47M+oGh+Fd6/nDT0+J6+DmPYOp3rRsSLLNQNsGIpG1DMcyVPq7veptCb0HL5i81nwBTi85EUMd1d/4mYlwCz7QAPTCsZli0WkxNa09Atax6GWgUnmccCn4RVFDDmcFU2cEwqJ1GIuVlpHNPofXXvXmqQQP+8uqxfksD90yOifWbZ0Ewerl2S4Nme13S5tcl6psR6k2dxqkjI632ouIyn8W4Nlxbth33QB+ksiPzANB9AgapSd4Rqo59QO0TPU26svXtNUVxzMokj+FaWAfiEjZnwmDG8moaPR+o6Ar2NRaBEbrIrsRmB3dDXvVDJv1UDkPkvYGfi5zWFCBY3v9I4BYt+4PPcYg78vWX4ocpy1zapCjLir5IlwQs/WOyiBexILsOzkOkuGAsEQUtzrozAVH3O6AlsI5dsT3xfeDiZYFNHQob0yA8Kh5fpmo9v1Eoug== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00DD_01D5C716.4C2AF7F0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b46ca67-2728-4440-e540-08d795250dec X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 16:57:47.4463 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: i9V+U58btzTlzfteIT/kRpokoEbiCC+O52xWoUgTjJvRUsxmvmGOwQbfPevyuemsW6N6qCdkjvqnQGvr0JPMspvAaMpG1snGQxq0msU7/2U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5789 Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 16:58:01 -0000 ------=_NextPart_000_00DD_01D5C716.4C2AF7F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: netconf On Behalf Of Martin Bjorklund Sent: 2020. janu=C3=A1r 9., cs=C3=BCt=C3=B6rt=C3=B6k 12:44 To: netconf@ietf.org Subject: Re: [netconf] New Version Notification - = draft-ietf-netconf-notification-capabilities-09.txt Hi, I think this document is heading in the right direction. However, I = think we need to clarify how these "system capabilities" are different = from NETCONF and RESTCONF capabilities. Also define the terms "system = capability" and perhaps "protocol capability" (to make the distinction = clear). Then use "system capability" instead of just "capability" in = the doc. BALAZS: What would be your definition? I wanted to use a term that is as broad as possible because: - we can leave the definition of specific capabilities to other RFCs, so = there is no need to be too specific here - it is not just NETCONF and RESTCONF. We are already working on = draft-ietf-netconf-https-notif which brings in HTTP; we might have = capabilities that define e.g. the logging file sizes or really anything. = We do not want to restrict the possibilities now. Later we may decide = that logging file sizes belong here or maybe not. I am at loss how to define system capabilities: "Any capability of the = system implementing the server or the publisher." Does that really add = any information? It says: System capabilities may include capabilities of a NETCONF or RESTCONF server or a notification publisher. I think that this is not correct; they describe the capabilities of a = server (where the term "server" is as defined in RFC 8342). BALAZS: We do want to ALSO include publisher capabilities. E.g. The = minimum (reporting) period or the maximum-number of changes per = notification is not a capability of the server. It is the capability of = the publisher. Do you want to remove the words "RESTCONF or NETCONF" ? The document says that system capabilities can be specified "on = system/publisher level, datastore level or for specific data nodes". [edit: s;/publisher;; since it is now more general than notifs] But you don't actually specify anything on the datastore level; this is = done by doing a normal data node capability for the root node. This is not explicitly stated but kind of implied. I suggest that this = is either removed, or made explicit. BALAZS: It is stated in the module: "The special value '/' denotes all data nodes in the datastore." I will also add a sentence: OLD: Capability values can be specified on system/publisher level, datastore level or for specific data nodes (and their contained sub- tree) of a specific datastore. Capability values on a smaller, more specific part of the system's data always override more generic values. NEW: Capability values can be specified on system/publisher level, datastore level (BY SELECTING ALL NODES IN THE DATASTORE) or for = specific data nodes (and their contained sub- tree) of a specific datastore. Capability values on a smaller, more specific part of the system's data always override more generic values. /martin Kent Watsen wrote: >=20 > Dear WG, >=20 > This is a fairly substantial update that defines a generic=20 > "ietf-system-capabilities=E2=80=99 > module and a separate "ietf-notification-capabilities=E2=80=9D module = that=20 > augments into it. >=20 > We could start WGLC #2 now, but it would be good to get a few=20 > high-level reactions from the WG before doing so. >=20 > Please provide comments as to if you believe the draft is ready for=20 > WGLC #2. >=20 > Thanks, > Kent // as shepherd >=20 >=20 > > On Jan 7, 2020, at 3:28 AM, internet-drafts@ietf.org wrote: > >=20 > >=20 > > A new version (-09) has been submitted for > > draft-ietf-netconf-notification-capabilities: > > https://www.ietf.org/internet-drafts/draft-ietf-netconf-notification > > -capabilities-09.txt > >=20 > >=20 > > The IETF datatracker page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-cap > > abilities/ > >=20 > > Diff from previous version: > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-notification-ca > > pabilities-09 > >=20 > > Please note that it may take a couple of minutes from the time of=20 > > submission until the diff is available at tools.ietf.org. > >=20 > > IETF Secretariat. > >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_00DD_01D5C716.4C2AF7F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTIwMDEwOTE2NTc0NVowIwYJKoZIhvcNAQkEMRYEFL3I5aGg9SxjR6HgEzNC5qBJwC02MEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQBredpTflTkrGA+MflTIHAnbK4pYDXPgrZpaLTxf1cxz2P2/lR6A7/N 229dz15xmTPdVipcKtCYsE0yhnu3DYaUNQVADRZmSaFwGHj83ICoBKxcbAOroot1E/Hxv5VSokZo zJSBFb6UyG2WxMd8EZA9JX+qas33QA+aTRocGrRSeE/BZiiu+OterGn/tTzl6hscxOb3CJm5LKKN hO7EdQBdJ395rYTETvSjMSniJm3Cg7/siw/Ew6I8QCzKdaTlaNLFzSMnk3TEP80OgNq+gWpM0Xsi iiB/zTFm9kY9XS8ry/tqS2/q5Ua4REBJmrwT5ouz5439AFLWlhuUliB/JASlAAAAAAAA ------=_NextPart_000_00DD_01D5C716.4C2AF7F0-- From nobody Thu Jan 9 09:14:51 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 1C5D31200A4 for ; Thu, 9 Jan 2020 09:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diV7gaKNWkGX for ; Thu, 9 Jan 2020 09:14:47 -0800 (PST) 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 D8FD8120019 for ; Thu, 9 Jan 2020 09:14:46 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id l2so8063516lja.6 for ; Thu, 09 Jan 2020 09:14:46 -0800 (PST) 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=LxpnWOauNF4Wy9DutnZ1f8VTYQnl7/fh+jpyr3ZBFbs=; b=XtrKRsCaxqiHKnYNckQFzPQpZf97RqerqurF8WjG4rUym+zshHk2RALBrI5StR+7eS H3nWHiXcA3zlbdVXjcUvmkwnzj1807DBSwSqoX1HyJM7kM+g6T6Knagtm7t+BahZBEJy bryBrnfbz6Mh404LgBeRRVZPHZOJmH9f3P/GRxN7EcboqsHgiqir5KL0eURPbe/VnqLE JVqgNfUTCqhUXM+HFc8UkrIGX5rgqB7OnxAuzSskQmQl+UT/u1RA12sOgDDq+dfirwbf 2Qd6dj/DBlXCYLxzS4mJGkL6CeQlYBkF0ekrKCmCsTgv7uYojGuTWkObEHeKi8LLIOoy tTmw== 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=LxpnWOauNF4Wy9DutnZ1f8VTYQnl7/fh+jpyr3ZBFbs=; b=lcEuayipbK2rHvh01HZqYlwYlTUdpvvgfSwcEp92ftbI9FVAP9uqRR2plTOapIiWF3 Tx+KCfQTtVNaGzgIxJL/s+Z6V6TIXJq6ENusxK60Dy2umH45I+lmslewEbEF+TNfaYWy nCYPn8DeqcxfHKyoB9W5V/05gHzbY+p6C85r/2fZslbqHtiEzD3yN9IW4KoS/+PltxsW 9eCWQP5s2Eb8oVu9+040tF0U1Z4gFN/J++vWEnDxh+pFUnCOLFd4wlMjjn54yloJKfvf dlNEx7QZKYDXxg4fToccX4buOlv1qbiV/uE7e35kUG/7g40sAhNFuyaBCgv6SADvfkR0 lxnw== X-Gm-Message-State: APjAAAV9t7aORWEf/6vNK6zZsi/VgwZuB2wXMGDnEHd9yqru5xotlXRE hmkI5aYFWGxP65EZxNBWslD5KOl3WlK/2qXtOOU36Q== X-Google-Smtp-Source: APXvYqxktHBRhMzX/vYksr9QastNXsohYwXDJGcr1zyfg9E9BITSuA8sAl7vmli6LJL27yDU2huElUbPI6zSn+zVK9A= X-Received: by 2002:a2e:7d01:: with SMTP id y1mr7395601ljc.100.1578590085129; Thu, 09 Jan 2020 09:14:45 -0800 (PST) MIME-Version: 1.0 References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <20200109.125407.1696793655072242187.mbjorklu@cisco.com> In-Reply-To: <20200109.125407.1696793655072242187.mbjorklu@cisco.com> From: Andy Bierman Date: Thu, 9 Jan 2020 09:14:34 -0800 Message-ID: To: Martin Bjorklund Cc: Kent Watsen , Netconf Content-Type: multipart/alternative; boundary="000000000000453ce5059bb82529" Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 17:14:50 -0000 --000000000000453ce5059bb82529 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 9, 2020 at 3:54 AM Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I think the new system capabilities module is good enough. > > The node-instance-identifier type allows a key to be missing, which > > provides some entry reuse. > > > > My concerns are with the notification capabilities module. > > > > - notification-support: why is this an enumeration instead of bits? > > > > suggest: > > > > typedef notification-support { > > type bits { > > bit notifications-for-config-changes-supported { > > description "The publisher is capable of sending > > notifications for config=3Dtrue nodes, but not > > for config=3Dfalse nodes for the relevant scope > > and subscription type." ; > > } > > bit notifications-for-state-changes-supported { > > description "The publisher is capable of sending > > notifications for config=3Dfalse nodes, but not > > for config=3Dtrue nodes for the relevant scope > > and subscription type." ; > > } > > } > > > > - can the names be shorter (config-changes, state-changes)? > > these names seem redundant and verbose > > +1 for bits and the suggested shorter names > > > > > - update-period > > this object seems implementation-specific. > > The description should be less normative and use 2119 language > > > > A periodic subscription to the selected data nodes must > > specify a value that is at least as large or greater than > > this > > > > Suggest: s/must/SHOULD/ > > I don't think either is correct. This leaf informs the client what an > acceptable 'period' value is. A client that sends a shorter period > will get a 'period-unsupported' error back, as defined in RFC 8641. > Perhaps rephrase the sentence to: > > A request for a periodic subscription to the selected data nodes > with a smaller period than what this leaf specifies will result in > a 'period-unsupported' error. > > > I agree this is better. > > - supported-update-period > > - this is very implementation-specific, especially as a leaf-list > > instead of a > > leaf with a range > > - also has 'must' language that is inappropriate; s/must/SHOULD/ > > See above. > > > - max-objects-per-update > > - extremely implementation-specific; Does this assume a server > generates > > updates > > by counting objects and stopping when this value is reached? > > - the text is not clear if it means objects or object instances? Do > > child nodes count > > as instances? IMO this object should be removed or changes to max. > > bytes per update > > (also implementation-specific) > > I agree that this is implementation-specific, and a byte-count as > well. It assumes that the implementation uses very static > datastructures. But I think it can be ok - an implementation that > doesn't have such static limits will not instantiate this leaf. > > Then there should be text in the description-stmt that this leaf will not be instantiated if the server implementation does not restrict an update to a specific number of objects. What about the supported-update-period leaf-list? If a server allows any centi-second value from 1 sec to 1 hour then this will be a leaf-list with 5900 instances in it. Since there is no reason to limit the upper-bound (e.g., client wants 1 statistics update per day) this leaf-list will likely have millions of instances in it. IMO this leaf-list should be removed. The minimum-update-period is sufficient. > /martin > Andy > > > > > - supported-excluded-change-type > > - this union has overlapping enumeration implied values > > suggest assigning value -2; and value -1; to none and all enums > > > > > > Andy > > > > > > > > On Tue, Jan 7, 2020 at 5:04 AM Kent Watsen wrote= : > > > > > > > > Dear WG, > > > > > > This is a fairly substantial update that defines a generic > > > "ietf-system-capabilities=E2=80=99 > > > module and a separate "ietf-notification-capabilities=E2=80=9D module= that > > > augments into it. > > > > > > We could start WGLC #2 now, but it would be good to get a few > high-level > > > reactions > > > from the WG before doing so. > > > > > > Please provide comments as to if you believe the draft is ready for > WGLC > > > #2. > > > > > > Thanks, > > > Kent // as shepherd > > > > > > > > > > On Jan 7, 2020, at 3:28 AM, internet-drafts@ietf.org wrote: > > > > > > > > > > > > A new version (-09) has been submitted for > > > draft-ietf-netconf-notification-capabilities: > > > > > > > > https://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-capa= bilities-09.txt > > > > > > > > > > > > The IETF datatracker page for this Internet-Draft is: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabili= ties/ > > > > > > > > Diff from previous version: > > > > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-notification-capab= ilities-09 > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission > > > > until the diff is available at tools.ietf.org. > > > > > > > > IETF Secretariat. > > > > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > --000000000000453ce5059bb82529 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 9, 2020 at 3:54 AM Martin= Bjorklund <mbjorklu@cisco.com= > wrote:
Andy= Bierman <andy@y= umaworks.com> wrote:
> Hi,
>
> I think the new system capabilities module is good enough.
> The node-instance-identifier type allows a key to be missing, which > provides some entry reuse.
>
> My concerns are with the notification capabilities module.
>
>=C2=A0 =C2=A0- notification-support:=C2=A0 why is this an enumeration i= nstead of bits?
>
> suggest:
>
>=C2=A0 =C2=A0 =C2=A0 typedef notification-support {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type bits {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit notifications-for-config-c= hanges-supported {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description "The p= ublisher is capable of sending
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notifications fo= r config=3Dtrue nodes, but not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for config=3Dfal= se nodes for the relevant scope
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and subscription= type." ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit notifications-for-state-ch= anges-supported {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description "The p= ublisher is capable of sending
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notifications fo= r config=3Dfalse nodes, but not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for config=3Dtru= e nodes for the relevant scope
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and subscription= type." ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0 - can the names be shorter (config-changes, state-changes= )?
>=C2=A0 =C2=A0 =C2=A0these names seem redundant and verbose

+1 for bits and the suggested shorter names



>=C2=A0 =C2=A0- update-period
>=C2=A0 =C2=A0 =C2=A0this object seems implementation-specific.
>=C2=A0 =C2=A0 =C2=A0The description should be less normative and use 21= 19 language
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A periodic subscription= to the selected data nodes must
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specify a value that is= at least as large or greater than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Suggest:=C2=A0 s/must/SHOULD/

I don't think either is correct.=C2=A0 This leaf informs the client wha= t an
acceptable 'period' value is.=C2=A0 A client that sends a shorter p= eriod
will get a 'period-unsupported' error back, as defined in RFC 8641.=
Perhaps rephrase the sentence to:

=C2=A0 A request for a periodic subscription to the selected data nodes
=C2=A0 with a smaller period than what this leaf specifies will result in =C2=A0 a 'period-unsupported' error.



I agree this is better.

=
=C2=A0
>=C2=A0 =C2=A0- supported-update-period
>=C2=A0 =C2=A0 =C2=A0- this is very implementation-specific, especially = as a leaf-list
> instead of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf with a range
>=C2=A0 =C2=A0 =C2=A0- also has 'must' language that is inapprop= riate; s/must/SHOULD/

See above.

>=C2=A0 - max-objects-per-update
>=C2=A0 =C2=A0 - extremely implementation-specific; Does this assume a s= erver generates
> updates
>=C2=A0 =C2=A0 =C2=A0 by counting objects and stopping when this value i= s reached?
>=C2=A0 =C2=A0 - the text is not clear if it means objects or object ins= tances? Do
> child nodes count
>=C2=A0 =C2=A0 =C2=A0 as instances? IMO this object should be removed or= changes to max.
> bytes per update
>=C2=A0 =C2=A0 =C2=A0 (also implementation-specific)

I agree that this is implementation-specific, and a byte-count as
well.=C2=A0 It assumes that the implementation uses very static
datastructures.=C2=A0 =C2=A0But I think it can be ok - an implementation th= at
doesn't have such static limits will not instantiate this leaf.


Then there should be text in the descr= iption-stmt that this leaf will not
be instantiated if the server= implementation does not restrict an update
to a specific number = of objects.

What about the supported-update-period= leaf-list?
If a server allows any centi-second value from 1 sec = to 1 hour then this will
be a leaf-list with 5900 instances in it= .=C2=A0 Since there is no reason to limit the upper-bound
(e.g., = client wants 1 statistics update per day) this leaf-list will likely have m= illions
of instances in it.

IMO this lea= f-list should be removed. The minimum-update-period is sufficient.





>=C2=A0 - supported-excluded-change-type
>=C2=A0 =C2=A0 - this union has overlapping enumeration implied values >=C2=A0 =C2=A0 =C2=A0suggest assigning value -2; and value -1; to none a= nd all enums
>
>
> Andy
>
>
>
> On Tue, Jan 7, 2020 at 5:04 AM Kent Watsen <kent+ietf@watsen.net> wrote: >
> >
> > Dear WG,
> >
> > This is a fairly substantial update that defines a generic
> > "ietf-system-capabilities=E2=80=99
> > module and a separate "ietf-notification-capabilities=E2=80= =9D module that
> > augments into it.
> >
> > We could start WGLC #2 now, but it would be good to get a few hig= h-level
> > reactions
> > from the WG before doing so.
> >
> > Please provide comments as to if you believe the draft is ready f= or WGLC
> > #2.
> >
> > Thanks,
> > Kent // as shepherd
> >
> >
> > > On Jan 7, 2020, at 3:28 AM, internet-drafts@ietf.org wrote:
> > >
> > >
> > > A new version (-09) has been submitted for
> > draft-ietf-netconf-notification-capabilities:
> > >
> > ht= tps://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-capabili= ties-09.txt
> > >
> > >
> > > The IETF datatracker page for this Internet-Draft is:
> > >
> > https://data= tracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/
> > >
> > > Diff from previous version:
> > >
> > https:/= /www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-notification-capabilities-0= 9
> > >
> > > Please note that it may take a couple of minutes from the ti= me of
> > submission
> > > until the diff is available at tools.ietf.org.
> > >
> > > IETF Secretariat.
> > >
> >
> > _______________________________________________
> > netconf mailing list
> > netconf@iet= f.org
> > https://www.ietf.org/mailman/listinfo/netconf=
> >
--000000000000453ce5059bb82529-- From nobody Thu Jan 9 10:49:57 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 61A2E12011E for ; Thu, 9 Jan 2020 03:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl26Ekaxs6zk for ; Thu, 9 Jan 2020 03:54:48 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90FB12025D for ; Thu, 9 Jan 2020 03:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6372; q=dns/txt; s=iport; t=1578570887; x=1579780487; h=date:message-id:to:cc:subject:from:in-reply-to: references:mime-version:content-transfer-encoding; bh=u8PVv7tZV7nvZWBN08jYwLTtqx1DVatftrdafO2gVnU=; b=gsHsnfa2Qeq3oI7aRgQiYvSm7GkfG5khDjpsu0iT87b088pun1Hix/gE 1yDDuyb1dMG2zeySd2j0i8GSMVHHpftvWoFTYn5Lz++tzVOaPB1kSz89p o82VsSwV6SMjva1vVrUiYBU1hqeWubApQ3AO7B7IOT/WjmU7semsnVyrt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAwAoFBde/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyDFVUgEiqECYZYgiuIIYluj2GBZwkBAQEOGA0KAQGDe0UCF4F?= =?us-ascii?q?4OBMCAw0BAQQBAQECAQUEbYU3DIVfAQEBAwEBIRE6CQIQCxgCAgkdAgICJTA?= =?us-ascii?q?ZgyeCViUPqXl1gTKEPgIOQYQAgT2BDiiMM4FBP4ERgxM+gmQBAQIBARiBDyA?= =?us-ascii?q?CgyaCXgSgAY8pgkCHNo5sG4JHdocIkB6QIIcOkj2BaSKBWE0jFTuCbAlHGA2?= =?us-ascii?q?NGxoViE+FQEADMAGQZwEB?= X-IronPort-AV: E=Sophos;i="5.69,413,1571702400"; d="scan'208";a="21468606" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jan 2020 11:54:43 +0000 Received: from localhost (x15.tail-f.com [10.147.40.158]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 009Bshbu013401; Thu, 9 Jan 2020 11:54:43 GMT Date: Thu, 09 Jan 2020 12:54:07 +0100 (CET) Message-Id: <20200109.125407.1696793655072242187.mbjorklu@cisco.com> To: andy@yumaworks.com Cc: kent+ietf@watsen.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Outbound-SMTP-Client: 10.147.40.158, x15.tail-f.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: X-Mailman-Approved-At: Thu, 09 Jan 2020 10:49:56 -0800 Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 11:54:50 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBIaSwNCj4gDQo+IEkg dGhpbmsgdGhlIG5ldyBzeXN0ZW0gY2FwYWJpbGl0aWVzIG1vZHVsZSBpcyBnb29kIGVub3VnaC4N Cj4gVGhlIG5vZGUtaW5zdGFuY2UtaWRlbnRpZmllciB0eXBlIGFsbG93cyBhIGtleSB0byBiZSBt aXNzaW5nLCB3aGljaA0KPiBwcm92aWRlcyBzb21lIGVudHJ5IHJldXNlLg0KPiANCj4gTXkgY29u Y2VybnMgYXJlIHdpdGggdGhlIG5vdGlmaWNhdGlvbiBjYXBhYmlsaXRpZXMgbW9kdWxlLg0KPiAN Cj4gICAtIG5vdGlmaWNhdGlvbi1zdXBwb3J0OiAgd2h5IGlzIHRoaXMgYW4gZW51bWVyYXRpb24g aW5zdGVhZCBvZiBiaXRzPw0KPiANCj4gc3VnZ2VzdDoNCj4gDQo+ICAgICAgdHlwZWRlZiBub3Rp ZmljYXRpb24tc3VwcG9ydCB7DQo+ICAgICAgICAgdHlwZSBiaXRzIHsNCj4gICAgICAgICAgIGJp dCBub3RpZmljYXRpb25zLWZvci1jb25maWctY2hhbmdlcy1zdXBwb3J0ZWQgew0KPiAgICAgICAg ICAgICBkZXNjcmlwdGlvbiAiVGhlIHB1Ymxpc2hlciBpcyBjYXBhYmxlIG9mIHNlbmRpbmcNCj4g ICAgICAgICAgICAgICBub3RpZmljYXRpb25zIGZvciBjb25maWc9dHJ1ZSBub2RlcywgYnV0IG5v dA0KPiAgICAgICAgICAgICAgIGZvciBjb25maWc9ZmFsc2Ugbm9kZXMgZm9yIHRoZSByZWxldmFu dCBzY29wZQ0KPiAgICAgICAgICAgICAgIGFuZCBzdWJzY3JpcHRpb24gdHlwZS4iIDsNCj4gICAg ICAgICAgIH0NCj4gICAgICAgICAgIGJpdCBub3RpZmljYXRpb25zLWZvci1zdGF0ZS1jaGFuZ2Vz LXN1cHBvcnRlZCB7DQo+ICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJUaGUgcHVibGlzaGVyIGlz IGNhcGFibGUgb2Ygc2VuZGluZw0KPiAgICAgICAgICAgICAgIG5vdGlmaWNhdGlvbnMgZm9yIGNv bmZpZz1mYWxzZSBub2RlcywgYnV0IG5vdA0KPiAgICAgICAgICAgICAgIGZvciBjb25maWc9dHJ1 ZSBub2RlcyBmb3IgdGhlIHJlbGV2YW50IHNjb3BlDQo+ICAgICAgICAgICAgICAgYW5kIHN1YnNj cmlwdGlvbiB0eXBlLiIgOw0KPiAgICAgICAgICAgfQ0KPiAgICAgICAgIH0NCj4gDQo+ICAgIC0g Y2FuIHRoZSBuYW1lcyBiZSBzaG9ydGVyIChjb25maWctY2hhbmdlcywgc3RhdGUtY2hhbmdlcyk/ DQo+ICAgICB0aGVzZSBuYW1lcyBzZWVtIHJlZHVuZGFudCBhbmQgdmVyYm9zZQ0KDQorMSBmb3Ig Yml0cyBhbmQgdGhlIHN1Z2dlc3RlZCBzaG9ydGVyIG5hbWVzDQoNCg0KDQo+ICAgLSB1cGRhdGUt cGVyaW9kDQo+ICAgICB0aGlzIG9iamVjdCBzZWVtcyBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYy4N Cj4gICAgIFRoZSBkZXNjcmlwdGlvbiBzaG91bGQgYmUgbGVzcyBub3JtYXRpdmUgYW5kIHVzZSAy MTE5IGxhbmd1YWdlDQo+IA0KPiAgICAgICAgICAgICBBIHBlcmlvZGljIHN1YnNjcmlwdGlvbiB0 byB0aGUgc2VsZWN0ZWQgZGF0YSBub2RlcyBtdXN0DQo+ICAgICAgICAgICAgIHNwZWNpZnkgYSB2 YWx1ZSB0aGF0IGlzIGF0IGxlYXN0IGFzIGxhcmdlIG9yIGdyZWF0ZXIgdGhhbg0KPiAgICAgICAg ICAgICB0aGlzDQo+IA0KPiAgICAgICBTdWdnZXN0OiAgcy9tdXN0L1NIT1VMRC8NCg0KSSBkb24n dCB0aGluayBlaXRoZXIgaXMgY29ycmVjdC4gIFRoaXMgbGVhZiBpbmZvcm1zIHRoZSBjbGllbnQg d2hhdCBhbg0KYWNjZXB0YWJsZSAncGVyaW9kJyB2YWx1ZSBpcy4gIEEgY2xpZW50IHRoYXQgc2Vu ZHMgYSBzaG9ydGVyIHBlcmlvZA0Kd2lsbCBnZXQgYSAncGVyaW9kLXVuc3VwcG9ydGVkJyBlcnJv ciBiYWNrLCBhcyBkZWZpbmVkIGluIFJGQyA4NjQxLg0KUGVyaGFwcyByZXBocmFzZSB0aGUgc2Vu dGVuY2UgdG86DQoNCiAgQSByZXF1ZXN0IGZvciBhIHBlcmlvZGljIHN1YnNjcmlwdGlvbiB0byB0 aGUgc2VsZWN0ZWQgZGF0YSBub2Rlcw0KICB3aXRoIGEgc21hbGxlciBwZXJpb2QgdGhhbiB3aGF0 IHRoaXMgbGVhZiBzcGVjaWZpZXMgd2lsbCByZXN1bHQgaW4NCiAgYSAncGVyaW9kLXVuc3VwcG9y dGVkJyBlcnJvci4NCg0KDQo+ICAgLSBzdXBwb3J0ZWQtdXBkYXRlLXBlcmlvZA0KPiAgICAgLSB0 aGlzIGlzIHZlcnkgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMsIGVzcGVjaWFsbHkgYXMgYSBsZWFm LWxpc3QNCj4gaW5zdGVhZCBvZiBhDQo+ICAgICAgIGxlYWYgd2l0aCBhIHJhbmdlDQo+ICAgICAt IGFsc28gaGFzICdtdXN0JyBsYW5ndWFnZSB0aGF0IGlzIGluYXBwcm9wcmlhdGU7IHMvbXVzdC9T SE9VTEQvDQoNClNlZSBhYm92ZS4NCg0KPiAgLSBtYXgtb2JqZWN0cy1wZXItdXBkYXRlDQo+ICAg IC0gZXh0cmVtZWx5IGltcGxlbWVudGF0aW9uLXNwZWNpZmljOyBEb2VzIHRoaXMgYXNzdW1lIGEg c2VydmVyIGdlbmVyYXRlcw0KPiB1cGRhdGVzDQo+ICAgICAgYnkgY291bnRpbmcgb2JqZWN0cyBh bmQgc3RvcHBpbmcgd2hlbiB0aGlzIHZhbHVlIGlzIHJlYWNoZWQ/DQo+ICAgIC0gdGhlIHRleHQg aXMgbm90IGNsZWFyIGlmIGl0IG1lYW5zIG9iamVjdHMgb3Igb2JqZWN0IGluc3RhbmNlcz8gRG8N Cj4gY2hpbGQgbm9kZXMgY291bnQNCj4gICAgICBhcyBpbnN0YW5jZXM/IElNTyB0aGlzIG9iamVj dCBzaG91bGQgYmUgcmVtb3ZlZCBvciBjaGFuZ2VzIHRvIG1heC4NCj4gYnl0ZXMgcGVyIHVwZGF0 ZQ0KPiAgICAgIChhbHNvIGltcGxlbWVudGF0aW9uLXNwZWNpZmljKQ0KDQpJIGFncmVlIHRoYXQg dGhpcyBpcyBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYywgYW5kIGEgYnl0ZS1jb3VudCBhcw0Kd2Vs bC4gIEl0IGFzc3VtZXMgdGhhdCB0aGUgaW1wbGVtZW50YXRpb24gdXNlcyB2ZXJ5IHN0YXRpYw0K ZGF0YXN0cnVjdHVyZXMuICAgQnV0IEkgdGhpbmsgaXQgY2FuIGJlIG9rIC0gYW4gaW1wbGVtZW50 YXRpb24gdGhhdA0KZG9lc24ndCBoYXZlIHN1Y2ggc3RhdGljIGxpbWl0cyB3aWxsIG5vdCBpbnN0 YW50aWF0ZSB0aGlzIGxlYWYuDQoNCg0KL21hcnRpbg0KDQoNCg0KPiAgLSBzdXBwb3J0ZWQtZXhj bHVkZWQtY2hhbmdlLXR5cGUNCj4gICAgLSB0aGlzIHVuaW9uIGhhcyBvdmVybGFwcGluZyBlbnVt ZXJhdGlvbiBpbXBsaWVkIHZhbHVlcw0KPiAgICAgc3VnZ2VzdCBhc3NpZ25pbmcgdmFsdWUgLTI7 IGFuZCB2YWx1ZSAtMTsgdG8gbm9uZSBhbmQgYWxsIGVudW1zDQo+IA0KPiANCj4gQW5keQ0KPiAN Cj4gDQo+IA0KPiBPbiBUdWUsIEphbiA3LCAyMDIwIGF0IDU6MDQgQU0gS2VudCBXYXRzZW4gPGtl bnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gDQo+ID4NCj4gPiBEZWFyIFdHLA0KPiA+DQo+ ID4gVGhpcyBpcyBhIGZhaXJseSBzdWJzdGFudGlhbCB1cGRhdGUgdGhhdCBkZWZpbmVzIGEgZ2Vu ZXJpYw0KPiA+ICJpZXRmLXN5c3RlbS1jYXBhYmlsaXRpZXPigJkNCj4gPiBtb2R1bGUgYW5kIGEg c2VwYXJhdGUgImlldGYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGllc+KAnSBtb2R1bGUgdGhhdA0K PiA+IGF1Z21lbnRzIGludG8gaXQuDQo+ID4NCj4gPiBXZSBjb3VsZCBzdGFydCBXR0xDICMyIG5v dywgYnV0IGl0IHdvdWxkIGJlIGdvb2QgdG8gZ2V0IGEgZmV3IGhpZ2gtbGV2ZWwNCj4gPiByZWFj dGlvbnMNCj4gPiBmcm9tIHRoZSBXRyBiZWZvcmUgZG9pbmcgc28uDQo+ID4NCj4gPiBQbGVhc2Ug cHJvdmlkZSBjb21tZW50cyBhcyB0byBpZiB5b3UgYmVsaWV2ZSB0aGUgZHJhZnQgaXMgcmVhZHkg Zm9yIFdHTEMNCj4gPiAjMi4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiBLZW50IC8vIGFzIHNoZXBo ZXJkDQo+ID4NCj4gPg0KPiA+ID4gT24gSmFuIDcsIDIwMjAsIGF0IDM6MjggQU0sIGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCj4gPiA+DQo+ID4gPg0KPiA+ID4gQSBuZXcgdmVyc2lv biAoLTA5KSBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yDQo+ID4gZHJhZnQtaWV0Zi1uZXRjb25mLW5v dGlmaWNhdGlvbi1jYXBhYmlsaXRpZXM6DQo+ID4gPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxp dGllcy0wOS50eHQNCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgcGFn ZSBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gPiA+DQo+ID4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYmls aXRpZXMvDQo+ID4gPg0KPiA+ID4gRGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb246DQo+ID4gPg0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldGNvbmYt bm90aWZpY2F0aW9uLWNhcGFiaWxpdGllcy0wOQ0KPiA+ID4NCj4gPiA+IFBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4g c3VibWlzc2lvbg0KPiA+ID4gdW50aWwgdGhlIGRpZmYgaXMgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KPiA+ID4NCj4gPiA+IElFVEYgU2VjcmV0YXJpYXQuDQo+ID4gPg0KPiA+DQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRj b25mIG1haWxpbmcgbGlzdA0KPiA+IG5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPg0K From nobody Fri Jan 10 03: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 5F15712002F for ; Fri, 10 Jan 2020 03:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdXnBFKYTuFj for ; Fri, 10 Jan 2020 03:50:57 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80087.outbound.protection.outlook.com [40.107.8.87]) (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 0006E120024 for ; Fri, 10 Jan 2020 03:50:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KomTVmr2rfU5bkaZT226upJXebv22dQDoAuHptjqkhjSyYxsyyoSHqZ2F4lH5AGWPm4SnIRT1THG4r+voohF0fwYRerJ25mFf5Nx1hjw+TzJpxSnQ8e0hxWgtslWNfxTNFOhVsiR3Mf0+ISUJkT72AiMJ+SI0hLdGUFgtUCcSyZC8NnPpngBuOGyLm0ZdSdipmfShl0ErhF2CV1uU0sFashFicYEiDwoAJKwVFjXc8eFwU7qYK8IhtjXDoU8NmtapxXZrrihdYngTdeAPZWW3D+WdTW3lx7s7AYS/Nsljv0OnKf1i1ojb1/X++F4lforSHZg1UXNh97Wsa9Vg+b1GQ== 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=naQblk/QcARAv0D3wQHStBAxygGU+xNeTZYmi2m3kfU=; b=CzJEzkHsmeGueNgYBwWBmXEm2Hymvwa3RCLSUhVk3DXHY0Mr9eA1bMt1en9JyqrK7Ifqzc8xRa9lNm4ipcihMBAiYRokWPzfHANm7lBx/vmiHm06k3JotPkIEsZ7LFsvBudEThNzeZpsihwaBK+oFQoz2MYmDqM5Z433/Pvo8ymKo5iU5UAbSFTYUYrkSpoGTEPpt1vPVfXNXiPezY22bf28YZB/Q5JCFhLKnyXBMNVSI+oaKkAjLt7mLId9jdOZrCnpKdIBlDZuwFHW+PVJpwJEijt9HAhHsqh6yn5VGQn+A9s2av+IRUcidjAupW9e7o9pPYwQrYZM1I6Tqua4Gw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=naQblk/QcARAv0D3wQHStBAxygGU+xNeTZYmi2m3kfU=; b=U1d7qaUZUaFT+RwG+BFx02IqJOuAJcnidkAJobsZV1/F6vlpID5dVKK7aSxwcLUQqQlwn9GF7CvDruT0Yokb5u3Dh7ZC6YRTfZNG5MSy5C9LoEL5pvnNVZs6ElYpy3UJIm0CSgccKlYHfCpUISKuQi26lHzbbC5l6etwwtJg/dI= Received: from VI1PR07MB4047.eurprd07.prod.outlook.com (52.134.20.154) by VI1PR07MB5454.eurprd07.prod.outlook.com (20.178.81.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.6; Fri, 10 Jan 2020 11:50:54 +0000 Received: from VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686]) by VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686%5]) with mapi id 15.20.2644.006; Fri, 10 Jan 2020 11:50:54 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman , Kent Watsen CC: NETCONF Working Group Thread-Topic: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt Thread-Index: AQHVxVsUq6ljVkP3y0ecYCN5b7iLjKfgMloAgAN4LHA= Date: Fri, 10 Jan 2020 11:50:54 +0000 Message-ID: References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 207a2c25-fe15-4ae5-c7b1-08d795c35915 x-ms-traffictypediagnostic: VI1PR07MB5454: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:506; x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(136003)(396003)(39860400002)(189003)(199004)(51914003)(15650500001)(81166006)(81156014)(8676002)(186003)(86362001)(55016002)(85182001)(5660300002)(2906002)(316002)(7696005)(26005)(53546011)(8936002)(33656002)(71200400001)(85202003)(6506007)(4326008)(9686003)(66476007)(110136005)(966005)(66616009)(64756008)(52536014)(478600001)(66556008)(66574012)(66946007)(76116006)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5454; H:VI1PR07MB4047.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: G7K685X2/8P5HppnLpreAXayO+jYsTJvdexbzw2zt+VR1ShEDQL1iNmUrypwVHX1UNOiDRI3NnTtXHN5wYYrk1fSVBi5TDtnNGXeY88imWmC51povsc3yTfCNtDXMunTK5BfQ72ZZLW7PGUDDYHF+X1cxJziWGdtnIDvJrIquXVo/g2weiq+0IfB6/uMq/d3k6GPFKZLrdV2sJW59G+KYnnwYlhioTeg4R/zIU6JWnNoYqdaafo20YUJ6G1qTRGqNw+DP/v8GS1U+80uGMU680I88oKcVrZaKIhE8QYXZoMvifYadobyzhEJMLo/2pcVzRa6LFuPT8lAHCz8+I7oFFBghoqOkdnqhW+T0QsApBWth2ZTZqceVm+5T+PhnNf6RbTjPnSN+VdbpWjcMAF16qgS/zOvLxm44iUaQLW5y6JtMr3QgHUN2W0rBFdaX+BrXRz22v35x7mMS+e4JtoIYuArcYuuXszjyIc0ajjjpgvFAzN7VacTqcyKCvvRPKO+gc5gDG751HaKInm2EG9zNqEmnjBr7zILznU1oBzs2cQ= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0106_01D5C7B4.974C5320" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 207a2c25-fe15-4ae5-c7b1-08d795c35915 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2020 11:50:54.1315 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iAKgZo72C4QHv46CFL6ribptEbbadi6luoJLM2zvTJnbqWdVtq+r+i46+0v+sg9dPRwa+un1FQYIFGBDDM8NH918ceFdPjaHdl9qrwG/ljA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5454 Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 11:51:01 -0000 ------=_NextPart_000_0106_01D5C7B4.974C5320 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0107_01D5C7B4.974C5320" ------=_NextPart_001_0107_01D5C7B4.974C5320 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks for the comments. See below. Balazs =20 From: netconf On Behalf Of Andy Bierman Sent: 2020. janu=C3=A1r 8., szerda 5:46 To: Kent Watsen Cc: NETCONF Working Group Subject: Re: [netconf] New Version Notification - = draft-ietf-netconf-notification-capabilities-09.txt =20 Hi, =20 I think the new system capabilities module is good enough. The node-instance-identifier type allows a key to be missing, which = provides some entry reuse. =20 My concerns are with the notification capabilities module. =20 - notification-support: why is this an enumeration instead of bits? =20 suggest: =20 typedef notification-support { type bits { bit notifications-for-config-changes-supported { description "The publisher is capable of sending notifications for config=3Dtrue nodes, but not for config=3Dfalse nodes for the relevant scope and subscription type." ; } bit notifications-for-state-changes-supported { description "The publisher is capable of sending notifications for config=3Dfalse nodes, but not for config=3Dtrue nodes for the relevant scope and subscription type." ; } } - can the names be shorter (config-changes, state-changes)? these names seem redundant and verbose =20 BALAZS: OK changed to bits and shorter names =20 - update-period this object seems implementation-specific.=20 The description should be less normative and use 2119 language =20 A periodic subscription to the selected data nodes must specify a value that is at least as large or greater than this =20 Suggest: s/must/SHOULD/ BALAZS: OK changed to SHOULD. This is a requirement on the client so I = though it is not an RFC2119 must or should =20 - supported-update-period - this is very implementation-specific, especially as a leaf-list = instead of a leaf with a range - also has 'must' language that is inappropriate; s/must/SHOULD/ BALAZS: OK changed to SHOULD.=20 This is not implementation specific. E.g. the standard 3GPP TS 28.622 = specifies that the system should declare a set of specific values (Not = intervals) that are supported =20 - max-objects-per-update - extremely implementation-specific; Does this assume a server = generates updates by counting objects and stopping when this value is reached? - the text is not clear if it means objects or object instances? Do = child nodes count as instances? IMO this object should be removed or changes to max. = bytes per update (also implementation-specific) BALAZS: RFC8641 defines: identity update-too-big { description "Periodic or on-change push update data trees exceed a maximum size limit. Hints on the estimated size of what was too big may be returned as supplemental information."; } This is the related capability. If you can get back a too-big error, = then you should have a capability declaring what TOO-big means. Bytes are risky. If the value of a string is updated from a single = character to a 2 characters the subscription might become invalid=20 as we have more bytes now. Also it is impossible to calculate the number = of bytes as it depends on future instance data content. You could say the same way that if we count data nodes, if a leaf-list = gets one more entries the subscription could become invalid. Still IMHO the best solution is to count the number of =E2=80=9Cdata = nodes=E2=80=9D. I will change the description. Also if the node can not a meaningful value it is free to omit the leaf. =20 - supported-excluded-change-type - this union has overlapping enumeration implied values suggest assigning value -2; and value -1; to none and all enums BALAZS: OOPS, will be corrected. =20 =20 Andy =20 =20 =20 On Tue, Jan 7, 2020 at 5:04 AM Kent Watsen > wrote: Dear WG, This is a fairly substantial update that defines a generic = "ietf-system-capabilities=E2=80=99 module and a separate "ietf-notification-capabilities=E2=80=9D module = that augments into it. We could start WGLC #2 now, but it would be good to get a few high-level = reactions from the WG before doing so. Please provide comments as to if you believe the draft is ready for WGLC = #2.. Thanks, Kent // as shepherd > On Jan 7, 2020, at 3:28 AM, internet-drafts@ietf.org = wrote: >=20 >=20 > A new version (-09) has been submitted for = draft-ietf-netconf-notification-capabilities: > = https://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-capa= bilities-09.txt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > = https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabili= ties/ >=20 > Diff from previous version: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-notification-capab= ilities-09 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the diff is available at tools.ietf.org = . >=20 > IETF Secretariat. >=20 _______________________________________________ netconf mailing list netconf@ietf.org =20 https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_001_0107_01D5C7B4.974C5320 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks for = the comments. See below. Balazs

 

From: = netconf <netconf-bounces@ietf.org> On Behalf Of Andy = Bierman
Sent: 2020. janu=C3=A1r 8., szerda 5:46
To: = Kent Watsen <kent+ietf@watsen.net>
Cc: NETCONF Working = Group <netconf@ietf.org>
Subject: Re: [netconf] New = Version Notification - = draft-ietf-netconf-notification-capabilities-09.txt

 

Hi,

 

I = think the new system capabilities module is good = enough.

The = node-instance-identifier type allows a key to be missing, which provides = some entry reuse.

 

My concerns are with the notification capabilities = module.

 

  - notification-support:  why is this an = enumeration instead of bits?

 

suggest:

 

     typedef notification-support = {

        type bits = {
          bit = notifications-for-config-changes-supported {
      =       description "The publisher is capable of = sending
              = notifications for config=3Dtrue nodes, but not
      =         for config=3Dfalse nodes for the relevant = scope
              and = subscription type." ;
          = }
          bit = notifications-for-state-changes-supported {
      =       description "The publisher is capable of = sending
              = notifications for config=3Dfalse nodes, but not
      =         for config=3Dtrue nodes for the relevant = scope
              and = subscription type." ;
          = }
        }

   - can the names be shorter = (config-changes, state-changes)?

    these names seem redundant and = verbose

 

BALAZS:=C2=A0 OK changed to = bits and shorter names

 

  - update-period

    this object seems = implementation-specific. 

    The description should be less normative = and use 2119 language

 

            A periodic = subscription to the selected data nodes must

            specify a = value that is at least as large or greater than
      =       this

 

      Suggest:  = s/must/SHOULD/

BALAZS: OK changed to SHOULD. This is a requirement = on the client so I though it is not an RFC2119 must or = should

 

  - = supported-update-period

    - this is very implementation-specific, = especially as a leaf-list instead of a

      leaf with a = range

    - also = has 'must' language that is inappropriate; = s/must/SHOULD/

BALAZS: OK changed to SHOULD. =

This is not implementation specific. E.g. the = standard=C2=A0 =C2=A03GPP TS 28.622 specifies that the system should = declare a set of specific values (Not intervals) that are = supported

 

 - = max-objects-per-update

   - extremely implementation-specific; Does = this assume a server generates updates

     by counting objects and stopping = when this value is reached?

   - the text is not clear if it means = objects or object instances? Do child nodes = count

    =  as instances? IMO this object should be removed or changes to max. = bytes per update

  =    (also implementation-specific)

BALAZS: RFC8641 = defines:

=C2=A0=C2=A0=C2=A0=C2=A0 identity update-too-big = {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = description

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "Periodic or on-change push update data trees exceed a = maximum

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = size limit.=C2=A0 Hints on the estimated size of what was too = big

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = may be returned as supplemental = information.";

=C2=A0=C2=A0=C2=A0=C2=A0 }

This is the related = capability. If you can get back a too-big error, then you should have a = capability declaring what TOO-big means.

Bytes are risky. If the = value of a string is updated from a single character to a 2 characters = the subscription might become invalid

as we have more bytes now. = Also it is impossible to calculate the number of bytes as it depends on = future instance data content.

You could say the same way = that if we count data nodes, if a leaf-list gets one more entries the = subscription could become invalid.

Still IMHO the best solution = is to count the number of =E2=80=9Cdata nodes=E2=80=9D. I will change = the description.

Also if the node can not a meaningful value it is = free to omit the leaf.

 

 - = supported-excluded-change-type

   - this union has overlapping enumeration = implied values

  =   suggest assigning value -2; and value -1; to none and all = enums

BALAZS: OOPS, will be = corrected.

 

 

Andy

 

 

 

On = Tue, Jan 7, 2020 at 5:04 AM Kent Watsen <kent+ietf@watsen.net> = wrote:


Dear = WG,

This is a fairly substantial update that defines a generic = "ietf-system-capabilities=E2=80=99
module and a separate = "ietf-notification-capabilities=E2=80=9D module that augments into = it.

We could start WGLC #2 now, but it would be good to get a few = high-level reactions
from the WG before doing so.

Please = provide comments as to if you believe the draft is ready for WGLC = #2..

Thanks,
Kent // as shepherd


> On Jan 7, = 2020, at 3:28 AM, internet-drafts@ietf.org wrote:
>
> =
> A new version (-09) has been submitted for = draft-ietf-netconf-notification-capabilities:
> https://www.ietf.org/internet-drafts/draft-ietf-netconf= -notification-capabilities-09.txt
>
>
> The IETF = datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-not= ification-capabilities/
>
> Diff from previous = version:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-= notification-capabilities-09
>
> Please note that it = may take a couple of minutes from the time of submission
> until = the diff is available at tools.ietf.org.
>
> IETF = Secretariat.
> =

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

------=_NextPart_001_0107_01D5C7B4.974C5320-- ------=_NextPart_000_0106_01D5C7B4.974C5320 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTIwMDExMDExNTA1MlowIwYJKoZIhvcNAQkEMRYEFMwDdbPQEaetfoBH8SGdNFbJ70dCMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQBrLzg/FRzeg0kL3IRjJajgTQQiNF9dP7Cy6EVGKo0CluPlXWBL/Aap ZmroCAm6EgnpcjVFoTQYEJFi62x1qWIQLWm8Tli5VAaPnHYlFsvs0LFh6UHUJF36fnNZUEb7wRLs J1bdT7TKt0zNVQU6VbtJMpxZaexMfeaEF7lyXaiRvW47mG4E1xigC9D/GOWp+BHO4X5cyX1FVQcO HPKeTgH75s9FKkfNWmMI1Zy89Jc+WnnAoR1ftdim5gN4KU/O5VARfviYYoYyX3tapOnDcjut5HG7 2QWKnVnpgX1fh+lMoDK8haNLz7ul9SZc+0dbsKh8vfYqmdAnTdj7+gN8GQa8AAAAAAAA ------=_NextPart_000_0106_01D5C7B4.974C5320-- From nobody Fri Jan 10 04:16: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 F301F12006F for ; Fri, 10 Jan 2020 04:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8ANxr-74wyw for ; Fri, 10 Jan 2020 04:16:17 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20603.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::603]) (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 AE3A612006E for ; Fri, 10 Jan 2020 04:16:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VlR5vRmO/iqrbGzJzcWUxCTfyytYjgMn24WgS8Qcr4PPeycTMNLt79FN1P1TLnH92rndkpFnF+RyrbwqEZCw9mAgWHBTXvCQoshz2idECxinr3NXMuaHlKdw2WGkfp1raNCqgP9Ro+BlkWGkyxTUt7gUHBcaNjunKg7UI1sLFadz21xNeNgUvsJfT1NQTiA4zOXomGRX5DhluMHLxzZAyqHMQ/yN7GOtBiNom+7zYQ4YSl2z5bMyy2sY00MDj145leKAa3FbamGGYYYGOAwL7r5q8W+EcmiM/qikC0Zs9faD9tUH1tVADor5zmYdfP9txPsOXU01CyF9b6IM6h9xEQ== 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=uO9J7jHYGirsLrFb7pmhfMFuT0ccOmkkeRamtfcLrsc=; b=mG0t0cKtr2IbYv+28dOwfgFpdn3dNTjf8fB9GvuqvJaf3A2z2/ikPDcQKlYWCWSRJ4zHsccriT9mOWfgQglDdVIF9NmUOULhjXf1N1CqA3m+BWC9PSOwLS1T9WLfbmNyN2KzI5E6ESnr8j3X/wkKHaoEjMSxGx8KQggBF4VLdlgietQgXKpJovuYNimykTpM3bLLgSXsXa2uBnfRcHT2ulPdIBVILCdFoTq4okPWI+XIkH2Vfxf2LR7sBtbnpI/turUR7ezAXPgzZCuWsYVIVkUnMatsf/phPasLqUOCYurV2IxiBSFsOZ9B/dqXovnPzN34jSAaqZMIMzhNsAXzPQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uO9J7jHYGirsLrFb7pmhfMFuT0ccOmkkeRamtfcLrsc=; b=VFucylmxJuuYPo4J0A363+xDDOfELFUjWVf5zjh72REnrlZYCxtOqc/aSpf3ECmmM9HAlPsyEDLfPaJHKqAd+/VO3WpwcPFO+gVPb72u2MtPxf1BmaERoDwM9Teo3KL8Lsn6kuqN9lqEZ3nIUNT8QU/i4gMk4UNBuJHptFfL+mk= Received: from VI1PR07MB4047.eurprd07.prod.outlook.com (52.134.20.154) by VI1PR07MB4751.eurprd07.prod.outlook.com (20.177.56.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.6; Fri, 10 Jan 2020 12:16:10 +0000 Received: from VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686]) by VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686%5]) with mapi id 15.20.2644.006; Fri, 10 Jan 2020 12:16:10 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman , Martin Bjorklund CC: Netconf Thread-Topic: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt Thread-Index: AQHVxVsUq6ljVkP3y0ecYCN5b7iLjKfgMloAgAJjm5qAAT2VMA== Date: Fri, 10 Jan 2020 12:16:09 +0000 Message-ID: References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <20200109.125407.1696793655072242187.mbjorklu@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 171539fa-3be7-4888-767b-08d795c6e0b0 x-ms-traffictypediagnostic: VI1PR07MB4751: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(39860400002)(366004)(346002)(376002)(199004)(189003)(52536014)(15650500001)(9686003)(76116006)(81156014)(81166006)(4326008)(5660300002)(66476007)(85182001)(33656002)(66556008)(66446008)(66616009)(55016002)(64756008)(2906002)(66946007)(316002)(8676002)(86362001)(966005)(66574012)(110136005)(478600001)(6506007)(85202003)(71200400001)(8936002)(7696005)(53546011)(186003)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4751; H:VI1PR07MB4047.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hyHz7ni9w3+ml/D4CruNpkWhmlcJZWTxmBpUbsCzckHbSK9ot8X6TRojnob6dASakLUJ8KqWe0NzRGGaokbeqtiqYvxsrhv/94gD7ieqGaAKV5Bc7okR8OVruMHMLMLsdj5EilwKGFrNdCagZx8XazJ6MzNAN/94nSegGJusHd/sJPfBPGslc6bBvrDR3K4b1gIDFwev3DgJWpR7JoXAT/6AbhDGCQEGaRnNH8/Gjg9hhDEVaO3GwSjLJMlaYD/vZ9ywdFazVWPCCP6pzWAzIoxByTeoPfdytXO98y80YzryskbpTlbFHtBOOk5gTXrh3D44m7xb/IZleFKDdgj8csViMbiDxmYNYjM1IPfq7sqgmvqwvpfHXwu7msHWaTp8i7KXV36KYQBMmK8/OyJ/RHby00u9oFAeupoXu3idNNFCZlbqyu8IOdRea+1tQYiGBzvSz25FjjBThsiNoO/dXJxDVNVfBtLw/AjCxOrCVXo= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_011E_01D5C7B8.1F02E150" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 171539fa-3be7-4888-767b-08d795c6e0b0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2020 12:16:10.0159 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Koq+XBF/ocy3YfRfJam55Hhbzg6f+tN+j7xnRexi6dzlpDwJ77wHP84QcO4IXSvd2F7lR2ePf2dgpAyPVrIOUihcCFgdln+ARUKGgqOS0ys= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4751 Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 12:16:20 -0000 ------=_NextPart_000_011E_01D5C7B8.1F02E150 Content-Type: multipart/alternative; boundary="----=_NextPart_001_011F_01D5C7B8.1F02E150" ------=_NextPart_001_011F_01D5C7B8.1F02E150 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable See BALAZS2 below. =20 From: netconf On Behalf Of Andy Bierman Sent: 2020. janu=C3=A1r 9., cs=C3=BCt=C3=B6rt=C3=B6k 18:15 To: Martin Bjorklund Cc: Netconf Subject: Re: [netconf] New Version Notification - = draft-ietf-netconf-notification-capabilities-09.txt =20 =20 =20 On Thu, Jan 9, 2020 at 3:54 AM Martin Bjorklund > wrote: Andy Bierman > wrote: > Hi, >=20 > I think the new system capabilities module is good enough. > The node-instance-identifier type allows a key to be missing, which > provides some entry reuse. >=20 > My concerns are with the notification capabilities module. >=20 > - notification-support: why is this an enumeration instead of bits? >=20 > suggest: >=20 > typedef notification-support { > type bits { > bit notifications-for-config-changes-supported { > description "The publisher is capable of sending > notifications for config=3Dtrue nodes, but not > for config=3Dfalse nodes for the relevant scope > and subscription type." ; > } > bit notifications-for-state-changes-supported { > description "The publisher is capable of sending > notifications for config=3Dfalse nodes, but not > for config=3Dtrue nodes for the relevant scope > and subscription type." ; > } > } >=20 > - can the names be shorter (config-changes, state-changes)? > these names seem redundant and verbose +1 for bits and the suggested shorter names > - update-period > this object seems implementation-specific. > The description should be less normative and use 2119 language >=20 > A periodic subscription to the selected data nodes must > specify a value that is at least as large or greater than > this >=20 > Suggest: s/must/SHOULD/ I don't think either is correct. This leaf informs the client what an acceptable 'period' value is. A client that sends a shorter period will get a 'period-unsupported' error back, as defined in RFC 8641. Perhaps rephrase the sentence to: A request for a periodic subscription to the selected data nodes with a smaller period than what this leaf specifies will result in a 'period-unsupported' error. =20 I agree this is better. BALAZS2: OK =20 =20 > - supported-update-period > - this is very implementation-specific, especially as a leaf-list > instead of a > leaf with a range > - also has 'must' language that is inappropriate; s/must/SHOULD/ See above. > - max-objects-per-update > - extremely implementation-specific; Does this assume a server = generates > updates > by counting objects and stopping when this value is reached? > - the text is not clear if it means objects or object instances? Do > child nodes count > as instances? IMO this object should be removed or changes to = max. > bytes per update > (also implementation-specific) I agree that this is implementation-specific, and a byte-count as well. It assumes that the implementation uses very static datastructures. But I think it can be ok - an implementation that doesn't have such static limits will not instantiate this leaf. =20 Then there should be text in the description-stmt that this leaf will = not be instantiated if the server implementation does not restrict an update to a specific number of objects. BALAZS2: We have the following text in the sys-cap module description. I = hope that is OK: =E2=80=9CIf no entries are found in the previous steps the publisher is not capable of providing a value because it is unknown, the capability is changing for some reason, there is no specified limit etc. In this case the system's behavior is unspecified. =E2=80=9C This is actually a general issue, that sometimes it is not possible to = provide a meaningful value for a capability. =20 What about the supported-update-period leaf-list? If a server allows any centi-second value from 1 sec to 1 hour then this = will be a leaf-list with 5900 instances in it.. Since there is no reason to = limit the upper-bound (e.g., client wants 1 statistics update per day) this leaf-list will = likely have millions of instances in it. =20 IMO this leaf-list should be removed. The minimum-update-period is = sufficient. =20 BALAZS2: There are implementations and standards that use specific = values not ranges. =20 =20 /martin =20 =20 Andy =20 > - supported-excluded-change-type > - this union has overlapping enumeration implied values > suggest assigning value -2; and value -1; to none and all enums >=20 >=20 > Andy >=20 >=20 >=20 > On Tue, Jan 7, 2020 at 5:04 AM Kent Watsen > wrote: >=20 > > > > Dear WG, > > > > This is a fairly substantial update that defines a generic > > "ietf-system-capabilities=E2=80=99 > > module and a separate "ietf-notification-capabilities=E2=80=9D = module that > > augments into it. > > > > We could start WGLC #2 now, but it would be good to get a few = high-level > > reactions > > from the WG before doing so. > > > > Please provide comments as to if you believe the draft is ready for = WGLC > > #2. > > > > Thanks, > > Kent // as shepherd > > > > > > > On Jan 7, 2020, at 3:28 AM, internet-drafts@ietf.org = wrote: > > > > > > > > > A new version (-09) has been submitted for > > draft-ietf-netconf-notification-capabilities: > > > > > = https://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-capa= bilities-09.txt > > > > > > > > > The IETF datatracker page for this Internet-Draft is: > > > > > = https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabili= ties/ > > > > > > Diff from previous version: > > > > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-notification-capab= ilities-09 > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > > until the diff is available at tools.ietf.org = . > > > > > > IETF Secretariat. > > > > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org =20 > > https://www.ietf.org/mailman/listinfo/netconf > > ------=_NextPart_001_011F_01D5C7B8.1F02E150 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

See BALAZS2 below.

 

From: netconf <netconf-bounces@ietf.org> = On Behalf Of Andy Bierman
Sent: 2020. janu=C3=A1r 9., = cs=C3=BCt=C3=B6rt=C3=B6k 18:15
To: Martin Bjorklund = <mbjorklu@cisco.com>
Cc: Netconf = <netconf@ietf.org>
Subject: Re: [netconf] New Version = Notification - = draft-ietf-netconf-notification-capabilities-09.txt

 

 

 

On = Thu, Jan 9, 2020 at 3:54 AM Martin Bjorklund <mbjorklu@cisco.com> = wrote:

Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
> =
> I think the new system capabilities module is good = enough.
> The node-instance-identifier type allows a key to be = missing, which
> provides some entry reuse.
>
> My = concerns are with the notification capabilities module.
> =
>   - notification-support:  why is this an = enumeration instead of bits?
>
> suggest:
> =
>      typedef notification-support = {
>         type bits {
>  =          bit = notifications-for-config-changes-supported {
>      =        description "The publisher is capable of = sending
>              =  notifications for config=3Dtrue nodes, but not
>  =              for config=3Dfalse nodes = for the relevant scope
>            =    and subscription type." ;
>      =      }
>          =  bit notifications-for-state-changes-supported {
>  =            description "The publisher = is capable of sending
>            =    notifications for config=3Dfalse nodes, but = not
>               for = config=3Dtrue nodes for the relevant scope
>      =          and subscription type." = ;
>           }
>    =      }
>
>    - can the names be = shorter (config-changes, state-changes)?
>    =  these names seem redundant and verbose

+1 for bits and the = suggested shorter names



>   - = update-period
>     this object seems = implementation-specific.
>     The description = should be less normative and use 2119 language
>
>  =            A periodic subscription to the = selected data nodes must
>          =    specify a value that is at least as large or greater = than
>             this
> =
>       Suggest:  = s/must/SHOULD/

I don't think either is correct.  This leaf = informs the client what an
acceptable 'period' value is.  A = client that sends a shorter period
will get a 'period-unsupported' = error back, as defined in RFC 8641.
Perhaps rephrase the sentence = to:

  A request for a periodic subscription to the selected = data nodes
  with a smaller period than what this leaf specifies = will result in
  a 'period-unsupported' = error.

 

I = agree this is better.

BALAZS2: OK

 

 

>   - = supported-update-period
>     - this is very = implementation-specific, especially as a leaf-list
> instead of = a
>       leaf with a range
>  =    - also has 'must' language that is inappropriate; = s/must/SHOULD/

See above.

>  - = max-objects-per-update
>    - extremely = implementation-specific; Does this assume a server generates
> = updates
>      by counting objects and stopping = when this value is reached?
>    - the text is not clear = if it means objects or object instances? Do
> child nodes = count
>      as instances? IMO this object should = be removed or changes to max.
> bytes per update
>  =     (also implementation-specific)

I agree that this is = implementation-specific, and a byte-count as
well.  It assumes = that the implementation uses very static
datastructures.  =  But I think it can be ok - an implementation that
doesn't have = such static limits will not instantiate this = leaf.

 

Then there should be text in the description-stmt that = this leaf will not

be = instantiated if the server implementation does not restrict an = update

to a specific = number of objects.

BALAZS2: We have the following text in the sys-cap = module description. I hope that is OK:

=E2=80=9CIf no entries are = found in the previous steps the

=C2=A0=C2=A0=C2=A0=C2=A0 = publisher is not capable of providing a value = because

=C2=A0=C2=A0=C2=A0=C2=A0 it is unknown, the = capability is changing for some reason,

=C2=A0=C2=A0=C2=A0=C2=A0 = there is no specified limit etc. In this case = the

=C2=A0=C2=A0=C2=A0=C2=A0 system's behavior is = unspecified. =E2=80=9C

This is actually a general issue, that sometimes it = is not possible to provide a meaningful value for a = capability.

 

What about the supported-update-period = leaf-list?

If a server = allows any centi-second value from 1 sec to 1 hour then this = will

be a leaf-list with = 5900 instances in it..  Since there is no reason to limit the = upper-bound

(e.g., client = wants 1 statistics update per day) this leaf-list will likely have = millions

of instances in = it.

 

IMO this leaf-list should be removed. The = minimum-update-period is sufficient.

 

BALAZS2: There are implementations and standards = that use specific values not ranges.

 

 


/martin

 

 

Andy

 




>  - = supported-excluded-change-type
>    - this union has = overlapping enumeration implied values
>    =  suggest assigning value -2; and value -1; to none and all = enums
>
>
> Andy
>
>
>
> = On Tue, Jan 7, 2020 at 5:04 AM Kent Watsen <kent+ietf@watsen.net> wrote:
>
> = >
> > Dear WG,
> >
> > This is a fairly = substantial update that defines a generic
> > = "ietf-system-capabilities=E2=80=99
> > module and a = separate "ietf-notification-capabilities=E2=80=9D module = that
> > augments into it.
> >
> > We could = start WGLC #2 now, but it would be good to get a few high-level
> = > reactions
> > from the WG before doing so.
> = >
> > Please provide comments as to if you believe the draft = is ready for WGLC
> > #2.
> >
> > = Thanks,
> > Kent // as shepherd
> >
> = >
> > > On Jan 7, 2020, at 3:28 AM, internet-drafts@ietf.org wrote:
> > = >
> > >
> > > A new version (-09) has been = submitted for
> > = draft-ietf-netconf-notification-capabilities:
> > >
> = > https://www.ietf.org/internet-drafts/draft-ietf-netconf= -notification-capabilities-09.txt
> > >
> > = >
> > > The IETF datatracker page for this Internet-Draft = is:
> > >
> > https://datatracker.ietf.org/doc/draft-ietf-netconf-not= ification-capabilities/
> > >
> > > Diff = from previous version:
> > >
> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-= notification-capabilities-09
> > >
> > > = Please note that it may take a couple of minutes from the time = of
> > submission
> > > until the diff is available = at tools.ietf.org.
> > >
> > = > IETF Secretariat.
> > >
> >
> > = _______________________________________________
> > netconf = mailing list
> > netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
&g= t; >

------=_NextPart_001_011F_01D5C7B8.1F02E150-- ------=_NextPart_000_011E_01D5C7B8.1F02E150 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTIwMDExMDEyMTYwOFowIwYJKoZIhvcNAQkEMRYEFDb8AJ7ivAr0NoX1YgHIOT5LbAxaMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQDQ/c40rbTtUq54nk6DkxpuQfBdhm9gtqlUx2Irh5dVUxSc1T0tXwm6 kbZdgjieKjnqYdDp4aIDKJ6PQTTHkWfs8QzxM6XZA8PNSKNLaa2M5812enamkV17DfgKb0LG9Wfc W1YypARuGSI/N+o8mgIIr+t4a733VEnZNI6OYCJCmFvsJjnssP27hynyBgB6mJRSJkFax8sHczFk lZEJUzuCXdZTKS1WCcrBGk0pR6M72Z1KMIb/Qn5MtjIe6oNACCaB+fCpmvJyQr9kSXUTAcOKO9kS 3iOHNT5GneBItxL5MgHhgQLJCrA+5PiXhFMD9OQtx63ZRqnX/OEC7FwoAmYYAAAAAAAA ------=_NextPart_000_011E_01D5C7B8.1F02E150-- From nobody Fri Jan 10 07:35:09 2020 Return-Path: <0100016f901833d0-c822306b-9f2f-4c7b-9444-34742ec35a53-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 0663A12006B for ; Fri, 10 Jan 2020 07:35:07 -0800 (PST) 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_DNSWL_NONE=-0.0001, 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 D0lDpl0tlgEP for ; Fri, 10 Jan 2020 07:35:05 -0800 (PST) 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 62020120026 for ; Fri, 10 Jan 2020 07:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1578670503; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=DYrKLHekXakkEAZpG319C8czshPQqeY44vq6eDjaEjw=; b=EVm9riOa86jOh0MvdFAF+sXewmrMImxFlH/Vox5I+rFxs7ksrf3IHoxq4cwHdkcd xzUIqFVHXMLm++sOBB2MeCimGdhDthqPrS5d4OGOof9F+fRXx09b/oFPEK0scrgA0eF Ub7++3q41SbAwHST/QBZnrDHMeU8pHR6WScY3CxY= From: Kent Watsen Message-ID: <0100016f901833d0-c822306b-9f2f-4c7b-9444-34742ec35a53-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_575CA07D-D59B-4C75-B753-D112399BF516" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 10 Jan 2020 15:35:03 +0000 In-Reply-To: Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <0100016f83226d35-4c825571-7fe8-4074-8f6c-d9994e2ed37a-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.01.10-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 15:35:07 -0000 --Apple-Mail=_575CA07D-D59B-4C75-B753-D112399BF516 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Balazs, > Would the following be acceptable? > OLD: > list per-node-capabilities { > key "node-selector"; > leaf node-selector { > type nacm:node-instance-identifier; > NEW: > list per-node-capabilities { > choice node-selector { > leaf node-selector { type = nacm:node-instance-identifier; } > } >=20 > Later you can augment in an Xpath filter or a string with '*' and '?' = wildcards or whatever you want. > (The list does not need a key as it is config=3Dfalse) Yes, this is inline with what I had in mind but, since this was my = suggestion, I was hoping that Rob or others would reply. Kent // contributor --Apple-Mail=_575CA07D-D59B-4C75-B753-D112399BF516 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Balazs,

Would the following be = acceptable?
OLD:
     list = per-node-capabilities {
=        key "node-selector";
       leaf node-selector = {
=          type = nacm:node-instance-identifier;
NEW:
=      list per-node-capabilities {
=        choice node-selector {
       leaf = node-selector {   type nacm:node-instance-identifier; =  }
     }

Later you can augment in an Xpath filter or a string with '*' = and '?' wildcards or whatever you want.
(The list does not = need a key as it is config=3Dfalse)


Yes, this is inline with = what I had in mind but, since this was my suggestion, I was hoping that = Rob or others would reply.

Kent // = contributor


= --Apple-Mail=_575CA07D-D59B-4C75-B753-D112399BF516-- From nobody Fri Jan 10 07:48: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 2CF6712006B for ; Fri, 10 Jan 2020 07:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 kEEI6yi8gyMK for ; Fri, 10 Jan 2020 07:47:53 -0800 (PST) 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 489B6120048 for ; Fri, 10 Jan 2020 07:47:53 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id y6so2643132lji.0 for ; Fri, 10 Jan 2020 07:47:53 -0800 (PST) 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=kxa0+24gsQA4/PXBxyQg22Zvs5B4x9D7sQ8ALN3CQTc=; b=nvh/kteNydPpABamGD3WY0E00GLreiLMN47DxpM0mlhB0cioAndDkHP6jZqlGT4GD/ z8WHN39SROk9EXhw2VVSKa2D9H1bJM1QkZJa2ffrZRc30E2cFCftJciAtYAY78MqS3SX I1N3TTXsxfqToti8RT1QlA49lWmaQuQMs2jxXR01B1p2lTtl5Z0Y59cL6oBWQHtv0yhZ DTm9q85wvuZ0JEfAchz34wWEZQXGTqZrAOjNcoX8bFQpO7PHNOKwya2yGYlZ5XkBdDPM +bDgh755iguJqvWazwFPQYJ6XDX4hfB0quuzGHj+LKhJgTrGh9+B+52p2yAfJj/Q2yXL k2JA== 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=kxa0+24gsQA4/PXBxyQg22Zvs5B4x9D7sQ8ALN3CQTc=; b=GQzZxdc7oK5X8NQXewrTqh6EQyGEYIy9jTM3VJz1AplJEHZ9C/SeBnh5OgyDivrWQ0 gMwacGJeQ70LYdZv2fqO+OLj+I5jJ/RhQKN9fJg5VQOvIzq73RYvgweY+FzpUFFXLDK+ JRiE6qxRs2R6BSgRPSLt1DIUEcNXO8Ls2EVi0p6CijoWaKiGoA0flyMJ4pdVs3VDFoGt E2V89A3WK2ROFomCcsfX1GyCaTw1D2HwSCr9QyoqdqJB1OiOqn7moxRJyBSJ0GqDz+4X xCMhBSvteWkBjznA1lDlE4vkSjjHWJUjgiRv+rfCijJpvNJqbNwLGj9qWGZPYc/PDsSq N5xw== X-Gm-Message-State: APjAAAXE6fJsGZu9PbnnFjdfxAuvM7uFwCcgZNdhfU/54CU55Fe8Qoea 992kX62VrKAs3mHQflZxU4K6gn8GeWqnSbfoe1hTKA== X-Google-Smtp-Source: APXvYqytxDSuwDpEI25O55yO5n7FXmmvrSjz8YKOqCh+/Y7uHbwQcDAsuTYS+SF9OmWEr+/HhA0qKZ+wI63EVQBo1Fw= X-Received: by 2002:a2e:9596:: with SMTP id w22mr2981341ljh.21.1578671271392; Fri, 10 Jan 2020 07:47:51 -0800 (PST) MIME-Version: 1.0 References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <20200109.125407.1696793655072242187.mbjorklu@cisco.com> In-Reply-To: From: Andy Bierman Date: Fri, 10 Jan 2020 07:47:40 -0800 Message-ID: To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= Cc: Martin Bjorklund , Netconf Content-Type: multipart/alternative; boundary="0000000000005949fb059bcb0c05" Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 15:47:58 -0000 --0000000000005949fb059bcb0c05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 10, 2020 at 4:16 AM Bal=C3=A1zs Lengyel wrote: > *See BALAZS2 below.* > > > > *From:* netconf *On Behalf Of *Andy Bierman > *Sent:* 2020. janu=C3=A1r 9., cs=C3=BCt=C3=B6rt=C3=B6k 18:15 > *To:* Martin Bjorklund > *Cc:* Netconf > *Subject:* Re: [netconf] New Version Notification - > draft-ietf-netconf-notification-capabilities-09.txt > > > > > > > > On Thu, Jan 9, 2020 at 3:54 AM Martin Bjorklund > wrote: > > Andy Bierman wrote: > > Hi, > > > > I think the new system capabilities module is good enough. > > The node-instance-identifier type allows a key to be missing, which > > provides some entry reuse. > > > > My concerns are with the notification capabilities module. > > > > - notification-support: why is this an enumeration instead of bits? > > > > suggest: > > > > typedef notification-support { > > type bits { > > bit notifications-for-config-changes-supported { > > description "The publisher is capable of sending > > notifications for config=3Dtrue nodes, but not > > for config=3Dfalse nodes for the relevant scope > > and subscription type." ; > > } > > bit notifications-for-state-changes-supported { > > description "The publisher is capable of sending > > notifications for config=3Dfalse nodes, but not > > for config=3Dtrue nodes for the relevant scope > > and subscription type." ; > > } > > } > > > > - can the names be shorter (config-changes, state-changes)? > > these names seem redundant and verbose > > +1 for bits and the suggested shorter names > > > > > - update-period > > this object seems implementation-specific. > > The description should be less normative and use 2119 language > > > > A periodic subscription to the selected data nodes must > > specify a value that is at least as large or greater than > > this > > > > Suggest: s/must/SHOULD/ > > I don't think either is correct. This leaf informs the client what an > acceptable 'period' value is. A client that sends a shorter period > will get a 'period-unsupported' error back, as defined in RFC 8641. > Perhaps rephrase the sentence to: > > A request for a periodic subscription to the selected data nodes > with a smaller period than what this leaf specifies will result in > a 'period-unsupported' error. > > > > I agree this is better. > > BALAZS2: OK > > > > > > > - supported-update-period > > - this is very implementation-specific, especially as a leaf-list > > instead of a > > leaf with a range > > - also has 'must' language that is inappropriate; s/must/SHOULD/ > > See above. > > > - max-objects-per-update > > - extremely implementation-specific; Does this assume a server > generates > > updates > > by counting objects and stopping when this value is reached? > > - the text is not clear if it means objects or object instances? Do > > child nodes count > > as instances? IMO this object should be removed or changes to max. > > bytes per update > > (also implementation-specific) > > I agree that this is implementation-specific, and a byte-count as > well. It assumes that the implementation uses very static > datastructures. But I think it can be ok - an implementation that > doesn't have such static limits will not instantiate this leaf. > > > > Then there should be text in the description-stmt that this leaf will not > > be instantiated if the server implementation does not restrict an update > > to a specific number of objects. > > BALAZS2: We have the following text in the sys-cap module description. I > hope that is OK: > > =E2=80=9CIf no entries are found in the previous steps the > > publisher is not capable of providing a value because > > it is unknown, the capability is changing for some reason, > > there is no specified limit etc. In this case the > > system's behavior is unspecified. =E2=80=9C > > This is actually a general issue, that sometimes it is not possible to > provide a meaningful value for a capability. > > > > What about the supported-update-period leaf-list? > > If a server allows any centi-second value from 1 sec to 1 hour then this > will > > be a leaf-list with 5900 instances in it.. Since there is no reason to > limit the upper-bound > > (e.g., client wants 1 statistics update per day) this leaf-list will > likely have millions > > of instances in it. > > > > IMO this leaf-list should be removed. The minimum-update-period is > sufficient. > > > > BALAZS2: There are implementations and standards that use specific values > not ranges. > > > The YANG-Push standard simply specifies "centiseconds" as the type. There is no mention in RFC 8641 of anything related to supporting a subset of this data type. The YANG syntax for "centiseconds" allows for 4 billion distinct values: typedef centiseconds { type uint32; description "A period of time, measured in units of 0.01 seconds."; } IMO this object could be added via augment by a vendor or other SDO. It has no relevance to the YANG-Push standard. > > > /martin > > Andy > > > > > Andy > > > > > > > > - supported-excluded-change-type > > - this union has overlapping enumeration implied values > > suggest assigning value -2; and value -1; to none and all enums > > > > > > Andy > > > > > > > > On Tue, Jan 7, 2020 at 5:04 AM Kent Watsen wrote= : > > > > > > > > Dear WG, > > > > > > This is a fairly substantial update that defines a generic > > > "ietf-system-capabilities=E2=80=99 > > > module and a separate "ietf-notification-capabilities=E2=80=9D module= that > > > augments into it. > > > > > > We could start WGLC #2 now, but it would be good to get a few > high-level > > > reactions > > > from the WG before doing so. > > > > > > Please provide comments as to if you believe the draft is ready for > WGLC > > > #2. > > > > > > Thanks, > > > Kent // as shepherd > > > > > > > > > > On Jan 7, 2020, at 3:28 AM, internet-drafts@ietf.org wrote: > > > > > > > > > > > > A new version (-09) has been submitted for > > > draft-ietf-netconf-notification-capabilities: > > > > > > > > https://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-capa= bilities-09.txt > > > > > > > > > > > > The IETF datatracker page for this Internet-Draft is: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabili= ties/ > > > > > > > > Diff from previous version: > > > > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-notification-capab= ilities-09 > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission > > > > until the diff is available at tools.ietf.org. > > > > > > > > IETF Secretariat. > > > > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > --0000000000005949fb059bcb0c05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 10, 2020 at 4:16 AM Bal= =C3=A1zs Lengyel <balazs.= lengyel@ericsson.com> wrote:

See= BALAZS2 below.

=C2=A0

From: netconf <netconf-bounces@i= etf.org> On Behalf Of Andy Bierman
Sent: 2020. janu= =C3=A1r 9., cs=C3=BCt=C3=B6rt=C3=B6k 18:15
To: Martin Bjorklund &= lt;mbjorklu@cisco.c= om>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [netconf] N= ew Version Notification - draft-ietf-netconf-notification-capabilities-09.t= xt

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 9, = 2020 at 3:54 AM Martin Bjorklund <mbjorklu@cisco.com> wrote:

=

= Andy Bierman <an= dy@yumaworks.com> wrote:
> Hi,
>
> I think the ne= w system capabilities module is good enough.
> The node-instance-iden= tifier type allows a key to be missing, which
> provides some entry r= euse.
>
> My concerns are with the notification capabilities m= odule.
>
>=C2=A0 =C2=A0- notification-support:=C2=A0 why is th= is an enumeration instead of bits?
>
> suggest:
>
&g= t;=C2=A0 =C2=A0 =C2=A0 typedef notification-support {
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0type bits {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0bit notifications-for-config-changes-supported {
>=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description "The publisher is capab= le of sending
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0notifications for config=3Dtrue nodes, but not
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for config=3Dfalse nodes for the rele= vant scope
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an= d subscription type." ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit notifications-for-= state-changes-supported {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0description "The publisher is capable of sending
>=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notifications for config=3D= false nodes, but not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0for config=3Dtrue nodes for the relevant scope
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and subscription type." ;=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0 - can the names be shorter= (config-changes, state-changes)?
>=C2=A0 =C2=A0 =C2=A0these names se= em redundant and verbose

+1 for bits and the suggested shorter names=



>=C2=A0 =C2=A0- update-period
>=C2=A0 =C2=A0 =C2= =A0this object seems implementation-specific.
>=C2=A0 =C2=A0 =C2=A0Th= e description should be less normative and use 2119 language
>
&g= t;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A periodic subscription t= o the selected data nodes must
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0specify a value that is at least as large or greater than
&= gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this
>
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0Suggest:=C2=A0 s/must/SHOULD/

I don't th= ink either is correct.=C2=A0 This leaf informs the client what an
accept= able 'period' value is.=C2=A0 A client that sends a shorter period<= br>will get a 'period-unsupported' error back, as defined in RFC 86= 41.
Perhaps rephrase the sentence to:

=C2=A0 A request for a peri= odic subscription to the selected data nodes
=C2=A0 with a smaller perio= d than what this leaf specifies will result in
=C2=A0 a 'period-unsu= pported' error.

=C2=A0

I agre= e this is better.

BALAZS2: OK

=C2=A0

=C2=A0=

>=C2=A0 =C2=A0- supported-update-period
>=C2=A0 = =C2=A0 =C2=A0- this is very implementation-specific, especially as a leaf-l= ist
> instead of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf with a rang= e
>=C2=A0 =C2=A0 =C2=A0- also has 'must' language that is ina= ppropriate; s/must/SHOULD/

See above.

>=C2=A0 - max-object= s-per-update
>=C2=A0 =C2=A0 - extremely implementation-specific; Does= this assume a server generates
> updates
>=C2=A0 =C2=A0 =C2=A0= by counting objects and stopping when this value is reached?
>=C2=A0= =C2=A0 - the text is not clear if it means objects or object instances? Do=
> child nodes count
>=C2=A0 =C2=A0 =C2=A0 as instances? IMO th= is object should be removed or changes to max.
> bytes per update
= >=C2=A0 =C2=A0 =C2=A0 (also implementation-specific)

I agree that= this is implementation-specific, and a byte-count as
well.=C2=A0 It ass= umes that the implementation uses very static
datastructures.=C2=A0 =C2= =A0But I think it can be ok - an implementation that
doesn't have su= ch static limits will not instantiate this leaf.

=C2=A0

Then there should be text in the description-stmt that this = leaf will not

be instant= iated if the server implementation does not restrict an update

to a specific number of objects.<= /u>

BALAZS2: We = have the following text in the sys-cap module description. I hope that is O= K:

=E2=80=9CIf no entries are found in the previous steps the

=C2=A0=C2=A0=C2= =A0=C2=A0 publisher is not capable of providing a value because

=C2=A0=C2=A0= =C2=A0=C2=A0 it is unknown, the capability is changing for some reason,<= /u>

=C2= =A0=C2=A0=C2=A0=C2=A0 there is no specified limit etc. In this case the<= /u>

=C2= =A0=C2=A0=C2=A0=C2=A0 system's behavior is unspecified. =E2=80=9C

This is= actually a general issue, that sometimes it is not possible to provide a m= eaningful value for a capability.

=C2=A0

= What about the supported-update-period leaf-list?

If a server allows any centi-second value from 1 = sec to 1 hour then this will

be a leaf-list with 5900 instances in it..=C2=A0 Since there is no rea= son to limit the upper-bound

(e.g., client wants 1 statistics update per day) this leaf-list will l= ikely have millions

of i= nstances in it.

= =C2=A0

IMO this leaf-list shoul= d be removed. The minimum-update-period is sufficient.

=C2=A0

BALAZS2: There are implementations and standards that use= specific values not ranges.

=C2=A0



The YANG-Push standard simply specifies &qu= ot;centiseconds" as the type.
There is no mention in RFC 864= 1 of anything related to supporting a subset of this data type.
T= he YANG syntax for "centiseconds" allows for 4 billion distinct v= alues:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 typedef centiseconds= {
       t=
ype uint32;
       description
         "A period of time, measured in units of 0.01 seconds.";
     }

<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;break-before:page;color:rgb(0,0,0)">
IMO this object could be added via au=
gment by a vendor or other SDO.
It has no relevance to the YANG-Push standard.


=

=C2=A0


/martin



Andy

<= div>=C2=A0

=C2=A0

=C2=A0

An= dy

=C2=A0<= /p>




>=C2=A0 - suppor= ted-excluded-change-type
>=C2=A0 =C2=A0 - this union has overlapping = enumeration implied values
>=C2=A0 =C2=A0 =C2=A0suggest assigning val= ue -2; and value -1; to none and all enums
>
>
> Andy>
>
>
> On Tue, Jan 7, 2020 at 5:04 AM Kent Watse= n <kent+ietf= @watsen.net> wrote:
>
> >
> > Dear WG,
&= gt; >
> > This is a fairly substantial update that defines a ge= neric
> > "ietf-system-capabilities=E2=80=99
> > mod= ule and a separate "ietf-notification-capabilities=E2=80=9D module tha= t
> > augments into it.
> >
> > We could start W= GLC #2 now, but it would be good to get a few high-level
> > react= ions
> > from the WG before doing so.
> >
> > Pl= ease provide comments as to if you believe the draft is ready for WGLC
&= gt; > #2.
> >
> > Thanks,
> > Kent // as shep= herd
> >
> >
> > > On Jan 7, 2020, at 3:28 AM= , internet-dr= afts@ietf.org wrote:
> > >
> > >
> > &= gt; A new version (-09) has been submitted for
> > draft-ietf-netc= onf-notification-capabilities:
> > >
> > https://www.ietf.org/internet-drafts/draft-i= etf-netconf-notification-capabilities-09.txt
> > >
> = > >
> > > The IETF datatracker page for this Internet-Dra= ft is:
> > >
> > htt= ps://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/=
> > >
> > > Diff from previous version:
>= ; > >
> > https://www= .ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-notification-capabilities-09
> > >
> > > Please note that it may take a couple= of minutes from the time of
> > submission
> > > unti= l the diff is available at tools.ietf.org.
> > >
> > > IETF Secretaria= t.
> > >
> >
> > ____________________________= ___________________
> > netconf mailing list
> > netconf@ietf.org
>= > https://www.ietf.org/mailman/listinfo/netconf
> >

--0000000000005949fb059bcb0c05-- From nobody Fri Jan 10 08:07: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 E3665120958 for ; Fri, 10 Jan 2020 08:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPRD6rnbQllE for ; Fri, 10 Jan 2020 08:07:11 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2073.outbound.protection.outlook.com [40.107.22.73]) (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 DE72312094C for ; Fri, 10 Jan 2020 08:07:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cgfud5zVJEHg0BqvAnZWUgPQy1Bi4cugRvkKU6aZQXERmMvCfbZZd7aiGznO1pzUXffXXvbHY0QtS/sJKA0RyXXG5em2ViYKxYG6xVLlMiSpXc5JgHqTmW1V2PLzsBkEUEXBVdWZqfu0kpxa6uFzAp+L4EWaVbdiYM6DphDAwM+cZ0w8vJ7lia5U8JRLgGd5+HcelAouLjRzsMvh4Y1q2HF92KRbsWWJLmZnXNqmJ3KKX7UfgezjHL2O4t+EDoFMeL1VLn6DRVViMyHhVry0wHmGvU9o7KSkbO+jaOn4xwKABR5UA6ZWo6ez2v6cfTd/cV28PZuKAU2XS8X+6jNs0g== 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=i0kY+N3e9K/2yDgo6rKhuf6vHzqi1+glsZKqKAZu9bc=; b=dGGVGkpwmwTEFBvZvyvVmH+gluqXNE5PDh3Kj6/qNnMYP2cfh/jACtALXpn1iu9x38Dg+x5qiZ5qcvPwWZ2M9CXJyK3YXEqYNUyTeyeQ/SN6q19BqVI65ZzX4AIn/il1Q1Or+5LTwQRvB6z6lLqw/h4n5xpTSGdzPSpeQNaTsJv9rhMUief+dbFBoFo7YnlRAzyXAmx7xVquKFsp6K/Jw0PDhEM6itATb/eEC9Kx7YZhrIvZpNz/j4JQcRwLjPNJl3qZtDfWwT4s9cJZm2xCcI+Q++qwvwRjFygTHbLIJeJiTUnEU//mKp3Vx/kdghHO7FlLFvf4l3ssjiU07JeLpQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i0kY+N3e9K/2yDgo6rKhuf6vHzqi1+glsZKqKAZu9bc=; b=u0KO0vEvxfCVWFJy/tQiNvhomV1SHGZGxEZEHNss+htRTNEYE5wUTuIsvDUZF6dM1Law5VBvKoScgz2Yh2LaB4FPpoFcNUnpcU/vjxDW7jw8hKNgfxyF1veJVfDhpKZk1LB81LOkMWkLpcYAIbRfm2alU3dqJUc6EBg0slMsmkw= Received: from VI1PR07MB4047.eurprd07.prod.outlook.com (52.134.20.154) by VI1PR07MB5391.eurprd07.prod.outlook.com (20.178.80.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.10; Fri, 10 Jan 2020 16:07:08 +0000 Received: from VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686]) by VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686%5]) with mapi id 15.20.2644.006; Fri, 10 Jan 2020 16:07:08 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman CC: Martin Bjorklund , Netconf Thread-Topic: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt Thread-Index: AQHVxVsUq6ljVkP3y0ecYCN5b7iLjKfgMloAgAJjm5qAAT2VMIAAPFMAgAACCYA= Date: Fri, 10 Jan 2020 16:07:08 +0000 Message-ID: References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <20200109.125407.1696793655072242187.mbjorklu@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 88ad8859-f659-4d53-5c19-08d795e724be x-ms-traffictypediagnostic: VI1PR07MB5391: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2512; x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(366004)(346002)(39860400002)(199004)(189003)(6916009)(8676002)(81156014)(81166006)(15650500001)(316002)(85202003)(55016002)(33656002)(9686003)(54906003)(76116006)(26005)(5660300002)(71200400001)(85182001)(86362001)(186003)(64756008)(66946007)(66616009)(66476007)(66446008)(52536014)(66556008)(66574012)(7696005)(478600001)(4326008)(8936002)(6506007)(2906002)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5391; H:VI1PR07MB4047.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8nEHoffCg7BI1tq/12RYZtO3kwgYxoW/+J0K9iXaX7j0hfjGOw9ORtsxCPv8NCt901wV4eUzIFHhgJz+jWmXjrWU1TowVJ6TEzy1X/uXTsZoazNiR5WDstbtu3uwXXAvzhOBryWShVGvGYDrn6QEvPo3zIEvFEVZN6+Fkf/MxCKF/59p7HMs0A7ydUwRGtQCEept2s+neiZcbyKHN5jzisdVWnAV6JWnv2nMopph5mdJ8cl04wEM0TVzMuJhfBIGYF/XijF0+1XNRzlut9j9mE9FLFvtiiYQUj630aqC5cyn/6fnJYJHPMS2KnxuekcG5j7uWPqKtof5EkuweS4F82wzZjHsbkr3uc1xVkLxFrra7fzx0ky6DF/76P6c7nVl+YRmXjy/z0F+2oy1/SAX1x7OYvgCy7Kiy+x59qn7BVmXW+iPepHLyTxRZzZ88OLI x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0168_01D5C7D8.6305DE50" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 88ad8859-f659-4d53-5c19-08d795e724be X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2020 16:07:08.0864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PhuotD5dwhS14yvN6treutO1/odSeyXHWWbZs6Z7oSHpurewFEuBcYmr8Gim4yonAAFKWrYmtuNUZ+pogH5AefA6fzAwyS5m4xVkQAnjXUU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5391 Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 16:07:15 -0000 ------=_NextPart_000_0168_01D5C7D8.6305DE50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0169_01D5C7D8.6305DE50" ------=_NextPart_001_0169_01D5C7D8.6305DE50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Andy Bierman =20 Sent: 2020. janu=C3=A1r 10., p=C3=A9ntek 16:48 On Fri, Jan 10, 2020 at 4:16 AM Bal=C3=A1zs Lengyel = > = wrote: See BALAZS2 below.=20 =20 > - supported-update-period > - this is very implementation-specific, especially as a leaf-list > instead of a > leaf with a range > - also has 'must' language that is inappropriate; s/must/SHOULD/ See above. What about the supported-update-period leaf-list? If a server allows any centi-second value from 1 sec to 1 hour then this = will be a leaf-list with 5900 instances in it.. Since there is no reason to = limit the upper-bound (e.g., client wants 1 statistics update per day) this leaf-list will = likely have millions of instances in it. =20 IMO this leaf-list should be removed. The minimum-update-period is = sufficient. =20 BALAZS2: There are implementations and standards that use specific = values not ranges. =20 The YANG-Push standard simply specifies "centiseconds" as the type. There is no mention in RFC 8641 of anything related to supporting a = subset of this data type. The YANG syntax for "centiseconds" allows for 4 billion distinct values: =20 typedef centiseconds { type uint32; description "A period of time, measured in units of 0.01 seconds."; } =20 =20 IMO this object could be added via augment by a vendor or other SDO. It has no relevance to the YANG-Push standard. =20 BALAZS3: RFC8641 defines: period centiseconds derived from uint32. However it does not say anything about whether an application = should/shall support - The full uint32 range=20 - Just some interval(s) - Zero to a minimum value - A specific set of values I could argue the same way that a set of specific values is enough, = minimum is not needed and is not specified in RFC8641 IMHO 3GPP is an important user community, so if they are using specific = values, we should allow for that in our model. I see value in allowing both a minimum value and specific values. Does = it harm anyone to allow both? ------=_NextPart_001_0169_01D5C7D8.6305DE50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Andy Bierman <andy@yumaworks.com> =
Sent: 2020. janu=C3=A1r 10., p=C3=A9ntek = 16:48

On Fri, Jan = 10, 2020 at 4:16 AM Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com> wrote:

See BALAZS2 = below. 

<= div>

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type =
uint32;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
"A period of time, measured in units of 0.01 =
seconds.";
=C2=A0=C2=A0=C2=A0=C2=A0 =
}
 
 
IMO this object =
could be added via augment by a vendor or other =
SDO.
It has no relevance to the YANG-Push =
standard.
 
BALAZS3: RFC8641 defines: period =
centiseconds derived from uint32.
However it =
does not say anything about whether an application should/shall =
support
-        =
The full =
uint32 range 
-        =
Just some =
interval(s)
-        =
Zero to a =
minimum value
-        =
A specific =
set of values
I could =
argue the same way that a set of specific values is enough, minimum is =
not needed and is not specified in =
RFC8641
IMHO 3GPP is =
an important user =C2=A0community, so if they are using specific values, =
we should allow for that in our model.
I see value =
in allowing both a minimum value and specific values. Does it harm =
anyone to allow =
both?
------=_NextPart_001_0169_01D5C7D8.6305DE50-- ------=_NextPart_000_0168_01D5C7D8.6305DE50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTIwMDExMDE2MDcwNlowIwYJKoZIhvcNAQkEMRYEFNhp+vdWiFRgblL7619LOsCdnimzMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQAq3zho056W2HtzBz4DP3A8XKfW6PUZytDn0kprVJ0e2r51meDnnf6u xLCJpPpico4/3tX5SLIp3RdPmdA6cJm17DE2AghjklUHZeJaA5czoH8xuZ6Bytf/lwGGI+d3AzO4 vAQuSsmaedSd6XrckQKGco8p0YOQwd0Bo4ZRd7bk+vXlPFEEA2aY+ym3n2XNR/fUGmKy39vny+G+ Z9KMaMZoWAKaZPXHqQUfrOG4iw9ty4UsdDX2gyQ55PqwJJkSjzzJDNt7nqj6rrxS1ZjMws72ui/f xhC5IUv7cdJkx38QtV4POvucdSD3f8EukvfjHj67pWZF46NUg8YIApzwZijjAAAAAAAA ------=_NextPart_000_0168_01D5C7D8.6305DE50-- From nobody Fri Jan 10 08:07: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 2139A120968 for ; Fri, 10 Jan 2020 08:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GoFUZg6Z; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XLozHhEx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sNAXQIQ5NjI for ; Fri, 10 Jan 2020 08:07:38 -0800 (PST) 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 6451E120966 for ; Fri, 10 Jan 2020 08:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7980; q=dns/txt; s=iport; t=1578672454; x=1579882054; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GNxOtB9a7utLZ3bY1/r0ZF+bS4v+cwnFn1GuIG/0+TM=; b=GoFUZg6ZnZRykMmonmXc5O6vz3qVws4Ql88/v92CutAhirQUtXOzGUae 5J+wIoWZs5xnc3nEg32vlsNBir/gX2VsVp9YEqQagR7bmzxxg58iMzn4G eJHMNXKUjTlb6LGHDSJGpc6bsvW04Tqp8k2Ki61ZwxmHy8K6OiBofFNko U=; IronPort-PHdr: =?us-ascii?q?9a23=3AcTLHpR/IfDBLjf9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdSaCEnnK/jCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AAC4oBhe/4YNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWgGAQELAYEkL1AFgUQgBAsqCodFA4sDgl+TK4RigS6BJANUCQE?= =?us-ascii?q?BAQwBAS0CAQGEQAKBciQ1CA4CAw0BAQQBAQECAQUEbYULCCQMhV4BAQEBAxI?= =?us-ascii?q?bEwEBNQIBDwIBCBEEAQEvMh0IAgQBDQUIGoUCTQMuAQKgdQKBOIhhgieCfgE?= =?us-ascii?q?BBYUgGIIMCYE2AYwYGoFBP4FYgkw+hEuDQIIsliIkYJgVCoI3jH6JSppqjlq?= =?us-ascii?q?adAIEAgQFAg4BAQWBVAM0gVhwFTuCbFAYDZFlajiDO4pTdIEojngBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.69,417,1571702400"; d="scan'208,217";a="698397193" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Jan 2020 16:07:33 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 00AG7Xpo027671 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Jan 2020 16:07:33 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 Jan 2020 10:07:32 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 Jan 2020 10:07:32 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 10 Jan 2020 10:07:32 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lz+bEYA0uBZk8wuquakBQ6UXrgMm0Hhd14/i3JuJqiVgZY82rqQlbyIf1D/sQ/KlzR0aBFEWiiXOPKUpNic23g0WMehqflA/vZMHpLppOCFCKqPxCMncw/BOpU1EUZZESZOISpqEk+3RNjS/bdcE5gL1bUWdvy5mfj5l/EzIioVfNGyWFVtb1P3XnrW+VRR6cydSrNH1U57Nxp/C88QoslXkjSeWZ8f+lF0NaIL4hpTSnAMJ/4zveoKpVYpFhPHxWA6gX6GDR1IE6FAs+kTUcjdX6rycANg4R+HwjnWj+tbQmwrS4vM4BYq2RUd4NtHEkijxvI0+T4xn0rCQ271hhg== 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=y5yvVcCgiWug7GLzDCtUqkasElFxAVNIMGr9rVy5aks=; b=UZ9U0ZlvyB2pVas50jFC39hPa4/QcTbdFz7OIdAtLaH3bzB7dM72pmFG/sSvnncdBjuhRKKgjnrnp9JpGlBlauJOWEx0xRPJt4DwEaFJUnKmXiQSobu3nbJtIzJn5FZlF74Q84FbzpT4ecBsOrMEY7pk0c44eV3s1U62mOfGQqwcjTIzfFqu8DBm8ItI53yJsMaw1fXfWJN+TcvYOWs696m+GATUQ1LLYi72Zww5pAS06xKSYLb86EkCkCIXUxotO4/e/aOWuGwCM/PuJNEDGYFJ7606u0997qT9Q6fSMmTi0riNTTny/fYFHWQ02zoWh9W/qMlhfV4OQZxi5Q4/YQ== 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=y5yvVcCgiWug7GLzDCtUqkasElFxAVNIMGr9rVy5aks=; b=XLozHhExQNy2Vbx9KqPEXVjUDri/UXTKZRIDwsGtXBXcTkzC2JyLBvnxSOjMG6hzn37MVXBM0wLV5s6jePAc4El9omhX9d0HDHKbEFlUjXIaJx3fpEp7OnGrY+JkDgNJ7kvUgYOc480CY/inlKe7Bnupuxnjx7AI8dQ7I4vLJgo= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3760.namprd11.prod.outlook.com (20.178.254.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Fri, 10 Jan 2020 16:07:31 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1%7]) with mapi id 15.20.2623.013; Fri, 10 Jan 2020 16:07:31 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen , =?iso-8859-1?Q?Bal=E1zs_Lengyel?= CC: "netconf@ietf.org" Thread-Topic: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt Thread-Index: AQHVxVsSt5Mms9ZtVUqYtH0CGNIWiaffY4HQgAC0VICAANxNAIADGDWAgAAHhLA= Date: Fri, 10 Jan 2020 16:07:31 +0000 Message-ID: References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <0100016f83226d35-4c825571-7fe8-4074-8f6c-d9994e2ed37a-000000@email.amazonses.com> <0100016f901833d0-c822306b-9f2f-4c7b-9444-34742ec35a53-000000@email.amazonses.com> In-Reply-To: <0100016f901833d0-c822306b-9f2f-4c7b-9444-34742ec35a53-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.52] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3170fade-5ede-4b88-38dd-08d795e732cf x-ms-traffictypediagnostic: MN2PR11MB3760: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(136003)(39860400002)(366004)(51444003)(199004)(189003)(55016002)(478600001)(33656002)(8936002)(71200400001)(66556008)(76116006)(2906002)(64756008)(5660300002)(66446008)(66946007)(66476007)(186003)(86362001)(7696005)(15650500001)(53546011)(6506007)(52536014)(26005)(110136005)(8676002)(66574012)(4326008)(316002)(81156014)(81166006)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3760; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gszAtyuYKbURdiZ9QXNb19aT7nUBX+DjK787mRHgw+ihOUXTLLHFGPuBmhyoNKKrMvZPJVDd4wNMkfKJxkLN7KdsGPg1qFZP/NA+g0jRMTKmhzDNYIIFZqq1jsOQaWdINEm63mYSDEHsZdSo9CI7Oa3kGMsKxul8IYUUQu8KEhrcTuIHzXftp0dJ4HEqWKxHvX3wuceFbQptUHOxYHKh+GunLlbcZCeUD+OErcOI2nfxWcgAors8SxBRjAeXjU4UTCk0Pm/5r24MJS4E+jbDBlIMR57T1c/qu1Reb3KDPpGkWshB3KwMfPtE+2XL5hWpkc6MaX5qMeKQzkNHRgwZtJaciBtYgCAnbUVLQGmWXA/tjwFtrPAIYyt8urvAn+bTmNlba+yfTTalkT8u01G/PFasq7oTDhNXdphQfYuoIHX3lSMShTR0lt1i4Nv9fiLCZ6aev1nnU52or8SIplpRhplA7XUwQzbI1f2C+b701264r60oTPeW3kng9k/1aqRs x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43663A607C6739B6B2501C70B5380MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3170fade-5ede-4b88-38dd-08d795e732cf X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2020 16:07:31.7300 (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: Z2UDlK0hsYOJ0DsL/PhGGPBCLHGe+Me9MkoLZ4OGEq/RX8lD7wAmbOs9Hj/06LXIVgUgCaIJii520JvEz+qJoA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3760 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 16:07:43 -0000 --_000_MN2PR11MB43663A607C6739B6B2501C70B5380MN2PR11MB4366namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kent, Balazs, Yes, I think that this would work, but might also need to change the rule f= rom matching the capabilities from the longest node path, to the order that= the entries are in the list. E.g. the capabilities are decided by the fir= st entry in the list that matches the given path. The existing longest nod= e path behaviour can effectively be implemented by ordering the more specif= ic node paths before the less specific node paths. Would that be acceptable? I would also suggest giving the choice and the leaf a separate name below. Thanks, Rob From: Kent Watsen Sent: 10 January 2020 15:35 To: Bal=E1zs Lengyel Cc: Rob Wilton (rwilton) ; netconf@ietf.org Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notifi= cation-capabilities-09.txt Hi Balazs, Would the following be acceptable? OLD: list per-node-capabilities { key "node-selector"; leaf node-selector { type nacm:node-instance-identifier; NEW: list per-node-capabilities { choice node-selector { leaf node-selector { type nacm:node-instance-identifier; } } Later you can augment in an Xpath filter or a string with '*' and '?' wildc= ards or whatever you want. (The list does not need a key as it is config=3Dfalse) Yes, this is inline with what I had in mind but, since this was my suggesti= on, I was hoping that Rob or others would reply. Kent // contributor --_000_MN2PR11MB43663A607C6739B6B2501C70B5380MN2PR11MB4366namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Kent, = Balazs,

&nbs= p;

Yes, I th= ink that this would work, but might also need to change the rule from match= ing the capabilities from the longest node path, to the order that the entr= ies are in the list.  E.g. the capabilities are decided by the first entry in the list that matches the given path.&nb= sp; The existing longest node path behaviour can effectively be implemented= by ordering the more specific node paths before the less specific node pat= hs.

&nbs= p;

Would tha= t be acceptable?

&nbs= p;

I would a= lso suggest giving the choice and the leaf a separate name below.

&nbs= p;

Thanks,

Rob<= /o:p>

&nbs= p;

&nbs= p;

From: Kent Watsen <kent+ietf@watsen.net>
Sent: 10 January 2020 15:35
To: Bal=E1zs Lengyel <balazs.lengyel@ericsson.com>
Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; netconf@ietf.org=
Subject: Re: [netconf] New Version Notification - draft-ietf-netconf= -notification-capabilities-09.txt

 

 

Hi Balazs,



Would the following be acceptable?

OLD:
     list per-node-capabilities {
       key "node-selector";        leaf node-selector {
         type nacm:node-instan= ce-identifier;
NEW:
     list per-node-capabilities {
       choice node-selector {
       &n= bsp;     leaf node-selector {   type n= acm:node-instance-identifier;  }
     }

Later you can augment in an Xpath filter or a string with '*' and '?' wildc= ards or whatever you want.
(The list does not need a key as it is config=3Dfalse)

 

 

Yes, this is inline with what I had in mind but, sin= ce this was my suggestion, I was hoping that Rob or others would reply.

 

Kent // contributor

 

 

--_000_MN2PR11MB43663A607C6739B6B2501C70B5380MN2PR11MB4366namp_-- From nobody Fri Jan 10 08:44: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 C6C88120A07 for ; Fri, 10 Jan 2020 08:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 9r_WGu-7ryT9 for ; Fri, 10 Jan 2020 08:44:38 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFB11209FF for ; Fri, 10 Jan 2020 08:44:38 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id 203so1937307lfa.12 for ; Fri, 10 Jan 2020 08:44:38 -0800 (PST) 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=OEk92bVxNac2gFa8Hzeq5rYvVIWgHs0bO5tre2df21Y=; b=EN72+2LAXGqTElQ4j6RrUkooIsVTl2NaVWcd6zBVhGHfT+wjc6Xw9KFmcN+rGy03QV swrMiwwf1qTvtHlejDi59uVxMEe1WNR7QbCQcCkRZ3gFTfGPnGxl/V/w1LbzE2bI/s8z rjlAAVrv+k0TLAc1rfsVJfAmz+/JmamJrIKQtwemnxTgHq3z8VMbvZRX4VVqZk3uBogT THvdigcT7y5MyswrXdoN/AcZYxmLMem8I6qQJ3lkvRA/s5lZtT7pSeml52LBYqGSj8AT YsC3fkCxb7mz6ykZCA0DnciG39MtDh7EM5Ld37R2hHOJOm6Cy8VmpCxrYuF5PAf6WmVs 3YMA== 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=OEk92bVxNac2gFa8Hzeq5rYvVIWgHs0bO5tre2df21Y=; b=qhJyccabI1xWVNUguS1/c+QWIrzPam+qKvHt58TbOdhmMNADGmIRH4UwV2xEUkdaCX /LiLCYNuCwAEqLWIyC+cmSUs3k30zb3V0ftfKgrYwPaEz7WYtj5+Rv9uUs1pUfCPyi1K vdhLh5ZRNOzeRFJJ1TuqaEG5QnkpigIg93FgF4S2v7iGcVITWEK9LHvzsTjY/aZNvRuX IeUWf8vngZtl5qGx0kdjjCCw+7DrcemH2agEQ8sREAznHaGW7y+1Bn1zBiLlHRNXMlxx dJEjNWo4N8RystkMcUKd4ZscQdA5H1MG+S3VTkNnC/Dyo16X69ajjfaUzdZKxl/SUEjz Ytmg== X-Gm-Message-State: APjAAAUr+R5aTVB7TE6uiNlez9O+u1aaCCe6WkBb64BeIhwQ9rkgsUKs CH6MD+Z9OsoaDdmO2KTQHXf8ujIBymWBuCXJt+ZTJA== X-Google-Smtp-Source: APXvYqwC6k74t/1YHxezy46Wwbx5tUKK3kdk6swZCmTYczLeYro6sYByXgy9rx4NvWCktYVDWBkPV2TT+PxLnDdcJs4= X-Received: by 2002:a19:4849:: with SMTP id v70mr2961837lfa.30.1578674676299; Fri, 10 Jan 2020 08:44:36 -0800 (PST) MIME-Version: 1.0 References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <20200109.125407.1696793655072242187.mbjorklu@cisco.com> In-Reply-To: From: Andy Bierman Date: Fri, 10 Jan 2020 08:44:25 -0800 Message-ID: To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= Cc: Martin Bjorklund , Netconf Content-Type: multipart/alternative; boundary="0000000000004c11fb059bcbd70b" Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 16:44:43 -0000 --0000000000004c11fb059bcbd70b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 10, 2020 at 8:07 AM Bal=C3=A1zs Lengyel wrote: > > > > > *From:* Andy Bierman > *Sent:* 2020. janu=C3=A1r 10., p=C3=A9ntek 16:48 > > On Fri, Jan 10, 2020 at 4:16 AM Bal=C3=A1zs Lengyel < > balazs.lengyel@ericsson.com> wrote: > > *See BALAZS2 below. * > > > > > - supported-update-period > > - this is very implementation-specific, especially as a leaf-list > > instead of a > > leaf with a range > > - also has 'must' language that is inappropriate; s/must/SHOULD/ > > See above. > > What about the supported-update-period leaf-list? > > If a server allows any centi-second value from 1 sec to 1 hour then this > will > > be a leaf-list with 5900 instances in it.. Since there is no reason to > limit the upper-bound > > (e.g., client wants 1 statistics update per day) this leaf-list will > likely have millions > > of instances in it. > > > > IMO this leaf-list should be removed. The minimum-update-period is > sufficient. > > > > BALAZS2: There are implementations and standards that use specific values > not ranges. > > > > The YANG-Push standard simply specifies "centiseconds" as the type. > > There is no mention in RFC 8641 of anything related to supporting a subse= t > of this data type. > > The YANG syntax for "centiseconds" allows for 4 billion distinct values: > > > > typedef centiseconds { > > type uint32; > > description > > "A period of time, measured in units of 0.01 seconds."; > > } > > > > > > IMO this object could be added via augment by a vendor or other SDO. > > It has no relevance to the YANG-Push standard. > > > > BALAZS3: RFC8641 defines: period centiseconds derived from uint32. > > However it does not say anything about whether an application should/shal= l support > > - The full uint32 range > > - Just some interval(s) > > - Zero to a minimum value > > - A specific set of values > > RFC 7950 specifies the server requirements for typedefs, and the built-in type uint32 The YANG-Push data-def-stmts make no mention of any different interpretation of this data type. > I could argue the same way that a set of specific values is enough, minim= um is not needed and is not specified in RFC8641 > > IMHO 3GPP is an important user community, so if they are using specific = values, we should allow for that in our model. > > It is one thing for a client to configure a subset of values and quite another for a server to only accept a subset of the specified values. YANG Push is not constrained to a subset of the centiseconds data type. > I see value in allowing both a minimum value and specific values. Does it= harm anyone to allow both? > > It doesn't belong in the module for YANG-Push. IMO you need to use a deviation to replace the data type because your implementation that only accepts a subset of centiseconds is non-compliant. A client should not have to go read some unrelated capabilities objects to find out how a server deviates from the spec. BTW, the module names a top-level container called 'notification-capabilities' but none of the contents are for generic notifications. They are all for YANG-Push. Andy --0000000000004c11fb059bcbd70b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 10, 2020 at 8:07 AM Bal= =C3=A1zs Lengyel <balazs.= lengyel@ericsson.com> wrote:

=C2=A0

=C2=A0

From:= Andy Bierman <andy@yumaworks.com>
Sent: 2020. janu=C3=A1r 10., p=C3= =A9ntek 16:48

On = Fri, Jan 10, 2020 at 4:16 AM Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com&= gt; wrote:

See BALAZS2 below.=C2=A0=

=C2=A0

>=C2=A0 =C2=A0- supported-update-period
>= =C2=A0 =C2=A0 =C2=A0- this is very implementation-specific, especially as a= leaf-list
> instead of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf with= a range
>=C2=A0 =C2=A0 =C2=A0- also has 'must' language that= is inappropriate; s/must/SHOULD/

See above.

What about the supported-update-= period leaf-list?

If a s= erver allows any centi-second value from 1 sec to 1 hour then this will<= /u>

be a leaf-list with 5900 in= stances in it..=C2=A0 Since there is no reason to limit the upper-bound<= /u>

(e.g., client wants 1 stati= stics update per day) this leaf-list will likely have millions

of instances in it.

=C2=A0

IMO this leaf-list should be removed. The minimum-update-= period is sufficient.

=C2=A0=

BALAZS2: There = are implementations and standards that use specific values not ranges.

=C2=A0

T= he YANG-Push standard simply specifies "centiseconds" as the type= .

There is no mention in= RFC 8641 of anything related to supporting a subset of this data type.<= /u>

The YANG syntax for "c= entiseconds" allows for 4 billion distinct values:

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 typedef centiseconds {

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 type uint32;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "A period of time, measured in units of=
 0.01 seconds.";
=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0
=C2=
=A0
IMO this object could be added via augment by a vendor or other SD=
O.
It has no relevance to the YANG-Push standard.
=C2=A0
BALAZS3:=
 RFC8641 defines: period centiseconds derived from uint32.
Howev=
er it does not say anything about whether an application should/shall suppo=
rt
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 The full uint32 range 
<=
pre style=3D"margin-left:36pt">-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
u>Just so=
me interval(s)
-<=
span style=3D"font:7pt "Times New Roman"">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 Zero to a minimum value<=
/span>
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A specific set of values

RFC 7950 specifies the server requirements for typ= edefs, and the built-in type uint32
The YANG-Push data-def-stmts = make no mention of any different interpretation of this data type.
=C2=A0
I could argue the same way that a se=
t of specific values is enough, minimum is not needed and is not specified =
in RFC8641
IMHO 3GPP is an important user =C2=A0community=
, so if they are using specific values, we should allow for that in our mod=
el.

It is one thing for a client to configure a subset of values a= nd quite another
for a server to only accept a subset of the spec= ified values.
YANG Push is not constrained to a subset of the cen= tiseconds data type.
=C2=A0
I see value in allowing both a minim=
um value and specific values. Does it harm anyone to allow both?

It doesn't b= elong in the module for YANG-Push.
IMO you need to use a deviatio= n to replace the data type because your implementation
that only = accepts a subset of centiseconds is non-compliant.=C2=A0 A client should no= t have to
go read some unrelated capabilities objects to find out= how a server deviates from the spec.

BTW, the mod= ule names a top-level container called 'notification-capabilities' = but none
of the contents are for generic notifications. They are = all for YANG-Push.


Andy
<= br>
=C2=A0
--0000000000004c11fb059bcbd70b-- From nobody Sun Jan 12 05:34: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 F1921120071 for ; Sun, 12 Jan 2020 05:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHn6pncJZsel for ; Sun, 12 Jan 2020 05:34:13 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10053.outbound.protection.outlook.com [40.107.1.53]) (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 DDB14120020 for ; Sun, 12 Jan 2020 05:34:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lIg17l3b2d+Wv8oofegB0v1hbg47tTtNdgSGXIiy0p9YIAaw/E792iJx216cHGfnJD5txL6m/0o1C5n5Q4SlC1dqVbNR+44aztpxx0Geax8Cq5Wga25CWQmSSrukPQYFMI5bYZ9YB6I1ln7pbkfla1jxSP8386NZCxdepkswQvvLzFks26g6ED3QGVD6fTCwrxem+7jbyQHmRU3L+NK925iPDqby8q1hIxzr6TmDDap8vpRoHJdcmdjTCFmVonMo4jQqwZQKikBuEMbtVecxXipV+Mfp6J584UsijcekMgC28rggN2ms26QCwlX0W4O2ET7hsUbAWk+DtZOloOvgCQ== 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=SxaiS6xPK2i/f08SOA1Th4iYnqjhQ72hP9+Oc37X6uw=; b=GLzoHz/G+WhQUXL1x1jU8WY7g68iGBdwizT2v+5bO+D2AnuMqoRqN1krPTSPMrMCg7i27cEh9HpWC7gJIhbM8jEZvq8HIjH9n5ZreBmYNgvNmPsPLh4ni5ZuohDj0vqOwafIFTdQpcc+K8g33BCNr6jR19TpqUUFXcWVbTiWjmN5+GMRIuy8M2BHsUDpa2ijVCWye8PBmD4frSZxOx6s4jZSEQLueYisrTXGly0BU7JNK4KiNHZ/LVZ8sla6l8D1SLBJ+oAtXEHClf0yA9mvmRUp98Gg0ywaweJLfcQsA7pWdOFenvfqpDjdKZKG8Je4j9mP4eSia4xHPsbIF8/Ybw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SxaiS6xPK2i/f08SOA1Th4iYnqjhQ72hP9+Oc37X6uw=; b=CASWe+Jilp1/0sig3Qok5XCAd70O22zClcbupDR656xieGs1GR0+WWCVuw4HUp32OOVt6MDRQMGVENWbSYcGXspXh0NiQhozEi8IWvK0DbkxrnNpHG5fTqR8Kn3NIcj/sT3JXxQNLQakDZGi/D0ET1XO1ij72NKT1uI+kBTXvXk= Received: from AM6PR07MB5189.eurprd07.prod.outlook.com (20.177.198.217) by AM6PR07MB3973.eurprd07.prod.outlook.com (52.134.116.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.12; Sun, 12 Jan 2020 13:34:10 +0000 Received: from AM6PR07MB5189.eurprd07.prod.outlook.com ([fe80::ecdf:a780:e611:2853]) by AM6PR07MB5189.eurprd07.prod.outlook.com ([fe80::ecdf:a780:e611:2853%6]) with mapi id 15.20.2644.015; Sun, 12 Jan 2020 13:34:10 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: update to ssh-server draft Thread-Index: AdWhO0IZE1dC8qjAQkuUng0JdaMGKwAESXOACf0TZJA= Date: Sun, 12 Jan 2020 13:34:10 +0000 Message-ID: References: <0100016e93cdb1a3-6544deca-acbe-4c7c-a5eb-5efdbd8fe2c1-000000@email.amazonses.com> In-Reply-To: <0100016e93cdb1a3-6544deca-acbe-4c7c-a5eb-5efdbd8fe2c1-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [2a02:ab88:1383:f800:899:690a:d703:209] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7d6a123-d44c-4768-eec4-08d797641aff x-ms-traffictypediagnostic: AM6PR07MB3973: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02801ACE41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(376002)(346002)(366004)(396003)(189003)(199004)(7696005)(186003)(4326008)(3480700007)(478600001)(66446008)(8936002)(6506007)(66556008)(76116006)(64756008)(66476007)(9326002)(55016002)(66946007)(81156014)(81166006)(53546011)(8676002)(52536014)(316002)(15650500001)(5660300002)(9686003)(86362001)(66574012)(2906002)(33656002)(4001150100001)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB3973; H:AM6PR07MB5189.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eLlOYcqOZ5BOUupSI5t7o1/Pz+oE/VXt5aGMZh2ASM07196SCxfg70u/bMUZpq4UK3FzBBVKIoL+ArE66t7SL3216+jdPRdrE46xQusaTODhZnacSWFe0yIL6txmzE7mTILELsHzNJrhGBBh3FUw1W+ErZWAuSn1u9coiykcBdc5tj4TcCWycyUwVVPVnTSQD4hy/Wt6gNZQgHSQIWmKYyyRYWw+UsraOjXt+pRMVaRkI48RN1Pw/2DsQPW7puXDyqDBqowQjECp5HVU13usG5pXOWwIQM6apewqRQKJnel743Oct3hn1Rs0F6ItOj5Nl2pVPjV0f1FdUC1gbxw1V8PL/s3kaIpnKN4YQx4p/dbyFsT9gB3aLZ7Vst/cH7mMv3gbKvAwZsNGUwGTBroAnG0b1SjZMSJ8/z44CMG6eJ9hAEndAZ5chPZlNLgf5wFG x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR07MB5189148316EE5D958200243F833A0AM6PR07MB5189eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b7d6a123-d44c-4768-eec4-08d797641aff X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2020 13:34:10.0669 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: r08ydirsodR9oUS7ppJR1ghg8fWDpxYfrbrQv8mq6PFA3FMb+4W9Fao/foKJ8r2OH2SzKUsGIIV1URzp5Y9CHG1Y3HmYkHFPSrq8HcmpPkM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB3973 Archived-At: Subject: Re: [netconf] update to ssh-server draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 13:34:16 -0000 --_000_AM6PR07MB5189148316EE5D958200243F833A0AM6PR07MB5189eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kent, I have some difficulties in understanding the intent of the changes you des= cribe. In ietf-ssh-server@2019-11-20: | +-- supported-authentication-methods | | +-- publickey? empty | | +-- passsword? empty | | +-- hostbased? empty | | +-- none? empty | | +-- other* string Why do we bother with the 'none' and the 'other' methods? 'none' is not rec= ommended, and 'other' is just simply unknown. 'password' and 'publickey' authentication configuration is described by RFC= 7317. I would then expect reusable (local) definitions to be created in RFC= 7317, and until then maybe we should not bother with copying that to the ss= h-server model. Do you really foresee that the system authentication model = cannot be used for SSH? Implementing 'hostbased' could maybe make sense. I assume that requires the= use of 'local-or-truststore-host-keys-grouping' under some username so tha= t the mapping between key and users can be done (as you suggested before). = The users which are defined here could be authenticated with hostkeys on to= p of the RFC7317 users (which can login with pwd or pubkey). I also don't understand the point in having the feature 'client-auth-config= -supported'. The TLS groupings don't have this, and also where would the co= nfiguration of ca-certs, client-certs, etc. be if not in this server groupi= ng? Br, Balazs From: Kent Watsen Sent: Friday, November 22, 2019 4:49 PM To: Bal=E1zs Kov=E1cs Cc: netconf@ietf.org Subject: Re: update to ssh-server draft Hi Balazs, The new local configuration in ssh-server draft seem to have some not appro= priate terminology. The public key of the users should be maybe not called = host keys? Correct. Martin raised this point on the 13th too (subject: "client identi= fication in ietf-netconf-server") In RFC7317: +--rw user* [name] +--rw name string +--rw password? ianach:crypt-hash +--rw authorized-key* [name] +--rw name string +--rw algorithm string +--rw key-data binary In ietf-ssh-server@2019-11-20: | +-- supported-authentication-methods | | +-- publickey? empty | | +-- passsword? empty | | +-- hostbased? empty | | +-- none? empty | | +-- other* string | +-- users {client-auth-config-supported}? | | +-- user* [name] | | +-- name? string | | +-- password? ianach:crypt-hash | | +-- host-keys! | | +---u ts:local-or-truststore-host-keys-grouping Maybe this latter better serves hostbased key authentication? Was that real= ly the intention? Should it be possible to select between user authorized k= ey and host based auth? So for example, if one selects publickey, then shou= ld it still configure a trusted host key? The intention was to support "publickey" based auth (not "hostbased"). As = I was telling Martin, it's the same key format, but it's called "hostkey" f= or servers and has no special name for clients. I was being overzealous wi= th naming it "hostkey" here. That said, there should be a way to configure authenticating clients for *a= ll* the methods, including "hostbased", which isn't supported in the model = yet... Could provide a diff that irons out these issues? Thanks, Kent --_000_AM6PR07MB5189148316EE5D958200243F833A0AM6PR07MB5189eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

I have some difficulties in understanding the intent= of the changes you describe.

 

In ietf-ssh-server@2019-1= 1-20:

       | =
; +-- supported-authentication-methods
       | =
; |  +-- publickey?   empty
       | =
; |  +-- passsword?   empty
       | =
; |  +-- hostbased?   empty
       | =
; |  +-- none?        empty
       | =
; |  +-- other*       string

 

 

Why do we bother with the ‘none’ and the= ‘other’ methods? ‘none’ is not recommended, and &#= 8216;other’ is just simply unknown.

 

‘password’ and ‘publickey’ a= uthentication configuration is described by RFC7317. I would then expect re= usable (local) definitions to be created in RFC7317, and until then maybe w= e should not bother with copying that to the ssh-server model. Do you really foresee that the system authentication model cannot be used = for SSH?

 

Implementing ‘hostbased’ could maybe make sense. I assume=
 that requires the use of ‘local-or-truststore-host-keys-groupingR=
16; under some username so that the mapping between key and users can be do=
ne (as you suggested before). The users which are defined here could be aut=
henticated with hostkeys on top of the RFC7317 users (which can login with =
pwd or pubkey).
 
I also don’t understand the point in having the feature ‘=
client-auth-config-supported’. The TLS groupings don’t =
have this, and also where would the configuration of ca-certs, client-certs=
, etc. be if not in this server grouping?
 
Br,
Balazs

 

 

 

From: Kent Watsen = <kent+ietf@watsen.net>
Sent: Friday, November 22, 2019 4:49 PM
To: Bal=E1zs Kov=E1cs <balazs.kovacs@ericsson.com>
Cc: netconf@ietf.org
Subject: Re: update to ssh-server draft

 

Hi Balazs,

 

The new local configurati= on in ssh-server draft seem to have some not appropriate terminology. The p= ublic key of the users should be maybe not called host keys?

 

Correct.  Martin rai= sed this point on the 13th too (subject: "client identification in iet= f-netconf-server")

 



 In RFC7317:

 

     &= nbsp;      +--rw user* [name]

     &= nbsp;         +--rw name &= nbsp;      string

     &= nbsp;         +--rw password?&n= bsp;  ianach:crypt-hash

     &= nbsp;         +--rw authorized-= key* [name]

     &= nbsp;            = 3;--rw name         string

     &= nbsp;            = 3;--rw algorithm    string

     &= nbsp;            = 3;--rw key-data     binary

 

In ietf-ssh-server@2019-1= 1-20:

       | =
; +-- supported-authentication-methods
       | =
; |  +-- publickey?   empty
       | =
; |  +-- passsword?   empty
       | =
; |  +-- hostbased?   empty
       | =
; |  +-- none?        empty
       | =
; |  +-- other*       string
       | =
; +-- users {client-auth-config-supported}?
       | =
; |  +-- user* [name]
       | =
; |     +-- name?     &nbs=
p;  string
       | =
; |     +-- password?    ianach:cryp=
t-hash
       | =
; |     +-- host-keys!
       | =
; |        +---u ts:local-or-trustst=
ore-host-keys-grouping

 

Maybe this latter better = serves hostbased key authentication? Was that really the intention? Should = it be possible to select between user authorized key and host based auth? S= o for example, if one selects publickey, then should it still configure a trusted host key?

 

The intention was to supp= ort "publickey" based auth (not "hostbased").  As = I was telling Martin, it's the same key format, but it's called "hostk= ey" for servers and has no special name for clients.  I was being overzealous with naming it "hostkey" here.  

 

That said, there should b= e a way to configure authenticating clients for *all* the methods, includin= g "hostbased", which isn't supported in the model yet...

 

Could provide a diff that= irons out these issues?

 

Thanks,

Kent 

 

 

--_000_AM6PR07MB5189148316EE5D958200243F833A0AM6PR07MB5189eurp_-- From nobody Tue Jan 14 03:55: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 F1F21120052 for ; Tue, 14 Jan 2020 03:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUfcevxnKcTf for ; Tue, 14 Jan 2020 03:55:09 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20069.outbound.protection.outlook.com [40.107.2.69]) (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 E3F46120018 for ; Tue, 14 Jan 2020 03:55:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F8+MejHw9Ay/jCe4XCpI3t//eZklFThhjwIINpXNm8igxxJNo2cnd7SfkqCZwfynE3yYiVxbNMT0rpyofeIjLtPGf/aTMTrAzn5qv3hwesr9MfBDtUWVGsF+biIdYNrkIGW+xRhK7ZZs9Tj0CwZsNejTbf7p0Bn+rdznIQRsLtjEB5eeIPMCQTQxafGe/T7lwsGvBEVCrBmFygEVcbo6vx0kDkbhEb8AV4WWWFy8yBHkxEiMOie/STy45wXW3NEyQ85tLJiGTWcYia/z4lJMw4bOGuBiJTg4gw0Wjf7o8QHzOVgDYx1ICdTfPNrbzM0P5U6gOiDT2AlUE3Xw9k3pSw== 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=8s97CMZ0Pa0XkHg2CS0zWEGUtBMFAJ9ngYUAYzsDkqU=; b=hOm/3zd4SMl+SusrzC6kxmIS+xP1GDWv2yuY1xC4fb5f+G2O4TzE5CUlmdOiDYC5bAX2laV0MBfUJQ4KBOzPX0uYAz2wJM3kR/4yhtzmq7PMPKWwBwwViCtVAeshzq2e/pz/jDD7Q/2fWUyixGpmIP2cd6phOoi1cZZ/7DHLBQKRtIFC22CwuMQJ8WZNEP7Zq4E2bRieduzYzOb4aA2WmdVEoYYD6H5+gQ19LbsfkCjI/xwVJ4X9i8qHeTNxKMY6FD+R1KdGDIwH6OXdBRJHu3X76AlUFeoHaFfYGXo9A5xOoTWaXbM9wUFcK3a9NZH2LvQcPtZzE6Q4aENck3KlMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8s97CMZ0Pa0XkHg2CS0zWEGUtBMFAJ9ngYUAYzsDkqU=; b=Ai0xWSwzxuCJ2s9/4PWoIxtju3q3UaPIvg1B9fFOIPfEc/RpNAv8n/7sfeOI0gKtH8cuZB8NYCzsryT1ONA5qPwSDci3Fzocog8irbfmKV2af4FJ+8ohieTdTSbNHWI68oUxwlfKVJNinBLl7xKJ7JlEP+c35RkRUYxTBX+LoTc= Received: from VI1PR07MB4047.eurprd07.prod.outlook.com (52.134.20.154) by VI1PR07MB4688.eurprd07.prod.outlook.com (20.177.57.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18; Tue, 14 Jan 2020 11:55:05 +0000 Received: from VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686]) by VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686%5]) with mapi id 15.20.2644.015; Tue, 14 Jan 2020 11:55:05 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "Rob Wilton (rwilton)" , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt Thread-Index: AQHVxVsUq6ljVkP3y0ecYCN5b7iLjKffZvCAgACw5YCAANp+cIADGgSAgAAJEoCAAA+C4A== Date: Tue, 14 Jan 2020 11:55:05 +0000 Message-ID: References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <0100016f83226d35-4c825571-7fe8-4074-8f6c-d9994e2ed37a-000000@email.amazonses.com> <0100016f901833d0-c822306b-9f2f-4c7b-9444-34742ec35a53-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7aff5b51-05b7-48ef-9c38-08d798e89861 x-ms-traffictypediagnostic: VI1PR07MB4688: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(366004)(346002)(376002)(189003)(199004)(2906002)(5660300002)(316002)(110136005)(66556008)(64756008)(66446008)(66946007)(66574012)(66476007)(76116006)(33656002)(66616009)(8676002)(52536014)(4326008)(71200400001)(15650500001)(9686003)(86362001)(55016002)(478600001)(81156014)(6506007)(53546011)(8936002)(81166006)(7696005)(26005)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4688; H:VI1PR07MB4047.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cTRhDmRzkjhJ1XZ9e1F43vjCEYxnS0CMJ7/n4rIXiODPLkXTljLWvtuhRI8YC/1vU3iUZ6wzd/y5U/tjG19QvhH7K59g27l9sZA91zQK44xRT6h4viJdq3HS6u2W4WLfKheJX3/7timIUIwCwq8horwzvAt3LGYmSBszLpqVi43odzvsHWb0UDMyBpRe2thO6F/Jx0+GlczQE4Ljp36jiccrVg55yc8Urq2nFOJSbbxk7kyYtErhozeSnraWJXI4/FQp0qFgxC8QUp+qqndpl3C2nSKl4dpDN3MNoRL95PlEAF1ypNpnMM8Z/u90q/ytKnAauAUrSntfKptXGyVyDqaP7XzFnDGH31rLPy3aUvEyEc/wJ1kJo6yk14x5RKcBa4D05ZxzxoY/nQtcVDQtH9lWvG2t/BH/G01B+ILsWDZeuY04Pw8EZ7GhxN2/4NeB x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_021B_01D5CAD9.D6627B70" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7aff5b51-05b7-48ef-9c38-08d798e89861 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2020 11:55:05.0883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Nt3GOvc0kF7oMuQOChwSDjBbuaBBAJHT3luhKdeY83Ac5gZhzKgKE71cX/VgIw410iHNb8iVi3EPkNVtUX4VcUaFxGL2SyR7idSXFbQmpNE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4688 Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 11:55:14 -0000 ------=_NextPart_000_021B_01D5CAD9.D6627B70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_021C_01D5CAD9.D6627B70" ------=_NextPart_001_021C_01D5CAD9.D6627B70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK. For both. Regards Balazs =20 From: Rob Wilton (rwilton) =20 Sent: 2020. janu=E1r 10., p=E9ntek 17:08 To: Kent Watsen ; Bal=E1zs Lengyel Cc: netconf@ietf.org Subject: RE: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt =20 Hi Kent, Balazs, =20 Yes, I think that this would work, but might also need to change the = rule from matching the capabilities from the longest node path, to the order = that the entries are in the list. E.g. the capabilities are decided by the = first entry in the list that matches the given path. The existing longest = node path behaviour can effectively be implemented by ordering the more = specific node paths before the less specific node paths. =20 Would that be acceptable? =20 I would also suggest giving the choice and the leaf a separate name = below. =20 Thanks, Rob =20 =20 From: Kent Watsen >=20 Sent: 10 January 2020 15:35 To: Bal=E1zs Lengyel > Cc: Rob Wilton (rwilton) = >; netconf@ietf.org =20 Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt =20 =20 Hi Balazs, Would the following be acceptable? OLD: list per-node-capabilities { key "node-selector"; leaf node-selector { type nacm:node-instance-identifier; NEW: list per-node-capabilities { choice node-selector { leaf node-selector { type nacm:node-instance-identifier; = } } Later you can augment in an Xpath filter or a string with '*' and '?' wildcards or whatever you want. (The list does not need a key as it is config=3Dfalse) =20 =20 Yes, this is inline with what I had in mind but, since this was my suggestion, I was hoping that Rob or others would reply. =20 Kent // contributor =20 =20 ------=_NextPart_001_021C_01D5CAD9.D6627B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

OK. For both.

Regards Balazs

 

From: Rob Wilton (rwilton) = <rwilton@cisco.com>
Sent: 2020. janu=E1r 10., p=E9ntek = 17:08
To: Kent Watsen <kent+ietf@watsen.net>; Bal=E1zs = Lengyel <balazs.lengyel@ericsson.com>
Cc: = netconf@ietf.org
Subject: RE: [netconf] New Version = Notification - = draft-ietf-netconf-notification-capabilities-09.txt

<= /div>

 

Hi Kent, = Balazs,

 

Yes, I think that this would work, but might also need to = change the rule from matching the capabilities from the longest node = path, to the order that the entries are in the list.  E.g. the = capabilities are decided by the first entry in the list that matches the = given path.  The existing longest node path behaviour can = effectively be implemented by ordering the more specific node paths = before the less specific node paths.

 

Would that be = acceptable?

 

I would also suggest giving the choice and the leaf a = separate name below.

 

Thanks,

Rob

 

 

From: Kent = Watsen <kent+ietf@watsen.net> =
Sent: 10 January 2020 15:35
To: Bal=E1zs Lengyel = <balazs.lengyel@ericsson.com>
Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; netconf@ietf.org
Subject: = Re: [netconf] New Version Notification - = draft-ietf-netconf-notification-capabilities-09.txt

 

 

Hi = Balazs,




Would the following be = acceptable?

OLD:
     list = per-node-capabilities {
       key = "node-selector";
       l= eaf node-selector = {
         type = nacm:node-instance-identifier;
NEW:
     l= ist per-node-capabilities = {
       choice node-selector = {
             leaf = node-selector {   type nacm:node-instance-identifier; =  }
     }

Later you can augment = in an Xpath filter or a string with '*' and '?' wildcards or whatever = you want.
(The list does not need a key as it is = config=3Dfalse)

 

 

Yes, this is inline with what I had = in mind but, since this was my suggestion, I was hoping that Rob or = others would reply.

 

Kent // = contributor

 

 

------=_NextPart_001_021C_01D5CAD9.D6627B70-- ------=_NextPart_000_021B_01D5CAD9.D6627B70 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTIwMDExNDExNTUwM1owIwYJKoZIhvcNAQkEMRYEFPr834MY1KxZ3lv/eHe3mVL72j12MEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQBoK4ksiVuVqe/OXhz/uADnNzpaxWT4I/Rsagd08DiotmGtwbABR0YP loOjLPx/PxeVrbPPqvZgfIdQZrXEFIX4qRfsgaBGXDQpQSf/h+tM/yS9bLVPAU6jBJgHCAEL6UMi LVSNC5AdLg9Nx7VH7WBAbVhYzuAlafRzjn5posa+ESbTMq/aED7Bl8haJSRaYXxdaPcLJnAidPLC spzjOoOwDdRwdF33FO72HjOZppBOG2fAx1fSaXvsqDEIUKfLo8kIC41ClmCuHqRmTdffGLWuewSU OO7PJORiVBeZ3vmxjDXj4ZNlZjHbriqhhBiCHdg9qNWeWWt7ZJkSm2T+dZ6uAAAAAAAA ------=_NextPart_000_021B_01D5CAD9.D6627B70-- From nobody Tue Jan 14 08:12: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 8BC311208DF for ; Tue, 14 Jan 2020 08:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TivVU3g7p5BM for ; Tue, 14 Jan 2020 08:12:43 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 67D771208CB for ; Tue, 14 Jan 2020 08:12:43 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id i16so12393556edr.5 for ; Tue, 14 Jan 2020 08:12:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=DsDNMrRqE/46ln9E0WZB80qTCdXITbq4JxZrQuTEgPk=; b=LnnJDphNAb11aBVEv9g+NBbF2cDYNHRNlpe2xqp0wmVd/zHfRlR/gmxQOZu2jPgpoC mTE/Y6kFGrASPn6Lam4PC4p8jHO5GpVPGlsmArarTM+213kBrn8StVu2lI8jR5rOHhzS so+ZqRm7WLGn68SQSQ4cpsHDGMxPFisAeFsaG39xIsF775o66tc5Wbj1m1ywNv+cwRdD VW+QrbCCcnwt3BPMRmJqN0HwnVtRCZdC0cYxbB6bvkoK0j+pqvD5DiqutP8iG2TLEXcB MtmrxOkBQExiRYE+zITr9ukIKCXRv+ttQrXUdQWO9G5O7rhG0CoYRWhQ6FjW0jFoWn2I NUhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DsDNMrRqE/46ln9E0WZB80qTCdXITbq4JxZrQuTEgPk=; b=JudMZy3h/2vin7ScNL/ZyhgBwoRf9QQ+uUsQt21UrnNXYJfHElOGKGlHxXjzz02Xdw ulhsxdcZZw///l470p3vDOB0K7maMYD97ZNoQatJJwWRjHgG1Ye5dWypmstSWn8nr0PR VhctEd7QPel54qapX/Mq6fhQoYCaub6SLTq0y4Y3JgSRSWGzcoFusKex4NbJXcaELqK4 dLOcciztR1jeMf5iPF1BkqJqaW6D0kVYlQp0Sp0pBZZB0On8u6GVMVQ4bsjllhvd4ogw eLyw3swLmdbzHi9hXdw1GW5/uIw8k7irkbxRq2grIOECUEkLkTSaok5vqUJl5daQwSJy Rt9w== X-Gm-Message-State: APjAAAXcN0fVmEOK6ZE2akVWXJ2GWYms/KZs7iVbDkwYrYyxwkQqnGmT 7HWNdYPGhEklJkmyjv/Ex71rLG7d7cPlZ/KIBgMUvvb6NrU= X-Google-Smtp-Source: APXvYqz2GYwXEIRu/IUjTVNhy2jjajYWcFv1YAssgrOqPyjS4aAyuwXl74sNe+RUQO/CzE2pQ9tQiYF2z77FwqV/Uig= X-Received: by 2002:aa7:cd7c:: with SMTP id ca28mr24165184edb.101.1579018361542; Tue, 14 Jan 2020 08:12:41 -0800 (PST) MIME-Version: 1.0 From: aruna potti Date: Tue, 14 Jan 2020 08:13:45 -0800 Message-ID: To: netconf@ietf.org Content-Type: multipart/alternative; boundary="000000000000889c85059c1bdc7b" Archived-At: Subject: [netconf] Query regarding rfc6241 - 7.2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 14 Jan 2020 16:12:50 -0000 --000000000000889c85059c1bdc7b Content-Type: text/plain; charset="UTF-8" Hi, I have a question in section 7.2 of rfc6241. If the operation contains multiple sub-operations that apply to the same conceptual node in the underlying data model, then the result of the operation is undefined (i.e., outside the scope of the NETCONF protocol). As per the description I would like understand if my below query response is defined or not. If my request is not valid, please suggest how we can break it into multiple valid edit-configs? odu-1-11-42/1.1.1 openROADM-if:otnOdu outOfService odu-1-11-2/1 openROADM-if:otnOdu outOfService eth-1-11-2/1 openROADM-if:ethernetCsmacd outOfService odu-1-11-42/1.1.1 openROADM-if:otnOdu odu-1-11-2/1 openROADM-if:otnOdu eth-1-11-2/1 openROADM-if:ethernetCsmacd odu-1-11-42_1.1.1_odu-1-11-2_1 Thanks, Aruna. --000000000000889c85059c1bdc7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have a question in sec= tion 7.2 of rfc6241. 
If the <edit-config> operation contains =
multiple sub-operations
      that apply to the same conceptual node in the underlying data
      model, then the result of the operation is undefined (i.e.,
      outside the scope of the NETCONF protocol).

As per the description I would like understand if my bel=
ow query response is defined or not. 
If my request is not valid, please suggest how we can break it into multip=
le valid edit-configs?

<=
nc:rpc
xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
nc:message-id=3D"FJ0883">

=C2=A0=C2=A0<nc:edit-config>
=C2=A0=C2=A0=C2=A0=C2=A0<nc:target>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<nc:running/> </nc:target> =
=C2=A0=C2=A0=C2=A0=C2=A0<nc:config>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<org-openroadm-device xmlns=3D"= http://org/openroadm/device">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<interface>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<name>odu= -1-11-42/1.1.1</name>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<type xmlns:openROADM-if=3D"<= span style=3D"color:rgb(5,99,193)">http://org/openroadm/interfaces">openROADM-if:otnOdu</type>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<administrat= ive-state>outOfService</administrative-state>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<odu xmlns=3D"http://org/openroadm/otn-odu-interfaces"/> </interface>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<interface>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<name>odu= -1-11-2/1</name>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<type xmlns:openROADM-if=3D"<= span style=3D"color:rgb(5,99,193)">http://org/openroadm/interfaces">openROADM-if:otnOdu</type>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<administrat= ive-state>outOfService</administrative-state>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<odu xmlns=3D"http://org/openroadm/otn-odu-interfaces"/> </interface>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<interface>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<name>eth= -1-11-2/1</name>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<type xmlns:openROADM-if=3D"<= span style=3D"color:rgb(5,99,193)">http://org/openroadm/interfaces">openROADM-if:ethernetCsmacd</type>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<administrat= ive-state>outOfService</administrative-state>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</interface>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<interface nc:operation=3D"delete">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<name>odu= -1-11-42/1.1.1</name>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<type xmlns:openROADM-if=3D"<= span style=3D"color:rgb(5,99,193)">http://org/openroadm/interfaces">openROADM-if:otnOdu</type>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</interface>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<interface nc:operation=3D"delete">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<name>odu= -1-11-2/1</name>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<type xmlns:openROADM-if=3D"<= span style=3D"color:rgb(5,99,193)">http://org/openroadm/interfaces">openROADM-if:otnOdu</type>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</interface>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<interface nc:operation=3D"delete">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<name>eth= -1-11-2/1</name>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<type xmlns:openROADM-if=3D"<= span style=3D"color:rgb(5,99,193)">http://org/openroadm/interfaces">openROADM-if:ethernetCsmacd</type>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</interface>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<odu-connection nc:operation=3D"delete">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<connection-= name>odu-1-11-42_1.1.1_odu-1-11-2_1</connection-name>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</odu-connection>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</org-openroadm-device>
=C2=A0=C2=A0=C2=A0=C2=A0</nc:config>
=C2=A0=C2=A0</nc:edit-config>
</nc:rpc>


<= p class=3D"MsoNormal" style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-= family:"Calibri",sans-serif">Thanks,

Aruna.

--000000000000889c85059c1bdc7b-- From nobody Tue Jan 14 14:30:36 2020 Return-Path: <0100016fa62df2a2-005fc9be-4f02-4ba8-b731-1357af75e116-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 248BA120046 for ; Tue, 14 Jan 2020 14:30:34 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Gi2aNyCf0ASH for ; Tue, 14 Jan 2020 14:30:28 -0800 (PST) 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 AF49C120044 for ; Tue, 14 Jan 2020 14:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1579041027; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=FjESzx0ZgaW3xrEuDB1KOsuOajPp2ogY77t/rSUmIkM=; b=k/ZdLb5jOnAxSbDnDZUq2zHCutNmBlWOhiJ95H8/PNArdeLGDgli7cXsKdSS9qSW FjxCi4f7sXS+DxbyGaKlnKCnedW6RzfnEdU+gV1Xh3n3I4PSTPZmsT7RGPjDaSaOsFn d3wcVS7wzoPjjmTmLvNtwOXt0Whx+HWK9UyehOU4= From: Kent Watsen Message-ID: <0100016fa62df2a2-005fc9be-4f02-4ba8-b731-1357af75e116-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_616DAE20-32F8-41E7-9597-E4B77D82E6FF" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 14 Jan 2020 22:30:27 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= References: <0100016e93cdb1a3-6544deca-acbe-4c7c-a5eb-5efdbd8fe2c1-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.01.14-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] update to ssh-server draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 22:30:34 -0000 --Apple-Mail=_616DAE20-32F8-41E7-9597-E4B77D82E6FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Balazs, It is good to see that you're digging into the SSH modules, as they (and = the NETCONF modules) are the only modules that I don't have running code = for... Regarding your questions: > I have some difficulties in understanding the intent of the changes = you describe. > =20 > In ietf-ssh-server@2019-11-20: > | +-- supported-authentication-methods > | | +-- publickey? empty > | | +-- passsword? empty > | | +-- hostbased? empty > | | +-- none? empty > | | +-- other* string > =20 > =20 > Why do we bother with the =E2=80=98none=E2=80=99 and the =E2=80=98other=E2= =80=99 methods? =E2=80=98none=E2=80=99 is not recommended, and = =E2=80=98other=E2=80=99 is just simply unknown. RE "none": this is defined because it is in RFC 4252. Yes, there's lots = of guidance in that RFC regarding the use of "none", but it is = *supported*... I think what is needed here is a `feature` statement = enabling the server to express if "none" is supported of not - agreed? RE "other": I don't remember how "other" came to be listed, but it = doesn't appear in RFC 4252 and therefore should be removed (updated in = my local copy). > =E2=80=98password=E2=80=99 and =E2=80=98publickey=E2=80=99 = authentication configuration is described by RFC7317. I would then = expect reusable (local) definitions to be created in RFC7317, and until = then maybe we should not bother with copying that to the ssh-server = model. Do you really foresee that the system authentication model cannot = be used for SSH? System-level and NETCONF-level users may not be the same. I know some = system co-mingle the two while others don't. BTW, RFC 4252 says that "password" SHOULD be required, so a `feature` = statement seem warranted. RFC 4252 says that "publickey" is REQUIRED, = so *no* `feature` statement is needed for it. =20 > Implementing =E2=80=98hostbased=E2=80=99 could maybe make sense. I = assume that requires the use of = =E2=80=98local-or-truststore-host-keys-grouping=E2=80=98 under some = username so that the mapping between key and users can be done (as you = suggested before). The users which are defined here could be = authenticated with hostkeys on top of the RFC7317 users (which can login = with pwd or pubkey). RFC 4252 says that this method name is OPTIONAL, and therefore a = `feature` statement seems warranted here as well. Yes, it seems that =E2=80=98local-or-truststore-host-keys-grouping=E2=80=98= would be in play here. I don't think it needs to be under a username, as the SSH-client still = explicitly sends a username (same as with "none") per RFC 4552 Section = 5. =20 > I also don=E2=80=99t understand the point in having the feature = =E2=80=98client-auth-config-supported=E2=80=99. The TLS groupings = don=E2=80=99t have this, and also where would the configuration of = ca-certs, client-certs, etc. be if not in this server grouping? Please check again, the tls-server-grouping does have = 'client-auth-config-supported' = (https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-17#secti= on-4 = ). Answering your last question, note that TLS-level client auth is = optional, as client auth MAY occur at a protocol-layer above TLS. That = said, I'll grant you that this feature may not be ideal as instead, = perhaps, the server could instead rely on *if* any of the descendants = were configured. I'm less sure about SSH, but I don't believe that client authentication = can ever occur at a higher-level protocol layer. That being the case, = there's likely a good augment to removing the = "client-auth-config-supported" feature in ietf-ssh-server. =20 Kent // contributor --Apple-Mail=_616DAE20-32F8-41E7-9597-E4B77D82E6FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Balazs,

It is = good to see that you're digging into the SSH modules, as they (and the = NETCONF modules) are the only modules that I don't have running code = for...

Regarding your = questions:


I have some difficulties in understanding the intent of the = changes you describe.
 
In = ietf-ssh-server@2019-11-20:
     =
  |  +-- supported-authentication-methods
       |  |  +-- =
publickey?   empty
       =
|  |  +-- passsword?   empty
       |  |  +-- =
hostbased?   empty
       =
|  |  +-- none?        =
empty
       |  |  +-- =
other*       string
 
 
Why do we = bother with the =E2=80=98none=E2=80=99 and the =E2=80=98other=E2=80=99 = methods? =E2=80=98none=E2=80=99 is not recommended, and =E2=80=98other=E2=80= =99 is just simply unknown.

RE "none": this is defined because it is in RFC = 4252.  Yes, there's lots of guidance in that RFC regarding the use = of "none", but it is *supported*...   I think what is needed here = is a `feature` statement enabling the server to express if "none" is = supported of not - agreed?

RE = "other": I don't remember how "other" came to be listed, but it doesn't = appear in RFC 4252 and therefore should be removed  (updated in my = local copy).


=E2=80=98password=E2=80=99 and =E2=80=98publickey=E2=80=99 = authentication configuration is described by RFC7317. I would then = expect reusable (local) definitions to be created in RFC7317, and until = then maybe we should not bother with copying that to the ssh-server = model. Do you really foresee that the system authentication model cannot = be used for SSH?

System-level and NETCONF-level users may not be the = same.  I know some system co-mingle the two while others = don't.

BTW, RFC 4252 says that = "password" SHOULD be required, so a `feature` statement seem warranted. =  RFC 4252 says that "publickey" is REQUIRED, so *no* `feature` = statement is needed for it.
 

Implementing =E2=80=98hostbased=E2=80=99 could maybe make =
sense. I assume that requires the use of =
=E2=80=98local-or-truststore-host-keys-grouping=E2=80=98 under some =
username so that the mapping between key and users can be done (as you =
suggested before). The users which are defined here could be =
authenticated with hostkeys on top of the RFC7317 users (which can login =
with pwd or pubkey).

RFC 4252 says that this method name is OPTIONAL, = and therefore a `feature` statement seems warranted here as = well.

Yes, it seems = that =E2=80=98local-or-truststore-host-keys-grouping=E2=80=98 = would be in play here.

I don't think it needs to be under a username, as the = SSH-client still explicitly sends a username (same as with "none") per = RFC 4552 Section 5.

 
I =
also don=E2=80=99t understand the point in having the feature =
=E2=80=98client-auth-config-supported=E2=80=99. The TLS groupings don=E2=80=99t have this, and also where =
would the configuration of ca-certs, client-certs, etc. be if not in =
this server grouping?


Answering your = last question, note that TLS-level client auth is optional, as client = auth MAY occur at a protocol-layer above TLS.  That said, I'll = grant you that this feature may not be ideal as instead, perhaps, the = server could instead rely on *if* any of the descendants were = configured.

I'm less sure about SSH, = but I don't believe that client authentication can ever occur at a = higher-level protocol layer.  That being the case, there's likely a = good augment to removing the "client-auth-config-supported" feature in = ietf-ssh-server.  


Kent // contributor


= --Apple-Mail=_616DAE20-32F8-41E7-9597-E4B77D82E6FF-- From nobody Tue Jan 14 16:34:23 2020 Return-Path: <0100016fa69f59c6-212e569d-fb2b-47cb-a1ff-e897829ba111-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 AE797120046 for ; Tue, 14 Jan 2020 16:34:21 -0800 (PST) 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_DNSWL_NONE=-0.0001, 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 JNt8O7ZbpNht for ; Tue, 14 Jan 2020 16:34:20 -0800 (PST) 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 416B412002F for ; Tue, 14 Jan 2020 16:34:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1579048459; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=VuAK6RpWgBINstgYvao0pp6HbdMtE0WZ7mkhLJBGjq0=; b=U156AHyaw4ktc15/z/L7b/SGuTMznQvd2FriFGGuUk0/SCFRfrNBZOyqP9Anavzi 9CzUU+f9dnQtidDu2UpZh0E2uJIjUEDwnrQz30wGhp2GDscTjNvu1Q2nevQE5TTg9Zp rsIaoHoSv5oOpO0OJ7jHALIny0sl5J+Noz5wDaFQ= From: Kent Watsen Message-ID: <0100016fa69f59c6-212e569d-fb2b-47cb-a1ff-e897829ba111-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_11C1D9E4-68A6-49B9-B51A-0F57E978C39A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 15 Jan 2020 00:34:19 +0000 In-Reply-To: <20191119.161851.678459934233941550.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <20191119.161851.678459934233941550.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.01.15-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [netconf-wg/https-notif] Should the receivers container be moved under the augment statement and the leafref renamed? (#2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 15 Jan 2020 00:34:22 -0000 --Apple-Mail=_11C1D9E4-68A6-49B9-B51A-0F57E978C39A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, > On Nov 19, 2019, at 10:18 AM, Martin Bjorklund wrote: >=20 >> The reason to not move the receiver container under the augment is so >> as to allow the leafref to point to multiple receivers. >=20 > I don't understand this reason. Each "receiver" (in https-notif) maps to an HTTPS connection from the = publisher to the receiver. There is likely to be more than one configured subscription, yet all = notifications should go to the same receiver. We'd like to use the same HTTPS "connection" for all, as opposed to = having an HTTPS connection for each. The "receiver-ref" leaf provides an indirection enabling this = many-to-one relationship. > Since this is not a stand-alone model, I think it should augment > /sn:subscriptions. In some way it doesn't matter what nodes are > called and where they are located, but having descriptive names and > keep related nodes under common subtrees helps the understanding of > models. Is s/receiver-ref/https-receiver-ref/ what you had in mind? Kent // contributor --Apple-Mail=_11C1D9E4-68A6-49B9-B51A-0F57E978C39A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,


On Nov 19, 2019, at 10:18 AM, = Martin Bjorklund <mbj@tail-f.com> wrote:

The = reason to not move the receiver container under the augment is so
as to allow the leafref to point to multiple receivers.

I don't understand this reason.

Each "receiver" (in https-notif) maps to an HTTPS = connection from the publisher to the receiver.

There is likely to be more than one configured = subscription, yet all notifications should go to the same = receiver.

We'd like to use the same = HTTPS "connection" for all, as opposed to having an HTTPS connection for = each.

The "receiver-ref" leaf = provides an indirection enabling this many-to-one = relationship.


Since this is = not a stand-alone model, I think it should augment
/sn:subscriptions.  In some way it doesn't matter what = nodes are
called and = where they are located, but having descriptive names and
keep related = nodes under common subtrees helps the understanding of
models.

Is s/receiver-ref/https-receiver-ref/ = what you had in mind?



Kent // contributor


= --Apple-Mail=_11C1D9E4-68A6-49B9-B51A-0F57E978C39A-- From nobody Tue Jan 14 17:01: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 9DF1812002F for ; Tue, 14 Jan 2020 17:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTjBEO_97IwP for ; Tue, 14 Jan 2020 17:00:53 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45218120058 for ; Tue, 14 Jan 2020 17:00:53 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id z16so7533305pfk.0 for ; Tue, 14 Jan 2020 17:00:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=8wCQXf0Tk7XB6Zx3IBK1/0wtB3FUsKhmXXcV31X+IFA=; b=DJDjmTiPR6OHHMG58fVAmpn/BiNJW/Ift/OK0lztf1AH7pbzkEBSZ0aRbGhRriktzu RAcRFY5GPQRuAZKUWZlIU+GTrgC73CbKZ9rpCK33028caxC/B/p3UNQZFVUczJMdEXO9 9DeY/qWKEy9UxGBmxb9gHOAveYZ5X9zUcCXhn51Bpf0RfqhSVCvUB171LCipCJfogSnM i1rJv7BoYU356hCpUXUkroLmvUOO+VZrk6c6DiO6zlnQH/T5gZRDL+NMxAyghw3TvqAV CZVlb2TzkuIjvpRsw5qkP8YCr69uJLBLV8BMEzyfJqg+vyEPAFmeCMip+WInL3GPqWMQ SEpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=8wCQXf0Tk7XB6Zx3IBK1/0wtB3FUsKhmXXcV31X+IFA=; b=rw8nfZjJg3Vp055xzp7X5kIvrZ4jj0SDU7zV7QRZSXQbXVJ65SlZOgzfIZX0Xs4OWK ZeXe2M/3MLviaIUiZQEFVL7oqa01UxnzOveO4pQfiz0g+/ZQfdOYd4uvJhosG3zdFRgu THNVlpEmC96DO3+hnviY6dTg+lxko43Te5w/zZv5hITCM6nR8f5TeqFxPOFShUAr2q6F d6DkrMa7KJI8iutyH8iVwDNQSkDOmPfJqqI54RKetfyuS+8VLN5MVjSA5sdodXxhk/gQ 1L4mmCc+fJ3Dr2fXvxNjF0WRambC5qchw/NU0oZR5Gb0k7UF9dVjdHmV401QH9olknbf u8EA== X-Gm-Message-State: APjAAAVX1kfCZfAKtCxSvzzOfi26AcQD+ebdXH4hZMyRZolUsXejyN4T ZEbt1c1W/qsXf0OWa+jP2sMZ3Dhw X-Google-Smtp-Source: APXvYqxgcvIpqJhKggTnIS+NB8GAziwkT6cXIljj5fpS2VJyOOwC83fhM+RxJWi45C6ZtjDdTW3LKw== X-Received: by 2002:a63:6fca:: with SMTP id k193mr31217947pgc.416.1579050052374; Tue, 14 Jan 2020 17:00:52 -0800 (PST) Received: from [10.33.123.108] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id t63sm19633357pfb.70.2020.01.14.17.00.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Jan 2020 17:00:51 -0800 (PST) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Tue, 14 Jan 2020 17:00:50 -0800 To: Netconf X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [netconf] Issue #1 Can binary be an added option to the encoding mechanism X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 15 Jan 2020 01:01:00 -0000 The above issue was opened on GitHub to track support for binary = encoding of notifications in draft-ietf-netconf-https-notification = draft. The question is how does a publisher learn of the receiver = capabilities, including its ability to receive binary encoded = notifications. The original suggestion was to use OPTIONS method in HTTP to learn = receivers capability. It turns out that OPTIONS does not have a header = that can be used for this purpose. Martin suggested using Accept-Post, = but the IETF draft that suggested that header has expired, and we are = not clear on the support for it. Therefore, the current proposal is to use GET with a specific = Content-Type that returns metadata, i.e. an ordered set of encodings. Comments/Questions? Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed Jan 15 04:01:36 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 A7A0C1200A3 for ; Wed, 15 Jan 2020 04:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 Ev2VL5z4txF2 for ; Wed, 15 Jan 2020 04:01:28 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1139212006D for ; Wed, 15 Jan 2020 04:01:27 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 76FF51AE0351; Wed, 15 Jan 2020 13:01:23 +0100 (CET) Date: Wed, 15 Jan 2020 13:00:46 +0100 (CET) Message-Id: <20200115.130046.2182524722233687962.mbj@tail-f.com> To: arunapotti@gmail.com Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] Query regarding rfc6241 - 7.2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 15 Jan 2020 12:01:35 -0000 Hi, It seems you are setting the administrative-state to 'outOfService' on a set of interfaces, and at the same time you delete these interfaces. So instead you should simply just delete them. Alternatively, fist send one edit-config that sets the administrative-state, and then a second edit-config with the deletes. /martin aruna potti wrote: > Hi, > > I have a question in section 7.2 of rfc6241. > > If the operation contains multiple sub-operations > that apply to the same conceptual node in the underlying data > model, then the result of the operation is undefined (i.e., > outside the scope of the NETCONF protocol). > > As per the description I would like understand if my below query > response is defined or not. > > If my request is not valid, please suggest how we can break it into > multiple valid edit-configs? > > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > nc:message-id="FJ0883"> > > > > > > > > odu-1-11-42/1.1.1 > xmlns:openROADM-if="http://org/openroadm/interfaces">openROADM-if:otnOdu > > outOfService > > > > odu-1-11-2/1 > xmlns:openROADM-if="http://org/openroadm/interfaces">openROADM-if:otnOdu > > outOfService > > > > eth-1-11-2/1 > xmlns:openROADM-if="http://org/openroadm/interfaces">openROADM-if:ethernetCsmacd > > outOfService > > > odu-1-11-42/1.1.1 > xmlns:openROADM-if="http://org/openroadm/interfaces">openROADM-if:otnOdu > > > > odu-1-11-2/1 > xmlns:openROADM-if="http://org/openroadm/interfaces">openROADM-if:otnOdu > > > > eth-1-11-2/1 > xmlns:openROADM-if="http://org/openroadm/interfaces">openROADM-if:ethernetCsmacd > > > > odu-1-11-42_1.1.1_odu-1-11-2_1 > > > > > > > > Thanks, > > Aruna. From nobody Wed Jan 15 12:23:25 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 D01011209CB for ; Wed, 15 Jan 2020 12:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=klC8Byja; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=pk4SDOAT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1WZvAIbGbWF for ; Wed, 15 Jan 2020 12:23:22 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A291209EA for ; Wed, 15 Jan 2020 12:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22801; q=dns/txt; s=iport; t=1579119802; x=1580329402; h=from:to:cc:subject:date:message-id:mime-version; bh=8aWVL1429urYs38ZcKnOdq2xdL8XdHkhA5GrUGYbMR8=; b=klC8ByjadIzKI3Qz4/S/u6XUNY5JQ/fEjmL3S9hBEw3QM3lkC4qRcC97 YQRI5N01jTRnTzQwZy1Xa4I+sxCv6Zl4588eANosYxSH5tTwoRjGPWk/e VplWVNhX+TQ0mEabPqHrSuPbd2wnPJAB7+At/SSwMMUPXneKOTUhtf28U E=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AJn0eBhzvDyHqPh7XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YRyN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuIF0r6MNbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdCAACdB9e/4gNJK1lHQEBAQkBEQU?= =?us-ascii?q?FAYF7gSUvUAVsKy0gBAsqCodLA4p4ihyQUYJSA1QCBwEBAQkDAQElCAIBAYR?= =?us-ascii?q?AAoF/JDgTAgMNAQEEAQEBAgEFBG2FNwyFYRYbEwEBNwERARYXIzAmAQQODQY?= =?us-ascii?q?NB4MFgX1NAx8PAQIMnWkCgTiIYYIngn8BAQWBMwIOQYMkGIIGBwMGgTaBU4p?= =?us-ascii?q?FGoFBP4FYgh8Bg04BAQIBARiBSSuDFYIsjVeJV5gaCoI4BINhgjiBII8Omm6?= =?us-ascii?q?XOZIjAgQCBAUCDgEBBYFpIoFYcBWDJ1AYDYgBg3OFFIU/dIEpiyUBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,323,1574121600"; d="p7s'?scan'208,217";a="413229132" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jan 2020 20:23:21 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00FKNLYB016733 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jan 2020 20:23:21 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 Jan 2020 14:23:20 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 Jan 2020 14:23:13 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 15 Jan 2020 14:23:13 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SVwXUsnytQdk8a+i53ozpHhKkTlk5yuI2auaTsNr7FOQVVWOaF+gj7kl4xowlx25WkpE//6CHHgvu6y6waLGeYlyi9ez0BZQJZKz6D/eb6H8idpxj6t1+mnIQdfO21W6BjnocFqoYHs9waqMM92dMajzCQv4ZVj8ky/WsvB9aw6PJbB+hm3lNMxI7McyYbfmu+1fJ6K0HrlvWC7WBtmFCebcMjV49eqwNJ7f/yyWsi1OnI2iV4VsjmYGDXj464c4QZSCEEO1xLHnW03pgvGV680j/3VOJAjZPuIErnCfJ34BAAcZjIcfnr0+ve3L1KIJbznh41bdDLF6wCSXzA2Cgw== 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=Rs5pwhdBTd14AoN6x7vYm8wRUCCdliQDfU+XUMo/q3w=; b=QwlXTIJCe8rqiZJqHBOKnRukIkrUPpszXXziPzyJugX+/bgXWcjHju1LXtNz+b4JdVwKNf9yzrWaUbkR1JJ9PtDJAyDPe9mkKftb1zSNG2T6bIIKESvDkqkhwBzt6XdAjU3jEp4Kz0fwtXDVD3+ASga1qPfFEu6uxHkJzJrdzXrBz9jSRBlnNTnpXQE7avFn395nngZoX8Tbk0nXOiPegihthpTnOkOLOTsPWrHjDxg8v+d2F0ufryjHTpS1ORMr372gqjtmi6IDElYRYbAQ9FVgrgrRsFfIj0OmOk4uQ0EDGlgLdKP/iAOl66E0IQL5eFQ4kDNGaFrhAgNEv7vM7g== 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=Rs5pwhdBTd14AoN6x7vYm8wRUCCdliQDfU+XUMo/q3w=; b=pk4SDOATBxGirtv7zRV9akPeZ1xoSx/loUGGsyx1ZyIspL5If9/XmaoW5aiXOesLmBJdXWSrJRBNi4mdyQn97mCf2WPjpIyNaEKrnpb0MZXAnq6StgABdpv1J2pdRK8aHkVBdsa7S+9zaQ1OiAEIxRINBLOe8EXd0N2ir2X+HYM= Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18; Wed, 15 Jan 2020 20:23:12 +0000 Received: from BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5]) by BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5%5]) with mapi id 15.20.2644.015; Wed, 15 Jan 2020 20:23:12 +0000 From: "Eric Voit (evoit)" To: Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: Configured receiver capability exchange Thread-Index: AdXL4TILBTPP/wetTxqO44ff1VxXqQ== Date: Wed, 15 Jan 2020 20:23:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f1bb2959-e0a9-4f4c-8feb-08d799f8be81 x-ms-traffictypediagnostic: BYAPR11MB3638: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(189003)(199004)(5660300002)(33656002)(26005)(8676002)(3480700007)(81156014)(81166006)(71200400001)(9326002)(2906002)(8936002)(6506007)(7696005)(186003)(4326008)(9686003)(66476007)(66616009)(66556008)(55016002)(66446008)(76116006)(86362001)(66946007)(6916009)(52536014)(498600001)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3638; H:BYAPR11MB2536.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P1VH4UhD0ZkcjVjZGmEdmr1heXZ5iQYYo7M5PBq8I/c/WzuMNyaAVBz/aRyYiy6blXtpZlII+v7eAw+dY747YvrBRw7H2wrsOzz5skQBOW53QIQwrr0+dxtqy4aKYoJagMzQspmX/xCYe9fi5uP/axa1BQYODKCVBUpUJvaMjCdd8UAUcvYdXN8FNntrwbdsTaylKEEAgDnS5NEdIcW2goKboPJ436zRdiGz/4TGGr+lVhdXMyZqog9wpbmMo2iIWqCJMbaZsTO6lfWLQmGM+bFxXDdxI1C+E2lH6KZg8zawVxWseH5WfpBdYHTO1PjFST8ByaxZeaoeM0wG7VS0iFg+MIKKH8MriLgujXVCTYMEkjYKovypQWoAt57fbc0f54dHaPr6E9z81RP8PNUjPtxTuFMwr/Ri5Py5aPtE2GCNpQYLnBxDu1jPnoc6ssb87n2K8nhJoPcceC/bpmC7AGCUXEU/lHU2b/DDXXCR9+8= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0108_01D5CBB7.ACE3ED90" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f1bb2959-e0a9-4f4c-8feb-08d799f8be81 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 20:23:12.2016 (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: i5u6DqlelTnLf+Wep5UN5Wsaqgeb06WBtVpg7pKihrfNAp/2+OEH0UP6UGseJGg4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3638 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: [netconf] Configured receiver capability exchange X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 15 Jan 2020 20:23:25 -0000 ------=_NextPart_000_0108_01D5CBB7.ACE3ED90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0109_01D5CBB7.ACE3ED90" ------=_NextPart_001_0109_01D5CBB7.ACE3ED90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mahesh, During the IETF 106 session, there was discussion on how both a publisher might know if there is receiver support for draft-ietf-netconf-notification-messages. Section 6 highlights several of the considerations. Relevant are the following: (a) Remote device capability discovery from the point of view of the Publisher needs to be enhanced to know if the far end can interpret notification messages type beyond RFC-5277, Section 4. (b) This capability discovery question is relevant for both configured subscription receivers and dynamic subscribers. (c) The capability discovery question can be generalized beyond subscriptions, as there are many reasons to know the available capabilities of the far end. (d) Capability discovery advertisement has traditionally been discussed within transport documents (e.g. RFC-6241 Section 8.1). Based on (a)-(d), coming up with a transport independent point-solution within draft-ietf-netconf-notification-messages *just* to discover this single element of client functionality seems overkill/heavyweight. I was fine with letting this remote capabilities discovery question sit for a while. However draft-ietf-netconf-https-notif shows that we now must address this question. Specifically should the diagram section 1.4.1 show this capability exchange? It turns out that independent of draft-ietf-netconf-notification-messages, there several questions in draft-ietf-netconf-https-notif which need to be answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with YANG defined notification #1" anyway. These questions are: (1) Does the targeted HTTPS receiver support configured subscriptions? (2) Can the targeted HTTP@ receiver accept a new subscription as described in a ? Only if these questions are "yes", should the be responded to with an "OK". Add to this a third question driven from (a)-(d): (3) Does the receiver support the message type within "draft-ietf-netconf-notification-messages"? A strawman way to handle the all three questions within draft-ietf-netconf-https-notif would be to respond to a notification with an HTTP Status 202 (Accepted)" acknowledgement. This 202 would include body elements listing supported receiver resources. Maybe something YANG encoded via ietf-yang-structure-ext containing: urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 What do you think of this approach? Eric ------=_NextPart_001_0109_01D5CBB7.ACE3ED90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mahesh,

 

During the = IETF 106 session, there was discussion on how both a publisher might = know if there is receiver support for draft-ietf-netconf-notification-messages.  Section 6 highlights several of the considerations.   Relevant are the = following:

 

(a) Remote device capability discovery from the point = of view of the Publisher needs to be enhanced to know if the far end can = interpret notification messages type beyond RFC-5277, Section = 4.

 

(b) This capability discovery question is relevant for = both configured subscription receivers and dynamic subscribers.  =

 

(c) The capability discovery question can be = generalized beyond subscriptions, as there are many reasons to know the = available capabilities of the far end.  

 

(d) = Capability discovery advertisement has traditionally been discussed = within transport documents (e.g. RFC-6241 Section 8.1).  =  

 

 

Based on = (a)-(d), coming up with a transport independent point-solution within draft-ietf-netconf-notification-messages *just* to discover this single element of client functionality seems = overkill/heavyweight.

 

I was fine = with letting this remote capabilities discovery question sit for a = while.   However dr= aft-ietf-netconf-https-notif shows that we now must address this = question.  Specifically should the diagram section 1.4.1 show this = capability exchange? 

 

It turns out = that independent of draft-ietf-netconf-notification-messages, there = several questions in draft-ietf-netconf-https-notif which need to be = answered prior to the section 1.4.1 arrow: "Send HTTPS POST message = with YANG defined notification #1" anyway.  These questions = are:

  (1) Does the targeted = HTTPS receiver support configured subscriptions?

  (2) Can the targeted HTTP@ receiver accept a = new subscription as described in a = <subscription-started>?

Only if = these questions are "yes", should the = <subscription-started> be responded to with an = "OK".

 

Add to this = a third question driven from (a)-(d):

  (3) Does the receiver support the message type = within = "draft-ietf-netconf-notification-messages"?

 

A strawman = way to handle the all three questions within = draft-ietf-netconf-https-notif would be to respond to a = <subscription-started> notification with an HTTP Status 202 = (Accepted)" acknowledgement.  This 202 would include body = elements listing supported receiver resources.  Maybe something = YANG encoded via ietf-yang-structure-ext containing:

 

      <foo = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

        = <capabilities>

          = <capability>

         &= nbsp;  = urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0

=

          = </capability>

    =     </capabilities>

      = </foo>

 

What do you think of this approach?

 

Eric

 

------=_NextPart_001_0109_01D5CBB7.ACE3ED90-- ------=_NextPart_000_0108_01D5CBB7.ACE3ED90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTE1MjAyMzAxWjAjBgkqhkiG 9w0BCQQxFgQUqa5dBn4fkinH8cwl/16ul3D8yT8wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQALHgWXUflMZHcL4tMtdd9vwFDX8I0lmL5As/a7GttOb0KN5cqcImw4xGcFHfKVBXrg 3Fvms3hx4+v/O+ZSmSPAGpv6v5Gvpq/7hTKG8x/p3clgEc+1HMrvlc0LjTPZ/CkOYyFrP89CgUD8 L1KB6g4B3r07H24LIyH/AqD4WuZ5jaqLvybCna5jrQtuy+5XrlAWPXn2Hv6k+rFn5KJNlKmjv/Y1 IXzSEKR9B+u2yRjcWEIlpZMo2qaed5jNcGyeMmAw1RSn3Y3LjUymuGUiNv+lZORAAHqOcoZaUJWh gtmh23XRKM2YW3nsPt4obGqLPbf0JyFzLfiaP5G699EV/cdKAAAAAAAA ------=_NextPart_000_0108_01D5CBB7.ACE3ED90-- From nobody Thu Jan 16 07:20:21 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 1DF94120112; Thu, 16 Jan 2020 07:20:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157918802007.26211.15290734681239936924@ietfa.amsl.com> Date: Thu, 16 Jan 2020 07:20:20 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-10.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 15:20:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Generic YANG-related System Capabilities and YANG-Push Notification Capabilities Authors : Balazs Lengyel Alexander Clemm Benoit Claise Filename : draft-ietf-netconf-notification-capabilities-10.txt Pages : 23 Date : 2020-01-15 Abstract: This document proposes two YANG modules. The module ietf-system- capabilities provides a structure that can be used to specify any YANG related system capability. The module ietf-notification-capabilities allows a publisher to specify capabilities related to "Subscription to YANG Datastores" (YANG-Push). It proposes to use YANG Instance Data to document this information and make it already available at implementation-time, but also allow it to be reported at run-time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-10 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 17 04:27: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 1172E120836 for ; Fri, 17 Jan 2020 04:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YN_RBTIJt3MK for ; Fri, 17 Jan 2020 04:27:13 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10067.outbound.protection.outlook.com [40.107.1.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D6B12003F for ; Fri, 17 Jan 2020 04:27:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FM2AJln+Tu6NNCH8qunOiU4S/OXDVzQNJwaY06SOGS8AmGfUOlVJVpk9lb3WfeQB7BbQjwYBQPhyJKrBmAe7xyc53tV/UoFavBL8cSJhZkFxjwCM7pQtcCCqpOG/jhybLtvPUWLxU7eFVX0glwiN1X1wckckhNKODk4m6h4SMQLOh4ChFqPrVJpSxMBDbNC2OoaiTUyX9ZzNWMC/f7GGn/x9gsiogEbhionKgNTTFRXmO8Ujy9NP0DJ8YvFaYF0jHRMy5OnSSut4OzbsoeoBKqgWF4loGDXE5z95zJbf1P9rhlLLSbnSOJ9kXOjh9iwVqdyVuuC9Vjx3os79rcFjeQ== 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=ezzyXUdDrR1OYbyrKbpLuMWhzstp5igVCiLbR1ejhNQ=; b=T6tmfbODHjY+JFJfEHJPWU/wAcx3KhXN30ZB5F5tqhFxk/QAWWOqpXNhnjBMYwc7o1ai3omwntwnPYRUw6UcRd6PUYpwjNTA9HZUQL1st+ne4t3h2MOnIf3hhKEXuQqM+72I6+WGhmqIUIhxPKhEJ+1viYdi29GTxCN/upfj98UT+KwK3XjrZ40czC7MKwuoAMSfxvcoLy8w17kan79cZC2HGMOAxXXTxOZk4pc0F+axOxm3pkDE2H72xuq/RevvwU1YNnmIKOxqxYe676Tik6b6tSQAXFi+d47CtIO3eYbGbbI8FrX6VUbmLOX6jWrLYEL+6NithpPaim4dFc7i5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ezzyXUdDrR1OYbyrKbpLuMWhzstp5igVCiLbR1ejhNQ=; b=TYj865o6QsBf6eSjZYBSN0f8JBnTONK7EX5UIWzLVyQ63whYwnJnGEUfkLDwaNnTHhLNtrMLEGzJ46GW+nBJ0YDnEvTFGpa/y/MkxDEa0BXC+HT0UsaWlGKLfD/8iL1TqaGzVCUDm8Q800Mn8Egx514HOMyCne0BInmmLfMbMQI= Received: from VI1PR07MB4047.eurprd07.prod.outlook.com (52.134.20.154) by VI1PR07MB6111.eurprd07.prod.outlook.com (20.178.124.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.6; Fri, 17 Jan 2020 12:27:10 +0000 Received: from VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686]) by VI1PR07MB4047.eurprd07.prod.outlook.com ([fe80::819:a879:8fe2:1686%5]) with mapi id 15.20.2644.015; Fri, 17 Jan 2020 12:27:10 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "Eric Voit (evoit)" , Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: Configured receiver capability exchange Thread-Index: AdXL4TILBTPP/wetTxqO44ff1VxXqQBT5rgg Date: Fri, 17 Jan 2020 12:27:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df5b193d-32f9-4ed0-a55c-08d79b4892de x-ms-traffictypediagnostic: VI1PR07MB6111: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(396003)(346002)(136003)(39860400002)(199004)(189003)(53546011)(6506007)(55016002)(7696005)(9686003)(9326002)(86362001)(71200400001)(2906002)(110136005)(316002)(26005)(66574012)(3480700007)(4326008)(478600001)(186003)(5660300002)(52536014)(66946007)(66616009)(8676002)(66556008)(64756008)(66476007)(66446008)(81156014)(81166006)(33656002)(76116006)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB6111; H:VI1PR07MB4047.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WGnD2Em7j4SylJA7kSnS0Meta0AvDfnURClE31bmO3XQ4kJZILYYswIuCP+TLEkbv3FuSKc5rLSQlXXe3ML+Z0MDa9/dbojaxRdrLalkzKx/4231BAIto0GL4TydXuWEn26nCTeZFpPvDsFxux/qAozIwlj4vHi3hKnBTwrwQMNCUn3C3Hdp1KKJGeEHeUoho3P6Q1+0o5h+d96JvYxneSp3zGFE9A9GtryILnfy/+I5nJRSpRoX5aXJsvDsLZAxR0M8seuFWW1FvsiSzQpw6Ws1uTAIHEEg6Bp7a7M9zMUeNc563hocLWP1uggM/tMz+tj1WcjeqpodI4dbgNlFmKZrosCRGLRgCydtDI50jK0bYcp+13L5eCrOW0sAEUCIWNQmJrDx3Li+dcm7a6sogiXpXWvmjSHgLHNoNJXCm6Oki2xbaTr14xGMBBOa+4Gc6rwqvroIyoDZnNFEwlgEtVwuRVDYUlYusmmtxVm7vFPBqCczl7St0iB/yC3z5PWhjyZfa17IAJMpIOlhhgkxnA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C5_01D5CD39.D11A7660" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: df5b193d-32f9-4ed0-a55c-08d79b4892de X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2020 12:27:09.9300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OvzuQMklMSjXaR4HNA+MosHKTHd7Oqjf01qZ1dhbMrsoc6FMDEP+9A23Dv63wTWgsZLi7lelkVyVs5YiNAE8oU0Gt9Mz8sV/oPA/dZUSAMA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6111 Archived-At: Subject: Re: [netconf] Configured receiver capability exchange X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 17 Jan 2020 12:27:20 -0000 ------=_NextPart_000_00C5_01D5CD39.D11A7660 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00C6_01D5CD39.D11A9D70" ------=_NextPart_001_00C6_01D5CD39.D11A9D70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I would like a discovery mechanism that does not include a mandatory additional message roundtrip.=20 =20 Most of the times the subscriber will be aware of the receivers capabilities, in these cases so discovery is not needed; so don=92t add overhead. =20 Customers also indicated that they anticipate that TCP/TLS will often be used only for a few notifications broken down and later reestablished so = any overhead we add will be added for each (many) session setup.=20 =20 Regards Balazs =20 From: netconf On Behalf Of Eric Voit (evoit) Sent: 2020. janu=E1r 15., szerda 21:23 To: Mahesh Jethanandani Cc: netconf@ietf.org Subject: [netconf] Configured receiver capability exchange =20 Hi Mahesh, =20 During the IETF 106 session, there was discussion on how both a = publisher might know if there is receiver support for draft-ietf-netconf-notification-messages. Section 6 highlights several of the considerations. Relevant are the following: =20 (a) Remote device capability discovery from the point of view of the Publisher needs to be enhanced to know if the far end can interpret notification messages type beyond RFC-5277, Section 4. =20 (b) This capability discovery question is relevant for both configured subscription receivers and dynamic subscribers. =20 =20 (c) The capability discovery question can be generalized beyond subscriptions, as there are many reasons to know the available = capabilities of the far end. =20 =20 (d) Capability discovery advertisement has traditionally been discussed within transport documents (e.g. RFC-6241 Section 8.1). =20 =20 =20 Based on (a)-(d), coming up with a transport independent point-solution within draft-ietf-netconf-notification-messages *just* to = discover this single element of client functionality seems overkill/heavyweight. =20 I was fine with letting this remote capabilities discovery question sit = for a while. However draft-ietf-netconf-https-notif shows = that we now must address this question. Specifically should the diagram = section 1.4.1 show this capability exchange? =20 =20 It turns out that independent of = draft-ietf-netconf-notification-messages, there several questions in draft-ietf-netconf-https-notif which need to = be answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with YANG defined notification #1" anyway. These questions are: (1) Does the targeted HTTPS receiver support configured subscriptions? (2) Can the targeted HTTP@ receiver accept a new subscription as = described in a ? Only if these questions are "yes", should the be responded to with an "OK". =20 Add to this a third question driven from (a)-(d): (3) Does the receiver support the message type within "draft-ietf-netconf-notification-messages"? =20 A strawman way to handle the all three questions within draft-ietf-netconf-https-notif would be to respond to a notification with an HTTP Status 202 (Accepted)" acknowledgement. This 202 would include body elements listing supported receiver resources. Maybe something YANG encoded via ietf-yang-structure-ext containing: =20 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 =20 What do you think of this approach? =20 Eric =20 ------=_NextPart_001_00C6_01D5CD39.D11A9D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

I would like = a discovery mechanism that does not include a mandatory additional = message roundtrip.

 

Most of the = times the subscriber will be aware of the receivers capabilities, in = these cases so discovery is not needed; so don’t add = overhead.

 

Customers also indicated that they anticipate that = TCP/TLS will often be used only for a few notifications broken down and = later reestablished so any overhead we add will be added for each (many) = session setup.

 

Regards = Balazs

 

From: netconf = <netconf-bounces@ietf.org> On Behalf Of Eric Voit = (evoit)
Sent: 2020. janu=E1r 15., szerda 21:23
To: = Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: = netconf@ietf.org
Subject: [netconf] Configured receiver = capability exchange

 

Hi = Mahesh,

 

During the IETF 106 session, there was discussion on = how both a publisher might know if there is receiver support for draft-ietf-netconf-notification-messages.  Section 6 highlights several of the considerations.   Relevant are the = following:

 

(a) Remote device capability discovery from the point = of view of the Publisher needs to be enhanced to know if the far end can = interpret notification messages type beyond RFC-5277, Section = 4.

 

(b) This capability discovery question is relevant for = both configured subscription receivers and dynamic subscribers.  =

 

(c) The capability discovery question can be = generalized beyond subscriptions, as there are many reasons to know the = available capabilities of the far end.  

 

(d) = Capability discovery advertisement has traditionally been discussed = within transport documents (e.g. RFC-6241 Section 8.1).  =  

 

 

Based on = (a)-(d), coming up with a transport independent point-solution within draft-ietf-netconf-notification-messages *just* to discover this single element of client functionality seems = overkill/heavyweight.

 

I was fine = with letting this remote capabilities discovery question sit for a = while.   However dr= aft-ietf-netconf-https-notif shows that we now must address this = question.  Specifically should the diagram section 1.4.1 show this = capability exchange? 

 

It turns out = that independent of draft-ietf-netconf-notification-messages, there = several questions in draft-ietf-netconf-https-notif which need to be = answered prior to the section 1.4.1 arrow: "Send HTTPS POST message = with YANG defined notification #1" anyway.  These questions = are:

  (1) Does the targeted = HTTPS receiver support configured subscriptions?

  (2) Can the targeted HTTP@ receiver accept a = new subscription as described in a = <subscription-started>?

Only if = these questions are "yes", should the = <subscription-started> be responded to with an = "OK".

 

Add to this = a third question driven from (a)-(d):

  (3) Does the receiver support the message type = within = "draft-ietf-netconf-notification-messages"?

 

A strawman = way to handle the all three questions within = draft-ietf-netconf-https-notif would be to respond to a = <subscription-started> notification with an HTTP Status 202 = (Accepted)" acknowledgement.  This 202 would include body = elements listing supported receiver resources.  Maybe something = YANG encoded via ietf-yang-structure-ext containing:

 

      <foo = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

        = <capabilities>

          = <capability>

         &= nbsp;  = urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0

=

          = </capability>

    =     </capabilities>

      = </foo>

 

What do you think of this approach?

 

Eric

 

------=_NextPart_001_00C6_01D5CD39.D11A9D70-- ------=_NextPart_000_00C5_01D5CD39.D11A7660 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTIwMDExNzEyMjcwOFowIwYJKoZIhvcNAQkEMRYEFEX+KUPSMCD76CwVOBkImHKNRCmZMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQAoYFL0JtPZA2jtj11CIudW5+iUf2ezUik9PaUC30ljMGP/ipGVKzAx x0a8ILHRqR53SBzKyBSZSJ9HWlSaP+yOZOmHMjvx96jqLA58YCFHihlt2typTxpWuoTPhnAbTYSu j+sMWAq9/L8bPKzCSmqSU+qctTI5Bz2q6F+vxuyE02V8Gg0upOeB3aAksMg0RW3iCPXMB3kMwBhe 9pJb3wRYdf+BYzJuTqsAZTwXXcr2wGIxk7Tlna9iRgqoCjkKvlfeh1EPMYDGm/9OR7wx8tPSUXUW C4XAIvr1O/cicLKvoBaCE0F7ohaGzLRp5iGV90OkjhUaYQN3p8+gOy4UB8cfAAAAAAAA ------=_NextPart_000_00C5_01D5CD39.D11A7660-- From nobody Fri Jan 17 09:35: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 824EB120043 for ; Fri, 17 Jan 2020 09:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=b2YpN9Xh; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=lLB3feE4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxlRPF3aL0XV for ; Fri, 17 Jan 2020 09:35:43 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA5712007C for ; Fri, 17 Jan 2020 09:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22362; q=dns/txt; s=iport; t=1579282543; x=1580492143; h=from:to:subject:date:message-id:mime-version; bh=AJvbAq5HQqf34sz8OjGD4Rd96dWX9L56dFDW/2eWO7M=; b=b2YpN9XhkC2qbUf/Ybbu51tVcuJg2QC181STBNAjI5grYR6vPQk84jT2 55rXi/KKHQ03q8oQQLQx1BPbNxfa1JpNiVeTWfX4qqiLrDRSeUBJESH1W TTSyDqhxpinBYplSHfUJnTt1mEf7srmSk9AAFM9QVGwiWk4ZuOg0VXwaJ U=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AwfSc0B3OOeI0YRBzsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGPt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQBFP8LeLCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1EwDu7yFe/51dJa1lHgELHIMgLyQ?= =?us-ascii?q?sBWwrLSAECyoKh00DinlOghGJYIlMhGKCUgNUAgcBAQEJAwEBJQgCAQGEQAK?= =?us-ascii?q?CCiQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQIDEhsTAQE4EQEIEQQBAQ4aCR8?= =?us-ascii?q?RFAkJAQQBEggGDQeDBYF9TQMfDwECDKIAAoE5iGGCJ4J/AQEFgTMCDkGCew0?= =?us-ascii?q?LggUHAwaBNoFTg0gMhm0agUE/gViCTD6BVEdJAQECAQEYgUkrCYMMgiyNWg2?= =?us-ascii?q?JTJdZRAqCOYNlgjg5Z4pLhEOaco5ciGGCIZADAgQCBAUCDgEBBYFpIoFYcBW?= =?us-ascii?q?DJ1AYDYgBg3OFFIU/dIEpiy4BgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,331,1574121600"; d="p7s'?scan'208,217";a="699262626" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jan 2020 17:35:42 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 00HHZghs030601 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jan 2020 17:35:42 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 17 Jan 2020 11:35:41 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 17 Jan 2020 11:35:41 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 17 Jan 2020 11:35:41 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GA63kbQKIFp/R5E9bNhO8zkTVbat3VZd/S8etjdCi3SnUIOvsXG6UVMYGgRt7CSjjd31jt/xdDZbZXJtxWpKMkVsavM8NG1tlFtjwjNNyGMGAc8R/HsKQDyhFpDBko1kGafBOXa8cDF7RUf3xWBaXyl1nf7Zi844KUj5yQqt9a+a0ZG8Am+CBLQQPl8LYwNsE81/Q2nFxWmu3MxQ2W24dmoAYGlEtj63eLAWOMyROgnz5sknrZUcVAFGKgGHkU27o4zCi6r2OSdrLCZbhOVZmb3dX6qBefWQdRrZkcsxqPzDdqyldkzaa67hTiDj3+b5hMQClhu66pVw7oxdmjTcoQ== 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=kf/PlYLtLUi5IL4rCYuaSlzSEXlmv97YtioHy/7oRIg=; b=QW4lu6UcF5YaZRadZK+da/tbYGn66atVQoHSm+dabb651Dz3Iswk4Sy9UoHIvpc12ppHwpvkjJSHYYL7KOv0vPE22hecMQ/Mz7mbYZG0c6Pwsffn6jA0ntdXg2tFEFk3JmmIcHofoq+lalfMsO2mf3UJYkdxDpZQKFY1hiK9yoBLqbtRwuE+xI/ino+PN10geUHTm0FS4Oo8LOqbImk6mmSx8ni2hIPoqcXieSzvcCHzPjuhHcBN4tWsG7Kl19Om1YkSxlfAetXzplJdtPDpHxlRH2JNQYnqUtDayYl4MyaMPuyLxTy6u+0+QPs5t3Ma+FyoTYoTzqQ8/qJAGifVOw== 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=kf/PlYLtLUi5IL4rCYuaSlzSEXlmv97YtioHy/7oRIg=; b=lLB3feE4cjwAw1K62/HPGDELVqF6FpzASSyraveOnZ8qX9Bh7PJoUbGaDyvuX8g+zcBpdpHxiQaOWfpR85UUTpB1/m8vsTSB7iQ1Nli9ZpypydqFszESy6HSndUCFunVWuRAB0muM1VX4XC6vb8IIgMAtA1SpKJ9tVeGVJH6NiM= Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB3063.namprd11.prod.outlook.com (20.177.225.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.23; Fri, 17 Jan 2020 17:35:39 +0000 Received: from BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5]) by BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5%5]) with mapi id 15.20.2644.015; Fri, 17 Jan 2020 17:35:39 +0000 From: "Eric Voit (evoit)" To: "netconf@ietf.org" , "Balazs Lengyel (balazs.lengyel@ericsson.com)" Thread-Topic: Configured receiver capability exchange Thread-Index: AdXNXIcLBTPP/wetTxqO44ff1VxXqQ== Date: Fri, 17 Jan 2020 17:35:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 12a74c6a-9e57-4993-4bd6-08d79b73ab9c x-ms-traffictypediagnostic: BYAPR11MB3063: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3513; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(39860400002)(136003)(396003)(189003)(199004)(66476007)(66616009)(316002)(110136005)(52536014)(55016002)(76116006)(64756008)(66556008)(66446008)(71200400001)(66574012)(33656002)(66946007)(86362001)(9686003)(5660300002)(3480700007)(7696005)(2906002)(53546011)(81166006)(26005)(6506007)(186003)(9326002)(81156014)(8676002)(8936002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3063; H:BYAPR11MB2536.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5bNLxvDIbCKTlT+/J+yTiD+VliYVl7Sq/CaNrDD5EHSIHigVAO/vcbVrCHc5AY0Z/+L6x5agNe5xR7VgCkMhCYO2lClDshu955peRxM01+w6sCg5BDB8uE6/wREElAAawD2tesI0q1x+s/XH2wy9WQfVKTTkN6Z8OJf/ic5QgMl9SyvWuoBBCuuMg66BzRKRMlVmyJhX9ugpW6lXbqRG4xxijs6KviKELhsYxNt3pmE0bp1DB972uZPDOAP1jwj2+atjiBCr+qCbdQ+lr62aysvx3bh5gn9RBjeKTf1XS/BT1D9ScUGVTaQoMgAZtEnr/ofeUvUL2WeYOvlFoCwAkZPBqkaQ5Latw02rMeK9IqPAzlvm0lF6eJhbnix5XDTiaFM8x8y+dBajvBR52cdjZ1c6OxyMUBhXgx7mdEvEPB/gKviWhM/HfAORHk1TWc83xBc+Ey7s4CyLQ4fQmvtnJuJeRW8ziLBf2tTHiJx7iCw= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0053_01D5CD32.9E40E690" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 12a74c6a-9e57-4993-4bd6-08d79b73ab9c X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2020 17:35:39.6197 (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: /i3dhaFP9yxq0T1tcwBrz8cz6e3jyRqc0oHXqAOlCw8vvaqrZ2xR5kykzfCxvlOD X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3063 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netconf] Configured receiver capability exchange X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 17 Jan 2020 17:35:48 -0000 ------=_NextPart_000_0053_01D5CD32.9E40E690 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0054_01D5CD32.9E40E690" ------=_NextPart_001_0054_01D5CD32.9E40E690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Balazs, =20 The proposal below wouldn't have another roundtrip. Basically the 'OK' response to a would include the receiver capabilities. =20 As there could be multiple configured subscriptions, these receiver capabilities could end up being delivered a number of times. I guess we might then only include the receiver capabilities for the first = configured subscription established to that receiver. =20 Eric =20 From: Bal=E1zs Lengyel >=20 Sent: Friday, January 17, 2020 7:27 AM To: Eric Voit (evoit) >; = Mahesh Jethanandani > Cc: netconf@ietf.org =20 Subject: RE: Configured receiver capability exchange =20 Hello, I would like a discovery mechanism that does not include a mandatory additional message roundtrip.=20 =20 Most of the times the subscriber will be aware of the receivers capabilities, in these cases so discovery is not needed; so don=92t add overhead. =20 Customers also indicated that they anticipate that TCP/TLS will often be used only for a few notifications broken down and later reestablished so = any overhead we add will be added for each (many) session setup.=20 =20 Regards Balazs =20 From: netconf > On Behalf Of Eric Voit (evoit) Sent: 2020. janu=E1r 15., szerda 21:23 To: Mahesh Jethanandani > Cc: netconf@ietf.org =20 Subject: [netconf] Configured receiver capability exchange =20 Hi Mahesh, =20 During the IETF 106 session, there was discussion on how both a = publisher might know if there is receiver support for draft-ietf-netconf-notification-messages. Section 6 highlights several of the considerations. Relevant are the following: =20 (a) Remote device capability discovery from the point of view of the Publisher needs to be enhanced to know if the far end can interpret notification messages type beyond RFC-5277, Section 4. =20 (b) This capability discovery question is relevant for both configured subscription receivers and dynamic subscribers. =20 =20 (c) The capability discovery question can be generalized beyond subscriptions, as there are many reasons to know the available = capabilities of the far end. =20 =20 (d) Capability discovery advertisement has traditionally been discussed within transport documents (e.g. RFC-6241 Section 8.1). =20 =20 =20 Based on (a)-(d), coming up with a transport independent point-solution within draft-ietf-netconf-notification-messages *just* to = discover this single element of client functionality seems overkill/heavyweight. =20 I was fine with letting this remote capabilities discovery question sit = for a while. However draft-ietf-netconf-https-notif shows = that we now must address this question. Specifically should the diagram = section 1.4.1 show this capability exchange? =20 =20 It turns out that independent of = draft-ietf-netconf-notification-messages, there several questions in draft-ietf-netconf-https-notif which need to = be answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with YANG defined notification #1" anyway. These questions are: (1) Does the targeted HTTPS receiver support configured subscriptions? (2) Can the targeted HTTP@ receiver accept a new subscription as = described in a ? Only if these questions are "yes", should the be responded to with an "OK". =20 Add to this a third question driven from (a)-(d): (3) Does the receiver support the message type within "draft-ietf-netconf-notification-messages"? =20 A strawman way to handle the all three questions within draft-ietf-netconf-https-notif would be to respond to a notification with an HTTP Status 202 (Accepted)" acknowledgement. This 202 would include body elements listing supported receiver resources. Maybe something YANG encoded via ietf-yang-structure-ext containing: =20 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 =20 What do you think of this approach? =20 Eric =20 ------=_NextPart_001_0054_01D5CD32.9E40E690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Balazs,

 

The proposal = below wouldn't have another roundtrip.  Basically the 'OK' response = to a <subscription-started> would include the receiver = capabilities.

 

As there could be multiple configured subscriptions, = these receiver capabilities could end up being delivered a number of = times.  I guess we might then only include the receiver = capabilities for the first configured subscription established to that = receiver.

 

Eric

 

From: = Bal=E1zs Lengyel <balazs.lengyel@ericsson.com>
Sent: Friday, January 17, 2020 7:27 AM
To: = Eric Voit (evoit) <evoit@cisco.com>; Mahesh = Jethanandani <mjethanandani@gmail.com>Cc: netconf@ietf.org
Subject: = RE: Configured receiver capability exchange

 

Hello,

I would like = a discovery mechanism that does not include a mandatory additional = message roundtrip.

 

Most of the = times the subscriber will be aware of the receivers capabilities, in = these cases so discovery is not needed; so don’t add = overhead.

 

Customers also indicated that they anticipate that = TCP/TLS will often be used only for a few notifications broken down and = later reestablished so any overhead we add will be added for each (many) = session setup.

 

Regards = Balazs

 

From: netconf <netconf-bounces@ietf.org>= On Behalf Of Eric Voit (evoit)
Sent: 2020. janu=E1r = 15., szerda 21:23
To: Mahesh Jethanandani <mjethanandani@gmail.com>Cc: netconf@ietf.org
Subject: = [netconf] Configured receiver capability = exchange

 

Hi = Mahesh,

 

During the IETF 106 session, there was discussion on = how both a publisher might know if there is receiver support for draft-ietf-netconf-notification-messages.  Section 6 highlights several of the considerations.   Relevant are the = following:

 

(a) Remote device capability discovery from the point = of view of the Publisher needs to be enhanced to know if the far end can = interpret notification messages type beyond RFC-5277, Section = 4.

 

(b) This capability discovery question is relevant for = both configured subscription receivers and dynamic subscribers.  =

 

(c) The capability discovery question can be = generalized beyond subscriptions, as there are many reasons to know the = available capabilities of the far end.  

 

(d) = Capability discovery advertisement has traditionally been discussed = within transport documents (e.g. RFC-6241 Section 8.1).  =  

 

 

Based on = (a)-(d), coming up with a transport independent point-solution within draft-ietf-netconf-notification-messages *just* to discover this single element of client functionality seems = overkill/heavyweight.

 

I was fine = with letting this remote capabilities discovery question sit for a = while.   However dr= aft-ietf-netconf-https-notif shows that we now must address this = question.  Specifically should the diagram section 1.4.1 show this = capability exchange? 

 

It turns out = that independent of draft-ietf-netconf-notification-messages, there = several questions in draft-ietf-netconf-https-notif which need to be = answered prior to the section 1.4.1 arrow: "Send HTTPS POST message = with YANG defined notification #1" anyway.  These questions = are:

  (1) Does the targeted = HTTPS receiver support configured subscriptions?

  (2) Can the targeted HTTP@ receiver accept a = new subscription as described in a = <subscription-started>?

Only if = these questions are "yes", should the = <subscription-started> be responded to with an = "OK".

 

Add to this = a third question driven from (a)-(d):

  (3) Does the receiver support the message type = within = "draft-ietf-netconf-notification-messages"?

 

A strawman = way to handle the all three questions within = draft-ietf-netconf-https-notif would be to respond to a = <subscription-started> notification with an HTTP Status 202 = (Accepted)" acknowledgement.  This 202 would include body = elements listing supported receiver resources.  Maybe something = YANG encoded via ietf-yang-structure-ext containing:

 

      <foo = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

        = <capabilities>

          = <capability>

         &= nbsp;  = urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0

=

          = </capability>

    =     </capabilities>

      = </foo>

 

What do you think of this approach?

 

Eric

 

------=_NextPart_001_0054_01D5CD32.9E40E690-- ------=_NextPart_000_0053_01D5CD32.9E40E690 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTE3MTczNTM2WjAjBgkqhkiG 9w0BCQQxFgQUvlJbRVedBe5m0CAKO0s8omTko28wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAOPjvrbsWd97LX6UA3kstGhmN9dAmJSPTS/evzLqXd+VDsl8jH0qwH7iJF5u/c+Hbf RYrQb4d3Mo0eFTHtmRgiSMT7nNJ+9qR3GpCiW4gtIfkW6jkL/9WDxRxYG8rNtCgAS5g9lYN9KCTQ +P+5z5UUFkRrMDgRwQZAks1n3OoF+LXhqXdXk5WEqg8jHCYXGKNSmHIsflWnm0Dh9mQvVe+9IhkA 0kAmp96NKzbgUMMV/FOBvLsUWjbHjCxyNr6dwrjPj1rnYs0mWg8bJcDpmGnC70ZZaBvNYirHb2O8 jvKQbVyJeb2RA16UiuXW0UhYqLQuRXZy0CgtR3xwd0gHlcggAAAAAAAA ------=_NextPart_000_0053_01D5CD32.9E40E690-- From nobody Tue Jan 21 08:44: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 21B971201A3 for ; Tue, 21 Jan 2020 08:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JIN0R4fg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Z9plwDHl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZisHvFpbVQt for ; Tue, 21 Jan 2020 08:43:58 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0EF8120884 for ; Tue, 21 Jan 2020 08:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14945; q=dns/txt; s=iport; t=1579625024; x=1580834624; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZjmRAZf+wJuB/cGuU/VaVKqZjY7XAjaz5p7TYO9dkTc=; b=JIN0R4fgiXKJJzk5oY0L1n0qb8UzKJgzxwv5vT5un5extLcXPMGgHs0R Z5NXGrQ+9pHbYURnMBxTDDS/IdIYfEGBL2aDTheZjligIO6Xy4da0ZguH jO1ja7jYug004aLI5oZpFoSSD/xiepQG4phC3rNeCLIjQOM7Nz6ZlDPFm Q=; IronPort-PHdr: =?us-ascii?q?9a23=3APabPIxb0hZ9JuOBLbxDRcNT/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavwdSU6Gc1EfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAQArKSde/4wNJK1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gSUvUAVsWCAECyqEEoNGA4sCgl+TLIRiglI?= =?us-ascii?q?DVAkBAQEMAQEtAgEBhEACF4F7JDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQE?= =?us-ascii?q?DEhEdAQE1AgEPAgEIEQMBAQEoAwICAjAUCQgCBAENBRkJgwQBgX1NAy4Boz4?= =?us-ascii?q?CgTmIYXWBMoJ/AQEFhQMYggwJgTiMFBqBQT+BOCCCTD6CZASCARaCWjKCLJB?= =?us-ascii?q?VhVwkiU+PMgqCOY0AiTEbmneOXpsGAgQCBAUCDgEBBYFpIiqBLnAVOyoBgkF?= =?us-ascii?q?QGA2IATiDO4pTdAIBgSaMZAEB?= X-IronPort-AV: E=Sophos;i="5.70,346,1574121600"; d="scan'208,217";a="420489743" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jan 2020 16:43:43 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 00LGhhdq016450 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Jan 2020 16:43:43 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 Jan 2020 10:43:43 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 Jan 2020 11:43:40 -0500 Received: from NAM04-SN1-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.1473.3 via Frontend Transport; Tue, 21 Jan 2020 11:43:40 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e6SLeEzvImNylFj6q7L/DZ7zkiro3//iLuEK0d66wCg6dT8FziLhmd2eGhmDT78VRawr5coa3V4Yd4TiprUVbL7tax0osmyvQdam8JRGrH56FJcLrCffbLatf1fvX8Ue+WOm43HlToXomMB+8bxrot4DSSNJlws0/5zz2NMl8r88/K7fcCAYfZT0AmwaX7J5QqB1EJGqO/FcwqRkFnL7Nvi7FyGHLIL6/2Az0itwsUlmcug1YlXenlj4F9izRXaCKl3AtNFhK1uwJwTummKFzI0yUSZhlJns7/h1lVhIDDGKKr3j1kF3Q8cxtMyOWcXyeT+d5HnV92CrxxxuHBKwbQ== 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=ZjmRAZf+wJuB/cGuU/VaVKqZjY7XAjaz5p7TYO9dkTc=; b=IAPvcs48GyvqqXSb6ydocTTTjovg+zzNNIxABSSfB3L/6iDlr/bRK+KGhR2FIH6lUwgqpSIzZ8J6bDnDRXJyKqeli4jpBAlvZEPkrGyVa4ACzAnd65JM+Jhru7XNSa8hA8izX42Aob3QMSrGqeYSAOruq+hyEYkdnxd+FmzTo8yZ/Q7Cj9NBjN/F7ma4xkUPamqa0S7pi7uBUm12FPMoKOE/vvPw/AAKAgIdDyplojJyL44WWgjy3lYgE/sas3fl5Y6uooetndcuYZEMBy2r8c6xonmlUZ3xU6ivClAOgshPQ6zBg6k+QK2FemVcHAoKxaSGhZlwUjhhigNj4mTBZg== 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=ZjmRAZf+wJuB/cGuU/VaVKqZjY7XAjaz5p7TYO9dkTc=; b=Z9plwDHlh2oe1Pg4DzepI/8f4+deiaq4cfH+RJqFiCsPfpch2JqlshHckhoX/tZARgk+dmrQ2xNQvRjI4fts/fCSvWBk64DLRSECUpX00YI0leuIFe6uMu/7n73oHzD0XiFZKQXTyHINsH67zh+M5cNRjr2zf83oez6cixLKmVA= Received: from DM5PR11MB1355.namprd11.prod.outlook.com (10.168.103.145) by DM5PR11MB1882.namprd11.prod.outlook.com (10.175.87.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.25; Tue, 21 Jan 2020 16:43:39 +0000 Received: from DM5PR11MB1355.namprd11.prod.outlook.com ([fe80::3d45:700d:3f44:243]) by DM5PR11MB1355.namprd11.prod.outlook.com ([fe80::3d45:700d:3f44:243%6]) with mapi id 15.20.2644.026; Tue, 21 Jan 2020 16:43:39 +0000 From: "Reshad Rahman (rrahman)" To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "Rob Wilton (rwilton)" , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt Thread-Index: AQHVxVsT75iyiSEfckqVICMZWQcw1KffZvCAgACw5YCAANxNAIADGDWAgAAJEoCABgLMgIAK/R8A Date: Tue, 21 Jan 2020 16:43:39 +0000 Message-ID: <58F397A3-9E37-4E61-BDEE-C0DAA61B6A3B@cisco.com> References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <0100016f83226d35-4c825571-7fe8-4074-8f6c-d9994e2ed37a-000000@email.amazonses.com> <0100016f901833d0-c822306b-9f2f-4c7b-9444-34742ec35a53-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:2840:1250:8db8:371:db62:f944] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 47803bf0-fb80-479e-27eb-08d79e911174 x-ms-traffictypediagnostic: DM5PR11MB1882: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(39860400002)(376002)(346002)(396003)(189003)(199004)(478600001)(2906002)(2616005)(33656002)(6486002)(36756003)(4326008)(9326002)(53546011)(6506007)(186003)(6512007)(5660300002)(81156014)(81166006)(91956017)(86362001)(76116006)(66476007)(66446008)(66556008)(64756008)(66946007)(8936002)(71200400001)(8676002)(110136005)(15650500001)(316002)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1882; H:DM5PR11MB1355.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BEjUBDvd9eZawWt/a3OVH/ABGwQlFjA7zNNeuN8SCg3DDiv+9y1cmDJAX7tCKnIrZgusj4tpXTQTZNSekGBSdQkHUpGJcxmjwNGeCQhRgfsOMizCXawcHCg77/jfND+V7ovRHCwg7Pw0lEfpB0Kb6Ld5+y2CO302QWmjH7Yzewml6c+xPNq+DuJGLUMslBWOMwBK+BSmTMrsvXZSjk2nFCJkPQ1zxC5iN/vYwJdw3XzniRrEDaVvSFmATlg3ALtKQbKaaQgce0ME2j1SogdkJPlgA4kRnGk29ZBPQKtaxxnqBLkn+h7egMAmVf5ZYa+z9Ud34/3EIPy6cbf9k+VdgpZ+Oe3EG/sw8BvozBA4dtKQxOb+mFnF5GwJyDNheaTksWTf8BSpsGsk6GNOJrcrgbk6rxcru+7VbEyV2t4R6f9+AbVMo7Ql51D89DHcfJT9 Content-Type: multipart/alternative; boundary="_000_58F397A39E374E61BDEEC0DAA61B6A3Bciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 47803bf0-fb80-479e-27eb-08d79e911174 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 16:43:39.5026 (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: g4xBmkoUyRbVGeeXxo4zPftILM7wT3fBlsZe9DveuN6NCMhNF/UXJNLx7V2pZNCH/jGU9bpo4jBXH1lANgX8bQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1882 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 16:44:03 -0000 --_000_58F397A39E374E61BDEEC0DAA61B6A3Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClJlZ2FyZGluZyB0aGUgY2hhbmdlIGJlbG93ICh3aGljaCB3YXMgYWRkZWQgaW4gcmV2 LTEwKSB0byBtYXRjaCBieSBvcmRlciwgd2FzIHRoaXMgZG9uZSBqdXN0IHRvIG1ha2UgbGlmZSBl YXNpZXIgZm9yIHRoZSBjbGllbnQgKHRoZSBwdWJsaXNoZXIgaXMgZGVjaWRpbmcgd2hhdOKAmXMg dGhlIGJlc3QgbWF0Y2gpIG9yIGlzIHRoZXJlIGFub3RoZXIgbW90aXZhdGlvbj8gSSB0aGluayB0 aGlzIGlzIGEgZ29vZCBjaGFuZ2UsIGJ1dCBjdXJpb3VzIGFzIHRvIHRoZSByZWFzb24uDQoNClJl Z2FyZHMsDQpSZXNoYWQuDQoNCkZyb206IG5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9y Zz4gb24gYmVoYWxmIG9mIEJhbMOhenMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWw9NDBlcmljc3Nv bi5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBUdWVzZGF5LCBKYW51YXJ5IDE0LCAyMDIwIGF0 IDY6NTUgQU0NClRvOiAiUm9iIFdpbHRvbiAocndpbHRvbikiIDxyd2lsdG9uQGNpc2NvLmNvbT4s IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4NCkNjOiAibmV0Y29uZkBpZXRmLm9y ZyIgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldGNvbmZdIE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0 aWVzLTA5LnR4dA0KDQpPSy4gRm9yIGJvdGguDQpSZWdhcmRzIEJhbGF6cw0KDQpGcm9tOiBSb2Ig V2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+DQpTZW50OiAyMDIwLiBqYW51w6Fy IDEwLiwgcMOpbnRlayAxNzowOA0KVG86IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5l dD47IEJhbMOhenMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPg0KQ2M6IG5l dGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbbmV0Y29uZl0gTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIC0gZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMDku dHh0DQoNCkhpIEtlbnQsIEJhbGF6cywNCg0KWWVzLCBJIHRoaW5rIHRoYXQgdGhpcyB3b3VsZCB3 b3JrLCBidXQgbWlnaHQgYWxzbyBuZWVkIHRvIGNoYW5nZSB0aGUgcnVsZSBmcm9tIG1hdGNoaW5n IHRoZSBjYXBhYmlsaXRpZXMgZnJvbSB0aGUgbG9uZ2VzdCBub2RlIHBhdGgsIHRvIHRoZSBvcmRl ciB0aGF0IHRoZSBlbnRyaWVzIGFyZSBpbiB0aGUgbGlzdC4gIEUuZy4gdGhlIGNhcGFiaWxpdGll cyBhcmUgZGVjaWRlZCBieSB0aGUgZmlyc3QgZW50cnkgaW4gdGhlIGxpc3QgdGhhdCBtYXRjaGVz IHRoZSBnaXZlbiBwYXRoLiAgVGhlIGV4aXN0aW5nIGxvbmdlc3Qgbm9kZSBwYXRoIGJlaGF2aW91 ciBjYW4gZWZmZWN0aXZlbHkgYmUgaW1wbGVtZW50ZWQgYnkgb3JkZXJpbmcgdGhlIG1vcmUgc3Bl Y2lmaWMgbm9kZSBwYXRocyBiZWZvcmUgdGhlIGxlc3Mgc3BlY2lmaWMgbm9kZSBwYXRocy4NCg0K V291bGQgdGhhdCBiZSBhY2NlcHRhYmxlPw0KDQpJIHdvdWxkIGFsc28gc3VnZ2VzdCBnaXZpbmcg dGhlIGNob2ljZSBhbmQgdGhlIGxlYWYgYSBzZXBhcmF0ZSBuYW1lIGJlbG93Lg0KDQpUaGFua3Ms DQpSb2INCg0KDQpGcm9tOiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ8bWFpbHRv OmtlbnQraWV0ZkB3YXRzZW4ubmV0Pj4NClNlbnQ6IDEwIEphbnVhcnkgMjAyMCAxNTozNQ0KVG86 IEJhbMOhenMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPG1haWx0bzpiYWxh enMubGVuZ3llbEBlcmljc3Nvbi5jb20+Pg0KQ2M6IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2ls dG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+PjsgbmV0Y29uZkBpZXRmLm9y ZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBh YmlsaXRpZXMtMDkudHh0DQoNCg0KSGkgQmFsYXpzLA0KDQoNCg0KDQpXb3VsZCB0aGUgZm9sbG93 aW5nIGJlIGFjY2VwdGFibGU/DQpPTEQ6DQogICAgIGxpc3QgcGVyLW5vZGUtY2FwYWJpbGl0aWVz IHsNCiAgICAgICBrZXkgIm5vZGUtc2VsZWN0b3IiOw0KICAgICAgIGxlYWYgbm9kZS1zZWxlY3Rv ciB7DQogICAgICAgICB0eXBlIG5hY206bm9kZS1pbnN0YW5jZS1pZGVudGlmaWVyOw0KTkVXOg0K ICAgICBsaXN0IHBlci1ub2RlLWNhcGFiaWxpdGllcyB7DQogICAgICAgY2hvaWNlIG5vZGUtc2Vs ZWN0b3Igew0KICAgICAgICAgICAgIGxlYWYgbm9kZS1zZWxlY3RvciB7ICAgdHlwZSBuYWNtOm5v ZGUtaW5zdGFuY2UtaWRlbnRpZmllcjsgIH0NCiAgICAgfQ0KDQpMYXRlciB5b3UgY2FuIGF1Z21l bnQgaW4gYW4gWHBhdGggZmlsdGVyIG9yIGEgc3RyaW5nIHdpdGggJyonIGFuZCAnPycgd2lsZGNh cmRzIG9yIHdoYXRldmVyIHlvdSB3YW50Lg0KKFRoZSBsaXN0IGRvZXMgbm90IG5lZWQgYSBrZXkg YXMgaXQgaXMgY29uZmlnPWZhbHNlKQ0KDQoNClllcywgdGhpcyBpcyBpbmxpbmUgd2l0aCB3aGF0 IEkgaGFkIGluIG1pbmQgYnV0LCBzaW5jZSB0aGlzIHdhcyBteSBzdWdnZXN0aW9uLCBJIHdhcyBo b3BpbmcgdGhhdCBSb2Igb3Igb3RoZXJzIHdvdWxkIHJlcGx5Lg0KDQpLZW50IC8vIGNvbnRyaWJ1 dG9yDQoNCg0K --_000_58F397A39E374E61BDEEC0DAA61B6A3Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <956ABA551EB1204985BDAD49ECE05600@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS10YWIt c3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUy MQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdh cmRpbmcgdGhlIGNoYW5nZSBiZWxvdyAod2hpY2ggd2FzIGFkZGVkIGluIHJldi0xMCkgdG8gbWF0 Y2ggYnkgb3JkZXIsIHdhcyB0aGlzIGRvbmUganVzdCB0byBtYWtlIGxpZmUgZWFzaWVyIGZvciB0 aGUgY2xpZW50ICh0aGUgcHVibGlzaGVyIGlzIGRlY2lkaW5nIHdoYXTigJlzIHRoZSBiZXN0IG1h dGNoKSBvciBpcyB0aGVyZSBhbm90aGVyIG1vdGl2YXRpb24/IEkgdGhpbmsNCiB0aGlzIGlzIGEg Z29vZCBjaGFuZ2UsIGJ1dCBjdXJpb3VzIGFzIHRvIHRoZSByZWFzb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5SZXNoYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5uZXRjb25mICZs dDtuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBCYWzDoXpzIExlbmd5 ZWwgJmx0O2JhbGF6cy5sZW5neWVsPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnJmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKYW51YXJ5IDE0LCAyMDIwIGF0IDY6NTUgQU08YnI+ DQo8Yj5UbzogPC9iPiZxdW90O1JvYiBXaWx0b24gKHJ3aWx0b24pJnF1b3Q7ICZsdDtyd2lsdG9u QGNpc2NvLmNvbSZndDssIEtlbnQgV2F0c2VuICZsdDtrZW50JiM0MztpZXRmQHdhdHNlbi5uZXQm Z3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtuZXRjb25mQGlldGYub3JnJnF1b3Q7ICZsdDtuZXRj b25mQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW25ldGNvbmZdIE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2Fw YWJpbGl0aWVzLTA5LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PSy4gRm9yIGJvdGguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5SZWdhcmRzIEJhbGF6czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFJvYiBXaWx0b24gKHJ3aWx0b24p ICZsdDtyd2lsdG9uQGNpc2NvLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IDIwMjAuIGphbnXD oXIgMTAuLCBww6ludGVrIDE3OjA4PGJyPg0KPGI+VG86PC9iPiBLZW50IFdhdHNlbiAmbHQ7a2Vu dCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0OzsgQmFsw6F6cyBMZW5neWVsICZsdDtiYWxhenMubGVu Z3llbEBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBuZXRjb25mQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbbmV0Y29uZl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IC0gZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMDkudHh0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ SGkgS2VudCwgQmFsYXpzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+WWVzLCBJIHRoaW5rIHRoYXQgdGhp cyB3b3VsZCB3b3JrLCBidXQgbWlnaHQgYWxzbyBuZWVkIHRvIGNoYW5nZSB0aGUgcnVsZSBmcm9t IG1hdGNoaW5nIHRoZSBjYXBhYmlsaXRpZXMgZnJvbSB0aGUgbG9uZ2VzdCBub2RlIHBhdGgsIHRv IHRoZSBvcmRlciB0aGF0IHRoZSBlbnRyaWVzIGFyZSBpbiB0aGUgbGlzdC4mbmJzcDsgRS5nLiB0 aGUgY2FwYWJpbGl0aWVzIGFyZSBkZWNpZGVkIGJ5DQogdGhlIGZpcnN0IGVudHJ5IGluIHRoZSBs aXN0IHRoYXQgbWF0Y2hlcyB0aGUgZ2l2ZW4gcGF0aC4mbmJzcDsgVGhlIGV4aXN0aW5nIGxvbmdl c3Qgbm9kZSBwYXRoIGJlaGF2aW91ciBjYW4gZWZmZWN0aXZlbHkgYmUgaW1wbGVtZW50ZWQgYnkg b3JkZXJpbmcgdGhlIG1vcmUgc3BlY2lmaWMgbm9kZSBwYXRocyBiZWZvcmUgdGhlIGxlc3Mgc3Bl Y2lmaWMgbm9kZSBwYXRocy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPldvdWxkIHRoYXQgYmUgYWNjZXB0 YWJsZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkkgd291bGQgYWxzbyBzdWdnZXN0IGdpdmluZyB0aGUg Y2hvaWNlIGFuZCB0aGUgbGVhZiBhIHNlcGFyYXRlIG5hbWUgYmVsb3cuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPlJvYjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gS2VudCBX YXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprZW50JiM0MztpZXRmQHdhdHNlbi5uZXQiPmtlbnQm IzQzO2lldGZAd2F0c2VuLm5ldDwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTAgSmFudWFy eSAyMDIwIDE1OjM1PGJyPg0KPGI+VG86PC9iPiBCYWzDoXpzIExlbmd5ZWwgJmx0OzxhIGhyZWY9 Im1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20iPmJhbGF6cy5sZW5neWVsQGVyaWNz c29uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4m Z3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0gTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIC0gZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMDku dHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkhpIEJh bGF6cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPldvdWxkIHRoZSBmb2xsb3dpbmcgYmUgYWNjZXB0YWJsZT88L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5PTEQ6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7bGlzdCBwZXItbm9kZS1jYXBhYmlsaXRpZXMgezxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2tleSAmcXVvdDtub2RlLXNlbGVjdG9yJnF1b3Q7 Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2xlYWYgbm9k ZS1zZWxlY3RvciB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7dHlwZSBuYWNtOm5vZGUtaW5zdGFuY2UtaWRlbnRpZmllcjs8YnI+DQpO RVc6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bGlzdCBwZXItbm9kZS1jYXBh YmlsaXRpZXMgezxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2Nob2ljZSBub2RlLXNlbGVjdG9yIHs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+bGVhZiBub2RlLXNlbGVjdG9yIHsgJm5ic3A7Jm5ic3A7 dHlwZSBuYWNtOm5vZGUtaW5zdGFuY2UtaWRlbnRpZmllcjsgJm5ic3A7fTxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO308YnI+DQo8YnI+DQpMYXRlciB5b3UgY2FuIGF1Z21lbnQg aW4gYW4gWHBhdGggZmlsdGVyIG9yIGEgc3RyaW5nIHdpdGggJyonIGFuZCAnPycgd2lsZGNhcmRz IG9yIHdoYXRldmVyIHlvdSB3YW50Ljxicj4NCihUaGUgbGlzdCBkb2VzIG5vdCBuZWVkIGEga2V5 IGFzIGl0IGlzIGNvbmZpZz1mYWxzZSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlllcywg dGhpcyBpcyBpbmxpbmUgd2l0aCB3aGF0IEkgaGFkIGluIG1pbmQgYnV0LCBzaW5jZSB0aGlzIHdh cyBteSBzdWdnZXN0aW9uLCBJIHdhcyBob3BpbmcgdGhhdCBSb2Igb3Igb3RoZXJzIHdvdWxkIHJl cGx5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+S2Vu dCAvLyBjb250cmlidXRvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_58F397A39E374E61BDEEC0DAA61B6A3Bciscocom_-- From nobody Wed Jan 22 01:37: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 7940612003E for ; Wed, 22 Jan 2020 01:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ2LubNwKLsY for ; Wed, 22 Jan 2020 01:37:40 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60084.outbound.protection.outlook.com [40.107.6.84]) (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 D5809120013 for ; Wed, 22 Jan 2020 01:37:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=akMauL83osYhEIa3SHRKChumD3wrmt/+JvK6wxm40ujViosTSwhxthIuMbCS9k5zl+Rh7CrbXgiTpvnTX/A+pkJxi92UxMiy7OFpPgNZYBdqZyeYIWF98hB0Qy5N1FeuRyWFj3naeNv+c46QOurf5JYiQxkktiU5TwIWTF0D73lJzZuILd706p1K3W+awIbBwKi7Px43/aqSoIYX2YSQAnuU8r5tIiATaqoY3yiJ+t12nFnhYbDVrO+hCdqfzUOfFVkFwlUOeCroqaZcHL+vdzre7ZlMrBu/GSQctIgdm9OhYJjE877dHmGmviN6fcMIiZuuUiy+cAYMW5SVLzg+gQ== 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=smch5vsGdVCDc1weJCLA6thPTC4tvf+lUSuioxPHaYA=; b=MVP6G7m/cluLkaOZ/lcNgigMRQha84ESY+O3lNDrXRIW7VJPvNnd8Zs2GKcto9dIlId6Ii4JiETQ6lhC88QeKqCIe3rmB/NlYv0oe8OShw6cYkGTyW0XTHc4XshwZB0dvS1n9OZeIGeokvfFhZ5NEGhU7dSNvv6KBZ5XvvplJmubIil4u+Cd9/SUXb2ulyfLcOjUjffHAMYyyaiLKfJI2zXurXEymCpGkBnSMrlkJHzDu5lRIwnn14G9NmruL7O23+Ii2y5PbhY3z3N9YRpE1+PfUeeKFIdNf3jwwqo6dWpXjVLiyfzl3DZGIFcOVcZ+OJQgqIkuRg6nmX/dWGZm1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=smch5vsGdVCDc1weJCLA6thPTC4tvf+lUSuioxPHaYA=; b=VLQqbzavowfmDWNVfm8X6sHPfpoZ3DuMEzUQkm0VeQqPz0U0mgI4ZvTFjxWmHhy3cYWWxNTxh6nJ+2X/ggXGQr0yXin98TwUVrvxQwvb74tn7NKyqODxRtewKWbn6N54MfKZlVUGRugZ9KrOw0Mfl+2F24a6ESixCcAAMNXGtgU= Received: from AM0PR07MB5187.eurprd07.prod.outlook.com (20.178.20.74) by AM0PR07MB5521.eurprd07.prod.outlook.com (20.178.23.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.14; Wed, 22 Jan 2020 09:37:37 +0000 Received: from AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::1976:7522:8041:5d93]) by AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::1976:7522:8041:5d93%7]) with mapi id 15.20.2665.017; Wed, 22 Jan 2020 09:37:37 +0000 From: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: update to ssh-server draft Thread-Index: AdWhO0IZE1dC8qjAQkuUng0JdaMGKwAESXOACf0TZJAAemCygAF1yiUA Date: Wed, 22 Jan 2020 09:37:37 +0000 Message-ID: References: <0100016e93cdb1a3-6544deca-acbe-4c7c-a5eb-5efdbd8fe2c1-000000@email.amazonses.com> <0100016fa62df2a2-005fc9be-4f02-4ba8-b731-1357af75e116-000000@email.amazonses.com> In-Reply-To: <0100016fa62df2a2-005fc9be-4f02-4ba8-b731-1357af75e116-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b08b439f-1d0e-4a44-3359-08d79f1eb7c4 x-ms-traffictypediagnostic: AM0PR07MB5521: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(376002)(396003)(346002)(39860400002)(199004)(189003)(15650500001)(7696005)(4001150100001)(3480700007)(478600001)(85182001)(66946007)(966005)(76116006)(66446008)(66556008)(64756008)(66476007)(26005)(9326002)(53546011)(186003)(8676002)(6506007)(86362001)(4326008)(81156014)(81166006)(316002)(8936002)(66574012)(9686003)(52536014)(71200400001)(5660300002)(33656002)(2906002)(85202003)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5521; H:AM0PR07MB5187.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2QGIOe45nIDJ3BkP48b/S/DhOHoOb15dUG4FgaHNsW6GqrYjwNEgaorRBfU/ONdhpcIfYIwC/S9FYMUg+I0APqVvEdFQCH8Uk4+SnCq5CkdLQaImMlv+QUt6f4k6qfhJrsYnihCkk7KYMzAFvDVOjTTQSvmIdX1wBkIC22J8b4WFCcVs3g5ulaEpTOPOK8umz7taPeQPRGYTvMln5xlcwbcM45w3cEg9EnvpTcprILtaZ31Bt90rVmlTGYRsVyxjlRn3AplAM/5M5TBf2vampTGZX2zcCw1LL/bw6ZV0HgbQZP+kf6s9914L9l0bCrZ0SE8HPxC0cHc/m/lNmZn9tshJsBK0mDW9BjXI8O1sgfx6xXEgR7Pn7D5wHZWBXQ/GFj2rTK2enX1hVmEN0DEmCvHhhUeezqNd0CUxCdgl/WenjF4N6rfdlM/iCX9zVfr06NwwWWmaNKGvwuYomAB+7Ny3JUwtaFSrnmdCDPJAnAI= x-ms-exchange-antispam-messagedata: zgW83PeFoETcMyRtv0zS1rWFfHYj3PPORkRvcRBtIwrB/9yZEYLr6s835lEn0++BDfoQ/d7HV3stMS49zTkv2zn+PlrrT36AbtVa1GujLdWxj+zzdGUdGToYQGvfTjd3p0ZhigBj83zuUl7MUIVwDw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB51870877DB698D0A14DC0A03830C0AM0PR07MB5187eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b08b439f-1d0e-4a44-3359-08d79f1eb7c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 09:37:37.5989 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZeVY3db6cJNhtt/oQCAY3+Ei3b4UI2n1ftolywrG5iobloYFwXkT/EaG64+9gr0Ym4HHMVXnlVO2q4kYTaInvdXDmqqVl6wqEDVbMovk2Bc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5521 Archived-At: Subject: Re: [netconf] update to ssh-server draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 09:37:43 -0000 --_000_AM0PR07MB51870877DB698D0A14DC0A03830C0AM0PR07MB5187eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KU2VlIGJlbG93Lg0KQnIsDQpCYWxhenMNCg0KRnJvbTogS2VudCBXYXRzZW4g PGtlbnQraWV0ZkB3YXRzZW4ubmV0Pg0KU2VudDogVHVlc2RheSwgSmFudWFyeSAxNCwgMjAyMCAx MTozMCBQTQ0KVG86IEJhbMOhenMgS292w6FjcyA8YmFsYXpzLmtvdmFjc0Blcmljc3Nvbi5jb20+ DQpDYzogbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IHVwZGF0ZSB0byBzc2gtc2VydmVy IGRyYWZ0DQoNCg0KSGkgQmFsYXpzLA0KDQpJdCBpcyBnb29kIHRvIHNlZSB0aGF0IHlvdSdyZSBk aWdnaW5nIGludG8gdGhlIFNTSCBtb2R1bGVzLCBhcyB0aGV5IChhbmQgdGhlIE5FVENPTkYgbW9k dWxlcykgYXJlIHRoZSBvbmx5IG1vZHVsZXMgdGhhdCBJIGRvbid0IGhhdmUgcnVubmluZyBjb2Rl IGZvci4uLg0KDQpSZWdhcmRpbmcgeW91ciBxdWVzdGlvbnM6DQoNCg0KDQpJIGhhdmUgc29tZSBk aWZmaWN1bHRpZXMgaW4gdW5kZXJzdGFuZGluZyB0aGUgaW50ZW50IG9mIHRoZSBjaGFuZ2VzIHlv dSBkZXNjcmliZS4NCg0KSW4gaWV0Zi1zc2gtc2VydmVyQDIwMTktMTEtMjA6DQoNCiAgICAgICB8 ICArLS0gc3VwcG9ydGVkLWF1dGhlbnRpY2F0aW9uLW1ldGhvZHMNCg0KICAgICAgIHwgIHwgICst LSBwdWJsaWNrZXk/ICAgZW1wdHkNCg0KICAgICAgIHwgIHwgICstLSBwYXNzc3dvcmQ/ICAgZW1w dHkNCg0KICAgICAgIHwgIHwgICstLSBob3N0YmFzZWQ/ICAgZW1wdHkNCg0KICAgICAgIHwgIHwg ICstLSBub25lPyAgICAgICAgZW1wdHkNCg0KICAgICAgIHwgIHwgICstLSBvdGhlciogICAgICAg c3RyaW5nDQoNCg0KV2h5IGRvIHdlIGJvdGhlciB3aXRoIHRoZSDigJhub25l4oCZIGFuZCB0aGUg 4oCYb3RoZXLigJkgbWV0aG9kcz8g4oCYbm9uZeKAmSBpcyBub3QgcmVjb21tZW5kZWQsIGFuZCDi gJhvdGhlcuKAmSBpcyBqdXN0IHNpbXBseSB1bmtub3duLg0KDQpSRSAibm9uZSI6IHRoaXMgaXMg ZGVmaW5lZCBiZWNhdXNlIGl0IGlzIGluIFJGQyA0MjUyLiAgWWVzLCB0aGVyZSdzIGxvdHMgb2Yg Z3VpZGFuY2UgaW4gdGhhdCBSRkMgcmVnYXJkaW5nIHRoZSB1c2Ugb2YgIm5vbmUiLCBidXQgaXQg aXMgKnN1cHBvcnRlZCouLi4gICBJIHRoaW5rIHdoYXQgaXMgbmVlZGVkIGhlcmUgaXMgYSBgZmVh dHVyZWAgc3RhdGVtZW50IGVuYWJsaW5nIHRoZSBzZXJ2ZXIgdG8gZXhwcmVzcyBpZiAibm9uZSIg aXMgc3VwcG9ydGVkIG9mIG5vdCAtIGFncmVlZD8NCg0KQmFsYXpzPiBZZXMsIEkgYWdyZWUuDQoN ClJFICJvdGhlciI6IEkgZG9uJ3QgcmVtZW1iZXIgaG93ICJvdGhlciIgY2FtZSB0byBiZSBsaXN0 ZWQsIGJ1dCBpdCBkb2Vzbid0IGFwcGVhciBpbiBSRkMgNDI1MiBhbmQgdGhlcmVmb3JlIHNob3Vs ZCBiZSByZW1vdmVkICAodXBkYXRlZCBpbiBteSBsb2NhbCBjb3B5KS4NCg0KQmFsYXpzPiBZZXMs IHBsZWFzZSByZW1vdmUg4oCYb3RoZXLigJkuDQoNCuKAmHBhc3N3b3Jk4oCZIGFuZCDigJhwdWJs aWNrZXnigJkgYXV0aGVudGljYXRpb24gY29uZmlndXJhdGlvbiBpcyBkZXNjcmliZWQgYnkgUkZD NzMxNy4gSSB3b3VsZCB0aGVuIGV4cGVjdCByZXVzYWJsZSAobG9jYWwpIGRlZmluaXRpb25zIHRv IGJlIGNyZWF0ZWQgaW4gUkZDNzMxNywgYW5kIHVudGlsIHRoZW4gbWF5YmUgd2Ugc2hvdWxkIG5v dCBib3RoZXIgd2l0aCBjb3B5aW5nIHRoYXQgdG8gdGhlIHNzaC1zZXJ2ZXIgbW9kZWwuIERvIHlv dSByZWFsbHkgZm9yZXNlZSB0aGF0IHRoZSBzeXN0ZW0gYXV0aGVudGljYXRpb24gbW9kZWwgY2Fu bm90IGJlIHVzZWQgZm9yIFNTSD8NCg0KU3lzdGVtLWxldmVsIGFuZCBORVRDT05GLWxldmVsIHVz ZXJzIG1heSBub3QgYmUgdGhlIHNhbWUuICBJIGtub3cgc29tZSBzeXN0ZW0gY28tbWluZ2xlIHRo ZSB0d28gd2hpbGUgb3RoZXJzIGRvbid0Lg0KDQpCYWxhenM+IE9rLCBidXQgdGhlbiBJIGFzc3Vt ZSB0aGUgbW9kZWwvZm9ybWF0IG9mIGNvbmZpZ3VyYXRpb24gc2hvdWxkIGJlIHRoZSBzYW1lIGFz IGluIFJGQzczMTcsIHJpZ2h0Pw0KDQpCVFcsIFJGQyA0MjUyIHNheXMgdGhhdCAicGFzc3dvcmQi IFNIT1VMRCBiZSByZXF1aXJlZCwgc28gYSBgZmVhdHVyZWAgc3RhdGVtZW50IHNlZW0gd2FycmFu dGVkLiAgUkZDIDQyNTIgc2F5cyB0aGF0ICJwdWJsaWNrZXkiIGlzIFJFUVVJUkVELCBzbyAqbm8q IGBmZWF0dXJlYCBzdGF0ZW1lbnQgaXMgbmVlZGVkIGZvciBpdC4NCg0KQmFsYXpzPiBPay4NCg0K DQpJbXBsZW1lbnRpbmcg4oCYaG9zdGJhc2Vk4oCZIGNvdWxkIG1heWJlIG1ha2Ugc2Vuc2UuIEkg YXNzdW1lIHRoYXQgcmVxdWlyZXMgdGhlIHVzZSBvZiDigJhsb2NhbC1vci10cnVzdHN0b3JlLWhv c3Qta2V5cy1ncm91cGluZ+KAmCB1bmRlciBzb21lIHVzZXJuYW1lIHNvIHRoYXQgdGhlIG1hcHBp bmcgYmV0d2VlbiBrZXkgYW5kIHVzZXJzIGNhbiBiZSBkb25lIChhcyB5b3Ugc3VnZ2VzdGVkIGJl Zm9yZSkuIFRoZSB1c2VycyB3aGljaCBhcmUgZGVmaW5lZCBoZXJlIGNvdWxkIGJlIGF1dGhlbnRp Y2F0ZWQgd2l0aCBob3N0a2V5cyBvbiB0b3Agb2YgdGhlIFJGQzczMTcgdXNlcnMgKHdoaWNoIGNh biBsb2dpbiB3aXRoIHB3ZCBvciBwdWJrZXkpLg0KDQpSRkMgNDI1MiBzYXlzIHRoYXQgdGhpcyBt ZXRob2QgbmFtZSBpcyBPUFRJT05BTCwgYW5kIHRoZXJlZm9yZSBhIGBmZWF0dXJlYCBzdGF0ZW1l bnQgc2VlbXMgd2FycmFudGVkIGhlcmUgYXMgd2VsbC4NCg0KWWVzLCBpdCBzZWVtcyB0aGF0IOKA mGxvY2FsLW9yLXRydXN0c3RvcmUtaG9zdC1rZXlzLWdyb3VwaW5n4oCYIHdvdWxkIGJlIGluIHBs YXkgaGVyZS4NCg0KQmFsYXpzPiBJIGFncmVlIHRvIGJvdGguDQoNCkkgZG9uJ3QgdGhpbmsgaXQg bmVlZHMgdG8gYmUgdW5kZXIgYSB1c2VybmFtZSwgYXMgdGhlIFNTSC1jbGllbnQgc3RpbGwgZXhw bGljaXRseSBzZW5kcyBhIHVzZXJuYW1lIChzYW1lIGFzIHdpdGggIm5vbmUiKSBwZXIgUkZDIDQ1 NTIgU2VjdGlvbiA1Lg0KDQpCYWxhenM+IFlvdSBoYXZlIHRvIGhhdmUgYSB3aGl0ZWxpc3Qgb2Yg dXNlcnMgb24gdGhlIHNlcnZlciBzaWRlIHdoZXJlIHlvdSBhbGxvdyBob3N0YmFzZWQgYXV0aGVu dGljYXRpb24uIFRoZSByZXN0IG9mIHRoZSB1c2VycyBzaG91bGQgbm90IGJlIGFibGUgdG8gbG9n aW4gd2l0aCBhIGhvc3Qga2V5LiBXZSBhbHNvIG5lZWQgdG8gc29tZWhvdyBtYWtlIGl0IHBvc3Np YmxlIHRvIHN0YWNrIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgLT4gYXNrIG1vcmUgdGhhbiBvbmUg Zm9yIGEgbG9naW4gdG8gc3VjY2VlZCBvciB3aGF0ZXZlciBvdGhlciBwb2xpY2llcyBhcmUgc3Vw cG9ydGVkIGluIGdlbmVyYWwgYnkgYW4gU1NIIHNlcnZlci4NCg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzQyNTIjc2VjdGlvbi00DQpodHRwczovL21hbi5vcGVuYnNkLm9yZy9zc2hk X2NvbmZpZyNBdXRoZW50aWNhdGlvbk1ldGhvZHMNCg0KDQpJIGFsc28gZG9u4oCZdCB1bmRlcnN0 YW5kIHRoZSBwb2ludCBpbiBoYXZpbmcgdGhlIGZlYXR1cmUg4oCYY2xpZW50LWF1dGgtY29uZmln LXN1cHBvcnRlZOKAmS4gVGhlIFRMUyBncm91cGluZ3MgZG9u4oCZdCBoYXZlIHRoaXMsIGFuZCBh bHNvIHdoZXJlIHdvdWxkIHRoZSBjb25maWd1cmF0aW9uIG9mIGNhLWNlcnRzLCBjbGllbnQtY2Vy dHMsIGV0Yy4gYmUgaWYgbm90IGluIHRoaXMgc2VydmVyIGdyb3VwaW5nPw0KDQpQbGVhc2UgY2hl Y2sgYWdhaW4sIHRoZSB0bHMtc2VydmVyLWdyb3VwaW5nIGRvZXMgaGF2ZSAnY2xpZW50LWF1dGgt Y29uZmlnLXN1cHBvcnRlZCcgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW5ldGNvbmYtdGxzLWNsaWVudC1zZXJ2ZXItMTcjc2VjdGlvbi00KS4NCg0KQW5zd2VyaW5nIHlv dXIgbGFzdCBxdWVzdGlvbiwgbm90ZSB0aGF0IFRMUy1sZXZlbCBjbGllbnQgYXV0aCBpcyBvcHRp b25hbCwgYXMgY2xpZW50IGF1dGggTUFZIG9jY3VyIGF0IGEgcHJvdG9jb2wtbGF5ZXIgYWJvdmUg VExTLiAgVGhhdCBzYWlkLCBJJ2xsIGdyYW50IHlvdSB0aGF0IHRoaXMgZmVhdHVyZSBtYXkgbm90 IGJlIGlkZWFsIGFzIGluc3RlYWQsIHBlcmhhcHMsIHRoZSBzZXJ2ZXIgY291bGQgaW5zdGVhZCBy ZWx5IG9uICppZiogYW55IG9mIHRoZSBkZXNjZW5kYW50cyB3ZXJlIGNvbmZpZ3VyZWQuDQoNCkkn bSBsZXNzIHN1cmUgYWJvdXQgU1NILCBidXQgSSBkb24ndCBiZWxpZXZlIHRoYXQgY2xpZW50IGF1 dGhlbnRpY2F0aW9uIGNhbiBldmVyIG9jY3VyIGF0IGEgaGlnaGVyLWxldmVsIHByb3RvY29sIGxh eWVyLiAgVGhhdCBiZWluZyB0aGUgY2FzZSwgdGhlcmUncyBsaWtlbHkgYSBnb29kIGF1Z21lbnQg dG8gcmVtb3ZpbmcgdGhlICJjbGllbnQtYXV0aC1jb25maWctc3VwcG9ydGVkIiBmZWF0dXJlIGlu IGlldGYtc3NoLXNlcnZlci4NCg0KQmFsYXpzPiBPaywgZm9yIFRMUyB5b3UgYXJlIHJpZ2h0LCBJ IGFjY2lkZW50YWxseSBtaXNzZWQgdGhhdC4gSSB0aGluayBpbiBUTFMgaXQgaXMgb2sgYXMgZmVh dHVyZSBmb3IgdGhlIHJlYXNvbnMgeW91IGhhZC4gQnV0IGluIFNTSCBjYXNlLCBJ4oCZdmUgb25s eSBzZWVuIFNTSCBkb2luZyB0aGUgdXNlciBhdXRoZW50aWNhdGlvbiBhcyBvZiBSRkMgNDI1Miwg YXMgeW91IHNhaWQuIFNvIEnigJlkIHZvdGUgZm9yIG5vdCBoYXZpbmcgYSBmZWF0dXJlIGZvciBT U0ggY2xpZW50IGF1dGggYW5kIHRoYXQgc29tZXRoaW5nIG11c3QgYmUgY29uZmlndXJlZCB0aGVy ZS4NCg0KQmFsYXpzPiBJ4oCZbSBhbHNvIHRoaW5raW5nIGlmIGNlcnRpZmljYXRlIGJhc2VkIGF1 dGhlbnRpY2F0aW9uIHNob3VsZCBiZSB1bmRlciB0aGUgdXNlciB3aGl0ZWxpc3QsIGJ1dCBJ4oCZ bSBub3QgdmVyeSBmYW1pbGlhciB3aXRoIFJGQzYxODcuDQoNCg0KS2VudCAvLyBjb250cmlidXRv cg0KDQoNCg== --_000_AM0PR07MB51870877DB698D0A14DC0A03830C0AM0PR07MB5187eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEtlbnQsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlNlZSBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJyLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFsYXpzPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PGI+RnJvbTo8L2I+IEtlbnQgV2F0c2VuICZsdDtrZW50JiM0Mztp ZXRmQHdhdHNlbi5uZXQmZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAx NCwgMjAyMCAxMTozMCBQTTxicj4NCjxiPlRvOjwvYj4gQmFsw6F6cyBLb3bDoWNzICZsdDtiYWxh enMua292YWNzQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG5ldGNvbmZAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IHVwZGF0ZSB0byBzc2gtc2VydmVyIGRyYWZ0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5IaSBCYWxh enMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SXQgaXMg Z29vZCB0byBzZWUgdGhhdCB5b3UncmUgZGlnZ2luZyBpbnRvIHRoZSBTU0ggbW9kdWxlcywgYXMg dGhleSAoYW5kIHRoZSBORVRDT05GIG1vZHVsZXMpIGFyZSB0aGUgb25seSBtb2R1bGVzIHRoYXQg SSBkb24ndCBoYXZlIHJ1bm5pbmcgY29kZSBmb3IuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5SZWdhcmRpbmcgeW91ciBxdWVzdGlvbnM6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+SSBoYXZlIHNvbWUgZGlmZmljdWx0aWVzIGluIHVuZGVyc3RhbmRpbmcgdGhlIGlu dGVudCBvZiB0aGUgY2hhbmdlcyB5b3UgZGVzY3JpYmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5J biBpZXRmLXNzaC1zZXJ2ZXJAMjAxOS0xMS0yMDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDt8Jm5ic3A7ICYjNDM7LS0gc3VwcG9ydGVkLWF1dGhlbnRpY2F0aW9uLW1ldGhvZHM8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLSBwdWJs aWNrZXk/Jm5ic3A7Jm5ic3A7IGVtcHR5PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjEuMGluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyB8Jm5ic3A7ICYjNDM7LS0gcGFzc3N3b3JkPyZuYnNwOyZuYnNwOyBlbXB0eTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tIGhvc3RiYXNlZD8m bmJzcDsmbmJzcDsgZW1wdHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MS4waW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwm bmJzcDsgJiM0MzstLSBub25lPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBlbXB0eTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBp biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAm IzQzOy0tIG90aGVyKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdHJpbmc8 bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5XaHkgZG8gd2UgYm90aGVyIHdpdGggdGhlIOKAmG5vbmXigJkgYW5kIHRoZSDi gJhvdGhlcuKAmSBtZXRob2RzPyDigJhub25l4oCZIGlzIG5vdCByZWNvbW1lbmRlZCwgYW5kIOKA mG90aGVy4oCZIGlzIGp1c3Qgc2ltcGx5IHVua25vd24uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5SRSAmcXVvdDtu b25lJnF1b3Q7OiB0aGlzIGlzIGRlZmluZWQgYmVjYXVzZSBpdCBpcyBpbiBSRkMgNDI1Mi4gJm5i c3A7WWVzLCB0aGVyZSdzIGxvdHMgb2YgZ3VpZGFuY2UgaW4gdGhhdCBSRkMgcmVnYXJkaW5nIHRo ZSB1c2Ugb2YgJnF1b3Q7bm9uZSZxdW90OywgYnV0IGl0IGlzICpzdXBwb3J0ZWQqLi4uICZuYnNw OyBJIHRoaW5rIHdoYXQgaXMgbmVlZGVkIGhlcmUgaXMgYSBgZmVhdHVyZWAgc3RhdGVtZW50IGVu YWJsaW5nDQogdGhlIHNlcnZlciB0byBleHByZXNzIGlmICZxdW90O25vbmUmcXVvdDsgaXMgc3Vw cG9ydGVkIG9mIG5vdCAtIGFncmVlZD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFsYXpzJmd0 OyBZZXMsIEkgYWdyZWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+UkUgJnF1b3Q7b3RoZXImcXVvdDs6IEkgZG9uJ3QgcmVtZW1iZXIgaG93ICZxdW90O290 aGVyJnF1b3Q7IGNhbWUgdG8gYmUgbGlzdGVkLCBidXQgaXQgZG9lc24ndCBhcHBlYXIgaW4gUkZD IDQyNTIgYW5kIHRoZXJlZm9yZSBzaG91bGQgYmUgcmVtb3ZlZCAmbmJzcDsodXBkYXRlZCBpbiBt eSBsb2NhbCBjb3B5KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFsYXpzJmd0OyBZZXMsIHBsZWFzZSByZW1v dmUg4oCYb3RoZXLigJkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj7igJhwYXNzd29yZOKAmSBhbmQg4oCYcHVibGlja2V54oCZIGF1dGhl bnRpY2F0aW9uIGNvbmZpZ3VyYXRpb24gaXMgZGVzY3JpYmVkIGJ5IFJGQzczMTcuIEkgd291bGQg dGhlbiBleHBlY3QgcmV1c2FibGUgKGxvY2FsKSBkZWZpbml0aW9ucyB0byBiZSBjcmVhdGVkIGlu IFJGQzczMTcsIGFuZCB1bnRpbCB0aGVuIG1heWJlIHdlIHNob3VsZCBub3QgYm90aGVyIHdpdGgg Y29weWluZw0KIHRoYXQgdG8gdGhlIHNzaC1zZXJ2ZXIgbW9kZWwuIERvIHlvdSByZWFsbHkgZm9y ZXNlZSB0aGF0IHRoZSBzeXN0ZW0gYXV0aGVudGljYXRpb24gbW9kZWwgY2Fubm90IGJlIHVzZWQg Zm9yIFNTSD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPlN5c3RlbS1sZXZlbCBhbmQgTkVUQ09ORi1sZXZlbCB1c2VycyBtYXkgbm90IGJlIHRo ZSBzYW1lLiAmbmJzcDtJIGtub3cgc29tZSBzeXN0ZW0gY28tbWluZ2xlIHRoZSB0d28gd2hpbGUg b3RoZXJzIGRvbid0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYWxh enMmZ3Q7IE9rLCBidXQgdGhlbiBJIGFzc3VtZSB0aGUgbW9kZWwvZm9ybWF0IG9mIGNvbmZpZ3Vy YXRpb24gc2hvdWxkIGJlIHRoZSBzYW1lIGFzIGluIFJGQzczMTcsIHJpZ2h0Pzxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkJUVywgUkZDIDQyNTIgc2F5cyB0aGF0ICZxdW90O3Bhc3N3 b3JkJnF1b3Q7IFNIT1VMRCBiZSByZXF1aXJlZCwgc28gYSBgZmVhdHVyZWAgc3RhdGVtZW50IHNl ZW0gd2FycmFudGVkLiAmbmJzcDtSRkMgNDI1MiBzYXlzIHRoYXQgJnF1b3Q7cHVibGlja2V5JnF1 b3Q7IGlzIFJFUVVJUkVELCBzbyAqbm8qIGBmZWF0dXJlYCBzdGF0ZW1lbnQgaXMgbmVlZGVkIGZv ciBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhbGF6cyZndDsgT2suPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+SW1wbGVtZW50aW5nIOKAmGhvc3RiYXNlZOKAmSBjb3VsZCBtYXliZSBtYWtlIHNlbnNl LiBJIGFzc3VtZSB0aGF0IHJlcXVpcmVzIHRoZSB1c2Ugb2Yg4oCYbG9jYWwtb3ItdHJ1c3RzdG9y ZS1ob3N0LWtleXMtZ3JvdXBpbmfigJggdW5kZXIgc29tZSB1c2VybmFtZSBzbyB0aGF0IHRoZSBt YXBwaW5nIGJldHdlZW4ga2V5IGFuZCB1c2VycyBjYW4gYmUgZG9uZSAoYXMgeW91IHN1Z2dlc3Rl ZCBiZWZvcmUpLiBUaGUgdXNlcnMgd2hpY2ggYXJlIGRlZmluZWQgaGVyZSBjb3VsZCBiZSBhdXRo ZW50aWNhdGVkIHdpdGggaG9zdGtleXMgb24gdG9wIG9mIHRoZSBSRkM3MzE3IHVzZXJzICh3aGlj aCBjYW4gbG9naW4gd2l0aCBwd2Qgb3IgcHVia2V5KS48L3NwYW4+PG86cD48L286cD48L3ByZT4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5SRkMgNDI1MiBzYXlzIHRoYXQgdGhpcyBtZXRob2QgbmFtZSBpcyBPUFRJ T05BTCwgYW5kIHRoZXJlZm9yZSBhIGBmZWF0dXJlYCBzdGF0ZW1lbnQgc2VlbXMgd2FycmFudGVk IGhlcmUgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPlllcywgaXQgc2VlbXMgdGhhdCZuYnNwO+KAmGxvY2FsLW9yLXRydXN0c3Rv cmUtaG9zdC1rZXlzLWdyb3VwaW5n4oCYIHdvdWxkIGJlIGluIHBsYXkgaGVyZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFsYXpzJmd0OyBJIGFncmVlIHRvIGJvdGgu PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBkb24ndCB0aGluayBpdCBuZWVkcyB0 byBiZSB1bmRlciBhIHVzZXJuYW1lLCBhcyB0aGUgU1NILWNsaWVudCBzdGlsbCBleHBsaWNpdGx5 IHNlbmRzIGEgdXNlcm5hbWUgKHNhbWUgYXMgd2l0aCAmcXVvdDtub25lJnF1b3Q7KSBwZXIgUkZD IDQ1NTIgU2VjdGlvbiA1LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFsYXpzJmd0OyBZb3UgaGF2 ZSB0byBoYXZlIGEgd2hpdGVsaXN0IG9mIHVzZXJzIG9uIHRoZSBzZXJ2ZXIgc2lkZSB3aGVyZSB5 b3UgYWxsb3cgaG9zdGJhc2VkIGF1dGhlbnRpY2F0aW9uLiBUaGUgcmVzdCBvZiB0aGUgdXNlcnMg c2hvdWxkIG5vdCBiZSBhYmxlIHRvIGxvZ2luIHdpdGggYSBob3N0IGtleS4gV2UgYWxzbyBuZWVk IHRvIHNvbWVob3cgbWFrZSBpdCBwb3NzaWJsZSB0byBzdGFjayBhdXRoZW50aWNhdGlvbg0KIG1l dGhvZHMgLSZndDsgYXNrIG1vcmUgdGhhbiBvbmUgZm9yIGEgbG9naW4gdG8gc3VjY2VlZCBvciB3 aGF0ZXZlciBvdGhlciBwb2xpY2llcyBhcmUgc3VwcG9ydGVkIGluIGdlbmVyYWwgYnkgYW4gU1NI IHNlcnZlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzQyNTIjc2VjdGlvbi00Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNDI1MiNzZWN0aW9uLTQ8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBocmVmPSJodHRwczovL21hbi5vcGVuYnNkLm9yZy9zc2hkX2NvbmZpZyNBdXRoZW50 aWNhdGlvbk1ldGhvZHMiPmh0dHBzOi8vbWFuLm9wZW5ic2Qub3JnL3NzaGRfY29uZmlnI0F1dGhl bnRpY2F0aW9uTWV0aG9kczwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkkgYWxzbyBkb27igJl0IHVuZGVyc3RhbmQgdGhlIHBvaW50IGluIGhh dmluZyB0aGUgZmVhdHVyZSDigJg8L3NwYW4+Y2xpZW50LWF1dGgtY29uZmlnLXN1cHBvcnRlZOKA mS4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgVExTIGdyb3VwaW5ncyBkb27igJl0IGhhdmUgdGhpcywg YW5kIGFsc28gd2hlcmUgd291bGQgdGhlIGNvbmZpZ3VyYXRpb24gb2YgY2EtY2VydHMsIGNsaWVu dC1jZXJ0cywgZXRjLiBiZSBpZiBub3QgaW4gdGhpcyBzZXJ2ZXIgZ3JvdXBpbmc/PC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlBs ZWFzZSBjaGVjayBhZ2FpbiwgdGhlIHRscy1zZXJ2ZXItZ3JvdXBpbmcgZG9lcyBoYXZlICdjbGll bnQtYXV0aC1jb25maWctc3VwcG9ydGVkJyAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi10bHMtY2xpZW50LXNlcnZlci0xNyNzZWN0aW9uLTQi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtdGxzLWNsaWVu dC1zZXJ2ZXItMTcjc2VjdGlvbi00PC9hPikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+QW5zd2VyaW5nIHlvdXIgbGFzdCBxdWVzdGlvbiwgbm90ZSB0aGF0 IFRMUy1sZXZlbCBjbGllbnQgYXV0aCBpcyBvcHRpb25hbCwgYXMgY2xpZW50IGF1dGggTUFZIG9j Y3VyIGF0IGEgcHJvdG9jb2wtbGF5ZXIgYWJvdmUgVExTLiAmbmJzcDtUaGF0IHNhaWQsIEknbGwg Z3JhbnQgeW91IHRoYXQgdGhpcyBmZWF0dXJlIG1heSBub3QgYmUgaWRlYWwgYXMgaW5zdGVhZCwg cGVyaGFwcywNCiB0aGUgc2VydmVyIGNvdWxkIGluc3RlYWQgcmVseSBvbiAqaWYqIGFueSBvZiB0 aGUgZGVzY2VuZGFudHMgd2VyZSBjb25maWd1cmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSdt IGxlc3Mgc3VyZSBhYm91dCBTU0gsIGJ1dCBJIGRvbid0IGJlbGlldmUgdGhhdCBjbGllbnQgYXV0 aGVudGljYXRpb24gY2FuIGV2ZXIgb2NjdXIgYXQgYSBoaWdoZXItbGV2ZWwgcHJvdG9jb2wgbGF5 ZXIuICZuYnNwO1RoYXQgYmVpbmcgdGhlIGNhc2UsIHRoZXJlJ3MgbGlrZWx5IGEgZ29vZCBhdWdt ZW50IHRvIHJlbW92aW5nIHRoZSAmcXVvdDtjbGllbnQtYXV0aC1jb25maWctc3VwcG9ydGVkJnF1 b3Q7DQogZmVhdHVyZSBpbiBpZXRmLXNzaC1zZXJ2ZXIuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYWxhenMmZ3Q7IE9rLCBmb3IgVExTIHlvdSBhcmUgcmln aHQsIEkgYWNjaWRlbnRhbGx5IG1pc3NlZCB0aGF0LiBJIHRoaW5rIGluIFRMUyBpdCBpcyBvayBh cyBmZWF0dXJlIGZvciB0aGUgcmVhc29ucyB5b3UgaGFkLiBCdXQgaW4gU1NIIGNhc2UsIEnigJl2 ZSBvbmx5IHNlZW4gU1NIIGRvaW5nIHRoZSB1c2VyIGF1dGhlbnRpY2F0aW9uIGFzIG9mIFJGQyA0 MjUyLCBhcyB5b3Ugc2FpZC4gU28gSeKAmWQgdm90ZSBmb3Igbm90DQogaGF2aW5nIGEgZmVhdHVy ZSBmb3IgU1NIIGNsaWVudCBhdXRoIGFuZCB0aGF0IHNvbWV0aGluZyBtdXN0IGJlIGNvbmZpZ3Vy ZWQgdGhlcmUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFsYXpzJmd0OyBJ4oCZbSBhbHNv IHRoaW5raW5nIGlmIGNlcnRpZmljYXRlIGJhc2VkIGF1dGhlbnRpY2F0aW9uIHNob3VsZCBiZSB1 bmRlciB0aGUgdXNlciB3aGl0ZWxpc3QsIGJ1dCBJ4oCZbSBub3QgdmVyeSBmYW1pbGlhciB3aXRo IFJGQzYxODcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5LZW50IC8vIGNvbnRy aWJ1dG9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_AM0PR07MB51870877DB698D0A14DC0A03830C0AM0PR07MB5187eurp_-- From nobody Wed Jan 22 06:43: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 57AEA1200F6 for ; Wed, 22 Jan 2020 06:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iVp9hLcW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OszUWiyV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE9u4uFu5IiV for ; Wed, 22 Jan 2020 06:43:02 -0800 (PST) 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 914C91200F3 for ; Wed, 22 Jan 2020 06:43:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28188; q=dns/txt; s=iport; t=1579704182; x=1580913782; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bVasJiENGn7PLIuWeol/5jnX+TSjQu94aiqygHim5lg=; b=iVp9hLcWOIqIIddDd42ObwKM31VhqocbqoOzWKtreaghF48opMTS4zwM QgjomRBM7zaa6QwGXOyuxWyt8mRrC7XTKjDUxLJkxm9+ymp7saYEQilXn U1dHdLuH1FgOiCKIxiKKPIQpfqbwGLtONig940rsMkem0CF9xGk8plJjT Q=; IronPort-PHdr: =?us-ascii?q?9a23=3Av0zXZRbWx+D9duZ6rDAjstn/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavwcC0+AMNEfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAACjXihe/5RdJa1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gSUvJCwFbFggBAsqCoQIg0YDiwiCX5gOglI?= =?us-ascii?q?DVAkBAQEMAQEtAgEBhEACF4IDJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQE?= =?us-ascii?q?DEhEKEwEBNQIBDwIBCBEDAQEBIQcDAgICMBQJCAIEAQ0FCBEJgwWBfU0DLgE?= =?us-ascii?q?Co2cCgTmIYXWBMoJ/AQEFhQoYggwJgTiMFhqBQT+BWIJMPoJkBIFjHhaCWjK?= =?us-ascii?q?CLJBVhVwkiU+PMgqCOY0CiUyad45emwgCBAIEBQIOAQEFgWkiKoEucBU7gmx?= =?us-ascii?q?QGA2IATiDO4pTdAIBgSaLOAGBDwEB?= X-IronPort-AV: E=Sophos;i="5.70,350,1574121600"; d="scan'208,217";a="707882203" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jan 2020 14:43:01 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 00MEh0gX010917 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Jan 2020 14:43:01 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 08:43:00 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 08:42:59 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 22 Jan 2020 08:42:59 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WB1GL8hXBO8t8tcsH98TJ7VPE8kUnHD3IAJCLZAJRwPlFX5PRjjujgNHTMVhjDHGDR1yLg6904QCK2JOM8LNnsMAHViI2v0UcYwAwADV8fPoJxsvWQAsCH3z+NR4i/Cioqaid9TSlX5paDXbh+1Yo4wCbOD9Kw424RVlgATuDXfNAdVdvQOsRzncLYfqCplop3DS0Vn+fcQDX9yWrmcvtNfwFjfHBYiW1PO7L1UE1Ump9MKD0hu/RC0rg+7d4MAEu8zfWMyw5cn8NeRj971aJwPwOdLWBdmuL1Z3mdqGQz7LWj/NuMmT/cTtqtIG60SfjkzYNQuUnRnPTGzQ8wd9ew== 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=bVasJiENGn7PLIuWeol/5jnX+TSjQu94aiqygHim5lg=; b=f8hZsn3RX57TBj78W8iYxUcWmtPcZmX2IKFq2/yObhFgkDy1Cgwudt9CWl3pw3mxINlEUiabNQ4MatCgV7eMaoOzVbUDi5+1X5fML9tALeq7/8rLKyTduJs6Vv+uvoaoMGUGEDsDnOj0k7GTFLALYyaX1HZOcrLc5AZWWlUDF5zPLWZRJZN5dtjsvY/fjXqOlF4RP8IUGnWbBr4X2u/w/Rzk7I8wyaLGO1yRmMtexLritG7LihwyUqa3myaG6lNKNNm92/tCR886rldzDVwQlpQYj7cen1znvrVVMgSupesvdHzpHQ5xNqs932kUMdD7CGrJHvMQMVBAlERwsKcjHQ== 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=bVasJiENGn7PLIuWeol/5jnX+TSjQu94aiqygHim5lg=; b=OszUWiyVAo3mil+FigEMKPGhcNLgWiUNGDyU9hO7EJwSoscoZ4BLTVXGkv3NZ3w8zEMWJheXp1oLzru/onPxTdiO4jpQNThR2S61s2SPADrvvlvCQMwUgMzEi/0D4L3W8TiUCcBsiCx5BDFlqnDFIG9TuXD4zDnOC25YIZlxKyc= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3757.namprd11.prod.outlook.com (20.178.252.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Wed, 22 Jan 2020 14:42:58 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1%7]) with mapi id 15.20.2644.027; Wed, 22 Jan 2020 14:42:58 +0000 From: "Rob Wilton (rwilton)" To: "Reshad Rahman (rrahman)" , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt Thread-Index: AQHVxVsSt5Mms9ZtVUqYtH0CGNIWiaffY4HQgAC0VICAANxNAIADGDWAgAAHhLCABgRagIALUPKAgAEr+lA= Date: Wed, 22 Jan 2020 14:42:58 +0000 Message-ID: References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <0100016f83226d35-4c825571-7fe8-4074-8f6c-d9994e2ed37a-000000@email.amazonses.com> <0100016f901833d0-c822306b-9f2f-4c7b-9444-34742ec35a53-000000@email.amazonses.com> <58F397A3-9E37-4E61-BDEE-C0DAA61B6A3B@cisco.com> In-Reply-To: <58F397A3-9E37-4E61-BDEE-C0DAA61B6A3B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.39] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9b03cf9a-caa3-4a0d-69aa-08d79f495fdc x-ms-traffictypediagnostic: MN2PR11MB3757: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(136003)(396003)(366004)(346002)(199004)(189003)(478600001)(71200400001)(5660300002)(4326008)(53546011)(316002)(8936002)(9686003)(8676002)(55016002)(81166006)(81156014)(9326002)(7696005)(6506007)(2906002)(66476007)(66446008)(66556008)(33656002)(26005)(76116006)(52536014)(186003)(64756008)(110136005)(66574012)(15650500001)(66946007)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3757; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PyCGto0Uo9N1MqhuPizQFcdFAE0cwgn1QJ07ACgSb9w/wEbClALhgJjEAvsxKN1+AxMpGWcdKDylwu+HmsdznlqKdAF0bDdK63euFhYfhUqYQ9p/pTUkmlgE0SKtZ7JIhJ0z2xXCqb/Nk5QnJ7u+1wB19LsA9GbE6DxyF1T9kCj2Bew/M7OGGBc47gKay0eJjDcnGVXGVYjRhiNEdCbbgFwhEx2BsaETj1iFTClRK35KYKC+KVBtORugts3n9A15VRp/Yh9jOxyJWTF2Qv713PCI0xAfGp38Y0nHYXx79tgE0gRgXdjV/Gjy32jL31SwNdq+A4sxm3ctptGoS0rNRoegN4nU6lUGqx3CfV5zs7IvQScLICE1OXpMTQAdZzUkR/Y/oIiLtUZupjQWOQA/9GPi3XPqT2ESfd6D0LeLAZ7JjVxYs2ECqhDfkkaYKh/3 Content-Type: multipart/alternative; boundary="_000_MN2PR11MB436687635084B38EC8E579EEB50C0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9b03cf9a-caa3-4a0d-69aa-08d79f495fdc X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 14:42:58.3665 (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: Gm7xSvNLZB1OfAH2412Ma3UEME0aHDKsWhYfeuqWYVGUpXYcywgCVryqIQ/lDR64SIwUQwxI6SyiNqrL+wHDWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3757 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 14:43:06 -0000 --_000_MN2PR11MB436687635084B38EC8E579EEB50C0MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmVzaGFkLA0KDQpJbiByZXYtOSwgaW4gdGhlIFlBTkcgbW9kdWxlIGRlc2NyaXB0aW9uLCB0 aGVyZSBpcyBhIGhpZXJhcmNoeSBvZiB3aGljaCBjYXBhYmlsaXRpZXMgYXBwbHksIGJhc2ljYWxs eSB0aGUgbG9uZ2VzdCBtYXRjaCB3aW5zOg0KDQogICAgICBJZiBhIGNhcGFiaWxpdHkgaXMgc3Bl Y2lmaWVkIG9uIG11bHRpcGxlIGxldmVscywgdGhlDQogICAgICBzcGVjaWZpY2F0aW9uIG9uIGEg bW9yZSBzcGVjaWZpYyBsZXZlbCBvdmVycmlkZXMgbW9yZQ0KICAgICAgZ2VuZXJpYyBjYXBhYmls aXR5IHNwZWNpZmljYXRpb25zOyB0aHVzDQogICAgICAtIGEgc3lzdGVtIGxldmVsIHNwZWNpZmlj YXRpb24gaXMgb3ZlcnJpZGRlbiBieSBhbnkNCiAgICAgIG90aGVyIHNwZWNpZmljYXRpb24NCiAg ICAgIC0gYSBkYXRhc3RvcmUgbGV2ZWwgc3BlY2lmaWNhdGlvbiAod2l0aCBhIG5vZGUtc2VsZWN0 b3IgJy8nKSBpcw0KICAgICAgb3ZlcnJpZGRlbiBieSBhIHNwZWNpZmljYXRpb24gd2l0aCBhIG1v cmUgc3BlY2lmaWMgbm9kZS1zZWxlY3Rvci4NCiAgICAgIC0gYSBzcGVjaWZpY2F0aW9uIGZvciBh IHNwZWNpZmljIGRhdGFzdG9yZSBhbmQgbm9kZS1zZWxlY3Rvcg0KICAgICAgaXMgb3ZlcnJpZGRl biBieSBhIHNwZWNpZmljYXRpb24gZm9yIHRoZSBzYW1lIGRhdGFzdG9yZSB3aXRoDQogICAgICBh IG5vZGUtc2VsZWN0b3IgdGhhdCBkZXNjcmliZXMgbW9yZSBsZXZlbHMgb2YgY29udGFpbmluZyBs aXN0cw0KICAgICAgYW5kIGNvbnRhaW5lcnMuDQogICAgICBJdCBpcyBub3QgYWxsb3dlZCB0byBo YXZlIG11bHRpcGxlIG5vZGUgc2VsZWN0b3JzIHdoaWNoDQogICAgICAtIGFyZSBkZWZpbmVkIGZv ciB0aGUgc2FtZSBkYXRhc3RvcmUgQU5EDQogICAgICAtIGhhdmUgdGhlIHNhbWUgbnVtYmVyIG9m IGNvbnRhaW5tZW50IGxldmVscyBBTkQNCiAgICAgIC0gc2VsZWN0IGFuIG92ZXJsYXBwaW5nIHNl dCBvZiBub2Rlcy4NCg0KQnV0IGFzIHNvb24gYXMgeW91IGFsbG93IG1vcmUgY29tcGxleCBzcGVj aWZpY2F0aW9ucyAoZS5nLiBwZXJoYXBzIFhwYXRoIHRvIHNlbGVjdCB0aGUgc2V0IG9mIG5vZGVz IHRoYXQgYSBjYXBhYmlsaXR5IGFwcGxpZXMgdG8pIHRoZW4gd29ya2luZyBvdXQgd2hpY2ggZW50 cnkgaXMgdGhlIGxvbmdlc3QgbWF0Y2ggaXMgdmVyeSBoYXJkLCBpZiBub3QgaW1wb3NzaWJsZS4g IEhlbmNlIG1vdmluZyB0byBhbiBvcmRlcmVkIGxpc3QgKGFzIHBlciB0aGUgLTEwIGRyYWZ0KSBl bnN1cmVzIHRoYXQgdGhlIGNhcGFiaWxpdGllcyBhcmUgYWx3YXlzIGRldGVybWluaXN0aWMuDQoN ClRoYW5rcywNClJvYg0KDQoNCkZyb206IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIDxycmFobWFu QGNpc2NvLmNvbT4NClNlbnQ6IDIxIEphbnVhcnkgMjAyMCAxNjo0NA0KVG86IEJhbMOhenMgTGVu Z3llbCA8YmFsYXpzLmxlbmd5ZWw9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+OyBSb2Ig V2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+OyBLZW50IFdhdHNlbiA8a2VudCtp ZXRmQHdhdHNlbi5uZXQ+DQpDYzogbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRj b25mXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gLSBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZp Y2F0aW9uLWNhcGFiaWxpdGllcy0wOS50eHQNCg0KSGksDQoNClJlZ2FyZGluZyB0aGUgY2hhbmdl IGJlbG93ICh3aGljaCB3YXMgYWRkZWQgaW4gcmV2LTEwKSB0byBtYXRjaCBieSBvcmRlciwgd2Fz IHRoaXMgZG9uZSBqdXN0IHRvIG1ha2UgbGlmZSBlYXNpZXIgZm9yIHRoZSBjbGllbnQgKHRoZSBw dWJsaXNoZXIgaXMgZGVjaWRpbmcgd2hhdOKAmXMgdGhlIGJlc3QgbWF0Y2gpIG9yIGlzIHRoZXJl IGFub3RoZXIgbW90aXZhdGlvbj8gSSB0aGluayB0aGlzIGlzIGEgZ29vZCBjaGFuZ2UsIGJ1dCBj dXJpb3VzIGFzIHRvIHRoZSByZWFzb24uDQoNClJlZ2FyZHMsDQpSZXNoYWQuDQoNCkZyb206IG5l dGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEJhbMOhenMgTGVu Z3llbCA8YmFsYXpzLmxlbmd5ZWw9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRl OiBUdWVzZGF5LCBKYW51YXJ5IDE0LCAyMDIwIGF0IDY6NTUgQU0NClRvOiAiUm9iIFdpbHRvbiAo cndpbHRvbikiIDxyd2lsdG9uQGNpc2NvLmNvbT4sIEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0 c2VuLm5ldD4NCkNjOiAibmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW25ldGNvbmZdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYt bmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0aWVzLTA5LnR4dA0KDQpPSy4gRm9yIGJvdGgu DQpSZWdhcmRzIEJhbGF6cw0KDQpGcm9tOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBj aXNjby5jb20+DQpTZW50OiAyMDIwLiBqYW51w6FyIDEwLiwgcMOpbnRlayAxNzowOA0KVG86IEtl bnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD47IEJhbMOhenMgTGVuZ3llbCA8YmFsYXpz Lmxlbmd5ZWxAZXJpY3Nzb24uY29tPg0KQ2M6IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJF OiBbbmV0Y29uZl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0Zi1uZXRjb25m LW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMDkudHh0DQoNCkhpIEtlbnQsIEJhbGF6cywNCg0K WWVzLCBJIHRoaW5rIHRoYXQgdGhpcyB3b3VsZCB3b3JrLCBidXQgbWlnaHQgYWxzbyBuZWVkIHRv IGNoYW5nZSB0aGUgcnVsZSBmcm9tIG1hdGNoaW5nIHRoZSBjYXBhYmlsaXRpZXMgZnJvbSB0aGUg bG9uZ2VzdCBub2RlIHBhdGgsIHRvIHRoZSBvcmRlciB0aGF0IHRoZSBlbnRyaWVzIGFyZSBpbiB0 aGUgbGlzdC4gIEUuZy4gdGhlIGNhcGFiaWxpdGllcyBhcmUgZGVjaWRlZCBieSB0aGUgZmlyc3Qg ZW50cnkgaW4gdGhlIGxpc3QgdGhhdCBtYXRjaGVzIHRoZSBnaXZlbiBwYXRoLiAgVGhlIGV4aXN0 aW5nIGxvbmdlc3Qgbm9kZSBwYXRoIGJlaGF2aW91ciBjYW4gZWZmZWN0aXZlbHkgYmUgaW1wbGVt ZW50ZWQgYnkgb3JkZXJpbmcgdGhlIG1vcmUgc3BlY2lmaWMgbm9kZSBwYXRocyBiZWZvcmUgdGhl IGxlc3Mgc3BlY2lmaWMgbm9kZSBwYXRocy4NCg0KV291bGQgdGhhdCBiZSBhY2NlcHRhYmxlPw0K DQpJIHdvdWxkIGFsc28gc3VnZ2VzdCBnaXZpbmcgdGhlIGNob2ljZSBhbmQgdGhlIGxlYWYgYSBz ZXBhcmF0ZSBuYW1lIGJlbG93Lg0KDQpUaGFua3MsDQpSb2INCg0KDQpGcm9tOiBLZW50IFdhdHNl biA8a2VudCtpZXRmQHdhdHNlbi5uZXQ8bWFpbHRvOmtlbnQraWV0ZkB3YXRzZW4ubmV0Pj4NClNl bnQ6IDEwIEphbnVhcnkgMjAyMCAxNTozNQ0KVG86IEJhbMOhenMgTGVuZ3llbCA8YmFsYXpzLmxl bmd5ZWxAZXJpY3Nzb24uY29tPG1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+Pg0K Q2M6IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRv bkBjaXNjby5jb20+PjsgbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQt aWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMDkudHh0DQoNCg0KSGkgQmFs YXpzLA0KDQoNCg0KV291bGQgdGhlIGZvbGxvd2luZyBiZSBhY2NlcHRhYmxlPw0KT0xEOg0KICAg ICBsaXN0IHBlci1ub2RlLWNhcGFiaWxpdGllcyB7DQogICAgICAga2V5ICJub2RlLXNlbGVjdG9y IjsNCiAgICAgICBsZWFmIG5vZGUtc2VsZWN0b3Igew0KICAgICAgICAgdHlwZSBuYWNtOm5vZGUt aW5zdGFuY2UtaWRlbnRpZmllcjsNCk5FVzoNCiAgICAgbGlzdCBwZXItbm9kZS1jYXBhYmlsaXRp ZXMgew0KICAgICAgIGNob2ljZSBub2RlLXNlbGVjdG9yIHsNCiAgICAgICAgICAgICBsZWFmIG5v ZGUtc2VsZWN0b3IgeyAgIHR5cGUgbmFjbTpub2RlLWluc3RhbmNlLWlkZW50aWZpZXI7ICB9DQog ICAgIH0NCg0KTGF0ZXIgeW91IGNhbiBhdWdtZW50IGluIGFuIFhwYXRoIGZpbHRlciBvciBhIHN0 cmluZyB3aXRoICcqJyBhbmQgJz8nIHdpbGRjYXJkcyBvciB3aGF0ZXZlciB5b3Ugd2FudC4NCihU aGUgbGlzdCBkb2VzIG5vdCBuZWVkIGEga2V5IGFzIGl0IGlzIGNvbmZpZz1mYWxzZSkNCg0KDQpZ ZXMsIHRoaXMgaXMgaW5saW5lIHdpdGggd2hhdCBJIGhhZCBpbiBtaW5kIGJ1dCwgc2luY2UgdGhp cyB3YXMgbXkgc3VnZ2VzdGlvbiwgSSB3YXMgaG9waW5nIHRoYXQgUm9iIG9yIG90aGVycyB3b3Vs ZCByZXBseS4NCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQoNCg== --_000_MN2PR11MB436687635084B38EC8E579EEB50C0MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWww LCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3Jt YWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLXRh Yi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHls ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnNwYW4ubWZ0cg0KCXttc28tc3R5bGUtbmFtZTptX2Z0cjt9 DQpzcGFuLm1oZHINCgl7bXNvLXN0eWxlLW5hbWU6bV9oZHI7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i Izk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBSZXNoYWQsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkluIHJldi05LCBpbiB0aGUgWUFORyBtb2R1bGUgZGVzY3JpcHRpb24sIHRoZXJlIGlzIGEg aGllcmFyY2h5IG9mIHdoaWNoIGNhcGFiaWxpdGllcyBhcHBseSwgYmFzaWNhbGx5IHRoZSBsb25n ZXN0IG1hdGNoIHdpbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJtc28tZWxl bWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4 LjBwdCA4LjBwdCA4LjBwdCA4LjBwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dv cmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgYSBjYXBhYmlsaXR5IGlzIHNwZWNpZmllZCBv biBtdWx0aXBsZSBsZXZlbHMsIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3 b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRpb24gb24gYSBtb3JlIHNwZWNp ZmljIGxldmVsIG92ZXJyaWRlcyBtb3JlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1 O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ2VuZXJpYyBjYXBhYmlsaXR5IHNwZWNpZmlj YXRpb25zOyB0aHVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6 YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLSBhIHN5c3RlbSBsZXZlbCBzcGVjaWZpY2F0aW9uIGlzIG92ZXJy aWRkZW4gYnkgYW55PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6 YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgb3RoZXIgc3BlY2lmaWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tn cm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBj bSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gYSBkYXRhc3RvcmUg bGV2ZWwgc3BlY2lmaWNhdGlvbiAod2l0aCBhIG5vZGUtc2VsZWN0b3IgJy8nKSBpczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9u ZTtwYWRkaW5nOjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG92 ZXJyaWRkZW4gYnkgYSBzcGVjaWZpY2F0aW9uIHdpdGggYSBtb3JlIHNwZWNpZmljIG5vZGUtc2Vs ZWN0b3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWst YWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLSBhIHNwZWNpZmljYXRpb24gZm9yIGEgc3BlY2lmaWMgZGF0YXN0b3JlIGFu ZCBub2RlLXNlbGVjdG9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJl YWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgb3ZlcnJpZGRlbiBieSBhIHNwZWNpZmljYXRpb24gZm9y IHRoZSBzYW1lIGRhdGFzdG9yZSB3aXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1 O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBub2RlLXNlbGVjdG9yIHRoYXQgZGVzY3Jp YmVzIG1vcmUgbGV2ZWxzIG9mIGNvbnRhaW5pbmcgbGlzdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20i Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgY29udGFpbmVycy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9y ZGVyOm5vbmU7cGFkZGluZzowY20iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBJdCBpcyBub3QgYWxsb3dlZCB0byBoYXZlIG11bHRpcGxlIG5vZGUgc2VsZWN0b3JzIHdo aWNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLSBhcmUgZGVmaW5lZCBmb3IgdGhlIHNhbWUgZGF0YXN0b3JlIEFORDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9u ZTtwYWRkaW5nOjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0g aGF2ZSB0aGUgc2FtZSBudW1iZXIgb2YgY29udGFpbm1lbnQgbGV2ZWxzIEFORDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcu OXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtw YWRkaW5nOjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gc2Vs ZWN0IGFuIG92ZXJsYXBwaW5nIHNldCBvZiBub2Rlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CdXQgYXMgc29v biBhcyB5b3UgYWxsb3cgbW9yZSBjb21wbGV4IHNwZWNpZmljYXRpb25zIChlLmcuIHBlcmhhcHMg WHBhdGggdG8gc2VsZWN0IHRoZSBzZXQgb2Ygbm9kZXMgdGhhdCBhIGNhcGFiaWxpdHkgYXBwbGll cyB0bykgdGhlbiB3b3JraW5nIG91dCB3aGljaCBlbnRyeSBpcyB0aGUgbG9uZ2VzdCBtYXRjaCBp cyB2ZXJ5IGhhcmQsIGlmDQogbm90IGltcG9zc2libGUuJm5ic3A7IEhlbmNlIG1vdmluZyB0byBh biBvcmRlcmVkIGxpc3QgKGFzIHBlciB0aGUgLTEwIGRyYWZ0KSBlbnN1cmVzIHRoYXQgdGhlIGNh cGFiaWxpdGllcyBhcmUgYWx3YXlzIGRldGVybWluaXN0aWMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJvYjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZXNoYWQgUmFobWFuIChycmFobWFuKSAmbHQ7 cnJhaG1hbkBjaXNjby5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMjEgSmFudWFyeSAyMDIw IDE2OjQ0PGJyPg0KPGI+VG86PC9iPiBCYWzDoXpzIExlbmd5ZWwgJmx0O2JhbGF6cy5sZW5neWVs PTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnJmd0OzsgUm9iIFdpbHRvbiAocndpbHRvbikg Jmx0O3J3aWx0b25AY2lzY28uY29tJmd0OzsgS2VudCBXYXRzZW4gJmx0O2tlbnQmIzQzO2lldGZA d2F0c2VuLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtuZXRjb25mXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gLSBkcmFm dC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGllcy0wOS50eHQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRpbmcgdGhlIGNoYW5nZSBiZWxvdyAod2hpY2gg d2FzIGFkZGVkIGluIHJldi0xMCkgdG8gbWF0Y2ggYnkgb3JkZXIsIHdhcyB0aGlzIGRvbmUganVz dCB0byBtYWtlIGxpZmUgZWFzaWVyIGZvciB0aGUgY2xpZW50ICh0aGUgcHVibGlzaGVyIGlzIGRl Y2lkaW5nIHdoYXTigJlzIHRoZSBiZXN0IG1hdGNoKSBvciBpcyB0aGVyZSBhbm90aGVyIG1vdGl2 YXRpb24/IEkgdGhpbmsNCiB0aGlzIGlzIGEgZ29vZCBjaGFuZ2UsIGJ1dCBjdXJpb3VzIGFzIHRv IHRoZSByZWFzb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXNoYWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5uZXRjb25mICZsdDtu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBCYWzDoXpzIExlbmd5ZWwg Jmx0O2JhbGF6cy5sZW5neWVsPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKYW51YXJ5IDE0LCAyMDIwIGF0IDY6NTUgQU08YnI+DQo8 Yj5UbzogPC9iPiZxdW90O1JvYiBXaWx0b24gKHJ3aWx0b24pJnF1b3Q7ICZsdDtyd2lsdG9uQGNp c2NvLmNvbSZndDssIEtlbnQgV2F0c2VuICZsdDtrZW50JiM0MztpZXRmQHdhdHNlbi5uZXQmZ3Q7 PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtuZXRjb25mQGlldGYub3JnJnF1b3Q7ICZsdDtuZXRjb25m QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW25ldGNvbmZdIE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJp bGl0aWVzLTA5LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5P Sy4gRm9yIGJvdGguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiPlJlZ2FyZHMgQmFsYXpzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1DQSI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLUNBIj4gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0O3J3aWx0b25AY2lzY28uY29tJmd0 Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDIwMjAuIGphbnXDoXIgMTAuLCBww6ludGVrIDE3OjA4PGJy Pg0KPGI+VG86PC9iPiBLZW50IFdhdHNlbiAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0 OzsgQmFsw6F6cyBMZW5neWVsICZsdDtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBb bmV0Y29uZl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0Zi1uZXRjb25mLW5v dGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMDkudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBLZW50LCBC YWxhenMsPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIEkgdGhpbmsgdGhhdCB0aGlzIHdvdWxkIHdv cmssIGJ1dCBtaWdodCBhbHNvIG5lZWQgdG8gY2hhbmdlIHRoZSBydWxlIGZyb20gbWF0Y2hpbmcg dGhlIGNhcGFiaWxpdGllcyBmcm9tIHRoZSBsb25nZXN0IG5vZGUgcGF0aCwgdG8gdGhlIG9yZGVy IHRoYXQgdGhlIGVudHJpZXMgYXJlIGluIHRoZSBsaXN0LiZuYnNwOyBFLmcuIHRoZSBjYXBhYmls aXRpZXMgYXJlIGRlY2lkZWQgYnkgdGhlIGZpcnN0IGVudHJ5IGluDQogdGhlIGxpc3QgdGhhdCBt YXRjaGVzIHRoZSBnaXZlbiBwYXRoLiZuYnNwOyBUaGUgZXhpc3RpbmcgbG9uZ2VzdCBub2RlIHBh dGggYmVoYXZpb3VyIGNhbiBlZmZlY3RpdmVseSBiZSBpbXBsZW1lbnRlZCBieSBvcmRlcmluZyB0 aGUgbW9yZSBzcGVjaWZpYyBub2RlIHBhdGhzIGJlZm9yZSB0aGUgbGVzcyBzcGVjaWZpYyBub2Rl IHBhdGhzLjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGQgdGhhdCBiZSBhY2NlcHRhYmxlPzxzcGFu IGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBhbHNvIHN1Z2dlc3QgZ2l2aW5nIHRoZSBjaG9pY2UgYW5k IHRoZSBsZWFmIGEgc2VwYXJhdGUgbmFtZSBiZWxvdy48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r cyw8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Um9iPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBsYW5nPSJFTi1DQSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1DQSI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUNBIj4gS2VudCBXYXRz ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprZW50JiM0MztpZXRmQHdhdHNlbi5uZXQiPmtlbnQmIzQz O2lldGZAd2F0c2VuLm5ldDwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTAgSmFudWFyeSAy MDIwIDE1OjM1PGJyPg0KPGI+VG86PC9iPiBCYWzDoXpzIExlbmd5ZWwgJmx0OzxhIGhyZWY9Im1h aWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20iPmJhbGF6cy5sZW5neWVsQGVyaWNzc29u LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7 Ow0KPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0gTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIC0gZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMDkudHh0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEJhbGF6cyw8c3BhbiBsYW5n PSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8YnI+ DQo8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+V291bGQgdGhlIGZvbGxvd2luZyBiZSBhY2NlcHRhYmxlPzxzcGFu IGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9MRDo8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtsaXN0IHBlci1ub2RlLWNhcGFiaWxpdGllcyB7PGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7a2V5ICZxdW90O25vZGUtc2VsZWN0 b3ImcXVvdDs7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 bGVhZiBub2RlLXNlbGVjdG9yIHs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0eXBlIG5hY206bm9kZS1pbnN0YW5jZS1pZGVudGlmaWVy Ozxicj4NCk5FVzo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtsaXN0IHBlci1u b2RlLWNhcGFiaWxpdGllcyB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Y2hvaWNlIG5vZGUtc2VsZWN0b3Igezxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5sZWFmIG5vZGUtc2VsZWN0b3IgeyAmbmJz cDsmbmJzcDt0eXBlIG5hY206bm9kZS1pbnN0YW5jZS1pZGVudGlmaWVyOyAmbmJzcDt9PGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTxicj4NCjxicj4NCkxhdGVyIHlvdSBjYW4g YXVnbWVudCBpbiBhbiBYcGF0aCBmaWx0ZXIgb3IgYSBzdHJpbmcgd2l0aCAnKicgYW5kICc/JyB3 aWxkY2FyZHMgb3Igd2hhdGV2ZXIgeW91IHdhbnQuPGJyPg0KKFRoZSBsaXN0IGRvZXMgbm90IG5l ZWQgYSBrZXkgYXMgaXQgaXMgY29uZmlnPWZhbHNlKTxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBsYW5nPSJFTi1DQSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+WWVzLCB0aGlzIGlzIGlubGluZSB3aXRoIHdoYXQgSSBoYWQgaW4gbWluZCBidXQsIHNpbmNl IHRoaXMgd2FzIG15IHN1Z2dlc3Rpb24sIEkgd2FzIGhvcGluZyB0aGF0IFJvYiBvciBvdGhlcnMg d291bGQgcmVwbHkuPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxzcGFuIGxhbmc9IkVOLUNB Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5LZW50IC8vIGNvbnRyaWJ1dG9yPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxzcGFu IGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_MN2PR11MB436687635084B38EC8E579EEB50C0MN2PR11MB4366namp_-- From nobody Wed Jan 22 09:48:20 2020 Return-Path: <0100016fce5e75fe-26e79977-8a43-4554-8722-4b931020fcad-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 C37A812012C for ; Wed, 22 Jan 2020 09:48:18 -0800 (PST) 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_DNSWL_NONE=-0.0001, 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 zyq5DD5AtZlf for ; Wed, 22 Jan 2020 09:48:16 -0800 (PST) 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 52535120108 for ; Wed, 22 Jan 2020 09:48:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1579715295; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Pt9lT0L5HqRMiqnStF1ewFrF66wMuLeHOn+1EFX4ZMg=; b=bw1DcU79JxbFKAsZgnVnrqtEyKwfLjgJi6YF2EkiHFqiH5nx0XQuOY3d3hpD/Yrq k9mbF+qkHZRP7Kw50WdfnZe34pfOXaixINDByyRwsIvUM6NWZLe0Y0NnUD7/vZPdtrt SD0yHox9ksku/Lk2EqZ3wN1ZbbX3mWhHFsvVRJqY= From: Kent Watsen Message-ID: <0100016fce5e75fe-26e79977-8a43-4554-8722-4b931020fcad-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4374E242-91D6-4DC3-8CA0-7B928207417D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 22 Jan 2020 17:48:14 +0000 In-Reply-To: Cc: Kent Watsen , "netconf@ietf.org" To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= References: <0100016e93cdb1a3-6544deca-acbe-4c7c-a5eb-5efdbd8fe2c1-000000@email.amazonses.com> <0100016fa62df2a2-005fc9be-4f02-4ba8-b731-1357af75e116-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.01.22-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] update to ssh-server draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 17:48:19 -0000 --Apple-Mail=_4374E242-91D6-4DC3-8CA0-7B928207417D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Balazs, Please see commits from today: = https://github.com/netconf-wg/ssh-client-server/commits/master = As well some comments below. Kent > On Jan 22, 2020, at 4:37 AM, Bal=C3=A1zs Kov=C3=A1cs = wrote: >=20 > Hi Kent, > =20 > See below. > Br, > Balazs > =20 > From: Kent Watsen >=20= > Sent: Tuesday, January 14, 2020 11:30 PM > To: Bal=C3=A1zs Kov=C3=A1cs > > Cc: netconf@ietf.org > Subject: Re: update to ssh-server draft > =20 > =20 > Hi Balazs, > =20 > It is good to see that you're digging into the SSH modules, as they = (and the NETCONF modules) are the only modules that I don't have running = code for... > =20 > Regarding your questions: > =20 >=20 >=20 > I have some difficulties in understanding the intent of the changes = you describe. > =20 > In ietf-ssh-server@2019-11-20: > | +-- supported-authentication-methods > | | +-- publickey? empty > | | +-- passsword? empty > | | +-- hostbased? empty > | | +-- none? empty > | | +-- other* string > =20 > =20 > Why do we bother with the =E2=80=98none=E2=80=99 and the =E2=80=98other=E2= =80=99 methods? =E2=80=98none=E2=80=99 is not recommended, and = =E2=80=98other=E2=80=99 is just simply unknown. > =20 > RE "none": this is defined because it is in RFC 4252. Yes, there's = lots of guidance in that RFC regarding the use of "none", but it is = *supported*... I think what is needed here is a `feature` statement = enabling the server to express if "none" is supported of not - agreed? > =20 > Balazs> Yes, I agree. Feature added. > =20 > RE "other": I don't remember how "other" came to be listed, but it = doesn't appear in RFC 4252 and therefore should be removed (updated in = my local copy). > =20 > Balazs> Yes, please remove =E2=80=98other=E2=80=99. Removed. =20 > =E2=80=98password=E2=80=99 and =E2=80=98publickey=E2=80=99 = authentication configuration is described by RFC7317. I would then = expect reusable (local) definitions to be created in RFC7317, and until = then maybe we should not bother with copying that to the ssh-server = model. Do you really foresee that the system authentication model cannot = be used for SSH? > =20 > System-level and NETCONF-level users may not be the same. I know some = system co-mingle the two while others don't. > =20 > Balazs> Ok, but then I assume the model/format of configuration should = be the same as in RFC7317, right? I think the value typedef's to 'ssh-host-key=E2=80=99 in = ietf-crypto-types. If so, then good, right? > BTW, RFC 4252 says that "password" SHOULD be required, so a `feature` = statement seem warranted. RFC 4252 says that "publickey" is REQUIRED, = so *no* `feature` statement is needed for it. > =20 > Balazs> Ok. Feature added. > Implementing =E2=80=98hostbased=E2=80=99 could maybe make sense. I = assume that requires the use of = =E2=80=98local-or-truststore-host-keys-grouping=E2=80=98 under some = username so that the mapping between key and users can be done (as you = suggested before). The users which are defined here could be = authenticated with hostkeys on top of the RFC7317 users (which can login = with pwd or pubkey). > =20 > RFC 4252 says that this method name is OPTIONAL, and therefore a = `feature` statement seems warranted here as well. > =20 > Yes, it seems that =E2=80=98local-or-truststore-host-keys-grouping=E2=80= =98 would be in play here. > =20 > Balazs> I agree to both. Feature added. Also added =E2=80=98use' of local-or-truststore-host-keys-grouping. > I don't think it needs to be under a username, as the SSH-client still = explicitly sends a username (same as with "none") per RFC 4552 Section = 5. > =20 > Balazs> You have to have a whitelist of users on the server side where = you allow hostbased authentication. The rest of the users should not be = able to login with a host key. We also need to somehow make it possible = to stack authentication methods -> ask more than one for a login to = succeed or whatever other policies are supported in general by an SSH = server. > =20 > https://tools.ietf.org/html/rfc4252#section-4 = > https://man.openbsd.org/sshd_config#AuthenticationMethods = I did not look into this. For now this issue remains open. =20 > I also don=E2=80=99t understand the point in having the feature = =E2=80=98client-auth-config-supported=E2=80=99. The TLS groupings = don=E2=80=99t have this, and also where would the configuration of = ca-certs, client-certs, etc. be if not in this server grouping? > =20 > Please check again, the tls-server-grouping does have = 'client-auth-config-supported' = (https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-17#secti= on-4 = ). > =20 > Answering your last question, note that TLS-level client auth is = optional, as client auth MAY occur at a protocol-layer above TLS. That = said, I'll grant you that this feature may not be ideal as instead, = perhaps, the server could instead rely on *if* any of the descendants = were configured. > =20 > I'm less sure about SSH, but I don't believe that client = authentication can ever occur at a higher-level protocol layer. That = being the case, there's likely a good augment to removing the = "client-auth-config-supported" feature in ietf-ssh-server. =20 > =20 > Balazs> Ok, for TLS you are right, I accidentally missed that. I think = in TLS it is ok as feature for the reasons you had. But in SSH case, = I=E2=80=99ve only seen SSH doing the user authentication as of RFC 4252, = as you said. So I=E2=80=99d vote for not having a feature for SSH client = auth and that something must be configured there. I did not remove the "client-auth-config-supported=E2=80=9D feature. =20 I still believe that the reason stated in the feature's = =E2=80=98description=E2=80=99 statement is valid. Perhaps an = alternative approach to this is to *remove* the =E2=80=98user=E2=80=99 = list node altogether, forcing consuming applications to define their own = strategy for how to authenticate ssh clients. To the application, the = difference is in if the client auth configuration is contained within = the app=E2=80=99s equivalent concept of a =E2=80=9Cuser=E2=80=9D, or if = the app maintains a leafref from its =E2=80=9Cuser=E2=80=9D to the = 'client-authentication/user=E2=80=99 node for these values. Does this = make sense? > Balazs> I=E2=80=99m also thinking if certificate based authentication = should be under the user whitelist, but I=E2=80=99m not very familiar = with RFC6187. Could be, perhaps likely so. If nothing else, it seems the most = conservative thing to do. Kent // contributor --Apple-Mail=_4374E242-91D6-4DC3-8CA0-7B928207417D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Balazs,

Please see = commits from today: https://github.com/netconf-wg/ssh-client-server/commits/master<= /a>

As well = some comments below.

Kent


On Jan = 22, 2020, at 4:37 AM, Bal=C3=A1zs Kov=C3=A1cs <balazs.kovacs@ericsson.com> wrote:

Hi = Kent,
 
See = below.
Br,
Balazs
 
From: Kent Watsen <kent+ietf@watsen.net> 
Sent: Tuesday, January 14, 2020 = 11:30 PM
To: Bal=C3=A1zs Kov=C3=A1cs = <balazs.kovacs@ericsson.com>
Cc: netconf@ietf.org
Subject: Re: update to ssh-server = draft
 
 
Hi Balazs,
 
It is good to see that you're digging = into the SSH modules, as they (and the NETCONF modules) are the only = modules that I don't have running code for...
 
Regarding your questions:
 


I have some difficulties in understanding the = intent of the changes you describe.
 
In = ietf-ssh-server@2019-11-20:
     =
  |  +-- supported-authentication-methods
       |  |  +-- =
publickey?   empty
       =
|  |  +-- passsword?   empty
       |  |  +-- =
hostbased?   empty
       =
|  |  +-- none?        =
empty
       |  |  +-- =
other*       string
 
 
Why do we bother with the =E2=80=98none=E2=80=99 and the = =E2=80=98other=E2=80=99 methods? =E2=80=98none=E2=80=99 is not = recommended, and =E2=80=98other=E2=80=99 is just simply unknown.
 
RE "none": this is defined because it is in RFC = 4252.  Yes, there's lots of guidance in that RFC regarding the use = of "none", but it is *supported*...   I think what is needed here = is a `feature` statement enabling the server to express if "none" is = supported of not - agreed?
 
Balazs> Yes, I = agree.

Feature added.



 
RE "other": I don't remember how "other" came to = be listed, but it doesn't appear in RFC 4252 and therefore should be = removed  (updated in my local copy).
 
Balazs> Yes, please remove = =E2=80=98other=E2=80=99.

Removed.

 
=E2=80=98password=E2=80=99 and =E2=80=98publickey=E2= =80=99 authentication configuration is described by RFC7317. I would = then expect reusable (local) definitions to be created in RFC7317, and = until then maybe we should not bother with copying that to the = ssh-server model. Do you really foresee that the system authentication = model cannot be used for SSH?
 
System-level and NETCONF-level users may not be the same. =  I know some system co-mingle the two while others don't.
 
Balazs> Ok, but then I assume the model/format of = configuration should be the same as in RFC7317, right?

I= think the value typedef's to 'ssh-host-key=E2=80=99 in = ietf-crypto-types.  If so, then good, right?


BTW, RFC 4252 says that "password" = SHOULD be required, so a `feature` statement seem warranted.  RFC = 4252 says that "publickey" is REQUIRED, so *no* `feature` statement is = needed for it.
 
Balazs> Ok.

Feature added.

Implementing =E2=80=98hostbased=E2=80=99 could =
maybe make sense. I assume that requires the use of =
=E2=80=98local-or-truststore-host-keys-grouping=E2=80=98 under some =
username so that the mapping between key and users can be done (as you =
suggested before). The users which are defined here could be =
authenticated with hostkeys on top of the RFC7317 users (which can login =
with pwd or pubkey).
 
RFC 4252 says that this method name is OPTIONAL, = and therefore a `feature` statement seems warranted here as well.
 
Yes, it seems = that =E2=80=98local-or-truststore-host-keys-grouping=E2=80=98 would = be in play here.
 
Balazs> I agree to both.

Feature added.
Also added =E2=80=98use' = of local-or-truststore-host-keys-grouping.


I don't think it = needs to be under a username, as the SSH-client still explicitly sends a = username (same as with "none") per RFC 4552 Section 5.
 
Balazs> You have to have a whitelist = of users on the server side where you allow hostbased authentication. = The rest of the users should not be able to login with a host key. We = also need to somehow make it possible to stack authentication methods = -> ask more than one for a login to succeed or whatever other = policies are supported in general by an SSH server.
 
https://tools.ietf.org/html/rfc4252#section-4
https://man.openbsd.org/sshd_config#AuthenticationMethods

I did = not look into this.  For now this issue remains = open.

 
I also don=E2=80=99t understand the point in =
having the feature =E2=80=98client-auth-config-supported=E2=80=99. =
The TLS groupings don=E2=80=99t have this, and also where =
would the configuration of ca-certs, client-certs, etc. be if not in =
this server grouping?
 
Please check again, the tls-server-grouping does = have 'client-auth-config-supported' (https://tools.ietf.org/html/draft-ietf-netconf-tls-client-serve= r-17#section-4).
 
Answering your last question, note that = TLS-level client auth is optional, as client auth MAY occur at a = protocol-layer above TLS.  That said, I'll grant you that this = feature may not be ideal as instead, perhaps, the server could instead = rely on *if* any of the descendants were configured.
 
I'm less sure about SSH, but I don't = believe that client authentication can ever occur at a higher-level = protocol layer.  That being the case, there's likely a good augment = to removing the "client-auth-config-supported" feature in = ietf-ssh-server.  
 
Balazs> = Ok, for TLS you are right, I accidentally missed that. I think in TLS it = is ok as feature for the reasons you had. But in SSH case, I=E2=80=99ve = only seen SSH doing the user authentication as of RFC 4252, as you said. = So I=E2=80=99d vote for not having a feature for SSH client auth and = that something must be configured = there.

I did not remove the = "client-auth-config-supported=E2=80=9D feature.  

I still believe that the reason stated in the = feature's =E2=80=98description=E2=80=99 statement is valid. =  Perhaps an alternative approach to this is to *remove* the = =E2=80=98user=E2=80=99 list node altogether, forcing consuming = applications to define their own strategy for how to authenticate ssh = clients.  To the application, the difference is in if the client = auth configuration is contained within the app=E2=80=99s equivalent = concept of a =E2=80=9Cuser=E2=80=9D, or if the app maintains a leafref = from its =E2=80=9Cuser=E2=80=9D to the 'client-authentication/user=E2=80=99= node for these values.  Does this make sense?



Balazs> I=E2=80=99m also thinking if certificate based = authentication should be under the user whitelist, but I=E2=80=99m not = very familiar with RFC6187.

Could be, perhaps likely so.  If nothing = else, it seems the most conservative thing to do.


Kent // = contributor







= --Apple-Mail=_4374E242-91D6-4DC3-8CA0-7B928207417D-- From nobody Fri Jan 24 13:31:57 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 531B91209AC for ; Fri, 24 Jan 2020 13:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ElkeXUS5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=n4zngKxf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ep9cFo0YvZJL for ; Fri, 24 Jan 2020 13:31:53 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBC8120884 for ; Fri, 24 Jan 2020 13:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27793; q=dns/txt; s=iport; t=1579901513; x=1581111113; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=78mzCN+qhR8tIbbVj7W4sLQozA8UeJRiuk8nGpXEjEY=; b=ElkeXUS54YURF8LZAroWuuOdT2aEaYKW7PvJcOU3r/cv7mB0Rufm7o/z BPbUCnPMVYDorGcdYOagr01KM2nYlisBI5jWaVzdqDmhiM0WKQKB2U29V Fy09p7gAgW+uu9wEsy62D++QmldW4rFkTNu0ATcZYaNqGjwU0dkWG777l c=; IronPort-PHdr: =?us-ascii?q?9a23=3ANQV1ZBf0j3t19B8t76yicwFFlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTYzHMFLUndu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AAB7YSte/5pdJa1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gSUvJCwFbFggBAsqhBODRgOLEYI6JZgPglI?= =?us-ascii?q?DVAkBAQEMAQEtAgEBhEACF4ILJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQE?= =?us-ascii?q?DEhEdAQE1AgEPAgEIEQMBAQEoAwICAjAUCQgCBAENBRkJgwQBgX1NAy4BomA?= =?us-ascii?q?CgTmIYXWBMoJ/AQEFhRgYggwJgTiMFxqBQT+BOAwUgkw+gmQEggEWgloygiy?= =?us-ascii?q?QVYVeJIlRjzQKgjmNBokxG5p8jmCbDQIEAgQFAg4BAQWBaSIqgS5wFTsqAYJ?= =?us-ascii?q?BUBgNiAE4gzuKU3QCAYEmjA8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,358,1574121600"; d="scan'208,217";a="412936011" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jan 2020 21:31:51 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00OLVpnl004383 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Jan 2020 21:31:51 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 24 Jan 2020 15:31:50 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 24 Jan 2020 15:31:49 -0600 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 24 Jan 2020 15:31:49 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NnprIkCh721kuLDG70GUcdjeNOXHWEnFEwGGAI7jSsJlimlqpCKTDv6CV+wmwAiOgdKmlzYtDdlNKmf1x+lwotUF6niIX3gcaBusMqlCXtmum7mobUB+Z2le4fp9Et2+PwgumD2ExKvIvi+IMppI03z8mQ5Rqonq+FJV06pNFk8GWT+bviBD423RXZgp8S6AD2ODkGKq3sngtDncWW1VXrbB9Qwe8bw4wdhk7syb2U1Z27YnvFvdsPCrj0l+q3f3pFVek1jd/xZ76+wXoOXBGt9xJgGy4mDDXZjGPjwJcqAQzKEp7Mc8ltTfy1C2IJKXcWbjKzgim5zatrICEISZRg== 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=78mzCN+qhR8tIbbVj7W4sLQozA8UeJRiuk8nGpXEjEY=; b=V8yumZXQ3tw309E/w/6L95idEisg11bWJ3TwWliy8v04Ff/WF5X93aC+oLw5n/H7pTXfClWUFHDJkNI7QO+6twSruukJr0GkVKqs0ZOo0ebSprn4CIiEMC0xF66HSQocVjb7WCW5SoLykXiv+nevWQlA7AJlr/7bxipI2GR7FtilnAUObABJ7i4zrzAI9c6fxVcBTV9fp7xl0GDS3WzFyB/Eh4zF4mSVg99BH5nbMKtMVPNvp0K1h+ReUzQDSymt0NS2RmTQe07ZgBcbvfEcchqPavNxJ29syQginSzCdLMkmazZG/j2ISIQADVWYtoGTeQHuxEC/euTWIKecAhVlg== 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=78mzCN+qhR8tIbbVj7W4sLQozA8UeJRiuk8nGpXEjEY=; b=n4zngKxfYgwz2pGDmgryWGUKbWnebl4y6OQ7lyLIL43Dtnr0xqSPfVJ0dvvdmLSGmwyD/TgovjVyn/1Pb2/zOO0KM1AfBGflKZnLLttOg9Van6dJ4Ey1ZifVH098ymEziL3IxleKoDmUynFs8koAz3RbBDXDvaKtlszi1sgeQ2U= Received: from DM5PR11MB1355.namprd11.prod.outlook.com (10.168.103.145) by DM5PR11MB1452.namprd11.prod.outlook.com (10.172.36.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20; Fri, 24 Jan 2020 21:31:48 +0000 Received: from DM5PR11MB1355.namprd11.prod.outlook.com ([fe80::3d45:700d:3f44:243]) by DM5PR11MB1355.namprd11.prod.outlook.com ([fe80::3d45:700d:3f44:243%6]) with mapi id 15.20.2665.017; Fri, 24 Jan 2020 21:31:48 +0000 From: "Reshad Rahman (rrahman)" To: "Rob Wilton (rwilton)" , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt Thread-Index: AQHVxVsT75iyiSEfckqVICMZWQcw1KffZvCAgACw5YCAANxNAIADGDWAgAAJEoCABgLMgIAK/R8AgAHEbwCAA0L5gA== Date: Fri, 24 Jan 2020 21:31:28 +0000 Message-ID: <84FD378C-CF5A-4F0F-9911-8FE9A385095B@cisco.com> References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <0100016f83226d35-4c825571-7fe8-4074-8f6c-d9994e2ed37a-000000@email.amazonses.com> <0100016f901833d0-c822306b-9f2f-4c7b-9444-34742ec35a53-000000@email.amazonses.com> <58F397A3-9E37-4E61-BDEE-C0DAA61B6A3B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:c0c4:1008::491] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 50640adf-3095-4e32-fecc-08d7a114d192 x-ms-traffictypediagnostic: DM5PR11MB1452: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02929ECF07 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(376002)(136003)(366004)(346002)(189003)(199004)(53546011)(33656002)(6506007)(2906002)(2616005)(36756003)(478600001)(8936002)(81166006)(8676002)(6666004)(86362001)(81156014)(5660300002)(4326008)(66476007)(316002)(110136005)(76116006)(64756008)(66946007)(66446008)(66574012)(66556008)(91956017)(186003)(6486002)(6512007)(71200400001)(15650500001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1452; H:DM5PR11MB1355.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EnH/oSQ2KKwN96kIfgD2WngEvYLN8BfawdEBPWk2crG5//wanYpzMn56s0CyLBmA37v0k1qbIkJAQb70aR1C8vMONYhYr6IrL3IO/mUUxdNViXl9b+wudocabswqvmdjpq4y9tPq7TTQxFM5JGSONtZ7UVtDst2QE1qfvovAI3kNjZykZNq9mu81t3HAUn80aNv5XDDcGTTZPMOdWA1x69nq2fZnONkHl7pn9eBHO3L3uOyO5H6RV7bp1T8AjolpQb7gaTEsnfqzj4zUx9DkpdhKkvmBXdVnt/QeRINOlWItj47TZ9RICQZjDOnjj24V8hQVw2Jwzk5huam19hAfCa51STLil1LLgTLF3i3Aej25INaAchjQgJ+1699nNMPwz4Uj3BYOVpWjT3oUE+9kzQscK+NC+AN+J/ktYxpVDqtVvtqH+ssQGzX94XVptn7u x-ms-exchange-antispam-messagedata: uPGEoqqeaAc9yYeRoGe1dfeOxVQrHYuyvYnZuiWfRLrmYMTlSJIjGcItPxEFqGNk5Za2n9DKuRT/qNuBlfL2YB8wX0qvhd7gp/OZmqyzkSU28JtrBlamZNfqaGgQlsc0mvyKAY9f9PXs5LHMCYujC9YuR5sHNVdpd0f1gVbqVJ8= Content-Type: multipart/alternative; boundary="_000_84FD378CCF5A4F0F99118FE9A385095Bciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 50640adf-3095-4e32-fecc-08d7a114d192 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2020 21:31:28.9986 (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: tJ7Zriz37a0Zq1MWRguEns+yGiK9g59ZhK7nU7s3FjOlJCplupPaJL+veHpGV8KXc6yNf4K+Ab+Id5GFv4eDLg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1452 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 21:31:55 -0000 --_000_84FD378CCF5A4F0F99118FE9A385095Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iIGFuZCBCYWxhenMsDQoNCkkgYWdyZWUgdGhhdCB0aGUgcHJldmlvdXMgbWVjaGFuaXNt IHdhcyBlcnJvciBwcm9uZSBpbiB0aGF0IGRpZmZlcmVudCBjbGllbnQgaW1wbGVtZW50YXRpb25z IGNvdWxkIGNvbWUgdG8gZGlmZmVyZW50IHJlc3VsdHMgZGVwZW5kaW5nIG9uIHRoZWlyIGludGVy cHJldGF0aW9uL2ltcGxlbWVudGF0aW9uIG9mIHRoZSBjcml0ZXJpYSBiZWxvdy4NCg0KSXQgaXMg YSBtb290IHBvaW50IG5vdywgYnV0IEkgYmVsaWV2ZSB0aGUgY3JpdGVyaWEgc2hvdWxkIGhhdmUg YmVlbiBiZXN0LW1hdGNoIGFuZCBub3QgbG9uZ2VzdC1tYXRjaC4gTm93IHRoZSBwdWJsaXNoZXIg Y2FuIGJlIG1vcmUgZXhwbGljaXQgYWJvdXQgdGhpcy4NCg0KUmVnYXJkcywNClJlc2hhZC4NCg0K RnJvbTogIlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+DQpEYXRlOiBX ZWRuZXNkYXksIEphbnVhcnkgMjIsIDIwMjAgYXQgOTo0MiBBTQ0KVG86ICJSZXNoYWQgUmFobWFu IChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28uY29tPiwgQmFsw6F6cyBMZW5neWVsIDxiYWxhenMu bGVuZ3llbD00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4sIEtlbnQgV2F0c2VuIDxrZW50 K2lldGZAd2F0c2VuLm5ldD4NCkNjOiAibmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSRTogW25ldGNvbmZdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAtIGRy YWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0aWVzLTA5LnR4dA0KDQpIaSBS ZXNoYWQsDQoNCkluIHJldi05LCBpbiB0aGUgWUFORyBtb2R1bGUgZGVzY3JpcHRpb24sIHRoZXJl IGlzIGEgaGllcmFyY2h5IG9mIHdoaWNoIGNhcGFiaWxpdGllcyBhcHBseSwgYmFzaWNhbGx5IHRo ZSBsb25nZXN0IG1hdGNoIHdpbnM6DQoNCiAgICAgIElmIGEgY2FwYWJpbGl0eSBpcyBzcGVjaWZp ZWQgb24gbXVsdGlwbGUgbGV2ZWxzLCB0aGUNCiAgICAgIHNwZWNpZmljYXRpb24gb24gYSBtb3Jl IHNwZWNpZmljIGxldmVsIG92ZXJyaWRlcyBtb3JlDQogICAgICBnZW5lcmljIGNhcGFiaWxpdHkg c3BlY2lmaWNhdGlvbnM7IHRodXMNCiAgICAgIC0gYSBzeXN0ZW0gbGV2ZWwgc3BlY2lmaWNhdGlv biBpcyBvdmVycmlkZGVuIGJ5IGFueQ0KICAgICAgb3RoZXIgc3BlY2lmaWNhdGlvbg0KICAgICAg LSBhIGRhdGFzdG9yZSBsZXZlbCBzcGVjaWZpY2F0aW9uICh3aXRoIGEgbm9kZS1zZWxlY3RvciAn LycpIGlzDQogICAgICBvdmVycmlkZGVuIGJ5IGEgc3BlY2lmaWNhdGlvbiB3aXRoIGEgbW9yZSBz cGVjaWZpYyBub2RlLXNlbGVjdG9yLg0KICAgICAgLSBhIHNwZWNpZmljYXRpb24gZm9yIGEgc3Bl Y2lmaWMgZGF0YXN0b3JlIGFuZCBub2RlLXNlbGVjdG9yDQogICAgICBpcyBvdmVycmlkZGVuIGJ5 IGEgc3BlY2lmaWNhdGlvbiBmb3IgdGhlIHNhbWUgZGF0YXN0b3JlIHdpdGgNCiAgICAgIGEgbm9k ZS1zZWxlY3RvciB0aGF0IGRlc2NyaWJlcyBtb3JlIGxldmVscyBvZiBjb250YWluaW5nIGxpc3Rz DQogICAgICBhbmQgY29udGFpbmVycy4NCiAgICAgIEl0IGlzIG5vdCBhbGxvd2VkIHRvIGhhdmUg bXVsdGlwbGUgbm9kZSBzZWxlY3RvcnMgd2hpY2gNCiAgICAgIC0gYXJlIGRlZmluZWQgZm9yIHRo ZSBzYW1lIGRhdGFzdG9yZSBBTkQNCiAgICAgIC0gaGF2ZSB0aGUgc2FtZSBudW1iZXIgb2YgY29u dGFpbm1lbnQgbGV2ZWxzIEFORA0KICAgICAgLSBzZWxlY3QgYW4gb3ZlcmxhcHBpbmcgc2V0IG9m IG5vZGVzLg0KDQpCdXQgYXMgc29vbiBhcyB5b3UgYWxsb3cgbW9yZSBjb21wbGV4IHNwZWNpZmlj YXRpb25zIChlLmcuIHBlcmhhcHMgWHBhdGggdG8gc2VsZWN0IHRoZSBzZXQgb2Ygbm9kZXMgdGhh dCBhIGNhcGFiaWxpdHkgYXBwbGllcyB0bykgdGhlbiB3b3JraW5nIG91dCB3aGljaCBlbnRyeSBp cyB0aGUgbG9uZ2VzdCBtYXRjaCBpcyB2ZXJ5IGhhcmQsIGlmIG5vdCBpbXBvc3NpYmxlLiAgSGVu Y2UgbW92aW5nIHRvIGFuIG9yZGVyZWQgbGlzdCAoYXMgcGVyIHRoZSAtMTAgZHJhZnQpIGVuc3Vy ZXMgdGhhdCB0aGUgY2FwYWJpbGl0aWVzIGFyZSBhbHdheXMgZGV0ZXJtaW5pc3RpYy4NCg0KVGhh bmtzLA0KUm9iDQoNCg0KRnJvbTogUmVzaGFkIFJhaG1hbiAocnJhaG1hbikgPHJyYWhtYW5AY2lz Y28uY29tPg0KU2VudDogMjEgSmFudWFyeSAyMDIwIDE2OjQ0DQpUbzogQmFsw6F6cyBMZW5neWVs IDxiYWxhenMubGVuZ3llbD00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz47IFJvYiBXaWx0 b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47IEtlbnQgV2F0c2VuIDxrZW50K2lldGZA d2F0c2VuLm5ldD4NCkNjOiBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldGNvbmZd IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRp b24tY2FwYWJpbGl0aWVzLTA5LnR4dA0KDQpIaSwNCg0KUmVnYXJkaW5nIHRoZSBjaGFuZ2UgYmVs b3cgKHdoaWNoIHdhcyBhZGRlZCBpbiByZXYtMTApIHRvIG1hdGNoIGJ5IG9yZGVyLCB3YXMgdGhp cyBkb25lIGp1c3QgdG8gbWFrZSBsaWZlIGVhc2llciBmb3IgdGhlIGNsaWVudCAodGhlIHB1Ymxp c2hlciBpcyBkZWNpZGluZyB3aGF04oCZcyB0aGUgYmVzdCBtYXRjaCkgb3IgaXMgdGhlcmUgYW5v dGhlciBtb3RpdmF0aW9uPyBJIHRoaW5rIHRoaXMgaXMgYSBnb29kIGNoYW5nZSwgYnV0IGN1cmlv dXMgYXMgdG8gdGhlIHJlYXNvbi4NCg0KUmVnYXJkcywNClJlc2hhZC4NCg0KRnJvbTogbmV0Y29u ZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQmFsw6F6cyBMZW5neWVs IDxiYWxhenMubGVuZ3llbD00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IFR1 ZXNkYXksIEphbnVhcnkgMTQsIDIwMjAgYXQgNjo1NSBBTQ0KVG86ICJSb2IgV2lsdG9uIChyd2ls dG9uKSIgPHJ3aWx0b25AY2lzY28uY29tPiwgS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4u bmV0Pg0KQ2M6ICJuZXRjb25mQGlldGYub3JnIiA8bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbbmV0Y29uZl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0Zi1uZXRj b25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMDkudHh0DQoNCk9LLiBGb3IgYm90aC4NClJl Z2FyZHMgQmFsYXpzDQoNCkZyb206IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2Nv LmNvbT4NClNlbnQ6IDIwMjAuIGphbnXDoXIgMTAuLCBww6ludGVrIDE3OjA4DQpUbzogS2VudCBX YXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PjsgQmFsw6F6cyBMZW5neWVsIDxiYWxhenMubGVu Z3llbEBlcmljc3Nvbi5jb20+DQpDYzogbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtu ZXRjb25mXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gLSBkcmFmdC1pZXRmLW5ldGNvbmYtbm90 aWZpY2F0aW9uLWNhcGFiaWxpdGllcy0wOS50eHQNCg0KSGkgS2VudCwgQmFsYXpzLA0KDQpZZXMs IEkgdGhpbmsgdGhhdCB0aGlzIHdvdWxkIHdvcmssIGJ1dCBtaWdodCBhbHNvIG5lZWQgdG8gY2hh bmdlIHRoZSBydWxlIGZyb20gbWF0Y2hpbmcgdGhlIGNhcGFiaWxpdGllcyBmcm9tIHRoZSBsb25n ZXN0IG5vZGUgcGF0aCwgdG8gdGhlIG9yZGVyIHRoYXQgdGhlIGVudHJpZXMgYXJlIGluIHRoZSBs aXN0LiAgRS5nLiB0aGUgY2FwYWJpbGl0aWVzIGFyZSBkZWNpZGVkIGJ5IHRoZSBmaXJzdCBlbnRy eSBpbiB0aGUgbGlzdCB0aGF0IG1hdGNoZXMgdGhlIGdpdmVuIHBhdGguICBUaGUgZXhpc3Rpbmcg bG9uZ2VzdCBub2RlIHBhdGggYmVoYXZpb3VyIGNhbiBlZmZlY3RpdmVseSBiZSBpbXBsZW1lbnRl ZCBieSBvcmRlcmluZyB0aGUgbW9yZSBzcGVjaWZpYyBub2RlIHBhdGhzIGJlZm9yZSB0aGUgbGVz cyBzcGVjaWZpYyBub2RlIHBhdGhzLg0KDQpXb3VsZCB0aGF0IGJlIGFjY2VwdGFibGU/DQoNCkkg d291bGQgYWxzbyBzdWdnZXN0IGdpdmluZyB0aGUgY2hvaWNlIGFuZCB0aGUgbGVhZiBhIHNlcGFy YXRlIG5hbWUgYmVsb3cuDQoNClRoYW5rcywNClJvYg0KDQoNCkZyb206IEtlbnQgV2F0c2VuIDxr ZW50K2lldGZAd2F0c2VuLm5ldDxtYWlsdG86a2VudCtpZXRmQHdhdHNlbi5uZXQ+Pg0KU2VudDog MTAgSmFudWFyeSAyMDIwIDE1OjM1DQpUbzogQmFsw6F6cyBMZW5neWVsIDxiYWxhenMubGVuZ3ll bEBlcmljc3Nvbi5jb208bWFpbHRvOmJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbT4+DQpDYzog Um9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9uQGNp c2NvLmNvbT4+OyBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtuZXRjb25mXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gLSBkcmFmdC1pZXRm LW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGllcy0wOS50eHQNCg0KDQpIaSBCYWxhenMs DQoNCg0KDQoNCldvdWxkIHRoZSBmb2xsb3dpbmcgYmUgYWNjZXB0YWJsZT8NCk9MRDoNCiAgICAg bGlzdCBwZXItbm9kZS1jYXBhYmlsaXRpZXMgew0KICAgICAgIGtleSAibm9kZS1zZWxlY3RvciI7 DQogICAgICAgbGVhZiBub2RlLXNlbGVjdG9yIHsNCiAgICAgICAgIHR5cGUgbmFjbTpub2RlLWlu c3RhbmNlLWlkZW50aWZpZXI7DQpORVc6DQogICAgIGxpc3QgcGVyLW5vZGUtY2FwYWJpbGl0aWVz IHsNCiAgICAgICBjaG9pY2Ugbm9kZS1zZWxlY3RvciB7DQogICAgICAgICAgICAgbGVhZiBub2Rl LXNlbGVjdG9yIHsgICB0eXBlIG5hY206bm9kZS1pbnN0YW5jZS1pZGVudGlmaWVyOyAgfQ0KICAg ICB9DQoNCkxhdGVyIHlvdSBjYW4gYXVnbWVudCBpbiBhbiBYcGF0aCBmaWx0ZXIgb3IgYSBzdHJp bmcgd2l0aCAnKicgYW5kICc/JyB3aWxkY2FyZHMgb3Igd2hhdGV2ZXIgeW91IHdhbnQuDQooVGhl IGxpc3QgZG9lcyBub3QgbmVlZCBhIGtleSBhcyBpdCBpcyBjb25maWc9ZmFsc2UpDQoNCg0KWWVz LCB0aGlzIGlzIGlubGluZSB3aXRoIHdoYXQgSSBoYWQgaW4gbWluZCBidXQsIHNpbmNlIHRoaXMg d2FzIG15IHN1Z2dlc3Rpb24sIEkgd2FzIGhvcGluZyB0aGF0IFJvYiBvciBvdGhlcnMgd291bGQg cmVwbHkuDQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0KDQo= --_000_84FD378CCF5A4F0F99118FE9A385095Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <46D11FA495E9CF43A1F90D1348C0C4B0@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNw YW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBSb2IgYW5kIEJh bGF6cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYWdyZWUgdGhhdCB0aGUgcHJldmlvdXMgbWVjaGFu aXNtIHdhcyBlcnJvciBwcm9uZSBpbiB0aGF0IGRpZmZlcmVudCBjbGllbnQgaW1wbGVtZW50YXRp b25zIGNvdWxkIGNvbWUgdG8gZGlmZmVyZW50IHJlc3VsdHMgZGVwZW5kaW5nIG9uIHRoZWlyIGlu dGVycHJldGF0aW9uL2ltcGxlbWVudGF0aW9uIG9mIHRoZSBjcml0ZXJpYSBiZWxvdy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkl0IGlzIGEgbW9vdCBwb2ludCBub3csIGJ1dCBJIGJlbGlldmUgdGhlIGNy aXRlcmlhIHNob3VsZCBoYXZlIGJlZW4gYmVzdC1tYXRjaCBhbmQgbm90IGxvbmdlc3QtbWF0Y2gu IE5vdyB0aGUgcHVibGlzaGVyIGNhbiBiZSBtb3JlIGV4cGxpY2l0IGFib3V0IHRoaXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXNoYWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9t OiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4m cXVvdDtSb2IgV2lsdG9uIChyd2lsdG9uKSZxdW90OyAmbHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgSmFudWFyeSAyMiwgMjAyMCBhdCA5OjQyIEFN PGJyPg0KPGI+VG86IDwvYj4mcXVvdDtSZXNoYWQgUmFobWFuIChycmFobWFuKSZxdW90OyAmbHQ7 cnJhaG1hbkBjaXNjby5jb20mZ3Q7LCBCYWzDoXpzIExlbmd5ZWwgJmx0O2JhbGF6cy5sZW5neWVs PTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnJmd0OywgS2VudCBXYXRzZW4gJmx0O2tlbnQm IzQzO2lldGZAd2F0c2VuLm5ldCZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O25ldGNvbmZAaWV0 Zi5vcmcmcXVvdDsgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PlJFOiBbbmV0Y29uZl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0Zi1uZXRj b25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMDkudHh0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJlc2hhZCw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SW4gcmV2LTksIGluIHRoZSBZQU5HIG1vZHVsZSBkZXNjcmlwdGlvbiwgdGhl cmUgaXMgYSBoaWVyYXJjaHkgb2Ygd2hpY2ggY2FwYWJpbGl0aWVzIGFwcGx5LCBiYXNpY2FsbHkg dGhlIGxvbmdlc3QgbWF0Y2ggd2luczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu Zzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1h bGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZiBhIGNhcGFiaWxp dHkgaXMgc3BlY2lmaWVkIG9uIG11bHRpcGxlIGxldmVscywgdGhlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFj a2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbiBvbiBhIG1vcmUgc3BlY2lmaWMgbGV2 ZWwgb3ZlcnJpZGVzIG1vcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1i cmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBn ZW5lcmljIGNhcGFiaWxpdHkgc3BlY2lmaWNhdGlvbnM7IHRodXM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNr Z3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtIGEgc3lzdGVtIGxldmVsIHNwZWNpZmljYXRpb24gaXMgb3Zl cnJpZGRlbiBieSBhbnk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVh azpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvdGhl ciBzcGVjaWZpY2F0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJl YWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBh IGRhdGFzdG9yZSBsZXZlbCBzcGVjaWZpY2F0aW9uICh3aXRoIGEgbm9kZS1zZWxlY3RvciAnLycp IGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3ZlcnJpZGRlbiBieSBh IHNwZWNpZmljYXRpb24gd2l0aCBhIG1vcmUgc3BlY2lmaWMgbm9kZS1zZWxlY3Rvci48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIGEgc3BlY2lmaWNhdGlvbiBmb3IgYSBz cGVjaWZpYyBkYXRhc3RvcmUgYW5kIG5vZGUtc2VsZWN0b3I8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBpcyBvdmVycmlkZGVuIGJ5IGEgc3BlY2lmaWNhdGlvbiBmb3IgdGhl IHNhbWUgZGF0YXN0b3JlIHdpdGg8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29y ZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBhIG5vZGUtc2VsZWN0b3IgdGhhdCBkZXNjcmliZXMgbW9yZSBsZXZlbHMgb2YgY29udGFpbmlu ZyBsaXN0czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr LWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCBjb250YWlu ZXJzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs bCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0IGlzIG5vdCBhbGxv d2VkIHRvIGhhdmUgbXVsdGlwbGUgbm9kZSBzZWxlY3RvcnMgd2hpY2g8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDti YWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIGFyZSBkZWZpbmVkIGZvciB0aGUgc2FtZSBkYXRhc3Rv cmUgQU5EPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWst YWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBoYXZlIHRoZSBz YW1lIG51bWJlciBvZiBjb250YWlubWVudCBsZXZlbHMgQU5EPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dy b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLSBzZWxlY3QgYW4gb3ZlcmxhcHBpbmcgc2V0IG9mIG5vZGVzLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgYXMgc29vbiBhcyB5b3Ug YWxsb3cgbW9yZSBjb21wbGV4IHNwZWNpZmljYXRpb25zIChlLmcuIHBlcmhhcHMgWHBhdGggdG8g c2VsZWN0IHRoZSBzZXQgb2Ygbm9kZXMgdGhhdCBhIGNhcGFiaWxpdHkgYXBwbGllcyB0bykgdGhl biB3b3JraW5nIG91dCB3aGljaCBlbnRyeSBpcyB0aGUgbG9uZ2VzdCBtYXRjaCBpcyB2ZXJ5IGhh cmQsIGlmIG5vdCBpbXBvc3NpYmxlLiZuYnNwOyBIZW5jZSBtb3ZpbmcgdG8gYW4gb3JkZXJlZA0K IGxpc3QgKGFzIHBlciB0aGUgLTEwIGRyYWZ0KSBlbnN1cmVzIHRoYXQgdGhlIGNhcGFiaWxpdGll cyBhcmUgYWx3YXlzIGRldGVybWluaXN0aWMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r cyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvYjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+ IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pICZsdDtycmFobWFuQGNpc2NvLmNvbSZndDsNCjxicj4N CjxiPlNlbnQ6PC9iPiAyMSBKYW51YXJ5IDIwMjAgMTY6NDQ8YnI+DQo8Yj5Ubzo8L2I+IEJhbMOh enMgTGVuZ3llbCAmbHQ7YmFsYXpzLmxlbmd5ZWw9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5v cmcmZ3Q7OyBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7OyBL ZW50IFdhdHNlbiAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldGNvbmZdIE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24t Y2FwYWJpbGl0aWVzLTA5LnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2Fy ZGluZyB0aGUgY2hhbmdlIGJlbG93ICh3aGljaCB3YXMgYWRkZWQgaW4gcmV2LTEwKSB0byBtYXRj aCBieSBvcmRlciwgd2FzIHRoaXMgZG9uZSBqdXN0IHRvIG1ha2UgbGlmZSBlYXNpZXIgZm9yIHRo ZSBjbGllbnQgKHRoZSBwdWJsaXNoZXIgaXMgZGVjaWRpbmcgd2hhdOKAmXMgdGhlIGJlc3QgbWF0 Y2gpIG9yIGlzIHRoZXJlIGFub3RoZXIgbW90aXZhdGlvbj8gSSB0aGluaw0KIHRoaXMgaXMgYSBn b29kIGNoYW5nZSwgYnV0IGN1cmlvdXMgYXMgdG8gdGhlIHJlYXNvbi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlJlc2hhZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPm5ldGNvbmYgJmx0 O25ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEJhbMOhenMgTGVuZ3ll bCAmbHQ7YmFsYXpzLmxlbmd5ZWw9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEphbnVhcnkgMTQsIDIwMjAgYXQgNjo1NSBBTTxicj4N CjxiPlRvOiA8L2I+JnF1b3Q7Um9iIFdpbHRvbiAocndpbHRvbikmcXVvdDsgJmx0O3J3aWx0b25A Y2lzY28uY29tJmd0OywgS2VudCBXYXRzZW4gJmx0O2tlbnQmIzQzO2lldGZAd2F0c2VuLm5ldCZn dDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O25ldGNvbmZAaWV0Zi5vcmcmcXVvdDsgJmx0O25ldGNv bmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbbmV0Y29uZl0gTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBh YmlsaXRpZXMtMDkudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9LLiBGb3IgYm90aC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJlZ2FyZHMgQmFsYXpzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUm9iIFdpbHRvbiAocndpbHRvbikg Jmx0O3J3aWx0b25AY2lzY28uY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gMjAyMC4gamFudcOh ciAxMC4sIHDDqW50ZWsgMTc6MDg8YnI+DQo8Yj5Ubzo8L2I+IEtlbnQgV2F0c2VuICZsdDtrZW50 JiM0MztpZXRmQHdhdHNlbi5uZXQmZ3Q7OyBCYWzDoXpzIExlbmd5ZWwgJmx0O2JhbGF6cy5sZW5n eWVsQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtuZXRjb25mXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g LSBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGllcy0wOS50eHQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEtlbnQsIEJhbGF6cyw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBJIHRoaW5rIHRoYXQgdGhpcyB3b3VsZCB3b3JrLCBi dXQgbWlnaHQgYWxzbyBuZWVkIHRvIGNoYW5nZSB0aGUgcnVsZSBmcm9tIG1hdGNoaW5nIHRoZSBj YXBhYmlsaXRpZXMgZnJvbSB0aGUgbG9uZ2VzdCBub2RlIHBhdGgsIHRvIHRoZSBvcmRlciB0aGF0 IHRoZSBlbnRyaWVzIGFyZSBpbiB0aGUgbGlzdC4mbmJzcDsgRS5nLiB0aGUgY2FwYWJpbGl0aWVz IGFyZSBkZWNpZGVkIGJ5IHRoZSBmaXJzdCBlbnRyeSBpbg0KIHRoZSBsaXN0IHRoYXQgbWF0Y2hl cyB0aGUgZ2l2ZW4gcGF0aC4mbmJzcDsgVGhlIGV4aXN0aW5nIGxvbmdlc3Qgbm9kZSBwYXRoIGJl aGF2aW91ciBjYW4gZWZmZWN0aXZlbHkgYmUgaW1wbGVtZW50ZWQgYnkgb3JkZXJpbmcgdGhlIG1v cmUgc3BlY2lmaWMgbm9kZSBwYXRocyBiZWZvcmUgdGhlIGxlc3Mgc3BlY2lmaWMgbm9kZSBwYXRo cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGQgdGhhdCBiZSBhY2NlcHRhYmxlPzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGFsc28gc3VnZ2VzdCBnaXZpbmcgdGhlIGNob2lj ZSBhbmQgdGhlIGxlYWYgYSBzZXBhcmF0ZSBuYW1lIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb2I8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkZyb206PC9iPiBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtl bnQmIzQzO2lldGZAd2F0c2VuLm5ldCI+a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0PC9hPiZndDsN Cjxicj4NCjxiPlNlbnQ6PC9iPiAxMCBKYW51YXJ5IDIwMjAgMTU6MzU8YnI+DQo8Yj5Ubzo8L2I+ IEJhbMOhenMgTGVuZ3llbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhbGF6cy5sZW5neWVsQGVyaWNz c29uLmNvbSI+YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8 L2I+IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNj by5jb20iPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bmV0Y29u ZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtuZXRjb25mXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gLSBkcmFmdC1pZXRmLW5ldGNvbmYt bm90aWZpY2F0aW9uLWNhcGFiaWxpdGllcy0wOS50eHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhpIEJhbGF6cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Xb3VsZCB0aGUgZm9sbG93aW5nIGJlIGFjY2VwdGFibGU/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9MRDo8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtsaXN0IHBlci1ub2RlLWNhcGFiaWxpdGll cyB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7a2V5ICZx dW90O25vZGUtc2VsZWN0b3ImcXVvdDs7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7bGVhZiBub2RlLXNlbGVjdG9yIHs8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0eXBlIG5hY206bm9kZS1pbnN0 YW5jZS1pZGVudGlmaWVyOzxicj4NCk5FVzo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtsaXN0IHBlci1ub2RlLWNhcGFiaWxpdGllcyB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2hvaWNlIG5vZGUtc2VsZWN0b3Igezxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3Bh biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5sZWFmIG5vZGUt c2VsZWN0b3IgeyAmbmJzcDsmbmJzcDt0eXBlIG5hY206bm9kZS1pbnN0YW5jZS1pZGVudGlmaWVy OyAmbmJzcDt9PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTxicj4NCjxicj4N CkxhdGVyIHlvdSBjYW4gYXVnbWVudCBpbiBhbiBYcGF0aCBmaWx0ZXIgb3IgYSBzdHJpbmcgd2l0 aCAnKicgYW5kICc/JyB3aWxkY2FyZHMgb3Igd2hhdGV2ZXIgeW91IHdhbnQuPGJyPg0KKFRoZSBs aXN0IGRvZXMgbm90IG5lZWQgYSBrZXkgYXMgaXQgaXMgY29uZmlnPWZhbHNlKTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVz LCB0aGlzIGlzIGlubGluZSB3aXRoIHdoYXQgSSBoYWQgaW4gbWluZCBidXQsIHNpbmNlIHRoaXMg d2FzIG15IHN1Z2dlc3Rpb24sIEkgd2FzIGhvcGluZyB0aGF0IFJvYiBvciBvdGhlcnMgd291bGQg cmVwbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPktlbnQgLy8gY29udHJpYnV0b3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_84FD378CCF5A4F0F99118FE9A385095Bciscocom_-- From nobody Sat Jan 25 08:23:15 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 59276120074 for ; Sat, 25 Jan 2020 08:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=dwjt4yEF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ojpq6PUI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBxNWgt1VHPq for ; Sat, 25 Jan 2020 08:23:10 -0800 (PST) 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 C6814120025 for ; Sat, 25 Jan 2020 08:23:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4516; q=dns/txt; s=iport; t=1579969390; x=1581178990; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Src8+OAoIknF8mlkcwxRJ0TXhbVlv8F9eK/rklRbhHQ=; b=dwjt4yEFxLxH39K0cyR3qpm0P7wNlb1QbDZ8bs3xYYIoiIWx2RhxnyXO tCLsg8NmDEyEBoPjdtXcFWwH1j9Q3/wko17mlqVd0Xx51U9bAl1xGKvca dVEA0sWJyeI6wqTgtdFVJp93Fy/GpF6/IpUQ2gOkjSlAEaip4rjkNV+q2 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AH01uAx3YXKONst+NsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1fyLPvjaQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSBQCjaixe/4cNJK1lHQEBAQkBEQU?= =?us-ascii?q?FAYFqBQELAYFTUAVsWCAECyqEFINGA4sTTpogglIDVAkBAQEMAQEYDQgCAQG?= =?us-ascii?q?De0UCF4ILJDcGDgIDDQEBBAEBAQIBBQRthQsGJgyFXwIBAwEBEBERDAEBLAk?= =?us-ascii?q?DDwIBCBoCCR0CAgIlCxUQAgQBEiKDBAGCSgMuAQIMoCICgTmIYXWBMoJ/AQE?= =?us-ascii?q?FgTMCDkGDERiCDAmBDioBjB0agUE/gTgggkw+gmQBAQIBARiBXoJ5MoIskFW?= =?us-ascii?q?fBwqCOYdCjnUbgkh4hxKQKo5giGSSKQIEAgQFAg4BAQWBaCOBWHAVGiEqAYJ?= =?us-ascii?q?BCUcYDYhwinyDc4UUhT90gSmNAwEB?= X-IronPort-AV: E=Sophos;i="5.70,361,1574121600"; d="scan'208";a="707449882" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jan 2020 16:23:09 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 00PGN9qs010964 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 25 Jan 2020 16:23:09 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 25 Jan 2020 10:23:08 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 25 Jan 2020 10:23:08 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 25 Jan 2020 11:23:07 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m/xG84kwdcQs/Y0hXJ8p86ieSNc0LlZcgX3OThtz6M2oiHIjBeI+ldMb40heqfbC/nhS75BG0lUviWMOIc4yacep3iZfYXokcOlq/CUqXt11hhGQdHEqNjHtTuLBIdYMgV38H3WlLfkKApEX6TG3AjPc/lcRaG9uYWD3GACkQdgNxdkQU/kkATfHJM+w7yYZl0TRzC5OwbSOJTnYZv5fN2WqLefL1xDbHiltpaTaKfZM7+29nkJaoEiF8RDBwMuQqVCzLCuUuoGXar86j9jbXQymfQDEwybs6BNOQfMITCFZtpGKsnN5GERifMAV+g5XcHgCbx1EluDKXBUHCTr/Pg== 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=Src8+OAoIknF8mlkcwxRJ0TXhbVlv8F9eK/rklRbhHQ=; b=GG8mesHA8CWibmBa3T9vV5Inf3/g9BGVChfxLdqakACKwsjoxkFblWiK10wAWyeXJjSrE4jmg80RwMt8OOB0gECCPDBwYxX/iUr5ji0x0xpj1U0WObJg73g9QuShA40noVIMpOFiwEVN87FE027NR+xh9ImcRj3Auult0Epll+GgBnb3xR2bQe+q5ZKiQncJrHRoUXYxr1r5EnWi7iMCWToVkJzWR26wySXqjbijVDqdqYsgHr9IRwqMT04Hz1GzA0FAtr58xfxuQbb+lG00MObKFOwaLbJXOf8dEJw9pBRc4oy9uKewqFnNjQdBAWl+6Pkor7izD9wa4Xh5NGkd/w== 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=Src8+OAoIknF8mlkcwxRJ0TXhbVlv8F9eK/rklRbhHQ=; b=ojpq6PUIcYjw1scLNrpHhk4/PW8IEuFG3pwHIhk/5RONih5hPQ/m3VAcKGHZvpALZVHZ8R5rXEc+JU/JbP97b6/EBOC3Nf3HORyTgMM2QM+bybK8damd1JSCW+cKEimLfwNLQJvQFZUL7uBSicx4LUGOPW2HP6D6FqDgfYz06zs= Received: from DM6PR11MB3420.namprd11.prod.outlook.com (20.177.218.95) by DM6PR11MB3019.namprd11.prod.outlook.com (20.177.217.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.24; Sat, 25 Jan 2020 16:23:06 +0000 Received: from DM6PR11MB3420.namprd11.prod.outlook.com ([fe80::9dfc:c03f:8638:25b1]) by DM6PR11MB3420.namprd11.prod.outlook.com ([fe80::9dfc:c03f:8638:25b1%6]) with mapi id 15.20.2644.028; Sat, 25 Jan 2020 16:23:06 +0000 From: "Reshad Rahman (rrahman)" To: "netconf@ietf.org" , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= Thread-Topic: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-10.txt Thread-Index: AQHVzICP2tQXo+LVnUezGkHDlFwlsKf7Sp0A Date: Sat, 25 Jan 2020 16:23:06 +0000 Message-ID: <4E44FB5B-799A-49CD-95DA-C81D8B5EEE31@cisco.com> References: <157918802007.26211.15290734681239936924@ietfa.amsl.com> In-Reply-To: <157918802007.26211.15290734681239936924@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:c0c4:1001::1d1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4558bebb-b1e0-4a5e-d164-08d7a1b2dc2b x-ms-traffictypediagnostic: DM6PR11MB3019: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0293D40691 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(346002)(376002)(396003)(39860400002)(189003)(199004)(966005)(186003)(15650500001)(86362001)(2616005)(2906002)(6506007)(66446008)(64756008)(66476007)(91956017)(66556008)(76116006)(478600001)(66946007)(8936002)(6486002)(81156014)(6512007)(8676002)(81166006)(316002)(36756003)(33656002)(71200400001)(66574012)(110136005)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3019; H:DM6PR11MB3420.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kXNtDxgOUFAl/KIMVvNRFdatcbj2yj4mxjs/h07s0FLWXEyUKhabV7n8f0biEIs2vlsX/TSRElTE5b0w17JaYNSKRfiFb8xEQEiZMqAudkBpXAdOAkRQCHLSNO5ib3Aq548xbk7NPSGxYGaRYmuCQBk/o7iUneR8Xp0yEyMPbAFKbjdFpSHJoMVcYVqPR3BQEhGUojJF38Et92SkZn9O9wLsF6ixRimdoLZ6QqHengp6O4Dpf9FOlkV8ml2RiRaiJ8GrzoIuQCfCjcDjLns5yaZMP0xAJx3PJW/Zk4gGDSB+q3wOxI38Vtkxkw0ngs1Dk5l9O8cASD5x5M/lgvH+5d8XoyyTB0XwcTu7LuFXalzdIql5OFLCM12mEZmsVdyb+ptRFrOp9PbZITFkiOycoWseCw1Ggwk9DMeK4ctFawKyx9q+3JnvlCN+V9Xna19+9aaJW2NjX6GpeYqdoS+eKtTD1Xh4IGplNnflVuSif/M= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5753ECA0551C8A4E956478F27D299BB9@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4558bebb-b1e0-4a5e-d164-08d7a1b2dc2b X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2020 16:23:06.5334 (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: E1n5mf6Jlg2JTHyf94IikrA7F+DU8twxUXz5MsixVsIEWbIj9l0TpAQNEESTs5w39w/TE8I+S+nDRyVXJdtxSA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3019 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-10.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2020 16:23:13 -0000 SGkgQmFsYXpzLA0KDQpRdWVzdGlvbnMvY29tbWVudHMgb24gdGhlIGV4YW1wbGVzOg0KLSBNeSBt YWluIGNvbW1lbnQgaXMgdGhhdCB0aGUgZXhhbXBsZSBzZWN0aW9uIG5lZWRzIHRvIGJlIGV4dGVu ZGVkIHRvIGFkZHJlc3MgbW9yZSB1c2UtY2FzZXMuIE9uZSBvZiB0aGUgcmVhc29ucyB3ZSBkaWRu J3QgZ28gd2l0aCBZQU5HIG1vZGVsIGFubm90YXRpb24gaXMgdGhlIG5lZWQgdG8gZXhwcmVzcyBj YXBhYmlsaXRpZXMgcGVyLWluc3RhbmNlLCB3ZSBzaG91bGQgaGF2ZSBhbiBleGFtcGxlIHRvIGls bHVzdHJhdGUgdGhhdC4gKGUuZy4gd2hlcmUgMSBpbnRlcmZhY2UgaGFzIGRpZmZlcmVudCBvbi1j aGFuZ2UgY2FwYWJpbGl0aWVzIHRoYW4gdGhlIGRlZmF1bHQvb3RoZXJzKS4NCi0gUGFnZSAxOS0y MCBib3RoIGV4YW1wbGVzIGhhdmUgcnVubmluZyBkYXRhc3RvcmUgb24tY2hhbmdlLXN1cHBvcnRl ZCBzZXQgdG8gImNvbmZpZy1jaGFuZ2VzIHN0YXRlLWNoYW5nZXMiLiBJIGRvbid0IHRoaW5rIHN0 YXRlLWNoYW5nZXMgbWFrZXMgc2Vuc2UgZm9yIHJ1bm5pbmcgc2luY2Ugc3RhdGUtY2hhbmdlcyBp cyBmb3IgY29uZmlnIGZhbHNlIG5vZGVzPw0KLSBJbiB0aGUgMm5kIGV4YW1wbGUsIHdoeSAiY29u ZmlnLWNoYW5nZXMiIGZvciBpbi1vY3RldHMgYW5kIG91dC1vY3RldHMsIHNob3VsZCBiZSBzdGF0 ZS1jaGFuZ2VzIG9ubHk/DQotIFBhZ2UgMjEgdGhlIDJuZCBleGFtcGxlIGhhcyB0aGlzOiAvaWY6 aW50ZXJmYWNlcy9pZjppbnRlcmZhY2UvaWY6c3RhdGlzdGljczwvbm9kZS1zZWxlY3Rvcj4sIHR5 cG8/IA0KLSBTZWNvbmQgZXhhbXBsZSwgZG8gd2UgbmVlZCBhIG5vZGUtc2VsZWN0b3IgIGVudHJ5 IHRvIGluZGljYXRlIHRoYXQgZGF0YXN0b3JlIHN1YnNjcmlwdGlvbiBjYXBhYmlsaXRpZXMgYXJl IG5vdCByZXBvcnRlZCBvbi1jaGFuZ2U/IEFuZCBhbiBlbnRyeSBmb3IgLyB0byBpbmRpY2F0ZSB0 aGF0IG9wZXJhdGlvbmFsIGlzIG9uLWNoYW5nZSBjYXBhYmxlIChhcyBpbiBleGFtcGxlIDEpPw0K DQpSZWdhcmRzLA0KUmVzaGFkLg0KDQrvu79PbiAyMDIwLTAxLTE2LCAxMDoyMSBBTSwgIm5ldGNv bmYgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPG5ldGNvbmYtYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToN Cg0KICAgIA0KICAgIEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv bi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICBUaGlzIGRyYWZ0IGlzIGEg d29yayBpdGVtIG9mIHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gV0cgb2YgdGhlIElFVEYuDQog ICAgDQogICAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBHZW5lcmljIFlBTkctcmVsYXRlZCBT eXN0ZW0gQ2FwYWJpbGl0aWVzIGFuZCBZQU5HLVB1c2ggTm90aWZpY2F0aW9uIENhcGFiaWxpdGll cw0KICAgICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogQmFsYXpzIExlbmd5ZWwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEFsZXhhbmRlciBDbGVtbQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQmVub2l0IENsYWlzZQ0KICAgIAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1p ZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGllcy0xMC50eHQNCiAgICAJUGFnZXMg ICAgICAgICAgIDogMjMNCiAgICAJRGF0ZSAgICAgICAgICAgIDogMjAyMC0wMS0xNQ0KICAgIA0K ICAgIEFic3RyYWN0Og0KICAgICAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdHdvIFlBTkcgbW9k dWxlcy4gIFRoZSBtb2R1bGUgaWV0Zi1zeXN0ZW0tDQogICAgICAgY2FwYWJpbGl0aWVzIHByb3Zp ZGVzIGEgc3RydWN0dXJlIHRoYXQgY2FuIGJlIHVzZWQgdG8gc3BlY2lmeSBhbnkNCiAgICAgICBZ QU5HIHJlbGF0ZWQgc3lzdGVtIGNhcGFiaWxpdHkuDQogICAgDQogICAgICAgVGhlIG1vZHVsZSBp ZXRmLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMgYWxsb3dzIGEgcHVibGlzaGVyIHRvDQogICAg ICAgc3BlY2lmeSBjYXBhYmlsaXRpZXMgcmVsYXRlZCB0byAiU3Vic2NyaXB0aW9uIHRvIFlBTkcg RGF0YXN0b3JlcyINCiAgICAgICAoWUFORy1QdXNoKS4gIEl0IHByb3Bvc2VzIHRvIHVzZSBZQU5H IEluc3RhbmNlIERhdGEgdG8gZG9jdW1lbnQgdGhpcw0KICAgICAgIGluZm9ybWF0aW9uIGFuZCBt YWtlIGl0IGFscmVhZHkgYXZhaWxhYmxlIGF0IGltcGxlbWVudGF0aW9uLXRpbWUsIGJ1dA0KICAg ICAgIGFsc28gYWxsb3cgaXQgdG8gYmUgcmVwb3J0ZWQgYXQgcnVuLXRpbWUuDQogICAgDQogICAg DQogICAgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25m LW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMvDQogICAgDQogICAgVGhlcmUgYXJlIGFsc28gaHRt bGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGllcy0xMA0KICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25m LW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMTANCiAgICANCiAgICBBIGRpZmYgZnJvbSB0aGUg cHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0 aWVzLTEwDQogICAgDQogICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQogICAgDQogICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Og0KICAgIGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQog ICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICBuZXRjb25mIG1haWxpbmcgbGlzdA0KICAgIG5ldGNvbmZAaWV0Zi5vcmcNCiAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCiAgICANCg0K From nobody Tue Jan 28 07:14: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 DEE7E120124 for ; Tue, 28 Jan 2020 07:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fRUnaz67; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=TcqBT9E1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcbLwwoQQN0a for ; Tue, 28 Jan 2020 07:14:49 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80DB120178 for ; Tue, 28 Jan 2020 07:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12167; q=dns/txt; s=iport; t=1580224487; x=1581434087; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EcCtlpy3nG1JSDRD1qaz65S2aS9gvmKHrigQbublzDw=; b=fRUnaz67gkDgm1GlqhCzEx4LqGjgUk6v+wQwU5GLMJAzk6aD8eXRwbAW R4gaS4jYRS/5L7HuaA49ofvNsVb+h5LRGaEmiqjotVbSpj1RN6jdMtBXo aK8VzUcUGHmMecB4fMvqz4FTa9AT5UA2SZDvs4+ekOGNfHdmq3UdpuIqS A=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AzMYU/RPDiW6QtVs1/Jwl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKU/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj2MvnrcwQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgBQCsTzBe/4MNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVFAFbCstIAQLKgqECoNGA4sWgl+JYY4uglIDVAIHAQEBCQM?= =?us-ascii?q?BASMKAgEBhEACgiYkOBMCAw0BAQQBAQECAQUEbYU3DIVeAQEBAQIBEhEdAQE?= =?us-ascii?q?3AQQLAgEIDgoNHQICAh8RJQEBBAENBQgGDQeDBYF9TQMOEQ8BAgyiNAKBOYh?= =?us-ascii?q?idYEygn8BAQWBMwIOQYMSDQuCBQcDBoE4gVOKSxqBQT+BWIIXNT6CG0kBAQI?= =?us-ascii?q?BAYFJGIMOMoIsjVyhPEQKgjmDaII4gSKKTIREmnyOYIhkgiSQBQIEAgQFAg4?= =?us-ascii?q?BAQWBaSKBWHAVgydQGA2OHYNzhRSFPgF0gSmLdwGBDwEB?= X-IronPort-AV: E=Sophos;i="5.70,374,1574121600"; d="p7s'?scan'208";a="416094886" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jan 2020 15:14:39 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 00SFEdHV028634 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Jan 2020 15:14:39 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 Jan 2020 09:14:38 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 Jan 2020 10:14:36 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 28 Jan 2020 09:14:36 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D237YWbPFk7kGEPKQxQGwY7qVRlttkz6WU7sy1WQJmO4fPmU9ifO9FDI/1yUTQadViLon6tDX+pWnDzlESx2UbioeS3Z3BRKWPsKOONU1AegAwSMMfo1jR2yrrjCbQN5gl7KrUcs95GgdL1JKBjBrGturbt+m3Qxmc42p4aAo4pxz1fRVmm54BwdCFcbbK+49vIOxYZEY6PDgpaltF8kmp+wQu3MLIt7EuFI1SPPel3qjG3tv7AZoVyWmWNXqR/0HDJt1shtgPM7UKJVv2d3w0DsKq7WwLS6/wLOJ78FHFTWOIRd7lZOW0g/x1cdTZ0y2vHgRzLx0m4WgaxNkWa7ug== 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=J9sB9gmw8t2A9BKX7sDqisf/pL6O4uZcCB9K6n7n7aE=; b=K65r2jUSt+bQnj9ehTzX1oU9iQgAtBrnKwRPZCdz49b07pp1GkLH8OFyw/ffcNtJrdkjka5ekBKzmEQwFpghjanZT2b8TVXsGZas+vrGl7mjBRurgS5XfXZZt//KFI9mf0qe0Wl9Ejv4e/LbPmHCIb9xgrqoKbu8RVKNlJxOABkq+V4Y8VFquU485FdGb9tHYZ417337Fq0n1+hhOu6U+3XJxalY4WdBrhyp7JO4prA2QDQjyhKcmQBHtr5mjmq+6aJ/mPXY5fMXDlKthx1wxRTga02c1gY3TEodtTo9U3nlP4AZTXCU6fY3/XPXFiRBfHpjNvVJwf1LHSgnfn4EuQ== 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=J9sB9gmw8t2A9BKX7sDqisf/pL6O4uZcCB9K6n7n7aE=; b=TcqBT9E1er21gnccMWntA6wqe8EETIlQuS4GxTJ4Vb2hFmz/wVAmO+ipD994dCdv4GCHZlZpQ+f6khTKhLgzVW5osKctuGYl2oPSHx2WEjVELKal8NbhutEaC9nqIleGizcy3TVS2JKKvx7QztVy5gs+5A6Bp2aZfGSBCLKzYpA= Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB3047.namprd11.prod.outlook.com (20.177.226.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.22; Tue, 28 Jan 2020 15:14:35 +0000 Received: from BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5]) by BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5%5]) with mapi id 15.20.2665.026; Tue, 28 Jan 2020 15:14:35 +0000 From: "Eric Voit (evoit)" To: Martin Bjorklund , "mjethanandani@gmail.com" CC: "netconf@ietf.org" Thread-Topic: [netconf] Configured receiver capability exchange Thread-Index: AdXL4TILBTPP/wetTxqO44ff1VxXqQJkujEAAAy/zYAAEOPWUA== Date: Tue, 28 Jan 2020 15:14:35 +0000 Message-ID: References: <9E429FFB-23F2-4005-9153-A35B4231E965@gmail.com> <20200128.074935.2293026921027473843.mbj@tail-f.com> In-Reply-To: <20200128.074935.2293026921027473843.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.79] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 124e2e73-e39a-450e-ad1d-08d7a404c90d x-ms-traffictypediagnostic: BYAPR11MB3047: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(366004)(136003)(376002)(396003)(199004)(189003)(81166006)(81156014)(316002)(8676002)(110136005)(52536014)(7696005)(9686003)(26005)(76116006)(66946007)(478600001)(66476007)(66556008)(64756008)(66446008)(66616009)(86362001)(4326008)(33656002)(2906002)(53546011)(186003)(8936002)(71200400001)(6506007)(55016002)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3047; H:BYAPR11MB2536.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QnpacZxMWzItXqgmYb6D0HYo7qPzr/YzuTCvx8jNFlNVpoac7A3qKjDTF586MEg/KAM4GmeiCoeACdc74adGtHTwbR/N1f0I7e+rya2qgX4lQz98WttPyWkynfHP4czxAScOynpfL2LDfP+Bql9NpCgZvXOBuaYkHZfB3d+CRFUn/7YTv7d0+jJ35kFVGjwWndyDjyFZK/FrZqy9FEmgph7qvOMLl2htSN38dUDDDHnsL9iRlfI+3G0dNUItirwiaweA1jMrPKQhmHlmrvF1eNiNBEs0GgTS7Vaw+JBvRSyPH/WKjYdt6FQp+W8Cn+zV9lLJ+s4V5HQ9jIHGp24lhnY57RPv6SEhQu98DfDfdylQvXzuVPJxyM2ENpoGZ/SdBQl0QQyC0z/mciEk8vqffX8zmCqZR2DNlTsfH6VRFkWYQEAN8FQURNlafTVGoYHtJ6p/Ug/u2d2Z32qarukw4e1c4/7tVbp/J9NxJA0Y8yJdToASrwP57u9KBACI30DmFbRBEFS/VTduYX8US5Xd9Q== x-ms-exchange-antispam-messagedata: uUWoLCTZyaGlrLsMX73EovH5tcNFSzJ3wLiGaJblICyiXYvR8c3X07qDZSBr+Cx1jDXAohN1LTTV4rz9UQmIdhJ6HgPQlWJNFRuHrGCqJW3AIX7B2XazDbQhHGAuk2RNUqwk6KxAj+qPjUS2zOJEkA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_054B_01D5D5C3.BBCEF820" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 124e2e73-e39a-450e-ad1d-08d7a404c90d X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2020 15:14:35.4476 (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: MgY5FKNHTP9jCBV3tZUSi9NiateWkY/bgXY6mbE8K6wu3TLJc4CyoRGD/JA9bqmI X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3047 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [netconf] Configured receiver capability exchange X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 28 Jan 2020 15:14:52 -0000 ------=_NextPart_000_054B_01D5D5C3.BBCEF820 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Hi, >=20 > Mahesh Jethanandani wrote: > > Hi Eric, > > > > Specifically to your suggestion towards > > draft-ietf-netconf-https-notif, and its ability to learn the = receiver > > capabilities =E2=80=A6 > > > > As you might have seen, we had suggested a rather simple mechanism = to > > learn the capabilities of the receiver that involved a GET with a > > specific Content-Type to invoke a response that returns the metadata > > we desire. All the method requires is a HTTP(S) server at the other > > end. If the Content-Type is not supported by the server, the server > > will return an error. We like it for its simplicity. >=20 > I prefer this over the proposal to (mis?)use . >=20 > First of all, one thing you want to discover is the encoding for = notifications. > is a notification. So which encoding should be = used > to send it? is just for configured subscriptions. The = encoding is set as part of the publisher configuration. =20 > Second, there is no "reply" defined for since = it is a > one-way notification, so adding that seems a bit out of place. With configured subscriptions, there is a need the receiver to confirm = acceptance of the subscription. Otherwise, configured subscriptions = becomes a denial-of-service risk. As a result of this need, there is = the following text in the Security Considerations of RFC-8639: With configured subscriptions, one or more publishers could be used to overwhelm a receiver. To counter this, notification messages SHOULD NOT be sent to any receiver that does not support this specification. Receivers that do not want notification messages need only terminate or refuse any transport sessions from the publisher. This is one reason we already need to do an "ok" is in reply to the = HTTP, even without capability exchange. I am just thinking we can use = the already needed "OK" message for additional information on receiver = capabilities. Eric > /martin >=20 >=20 >=20 > > > > Your suggestion is of using . Does that not > > involve having a RESTCONF/NETCONF server support on the receiver? If > > is supported, does it mean > > or also needs to = be > > supported? If we do not/cannot support modification of subscription, > > and instead require establishment of a new subscription to learn of > > modifications, what would we be missing out with the GET method? = Could > > subscription be terminated simply by terminating the session? > > > > Thanks. > > > > > On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) > > > wrote: > > > > > > Hi Mahesh, > > > > > > During the IETF 106 session, there was discussion on how both a > > > publisher might know if there is receiver support for > > > draft-ietf-netconf-notification-messages > > > messages/?include_text=3D1>. > > > Section 6 highlights several of the considerations. Relevant are > > > the > > > following: > > > > > > (a) Remote device capability discovery from the point of view of = the > > > Publisher needs to be enhanced to know if the far end can = interpret > > > notification messages type beyond RFC-5277, Section 4. > > > > > > (b) This capability discovery question is relevant for both > > > configured subscription receivers and dynamic subscribers. > > > > > > (c) The capability discovery question can be generalized beyond > > > subscriptions, as there are many reasons to know the available > > > capabilities of the far end. > > > > > > (d) Capability discovery advertisement has traditionally been > > > discussed within transport documents (e.g. RFC-6241 Section 8.1). > > > > > > > > > Based on (a)-(d), coming up with a transport independent > > > point-solution within draft-ietf-netconf-notification-messages > > > = > > ssages/?include_text=3D1> > > > *just* to discover this single element of client functionality = seems > > > overkill/heavyweight. > > > > > > I was fine with letting this remote capabilities discovery = question > > > sit for a while. However draft-ietf-netconf-https-notif > > > > > > shows that we now must address this question. Specifically should > > > the diagram section 1.4.1 show this capability exchange? > > > > > > It turns out that independent of > > > draft-ietf-netconf-notification-messages, there several questions = in > > > draft-ietf-netconf-https-notif which need to be answered prior to > > > the section 1.4.1 arrow: "Send HTTPS POST message with YANG = defined > > > notification #1" anyway. These questions are: > > > (1) Does the targeted HTTPS receiver support configured = subscriptions? > > > (2) Can the targeted HTTP@ receiver accept a new subscription as > > > described in a ? > > > Only if these questions are "yes", should the = > > > be responded to with an "OK". > > > > > > Add to this a third question driven from (a)-(d): > > > (3) Does the receiver support the message type within > > > "draft-ietf-netconf-notification-messages"? > > > > > > A strawman way to handle the all three questions within > > > draft-ietf-netconf-https-notif would be to respond to a > > > notification with an HTTP Status 202 > > > (Accepted)" acknowledgement. This 202 would include body elements > > > listing supported receiver resources. Maybe something YANG = encoded > > > via ietf-yang-structure-ext containing: > > > > > > > > > > > > > > > = urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 > > > > > > > > > > > > > > > What do you think of this approach? > > > > > > Eric > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > ------=_NextPart_000_054B_01D5D5C3.BBCEF820 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTI4MTUxNDMyWjAjBgkqhkiG 9w0BCQQxFgQUDSIXTbSEEqtK/jX4u6hfhcvn7hAwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAiuw1YxVF4C6Du55ASqR70yLp/H/nGz6A9uwgR0X+jNXCSTpUo2gghxpsL24ImLotf yrsET420nCYvBdbzZXk5iCG608WhEZvkJFwaPHm80y4n/yyWvgE4rOtSASoz376XAVhVz4FbRE3L 3aFkAc5TqKvhToasq22CS40MvKgSgMjWF20OLJ1ouSXemJRWNW+rNTe9AlbbLVxKdJQ/0apqKKlB kKWNoiY2yRGsP+KTtnRf4xLHsFSjMLp/tqee58fVse8iQK07vQpiaeUjUY82YhcMrYriu+mTZU6A XBaoJx0gudIQW3t+mnMqG3I5RuAZ20S9WaqYkZ6O52EX6QmIAAAAAAAA ------=_NextPart_000_054B_01D5D5C3.BBCEF820-- From nobody Tue Jan 28 08:28:08 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 781581209D5 for ; Tue, 28 Jan 2020 08:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 qwRWRuji0qMx for ; Tue, 28 Jan 2020 08:28:03 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3315C120BBB for ; Tue, 28 Jan 2020 08:27:59 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 446D01AE01AA; Tue, 28 Jan 2020 17:27:56 +0100 (CET) Date: Tue, 28 Jan 2020 17:27:18 +0100 (CET) Message-Id: <20200128.172718.208580931536379456.mbj@tail-f.com> To: evoit@cisco.com Cc: mjethanandani@gmail.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <9E429FFB-23F2-4005-9153-A35B4231E965@gmail.com> <20200128.074935.2293026921027473843.mbj@tail-f.com> X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] Configured receiver capability exchange X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 28 Jan 2020 16:28:05 -0000 IkVyaWMgVm9pdCAoZXZvaXQpIiA8ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCj4gPiBIaSwNCj4g PiANCj4gPiBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4gd3Jv dGU6DQo+ID4gPiBIaSBFcmljLA0KPiA+ID4NCj4gPiA+IFNwZWNpZmljYWxseSB0byB5b3VyIHN1 Z2dlc3Rpb24gdG93YXJkcw0KPiA+ID4gZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmLCBh bmQgaXRzIGFiaWxpdHkgdG8gbGVhcm4gdGhlIHJlY2VpdmVyDQo+ID4gPiBjYXBhYmlsaXRpZXMg 4oCmDQo+ID4gPg0KPiA+ID4gQXMgeW91IG1pZ2h0IGhhdmUgc2Vlbiwgd2UgaGFkIHN1Z2dlc3Rl ZCBhIHJhdGhlciBzaW1wbGUgbWVjaGFuaXNtIHRvDQo+ID4gPiBsZWFybiB0aGUgY2FwYWJpbGl0 aWVzIG9mIHRoZSByZWNlaXZlciB0aGF0IGludm9sdmVkIGEgR0VUIHdpdGggYQ0KPiA+ID4gc3Bl Y2lmaWMgQ29udGVudC1UeXBlIHRvIGludm9rZSBhIHJlc3BvbnNlIHRoYXQgcmV0dXJucyB0aGUg bWV0YWRhdGENCj4gPiA+IHdlIGRlc2lyZS4gQWxsIHRoZSBtZXRob2QgcmVxdWlyZXMgaXMgYSBI VFRQKFMpIHNlcnZlciBhdCB0aGUgb3RoZXINCj4gPiA+IGVuZC4gSWYgdGhlIENvbnRlbnQtVHlw ZSBpcyBub3Qgc3VwcG9ydGVkIGJ5IHRoZSBzZXJ2ZXIsIHRoZSBzZXJ2ZXINCj4gPiA+IHdpbGwg cmV0dXJuIGFuIGVycm9yLiBXZSBsaWtlIGl0IGZvciBpdHMgc2ltcGxpY2l0eS4NCj4gPiANCj4g PiBJIHByZWZlciB0aGlzIG92ZXIgdGhlIHByb3Bvc2FsIHRvIChtaXM/KXVzZSA8c3Vic2NyaXB0 aW9uLXN0YXJ0ZWQ+Lg0KPiA+IA0KPiA+IEZpcnN0IG9mIGFsbCwgb25lIHRoaW5nIHlvdSB3YW50 IHRvIGRpc2NvdmVyIGlzIHRoZSBlbmNvZGluZyBmb3INCj4gPiBub3RpZmljYXRpb25zLg0KPiA+ IDxzdWJzY3JpcHRpb24tc3RhcnRlZD4gaXMgYSBub3RpZmljYXRpb24uICBTbyB3aGljaCBlbmNv ZGluZyBzaG91bGQgYmUNCj4gPiB1c2VkDQo+ID4gdG8gc2VuZCBpdD8NCj4gDQo+IDxzdWJzY3Jp cHRpb24tc3RhcnRlZD4gaXMganVzdCBmb3IgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zLiAgVGhl DQo+IGVuY29kaW5nIGlzIHNldCBhcyBwYXJ0IG9mIHRoZSBwdWJsaXNoZXIgY29uZmlndXJhdGlv bi4NCg0KTXkgYmFkIChidXQgcGVyaGFwcyB1bmZvcnR1bmF0ZSB0aGF0IHRoaXMgbmVlZHMgdG8g YmUgbWFudWFsbHkNCmNvbmZpZ3VyZWQsIHJhdGhlciB0aGFuIGR5bmFtaWNhbGx5IGFncmVlZCB1 cG9uKS4NCg0KQW55d2F5LCB0aGUgPHN1YnNjcmlwdGlvbi1zdGFydGVkPiBub3RpZmljYXRpb24g bXVzdCBiZSBzZW50IGluIHNvbWUNCm1lc3NhZ2UgZm9ybWF0LiAgU2hvdWxkIGl0IGJlIDUyNzct c3R5bGUgb3INCmRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMtc3R5bGU/ DQoNCj4gPiBTZWNvbmQsIHRoZXJlIGlzIG5vICJyZXBseSIgZGVmaW5lZCBmb3IgPHN1YnNjcmlw dGlvbi1zdGFydGVkPiBzaW5jZQ0KPiA+IGl0IGlzIGENCj4gPiBvbmUtd2F5IG5vdGlmaWNhdGlv biwgc28gYWRkaW5nIHRoYXQgc2VlbXMgYSBiaXQgb3V0IG9mIHBsYWNlLg0KPiANCj4gV2l0aCBj b25maWd1cmVkIHN1YnNjcmlwdGlvbnMsIHRoZXJlIGlzIGEgbmVlZCB0aGUgcmVjZWl2ZXIgdG8g Y29uZmlybQ0KPiBhY2NlcHRhbmNlIG9mIHRoZSBzdWJzY3JpcHRpb24uICBPdGhlcndpc2UsIGNv bmZpZ3VyZWQgc3Vic2NyaXB0aW9ucw0KPiBiZWNvbWVzIGEgZGVuaWFsLW9mLXNlcnZpY2Ugcmlz ay4gIEFzIGEgcmVzdWx0IG9mIHRoaXMgbmVlZCwgdGhlcmUgaXMNCj4gdGhlIGZvbGxvd2luZyB0 ZXh0IGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBvZiBSRkMtODYzOToNCj4gDQo+ICAg V2l0aCBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMsIG9uZSBvciBtb3JlIHB1Ymxpc2hlcnMgY291 bGQgYmUgdXNlZA0KPiAgICB0byBvdmVyd2hlbG0gYSByZWNlaXZlci4gIFRvIGNvdW50ZXIgdGhp cywgbm90aWZpY2F0aW9uIG1lc3NhZ2VzDQo+ICAgIFNIT1VMRCBOT1QgYmUgc2VudCB0byBhbnkg cmVjZWl2ZXIgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IHRoaXMNCj4gICAgc3BlY2lmaWNhdGlvbi4g IFJlY2VpdmVycyB0aGF0IGRvIG5vdCB3YW50IG5vdGlmaWNhdGlvbiBtZXNzYWdlcyBuZWVkDQo+ ICAgIG9ubHkgdGVybWluYXRlIG9yIHJlZnVzZSBhbnkgdHJhbnNwb3J0IHNlc3Npb25zIGZyb20g dGhlIHB1Ymxpc2hlci4NCj4gDQo+IFRoaXMgaXMgb25lIHJlYXNvbiB3ZSBhbHJlYWR5IG5lZWQg dG8gZG8gYW4gIm9rIiBpcyBpbiByZXBseSB0byB0aGUNCj4gSFRUUCwgZXZlbiB3aXRob3V0IGNh cGFiaWxpdHkgZXhjaGFuZ2UuICBJIGFtIGp1c3QgdGhpbmtpbmcgd2UgY2FuIHVzZQ0KPiB0aGUg YWxyZWFkeSBuZWVkZWQgIk9LIiBtZXNzYWdlIGZvciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIG9u IHJlY2VpdmVyDQo+IGNhcGFiaWxpdGllcy4NCg0KTm90IHN1cmUgSSBmb2xsb3cgaG93IHRoaXMg aXMgYSBuZWVkIHRvIGRvIGFuICJvayIgYW5kIHdoYXQgdGhhdCB3b3VsZA0KYmUuICBJbiBteSB1 bmRlcnN0YW5kaW5nLCB3aGVuIHRoZSBwdWJsaXNoZXIgbmVlZHMgdG8gc2VuZCBhDQpub3RpZmlj YXRpb24gdG8gYSBjb25maWd1cmVkIHJlY2VpdmVyIHRoYXQgaXMgZG9pbmcgaHR0cHMtbm90aWYs IGl0DQp3aWxsIG9wZW4gYW4gSFRUUFMgc2Vzc2lvbiAodW5sZXNzIHRoZXJlIGFscmVhZHkgaXMg b25lIGFjdGl2ZSkgYW5kDQpQT1NUIHRoZSBub3RpZmljYXRpb24gaW4gc29tZSBmb3JtYXQsIHdp dGggc29tZSBlbmNvZGluZy4gIFRoZSBIVFRQUw0Kc2VydmVyIHdpbGwgcmVwbHkgMjAwIE9LIG9y IGFuIGVycm9yLCBvciBwZXJoYXBzIGNsb3NlIHRoZSBzZXNzaW9uLg0KDQoNCi9tYXJ0aW4NCg0K DQoNCj4gDQo+IEVyaWMNCj4gDQo+ID4gL21hcnRpbg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+ID4N Cj4gPiA+IFlvdXIgc3VnZ2VzdGlvbiBpcyBvZiB1c2luZyA8c3Vic2NyaXB0aW9uLXN0YXJ0ZWQ+ LiBEb2VzIHRoYXQgbm90DQo+ID4gPiBpbnZvbHZlIGhhdmluZyBhIFJFU1RDT05GL05FVENPTkYg c2VydmVyIHN1cHBvcnQgb24gdGhlIHJlY2VpdmVyPyBJZg0KPiA+ID4gPHN1YnNjcmlwdGlvbi1z dGFydGVkPiBpcyBzdXBwb3J0ZWQsIGRvZXMgaXQgbWVhbg0KPiA+ID4gPHN1YnNjcmlwdGlvbi1t b2RpZmllZD4gb3IgPHN1YnNjcmlwdGlvbi10ZXJtaW5hdGVkPiBhbHNvIG5lZWRzIHRvIGJlDQo+ ID4gPiBzdXBwb3J0ZWQ/IElmIHdlIGRvIG5vdC9jYW5ub3Qgc3VwcG9ydCBtb2RpZmljYXRpb24g b2Ygc3Vic2NyaXB0aW9uLA0KPiA+ID4gYW5kIGluc3RlYWQgcmVxdWlyZSBlc3RhYmxpc2htZW50 IG9mIGEgbmV3IHN1YnNjcmlwdGlvbiB0byBsZWFybiBvZg0KPiA+ID4gbW9kaWZpY2F0aW9ucywg d2hhdCB3b3VsZCB3ZSBiZSBtaXNzaW5nIG91dCB3aXRoIHRoZSBHRVQgbWV0aG9kPyBDb3VsZA0K PiA+ID4gc3Vic2NyaXB0aW9uIGJlIHRlcm1pbmF0ZWQgc2ltcGx5IGJ5IHRlcm1pbmF0aW5nIHRo ZSBzZXNzaW9uPw0KPiA+ID4NCj4gPiA+IFRoYW5rcy4NCj4gPiA+DQo+ID4gPiA+IE9uIEphbiAx NSwgMjAyMCwgYXQgMTI6MjMgUE0sIEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNjby5jb20+ DQo+ID4gPiA+IHdyb3RlOg0KPiA+ID4gPg0KPiA+ID4gPiBIaSBNYWhlc2gsDQo+ID4gPiA+DQo+ ID4gPiA+IER1cmluZyB0aGUgSUVURiAxMDYgc2Vzc2lvbiwgdGhlcmUgd2FzIGRpc2N1c3Npb24g b24gaG93IGJvdGggYQ0KPiA+ID4gPiBwdWJsaXNoZXIgbWlnaHQga25vdyBpZiB0aGVyZSBpcyBy ZWNlaXZlciBzdXBwb3J0IGZvcg0KPiA+ID4gPiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0 aW9uLW1lc3NhZ2VzDQo+ID4gPiA+IDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLQ0KPiA+IG1lc3NhZ2VzLz9pbmNsdWRlX3Rl eHQ9MT4uDQo+ID4gPiA+IFNlY3Rpb24gNiBoaWdobGlnaHRzIHNldmVyYWwgb2YgdGhlIGNvbnNp ZGVyYXRpb25zLiAgUmVsZXZhbnQgYXJlDQo+ID4gPiA+IHRoZQ0KPiA+ID4gPiBmb2xsb3dpbmc6 DQo+ID4gPiA+DQo+ID4gPiA+IChhKSBSZW1vdGUgZGV2aWNlIGNhcGFiaWxpdHkgZGlzY292ZXJ5 IGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlDQo+ID4gPiA+IFB1Ymxpc2hlciBuZWVkcyB0 byBiZSBlbmhhbmNlZCB0byBrbm93IGlmIHRoZSBmYXIgZW5kIGNhbiBpbnRlcnByZXQNCj4gPiA+ ID4gbm90aWZpY2F0aW9uIG1lc3NhZ2VzIHR5cGUgYmV5b25kIFJGQy01Mjc3LCBTZWN0aW9uIDQu DQo+ID4gPiA+DQo+ID4gPiA+IChiKSBUaGlzIGNhcGFiaWxpdHkgZGlzY292ZXJ5IHF1ZXN0aW9u IGlzIHJlbGV2YW50IGZvciBib3RoDQo+ID4gPiA+IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIHJl Y2VpdmVycyBhbmQgZHluYW1pYyBzdWJzY3JpYmVycy4NCj4gPiA+ID4NCj4gPiA+ID4gKGMpIFRo ZSBjYXBhYmlsaXR5IGRpc2NvdmVyeSBxdWVzdGlvbiBjYW4gYmUgZ2VuZXJhbGl6ZWQgYmV5b25k DQo+ID4gPiA+IHN1YnNjcmlwdGlvbnMsIGFzIHRoZXJlIGFyZSBtYW55IHJlYXNvbnMgdG8ga25v dyB0aGUgYXZhaWxhYmxlDQo+ID4gPiA+IGNhcGFiaWxpdGllcyBvZiB0aGUgZmFyIGVuZC4NCj4g PiA+ID4NCj4gPiA+ID4gKGQpIENhcGFiaWxpdHkgZGlzY292ZXJ5IGFkdmVydGlzZW1lbnQgaGFz IHRyYWRpdGlvbmFsbHkgYmVlbg0KPiA+ID4gPiBkaXNjdXNzZWQgd2l0aGluIHRyYW5zcG9ydCBk b2N1bWVudHMgKGUuZy4gUkZDLTYyNDEgU2VjdGlvbiA4LjEpLg0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPiBCYXNlZCBvbiAoYSktKGQpLCBjb21pbmcgdXAgd2l0aCBhIHRyYW5zcG9ydCBpbmRl cGVuZGVudA0KPiA+ID4gPiBwb2ludC1zb2x1dGlvbiB3aXRoaW4gZHJhZnQtaWV0Zi1uZXRjb25m LW5vdGlmaWNhdGlvbi1tZXNzYWdlcw0KPiA+ID4gPiA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZQ0KPiA+ID4gPiBzc2Fn ZXMvP2luY2x1ZGVfdGV4dD0xPg0KPiA+ID4gPiAqanVzdCogdG8gZGlzY292ZXIgdGhpcyBzaW5n bGUgZWxlbWVudCBvZiBjbGllbnQgZnVuY3Rpb25hbGl0eSBzZWVtcw0KPiA+ID4gPiBvdmVya2ls bC9oZWF2eXdlaWdodC4NCj4gPiA+ID4NCj4gPiA+ID4gSSB3YXMgZmluZSB3aXRoIGxldHRpbmcg dGhpcyByZW1vdGUgY2FwYWJpbGl0aWVzIGRpc2NvdmVyeSBxdWVzdGlvbg0KPiA+ID4gPiBzaXQg Zm9yIGEgd2hpbGUuICBIb3dldmVyIGRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZg0KPiA+ ID4gPiA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1odHRw cy1ub3RpZi0wMT4NCj4gPiA+ID4gc2hvd3MgdGhhdCB3ZSBub3cgbXVzdCBhZGRyZXNzIHRoaXMg cXVlc3Rpb24uICBTcGVjaWZpY2FsbHkgc2hvdWxkDQo+ID4gPiA+IHRoZSBkaWFncmFtIHNlY3Rp b24gMS40LjEgc2hvdyB0aGlzIGNhcGFiaWxpdHkgZXhjaGFuZ2U/DQo+ID4gPiA+DQo+ID4gPiA+ IEl0IHR1cm5zIG91dCB0aGF0IGluZGVwZW5kZW50IG9mDQo+ID4gPiA+IGRyYWZ0LWlldGYtbmV0 Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMsIHRoZXJlIHNldmVyYWwgcXVlc3Rpb25zIGluDQo+ ID4gPiA+IGRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZiB3aGljaCBuZWVkIHRvIGJlIGFu c3dlcmVkIHByaW9yIHRvDQo+ID4gPiA+IHRoZSBzZWN0aW9uIDEuNC4xIGFycm93OiAiU2VuZCBI VFRQUyBQT1NUIG1lc3NhZ2Ugd2l0aCBZQU5HIGRlZmluZWQNCj4gPiA+ID4gbm90aWZpY2F0aW9u ICMxIiBhbnl3YXkuICBUaGVzZSBxdWVzdGlvbnMgYXJlOg0KPiA+ID4gPiAgICgxKSBEb2VzIHRo ZSB0YXJnZXRlZCBIVFRQUyByZWNlaXZlciBzdXBwb3J0IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9u cz8NCj4gPiA+ID4gICAoMikgQ2FuIHRoZSB0YXJnZXRlZCBIVFRQQCByZWNlaXZlciBhY2NlcHQg YSBuZXcgc3Vic2NyaXB0aW9uIGFzDQo+ID4gPiA+ICAgZGVzY3JpYmVkIGluIGEgPHN1YnNjcmlw dGlvbi1zdGFydGVkPj8NCj4gPiA+ID4gT25seSBpZiB0aGVzZSBxdWVzdGlvbnMgYXJlICJ5ZXMi LCBzaG91bGQgdGhlIDxzdWJzY3JpcHRpb24tc3RhcnRlZD4NCj4gPiA+ID4gYmUgcmVzcG9uZGVk IHRvIHdpdGggYW4gIk9LIi4NCj4gPiA+ID4NCj4gPiA+ID4gQWRkIHRvIHRoaXMgYSB0aGlyZCBx dWVzdGlvbiBkcml2ZW4gZnJvbSAoYSktKGQpOg0KPiA+ID4gPiAgICgzKSBEb2VzIHRoZSByZWNl aXZlciBzdXBwb3J0IHRoZSBtZXNzYWdlIHR5cGUgd2l0aGluDQo+ID4gPiA+ICAgImRyYWZ0LWll dGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMiPw0KPiA+ID4gPg0KPiA+ID4gPiBBIHN0 cmF3bWFuIHdheSB0byBoYW5kbGUgdGhlIGFsbCB0aHJlZSBxdWVzdGlvbnMgd2l0aGluDQo+ID4g PiA+IGRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZiB3b3VsZCBiZSB0byByZXNwb25kIHRv IGENCj4gPiA+ID4gPHN1YnNjcmlwdGlvbi1zdGFydGVkPiBub3RpZmljYXRpb24gd2l0aCBhbiBI VFRQIFN0YXR1cyAyMDINCj4gPiA+ID4gKEFjY2VwdGVkKSIgYWNrbm93bGVkZ2VtZW50LiAgVGhp cyAyMDIgd291bGQgaW5jbHVkZSBib2R5IGVsZW1lbnRzDQo+ID4gPiA+IGxpc3Rpbmcgc3VwcG9y dGVkIHJlY2VpdmVyIHJlc291cmNlcy4gIE1heWJlIHNvbWV0aGluZyBZQU5HIGVuY29kZWQNCj4g PiA+ID4gdmlhIGlldGYteWFuZy1zdHJ1Y3R1cmUtZXh0IGNvbnRhaW5pbmc6DQo+ID4gPiA+DQo+ ID4gPiA+ICAgICAgIDxmb28geG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpi YXNlOjEuMCI+DQo+ID4gPiA+ICAgICAgICAgPGNhcGFiaWxpdGllcz4NCj4gPiA+ID4gICAgICAg ICAgIDxjYXBhYmlsaXR5Pg0KPiA+ID4gPiAgICAgICAgICAgICB1cm46aWV0ZjpwYXJhbXM6eG1s Om5zOnlhbmc6aWV0Zi1ub3RpZmljYXRpb24tbWVzc2FnZXM6MS4wDQo+ID4gPiA+ICAgICAgICAg ICA8L2NhcGFiaWxpdHk+DQo+ID4gPiA+ICAgICAgICAgPC9jYXBhYmlsaXRpZXM+DQo+ID4gPiA+ ICAgICAgIDwvZm9vPg0KPiA+ID4gPg0KPiA+ID4gPiBXaGF0IGRvIHlvdSB0aGluayBvZiB0aGlz IGFwcHJvYWNoPw0KPiA+ID4gPg0KPiA+ID4gPiBFcmljDQo+ID4gPg0KPiA+ID4gTWFoZXNoIEpl dGhhbmFuZGFuaQ0KPiA+ID4gbWpldGhhbmFuZGFuaUBnbWFpbC5jb20NCj4gPiA+DQo+ID4gPg0K PiA+ID4NCg== From nobody Tue Jan 28 09:05:57 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 25AD0120815 for ; Tue, 28 Jan 2020 09:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GtjhitMC; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=E25Ha0bW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5Ryd62E5YzG for ; Tue, 28 Jan 2020 09:05:50 -0800 (PST) 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 E16B01202A0 for ; Tue, 28 Jan 2020 09:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14160; q=dns/txt; s=iport; t=1580231149; x=1581440749; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WMWOXpY6SKcu8A49IEGeMzttiFyLm5yPOVGAm+rmPvM=; b=GtjhitMC0FW2GRBNTjFqdYUTNESAiJOPfcdjLIPRtBLcLwSSldvfZBUZ ejb/sRKXd1NqWuOssds2Bbc3gFhRs6+pXlE8KhxT8gRjWKGDH3uXWbV2O 6m3pcQJayAVhVsbHZnVQqUjVcrYzkoRkJt/tE4Quml8GT+mBJslb1hFKO w=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AAUF48x9XUY8bMf9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcObDkznBPXrdCc9Ws9FUQwt8g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgBQCNaDBe/5FdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVFAFbCstIAQLKgqECoNGA4sVgl+JYY4uglIDVAIHAQEBCQM?= =?us-ascii?q?BASMKAgEBhEACgiYkOBMCAw0BAQQBAQECAQUEbYU3DIVeAQEBAQIBEhEdAQE?= =?us-ascii?q?3AQQLAgEIDgcDDR0CAgIfESUBAQQOBQgGDQeDBYF9TQMOEQ8BAgyiVwKBOYh?= =?us-ascii?q?idYEygn8BAQWBMwIOQYMODQuCBQcDBoE4gVOKSxqBQT+BWIIXNT6CG0kBAQI?= =?us-ascii?q?BAYFJGBWCeTKCLI1coTxECoI5g2iCOIEiikyERJp8l0SCJJAFAgQCBAUCDgE?= =?us-ascii?q?BBYFpIoFYcBWDJ1AYDY4dg3OFFIU+AXSBKYt3AYEPAQE?= X-IronPort-AV: E=Sophos;i="5.70,374,1574121600"; d="p7s'?scan'208";a="696695086" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jan 2020 17:05:48 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 00SH5mHx012706 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Jan 2020 17:05:48 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 Jan 2020 11:05:47 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 Jan 2020 11:05:45 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 28 Jan 2020 11:05:45 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=amUIZtMEGNcbkKgWbmOag9noiAost6vRXthsSEgemEA79U5T4U1ybMsCXCsFDN2TR3xmQWCEtw6lz6qmsY6ExZCd5xU/IN8PxZsA+MSnWmjb+2AKKHUrBwvRn4uscu415db1q8pgMDFqtWJ138HEcv/KRThJwS1nxf4FEwEW1Qp4AbuJHEU/As+kV+E67o7qgalp63W3GMF/kRlGSiblGdXxRKjf/5KczBOKXU7uJYjIfMeevCcFg3Ak7e4f57eAbXYqm+yVOaFqs8vCzJasOgGcLXz19zrRbB/PxKKIxuLMfRHfwxqb4Vyj6OoDJzkKghyTwQuerAquApUmCUVLfQ== 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=aFwiuInD64c9hgOYG5Mz7QQ3WXWAqoBELZdlG0Z9Z8k=; b=M7Hc795PEQiNDLy4AU2Le69DC1wxx2ts9BvB5410vOguzsTHbflc8+l1OaU0Tp9uNG9DMjkesdG6ZefvNSKVkTI0D32i7VOjWcf8BDhInZ9umMAAUcyYas+I7nvdDpXAU9odASIPJlpC3zmUMkYQbisgvIrMD9UA2YpnXeclIXwlrnq7ugVcBgxvdvotyZKLhWdcs+HCrEpO9koZnWGI6EA+zzRrBnjrQbmD8mD6wRuQkp535xYQVA4ATgnXWW5eVVuoj/H22/RVhjCis9jy+e7IZKcVqaKvRWn3JDGIsy/EMlu9orveiHwwP/9/5XA2b3R7FvztNJa2KWFvv8VAjg== 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=aFwiuInD64c9hgOYG5Mz7QQ3WXWAqoBELZdlG0Z9Z8k=; b=E25Ha0bW6plHXYOe9vx28h4L9COTYu7VOKPKLHdoGVBYTK/ik+sTbZA/A1PpzMyuvN+SRXmYJ/V7NW1lTmxDFiq8iXObP1ZyDI8Qx8RrsrP9PxwDmaXP7QqsX1lL7Uhq/UmscShNKEa6yr4abO8dOY0uRN8R9A4EUo3R+DwI2M8= Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.19; Tue, 28 Jan 2020 17:05:44 +0000 Received: from BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5]) by BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5%5]) with mapi id 15.20.2665.026; Tue, 28 Jan 2020 17:05:44 +0000 From: "Eric Voit (evoit)" To: Martin Bjorklund CC: "mjethanandani@gmail.com" , "netconf@ietf.org" Thread-Topic: [netconf] Configured receiver capability exchange Thread-Index: AdXL4TILBTPP/wetTxqO44ff1VxXqQJkujEAAAy/zYAAEOPWUAADSVoAAAAey9A= Date: Tue, 28 Jan 2020 17:05:44 +0000 Message-ID: References: <9E429FFB-23F2-4005-9153-A35B4231E965@gmail.com> <20200128.074935.2293026921027473843.mbj@tail-f.com> <20200128.172718.208580931536379456.mbj@tail-f.com> In-Reply-To: <20200128.172718.208580931536379456.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.79] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5d05d184-3022-4a96-cd0b-08d7a414502f x-ms-traffictypediagnostic: BYAPR11MB2536: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(346002)(366004)(396003)(199004)(189003)(66446008)(64756008)(316002)(71200400001)(76116006)(6506007)(53546011)(2906002)(66556008)(66946007)(66476007)(66616009)(33656002)(6916009)(478600001)(54906003)(7696005)(26005)(4326008)(81156014)(8676002)(86362001)(81166006)(186003)(5660300002)(52536014)(8936002)(9686003)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2536; H:BYAPR11MB2536.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ycQg9p5D+izl0BPMkoUe22UEYRjoanaQf8UoH5H/ox/Ov4JM/2n/ocbxPLemw0p7EwfZ7Lcc3UN1cIfY+HTvbSUPg5iCc+HIXZMHqcF84m6v0VHXmJdBLFk2sSDSrzZ/F8OLn2unoNskMozJfP6kN/ZJCck3YYazhior6gvLg6dx86UAW7lEtj1QIIlwxltNFAHNJKDymTNz71lHUjSHXVieiPpL5z06ylix10A3MvSUKCVYniwQZLkrm95iHQHq3xa3qSIUxl6LQ5lzuYYUH92aaVngSF091hGfbg1G5XbafV9sDkUbgOsAI/CB4oRge1o/jzRtLcQYQr9UcxXqRJ2cx4g+IAVwZdcviIv5fGjkHB8c3WSV43j6Od1Qr3Ag0M8LVoC1I/AGxCwZb4h0ORHBFfQ4tnfbrusA9MYzsam/QOmqwQNjBIDbMT8kBF1pVeM98TsyC0+1vXpS5LIQcTUpw7bU2iiTBCU0Y7ZsVCbI5JRUb93zDKSC/AJpO5s4l+8yf+eoRKg0xroSusP6mA== x-ms-exchange-antispam-messagedata: wDqTM/dgIKy0T7+PLWDIvUDbEAQcwztAWeTlUVtcBLKSEgLpXZeGQFKtSFulBAdrgh69KyW91TyEulR0I6T1ABUG8/d27LvDyhONIrpir0ANbAglTFucCtQ5DanFveknfhFvfWMlrr+qekuewmN+qA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_058A_01D5D5D0.ECFF0EF0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5d05d184-3022-4a96-cd0b-08d7a414502f X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2020 17:05:44.6316 (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: 6VDiSXPGWRjN+CKC8j5ch2B6n04dXBY+uy6sxUMJb/c89h0czJYhQitO1pUVHjNi X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2536 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [netconf] Configured receiver capability exchange X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 28 Jan 2020 17:05:55 -0000 ------=_NextPart_000_058A_01D5D5D0.ECFF0EF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > From: Martin Bjorklund, January 28, 2020 11:27 AM >=20 > "Eric Voit (evoit)" wrote: > > > Hi, > > > > > > Mahesh Jethanandani wrote: > > > > Hi Eric, > > > > > > > > Specifically to your suggestion towards > > > > draft-ietf-netconf-https-notif, and its ability to learn the > > > > receiver capabilities =E2=80=A6 > > > > > > > > As you might have seen, we had suggested a rather simple = mechanism > > > > to learn the capabilities of the receiver that involved a GET = with > > > > a specific Content-Type to invoke a response that returns the > > > > metadata we desire. All the method requires is a HTTP(S) server = at > > > > the other end. If the Content-Type is not supported by the = server, > > > > the server will return an error. We like it for its simplicity. > > > > > > I prefer this over the proposal to (mis?)use = . > > > > > > First of all, one thing you want to discover is the encoding for > > > notifications. > > > is a notification. So which encoding = should > > > be used to send it? > > > > is just for configured subscriptions. The > > encoding is set as part of the publisher configuration. >=20 > My bad (but perhaps unfortunate that this needs to be manually = configured, > rather than dynamically agreed upon). >=20 > Anyway, the notification must be sent in some > message format. Should it be 5277-style or = draft-ietf-netconf-notification- > messages-style? To me it seems that 5277-style makes sense if the publisher is unsure of = draft-ietf-netconf-notification-messages support. That way the = Publisher then has an option to move further YANG notifications to = draft-ietf-netconf-notification-messages should the receiver indicate = capability support.=20 > > > Second, there is no "reply" defined for = since > > > it is a one-way notification, so adding that seems a bit out of > > > place. > > > > With configured subscriptions, there is a need the receiver to = confirm > > acceptance of the subscription. Otherwise, configured subscriptions > > becomes a denial-of-service risk. As a result of this need, there = is > > the following text in the Security Considerations of RFC-8639: > > > > With configured subscriptions, one or more publishers could be = used > > to overwhelm a receiver. To counter this, notification messages > > SHOULD NOT be sent to any receiver that does not support this > > specification. Receivers that do not want notification messages = need > > only terminate or refuse any transport sessions from the = publisher. > > > > This is one reason we already need to do an "ok" is in reply to the > > HTTP, even without capability exchange. I am just thinking we can = use > > the already needed "OK" message for additional information on = receiver > > capabilities. >=20 > Not sure I follow how this is a need to do an "ok" and what that would = be. > In my understanding, when the publisher needs to send a notification = to a > configured receiver that is doing https-notif, it will open an HTTPS = session > (unless there already is one active) and POST the notification in some > format, with some encoding. The HTTPS server will reply 200 OK or an = error, > or perhaps close the session. In the beginning of this thread, I suggest some thoughts on this for = Section 1.4.1. Hopefully a future draft version can clarify these = specifics. Eric > /martin >=20 >=20 >=20 > > > > Eric > > > > > /martin > > > > > > > > > > > > > > > > > Your suggestion is of using . Does that = not > > > > involve having a RESTCONF/NETCONF server support on the = receiver? > > > > If is supported, does it mean > > > > or also needs = to > > > > be supported? If we do not/cannot support modification of > > > > subscription, and instead require establishment of a new > > > > subscription to learn of modifications, what would we be missing > > > > out with the GET method? Could subscription be terminated simply = by > terminating the session? > > > > > > > > Thanks. > > > > > > > > > On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) > > > > > > > > > > wrote: > > > > > > > > > > Hi Mahesh, > > > > > > > > > > During the IETF 106 session, there was discussion on how both = a > > > > > publisher might know if there is receiver support for > > > > > draft-ietf-netconf-notification-messages > > > > > = > > > > n- > > > messages/?include_text=3D1>. > > > > > Section 6 highlights several of the considerations. Relevant > > > > > are the > > > > > following: > > > > > > > > > > (a) Remote device capability discovery from the point of view = of > > > > > the Publisher needs to be enhanced to know if the far end can > > > > > interpret notification messages type beyond RFC-5277, Section = 4. > > > > > > > > > > (b) This capability discovery question is relevant for both > > > > > configured subscription receivers and dynamic subscribers. > > > > > > > > > > (c) The capability discovery question can be generalized = beyond > > > > > subscriptions, as there are many reasons to know the available > > > > > capabilities of the far end. > > > > > > > > > > (d) Capability discovery advertisement has traditionally been > > > > > discussed within transport documents (e.g. RFC-6241 Section = 8.1). > > > > > > > > > > > > > > > Based on (a)-(d), coming up with a transport independent > > > > > point-solution within draft-ietf-netconf-notification-messages > > > > > = > > > > n-me > > > > > ssages/?include_text=3D1> > > > > > *just* to discover this single element of client functionality > > > > > seems overkill/heavyweight. > > > > > > > > > > I was fine with letting this remote capabilities discovery > > > > > question sit for a while. However > > > > > draft-ietf-netconf-https-notif > > > > > = > > > > > shows that we now must address this question. Specifically > > > > > should the diagram section 1.4.1 show this capability = exchange? > > > > > > > > > > It turns out that independent of > > > > > draft-ietf-netconf-notification-messages, there several > > > > > questions in draft-ietf-netconf-https-notif which need to be > > > > > answered prior to the section 1.4.1 arrow: "Send HTTPS POST > > > > > message with YANG defined notification #1" anyway. These > questions are: > > > > > (1) Does the targeted HTTPS receiver support configured > subscriptions? > > > > > (2) Can the targeted HTTP@ receiver accept a new = subscription as > > > > > described in a ? > > > > > Only if these questions are "yes", should the > > > > > be responded to with an "OK". > > > > > > > > > > Add to this a third question driven from (a)-(d): > > > > > (3) Does the receiver support the message type within > > > > > "draft-ietf-netconf-notification-messages"? > > > > > > > > > > A strawman way to handle the all three questions within > > > > > draft-ietf-netconf-https-notif would be to respond to a > > > > > notification with an HTTP Status 202 > > > > > (Accepted)" acknowledgement. This 202 would include body > > > > > elements listing supported receiver resources. Maybe = something > > > > > YANG encoded via ietf-yang-structure-ext containing: > > > > > > > > > > > > > > > > > > > > > > > > > = urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 > > > > > > > > > > > > > > > > > > > > > > > > > What do you think of this approach? > > > > > > > > > > Eric > > > > > > > > Mahesh Jethanandani > > > > mjethanandani@gmail.com > > > > > > > > > > > > ------=_NextPart_000_058A_01D5D5D0.ECFF0EF0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTI4MTY0ODU4WjAjBgkqhkiG 9w0BCQQxFgQUTUZtPGvulHmWSdkb7zo7vUwb9o4wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAX40L3amKxNADYjMQ69yUA0T1SFJRPQpOF9ius/+ffGtAY+54XekklZ9Bkk7lhH2DM ekCUcgax44sNbUvr8R8H1GBgnH3kr5cXAdHSIDCzao5swqiP/dw1LiRFmDaqC0RZTXQjRQdw8d7s AYbXYbpo1EbNl9+s9FwBl+0RTpXNmJOD8rt5evr9spwaCy8FKLjcm6wZWq/SgGH4yq2ppcQDhyvE qpJgzHX6vwJvZB92k3JP34hf4gsdQ8vCZPDcZDHN/QPumIY85zVm3w7f32/62qjzQgrRwNFETiMB WeIPe3U74oGxrYGm6CHrWXF9G4iC1HcAK55RLdDpJ7GdsNd5AAAAAAAA ------=_NextPart_000_058A_01D5D5D0.ECFF0EF0-- From nobody Tue Jan 28 10:13: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 4DD4C12004E for ; Tue, 28 Jan 2020 10:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ih23aTQ2E7W for ; Tue, 28 Jan 2020 10:13:23 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E3A1200EB for ; Tue, 28 Jan 2020 10:13:22 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id b15so9834474lfc.4 for ; Tue, 28 Jan 2020 10:13:22 -0800 (PST) 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=ZKP1M6ED7BJQCbB/0z3ZC1rmISpQlzUKmXuYCTZgw9o=; b=LfWS4iW2kl5VOkFZulOpzVSGiHS3wVJoGzhFmvkNeHCBpN886veTue1fQBeT78j7AY U0llX9V82SIbK6vXplSz59FEg8YQqLt5GRM67axczg633VuaxlsrBT7ZmHyAW9m+lpNM kX1hGLrkOvOJW2suf5Ra5okTEYzvQxDgXdI9Wg1WgfObOMrAwKnOU38acwJFKfEeKy5b /U1H8n4q9V0r9betpIn6JWllkM38gITrWNMV9sf5ezOGGvSfMBB3bqMG8xTv6jFH22mR VUEmdARE5zf15UuCF0+ks9JPryiPEEKEcspzw1ThI1VpCaJ39qYgOzcF5OLU4GbT+t/k nqzA== 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=ZKP1M6ED7BJQCbB/0z3ZC1rmISpQlzUKmXuYCTZgw9o=; b=ibwPiJdocuaNmOsQB4k+oPvT68huqo2Mie5UWQjPMkZ5DfOBim9aTyySnTW23xd5/9 n1VIpDlVLBUXmEqeglsgb0zVpaMT6PPIk0CBxz7Xq5r6X7vwkoATJMvNrmwsmdXqHpys 22DIgkoDK5JYAs9lVcMHtN/XjZOgxZL8uN49Fxhxa5b0QJzl4XS+6zhaOtDO1mzJQM+r w2F2PvXZAQKScxZ185FwV0oVejJPeySxLMzXFIy2FIgM4spBaWEV+eTsj/EN/4AM44Ow 7xI9jGsoaO/CNmECXr21ML2iVSXlV46QhtuVGUJLGQpIlWYplHtF8iEGgJRe+fyYLWMr WRwQ== X-Gm-Message-State: APjAAAU5cAHiyenbJ7FynLk+GdCAIe83x8hF8VKPhTEFmjjI5EkeRsfb 2r2nNlClhmEu+I1XXvZnq9Xw+J1lfA2rclJkPUaXxw== X-Google-Smtp-Source: APXvYqwoeJmWmdZZtukuXlsJmnkEebdJMrAiPO1hFI1olbkevouHUkpKud/X9i9P0pE0oDV+mWIyw8R7aNoNbpAUiF8= X-Received: by 2002:a19:ac43:: with SMTP id r3mr3153130lfc.156.1580235200771; Tue, 28 Jan 2020 10:13:20 -0800 (PST) MIME-Version: 1.0 References: <123C86B4-CE8C-4BBD-84CF-630310CEA50E@gmail.com> In-Reply-To: <123C86B4-CE8C-4BBD-84CF-630310CEA50E@gmail.com> From: Andy Bierman Date: Tue, 28 Jan 2020 10:13:09 -0800 Message-ID: To: Mahesh Jethanandani Cc: "Eric Voit (evoit)" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cdce4a059d372dad" Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 28 Jan 2020 18:13:25 -0000 --000000000000cdce4a059d372dad Content-Type: text/plain; charset="UTF-8" On Mon, Jan 27, 2020 at 4:19 PM Mahesh Jethanandani wrote: > Hi Eric, > > This e-mail triggers two responses. Let us deal with > draft-ietf-netconf-notification-messages here, and I will bring up > comments/questions related to draft-ietf-netconf-https-notif in the other > thread. > > You have indicated a desire that receiver capabilities should be > documented by the transport specific draft, e.g. > draft-ietf-netconf-https-notif, and not this draft. As such you believe > that the draft is ready. > > To the WG, the authors have indicated a desire to wrap up this draft, and > would like us, the chairs, to issue a WGLC on it. Before we do that, we > wanted to ask if the WG believes that the document is ready, and that there > are no more issues that need to discussed/addressed by > draft-ietf-netconf-notification-messages document at this time. > > I would like to see clear and consistent text wrt to RFC 5277. There is this confusing text: YANG one-way exchanges currently use a non-extensible header and encoding defined in section 4 of RFC-5277 . These RFCs MUST be updated to enable this draft. These RFCs SHOULD be updated to provide examples This seems inconsistent with this text: Backwards Compatibility With this specification, there is no change to YANG's 'notification' statement Legacy clients are unaffected, and existing users of [RFC5277 ], [RFC7950 ], and [RFC8040 ] are free to use current behaviors until all involved device support this specification. It is rather odd to see RFC 2119 language used for a directive to a WG to take on some sort of work item. (RFCs MUST be updated) I think this draft needs some sort of Applicability Statement. Why are servers supposed to use this header and stop using the RFC 5277 header? The mandatory info like subscription-id is redundant since the payload already has this info. This new header can make it much more difficult for a client to write code to process a notification, since the header itself would be modeled with YANG and subject to change. The processing may also be slower because the added complexity. It does not seem that every server needs this added complexity. Cheers. > > Mahesh and Kent (as co-chairs). > > Andy > On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) wrote: > > Hi Mahesh, > > During the IETF 106 session, there was discussion on how both a publisher > might know if there is receiver support for > draft-ietf-netconf-notification-messages > . > Section 6 highlights several of the considerations. Relevant are the > following: > > (a) Remote device capability discovery from the point of view of the > Publisher needs to be enhanced to know if the far end can interpret > notification messages type beyond RFC-5277, Section 4. > > (b) This capability discovery question is relevant for both configured > subscription receivers and dynamic subscribers. > > (c) The capability discovery question can be generalized beyond > subscriptions, as there are many reasons to know the available capabilities > of the far end. > > (d) Capability discovery advertisement has traditionally been discussed > within transport documents (e.g. RFC-6241 Section 8.1). > > > Based on (a)-(d), coming up with a transport independent point-solution > within draft-ietf-netconf-notification-messages > > *just* to discover this single element of client functionality seems > overkill/heavyweight. > > I was fine with letting this remote capabilities discovery question sit > for a while. However draft-ietf-netconf-https-notif > shows > that we now must address this question. Specifically should the diagram > section 1.4.1 show this capability exchange? > > It turns out that independent of draft-ietf-netconf-notification-messages, > there several questions in draft-ietf-netconf-https-notif which need to be > answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with > YANG defined notification #1" anyway. These questions are: > (1) Does the targeted HTTPS receiver support configured subscriptions? > (2) Can the targeted HTTP@ receiver accept a new subscription as > described in a ? > Only if these questions are "yes", should the be > responded to with an "OK". > > Add to this a third question driven from (a)-(d): > (3) Does the receiver support the message type within > "draft-ietf-netconf-notification-messages"? > > A strawman way to handle the all three questions within > draft-ietf-netconf-https-notif would be to respond to a > notification with an HTTP Status 202 (Accepted)" > acknowledgement. This 202 would include body elements listing supported > receiver resources. Maybe something YANG encoded via > ietf-yang-structure-ext containing: > > > > > urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 > > > > > What do you think of this approach? > > Eric > > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000cdce4a059d372dad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 27, 2020 at 4:19 PM Mahes= h Jethanandani <mjethanandani= @gmail.com> wrote:
Hi Eric,

This e-mail triggers two responses. Let us deal with draft-ietf-netco= nf-notification-messages here, and I will bring up comments/questions relat= ed to draft-ietf-netconf-https-notif in the other thread.

You have indicated a desire that receiver capabilities should be do= cumented by the transport specific draft, e.g. draft-ietf-netconf-https-not= if, and not this draft. As such you believe that the draft is ready.
<= div>
To the WG, the authors have indicated a desire to wrap u= p this draft, and would like us, the chairs, to issue a WGLC on it. Before = we do that, we wanted to ask if the WG believes that the document is ready,= and that there are no more issues that need to discussed/addressed by draf= t-ietf-netconf-notification-messages document at this time.

<= /div>


I would like to = see clear and consistent text wrt to RFC 5277.
There is this conf= using text:

=C2=A0=C2=A0 =C2=A0 =C2=A0YANG one-way exchanges currently u= se a non-extensible header and
   encoding defined in section=C2=A04 of RFC-5277.  These RFCs MUST =
be
   updated to enable this draft.  These RFCs SHOULD be updated to
   provide examples



This seems inconsistent with this text:

  Backwards Compatibility


   With this specification, there is no change to YANG's 'notificat=
ion'
   statement

   Legacy clients are unaffected, and existing users of [RFC5277],
   [RFC7950], and [RFC8040<=
/a>] are free to use current behaviors until all
   involved device support this specification.



It is rather odd to see RFC =
2119 language used for a directive to a WG
to take on some sort of work =
item. (RFCs MUST be updated)

I think this draft needs some sort of Applicability Statemen=
t. Why are servers supposed
to use this hea= der and stop using the RFC 5277 header?=C2=A0 The mandatory info like subsc= ription-id
is redundant since the payload a= lready has this info.=C2=A0

This new header can make it much more difficult for a= client to write code to process a notification,
since the header itself would be modeled with YANG and subject to cha= nge.=C2=A0 The processing
may also be slowe= r because the added complexity.=C2=A0 It does not seem that every server ne= eds
this added complexity.



Cheers.

Mahesh and Kent (as c= o-chairs).


<= br>
Andy
=C2=A0

Hi Mahesh,=
=C2=A0
During the IETF 106= session, there was discussion on how both a publisher might know if there = is receiver support for=C2=A0draft-ietf-netconf-notification-messages= .=C2=A0 Section 6 highlights several of the considerations.=C2= =A0=C2=A0=C2=A0Relevant are the following:=
=C2=A0
(a) Remote devic= e capability discovery from the point of view of the Publisher needs to be = enhanced to know if the far end can interpret notification messages type be= yond RFC-5277, Section 4.
=C2=A0=
(b) This capability discovery question is relevant for both= configured subscription receivers and dynamic subscribers.=C2=A0=C2= =A0
=C2=A0
(c) The capability discovery question can be generalized beyond subscripti= ons, as there are many reasons to know the available capabilities of the fa= r end.=C2=A0=C2=A0=C2=A0
= =C2=A0
(d) Capability discovery advertisement has tra= ditionally been discussed within transport documents (e.g. RFC-6241 Section= 8.1).=C2=A0 =C2=A0
=C2=A0
=
=C2=A0
Based on (a)-(d), coming up w= ith a transport independent point-solution within=C2=A0draft-ietf-net= conf-notification-messages=C2=A0*just* to discover = this single element of client functionality seems overkill/heavyweight.<= /u>
=C2=A0
I was fine wi= th letting this remote capabilities discovery question sit for a while.=C2= =A0=C2=A0 However=C2=A0draft-ietf-netconf-https-notif=C2=A0shows that we now must address this question.=C2=A0 Specifica= lly should the diagram section 1.4.1 show this capability exchange?=C2=A0=C2=A0
=C2=A0
It turns out that independent of draft-ietf-netconf-notification-me= ssages, there several questions in draft-ietf-netconf-https-notif which nee= d to be answered prior to the section 1.4.1 arrow: "Send HTTPS POST me= ssage with YANG defined notification #1" anyway.=C2=A0 These questions= are:
=C2=A0 (1) Does the targeted HTTPS recei= ver support configured subscriptions?
=C2=A0 (= 2) Can the targeted HTTP@ receiver accept a new subscription as described i= n a <subscription-started>?
Only if thes= e questions are "yes", should the <subscription-started> be= responded to with an "OK".
= =C2=A0
Add to this a third question driven from (a)-(= d):
=C2=A0 (3) Does the receiver support the m= essage type within "draft-ietf-netconf-notification-messages"?=
=C2=A0
A strawman w= ay to handle the all three questions within draft-ietf-netconf-https-notif = would be to respond to a <subscription-started> notification with an = HTTP Status 202 (Accepted)" acknowledgement.=C2=A0 This 202 would incl= ude body elements listing supported receiver resources.=C2=A0 Maybe somethi= ng YANG encoded via ietf-yang-structure-ext containing:
=
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <foo xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &l= t;capabilities>
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 <capability>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 urn:iet= f:params:xml:ns:yang:ietf-notification-messages:1.0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </capabilit= y>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0</capabilities>
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 </foo>
=C2=A0
What do you think of this approach?
=C2=A0
Eric
<= /div>
Mahesh Jethanandani



_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000cdce4a059d372dad-- From nobody Thu Jan 30 17:01:35 2020 Return-Path: <0100016ff91dfd1b-9e8e6622-7e36-45dc-a661-f4702b494040-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 92F6F120131 for ; Thu, 30 Jan 2020 17:01:33 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 H3hPMmtHDJ90 for ; Thu, 30 Jan 2020 17:01:31 -0800 (PST) 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 28E41120074 for ; Thu, 30 Jan 2020 17:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1580432489; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=KbPyasI42eDo2/PXFJjlvvrLNnOyWP+o0O/Rvh2ieDI=; b=TVgdsG5+D3AyeWX4NH1TaWPa24xpI0Jrm/u+h064prs96EDLxNmY/xcIyJ4H3XeR 1GJcZRLpRw24hubu3pUoJCK57waJq4/WYydWrVCh0jUyB4qP3TFUxyFAr0/MuW2QIol jBo20Ye0trSyIuJBRtRtqPUpxQKSuubu/XB8SOPg= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_4177C143-696A-45EF-A249-D047D1B21490" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <0100016ff91dfd1b-9e8e6622-7e36-45dc-a661-f4702b494040-000000@email.amazonses.com> Date: Fri, 31 Jan 2020 01:01:29 +0000 Cc: Russ Housley To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.01.31-54.240.48.95 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Truststore: bags, sets, or other? X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 31 Jan 2020 01:01:34 -0000 --Apple-Mail=_4177C143-696A-45EF-A249-D047D1B21490 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [CC-ing Russ, who says he knows a lot about bags ;) The truststore draft [1] has the following general structure: module: ietf-truststore +--rw truststore +--rw certificates* [name] {x509-certificates}? | +--rw name string | +--rw certificate* [name] | +--rw name string | ... +--rw host-keys* [name] {ssh-host-keys}? | +--rw name string | +--rw host-key* [name] | +--rw name string | ... +--rw raw-public-keys* [name] {raw-public-keys}? +--rw name string +--rw raw-public-key* [name] +--rw name string ... I have been struggling with the naming of the top-level nodes = (/certificates, /host-keys, etc.) being plural while also being = =E2=80=98list=E2=80=99 elements. What is intended is that each of = these top-level nodes is a "list of sets/bags of things. To resolve = this issue, I=E2=80=99m thinking about the following change: OLD: +--rw s* [name] {}? +--rw name string +--rw * [name] +--rw name string =E2=80=A6 NEW: +--rw -bags {}? +--rw -bag* [name] +--rw name string +--rw * [name] +--rw name string =E2=80=A6 Better, right? Any other ideas? Note that the term =E2=80=9Cbag=E2=80=9D is the commonly used term in = crypto circles with regard to PKI and, in particular, in reference to = the =E2=80=9CCertBag=E2=80=9D type defined in Section 4.2.3 in RFC 7292 = [2]. That said, I don=E2=80=99t think that =E2=80=9Cbag" is commonly = used in reference to SSH host keys or raw public keys. I don=E2=80=99t = know if that is any issue but, in case it is, the choices are: 1) use =E2=80=9Cbag=E2=80=9D for all three 2) use =E2=80=9Cset=E2=80=9D for all three 3) use =E2=80=9Cbag=E2=80=9D for certificates and =E2=80=9Cset=E2=80= =9D for the other two 4) Thoughts? [1] https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors = [2] https://tools.ietf.org/html/rfc7292#section-4.2.3 = Kent --Apple-Mail=_4177C143-696A-45EF-A249-D047D1B21490 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [CC-ing Russ, who says he = knows a lot about bags ;)


The truststore draft [1] = has the following general structure:

   module: = ietf-truststore
     +--rw truststore
      =   +--rw certificates* [name] {x509-certificates}?
      =   |  +--rw name           = string
        |  +--rw certificate* = [name]
        |     +--rw name =                     =  string
        |     = ...
        +--rw host-keys* [name] = {ssh-host-keys}?
        |  +--rw name     =       string
        | =  +--rw host-key* [name]
        |   =   +--rw name        string
      =   |     ...
        +--rw = raw-public-keys* [name] {raw-public-keys}?
      =      +--rw name             =  string
           +--rw = raw-public-key* [name]
              +--rw = name                 = string
              = ...


I = have been struggling with the naming of the top-level nodes = (/certificates, /host-keys, etc.) being plural while also = being =E2=80=98list=E2=80=99 elements.   What is intended is = that each of these top-level nodes is a "list of sets/bags of things. =    To resolve this issue, I=E2=80=99m thinking about the = following change:

OLD:
      =       +--rw <thing>s* = [name] {<thing-feature>}?
      =          +--rw name string
                =   +--rw <thing>* [name]
      =                +--rw = name string
            =           =E2=80=A6

NEW:
            +--rw = <thing>-bags {<thing-feature>}?
    =            +--rw <thing>-bag* = [name]
              =     +--rw name string
      =                +--rw = <thing>* [name]
          =               +--rw name string
                =          =E2=80=A6

Better, right?   Any other ideas?

Note that the term =E2=80=9Cbag=E2=80=9D is the commonly used = term in crypto circles with regard to PKI and, in particular, in = reference to the =E2=80=9CCertBag=E2=80=9D type defined in Section 4.2.3 = in RFC 7292 [2].   That said, I don=E2=80=99t think that = =E2=80=9Cbag" is commonly used in reference to SSH host keys or raw = public keys.  I don=E2=80=99t know if that is any issue but, in = case it is, the choices are:

1) use =E2=80=9Cbag=E2=80=9D for = all three
2) use =E2=80=9Cset=E2=80=9D for = all three
3) use =E2=80=9Cbag=E2=80=9D for = certificates and =E2=80=9Cset=E2=80=9D for the other two
= 4) <another idea?>

Thoughts?


[1] https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors
[2] https://tools.ietf.org/html/rfc7292#section-4.2.3

Kent


= --Apple-Mail=_4177C143-696A-45EF-A249-D047D1B21490-- From nobody Fri Jan 31 02:10: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 033271200D6 for ; Fri, 31 Jan 2020 02:10:32 -0800 (PST) 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 0c5FpOmtd-1v for ; Fri, 31 Jan 2020 02:10:30 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2141D120026 for ; Fri, 31 Jan 2020 02:10:30 -0800 (PST) Received: from localhost (h-4-44.A165.priv.bahnhof.se [158.174.4.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 13A711AE02F0; Fri, 31 Jan 2020 11:10:28 +0100 (CET) Date: Fri, 31 Jan 2020 11:10:27 +0100 (CET) Message-Id: <20200131.111027.840757629039452002.mbj@tail-f.com> To: kent@watsen.net Cc: netconf@ietf.org, housley@vigilsec.com From: Martin Bjorklund In-Reply-To: <0100016ff91dfd1b-9e8e6622-7e36-45dc-a661-f4702b494040-000000@email.amazonses.com> References: <0100016ff91dfd1b-9e8e6622-7e36-45dc-a661-f4702b494040-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] Truststore: bags, sets, or other? X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 31 Jan 2020 10:10:32 -0000 SGksDQoNCktlbnQgV2F0c2VuIDxrZW50QHdhdHNlbi5uZXQ+IHdyb3RlOg0KPiBbQ0MtaW5nIFJ1 c3MsIHdobyBzYXlzIGhlIGtub3dzIGEgbG90IGFib3V0IGJhZ3MgOykNCj4gDQo+IA0KPiBUaGUg dHJ1c3RzdG9yZSBkcmFmdCBbMV0gaGFzIHRoZSBmb2xsb3dpbmcgZ2VuZXJhbCBzdHJ1Y3R1cmU6 DQo+IA0KPiAgICBtb2R1bGU6IGlldGYtdHJ1c3RzdG9yZQ0KPiAgICAgICstLXJ3IHRydXN0c3Rv cmUNCj4gICAgICAgICArLS1ydyBjZXJ0aWZpY2F0ZXMqIFtuYW1lXSB7eDUwOS1jZXJ0aWZpY2F0 ZXN9Pw0KPiAgICAgICAgIHwgICstLXJ3IG5hbWUgICAgICAgICAgIHN0cmluZw0KPiAgICAgICAg IHwgICstLXJ3IGNlcnRpZmljYXRlKiBbbmFtZV0NCj4gICAgICAgICB8ICAgICArLS1ydyBuYW1l ICAgICAgICAgICAgICAgICAgICAgIHN0cmluZw0KPiAgICAgICAgIHwgICAgIC4uLg0KPiAgICAg ICAgICstLXJ3IGhvc3Qta2V5cyogW25hbWVdIHtzc2gtaG9zdC1rZXlzfT8NCj4gICAgICAgICB8 ICArLS1ydyBuYW1lICAgICAgICAgICBzdHJpbmcNCj4gICAgICAgICB8ICArLS1ydyBob3N0LWtl eSogW25hbWVdDQo+ICAgICAgICAgfCAgICAgKy0tcncgbmFtZSAgICAgICAgc3RyaW5nDQo+ICAg ICAgICAgfCAgICAgLi4uDQo+ICAgICAgICAgKy0tcncgcmF3LXB1YmxpYy1rZXlzKiBbbmFtZV0g e3Jhdy1wdWJsaWMta2V5c30/DQo+ICAgICAgICAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAg c3RyaW5nDQo+ICAgICAgICAgICAgKy0tcncgcmF3LXB1YmxpYy1rZXkqIFtuYW1lXQ0KPiAgICAg ICAgICAgICAgICstLXJ3IG5hbWUgICAgICAgICAgICAgICAgIHN0cmluZw0KPiAgICAgICAgICAg ICAgIC4uLg0KPiANCj4gDQo+IEkgaGF2ZSBiZWVuIHN0cnVnZ2xpbmcgd2l0aCB0aGUgbmFtaW5n IG9mIHRoZSB0b3AtbGV2ZWwgbm9kZXMNCj4gKC9jZXJ0aWZpY2F0ZXMsIC9ob3N0LWtleXMsIGV0 Yy4pIGJlaW5nIHBsdXJhbCB3aGlsZSBhbHNvIGJlaW5nIOKAmGxpc3TigJkNCj4gZWxlbWVudHMu ICBXaGF0IGlzIGludGVuZGVkIGlzIHRoYXQgZWFjaCBvZiB0aGVzZSB0b3AtbGV2ZWwgbm9kZXMg aXMgYQ0KPiAibGlzdCBvZiBzZXRzL2JhZ3Mgb2YgdGhpbmdzLiAgVG8gcmVzb2x2ZSB0aGlzIGlz c3VlLCBJ4oCZbSB0aGlua2luZw0KPiBhYm91dCB0aGUgZm9sbG93aW5nIGNoYW5nZToNCj4gDQo+ IE9MRDoNCj4gICAgICAgICAgICAgKy0tcncgPHRoaW5nPnMqIFtuYW1lXSB7PHRoaW5nLWZlYXR1 cmU+fT8NCj4gICAgICAgICAgICAgICAgKy0tcncgbmFtZSBzdHJpbmcNCj4gICAgICAgICAgICAg ICAgICAgKy0tcncgPHRoaW5nPiogW25hbWVdDQo+ICAgICAgICAgICAgICAgICAgICAgICstLXJ3 IG5hbWUgc3RyaW5nDQo+ICAgICAgICAgICAgICAgICAgICAgICDigKYNCj4gDQo+IE5FVzoNCj4g ICAgICAgICAgICAgKy0tcncgPHRoaW5nPi1iYWdzIHs8dGhpbmctZmVhdHVyZT59Pw0KPiAgICAg ICAgICAgICAgICArLS1ydyA8dGhpbmc+LWJhZyogW25hbWVdDQo+ICAgICAgICAgICAgICAgICAg ICstLXJ3IG5hbWUgc3RyaW5nDQo+ICAgICAgICAgICAgICAgICAgICAgICstLXJ3IDx0aGluZz4q IFtuYW1lXQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICArLS1ydyBuYW1lIHN0cmluZw0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAg4oCmDQo+IA0KPiBCZXR0ZXIsIHJpZ2h0PyAgIEFueSBv dGhlciBpZGVhcz8NCg0KV2UgaGF2ZSBjdXJyZW50IHB1Ymxpc2hlZCBtb2R1bGVzIHdpdGggYm90 aCAiLWxpc3QiIGFuZCAiLXNldCIuICBObw0KIi1iYWciIHNvIGZhci4NCg0KRm9yIGV4YW1wbGU6 DQoNCiAgImxpc3QgcnVsZS1saXN0IiBpbiBpZXRmLW5ldGNvbmYtYWNtDQoNCiAgImxpc3QgbW9k dWxlLXNldCIgaW4gaWV0Zi15YW5nLWxpYnJhcnkNCg0KVGhlcmUgYXJlIHNvbWUgZXhhbXBsZXMg b2YgInMiIGFzIHdlbGwsIGJ1dCB0aGVzZSBhcmUgcGx1cmFsICJzIiBmb3IgYQ0Kbm9ybWFsIGxp c3Qgb2Ygc2luZ2xldG9ucywgYW5kIHNob3VsZCBoYXZlIGJlZW4gbmFtZWQgdy9vIHRoZSBwbHVy YWwNCiJzIiAoaWYgd2Ugd2VyZSB0byBiZSBjb25zaXN0ZW50KS4NCg0KSSB3b3VsZCB0cnkgdG8g YXZvaWQgInMiIGZvciBhICJsaXN0LW9mLWxpc3RzIiwgYnV0IHRoZW4gcGljayB0aGUNCnN1ZmZp eCB0aGF0IGZlZWxzIG1vc3QgbmF0dXJhbCBpbiB0aGUgZG9tYWluLiAgKEZvciBleGFtcGxlLCBy YXRoZXINCiJsaXN0IGFjY2Vzcy1jb250cm9sLWxpc3QiIHRoYW4gImxpc3QgYWNjZXNzLWNvbnRy b2wtc2V0IikuDQoNClBlcmhhcHMgeW91IGNhbiBhcmd1ZSB0aGF0ICItbGlzdCIgd29ya3MgYmV0 dGVyIGZvciBvcmRlcmVkIHNlcXVlbmNlcywNCmFuZCAiLXNldCIgYW5kICItYmFnIiBmb3IgdW5v cmRlcmVkLiAgQnV0IHRoZW4gdGhlcmUgYXJlICJvcmRlZGVkDQpzZXRzIiBhbmQgInVub3JkZXJl ZCBsaXN0cyIgKGFuZCBldmVuIGFwcGFyZW50bHkgIm9yZGVyZWQgYmFnIiwgaW4NClVNTCkuDQoN ClRoZSBwbHVyYWwgInMiIGlzIGJldHRlciBmb3IgYSBzdXJyb3VuZGluZyBjb250YWluZXIgKGlm IG9uZSBleGlzdHMpLg0KDQoNCi9tYXJ0aW4NCg0KDQo+IA0KPiBOb3RlIHRoYXQgdGhlIHRlcm0g 4oCcYmFn4oCdIGlzIHRoZSBjb21tb25seSB1c2VkIHRlcm0gaW4gY3J5cHRvIGNpcmNsZXMNCj4g d2l0aCByZWdhcmQgdG8gUEtJIGFuZCwgaW4gcGFydGljdWxhciwgaW4gcmVmZXJlbmNlIHRvIHRo ZSDigJxDZXJ0QmFn4oCdDQo+IHR5cGUgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMi4zIGluIFJGQyA3 MjkyIFsyXS4gIFRoYXQgc2FpZCwgSSBkb27igJl0DQo+IHRoaW5rIHRoYXQg4oCcYmFnIiBpcyBj b21tb25seSB1c2VkIGluIHJlZmVyZW5jZSB0byBTU0ggaG9zdCBrZXlzIG9yIHJhdw0KPiBwdWJs aWMga2V5cy4gIEkgZG9u4oCZdCBrbm93IGlmIHRoYXQgaXMgYW55IGlzc3VlIGJ1dCwgaW4gY2Fz ZSBpdCBpcywNCj4gdGhlIGNob2ljZXMgYXJlOg0KPiANCj4gCTEpIHVzZSDigJxiYWfigJ0gZm9y IGFsbCB0aHJlZQ0KPiAJMikgdXNlIOKAnHNldOKAnSBmb3IgYWxsIHRocmVlDQo+IAkzKSB1c2Ug 4oCcYmFn4oCdIGZvciBjZXJ0aWZpY2F0ZXMgYW5kIOKAnHNldOKAnSBmb3IgdGhlIG90aGVyIHR3 bw0KPiAJNCkgPGFub3RoZXIgaWRlYT8+DQo+IA0KPiBUaG91Z2h0cz8NCj4gDQo+IA0KPiBbMV0g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi10cnVzdC1hbmNo b3JzDQo+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXRy dXN0LWFuY2hvcnM+DQo+IFsyXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzI5MiNz ZWN0aW9uLTQuMi4zDQo+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzI5MiNzZWN0 aW9uLTQuMi4zPg0KPiANCj4gS2VudA0KPiANCj4gDQo= From nobody Fri Jan 31 10:04:08 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 267601208CC for ; Fri, 31 Jan 2020 10:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=eE9iMDrC; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=x7kBUzJP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-depItvrOTj for ; Fri, 31 Jan 2020 10:04:04 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1911201E0 for ; Fri, 31 Jan 2020 10:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30858; q=dns/txt; s=iport; t=1580493844; x=1581703444; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lfd2qArvGSJ36KzkSe/Dux12URN4+KUH5M6cu8k0IW8=; b=eE9iMDrC/uwUeASwr0lkDP35Q1MZrMDu0SiRpjJa0vDpXCq62PXklygP AEMjlW8aD8KOTrQdfoBRd29ATqSfkqhE3O/J9cljT5KLRac0A6pemkHe2 sVbLUTMXBLt0DJvknoOgm7HecVG5es2lbaH+i93Ukfuqn/RvKX7yKHqbW k=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AelI09x1vKNQd1KB+smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGPt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQBFP8LeLCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DzCAAUazRe/5tdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBJS9QBWwrLSAECyoKhAqDRgOKdYJfhz2CJI4uglIDVAIHAQE?= =?us-ascii?q?BCQMBARgBDAgCAQGDe0UCgjEkOBMCAw0BAQQBAQECAQUEbYU3DIVmAQEBAQM?= =?us-ascii?q?BARARChMBASwJAgEPAgEIFRATAwQDAgICHwYLFBECBAENBQgGDQeDBYF9TQM?= =?us-ascii?q?fDwECDKMGAoE5iGJ1gTKCfwEBBYEzAg5BgxENC4IFBwMGgTiBU4pNGoFBP4E?= =?us-ascii?q?RR4JMPoIbSQEBAgEBGIExGCsJgloygiyNXYleiHOOckQKgjuDa4I4gSKKUIR?= =?us-ascii?q?FgkiYPY5ggUuHHIIokAkCBAIEBQIOAQEFgWkigVhwFTuCbFAYDY4dOIM7hRS?= =?us-ascii?q?FP3SBKYwQAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.70,386,1574121600"; d="p7s'?scan'208,217";a="624844227" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Jan 2020 18:04:02 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 00VI42pO002647 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Jan 2020 18:04:02 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 12:04:02 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 12:04:01 -0600 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 31 Jan 2020 12:04:01 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bklz6KBknbv9s6iNSdpkNBPPu9CuI+zKshlcc1xIHT9OmM1nxdXbbH+LsMfK9bSo+EAAv5/F1FcLP/fiy/u06WL3cSLEKGZJlsKPgAWx3ZWuhsbgyuNV61k0Gr9XT2DMcViT6vpIzb70QmU/04eGdEDx/rZcdkKp9r4KLj/huceqP8mlXbqrNWUytk8JY5v4TbI0W8zj+62QbShHMyYG0OZ/GiGFg0emyYrIEpo9yVDqhnVZ5aOxN8It/tZr99vTgRtneijedadawme0RxXnpTNFhNEGMJtDkqWF9l0+Muk6Kja6gzyXxtS/Bb57n6p5Aqm6GlsXRuFnlnU3AXV+wQ== 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=W3nYC848cnH1mEVsnBbMa23uOO7skMRAg5JNCTu7Ys8=; b=Ozhd0p1kBGKT1aGlpj89i79meb7iJdHTURQ3JA5hfpUp7gGdFL3iJ92RT5yQMgar8nkeIKijp/As79D37994A4dA+PDKxy74i48My/jULkOXEKcRBvTuXg7mzXP9Ic2SLHQtwKKI3ORntH+gMugvVQLQPNcPZrYLOckHDBoKCdvYfxZCeQNP/RnfBt270rWxTEqdzUhrIh7JMlmnMRes3iQ7i3wfZpor+MPvgMA/XEIf/vH6A4YH0M0aJ7nPL6i8KbMcIfMGgHAjofnGfQn3RxcHFBCVDkzMi42dUNVxJR2GiY50I5AfvN42irR0489a9hoGIMwfpYrNFKaJ3a5gJw== 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=W3nYC848cnH1mEVsnBbMa23uOO7skMRAg5JNCTu7Ys8=; b=x7kBUzJPOCQEM9nymf2SfuN49dGBc0ugqoVRFG6r2JSvOscagP+4uVbaDS00hei6MGvyluXjqDWSyV9tJMft2WUYAAxL05LarOqyfJXD+HlVI3A1MTU8ETwSLmdFA1MdGKgHovMUgfxNC0Umi0/J3cjK1v+hve+MI4im144+Z4o= Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB3221.namprd11.prod.outlook.com (20.177.186.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.24; Fri, 31 Jan 2020 18:04:00 +0000 Received: from BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5]) by BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5%5]) with mapi id 15.20.2665.027; Fri, 31 Jan 2020 18:04:00 +0000 From: "Eric Voit (evoit)" To: Andy Bierman , Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) Thread-Index: AQHV1XCe/lJrt7B/vkCp8Nt9IDtyWKgAYk+AgASxC2A= Date: Fri, 31 Jan 2020 18:04:00 +0000 Message-ID: References: <123C86B4-CE8C-4BBD-84CF-630310CEA50E@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d243d11a-58c7-4491-4221-08d7a677f30b x-ms-traffictypediagnostic: BYAPR11MB3221: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 029976C540 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(366004)(136003)(39860400002)(376002)(199004)(189003)(186003)(15650500001)(110136005)(66946007)(55016002)(9686003)(26005)(52536014)(66616009)(66476007)(64756008)(33656002)(5660300002)(76116006)(66556008)(66446008)(71200400001)(86362001)(53546011)(6506007)(81166006)(8676002)(4326008)(316002)(478600001)(81156014)(7696005)(966005)(9326002)(2906002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3221; H:BYAPR11MB2536.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HBBV6LQZk4txk+A3ktRz67on0GAvX7LS/YzlTJ3korzsgW4xpYCS06xf8QnIiMsHrZGpvIfUJURsmGIRpvaxmHwDTZDMm8YD7vEdiFy5bt+L6xpEtRdI3efTS5KVHaagiK9e5yN47qmrrM/VC5Y0ib8VM0p1cBgj+gwSIpuwy4cO3Avq85rkz6F+9I9Cns8966hTaef7hB+/p3z/xhtmrwtIjgZVGd0QIx9KWZuM0zWbjDzTzRwcGVYgJDu+07X6Xxxad56jbIpqy++QJY8y4anVuk3+S5q2fCjYXWwU/DOnAd/NhlzW1FbbpeoeGW1wbPJGxAAMFp0Oq8Q+CI+fKjUHq0qJCO/1D5a5eSKi2uk/rHqmz7J+ZB35bCbdP0qcur3zZSiAQY9mnjItqoF6ZrSEtmTO0UKhAZ/dMOvC79BGQvApkKtzgm3ywuKcFwawZbmKoriIjpmqX161xJcvRVZnOx/ziranOasDqRGI/Zi5XWrDUNd0aFHUgzxHKcrF5Xa/tWWxZgLMFBQGIxlUew== x-ms-exchange-antispam-messagedata: 5WR9JUSE73YbibdMQD4nrcOlaBobrTb6xZ/LUfzvVM1bP9BFL8sjoh39b08j6eduNbyJ7NBifAumBNpDCSmosCXKeOpcRfReVJup5aBW4VUZuTUWdB7spDlYJFHv9rNs+qMia2C0orivtv5ar2u1gA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0AC0_01D5D836.E3C7BF90" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d243d11a-58c7-4491-4221-08d7a677f30b X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 18:04:00.3915 (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: linpw89dHt8TXMxugbASHdR8VwZugNRI8agz9qZYz+NWNHmHMUaPmlrcep32A6GO X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3221 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 31 Jan 2020 18:04:07 -0000 ------=_NextPart_000_0AC0_01D5D836.E3C7BF90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0AC1_01D5D836.E3C7BF90" ------=_NextPart_001_0AC1_01D5D836.E3C7BF90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi Andy, From: Andy Bierman, January 28, 2020 1:13 PM On Mon, Jan 27, 2020 at 4:19 PM Mahesh Jethanandani > wrote: Hi Eric, This e-mail triggers two responses. Let us deal with draft-ietf-netconf-notification-messages here, and I will bring up comments/questions related to draft-ietf-netconf-https-notif in the other thread. You have indicated a desire that receiver capabilities should be documented by the transport specific draft, e.g. draft-ietf-netconf-https-notif, and not this draft. As such you believe that the draft is ready. To the WG, the authors have indicated a desire to wrap up this draft, and would like us, the chairs, to issue a WGLC on it. Before we do that, we wanted to ask if the WG believes that the document is ready, and that there are no more issues that need to discussed/addressed by draft-ietf-netconf-notification-messages document at this time. I would like to see clear and consistent text wrt to RFC 5277. There is this confusing text: YANG one-way exchanges currently use a non-extensible header and encoding defined in section 4 of RFC-5277. These RFCs MUST be updated to enable this draft. These RFCs SHOULD be updated to provide examples This seems inconsistent with this text: Backwards Compatibility With this specification, there is no change to YANG's 'notification' statement Legacy clients are unaffected, and existing users of [RFC5277 ], [RFC7950 ], and [RFC8040 ] are free to use current behaviors until all involved device support this specification. I don't see these as inconsistent. The YANG notification statement is defined in RFC-7950 Section 7.16. And legacy clients do not need to change. It is rather odd to see RFC 2119 language used for a directive to a WG to take on some sort of work item. (RFCs MUST be updated) I agree that RFC 2119 language is not proper here. Perhaps the specific changes should be framed as notes to RFC editor. I think this draft needs some sort of Applicability Statement. Why are servers supposed to use this header and stop using the RFC 5277 header? Makes sense, I will put together some text on this. The mandatory info like subscription-id is redundant since the payload already has this info. The subscription-id is only in the notifications defined in RFC-8641. I.e. "push-update" and " push-change-update". This is the biggest gap which needs to be remedied. This new header can make it much more difficult for a client to write code to process a notification, since the header itself would be modeled with YANG and subject to change. The processing may also be slower because the added complexity. It does not seem that every server needs this added complexity. This is one reason that this specification isn't ready to obsolete RFC-5277 notifications. Eric Cheers. Mahesh and Kent (as co-chairs). Andy On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) > wrote: Hi Mahesh, During the IETF 106 session, there was discussion on how both a publisher might know if there is receiver support for draft-ietf-netconf-notification-messages. Section 6 highlights several of the considerations. Relevant are the following: (a) Remote device capability discovery from the point of view of the Publisher needs to be enhanced to know if the far end can interpret notification messages type beyond RFC-5277, Section 4. (b) This capability discovery question is relevant for both configured subscription receivers and dynamic subscribers. (c) The capability discovery question can be generalized beyond subscriptions, as there are many reasons to know the available capabilities of the far end. (d) Capability discovery advertisement has traditionally been discussed within transport documents (e.g. RFC-6241 Section 8.1). Based on (a)-(d), coming up with a transport independent point-solution within draft-ietf-netconf-notification-messages *just* to discover this single element of client functionality seems overkill/heavyweight. I was fine with letting this remote capabilities discovery question sit for a while. However draft-ietf-netconf-https-notif shows that we now must address this question. Specifically should the diagram section 1.4.1 show this capability exchange? It turns out that independent of draft-ietf-netconf-notification-messages, there several questions in draft-ietf-netconf-https-notif which need to be answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with YANG defined notification #1" anyway. These questions are: (1) Does the targeted HTTPS receiver support configured subscriptions? (2) Can the targeted HTTP@ receiver accept a new subscription as described in a ? Only if these questions are "yes", should the be responded to with an "OK". Add to this a third question driven from (a)-(d): (3) Does the receiver support the message type within "draft-ietf-netconf-notification-messages"? A strawman way to handle the all three questions within draft-ietf-netconf-https-notif would be to respond to a notification with an HTTP Status 202 (Accepted)" acknowledgement. This 202 would include body elements listing supported receiver resources. Maybe something YANG encoded via ietf-yang-structure-ext containing: urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 What do you think of this approach? Eric Mahesh Jethanandani mjethanandani@gmail.com _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_001_0AC1_01D5D836.E3C7BF90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 

From: Andy Bierman, January 28, 2020 = 1:13 PM

On Mon, Jan 27, = 2020 at 4:19 PM Mahesh Jethanandani <mjethanandani@gmail.com> = wrote:

Hi = Eric,

 

This e-mail triggers two responses. Let us deal with = draft-ietf-netconf-notification-messages here, and I will bring up = comments/questions related to draft-ietf-netconf-https-notif in the = other thread.

 

You have indicated a desire that receiver capabilities = should be documented by the transport specific draft, e.g. = draft-ietf-netconf-https-notif, and not this draft. As such you believe = that the draft is ready.

 

To the WG, the authors have indicated a desire to wrap = up this draft, and would like us, the chairs, to issue a WGLC on it. = Before we do that, we wanted to ask if the WG believes that the document = is ready, and that there are no more issues that need to = discussed/addressed by draft-ietf-netconf-notification-messages document = at this time.

 

 

 

I = would like to see clear and consistent text wrt to RFC = 5277.

There is this = confusing text:

 

      YANG one-way = exchanges currently use a non-extensible header = and

=C2=A0=C2=A0 encoding defined in section 4 of =
RFC-5277.=C2=A0 These RFCs MUST be
=C2=A0=C2=A0 updated to enable this draft.=C2=A0 =
These RFCs SHOULD be updated to
=C2=A0=C2=A0 provide =
examples
 
 
This seems =
inconsistent with this text:
 

=C2=A0 Backwards = Compatibility

 
 
=C2=A0=C2=A0 With this specification, there is no =
change to YANG's 'notification'
=C2=A0=C2=A0 =
statement
 
=C2=A0=C2=A0 Legacy clients are unaffected, and =
existing users of [RFC5277],
=C2=A0=C2=A0 [RFC7950], and [RFC8040] are free to use current behaviors until =
all
=C2=A0=C2=A0 =
involved device support this =
specification.

 

<eric> I don't see these as = inconsistent.=C2=A0 The YANG notification statement is defined in = RFC-7950 Section 7.16.=C2=A0=C2=A0 And legacy clients do not need to = change.


It is rather = odd to see RFC 2119 language used for a directive to a WG
to take on = some sort of work item. (RFCs MUST be updated)

<eric>=C2=A0 I = agree that RFC 2119 language is not proper here.=C2=A0 Perhaps the = specific changes should be framed as notes to RFC = editor.

 

I think this draft needs some sort of Applicability = Statement. Why are servers supposed

to use this header and stop using the RFC 5277 = header? 

<eric> Makes sense, I will put together = some text on this.

 

The = mandatory info like subscription-id is redundant since the payload = already has this info. 

<eric> The subscription-id is only in the = notifications defined in RFC-8641.=C2=A0=C2=A0 I.e. = "push-update" and " = push-change-update".=C2=A0 = This is the biggest gap which needs to be remedied.=C2=A0 =

 

This new header can make it much more difficult for a = client to write code to process a = notification,

since the = header itself would be modeled with YANG and subject to change.  = The processing

may also be = slower because the added complexity.  It does not seem that every = server needs

this added = complexity.

<eric> This is one reason that this = specification isn't ready to obsolete RFC-5277 = notifications.

 

Eric

 

 

 

Cheers.

 

Mahesh and Kent (as co-chairs).

 

 

 

Andy

 

On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) <evoit@cisco.com> wrote:

 

Hi Mahesh,

 

During the IETF 106 session, there was discussion on = how both a publisher might know if there is receiver support for draft-ietf-netconf-notification-messages.  Section 6 highlights several of the = considerations.   Relevant are the = following:

I = was fine with letting this remote capabilities discovery question sit = for a while.   However draft-ietf-netconf-https-notif sh= ows that we now must address this question.  Specifically should = the diagram section 1.4.1 show this capability = exchange?  

 

It turns out that independent of = draft-ietf-netconf-notification-messages, there several questions in = draft-ietf-netconf-https-notif which need to be answered prior to the = section 1.4.1 arrow: "Send HTTPS POST message with YANG defined = notification #1" anyway.  These questions = are:

  (1) Does the = targeted HTTPS receiver support configured = subscriptions?

  (2) = Can the targeted HTTP@ receiver accept a new subscription as described = in a <subscription-started>?

Only if these questions are "yes", should = the <subscription-started> be responded to with an = "OK".

 

Add to this a third question driven from = (a)-(d):

  (3) Does = the receiver support the message type within = "draft-ietf-netconf-notification-messages"?

 

A strawman way to handle the all three questions = within draft-ietf-netconf-https-notif would be to respond to a = <subscription-started> notification with an HTTP Status 202 = (Accepted)" acknowledgement.  This 202 would include body = elements listing supported receiver resources.  Maybe something = YANG encoded via ietf-yang-structure-ext = containing:

 

      <foo = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

        = <capabilities>

          = <capability>

         &= nbsp;  = urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0

=

          = </capability>

    =     </capabilities>

      = </foo>

 

What do you think of this = approach?

 

Eric

 

Mahesh Jethanandani

 

 

 

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

------=_NextPart_001_0AC1_01D5D836.E3C7BF90-- ------=_NextPart_000_0AC0_01D5D836.E3C7BF90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMTMxMTgwMzUzWjAjBgkqhkiG 9w0BCQQxFgQUgW+9CVtuXy7tHP2QwSFBGSL+FZYwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQApcAGnnUG4nlokXi/RRmF+LMYi4cmWkhRrJxz4u7YeReS7o+YRhtAGxIHTxjPTEpJB usu921YXa4+kk2ftJfqeKyuwM0Utr0Js4haF8fqfNi/s4pVVIHVPv2jzURfyDjJMGp024ODMtbEF 32MGBY9j/ipNIvV3yntoupUtbCuPES4eeEYDnvPpaijXN2UgTBrWReCz6TcOd6EC1gvvGrBqxDul 5MXOa8IsuLencJts+U5MQ92jALlySM1kPC95grmXji5TGTt64/QDAvEHdFw929hDL279spAujRXT 5X4Ojw8f9pCUcURRhMW72K8fe1ZCEL08T+pLGUQE9Va5pBZCAAAAAAAA ------=_NextPart_000_0AC0_01D5D836.E3C7BF90-- From nobody Fri Jan 31 10:50:35 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 D1BD912011B; Fri, 31 Jan 2020 10:50:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ibagdona@gmail.com, kent+ietf@watsen.net, netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158049663385.21154.15056829360962684929.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2020 10:50:33 -0800 Archived-At: Subject: [netconf] netconf - Update to a Meeting Session Request for IETF 107 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 18:50:34 -0000 An update to a meeting session request has just been submitted by Kent Watsen, a Chair of the netconf working group. --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Kent Watsen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: netmod httpbis tcpm idr Technology Overlap: opsarea opsawg Key Participant Conflict: bfd People who must be present: Mahesh Jethanandani Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: Please place the session in the first half of the week (i.e., M-W). --------------------------------------------------------- From nobody Fri Jan 31 11:13: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 46173120105 for ; Fri, 31 Jan 2020 11:13:53 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Jmd9cTiKBzIv for ; Fri, 31 Jan 2020 11:13:49 -0800 (PST) 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 4E39D1200F6 for ; Fri, 31 Jan 2020 11:13:49 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id h23so8213660ljc.8 for ; Fri, 31 Jan 2020 11:13:49 -0800 (PST) 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=5SC/7Gwb9abrx79Ixf3N5nMIjSdR3WXcQjpTaDrfN0g=; b=DPROsSS2RWst+pUy6YKab5zcBa49y1I/r2qAom8bRERRTM+6lMRu8RgBm0qLHN4d6u 2N2n/HAXmszo/IqSC5lhQrI0rY/hz4osGmo5Wn4qAyCBy+JhTL7LyjvREe3u1Xol1aLk Cercusr0BWE85fbNagi0+WtJZcSlz4BNwQb6OLCytULFkoAUnfinYpuEGg2HWe7DLbES MOTqpckwdYz3SpEcg+09WaK3jtW/sQ0crPV4birDczYT78WvsZg5mr7lc/FOhVFFpRNt zrSHTovHQR9KkNcyXH86FbbDR5unOhmcDHplzTqnW/PwQzqKAslyjsUaJAcK586nBt5T HgVg== 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=5SC/7Gwb9abrx79Ixf3N5nMIjSdR3WXcQjpTaDrfN0g=; b=oNWZubottt8kotsYVigAL/faPK1KmspQfFsSzO8V4lEzhkBq3F3aKm3TdPOlQEpjqB 3bUG8pro/o41WIiPghCvKYVXzk41tjnu04rHRG1WjJDf+NQdKnc+mpftFYKEXfalMFgz CCMv/mimU3Cl1EUniaBZclHGiSFQnaMI8aySSlBv6lOxQCNsBzfmJaXEZ42eUn3HsO5T V/YDc1WpN/B3tX60PAbyKxLDqQ3idRekwrrIiSspinlgnnsLTrTSfO0aR/gNOpIsfXTD vHyMKmcTRFfCwk/2IM/2iHo3lcmWqABg+U/U9Y176YxiOrURLOVFMx0bQK/yOxKRmzbB r0rg== X-Gm-Message-State: APjAAAU5MsKktVi72JXQUUOeSBcDnJQToCRN8MpKp3GiodbfAv6ZvVC/ QCm2DliRKggRMjmQccV6nQTfH2yvvAhPBepA8qhj/OtBjrk= X-Google-Smtp-Source: APXvYqwzhi5lSBNtRTb/5NjCYGtFGCF9ntiVxVRIKzuH1v3SKZAQET1OCUrNhiWQDxxVSRcq9lNK3UCceTEky6CgnEU= X-Received: by 2002:a2e:5854:: with SMTP id x20mr6319887ljd.287.1580498027295; Fri, 31 Jan 2020 11:13:47 -0800 (PST) MIME-Version: 1.0 References: <123C86B4-CE8C-4BBD-84CF-630310CEA50E@gmail.com> In-Reply-To: From: Andy Bierman Date: Fri, 31 Jan 2020 11:13:36 -0800 Message-ID: To: "Eric Voit (evoit)" Cc: Mahesh Jethanandani , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007c4cb1059d745f4a" Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 31 Jan 2020 19:13:53 -0000 --0000000000007c4cb1059d745f4a Content-Type: text/plain; charset="UTF-8" Hi Eric, All these changes sound good to me. How about changing the cited text: OLD: These RFCs MUST be updated to enable this draft. These RFCs SHOULD be updated to provide examples NEW: These RFCs need to be updated to enable this draft and provide examples. Andy On Fri, Jan 31, 2020 at 10:04 AM Eric Voit (evoit) wrote: > Hi Andy, > > > > *From:* Andy Bierman, January 28, 2020 1:13 PM > > On Mon, Jan 27, 2020 at 4:19 PM Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > > Hi Eric, > > > > This e-mail triggers two responses. Let us deal with > draft-ietf-netconf-notification-messages here, and I will bring up > comments/questions related to draft-ietf-netconf-https-notif in the other > thread. > > > > You have indicated a desire that receiver capabilities should be > documented by the transport specific draft, e.g. > draft-ietf-netconf-https-notif, and not this draft. As such you believe > that the draft is ready. > > > > To the WG, the authors have indicated a desire to wrap up this draft, and > would like us, the chairs, to issue a WGLC on it. Before we do that, we > wanted to ask if the WG believes that the document is ready, and that there > are no more issues that need to discussed/addressed by > draft-ietf-netconf-notification-messages document at this time. > > > > > > > > I would like to see clear and consistent text wrt to RFC 5277. > > There is this confusing text: > > > > YANG one-way exchanges currently use a non-extensible header and > > encoding defined in section 4 of RFC-5277 . These RFCs MUST be > > updated to enable this draft. These RFCs SHOULD be updated to > > provide examples > > > > > > This seems inconsistent with this text: > > > > Backwards Compatibility > > > > > > With this specification, there is no change to YANG's 'notification' > > statement > > > > Legacy clients are unaffected, and existing users of [RFC5277 ], > > [RFC7950 ], and [RFC8040 ] are free to use current behaviors until all > > involved device support this specification. > > > > I don't see these as inconsistent. The YANG notification statement > is defined in RFC-7950 Section 7.16. And legacy clients do not need to > change. > > > It is rather odd to see RFC 2119 language used for a directive to a WG > to take on some sort of work item. (RFCs MUST be updated) > > I agree that RFC 2119 language is not proper here. Perhaps the > specific changes should be framed as notes to RFC editor. > > > > I think this draft needs some sort of Applicability Statement. Why are > servers supposed > > to use this header and stop using the RFC 5277 header? > > Makes sense, I will put together some text on this. > > > > The mandatory info like subscription-id is redundant since the payload > already has this info. > > The subscription-id is only in the notifications defined in > RFC-8641. I.e. "push-update" and " push-change-update". This is the > biggest gap which needs to be remedied. > > > > This new header can make it much more difficult for a client to write code > to process a notification, > > since the header itself would be modeled with YANG and subject to change. > The processing > > may also be slower because the added complexity. It does not seem that > every server needs > > this added complexity. > > This is one reason that this specification isn't ready to obsolete > RFC-5277 notifications. > > > > Eric > > > > > > > > Cheers. > > > > Mahesh and Kent (as co-chairs). > > > > > > > > Andy > > > > On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) wrote: > > > > Hi Mahesh, > > > > During the IETF 106 session, there was discussion on how both a publisher > might know if there is receiver support for > draft-ietf-netconf-notification-messages > . > Section 6 highlights several of the considerations. Relevant are the > following: > > > > (a) Remote device capability discovery from the point of view of the > Publisher needs to be enhanced to know if the far end can interpret > notification messages type beyond RFC-5277, Section 4. > > > > (b) This capability discovery question is relevant for both configured > subscription receivers and dynamic subscribers. > > > > (c) The capability discovery question can be generalized beyond > subscriptions, as there are many reasons to know the available capabilities > of the far end. > > > > (d) Capability discovery advertisement has traditionally been discussed > within transport documents (e.g. RFC-6241 Section 8.1). > > > > > > Based on (a)-(d), coming up with a transport independent point-solution > within draft-ietf-netconf-notification-messages > *just* > to discover this single element of client functionality seems > overkill/heavyweight. > > > > I was fine with letting this remote capabilities discovery question sit > for a while. However draft-ietf-netconf-https-notif > shows > that we now must address this question. Specifically should the diagram > section 1.4.1 show this capability exchange? > > > > It turns out that independent of draft-ietf-netconf-notification-messages, > there several questions in draft-ietf-netconf-https-notif which need to be > answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with > YANG defined notification #1" anyway. These questions are: > > (1) Does the targeted HTTPS receiver support configured subscriptions? > > (2) Can the targeted HTTP@ receiver accept a new subscription as > described in a ? > > Only if these questions are "yes", should the be > responded to with an "OK". > > > > Add to this a third question driven from (a)-(d): > > (3) Does the receiver support the message type within > "draft-ietf-netconf-notification-messages"? > > > > A strawman way to handle the all three questions within > draft-ietf-netconf-https-notif would be to respond to a > notification with an HTTP Status 202 (Accepted)" > acknowledgement. This 202 would include body elements listing supported > receiver resources. Maybe something YANG encoded via > ietf-yang-structure-ext containing: > > > > > > > > > > urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 > > > > > > > > > > What do you think of this approach? > > > > Eric > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --0000000000007c4cb1059d745f4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

All these cha= nges sound good to me.

How about changing the cite= d text:

OLD:
These RFCs MUST be updated = to enable this draft.=C2=A0=C2=A0
These RFCs SHOULD be updated to= provide examples

NEW:
These RFCs ne= ed to be updated to enable this draft and provide examples.
<= br>

Andy


=
On Fri= , Jan 31, 2020 at 10:04 AM Eric Voit (evoit) <evoit@cisco.com> wrote:

Hi Andy,

= =C2=A0

From: Andy Bierman, January 28, 2020 1:13 PM

<= div>

On Mon, Jan 27, 2020 at 4:19 PM Mahesh= Jethanandani <mjethanandani@gmail.com> wrote:

Hi Eric,

=C2=A0

This e-mail triggers two responses. Let us deal with draft-ietf-netconf= -notification-messages here, and I will bring up comments/questions related= to draft-ietf-netconf-https-notif in the other thread.

=C2=A0

You have indicated a desire that receiver capabilities shoul= d be documented by the transport specific draft, e.g. draft-ietf-netconf-ht= tps-notif, and not this draft. As such you believe that the draft is ready.=

=C2=A0

To the WG, the authors have indicated a = desire to wrap up this draft, and would like us, the chairs, to issue a WGL= C on it. Before we do that, we wanted to ask if the WG believes that the do= cument is ready, and that there are no more issues that need to discussed/a= ddressed by draft-ietf-netconf-notification-messages document at this time.=

=C2=A0

=C2=A0<= /p>

=C2=A0

I would like to see clear and consistent text wrt to RF= C 5277.

There is this co= nfusing text:

=C2= =A0

=C2=A0=C2=A0 =C2=A0 =C2=A0YANG one-way exchanges currently = use a non-extensible header and

=C2=A0=C2=A0 encoding defin=
ed in section=C2=A04 of RFC-5277.=C2=A0 These RFCs MUST be
=C2=A0=C2=A0 updated to ena=
ble this draft.=C2=A0 These RFCs SHOULD be updated to<=
/pre>
=C2=A0=C2=A0 provide examples<=
u>
=C2=A0
=C2=A0
This seems inconsistent with thi=
s text:
=C2=A0
=C2=A0 B=
ackwards Compatibility
=C2=A0
=
=C2=A0
=C2=A0=C2=A0=
 With this specification, there is no change to YANG's 'notificatio=
n'
=C2=A0=C2=
=A0 statement
=C2=A0
=C2=A0=C2=
=A0 Legacy clients are unaffected, and existing users of [RFC5277],
=C2=A0=C2=A0 [RFC7950], and [RFC8040] =
are free to use current behaviors until all
=
=C2=A0=C2=A0 involved device support this speci=
fication.
=C2=
=A0
=
<eric> I don't see these as inconsistent.=C2=A0 The YANG notifica=
tion statement is defined in RFC-7950 Section 7.16.=C2=A0=C2=A0 And legacy =
clients do not need to change.

It is rather odd to see RFC 2119 language used for a directive=
 to a WG
to take on some sort of work item. (RFCs MUST be updated)
&l=
t;eric>=C2=A0 I agree that RFC 2119 language is not proper here.=C2=A0 P=
erhaps the specific changes should be framed as notes to RFC editor.=

=C2=A0
I think this draft needs some sort of Appli=
cability Statement. Why are servers supposed
to use this header and stop using the RFC 5277 header?= =C2=A0

<eric> Makes sense, I will put together some text on this.=

=C2=A0

The mandatory info like subscription-id is redund= ant since the payload already has this info.=C2=A0

<eric> The subs= cription-id is only in the notifications defined in RFC-8641.=C2=A0=C2=A0 I= .e. "push-update" and " push-change-update&qu= ot;.=C2=A0 This is the biggest gap which needs to be remedied.=C2=A0

=C2=A0

This new header can make it much more d= ifficult for a client to write code to process a notification,

since the header itself would be mod= eled with YANG and subject to change.=C2=A0 The processing

may also be slower because the added com= plexity.=C2=A0 It does not seem that every server needs

this added complexity.

<eric> This= is one reason that this specification isn't ready to obsolete RFC-5277= notifications.

=C2=A0

Eric

=C2=A0

=C2=A0

=C2=A0

Cheers.

=C2=A0=

Mahesh and Kent (as co-chairs)= .

=C2=A0

=C2=A0=

=C2=A0

Andy

=C2=A0

On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) <evoit@cisco.com> wrote:

=C2=A0

<= p class=3D"MsoNormal">Hi Mahesh,

=C2=A0

During t= he IETF 106 session, there was discussion on how both a publisher might kno= w if there is receiver support for=C2=A0draft-ietf-netconf-notifi= cation-messages.=C2=A0 Section 6 highlights several of the consi= derations.=C2=A0=C2=A0=C2=A0Relevant are the following:

=C2=A0

(a) Remote device capability discovery from the point of vie= w of the Publisher needs to be enhanced to know if the far end can interpre= t notification messages type beyond RFC-5277, Section 4.

<= /div>

=C2=A0

(b) This capability discovery question is relevant for both= configured subscription receivers and dynamic subscribers.=C2=A0=C2=A0<= /u>

=C2=A0

(c) The capability discovery question can be= generalized beyond subscriptions, as there are many reasons to know the av= ailable capabilities of the far end.=C2=A0=C2=A0=C2=A0

=C2=A0

(d) Capability discovery advertisement has traditionally bee= n discussed within transport documents (e.g. RFC-6241 Section 8.1).=C2=A0 = =C2=A0

=C2=A0<= /u>

=C2=A0

Based on (a)-(d), coming up with a transport indepe= ndent point-solution within=C2=A0draft-ietf-netconf-notification-= messages=C2=A0*just* to discover this single element of client f= unctionality seems overkill/heavyweight.

=C2=A0

= I was fine with letting this remote capabilities discovery question sit for= a while.=C2=A0=C2=A0 However=C2=A0draft-ietf-netconf-https-notif=C2=A0shows that we= now must address this question.=C2=A0 Specifically should the diagram sect= ion 1.4.1 show this capability exchange?=C2=A0=C2=A0

=C2=A0

It turns out that independent of draft-ietf-netconf-notificatio= n-messages, there several questions in draft-ietf-netconf-https-notif which= need to be answered prior to the section 1.4.1 arrow: "Send HTTPS POS= T message with YANG defined notification #1" anyway.=C2=A0 These quest= ions are:

=C2=A0 (1) Doe= s the targeted HTTPS receiver support configured subscriptions?

=C2=A0 (2) Can the targeted HTTP@ r= eceiver accept a new subscription as described in a <subscription-starte= d>?

Only if these que= stions are "yes", should the <subscription-started> be resp= onded to with an "OK".

=C2=A0

Add to t= his a third question driven from (a)-(d):

=C2=A0 (3) Does the receiver support the message type wit= hin "draft-ietf-netconf-notification-messages"?

=

=C2=A0

A strawman way to handle the all three questions within dr= aft-ietf-netconf-https-notif would be to respond to a <subscription-star= ted> notification with an HTTP Status 202 (Accepted)" acknowledgeme= nt.=C2=A0 This 202 would include body elements listing supported receiver r= esources.=C2=A0 Maybe something YANG encoded via ietf-yang-structure-ext co= ntaining:

=C2=A0<= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = <foo xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"><= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <capabilities>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <c= apability>

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 urn:ietf:params:x= ml:ns:yang:ietf-notification-messages:1.0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &l= t;/capability>

=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0</capabilities>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </foo&= gt;

=C2=A0=

What do you think of this approach?

=C2=A0

<= /div>

Eric

=C2=A0

<= p class=3D"MsoNormal">Mahesh Jethanandani

=C2=A0

=C2=A0<= u>

=C2=A0

=

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

= --0000000000007c4cb1059d745f4a-- From nobody Fri Jan 31 14:06:15 2020 Return-Path: <0100016ffda3d528-f411ef14-2813-4372-99c4-8269e5ea435e-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 DF5F3120041 for ; Fri, 31 Jan 2020 14:06:13 -0800 (PST) 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_DNSWL_NONE=-0.0001, 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 PK3gKbee8Hxg for ; Fri, 31 Jan 2020 14:06:12 -0800 (PST) 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 C7F4712002E for ; Fri, 31 Jan 2020 14:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1580508370; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=/FmObx7+mmja4txG+zhu1QBTZ5Pmt4PGaSTiRvBletI=; b=Nb9vqNWFH1wSZa2VEQZwV4MRVfr1TGqyzqOqKfY+HlLV8HkD4l7uCWE+SlculACJ AGTheaqbLqPz78AO+9AobQCgk67/a8dwE9UxNGFki56az8tmyzlE63nFv2/Br92axBO wO4V1aD8lnjP65L5oNkBm/s5nwQnhxsTyCL1hc7g= From: Kent Watsen Message-ID: <0100016ffda3d528-f411ef14-2813-4372-99c4-8269e5ea435e-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FCFFC781-1AF9-4153-AE1A-BDF60BF928CF" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 31 Jan 2020 22:06:10 +0000 In-Reply-To: <20200131.111027.840757629039452002.mbj@tail-f.com> Cc: Russ Housley , "netconf@ietf.org" To: Martin Bjorklund References: <0100016ff91dfd1b-9e8e6622-7e36-45dc-a661-f4702b494040-000000@email.amazonses.com> <20200131.111027.840757629039452002.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.01.31-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Truststore: bags, sets, or other? X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 31 Jan 2020 22:06:14 -0000 --Apple-Mail=_FCFFC781-1AF9-4153-AE1A-BDF60BF928CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Martin, >> NEW: >> +--rw -bags {}? >> +--rw -bag* [name] >> +--rw name string >> +--rw * [name] >> +--rw name string >> =E2=80=A6 >>=20 >> Better, right? Any other ideas? >=20 > We have current published modules with both "-list" and "-set". No > "-bag" so far. >=20 > For example: >=20 > "list rule-list" in ietf-netconf-acm >=20 > "list module-set" in ietf-yang-library True. > There are some examples of "s" as well, but these are plural "s" for a > normal list of singletons, and should have been named w/o the plural > "s" (if we were to be consistent). >=20 > I would try to avoid "s" for a "list-of-lists", but then pick the > suffix that feels most natural in the domain. (For example, rather > "list access-control-list" than "list access-control-set=E2=80=9D). Agreed. > Perhaps you can argue that "-list" works better for ordered sequences, > and "-set" and "-bag" for unordered. But then there are "ordeded > sets" and "unordered lists" (and even apparently "ordered bag", in > UML). Perhaps. > The plural "s" is better for a surrounding container (if one exists). Agreed. I also received a private response from Russ, who rather not join the = netconf list, but said: 1) =E2=80=9Cbag=E2=80=9D was originally created to deal with issues with = ASN.1 the SET and SEQUENCE types, and since have entered general crypto = parlance outside the PKCS#12 context. 2) =E2=80=9Cbag=E2=80=9D is the ideal term for when conveying a = unordered collection of X.509 certificates. 3) =E2=80=9Cbag=E2=80=9D is not known to be used in the context of SSH = host keys or RPKs, but there isn=E2=80=99t anything wrong or bad with = doing so either. All said, I believe the best course is to use =E2=80=9Cbag=E2=80=9D and, = more specifically, to use the "/x-bags/x-bag/=E2=80=A6=E2=80=9D = structure that is present at the top of this message. Assuming there = are no objections, this change will be in the next update. Kent --Apple-Mail=_FCFFC781-1AF9-4153-AE1A-BDF60BF928CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Martin,

NEW:
          &nb= sp;+--rw <thing>-bags {<thing-feature>}?
          &nb= sp;   +--rw <thing>-bag* [name]
          &nb= sp;      +--rw name string
          &nb= sp;         +--rw = <thing>* [name]
          &nb= sp;            = ;+--rw name string
          &nb= sp;            = ; =E2=80=A6

Better, right? =   Any other ideas?

We have current published = modules with both "-list" and "-set".  No
"-bag" so far.

For example:

 "list rule-list" in = ietf-netconf-acm

 "list module-set" in ietf-yang-library

True.


There are some examples of "s" = as well, but these are plural "s" for a
normal list of singletons, and should have been named w/o the = plural
"s" (if we = were to be consistent).

I would try to avoid "s" for a "list-of-lists", but then pick = the
suffix that = feels most natural in the domain.  (For example, rather
"list access-control-list" than = "list access-control-set=E2=80=9D).

Agreed.

Perhaps you can argue that "-list" works better for ordered = sequences,
and "-set" = and "-bag" for unordered.  But then there are "ordeded
sets" and "unordered lists" (and = even apparently "ordered bag", in
UML).

Perhaps.

The plural "s" is better for a surrounding container (if one = exists).

Agreed.


I also received a private response from Russ, who = rather not join the netconf list, but said:

1) =E2=80=9Cbag=E2=80=9D was originally created to = deal with issues with ASN.1 the SET and SEQUENCE types, and since have = entered general crypto parlance outside the PKCS#12 = context.

2) =E2=80=9Cbag=E2=80=9D is = the ideal term for when conveying a unordered collection of X.509 = certificates.

3) =E2=80=9Cbag=E2=80=9D= is not known to be used in the context of SSH host keys or RPKs, but = there isn=E2=80=99t anything wrong or bad with doing so = either.

All said, I believe the best = course is to use =E2=80=9Cbag=E2=80=9D and, more specifically, to use = the "/x-bags/x-bag/=E2=80=A6=E2=80=9D structure that is present at the = top of this message.   Assuming there are no objections, this = change will be in the next update.

Kent

= --Apple-Mail=_FCFFC781-1AF9-4153-AE1A-BDF60BF928CF--