From nobody Wed Dec 1 08:15:38 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF473A0915 for ; Wed, 1 Dec 2021 08:15:37 -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_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 V2r_wH61GDc8 for ; Wed, 1 Dec 2021 08:15:33 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502623A0914 for ; Wed, 1 Dec 2021 08:15:33 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 499) id D159AF360C; Wed, 1 Dec 2021 08:15:31 -0800 (PST) To: schishol@nortel.com, htrevino@cisco.com, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, mjethanandani@gmail.com From: RFC Errata System Cc: zemiyou@gmail.com, netconf@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20211201161531.D159AF360C@rfc-editor.org> Date: Wed, 1 Dec 2021 08:15:31 -0800 (PST) Archived-At: Subject: [netconf] [Technical Errata Reported] RFC5277 (6770) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 16:15:38 -0000 The following errata report has been submitted for RFC5277, "NETCONF Event Notifications". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6770 -------------------------------------- Type: Technical Reported by: Tetsuya Hasegawa Section: 4 Original Text ------------- 4. XML Schema for Event Notification Corrected Text -------------- Add a new section "YANG Module for Event Notifications". Notes ----- The XML schema for notifications is defined, but the yang module is not. To achieve interoperability, please add a YANG module for notifications. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5277 (draft-ietf-netconf-notification-14) -------------------------------------- Title : NETCONF Event Notifications Publication Date : July 2008 Author(s) : S. Chisholm, H. Trevino Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Wed Dec 1 08:36:12 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16DE3A09BC for ; Wed, 1 Dec 2021 08:36:08 -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, 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.20210112.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 e9KL_CN2r4vO for ; Wed, 1 Dec 2021 08:36:02 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 D7B2D3A0B25 for ; Wed, 1 Dec 2021 08:35:16 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id t26so64382503lfk.9 for ; Wed, 01 Dec 2021 08:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YPkDwxf322kKy8FQD8Yln/gr5MelWrHzbdHAlVTpIvk=; b=EZE/N0AIGpL9AoeYwUYrq82Qyfz6WCE+K0o/jWJTfojaeYBE00WafG7pJ6gwtGxFI6 ngLo3hCMrNInRGPzX/QfEJRgvG5Te4KZ98EX+gXogUyp8r4uQ9X7xStfg4Xzb1pRq4Hm fnfcy9ujGzFAxfldkPgezZF/RvbmB1QDjO+yBJeh3WHBmsaEDdvWk9nW9/aUaMQwCcg9 68Qqh0VxnjmWZGMkyGc7WJcBIXc+TkfRTLfrxC9lEHWxvox/5hcCiJQBzutD47BNyNWD j0BJQQlgs3TXmStljKUmUJFXG0ZNx0OSdk9gkDDeRkTfYcSRjjD7F2ncRbVvVhQmAQFw sy1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YPkDwxf322kKy8FQD8Yln/gr5MelWrHzbdHAlVTpIvk=; b=YLNtwc/Vfvg17y5/Bnhy6sQ64FWj3+Hri/GvEKNF5Zb+D/n9Nr21yV4eakm8NCH/mS hmEPZoNIXnwNNfBt5YWAOl5WfeTm7990VEGADIT4uAFVlB9DXe4gCvBbTbjUxJ0Wq9E9 6cSmyIWeqCIF1aIeqf3tIbyrr+S0QLcUIx//7hGw/fQDBssE5nRjRv6mh1Jt6OerjvyO pvAn9hfs811NHkle0QcAMpUHJlDYUlW7Dgn10E1Y5nh4X3i8s2SSWRACRWNA2onuJe9X K3mluEnRzDltAxj6oNPfztu9GW+kd3BGgu0/9UDWfC/bTFjb+Pc6sRdo38QhV4oz+ybr Nz2A== X-Gm-Message-State: AOAM532ug5G06va1vK5DxiexlUGdm9DY0H+vqyBqFZ0YpHC0mZBANy5z URtUg5poP/dF5bU9d2cAUDueb4vwtVFT5YI8XvmU6w== X-Google-Smtp-Source: ABdhPJyn8LKz+iwKpivXpM9LB4fpbSdnXSfUPBVXneXO6z2E/bzleu5xz+qK7hA8Oxh72ZwN18p6f9hPl96QNQ1gsc0= X-Received: by 2002:ac2:5317:: with SMTP id c23mr6810801lfh.525.1638376512575; Wed, 01 Dec 2021 08:35:12 -0800 (PST) MIME-Version: 1.0 References: <20211201161531.D159AF360C@rfc-editor.org> In-Reply-To: <20211201161531.D159AF360C@rfc-editor.org> From: Andy Bierman Date: Wed, 1 Dec 2021 08:35:01 -0800 Message-ID: To: RFC Errata System Cc: schishol@nortel.com, "Hector Trevino (htrevino)" , Warren Kumari , Robert Wilton , Kent Watsen , Mahesh Jethanandani , zemiyou@gmail.com, Netconf Content-Type: multipart/alternative; boundary="0000000000000a7b5405d218428f" Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC5277 (6770) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 16:36:09 -0000 --0000000000000a7b5405d218428f Content-Type: text/plain; charset="UTF-8" Hi, This errata should be rejected. There is no YANG module for the NETCONF defined anywhere. There is no standard YANG module for the operation. 1) RFC 5277 predates RFC 6020, so YANG is not normative in RFC 5277. Use the update in RFC 8639. 2) It is not possible to model the element in YANG. 3) A new RFC is required to add new functionality. This is not a bugfix suitable for an Errata. Andy On Wed, Dec 1, 2021 at 8:15 AM RFC Errata System wrote: > The following errata report has been submitted for RFC5277, > "NETCONF Event Notifications". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6770 > > -------------------------------------- > Type: Technical > Reported by: Tetsuya Hasegawa > > Section: 4 > > Original Text > ------------- > 4. XML Schema for Event Notification > > Corrected Text > -------------- > Add a new section "YANG Module for Event Notifications". > > > Notes > ----- > The XML schema for notifications is defined, but the yang module is not. > To achieve interoperability, please add a YANG module for notifications. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5277 (draft-ietf-netconf-notification-14) > -------------------------------------- > Title : NETCONF Event Notifications > Publication Date : July 2008 > Author(s) : S. Chisholm, H. Trevino > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --0000000000000a7b5405d218428f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This errata should be rejected.
There is no YANG module for the NETCONF <notification> defined= anywhere.
There is no standard YANG module for the <create-su= bscription> operation.

1) RFC 5277 predates RFC= 6020, so YANG is not normative in RFC 5277.
Use the update in RF= C 8639.

2) It is not possible to model the <= ;notification> element in YANG.

3) A new RFC is= required to add new functionality. This is not a bugfix
suitable= for an Errata.


Andy

=

On Wed, Dec 1, 2021 at 8:15 AM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata = report has been submitted for RFC5277,
"NETCONF Event Notifications".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6770

--------------------------------------
Type: Technical
Reported by: Tetsuya Hasegawa <zemiyou@gmail.com>

Section: 4

Original Text
-------------
4.=C2=A0 XML Schema for Event Notification

Corrected Text
--------------
Add a new section "YANG Module for Event Notifications".


Notes
-----
The XML schema for notifications is defined, but the yang module is not. To= achieve interoperability, please add a YANG module for notifications.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5277 (draft-ietf-netconf-notification-14)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: NETCONF Event= Notifications
Publication Date=C2=A0 =C2=A0 : July 2008
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: S. Chisholm, H. Trevino=
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Configurat= ion
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operations an= d Management
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--0000000000000a7b5405d218428f-- From nobody Wed Dec 1 09:26:07 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA23D3A079B; Wed, 1 Dec 2021 09:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2ItRMn7TL0y; Wed, 1 Dec 2021 09:25:58 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18573A0791; Wed, 1 Dec 2021 09:25:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 499) id 896F1F3605; Wed, 1 Dec 2021 09:25:58 -0800 (PST) To: zemiyou@gmail.com, schishol@nortel.com, htrevino@cisco.com From: RFC Errata System Cc: rwilton@cisco.com, iesg@ietf.org, netconf@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20211201172558.896F1F3605@rfc-editor.org> Date: Wed, 1 Dec 2021 09:25:58 -0800 (PST) Archived-At: Subject: [netconf] [Errata Rejected] RFC5277 (6770) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 17:26:02 -0000 The following errata report has been rejected for RFC5277, "NETCONF Event Notifications". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6770 -------------------------------------- Status: Rejected Type: Technical Reported by: Tetsuya Hasegawa Date Reported: 2021-12-01 Rejected by: Rob Wilton (IESG) Section: 4 Original Text ------------- 4. XML Schema for Event Notification Corrected Text -------------- Add a new section "YANG Module for Event Notifications". Notes ----- There is no YANG module for the NETCONF defined anywhere. There is no standard YANG module for the operation. 1) RFC 5277 predates RFC 6020, so YANG is not normative in RFC 5277. Please use the update in RFC 8639. 2) It is not possible to model the element in YANG. 3) A new RFC is required to add new functionality. This is not a bugfix suitable for an Errata. --VERIFIER NOTES-- -------------------------------------- RFC5277 (draft-ietf-netconf-notification-14) -------------------------------------- Title : NETCONF Event Notifications Publication Date : July 2008 Author(s) : S. Chisholm, H. Trevino Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Wed Dec 1 09:27:08 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB9A3A0799 for ; Wed, 1 Dec 2021 09:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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=AxG6KcGW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ykmO5566 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yNSC5vmKYAZ for ; Wed, 1 Dec 2021 09:27:00 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AC73A07A0 for ; Wed, 1 Dec 2021 09:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16082; q=dns/txt; s=iport; t=1638379620; x=1639589220; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=C7ODVKEsznvUQR0JkZZbkVFTVGnOZmisWHdBLdh4D8I=; b=AxG6KcGWI4VZS6POIrUQFcdT2Ih2sNZdqG7FH5fTcgHtho4Zc0g2snFR oNeI7VFeG9W4MdUQH9lWXrj4BtE6BPOaAPDqJHsD5e5D4wUJ2QqmKm8EZ iPw+5iC36OiItc/fgt/gGCVRJz0Qs5rUmV/t2WAgceVeUTpkgbWz9IsN4 k=; X-IPAS-Result: =?us-ascii?q?A0ALAABmr6dhl4YNJK1aHAEBAQEBAQcBARIBAQQEAQGCB?= =?us-ascii?q?QcBAQsBgSAxKSh/WjcxhEeDRwOEWWCFDoMCA4sFin+FCoEugSUDVAsBAQENA?= =?us-ascii?q?QEqAQoMBAEBhD9FAheCbQIlNAkOAQIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGB?= =?us-ascii?q?BQBAQEBAQEBAQkUBwYMBQ4QJ4U7ByYNhkIBAQEBAwEBEBEKEwEBLAsBDwIBB?= =?us-ascii?q?gIRBAEBDhoDAgICHwYLFAkIAgQBDQUIGoIESwGCDlcDLwEOlFmPNgGBOgKKH?= =?us-ascii?q?3qBMYEBgggBAQYEBIULDQuCNQMGgToBgw2EHAEBgR6BYIQIJxyBSUSBFUOCZ?= =?us-ascii?q?z6BBYEcQgEBgWIrCYJiN4IukS8QWFNbJxYHYwIPS5F9KYJWR4kdg3WJZpFQa?= =?us-ascii?q?AqDPJkdhggVg26LdwOXTpYcH4IjjX+QWxuEWAIEAgQFAg4BAQaBYWaBLnAVG?= =?us-ascii?q?iGCaVEZD4s9gmMZgQ0BCIJDhRSFSnQ4AgYBCgEBAwmSbAEB?= IronPort-PHdr: A9a23:6Qe7bxxX1lBiQyXXCzPZngc9DxPP8534PQ8Qv5wgjb8GMqGu5I/rM 0GX4/JxxETIUoPW57Mh6aLWvqnsVHZG7cOHt3YPI5BJXgUO3MMRmQFoCcWZCEr9efjtaSFyH MlLWFJ/uX+hNk0AE8flbFqUqXq3vlYv IronPort-Data: A9a23:ocbZhK6z7FiG36F4mAODDwxRtKbHchMFZxGqfqrLsTDasY5as4F+v mQaC2iOPq6CazTwe9l/aI/i/EJS6MeHzNZnSgZkrHowZn8b8sCt6fZ1gavT04J+CuWZESqLO u1HMoGowPjZzRYwnz/1WlTbhSEUOZqgG/ysV4YoBggrHVU9EX150Eo58wIEqtcAbeaRUlvlV eza+6UzCHf9s9KjGjtJg04rgEoHUMXa4Fv0jHRnDRx4lAO2e00uMX4qDfrZw00U7WVjNrXSq +7rlNlV945ClvsnIovNfr3TKiXmTlNOVOSDoiI+ZkSsvvRNjgwv0qkGMqQTVUVstT+RsIsox JIWiZPlHG/FPoWU8AgcexBcFyc7Nqpc9fqeez60sNeYyAvNdH6EL/dGVR5te9ZGvL8sRzgVq ZT0KxhVBvyHr/ipwbanTe9EjcU4J86tN4Qa0p1l5W6JUa19EMmdGM0m4/d493A9r+JPMc/FO dUdZjhUKxfbTEB2bwJ/5JUWxbf02SaXnydjgFSYuaEw5Wb7zQFt3v7qKtW9UtmISNlVl0CRo G7P+WXRDRQTNdjZwj2Amlqvi+nT3iL2RIw6C7Sk7fNsxlue2gQ7FxQMT1a9ifqkj0ekWpRZJ lB80jElrakp9EuvZt/6RQG1pDiPuRt0c8BeGKg35ACRzbD8+QiSQ2UITyJGcpohrsBebTUs2 k6hjs7sDCNoqr6OD3ma89+8vz63ODkSMEcNYCYFSU0O5NyLnW0ophvLStAmG6mvg5isQ3f7w iuBq241gLB7YdM3O7uT3U3HjA+q+Jf1TDUL7B34BTupqVhFa9vwD2C30mTz4fFFJYefa1COu nkYhsSThNzi67nQyERhp81QQNmUC+a53C702gU2RsZ/n9i50zvyI94PsWgWyFJBa55cEQIFd nM/ru+4CHV7FX+uYKkfj2mZVJlylPOI+TgIqpnpgjdma5x1ckqM+ztjIBfKmWvsi0Mr16o4P P93kPpA715HVcyLLxLvGo/xNIPHIAhlnQs/origlnyaPUK2PiL9dFv8GALmghoFxK2Fuh7J1 N1UKtGHzR5SOMWnPHKHq99MdQhQdSFjbXwTlyCxXrPTSuaBMDx+Y8I9PZt8E2CYt/0Pz7yRr i3VtrFwkQeg3RUr1jlmmlg6OO+wAv6TXFowPDcnOh6zymM/bIO0hJrzhLNpFYTLANdLlKYuJ 9FcIp3oKq0WFlzvpmRMBbGg/dcKXEn62mqmYXH/CBBhJMEIeuA80oK9FucZ3HJVVXTfWApXi +DI6z43trJfHVk/V5iPN6r0p75z1FBE8N9Ps4LzCoE7UC3RHEJCcUQdUtdfzxkwFCj+ IronPort-HdrOrdr: A9a23:Uj+TcqOrWjNsocBcT23155DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9wr4WBkb6Le90dq7MA3hHP9OkMcs1NKZPDUO11HYV72KgbGSpgEIXheOitK1tp 0QMpSWaueAd2SS5PySiGLTfrpQo6jkzEnrv5ai854Hd3ANV0gU1XYANu/tKDwOeOApP+tcKL Osou584xawc3Ueacq2QlMfWfLYmtHNnJX6JTYbGh8O8mC1/HOVwY+/NyLd8gYVUjtJz7tn23 PCiRbF6qKqtOz+4gPA1lXU849dlLLau5h+7Y23+4oowwfX+0KVjbdaKvq/VfcO0aeSAWMR4Z zxStEbTp1OAj3qDzmISFDWqnjdOX4Vmg/fIBmj8CDeSQiTfkNmNyKH7rgpKCcxonBQz+1Uwe ZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjwkC3fLFuI4O5l7Zvtn+90a1wax7S+cQiCq 1jHcvc7PFZfReTaG3YpHBmxJipUm4oFhmLT0AesojNugIm00xR3g8d3ogSj30A/JUyR91N4P nFKL1hkPVLQtUNZaxwCe8dSY+8C3DLQxjLLGWOSG6XWJ0vKjbIsdr68b817OaldNgBy4Yzgo 3IVBdCuWs7ayvVeIWzNV1wg1nwqUmGLEHQI/Bllu5EU+fHNcjW2AW4OSQTr/c= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.87,279,1631577600"; d="scan'208,217";a="784339163" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Dec 2021 17:26:59 +0000 Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 1B1HQxYO010417 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 1 Dec 2021 17:26:59 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 1 Dec 2021 11:26:58 -0600 Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 1 Dec 2021 11:26:58 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Wed, 1 Dec 2021 12:26:58 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y2NzWJrdmM3kGDlQ6WQt691pAjxV5Wi4YvDKVGYvraFeXou2kyHu9TCXDBIFzw8g2O5cUjaYTiuKqlucC7k87zLtTmQUHEbF8oxS83k2GG4q4/qXyGN2UmZRCqYys9iv9wUzaITFVpINVzs8o/gENNZbskSzruzScz2EP7jZhorm36M4NwgLYBwvFnRO+ABgSWK3o+GKhb+Dm49zFVGHn95lvNSU2lZtv94S76UHe7GYq7Ri5j63tcw+qov2dkx6Bt8HKQSNpnqQLI40rYsJavBSWcUfYZrxBTT4/ur1jFDku27zKjNqUE9E2jPpQi5/qp8V/8+Xasq3OnYtS0/jqw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=C7ODVKEsznvUQR0JkZZbkVFTVGnOZmisWHdBLdh4D8I=; b=Z73VWC/cp91RCoXfOsiIAlWQntOFfvJpRfmuQ48unuCL+MfEBrA4UCTKpsouAqvSNVIaurwxlVlvBL3YQDnY8Ltu6+WvYX6FAgh6GxxKBbJ/zrRdYeIAQGtk9TQjIMFEiouclnTaY9GCEfrzu8aa3YRrsSXd7RtMKLrCOqOEQbbv/QyrrWV3BwE0Zp/Kt0zHhPWOwZg9eqD8WRdy4+jB5zpMj/3btzBwC33HQBJge4Avjdp5pWRWI/A/0tHvXnGmRB5eWNZiW5Qvd9u0z2FUBeplw16/xcwYaaQlc/mwD4FY/cRi3tdHsK3IHUQzMYtUhecuYJVOsXYzKAgMNq4fBQ== 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=C7ODVKEsznvUQR0JkZZbkVFTVGnOZmisWHdBLdh4D8I=; b=ykmO5566NyB9wEf8obAvqAhdVY3fazW6pi9LIAscFGi1iWkuEO0/6GGyi+TU4Rza/tbsKRA0/+Tgm6vaN3beJBug/N9yF9VrrjFDZJSEtLOxV1CrNih40RE8w/zGTchq+bVp9sIMpdQGKqHlJx5ihQpo+dcigJfNNdL+GK9Izzc= Received: from BY5PR11MB4196.namprd11.prod.outlook.com (2603:10b6:a03:1ce::13) by BYAPR11MB3656.namprd11.prod.outlook.com (2603:10b6:a03:f8::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.22; Wed, 1 Dec 2021 17:26:56 +0000 Received: from BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::3dad:eeb0:be1c:b167]) by BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::3dad:eeb0:be1c:b167%5]) with mapi id 15.20.4734.024; Wed, 1 Dec 2021 17:26:56 +0000 From: "Rob Wilton (rwilton)" To: hasegawa , Andy Bierman CC: RFC Errata System , "schishol@nortel.com" , "Hector Trevino (htrevino)" , Warren Kumari , Kent Watsen , Mahesh Jethanandani , Netconf Thread-Topic: [netconf] [Technical Errata Reported] RFC5277 (6770) Thread-Index: AQHX5s61mBsIj7AyYkukGP5UmnL0/qwd1SiAgAAKUgCAAAPx0A== Date: Wed, 1 Dec 2021 17:26:56 +0000 Message-ID: References: <20211201161531.D159AF360C@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 045e6cf5-8904-492b-6040-08d9b4efc676 x-ms-traffictypediagnostic: BYAPR11MB3656: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4PkYZ8aNJykOgoWYm1WCp0mLpPHJZEXYq992sI9lyEg0TAH8pRjUCHSI9ZzBj5+JT3j3xb7BxFFztQjHxGo2ESD/u2oJ+wBpMl7ayihFob+R2Ub5DPdmcSXiGEsjg8tQ/2HssKIH1QyJjcR0uLFNTB67X99BdpMOP3nZcH0joyDw3E2lz3CnE9f+f7yOP8eBflkWmNMF3DqPpsawCzD8CeGeuW7G/7lwxFFCXz/hsj5yz0THZr7Z+28FgGXjnn9SfEfXTe8+Ns8I7yVHsUVrD8tmPPyEmmq8ZrvDhM/HFf3fyO8w0BdxucGCP2igwHs8RPkpRLvNK1knJ0h+4G9YsRBUK4+lteOl+uIHL0h1B9bTjJVR1HZcqs/1kKMqUAVEUrS3Y5jKUfAFjTHT+4GxxjBmwLShHWr3mWv6u1ap1AyjH3KNC4Us2KQO3xe46lJTP4D+imAW0hKnbiYwOUmd3LmFJXX2yCatmJlao8vtSnPrmBtgwRNcEFWwAJNIRoJyFtAAUI/sMXlfsAP3cxKXPIK6P5l1sJ5FTD29uuTdCgTJT0b5ALUYeFyicGAfTGyJPLv0SPOENpcjiLW34jey+cIaCaHV16cduofJNXLxGJ293bxtZMWFK7xXOt9EEZkXiGEEHTR0892NO3rGEnuriuP3B5r090mhvNrJO3EvUfxog/zN9bkjWLtfPy7Hr3twVzVzdOo+Bf8vcl92ykI9xSO+kIRXTrnJnIvafzg01fagTUBC0mV3PO2svy1jra69AW26hmp9mlBNMKmAFqQhFj8NXzb1Jq5EDULcxY7uczwXjLTEdM+KaoLpPQma9G+xCTDJ8SwBZBrxHsuTuBJE/g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4196.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(2906002)(166002)(186003)(966005)(52536014)(66556008)(83380400001)(6506007)(110136005)(38070700005)(55016003)(26005)(7696005)(54906003)(53546011)(508600001)(76116006)(64756008)(66446008)(66946007)(8936002)(66476007)(86362001)(9686003)(33656002)(122000001)(316002)(5660300002)(4326008)(9326002)(38100700002)(71200400001)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?OXh3c2dEbktSbXdhOVlFVHhCSHlnQXMwdWpNTXZ4UTNnMHAvVzM4Ri9yMHlM?= =?utf-8?B?YkM1MWlrd01yY1BvUGExL2V0MEx3Qm9xTjVHTUJyVG1VMjRKVVVqV0dkRVhv?= =?utf-8?B?SjVjSk4rNHd2WHFmcWxURGxKT0RYTlN4OXJmZnhKOVV2czZLc0Q1SVV2ZXdR?= =?utf-8?B?SHVYM21VQmRTdkMwSUtWUXU2V1BaOVVnTTFXNXBJbGNzWmpoTFFWekJqS0Zr?= =?utf-8?B?bkh3dGl0dCtKbGluM2V6Z3J0MFJ5V1FXOG9CY0JpMFJOTFlXWVhDWkFrVFEz?= =?utf-8?B?UHdYckgzVkU5TW5od1VmcXZtN1hZbUJ3RmRPcyt5bC9vQzFlNlpCWDlVTGJa?= =?utf-8?B?MkY2WHpwcEl2Tm83V1V2MytoQkFKRDJia2tlbGZ1NGZQRzBQb3lmdjlzVnds?= =?utf-8?B?N0pXQmdFa0o5cnEyL3VyT2d3SitmT0p1QW5DUm01ZGVPZE9vVlhwN3R2bFpv?= =?utf-8?B?eGkxMWQxNTRhNVFNc2xyeEw1am9TQk9WbU1CWFUxYVBIYlNETHpQZC94YXp3?= =?utf-8?B?QmQ4WU56cE01V282QnQzenJXL0puQ002ekZEaS9XMkVCdytYQzRZM3NpcjVz?= =?utf-8?B?ZWdkb0tsNHVhUmFlajBmSTBkd3BoR01IaG44V0pPckNSL2RKNWJTTmdmaUxl?= =?utf-8?B?U0xYSDF0c2pFQTJPc0JuOXpUZENSQlRmNGFLeHJpVjlJUVZyMXp2cjB1Vkta?= =?utf-8?B?YTJheGxjajFWaFBiK3U3V3dxQlJtbUxSV1AyMjZBcXhOdkJwS0VUZDk4c3lH?= =?utf-8?B?MFdpcFBPM2FmMFJYWHhGYTJDODZVWU9KQkpnd2Y3UnBPcTkxZ3puS1lCQmtO?= =?utf-8?B?cUtGUk9UU1ZhREpESUFlNnVPczltUnYwVy9PTzFPbm5XdmYydFpLYnNLaVY5?= =?utf-8?B?eUNZcllpdWVab0szZjJXYVUyL1JwU3B4dmtEM1YrbG13b1N0SklFcWRMMnQ2?= =?utf-8?B?WFNZeGhWcldZdXJuSHRjLzhDbFZBdjY1ZzNiMXN1WUFsTzluT2QyS1JmZ20z?= =?utf-8?B?UWxYdUgraTcrRkpoSEhSa3FiOGJCT2pyTkVZMUtBRDg5aWxEM3A3dkwrb3F5?= =?utf-8?B?dGFmaUR6aXF2MUg3NHNsZzNBWWY4K0QvdG45aHRmbm0wRVV4WlVtT3FzWHJh?= =?utf-8?B?NEdJVmYxamRUZWM2V2RUaFBMWUZoUEY3TmRJeFFReERFck42U3FKRVZjSlRq?= =?utf-8?B?QUFLU1RHMmtDek0rV1JicEd4THZCOGNwU3I4azBCUmNEWGJxWVVwQnp2MUMx?= =?utf-8?B?SlgrWklhaFU2NTQyNjFiRmplNS9abnplaDh6SVorRzczanYzbFJUaGRrc3hR?= =?utf-8?B?aElzcnI5ZVl6V2xuZzNUb3FacFpCN3dWVmtCZ0xEb3dWL3I3WmpaM3MwbXZY?= =?utf-8?B?L0pRMThpUWExVStMUW9JZ2dtVnd2QnhGeHQ4MUNUOGk2cEY5cC93dEY4OGRj?= =?utf-8?B?cjZTM1lJUWpiYktKMzZ1WUFOZll4QWRidWQxNGJMa0d1UFMrb2tHc3Rid05T?= =?utf-8?B?OHE1Q0greUZQUU8yNDlKeXRIblh1RmpkN21GZUhFMWRoaDJhOFphdTI1U3Ry?= =?utf-8?B?SlpsVkhWck5jblJxckhwaTFlUUtBajlFdm1jeHZwWWlwZzFjRzZ5a2ZJdkFW?= =?utf-8?B?OERZNkwwdlo2amZMUThOWTNudy84SjBLMm1LNW1MQW01SXZWc01PQkh5ZVNK?= =?utf-8?B?UUhPNXZaMWhLYjZBM3NDT09sSExNVS8xOERNdUErMW1Wa0hhck1NSUZrQjZJ?= =?utf-8?B?UTd0bUtybnNlVlN4WS9RR2VVZkhGRHpVUVI2K1pBRUVZRldaSy9FbWZBM1dB?= =?utf-8?B?ME9KOTBqSEJtUW9kM1VaU1BBYnhsNVhyUk03Ky9ZZmZPMEc5UWNYVHpaUWM3?= =?utf-8?B?MUE0RU9jK1RTQ0RmS2YwSjM5QVdndTFYZ1FoRm5XeThFU0lLOWlzVThxczRy?= =?utf-8?B?OGFSbFBoZVkzemJEZm1HMVl3RDVVRHB3bVRaMW80TDlWUWg1ekdmWS9kYTM0?= =?utf-8?B?L05Xd0hwL0tGMVYzZ1lwRCtlekpKNTZwSno3TWJWbGJpN2pkNmJoZUpVanJ4?= =?utf-8?B?SEhtdWtodjRZSkcvRm5MUnI3TTRIbk9GZDl6Zm5RVTZWSGdRZ25VZmROUDAv?= =?utf-8?B?MlRidEYxcjJUYjVZUzNCQXAyLzNvQzM3RDd0Ymg4TXhtWGlBSk5kQlgwb2dQ?= =?utf-8?B?bWc9PQ==?= Content-Type: multipart/alternative; boundary="_000_BY5PR11MB4196363D5DB6A54810950E3AB5689BY5PR11MB4196namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4196.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 045e6cf5-8904-492b-6040-08d9b4efc676 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2021 17:26:56.7926 (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: wuoqv+KCleqazc0BFAP6+gylj4HTjOhoRCsKpkKRPXQ9Odg6YK6IK4TFxW6/qvv1cno3wjoELXOiifFYLIP42A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3656 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC5277 (6770) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 17:27:06 -0000 --_000_BY5PR11MB4196363D5DB6A54810950E3AB5689BY5PR11MB4196namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwgVGV0c3V5YSwNCg0KVGhhbmtzIGZvciB0aGUgcXVpY2sgZGlzY3Vzc2lvbi9jbG9z dXJlLiAgSSBoYXZlIHJlamVjdGVkIHRoaXMgZXJyYXRhLg0KDQpSZWdhcmRzLA0KUm9iDQoNCg0K RnJvbTogaGFzZWdhd2EgPHplbWl5b3VAZ21haWwuY29tPg0KU2VudDogMDEgRGVjZW1iZXIgMjAy MSAxNzoxMg0KVG86IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPg0KQ2M6IFJGQyBF cnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPjsgc2NoaXNob2xAbm9ydGVs LmNvbTsgSGVjdG9yIFRyZXZpbm8gKGh0cmV2aW5vKSA8aHRyZXZpbm9AY2lzY28uY29tPjsgV2Fy cmVuIEt1bWFyaSA8d2FycmVuQGt1bWFyaS5uZXQ+OyBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndp bHRvbkBjaXNjby5jb20+OyBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+OyBNYWhl c2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT47IE5ldGNvbmYgPG5ldGNv bmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldGNvbmZdIFtUZWNobmljYWwgRXJyYXRhIFJl cG9ydGVkXSBSRkM1Mjc3ICg2NzcwKQ0KDQpUaGFuayB5b3UgZm9yIHlvdXIgZXhwbGFuYXRpb24u IEkgdW5kZXJzdGFuZC4NCg0KMjAyMeW5tDEy5pyIMuaXpSjmnKgpIDE6MzUgQW5keSBCaWVybWFu IDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+Og0KSGksDQoN ClRoaXMgZXJyYXRhIHNob3VsZCBiZSByZWplY3RlZC4NClRoZXJlIGlzIG5vIFlBTkcgbW9kdWxl IGZvciB0aGUgTkVUQ09ORiA8bm90aWZpY2F0aW9uPiBkZWZpbmVkIGFueXdoZXJlLg0KVGhlcmUg aXMgbm8gc3RhbmRhcmQgWUFORyBtb2R1bGUgZm9yIHRoZSA8Y3JlYXRlLXN1YnNjcmlwdGlvbj4g b3BlcmF0aW9uLg0KDQoxKSBSRkMgNTI3NyBwcmVkYXRlcyBSRkMgNjAyMCwgc28gWUFORyBpcyBu b3Qgbm9ybWF0aXZlIGluIFJGQyA1Mjc3Lg0KVXNlIHRoZSB1cGRhdGUgaW4gUkZDIDg2MzkuDQoN CjIpIEl0IGlzIG5vdCBwb3NzaWJsZSB0byBtb2RlbCB0aGUgPG5vdGlmaWNhdGlvbj4gZWxlbWVu dCBpbiBZQU5HLg0KDQozKSBBIG5ldyBSRkMgaXMgcmVxdWlyZWQgdG8gYWRkIG5ldyBmdW5jdGlv bmFsaXR5LiBUaGlzIGlzIG5vdCBhIGJ1Z2ZpeA0Kc3VpdGFibGUgZm9yIGFuIEVycmF0YS4NCg0K DQpBbmR5DQoNCg0KT24gV2VkLCBEZWMgMSwgMjAyMSBhdCA4OjE1IEFNIFJGQyBFcnJhdGEgU3lz dGVtIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0 b3Iub3JnPj4gd3JvdGU6DQpUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3Vi bWl0dGVkIGZvciBSRkM1Mjc3LA0KIk5FVENPTkYgRXZlbnQgTm90aWZpY2F0aW9ucyIuDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpZb3UgbWF5IHJldmlldyB0aGUg cmVwb3J0IGJlbG93IGFuZCBhdDoNCmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YS9l aWQ2NzcwDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUeXBlOiBU ZWNobmljYWwNClJlcG9ydGVkIGJ5OiBUZXRzdXlhIEhhc2VnYXdhIDx6ZW1peW91QGdtYWlsLmNv bTxtYWlsdG86emVtaXlvdUBnbWFpbC5jb20+Pg0KDQpTZWN0aW9uOiA0DQoNCk9yaWdpbmFsIFRl eHQNCi0tLS0tLS0tLS0tLS0NCjQuICBYTUwgU2NoZW1hIGZvciBFdmVudCBOb3RpZmljYXRpb24N Cg0KQ29ycmVjdGVkIFRleHQNCi0tLS0tLS0tLS0tLS0tDQpBZGQgYSBuZXcgc2VjdGlvbiAiWUFO RyBNb2R1bGUgZm9yIEV2ZW50IE5vdGlmaWNhdGlvbnMiLg0KDQoNCk5vdGVzDQotLS0tLQ0KVGhl IFhNTCBzY2hlbWEgZm9yIG5vdGlmaWNhdGlvbnMgaXMgZGVmaW5lZCwgYnV0IHRoZSB5YW5nIG1v ZHVsZSBpcyBub3QuIFRvIGFjaGlldmUgaW50ZXJvcGVyYWJpbGl0eSwgcGxlYXNlIGFkZCBhIFlB TkcgbW9kdWxlIGZvciBub3RpZmljYXRpb25zLg0KDQpJbnN0cnVjdGlvbnM6DQotLS0tLS0tLS0t LS0tDQpUaGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQiLiBJZiBu ZWNlc3NhcnksIHBsZWFzZQ0KdXNlICJSZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBpdCBz aG91bGQgYmUgdmVyaWZpZWQgb3INCnJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hl ZCwgdGhlIHZlcmlmeWluZyBwYXJ0eQ0KY2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBh bmQgZWRpdCB0aGUgcmVwb3J0LCBpZiBuZWNlc3NhcnkuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpSRkM1Mjc3IChkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0 aW9uLTE0KQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRpdGxlICAg ICAgICAgICAgICAgOiBORVRDT05GIEV2ZW50IE5vdGlmaWNhdGlvbnMNClB1YmxpY2F0aW9uIERh dGUgICAgOiBKdWx5IDIwMDgNCkF1dGhvcihzKSAgICAgICAgICAgOiBTLiBDaGlzaG9sbSwgSC4g VHJldmlubw0KQ2F0ZWdvcnkgICAgICAgICAgICA6IFBST1BPU0VEIFNUQU5EQVJEDQpTb3VyY2Ug ICAgICAgICAgICAgIDogTmV0d29yayBDb25maWd1cmF0aW9uDQpBcmVhICAgICAgICAgICAgICAg IDogT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudA0KU3RyZWFtICAgICAgICAgICAgICA6IElFVEYN ClZlcmlmeWluZyBQYXJ0eSAgICAgOiBJRVNHDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpuZXRjb25mIG1haWxpbmcgbGlzdA0KbmV0Y29uZkBpZXRm Lm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZg0K --_000_BY5PR11MB4196363D5DB6A54810950E3AB5689BY5PR11MB4196namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdv dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5IaSBBbmR5LCA8L3NwYW4+VGV0c3V5YSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzIGZvciB0aGUgcXVpY2sgZGlzY3Vzc2lvbi9jbG9zdXJlLiZuYnNwOyBJIGhhdmUgcmVq ZWN0ZWQgdGhpcyBlcnJhdGEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb2I8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gaGFzZWdhd2EgJmx0O3plbWl5b3VAZ21haWwuY29t Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDAxIERlY2VtYmVyIDIwMjEgMTc6MTI8YnI+DQo8Yj5U bzo8L2I+IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gUkZDIEVycmF0YSBTeXN0ZW0gJmx0O3JmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmcmZ3Q7 OyBzY2hpc2hvbEBub3J0ZWwuY29tOyBIZWN0b3IgVHJldmlubyAoaHRyZXZpbm8pICZsdDtodHJl dmlub0BjaXNjby5jb20mZ3Q7OyBXYXJyZW4gS3VtYXJpICZsdDt3YXJyZW5Aa3VtYXJpLm5ldCZn dDs7IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDtyd2lsdG9uQGNpc2NvLmNvbSZndDs7IEtlbnQg V2F0c2VuICZsdDtrZW50K2lldGZAd2F0c2VuLm5ldCZndDs7IE1haGVzaCBKZXRoYW5hbmRhbmkN CiAmbHQ7bWpldGhhbmFuZGFuaUBnbWFpbC5jb20mZ3Q7OyBOZXRjb25mICZsdDtuZXRjb25mQGll dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldGNvbmZdIFtUZWNobmljYWwg RXJyYXRhIFJlcG9ydGVkXSBSRkM1Mjc3ICg2NzcwKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+VGhhbmsgeW91IGZvciB5b3VyIGV4cGxhbmF0aW9uLiBJIHVuZGVy c3RhbmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4yMDIxPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5bm0PC9zcGFuPjEy PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pyIPC9zcGFu PjI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7ml6U8L3Nw YW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuacqDwv c3Bhbj4pIDE6MzUgQW5keSBCaWVybWFuDQogJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3 b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+VGhpcyBlcnJhdGEgc2hvdWxkIGJlIHJlamVjdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+VGhlcmUgaXMgbm8gWUFORyBtb2R1bGUgZm9yIHRoZSBORVRDT05GICZsdDtub3RpZmljYXRp b24mZ3Q7IGRlZmluZWQgYW55d2hlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGVyZSBpcyBu byBzdGFuZGFyZCBZQU5HIG1vZHVsZSBmb3IgdGhlICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uJmd0 OyBvcGVyYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjEpIFJGQyA1Mjc3IHByZWRhdGVzIFJGQyA2MDIwLCBzbyBZQU5HIGlzIG5vdCBub3Jt YXRpdmUgaW4gUkZDIDUyNzcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Vc2UgdGhlIHVwZGF0ZSBp biBSRkMgODYzOS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+MikgSXQgaXMgbm90IHBvc3NpYmxlIHRvIG1vZGVsIHRoZSAmbHQ7bm90aWZpY2F0aW9u Jmd0OyBlbGVtZW50IGluIFlBTkcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjMpIEEgbmV3IFJGQyBpcyByZXF1aXJlZCB0byBhZGQgbmV3IGZ1bmN0 aW9uYWxpdHkuIFRoaXMgaXMgbm90IGEgYnVnZml4PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5zdWl0 YWJsZSBmb3IgYW4gRXJyYXRhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFuZHk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5PbiBXZWQsIERlYyAxLCAyMDIxIGF0IDg6MTUgQU0gUkZDIEVycmF0YSBT eXN0ZW0gJmx0OzxhIGhyZWY9Im1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnIiB0YXJn ZXQ9Il9ibGFuayI+cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBi ZWVuIHN1Ym1pdHRlZCBmb3IgUkZDNTI3Nyw8YnI+DQomcXVvdDtORVRDT05GIEV2ZW50IE5vdGlm aWNhdGlvbnMmcXVvdDsuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQpZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDo8YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNjc3MCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YS9laWQ2NzcwPC9h Pjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K VHlwZTogVGVjaG5pY2FsPGJyPg0KUmVwb3J0ZWQgYnk6IFRldHN1eWEgSGFzZWdhd2EgJmx0Ozxh IGhyZWY9Im1haWx0bzp6ZW1peW91QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnplbWl5b3VA Z21haWwuY29tPC9hPiZndDs8YnI+DQo8YnI+DQpTZWN0aW9uOiA0PGJyPg0KPGJyPg0KT3JpZ2lu YWwgVGV4dDxicj4NCi0tLS0tLS0tLS0tLS08YnI+DQo0LiZuYnNwOyBYTUwgU2NoZW1hIGZvciBF dmVudCBOb3RpZmljYXRpb248YnI+DQo8YnI+DQpDb3JyZWN0ZWQgVGV4dDxicj4NCi0tLS0tLS0t LS0tLS0tPGJyPg0KQWRkIGEgbmV3IHNlY3Rpb24gJnF1b3Q7WUFORyBNb2R1bGUgZm9yIEV2ZW50 IE5vdGlmaWNhdGlvbnMmcXVvdDsuPGJyPg0KPGJyPg0KPGJyPg0KTm90ZXM8YnI+DQotLS0tLTxi cj4NClRoZSBYTUwgc2NoZW1hIGZvciBub3RpZmljYXRpb25zIGlzIGRlZmluZWQsIGJ1dCB0aGUg eWFuZyBtb2R1bGUgaXMgbm90LiBUbyBhY2hpZXZlIGludGVyb3BlcmFiaWxpdHksIHBsZWFzZSBh ZGQgYSBZQU5HIG1vZHVsZSBmb3Igbm90aWZpY2F0aW9ucy48YnI+DQo8YnI+DQpJbnN0cnVjdGlv bnM6PGJyPg0KLS0tLS0tLS0tLS0tLTxicj4NClRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9z dGVkIGFzICZxdW90O1JlcG9ydGVkJnF1b3Q7LiBJZiBuZWNlc3NhcnksIHBsZWFzZTxicj4NCnVz ZSAmcXVvdDtSZXBseSBBbGwmcXVvdDsgdG8gZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2 ZXJpZmllZCBvcjxicj4NCnJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhl IHZlcmlmeWluZyBwYXJ0eSZuYnNwOyA8YnI+DQpjYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3Rh dHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4gPGJyPg0KPGJyPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpSRkM1Mjc3IChkcmFmdC1pZXRm LW5ldGNvbmYtbm90aWZpY2F0aW9uLTE0KTxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KVGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBORVRDT05GIEV2ZW50IE5vdGlmaWNhdGlvbnM8YnI+DQpQ dWJsaWNhdGlvbiBEYXRlJm5ic3A7ICZuYnNwOyA6IEp1bHkgMjAwODxicj4NCkF1dGhvcihzKSZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBTLiBDaGlzaG9sbSwgSC4g VHJldmlubzxicj4NCkNhdGVnb3J5Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgOiBQUk9QT1NFRCBTVEFOREFSRDxicj4NClNvdXJjZSZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IE5ldHdvcmsgQ29uZmlndXJhdGlvbjxicj4N CkFyZWEmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDogT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudDxicj4NClN0cmVhbSZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IElFVEY8YnI+DQpWZXJpZnlpbmcg UGFydHkmbmJzcDsgJm5ic3A7ICZuYnNwOzogSUVTRzxicj4NCjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0Y29uZiBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BY5PR11MB4196363D5DB6A54810950E3AB5689BY5PR11MB4196namp_-- From nobody Fri Dec 3 17:10:40 2021 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 1704F3A0D37; Fri, 3 Dec 2021 17:10:34 -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: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <163858023406.23823.9409227063994285063@ietfa.amsl.com> Date: Fri, 03 Dec 2021 17:10:34 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-sztp-csr-12.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2021 01:10:35 -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 : Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request Authors : Kent Watsen Russ Housley Sean Turner Filename : draft-ietf-netconf-sztp-csr-12.txt Pages : 36 Date : 2021-12-03 Abstract: This draft extends the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-sztp-csr-12.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-12 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Fri Dec 3 17:15:36 2021 Return-Path: <0100017d8302a1ac-1b711386-b799-416b-99b5-4e68fceca3d0-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 B2BDD3A0D36; Fri, 3 Dec 2021 17:15:34 -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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 O0zQs4A8SGGx; Fri, 3 Dec 2021 17:15:29 -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 F1ABC3A0D35; Fri, 3 Dec 2021 17:15:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1638580527; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=d+Tp2rBViboHkYtH0ymhPIHx0M3nyhcXlmf++Vekxwg=; b=RGuaZnliQV4bq1k1kf6NoR2Fvzx/Tg/0kw8tL59DhRLSd+gMvCNtmFsX48YP3NhM XfN+mo49Hqv7HGwNPlH1tZkIuy0SsOwa0bwVim+ByWkpSxkx+COEt9Uar6KJAfsib/E L+IgjR91XOh1fDW8jFyB87fmwMvDgR/R1Bm75fJU= From: Kent Watsen Message-ID: <0100017d8302a1ac-1b711386-b799-416b-99b5-4e68fceca3d0-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_20E1DB5D-7C67-4359-804C-DAB12ED05EA3" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Sat, 4 Dec 2021 01:15:27 +0000 In-Reply-To: <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol> Cc: IETF SecDir , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" To: Yaron Sheffer References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.04-54.240.8.96 Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-sztp-csr-11 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, 04 Dec 2021 01:15:35 -0000 --Apple-Mail=_20E1DB5D-7C67-4359-804C-DAB12ED05EA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yaron, Please see below for some responses to your comments. I did also just post -12 including these changes: = https://www.ietf.org/archive/id/draft-ietf-netconf-sztp-csr-12.html Here=E2=80=99s a direct link to the diffs (note: Opsdir and Gendir = comments are also included): https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-sztp-csr-12= Kent (and Russ and Sean) >=20 > On Nov 28, 2021, at 3:22 PM, Yaron Sheffer = wrote: >=20 > In the third point below (certificate rotation), I understand why the = editors see it as out of scope. But we are still leaving implementers = with no guidance, and we=E2=80=99ve all seen enough real world cases = where this leads to people ignoring the vague =E2=80=9Cregenerate the = private key=E2=80=9D. Let me try to offer an alternative. > =20 > Old: > =20 > In cases where the SZTP-client does not possess an HSM, or otherwise = is unable to use an HSM for the private key, it is RECOMMENDED to = regenerate the private key (and associated identity certificates) = periodically. Details for how to generate a new private key and = associate a new identity certificate are outside the scope of this = document. > =20 > New: > =20 > In cases where the SZTP-client does not possess an HSM, or otherwise = is unable to use an HSM for the private key, it is RECOMMENDED to = regenerate the private key (and associated identity certificates) = periodically. If CMP or CMC was used for initial certificate = provisioning, it is RECOMMENDED to reuse the protocol (CMC or CMP) for = periodic certificate registration. Similarly, implementations SHOULD = also reuse the initial origin authentication method. > =20 Russ writes: Perhaps the word "regenerate" is the thing that is causing = confusion. Suggestion: In cases where the SZTP-client does not possess an HSM, or otherwise is = unable to use an HSM for the private key, it is RECOMMENDED that the = device periodically reset the configuration to the factory default and = repeat the SZTP protocol. Repeating the SZTP protocol may cause the = device to generate a fresh private key (and associated identity = certificates). Details for how to generate a new private key and = associate a new identity certificate are outside the scope of this = document. To which you replied: =20 I=E2=80=99m really surprised that a factory reset is the right thing = to do in this use case. But you are the expert. The new text works for me. Yaron =20 As the originator of the OLD text, I have the following comments: 1) it is not uncommon to find new devices without an HSM or devices with = an HSM that is only used as a source of entropy (not key protection). = So saying something to address these implementations seems prudent. 2) There=E2=80=99s no reason to call out CMP/CMS. P10 also works, and = note that the YANG in the draft is extensible to allow new formats to be = introduced over time. 3) The protocol as a whole is intended to move a device from an = =E2=80=9Cunmanaged=E2=80=9D state to a =E2=80=9Cmanaged=E2=80=9D state. = That is, SZTP would no longer be in play, as the only management = connections would be, e.g., NETCONF or RESTCONF. Once in the device is = in the managed state, =E2=80=9Cnormal=E2=80=9D ongoing management = mechanisms are expected to be utilized. We can hope that the mechanisms = include periodically prompting the device to regen its key and a = reissuance of an LDevID, but details are out of scope to this draft. 4) One case I=E2=80=99m aware of where a device runs the SZTP protocol = throughout its lifecycle is when a device is deployed in a physically = insecure location (think: a kiosk in an airport) whereby, to thwart = inadvertent disclosure of networking settings from a slash-and-grab, the = entirety of the device=E2=80=99s config is stored in memory (not on = disk). As such, every time power is lost, the device automatically = reverts to its factory default state and, when power is restored, must = run the SZTP protocol to join the network and be provisioned with = configuration. The draft addresses this case with statement =E2=80=9CIt = is RECOMMENDED that a new private key is generated for each CSR = described in this document." The net-net of all this is the following: NEWEST: In cases where the SZTP-client does not possess an HSM, or is unable to use an HSM to protect the private key, it is RECOMMENDED to periodically reset the private key (and associated identity certificates) in order to minimize the lifetime of unprotected private keys. For instance, an NMS controller/orchestrator application could periodically prompt the SZTP-client to generate a new private key and provide a certificate signing request (CSR) or, alternatively, push both the key and an identity certificate to the SZTP-client using, e.g., a PKCS #12 [RFC7292]. In another example, the SZTP-client could be configured to periodically reset the configuration to its factory default, thus causing removal of the private key and associated identity certificates and reexecution of the SZTP protocol. Good? [more below] > Thanks, > Yaron >=20 > =20 > =20 > From: Russ Housley > > Date: Sunday, November 28, 2021 at 20:10 > To: Yaron Sheffer > > Cc: Kent Watsen >, = IETF SecDir >, = draft-ietf-netconf-sztp-csr.all@ietf.org = = >, last-call@ietf.org = >, netconf@ietf.org = > > Subject: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 >=20 > Yaron: > =20 > =20 > Thank you for addressing my comments, I am happy with most of your = responses but I do have a few remaining questions: > =20 > =C2=B7 The commit that removes the dependency on IDevID and = LDevID does not fix the issue of non-orthogonality. There is very = detailed description for CMP and CMC, but nothing for PKCS #10 = (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box and it=E2=80=99= ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of PKCS#10 for = these certs is still TBD=E2=80=9D? > =20 > PKCS#10 is pretty simple. Are you aware of anything more that ought = to be said? > =20 > I think we should explicitly mention what this method *cannot* = provide. As far as I can tell, none of the origin authentication methods = are available when using PKCS #10 directly without wrapping it further. > =20 > That is reasonable. I will talk with my co-authors and see if we can = come up with a brief summary. One reason why the description statement in the "case p10-csr=E2=80=9D = node is so small is because that node (unlike "case cmc-csr" and "case = cmp-csr=E2=80=9D) uses the following typedef from the =E2=80=9Ccrypto-type= s=E2=80=9D draft (i.e. type ct:csr): typedef csr { type binary; description "A CertificationRequest structure, as specified in=20 RFC 2986, encoded using ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification Version 1.7 ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)."; } That is, the description for how the p10 is encoded on-the-wire is = defined elsewhere, and not duplicated here. To address your primary = point, as well as the point just mentioned, how about this? OLD: case p10-csr { leaf p10-csr { type ct:csr; description "A CertificationRequest structure, per RFC 2986."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification"; } } NEW: case p10-csr { leaf p10-csr { type ct:csr; description "A CertificationRequest structure, per RFC 2986. Encoding details are defined in the 'ct:csr' typedef defined in RFC AAAA. A raw P10 does not support origin authentication in the CSR structure. External origin authentication may be provided via the ZTP-client's authentication to the ZTP-server at the transport layer (e.g., TLS)."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification RFC AAAA: YANG Data Types and Groupings for Cryptography"; } } =20 Good? =20 > =C2=B7 I suggest to add the following reference to the = paragraph on quality randomness, as a strong proof that this is a real = world concern: > =20 > Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining = Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", = Proceedings of the 21st USENIX Security Symposium , August 2012, = >. > =20 > In another thread, something like this was suggested for another = document: > =20 > Implementations must randomly generate nonces and private keys. > The use of inadequate pseudo-random number generators (PRNGs) to > generate cryptographic keys can result in little or no security. An = attacker > may find it much easier to reproduce the PRNG environment that > produced the keys, searching the resulting small set of = possibilities, > rather than brute force searching the whole key space. As example = for > predictable random numbers see CVE-2008-0166 [=E2=80=A6]. The = generation > of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6= ], > NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and > others offers valuable guidance in this area. > =20 > If this approach works for you, we'll dig up the appropriate = references. > =20 > Yes, but the Heninger et al. reference is a better fit than the Debian = CVE because (1) it discusses network devices rather than servers and (2) = it shows how even less broken RNGs can be exploited by a network = attacker that only sees the public keys. > =20 > I just read the Abstract of the paper, and I see your point about the = attacker only observing the public keys. How about: > =20 > =20 > Implementations must randomly generate nonces and private keys. > The use of inadequate pseudo-random number generators (PRNGs) to > generate cryptographic keys can result in little or no security. An = attacker > may find it much easier to reproduce the PRNG environment that > produced the keys, searching the resulting small set of = possibilities, > rather than brute force searching the whole key space. As an = example of > predictable random numbers see CVE-2008-0166 [=E2=80=A6], and some = consequences > of low-entropy random numbers are discussed in Mining Your Ps and = Qs [...]. > The generation of quality random numbers is difficult. ISO/IEC = 20543:2019 [=E2=80=A6], > NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and > others offers valuable guidance in this area. The final text reads: Implementations must randomly generate nonces and private keys. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. As an example of predictable random numbers see CVE-2008-0166 [CVE-2008-0166], and some consequences of low-entropy random numbers are discussed in Mining Your Ps and Qs [MiningPsQs]. The generation of quality random numbers is difficult. [ISO.20543-2019], [NIST.SP.800-90Ar1], BSI AIS 31 [AIS31], BCP 106 [RFC4086], and others offer valuable guidance in this area. Good? > =C2=B7 I understand that key generation is out of scope and = maybe this needs to be a separate work item, but recommending periodic = replacement of the certs without recommending a suitable mechanism = leaves this solution with a big hole. > =20 > I do not agree. It does offer the protocol for obtaining replacement = certificates for devices that are able to generating a fresh = public/private key pair. Getting more detailed would be algorithm = specific, which is not appropriate in this document. > =20 > Not really, because the =E2=80=9Cprotocol=E2=80=9D described here is: = Client sends a CSR, Server responds with a complete client configuration = blob. This obviously doesn=E2=80=99t work for an already deployed = client. > =20 > I am really confused. The document is an addition to the Secure Zero = Touch Provisioning (SZTP). As such, it is technique to securely = provision a networking device when it is booting in a factory-default = state. That should happen at the initial deployment or after the device = is reset to the factory configuration. This is not the protocol for use = with an already deployed client. [the response for this =E2=80=9Cthird point=E2=80=9D is at the top of = this email.] Kent, on behalf of the authors --Apple-Mail=_20E1DB5D-7C67-4359-804C-DAB12ED05EA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi Yaron,

Please see below for some responses to = your comments.

I= did also just post -12 including these changes:
https://www.ietf.org/archive/id/draft-ietf-netconf-sztp-csr-12.= html

Here=E2=80=99s a direct link to = the diffs (note: Opsdir and Gendir comments are also included):
= https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-sztp-csr-12<= br class=3D"">

Kent (and Russ and Sean)



On Nov 28, 2021, at 3:22 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

In the third point below (certificate rotation), I = understand why the editors see it as out of scope. But we are still = leaving implementers with no guidance, and we=E2=80=99ve all seen enough = real world cases where this leads to people ignoring the vague = =E2=80=9Cregenerate the private key=E2=80=9D. Let me try to offer an = alternative.
 
Old:
 
In cases where the = SZTP-client does not possess an HSM, or otherwise is unable to use an = HSM for the private key, it is RECOMMENDED to regenerate the private key = (and associated identity certificates) periodically. Details for how to = generate a new private key and associate a new identity certificate are = outside the scope of this document.
 
New:
 
In cases where the SZTP-client does not possess an HSM, or = otherwise is unable to use an HSM for the private key, it is RECOMMENDED = to regenerate the private key (and associated identity certificates) = periodically. If CMP or CMC was used for initial certificate = provisioning, it is RECOMMENDED to reuse the protocol (CMC or CMP) for = periodic certificate registration. Similarly, implementations SHOULD = also reuse the initial origin authentication method.
 

Russ writes:

    Perhaps the word = "regenerate" is the thing that is causing confusion.
    Suggestion:

In cases where the SZTP-client = does not possess an HSM, or otherwise is unable to use an HSM for the = private key, it is RECOMMENDED that the device periodically reset the = configuration to the factory default and repeat the SZTP protocol. =  Repeating the SZTP protocol may cause the device to generate a = fresh private key (and associated identity certificates). Details for = how to generate a new private key and associate a new identity = certificate are outside the scope of this = document.


To which you replied:
 
    I=E2=80=99m really = surprised that a factory reset is the right thing to do in this use = case. But you are the expert.
    The new text works for = me.
    Yaron
 

As the = originator of the OLD text, I have the following comments:

1) it is not uncommon to find new devices = without an HSM or devices with an HSM that is only used as a source = of entropy (not key protection).  So saying something to address = these implementations seems prudent.

2) = There=E2=80=99s no reason to call out CMP/CMS.  P10 also works, and = note that the YANG in the draft is extensible to allow new formats = to be introduced over time.

3) The protocol as a whole is intended to move a = device from an =E2=80=9Cunmanaged=E2=80=9D state to a =E2=80=9Cmanaged=E2=80= =9D state. That is, SZTP would no longer be in play, as the only = management connections would be, e.g., NETCONF or = RESTCONF.  Once in the device is in the managed state, = =E2=80=9Cnormal=E2=80=9D ongoing management mechanisms are expected to = be utilized.  We can hope that the mechanisms include = periodically prompting the device to regen its key and a reissuance of = an LDevID, but details are out of scope to this draft.

4) One case I=E2=80=99m aware of = where a device runs the SZTP protocol throughout its lifecycle is when a = device is deployed in a physically insecure location (think: a = kiosk in an airport) whereby, to thwart inadvertent disclosure = of networking settings from a slash-and-grab, the entirety of the = device=E2=80=99s config is stored in memory (not on disk).  As = such, every time power is lost, the device automatically reverts to its = factory default state and, when power is restored, must run the = SZTP protocol to join the network and be provisioned with configuration. = The draft addresses this case with statement =E2=80=9CIt is RECOMMENDED = that a new private key is generated for each CSR described in this = document."


The net-net of all this is the = following:

NEWEST:

   In cases where the SZTP-client does = not possess an HSM, or is unable
   to use = an HSM to protect the private key, it is RECOMMENDED to
   periodically reset the private key (and = associated identity
   certificates) in order to = minimize the lifetime of unprotected
  =  private keys.  For instance, an NMS = controller/orchestrator
   application could = periodically prompt the SZTP-client to generate a
   new private key and provide a certificate = signing request (CSR) or,
   alternatively, = push both the key and an identity certificate to the
   SZTP-client using, e.g., a PKCS #12 = [RFC7292].  In another example,
  =  the SZTP-client could be configured to periodically = reset the
   configuration to its factory = default, thus causing removal of the
  =  private key and associated identity certificates = and reexecution of
   the SZTP protocol.


Good?

[more below]


Thanks,
          &= nbsp;     Yaron

 
 

From: Russ Housley <housley@vigilsec.com>
Date: Sunday, November 28, = 2021 at 20:10
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Kent Watsen <kent+ietf@watsen.net>, = IETF SecDir <secdir@ietf.org>, draft-ietf-netconf-sztp-csr.all@ietf.org <draft-ietf-netconf-sztp-csr.all@ietf.org>, last-call@ietf.org <last-call@ietf.org>, netconf@ietf.org <netconf@ietf.org>
Subject: Re: Secdir last call = review of draft-ietf-netconf-sztp-csr-11

Yaron:
 
 
Thank you for addressing my comments, I am happy with most of = your responses but I do have a few remaining questions:
 

=C2=B7         The commit that = removes the dependency on IDevID and LDevID does not fix the issue of = non-orthogonality. There is very detailed description for CMP and CMC, = but nothing for PKCS #10 (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 = out of the box and it=E2=80=99ll just work=E2=80=9D? Or does it mean = =E2=80=9Cthe usage of PKCS#10 for these certs is still TBD=E2=80=9D?

 
PKCS#10 is pretty simple.  Are you aware of anything = more that ought to be said?
 
I think we should explicitly mention what this method *cannot* provide. As far as I can tell, none of the origin = authentication methods are available when using PKCS #10 directly = without wrapping it further.
 
That= is reasonable.  I will talk with my co-authors and see if we can = come up with a brief = summary.


One reason why the = description statement in the "case p10-csr=E2=80=9D node is so small is = because that node (unlike "case cmc-csr" and "case cmp-csr=E2=80=9D) = uses the following typedef from the =E2=80=9Ccrypto-types=E2=80=9D draft = (i.e. type ct:csr):

    =  typedef csr {
       type = binary;
       description
         "A CertificationRequest = structure, as specified in 
      =     RFC 2986, encoded using ASN.1 distinguished encoding
          rules (DER), as specified = in ITU-T X.690.";
       reference
         "RFC 2986:
            PKCS #10: = Certification Request Syntax Specification
    =         Version 1.7
    =       ITU-T X.690:
      =       Information technology - ASN.1 encoding rules:
            Specification of = Basic Encoding Rules (BER),
        =     Canonical Encoding Rules (CER) and Distinguished
            Encoding Rules = (DER).";
     }

That is, the description for how the p10 is encoded = on-the-wire is defined elsewhere, and not duplicated here.  To = address your primary point, as well as the point just mentioned, how = about this?

OLD:

         case p10-csr {
           leaf p10-csr {
             type = ct:csr;
            =  description
          =      "A CertificationRequest structure, per RFC = 2986.";
            =  reference
            =    "RFC 2986: PKCS #10: Certification
  =                     =     Request Syntax Specification";
    =        }
        =  }

NEW:

         case p10-csr {
           leaf p10-csr {
             type = ct:csr;
            =  description
          =      "A CertificationRequest structure, per = RFC 2986.
            =     Encoding details are defined in the 'ct:csr'
              =   typedef defined in RFC AAAA.

              =   A raw P10 does not support origin authentication in
              =   the CSR structure.  External = origin authentication
        =         may be provided via the = ZTP-client's authentication
      =           to the ZTP-server at the = transport layer (e.g., TLS).";
      =        reference
      =          "RFC 2986: PKCS #10: Certification = Request Syntax
          =               =   Specification
        =         RFC AAAA: YANG Data Types and Groupings = for
              =             Cryptography";
           }
 =        }

 

Good? =  



=C2=B7         I suggest to add the = following reference to the paragraph on quality randomness, as a strong = proof that this is a real world concern:

 
Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, = "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network = Devices", Proceedings of the 21st USENIX Security Symposium , = August 2012, <https://factorable.net/>.
 
In another thread, something like this was suggested for = another document:
 
   Implementations must randomly generate nonces = and private keys.
   The use of inadequate = pseudo-random number generators (PRNGs) to
   generate cryptographic keys can result in little = or no security. An attacker
   may find it much easier to = reproduce the PRNG environment that
   produced the keys, searching the resulting small = set of possibilities,
   rather than brute force = searching the whole key space. As example for
   predictable random numbers see CVE-2008-0166 = [=E2=80=A6]. The generation
   of quality random numbers = is difficult. ISO/IEC 20543:2019 [=E2=80=A6],
   NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS = 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], and
   others offers valuable guidance in this = area.
 
If this approach works for you, we'll = dig up the appropriate references.
 
Yes, but the Heninger et al. reference is a better fit than = the Debian CVE because (1) it discusses network devices rather than = servers and (2) it shows how even less broken RNGs can be exploited by a = network attacker that only sees the public keys.
 
I = just read the Abstract of the paper, and I see your point about the = attacker only observing the public keys.  How about:
 
 
   Implementations must randomly generate nonces = and private keys.
   The use of inadequate pseudo-random number = generators (PRNGs) to
   generate cryptographic keys can result in little = or no security. An attacker
   may find it much easier to reproduce the PRNG = environment that
   produced the keys, searching the resulting small = set of possibilities,
   rather than brute force searching the whole key = space. As an example of
   predictable random numbers see CVE-2008-0166 = [=E2=80=A6], and some consequences
   of low-entropy = random numbers are discussed in Mining Your Ps and Qs = [...].
   The generation of quality = random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6],
   NIST SP 800-90A = Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], = and
  =  others offers valuable guidance in this = area.


The final text = reads:

  =  Implementations must randomly generate nonces and = private keys.  The
   use of = inadequate pseudo-random number generators (PRNGs) to generate
   cryptographic keys can result in little or no = security.  An attacker
   may = find it much easier to reproduce the PRNG environment that
   produced the keys, searching the resulting small = set of
   possibilities, rather than brute force = searching the whole key space.
   As an = example of predictable random numbers see CVE-2008-0166
   [CVE-2008-0166], and some consequences of = low-entropy random numbers
   are discussed = in Mining Your Ps and Qs [MiningPsQs].  The generation
   of quality random numbers is = difficult.  [ISO.20543-2019],
  =  [NIST.SP.800-90Ar1], BSI AIS 31 [AIS31], BCP 106 = [RFC4086], and
   others offer valuable = guidance in this area.

Good?



=C2=B7         I understand that = key generation is out of scope and maybe this needs to be a separate = work item, but recommending periodic replacement of the certs without = recommending a suitable mechanism leaves this solution with a big = hole.

 
I do not agree. =  It does offer the protocol for obtaining replacement certificates = for devices that are able to generating a fresh public/private key pair. =  Getting more detailed would be algorithm specific, which is not = appropriate in this document.
 
Not really, because the =E2=80=9Cprotocol=E2=80=9D described = here is: Client sends a CSR, Server responds with a complete client = configuration blob. This obviously doesn=E2=80=99t work for an already = deployed client.
 
I = am really confused.  The document  is an addition to = the Secure Zero Touch Provisioning (SZTP).  As such, it is = technique to securely provision a networking device when it is booting = in a factory-default state.  That should happen at the initial = deployment or after the device is reset to the factory configuration. =  This is not the protocol for use with an already deployed = client.


[the response for this = =E2=80=9Cthird point=E2=80=9D is at the top of this = email.]



Kent, on behalf of the authors




= --Apple-Mail=_20E1DB5D-7C67-4359-804C-DAB12ED05EA3-- From nobody Sat Dec 4 03:58:48 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D14D3A07FF; Sat, 4 Dec 2021 03:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 nPNRHOg5LlPt; Sat, 4 Dec 2021 03:58:18 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 3690F3A07FC; Sat, 4 Dec 2021 03:58:18 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id s137so5737656pgs.5; Sat, 04 Dec 2021 03:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:date:from:subject:thread-topic:in-reply-to:message-id :references:to:cc:content-transfer-encoding; bh=YEe03L8CMnAXeYNUbKiTeX7LY2GWe7J58EJqZenrfLE=; b=aA9hvhyDYJyxlHC0WjF3MkZfEJ79WoKSvDoBjKYS5uo5tkJUtouPT/n1hiFIixyLlA Mc91jjvbAx081z3GsxfkPmw0/0Moc2lKcEx/OW4m0Jrt/94hOHJD8yoaTZtnqHXwq260 1a2K3JIhjcZMO4fE4itJ0jRGBufG6LF1FksBSLylipf1TPUOPm+Po1Z9tFdgc12MxuKR a+oMZlD1M+d5dgfam8nIfao8koHLo+QKsq8UvjiB185ScTcPp9KIUjWgvjQ5qMkpVSMe SESeGVkXnTL4JaMCBl8Wpe1ndNOIWtyfZ/MmO6UkFYdn9ir/KfuVWahWMM5mhXX0/GLU vxXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:date:from:subject:thread-topic :in-reply-to:message-id:references:to:cc:content-transfer-encoding; bh=YEe03L8CMnAXeYNUbKiTeX7LY2GWe7J58EJqZenrfLE=; b=BcAV1wtiMo/8hfKlbzpjmA/H/BQrB/1DsrxP2Sgggbpo66tBWIRzNmkSvh+wTHtIc3 M/tn0LstQSutiQShoqKyZMcH7ynnXinXYQZeyX+tsCbuKBFEFeArnlvSWDFVj1+6d1aw rGUmiPi/Vh8VAtWAiMndIKAt9IBTSqczL3pxlK5f+TtISjS9v5uxlgNtWtO0dE8IxWke lrQvRnIbDZNczxa7xZax8KgUwXxoKIRE1hkh6CTG8tp5xrI6w8ZI277KxhFn+rs8WAY5 AckTSvrX9CZBOoo8BV3iqCJn+1IbeW0IyklHrIzPOeggmaJMniVP10Nbca6DVsUj4m/q L1TQ== X-Gm-Message-State: AOAM531udaM6VmRWz67w+OdcFxApzSWauMbX5cLEqIKkGfUX0x4ThRJ8 WqbiPg5HzPiZVDtiei3oQHfl0DM4Wlc= X-Google-Smtp-Source: ABdhPJzprH9cfWw9Q5khBhqo9zwdtBxQlNYa/CnbsjOODAyZCxemPZVlbuTuKLG4MU/InV9zaQ+yFA== X-Received: by 2002:a65:40cd:: with SMTP id u13mr9219833pgp.450.1638619096543; Sat, 04 Dec 2021 03:58:16 -0800 (PST) Received: from MacBook-Pro-2.local (IGLD-84-229-147-189.inter.net.il. [84.229.147.189]) by smtp.gmail.com with ESMTPSA id t8sm6102309pfe.28.2021.12.04.03.58.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Dec 2021 03:58:16 -0800 (PST) MIME-Version: 1.0 Date: Sat, 4 Dec 2021 13:58:10 +0200 From: Yaron Sheffer Thread-Topic: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 In-Reply-To: <0100017d8302a1ac-1b711386-b799-416b-99b5-4e68fceca3d0-000000@email.amazonses.com> Message-ID: <21D42DFF-02A0-F141-B59B-4E4E54C12934@hxcore.ol> References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol>, <0100017d8302a1ac-1b711386-b799-416b-99b5-4e68fceca3d0-000000@email.amazonses.com> To: Kent Watsen Cc: IETF SecDir , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-sztp-csr-11 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, 04 Dec 2021 11:58:24 -0000

I am good with the latest text= . Thank you Kent and Russ!

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: Kent Watsen <kent+ietf@watsen.net&g= t;
Date: Saturday, December 4, 2021 at 03:15
To: Yaron = Sheffer <yaronf.ietf@gmail.com>
Cc: IETF SecDir <secdir@= ietf.org>, draft-ietf-netconf-sztp-csr.all@ietf.org <draft-ietf-netco= nf-sztp-csr.all@ietf.org>, last-call@ietf.org <last-call@ietf.org>= , netconf@ietf.org <netconf@ietf.org>
Subject: Re: Secdir l= ast call review of draft-ietf-netconf-sztp-csr-11

 

Hi Yaron,=

 <= /p>

Please see be= low for some responses to your comments.

 

<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

In the third point below (certifica= te rotation), I understand why the editors see it as out of scope. But we a= re still leaving implementers with no guidance, and we=E2=80=99ve all seen = enough real world cases where this leads to people ignoring the vague =E2= =80=9Cregenerate the private key=E2=80=9D. Let me try to offer an alternati= ve.

 

Old:

 

In cases where the SZTP-client does not possess an HSM, or o= therwise is unable to use an HSM for the private key, it is RECOMMENDED to = regenerate the private key (and associated identity certificates) periodica= lly. Details for how to generate a new private key and associate a new iden= tity certificate are outside the scope of this document.

 

New:=

 <= /o:p>

In case= s where the SZTP-client does not possess an HSM, or otherwise is unable to = use an HSM for the private key, it is RECOMMENDED to regenerate the private= key (and associated identity certificates) periodically. If CMP or CMC was= used for initial certificate provisioning, it is RECOMMENDED to reuse the = protocol (CMC or CMP) for periodic certificate registration. Similarly, imp= lementations SHOULD also reuse the initial origin authentication method.

&nbs= p;

 

Russ writes:

 

    Perhaps the word "regenerate" is the thing = that is causing confusion.

    S= uggestion:

 

In cases where the SZTP-client does not= possess an HSM, or otherwise is unable to use an HSM for the private key, = it is RECOMMENDED that the device periodically reset the configuration to t= he factory default and repeat the SZTP protocol.  Repeating the SZTP p= rotocol may cause the device to generate a fresh private key (and associate= d identity certificates). Details for how to generate a new private key and= associate a new identity certificate are outside the scope of this documen= t.

 

 

To which you replied:

 

    I=E2=80=99m= really surprised that a factory reset is the right thing to do in this use= case. But you are the expert.

  &nbs= p; The new text works for me.

   = ; Yaron

 

=

 

As the originator of the OLD text, I have the= following comments:

1) it is not uncommon to find new devices witho= ut an HSM or devices with an HSM that is only used as a source of entr= opy (not key protection).  So saying something to address these implem= entations seems prudent.

2) There=E2=80=99s no reason to call o= ut CMP/CMS.  P10 also works, and note that the YANG in the draft is&nb= sp;extensible to allow new formats to be introduced over time.

 

3) The protocol as a wh= ole is intended to move a device from an =E2=80=9Cunmanaged=E2=80=9D state = to a =E2=80=9Cmanaged=E2=80=9D state. That is, SZTP would no longer be= in play, as the only management connections would be, e.g., NETCONF or RES= TCONF.  Once in the device is in the managed state, =E2=80=9Cnorm= al=E2=80=9D ongoing management mechanisms are expected to be utilized. = ; We can hope that the mechanisms include periodically prompting the d= evice to regen its key and a reissuance of an LDevID, but details are = out of scope to this draft.

4) One case I=E2=80=99m aware of where a device runs the SZTP p= rotocol throughout its lifecycle is when a device is deployed in a phy= sically insecure location (think: a kiosk in an airport) whereby, to thwart= inadvertent disclosure of networking settings from a slash-and-grab, = the entirety of the device=E2=80=99s config is stored in memory (not on dis= k).  As such, every time power is lost, the device automatically rever= ts to its factory default state and, when power is restored, must run = the SZTP protocol to join the network and be provisioned with configuration= . The draft addresses this case with statement =E2=80=9CIt is RECOMMENDED t= hat a new private key is generated for each CSR described in this docu= ment."

 

The net-net of all this is the following:

 

NEWEST:

&nbs= p;

   In ca= ses where the SZTP-client does not possess an HSM, or is unable
&nb= sp;  to use an HSM to protect the private key, it is RECOMMENDED = to
   periodically reset the private key (and associated ident= ity
   certificates) in order to minimize the lifetime of = ;unprotected
   private keys.  For instance, an NMS = controller/orchestrator
   application could periodically prom= pt the SZTP-client to generate a
   new private key and p= rovide a certificate signing request (CSR) or,
   alterna= tively, push both the key and an identity certificate to the
 =  SZTP-client using, e.g., a PKCS #12 [RFC7292].  In another=  example,
   the SZTP-client could be configured to perio= dically reset the
   configuration to its factory default= , thus causing removal of the
   private key and associat= ed identity certificates and reexecution of
   the SZTP p= rotocol.

 

Good?

 

[more below]

 

 

Thanks,

    =             Yaron

 <= /span>

 =

&= nbsp;

From:&nb= sp;Russ Housley <housley@vigilsec.com>
Date= : Sunday, November 28, = 2021 at 20:10
To: Yaron Sheffer <yaronf.ietf@gma= il.com>
Cc: Kent Watsen <kent+ietf@watsen.= net>, IETF SecDir <secdir@ietf= .org>, draft-ietf-netconf-sztp-csr.= all@ietf.org <draft-ietf-netconf-sz= tp-csr.all@ietf.org>, last-call@ietf.org <last-call@ietf.org>, <= /span>netconf@ietf.org <netconf@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-netconf-sztp-= csr-11

Yaron:

 

 

Thank you for addressing my com= ments, I am happy with most of your responses but I do have a few remaining= questions:

 

=C2=B7         The commit that removes the d= ependency on IDevID and LDevID does not fix the issue of non-orthogonality.= There is very detailed description for CMP and CMC, but nothing for PKCS #= 10 (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box and it=E2=80= =99ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of PKCS#10 for= these certs is still TBD=E2=80=9D?

<= div style=3D'margin-left:.5in'>

 

=

PKCS#10 is pretty simple.  Are yo= u aware of anything more that ought to be said?

<= /div>
<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

<= /div>

I think we should explicitly mention what this method *ca= nnot* provide. As far as I can tell, none of the origin authentication = methods are available when using PKCS #10 directly without wrapping it furt= her.

 

That is reasonable.  I will talk with my = co-authors and see if we can come up with a brief summary.

 

 

One reason why the description statement in the "case= p10-csr=E2=80=9D node is so small is because that node (unlike "case&= nbsp;cmc-csr" and "case cmp-csr=E2=80=9D) uses the following type= def from the =E2=80=9Ccrypto-types=E2=80=9D draft (i.e. type ct:csr):
     typedef csr {
       type bina= ry;
       description
       = ;  "A CertificationRequest structure, as specified in 
&n= bsp;         RFC 2986, encoded using ASN.1 distinguishe= d encoding
          rules (DER), as specified = in ITU-T X.690.";
       reference
  &n= bsp;      "RFC 2986:
        &nb= sp;   PKCS #10: Certification Request Syntax Specification
  &= nbsp;         Version 1.7
       = ;   ITU-T X.690:
            Informat= ion technology - ASN.1 encoding rules:
         = ;   Specification of Basic Encoding Rules (BER),
    &nbs= p;       Canonical Encoding Rules (CER) and Distinguished            Encoding Rules (DER).";
=      }

That is, the description for how the p10 is en= coded on-the-wire is defined elsewhere, and not duplicated here.  To a= ddress your primary point, as well as the point just mentioned, how about t= his?


OLD:

         c= ase p10-csr {
           leaf p10-csr {             type ct:csr;
  &nb= sp;          description
      &= nbsp;        "A CertificationRequest structure, pe= r RFC 2986.";
             refer= ence
               "RFC 29= 86: PKCS #10: Certification
            &n= bsp;             Request Syntax Specification= ";
           }
    &nbs= p;    }

NEW:

         case p10-csr {
    =        leaf p10-csr {
        &n= bsp;    type ct:csr;
           =  description
              &nbs= p;"A CertificationRequest structure, per RFC 2986.
  &nbs= p;             Encoding details are defined i= n the 'ct:csr'
               &n= bsp;typedef defined in RFC AAAA.

          =       A raw P10 does not support origin authentica= tion in
                the= CSR structure.  External origin authentication
  &n= bsp;             may be provided via the= ZTP-client's authentication
          &nb= sp;     to the ZTP-server at the transport layer (e.g.,= TLS).";
             reference<= br>               "RFC 2986: P= KCS #10: Certification Request Syntax
        &= nbsp;                 Specific= ation
                RFC A= AAA: YANG Data Types and Groupings for
         = ;                 Cryptography= ";
           }
    &nbs= p;    }

 

 

Good?  

 

 



=C2=B7         I suggest to add the following= reference to the paragraph on quality randomness, as a strong proof that t= his is a real world concern:

 

Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman,= "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network = Devices", Proceedings of the 21st USENIX Security Symposium , August 2012, <https://factorable.net/>.

=

 

In another thread, something like this was suggested for another docu= ment:

=

 

   Implementations must randomly generate nonces = and private keys.

   The use of inadequate pseudo-random numb= er generators (PRNGs) to

   generate cryptographic keys can result= in little or no security. An attacker

   may find it much easie= r to reproduce the PRNG environment that

   produced the keys, sea= rching the resulting small set of possibilities,

=
=

   rather than br= ute force searching the whole key space. As example for

   predict= able random numbers see CVE-2008-0166 [=E2=80=A6]. The generation

  &nb= sp;of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80= =A6],

=

   NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [= =E2=80=A6], BCP 106 [RFC4086], and

   others offers valuable = guidance in this area.

 

If this approach works for you, we'll dig up th= e appropriate references.

 

Yes, but the Heninger et al. reference is a b= etter fit than the Debian CVE because (1) it discusses network devices rath= er than servers and (2) it shows how even less broken RNGs can be exploited= by a network attacker that only sees the public keys.

=
<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

<= /div>

I just read the Abstract of the paper, and I see your point about= the attacker only observing the public keys.  How about:

 

 

   Impleme= ntations must randomly generate nonces and private keys.

   The use of inadequate pseudo-random number g= enerators (PRNGs) to

   gener= ate cryptographic keys can result in little or no security. An attacker

   may find it much easier to re= produce the PRNG environment that

 = ;  produced the keys, searching the resulting small set of possibiliti= es,

   rather than brute forc= e searching the whole key space. As an example of

   predictable random numbers see CVE-2008-0166 [=E2= =80=A6], and some consequences

  &= nbsp;of low-entropy random numbers are discussed in Mining Your Ps and= Qs [...].

<= p class=3DMsoNormal style=3D'margin-left:.5in'>   The generation = of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6],

   NIST SP 800-90A Rev.1 [=E2=80= =A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], and

   others offers valuable guidance in this are= a.

 

 

The final text reads:

 

   Implementations mu= st randomly generate nonces and private keys.  The
 =  use of inadequate pseudo-random number generators (PRNGs) to ge= nerate
   cryptographic keys can result in little or no securi= ty.  An attacker
   may find it much easier to = reproduce the PRNG environment that
   produced the keys,= searching the resulting small set of
   possibilities, rather= than brute force searching the whole key space.
   As an= example of predictable random numbers see CVE-2008-0166
   [C= VE-2008-0166], and some consequences of low-entropy random numbers
=    are discussed in Mining Your Ps and Qs [MiningPsQs]. &nbs= p;The generation
   of quality random numbers is difficul= t.  [ISO.20543-2019],
   [NIST.SP.800-90Ar1], BSI AI= S 31 [AIS31], BCP 106 [RFC4086], and
   others offer valu= able guidance in this area.

Good?<= o:p>

 

 

 

=

=C2=B7    &nb= sp;    I understand that key generation is out of scope and maybe this needs to = be a separate work item, but recommending periodic replacement of the certs= without recommending a suitable mechanism leaves this solution with a big = hole.

 

I do not agree.  It does offer the protocol= for obtaining replacement certificates for devices that are able to genera= ting a fresh public/private key pair.  Getting more detailed would be = algorithm specific, which is not appropriate in this document.

 

Not really, because the =E2=80=9Cprotocol=E2= =80=9D described here is: Client sends a CSR, Server responds with a comple= te client configuration blob. This obviously doesn=E2=80=99t work for an al= ready deployed client.

<= div>

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>I am really confused.  = The document  is an addition to the Secure Zero Touch Provisionin= g (SZTP).  As such, it is technique to securely provision a networking= device when it is booting in a factory-default state.  That should ha= ppen at the initial deployment or after the device is reset to the factory = configuration.  This is not the protocol for use with an already deplo= yed client.

 

 

[the response for this =E2=80=9Cthi= rd point=E2=80=9D is at the top of this email.]

 

 

 

Kent, on behalf of t= he authors

 

 

 

 

= From nobody Fri Dec 10 02:50:52 2021 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 495FD3A07E1; Fri, 10 Dec 2021 02:50:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-netconf-sztp-csr@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, mjethanandani@gmail.com, mjethanandani@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <163913344557.2346.7878185314700155840@ietfa.amsl.com> Date: Fri, 10 Dec 2021 02:50:46 -0800 Archived-At: Subject: [netconf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-netconf-sztp-csr-12=3A_=28with_COMMENT=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2021 10:50:47 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-netconf-sztp-csr-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Mahesh Jethanandani for the shepherd's write-up even if the section about the WG consensus does not give any information about the WG consensus... I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 1.2 -- Just wondering why the terms of SZTP-client/server have to be defined in the document rather than using the previously defined bootstrap server. -- Section 1.4 -- Even if the base64 content is rather long, why not providing examples in appendix ? -- Section 2.1 -- I am not a YANG expert, but it seems that the lines "module: ietf-sztp-csr" should only appear once in the tree view ? In "generate an new asymmetric key", should it rather be a "key pair" ? Of course, being asymmetric requires two keys so this may be implicit. -- Section 2.2 -- As P10 is not previously defined (guessing it is PKCS#10 though), suggest s/P10-based/PCKS#10-based/ In the example for the algorithm leaves, are the base64 values really too long to be represented in the examples ? == NITS == In section 3, "This module is defines independently" ? From nobody Sat Dec 11 06:35:07 2021 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 5D3493A089A; Sat, 11 Dec 2021 06:35:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: draft-ietf-netconf-sztp-csr.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163923330133.25390.15619360580796692604@ietfa.amsl.com> Reply-To: Yaron Sheffer Date: Sat, 11 Dec 2021 06:35:01 -0800 Archived-At: Subject: [netconf] Secdir telechat review of draft-ietf-netconf-sztp-csr-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 14:35:01 -0000 Reviewer: Yaron Sheffer Review result: Ready The latest version addresses all my previous review's comments. From nobody Mon Dec 13 11:35:19 2021 Return-Path: <0100017db54a93d5-b2d5ac81-73ed-4acd-9aed-b835b59e846b-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 6A7783A0A8C; Mon, 13 Dec 2021 11:35:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 y5_Lle8FhvMG; Mon, 13 Dec 2021 11:35:08 -0800 (PST) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C580A3A0A87; Mon, 13 Dec 2021 11:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639424103; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=7QlYHC8vWwERpYZwiFv6qAtvro/so65wU3YJP/cqeco=; b=G7lNiiO3EYMTnFUxxzrRH5UoG3PiCbhqmFUth56ijLBLYNL4EgdG38X2nVy56yrq y3aDGEqYNnEL0FTFvJ55x6E6jWnbEdJdg7//d+TiGYwpZVuORQuS/LzYKlc0HkpE/KY WyuGMu3ehv2rE2AXsXKeQYsoZz6cPrk3zpkWbOeA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Kent Watsen In-Reply-To: <163913344557.2346.7878185314700155840@ietfa.amsl.com> Date: Mon, 13 Dec 2021 19:35:03 +0000 Cc: The IESG , draft-ietf-netconf-sztp-csr@ietf.org, "netconf-chairs@ietf.org" , "netconf@ietf.org" , Mahesh Jethanandani Content-Transfer-Encoding: quoted-printable Message-ID: <0100017db54a93d5-b2d5ac81-73ed-4acd-9aed-b835b59e846b-000000@email.amazonses.com> References: <163913344557.2346.7878185314700155840@ietfa.amsl.com> To: =?utf-8?Q?=C3=89ric_Vyncke?= X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.13-54.240.48.92 Archived-At: Subject: Re: [netconf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-netconf-sztp-csr-12=3A_=28with_COMMENT=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 19:35:13 -0000 Hi Eric, Thank you for your review. Responses to your unblocking comments are = below. Kent > On Dec 10, 2021, at 5:50 AM, =C3=89ric Vyncke via Datatracker = wrote: >=20 > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-netconf-sztp-csr-12: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for the work put into this document. >=20 > Please find below some non-blocking COMMENT points (but replies would = be > appreciated even if only for my own education), and some nits. >=20 > Special thanks to Mahesh Jethanandani for the shepherd's write-up even = if the > section about the WG consensus does not give any information about the = WG > consensus... >=20 > I hope that this helps to improve the document, >=20 > Regards, >=20 > -=C3=A9ric > =3D=3D COMMENTS =3D=3D >=20 > -- Section 1.2 -- > Just wondering why the terms of SZTP-client/server have to be defined = in the > document rather than using the previously defined bootstrap server. Good catch. The main issue is, I think, that the RFC 8572 uses the term = =E2=80=9Cdevice=E2=80=9D, which is very generic and sometimes maybe = confusing (though RFC 8572 does a fine job always establishing context). = We could=E2=80=99ve used =E2=80=9Cbootstrap-server=E2=80=9D and = =E2=80=9Cbootstrap-client=E2=80=9D, but it seemed more proper to use = =E2=80=9CSZTP=E2=80=9D, comparable to how folks talk about =E2=80=9CSSH = client=E2=80=9D, =E2=80=9CTLS server=E2=80=9D, etc.=20 > -- Section 1.4 -- > Even if the base64 content is rather long, why not providing examples = in > appendix ? I have 10 other drafts in-progress and the general consensus of the WG = is that having real base64 values offers little value while sometimes = creating huge readability issues. I have seen it once where more than a = page of draft text was nothing but base64 (a chain of certs). Much of = YANG=E2=80=99s readability comes from matching parameters/indentation = and, when huge blocks of gibberish exist, that becomes hard to do. > -- Section 2.1 -- > I am not a YANG expert, but it seems that the lines "module: = ietf-sztp-csr" > should only appear once in the tree view ? You're so modest ;) Actually, an update to the underlying tool I was using to generate the = tree diagram had a change in behavior. Fixed now! > In "generate an new asymmetric key", should it rather be a "key pair" = ? Of > course, being asymmetric requires two keys so this may be implicit. Common parlance? At least, neither of my co-authors (established Sec = folks) nor the Secdir had issue with it. My guess is that the private key is generated while the public key is = derived from the private key. > -- Section 2.2 -- > As P10 is not previously defined (guessing it is PKCS#10 though), = suggest > s/P10-based/PCKS#10-based/ Update applied. > In the example for the algorithm leaves, are the base64 values really = too long > to be represented in the examples ? The algorithm-identifiers are pretty small ASN.1 objects...such that the = real base64 is just a line long. That said, I no longer use real = base64 values in any of my drafts, so small or not makes no = difference... > =3D=3D NITS =3D=3D > In section 3, "This module is defines independently" ? Good catch: s/defines/defined/ Kent From nobody Tue Dec 14 05:23:29 2021 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 4B1093A0C52; Tue, 14 Dec 2021 05:23:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Zaheduzzaman Sarker via Datatracker To: "The IESG" Cc: draft-ietf-netconf-sztp-csr@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, mjethanandani@gmail.com, mjethanandani@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Zaheduzzaman Sarker Message-ID: <163948820661.12873.16286675430659744022@ietfa.amsl.com> Date: Tue, 14 Dec 2021 05:23:27 -0800 Archived-At: Subject: [netconf] Zaheduzzaman Sarker's Discuss on draft-ietf-netconf-sztp-csr-12: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 13:23:28 -0000 Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-netconf-sztp-csr-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would like to discuss two points - - as this specification add more detailed response for HTTP 400 Bad Request error code. I would like to know if RFC7807 has been considered for such usage. - is this specification defining new media type "application/yang.data+json"? and would ask why? It could very well use "application/problem+json" or "application/problem+xml" from RFC7807 or even "application/yang-data+json". ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work on this document. From nobody Tue Dec 14 15:25:40 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3233A0C02 for ; Tue, 14 Dec 2021 15:25:30 -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, 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.20210112.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 yM7eRmGFbwHs for ; Tue, 14 Dec 2021 15:25:25 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AED73A0C19 for ; Tue, 14 Dec 2021 15:25:25 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id l7so30687250lja.2 for ; Tue, 14 Dec 2021 15:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=9U8uLB6VuBSADOM4SPUZrjGdzY3gaqT5kVD2CM0JDGU=; b=ho7A9pC+QakkPAVnibkJsSF9j2zERGJ1Fr4IHbdsQxS84NjddPkO1vFB1BagFQw9p+ lGGvsj4+bVeFpQ37YeoTWsDfBs7my04ZPOp5GD0pYGEccnuJUXuEelL1f3+0OZQmuxzR 0A+AkkOCakSZBfiYGfRi+2ZpNrYK3E2pUIrOjaFkUfogk8/GKfyqex2SzXEWMkvD3IZb xtuXiNEbm5YnydYsvT8jyl6uIr7itHbugKNiT83ODckZQZlP483gpp1vB8GEtSSl/FOg id5X2ywlyiZj5cQOyvt/8dCHwQgWsWpa6XdOempDnr/bdcBctrIZpFAp0p5e3JEcXGJe gASQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9U8uLB6VuBSADOM4SPUZrjGdzY3gaqT5kVD2CM0JDGU=; b=YJBMGBervnZe8WxRfowxSYEx/HDI7hwpOk7a872N5q+UVnyzayIt7hur0ieGGVa1Y7 RSQyw6KCxuFLBykhA1Sh9TJUBQEPBPE+jc1XAGre8PoksSEy5IiwWQ8tEd/k6VickrM+ JTK5KC56W7unBx+sTcFdqeCoC3cFqxrR4yuJF/CYWHwdeBKp3A8e/a6Q8QlZAG2goA0s TgvcwbHjVOpfdoJPTwNMvfnIzNbfiRCqub+Kue2UwuiAbGm8pR4JeMNt7VBi2BpVLwyU JUYOsDRJnsY2nxmpu9kHq2I32i0fN37/flRY9laWQe3ujrV2JNe6agiMrqfxIySGLS+q +3BA== X-Gm-Message-State: AOAM533r/xgRF8xVsjFXLCLieFXLGvxR5YcYS41gGXw/L6MzHpxpuCXF 7K4+U+HQivOOVjnXTHTcpJDm45O3PBRhS5hIRLHu9tZ2imky5Wa9 X-Google-Smtp-Source: ABdhPJyXNLbijbbmsGZ7np/Lks3p5ru/8FNSNccIRP3x0nflUkczrJXigBQ21PKqh+l5SKozqMCq+OxhvdKg4Qwd7BM= X-Received: by 2002:a05:651c:1a29:: with SMTP id by41mr1962431ljb.144.1639524321309; Tue, 14 Dec 2021 15:25:21 -0800 (PST) MIME-Version: 1.0 From: Andy Bierman Date: Tue, 14 Dec 2021 15:25:10 -0800 Message-ID: To: Netconf Content-Type: multipart/alternative; boundary="000000000000c5d3bc05d3238090" Archived-At: Subject: [netconf] missing drafts on datatracker 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 Dec 2021 23:25:39 -0000 --000000000000c5d3bc05d3238090 Content-Type: text/plain; charset="UTF-8" Hi, The WG datastracker used to have more client/server drafts. Looks like they expired and were taken off the datatracker These drafts are still on the datatracker: draft-ietf-netconf-crypt-types-21 draft-ietf-netconf-ssh-client-server-25 draft-ietf-netconf-tls-client-server-25 These drafts are not on the NETCONF WG datatracker: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-22 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-15 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-07 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-23 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-23 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server-10 What is the ETA for publication of these drafts as RFCs? thanks, Andy --000000000000c5d3bc05d3238090 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The WG datastracker used to hav= e more client/server drafts.
Looks like they expired and were tak= en off the datatracker

These drafts are still on t= he datatracker:

draft-ietf-netconf-crypt-types-21<= /div>
draft-ietf-netconf-ssh-client-server-25
draft-ietf-netc= onf-tls-client-server-25

These drafts are not = on the NETCONF WG datatracker:

<= a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-an= chors-15">https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-an= chors-15
=

What is the ETA for= publication of these drafts as RFCs?

thanks,
Andy

--000000000000c5d3bc05d3238090-- From nobody Tue Dec 14 15:47:54 2021 Return-Path: <0100017dbb584922-aeaace01-ca0f-402c-a25e-bf9e4fc9ad76-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 E8D0F3A0C08 for ; Tue, 14 Dec 2021 15:47:51 -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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 R22-i8EvapIW for ; Tue, 14 Dec 2021 15:47: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 7AD743A0C00 for ; Tue, 14 Dec 2021 15:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639525665; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=TOB6Jjy/w/v8McTi5tiXBRLniFdwQoedq5n089r9y6k=; b=XaD7dXjiXrThzXLb33vvmQAOwO2ClFNHm+TH53cv3XC11Ge0GiQkk50p8HRHr3+c B4nTLORcanqwrMarXVLhTh/ZFsonGVhRItfq7DfPZ+lnv3sg3ZC/qDvzd1YvyNU7xR6 QsD1E42WqZTsVFJ7+mZ3apQMoQvO4lkshanpE/k8= From: Kent Watsen Message-ID: <0100017dbb584922-aeaace01-ca0f-402c-a25e-bf9e4fc9ad76-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6AC0C1F8-1022-434C-B5F2-8F7CF6339911" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 14 Dec 2021 23:47:45 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: Andy Bierman References: X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.14-54.240.48.90 Archived-At: Subject: Re: [netconf] missing drafts on datatracker 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 Dec 2021 23:47:52 -0000 --Apple-Mail=_6AC0C1F8-1022-434C-B5F2-8F7CF6339911 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Andy, > On Dec 14, 2021, at 6:25 PM, Andy Bierman wrote: >=20 > Hi, >=20 > The WG datastracker used to have more client/server drafts. > Looks like they expired and were taken off the datatracker Correct, some of the I-Ds we WGLC=E2=80=99ed first are expiring now. = Recall we broke up the LC-reviews into 3 tranches. As author, I = should=E2=80=99ve posted an update to avoid the optics, but didn=E2=80=99t= because it doesn=E2=80=99t make a difference to the publishing process, = AFAICT. In either case, I will post an update for the entire suite of = drafts later tonight to clear this issue. >=20 > These drafts are still on the datatracker: >=20 > draft-ietf-netconf-crypt-types-21 > draft-ietf-netconf-ssh-client-server-25 > draft-ietf-netconf-tls-client-server-25 >=20 > These drafts are not on the NETCONF WG datatracker: >=20 > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-22 = > = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-15 = > = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-serve= r-07 = > = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-se= rver-23 = > = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-s= erver-23 = > = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server= -10 = >=20 > What is the ETA for publication of these drafts as RFCs? As coincidence would have it, the BBF expressed eagerness (offline) to = see these drafts published quickly and a resource has reached out to me = to help bang out the last few items=E2=80=A6hopefully in the next couple = weeks! Then it will be Shepherd write-ups ---> AD review ---> IESG = review ---> RFC Editor review. All in all, I=E2=80=99d guess late-Q1 = to early-Q2. = **************************************************************************= ******************************************* CAN ANYONE VOLUNTEER TO DO THE SHEPHERD WRITEUP FOR SOME OF THESE = DRAFTS?! =20 NOTE: DOING A SHEPHERD WRITEUP IS GOOD PRACTICE TOWARDS BECOMING A WG = CHAIR. =20 THE IETF IS LOOKING TO PROMOTE MORE FOLKS INTO LEADERSHIP POSITIONS,=20 SO ***PLEASE*** VOLUNTEER IF INTERESTED! IF NO ONE VOLUNTEERS, THEN MAHESH WILL HAVE TO DO ALL BY HIMSELF (AS I = HAVE TO RECUSE MYSELF), WHICH MAY TAKE WHILE... = **************************************************************************= ******************************************* >=20 > thanks, > Andy Kent // many hats --Apple-Mail=_6AC0C1F8-1022-434C-B5F2-8F7CF6339911 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Andy,



On Dec 14, 2021, at 6:25 PM, Andy Bierman <andy@yumaworks.com> = wrote:

Hi,

The WG datastracker used to have more = client/server drafts.
Looks like they expired and = were taken off the datatracker

Correct, some of the I-Ds we WGLC=E2=80=99ed first = are expiring now.  Recall we broke up the LC-reviews into 3 = tranches.  As author, I should=E2=80=99ve posted an update to avoid = the optics, but didn=E2=80=99t because it doesn=E2=80=99t make a = difference to the publishing process, AFAICT.  In either case, I = will post an update for the entire suite of drafts later tonight to = clear this issue.

These drafts are still on the = datatracker:

draft-ietf-netconf-crypt-types-21
draft-ietf-netconf-ssh-client-server-25
draft-ietf-netconf-tls-client-server-25

These drafts are not on the NETCONF WG datatracker:

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keysto= re-22
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-= anchors-15
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-c= lient-server-07
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netcon= f-client-server-23
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restco= nf-client-server-23
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-cl= ient-server-10

What is the ETA for publication of = these drafts as RFCs?

As coincidence would have it, the BBF expressed = eagerness (offline) to see these drafts published quickly and a resource = has reached out to me to help bang out the last few items=E2=80=A6hopefull= y in the next couple weeks!   Then it will be Shepherd write-ups = ---> AD review ---> IESG review ---> RFC Editor review.   All in all, = I=E2=80=99d guess late-Q1 to early-Q2.


*********************************************************************************************************************
CAN ANYONE = VOLUNTEER TO DO THE SHEPHERD WRITEUP FOR SOME OF THESE DRAFTS?! =   

NOTE:= DOING A SHEPHERD WRITEUP IS GOOD PRACTICE TOWARDS BECOMING A WG CHAIR. =  

THE = IETF IS LOOKING TO PROMOTE MORE FOLKS INTO LEADERSHIP = POSITIONS, 
SO ***PLEASE*** VOLUNTEER IF = INTERESTED!

IF NO ONE VOLUNTEERS, THEN MAHESH WILL HAVE TO DO ALL BY = HIMSELF (AS I HAVE TO
RECUSE MYSELF), WHICH MAY = TAKE WHILE...
*********************************************************************************************************************



thanks,
Andy

Kent  // many hats




= --Apple-Mail=_6AC0C1F8-1022-434C-B5F2-8F7CF6339911-- From nobody Tue Dec 14 16:10:02 2021 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 C9A623A0C39; Tue, 14 Dec 2021 16:09:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-netconf-sztp-csr@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, mjethanandani@gmail.com, mjethanandani@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <163952699208.6437.8936066509149136808@ietfa.amsl.com> Date: Tue, 14 Dec 2021 16:09:52 -0800 Archived-At: Subject: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 00:09:58 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-netconf-sztp-csr-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document; it seems useful to have the flexibility to specify a CSR and get an LDevID during enrollment. I had a similar concern as Zahed's Discuss point (though I'm not sure I can really express my concerns very well yet), and will attempt to follow the discussion thereof. Section 2.1 Why do we need the "sztp-csr" namespace prefix on the new nodes in the get-bootstrapping-data example, but not need the "ietf-sztp-csr" prefix on the nodes in the ietf-restconf/errors example? Section 2.3 description "Provides the CSR generated by the SZTP-client. When present, the SZTP-server SHOULD respond with an SZTP onboarding information message containing a signed certificate for the conveyed CSR. The SZTP-server MAY alternatively respond with another HTTP error containing another 'csr-request', in which case the SZTP-client MUST invalidate the previously generated CSR."; I'm curious what is intended by "invalidate the [...] CSR". My background on CSR usage hasn't really encountered a sense of "validity" for them that would need cancellation, since it's not really a important piece of information in its on right (just a way to ask a CA to do something). The interesting bit is whether the CA actually issued anything, but I'm not sure how much harm a stale CSR would actually cause. Section 3.2 identity cmp-csr { base certificate-request-format; description "Indicates that the ZTP-client supports generating requests using a constrained version of the PKIMessage containing a p10cr structure defined in RFC 4210."; I'd probably spend a few more words to indicate the nature of the constraints that cause us to say "constrained version". (Likewise for the cmc-csr.) Enables the ZTP-server to provide a fully-populated CertificationRequestInfo structure that the ZTP-client only needs to sign in order to generate the complete 'CertificationRequest' structure to send to ZTP-server in its next 'get-bootstrapping-data' request message. When provided, the ZTP-client SHOULD use this structure to generate its CSR; failure to do so MAY result in a 400 Bad Request response containing another 'csr-request' structure. This guidance seems to risk running afoul of the first rule of PKIs: know what you sign. While I understand that the context for this protocol exchange is a relatively "dumb" device getting onboarded into the owner's deployment, and that the owner may in fact require some things in the LDevID that were not coded into the device by its implementors, I don't think we should stand mute on the security considerations of asking for a certificate that contains attributes/restrictions/etc. that are not understood. leaf cmc-csr { type binary; description "A constrained version of the 'Full PKI Request' message defined in RFC 5272, encoded using ASN.1 (Same comment about "constrained version" as above.) For asymmetric key-based origin authentication based on the initial device identity certificate's private key that signs the encapsulated CSR signed by the local device identity certificate's private key, the PKIData contains one cmsSequence element and no otherMsgSequence element. The cmsSequence is the This part says nothing about whether there is a reqSequence element in the toplevel PKIData... TaggedContentInfo and it includes a bodyPartID element and a contentInfo. The contentInfo is a SignedData encapsulating a PKIData with one reqSequence element and no cmsSequence or otherMsgSequence elements. The reqSequence is the TaggedRequest and it is the tcr CHOICE. The tcr is the TaggedCertificationRequest and it a bodyPartId and the certificateRequest elements. [...] ... since this reqSequence seems to refer to the PKIData inside the SignedData in the contentInfo in the cmsSequence. Should we say anything about the presence/absence of reqSequence in the toplevel PKIData (since we do in the other two cases)? case cmp-csr { leaf cmp-csr { type binary; description [...] For asymmetric key-based origin authentication of a CSR based on the initial device identity certificate's private key for the associated initial device identity certificate's public key, PKIMessages contains one PKIMessage with the header and body elements, no protection element, and should contain the extraCerts element. [...] Is this a "should" or a "SHOULD"? For asymmetric key-based origin authentication based on the initial device identity certificate's private key that signs the encapsulated CSR signed by the local device identity certificate's private key, PKIMessages contains one PKIMessage with the header, body, and protection elements, and should contain the extraCerts element. [...] (ditto) Section 4 I'd consider also mentioning the CMC, CMP, and PKCS#10 security considerations as being applicable to the relevant CSR choices. Section 4.1.1 The security of this private key is essential in order to ensure the associated identity certificate can be used as a root of trust. "root of trust" is something of a loaded term (see the ongoing discussion in the RATS WG for differing interpretations of what it means). I'd suggest using a different phrasing, like "can be used to authenticate the device it is issued to". Section 4.1.3 Should we mention the "nonce" parameter to get-bootstrapping-data here? When a public/private key pair associated with the manufacturer- generated identity certificate (e.g., IDevID) is used for the request, there may not be confirmation to the SZTP-client that the response has not been replayed; however, the worst case result is a lost certificate that is associated to the private key known only to the SZTP-client. That's only the worse-case result if we assume that the private key is not compromised. We might want to reiterate that assumption and/or mention the scope of consequences for the case where the private key is compromised. Section 4.2.2 When a new asymmetric key is used, with the CMP or CMC formats, the parent ASN.1 structure of the CSR provides origin authentication using either the manufacturer-generated private key or a shared secret. In this way the proof-of-possession of the CSR is directly linked to the proof-or-origin provided by the parent ASN.1 structure. I think this section would be a good place to talk about how in the "raw PKCS#10" case, there needs to be a level of trust in the bootstrapping server roughly analogous to how an RA would be trusted, in that they are the only entity that has verified the client identity and the bootstrapping server's assertion of the client identity is a key step in the certificate issuance process. Such discussion might also contrast use of the IDevID at the TLS layer with HTTP-layer authentication of the client. Section 4.4 Though our "identity" and "grouping" statements (as noted) to not appear in any protocol-accessible nodes as-is, we might still feel empowered to discuss any considerations that would apply when they actually are instantiated in other modules. However, it seems that there would not be anything new to say other than what's in RFCs 2986, 4210, and 5272, and if we take my suggestion to reference them from the toplevel section 4, there would be no need to do so again here. NITS Abstract, Introduction I'd consider clarifying that when we "extend" the get-bootstrapping-data RPC to include a CSR, that's as the input to the RPC, not the output. (I initially misread it when reading the abstract.) Section 2.2 You may want to use more-recent dates than 2015 for the examples. I suggest using different "BASE64VALUE="s for the different public keys in the two-asymmetric-key example. Section 3.2 leaf-list algorithm-identifier { type binary; min-elements 1; description "An AlgorithmIdentifier, as defined in RFC 2986, encoded using ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690."; At risk of excessive pedanticism, I see RFC 2986 discuss the parametrized AlgorithmIdentifier{}, which compares it to the unparameterized AlgorithmIdentifier in the ensuing discussion. AlgorithmIdentifier is (also) defined in, e.g., RFC 5280 if we didn't want to get into the parameterization here. (Any change made here should be made throughout, of course.) grouping csr-grouping { description "Enables a ZTP-client to convey a certificate signing request, using the encoding format selected by a ZTP-server's 'csr-request' response to the ZTP-client's previously sent 'get-bootstrapping-data' request containing the 'csr-support' node."; (nit) Since we're (now) in just the ztp-types module, we can't necessarily assume there will be a "get-bootstrapping-data" request involved. For asymmetric key-based origin authentication of a CSR based on the initial device identity certificate's private key for the associated identity certificate's public key, the PKIData contains one reqSequence (nit) I think the "associated identity certificate's public key" phrasing here is a bit confusing. I think that we're trying to cover the case where the key from the IDevID is reused for the LDevID, so we're using the LDevID private key to authenticate the CSR and it's sigining "it's own" public key", but in the context of this YANG grouping we've mostly lost the context of the "associated identity certificate". (A similar comment applies to the CMP case.) elements. The reqSequence is the TaggedRequest and it is the tcr CHOICE. The tcr is the (nit) should we have another word after "CHOICE", like "arm" or "branch"? TaggedCertificationRequest and it a bodyPartId and the (nit) also, I'd maybe s/the/a/ for these two "the is the " constructions since they seem to just be describing the type of a given ASN.1 element. Also, s/it/it is/. Section 4.1.1 private keys. For instance, an NMS controller/orchestrator application could periodically prompt the SZTP-client to generate a new private key and provide a certificate signing request (CSR) or, alternatively, push both the key and an identity certificate to the SZTP-client using, e.g., a PKCS #12 [RFC7292]. [...] maybe "a PKCS #12 message"? Section 4.1.5 The CMP and CMC certificate request formats defined in this document support origin authentication. A raw PKCS#10 does not support origin authentication. "PKCS#10 CSR" From nobody Tue Dec 14 16:11:34 2021 Return-Path: <0100017dbb6de6a8-503b8aaa-031f-4c2c-bca4-79eaec0fbff7-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 774F73A0C39; Tue, 14 Dec 2021 16:11:31 -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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 9m_dh4zinAyI; Tue, 14 Dec 2021 16:11:27 -0800 (PST) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E453A0C6F; Tue, 14 Dec 2021 16:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639527081; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=yghD45HI+eM5lnl3O55tgccYECQnX07CY7PgkidphSs=; b=WpY4vo1mU6m08Il7wKpEzD3/DgA6ufrkAqYXVAzg93n2UfqLB1v1u33t2+5m4AUP XOmILYxDV3N9CU8VO1Ksl6WsDQqkPU7Mp1Oz2dUZeUJ4tZq8p+oJ0amF4L0sF8sJGw+ loGqn3s2NTlQZSkTMcZa24RMwXiMrFbp0aO2FM9g= From: Kent Watsen Message-ID: <0100017dbb6de6a8-503b8aaa-031f-4c2c-bca4-79eaec0fbff7-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8C6A2561-46A6-4E18-854F-79A23D5E2D34" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Wed, 15 Dec 2021 00:11:21 +0000 In-Reply-To: <163948820661.12873.16286675430659744022@ietfa.amsl.com> Cc: The IESG , draft-ietf-netconf-sztp-csr@ietf.org, "netconf-chairs@ietf.org" , "netconf@ietf.org" To: Zaheduzzaman Sarker References: <163948820661.12873.16286675430659744022@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.15-54.240.48.93 Archived-At: Subject: Re: [netconf] Zaheduzzaman Sarker's Discuss on draft-ietf-netconf-sztp-csr-12: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 00:11:32 -0000 --Apple-Mail=_8C6A2561-46A6-4E18-854F-79A23D5E2D34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Zaheduzzaman, Thank you for your review! Responses to your comments are below. Kent // as a co-author > On Dec 14, 2021, at 8:23 AM, Zaheduzzaman Sarker via Datatracker = wrote: >=20 > Zaheduzzaman Sarker has entered the following ballot position for > draft-ietf-netconf-sztp-csr-12: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I would like to discuss two points - >=20 > - as this specification add more detailed response for HTTP 400 Bad = Request > error code. I would like to know if RFC7807 has been considered for = such > usage. The authors did not know about RFC 7807. Thank you for bringing it to = our attention. Looking at RFC 7807, we do not believe that we should use it because: - an SZTP-server (RFC 8572) is a RESTCONF-server (RFC 8040) - RESTCONF defines it=E2=80=99s own mechanism for structure responses https://datatracker.ietf.org/doc/html/rfc8040#section-7.1. This comment would have been good when RFC 8040 was being published, but now it is water over the bridge, so to speak. Agreed? > - is this specification defining new media type = "application/yang.data+json"? > and would ask why? It could very well use "application/problem+json" = or > "application/problem+xml" from RFC7807 or even = "application/yang-data+json". Aye! This is a typo. It should be "application/yang-data+json=E2=80=9D,= which is defined In RFC 8040 here: = https://datatracker.ietf.org/doc/html/rfc8040#section-11.3.2 = . I have fixed this typo here: = https://github.com/netconf-wg/sztp-csr/commit/7d62548f36b2bc325533c6d6a362= 900badc5301b = An I-D update is pending a few more IESG-reviews. Good? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for the work on this document. Thank you! K. --Apple-Mail=_8C6A2561-46A6-4E18-854F-79A23D5E2D34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Zaheduzzaman,

Thank you = for your review!  Responses to your comments are below.

Kent // as a = co-author


On Dec 14, 2021, at 8:23 AM, Zaheduzzaman Sarker via = Datatracker <noreply@ietf.org> wrote:

Zaheduzzaman Sarker has entered the following ballot position = for
draft-ietf-netconf-sztp-csr-12: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/for more information about how to handle DISCUSS and = COMMENT positions.


The = document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

I would like to discuss two points = -

 - as this specification add more = detailed response for HTTP 400 Bad Request
 error = code. I would like to know if RFC7807 has been considered for such
 usage.


The authors did not know = about RFC 7807.  Thank you for bringing it to = our attention.


This = comment would have been good when RFC 8040 = was being published, but
now it is water over the = bridge, so to speak.  Agreed?


 - is = this specification defining new media type = "application/yang.data+json"?
 and would ask why? It = could very well use "application/problem+json" or
=  "application/problem+xml" from RFC7807 or even = "application/yang-data+json".

Aye! =  This is a typo.   It should be = "application/yang-data+json=E2=80=9D, which is defined


An I-D update = is pending a few more IESG-reviews.

Good?



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Thanks for the work on this = document.

Thank you!


K.



= --Apple-Mail=_8C6A2561-46A6-4E18-854F-79A23D5E2D34-- From nobody Tue Dec 14 17:37:38 2021 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 B44BB3A0D6C; Tue, 14 Dec 2021 17:37:30 -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: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <163953225066.16614.11256878331228381042@ietfa.amsl.com> Date: Tue, 14 Dec 2021 17:37:30 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-16.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: Wed, 15 Dec 2021 01:37:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : A YANG Data Model for a Truststore Author : Kent Watsen Filename : draft-ietf-netconf-trust-anchors-16.txt Pages : 39 Date : 2021-12-14 Abstract: This document defines a YANG module for configuring bags of certificates and bags of public keys that can be referenced by other data models for trust. Notifications are sent when certificates are about to expire. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2021-12-14 --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-trust-anchors-16.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-trust-anchors-16 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Dec 14 17:39:14 2021 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 5A2013A0CF3; Tue, 14 Dec 2021 17:39:13 -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: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <163953235332.14304.738684703470198970@ietfa.amsl.com> Date: Tue, 14 Dec 2021 17:39:13 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-keystore-23.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 01:39:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : A YANG Data Model for a Keystore Author : Kent Watsen Filename : draft-ietf-netconf-keystore-23.txt Pages : 50 Date : 2021-12-14 Abstract: This document defines a YANG module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted or hidden. Asymmetric keys may be associated with certificates. Notifications are sent when certificates are about to expire. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * CCCC --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2021-12-14 --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-keystore-23.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-23 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Dec 14 17:40:47 2021 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 9F7463A0D6D; Tue, 14 Dec 2021 17:40:40 -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: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <163953244060.20061.642436508134882672@ietfa.amsl.com> Date: Tue, 14 Dec 2021 17:40:40 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-11.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 01:40:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for TCP Clients and TCP Servers Authors : Kent Watsen Michael Scharf Filename : draft-ietf-netconf-tcp-client-server-11.txt Pages : 34 Date : 2021-12-14 Abstract: This document defines three YANG 1.1 modules to support the configuration of TCP clients and TCP servers. The modules include basic parameters of a TCP connection relevant for client or server applications, as well as client configuration required for traversing proxies. The modules can be used either standalone or in conjunction with configuration of other stack protocol layers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-tcp-client-server-11.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tcp-client-server-11 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Dec 14 17:42:58 2021 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 524D23A0D6B; Tue, 14 Dec 2021 17:42:56 -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: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <163953257627.17555.4326244017800303722@ietfa.amsl.com> Date: Tue, 14 Dec 2021 17:42:56 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-ssh-client-server-26.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: Wed, 15 Dec 2021 01:42:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for SSH Clients and SSH Servers Author : Kent Watsen Filename : draft-ietf-netconf-ssh-client-server-26.txt Pages : 134 Date : 2021-12-14 Abstract: This document defines three YANG 1.1 modules: the first defines features and groupings common to both SSH clients and SSH servers, the second defines a grouping for a generic SSH client, and the third defines a grouping for a generic SSH server. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2021-12-14 --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix B. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-ssh-client-server-26.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-26 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Dec 14 17:48:03 2021 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 185EE3A0D77; Tue, 14 Dec 2021 17:47:58 -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: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <163953287804.15823.5927076303291288667@ietfa.amsl.com> Date: Tue, 14 Dec 2021 17:47:58 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-26.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: Wed, 15 Dec 2021 01:47:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for TLS Clients and TLS Servers Author : Kent Watsen Filename : draft-ietf-netconf-tls-client-server-26.txt Pages : 139 Date : 2021-12-14 Abstract: This document defines three YANG 1.1 modules: the first defines features and groupings common to both TLS clients and TLS servers, the second defines a grouping for a generic TLS client, and the third defines a grouping for a generic TLS server. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * FFFF --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2021-12-14 --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix B. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-tls-client-server-26.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tls-client-server-26 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Dec 14 17:49:07 2021 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 56F103A0D77; Tue, 14 Dec 2021 17:49:05 -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: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <163953294529.21495.4146909377983752081@ietfa.amsl.com> Date: Tue, 14 Dec 2021 17:49:05 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-http-client-server-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 01:49:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for HTTP Clients and HTTP Servers Author : Kent Watsen Filename : draft-ietf-netconf-http-client-server-08.txt Pages : 31 Date : 2021-12-14 Abstract: This document defines two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2021-12-14 --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-http-client-server/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-http-client-server-08.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-http-client-server-08 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Dec 14 17:50:26 2021 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 619E23A0D84; Tue, 14 Dec 2021 17:50:24 -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: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <163953302434.20061.11500016207346630219@ietfa.amsl.com> Date: Tue, 14 Dec 2021 17:50:24 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-client-server-24.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 01:50:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : NETCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-netconf-client-server-24.txt Pages : 60 Date : 2021-12-14 Abstract: This document defines two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2021-12-14 --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-netconf-client-server-24.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-client-server-24 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Dec 14 17:52:09 2021 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 2BB2D3A0D76; Tue, 14 Dec 2021 17:52:03 -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: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <163953312313.10872.2117169278352312627@ietfa.amsl.com> Date: Tue, 14 Dec 2021 17:52:03 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-restconf-client-server-24.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 01:52:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : RESTCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-restconf-client-server-24.txt Pages : 55 Date : 2021-12-14 Abstract: This document defines two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * IIII --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2021-12-14 --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-restconf-client-server-24.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-client-server-24 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Dec 15 11:41:37 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DB53A046E for ; Wed, 15 Dec 2021 11:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHXuCmTqPd1u for ; Wed, 15 Dec 2021 11:41:23 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 C9A123A08F9 for ; Wed, 15 Dec 2021 11:41:23 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id z18so31880944iof.5 for ; Wed, 15 Dec 2021 11:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0xAr+RmphxYysU02UOc6ZNiAWeUETk+kEBfK/aBxLmQ=; b=ZIQv4L2Gzlwz0KO5Kr1YChSqFUdrwMbLRPisu/+rN/ekQlnahaVwV1fYeFC/NX1bf0 9okw6Uvzm1XTg5oBt0+bQgFgLvVroAQS+kyiD859KotQ6a/RfjWHoQ6qXidsLkjMzQGi faLdFokvnw1SEzCiTT1R/vJ+7beWWMNtm88N2YAgpMTuPgN+SE6WpStS8r+PWolpfM+q 2O34Au7TcDhdocEB5tX/ubzsrDlbyaDpMbDdmiqe7Hk+fJ7q+shTpJPDoAmHz6nbH+0Q EM/gQKNc2ZXHTrT8YLyVNkO/1zVwPsgMQ5ZchJ1c4Qh5arZBYJ8uiLFvSM8rAazlRX3V wI7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0xAr+RmphxYysU02UOc6ZNiAWeUETk+kEBfK/aBxLmQ=; b=P79ZcIWqiHisnKmE+inMrRgiCwQR1iBQlv0KvEmspaNLH6lGAM0RKhGG51KMG/iYNj 4ONjAdqd8w0UxEPszF68+sENBHdY+/YtmY3jH8lSQNr0eNsNv01yexIz9n7CjGltysbU flmY/vIWtxMqYMJa23wuF6uVfU/wAHS2Y4xVrQbIl/P6ABMvnlUef1pi/n1F4yLZmzQi 5Z3ZrwVAVjO//EuTFIJwxmNE9N4cpxL5ACpdyhGUjI3c+FWxSltKVNhnh9HsNZRWC1L/ kxV+MmzZb5FQhbJVWg5CaqyDkLVdNyxu+Aq+qKYfRZHhDRJxjgaWmzzdf9tQvABqJ0vv 4I3w== X-Gm-Message-State: AOAM533Vd0WNhnpeqnnqWjOIke0eLWniw0UgaAexyiUgxKWUZ9VdVNON AQvSYlcyXdEFCFw4VllMJBzAzv+CQIV7pG99sIBLXw== X-Google-Smtp-Source: ABdhPJwcWGlaS/CVJbVxtlup+GjvyBMjmfGkh71JH93qe1MyIqq/zKmot1N6GCbC4XKOeS4h+WbZYPbwE0BKPNDYT3s= X-Received: by 2002:a6b:2cc1:: with SMTP id s184mr7467668ios.63.1639597281254; Wed, 15 Dec 2021 11:41:21 -0800 (PST) MIME-Version: 1.0 References: <163733688535.10662.12846915795187697217@ietfa.amsl.com> <0100017d487f0f15-c299535d-2006-4dde-9b36-4799849666c0-000000@email.amazonses.com> <0100017d4d608976-11759577-0c2e-4efb-bc34-3da1d8ad2bcb-000000@email.amazonses.com> In-Reply-To: <0100017d4d608976-11759577-0c2e-4efb-bc34-3da1d8ad2bcb-000000@email.amazonses.com> From: Warren Kumari Date: Wed, 15 Dec 2021 14:40:45 -0500 Message-ID: To: Kent Watsen Cc: "Rob Wilton (rwilton)" , Dan Romascanu , "last-call@ietf.org" , "ops-dir@ietf.org" , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008635ca05d3347d9f" Archived-At: Subject: Re: [netconf] [Last-Call] Opsdir last call review of draft-ietf-netconf-sztp-csr-11 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 Dec 2021 19:41:29 -0000 --0000000000008635ca05d3347d9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just a quick note to say thanks to the Dan, the authors and Rob -- this has improved the document. W On Tue, Nov 23, 2021 at 10:18 AM Kent Watsen wrote: > Hi Rob, > > Thank you for your input. Please see below for responses to your comment= s. > > Kent > > > > Which option seems best? Does anyone have. preference? > > I don=E2=80=99t think that we should do (1). If the industry widely unde= rstands > IDevID/LDevID to mean 802.1AR then redefining it in this draft to have a > wider meaning could just be confusing to readers. > > > Agreed. > > > So I think that the draft has broadly got this right in its current > approach, but I would propose also extending that to the YANG module > descriptions. > > > Agreed. > > > > Specifically, I would suggest adding a version of this paragraph to the > end of the descriptions of cmc-csr and cmp-csr, which already have quite > long descriptions, so the extra paragraph shouldn=E2=80=99t really be a p= roblem. > > > The terms 'IDevID' and 'LDevID' are used herein to > > mean 'initial device identifier' and 'local device > > identifer'. These terms are defined consistent with > > the IEEE 802.1AR specification, though there is no > > requirement that a ZTP-client's identity certificate > > conform to IEEE 802.1AR. > > > > Yikes! After sending the response to Dan, I decided on option 2 > (expanding all the IDevID/LDevID usages). In my response to Yaron > yesterday I wrote: > > We updated the YANG module to greatly remove references to IDevID/LDevID. > > Specifically: > 1) s/IDevID/initial device identity certificate/g > 2) s/LDevID/local device identity certificate/g > 3) manually rewrap lines to col 69 as required > 4) removed the terminology-disclaimer block at top > > The diff is here: > https://github.com/netconf-wg/sztp-csr/commit/ac35f96eec96528dddf5798d528= d9874a85c604b > > Good? > > This isn=E2=80=99t what you suggest, but it=E2=80=99s quite good, maybe b= etter? Your > approach seems like it would=E2=80=99ve been more convenient but, given t= hat it is > what it is now, are you okay with the current edit? [PS: I haven=E2=80= =99t posted > an updated draft yet as I=E2=80=99m waiting to complete the reviews with = Yaron and > Dan first] > > > I would suggest changing the description in cert-req-info to =E2=80=9C(e.= g., an > IDevID from IEEE 802.1AR)=E2=80=9D > > > > Done! > https://github.com/netconf-wg/sztp-csr/commit/45ace9b40eedabb84e10607592d= 29146cb54a9c9 > > > Rob > > > K. > > > > > > --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra --0000000000008635ca05d3347d9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just a quick note to say thanks to the Dan, the authors an= d Rob -- this has improved the document.
W

On Tue, Nov 23, 2021 at= 10:18 AM Kent Watsen <kent@watsen.ne= t> wrote:
Hi Rob,

Thank= you for your input.=C2=A0 Please see below for responses to your comments.=

Kent


<= blockquote type=3D"cite">

= Which option seems best?=C2=A0 Does anyone have. preference?<= /div>
=C2=A0
I don=E2=80=99t think that= we should do (1).=C2=A0 If the industry widely understands IDevID/LDevID t= o mean 802.1AR then redefining it in this draft to have a wider meaning cou= ld just be confusing to readers.
=

Agreed.


So I think that the dr= aft has broadly got this right in its current approach, but I would propose= also extending that to the YANG module descriptions.

Agreed.

=C2=A0
Specifically, I would s= uggest adding a version of this paragraph to the end of the descriptions of= cmc-csr and cmp-csr, which already have quite long descriptions, so the ex= tra paragraph shouldn=E2=80=99t really be a problem.
=C2=A0

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The terms 'IDevID' and 'LDevID&#= 39; are used herein to

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mean 'initial device identifier= ' and 'local device

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identifer'.=C2=A0 These term= s are defined consistent with

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 requirement that a ZTP-client's= identity certificate

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 conform to IEEE 802.1AR.<= /u>


=

Yikes! =C2=A0 After sending the response to Dan,=C2=A0<= span style=3D"color:rgb(0,0,0)">I decided on option 2 (expanding all the ID= evID/LDevID usages).=C2=A0 In my response to Yaron yesterday I wrote:

We = updated the YANG module to greatly remove references to IDevID/LDevID.
<= br> Specifically:
1) s/IDevID/initial device identity cer= tificate/g
2)=C2=A0s/LDevI= D/local device identity certificate/g
3) manually rewrap lines to col 69 as required
4) removed the terminology-disclaimer bl= ock at top

The diff is = here:=C2=A0https://github.com/net= conf-wg/sztp-csr/commit/ac35f96eec96528dddf5798d528d9874a85c604b
Good?

This = isn=E2=80=99t what you suggest, but it=E2=80=99s quite good, maybe better? = =C2=A0 Your approach seems like it would=E2=80=99ve been more convenient bu= t, given that it is what it is now, are you okay with the current edit? =C2= =A0[PS: I haven=E2=80=99t posted an updated draft yet as I=E2=80=99m waitin= g to complete the reviews with Yaron and Dan first]

=C2=A0
I would suggest changing the description in cert-req-info to =E2=80=9C(= e.g., an IDevID from IEEE 802.1AR)=E2=80=9D


Done!=C2=A0https://github.com/netconf-wg/sztp-csr/commit/45ace9b40e= edabb84e10607592d29146cb54a9c9


Rob=

K.





<= /div>

--
The computing scientist=E2= =80=99s main challenge is not to get confused by the
complexities of his= own making.
=C2=A0 -- E. W. Dijkstra
--0000000000008635ca05d3347d9f-- From nobody Wed Dec 15 11:42:48 2021 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 12D6C3A0A62; Wed, 15 Dec 2021 11:42:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-netconf-sztp-csr@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, mjethanandani@gmail.com, mjethanandani@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <163959735420.32477.10309110443759504502@ietfa.amsl.com> Date: Wed, 15 Dec 2021 11:42:35 -0800 Archived-At: Subject: [netconf] Warren Kumari's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 19:42:43 -0000 Warren Kumari has entered the following ballot position for draft-ietf-netconf-sztp-csr-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A quick note to say thanks to the WG for this document, and also to Dan, Rob, the authors for the OpsDir review thread. From nobody Wed Dec 15 16:05:08 2021 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 25C8B3A0CF6; Wed, 15 Dec 2021 16:05:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-netconf-sztp-csr@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, mjethanandani@gmail.com, mjethanandani@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <163961310503.29838.2930717052258225050@ietfa.amsl.com> Date: Wed, 15 Dec 2021 16:05:05 -0800 Archived-At: Subject: [netconf] Roman Danyliw's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 00:05:06 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-netconf-sztp-csr-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Yaron Sheffer for the SECDIR review. ** Section 4.1.1. For instance, an NMS controller/orchestrator application could periodically prompt the SZTP-client to generate a new private key and provide a certificate signing request (CSR) or, alternatively, push both the key and an identity certificate to the SZTP-client using I don’t have a sense of the classes of endpoints that would rely on SZTP. Would it include highly constrained or battery powered devices for which this re-keying would be too expensive? ** Editorial nits: -- Section 2.1. s/an new/a new/ -- Section 2.2. Typo. s/Following are/The following are/ -- Section 4.1.1. s/forever contain/contain/ From nobody Thu Dec 16 05:50:10 2021 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 DF88D3A0EB8; Thu, 16 Dec 2021 05:49:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-netconf-sztp-csr@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, mjethanandani@gmail.com, mjethanandani@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <163966259619.16795.14245849874966353326@ietfa.amsl.com> Date: Thu, 16 Dec 2021 05:49:56 -0800 Archived-At: Subject: [netconf] Lars Eggert's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 13:49:57 -0000 Lars Eggert has entered the following ballot position for draft-ietf-netconf-sztp-csr-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Reference [I-D.ietf-netconf-crypto-types] from this Proposed Standard to draft-ietf-netconf-crypto-types of unknown standards level. That should be fixed in the datatracker for draft-ietf-netconf-crypto-types... Document still refers to the "Simplified BSD License", which was corrected in the TLP on September 21, 2021. It should instead refer to the "Revised BSD License". Thanks to Meral Shirazipour for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/4XKQuQMRJ3xEca_Le-NpYcF-RYI). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 4.1.1. , paragraph 5, nit: - private key and associated identity certificates and reexecution of + private key and associated identity certificates and re-execution of + + Section 2.1. , paragraph 5, nit: > ver that it supports the ability the generate CSRs. This parameter conveys if > ^^^^^^^^^^^^ After "the", the verb "generate" doesn't fit. Is "generate" spelled correctly? If "generate" is the first word in a compound adjective, use a hyphen between the two words. Using the verb "generate" as a noun may be non-standard. Section 2.1. , paragraph 5, nit: > the SZTP-client is able to generate an new asymmetric key and, if so, which > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". Section 3.2. , paragraph 20, nit: > the TaggedCertificationRequest and it a bodyPartId and the certificateReque > ^^^^ A verb may be missing between "it" and "a", or a word may be misspelled. Section 3.2. , paragraph 20, nit: > the TaggedCertificationRequest and it a bodyPartId and the certificateReque > ^^^^ A verb may be missing between "it" and "a", or a word may be misspelled. Section 3.2. , paragraph 21, nit: > the TaggedCertificationRequest and it a bodyPartId and the certificateReque > ^^^^ A verb may be missing between "it" and "a", or a word may be misspelled. Section 4.1.5. , paragraph 7, nit: > in Wu. Contributors Special thanks goes to David von Oheimb and Hendrik Broc > ^^^^ It seems that the correct verb form here is "go". Document references draft-ietf-netmod-factory-default, but that has been published as RFC8808. Document references draft-ietf-netconf-keystore-22, but -23 is the latest available revision. Document references draft-ietf-netconf-trust-anchors-15, but -16 is the latest available revision. These URLs point to tools.ietf.org, which is being deprecated: * http://tools.ietf.org/wg/netconf These URLs in the document did not return content: * http://standards.ieee.org/findstds/standard/802.1AR-2018.html From nobody Thu Dec 16 05:50:37 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97873A0EB7; Thu, 16 Dec 2021 05:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU-npiot4HUh; Thu, 16 Dec 2021 05:50:31 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 058883A0EBD; Thu, 16 Dec 2021 05:50:30 -0800 (PST) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:c4eb:1479:77a2:3087]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 9F75A606E27; Thu, 16 Dec 2021 15:50:18 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1639662618; bh=F5f/gjXDQ7kTy0/pzbWRa4XBcTYp1XvSvvmj2riX5L4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=X7l4CXwTtnb5wIRwjShHdJ0BkPCaEey1ZP7hu7VRAx1N/gth3Mxznf/GFPq+WKfAE ROUMXwnheg/rqIJZD0J2szwAHfq4S4X2S5EuCzkzfQJ+FLaCKEp260szh/PqmQbAR0 Rh06lgAfw/eKoTNllcjAoQDLn5rf82Ax1Cwx062A= Content-Type: multipart/signed; boundary="Apple-Mail=_14AABCF1-8CD8-41C6-839F-D501DAEB5CE1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: Lars Eggert In-Reply-To: <163773212617.25289.11973969487179870918@ietfa.amsl.com> Date: Thu, 16 Dec 2021 15:50:15 +0200 Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-netconf-sztp-csr.all@ietf.org, netconf@ietf.org Message-Id: <1DE788D0-E521-4277-9CC4-449F8E3E854E@eggert.org> References: <163773212617.25289.11973969487179870918@ietfa.amsl.com> To: Meral Shirazipour X-MailScanner-ID: 9F75A606E27.A4540 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [netconf] [Last-Call] Genart last call review of draft-ietf-netconf-sztp-csr-11 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, 16 Dec 2021 13:50:36 -0000 --Apple-Mail=_14AABCF1-8CD8-41C6-839F-D501DAEB5CE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Meral, thank you for your review. I have entered a No Objection ballot = for this document. Lars > On 2021-11-24, at 7:35, Meral Shirazipour via Datatracker = wrote: >=20 > Reviewer: Meral Shirazipour > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-netconf-sztp-csr-11 >=20 > Reviewer: Meral Shirazipour > Review Date: 2021-11-23 > IETF LC End Date: 2021-11-23 > IESG Telechat date: NA >=20 >=20 > Summary: This draft is ready to be published as Standards Track RFC. >=20 >=20 > Major issues: >=20 >=20 > Minor issues: >=20 >=20 > Nits/editorial comments: >=20 > [Page 3], Section 1.1 "bootstraped"->"bootstrapped" >=20 >=20 >=20 > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail=_14AABCF1-8CD8-41C6-839F-D501DAEB5CE1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmG7RBcACgkQVLXDCb9w wVdLiQ/9GkG5u8xMnKI5u6VRZB/j0ytGibu80U2+cgJC2zc1BTejTKDn15jez4QS dRq/NRGMpHarOHsSMfTfymUyICoLhgPIekk/LqbV7ByNq429lMFYYXMXen3ss8xY jihwy3OYMB/66B23JeTOsN4YH0c6p/9pJVfIKfts/EpHH0rjfJN26g3kApQElCyk 9nNiCRBJZW6jmJFmbzirfimQ1T30jgTn2vByYozzacH0Ib1oMJAgcVuNytrhbDDe RjHgNa8kKv5K6ehnebu+Hrjm4vs9JsU2MG8MzBqoaE1U1SoPmNvlfKOmqONcngVn wSfvyMSZTeu38raqxeN4kRunB2ZJnpL5593l5+FDOMIGxAmFsnBH5YPSgvU0l2Cm V+odOw5/o35O6NjCYT1QA53FZUOO6ZMQL2lm/YlR1uJYjQwDCHoN6a2NYabBli8r /tUd7grIYJ3R8mFCnU8QuC2gn7DI11USHboNCkJij2UssUdYPj5ss30Nw1KojT6H 9K5AC71BgOtFz4zVIrDOZVslr73XALO5qGfgfOFamFkXThz2Yvtv8v2+f60Ll3yZ 8ivLTmERMrfceWMV6X6EjIswv8U+CmImAptii4gkXVSX9s3yzvIfuCDF4s3rp0W/ sO6pE7E3197ndjCkKAMJeKYfp1JIwuPNYO2U+1NBVNT9oD/DvQ4= =SaP3 -----END PGP SIGNATURE----- --Apple-Mail=_14AABCF1-8CD8-41C6-839F-D501DAEB5CE1-- From nobody Thu Dec 16 06:50:31 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF41F3A0FCC for ; Thu, 16 Dec 2021 06:50:27 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klNIvVNHpdUp for ; Thu, 16 Dec 2021 06:50:24 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6016F3A0FCA for ; Thu, 16 Dec 2021 06:50:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BB4B9300C52 for ; Thu, 16 Dec 2021 09:50:26 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fibJkU6oTrCa for ; Thu, 16 Dec 2021 09:50:25 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id B7559300BE8; Thu, 16 Dec 2021 09:50:24 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: <163961310503.29838.2930717052258225050@ietfa.amsl.com> Date: Thu, 16 Dec 2021 09:50:20 -0500 Cc: IESG , draft-ietf-netconf-sztp-csr@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, mjethanandani@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <163961310503.29838.2930717052258225050@ietfa.amsl.com> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [netconf] Roman Danyliw's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 14:50:28 -0000 > ** Section 4.1.1. >=20 > For instance, an NMS controller/orchestrator > application could periodically prompt the SZTP-client to generate a > new private key and provide a certificate signing request (CSR) or, > alternatively, push both the key and an identity certificate to the > SZTP-client using >=20 > I don=E2=80=99t have a sense of the classes of endpoints that would = rely on SZTP.=20 > Would it include highly constrained or battery powered devices for = which this > re-keying would be too expensive? Sure. Perhaps we should say that devices with the power and computation = resources should periodically generate fresh keying material. Russ= From nobody Thu Dec 16 07:21:39 2021 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 D28423A1001; Thu, 16 Dec 2021 07:21:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-netconf-sztp-csr@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, mjethanandani@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <163966808813.12195.18438122593101389552@ietfa.amsl.com> Date: Thu, 16 Dec 2021 07:21:28 -0800 Archived-At: Subject: [netconf] Murray Kucherawy's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 15:21:29 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-netconf-sztp-csr-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The media types in the examples should be "application/yang-data+json", I believe. There's currently "yang.data" instead of "yang-data". From nobody Thu Dec 16 07:27:12 2021 Return-Path: <0100017dc3da828a-0f2a9c7e-1026-42e8-bd74-b82957831048-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 27B0D3A1001; Thu, 16 Dec 2021 07:27:03 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 yAQbEMz3bdqU; Thu, 16 Dec 2021 07:26:59 -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 9BADE3A1008; Thu, 16 Dec 2021 07:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639668417; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=Ppr2qWMJ91A5sOE90GJr78ptOiVmEqmfc03oHQL9Fl0=; b=KnEtPWcnr0S79FkmpJEJx5agdcer1vwx8Y+RB2rgDdMp4kLm4f+pNIutt2Hs2BLX LJ/Q4aMiOafJVMBdqiwKQ9DlTXuIwOAsSDclGrW3AcFtx7FNI9hbq6eO1l7e2LEbuob iMzkwRciPoGDFdZEL3yIqLcMTgf2Ut0Nu4+av5gw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Kent Watsen In-Reply-To: <163959735420.32477.10309110443759504502@ietfa.amsl.com> Date: Thu, 16 Dec 2021 15:26:57 +0000 Cc: The IESG , draft-ietf-netconf-sztp-csr@ietf.org, "netconf-chairs@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017dc3da828a-0f2a9c7e-1026-42e8-bd74-b82957831048-000000@email.amazonses.com> References: <163959735420.32477.10309110443759504502@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.16-54.240.8.83 Archived-At: Subject: Re: [netconf] Warren Kumari's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 15:27:04 -0000 Hi Warren, Thank you for your review and appreciation. No more comments below. Best regards, Kent (on behalf of the authors and WG) > On Dec 15, 2021, at 2:42 PM, Warren Kumari via Datatracker = wrote: >=20 > Warren Kumari has entered the following ballot position for > draft-ietf-netconf-sztp-csr-12: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > A quick note to say thanks to the WG for this document, and also to = Dan, Rob, > the authors for the OpsDir review thread. >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Dec 16 07:45:35 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1A63A1035; Thu, 16 Dec 2021 07:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 T9Kt18DsWufZ; Thu, 16 Dec 2021 07:45:20 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05lp2173.outbound.protection.outlook.com [104.47.17.173]) (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 875493A1033; Thu, 16 Dec 2021 07:45:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kZcN/8IpycgRH6wsWM30grydpYuj9vrw8isoEhoHGHVTVIlnHY7TryMO2y3Jvmwc3FAivs+2BVPN6Zv2NJwHdZ6LDsZUagyJ10SSCF2fqmiw455qxWTWVwfSZbKEWNlk3PplxdPFxriH3q+2FKxBFRnUCxR61lBWnOXaGAYy1PjkwpGXZWrU8eCPfG0HHJI5eFXpQRcxX4Exm5YpYyWZ3KJziKBuGqQy1mpqmA+I63Qh0KnAPcAL56XiYhY8R7E2prliVoiLY6O7Qx9cq/DPD3/4YO3HbiLqFhGAiUD/Kn1ym68yKpK6WRiMopKgY48HKpJ3hy2nyXJodONykGesIA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OtebEDUdxUhvFjN0qN88JBmt5omYkUYyCyGF5upRBTM=; b=i8886nu+WAdIykw2i1rRnoY/oFT3a/sdupeeeaBpWpUk0of02KC4Cf3Rg2DEGIBKFD1e18uZRPbc9vO+5IDry+18WCoV1hlZw5uEtqBIsYd7ct9/Cz+dBd03u8qAallKzpIe79OnN451AI7DHI9sx0HLh6juCLbhwMaJyzP+TvJrNdI/s5bCfeOO/NeF0FvctcaBnW1Rp+cE/WlcQyW+hzvq/BCyyDpowPC+muO0RpIHf6uO0l8ksk81QKNwB86OjqlGsMQoHaobwgqiiq+ExvVwVmGPKP0uNmESi8ToPVdXLavk/4V6UbIai08iE3i+WC+Jvs2ugKxhDj8DSohW+Q== 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=OtebEDUdxUhvFjN0qN88JBmt5omYkUYyCyGF5upRBTM=; b=RhfPaOOrJ6rX78k8Sh8JDDL984SPVAige0XMfTiPc6quu6ZD9M3IMCCtWZRIotC0yd8JlfkY/F9mEGUa8eDIZhh0zLgsRTJqLupqzwILjPrjUVB2SLNiXnESfap2SIfaeE+s9kWsA6HxLhO0EXc3kd9iRkVZ/0AZ22i7JY1qCZo= Received: from HE1PR07MB4187.eurprd07.prod.outlook.com (2603:10a6:7:98::23) by HE1PR07MB4235.eurprd07.prod.outlook.com (2603:10a6:7:95::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.8; Thu, 16 Dec 2021 15:45:13 +0000 Received: from HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::9982:7fa1:fcf6:2967]) by HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::9982:7fa1:fcf6:2967%3]) with mapi id 15.20.4778.018; Thu, 16 Dec 2021 15:45:13 +0000 From: Zaheduzzaman Sarker To: Kent Watsen CC: The IESG , "draft-ietf-netconf-sztp-csr@ietf.org" , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Zaheduzzaman Sarker's Discuss on draft-ietf-netconf-sztp-csr-12: (with DISCUSS and COMMENT) Thread-Index: AQHX8O3V9Hut0HutdUW95ecisaIcWawyrriAgAKXPwA= Date: Thu, 16 Dec 2021 15:45:13 +0000 Message-ID: <40468B1C-773D-46C0-8386-735478F8B04E@ericsson.com> References: <163948820661.12873.16286675430659744022@ietfa.amsl.com> <0100017dbb6de6a8-503b8aaa-031f-4c2c-bca4-79eaec0fbff7-000000@email.amazonses.com> In-Reply-To: <0100017dbb6de6a8-503b8aaa-031f-4c2c-bca4-79eaec0fbff7-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f37ed7a2-5521-4264-1d9a-08d9c0ab0ce3 x-ms-traffictypediagnostic: HE1PR07MB4235:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oWMIqoOL9yLg38oTMLuqY1oFqyUk7qPPACnLb/ocI8pxrK7tnfsBpNG89/Kqx4qK2r1K1GYN/GT8FB4oD8VXU67bsacUoazbgxCtu9cChSKhmvkLHVqz9wacgCM7hzeDjfAfuc3FkFfS3lVeEkCkaa9WXcDBsiyhgZoQxu1k1t80Jj7TMpZYc4byz73UMg4zLgmj1bL6vna8BhrfBPrRJITlMYmsXtvs6F2b5Ryd4DuNSeRKLBQhAoC2KWsuE5S5Cz3dDEOEeJGWk7yd2UXdLoWzcr4H64719gpVe5wfygUKO5SNA0fSLWsVjCGQYjAMrFFJAH4yOzkSL9UVwnMxWhZ9VffxlCMt0gHI3nUmS4n0x1X11x1U5vcEWmCxtWuTU2wbmceabrh/o1OjD837Ezr/RFs8P6PPvimyNTPbbv1y/rxoFsUALTibLtKGddg1C2BUD2GCcPPBgbkEBpBBdqZalKVgnejbEJGZop8vqz1ZuCw6qQUDYdJOwy4EB+rQc66RrRTkGBm0FwL6c93OrC9djSD2WAngQmnTkbLWmfTjOXUcAOloU4Z+va3EsmrMS6a72GfQuGb1kgvL2jmm/KWXz5ZCU/gsCKcsoRmFd6T15piFPk3a9CFKKwEVE3bZjvLEkXWQGuUqt2qn4tFcSsJVpRyugDpE6+IY5deEDN5WfCwT0dtiP0tTViKtq15HaUX3whfyqR4DK2tH21YjTIm6YPidSya6IjTw5RTKTW/jyftN2G/p4mVCqcHqf7+a70mE0Tl61FyvnzrMQdvw1NbxZSceRFxqPrZsTbL7Fg5Fy1KZ/RBfscW//aQUAXfgrJAfq4xOBcHcOmSu8BGfaESYencymTZe0vdMW+Lnzvc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4187.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(53546011)(38070700005)(6486002)(66446008)(91956017)(26005)(66946007)(76116006)(82960400001)(38100700002)(166002)(86362001)(99936003)(122000001)(66476007)(316002)(186003)(66556008)(6916009)(508600001)(4326008)(2616005)(8676002)(83380400001)(8936002)(36756003)(64756008)(2906002)(44832011)(6506007)(966005)(71200400001)(6512007)(5660300002)(33656002)(54906003)(45980500001)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NlhQVE4zWU5ESVlkSU9yYmsyV1ZLcHlxL0lHK0xEblRsWlJLMnFzbGljZ2tO?= =?utf-8?B?YU4yUEFMbWJQUjNtVjMrNS92U3JTVjFwR0pOZW0zaGp2N3FqSGh4VndoM05L?= =?utf-8?B?Z3VlYlFqQ0pDUFFDaEt3OWE3alBFanZERm0vYVpVUmFhY2ViUHNxRkU1VXFk?= =?utf-8?B?WU9LRzcrbmkzQklSTW15ZG9FNGxCalZITW13YnVzVnY5elhFOUJKemlCNmt0?= =?utf-8?B?ZUljR2k5MEJYamNNakpwb09YZysxU29EV3E3RlcvYmlQUzJPL0hFUzJtS21N?= =?utf-8?B?c2REdEZ5TTgxb3Fmd2x2TFdFd0dNNXdWRlJSRHdzWWwzUXBkSVRWMy9LRUVD?= =?utf-8?B?cDNMV2lPTk15VkxBM2Y4UEp2a3RVT2NBTWJyZWplUGNHcU5mb1NFQUk2c1E0?= =?utf-8?B?Y245QWFtaVpHWXVFbnQ0bXlMQndvMmZXbVFGa2dKMUY0bWtwb2I0ck1ZTGJs?= =?utf-8?B?MFc5djVHc3AxTzFWMTZoS2FLdHdlbGVmRXo3Q1gwL05kWk9zbXdzbXRMN2lw?= =?utf-8?B?bC9ZWXVwaEJscUhTczN2UFNNNWdVT1FJSThVdjRLa2l3ZDI1enRrTUU2S3g0?= =?utf-8?B?SmR6cFJJWTZ2bHkvODVCejBQZThEaXcxdVF3WUNkWTVrVTRHZkhwNEFaQ25l?= =?utf-8?B?WUJZQmtXZDBZSGd5VkpndkJ6Vi9tcHNuMGFYdk1kbkRsaVcwcjVXRGg1Z0s5?= =?utf-8?B?TFFXQ0N3a2Zoemx4V25MV1B4R0NHRS82b2h6NmxlZDFtVHdFZTNZejlhd3Iv?= =?utf-8?B?UC9ONDFtVnc5Y1JTWFRaZDJSdDZNaFhJaDNDR1J0dXpvaEgrOWRjMHVnc3E2?= =?utf-8?B?akdHTmJ5WmxId3NMbkV3THRNaU9hVzVKVVorNnRKeFFRVndCYU8vT2drS1Rx?= =?utf-8?B?aEFudENTMHo2N2pmN2RzbWZGQkRVM0hFN2ZpeXdsLzl5c3BLelh3NFpZanlu?= =?utf-8?B?NU5yTzh4WVdsQjMxV1dYcHF0UDVaRFFGcjNNaEdpMnYzZUNqUm1KR2JXMjhs?= =?utf-8?B?dVM4WWhiYW4rQStDdTEwVjE4Vnd3QXJHTnRVZXpuK2lpaE90MUFobllMcXA3?= =?utf-8?B?YkN0ZTBtc1ZVRzhNTVpadHFyK2xTUWJoQ2R2ZGg1ZGhZeWpSN3oyOStUMC9p?= =?utf-8?B?NStXa1lmTkE1b0R4em5WbTZDbGRBSXRJZTZ3b2lUc2FTeW5rWHo5NVRlZDZY?= =?utf-8?B?NGhEdTFmRC9BbmJ6c09DbnhlakM1RTJXUkUxR0NXUTB5TnIybXg2bkFWdWFO?= =?utf-8?B?aHhURTdMZWFiL1Jnakxsang1VnFkYloyK2FabDVWTFNVOUJPa2JuWHJvQ0ts?= =?utf-8?B?QVV0ckRTV2JiL3JBZDdwVmlFTVczSUZ1c0xBbVNVOHJhRnV0OFdKUk5sMlRq?= =?utf-8?B?aE5xbjZieDlPNDhvRzgzOEpOb0xTVDN2RURrbUlzYTJkcURaN3Jqd0UzZXhG?= =?utf-8?B?RXNPMjV6ZTBDUnl1K2Zjc3ZpTDNjWEtRYzBsd1FxV3lSaElZSEx0TTNLNzdO?= =?utf-8?B?WHZXd1Y1TE1iZkVGL0dSMEhsSU1naXJoMldTSDU1SERDL3Q4SFByTjhWeDY1?= =?utf-8?B?NXlBRTFlVmdkd3Fqb1g2Z21nZEN3WUJUZS9WZExUVTR6WlNxNFB0ZGtOUEZj?= =?utf-8?B?eFdNVEVWK2dsZUFyOEEvNHlWWWRPZjd4Qld4T2JqMENVV1RHeDdJaW1Ib3F0?= =?utf-8?B?OFZnNVJOajlQblRjbHVKalNFMWtUZUFFN2dSNzI2YktxUGo1SXBpRGVLNStn?= =?utf-8?B?MkF4RmVtYTF0NWNrSUdpMVg1L1FlSWFtakxhZzNyNWRmUmUwUHIvbUw3M0l4?= =?utf-8?B?SUhDYlFoRldBTHkrK1IzalppYml2U2dicjVCZXIyWDVXZ00wc1loTkNZTTBk?= =?utf-8?B?UTN6U3E3L3RGOUp3OERtV1F6bGVHd25lTlNHSnBERzREWW1ITXExeWsyWVV3?= =?utf-8?B?ejY5N1NIQURrY1h6VldBckxoV3RuQ3NFNEt5N1c5amJMWG04V0NhS3ZUNmlq?= =?utf-8?B?WkpmSStYTlY3WFNXV1hnRnRqb0cwK3o4YVB6aHJPbnhNOTMvUWFNOFgvWkRq?= =?utf-8?B?ZGVvMWpnVlhqMDhzNzNIeXRKZlZWOGpJaERsUmdJdTJObjlNbjNJUW5nK0VS?= =?utf-8?B?ZjNzcDVWa2V6bUdLZ2owcUczN3V5Rm11S3Jhb2w2eTlJb2xiTXdLb1VhQWVi?= =?utf-8?B?S3hCYWhVSnJFWmxrU1dRMU84a1B5QTYrR2lqbkZaOTdBbjR5VWwvZHN4cTZK?= =?utf-8?B?K2xFV2wrUjVkcW5wRUlPQXlrWFdqWWo5N1dpWnlMNks3Q0V1d29ZMlRDNVIv?= =?utf-8?B?U0pjdUo5eEdxS3FaMXFDZUttOWJud2lnRHRncnBadDk5S2dsaDFhUT09?= Content-Type: multipart/signed; boundary="Apple-Mail=_8927EE16-3C47-44D4-8E81-16C6CAE6AA38"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4187.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f37ed7a2-5521-4264-1d9a-08d9c0ab0ce3 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2021 15:45:13.6381 (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: Kcg6Jxurz1UuzsFQYSWAZy5R4+gKIkqywXEzNLQfpJdbL+JrNdGnGKPMR16z80FEX1IEHFx2MyxdMYfuWarpxD5pAcKjp56ozw+w0jG3CQlarJi1JORG00AxpvqL7GMa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4235 Archived-At: Subject: Re: [netconf] Zaheduzzaman Sarker's Discuss on draft-ietf-netconf-sztp-csr-12: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 15:45:26 -0000 --Apple-Mail=_8927EE16-3C47-44D4-8E81-16C6CAE6AA38 Content-Type: multipart/alternative; boundary="Apple-Mail=_689A52E6-A4A7-41E4-9897-9F8429C5D14E" --Apple-Mail=_689A52E6-A4A7-41E4-9897-9F8429C5D14E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Thanks for the response.=20 > On 15 Dec 2021, at 01:11, Kent Watsen wrote: >=20 > Hi Zaheduzzaman, >=20 > Thank you for your review! Responses to your comments are below. >=20 > Kent // as a co-author >=20 >=20 >> On Dec 14, 2021, at 8:23 AM, Zaheduzzaman Sarker via Datatracker = > wrote: >>=20 >> Zaheduzzaman Sarker has entered the following ballot position for >> draft-ietf-netconf-sztp-csr-12: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ = >> for more information about how to handle DISCUSS and COMMENT = positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ = = >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> I would like to discuss two points - >>=20 >> - as this specification add more detailed response for HTTP 400 Bad = Request >> error code. I would like to know if RFC7807 has been considered for = such >> usage. >=20 >=20 > The authors did not know about RFC 7807. Thank you for bringing it to = our attention. >=20 > Looking at RFC 7807, we do not believe that we should use it because: > - an SZTP-server (RFC 8572) is a RESTCONF-server (RFC 8040) > - RESTCONF defines it=E2=80=99s own mechanism for structure = responses > https://datatracker.ietf.org/doc/html/rfc8040#section-7.1 = . >=20 > This comment would have been good when RFC 8040 was being published, = but > now it is water over the bridge, so to speak. Agreed? Ok I get it. I am now thinking if it is worth mention this fact in the = draft. My main point was that RFC7807 is more a generic HTTP way to send = details about problem which this specification is using hence might need = motivation for why not RFC 7807 is used, specially looking the = discussion on this topic in the mailing list.=20 >=20 >=20 >> - is this specification defining new media type = "application/yang.data+json"? >> and would ask why? It could very well use "application/problem+json" = or >> "application/problem+xml" from RFC7807 or even = "application/yang-data+json". >=20 > Aye! This is a typo. It should be "application/yang-data+json=E2=80=9D= , which is defined > In RFC 8040 here: = https://datatracker.ietf.org/doc/html/rfc8040#section-11.3.2 = . >=20 > I have fixed this typo here: = https://github.com/netconf-wg/sztp-csr/commit/7d62548f36b2bc325533c6d6a362= 900badc5301b = >=20 > An I-D update is pending a few more IESG-reviews. >=20 > Good? Very good. //Zahed >=20 >=20 >=20 --Apple-Mail=_689A52E6-A4A7-41E4-9897-9F8429C5D14E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Thanks = for the response. 


On 15 Dec 2021, at 01:11, Kent Watsen <kent@watsen.net> = wrote:

Hi Zaheduzzaman,

Thank you for your review! =  Responses to your comments are below.

Kent // as a co-author


On Dec = 14, 2021, at 8:23 AM, Zaheduzzaman Sarker via Datatracker <noreply@ietf.org> = wrote:

Zaheduzzaman Sarker has entered the following ballot position = for
draft-ietf-netconf-sztp-csr-12: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/for more information about how to handle DISCUSS and = COMMENT positions.


The = document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

I would like to discuss two points = -

 - as this specification add more = detailed response for HTTP 400 Bad Request
 error = code. I would like to know if RFC7807 has been considered for such
 usage.


The authors did not = know about RFC 7807.  Thank you for bringing it to our = attention.

Looking at RFC 7807, we do not believe that we should use = it because:
  - = an SZTP-server (RFC 8572) is a RESTCONF-server (RFC = 8040)
  - RESTCONF = defines it=E2=80=99s own mechanism for structure = responses
    = https://datatracker.ietf.org/doc/html/rfc8040#section-7.1.

This = comment would have been good when RFC 8040 was being published, = but
now it is water over the bridge, so to speak. =  Agreed?
Ok I get it. I am now thinking if it is worth mention this fact in the = draft. My main point was that RFC7807 is more a generic HTTP way to send = details about problem which this specification is using hence might need = motivation for why not RFC 7807 is used, specially looking the = discussion on this topic in the mailing = list. 


 - is this specification defining new = media type "application/yang.data+json"?
 and would = ask why? It could very well use "application/problem+json" or
 "application/problem+xml" from RFC7807 or even = "application/yang-data+json".

Aye!  This = is a typo. =   It should be "application/yang-data+json=E2=80=9D, which is = defined
In RFC 8040 = here: https://datatracker.ietf.org/doc/html/rfc8040#section-11.3.2.

I have = fixed this typo here: https://github.com/netconf-wg/sztp-csr/commit/7d62548f36b2bc325= 533c6d6a362900badc5301b

An = I-D update is pending a few more IESG-reviews.

Good?
Very = good.

//Zahed




= --Apple-Mail=_689A52E6-A4A7-41E4-9897-9F8429C5D14E-- --Apple-Mail=_8927EE16-3C47-44D4-8E81-16C6CAE6AA38 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBf4w ggX6MIID4qADAgECAg8BdUoQAyUVYjB/ZVVBDvMwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMC U0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB IHYzMB4XDTIwMTAyMTA3MjkyNVoXDTIzMTAyMjA3MjkyNFowYjERMA8GA1UECgwIRXJpY3Nzb24x HDAaBgNVBAMME1phaGVkdXp6YW1hbiBTYXJrZXIxLzAtBgkqhkiG9w0BCQEWIHphaGVkdXp6YW1h bi5zYXJrZXJAZXJpY3Nzb24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmjJb Zy6kdvqWwiZanvVnqKsb990pSFndyIgFspP9mArDxvEX0oqrBugPRyJSp1KA0KDPo9L3SBHk7pbp hJDbJAxPdPAbyZ+DMHV/UtQSUUpp8rRoYNEA6Ew3OlG5Sz1Nhq9AcjSKeOZKunnJInh/y435NACo co2uP/6Gk0XBeB3qE645aIqpbsO3DCUMOWxWIjjTRFQ/TqoUjbIwfw+rO64Y3qEa96Ibj63AoDtt 3gwmtpFkVm5C44XfK7J4LyXIIz4TQqnfxlfoJ+ttFMfV1ZV1OvA7xXj0yO/6btsktlktpgMvow87 HPkSRtsLXQoRhU4E1zclEPWz5SzhUXuOvwIDAQABo4IBxjCCAcIwHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwHQYDVR0OBBYEFJlMp3EJ+P/dXOLqvbT718jDfw1mMA4GA1UdDwEB/wQE AwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzArBgNVHREEJDAigSB6YWhlZHV6emFt YW4uc2Fya2VyQGVyaWNzc29uLmNvbTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwDQYJKoZIhvcNAQELBQADggIBAD1OD1xt xE0jjc12/QXWWe8Cv2q1ZRn1PwacRWFJMyprPB6CiR6YBnmovYCyvCrNCqzsNaTpQLAQeKxwpmOg fZ1SrdyqQKjtCiAlQynqV+dX5VAA6kt/fM67jZbU+lmzw3/2mXNQKTnor1Ax2bJjtZB2DzvTmSPd EybZWxSfMMSsZHA4GLPGEHws+7fHeZ6RSRsAolXPTLGu7gxPkYDtaUzI9M8Z9GKz2UC/wNP2UieR 95h5TnKiqAWLqAxwzcu7GVWIdJ4rzgOenaNg56OM5q87+X90ZSAODWAPnxdDgVGspHbxt2g9cQYb pkKiHWrOuLIWd8B/oGbE1ruKqcFKC39aYkd7JRlHjkNfU/IpymDoGd3RYMtsJW2JvinuZMmMZ5F5 Xpw1yJuSPrq5tHbPx7S6hjqYhd9VkRLbKkprw9+HJZBrUrhrUx4HVF2/bo+WG9GCTdQUsm8JQt9B zpRh2ySNBQZfUn1WN3Q+lMcGSdItCNYH6HnXGrAmv+oDZ1pnp9z+NNmDoNMAHaFvwYCFd9/HvjJu 5kL90Fp3UEJQAk6X+2+ElrfNplUz16nAOBvxcY55R5eI9SDD8MmNfADekiMldSwB9LjMrqBhwWeE UblghhtceJ3iqg35LURo+KXdL3h0/IodZPBYoMLMhMbDdYokIUY+mWW5W1T1WzV9PyWqMYICyjCC AsYCAQEwWjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCDwF1ShADJRViMH9lVUEO8zANBglghkgBZQMEAgEFAKCC AUEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjExMjE2MTU0NTEy WjAvBgkqhkiG9w0BCQQxIgQgA83rBmhUHVM43/iGrgwZewkaJhhnpYepjIfwZIKTjCYwaQYJKwYB BAGCNxAEMVwwWjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVy aWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCDwF1ShADJRViMH9lVUEO8zBrBgsqhkiG9w0BCRAC CzFcoFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdUoQAyUVYjB/ZVVBDvMwDQYJKoZIhvcNAQELBQAEggEA jtJBTYF/tQJOf8uYQEyun5Bv7wWQYXw0ePcoMrP+HsznCYm5zcYwdApHNur4WxsIP/l1RyrFOFb0 B3atDEMsqRL3f4mYqIUVMsKPc6gYvxqSfLXwq5rUEmeltETmGJD72rH/juj7nUWELkEocpJFgXJB jb23GdwZd4Yppg9CGMcI8mDqEBPEZ6P8J8sbqzq1yXFBewUWKQFDLtXeZ+JF65HG23UmcociPClV 9IUqZ/lX0nI0gHDD5OpC8Irw57lWz8jCgn+1OHifLeHfBEOf3iatqK91pnCOI83jNkUUgML3yJ+3 ksh6XE0guuZQ47C+WD79IJvv/WIXT/fj4folPQAAAAAAAA== --Apple-Mail=_8927EE16-3C47-44D4-8E81-16C6CAE6AA38-- From nobody Fri Dec 17 08:19:33 2021 Return-Path: <0100017dc930e649-38db63ee-870b-429c-8335-1d74ac629361-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 9BF633A061B; Fri, 17 Dec 2021 08:19:31 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 wSeFqXiVgmUY; Fri, 17 Dec 2021 08:19:26 -0800 (PST) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E3E3A0776; Fri, 17 Dec 2021 08:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639757965; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=qKSX78ZUSGSUWYBKFy3QtzDKPVGd2zRrfWOpKCK/q8U=; b=M75ha/pXU/3JrFrN7nZv/etNE9MGUeXaDpmkxkh4II97o+5DlZ/8UW7EblGc7itu hDE96CRiXWgJu0BL5TVBcDdruu5lNivNHAp6m11KQXMOzgySMpaOiOntRUYPM43fKln tvxPLlyJcRSZTWnbyWH4fW0VxIEj40WW6oIiJIPE= From: Kent Watsen Message-ID: <0100017dc930e649-38db63ee-870b-429c-8335-1d74ac629361-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E050664D-E752-45A9-B813-3D9E83E9BD5F" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 17 Dec 2021 16:19:24 +0000 In-Reply-To: <163966259619.16795.14245849874966353326@ietfa.amsl.com> Cc: The IESG , draft-ietf-netconf-sztp-csr@ietf.org, "netconf-chairs@ietf.org" , "netconf@ietf.org" , Mahesh Jethanandani To: Lars Eggert References: <163966259619.16795.14245849874966353326@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.17-54.240.48.110 Archived-At: Subject: Re: [netconf] Lars Eggert's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 16:19:32 -0000 --Apple-Mail=_E050664D-E752-45A9-B813-3D9E83E9BD5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Lars, Thank you for your review. Below are responses to your comments. Diffs can be found here: GitHub link = . [some diffs are found in the TBD-commit for Ben=E2=80=99= s review] Kent (and Sean and Russ) > On Dec 16, 2021, at 8:49 AM, Lars Eggert via Datatracker = wrote: >=20 > Lars Eggert has entered the following ballot position for > draft-ietf-netconf-sztp-csr-12: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Reference [I-D.ietf-netconf-crypto-types] from this Proposed Standard = to > draft-ietf-netconf-crypto-types of unknown standards level. That = should be > fixed in the datatracker for draft-ietf-netconf-crypto-types... Silly chairs ;) (Fixed) > Document still refers to the "Simplified BSD License", which was = corrected in > the TLP on September 21, 2021. It should instead refer to the "Revised = BSD > License". I didn=E2=80=99t know that, thanks for the update. (Fixed) > Thanks to Meral Shirazipour for their General Area Review Team = (Gen-ART) review > = (https://mailarchive.ietf.org/arch/msg/gen-art/4XKQuQMRJ3xEca_Le-NpYcF-RYI= ). Indeed. Thanks to all who help publish these documents! :) > = --------------------------------------------------------------------------= ----- > All comments below are about very minor potential issues that you may = choose to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), = so there > will likely be some false positives. There is no need to let me know = what you > did with these suggestions. >=20 > Section 4.1.1. , paragraph 5, nit: > - private key and associated identity certificates and reexecution = of > + private key and associated identity certificates and re-execution = of > + + Fixed. > Section 2.1. , paragraph 5, nit: >> ver that it supports the ability the generate CSRs. This parameter = conveys if >> ^^^^^^^^^^^^ > After "the", the verb "generate" doesn't fit. Is "generate" spelled = correctly? > If "generate" is the first word in a compound adjective, use a hyphen = between > the two words. Using the verb "generate" as a noun may be = non-standard. Fixed (now says "the ability to=E2=80=9D) > Section 2.1. , paragraph 5, nit: >> the SZTP-client is able to generate an new asymmetric key and, if so, = which >> ^^ > Use "a" instead of "an" if the following word doesn't start with a = vowel sound, > e.g. "a sentence", "a university". Fixed (now says =E2=80=9Ca new=E2=80=9D) > Section 3.2. , paragraph 20, nit: >> the TaggedCertificationRequest and it a bodyPartId and the = certificateReque >> ^^^^ > A verb may be missing between "it" and "a", or a word may be = misspelled. Fixed (now says =E2=80=9Cand it is the=E2=80=9D) [from Ben=E2=80=99s = review] > Section 3.2. , paragraph 20, nit: >> the TaggedCertificationRequest and it a bodyPartId and the = certificateReque >> ^^^^ > A verb may be missing between "it" and "a", or a word may be = misspelled. Fixed (now says =E2=80=9Cand it is the=E2=80=9D) [from Ben=E2=80=99s = review] > Section 3.2. , paragraph 21, nit: >> the TaggedCertificationRequest and it a bodyPartId and the = certificateReque >> ^^^^ > A verb may be missing between "it" and "a", or a word may be = misspelled. Fixed (now says =E2=80=9Cand it is the=E2=80=9D) [from Ben=E2=80=99s = review] > Section 4.1.5. , paragraph 7, nit: >> in Wu. Contributors Special thanks goes to David von Oheimb and = Hendrik Broc >> ^^^^ > It seems that the correct verb form here is "go". Fixed. > Document references draft-ietf-netmod-factory-default, but that has = been > published as RFC8808. Fixed. > Document references draft-ietf-netconf-keystore-22, but -23 is the = latest > available revision. Ignored (both are works in progress) > Document references draft-ietf-netconf-trust-anchors-15, but -16 is = the latest > available revision. Ignored (both are works in progress) > These URLs point to tools.ietf.org, which is being deprecated: > * http://tools.ietf.org/wg/netconf Fixed! (Now both YANG modules point to = "https://datatracker.ietf.org/wg/netconf=E2=80=9D) > These URLs in the document did not return content: > * http://standards.ieee.org/findstds/standard/802.1AR-2018.html Fixed! (URL now "https://standards.ieee.org/standard/802_1AR-2018.html = " Thanks again! K. --Apple-Mail=_E050664D-E752-45A9-B813-3D9E83E9BD5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Lars,

Thank you for = your review.  Below are responses to your comments.

Diffs can be found = here: GitHub link.   [some = diffs are found in the TBD-commit for Ben=E2=80=99s review]

Kent (and Sean and = Russ)


On Dec 16, 2021, at 8:49 AM, = Lars Eggert via Datatracker <noreply@ietf.org> wrote:

Lars = Eggert has entered the following ballot position for
draft-ietf-netconf-sztp-csr-12: No Objection

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/for more information about how to handle DISCUSS and = COMMENT positions.


The = document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Reference = [I-D.ietf-netconf-crypto-types] from this Proposed Standard to
draft-ietf-netconf-crypto-types of unknown standards level. = That should be
fixed in the datatracker for = draft-ietf-netconf-crypto-types...

Silly = chairs ;)  (Fixed)


Document still refers to the "Simplified BSD License", which = was corrected in
the TLP on September 21, 2021. It should = instead refer to the "Revised BSD
License".

I didn=E2=80= =99t know that, thanks for the update.  (Fixed)



---------------------------------------------------------------= ----------------
All comments below are about very minor = potential issues that you may choose to
address in some = way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so = there
will likely be some false positives. There is no = need to let me know what you
did with these = suggestions.

Section 4.1.1. , paragraph 5, = nit:
-    private key and associated = identity certificates and reexecution of
+ =    private key and associated identity certificates and = re-execution of
+ =             &n= bsp;           &nbs= p;            =             &n= bsp;        +

Fixed.


Section 2.1. , paragraph 5, nit:
ver that it supports the ability the generate = CSRs. This parameter conveys if
=             &n= bsp;           &nbs= p;       ^^^^^^^^^^^^
After "the", the verb "generate" doesn't fit. Is = "generate" spelled correctly?
If "generate" is the first = word in a compound adjective, use a hyphen between
the two = words. Using the verb "generate" as a noun may be non-standard.

Fixed = (now says "the ability to=E2=80=9D)


Section 2.1. , paragraph 5, = nit:
the SZTP-client = is able to generate an new asymmetric key and, if so, which
= =             &n= bsp;           &nbs= p;           ^^
Use "a" instead of "an" if the following word = doesn't start with a vowel sound,
e.g. "a sentence", "a = university".

Fixed (now says =E2=80=9Ca new=E2=80=9D)
<= br class=3D"">

Section 3.2. , paragraph 20, = nit:
the = TaggedCertificationRequest and it a bodyPartId and the = certificateReque
=             &n= bsp;           &nbs= p;          ^^^^
A verb may be missing between "it" and "a", or a = word may be misspelled.

Fixed (now says =E2=80=9Cand it is the=E2=80=9D) =  [from Ben=E2=80=99s review]


Section 3.2. , paragraph 20, nit:
the TaggedCertificationRequest and it a = bodyPartId and the certificateReque
=             &n= bsp;           &nbs= p;          ^^^^
A verb may be missing between "it" and "a", or a = word may be misspelled.

Fixed (now says =E2=80=9Cand it is the=E2=80=9D)  [from = Ben=E2=80=99s review]


Section 3.2. , paragraph 21, nit:
the = TaggedCertificationRequest and it a bodyPartId and the = certificateReque
=             &n= bsp;           &nbs= p;          ^^^^
A verb may be missing between "it" and "a", or a = word may be misspelled.

Fixed (now says =E2=80=9Cand it is the=E2=80=9D)  [from = Ben=E2=80=99s review]


Section 4.1.5. , paragraph 7, nit:
in Wu. Contributors = Special thanks goes to David von Oheimb and Hendrik Broc
=             &n= bsp;           &nbs= p;         ^^^^
It seems that the correct verb form here is = "go".

Fixed.


Document references draft-ietf-netmod-factory-default, but = that has been
published as RFC8808.

Fixed.


Document references draft-ietf-netconf-keystore-22, but -23 = is the latest
available revision.

Ignored = (both are works in progress)


Document references draft-ietf-netconf-trust-anchors-15, but = -16 is the latest
available revision.

Ignored (both = are works in progress)


These URLs point to tools.ietf.org, which is = being deprecated:
* http://tools.ietf.org/wg/netconf

Fixed! = (Now both YANG modules point to "https://datatracker.ietf.org/wg/netconf=E2=80=9D)


These URLs in the document = did not return content:
* http://standards.ieee.org/findstds/standard/802.1AR-2018.html

Fixed! (URL now "https://standards.ieee.org/standard/802_1AR-2018.html"



Thanks again!
K.



= --Apple-Mail=_E050664D-E752-45A9-B813-3D9E83E9BD5F-- From nobody Mon Dec 20 19:10:00 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C70A3A108E; Mon, 20 Dec 2021 19:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6Cjl07w9hQ8; Mon, 20 Dec 2021 19:09:53 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A163A108B; Mon, 20 Dec 2021 19:09:52 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BL39VBL007898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Dec 2021 22:09:38 -0500 Date: Mon, 20 Dec 2021 19:09:31 -0800 From: Benjamin Kaduk To: Kent Watsen Cc: Zaheduzzaman Sarker , "netconf@ietf.org" , draft-ietf-netconf-sztp-csr@ietf.org, The IESG , "netconf-chairs@ietf.org" Message-ID: <20211221030931.GM11486@mit.edu> References: <163948820661.12873.16286675430659744022@ietfa.amsl.com> <0100017dbb6de6a8-503b8aaa-031f-4c2c-bca4-79eaec0fbff7-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0100017dbb6de6a8-503b8aaa-031f-4c2c-bca4-79eaec0fbff7-000000@email.amazonses.com> Archived-At: Subject: Re: [netconf] Zaheduzzaman Sarker's Discuss on draft-ietf-netconf-sztp-csr-12: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2021 03:09:58 -0000 Hi Kent, On Wed, Dec 15, 2021 at 12:11:21AM +0000, Kent Watsen wrote: > Hi Zaheduzzaman, > > Thank you for your review! Responses to your comments are below. > > Kent // as a co-author > > > > On Dec 14, 2021, at 8:23 AM, Zaheduzzaman Sarker via Datatracker wrote: > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I would like to discuss two points - > > > > - as this specification add more detailed response for HTTP 400 Bad Request > > error code. I would like to know if RFC7807 has been considered for such > > usage. > > > The authors did not know about RFC 7807. Thank you for bringing it to our attention. > > Looking at RFC 7807, we do not believe that we should use it because: > - an SZTP-server (RFC 8572) is a RESTCONF-server (RFC 8040) > - RESTCONF defines it’s own mechanism for structure responses > https://datatracker.ietf.org/doc/html/rfc8040#section-7.1. > > This comment would have been good when RFC 8040 was being published, but > now it is water over the bridge, so to speak. Agreed? I agree that RFC 8040 would have been the place to use the RFC 7807 structured error responses, and trying to shoehorn it in here is not a great fit. However, I also think that using 400 Bad Request as part of the expected flow of operations is also not a good fit. That is, what seems to be happening in this workflow is not so much that the client sent a "bad request" as that it sent a request for something logically different than "get-bootstrapping-data": it seems more like a "negotiate CSR parameters" operation than "get boostrapping data", at least in the flow as described. In particular this seems rather dicey in the context of Section 4.6 of draft-ietf-httpbis-bcp56bis. It feels like this RPC exchange is essentially redefining the HTTP status code and expecting this specific application to execute a specific behavior in response to that status code, specifically, a specific behavior that is not the normal HTTP semantics for that status code. BCP56bis goes so far as to state that "Applications using HTTP MUST NOT re-specify the semantics of HTTP status codes, even if it is only by copying their definition." I would like to get a better understanding of why it was deemed necessary to introduce this behavior into the get-bootstrapping-data RPC, rather than defining a new RPC for the new functionality. Thanks, Ben From nobody Tue Dec 21 09:55:33 2021 Return-Path: <0100017dde220d3d-4be5f8d7-c4a8-4f45-81d9-0c80bfac77a2-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 228C63A10DA; Tue, 21 Dec 2021 09:55:20 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ljKzZRvAFQ_l; Tue, 21 Dec 2021 09:55:15 -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 9D83B3A10D8; Tue, 21 Dec 2021 09:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1640109313; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=N7Sp8YNSU6ZIsUQKDcro3FNzRWkajtPcg/0OOYz4uYo=; b=C39FSLxvb/MxVWG+jqYfb4JaVPWfFMR8Y24WXNC50Wy2bEpXQX2EH9oVSk5STn+e +idHUhErBF4nkwF9mLaus7XE+px5UYHpsgeSJ85ABD43ngaS8B7B+nTuo0oi4YZ3grT kEce36UMV+CxVi+3AR9QyuPIETO3W5DAGyyKMNP0= From: Kent Watsen Message-ID: <0100017dde220d3d-4be5f8d7-c4a8-4f45-81d9-0c80bfac77a2-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1BDD9919-D028-49B3-8B0E-3C105A81CFD1" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 21 Dec 2021 17:55:13 +0000 In-Reply-To: <163952699208.6437.8936066509149136808@ietfa.amsl.com> Cc: The IESG , draft-ietf-netconf-sztp-csr@ietf.org, "netconf-chairs@ietf.org" , "netconf@ietf.org" To: Benjamin Kaduk References: <163952699208.6437.8936066509149136808@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.21-54.240.48.95 Archived-At: Subject: Re: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2021 17:55:21 -0000 --Apple-Mail=_1BDD9919-D028-49B3-8B0E-3C105A81CFD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben, Thank you for your thoughtful review. Responses to your comments are = below. Also, diffs are here: = https://github.com/netconf-wg/sztp-csr/commit/ee5b28d35ec26c895ce4691f85af= fd1487d51f3e = . Best regards, Kent (and Russ and Sean) > On Dec 14, 2021, at 7:09 PM, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-netconf-sztp-csr-12: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for this document; it seems useful to have the flexibility to > specify a CSR and get an LDevID during enrollment. >=20 > I had a similar concern as Zahed's Discuss point (though I'm not sure > I can really express my concerns very well yet), and will attempt to = follow > the discussion thereof. Zahed=E2=80=99s discuss is ongoing, but I think we=E2=80=99re just an = edit away now. >=20 > Section 2.1 >=20 > Why do we need the "sztp-csr" namespace prefix on the new nodes in the > get-bootstrapping-data example, but not need the "ietf-sztp-csr" = prefix > on the nodes in the ietf-restconf/errors example? You write =E2=80=9Cexample=E2=80=9D but I think you mean =E2=80=9Ctree = diagrams=E2=80=9D. The tree-diagram at the top of page 7 is stitched = together via some scripts. Technically, the parent node, = "error-info=E2=80=9D, is of type =E2=80=9Cyang:anydata=E2=80=9D, which = is a YANG for =E2=80=9Canything, no data model needed, can go here=E2=80=9D= , which means what is there now isn=E2=80=99t wrong. That said, your = observation is valid, the dichotomy is stark. I have updated the = scripts to prefix all those nodes the same as in the earlier tree = diagram. Since you cannot see what it looks like from the GitHub diff, = the new rendered view follows: module: ietf-restconf +--ro errors +--ro error* [] +--ro error-type enumeration +--ro error-tag string +--ro error-app-tag? string +--ro error-path? instance-identifier +--ro error-message? string +--ro error-info +--ro sztp-csr:csr-request +--ro sztp-csr:key-generation! | +--ro sztp-csr:selected-algorithm | +--ro sztp-csr:algorithm-identifier binary +--ro sztp-csr:csr-generation | +--ro sztp-csr:selected-format | +--ro sztp-csr:format-identifier identityref +--ro sztp-csr:cert-req-info? ct:csr-info > Section 2.3 >=20 > description > "Provides the CSR generated by the SZTP-client. >=20 > When present, the SZTP-server SHOULD respond with > an SZTP onboarding information message containing > a signed certificate for the conveyed CSR. The > SZTP-server MAY alternatively respond with another > HTTP error containing another 'csr-request', in > which case the SZTP-client MUST invalidate the > previously generated CSR."; >=20 > I'm curious what is intended by "invalidate the [...] CSR". My > background on CSR usage hasn't really encountered a sense of = "validity" > for them that would need cancellation, since it's not really a = important > piece of information in its on right (just a way to ask a CA to do > something). The interesting bit is whether the CA actually issued > anything, but I'm not sure how much harm a stale CSR would actually > cause. The intention of =E2=80=9Cinvalidate=E2=80=9D was to, e.g., delete the = private key that may have been generated specifically for the previous = CSR. Thinking about this now, the authors are of the opinion that = deleting the private key is likely all that any SZTP-client could ever = do. That being the case, we suggest: OLD: the SZTP-client MUST invalidate the previously generated CSR. NEW: the SZTP-client MUST delete any key generated for the previously = generated CSR. Makes sense? > Section 3.2 >=20 > identity cmp-csr { > base certificate-request-format; > description > "Indicates that the ZTP-client supports generating > requests using a constrained version of the PKIMessage > containing a p10cr structure defined in RFC 4210."; >=20 > I'd probably spend a few more words to indicate the nature of the > constraints that cause us to say "constrained version". > (Likewise for the cmc-csr.) The authors think that =E2=80=9Cprofiled=E2=80=9D is a better word than = =E2=80=9Cconstrained=E2=80=9D, as so suggest: description "Indicates that the ZTP-client supports generating requests using a profiled version of the PKIMessage that MUST contain a PKIHeader followed by a PKIBody containing only the p10cr structure defined in RFC 4210."; Thoughts? > Enables the ZTP-server to provide a fully-populated > CertificationRequestInfo structure that the ZTP-client > only needs to sign in order to generate the complete > 'CertificationRequest' structure to send to ZTP-server > in its next 'get-bootstrapping-data' request message. >=20 > When provided, the ZTP-client SHOULD use this structure > to generate its CSR; failure to do so MAY result in a > 400 Bad Request response containing another 'csr-request' > structure. >=20 > This guidance seems to risk running afoul of the first rule of PKIs: > know what you sign. While I understand that the context for this > protocol exchange is a relatively "dumb" device getting onboarded into > the owner's deployment, and that the owner may in fact require some > things in the LDevID that were not coded into the device by its > implementors, I don't think we should stand mute on the security > considerations of asking for a certificate that contains > attributes/restrictions/etc. that are not understood. After a little discussion, the authors are unable to understand a = scenario where it makes sense that a ZTP-client would disregard and/or = decorate/extend the CertificationRequestInfo structure from the = ZTP-server. That being the case, we recommend s/SHOULD/MUST/ and = s/MAY/will/ as follows: When provided, the ZTP-client MUST use this structure to generate its CSR; failure to do so will result in a 400 Bad Request response containing another 'csr-request' structure. Better? > leaf cmc-csr { > type binary; > description > "A constrained version of the 'Full PKI Request' > message defined in RFC 5272, encoded using ASN.1 > distinguished encoding rules (DER), as specified > in ITU-T X.690. >=20 > (Same comment about "constrained version" as above.) The authors again think that =E2=80=9Cprofiled=E2=80=9D is a better word = than =E2=80=9Cconstrained=E2=80=9D, as so suggest: description "A profiled version of the 'Full PKI Request' message defined in RFC 5272, encoded using ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690. Thoughts? >=20 > For asymmetric key-based origin authentication based on > the initial device identity certificate's private key > that signs the encapsulated CSR signed by the local > device identity certificate's private key, the PKIData > contains one cmsSequence element and no > otherMsgSequence element. The cmsSequence is the ... >=20 > This part says nothing about whether there is a reqSequence element in > the toplevel PKIData... The authors propose: OLD: and no otherMsgSequence element.=20 NEW: and no controlSequence, reqSequence, or otherMsgSequence elements.=20= Good? >=20 > TaggedContentInfo and it includes a bodyPartID element > and a contentInfo. The contentInfo is a SignedData > encapsulating a PKIData with one reqSequence element > and no cmsSequence or otherMsgSequence elements. The > reqSequence is the TaggedRequest and it is the tcr > CHOICE. The tcr is the TaggedCertificationRequest and > it a bodyPartId and the certificateRequest elements. > [...] >=20 > ... since this reqSequence seems to refer to the PKIData inside the > SignedData in the contentInfo in the cmsSequence. Should we say > anything about the presence/absence of reqSequence in the toplevel > PKIData (since we do in the other two cases)? Yes, the authors propose: OLD: [=E2=80=A6] NEW: PKIData contains one cmsSequence element and no controlSequence, reqSequence, or otherMsgSequence elements. [=E2=80=A6] Good? > case cmp-csr { > leaf cmp-csr { > type binary; > description > [...] > For asymmetric key-based origin authentication of a > CSR based on the initial device identity certificate's > private key for the associated initial device identity > certificate's public key, PKIMessages contains one > PKIMessage with the header and body elements, no > protection element, and should contain the extraCerts > element. [...] >=20 > Is this a "should" or a "SHOULD"? Yes. Fixed. > For asymmetric key-based origin authentication based on > the initial device identity certificate's private key > that signs the encapsulated CSR signed by the local > device identity certificate's private key, PKIMessages > contains one PKIMessage with the header, body, and > protection elements, and should contain the extraCerts > element. [...] >=20 > (ditto) Also now a "SHOULD=E2=80=9D here. > Section 4 >=20 > I'd consider also mentioning the CMC, CMP, and PKCS#10 security > considerations as being applicable to the relevant CSR choices. Silly authors, we forgot the apple pie ;) We added: For the various CSR formats, when using PKCS#10, the security considerations in [RFC2986] apply, when using CMP, the security considerations in [RFC4210] apply and, when using CMC, the security considerations in [RFC5272] apply. > Section 4.1.1 >=20 > The security of this private key is essential in order to ensure the > associated identity certificate can be used as a root of trust. >=20 > "root of trust" is something of a loaded term (see the ongoing > discussion in the RATS WG for differing interpretations of what it > means). I'd suggest using a different phrasing, like "can be used to > authenticate the device it is issued to". Fix applied - thanks! > Section 4.1.3 >=20 > Should we mention the "nonce" parameter to get-bootstrapping-data > here? Hmmm, if we were to mention the =E2=80=9Cnonce=E2=80=9D parameter at = all, it would only be to say that it has *nothing* to do with the CSR = mechanism presented in this document=E2=80=A6or, at least it doesn=E2=80=99= t have any relation currently. To be clear, the =E2=80=9Cnonce=E2=80=9D = parameter is defined in RFC 8572 (SZTP) as follows: leaf nonce { type binary { length "16..32"; } description "This optional input parameter enables a device to communicate to the bootstrap server a nonce value. This may be especially useful for devices lacking an accurate clock, as then the bootstrap server can dynamically obtain from the manufacturer a voucher with the nonce value in it, as described in RFC 8366."; reference "RFC 8366: A Voucher Artifact for Bootstrapping Protocols"; } Thoughts? > When a public/private key pair associated with the manufacturer- > generated identity certificate (e.g., IDevID) is used for the > request, there may not be confirmation to the SZTP-client that the > response has not been replayed; however, the worst case result is a > lost certificate that is associated to the private key known only to > the SZTP-client. >=20 > That's only the worse-case result if we assume that the private key is > not compromised. We might want to reiterate that assumption and/or > mention the scope of consequences for the case where the private key = is > compromised. Good point. We appended the following to the end of the paragraph: Protection of the private-key information is vital to public-key cryptography. Disclosure of the private-key material to another entity can lead to masquerades. Better? > Section 4.2.2 >=20 > When a new asymmetric key is used, with the CMP or CMC formats, the > parent ASN.1 structure of the CSR provides origin authentication > using either the manufacturer-generated private key or a shared > secret. In this way the proof-of-possession of the CSR is directly > linked to the proof-or-origin provided by the parent ASN.1 = structure. >=20 > I think this section would be a good place to talk about how in the = "raw > PKCS#10" case, there needs to be a level of trust in the bootstrapping > server roughly analogous to how an RA would be trusted, in that they = are > the only entity that has verified the client identity and the > bootstrapping server's assertion of the client identity is a key step = in > the certificate issuance process. The authors propose replacing the paragraph above with the following: When the bootstrapping device's manufacturer-generated private key (e.g., the IDevID key) is reused for the CSR, proof-of-origin is verified by validating the IDevID certification path and ensuring = that the CSR uses the same key pair. When a fresh asymmetric key is used with the CMP or CMC formats, = the authentication is part of the protocols, which could employ either the manufacturer-generated private key or a shared secret. In = addition, CMP and CMC support processing by a RA before the request is passed to the CA, which allows for more robust handling of errors. Thoughts? > Such discussion might also contrast use of the IDevID at the TLS layer > with HTTP-layer authentication of the client. The authors believe this is best addressed with more =E2=80=9Capple = pie=E2=80=9D in the top-level of Section 4 (Security Considerations): For the various authentication mechanisms, when using TLS-level authentication, the security considerations in [RFC8446] apply and, when using HTTP-level authentication, the security considerations in [RFC7235] apply. Would this satisfy your discuss? > Section 4.4 >=20 > Though our "identity" and "grouping" statements (as noted) to not = appear > in any protocol-accessible nodes as-is, we might still feel empowered = to > discuss any considerations that would apply when they actually are > instantiated in other modules. However, it seems that there would not > be anything new to say other than what's in RFCs 2986, 4210, and 5272, > and if we take my suggestion to reference them from the toplevel > section 4, there would be no need to do so again here. We put the =E2=80=9Capple pie=E2=80=9D into the top-level of Section 4. > NITS >=20 > Abstract, Introduction >=20 > I'd consider clarifying that when we "extend" the = get-bootstrapping-data > RPC to include a CSR, that's as the input to the RPC, not the output. > (I initially misread it when reading the abstract.) Done. > Section 2.2 >=20 > You may want to use more-recent dates than 2015 for the examples. Done. > I suggest using different "BASE64VALUE=3D"s for the different public > keys in the two-asymmetric-key example. Not fixed, given: 1.4. Conventions Various examples used in this document use a placeholder value for binary data that has been base64 encoded (e.g., "BASE64VALUE=3D"). This placeholder value is used as real base64 encoded structures are often many lines long and hence distracting to the example being presented. > Section 3.2 >=20 > leaf-list algorithm-identifier { > type binary; > min-elements 1; > description > "An AlgorithmIdentifier, as defined in RFC 2986, > encoded using ASN.1 distinguished encoding rules > (DER), as specified in ITU-T X.690."; >=20 > At risk of excessive pedanticism, I see RFC 2986 discuss the > parametrized AlgorithmIdentifier{}, which compares it to the > unparameterized AlgorithmIdentifier in the ensuing discussion. > AlgorithmIdentifier is (also) defined in, e.g., RFC 5280 if we didn't > want to get into the parameterization here. (Any change made here > should be made throughout, of course.) Not fixed, since the document refs RFC 2986 for the CSR structure, so = having a forward ref to RFC 5280 doesn=E2=80=99t seem right to us. = Thoughts? > grouping csr-grouping { > description > "Enables a ZTP-client to convey a certificate signing > request, using the encoding format selected by a > ZTP-server's 'csr-request' response to the ZTP-client's > previously sent 'get-bootstrapping-data' request > containing the 'csr-support' node."; >=20 > (nit) Since we're (now) in just the ztp-types module, we can't > necessarily assume there will be a "get-bootstrapping-data" request > involved. Good catch. Fixed. > For asymmetric key-based origin authentication of a > CSR based on the initial device identity certificate's > private key for the associated identity certificate's > public key, the PKIData contains one reqSequence >=20 > (nit) I think the "associated identity certificate's public key" > phrasing here is a bit confusing. I think that we're trying to cover > the case where the key from the IDevID is reused for the LDevID, so > we're using the LDevID private key to authenticate the CSR and it's > sigining "it's own" public key", but in the context of this YANG > grouping we've mostly lost the context of the "associated identity > certificate". > (A similar comment applies to the CMP case.) Not fixed, due to complexity and that this is just a =E2=80=9Cnit=E2=80=9D= . More detail, one author wrote: "We have gone back and forth on the text a couple of times. I am not = sure I won=E2=80=99t just revert to what we had before. I will note = that if we make a change here we have to change it 6 different times, 3X = for CMC and 3X for CMP. The phrasing was specifically done this way and = amended along the way to make it clear which key is doing what. We got = three cases two are asymmetric-based and one is symmetric-based. We = needed to differentiate between the 1st two, and that convoluted text is = how we did it." > elements. The reqSequence is the TaggedRequest and it > is the tcr CHOICE. The tcr is the >=20 > (nit) should we have another word after "CHOICE", like "arm" or > "branch"? Done. used =E2=80=9Cbranch=E2=80=9D. > TaggedCertificationRequest and it a bodyPartId and the >=20 > (nit) also, I'd maybe s/the/a/ for these two "the is the " > constructions since they seem to just be describing the type of a = given > ASN.1 element. > Also, s/it/it is/. All done. > Section 4.1.1 >=20 > private keys. For instance, an NMS controller/orchestrator > application could periodically prompt the SZTP-client to generate a > new private key and provide a certificate signing request (CSR) or, > alternatively, push both the key and an identity certificate to the > SZTP-client using, e.g., a PKCS #12 [RFC7292]. [...] >=20 > maybe "a PKCS #12 message"? Fix applied. > Section 4.1.5 >=20 > The CMP and CMC certificate request formats defined in this document > support origin authentication. A raw PKCS#10 does not support = origin > authentication. >=20 > "PKCS#10 CSR" Done. Thanks again! Kent (and Russ and Sean) --Apple-Mail=_1BDD9919-D028-49B3-8B0E-3C105A81CFD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ben,

Thank you for = your thoughtful review.  Responses to your comments are = below.

Also, = diffs are here: https://github.com/netconf-wg/sztp-csr/commit/ee5b28d35ec26c895= ce4691f85affd1487d51f3e.

Best regards,
Kent = (and Russ and Sean)


On Dec = 14, 2021, at 7:09 PM, Benjamin Kaduk via Datatracker <noreply@ietf.org> = wrote:

Benjamin Kaduk has entered the following ballot position = for
draft-ietf-netconf-sztp-csr-12: No Objection

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/for more information about how to handle DISCUSS and = COMMENT positions.


The = document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Thanks for this document; it seems = useful to have the flexibility to
specify a CSR and get an = LDevID during enrollment.

I had a similar = concern as Zahed's Discuss point (though I'm not sure
I = can really express my concerns very well yet), and will attempt to = follow
the discussion thereof.




Section 2.1

Why = do we need the "sztp-csr" namespace prefix on the new nodes in the
get-bootstrapping-data example, but not need the = "ietf-sztp-csr" prefix
on the nodes in the = ietf-restconf/errors example?

You = write =E2=80=9Cexample=E2=80=9D but I think you mean =E2=80=9Ctree = diagrams=E2=80=9D.  The tree-diagram at the top of page 7 is = stitched together via some scripts.  Technically, the parent node, = "error-info=E2=80=9D, is of type =E2=80=9Cyang:anydata=E2=80=9D, which = is a YANG for =E2=80=9Canything, no data model needed, can go here=E2=80=9D= , which means what is there now isn=E2=80=99t wrong.  That said, = your observation is valid, the dichotomy is stark.  I have updated = the scripts to prefix all those nodes the same as in the earlier tree = diagram.  Since you cannot see what it looks like from the GitHub = diff, the new rendered view follows:

   module: = ietf-restconf
     +--ro errors
        +--ro error* []
           +--ro = error-type       enumeration
 =          +--ro error-tag      =   string
          =  +--ro error-app-tag?   string
  =          +--ro error-path?    =   instance-identifier
      =      +--ro error-message?   string
           +--ro error-info
              +--ro = sztp-csr:csr-request
          =        +--ro sztp-csr:key-generation!
                =  |  +--ro sztp-csr:selected-algorithm
  =                |   =   +--ro sztp-csr:algorithm-identifier  =   binary
          =        +--ro sztp-csr:csr-generation
                =  |  +--ro sztp-csr:selected-format
  =                |   =   +--ro sztp-csr:format-identifier  =   identityref
          =        +--ro sztp-csr:cert-req-info?  =   ct:csr-info




Section 2.3

=           description =             "P= rovides the CSR generated by the SZTP-client.

=             &n= bsp;When present, the SZTP-server SHOULD respond with
=             &n= bsp;an SZTP onboarding information message containing
=             &n= bsp;a signed certificate for the conveyed CSR.  The
=             &n= bsp;SZTP-server MAY alternatively respond with another
=             &n= bsp;HTTP error containing another 'csr-request', in
=             &n= bsp;which case the SZTP-client MUST invalidate the
=             &n= bsp;previously generated CSR.";

I'm curious = what is intended by "invalidate the [...] CSR".  My
background on CSR usage hasn't really encountered a sense of = "validity"
for them that would need cancellation, since = it's not really a important
piece of information in its on = right (just a way to ask a CA to do
something).  The = interesting bit is whether the CA actually issued
anything, = but I'm not sure how much harm a stale CSR would actually
cause.

The intention of =E2=80=9Cinvalidate=E2=80=9D was = to, e.g., delete the private key that may have been generated = specifically for the previous CSR.  Thinking about this now, the = authors are of the opinion that deleting the private key is likely all = that any SZTP-client could ever do.  That being the case, we = suggest:

OLD: the SZTP-client MUST = invalidate the previously generated CSR.
NEW: the = SZTP-client MUST delete any key generated for the previously generated = CSR.

Makes = sense?



Section 3.2

=     identity cmp-csr {
=       base certificate-request-format;
      description
=         "Indicates that the = ZTP-client supports generating
=          requests using a = constrained version of the PKIMessage
=          containing a p10cr = structure defined in RFC 4210.";

I'd = probably spend a few more words to indicate the nature of the
constraints that cause us to say "constrained version".
(Likewise for the cmc-csr.)

The = authors think that =E2=80=9Cprofiled=E2=80=9D is a better word than = =E2=80=9Cconstrained=E2=80=9D, as so suggest:

   description
    =  "Indicates that the ZTP-client supports generating
      requests using a profiled version of the = PKIMessage
      that MUST contain a PKIHeader = followed by a PKIBody
      containing only the = p10cr structure defined in RFC 4210.";

Thoughts?



=            Enables = the ZTP-server to provide a fully-populated
=            Certific= ationRequestInfo structure that the ZTP-client
=            only = needs to sign in order to generate the complete
=            'Certifi= cationRequest' structure to send to ZTP-server
=            in its = next 'get-bootstrapping-data' request message.

=            When = provided, the ZTP-client SHOULD use this structure
=            to = generate its CSR; failure to do so MAY result in a
=            400 = Bad Request response containing another 'csr-request'
=            structur= e.

This guidance seems to risk running = afoul of the first rule of PKIs:
know what you sign. =  While I understand that the context for this
protocol = exchange is a relatively "dumb" device getting onboarded into
the owner's deployment, and that the owner may in fact = require some
things in the LDevID that were not coded into = the device by its
implementors, I don't think we should = stand mute on the security
considerations of asking for a = certificate that contains
attributes/restrictions/etc. = that are not understood.

After a little discussion, the authors are unable = to understand a scenario where it makes sense that a ZTP-client would = disregard and/or decorate/extend the CertificationRequestInfo structure = from the ZTP-server.  That being the case, we recommend = s/SHOULD/MUST/ and s/MAY/will/ as follows:

           When = provided, the ZTP-client MUST use this structure
  =          to generate its CSR; failure to do so = will result in a
          =  400 Bad Request response containing another 'csr-request'
           structure.

Better?



=           leaf cmc-csr = {
=             ty= pe binary;
=             de= scription
=             &n= bsp; "A constrained version of the 'Full PKI Request'
=             &n= bsp;  message defined in RFC 5272, encoded using = ASN.1
            =    distinguished encoding rules (DER), as = specified
        =        in ITU-T = X.690.

(Same comment about = "constrained version" as above.)


The authors again think that =E2=80=9Cprofiled=E2= =80=9D is a better word than =E2=80=9Cconstrained=E2=80=9D, as so = suggest:

    = description
  =           "A profiled version of the 'Full = PKI Request'
            =  message defined in RFC 5272, encoded using ASN.1
             distinguished = encoding rules (DER), as specified
      =        in ITU-T X.690.
Thoughts?




=             &n= bsp;  For asymmetric key-based origin authentication based = on
=             &n= bsp;  the initial device identity certificate's private key
=             &n= bsp;  that signs the encapsulated CSR signed by the local
=             &n= bsp;  device identity certificate's private key, the = PKIData
=             &n= bsp;  contains one cmsSequence element and no
=             &n= bsp;  otherMsgSequence element.  The cmsSequence is the = ...

This part says nothing about whether = there is a reqSequence element in
the toplevel = PKIData...

The authors propose:

OLD: and no otherMsgSequence = element. 
NEW: and  no controlSequence, reqSequence, = or otherMsgSequence elements. 




=             &n= bsp;  TaggedContentInfo and it includes a bodyPartID = element
=             &n= bsp;  and a contentInfo.  The contentInfo is a = SignedData
=             &n= bsp;  encapsulating a PKIData with one reqSequence element
=             &n= bsp;  and no cmsSequence or otherMsgSequence elements. The
=             &n= bsp;  reqSequence is the TaggedRequest and it is the tcr
=             &n= bsp;  CHOICE. The tcr is the TaggedCertificationRequest and
=             &n= bsp;  it a bodyPartId and the certificateRequest elements.
=             &n= bsp;  [...]

... since this = reqSequence seems to refer to the PKIData inside the
SignedData in the contentInfo in the cmsSequence. =  Should we say
anything about the presence/absence of = reqSequence in the toplevel
PKIData (since we do in the = other two cases)?

Yes, the authors propose:

OLD: [=E2=80=A6]

NEW:   PKIData contains one cmsSequence element and = no
            = controlSequence, reqSequence, or otherMsgSequence
            elements. = [=E2=80=A6]

Good?



        case cmp-csr = {
=           leaf cmp-csr = {
=             ty= pe binary;
=             de= scription
=             &n= bsp; [...]
=             &n= bsp;  For asymmetric key-based origin authentication of a
=             &n= bsp;  CSR based on the initial device identity = certificate's
=             &n= bsp;  private key for the associated initial device = identity
=             &n= bsp;  certificate's public key, PKIMessages contains one
=             &n= bsp;  PKIMessage with the header and body elements, no
=             &n= bsp;  protection element, and should contain the extraCerts
=             &n= bsp;  element. [...]

Is this a = "should" or a "SHOULD"?


Yes. =  Fixed.


=             &n= bsp;  For asymmetric key-based origin authentication based = on
=             &n= bsp;  the initial device identity certificate's private key
=             &n= bsp;  that signs the encapsulated CSR signed by the local
=             &n= bsp;  device identity certificate's private key, = PKIMessages
=             &n= bsp;  contains one PKIMessage with the header, body, and
=             &n= bsp;  protection elements, and should contain the = extraCerts
=             &n= bsp;  element. [...]

(ditto)

Also = now a "SHOULD=E2=80=9D here.



Section 4

I'd = consider also mentioning the CMC, CMP, and PKCS#10 security
considerations as being applicable to the relevant CSR = choices.

Silly authors, we forgot the apple pie =  ;)

We added:

   For the various CSR formats, when = using PKCS#10, the security
   considerations in = [RFC2986] apply, when using CMP, the security
  =  considerations in [RFC4210] apply and, when using CMC, the = security
   considerations in [RFC5272] = apply.



Section 4.1.1

  The = security of this private key is essential in order to ensure the
  associated identity certificate can be used as a = root of trust.

"root of trust" is something = of a loaded term (see the ongoing
discussion in the RATS = WG for differing interpretations of what it
means). =  I'd suggest using a different phrasing, like "can be used to
authenticate the device it is issued to".

Fix = applied - thanks!


Section 4.1.3

Should we mention = the "nonce" parameter to get-bootstrapping-data
here?

Hmmm, = if we were to mention the =E2=80=9Cnonce=E2=80=9D parameter at all, it = would only be to say that it has *nothing* to do with the CSR = mechanism presented in this document=E2=80=A6or, at least it = doesn=E2=80=99t have any relation currently.  To be clear, the = =E2=80=9Cnonce=E2=80=9D parameter is defined in RFC 8572 (SZTP) as = follows:

      leaf nonce {
        type binary {
  =         length "16..32";
    =     }
        description
          "This optional input = parameter enables a device to
        =    communicate to the bootstrap server a nonce value.
           This may be = especially useful for devices lacking
      =      an accurate clock, as then the bootstrap server
           can dynamically = obtain from the manufacturer a
        =    voucher with the nonce value in it, as described
           in RFC 8366.";
        reference
  =         "RFC 8366:
    =          A Voucher Artifact for Bootstrapping = Protocols";
      }

Thoughts?



  When a public/private key pair = associated with the manufacturer-
  generated = identity certificate (e.g., IDevID) is used for the
=   request, there may not be confirmation to the SZTP-client = that the
  response has not been replayed; = however, the worst case result is a
  lost = certificate that is associated to the private key known only to
  the SZTP-client.

That's only the worse-case result if we assume that the = private key is
not compromised.  We might want to = reiterate that assumption and/or
mention the scope of = consequences for the case where the private key is
compromised.

Good point.  We appended the following to the = end of the paragraph:

= Protection of the private-key information is vital to = public-key
cryptography.  Disclosure of = the private-key material to another
entity = can lead to masquerades.

Better?


Section 4.2.2

  When = a new asymmetric key is used, with the CMP or CMC formats, the
  parent ASN.1 structure of the CSR provides = origin authentication
  using either the = manufacturer-generated private key or a shared
=   secret.  In this way the proof-of-possession of the CSR = is directly
  linked to the proof-or-origin = provided by the parent ASN.1 structure.

I = think this section would be a good place to talk about how in the = "raw
PKCS#10" case, there needs to be a level of trust in = the bootstrapping
server roughly analogous to how an RA = would be trusted, in that they are
the only entity that = has verified the client identity and the
bootstrapping = server's assertion of the client identity is a key step in
the certificate issuance process.

The = authors propose replacing the paragraph above with the = following:

     When = the bootstrapping device's manufacturer-generated private key
     (e.g., the IDevID key) is reused for the = CSR, proof-of-origin is
     verified by = validating the IDevID certification path and ensuring that
     the CSR uses the same key pair.

     When a fresh asymmetric = key is used with the CMP or CMC formats, the
    =  authentication is part of the protocols, which could employ = either
     the manufacturer-generated = private key or a shared secret.  In addition,
  =    CMP and CMC support processing by a RA before the request = is passed
     to the CA, which allows for = more robust handling of errors.

Thoughts?



Such discussion might also contrast use of = the IDevID at the TLS layer
with HTTP-layer authentication = of the client.

The authors believe this is best addressed with = more =E2=80=9Capple pie=E2=80=9D in the top-level of Section 4 (Security = Considerations):

   For the various authentication = mechanisms, when using TLS-level
   authentication, the security considerations in [RFC8446] = apply and,
   when using HTTP-level = authentication, the security considerations in
   [RFC7235] apply.

Would this satisfy your discuss?



Section 4.4

Though our "identity" and "grouping" = statements (as noted) to not appear
in any = protocol-accessible nodes as-is, we might still feel empowered to
discuss any considerations that would apply when they = actually are
instantiated in other modules.  However, = it seems that there would not
be anything new to say other = than what's in RFCs 2986, 4210, and 5272,
and if we take = my suggestion to reference them from the toplevel
section = 4, there would be no need to do so again here.

We = put the =E2=80=9Capple pie=E2=80=9D into the top-level of Section = 4.


NITS

Abstract, Introduction

I'd consider clarifying that when we "extend" the = get-bootstrapping-data
RPC to include a CSR, that's as the = input to the RPC, not the output.
(I initially misread it = when reading the abstract.)

Done.



I suggest using different "BASE64VALUE=3D"s for the different = public
keys in the two-asymmetric-key example.

Not fixed, = given:

1.4.  Conventions

   Various examples used in this = document use a placeholder value for
   binary = data that has been base64 encoded (e.g., "BASE64VALUE=3D").
   This placeholder value is used as real base64 = encoded structures are
   often many lines long = and hence distracting to the example being
  =  presented.


Section 3.2

=             le= af-list algorithm-identifier {
=             &n= bsp; type binary;
=             &n= bsp; min-elements 1;
=             &n= bsp; description
=             &n= bsp;   "An AlgorithmIdentifier, as defined in RFC = 2986,
=             &n= bsp;    encoded using ASN.1 distinguished encoding = rules
=             &n= bsp;    (DER), as specified in ITU-T X.690.";

At risk of excessive pedanticism, I see RFC = 2986 discuss the
parametrized AlgorithmIdentifier{}, which = compares it to the
unparameterized AlgorithmIdentifier in = the ensuing discussion.
AlgorithmIdentifier is (also) = defined in, e.g., RFC 5280 if we didn't
want to get into = the parameterization here.  (Any change made here
should be made throughout, of course.)

Not = fixed, since the document refs RFC 2986 for the CSR structure, so having = a forward ref to RFC 5280 doesn=E2=80=99t seem right to = us.  Thoughts?


=     grouping csr-grouping {
=       description
=         "Enables a ZTP-client to = convey a certificate signing
=          request, using the = encoding format selected by a
=          ZTP-server's = 'csr-request' response to the ZTP-client's
=          previously sent = 'get-bootstrapping-data' request
=          containing the = 'csr-support' node.";

(nit) Since we're = (now) in just the ztp-types module, we can't
necessarily = assume there will be a "get-bootstrapping-data" request
involved.

Good catch.  Fixed.


=             &n= bsp;  For asymmetric key-based origin authentication of a
=             &n= bsp;  CSR based on the initial device identity = certificate's
=             &n= bsp;  private key for the associated identity certificate's
=             &n= bsp;  public key, the PKIData contains one reqSequence

(nit) I think the "associated identity = certificate's public key"
phrasing here is a bit = confusing.  I think that we're trying to cover
the = case where the key from the IDevID is reused for the LDevID, so
we're using the LDevID private key to authenticate the CSR = and it's
sigining "it's own" public key", but in the = context of this YANG
grouping we've mostly lost the = context of the "associated identity
certificate".
(A similar comment applies to the CMP case.)

Not = fixed, due to complexity and that this is just a =E2=80=9Cnit=E2=80=9D. =  More detail, one author wrote:

"We = have gone back and forth on the text a couple of times. I am not sure I = won=E2=80=99t just revert to what we had before.  I will note that = if we make a change here we have to change it 6 different times, 3X = for CMC and 3X for CMP. The phrasing was specifically done this = way and amended along the way to make it clear which key is doing = what.  We got three cases two are asymmetric-based and one = is symmetric-based. We needed to differentiate between the 1st two, = and that convoluted text is how we did it."


=             &n= bsp;  elements. The reqSequence is the TaggedRequest and it
=             &n= bsp;  is the tcr CHOICE. The tcr is the

(nit) should we have another word after "CHOICE", like "arm" = or
"branch"?
Done. used =E2=80=9Cbranch=E2=80=9D.


=             &n= bsp;  TaggedCertificationRequest and it a bodyPartId and = the

(nit) also, I'd maybe s/the/a/ for = these two "the <foo> is the <bar>"
constructions= since they seem to just be describing the type of a given
ASN.1 element.
Also, s/it/it is/.

All = done.


Section = 4.1.1

  private keys.  For = instance, an NMS controller/orchestrator
=   application could periodically prompt the SZTP-client to = generate a
  new private key and provide a = certificate signing request (CSR) or,
=   alternatively, push both the key and an identity certificate = to the
  SZTP-client using, e.g., a PKCS #12 = [RFC7292].  [...]

maybe "a PKCS #12 = message"?

Fix applied.






= --Apple-Mail=_1BDD9919-D028-49B3-8B0E-3C105A81CFD1-- From nobody Tue Dec 21 11:27:57 2021 Return-Path: <0100017dde769ef9-5c13468b-5266-47c3-8795-62735658c3be-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 E910E3A1289; Tue, 21 Dec 2021 11:27:43 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 nx4Epm6c7Ujt; Tue, 21 Dec 2021 11:27:42 -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 210213A07F5; Tue, 21 Dec 2021 11:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1640114856; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=f5ivYxw7krGq1WiifK5i6SnvyarL9r1zO/zzjCF0h/0=; b=aZazmuDMDuffwoFdmAFDQbPZUCmEECXen8W8cFzlm1j+6p/X/3vMH0d2k4GW8V12 Nc72YhsLuWLMPzYPP7r9aM+qJO0wkO0JqrQIrwEUUiVXDJSAFxhEfuABq/vNhWZPEoe iFDL7JViuo3E5McqHmI7rCtEZzqLJ3Za5nH1MCl4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Kent Watsen In-Reply-To: <163966808813.12195.18438122593101389552@ietfa.amsl.com> Date: Tue, 21 Dec 2021 19:27:35 +0000 Cc: The IESG , draft-ietf-netconf-sztp-csr@ietf.org, "netconf-chairs@ietf.org" , "netconf@ietf.org" , Mahesh Jethanandani Content-Transfer-Encoding: quoted-printable Message-ID: <0100017dde769ef9-5c13468b-5266-47c3-8795-62735658c3be-000000@email.amazonses.com> References: <163966808813.12195.18438122593101389552@ietfa.amsl.com> To: Murray Kucherawy X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.21-54.240.8.31 Archived-At: Subject: Re: [netconf] Murray Kucherawy's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2021 19:27:44 -0000 Hi Murray, Thank you for your review. Below is a response to you comment. Thanks again, Kent (and Russ and Sean) > On Dec 16, 2021, at 10:21 AM, Murray Kucherawy via Datatracker = wrote: >=20 > Murray Kucherawy has entered the following ballot position for > draft-ietf-netconf-sztp-csr-12: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The media types in the examples should be = "application/yang-data+json", I > believe. There's currently "yang.data" instead of "yang-data=E2=80=9D. Correct! This typo was fixed as part of Zahed=E2=80=99s review. K. From nobody Tue Dec 21 12:05:17 2021 Return-Path: <0100017dde9900c3-5a02bbf7-1188-4b56-ad5b-7adc1705faac-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 498A53A12C1; Tue, 21 Dec 2021 12:05:15 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 LA7zHjmNzrCH; Tue, 21 Dec 2021 12:05:11 -0800 (PST) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F82D3A12C0; Tue, 21 Dec 2021 12:05:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1640117109; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=YUzrFZltPRwJ21XLf6DOvqRFNZS4xCHrLiXs/Z6gkns=; b=TRwt2YzCbLY7iPN9YMXWm4E1c8VOqGcmkLevwieepHpHGM4BVaN7ZN3yvon1cHaH m1tpLURcrVgC4eSZPZC5iSCwidPhFFFnqjaKtsjN8V8C1c7F23TR2Pq7wAvPJXXoS88 aMdpFsBHffTxOT/D80UbI3wiLV8WqHvw9KaTjGTQ= From: Kent Watsen Message-ID: <0100017dde9900c3-5a02bbf7-1188-4b56-ad5b-7adc1705faac-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F91CBDB4-D39D-4418-9E8B-CD65401DF9C6" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 21 Dec 2021 20:05:08 +0000 In-Reply-To: <163961310503.29838.2930717052258225050@ietfa.amsl.com> Cc: The IESG , draft-ietf-netconf-sztp-csr@ietf.org, "netconf-chairs@ietf.org" , "netconf@ietf.org" , Mahesh Jethanandani To: Roman Danyliw References: <163961310503.29838.2930717052258225050@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.21-54.240.48.110 Archived-At: Subject: Re: [netconf] Roman Danyliw's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2021 20:05:16 -0000 --Apple-Mail=_F91CBDB4-D39D-4418-9E8B-CD65401DF9C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Roman, Thank you for your review! Below are responses to your comments. Diffs: = https://github.com/netconf-wg/sztp-csr/commit/f31f47932f60b88a746b8ec7a26a= 6f00986355e9 = Kent (and Sean and Russ) > On Dec 15, 2021, at 7:05 PM, Roman Danyliw via Datatracker = wrote: >=20 > Roman Danyliw has entered the following ballot position for > draft-ietf-netconf-sztp-csr-12: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you to Yaron Sheffer for the SECDIR review. >=20 > ** Section 4.1.1. >=20 > For instance, an NMS controller/orchestrator > application could periodically prompt the SZTP-client to generate a > new private key and provide a certificate signing request (CSR) or, > alternatively, push both the key and an identity certificate to the > SZTP-client using, e.g., a PKCS #12 [RFC7292]. >=20 > I don=E2=80=99t have a sense of the classes of endpoints that would = rely on SZTP.=20 > Would it include highly constrained or battery powered devices for = which this > re-keying would be too expensive? Possibly. For the most part, IoT deployments seem to be going to BRSKI = route (though that isn=E2=80=99t any more efficient in this regrade). = All of the SZTP deployments I=E2=80=99m aware of are easily able to = generate fresh keying material. But note that, if extreme cases, the = material could be pushed to the device via a p12, which obviates = concern, no? [No update to the draft has been made to reflect this comment yet.] >=20 > ** Editorial nits: > -- Section 2.1. s/an new/a new/ Fixed! (Change made by an earlier review) > -- Section 2.2. Typo. s/Following are/The following are/ Instead used s/Following are/Below are/ - otherwise okay to let copy = editor handle? > -- Section 4.1.1. s/Forever contain/contain/ Fixed! --Apple-Mail=_F91CBDB4-D39D-4418-9E8B-CD65401DF9C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Roman,

Thank you for = your review!   Below are responses to your comments.

Diffs: https://github.com/netconf-wg/sztp-csr/commit/f31f47932f60b88a7= 46b8ec7a26a6f00986355e9

Kent (and Sean and Russ)


On Dec 15, 2021, at 7:05 PM, Roman Danyliw via Datatracker = <noreply@ietf.org> wrote:

Roman = Danyliw has entered the following ballot position for
draft-ietf-netconf-sztp-csr-12: No Objection

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/for more information about how to handle DISCUSS and = COMMENT positions.


The = document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Thank you to Yaron Sheffer for the = SECDIR review.

** Section 4.1.1.

For instance, an NMS = controller/orchestrator
  application could = periodically prompt the SZTP-client to generate a
=   new private key and provide a certificate signing request = (CSR) or,
  alternatively, push both the key = and an identity certificate to the
=   SZTP-client using, e.g., a PKCS #12 = [RFC7292].

I don=E2=80=99t = have a sense of the classes of endpoints that would rely on SZTP.
Would it include highly constrained or battery powered = devices for which this
re-keying would be too = expensive?






= --Apple-Mail=_F91CBDB4-D39D-4418-9E8B-CD65401DF9C6-- From nobody Tue Dec 21 15:10:41 2021 Return-Path: <0100017ddf42725e-8ad53772-3b60-42bf-8244-74c2301001b9-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 96AF83A1450; Tue, 21 Dec 2021 15:10: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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 gtU5fpy7Qv97; Tue, 21 Dec 2021 15:10:16 -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 72BAB3A144F; Tue, 21 Dec 2021 15:10:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1640128213; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=IaGPz6DnQUHLP5BHMJcQxdUnbZtsZVhCssL+ZnGPUyU=; b=Ft2K63BLF35wn7exMRV3hrVKuv3D7SoDVCEj0f3Ii3Qp9D958P68pXnRrSTt4Znq wp2pkQltLD/m9tuqTqEejOYgZfqJ1Pt9U1tHyMOCoP74LwnLGodCCigV0gCvLomAhBq jiPIHt/pg/G44WYFAtsHlCPBs85sV6OjSAKYujvM= From: Kent Watsen Message-ID: <0100017ddf42725e-8ad53772-3b60-42bf-8244-74c2301001b9-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_611776ED-074F-4E95-925A-6BE272A19F3E" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 21 Dec 2021 23:10:13 +0000 In-Reply-To: <40468B1C-773D-46C0-8386-735478F8B04E@ericsson.com> Cc: The IESG , "draft-ietf-netconf-sztp-csr@ietf.org" , "netconf-chairs@ietf.org" , "netconf@ietf.org" To: Zaheduzzaman Sarker References: <163948820661.12873.16286675430659744022@ietfa.amsl.com> <0100017dbb6de6a8-503b8aaa-031f-4c2c-bca4-79eaec0fbff7-000000@email.amazonses.com> <40468B1C-773D-46C0-8386-735478F8B04E@ericsson.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.21-54.240.8.88 Archived-At: Subject: Re: [netconf] Zaheduzzaman Sarker's Discuss on draft-ietf-netconf-sztp-csr-12: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2021 23:10:22 -0000 --Apple-Mail=_611776ED-074F-4E95-925A-6BE272A19F3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Zahed, >> This comment would have been good when RFC 8040 was being published, = but >> now it is water over the bridge, so to speak. Agreed? > Ok I get it. I am now thinking if it is worth mention this fact in the = draft. My main point was that RFC7807 is more a generic HTTP way to send = details about problem which this specification is using hence might need = motivation for why not RFC 7807 is used, specially looking the = discussion on this topic in the mailing list.=20 As to if it is if it worth mention, I think not. Again, the encoding = used by this draft is solely at the whims of RFC 8040. It seems that = Ben agrees. I=E2=80=99ll assume this comment is closed, and resulting = in no action to update the draft. >> Good? > Very good. Thank you! > //Zahed Kent // co-author --Apple-Mail=_611776ED-074F-4E95-925A-6BE272A19F3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Zahed,

This comment would have been good when RFC 8040 was being published, = but
now it is water over the bridge, so to speak. =  Agreed?
Ok I get it. I am now thinking if it is worth mention this fact in the = draft. My main point was that RFC7807 is more a generic HTTP way to send = details about problem which this specification is using hence might need = motivation for why not RFC 7807 is used, specially looking the = discussion on this topic in the mailing = list. 

As to if it is if it worth mention, I think not. =  Again, the encoding used by this draft is solely at the whims of = RFC 8040.   It seems that Ben agrees.   I=E2=80=99ll assume = this comment is closed, and resulting in no action to update the = draft.


Good?
Very = good.

Thank = you!


//Zahed

Kent // co-author


= --Apple-Mail=_611776ED-074F-4E95-925A-6BE272A19F3E-- From nobody Wed Dec 22 04:10:19 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04CC3A08ED for ; Wed, 22 Dec 2021 04:10:17 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 hzh24ooWE1nU for ; Wed, 22 Dec 2021 04:10:14 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FAC13A08D9 for ; Wed, 22 Dec 2021 04:10:14 -0800 (PST) Received: from fraeml735-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JJsXD3y0Kz6H7kF for ; Wed, 22 Dec 2021 20:07:40 +0800 (CST) Received: from canpemm500006.china.huawei.com (7.192.105.130) by fraeml735-chm.china.huawei.com (10.206.15.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 22 Dec 2021 13:10:10 +0100 Received: from canpemm500005.china.huawei.com (7.192.104.229) by canpemm500006.china.huawei.com (7.192.105.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 22 Dec 2021 20:10:08 +0800 Received: from canpemm500005.china.huawei.com ([7.192.104.229]) by canpemm500005.china.huawei.com ([7.192.104.229]) with mapi id 15.01.2308.020; Wed, 22 Dec 2021 20:10:08 +0800 From: Qin Wu To: "netconf@ietf.org" Thread-Topic: List Pagination Open Issue #2: Zero vs Unknown Thread-Index: Adf3KiwysxPxBi5tRoOwaT0x5b2DYA== Date: Wed, 22 Dec 2021 12:10:08 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.100.16] Content-Type: multipart/alternative; boundary="_000_e4ad42acb7f145acb34b75f4277fc2fdhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netconf] List Pagination Open Issue #2: Zero vs Unknown 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 Dec 2021 12:10:18 -0000 --_000_e4ad42acb7f145acb34b75f4277fc2fdhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, All: One of issues we brought up in IETF 112 is about usage of The 'remaining 'a= nnotation. The 'remaining 'annotation defined in our drafts is used to return the numb= er of elements not included in a result set after a 'limit' or 'sublist-lim= it' operation. The current draft (i.e., draft-wwlh-netconf-list-pagination) states that: "If no elements were removed, this annotation MUST NOT appear. The minimum value (0), which never occurs in normal operation, is reserved = to represent 'unknown'. " But one best practice proposed by our design team member is: * No more entries ---> Return zero * Unknown ---> Not return the "remaining" annotation at all Talking with design team members, we believe that when NO entries are retur= ned in the RPC-reply, NO annotation can be returned (because RFC 7952 says = the annotation must be in the first element of the list, but there would be no first element.) The question is whether the "remaining" annotation should be always present= or whether there is a case which it MAY not appear. If we allow it to NOT = appear in those cases, it would only be reasonable to do so when there are = no more elements, as that would similar to existing list retrievals (i.e. y= ou get everything and there is no "remaining" annotation). Here is our proposed solution to address this issue. 1.Change 'MUST' into 'May' in the draft-wwlh-netconf-list-pagination as fol= lows: OLD TEXT: " If no elements were removed, this annotation MUST NOT appear. " NEW TEXT: " If no elements were removed, this annotation MAY NOT appear. " Add 'none' enumeration as follows md:annotation remaining { type union { type uint32; type enumeration { enum "none" { description "Indicates that there are no entries that were not Included in the result set, due to a 'limit' or 'sublist-limit' operation.."; } enum "unknown" { description "Indicates that number of remaining entries is unknown to the server in case, e.g., the server has determined that counting would be prohibitively expensive."; } } } description "This annotation contains the number of elements not included in the result set due to a 'limit' or 'sublist-limit' operation. If no elements were removed, either the annotation MAY be missing or MUST have the value '0' or 'none'. If it is unknown to the server how many entries may be returned, the value 'unknown' MUST be returned. The maximum value (2^32-1) is reserved to represent any value greater than or equal to 2^32-1 elements."; } Comments and suggestions are welcome! -Qin (On behalf of authors) --_000_e4ad42acb7f145acb34b75f4277fc2fdhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, = All:

One = of issues we brought up in IETF 112 is about usage of The ‘remaining = 'annotation.

The = ‘remaining 'annotation defined in our drafts is used to return the nu= mber of elements not included in a result set after a 'limit' or 'sublist-l= imit' operation.

The = current draft (i.e., draft-wwlh-netconf-list-pagination) states that:<= /o:p>

R= 20;If no elements were removed, this annotation MUST NOT appear.=

The = minimum value (0), which never occurs in normal operation, is reserved to r= epresent 'unknown'. ”

 

But = one best practice proposed by our design team member is:<= /p>

R= 26; No more entries ---> Return zero

R= 26; Unknown ---> Not return the "remaining" annotation at all<= o:p>

 

Talk= ing with design team members, we believe that when NO entries are returned = in the RPC-reply, NO annotation can be returned (because RFC 7952 says the = annotation must be in the first element of the list,

but = there would be no first element.)

The = question is whether the “remaining” annotation should be always= present or whether there is a case which it MAY not appear. If we allow it= to NOT appear in those cases, it would only be reasonable to do so when there are no more elements, as that would similar to existin= g list retrievals (i.e. you get everything and there is no “remaining= ” annotation).

 

Here= is our proposed solution to address this issue.

1.Ch= ange ‘MUST’ into ‘May’ in the draft-wwlh-netconf-li= st-pagination as follows:

OLD = TEXT:

R= 20;

If n= o elements were removed, this annotation MUST NOT appear.=

R= 21;

NEW = TEXT:

R= 20;

If n= o elements were removed, this annotation MAY NOT appear.<= /p>

R= 21;

Add = ‘none’ enumeration as follows

&nbs= p;    md:annotation remaining {

&nbs= p;      type union {

&nbs= p;        type uint32;

&nbs= p;        type enumeration {

&nbs= p;          enum “none" {

&nbs= p;            description

&nbs= p;              "Indicates that the= re are no entries that were not

&nbs= p;                Included in the r= esult set, due to a 'limit' or

&nbs= p;                'sublist-limit' o= peration..";

&nbs= p;          }

&nbs= p;          enum "unknown" {<= /span>

&nbs= p;            description

&nbs= p;              "Indicates that num= ber of remaining entries is unknown

&nbs= p;               to the server in case, = e.g., the server has determined

&nbs= p;               that counting would be = prohibitively expensive.";

&nbs= p;          }

&nbs= p;        }

&nbs= p;      }

&nbs= p;      description

&nbs= p;        "This annotation contains the number of = elements not included

&nbs= p;         in the result set due to a 'limit’= ; or 'sublist-limit’ operation.

&nbs= p;         If no elements were removed, either the anno= tation MAY be

&nbs= p;         missing or MUST have the value ‘0= ’ or ‘none’.  If it is unknown

&nbs= p;         to the server how many entries may be r= eturned, the value

&nbs= p;         ‘unknown’ MUST be returned.=  The maximum value (2^32-1) is

&nbs= p;         reserved to represent any value greater than=  or equal to

&nbs= p;         2^32-1 elements.";

&nbs= p;    }

Comm= ents and suggestions are welcome!

 

-Qin= (On behalf of authors)

--_000_e4ad42acb7f145acb34b75f4277fc2fdhuaweicom_-- From nobody Wed Dec 22 04:11:47 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0C33A08ED for ; Wed, 22 Dec 2021 04:11:46 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 5S1usXgLyUFd for ; Wed, 22 Dec 2021 04:11:41 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE533A08D9 for ; Wed, 22 Dec 2021 04:11:41 -0800 (PST) Received: from fraeml737-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JJsYv4mqwz6H7kF for ; Wed, 22 Dec 2021 20:09:07 +0800 (CST) Received: from canpemm500005.china.huawei.com (7.192.104.229) by fraeml737-chm.china.huawei.com (10.206.15.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 22 Dec 2021 13:11:37 +0100 Received: from canpemm500005.china.huawei.com (7.192.104.229) by canpemm500005.china.huawei.com (7.192.104.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 22 Dec 2021 20:11:35 +0800 Received: from canpemm500005.china.huawei.com ([7.192.104.229]) by canpemm500005.china.huawei.com ([7.192.104.229]) with mapi id 15.01.2308.020; Wed, 22 Dec 2021 20:11:35 +0800 From: Qin Wu To: "netconf@ietf.org" Thread-Topic: List Pagination Open Issue #1: Cusor Support Thread-Index: Adf3KOSj2qzNrEwqTmO7FsAglZpR3Q== Date: Wed, 22 Dec 2021 12:11:35 +0000 Message-ID: <66ef8ad4d3fa4300a968ad10363f3bac@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.100.16] Content-Type: multipart/alternative; boundary="_000_66ef8ad4d3fa4300a968ad10363f3bachuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netconf] List Pagination Open Issue #1: Cusor Support 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 Dec 2021 12:11:47 -0000 --_000_66ef8ad4d3fa4300a968ad10363f3bachuaweicom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEFsbDoNCkluIGRyYWZ0LXd3bGgtbmV0Y29uZi1saXN0LXBhZ2luYXRpb24tMDCjrHdlIGRl ZmluZSBmaXZlIHF1ZXJ5IHBhcmFtZXRlcnMgZm9yIGxpc3QgcGFnaW5hdGlvbiBhbmQgT25lIHF1 ZXJ5IHBhcmFtZXRlciBmb3IgZGVzY2VuZGFudCBsaXN0IHBhZ2luYXRpb24uIFRoZXNlIHF1ZXJ5 IHBhcmFtZXRlcnMgcHJvdmlkZSBvZmZzZXQgYmFzZWQgbGlzdCBwYWdpbmF0aW9uLg0KT25lIG9m IGZlYXR1cmVzIHdlIHdvdWxkIGxpa2UgdG8gaW52ZXN0aWdhdGUgaXMgY3Vyc29yIHN1cHBvcnQs IHdoaWNoIGhhcyBiZWVuIGJyb3VnaHQgdXAgaW4gSUVURiAxMTIgTkVUQ09ORiB2aXJ0dWFsIG1l ZXRpbmc6DQpGb3Igc2VydmVyIHcvIGN1cnNvciBzdXBwb3J0Og0KKiBJdCBFbmFibGVzIHRoZSBw YWdpbmcgdG8gY29udGludWUgb3ZlciB0aGUgc25hcHNob3QsIGRlc3BpdGUgdGhlIGRhdGFzZXQg Y2hhbmdpbmcuDQoqIFRoZSBjbGllbnQgYXNzdW1lcyB0aGUgbGlzdCBkb2VzbqGvdCBjaGFuZ2U7 DQpiLiAgRm9yIHNlcnZlciB3L28gY3Vyc29yIG9yIHNuYXBzaG90IHN1cHBvcnQ6DQoqIFRoZSBz ZXJ2ZXIgbWlnaHQgcmV0dXJuIGxhcmdlciByZW1haW5pbmcgdmFsdWUgdGhhbiBwcmV2aW91cyBm ZXRjaCBkdXJpbmcgcmVmZXRjaGluZyBwYWdlIGluIGEgdGltZSBzZXJpZXMgbG9nICh3aGVyZSBs b2dzIGFyZSBhcHBlbmRlZCkuDQpjLiAgRm9yIGNvbmZpZywgc29tZSBwcm90b2NvbHMgc3VwcG9y dCBsb2NrcyAodG8gcHJldmVudCBvdXQtb2YtYmFuZCBjaGFuZ2VzKSwgd2hpbGUgb3RoZXJzIHN1 cHBvcnQgdGFnL3RpbWVzdGFtcHMgKGVuYWJsaW5nIG91dC1vZi1iYW5kIGNoYW5nZXMgdG8gdGhl IGRldGVjdGVkKSwgc28gdGhlIGlzc3VlIGlzIGVmZmVjdGl2ZWx5IGxpbWl0ZWQgdG8gb3BzdGF0 ZSBsaXN0cy4NCkJhc2VkIG9uIHRoZSBhYm92ZSBvdXIgYW5hbHlzaXMsIGl0IGxvb2tzIHdlIGRv bqGvdCBoYXZlIGNvbXBlbGxpbmcgdXNlIGNhc2UsIHRoZXJlZm9yZSBjdXJzb3Igc3VwcG9ydCBp cyBub3QgbmVlZGVkIGluIHRoaXMgd29yay4NCg0KSWYgeW91IGhhdmUgZGlmZmVyZW50IG9waW5p b24sIHBsZWFzZSBsZXQgdXMga25vdy4NCg0KLVFpbiAob24gYmVoYWxmIG9mIEF1dGhvcnMpDQo= --_000_66ef8ad4d3fa4300a968ad10363f3bachuaweicom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, = All:

In d= raft-wwlh-netconf-list-pagination-00=A3=ACwe define five query parameters for list pagination and One query parameter for descendant list pagination. These query parame= ters provide offset based list pagination.

One = of features we would like to investigate is cursor support, which has been = brought up in IETF 112 NETCONF virtual meeting:

For = server w/ cursor support:

R= 26; It Enables the paging to continue over the snapshot, despite the datase= t changing.

R= 26; The client assumes the list doesn=A1=AFt change;

b. &= nbsp;For server w/o cursor or snapshot support:

R= 26; The server might return larger remaining value than previous fetch duri= ng refetching page in a time series log (where logs are appended).

c. &= nbsp;For config, some protocols support locks (to prevent out-of-band chang= es), while others support tag/timestamps (enabling out-of-band changes to t= he detected), so the issue is effectively limited to opstate lists.

Base= d on the above our analysis, it looks we don=A1=AFt have compelling use cas= e, therefore cursor support is not needed in this work.

 

If y= ou have different opinion, please let us know.

 

-Qin= (on behalf of Authors)

--_000_66ef8ad4d3fa4300a968ad10363f3bachuaweicom_-- From nobody Wed Dec 22 14:32:31 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6938F3A0D3E; Wed, 22 Dec 2021 14:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbeAQGotMGGS; Wed, 22 Dec 2021 14:32:25 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D723A0D3F; Wed, 22 Dec 2021 14:32:24 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BMMWF5g029213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Dec 2021 17:32:21 -0500 Date: Wed, 22 Dec 2021 14:32:14 -0800 From: Benjamin Kaduk To: Kent Watsen Cc: The IESG , draft-ietf-netconf-sztp-csr@ietf.org, "netconf-chairs@ietf.org" , "netconf@ietf.org" Message-ID: <20211222223214.GT11486@mit.edu> References: <163952699208.6437.8936066509149136808@ietfa.amsl.com> <0100017dde220d3d-4be5f8d7-c4a8-4f45-81d9-0c80bfac77a2-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0100017dde220d3d-4be5f8d7-c4a8-4f45-81d9-0c80bfac77a2-000000@email.amazonses.com> Archived-At: Subject: Re: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2021 22:32:30 -0000 Hi Kent (and Russ and Sean), Comments inline. On Tue, Dec 21, 2021 at 05:55:13PM +0000, Kent Watsen wrote: > Hi Ben, > > Thank you for your thoughtful review. Responses to your comments are below. > > Also, diffs are here: https://github.com/netconf-wg/sztp-csr/commit/ee5b28d35ec26c895ce4691f85affd1487d51f3e . > > Best regards, > Kent (and Russ and Sean) > > > > On Dec 14, 2021, at 7:09 PM, Benjamin Kaduk via Datatracker wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-netconf-sztp-csr-12: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for this document; it seems useful to have the flexibility to > > specify a CSR and get an LDevID during enrollment. > > > > I had a similar concern as Zahed's Discuss point (though I'm not sure > > I can really express my concerns very well yet), and will attempt to follow > > the discussion thereof. > > Zahed’s discuss is ongoing, but I think we’re just an edit away now. > > > > > > Section 2.1 > > > > Why do we need the "sztp-csr" namespace prefix on the new nodes in the > > get-bootstrapping-data example, but not need the "ietf-sztp-csr" prefix > > on the nodes in the ietf-restconf/errors example? > > You write “example” but I think you mean “tree diagrams”. The tree-diagram at the top of page 7 is stitched together via some scripts. Technically, the parent node, "error-info”, is of type “yang:anydata”, which is a YANG for “anything, no data model needed, can go here”, which means what is there now isn’t wrong. That said, your observation is valid, the dichotomy is stark. I have updated the scripts to prefix all those nodes the same as in the earlier tree diagram. Since you cannot see what it looks like from the GitHub diff, the new rendered view follows: You're right, I must have meant "tree diagrams"; sorry about that. Thanks for the explanation and updates! > module: ietf-restconf > +--ro errors > +--ro error* [] > +--ro error-type enumeration > +--ro error-tag string > +--ro error-app-tag? string > +--ro error-path? instance-identifier > +--ro error-message? string > +--ro error-info > +--ro sztp-csr:csr-request > +--ro sztp-csr:key-generation! > | +--ro sztp-csr:selected-algorithm > | +--ro sztp-csr:algorithm-identifier binary > +--ro sztp-csr:csr-generation > | +--ro sztp-csr:selected-format > | +--ro sztp-csr:format-identifier identityref > +--ro sztp-csr:cert-req-info? ct:csr-info > > > > > > Section 2.3 > > > > description > > "Provides the CSR generated by the SZTP-client. > > > > When present, the SZTP-server SHOULD respond with > > an SZTP onboarding information message containing > > a signed certificate for the conveyed CSR. The > > SZTP-server MAY alternatively respond with another > > HTTP error containing another 'csr-request', in > > which case the SZTP-client MUST invalidate the > > previously generated CSR."; > > > > I'm curious what is intended by "invalidate the [...] CSR". My > > background on CSR usage hasn't really encountered a sense of "validity" > > for them that would need cancellation, since it's not really a important > > piece of information in its on right (just a way to ask a CA to do > > something). The interesting bit is whether the CA actually issued > > anything, but I'm not sure how much harm a stale CSR would actually > > cause. > > The intention of “invalidate” was to, e.g., delete the private key that may have been generated specifically for the previous CSR. Thinking about this now, the authors are of the opinion that deleting the private key is likely all that any SZTP-client could ever do. That being the case, we suggest: > > OLD: the SZTP-client MUST invalidate the previously generated CSR. > NEW: the SZTP-client MUST delete any key generated for the previously generated CSR. > > Makes sense? Yes, that makes sense. [comment about "overkill" removed since we use the single-use property for replay detection] > > > > Section 3.2 > > > > identity cmp-csr { > > base certificate-request-format; > > description > > "Indicates that the ZTP-client supports generating > > requests using a constrained version of the PKIMessage > > containing a p10cr structure defined in RFC 4210."; > > > > I'd probably spend a few more words to indicate the nature of the > > constraints that cause us to say "constrained version". > > (Likewise for the cmc-csr.) > > The authors think that “profiled” is a better word than “constrained”, as so suggest: > > description > "Indicates that the ZTP-client supports generating > requests using a profiled version of the PKIMessage > that MUST contain a PKIHeader followed by a PKIBody > containing only the p10cr structure defined in RFC 4210."; > > Thoughts? That seems to flow better to me and not leave me looking for more content somewhere else. So, looks like a clear improvement. > > > > Enables the ZTP-server to provide a fully-populated > > CertificationRequestInfo structure that the ZTP-client > > only needs to sign in order to generate the complete > > 'CertificationRequest' structure to send to ZTP-server > > in its next 'get-bootstrapping-data' request message. > > > > When provided, the ZTP-client SHOULD use this structure > > to generate its CSR; failure to do so MAY result in a > > 400 Bad Request response containing another 'csr-request' > > structure. > > > > This guidance seems to risk running afoul of the first rule of PKIs: > > know what you sign. While I understand that the context for this > > protocol exchange is a relatively "dumb" device getting onboarded into > > the owner's deployment, and that the owner may in fact require some > > things in the LDevID that were not coded into the device by its > > implementors, I don't think we should stand mute on the security > > considerations of asking for a certificate that contains > > attributes/restrictions/etc. that are not understood. > > After a little discussion, the authors are unable to understand a scenario where it makes sense that a ZTP-client would disregard and/or decorate/extend the CertificationRequestInfo structure from the ZTP-server. That being the case, we recommend s/SHOULD/MUST/ and s/MAY/will/ as follows: > > When provided, the ZTP-client MUST use this structure > to generate its CSR; failure to do so will result in a > 400 Bad Request response containing another 'csr-request' > structure. > > Better? Those changes are okay in terms of the protocol operations. I think there are probably still some security considerations to document, in that the ZTP-client is trusting the ZTP-server to tell it what to sign (in the CSR). The ZTP client trusts the ZTP server for equally sensitive things already, so this seems to mostly be a documentation issue: "the ZTP server has full control over the contents of the CSR that the ZTP client generates (except for the actual private key), which can result in the client receiving a certificate with permissions or restrictions that it does not recognize. The ZTP server is already a trusted part of the ecosystem and it is natural to extend that trust by relying on it to give the ZTP client a CSR template that will be appropriate for its implementation and role in the network." > > > > leaf cmc-csr { > > type binary; > > description > > "A constrained version of the 'Full PKI Request' > > message defined in RFC 5272, encoded using ASN.1 > > distinguished encoding rules (DER), as specified > > in ITU-T X.690. > > > > (Same comment about "constrained version" as above.) > > > The authors again think that “profiled” is a better word than “constrained”, as so suggest: > > description > "A profiled version of the 'Full PKI Request' > message defined in RFC 5272, encoded using ASN.1 > distinguished encoding rules (DER), as specified > in ITU-T X.690. > > Thoughts? Sounds good. It looks like the "constrained" phrasing is also present in the identity cmc-csr; presumably we should make an analogous change there and anywhere else relevant. > > > > > > For asymmetric key-based origin authentication based on > > the initial device identity certificate's private key > > that signs the encapsulated CSR signed by the local > > device identity certificate's private key, the PKIData > > contains one cmsSequence element and no > > otherMsgSequence element. The cmsSequence is the ... > > > > This part says nothing about whether there is a reqSequence element in > > the toplevel PKIData... > > The authors propose: > > OLD: and no otherMsgSequence element. > NEW: and no controlSequence, reqSequence, or otherMsgSequence elements. > > Good? Yup. > > > > > TaggedContentInfo and it includes a bodyPartID element > > and a contentInfo. The contentInfo is a SignedData > > encapsulating a PKIData with one reqSequence element > > and no cmsSequence or otherMsgSequence elements. The > > reqSequence is the TaggedRequest and it is the tcr > > CHOICE. The tcr is the TaggedCertificationRequest and > > it a bodyPartId and the certificateRequest elements. > > [...] > > > > ... since this reqSequence seems to refer to the PKIData inside the > > SignedData in the contentInfo in the cmsSequence. Should we say > > anything about the presence/absence of reqSequence in the toplevel > > PKIData (since we do in the other two cases)? > > Yes, the authors propose: > > OLD: […] > > NEW: PKIData contains one cmsSequence element and no > controlSequence, reqSequence, or otherMsgSequence > elements. […] > > > Good? I don't think we mention controlSequence anywhere else at present (though it is mentioned in the "NEW" text above). I don't think the omission seemed noteworthy when I was doing my original review, so my primary consideration here is just that we give it consistent treatment everywhere (in terms of whether or not we mention it). > > > > case cmp-csr { > > leaf cmp-csr { > > type binary; > > description > > [...] > > For asymmetric key-based origin authentication of a > > CSR based on the initial device identity certificate's > > private key for the associated initial device identity > > certificate's public key, PKIMessages contains one > > PKIMessage with the header and body elements, no > > protection element, and should contain the extraCerts > > element. [...] > > > > Is this a "should" or a "SHOULD"? > > > Yes. Fixed. > > > > For asymmetric key-based origin authentication based on > > the initial device identity certificate's private key > > that signs the encapsulated CSR signed by the local > > device identity certificate's private key, PKIMessages > > contains one PKIMessage with the header, body, and > > protection elements, and should contain the extraCerts > > element. [...] > > > > (ditto) > > Also now a "SHOULD” here. > > > > > Section 4 > > > > I'd consider also mentioning the CMC, CMP, and PKCS#10 security > > considerations as being applicable to the relevant CSR choices. > > Silly authors, we forgot the apple pie ;) > > We added: > > For the various CSR formats, when using PKCS#10, the security > considerations in [RFC2986] apply, when using CMP, the security > considerations in [RFC4210] apply and, when using CMC, the security > considerations in [RFC5272] apply. > > > > > Section 4.1.1 > > > > The security of this private key is essential in order to ensure the > > associated identity certificate can be used as a root of trust. > > > > "root of trust" is something of a loaded term (see the ongoing > > discussion in the RATS WG for differing interpretations of what it > > means). I'd suggest using a different phrasing, like "can be used to > > authenticate the device it is issued to". > > Fix applied - thanks! > > > > Section 4.1.3 > > > > Should we mention the "nonce" parameter to get-bootstrapping-data > > here? > > Hmmm, if we were to mention the “nonce” parameter at all, it would only be to say that it has *nothing* to do with the CSR mechanism presented in this document…or, at least it doesn’t have any relation currently. To be clear, the “nonce” parameter is defined in RFC 8572 (SZTP) as follows: > > leaf nonce { > type binary { > length "16..32"; > } > description > "This optional input parameter enables a device to > communicate to the bootstrap server a nonce value. > This may be especially useful for devices lacking > an accurate clock, as then the bootstrap server > can dynamically obtain from the manufacturer a > voucher with the nonce value in it, as described > in RFC 8366."; > reference > "RFC 8366: > A Voucher Artifact for Bootstrapping Protocols"; > } > > Thoughts? I did see (after I originally wrote the remark) that the "nonce" is not new in this document...but since nonces are a common way to prevent replay attacks, I figured I would still ask the question. The 8572 discussion covers the nonce going into the voucher to detect/prevent replay. I suppose in principle that one could also have a setup that puts the nonce into the certificate as well, but I don't expect that to be common. So my thinking is that we should consider putting in some text along the lines of "though the get-bootstrapping-data RPC does contain a 'nonce' parameter, it is defined by RFC 8572 for use in preventing replay of a voucher; that mechanism is unrelated to detecting replay of the certificate that can be returned by the get-bootstrapping-data RPC". > > > > When a public/private key pair associated with the manufacturer- > > generated identity certificate (e.g., IDevID) is used for the > > request, there may not be confirmation to the SZTP-client that the > > response has not been replayed; however, the worst case result is a > > lost certificate that is associated to the private key known only to > > the SZTP-client. > > > > That's only the worse-case result if we assume that the private key is > > not compromised. We might want to reiterate that assumption and/or > > mention the scope of consequences for the case where the private key is > > compromised. > > Good point. We appended the following to the end of the paragraph: > > Protection of the private-key information is vital to public-key > cryptography. Disclosure of the private-key material to another > entity can lead to masquerades. > > Better? Yes > > > Section 4.2.2 > > > > When a new asymmetric key is used, with the CMP or CMC formats, the > > parent ASN.1 structure of the CSR provides origin authentication > > using either the manufacturer-generated private key or a shared > > secret. In this way the proof-of-possession of the CSR is directly > > linked to the proof-or-origin provided by the parent ASN.1 structure. > > > > I think this section would be a good place to talk about how in the "raw > > PKCS#10" case, there needs to be a level of trust in the bootstrapping > > server roughly analogous to how an RA would be trusted, in that they are > > the only entity that has verified the client identity and the > > bootstrapping server's assertion of the client identity is a key step in > > the certificate issuance process. > > The authors propose replacing the paragraph above with the following: > > When the bootstrapping device's manufacturer-generated private key > (e.g., the IDevID key) is reused for the CSR, proof-of-origin is > verified by validating the IDevID certification path and ensuring that > the CSR uses the same key pair. > > When a fresh asymmetric key is used with the CMP or CMC formats, the > authentication is part of the protocols, which could employ either > the manufacturer-generated private key or a shared secret. In addition, > CMP and CMC support processing by a RA before the request is passed > to the CA, which allows for more robust handling of errors. > > Thoughts? That's good text to have. I think it leaves unaddressed my desire to document that the PKCS#10 format does not provide this property, and the implication that if PKCS#10 is used with a new asymmetric key, there is an additional requirement on the SZTP server to be trusted infrastructure in the PKI (as well as the existing requirement to be trusted in the deployment/operations sense). Unless we propose to forbid the use of PKCS#10 with new asymmetric keys? > > > > Such discussion might also contrast use of the IDevID at the TLS layer > > with HTTP-layer authentication of the client. > > The authors believe this is best addressed with more “apple pie” in the top-level of Section 4 (Security Considerations): > > For the various authentication mechanisms, when using TLS-level > authentication, the security considerations in [RFC8446] apply and, > when using HTTP-level authentication, the security considerations in > [RFC7235] apply. > > Would this satisfy your discuss? This is fine "apple pie" text to have, though not quite the direction I was thinking. That said, looking at it again, I'm no longer sure that the direction I was thinking has much to say -- basically it's just that using the IDevID for TLS provides proof of origin as being from the device while HTTP-level authentication does not ... but it's only proof to the SZTP server, which (per the previous bit) would need to be trusted to properly relay that information into the PKI. So it's not terribly useful information to add. > > > > Section 4.4 > > > > Though our "identity" and "grouping" statements (as noted) to not appear > > in any protocol-accessible nodes as-is, we might still feel empowered to > > discuss any considerations that would apply when they actually are > > instantiated in other modules. However, it seems that there would not > > be anything new to say other than what's in RFCs 2986, 4210, and 5272, > > and if we take my suggestion to reference them from the toplevel > > section 4, there would be no need to do so again here. > > We put the “apple pie” into the top-level of Section 4. > > > > NITS > > > > Abstract, Introduction > > > > I'd consider clarifying that when we "extend" the get-bootstrapping-data > > RPC to include a CSR, that's as the input to the RPC, not the output. > > (I initially misread it when reading the abstract.) > > Done. > > > > Section 2.2 > > > > You may want to use more-recent dates than 2015 for the examples. > > Done. > > > > I suggest using different "BASE64VALUE="s for the different public > > keys in the two-asymmetric-key example. > > Not fixed, given: > > 1.4. Conventions > > Various examples used in this document use a placeholder value for > binary data that has been base64 encoded (e.g., "BASE64VALUE="). > This placeholder value is used as real base64 encoded structures are > often many lines long and hence distracting to the example being > presented. > > > > Section 3.2 > > > > leaf-list algorithm-identifier { > > type binary; > > min-elements 1; > > description > > "An AlgorithmIdentifier, as defined in RFC 2986, > > encoded using ASN.1 distinguished encoding rules > > (DER), as specified in ITU-T X.690."; > > > > At risk of excessive pedanticism, I see RFC 2986 discuss the > > parametrized AlgorithmIdentifier{}, which compares it to the > > unparameterized AlgorithmIdentifier in the ensuing discussion. > > AlgorithmIdentifier is (also) defined in, e.g., RFC 5280 if we didn't > > want to get into the parameterization here. (Any change made here > > should be made throughout, of course.) > > Not fixed, since the document refs RFC 2986 for the CSR structure, so having a forward ref to RFC 5280 doesn’t seem right to us. Thoughts? I am not going to insist on excessive pedanticism -- leaving it alone is probably fine. > > > grouping csr-grouping { > > description > > "Enables a ZTP-client to convey a certificate signing > > request, using the encoding format selected by a > > ZTP-server's 'csr-request' response to the ZTP-client's > > previously sent 'get-bootstrapping-data' request > > containing the 'csr-support' node."; > > > > (nit) Since we're (now) in just the ztp-types module, we can't > > necessarily assume there will be a "get-bootstrapping-data" request > > involved. > > Good catch. Fixed. > > > > For asymmetric key-based origin authentication of a > > CSR based on the initial device identity certificate's > > private key for the associated identity certificate's > > public key, the PKIData contains one reqSequence > > > > (nit) I think the "associated identity certificate's public key" > > phrasing here is a bit confusing. I think that we're trying to cover > > the case where the key from the IDevID is reused for the LDevID, so > > we're using the LDevID private key to authenticate the CSR and it's > > sigining "it's own" public key", but in the context of this YANG > > grouping we've mostly lost the context of the "associated identity > > certificate". > > (A similar comment applies to the CMP case.) > > Not fixed, due to complexity and that this is just a “nit”. More detail, one author wrote: > > "We have gone back and forth on the text a couple of times. I am not sure I won’t just revert to what we had before. I will note that if we make a change here we have to change it 6 different times, 3X for CMC and 3X for CMP. The phrasing was specifically done this way and amended along the way to make it clear which key is doing what. We got three cases two are asymmetric-based and one is symmetric-based. We needed to differentiate between the 1st two, and that convoluted text is how we did it." I think my comment can be distilled to: "there is no context in this paragraph to clearly tie down what the 'associated identity certificate' is." A practitioner skilled in the art that has read the entire document will figure it out, but in terms of quality of writing it's not great. (There are plenty of examples of worse writing in the RFC Series, though, so don't stress out about it.) > > > elements. The reqSequence is the TaggedRequest and it > > is the tcr CHOICE. The tcr is the > > > > (nit) should we have another word after "CHOICE", like "arm" or > > "branch"? > > Done. used “branch”. > > > > TaggedCertificationRequest and it a bodyPartId and the > > > > (nit) also, I'd maybe s/the/a/ for these two "the is the " > > constructions since they seem to just be describing the type of a given > > ASN.1 element. > > Also, s/it/it is/. > > All done. > > > > Section 4.1.1 > > > > private keys. For instance, an NMS controller/orchestrator > > application could periodically prompt the SZTP-client to generate a > > new private key and provide a certificate signing request (CSR) or, > > alternatively, push both the key and an identity certificate to the > > SZTP-client using, e.g., a PKCS #12 [RFC7292]. [...] > > > > maybe "a PKCS #12 message"? > > Fix applied. > > > > Section 4.1.5 > > > > The CMP and CMC certificate request formats defined in this document > > support origin authentication. A raw PKCS#10 does not support origin > > authentication. > > > > "PKCS#10 CSR" > > Done. > > > > Thanks again! > Kent (and Russ and Sean) Thank you, too! -Ben From nobody Thu Dec 23 10:17:36 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2EE3A085B for ; Thu, 23 Dec 2021 10:17:34 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJht8O73fgq1 for ; Thu, 23 Dec 2021 10:17:33 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2483C3A0845 for ; Thu, 23 Dec 2021 10:17:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 354BC300C75 for ; Thu, 23 Dec 2021 13:12:25 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0JN_6wjHXxap for ; Thu, 23 Dec 2021 13:12:23 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id D76B6300B9D; Thu, 23 Dec 2021 13:12:22 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: <20211222223214.GT11486@mit.edu> Date: Thu, 23 Dec 2021 13:12:18 -0500 Cc: Kent Watsen , IESG , draft-ietf-netconf-sztp-csr@ietf.org, "netconf-chairs@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0ED98E8C-611D-4303-9F1D-BDC1EAFD73AA@vigilsec.com> References: <163952699208.6437.8936066509149136808@ietfa.amsl.com> <0100017dde220d3d-4be5f8d7-c4a8-4f45-81d9-0c80bfac77a2-000000@email.amazonses.com> <20211222223214.GT11486@mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2021 18:17:35 -0000 Ben: Responding to just one comment in this message ... >>> TaggedContentInfo and it includes a bodyPartID element >>> and a contentInfo. The contentInfo is a SignedData >>> encapsulating a PKIData with one reqSequence element >>> and no cmsSequence or otherMsgSequence elements. The >>> reqSequence is the TaggedRequest and it is the tcr >>> CHOICE. The tcr is the TaggedCertificationRequest and >>> it a bodyPartId and the certificateRequest elements. >>> [...] >>>=20 >>> ... since this reqSequence seems to refer to the PKIData inside the >>> SignedData in the contentInfo in the cmsSequence. Should we say >>> anything about the presence/absence of reqSequence in the toplevel >>> PKIData (since we do in the other two cases)? >>=20 >> Yes, the authors propose: >>=20 >> OLD: [=E2=80=A6] >>=20 >> NEW: PKIData contains one cmsSequence element and no >> controlSequence, reqSequence, or otherMsgSequence >> elements. [=E2=80=A6] >>=20 >>=20 >> Good? >=20 > I don't think we mention controlSequence anywhere else at present = (though > it is mentioned in the "NEW" text above). I don't think the omission > seemed noteworthy when I was doing my original review, so my primary > consideration here is just that we give it consistent treatment = everywhere > (in terms of whether or not we mention it). When looking at the text to address your comment, I could see not a role = for controlSequence in this situation; however, I think there might = possibly be a role in some of the other places. For that reason, I thik = it should be allowable in other places. That is, the text should not = exclude it. If for consistency, you would rather not exclude = controlSequence anywhere, I am fine with that too. Russ From nobody Fri Dec 24 19:22:43 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ADC3A0BFB; Fri, 24 Dec 2021 19:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCVt-XNxWm6y; Fri, 24 Dec 2021 19:22:38 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79C43A0C0A; Fri, 24 Dec 2021 19:22:33 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BP3MOtU019974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Dec 2021 22:22:30 -0500 Date: Fri, 24 Dec 2021 19:22:23 -0800 From: Benjamin Kaduk To: Russ Housley Cc: Kent Watsen , IESG , draft-ietf-netconf-sztp-csr@ietf.org, "netconf-chairs@ietf.org" , "netconf@ietf.org" Message-ID: <20211225032223.GG11486@mit.edu> References: <163952699208.6437.8936066509149136808@ietfa.amsl.com> <0100017dde220d3d-4be5f8d7-c4a8-4f45-81d9-0c80bfac77a2-000000@email.amazonses.com> <20211222223214.GT11486@mit.edu> <0ED98E8C-611D-4303-9F1D-BDC1EAFD73AA@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0ED98E8C-611D-4303-9F1D-BDC1EAFD73AA@vigilsec.com> Archived-At: Subject: Re: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2021 03:22:41 -0000 Hi Russ, On Thu, Dec 23, 2021 at 01:12:18PM -0500, Russ Housley wrote: > Ben: > > Responding to just one comment in this message ... > > >>> TaggedContentInfo and it includes a bodyPartID element > >>> and a contentInfo. The contentInfo is a SignedData > >>> encapsulating a PKIData with one reqSequence element > >>> and no cmsSequence or otherMsgSequence elements. The > >>> reqSequence is the TaggedRequest and it is the tcr > >>> CHOICE. The tcr is the TaggedCertificationRequest and > >>> it a bodyPartId and the certificateRequest elements. > >>> [...] > >>> > >>> ... since this reqSequence seems to refer to the PKIData inside the > >>> SignedData in the contentInfo in the cmsSequence. Should we say > >>> anything about the presence/absence of reqSequence in the toplevel > >>> PKIData (since we do in the other two cases)? > >> > >> Yes, the authors propose: > >> > >> OLD: […] > >> > >> NEW: PKIData contains one cmsSequence element and no > >> controlSequence, reqSequence, or otherMsgSequence > >> elements. […] > >> > >> > >> Good? > > > > I don't think we mention controlSequence anywhere else at present (though > > it is mentioned in the "NEW" text above). I don't think the omission > > seemed noteworthy when I was doing my original review, so my primary > > consideration here is just that we give it consistent treatment everywhere > > (in terms of whether or not we mention it). > > When looking at the text to address your comment, I could see not a role for controlSequence in this situation; however, I think there might possibly be a role in some of the other places. For that reason, I thik it should be allowable in other places. That is, the text should not exclude it. If for consistency, you would rather not exclude controlSequence anywhere, I am fine with that too. I have no strong preference here. If you have looked at all the cases and think this one is "different enough" that controlSequence is not needed, I do not object to having it mentioned here. Thanks, Ben From nobody Tue Dec 28 06:07:29 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A948A3A15B2 for ; Tue, 28 Dec 2021 06:07:27 -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, 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=broadband-forum-org.20210112.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 UpprrveLpcUu for ; Tue, 28 Dec 2021 06:07:23 -0800 (PST) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 D9F1E3A15AC for ; Tue, 28 Dec 2021 06:07:22 -0800 (PST) Received: by mail-yb1-xb36.google.com with SMTP id d1so33709099ybh.6 for ; Tue, 28 Dec 2021 06:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadband-forum-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Thi5u3tZo9I+FF8qGmQSokqIdhq0fOuhYHOjxBbfglo=; b=qhDzdUHC4INk9IsdVIIFLrMFatcRgWoBe30Z7PYjoqXn5LExGY85pUXLOYodY2iSL/ KsUWlKRGkhs0fRLuc6XmP3KgoPGuKiNngUeLHIoxti5Rylek+TMG/vpbHKf2DNom32aX Okdw23xfdloqjQkyY1NgSWxlC4LK++up5x1UYqMIkOEClsssFGBeG8wJgsY4idUSV1GW DaGtWd/aU8BsGCYwSk3hlCFyzDPAFnx57vyD/o0GHDlB5c0ckgDnE6mHjIzNxAcTej3v 1MmVr7Qe+lptqrkeyni7/9wFCQUrvksnb6bGs3eYdoPEtU54+8Yl6vNwsI53DtqVJNrT NnQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Thi5u3tZo9I+FF8qGmQSokqIdhq0fOuhYHOjxBbfglo=; b=bfVrP5ehpTtPSId2Z2mkUwXAIZ9itdkvBBVpUnutwfQP7o+pOEyDycTIGKnpaqE8SM CEBk8OM780qorrCadHh21eY7kyS9RNgQ/3Z044C2jGgSVm33S9X4Tfk3yvrgTiGd+5vX mgnUjwuo0avIeWr9ygc+0b0+MTuOaU/TQtfTz5ND1cG1eNkmXnPJ8XKrxXZ096uSdzdk dAjsIWlPex67i1dksiOAt/RfPAV4BRpIybhXE+T1GypmnbwGkUytCOhBbZY0btf6IW7Z mrVpGvkuSLsEB6Rn2dUuqn0x2oRgtlIDBKDQTAKjTMjqj1o+gCqbhAjnjSaY8ZivBgIm AiUg== X-Gm-Message-State: AOAM533s7JZ49xnKobD3RIzqLShwx2JLSVRHWP4s6u1YfN7fBMXrgw/L nxL145SnnuBf8s/ZgoX6dH4TfmazBwuhuweT/9L4aDqTxCmJmA== X-Google-Smtp-Source: ABdhPJwm2wMukNDjwZKtvaYzS1yJpKk35eQsAzjtYIMPKl9p6Ol/L7hzvsQ/9fiLod/X1oiMKZUoqWulHJNbYYe2Kk0= X-Received: by 2002:a25:83d0:: with SMTP id v16mr1173996ybm.686.1640700439113; Tue, 28 Dec 2021 06:07:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: William Lupton Date: Tue, 28 Dec 2021 14:07:08 +0000 Message-ID: To: Qin Wu Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000db484b05d43556b0" Archived-At: Subject: Re: [netconf] List Pagination Open Issue #2: Zero vs Unknown 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 Dec 2021 14:07:28 -0000 --000000000000db484b05d43556b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I noticed the proposed use of "MAY NOT", which I think is best avoided (arguably "may not" means the same as "must not", and I note that it's not called out by RFC 2119). Perhaps you could use: OLD TEXT: =E2=80=9C If no elements were removed, this annotation MUST NOT appear. =E2=80=9D NEW TEXT: =E2=80=9C If no elements were removed, this annotation MAY be absent. =E2=80=9D On Wed, 22 Dec 2021 at 12:10, Qin Wu wrote: > Hi, All: > > One of issues we brought up in IETF 112 is about usage of The =E2=80=98re= maining > 'annotation. > > The =E2=80=98remaining 'annotation defined in our drafts is used to retur= n the > number of elements not included in a result set after a 'limit' or > 'sublist-limit' operation. > > The current draft (i.e., draft-wwlh-netconf-list-pagination) states that: > > =E2=80=9CIf no elements were removed, this annotation MUST NOT appear. > > The minimum value (0), which never occurs in normal operation, is reserve= d > to represent 'unknown'. =E2=80=9D > > > > But one best practice proposed by our design team member is: > > =E2=80=A2 No more entries ---> Return zero > > =E2=80=A2 Unknown ---> Not return the "remaining" annotation at all > > > > Talking with design team members, we believe that when NO entries are > returned in the RPC-reply, NO annotation can be returned (because RFC 795= 2 > says the annotation must be in the first element of the list, > > but there would be no first element.) > > The question is whether the =E2=80=9Cremaining=E2=80=9D annotation should= be always > present or whether there is a case which it MAY not appear. If we allow i= t > to NOT appear in those cases, it would only be reasonable to do so when > there are no more elements, as that would similar to existing list > retrievals (i.e. you get everything and there is no =E2=80=9Cremaining=E2= =80=9D annotation). > > > > Here is our proposed solution to address this issue. > > 1.Change =E2=80=98MUST=E2=80=99 into =E2=80=98May=E2=80=99 in the draft-w= wlh-netconf-list-pagination as > follows: > > OLD TEXT: > > =E2=80=9C > > If no elements were removed, this annotation MUST NOT appear. > > =E2=80=9D > > NEW TEXT: > > =E2=80=9C > > If no elements were removed, this annotation MAY NOT appear. > > =E2=80=9D > > Add =E2=80=98none=E2=80=99 enumeration as follows > > md:annotation remaining { > > type union { > > type uint32; > > type enumeration { > > enum =E2=80=9Cnone" { > > description > > "Indicates that there are no entries that were not > > Included in the result set, due to a 'limit' or > > 'sublist-limit' operation.."; > > } > > enum "unknown" { > > description > > "Indicates that number of remaining entries is unknown > > to the server in case, e.g., the server has determined > > that counting would be prohibitively expensive."; > > } > > } > > } > > description > > "This annotation contains the number of elements not included > > in the result set due to a 'limit=E2=80=99 or 'sublist-limit=E2= =80=99 operation. > > If no elements were removed, either the annotation MAY be > > missing or MUST have the value =E2=80=980=E2=80=99 or =E2=80=98= none=E2=80=99. If it is unknown > > to the server how many entries may be returned, the value > > =E2=80=98unknown=E2=80=99 MUST be returned. The maximum value = (2^32-1) is > > reserved to represent any value greater than or equal to > > 2^32-1 elements."; > > } > > Comments and suggestions are welcome! > > > > -Qin (On behalf of authors) > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000db484b05d43556b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I noticed the proposed use of "MAY N= OT", which I think is best avoided (arguably "may not" means= the same as "must not", and I note that it's not called out = by RFC 2119).

Perhaps you could use:

= OLD TEXT:

=E2=80=9C

If no elements were= removed, this annotation MUST NOT appear.

=E2=80=9D

NEW TEXT:

=E2=80=9C

If no= elements were removed, this annotation MAY be absent.=

= =E2=80=9D


On Wed, 22 Dec 2021 at 12:10, Qin Wu <bill.wu= =3D40huawei.com@dmarc.ietf.o= rg> wrote:

Hi, Al= l:

One of= issues we brought up in IETF 112 is about usage of The =E2=80=98remaining = 'annotation.

The = =E2=80=98remaining 'annotation defined in our drafts is used to return = the number of elements not included in a result set after a 'limit'= or 'sublist-limit' operation.

The cu= rrent draft (i.e., draft-wwlh-netconf-list-pagination) states that:<= u>

=E2=80= =9CIf no elements were removed, this annotation MUST NOT appear.<= /u>

The mi= nimum value (0), which never occurs in normal operation, is reserved to rep= resent 'unknown'. =E2=80=9D

=C2=A0

But on= e best practice proposed by our design team member is:=

=E2=80= =A2 No more entries ---> Return zero

=E2=80= =A2 Unknown ---> Not return the "remaining" annotation at all<= u>

=C2=A0

Talkin= g with design team members, we believe that when NO entries are returned in= the RPC-reply, NO annotation can be returned (because RFC 7952 says the an= notation must be in the first element of the list,

but th= ere would be no first element.)

The qu= estion is whether the =E2=80=9Cremaining=E2=80=9D annotation should be alwa= ys present or whether there is a case which it MAY not appear. If we allow = it to NOT appear in those cases, it would only be reasonable to do so when there are no more elements, as that would similar to existin= g list retrievals (i.e. you get everything and there is no =E2=80=9Cremaini= ng=E2=80=9D annotation).

=C2=A0

Here i= s our proposed solution to address this issue.

1.Chan= ge =E2=80=98MUST=E2=80=99 into =E2=80=98May=E2=80=99 in the draft-wwlh-netc= onf-list-pagination as follows:

OLD TE= XT:

=E2=80= =9C

If no = elements were removed, this annotation MUST NOT appear.

=E2=80= =9D

NEW TE= XT:

=E2=80= =9C

If no = elements were removed, this annotation MAY NOT appear.=

=E2=80= =9D

Add = =E2=80=98none=E2=80=99 enumeration as follows

=C2=A0= =C2=A0 =C2=A0md:annotation remaining {

=C2=A0= =C2=A0 =C2=A0 =C2=A0type union {

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum =E2=80=9Cnone" {=

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description<= /p>

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Indicates that there= are no entries that were not

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Included in the res= ult set, due to a 'limit' or

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'sublist-limit&= #39; operation..";

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

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "unknown" {=

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description<= /p>

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Indicates that numbe= r of remaining entries is unknown

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to the server in case, e.= g., the server has determined

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that counting would be pr= ohibitively expensive.";

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

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

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

=C2=A0= =C2=A0 =C2=A0 =C2=A0description

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0"This annotation contains the number of el= ements not=C2=A0included

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the result set=C2=A0due to a 'limit=E2= =80=99=C2=A0or=C2=A0'sublist-limit=E2=80=99=C2=A0operation.

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 If no elements were removed, either the annota= tion MAY be

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 missing or MUST have the value=C2=A0=E2=80=980= =E2=80=99 or=C2=A0=E2=80=98none=E2=80=99.=C2=A0 If it is unknown<= /u>

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 to the server how many entries may=C2=A0be ret= urned, the value

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=98unknown=E2=80=99=C2=A0MUST be returne= d.=C2=A0 The maximum=C2=A0value (2^32-1) is

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 reserved to represent any value greater than= =C2=A0or equal=C2=A0to

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 2^32-1 elements.";

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

Commen= ts and suggestions are welcome!

=C2=A0

-Qin (= On behalf of authors)

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000db484b05d43556b0-- From nobody Tue Dec 28 08:51:02 2021 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 00B713A0DE7; Tue, 28 Dec 2021 08:50:59 -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: mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org, rwilton@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164071025830.25203.11604982959000028731@ietfa.amsl.com> Date: Tue, 28 Dec 2021 08:50:58 -0800 Archived-At: Subject: [netconf] netconf - New Meeting Session Request for IETF 113 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, 28 Dec 2021 16:50:59 -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): unspecified Number of Attendees: 45 Conflicts to Avoid: Chair conflict: netmod tcpm idr anima Technology overlap: opsarea opsawg Can't meet: Friday morning, Friday early afternoon, Friday late afternoon People who must be present: Mahesh Jethanandani Kent Watsen Robert Wilton Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Dec 30 00:48:24 2021 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD613A0CA5 for ; Thu, 30 Dec 2021 00:48:22 -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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tq98RiiAMF3T for ; Thu, 30 Dec 2021 00:48:18 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E2C3A0CA8 for ; Thu, 30 Dec 2021 00:48:17 -0800 (PST) Received: from fraeml706-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JPhgs1Zh1z67Zn3 for ; Thu, 30 Dec 2021 16:46:01 +0800 (CST) Received: from kwepemm600019.china.huawei.com (7.193.23.64) by fraeml706-chm.china.huawei.com (10.206.15.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Thu, 30 Dec 2021 09:48:11 +0100 Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemm600019.china.huawei.com (7.193.23.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 30 Dec 2021 16:48:10 +0800 Received: from kwepemm600017.china.huawei.com ([7.193.23.234]) by kwepemm600017.china.huawei.com ([7.193.23.234]) with mapi id 15.01.2308.020; Thu, 30 Dec 2021 16:48:10 +0800 From: "maqiufang (A)" To: "netconf@ietf.org" Thread-Topic: New Version Notification for draft-wang-netconf-adaptive-subscription-08.txt Thread-Index: AQHX/VeDqPVVMTYtwUS03Ur+Y2ndB6xKt0lA Date: Thu, 30 Dec 2021 08:48:10 +0000 Message-ID: References: <164085302792.4870.16856105920443111648@ietfa.amsl.com> In-Reply-To: <164085302792.4870.16856105920443111648@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.100.87] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netconf] FW: New Version Notification for draft-wang-netconf-adaptive-subscription-08.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, 30 Dec 2021 08:48:23 -0000 SGksIGFsbA0KVi0wOCB3YXMgcG9zdGVkLiBBY2NvcmRpbmcgdG8gdGhlIGRpc2N1c3Npb24gaW4g bGFzdCBJRVRGIG1lZXRpbmcsIGZvbGxvd2luZ3MgYXJlIHRoZSBtYWpvciBjaGFuZ2VzOg0KMS4g RGVmaW5lIGEgbmV3IFJQQyBlcnJvciB0byBiZSByZXBvcnRlZCB3aGVuIGFuIFhQYXRoIHN5bnRh eCBkZWZpbmVkIGluICJ4cGF0aC1leHRlcm5hbC1ldmFsIiBpcyB1bnN1cHBvcnRlZCBieSBhIHNl cnZlci4NCjIuIEFkZCBhIG5ldyBleGFtcGxlIHNob3dpbmcgaG93IHRoZSBSUEMgZXJyb3IgYmVp bmcgcmV0dXJuZWQgYnkgYSBwdWJsaXNoZXIuCQ0KMy4gVXNhZ2UgZXhhbXBsZXMgZml4ZWQgaW4g dGhlIEFwcGVuZGl4LgkNCjQuIEdyYW1tYXRpY2FsIGVycm9ycyBjb3JyZWN0aW9uKG1pc3Npbmcg YXJ0aWNsZXMsIHBsdXJhbGl0eSBtaXNtYXRjaGVzLCBldGMpLg0KDQpUaGUgZGlmZiBpcyBhdmFp bGFibGUgYXQ6IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13YW5nLW5l dGNvbmYtYWRhcHRpdmUtc3Vic2NyaXB0aW9uLTA4Lg0KDQpDb21tZW50cyBhbmQgc3VnZ2VzdGlv bnMgYXJlIHdlbGNvbWUuOi0pDQoNCkJlc3QgUmVnYXJkcywNClFpdWZhbmcgTWENCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIg MzAsIDIwMjEgNDozMCBQTQ0KVG86IFBlbmcgTGl1IDxsaXVwZW5neWp5QGNoaW5hbW9iaWxlLmNv bT47IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPjsgUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5j b20+OyBtYXFpdWZhbmcgKEEpIDxtYXFpdWZhbmcxQGh1YXdlaS5jb20+OyBTb25nd2VpIChEYXZp ZCwgRGF0YUNvbSkgPHNvbmd3ZWk4MEBodWF3ZWkuY29tPjsgV2VpIFdhbmcgPHdhbmd3MzZAY2hp bmF0ZWxlY29tLmNuPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC13YW5nLW5ldGNvbmYtYWRhcHRpdmUtc3Vic2NyaXB0aW9uLTA4LnR4dA0KDQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC13YW5nLW5ldGNvbmYtYWRhcHRpdmUtc3Vic2NyaXB0aW9uLTA4 LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBRaXVmYW5nIE1hIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXdhbmctbmV0Y29u Zi1hZGFwdGl2ZS1zdWJzY3JpcHRpb24NClJldmlzaW9uOgkwOA0KVGl0bGU6CQlBZGFwdGl2ZSBT dWJzY3JpcHRpb24gdG8gWUFORyBOb3RpZmljYXRpb24NCkRvY3VtZW50IGRhdGU6CTIwMjEtMTIt MzANCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTI4DQpVUkw6ICAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC13YW5nLW5ldGNvbmYt YWRhcHRpdmUtc3Vic2NyaXB0aW9uLTA4LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbmctbmV0Y29uZi1hZGFwdGl2ZS1zdWJzY3Jp cHRpb24vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC13YW5nLW5ldGNvbmYtYWRhcHRpdmUtc3Vic2NyaXB0aW9uDQpEaWZmOiAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXdhbmctbmV0Y29u Zi1hZGFwdGl2ZS1zdWJzY3JpcHRpb24tMDgNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgYW5kIGFzc29jaWF0ZWQgbWVjaGFuaXNtDQogICBl bmFibGluZyB0aGUgc3Vic2NyaWJlcidzIGFkYXB0aXZlIHN1YnNjcmlwdGlvbnMgdG8gYSBwdWJs aXNoZXIncw0KICAgZXZlbnQgc3RyZWFtcyB3aXRoIHZhcmlvdXMgZGlmZmVyZW50IHBlcmlvZCBp bnRlcnZhbHMgdG8gcmVwb3J0DQogICB1cGRhdGVzLiAgQXBwbHlpbmcgdGhlc2UgZWxlbWVudHMg YWxsb3dzIHNlcnZlcnMgYXV0b21hdGljYWxseSBhZGp1c3QNCiAgIHRoZSByYXRlIGFuZCB2b2x1 bWUgb2YgdGVsZW1ldHJ5IHRyYWZmaWMgc2VudCBmcm9tIGEgcHVibGlzaGVyIHRvDQogICByZWNl aXZlcnMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQoNCg==