From nobody Sun Jan 3 09:49:14 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 08A3C3A1068 for ; Sun, 3 Jan 2021 09:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBud1_LA0WLV for ; Sun, 3 Jan 2021 09:49:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC253A1067 for ; Sun, 3 Jan 2021 09:49:11 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C46A5F406D1; Sun, 3 Jan 2021 09:49:10 -0800 (PST) To: evoit@cisco.com, rrahman@cisco.com, einarnn@cisco.com, ludwig@clemm.org, andy@yumaworks.com, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, mjethanandani@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: muly_i@rad.com, netconf@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210103174910.C46A5F406D1@rfc-editor.org> Date: Sun, 3 Jan 2021 09:49:10 -0800 (PST) Archived-At: Subject: [netconf] [Editorial Errata Reported] RFC8650 (6379) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 17:49:13 -0000 The following errata report has been submitted for RFC8650, "Dynamic Subscription to YANG Events and Datastores over RESTCONF". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6379 -------------------------------------- Type: Editorial Reported by: Muly Ilan Section: A.1.1 Original Text ------------- Upon receipt of the successful response, the subscriber does a GET to the provided URI to start the flow of notification messages. When the publisher receives this, the subscription is moved to the active state (c). GET /restconf/subscriptions/22 Figure 5: "establish-subscription" Subsequent POST Corrected Text -------------- Upon receipt of the successful response, the subscriber does a GET to the provided URI to start the flow of notification messages. When the publisher receives this, the subscription is moved to the active state (c). GET /restconf/subscriptions/22 Figure 5: "establish-subscription" Subsequent GET Notes ----- Substitute POST by GET in the figure caption 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. -------------------------------------- RFC8650 (draft-ietf-netconf-restconf-notif-15) -------------------------------------- Title : Dynamic Subscription to YANG Events and Datastores over RESTCONF Publication Date : November 2019 Author(s) : E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. Bierman Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Jan 4 07:02:20 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 1DE013A0DCB for ; Mon, 4 Jan 2021 07:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.074 X-Spam-Level: X-Spam-Status: No, score=-8.074 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Mz76QsEJ; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=wfdUKiA9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nayXeIHGf8Wr for ; Mon, 4 Jan 2021 07:02:16 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9263A0DC9 for ; Mon, 4 Jan 2021 07:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8008; q=dns/txt; s=iport; t=1609772536; x=1610982136; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zfpRaR3o+QNu7zlcZUcoJRRJHBbV0JLwNXjwUQrRXmg=; b=Mz76QsEJy8DhIB2y2/mJqWc1qotBCxUlLAZf6i+Z73u5lD3KHyZoMhFg HzQbkwee3C8lhgBhAOn6hzYY7NboRl1jiFLyrvVbOi7ckw18dZwU09bHT POAVGZKie9LWmleJn5kZq/EmZCmU7u00KHec+KRuqfNtX+i/LbIt/4hHF o=; X-Files: smime.p7s : 3975 X-IPAS-Result: =?us-ascii?q?A0ByBACSK/NfkJ1dJa1igliBU1F9LS4vLgqENYNIA41jA?= =?us-ascii?q?48MigGBQoERA1QEBwEBAQoDAQEjCgIEAQGESgKBbwIlNwYOAgMBAQEDAgMBA?= =?us-ascii?q?QEBBQEBAQIBBgQUAQEBAQEBhjgMhXMBAQEDARIRHQEBNwEECwIBCCUdAgICM?= =?us-ascii?q?CUCBAENBQgGFIMEAYF+VwMOEQ8BDqQsAoE8iGl2gTKDBAEBBoUBGIIJBwMGg?= =?us-ascii?q?TiBU4EiijQmG4FBP4ERQ4JWPoEEgwUBEgEjgxY0giyCSGRTgQEWBxRNEUePU?= =?us-ascii?q?SmLdYFumjoKgnaBGINGgmiUNIMpiiuUfJQLnHYZhCQCBAIEBQIOAQEGgWwia?= =?us-ascii?q?XBwFRqDClAXAg2OO4NXhRSFCQE6dDcCBgoBAQMJfIwNAYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AM35SHBMWbyErm9IwO24l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvK8x3kXHVsDW5/NYjPCQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNEfcqTi/4T8OHQ?= =?us-ascii?q?+5MhB6daz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?= =?us-ascii?q?DO5HBPfrdb?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,474,1599523200"; d="p7s'?scan'208";a="645452424" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jan 2021 15:02:15 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 104F2FtI026367 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jan 2021 15:02:15 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 Jan 2021 09:02:14 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 Jan 2021 09:02:13 -0600 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 4 Jan 2021 09:02:13 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AUU2EA+VPy7vC1oCK0UisAwk5CFKZIO97k3EemhjcAZaXLG16R7+wh5twW74ecqVktQt31ehwEVtnx4obkfBwgSIqfd2Qp87SFylyO/q/yf21jfMF19dlHUSMiKXvtQ7IJyA6hbpdYdQCN3atMIRWkyK6666DyNUKvGsWsU6MD3rWkVFiZjK4E7dH3fG5oQ1C081ncZ26yAEeF99N5kMbcQ4/v30IFxrJNPc08ijCsRHEhDmajnr9PnJHqE0hJqxgxPINirCv+WAZeQV0YRaqSw8G9N3/Gpa+ZadPeh8gmSEDhrHq7yvWYYNEq+681KQwmnTgVikQsY6o05Hulj5xA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=No+9GkXYNigYkd+WiHzX77t/JXpIz2R9MIAvuHQjaPg=; b=RYpz9va1JSwlkbTFxEvMYDlQRy0KWXL5jcWi5eLbPDhJ9VXKPd680TBNckPyM5U47TbSDOMRdYCC2+z85xYA+0WAUQ9VEWU3yVfUlmKcVfZkabiO3uKN1ZIpqWmeJudio0ymrdXdNMPtQaInVbr2UWVxhU16GuOjKLTFFXt2n0K/xaR6NmQUjqnD8jA4I9LjL9CAAb9hsDbp1F70d8eIhK/d4yoHGnKCHfwYyKilrSKCt4e9P/Wb60bQINu3PMp4h46UtoOrhmL46kgjBpoO0plvplLD64NDUXFbxFGSPIEVZiHJ5AZkDqZP0WeowK7B9bwD2gna8Q9oT9M9Ppejwg== 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=No+9GkXYNigYkd+WiHzX77t/JXpIz2R9MIAvuHQjaPg=; b=wfdUKiA9ENU8JQ2EedbRaRs8FThMhKp+e/C5Ap5gyc27/c4U4nHYNwTh/35sBK8kS5ZU5/EuDzbsZBoqq4Lpbj0mKhfmQYsOCz8PbrC0RUzWucfr/r8+epS78EAhKLDpK73pdrTSII4wSgjZaF7WMHbnWHSD515MTgO3buZ2BzM= Received: from MWHSPR01MB303.namprd11.prod.outlook.com (2603:10b6:301:35::39) by BL0PR11MB3090.namprd11.prod.outlook.com (2603:10b6:208:74::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.20; Mon, 4 Jan 2021 15:02:12 +0000 Received: from MWHSPR01MB303.namprd11.prod.outlook.com ([fe80::5413:151e:9731:ed90]) by MWHSPR01MB303.namprd11.prod.outlook.com ([fe80::5413:151e:9731:ed90%5]) with mapi id 15.20.3721.024; Mon, 4 Jan 2021 15:02:12 +0000 From: "Eric Voit (evoit)" To: RFC Errata System , "Einar Nilsen-Nygaard (einarnn)" , "ludwig@clemm.org" , "andy@yumaworks.com" , "warren@kumari.net" , "Rob Wilton (rwilton)" , "kent+ietf@watsen.net" , "mjethanandani@gmail.com" , Reshad Rahman CC: "muly_i@rad.com" , "netconf@ietf.org" Thread-Topic: [Editorial Errata Reported] RFC8650 (6379) Thread-Index: AQHW4fjEmNdCq5Qblk2DJYG6ush2/6oXkL8g Date: Mon, 4 Jan 2021 15:02:12 +0000 Message-ID: References: <20210103174910.C46A5F406D1@rfc-editor.org> In-Reply-To: <20210103174910.C46A5F406D1@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: rfc-editor.org; dkim=none (message not signed) header.d=none;rfc-editor.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [108.18.114.139] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca812752-f474-4c1e-3e3d-08d8b0c1b73a x-ms-traffictypediagnostic: BL0PR11MB3090: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1923; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: e79Q3mr/PIc20oDpMsEUGic/x/RBHDSvzOOE1HN0wwVsVbdKKu9osO6tSDFYZg/YIEaP6wdmo2X932BAafoHgP6w4pMsHa5v45D0H4y2fJyuqNpTRYw7LeTkXK/MeGuVufrB9KjnARcYItnMMjR2cP4+DpFY0ljFEVFgwbWxXHc585GxD7L/CR0bxSCmYjoAVVVbLtBXy4PC822PzH+4RluroOwoXXUZGDUiF9d8D4rCaw2Wh90ZvTzk1pWZHj6336Iv7VqyLC76bgo62M1+HsURglPxvBAB1RYAJcQGyh62aeb+ZzaZ0urEeFaG8jcrWbzlkat0FVZ3BdTihIKS6zACbfrlTVv0xrT+DNfljCDA97ZuSHTASPgYP96ah3rLzeGLL2CjkpxJJOQB62ybjYeADfMXGa1GAZEsfq1P4fqNzFZMhcWHVLCVYclSOP1R7xYKL1eJeLq0XYCBPmwyOg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHSPR01MB303.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(376002)(136003)(346002)(396003)(366004)(6506007)(83380400001)(2906002)(8936002)(316002)(478600001)(33656002)(110136005)(966005)(54906003)(5660300002)(66476007)(66616009)(66556008)(64756008)(66446008)(186003)(86362001)(66946007)(76116006)(55016002)(9686003)(26005)(52536014)(4326008)(7696005)(8676002)(71200400001)(99936003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?TXpmT01DdjZaTzNacnMzMWREWlcxUE44bTNCRG83VmJOQzROd0xtZmpOZ0NM?= =?utf-8?B?WWRRU2V5Tk5iSHlWb0dTS0lKaTFoOFc0eXFFdlcwemY4bDhCY0pRRmw4Z09P?= =?utf-8?B?ME9uSkhSODZVd25kaWd5SmpwMEZ6ZFZCVklWVmF6V0JZazRFME4zOVhmekdi?= =?utf-8?B?L3RWWGRxQWZkWjBYa096RkJIa2lKWjlvZHdSdTUzMzh1Q0x6cGllQjRsd242?= =?utf-8?B?dzMrVjBDMzY2MVl2MnBjN0hJcHlwT01iY2ZKTDFTei9vZ1JaczdPT2pYeXBr?= =?utf-8?B?bG9ydXZkVHEwRFNLai81Q1BsTGM3NExKTXc0VU9VNUVmUisyRWhBcTVZTE85?= =?utf-8?B?UWV4TG53T25icEtVUUdyb2NVZ1BnL1lLWlJEZXRBdUt5RUVId3pGQWpaYzRo?= =?utf-8?B?RFZDVHNwQXVHczEwcVZQbGNJbGFoS1NRUTlmOUc0OUl3bmt5WkpHYnpZWnBq?= =?utf-8?B?UDlpbk1paEdFTTV2S0QzWURJK1I0S1lqam1wNnE3L05sTGV5NjFBVUhMRnRG?= =?utf-8?B?ZHJ5NHR5MFFoSkQ3ZG12K2tBNjdpbWhkeFFGNXk0S0RIa3dibm1SODl5MnVy?= =?utf-8?B?OFBJTC9KWHdMREE3OW1OajBXWUxKL1pRUk5lczBONHBNbi9ZQVU2VCt4emZs?= =?utf-8?B?RmY1dldCcnZsSUsxU1FKTnZDRzVjRUpYOURnUFhVeE5yN1RHc1hXR0V0dzRi?= =?utf-8?B?akxmYlpPZ3hZYkFhS0tlYWVDOEM1dWxHN3BjKzIzWFZpcVJ3ZTdjNFc0MWI3?= =?utf-8?B?QkQ1cHFYNmlrQStvNFlFT1VUUFEwemZxREs4QUlabXFzL29DcUpTVzFOejJJ?= =?utf-8?B?ZTdGQ2o1N1VlVXowZDZuSlJnaUxXbUg4RmdBSCtNeHFuS2paWG82bzVPOTRY?= =?utf-8?B?eUszSlhuSUtydlVPbmdWcjIxclR2SDB0eDFFM3J0MkpQb2RodVZtRitkS1dU?= =?utf-8?B?ZXBLL25vZVpVRy9HbGM2WmNrUldNRjN3cFhET0FHaHQyTWxKL1NoUUNhb0Nr?= =?utf-8?B?REVPb29EK0N5ZU9HQlNkK0xWc0RTbFIzOHRud29MdFJiVDVENGg3enVqNUdX?= =?utf-8?B?d2NnakViT0NBRy92L28ydWRYeUF6ZHZqTit0QnhiOHE1ak1Wd1JEVjZidHVT?= =?utf-8?B?cmdvVkVkRmRQd1RlUUxUUlU0cmJkM29Ya2tEVktJb09JQ3NyY1U1bzl1TWEw?= =?utf-8?B?VGMvZHd5RXQ0Z2VyczMzV01LRDA0bFBNSWpEVVc1ajFEYkt6WE56dG1BUmxS?= =?utf-8?B?ak5NSkphOWtrdHpyVjQvV1hhYTl3V0RFdndqdnd0U3ErblEvSndDbUg5NzBn?= =?utf-8?Q?OClr1pVSeshG0=3D?= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00BF_01D6E280.A9044950" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHSPR01MB303.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca812752-f474-4c1e-3e3d-08d8b0c1b73a X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2021 15:02:12.1060 (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: gZ26bK8+mmvBWdwjZF1T8OaX2mglDMn6veIcP/kq+dFJE+sj7rQHjZ9mLXKlXkCs X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3090 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netconf] [Editorial Errata Reported] RFC8650 (6379) X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 04 Jan 2021 15:02:18 -0000 ------=_NextPart_000_00BF_01D6E280.A9044950 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Adding Reshad's new email. I think this should be accepted. Eric > The following errata report has been submitted for RFC8650, "Dynamic > Subscription to YANG Events and Datastores over RESTCONF". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6379 > > -------------------------------------- > Type: Editorial > Reported by: Muly Ilan > > Section: A.1.1 > > Original Text > ------------- > Upon receipt of the successful response, the subscriber does a GET to > the provided URI to start the flow of notification messages. When > the publisher receives this, the subscription is moved to the active > state (c). > > GET /restconf/subscriptions/22 > > Figure 5: "establish-subscription" Subsequent POST > > Corrected Text > -------------- > Upon receipt of the successful response, the subscriber does a GET to > the provided URI to start the flow of notification messages. When > the publisher receives this, the subscription is moved to the active > state (c). > > GET /restconf/subscriptions/22 > > Figure 5: "establish-subscription" Subsequent GET > > Notes > ----- > Substitute POST by GET in the figure caption > > 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. > > -------------------------------------- > RFC8650 (draft-ietf-netconf-restconf-notif-15) > -------------------------------------- > Title : Dynamic Subscription to YANG Events and Datastores > over > RESTCONF > Publication Date : November 2019 > Author(s) : E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. > Bierman > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG ------=_NextPart_000_00BF_01D6E280.A9044950 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMTA0MTUwMjA3WjAjBgkqhkiG 9w0BCQQxFgQUP8Hs5WF6xd4HPnxA9VRxX6AXtckwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBrSbvynFgWDQdJzkE/n/N+FHI7W7RCP/HAQEd/eZDzVHKtmJ5bNs9EivE/ylo0Qz21 zYoF+im5rt4jc4VVXgVFi5Lk52TRH/YnuomaIxSaw4vZsX1K/KNLy83JasREonaD9aI0FldOaoxM XXZ0qEf6dLAwy7FkJkCEXMHeBL2VXlOyjYll2JkUCHYZuzS3gVOG8QlIZQDd/90vUuzAmvSO8JnN LfLiORpaMJd3ouQmZC8ElwZ9Cvjnh+tFBaJXUb6U5bEZkXM4WX/cB+WinquiqKhlLhibT8G8St7U 0Nr9r5UDZFTr7yD6mQulSbGzzaf+5auxgEPvdlEaPamJPU4dAAAAAAAA ------=_NextPart_000_00BF_01D6E280.A9044950-- From nobody Mon Jan 4 07:05:44 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 A32853A0DF3 for ; Mon, 4 Jan 2021 07:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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, 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 (2048-bit key) header.d=yahoo.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 NTzqrvzgxPFL for ; Mon, 4 Jan 2021 07:05:41 -0800 (PST) Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.123]) (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 84F833A0DDF for ; Mon, 4 Jan 2021 07:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1609772734; bh=x7tmxs+ui+E5hRIlez84LKy+72VeWBYroUpfKLzust0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=KrCm5M5BDQARfX8L4EdygsvUXdCakDGGU4L3VGKBQmlTpdz2i/D3eDUutxR+CoHtdX38m0jsQqTmHH0pJP8j6umXQr6CfGYnU9t22iDo6s8NjaOA/+bj+OyLiWwkvCWC7qOVPu8k1bynXMltuJKZ2GllGH05ns+CoCneTIphZr04gSVWOBZw3M8pTV28CdM7/MMGsk/Rpt0W1WUklvBFl3TjBMTxx9h8ot6WyRoAPbpZZgPQileKPmt7P0ju3wkdYTbOx8yR5Ei2/JOyBz1RDxQShNVU2mfrsRt7O2nCtQFKlKyBwJjBtclM0XYkGF1JgcegI/A9PbdgxWR241jKIA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1609772734; bh=HRt3//bhfjyvXIkU3XkW+U2sYT4r10Ojky/+wEa0ENk=; h=Date:From:To:Subject:From:Subject; b=A5I5H1dTE0P5hWB4iYijC3GI0kvf5uZVLc9hejE5682dRQ5+KRLZcu7NNeRbuA4Fc8dI+mYlT2+UNaEMnHOUwj7UsveeChdd2NKhVSC589WMWXyKvZ/X6C+Qd0veil+fGBjCTjUqYYQBIVeMf9uLeI/3DM5WeCJlimv0MiYt+NS/k0EINvGqPvTrGbpDsChKSaN0TkQnKCtr1jJmHED+TGwwHp0XpYZhCNcvDYMlucHrTkrQZbXWKxb3UcjaoVkhEDeviLKPo7e8LOnOmbvtYzCdageAiEd7gQ+nvIiaFqVFxP8V7oZbv5JpXpgnBUoqiC6tTYEtjKlvetKm1x+ZEA== X-YMail-OSG: qPezVEEVM1kxA6WgK2hDMWhlgeNDjGe3lzDlTNdQH3ff1khM1HgUg4mCY4xJBUX YXNTVfwgsY7m0qYpHLoIZzLBZ1tuIgTJpEzJkwdQmI7yFM7ogpw1.UrCv3J0Gxe6hQzOjOyRT0_n p5_V_05J9fPiZ6cwA2XEnt0KsXIpD_zUihSlrOVK5Fzoj3NcEUVYkwJgXH.StA_ggo18t92V8DeS 1vIwA1gw8CCOFtbbRAj30vif4X7ltmc_zQbJdh0DQbRKLRe46Ruy1jVjAxLgYqeLK5b_8wtyAXZe YNdPGq_vw_sfo63BE87R4LXdUIrtaoYn8hov2soSVVdvxSE.7mToAbDEPqEXShR57XMslpw0T1_L Et9_Pp76A9T8jfSZl9bm5DfKiCL0p.Eq_MOUP.FUujyQcwKYSSgVaLfRYNA84d2QlrKG7TNt.atL B0YwtOXPuyMviU0VJKlwTgAKSfBu9pc3E7HmA1SsYO9FghNb_fe2n6GWLh2kfUINmqDQt_RcsSqC fzoDJA6PwxnDUgBksj8810bPnU.OPGBL0hJtUIt_WnTyO7I9_90F2JRKUVUnnNVTJA4w3uH9CRqZ thh9_pbWKdqa8bW6LvL.gMSRa28RylW_6s6fkUJiUNAAzm4B_5nYalUZWXcoAcsNOmRPA6eWmGV8 ijs0UK29QGMwTJAgSK0ogEFY0sqUxqQeFUPkOj3SuhLLUNUi0ZLIy9bclRwbvkM0gkdUXUOeN_KK p712DL5T67LZyt_vUAUTj_NG7vgzr0vR2jl2rZbHlAbsurFp4rd6COHdP24LAI_MpYM.KIv.eMJJ aqh69BkPcclaFx0f5orbpnywJ0wKn7E8Mtg54jTdoykkZVfS8yA.hbqEN17DUih5cWnm3y.ByBt_ 8OHH4CpKjSP3CfSOzqQs.EAmj0lPQ1fIqO96gp8LuStc.c0X7FqntGpYeCInZk3Om7D_91owjN5d UYjyfaaG5E9_YPgjl9Na8rYWIFh0aR3eO.3bxxS9NKkZONU2fLQlYyc3U6bE4qqYJwAGPJ8i1PLZ jTy92PGmjOxmf0y170rnFXmejgRXfIssBMfhz9zxEmBBT27H7uFKz7quGtqhPRLt3tpFi333J.Um MzxXNOoUwES0syEZBFMUyT8Tn57hqLXEtM1it40GlUfzkBYO5cg7B2XFLfT_S.atOthLtIaBUN4A uru7XbP5InbyZSb8QgdgJr4NdE2oO1htCeG2YykC1gwtJOzgMv9kZaVoz3rN5DkdHiQ.7ZFxZrQe yZM2KhWRoVZleOSijf_GL.zquBGJsyHBlq4N41pGZRWL7iDUe22EhPsWJsW.l1GNShlBDathd8vQ lnDG5AdGxBTUVjPd2UHotsCNJ3gJNMzKvZHRMXn_6j5gPOcdWW7nRLP1YMhq0hfBTjKHXEm5ADns 1zB7fvCjLN7YaOHuW4n_qgtDtoSHtq5OIxa9vodkVx54qh4arlAQqjHPWGR7sAioh5_Nur.WPUm4 v7XEYcpZ_p1xL1Jqnz.OokrMvaFweSTIds5UpUIHpTe9iAv_Mh1l1kV4F82XqWtxGkn3FqYUAtF_ wwGJUW0rQ84AWRJ3szIHCRHetL5DktWJj9t3VYYRpqVOW3wO.3kkyv53zOVwGoi91fniV3Re.88e i58kZxlcFbaQWuoWVGFjL6aQIi7ivT7DcosbCBjGClpp_pOs_4wkNOPnu55mvFb79D6kE4YVUTOs 1E.zSqZSg49IbUl5TDri0ptQtnOC9S7SajS0Ed58QDAJes7DzACn4FhFXYdhAdB7ezuiw6SyfieB az.0HBywh6.RnI9gHZPMkmrFJbDYVAgZ9L5.AedpUTxmeqV6ZTjiKXJN73MOQjNmKI4vVFlklVOV qqtaUHD0A3cxr_UHWmS_K8l8CHGLZwt3GMoN5h0tNqrnZ0p5GsHbGc7NRY1M3mXK6d8iCsTjHB5e zRrD05GC_n4lu74mu8I2_rrfk8Jlttu0Nf4_jWoE27yac.rJ7vNKHs6u2rpjl6R.LODv6z84xR3i H.sU3Ow3Ue.uWYBRxHshDtC2nvHjm9ZMt5IdUbV9YBhcSkWsSe1XRlr6MP3Eq2xeYuwaxmtGjCbB MOlmPVNgLpEa6spAoXD3On9yAg1y6p6WyhpQj6aZDYCvOBVh4QwhqOLKY7XkxlXSGB4zQvWKpShG DTzaL8ZQQuzsi.eEV4N0jaOnZGTgMLq.DXTvi66BTARTNF2.6Usne_u4jcMiHC1bw7vYswSlYK6T EUZGJLCwGTgdHt2AZweBXV3AbYaRwh5ONRCVpYv_DaLpnph6YIX_XI7iZFKgrxpRGEfO8f5Ory6j .4gymMgjTVcvnU_Erqz9pMOM6j1GFEYH97S9v1LFQjzKs0lWJTXBk3950MAcHc5qp4_G0yIiQxzR M9anijySDvNxA8t2_pcbJl8w1aOMj7FN.liKnkni1iUljjN9peLAzxMd4YhqCXSzgY3NP5UjBaL6 HlOO0TGYSo7kBT5rUWhid72VvsFEvHSVyY_Bee2IBngeZMYH7JyssKgudGM5btWhQsU1mWJuYrtw CrCza5mEdtjcWDI7Q4CkPgGk2riLDA0QVev4OUEx8yHPjlFJ7TTYSuW_JSHjtlXaCOrb8fkmyoA. zgY1n1GDIA.txPT7zBkNrmMOWJwZd5isQ8vMmS_VKGlWOlorCD5nwh5J_aOLzFSs5PKU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Mon, 4 Jan 2021 15:05:34 +0000 Date: Mon, 4 Jan 2021 15:04:37 +0000 (UTC) From: Reshad Rahman Reply-To: Reshad Rahman To: RFC Errata System , "Einar Nilsen-Nygaard (einarnn)" , "ludwig@clemm.org" , "andy@yumaworks.com" , "warren@kumari.net" , "Rob Wilton (rwilton)" , "kent+ietf@watsen.net" , "mjethanandani@gmail.com" , "Eric Voit (evoit)" Cc: "muly_i@rad.com" , "netconf@ietf.org" Message-ID: <1750813163.4213671.1609772677514@mail.yahoo.com> In-Reply-To: References: <20210103174910.C46A5F406D1@rfc-editor.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4213670_1579854331.1609772677513" X-Mailer: WebService/1.1.17278 YMailNorrin Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.3 Safari/605.1.15 Archived-At: Subject: Re: [netconf] [Editorial Errata Reported] RFC8650 (6379) X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 04 Jan 2021 15:05:43 -0000 ------=_Part_4213670_1579854331.1609772677513 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree. On Monday, January 4, 2021, 10:02:17 AM EST, Eric Voit (evoit) wrote: =20 =20 Adding Reshad's new email.=C2=A0 I think this should be accepted. Eric > The following errata report has been submitted for RFC8650, "Dynamic > Subscription to YANG Events and Datastores over RESTCONF". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6379 > > -------------------------------------- > Type: Editorial > Reported by: Muly Ilan > > Section: A.1.1 > > Original Text > ------------- >=C2=A0 =C2=A0 Upon receipt of the successful response, the subscriber does= a GET to >=C2=A0 =C2=A0 the provided URI to start the flow of notification messages.= =C2=A0 When >=C2=A0 =C2=A0 the publisher receives this, the subscription is moved to th= e active >=C2=A0 =C2=A0 state (c). > >=C2=A0 =C2=A0 GET /restconf/subscriptions/22 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 5: "establish-subs= cription" Subsequent POST > > Corrected Text > -------------- >=C2=A0 =C2=A0 Upon receipt of the successful response, the subscriber does= a GET to >=C2=A0 =C2=A0 the provided URI to start the flow of notification messages.= =C2=A0 When >=C2=A0 =C2=A0 the publisher receives this, the subscription is moved to th= e active >=C2=A0 =C2=A0 state (c). > >=C2=A0 =C2=A0 GET /restconf/subscriptions/22 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 5: "establish-subs= cription" Subsequent GET > > Notes > ----- > Substitute POST by GET in the figure caption > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please use= =20 > "Reply > All" to discuss whether it should be verified or rejected. When a decisio= n=20 > is > reached, the verifying party can log in to change the status and edit the= =20 > report, if > necessary. > > -------------------------------------- > RFC8650 (draft-ietf-netconf-restconf-notif-15) > -------------------------------------- > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Dynamic Subscript= ion to YANG Events and Datastores=20 > over > RESTCONF > Publication Date=C2=A0 =C2=A0 : November 2019 > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : E. Voit, R. Rahman, E. Nils= en-Nygaard, A. Clemm, A.=20 > Bierman > 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 Configur= ation > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operations = and Management > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF > Verifying Party=C2=A0 =C2=A0 : IESG =20 ------=_Part_4213670_1579854331.1609772677513 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree.

=20
=20
On Monday, January 4, 2021, 10:02:17 AM EST, Eric Voit = (evoit) <evoit@cisco.com> wrote:


Adding Reshad's new email.  I t= hink this should be accepted.

Eric

> The following errata report has been subm= itted for RFC8650, "Dynamic
> Subscription to YANG Eve= nts and Datastores over RESTCONF".
>
> --------------------------------------
> You may= review the report below and at:
> https://www.rfc-editor.org/errata/eid6379
>
> --------------------------------------
> Type: Editorial
> Reported by: Muly Il= an <muly_i@rad.com>
>
> Section: A.1.1
>
> Orig= inal Text
> -------------
> =   Upon receipt of the successful response, the subscriber does a GET = to
>    the provided URI to start the flow o= f notification messages.  When
>    the= publisher receives this, the subscription is moved to the active
>    state (c).
>
>    GET /restconf/subscriptions/22
>= ;
>              Fi= gure 5: "establish-subscription" Subsequent POST
>
> Corrected Text
> -------------->    Upon receipt of the successful response, = the subscriber does a GET to
>    the provid= ed URI to start the flow of notification messages.  When
>    the publisher receives this, the subscription is mov= ed to the active
>    state (c).
>
>    GET /restconf/subscriptions= /22
>
>       = ;       Figure 5: "establish-subscription" Subsequent GET>
> Notes
> --= ---
> Substitute POST by GET in the figure caption
>
> Instructions:
= > -------------
> This erratum is currently posted = as "Reported". If necessary, please use
> "Reply
> All" to discuss whether it should be verified or rejecte= d. When a decision
> is
> reache= d, the verifying party can log in to change the status and edit the
> report, if
> necessary.
>
> --------------------------------------
> RFC8650 (draft-ietf-netconf-restconf-notif-15)
> --------------------------------------
>= ; Title              : Dynamic Subscrip= tion to YANG Events and Datastores
> over
> RESTCONF
> Publication Date    := November 2019
> Author(s)        =   : E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A.
> Bierman
> Category      &nbs= p;     : PROPOSED STANDARD
> Source  &n= bsp;           : Network Configuration
> Area                : O= perations and Management
> Stream      =         : IETF
> Verifying Party&n= bsp;   : IESG
------=_Part_4213670_1579854331.1609772677513-- From nobody Mon Jan 4 11:03:18 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 404843A0FCB for ; Mon, 4 Jan 2021 11:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.089 X-Spam-Level: X-Spam-Status: No, score=-0.089 tagged_above=-999 required=5 tests=[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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 2K6FJxn5UDQr for ; Mon, 4 Jan 2021 11:03:15 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2111.outbound.protection.outlook.com [40.107.236.111]) (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 3FB6F3A0FBD for ; Mon, 4 Jan 2021 11:03:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ihnpBZ7uZzu7NDYx89pmvZ1BxjGhxR/soMhsRb/OkGQ+O1ChH2fOMC/9LVMebxZGa+h7e+mI9KnffZN0UwlLzsng3euizlGD/hnK+ietOMdGm0ZxtyH76bpJwGQK2PPer0f37zq/KVtdAOl7qmBGV0PEYMLFa15sZjKYNdIpYcAYY5aLy5ShP6tv2Py/eYxD7uiOsI7eyOpbYjsFEPYPpKzbZt3V9H82xaxfMLIDL7/rHsDXOQ01iOxquzLnACseuCkpPer0Uyp41zHBNuRpQnVX/NFMnaWaVGrZaxjxVZcsEwF9cDiMGu5De5VVL8SJ77Jdh81enCjHs2tjXOY9tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m6ogNDETTy46XPabk9ynMnL5EhdbnUsnm7GmgryWT+8=; b=C3mpsuIZJCpq0M2z8Sdcof0G1mpgP9NABtk3fFMa0+NgBnxWWZQuZbJlkxm4FU7BUbi0s+/GLdB4tRhTASPT45XtRlSKth5v5xLC2YMGm91Xso4ABfZ3/RN+CKDw8FipeGl2tBN+M5fA2iQaSlP58q18bZ2CUkNaglfgvFXKumvAsUtfU9olJwJWrazREGoNk58DqWqBlOiXAZCx237Uj7TYwxVXoDdLdNqfcFc/Xaddn/L00Mo0nX6Krt0h2GCvByn3N8Y1sMRWfV2C7sLJFCzV7ZRjqnqHyn6VqVAUxtl6X8TQLKqnEQQBiFXiy1iDB3enWW2LaHx+iXPUUbrGEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m6ogNDETTy46XPabk9ynMnL5EhdbnUsnm7GmgryWT+8=; b=BgjGJad/kFWrKJ6B/7nNh1VMT5k9Fd3ZWMA5vKXMmLPC18JA1wjdevYiRZUwuuj7TlXr5I3ujHcT7ZjJtfE3Ebwhp+Oeg+9cCD7PNt2ZJcWLJnDxTYaJWDIUaQEs0lHAy6fvmuFCh3OL4Q7wn+87A6ttbbvK9Yeo9dSXclv1sJA= Received: from BY5PR13MB3793.namprd13.prod.outlook.com (2603:10b6:a03:226::15) by BY5PR13MB3892.namprd13.prod.outlook.com (2603:10b6:a03:226::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.2; Mon, 4 Jan 2021 19:03:12 +0000 Received: from BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::81f6:a35d:1051:da32]) by BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::81f6:a35d:1051:da32%7]) with mapi id 15.20.3742.006; Mon, 4 Jan 2021 19:03:11 +0000 From: Alexander Clemm To: Reshad Rahman , RFC Errata System , "Einar Nilsen-Nygaard (einarnn)" , "ludwig@clemm.org" , "andy@yumaworks.com" , "warren@kumari.net" , "Rob Wilton (rwilton)" , "kent+ietf@watsen.net" , "mjethanandani@gmail.com" , "Eric Voit (evoit)" CC: "netconf@ietf.org" Thread-Topic: [netconf] [Editorial Errata Reported] RFC8650 (6379) Thread-Index: AQHW4qqlSSzTe0nbSkS8WME3Tlt8QKoXkICAgABCf1A= Date: Mon, 4 Jan 2021 19:03:11 +0000 Message-ID: References: <20210103174910.C46A5F406D1@rfc-editor.org> <1750813163.4213671.1609772677514@mail.yahoo.com> In-Reply-To: <1750813163.4213671.1609772677514@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yahoo.com; dkim=none (message not signed) header.d=none;yahoo.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [73.189.160.186] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62f8ec00-49b5-4261-c0ab-08d8b0e361ed x-ms-traffictypediagnostic: BY5PR13MB3892: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 54/9OiSDqLC5Aim2Z9dMh8SY6dE9vuRj6a8MwfDHuwMTTaaEjWE7nGF6So67k8fif78G7SUGMYCi77G7DuXi7Rac+oRlG9Ow4WsM94Jh3keLW2ieL1FL8puDxFgUe2Ikekn/ZfuK5M9ZwIqyc2Dlv3FrOAJKAVNVlyNsEXY4/otqO0q3lAHscZgfd7l7RKRrOr1ljQyGbxoJSRunEKvwYVQg/XIYkgPlnF8PeaRjmLWHssUmjrO19naLWB0xF5xvvmUdiPosAdRhPlGgRR7jMSKd+ONAIaF34HyjbBx+sraJnJzsLLTtzN8zjvQyj9Uvfg58+S5cxJGUTcyc2ic4nhTgW5SXrmIGwzwRuteEQwHS3QI7SU9Xb13j/pXp3PBH9I/R3RjHzd+wZ0h4mJlN1jRDGcwBy1O+al3pwgieUo8InT7BJM25N7LsD1eLQViPprY20wow5Jnh5QHcRm1yGTxVcgHClj30ft+278EavGCXp//ZuLtWi4imP8OeqJWaXhfFrj681eRRF5tN+yxDEA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3793.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(396003)(346002)(39840400004)(366004)(2906002)(8936002)(478600001)(53546011)(66446008)(71200400001)(6506007)(26005)(186003)(5660300002)(52536014)(66476007)(66556008)(64756008)(921005)(76116006)(66946007)(9686003)(8676002)(55016002)(86362001)(7696005)(4326008)(166002)(83380400001)(966005)(110136005)(316002)(33656002)(7416002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?uLEf6PEe4y4sGGxG5sGPdz79LhDO37fdFqOHks1Dl+rqJt8E9mwrTAWwJ9g/?= =?us-ascii?Q?xBIieTQWaCdTXwr0o7/AYc588HG0NS+kPUOjx5JOZcd2245yNxuccM8NFaDB?= =?us-ascii?Q?r1AZ0ztXBRT+28ofmrS+dbDOybib/5DEMfjjGW8NHfQY9f+kKgZE2Tu5Q4Nz?= =?us-ascii?Q?zfdQLkinToxAaXpe3xU6N74Q2qxzoReYCXdWxjwfiu7SCx8DUl6ihA3YaSW5?= =?us-ascii?Q?RsgTMjv+W8XitaWwDVZrFOCcXaN3mppWMAVgRoiJguGMQwthI5NWXWrYCsnK?= =?us-ascii?Q?wVAb+RD1mz7yF43zgxV8hOcV09OH5rD7geuKApTfOZNzLhwzE6G0ZUI4U4j1?= =?us-ascii?Q?dI1qLaqTH1xFaB2IwvtMQx3oL6KNmzmNqWaFJMzNor+A5dEqvP/NwmN7w1yH?= =?us-ascii?Q?LxFTC90q/h2LsiCfxWcPLWzf0xXobz1cu+ieyZHthzT9rs77mfCJjHZQsvzN?= =?us-ascii?Q?0eJvy32t17RbnQ0uaITivxDdj12dRXeMA1v1a4Wd/r8MFcnWvFreN8M/hKDf?= =?us-ascii?Q?A0lg+g+5y0bbwkMer0vZgjhKa5AqaACFYE7is44NuGLsUBYxO/WVpMTYhloj?= =?us-ascii?Q?czjuKpHv017vTsj/NclHGt6YQXAw1jBD2PN3D3yLEht01cTx0Hhif+Tf1AaI?= =?us-ascii?Q?XwiCGyscDm43OWVaFCZl5ZH99gxAbC+2SISYflVBfGFUeDoO5upKNkwEAGs5?= =?us-ascii?Q?iiwdqDuQ+NiaB4BQxv5jCJNO3wgFzY5/Ih5m1E9AqBmakXXtiLmyCL84U99+?= =?us-ascii?Q?ZAcp9q4a3VXSSD0/uiqSnNSPDFVJAADS5qtBKxSkqgGMoHj8g5NKVZUHEuiq?= =?us-ascii?Q?BBrJxohTEuk300QnM/040npdFPX5aiOcBn4GbM+s3h8O4OGVb90/GeFweAoI?= =?us-ascii?Q?O43mIcIv04edCYwSi7S3zsjo/1ktcjKwo4crJVCleSzxjd593BwdPq75U8gW?= =?us-ascii?Q?MjY3TOF2xTGKyp98WkyrmjSgqG4EIrjg9cTcFlFc/Kw=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR13MB3793BEB508BF330F053952F4DBD20BY5PR13MB3793namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3793.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62f8ec00-49b5-4261-c0ab-08d8b0e361ed X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2021 19:03:11.8696 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AG1vHp5szyhKnAHHVMcc4iZ2NmUDwqARL7ih3xrPGcFX1SWkFypSkcDrkWws/v3eq1klSne1R5I0qggbEz92Fw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3892 Archived-At: Subject: Re: [netconf] [Editorial Errata Reported] RFC8650 (6379) X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 04 Jan 2021 19:03:17 -0000 --_000_BY5PR13MB3793BEB508BF330F053952F4DBD20BY5PR13MB3793namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 --- Alex From: netconf On Behalf Of Reshad Rahman Sent: Monday, January 4, 2021 7:05 AM To: RFC Errata System ; Einar Nilsen-Nygaard (ei= narnn) ; ludwig@clemm.org; andy@yumaworks.com; warren@ku= mari.net; Rob Wilton (rwilton) ; kent+ietf@watsen.net; m= jethanandani@gmail.com; Eric Voit (evoit) Cc: netconf@ietf.org Subject: Re: [netconf] [Editorial Errata Reported] RFC8650 (6379) I agree. On Monday, January 4, 2021, 10:02:17 AM EST, Eric Voit (evoit) > wrote: Adding Reshad's new email. I think this should be accepted. Eric > The following errata report has been submitted for RFC8650, "Dynamic > Subscription to YANG Events and Datastores over RESTCONF". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6379 > > -------------------------------------- > Type: Editorial > Reported by: Muly Ilan > > > Section: A.1.1 > > Original Text > ------------- > Upon receipt of the successful response, the subscriber does a GET to > the provided URI to start the flow of notification messages. When > the publisher receives this, the subscription is moved to the active > state (c). > > GET /restconf/subscriptions/22 > > Figure 5: "establish-subscription" Subsequent POST > > Corrected Text > -------------- > Upon receipt of the successful response, the subscriber does a GET to > the provided URI to start the flow of notification messages. When > the publisher receives this, the subscription is moved to the active > state (c). > > GET /restconf/subscriptions/22 > > Figure 5: "establish-subscription" Subsequent GET > > Notes > ----- > Substitute POST by GET in the figure caption > > 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 decisio= n > is > reached, the verifying party can log in to change the status and edit the > report, if > necessary. > > -------------------------------------- > RFC8650 (draft-ietf-netconf-restconf-notif-15) > -------------------------------------- > Title : Dynamic Subscription to YANG Events and Datastores > over > RESTCONF > Publication Date : November 2019 > Author(s) : E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. > Bierman > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG --_000_BY5PR13MB3793BEB508BF330F053952F4DBD20BY5PR13MB3793namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

--- Alex

 

From: netconf <netconf-bounces@ietf.org>= ; On Behalf Of Reshad Rahman
Sent: Monday, January 4, 2021 7:05 AM
To: RFC Errata System <rfc-editor@rfc-editor.org>; Einar Nilse= n-Nygaard (einarnn) <einarnn@cisco.com>; ludwig@clemm.org; andy@yumaw= orks.com; warren@kumari.net; Rob Wilton (rwilton) <rwilton@cisco.com>= ; kent+ietf@watsen.net; mjethanandani@gmail.com; Eric Voit (evoit) <evoit@cisco.com>
Cc: netconf@ietf.org
Subject: Re: [netconf] [Editorial Errata Reported] RFC8650 (6379)

 

I agree.

 

On Monday, January 4, 2021, 10:02:1= 7 AM EST, Eric Voit (evoit) <evoit@ci= sco.com> wrote:

 

 

Adding Reshad's new email.  I = think this should be accepted.

Eric



> The following errata report has been submitted for RFC8650, "Dyna= mic
> Subscription to YANG Events and Datastores over RESTCONF".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6379
>
> --------------------------------------
> Type: Editorial
> Reported by: Muly Ilan <muly_i@rad.com>
>
> Section: A.1.1
>
> Original Text
> -------------
>    Upon receipt of the successful response, the subscriber d= oes a GET to
>    the provided URI to start the flow of notification messag= es.  When
>    the publisher receives this, the subscription is moved to= the active
>    state (c).
>
>    GET /restconf/subscriptions/22
>
>              Figure 5: "establ= ish-subscription" Subsequent POST
>
> Corrected Text
> --------------
>    Upon receipt of the successful response, the subscriber d= oes a GET to
>    the provided URI to start the flow of notification messag= es.  When
>    the publisher receives this, the subscription is moved to= the active
>    state (c).
>
>    GET /restconf/subscriptions/22
>
>              Figure 5: "establ= ish-subscription" Subsequent GET
>
> Notes
> -----
> Substitute POST by GET in the figure caption
>
> 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.
>
> --------------------------------------
> RFC8650 (draft-ietf-netconf-restconf-notif-15)
> --------------------------------------
> Title              : Dynamic Subscr= iption to YANG Events and Datastores
> over
> RESTCONF
> Publication Date    : November 2019
> Author(s)          : E. Voit, R. Rahman, E. N= ilsen-Nygaard, A. Clemm, A.
> Bierman
> Category            : PROPOSED STANDARD<= br> > Source              : Network Confi= guration
> Area                : Operatio= ns and Management
> Stream              : IETF
> Verifying Party    : IESG

--_000_BY5PR13MB3793BEB508BF330F053952F4DBD20BY5PR13MB3793namp_-- From nobody Tue Jan 5 02:06:14 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 955433A09C5; Tue, 5 Jan 2021 02:06:08 -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 VZJd2OIxps-Z; Tue, 5 Jan 2021 02:06:07 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF323A09C1; Tue, 5 Jan 2021 02:06:07 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 363FDF40760; Tue, 5 Jan 2021 02:06:05 -0800 (PST) To: muly_i@rad.com, evoit@cisco.com, rrahman@cisco.com, einarnn@cisco.com, ludwig@clemm.org, andy@yumaworks.com X-PHP-Originating-Script: 1005:errata_mail_lib.php 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: <20210105100605.363FDF40760@rfc-editor.org> Date: Tue, 5 Jan 2021 02:06:05 -0800 (PST) Archived-At: Subject: [netconf] [Errata Verified] RFC8650 (6379) X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 05 Jan 2021 10:06:09 -0000 The following errata report has been verified for RFC8650, "Dynamic Subscription to YANG Events and Datastores over RESTCONF". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6379 -------------------------------------- Status: Verified Type: Editorial Reported by: Muly Ilan Date Reported: 2021-01-03 Verified by: Rob Wilton (IESG) Section: A.1.1 Original Text ------------- Upon receipt of the successful response, the subscriber does a GET to the provided URI to start the flow of notification messages. When the publisher receives this, the subscription is moved to the active state (c). GET /restconf/subscriptions/22 Figure 5: "establish-subscription" Subsequent POST Corrected Text -------------- Upon receipt of the successful response, the subscriber does a GET to the provided URI to start the flow of notification messages. When the publisher receives this, the subscription is moved to the active state (c). GET /restconf/subscriptions/22 Figure 5: "establish-subscription" Subsequent GET Notes ----- Substitute POST by GET in the figure caption -------------------------------------- RFC8650 (draft-ietf-netconf-restconf-notif-15) -------------------------------------- Title : Dynamic Subscription to YANG Events and Datastores over RESTCONF Publication Date : November 2019 Author(s) : E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. Bierman Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Jan 5 02:06:50 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 AE6B63A09CD for ; Tue, 5 Jan 2021 02:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.519 X-Spam-Level: X-Spam-Status: No, score=-9.519 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=FGIHKxGG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vlkTvQTx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD4IW8Z3tV_P for ; Tue, 5 Jan 2021 02:06:46 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4F93A09C1 for ; Tue, 5 Jan 2021 02:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14496; q=dns/txt; s=iport; t=1609841206; x=1611050806; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PoqV15OdVPAHUp92oimo2NxlFbJwQ2bSYP33voofiJ4=; b=FGIHKxGGNNaiXhKMv0o1tDJrWgjvBR8IcOH65SmsBNl1gN8dydPZp3wg oG1AaBk4lWKcO2KRdG8+I5K6RuMoHaM8kcuNtm5J+tLqFWHWt59UtFOF0 hZCf01WLto4Woci0Z2JmGf4jHg5dn+akqOT093ITHskeBdIitXXhTCYmP c=; X-IPAS-Result: =?us-ascii?q?A0DaAgC+N/RfkJBdJa1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+BIzBRfVsvLgqHfQONZQOCcIcrhHKFD4RzgUKBEQNUCwEBAQ0BASILAgQBA?= =?us-ascii?q?YFsgl4CgW8CJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBhjgMhXMBA?= =?us-ascii?q?QEDARIbEwEBNwEECwIBCA4DBAEBDhoHIRETAQkIAgQBDQUIGoJ/BAEBgX5XA?= =?us-ascii?q?w4gAQMLo0ICgTyIaXSBNIMEAQEGhQMDCguCEAMGgTiCdYUCgUCDciYbgUE/g?= =?us-ascii?q?RFDglY+gQSBF0IEF4ERARIBIysJgxaCLIFpXyBEU4EBFgcUIisRR4xaCYJwE?= =?us-ascii?q?BmKMIM0iHyQZ1gKgnaJKo0VBoU5gymKK5UDlA6OC45xGYQlAgQCBAUCDgEBB?= =?us-ascii?q?oFtIQ9acHAVGoMKEz0XAg2OIRqDV4UUhQkBOnQCAQEBMgIGCgEBAwl8iyABg?= =?us-ascii?q?RABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AsZnnvhDWg7v2ftEPCb9iUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw31g3HQJnG8f9bhuuQuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFPPvmCo4CEfG1?= =?us-ascii?q?P0Mg8mbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,476,1599523200"; d="scan'208,217";a="623067801" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Jan 2021 10:06:45 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 105A6jwk008439 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jan 2021 10:06:45 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 5 Jan 2021 04:06:45 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 5 Jan 2021 04:06:44 -0600 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 5 Jan 2021 04:06:44 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DG2aF50BVSPE6cwsCJo0G2y1Z5WE2qtZkNYBrKuBx2JXoizdNQgKHtzdkEgj4zHbeXu6fbzujNl01Eto8AsNx0Bx7+LHdh8IBtp0u6Kf2ZwNZMLjSTcMoiKPv+mh1Qc3Xn+dKkaUL4b6Ise7BAqD5he9nHj0cfjjVlsFfCnqAkcNzeghBTvIDRWMlqtGWdX13YeXojPmBocwrskIqtPQXdOOPL3pfvRia/kC/9VOs/5cBMY0611xJGF/gB/TbhXiuLehi4pjIyjBT8Q1jFdXJyN2LZ1NW04r2IEUvaqRcWk9WeEywwmDKzkP0loz8ewyguY9N3Y073AkPNEQLlzwuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JGpUiKDpMo2cvXrctwI/I7nN12tc1pPE+pkPFB/358U=; b=A1rbWQIKzxG8dbgtERTZ3R5w9i9XpDajQ0v0Kii8KsXplfCEA1QhKD1meSad66OQgHmUKLkD6moIUvLXfFwQnzGQXaTAQFnqG7DMoWiuVR/0fVIOI6FKfmK/Bgqi7cdeXQJCreSK/INoAHlr7sA+8d/dhGLycHyhed+Z/0jMQYVKxsvtl6+NKU9izAcL3a1hghrkPEgD51Qb+qfGafU7ZmnBXyY5WzJqaWTqBaGAKcUtJXYmWJ8ZvKWYMIP27s4AniwbkpOKyBcLoEZyVIYozHadiRHWvTYeL2vtscFyGg//bUuzDbHTIJq4mfkjaKC46IxBcOHFpzyJ93PyKLpbhw== 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=JGpUiKDpMo2cvXrctwI/I7nN12tc1pPE+pkPFB/358U=; b=vlkTvQTxhmoS3IeswsdsM01CyzYOXjHrDQQPMzpPNBDN0Zcl6tklkaMgJK+4TkyZcnOIFNIhTJj2/IYV6fBw5gsC0SNOYo/+csGme26g7Sh4YkmUQuPmFS7jQOhWZKpmGPmviIm2Z+TyRZjpFQXBGCHXAFN9ajuAucHHduwbV/o= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4477.namprd11.prod.outlook.com (2603:10b6:208:17a::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.22; Tue, 5 Jan 2021 10:06:43 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3c82:1fa3:2b18:3afb]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3c82:1fa3:2b18:3afb%6]) with mapi id 15.20.3721.024; Tue, 5 Jan 2021 10:06:43 +0000 From: "Rob Wilton (rwilton)" To: Alexander Clemm , Reshad Rahman , RFC Errata System , "Einar Nilsen-Nygaard (einarnn)" , "ludwig@clemm.org" , "andy@yumaworks.com" , "warren@kumari.net" , "kent+ietf@watsen.net" , "mjethanandani@gmail.com" , "Eric Voit (evoit)" CC: "netconf@ietf.org" Thread-Topic: [netconf] [Editorial Errata Reported] RFC8650 (6379) Thread-Index: AQHW4fjEWSao3Uj84EWnw4tI16HYJ6oXkTcAgAAArYCAAEKogIAA/E+Q Date: Tue, 5 Jan 2021 10:06:43 +0000 Message-ID: References: <20210103174910.C46A5F406D1@rfc-editor.org> <1750813163.4213671.1609772677514@mail.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c5cb0b90-06c3-4e42-9b84-08d8b1619a56 x-ms-traffictypediagnostic: MN2PR11MB4477: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EnljrcGoZ9EtFeAeoWLrGOudOHINVGzTI4ncTj/0+D5Z5WzQ1Sk71z4j6bGenf3luzL6T5ggMzI4rVN2Ccg32HEdYPZDbrqXpOUbhJeUqOXZRLbRRTXMD/0Dqedw3AkkQEqWLim5KS8/FlnEXRvIg1gTtkl2qupvIWp3fphKr4YZs2nFUz5oIsqqZTNzXfXGIBvjvgkHvopCKMUh6caaef0pNXgtz5sRwW22rOClUAiNecvreoDs7zbE3uEhe8IBNOAosKnwyrKiZBfJjKkre/tTomDL6HrJeHSE2COGL3I2oqVOpJae9ZEyJ2XMJwoCuXngZqTMAqcgvtVWU44RobjSspqDClhp90jzvQ27TdnLdPq5Bcjvju7PFL+hU/ZIbHrrYMim+Ejai22w0HWLnrP89/Ol8DeQtrdMH6BvkQl4E6YvDY/IpZJwxbtm5tMpb4pTavJ1JXbpkMKTVHfv2tyHr0pctokckUItiA2cB5J9ugUZoLFBvOcM7pYNTpYaFoca1dEYOfazNBNm8h578w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(396003)(39860400002)(376002)(366004)(136003)(64756008)(66556008)(166002)(66946007)(4326008)(53546011)(8676002)(186003)(5660300002)(921005)(66476007)(2906002)(86362001)(6506007)(966005)(110136005)(6636002)(478600001)(26005)(66446008)(52536014)(9686003)(71200400001)(7696005)(55016002)(83380400001)(316002)(8936002)(33656002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?hy5njZhDc2Pi/DUtGBpVSzANKpW1kgO+vmXsNlT8x47WkApWX7fGKHeKj+ax?= =?us-ascii?Q?83KlEjW5TdfxeH0gyWYtYwVkx9Lw57knq+QiteNELWCLYtR6BHe0wUzyzVRB?= =?us-ascii?Q?B7PL3cATn6YWmxMMOmifJ3CgHvHeFcEOPORZWFr8cB5f8fjZWRhyRVjnw3Om?= =?us-ascii?Q?gBVDWJ9R9blSFT6OpTfsmlaVXgaYcayV2iYb5wdZQsmHj3ie7sFojzJ9+QYq?= =?us-ascii?Q?j248+fN/JggBc37DrXnq0WkfjHoFWICy+cPByzVbH0LnHmK/+M7xQRWLTRWz?= =?us-ascii?Q?GHnwUEPM48t1oGHhQlNVlvqEPQUpgCJZZlQ5biiiahd/G/N2BvOE90KpcdOl?= =?us-ascii?Q?RcujtSbl3+5AWVtK0JFjSsxHA+4lzDElIPUZaKnDhoIPCAn5gP2MN+xd0n5S?= =?us-ascii?Q?pBR8aPybeYjYC+Xdmi7Wrh753x9Y9oxJD5I0id8q58QB5gExhuTDewq61WNL?= =?us-ascii?Q?V4i1JZmextO8eFYzsLdjBym2NyaeqnGgcGHiy9aEIld7bNsUMkSLaZ+QdogZ?= =?us-ascii?Q?ob+YB4dlVGqcPRpmRTANO1e/BW7z+CenFO+Y6jwrqqqQm7uEz8kvSwczsPST?= =?us-ascii?Q?bYKZxamOdxtYQTXLy+GCO6FlVfmry+UiDHSpFwrOmKEGycyCeIQTLL58tio4?= =?us-ascii?Q?S2jKTEfXcujgYaPUoSRZxscHkCCce6zGGYAFrFJ0gsC7KMUeLOd4BYc+1Drh?= =?us-ascii?Q?ui5KZQfFrUu3CdMzSvSUiqITg7SbH0N/xxlX1kAWvYYlQIRf55IUGe47pagc?= =?us-ascii?Q?q1Lf5ZfUoZhzN8eu0dmbuwHxzPakmZzvZgFD9eEBFXScWWRrThL82HwvgIiR?= =?us-ascii?Q?pZjqThs9dS8ZCQ8g64iQ9LGOgduzbLF+ZRmvEtE8mRd4TQPZIE6fiVJpJM9q?= =?us-ascii?Q?uyncP0RpG3352Pjvv9SggGQOcVWjrBXTZUROmth1x+rJ0SxQVD0cEfyFPTUc?= =?us-ascii?Q?jRsqrZxRraUcz21jG5iUYMzrQIqu++Eg/dqAXyyHpK8=3D?= Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366D5E5806A6AE44CB4F886B5D10MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5cb0b90-06c3-4e42-9b84-08d8b1619a56 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2021 10:06:43.0657 (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: 00BRac3nkJA18kEUgBQp7uY+UzMD0wMEXEhLID5ijP++RK7G4RxCGEGT1O3Cw9zawBefqmjZ0MC+LD+jSYYCXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4477 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [netconf] [Editorial Errata Reported] RFC8650 (6379) X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 05 Jan 2021 10:06:49 -0000 --_000_MN2PR11MB4366D5E5806A6AE44CB4F886B5D10MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks all for confirming. I have verified this errata. Regards, Rob From: Alexander Clemm Sent: 04 January 2021 19:03 To: Reshad Rahman ; RFC Errata System ; Einar Nilsen-Nygaard (einarnn) ; ludwig@clemm.= org; andy@yumaworks.com; warren@kumari.net; Rob Wilton (rwilton) ; kent+ietf@watsen.net; mjethanandani@gmail.com; Eric Voit (evoit)= Cc: netconf@ietf.org Subject: RE: [netconf] [Editorial Errata Reported] RFC8650 (6379) +1 --- Alex From: netconf > O= n Behalf Of Reshad Rahman Sent: Monday, January 4, 2021 7:05 AM To: RFC Errata System >; Einar Nilsen-Nygaard (einarnn) >; ludwig@clemm.org; andy@yumaworks.com<= mailto:andy@yumaworks.com>; warren@kumari.net; Ro= b Wilton (rwilton) >; kent+ietf= @watsen.net; mjethanandani@gmail.com; Eric Voit (evoit) > Cc: netconf@ietf.org Subject: Re: [netconf] [Editorial Errata Reported] RFC8650 (6379) I agree. On Monday, January 4, 2021, 10:02:17 AM EST, Eric Voit (evoit) > wrote: Adding Reshad's new email. I think this should be accepted. Eric > The following errata report has been submitted for RFC8650, "Dynamic > Subscription to YANG Events and Datastores over RESTCONF". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6379 > > -------------------------------------- > Type: Editorial > Reported by: Muly Ilan > > > Section: A.1.1 > > Original Text > ------------- > Upon receipt of the successful response, the subscriber does a GET to > the provided URI to start the flow of notification messages. When > the publisher receives this, the subscription is moved to the active > state (c). > > GET /restconf/subscriptions/22 > > Figure 5: "establish-subscription" Subsequent POST > > Corrected Text > -------------- > Upon receipt of the successful response, the subscriber does a GET to > the provided URI to start the flow of notification messages. When > the publisher receives this, the subscription is moved to the active > state (c). > > GET /restconf/subscriptions/22 > > Figure 5: "establish-subscription" Subsequent GET > > Notes > ----- > Substitute POST by GET in the figure caption > > 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 decisio= n > is > reached, the verifying party can log in to change the status and edit the > report, if > necessary. > > -------------------------------------- > RFC8650 (draft-ietf-netconf-restconf-notif-15) > -------------------------------------- > Title : Dynamic Subscription to YANG Events and Datastores > over > RESTCONF > Publication Date : November 2019 > Author(s) : E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. > Bierman > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG --_000_MN2PR11MB4366D5E5806A6AE44CB4F886B5D10MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks al= l for confirming.  I have verified this errata.

&nbs= p;

Regards,<= o:p>

Rob<= /o:p>

&nbs= p;

&nbs= p;

From: Alexander Clemm <alex@futurewei.com>
Sent: 04 January 2021 19:03
To: Reshad Rahman <reshad@yahoo.com>; RFC Errata System <rf= c-editor@rfc-editor.org>; Einar Nilsen-Nygaard (einarnn) <einarnn@cis= co.com>; ludwig@clemm.org; andy@yumaworks.com; warren@kumari.net; Rob Wi= lton (rwilton) <rwilton@cisco.com>; kent+ietf@watsen.net; mjethanandani@gmail.com; Eric Voit (evoit) <evoit@cisco.com>
Cc: netconf@ietf.org
Subject: RE: [netconf] [Editorial Errata Reported] RFC8650 (6379)

 

+1

--- Alex

 

From: netconf <netconf= -bounces@ietf.org> On Behalf Of Reshad Rahman
Sent: Monday, January 4, 2021 7:05 AM
To: RFC Errata System <rfc-editor@rfc-editor.org>; Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com>; ludwig@clemm.org; andy@yumaworks.com; warren@kumari.= net; Rob Wilton (rwilton) <rwil= ton@cisco.com>; kent+ietf@watsen.net; mjethanandani@gmail.com; Eric Voit (evoit) <evoit@cisco.com>
Cc: netconf@ietf.org
Subject: Re: [netconf] [Editorial Errata Reported] RFC8650 (6379)

 

I agree.

 

On Monday, January 4= , 2021, 10:02:17 AM EST, Eric Voit (evoit) <evoit@cisco.com> wrote:

 

 

Adding Reshad's new = email.  I think this should be accepted.

Eric



> The following errata report has been submitted for RFC8650, "Dyna= mic
> Subscription to YANG Events and Datastores over RESTCONF".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6379
>
> --------------------------------------
> Type: Editorial
> Reported by: Muly Ilan <muly_i@rad.com>
>
> Section: A.1.1
>
> Original Text
> -------------
>    Upon receipt of the successful response, the subscriber d= oes a GET to
>    the provided URI to start the flow of notification messag= es.  When
>    the publisher receives this, the subscription is moved to= the active
>    state (c).
>
>    GET /restconf/subscriptions/22
>
>              Figure 5: "establ= ish-subscription" Subsequent POST
>
> Corrected Text
> --------------
>    Upon receipt of the successful response, the subscriber d= oes a GET to
>    the provided URI to start the flow of notification messag= es.  When
>    the publisher receives this, the subscription is moved to= the active
>    state (c).
>
>    GET /restconf/subscriptions/22
>
>              Figure 5: "establ= ish-subscription" Subsequent GET
>
> Notes
> -----
> Substitute POST by GET in the figure caption
>
> 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.
>
> --------------------------------------
> RFC8650 (draft-ietf-netconf-restconf-notif-15)
> --------------------------------------
> Title              : Dynamic Subscr= iption to YANG Events and Datastores
> over
> RESTCONF
> Publication Date    : November 2019
> Author(s)          : E. Voit, R. Rahman, E. N= ilsen-Nygaard, A. Clemm, A.
> Bierman
> Category            : PROPOSED STANDARD<= br> > Source              : Network Confi= guration
> Area                : Operatio= ns and Management
> Stream              : IETF
> Verifying Party    : IESG

--_000_MN2PR11MB4366D5E5806A6AE44CB4F886B5D10MN2PR11MB4366namp_-- From nobody Mon Jan 11 06:48:26 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 1251C3A0E04 for ; Mon, 11 Jan 2021 06:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fu4fdHo3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kREg9XaR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2KgI5hZG6AN for ; Mon, 11 Jan 2021 06:48:22 -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 4C44E3A105A for ; Mon, 11 Jan 2021 06:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18828; q=dns/txt; s=iport; t=1610376470; x=1611586070; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=48NHg+Hu5eNLgIf+sFsfbifweHNn6ixhBprlKAIQGRM=; b=fu4fdHo39WxpwxyNHDE4N2ywi78ycLQQ5p8+K1hxm3zPqB3xyJsR4Ku0 gItWsF9ADlpBinbOxS2MxSUQ8aZN3fYyR/9GjtrPHJz4DXM0gsu0oLFHM PKN0p5i+rLdnWh92yo0YWu0UQBYTvo4aW+ZB3Jv+2RvAqwgZagPPS08aV I=; X-IPAS-Result: =?us-ascii?q?A0D6AAAzZPxfkIoNJK1iHQEBAQEJARIBBQUBgX4FAQsBg?= =?us-ascii?q?SIwUX1bLy4KhDWDSAONeJQfhHOBQoERA1QLAQEBDQEBLQIEAQGESgIXgVoCJ?= =?us-ascii?q?TcGDgIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAYY4DIVzAQEBBCMKEwEBO?= =?us-ascii?q?A8CAQgRBAEBKAMCAgIwFAkIAgQBEgiDHgGBflcDLgEDoncCiiV2gTKDBAEBB?= =?us-ascii?q?oUYGIIQCYE4AYJ0gmxOQwGCTINyJhuBQT+BVIIhNT6EJBw0gmI0giyBaV8wl?= =?us-ascii?q?mWHMYwxjzqCBQqCd5wBgymQDo8plBKcayCENQIEAgQFAg4BAQaBbCIsgS1wF?= =?us-ascii?q?TuCaVAXAg2OIRqDV4pYdAI1AgYBCQEBAwl8i04BgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AcmQllRIQbjF9hykqZdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKk/iljKXIyd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2Yk5SG8f3IVbVpy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D=?= =?us-ascii?q?3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,338,1602547200"; d="scan'208,217";a="626156024" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jan 2021 14:47:49 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 10BElnXm028563 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jan 2021 14:47:49 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 11 Jan 2021 08:47:48 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 11 Jan 2021 08:47:48 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 11 Jan 2021 08:47:48 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LyCZymarj/saA5oSnuho5QV8LVwl8QtJ4AMmwY11xBWqKsHi5L0u5z/DsFzCw401VW4nMeLrvRnyplGotOybBuz4k52G79x6kXy4vWoL1wOuv6pU4Uxa18hZL8/mVWSiT9CDU/F3aKxkBgO1yM4aH6JImUBPHZ4ER+YlLYCzBaiEJQgTeJWtCO2YbtKBaD1eSlRWc2MoM7U3eExWk6PTo43kC3j9l9G84C2XakWJy5E0WP+8+w9EHTnWvmf/cvXhv13GHEnKPsl9S0Lakujqve0CGY9uzy106DLw8a1Z8VkLR5z+UkjYlazcrtYu9pQsbZs5pD2i/ocLQRzEqNqM+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=48NHg+Hu5eNLgIf+sFsfbifweHNn6ixhBprlKAIQGRM=; b=a3DoqF2jkqTo+1GCVxvcq2ck27oCLG3xZun1LEN4TCEvPm4rkmicbN+7bUocbAMHnhuaGIhnF1FdoDXeazIBajFuz+z8S8Gor+O20inAqpgDvAwG/sVoapTBRldO0I2rMQbaGCQ4Sad4rrq1G7fA+vshndFnUTncnIzWgWJuTnAlVZje0SK27U8wxu0o7jaGtKbxgKHvnQonAx7EqIYQBh3DG9vb2XeDTIbnRok7j6Cll8eQP9rK3z02bKvQ7Qpbgx7cUuQYgXd6v2sOYkEhMOnGEWtBCtCyfAehptBJw+q8qv4lrchS4x4zDoMfZmC3CtdjjxX44VjUU+2owqNeuA== 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=48NHg+Hu5eNLgIf+sFsfbifweHNn6ixhBprlKAIQGRM=; b=kREg9XaRhIv8Np7gFGcNjpqcPD0ZNeHJzLfTvu9+zjV6qcGTw9FCHHuJiLwRaKCSIVWdhNTty2WNSlQdHtLK6fmJc5eJ1gZUCLkRuDRI/kRzt47I/dCtD2mVTFc5NT9da8EiOF0ka5J91MAoaKSQpWXMbU4plCqQwNCPApb3X0A= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4600.namprd11.prod.outlook.com (2603:10b6:208:26e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Mon, 11 Jan 2021 14:47:47 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3c82:1fa3:2b18:3afb]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3c82:1fa3:2b18:3afb%6]) with mapi id 15.20.3742.012; Mon, 11 Jan 2021 14:47:47 +0000 From: "Rob Wilton (rwilton)" To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netconf@ietf.org" Thread-Topic: Clarification on NETCONF edit-config default-operation replace Thread-Index: AQHV8up3fXrFXOpHlkeLycpqDm3qRahAQ71ggeQjbAA= Date: Mon, 11 Jan 2021 14:47:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a7c5b6ab-4bd7-4bf6-6dc8-08d8b63fdce3 x-ms-traffictypediagnostic: MN2PR11MB4600: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MR4ATxLaI8FaNiLA9LOAjJItDIHDkFVx/Aai+x5FJz0EEYyPXH4bLWEQHoADqq6lRYvke/NnzOPREpjohtf2r+Ox8HUgHhfv+mCst2mG2XxkB2JQeZADl0ry4O1/dnN6HELLPViJ/jCF4B8xGPT6bj8YJg94FlRtWvkMETaS5h/S7yajFiDjwdKWqFkb2XDlvkKSt9rxCPH/T4PDujP96b8Arj1kJi9xvhjOrHRuxSbtBUAZ7/nsckaJrT2A8LXNfpM5zfwb0nuvzvq1uJ3VeonIYjvb+pncYXFGHy7CCGs1Nad4LidLr0swur2SFSsMRT+eDecehoRmZMTKZ2FgMj8R7FMzlL+OnRzVqY2cKpPkEn2Xb3q3Rws5cTZ+TIYcrGGEs6hwN0Lv8r7tFOfMhQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(136003)(376002)(346002)(366004)(478600001)(9686003)(55016002)(5660300002)(33656002)(8676002)(186003)(7696005)(76116006)(110136005)(26005)(66556008)(66446008)(52536014)(71200400001)(53546011)(64756008)(6506007)(296002)(316002)(66476007)(86362001)(8936002)(83380400001)(66946007)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?SnpQRU9qLzRqaG4zWTd2RkRFZWpuUnVoQUlRc1hjOE41c3JUSWZMclhMU2xE?= =?utf-8?B?MVhlSUpXSVYydlprT0p1YlN4YS8ySkJ4Yno5VGtHMmR0Y1hPV1hVVFV1czdx?= =?utf-8?B?MEovdXpnMVZXbzE0M3ZSMDBJYWIwT3RIK3NvWGxyTk1HdzRhaG5LMjVoQk1I?= =?utf-8?B?Y0JGektqZExyR2plTmVEaVBzVG1GUnV4b3pTeDk1NTU2NXNQaDJoM3IxTVlP?= =?utf-8?B?ektIaEJwZXp2RjdSbzhNZFZGNVJhVWpnZXZhUi9yM2x5c2tZNTl4eU1wbWJN?= =?utf-8?B?R1hWbVc0NzFtdVB2THoxRjlBRFVDTm9Pc0VnYWhHaUhLUjB2bW9nQWVoWFRs?= =?utf-8?B?N0ZJdVdJazNGWUpCWE5aSkVIVFdRS29oR3hXS05zQVZrVUVGbEJEQVNPdXBo?= =?utf-8?B?K0R5RlBvdXR1a1FDZkdaN284NTVtK1hpM2U4eGN0Qno1UDNZZzZCV3lGS3dy?= =?utf-8?B?THFDTEdKUVUrejBod1o2K0p4UHJQVy9JbHNqQkxjMVV3UmtQck9mRk52RW1y?= =?utf-8?B?TklmZ2ZaZGlycmlpKzQyWEJzOUtUSy80RkJmMHJIZDBwVXhjYmhxby81SG40?= =?utf-8?B?TFJqdG0zd1RFeGJOT2RRSzJ1QnJLT0RqaDBCWVc3VzVhVTFIWTJCTmZOdlQx?= =?utf-8?B?YlBLQ3U4bVYwTnU2eFZjYkFIYndoSUlUREdQM2toZ0hObFIzQjlBWk4xWTJm?= =?utf-8?B?ZzM3aUUrOVcyZXltZHY4c1E3d0dLWjlNU3Aza3FhbDhGRUN4WEx0eXBtNVMv?= =?utf-8?B?SG5uZVVDbVFKZy9ybEZEcW9zaGxyRDdJTFJ6c0tKMUFCNkk4SHNnYXhsRnZK?= =?utf-8?B?T1pEQ3I0QVlhaktzUmYwNXRFK1RjbHRPbFU2M3JPK056TzJOZW8vNHZ6M043?= =?utf-8?B?a3BpMTRUM3dpSW9JNHAwcThlSnhPM3B2RHNmYm5PMVFjOC9pbnRvZksvV0ZZ?= =?utf-8?B?cXVldWNPVGtoL2hVL3pzNS9PdmwraXphZ0dybEJjbmV1dkxrbWR6V25nWTBK?= =?utf-8?B?eUNManJNUWEveHp2aENSYnczTVdYUmVTSEJOWkczY3RvSFpZQVA2endYQXFO?= =?utf-8?B?d29QbTU0aDU3UXBrS21xQTlIUE1pR0NYZ09QeXpMZ2M3TFAxZ01xdUZHZUVy?= =?utf-8?B?aldvTGlRNENhVXdoY2ZBRndiN3BYNTcrRmpaeGU1RXdtY3NJR1R4UGplcnBI?= =?utf-8?B?MTZ2Si9kazdpdVFYVE05MG9HNEtidWZIWUVKSXlqYUZjU2wzNXdRY1ZFdy9n?= =?utf-8?B?THpWdFJsMFptUXhQdjlLeFovZFZRR2NVUFRyR1FXdHNOR1ErUERablc3SmVr?= =?utf-8?Q?BIgZHEI/MDLhI=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366168CEFD579AF9DF2BF91B5AB0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7c5b6ab-4bd7-4bf6-6dc8-08d8b63fdce3 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2021 14:47:47.6293 (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: U4EkhTkwH0P8yJCQKt4qTBPqa++KYIG6Qxc8IvjTA8F44vdKboxGd5AJgYVfA4LHqEZVISIeIMYA960eMiHzRQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4600 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [netconf] Clarification on NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 11 Jan 2021 14:48:25 -0000 --_000_MN2PR11MB4366168CEFD579AF9DF2BF91B5AB0MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnksIGRpZ2dpbmcgdXAgYW4gb2xkIHRocmVhZCBoZXJlLg0KDQpJIGFncmVlIHdpdGggdGhl IG91dGNvbWUgb2YgdGhlIHJlZmVyZW5jZWQgdGhyZWFkLCBidXQgSSB3b25kZXIgd2hldGhlciBp dCB3b3VsZG7igJl0IGJlIGhlbHBmdWwgdG8gaGF2ZSBhbiBlcnJhdGEgdG8gY2xhcmlmeSB0aGUg TkVUQ09ORiBSRkMsIGF0IGxlYXN0IHNvIHRoYXQgd2UgZml4IHRoaXMgdGV4dCBpbiBmdXR1cmU/ DQoNCk9uZSBvZiBteSBjb2xsZWFndWVzIHJlYWQgdGhlIE5FVENPTkYgUkZDIGFuZCB0b29rIOKA nGRlZmF1bHQtb3BlcmF0aW9uIHJlcGxhY2XigJ0gdG8gYmUgZXF1aXZhbGVudCB0byBhIGNvcHkt Y29uZmlnIG9wZXJhdGlvbi4gIEkgYWxzbyBub3RlIHRoYXQgc29tZSBvZiB0aGUgcmVmZXJlbmNl cyBvbiB0aGUgd2ViIHNlZW0gdG8gdGhlIGRlc2NyaWJlIHRoZSB3cm9uZyBiZWhhdmlvdXIuDQoN ClNwZWNpZmljYWxseSwgSSB3b25kZXIgd2hldGhlciB3ZSBzaG91bGQgY2hhbmdlOg0KDQoNCiAg ICAgICAgIHJlcGxhY2U6ICBUaGUgY29uZmlndXJhdGlvbiBkYXRhIGluIHRoZSA8Y29uZmlnPiBw YXJhbWV0ZXINCg0KICAgICAgICAgICAgY29tcGxldGVseSByZXBsYWNlcyB0aGUgY29uZmlndXJh dGlvbiBpbiB0aGUgdGFyZ2V0DQoNCiAgICAgICAgICAgIGRhdGFzdG9yZS4gIFRoaXMgaXMgdXNl ZnVsIGZvciBsb2FkaW5nIHByZXZpb3VzbHkgc2F2ZWQNCg0KICAgICAgICAgICAgY29uZmlndXJh dGlvbiBkYXRhLg0KDQp0bzoNCg0KDQogICAgICAgICByZXBsYWNlOiAgVGhlIGNvbmZpZ3VyYXRp b24gZGF0YSBpbiB0aGUgPGNvbmZpZz4gcGFyYW1ldGVyDQoNCiAgICAgICAgICAgIHJlcGxhY2Vz IHRoZSByZWxhdGVkIGNvbmZpZ3VyYXRpb24gaW4gdGhlIHRhcmdldA0KDQogICAgICAgICAgICBk YXRhc3RvcmUuDQoNClJlZ2FyZHMsDQpSb2INCg0KDQpGcm9tOiBuZXRjb25mIDxuZXRjb25mLWJv dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBTdGVybmUsIEphc29uIChOb2tpYSAtIENBL090 dGF3YSkNClNlbnQ6IDA5IE1hcmNoIDIwMjAgMTM6MjANClRvOiBJdm9yeSwgV2lsbGlhbSA8d2ls bGlhbS5pdm9yeUBpbnRsLmF0dC5jb20+OyBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W25ldGNvbmZdIENsYXJpZmljYXRpb24gb24gTkVUQ09ORiBlZGl0LWNvbmZpZyBkZWZhdWx0LW9w ZXJhdGlvbiByZXBsYWNlDQoNCkhlbGxvIFdpbGxpYW0sDQoNClRoZXJlIHdhcyBhIGRpc2N1c3Np b24gYWJvdXQgdGhpcyBvbiB0aGUgbGlzdCBhIGZldyB5ZWFycyBhZ28uICBTZWUgdGhlIHRocmVh ZCB3aXRoIHN1YmplY3Q6DQoNCkNsYXJpZmljYXRpb24gcmVxdWVzdCBmb3IgTkVUQ09ORiBlZGl0 LWNvbmZpZyBkZWZhdWx0LW9wZXJhdGlvbiByZXBsYWNlDQoNCkFuIGVkaXQtY29uZmlnIGNhbid0 IGJlIHVzZWQgYXMgYSByZXBsYWNlbWVudCBmb3IgYSBmdWxsICJyZXBsYWNlIGF0IHJvb3QiIG9m IHRoZSBlbnRpcmUgY29uZmlnIGxpa2UgYSBjb3B5LWNvbmZpZy4NCg0KSmFzb24NCg0KRnJvbTog bmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgSXZvcnksIFdpbGxpYW0NClNlbnQ6IFRodXJzZGF5LCBN YXJjaCA1LCAyMDIwIDc6MzUgQU0NClRvOiBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25m QGlldGYub3JnPg0KU3ViamVjdDogW25ldGNvbmZdIENsYXJpZmljYXRpb24gb24gTkVUQ09ORiBl ZGl0LWNvbmZpZyBkZWZhdWx0LW9wZXJhdGlvbiByZXBsYWNlDQoNCkhpLA0KDQpJJ2QgYXBwcmVj aWF0ZSBjbGFyaWZpY2F0aW9uIG9uIHRoZSBmb2xsb3dpbmcgTkVUQ09ORiBvcGVyYXRpb25zIHJl bGF0aW5nIHRvIGNvcHktY29uZmlnIGFuZCBlZGl0LWNvbmZpZzoNCg0KTXkgdW5kZXJzdGFuZGlu ZyBpcyBhcyBmb2xsb3dzOg0KDQotIDxjb3B5LWNvbmZpZz4gY29tcGxldGVseSByZXBsYWNlcyBh bnkgZXhpc3RpbmcgY29uZmlndXJhdGlvbg0KDQotIDxlZGl0LWNvbmZpZz4gd2l0aCBvcGVyYXRp b246cmVwbGFjZSBhdHRyaWJ1dGUgd2lsbCByZXBsYWNlIGFueSBleGlzdGluZyBjb25maWd1cmF0 aW9uIHdpdGggbmV3IGNvbmZpZ3VyYXRpb24gZm9yIG5vZGVzIHNwZWNpZmllZCBpbnNpZGUgdGhl IDxjb25maWc+IG9wZXJhdGlvbi4gVGhlIGF0dHJpYnV0ZSBtYXkgYmUgYXQgYW55IGxldmVsIGlu IHRoZSByZXF1ZXN0LCBhbmQgYXBwbGllcyBvbmx5IHRvIHRoZSBub2RlIHNwZWNpZmllZCBhbmQg bm9kZXMgdW5kZXIgdGhhdCBub2RlLg0KDQpXaGVyZSBJJ20gbm90IGNsZWFyIGlzIHRoZSA8ZWRp dC1jb25maWc+IG9wZXJhdGlvbiB3aXRoIHRoZSBkZWZhdWx0LW9wZXJhdGlvbiBwYXJhbWV0ZXIg c2V0IHRvIHJlcGxhY2UuIFJGQyA2MjQxIHNlY3Rpb24gNy4yIHN0YXRlczoNCg0KDQogICAgICAg ICByZXBsYWNlOiAgVGhlIGNvbmZpZ3VyYXRpb24gZGF0YSBpbiB0aGUgPGNvbmZpZz4gcGFyYW1l dGVyDQoNCiAgICAgICAgICAgIGNvbXBsZXRlbHkgcmVwbGFjZXMgdGhlIGNvbmZpZ3VyYXRpb24g aW4gdGhlIHRhcmdldA0KDQogICAgICAgICAgICBkYXRhc3RvcmUuICBUaGlzIGlzIHVzZWZ1bCBm b3IgbG9hZGluZyBwcmV2aW91c2x5IHNhdmVkDQoNCiAgICAgICAgICAgIGNvbmZpZ3VyYXRpb24g ZGF0YS4NCg0KDQpEb2VzIHRoaXMgbWVhbiB0aGF0IHRoaXMgaXMgdGhlIGVxdWl2YWxlbnQgb2Yg dGhlIDxjb3B5LWNvbmZpZz4gb3BlcmF0aW9uLCBpZSBBTEwgZXhpc3RpbmcgY29uZmlndXJhdGlv biBzaG91bGQgYmUgcmVtb3ZlZCwgZXZlbiBpZiB0aGVyZSBpcyBubyBleHBsaWNpdCByZXBsYWNl bWVudCBpbiB0aGUgbmV3IDxjb25maWc+IHNlY3Rpb24/DQoNClRoYW5rcywNCg0KV2lsbGlhbQ0K DQoNCg== --_000_MN2PR11MB4366168CEFD579AF9DF2BF91B5AB0MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1H QiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWst d29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Tb3JyeSwgZGlnZ2luZyB1 cCBhbiBvbGQgdGhyZWFkIGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgYWdyZWUgd2l0aCB0aGUgb3V0Y29tZSBvZiB0 aGUgcmVmZXJlbmNlZCB0aHJlYWQsIGJ1dCBJIHdvbmRlciB3aGV0aGVyIGl0IHdvdWxkbuKAmXQg YmUgaGVscGZ1bCB0byBoYXZlIGFuIGVycmF0YSB0byBjbGFyaWZ5IHRoZSBORVRDT05GIFJGQywg YXQgbGVhc3Qgc28gdGhhdCB3ZSBmaXggdGhpcyB0ZXh0IGluIGZ1dHVyZT88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+T25lIG9m IG15IGNvbGxlYWd1ZXMgcmVhZCB0aGUgTkVUQ09ORiBSRkMgYW5kIHRvb2sg4oCcZGVmYXVsdC1v cGVyYXRpb24gcmVwbGFjZeKAnSB0byBiZSBlcXVpdmFsZW50IHRvIGEgY29weS1jb25maWcgb3Bl cmF0aW9uLiZuYnNwOyBJIGFsc28gbm90ZSB0aGF0IHNvbWUgb2YgdGhlIHJlZmVyZW5jZXMgb24g dGhlIHdlYiBzZWVtIHRvIHRoZSBkZXNjcmliZQ0KIHRoZSB3cm9uZyBiZWhhdmlvdXIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PlNwZWNpZmljYWxseSwgSSB3b25kZXIgd2hldGhlciB3ZSBzaG91bGQgY2hhbmdlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHJlcGxhY2U6Jm5ic3A7IFRoZSBjb25maWd1cmF0aW9uIGRhdGEgaW4gdGhlICZs dDtjb25maWcmZ3Q7IHBhcmFtZXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1DQSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbXBsZXRlbHkgcmVwbGFjZXMgdGhlIGNvbmZpZ3Vy YXRpb24gaW4gdGhlIHRhcmdldDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1DQSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRhdGFzdG9yZS4mbmJzcDsgVGhpcyBpcyB1c2VmdWwgZm9y IGxvYWRpbmcgcHJldmlvdXNseSBzYXZlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYXRpb24gZGF0YS48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj50 bzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyByZXBsYWNlOiZuYnNwOyBUaGUgY29uZmlndXJhdGlvbiBkYXRh IGluIHRoZSAmbHQ7Y29uZmlnJmd0OyBwYXJhbWV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXBsYWNlcyB0aGUgcmVsYXRlZCBj b25maWd1cmF0aW9uIGluIHRoZSB0YXJnZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkYXRhc3RvcmUuPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8 YnI+DQpSb2I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gbmV0Y29uZiAmbHQ7bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+ T24gQmVoYWxmIE9mIDwvYj5TdGVybmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSk8YnI+DQo8 Yj5TZW50OjwvYj4gMDkgTWFyY2ggMjAyMCAxMzoyMDxicj4NCjxiPlRvOjwvYj4gSXZvcnksIFdp bGxpYW0gJmx0O3dpbGxpYW0uaXZvcnlAaW50bC5hdHQuY29tJmd0OzsgbmV0Y29uZkBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldGNvbmZdIENsYXJpZmljYXRpb24gb24gTkVU Q09ORiBlZGl0LWNvbmZpZyBkZWZhdWx0LW9wZXJhdGlvbiByZXBsYWNlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGVsbG8gV2lsbGlhbSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5UaGVyZSB3YXMgYSBkaXNjdXNzaW9uIGFib3V0IHRoaXMgb24g dGhlIGxpc3QgYSBmZXcgeWVhcnMgYWdvLiZuYnNwOyBTZWUgdGhlIHRocmVhZCB3aXRoIHN1Ympl Y3Q6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2xhcmlmaWNhdGlvbiByZXF1ZXN0 IGZvciBORVRDT05GIGVkaXQtY29uZmlnIGRlZmF1bHQtb3BlcmF0aW9uIHJlcGxhY2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BbiBlZGl0LWNvbmZpZyBjYW4ndCBiZSB1c2VkIGFz IGEgcmVwbGFjZW1lbnQgZm9yIGEgZnVsbCAmcXVvdDtyZXBsYWNlIGF0IHJvb3QmcXVvdDsgb2Yg dGhlIGVudGlyZSBjb25maWcgbGlrZSBhIGNvcHktY29uZmlnLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkphc29uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4g bmV0Y29uZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+bmV0 Y29uZi1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+SXZvcnks IFdpbGxpYW08YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDUsIDIwMjAgNzozNSBB TTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNv bmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtuZXRjb25mXSBDbGFyaWZpY2F0 aW9uIG9uIE5FVENPTkYgZWRpdC1jb25maWcgZGVmYXVsdC1vcGVyYXRpb24gcmVwbGFjZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkknZCBhcHByZWNpYXRlIGNsYXJpZmlj YXRpb24gb24gdGhlIGZvbGxvd2luZyBORVRDT05GIG9wZXJhdGlvbnMgcmVsYXRpbmcgdG8gY29w eS1jb25maWcgYW5kIGVkaXQtY29uZmlnOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSI+TXkgdW5kZXJzdGFuZGluZyBpcyBhcyBmb2xsb3dzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+LSAmbHQ7Y29weS1jb25m aWcmZ3Q7IGNvbXBsZXRlbHkgcmVwbGFjZXMgYW55IGV4aXN0aW5nIGNvbmZpZ3VyYXRpb248bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPi0gJmx0O2VkaXQt Y29uZmlnJmd0OyB3aXRoIG9wZXJhdGlvbjpyZXBsYWNlIGF0dHJpYnV0ZSB3aWxsIHJlcGxhY2Ug YW55IGV4aXN0aW5nIGNvbmZpZ3VyYXRpb24gd2l0aCBuZXcgY29uZmlndXJhdGlvbiBmb3Igbm9k ZXMgc3BlY2lmaWVkIGluc2lkZSB0aGUgJmx0O2NvbmZpZyZndDsgb3BlcmF0aW9uLiBUaGUgYXR0 cmlidXRlIG1heSBiZSBhdCBhbnkgbGV2ZWwgaW4gdGhlIHJlcXVlc3QsIGFuZA0KIGFwcGxpZXMg b25seSB0byB0aGUgbm9kZSBzcGVjaWZpZWQgYW5kIG5vZGVzIHVuZGVyIHRoYXQgbm9kZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPldoZXJlIEknbSBu b3QgY2xlYXIgaXMgdGhlICZsdDtlZGl0LWNvbmZpZyZndDsgb3BlcmF0aW9uIHdpdGggdGhlIGRl ZmF1bHQtb3BlcmF0aW9uIHBhcmFtZXRlciBzZXQgdG8gcmVwbGFjZS4gUkZDIDYyNDEgc2VjdGlv biA3LjIgc3RhdGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVwbGFjZTombmJzcDsgVGhl IGNvbmZpZ3VyYXRpb24gZGF0YSBpbiB0aGUgJmx0O2NvbmZpZyZndDsgcGFyYW1ldGVyPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29t cGxldGVseSByZXBsYWNlcyB0aGUgY29uZmlndXJhdGlvbiBpbiB0aGUgdGFyZ2V0PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGF0YXN0 b3JlLiZuYnNwOyBUaGlzIGlzIHVzZWZ1bCBmb3IgbG9hZGluZyBwcmV2aW91c2x5IHNhdmVkPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Y29uZmlndXJhdGlvbiBkYXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkRvZXMgdGhpcyBtZWFuIHRoYXQgdGhp cyBpcyB0aGUgZXF1aXZhbGVudCBvZiB0aGUgJmx0O2NvcHktY29uZmlnJmd0OyBvcGVyYXRpb24s IGllIEFMTCBleGlzdGluZyBjb25maWd1cmF0aW9uIHNob3VsZCBiZSByZW1vdmVkLCBldmVuIGlm IHRoZXJlIGlzIG5vIGV4cGxpY2l0IHJlcGxhY2VtZW50IGluIHRoZSBuZXcgJmx0O2NvbmZpZyZn dDsgc2VjdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiPldpbGxpYW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR11MB4366168CEFD579AF9DF2BF91B5AB0MN2PR11MB4366namp_-- From nobody Mon Jan 11 07:18:34 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 280393A0EC6 for ; Mon, 11 Jan 2021 07:18:33 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nn1pl-vPIsVl for ; Mon, 11 Jan 2021 07:18:31 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2499B3A0EC0 for ; Mon, 11 Jan 2021 07:18:25 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id f17so3977133ljg.12 for ; Mon, 11 Jan 2021 07:18:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YL0tqkyUIuGCdwLmNcJ4WiRMbCC0unXcnxgoHxu93DY=; b=oTjt6ZCbMP7fZHwBIcnqLM+jUJWkSCrNPN4mLsSEBhtq2+tC+4p0XP4VN67997uZ52 EV2TI5Tt9dIISkkjDcjrfvJjBJYrsJGtOfxQxoy/imZr/A0pboJvEPF+WXhbH5LVjXRJ bm57+GtwfuGCeTNw6+6yfsXMFDyLVEc32j/8tfI/MkeFmrlRx3BsgBHMj/9vUUQo3rs9 zSZ/IluFcRRblDgHKoWFyZekmBGmYQA8WUUBK+qZi2anMUd0ihjysIlBICaFFzwpfKGa UcAgpWIP3Ox0xXBnTOosvPRqn9lczG6ToFs5VPJRteXar33dxbdTocWABwewf85Xa2tQ bS/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YL0tqkyUIuGCdwLmNcJ4WiRMbCC0unXcnxgoHxu93DY=; b=nAJIK9WYNyUIvY2K8rH4XQ+hkXngbwltErgD2M9R9tQ64y1huTZD8lN1+KndcPgcJf yn7bWcJAlsYAB1Ge8LeodnFgyY5lMT+wuSk7cQUb8JidcXFkUMBKPUQFPehtQDm0wRYA T/+hJ+RDXl1M+eU3Hsa+qZ2qe9oiHzjr70wEhjRC+zkRFSwN8P8+uBY8q06A7AImqzeB oXAj4ZDuo65CgIc1TTz/FUc61VJmpdb1B/EKN2JkuOUEKQBHgunIEMLXXNnPMEDA+2C3 ZNJ31ww59Wmf2wgi9jX9ynY/5eDpnYGAbn1QIeAUXu/EbAw9JiAHva/51eH1iUAr2ejQ hfLA== X-Gm-Message-State: AOAM531Ku57CXzKwoUa2sRQ3DprJ68wrCLQJ2Cr52r79UgowY2j/SEd1 SOjFR5ZBzXcB/stH2tuO/ok7uYVmmnfUubLk611XBQ== X-Google-Smtp-Source: ABdhPJyo37Dn6GR+bl+yO8f5BeKC5ysWO3gpxi0locH3m90TPPskSbe+P3BIHbVgwBKS39yT51lQEFYrIXVMutY1gsU= X-Received: by 2002:a2e:98cc:: with SMTP id s12mr8003353ljj.325.1610378303887; Mon, 11 Jan 2021 07:18:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Mon, 11 Jan 2021 07:18:13 -0800 Message-ID: To: "Rob Wilton (rwilton)" Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c1efca05b8a16a2f" Archived-At: Subject: Re: [netconf] Clarification on NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 11 Jan 2021 15:18:33 -0000 --000000000000c1efca05b8a16a2f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 11, 2021 at 6:48 AM Rob Wilton (rwilton) wrote: > Sorry, digging up an old thread here. > > > > I agree with the outcome of the referenced thread, but I wonder whether i= t > wouldn=E2=80=99t be helpful to have an errata to clarify the NETCONF RFC,= at least > so that we fix this text in future? > > > > One of my colleagues read the NETCONF RFC and took =E2=80=9Cdefault-opera= tion > replace=E2=80=9D to be equivalent to a copy-config operation. I also not= e that > some of the references on the web seem to the describe the wrong behaviou= r. > > > > Specifically, I wonder whether we should change: > > > > replace: The configuration data in the parameter > > completely replaces the configuration in the target > > datastore. This is useful for loading previously saved > > configuration data. > > > > to: > > > > replace: The configuration data in the parameter > > replaces the related configuration in the target > > datastore. > > > No this should not be changed. It has been in use for about a decade. You propose to remove the only way to replace the entire config and make a huge NBC-change to provide a redundant mechanism instead. Regards, > Rob > Andy > > > > > *From:* netconf *On Behalf Of *Sterne, Jason > (Nokia - CA/Ottawa) > *Sent:* 09 March 2020 13:20 > *To:* Ivory, William ; netconf@ietf.org > *Subject:* Re: [netconf] Clarification on NETCONF edit-config > default-operation replace > > > > Hello William, > > > > There was a discussion about this on the list a few years ago. See the > thread with subject: > > > > Clarification request for NETCONF edit-config default-operation replace > > > > An edit-config can't be used as a replacement for a full "replace at root= " > of the entire config like a copy-config. > > > > Jason > > > > *From:* netconf *On Behalf Of *Ivory, William > *Sent:* Thursday, March 5, 2020 7:35 AM > *To:* netconf@ietf.org > *Subject:* [netconf] Clarification on NETCONF edit-config > default-operation replace > > > > Hi, > > > > I'd appreciate clarification on the following NETCONF operations relating > to copy-config and edit-config: > > > > My understanding is as follows: > > > > - completely replaces any existing configuration > > > > - with operation:replace attribute will replace any existin= g > configuration with new configuration for nodes specified inside the > operation. The attribute may be at any level in the request, and > applies only to the node specified and nodes under that node. > > > > Where I'm not clear is the operation with the > default-operation parameter set to replace. RFC 6241 section 7.2 states: > > > > replace: The configuration data in the parameter > > completely replaces the configuration in the target > > datastore. This is useful for loading previously saved > > configuration data. > > > > Does this mean that this is the equivalent of the operation= , > ie ALL existing configuration should be removed, even if there is no > explicit replacement in the new section? > > > > Thanks, > > > > William > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000c1efca05b8a16a2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 11, 2021 at 6:48 AM Rob W= ilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> wrote:

Sorry, digging up an old thread here.

=C2=A0

I agree with the outcome of the referenced thr= ead, but I wonder whether it wouldn=E2=80=99t be helpful to have an errata = to clarify the NETCONF RFC, at least so that we fix this text in future?=

=C2=A0

One of my colleagues read the NETCONF RFC and = took =E2=80=9Cdefault-operation replace=E2=80=9D to be equivalent to a copy= -config operation.=C2=A0 I also note that some of the references on the web= seem to the describe the wrong behaviour.

=C2=A0

Specifically, I wonder whether we should chang= e:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
replace:=C2=A0 The configuration data in the <config> parameter
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 completely replaces the configuration in the target
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 datastore.=C2=A0 This is useful for loading previously s=
aved
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 configuration data.

=C2=A0

to:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
replace:=C2=A0 The configuration data in the <config> parameter
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 replaces the related configuration in the target<=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 datastore.

=C2=A0



No this should not be changed.
<= div>It has been in use for=C2=A0 about a decade.
You propose to r= emove the only way to replace the entire config and make a huge NBC-change<= /div>
to provide a redundant mechanism instead.

Regards,
Rob


Andy
= =C2=A0

<= /p>

=C2=A0

=C2=A0

From: netconf <netconf-bounces@ietf.org> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)
Sent: 09 March 2020 13:20
To: Ivory, William <william.ivory@intl.att.com>; netconf@ietf.org
Subject: Re: [netconf] Clarification on NETCONF edit-config default-= operation replace

=C2=A0

Hello William,

=C2=A0

There was a discussion about th= is on the list a few years ago.=C2=A0 See the thread with subject:

=C2=A0

Clarification request for NETCO= NF edit-config default-operation replace

=C2=A0

An edit-config can't be use= d as a replacement for a full "replace at root" of the entire con= fig like a copy-config.

=C2=A0

Jason

=C2=A0

From: netconf <netconf-bounces@ietf.org> On Behalf Of Ivory, William
Sent: Thursday, March 5, 2020 7:35 AM
To: netconf@ie= tf.org
Subject: [netconf] Clarification on NETCONF edit-config default-oper= ation replace

=C2=A0

Hi,

=C2=A0

I'd appreciate clarificatio= n on the following NETCONF operations relating to copy-config and edit-conf= ig:

=C2=A0

My understanding is as follows:=

=C2=A0

- <copy-config> completel= y replaces any existing configuration

=C2=A0

- <edit-config> with oper= ation:replace attribute will replace any existing configuration with new co= nfiguration for nodes specified inside the <config> operation. The at= tribute may be at any level in the request, and applies only to the node specified and nodes under that node.

=C2=A0

Where I'm not clear is the = <edit-config> operation with the default-operation parameter set to r= eplace. RFC 6241 section 7.2 states:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
replace:=C2=A0 The configuration data in the <config> parameter
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 completely replaces the configuration in the target
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 datastore.=C2=A0 This is useful for loading previously s=
aved
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 configuration data.
=C2=A0

Does this mean that this is the= equivalent of the <copy-config> operation, ie ALL existing configura= tion should be removed, even if there is no explicit replacement in the new= <config> section?

=C2=A0

Thanks,

=C2=A0

William 

=C2=A0
_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000c1efca05b8a16a2f-- From nobody Mon Jan 11 07:33:54 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 46A663A0F35 for ; Mon, 11 Jan 2021 07:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Y1zrErCR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=bp0MBgar Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLTsZn6GiZ5L for ; Mon, 11 Jan 2021 07:33:49 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239113A0F2F for ; Mon, 11 Jan 2021 07:33:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29616; q=dns/txt; s=iport; t=1610379229; x=1611588829; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=asZb6tEFKm3LG8+edSnERlC0KgPXyhrFxKvj1CYLVp0=; b=Y1zrErCRGQe/61OU3W9GeNi5WM16dxv5sszKv6nneHzg9msJEC2EdEBl eHi3pxMiNIOxv+uqpFGNUOeeD2DCE7WAM/L21iaLjhnU/voFS1Ng6ad5X CzJusW5GplGu9nade8PAIDUp8b8mEjWmI0N1ev29o5LUywuPAuxLR36NU w=; X-IPAS-Result: =?us-ascii?q?A0A5AAB8bfxfkIoNJK1iGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAYF+AwEBAQsBgSIwUX1bLy4KhDWDSAONdAOZEoFCgREDVAsBAQENAQEYA?= =?us-ascii?q?QwIAgQBAYQGRAIXgVoCJTcGDgIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBA?= =?us-ascii?q?YY4DIVzAQEBBAEBIQoTAQEsCwEPAgEIEQQBASEHAwICAiULFAkIAgQOBQiDH?= =?us-ascii?q?gGBflcDLgEDC6JfAooldoEygwQBAQaFFxiCEAMGgTgBgnSCbE5DAYY+JhuBQ?= =?us-ascii?q?T+BVIIhNT6CXQEBAoFDHCsJgmI0giyBaV8BL0FGW3wjk2SHMYwxjzqCBQqCd?= =?us-ascii?q?4krklaDKZAOjymfKJFVIIQ1AgQCBAUCDgEBBoFsIiyBLXAVO4I1AQEyUBcCD?= =?us-ascii?q?Y4hGoNXhRSFRHQCNQIGAQkBAQMJfItOAYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3A+bKXvh0mSLmYBxD7smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFv6d8kVrAQoLB6OkCgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS9fjYlTNpWex9ngZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,338,1602547200"; d="scan'208,217";a="646221938" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jan 2021 15:33:48 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 10BFXl8v021927 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jan 2021 15:33:47 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 11 Jan 2021 09:33:47 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 11 Jan 2021 09:33:47 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 11 Jan 2021 09:33:47 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h+dsq8skQIdsjPcX5o80MqfblPaVAllhDfvkUil5ivfHTXG0jLL/Aoem6t8/t8OzBk+tXo8SNa70usIX5A2DdqOAN8/vhmf2UCTBjJRsduMjhM9c1zf8OTws29bpg/fEZwbTx14/CnkeutQZtz5XnAfWiDXzfhn/q5jxc7JgXUV3Exvreba3Fk3Hma6/VH6U+NqjnrpTLu6rxdGNXFvHDw1ZopRTWJr0o2DrdFY2DuTj+/LHpNBr3kbwKYl/t0ASpHAjKGOEHch9dWg9vHyVPjMNUE5fIwD8dKhJvTs0R8Ve5EiZlmM8pdyUSFv5chSdl+12ez53paUY5Umao8P1Lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=asZb6tEFKm3LG8+edSnERlC0KgPXyhrFxKvj1CYLVp0=; b=iAbgceQgHOzN2SQlpqI183BKQc/OsTdZFEkoTvwr4DSPwPUs9ZNPfNUp2N4UIsu/gevhxdwE3w0Nc8CR282QwQjXA3aDzY6e2jHBY/A9cvfxoHyJL6vGTAZ+e/eyBH1ooyu31+eCG0s1i/uKRY7TJk8SnrKHVMBa8Ynbac7vhnjmKHxj/B0vvLO8MODWGJyr9TI3vZy3yrplsDtikM+uFcMwmA8uhFfkneMi/tLa4Ey8mZDBvVlpBpcriGMMCWLh0Ygbl1DihyIW6WorqAEEe9ONNtMdl7koqkGa0RxoC4wHsEDoePKsgWsje4xlh+NYqJyD0k2k3Wd7W6LYwAyTyA== 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=asZb6tEFKm3LG8+edSnERlC0KgPXyhrFxKvj1CYLVp0=; b=bp0MBgarC3lkOkGC+qehzq7QPk5mNz0oL6iIDRFnGtl3tTX3w1M8b1Mmy9PsEkHdRIYUhj4yg8rYYdqjOXS1wbMcKEX4hUpE92X+Fciahy2dbEs/wenoimI/SmV4l3bWxKV/jPVmds539bvi6WqOd4axoIA5c/2dAvPGR5J0VDc= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4239.namprd11.prod.outlook.com (2603:10b6:208:192::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Mon, 11 Jan 2021 15:33:45 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3c82:1fa3:2b18:3afb]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3c82:1fa3:2b18:3afb%6]) with mapi id 15.20.3742.012; Mon, 11 Jan 2021 15:33:45 +0000 From: "Rob Wilton (rwilton)" To: Andy Bierman CC: "Sterne, Jason (Nokia - CA/Ottawa)" , "netconf@ietf.org" Thread-Topic: [netconf] Clarification on NETCONF edit-config default-operation replace Thread-Index: AQHV8up3fXrFXOpHlkeLycpqDm3qRahAQ71ggeQjbACAAAz2gIAAAbbA Date: Mon, 11 Jan 2021 15:33:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b9baef5f-3114-4186-62bb-08d8b64648d9 x-ms-traffictypediagnostic: MN2PR11MB4239: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8R2QoD6lbG7FLFgphRofdAl4bZAE0h/tuHfuSYqSTUvoOu2oQpMDI9wTeI2d20FfXt3gKtJfAogO+Omw2ExfbhelEw69JP0GCis2YtoikxvPfa2g73ZRcbYiazxXqhfqQ2KR5/GiAMLdvhdeWLCHGdEGsZTRLunET4Uxgoj6agckcbGGcy6d+qiG6sgKqyoXwzxfyZRumWZkViOiAUAnZuF/FrE8smGe2zYMWhWp2LldG0jv+S5gBisdwzzEd/2/vVwHppjg9peQOByJZJs6yNzJ1TEtQObLclYcwE7N/SliYLUjPiKjzoIF4g3xVW2NbG88sTCuvquNcq4LV+KZWy661aRmS0xR3DFMXPHa2qy50BV0d+18vtrDIjGnFX0MIVa1VxLuOYCGVq2GTwLm9od4jFQ3//1VE+TGge9IAp0+x3KxgOjDvaju0bY0ceO2FkIsoN/hMlHoU+aG/odzWQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(346002)(396003)(366004)(376002)(86362001)(76116006)(33656002)(5660300002)(53546011)(66556008)(66476007)(26005)(186003)(6506007)(7696005)(66446008)(166002)(2906002)(64756008)(83380400001)(478600001)(54906003)(6916009)(966005)(66946007)(9686003)(9326002)(55016002)(4326008)(8936002)(71200400001)(316002)(52536014)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Tm9uRC9IRmhwWThTMHcxUEUycGRPcEpaWnROTmR3OWxlOVl4OHlmTUZ2bm5R?= =?utf-8?B?aUl1TWNHc1l4ZmgyQlBHNXcxRHdsNjdzYTIxZThlTVpYN21QUUM4OUl5WWlE?= =?utf-8?B?NzhpU2ZUSXBnc25jYnp6MUFOMUtCR3ptMTBhVkpqbXpBVGFNbU96U2RUbkNs?= =?utf-8?B?TDFHMUlDTkZ1emV1S3dsWndxSVpQejFDeHNKYjg5YlNPK3RLOURKdkhSMTBI?= =?utf-8?B?aVVCVGJVKzl6ZGlBcmxUS0pPUWFKZXFQdHdyckhMVVdpYVVmRkZGS0RzMzBm?= =?utf-8?B?KzlQOGdyNG8rVjA4YUNpdnhRbTVtYmZmR3FFcG1XSTVaZE1laXExbnV2Tk1i?= =?utf-8?B?UkwxOG1QTTJqQUYwYmxNMmtoOEZMcGV0UGpHVmpIN3dxQUNnZ1RCeUQvSjg1?= =?utf-8?B?V2FSZWcvSlhHdnBVUjNkYXZzUnQwRWttQ2hFcng0aHUzM3E1VDEzS1RKTzQ2?= =?utf-8?B?OXB6OVVqYWlWeFkwUmNsQmxhc0NJeUFQVmxROVB1THhNU2Zta2lmc3dNQUd2?= =?utf-8?B?WHk5TGlUUVZwcEYyZlFSWHQzWTc5eE0vU3o4MlZPOXBIT1lySEhvbFR5U2pB?= =?utf-8?B?aTArSnV6RU53eWU0VjgzWXFBOWxWYVgwK096dzdUdTA5amRFMzR1alhXdmdi?= =?utf-8?B?U2NNOEduRVJaQzIxSEVZSHRmdCtDaU9RdVc3TGRqMkg1RS9wd0lCb0ZxWGRi?= =?utf-8?B?Z0hUcXVDa29JM1dOdGNjNVlkOE9OMW4vYmVQVE10bjdjczZuRVpJcTFlUkpw?= =?utf-8?B?Zk01Z3hCV1REV3FkcVZOWVJReDVDQU5kUFJzRm03WmJ6YjBSY1lBcDRwME1w?= =?utf-8?B?akZ4YnV6ci9kc3ZwWkJacUI1Sms2TmozVmZ2TGhJdXAzOEMxODM0TG1JL3Iv?= =?utf-8?B?MWFya29YMS8wdUM0N2EvSXpjVlhYYS9CemF3K1RrOFRCVk5qV0lmMmFoWG45?= =?utf-8?B?cUwrZWJIZThrZVNTVWNIcCtIRXFsakhudGFTQ3lMeldCTmJOaWJmbjBsUHZK?= =?utf-8?B?bk5lT0NsOFIyZmxJRXBmdmo5WFJxcjl2U1VzWTZ4aXZDUjhWWHlhR1JqTXhY?= =?utf-8?B?ZUhialROblpJbGVNNWdGSzg5UE5oeXo0cy9LRTNZNFQ4M3VIZkJPODJQb0FP?= =?utf-8?B?b21BSGdPUC9oVFI3cCt1NFhqOCtlMGltcDdRMmZQR2JtSHJiK0V0bmJubnMy?= =?utf-8?B?eVVsUW5WRXM5MUR4eUlSQW5aOTdLaElDbjg0NTdZZkVWbEhGazZneEJpSmhW?= =?utf-8?B?WnpaN2c2TVlrNjBTWDFBVEUyWnlMRUR4YnN2VXhGeGtLVzNjNkJacWl1U29X?= =?utf-8?Q?CPr9K9oyGoTOY=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366B35776E0E9641E7BBCD1B5AB0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9baef5f-3114-4186-62bb-08d8b64648d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2021 15:33:45.7458 (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: 7zeDkR79E08vOhsYFPRH/vesnM3HH+YAb5165TtcUuwfd4lpuPKTqxzJWt9LuvDEZqws5vWEauEwq/0yBNmfqQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4239 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [netconf] Clarification on NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 11 Jan 2021 15:33:52 -0000 --_000_MN2PR11MB4366B35776E0E9641E7BBCD1B5AB0MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KUGVyaGFwcyB3ZSBhcmUgY3Jvc3Npbmcgd2lyZXMgaGVyZS4NCg0KSeKAmW0g bm90IHRyeWluZyB0byBjaGFuZ2UgdGhlIGJlaGF2aW91ciwganVzdCB0cnlpbmcgdG8gZW5zdXJl IHRoYXQgdGhlIHNwZWMgZGVzY3JpYmVzIHRoZSBiZWhhdmlvdXIgdW5hbWJpZ3VvdXNseS4gIE15 IHByb3Bvc2VkIHRleHQgd2FzIGludGVuZGVkIHRvIGNsYXJpZnkgdGhlIGJlaGF2aW91ciB0byBi ZSBjb25zaXN0ZW50IHdpdGggSmFzb27igJlzIHN0YXRlbWVudCBiZWxvdyBhbmQgdGhlIGNvbmNs dXNpb24gb2YgdGhpcyB0aHJlYWQ6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9t c2cvbmV0Y29uZi9EVFBsa0pmNGVuS05IWGtCV240OW5wMmUtOGMvDQoNCkFyZSB5b3UgZGlzYWdy ZWVpbmcgd2l0aCBKYXNvbuKAmXMgc3RhdGVtZW50IOKAnEFuIGVkaXQtY29uZmlnIGNhbid0IGJl IHVzZWQgYXMgYSByZXBsYWNlbWVudCBmb3IgYSBmdWxsICJyZXBsYWNlIGF0IHJvb3QiIG9mIHRo ZSBlbnRpcmUgY29uZmlnIGxpa2UgYSBjb3B5LWNvbmZpZ+KAnSBvciB0aGUgcHJpb3IgY29uY2x1 c2lvbiB0byB0aGUgbGlua2VkIHRocmVhZCBhYm92ZT8NCg0KUmVnYXJkcywNClJvYg0KDQoNCkZy b206IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPg0KU2VudDogMTEgSmFudWFyeSAy MDIxIDE1OjE4DQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPg0K Q2M6IFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EvT3R0YXdhKSA8amFzb24uc3Rlcm5lQG5va2lh LmNvbT47IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gQ2xhcmlmaWNh dGlvbiBvbiBORVRDT05GIGVkaXQtY29uZmlnIGRlZmF1bHQtb3BlcmF0aW9uIHJlcGxhY2UNCg0K DQoNCk9uIE1vbiwgSmFuIDExLCAyMDIxIGF0IDY6NDggQU0gUm9iIFdpbHRvbiAocndpbHRvbikg PHJ3aWx0b249NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwY2lzY28uY29tQGRt YXJjLmlldGYub3JnPj4gd3JvdGU6DQpTb3JyeSwgZGlnZ2luZyB1cCBhbiBvbGQgdGhyZWFkIGhl cmUuDQoNCkkgYWdyZWUgd2l0aCB0aGUgb3V0Y29tZSBvZiB0aGUgcmVmZXJlbmNlZCB0aHJlYWQs IGJ1dCBJIHdvbmRlciB3aGV0aGVyIGl0IHdvdWxkbuKAmXQgYmUgaGVscGZ1bCB0byBoYXZlIGFu IGVycmF0YSB0byBjbGFyaWZ5IHRoZSBORVRDT05GIFJGQywgYXQgbGVhc3Qgc28gdGhhdCB3ZSBm aXggdGhpcyB0ZXh0IGluIGZ1dHVyZT8NCg0KT25lIG9mIG15IGNvbGxlYWd1ZXMgcmVhZCB0aGUg TkVUQ09ORiBSRkMgYW5kIHRvb2sg4oCcZGVmYXVsdC1vcGVyYXRpb24gcmVwbGFjZeKAnSB0byBi ZSBlcXVpdmFsZW50IHRvIGEgY29weS1jb25maWcgb3BlcmF0aW9uLiAgSSBhbHNvIG5vdGUgdGhh dCBzb21lIG9mIHRoZSByZWZlcmVuY2VzIG9uIHRoZSB3ZWIgc2VlbSB0byB0aGUgZGVzY3JpYmUg dGhlIHdyb25nIGJlaGF2aW91ci4NCg0KU3BlY2lmaWNhbGx5LCBJIHdvbmRlciB3aGV0aGVyIHdl IHNob3VsZCBjaGFuZ2U6DQoNCg0KICAgICAgICAgcmVwbGFjZTogIFRoZSBjb25maWd1cmF0aW9u IGRhdGEgaW4gdGhlIDxjb25maWc+IHBhcmFtZXRlcg0KDQogICAgICAgICAgICBjb21wbGV0ZWx5 IHJlcGxhY2VzIHRoZSBjb25maWd1cmF0aW9uIGluIHRoZSB0YXJnZXQNCg0KICAgICAgICAgICAg ZGF0YXN0b3JlLiAgVGhpcyBpcyB1c2VmdWwgZm9yIGxvYWRpbmcgcHJldmlvdXNseSBzYXZlZA0K DQogICAgICAgICAgICBjb25maWd1cmF0aW9uIGRhdGEuDQoNCnRvOg0KDQoNCiAgICAgICAgIHJl cGxhY2U6ICBUaGUgY29uZmlndXJhdGlvbiBkYXRhIGluIHRoZSA8Y29uZmlnPiBwYXJhbWV0ZXIN Cg0KICAgICAgICAgICAgcmVwbGFjZXMgdGhlIHJlbGF0ZWQgY29uZmlndXJhdGlvbiBpbiB0aGUg dGFyZ2V0DQoNCiAgICAgICAgICAgIGRhdGFzdG9yZS4NCg0KDQoNCk5vIHRoaXMgc2hvdWxkIG5v dCBiZSBjaGFuZ2VkLg0KSXQgaGFzIGJlZW4gaW4gdXNlIGZvciAgYWJvdXQgYSBkZWNhZGUuDQpZ b3UgcHJvcG9zZSB0byByZW1vdmUgdGhlIG9ubHkgd2F5IHRvIHJlcGxhY2UgdGhlIGVudGlyZSBj b25maWcgYW5kIG1ha2UgYSBodWdlIE5CQy1jaGFuZ2UNCnRvIHByb3ZpZGUgYSByZWR1bmRhbnQg bWVjaGFuaXNtIGluc3RlYWQuDQoNClJlZ2FyZHMsDQpSb2INCg0KQW5keQ0KDQoNCg0KRnJvbTog bmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQS9PdHRhd2Ep DQpTZW50OiAwOSBNYXJjaCAyMDIwIDEzOjIwDQpUbzogSXZvcnksIFdpbGxpYW0gPHdpbGxpYW0u aXZvcnlAaW50bC5hdHQuY29tPG1haWx0bzp3aWxsaWFtLml2b3J5QGludGwuYXR0LmNvbT4+OyBu ZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtu ZXRjb25mXSBDbGFyaWZpY2F0aW9uIG9uIE5FVENPTkYgZWRpdC1jb25maWcgZGVmYXVsdC1vcGVy YXRpb24gcmVwbGFjZQ0KDQpIZWxsbyBXaWxsaWFtLA0KDQpUaGVyZSB3YXMgYSBkaXNjdXNzaW9u IGFib3V0IHRoaXMgb24gdGhlIGxpc3QgYSBmZXcgeWVhcnMgYWdvLiAgU2VlIHRoZSB0aHJlYWQg d2l0aCBzdWJqZWN0Og0KDQpDbGFyaWZpY2F0aW9uIHJlcXVlc3QgZm9yIE5FVENPTkYgZWRpdC1j b25maWcgZGVmYXVsdC1vcGVyYXRpb24gcmVwbGFjZQ0KDQpBbiBlZGl0LWNvbmZpZyBjYW4ndCBi ZSB1c2VkIGFzIGEgcmVwbGFjZW1lbnQgZm9yIGEgZnVsbCAicmVwbGFjZSBhdCByb290IiBvZiB0 aGUgZW50aXJlIGNvbmZpZyBsaWtlIGEgY29weS1jb25maWcuDQoNCkphc29uDQoNCkZyb206IG5l dGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGll dGYub3JnPj4gT24gQmVoYWxmIE9mIEl2b3J5LCBXaWxsaWFtDQpTZW50OiBUaHVyc2RheSwgTWFy Y2ggNSwgMjAyMCA3OjM1IEFNDQpUbzogbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBp ZXRmLm9yZz4NClN1YmplY3Q6IFtuZXRjb25mXSBDbGFyaWZpY2F0aW9uIG9uIE5FVENPTkYgZWRp dC1jb25maWcgZGVmYXVsdC1vcGVyYXRpb24gcmVwbGFjZQ0KDQpIaSwNCg0KSSdkIGFwcHJlY2lh dGUgY2xhcmlmaWNhdGlvbiBvbiB0aGUgZm9sbG93aW5nIE5FVENPTkYgb3BlcmF0aW9ucyByZWxh dGluZyB0byBjb3B5LWNvbmZpZyBhbmQgZWRpdC1jb25maWc6DQoNCk15IHVuZGVyc3RhbmRpbmcg aXMgYXMgZm9sbG93czoNCg0KLSA8Y29weS1jb25maWc+IGNvbXBsZXRlbHkgcmVwbGFjZXMgYW55 IGV4aXN0aW5nIGNvbmZpZ3VyYXRpb24NCg0KLSA8ZWRpdC1jb25maWc+IHdpdGggb3BlcmF0aW9u OnJlcGxhY2UgYXR0cmlidXRlIHdpbGwgcmVwbGFjZSBhbnkgZXhpc3RpbmcgY29uZmlndXJhdGlv biB3aXRoIG5ldyBjb25maWd1cmF0aW9uIGZvciBub2RlcyBzcGVjaWZpZWQgaW5zaWRlIHRoZSA8 Y29uZmlnPiBvcGVyYXRpb24uIFRoZSBhdHRyaWJ1dGUgbWF5IGJlIGF0IGFueSBsZXZlbCBpbiB0 aGUgcmVxdWVzdCwgYW5kIGFwcGxpZXMgb25seSB0byB0aGUgbm9kZSBzcGVjaWZpZWQgYW5kIG5v ZGVzIHVuZGVyIHRoYXQgbm9kZS4NCg0KV2hlcmUgSSdtIG5vdCBjbGVhciBpcyB0aGUgPGVkaXQt Y29uZmlnPiBvcGVyYXRpb24gd2l0aCB0aGUgZGVmYXVsdC1vcGVyYXRpb24gcGFyYW1ldGVyIHNl dCB0byByZXBsYWNlLiBSRkMgNjI0MSBzZWN0aW9uIDcuMiBzdGF0ZXM6DQoNCg0KICAgICAgICAg cmVwbGFjZTogIFRoZSBjb25maWd1cmF0aW9uIGRhdGEgaW4gdGhlIDxjb25maWc+IHBhcmFtZXRl cg0KDQogICAgICAgICAgICBjb21wbGV0ZWx5IHJlcGxhY2VzIHRoZSBjb25maWd1cmF0aW9uIGlu IHRoZSB0YXJnZXQNCg0KICAgICAgICAgICAgZGF0YXN0b3JlLiAgVGhpcyBpcyB1c2VmdWwgZm9y IGxvYWRpbmcgcHJldmlvdXNseSBzYXZlZA0KDQogICAgICAgICAgICBjb25maWd1cmF0aW9uIGRh dGEuDQoNCg0KRG9lcyB0aGlzIG1lYW4gdGhhdCB0aGlzIGlzIHRoZSBlcXVpdmFsZW50IG9mIHRo ZSA8Y29weS1jb25maWc+IG9wZXJhdGlvbiwgaWUgQUxMIGV4aXN0aW5nIGNvbmZpZ3VyYXRpb24g c2hvdWxkIGJlIHJlbW92ZWQsIGV2ZW4gaWYgdGhlcmUgaXMgbm8gZXhwbGljaXQgcmVwbGFjZW1l bnQgaW4gdGhlIG5ldyA8Y29uZmlnPiBzZWN0aW9uPw0KDQpUaGFua3MsDQoNCldpbGxpYW0NCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0Y29u ZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== --_000_MN2PR11MB4366B35776E0E9641E7BBCD1B5AB0MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z b2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3Jk LXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBB bmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5QZXJoYXBzIHdlIGFyZSBjcm9zc2luZyB3aXJlcyBoZXJlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5J4oCZ bSBub3QgdHJ5aW5nIHRvIGNoYW5nZSB0aGUgYmVoYXZpb3VyLCBqdXN0IHRyeWluZyB0byBlbnN1 cmUgdGhhdCB0aGUgc3BlYyBkZXNjcmliZXMgdGhlIGJlaGF2aW91ciB1bmFtYmlndW91c2x5LiZu YnNwOyBNeSBwcm9wb3NlZCB0ZXh0IHdhcyBpbnRlbmRlZCB0byBjbGFyaWZ5IHRoZSBiZWhhdmlv dXIgdG8gYmUgY29uc2lzdGVudCB3aXRoIEphc29u4oCZcw0KIHN0YXRlbWVudCBiZWxvdyBhbmQg dGhlIGNvbmNsdXNpb24gb2YgdGhpcyB0aHJlYWQ6IDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0Y29uZi9EVFBsa0pmNGVuS05IWGtCV240OW5wMmUtOGMv Ij4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0Y29uZi9EVFBsa0pm NGVuS05IWGtCV240OW5wMmUtOGMvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BcmUgeW91IGRpc2FncmVlaW5nIHdpdGgg SmFzb27igJlzIHN0YXRlbWVudCDigJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPkFuIGVkaXQt Y29uZmlnIGNhbid0IGJlIHVzZWQgYXMgYSByZXBsYWNlbWVudCBmb3IgYSBmdWxsICZxdW90O3Jl cGxhY2UgYXQgcm9vdCZxdW90OyBvZiB0aGUgZW50aXJlIGNvbmZpZyBsaWtlIGEgY29weS1jb25m aWfigJ0gb3IgdGhlIHByaW9yDQogY29uY2x1c2lvbiB0byB0aGUgbGlua2VkIHRocmVhZCBhYm92 ZT8gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Sb2I8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQW5k eSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4g MTEgSmFudWFyeSAyMDIxIDE1OjE4PGJyPg0KPGI+VG86PC9iPiBSb2IgV2lsdG9uIChyd2lsdG9u KSAmbHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBTdGVybmUsIEphc29u IChOb2tpYSAtIENBL090dGF3YSkgJmx0O2phc29uLnN0ZXJuZUBub2tpYS5jb20mZ3Q7OyBuZXRj b25mQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0gQ2xhcmlmaWNh dGlvbiBvbiBORVRDT05GIGVkaXQtY29uZmlnIGRlZmF1bHQtb3BlcmF0aW9uIHJlcGxhY2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g TW9uLCBKYW4gMTEsIDIwMjEgYXQgNjo0OCBBTSBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7cndp bHRvbj08YSBocmVmPSJtYWlsdG86NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciPjQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U29ycnks IGRpZ2dpbmcgdXAgYW4gb2xkIHRocmVhZCBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSBhZ3JlZSB3aXRoIHRoZSBvdXRjb21lIG9mIHRoZSByZWZlcmVuY2VkIHRocmVhZCwgYnV0 IEkgd29uZGVyIHdoZXRoZXIgaXQgd291bGRu4oCZdCBiZSBoZWxwZnVsIHRvIGhhdmUgYW4gZXJy YXRhIHRvIGNsYXJpZnkgdGhlIE5FVENPTkYgUkZDLCBhdCBsZWFzdCBzbyB0aGF0IHdlIGZpeCB0 aGlzIHRleHQgaW4NCiBmdXR1cmU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbmUgb2Yg bXkgY29sbGVhZ3VlcyByZWFkIHRoZSBORVRDT05GIFJGQyBhbmQgdG9vayDigJxkZWZhdWx0LW9w ZXJhdGlvbiByZXBsYWNl4oCdIHRvIGJlIGVxdWl2YWxlbnQgdG8gYSBjb3B5LWNvbmZpZyBvcGVy YXRpb24uJm5ic3A7IEkgYWxzbyBub3RlIHRoYXQgc29tZSBvZiB0aGUgcmVmZXJlbmNlcyBvbiB0 aGUgd2ViIHNlZW0NCiB0byB0aGUgZGVzY3JpYmUgdGhlIHdyb25nIGJlaGF2aW91ci48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlNwZWNpZmljYWxseSwgSSB3b25kZXIgd2hldGhlciB3ZSBz aG91bGQgY2hhbmdlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXBsYWNlOiZuYnNwOyBUaGUgY29u ZmlndXJhdGlvbiBkYXRhIGluIHRoZSAmbHQ7Y29uZmlnJmd0OyBwYXJhbWV0ZXI8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb21wbGV0 ZWx5IHJlcGxhY2VzIHRoZSBjb25maWd1cmF0aW9uIGluIHRoZSB0YXJnZXQ8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkYXRhc3RvcmUu Jm5ic3A7IFRoaXMgaXMgdXNlZnVsIGZvciBsb2FkaW5nIHByZXZpb3VzbHkgc2F2ZWQ8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25m aWd1cmF0aW9uIGRhdGEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50bzo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVwbGFjZTombmJzcDsgVGhlIGNvbmZpZ3VyYXRpb24gZGF0 YSBpbiB0aGUgJmx0O2NvbmZpZyZndDsgcGFyYW1ldGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVwbGFjZXMgdGhlIHJlbGF0ZWQg Y29uZmlndXJhdGlvbiBpbiB0aGUgdGFyZ2V0PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGF0YXN0b3JlLjwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk5vIHRoaXMgc2hvdWxkIG5vdCBiZSBjaGFuZ2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaGFzIGJlZW4gaW4gdXNlIGZvciZuYnNw OyBhYm91dCBhIGRlY2FkZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPllvdSBwcm9wb3NlIHRvIHJlbW92ZSB0aGUgb25seSB3YXkgdG8gcmVwbGFj ZSB0aGUgZW50aXJlIGNvbmZpZyBhbmQgbWFrZSBhIGh1Z2UgTkJDLWNoYW5nZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG8gcHJvdmlkZSBhIHJl ZHVuZGFudCBtZWNoYW5pc20gaW5zdGVhZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPGJy Pg0KUm9iPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBuZXRjb25mICZsdDs8YSBocmVmPSJtYWls dG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+U3Rlcm5lLCBKYXNvbiAo Tm9raWEgLSBDQS9PdHRhd2EpPGJyPg0KPGI+U2VudDo8L2I+IDA5IE1hcmNoIDIwMjAgMTM6MjA8 YnI+DQo8Yj5Ubzo8L2I+IEl2b3J5LCBXaWxsaWFtICZsdDs8YSBocmVmPSJtYWlsdG86d2lsbGlh bS5pdm9yeUBpbnRsLmF0dC5jb20iIHRhcmdldD0iX2JsYW5rIj53aWxsaWFtLml2b3J5QGludGwu YXR0LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5uZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W25ldGNvbmZdIENsYXJpZmljYXRpb24gb24gTkVUQ09ORiBlZGl0LWNvbmZpZyBkZWZhdWx0LW9w ZXJhdGlvbiByZXBsYWNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIj5IZWxsbyBXaWxsaWFtLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tQ0EiPlRoZXJlIHdhcyBhIGRpc2N1c3Npb24gYWJvdXQgdGhpcyBvbiB0aGUgbGlzdCBh IGZldyB5ZWFycyBhZ28uJm5ic3A7IFNlZSB0aGUgdGhyZWFkIHdpdGggc3ViamVjdDo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNB Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUNBIj5DbGFyaWZpY2F0aW9uIHJlcXVlc3QgZm9yIE5FVENPTkYgZWRpdC1j b25maWcgZGVmYXVsdC1vcGVyYXRpb24gcmVwbGFjZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiPkFu IGVkaXQtY29uZmlnIGNhbid0IGJlIHVzZWQgYXMgYSByZXBsYWNlbWVudCBmb3IgYSBmdWxsICZx dW90O3JlcGxhY2UgYXQgcm9vdCZxdW90OyBvZiB0aGUgZW50aXJlIGNvbmZpZyBsaWtlIGEgY29w eS1jb25maWcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+SmFzb248L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IG5ldGNvbmYgJmx0 OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5uZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5J dm9yeSwgV2lsbGlhbTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggNSwgMjAyMCA3 OjM1IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFtuZXRjb25mXSBDbGFyaWZpY2F0aW9uIG9uIE5FVENPTkYgZWRpdC1jb25maWcgZGVmYXVsdC1v cGVyYXRpb24gcmVwbGFjZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1DQSI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1DQSI+SSdkIGFwcHJlY2lhdGUgY2xhcmlmaWNhdGlvbiBvbiB0aGUgZm9sbG93aW5nIE5FVENP TkYgb3BlcmF0aW9ucyByZWxhdGluZyB0byBjb3B5LWNvbmZpZyBhbmQgZWRpdC1jb25maWc6PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+TXkgdW5k ZXJzdGFuZGluZyBpcyBhcyBmb2xsb3dzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tQ0EiPi0gJmx0O2NvcHktY29uZmlnJmd0OyBjb21wbGV0ZWx5IHJl cGxhY2VzIGFueSBleGlzdGluZyBjb25maWd1cmF0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+LSAmbHQ7ZWRpdC1jb25maWcmZ3Q7IHdpdGgg b3BlcmF0aW9uOnJlcGxhY2UgYXR0cmlidXRlIHdpbGwgcmVwbGFjZSBhbnkgZXhpc3RpbmcgY29u ZmlndXJhdGlvbiB3aXRoIG5ldyBjb25maWd1cmF0aW9uIGZvciBub2RlcyBzcGVjaWZpZWQgaW5z aWRlIHRoZSAmbHQ7Y29uZmlnJmd0OyBvcGVyYXRpb24uDQogVGhlIGF0dHJpYnV0ZSBtYXkgYmUg YXQgYW55IGxldmVsIGluIHRoZSByZXF1ZXN0LCBhbmQgYXBwbGllcyBvbmx5IHRvIHRoZSBub2Rl IHNwZWNpZmllZCBhbmQgbm9kZXMgdW5kZXIgdGhhdCBub2RlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t Q0EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiPldoZXJlIEknbSBub3QgY2xlYXIgaXMg dGhlICZsdDtlZGl0LWNvbmZpZyZndDsgb3BlcmF0aW9uIHdpdGggdGhlIGRlZmF1bHQtb3BlcmF0 aW9uIHBhcmFtZXRlciBzZXQgdG8gcmVwbGFjZS4gUkZDIDYyNDEgc2VjdGlvbiA3LjIgc3RhdGVz Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXBsYWNlOiZuYnNwOyBUaGUgY29uZmlndXJh dGlvbiBkYXRhIGluIHRoZSAmbHQ7Y29uZmlnJmd0OyBwYXJhbWV0ZXI8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb21wbGV0ZWx5IHJl cGxhY2VzIHRoZSBjb25maWd1cmF0aW9uIGluIHRoZSB0YXJnZXQ8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkYXRhc3RvcmUuJm5ic3A7 IFRoaXMgaXMgdXNlZnVsIGZvciBsb2FkaW5nIHByZXZpb3VzbHkgc2F2ZWQ8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25maWd1cmF0 aW9uIGRhdGEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUNB Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIj5Eb2VzIHRoaXMgbWVhbiB0aGF0IHRoaXMgaXMgdGhl IGVxdWl2YWxlbnQgb2YgdGhlICZsdDtjb3B5LWNvbmZpZyZndDsgb3BlcmF0aW9uLCBpZSBBTEwg ZXhpc3RpbmcgY29uZmlndXJhdGlvbiBzaG91bGQgYmUgcmVtb3ZlZCwgZXZlbiBpZiB0aGVyZSBp cyBubyBleHBsaWNpdCByZXBsYWNlbWVudA0KIGluIHRoZSBuZXcgJmx0O2NvbmZpZyZndDsgc2Vj dGlvbj88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNB Ij5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1DQSI+V2lsbGlhbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZT48c3BhbiBs YW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRjb25mIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_MN2PR11MB4366B35776E0E9641E7BBCD1B5AB0MN2PR11MB4366namp_-- From nobody Mon Jan 11 07:53:18 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 A81B83A0FC7 for ; Mon, 11 Jan 2021 07:53:16 -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.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75yk_EIMzfLM for ; Mon, 11 Jan 2021 07:53:14 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 4EF093A0FC4 for ; Mon, 11 Jan 2021 07:53:14 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id w26so3959742ljo.4 for ; Mon, 11 Jan 2021 07:53:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pdv/otlbYDOnCl784ne8bM7W4hBBsEKDEL32hwoatyI=; b=Kre9KBt/WG90HtKTftVRh+YcaCKHSwmChw8KYjgLXzD0ySxUmvAJCgECbi3R91trtX zdjrcbfXosh/BamlfCFpSFMkJZnLUgIO0zVHrYGuHA2a1BjXiREPKsTkx7N4aQj2lTUq Qya01pKiE6CBTS/LqJidyfWcyiPbuXlP/H4yDjLfGc1+J/pbn2BTOJIV3AjW5Jo9Vrlm bkMFx19MN40I3qztNpqfOHXhxw1mKxkjpcy33ShU2jbzsWQ3M5UkqD3GmXqDalSbt9/d fVcYHBiVnlW/i71dzuKbUdP4jqTvAwX3vPllQYo+ldTJah4EC7LU3SlV/aeg9csQpKWK XUwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pdv/otlbYDOnCl784ne8bM7W4hBBsEKDEL32hwoatyI=; b=AN20TyIjGfeLdSlI+lb1vPHt9q3dKo+jSwJqukMQfTA/o/+NUzG9XZYoMqWsw03YFW 21boTJCRUTxLp6wZumUrfRBRF4Y8QFsVmYOa3ApQIxVYJz86bf7ajT/I9KHWUY2eP0Qb Nn0WSKfHRQiWK+20R25KSjR5gKBSXmsWLjAsYxMLlZ0QQSXrm2GRsul0dYjyTzCCwe3q As6KC879sQreR70SNseW/xapbeVwzCNRF2m0uvdki08XRMUNF/Q5/oTYlMlF9eKh7QU/ UiND4zdNAjiHcq9hVFlDTY/HWywyNkrgC5S8pMnh6Z5/n12jytWh5dx/n9fPhC5EQI8B y2LA== X-Gm-Message-State: AOAM532vLZSL61JJ7XeTanqsMqYZz8YFEtFgix0J9kbUsotel6sAuBBu aBINAJHL6kIVybMFzZQTHnJchS1RK9JJ4I0hg1JHyQ== X-Google-Smtp-Source: ABdhPJxxmzF9LZyfIGZidhf9w2LJ11jWcksgxl/jjvYNmiciHSvF3p/t8wJU2oTzXdmNSC7sPiGuE+q9li4C8zalNeY= X-Received: by 2002:a2e:9a84:: with SMTP id p4mr68130lji.160.1610380392463; Mon, 11 Jan 2021 07:53:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Mon, 11 Jan 2021 07:53:01 -0800 Message-ID: To: "Rob Wilton (rwilton)" Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003f10db05b8a1e74b" Archived-At: Subject: Re: [netconf] Clarification on NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 11 Jan 2021 15:53:17 -0000 --0000000000003f10db05b8a1e74b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 11, 2021 at 7:33 AM Rob Wilton (rwilton) wrote: > Hi Andy, > > > > Perhaps we are crossing wires here. > > > > I=E2=80=99m not trying to change the behaviour, just trying to ensure tha= t the > spec describes the behaviour unambiguously. My proposed text was intende= d > to clarify the behaviour to be consistent with Jason=E2=80=99s statement = below and > the conclusion of this thread: > https://mailarchive.ietf.org/arch/msg/netconf/DTPlkJf4enKNHXkBWn49np2e-8c= / > > > > Are you disagreeing with Jason=E2=80=99s statement =E2=80=9CAn edit-confi= g can't be used > as a replacement for a full "replace at root" of the entire config like a > copy-config=E2=80=9D or the prior conclusion to the linked thread above? > > > No. I guess the wording in both cases is not correct. There is a description of the operation attribute in sec 7.2 (not very good, but normative). The default-operation text should just say that "merge" or "replace" is the assigned value of the operation when the attribute is not present in the representation of the data node. The value "none" indicates that no operation is assigned if the attribute is not present. > Regards, > > Rob > Andy > > > > > *From:* Andy Bierman > *Sent:* 11 January 2021 15:18 > *To:* Rob Wilton (rwilton) > *Cc:* Sterne, Jason (Nokia - CA/Ottawa) ; > netconf@ietf.org > *Subject:* Re: [netconf] Clarification on NETCONF edit-config > default-operation replace > > > > > > > > On Mon, Jan 11, 2021 at 6:48 AM Rob Wilton (rwilton) 40cisco.com@dmarc.ietf.org> wrote: > > Sorry, digging up an old thread here. > > > > I agree with the outcome of the referenced thread, but I wonder whether i= t > wouldn=E2=80=99t be helpful to have an errata to clarify the NETCONF RFC,= at least > so that we fix this text in future? > > > > One of my colleagues read the NETCONF RFC and took =E2=80=9Cdefault-opera= tion > replace=E2=80=9D to be equivalent to a copy-config operation. I also not= e that > some of the references on the web seem to the describe the wrong behaviou= r. > > > > Specifically, I wonder whether we should change: > > > > replace: The configuration data in the parameter > > completely replaces the configuration in the target > > datastore. This is useful for loading previously saved > > configuration data. > > > > to: > > > > replace: The configuration data in the parameter > > replaces the related configuration in the target > > datastore. > > > > > > > > No this should not be changed. > > It has been in use for about a decade. > > You propose to remove the only way to replace the entire config and make = a > huge NBC-change > > to provide a redundant mechanism instead. > > > > Regards, > Rob > > > > Andy > > > > > > > > *From:* netconf *On Behalf Of *Sterne, Jason > (Nokia - CA/Ottawa) > *Sent:* 09 March 2020 13:20 > *To:* Ivory, William ; netconf@ietf.org > *Subject:* Re: [netconf] Clarification on NETCONF edit-config > default-operation replace > > > > Hello William, > > > > There was a discussion about this on the list a few years ago. See the > thread with subject: > > > > Clarification request for NETCONF edit-config default-operation replace > > > > An edit-config can't be used as a replacement for a full "replace at root= " > of the entire config like a copy-config. > > > > Jason > > > > *From:* netconf *On Behalf Of *Ivory, William > *Sent:* Thursday, March 5, 2020 7:35 AM > *To:* netconf@ietf.org > *Subject:* [netconf] Clarification on NETCONF edit-config > default-operation replace > > > > Hi, > > > > I'd appreciate clarification on the following NETCONF operations relating > to copy-config and edit-config: > > > > My understanding is as follows: > > > > - completely replaces any existing configuration > > > > - with operation:replace attribute will replace any existin= g > configuration with new configuration for nodes specified inside the > operation. The attribute may be at any level in the request, and > applies only to the node specified and nodes under that node. > > > > Where I'm not clear is the operation with the > default-operation parameter set to replace. RFC 6241 section 7.2 states: > > > > replace: The configuration data in the parameter > > completely replaces the configuration in the target > > datastore. This is useful for loading previously saved > > configuration data. > > > > Does this mean that this is the equivalent of the operation= , > ie ALL existing configuration should be removed, even if there is no > explicit replacement in the new section? > > > > Thanks, > > > > William > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --0000000000003f10db05b8a1e74b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 11, 2021 at 7:33 AM Rob W= ilton (rwilton) <rwilton@cisco.com<= /a>> wrote:




Regards,

Rob

=

=C2=A0

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: 11 January 2021 15:18
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; netconf@ietf.org
Subject: Re: [netconf] Clarification on NETCONF edit-config default-= operation replace

=C2=A0

=C2=A0

=C2=A0

On Mon, Jan 11, 2021 at 6:48 AM Rob Wilton (rwilton)= <rwilton=3D40cisco.com@dmarc.ietf.org> wrote:

Sorry, digging up an old thread here.<= /p>

=C2=A0

I agree with the outcome of the referenced thread, b= ut I wonder whether it wouldn=E2=80=99t be helpful to have an errata to cla= rify the NETCONF RFC, at least so that we fix this text in future?

=C2=A0

One of my colleagues read the NETCONF RFC and took = =E2=80=9Cdefault-operation replace=E2=80=9D to be equivalent to a copy-conf= ig operation.=C2=A0 I also note that some of the references on the web seem to the describe the wrong behaviour.

=C2=A0

Specifically, I wonder whether we should change:<= /u>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
replace:=C2=A0 The configuration data in the <config> parameter
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 completely replaces the configuration in the target
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 datastore.=C2=A0 This is useful for loading previously s=
aved
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 configuration data.

=C2=A0

to:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
replace:=C2=A0 The configuration data in the <config> parameter
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 replaces the related configuration in the target<=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 datastore.

=C2=A0

=C2=A0

=C2=A0

No this should not be changed.

It has been in use for=C2=A0 about a decade.<= u>

You propose to remove the only way to replace the en= tire config and make a huge NBC-change

to provide a redundant mechanism instead.<= /u>

=C2=A0

Regards,
Rob

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

From: netconf <netconf-bounces@ietf.org> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)
Sent: 09 March 2020 13:20
To: Ivory, William <william.ivory@intl.att.com>; netconf@ietf.org<= br> Subject: Re: [netconf] Clarification on NETCONF edit-config default-= operation replace

=C2=A0

Hello William,=

=C2=A0

There was a discussion about th= is on the list a few years ago.=C2=A0 See the thread with subject:

=C2=A0

Clarification request for NETCO= NF edit-config default-operation replace

=C2=A0

An edit-config can't be use= d as a replacement for a full "replace at root" of the entire con= fig like a copy-config.

=C2=A0

Jason

=C2=A0

From: netconf <netconf-bounces@ietf.org> On Behalf Of Ivory, William
Sent: Thursday, March 5, 2020 7:35 AM
To: netconf@ie= tf.org
Subject: [netconf] Clarification on NETCONF edit-config default-oper= ation replace

=C2=A0

Hi,

=C2=A0

I'd appreciate clarificatio= n on the following NETCONF operations relating to copy-config and edit-conf= ig:

=C2=A0

My understanding is as follows:=

=C2=A0

- <copy-config> completel= y replaces any existing configuration

=C2=A0

- <edit-config> with oper= ation:replace attribute will replace any existing configuration with new co= nfiguration for nodes specified inside the <config> operation. The attribute may be at any level in the request, and applies only to the = node specified and nodes under that node.

=C2=A0

Where I'm not clear is the = <edit-config> operation with the default-operation parameter set to r= eplace. RFC 6241 section 7.2 states:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
replace:=C2=A0 The configuration data in the <config> parameter
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 completely replaces the configuration in the target
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 datastore.=C2=A0 This is useful for loading previously s=
aved
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 configuration data.
=C2=A0

Does this mean that this is the= equivalent of the <copy-config> operation, ie ALL existing configura= tion should be removed, even if there is no explicit replacement in the new <config> section?

=C2=A0

Thanks,

=C2=A0

William 

=C2=A0

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

--0000000000003f10db05b8a1e74b-- From nobody Mon Jan 11 09:43:38 2021 Return-Path: <01000176f28bbe25-64dc8d99-c769-4ff9-8b40-772c4ad11b0b-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 C52DA3A1125 for ; Mon, 11 Jan 2021 09:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Yir9S-A79cS for ; Mon, 11 Jan 2021 09:43:34 -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 777953A1124 for ; Mon, 11 Jan 2021 09:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1610387013; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=8L1CEeuVVvteCDZFmRcBYkq3txsDYJ5GSo8czHHvQow=; b=N2ESrfGa9R7aYTHJUAA7ZWnYdI21CpYxJjkcEThWtWL5UmUHQXSzxokGvR4Z0R7i Ic62VgyJetQ5mmtgntc6i+jY9b60MHbzcTK/eSoyGTIkqhOoPp1nw/C3jX1sRIHN8Ze dL+qMVHWcBe8Z7/ANrTKQ/joFSr60yj8K6y/JSTk= From: Kent Watsen Message-ID: <01000176f28bbe25-64dc8d99-c769-4ff9-8b40-772c4ad11b0b-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3624BB97-AA42-4FC3-97D7-690EEDBDBEC7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 11 Jan 2021 17:43:33 +0000 In-Reply-To: Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" To: Andy Bierman References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.01.11-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Clarification on NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 11 Jan 2021 17:43:36 -0000 --Apple-Mail=_3624BB97-AA42-4FC3-97D7-690EEDBDBEC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 11, 2021, at 10:53 AM, Andy Bierman wrote: >=20 > I guess the wording in both cases is not correct. > There is a description of the operation attribute in sec 7.2 (not very = good, but normative). > The default-operation text should just say that "merge" or "replace" = is the assigned value of > the operation when the attribute is not present in the representation = of the data node. > The value "none" indicates that no operation is assigned if the = attribute is not present. Agreed. It seems odd that the "default-operation=E2=80=9D section provides = (redundant) behavioral descriptions, rather than pointing to the = descriptions provided in the =E2=80=9Coperation=E2=80=9D section above. Nit: replace "no operation=E2=80=9D with "no default operation" in = Andy=E2=80=99s last sentence. K. --Apple-Mail=_3624BB97-AA42-4FC3-97D7-690EEDBDBEC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 11, 2021, at 10:53 AM, Andy Bierman <andy@yumaworks.com> = wrote:

I = guess the wording in both cases is not correct.
There = is a description of the operation attribute in sec 7.2 (not very good, = but normative).
The default-operation text should = just say that "merge" or "replace" is the assigned value of
the = operation when the attribute is not present in the representation of the = data node.
The value "none" indicates that no operation is = assigned if the attribute is not present.

Agreed.

It = seems odd that the "default-operation=E2=80=9D section provides = (redundant) behavioral descriptions, rather than pointing to the = descriptions provided in the =E2=80=9Coperation=E2=80=9D section = above.

Nit: replace "no operation=E2=80=9D with "no default = operation" in Andy=E2=80=99s last sentence.

K.

= --Apple-Mail=_3624BB97-AA42-4FC3-97D7-690EEDBDBEC7-- From nobody Mon Jan 11 10:17:26 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 A6DF53A1119 for ; Mon, 11 Jan 2021 10:17:24 -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.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhoxbikGCVUF for ; Mon, 11 Jan 2021 10:17:23 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 A49AA3A111A for ; Mon, 11 Jan 2021 10:17:22 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id x23so223380lji.7 for ; Mon, 11 Jan 2021 10:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RX3eZvvZFHbxg0n9vE/oJlv/Rvv/yXBzDMKLBnxOpXA=; b=SCJkzLulr/J5ZI9WwPAbPiKMpf6YXq2QE6dz04Kvihh0xmBwnrDTNH3Vzm0vtC0Tau OCfCjK0Ex4wTvE8NV6U5/hUTakKGhJRkEhxvfCBJfFsxnYRoxHmC+1+ygZayl9Le9eqm pYOWcXqYq/LP301fEil+jizvfFilUrNdTcGrfZJP0YWXuPrBh/zNzgqVOhfFInbQZi+U HgFmjduhn4kkVgx9NEpv38Hv9LTUJu2unxtOkJUgUenQRTRaezPCs51aXJxv3ds1Mn7O ofgdlS52UELdlHVhF0a89e7C+Fr48Jenz7lTJrKotD0ZAbVFhwCGRNm7iPdqIcCuJP0c GIdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RX3eZvvZFHbxg0n9vE/oJlv/Rvv/yXBzDMKLBnxOpXA=; b=Ji8aBBAevPV3LUoxIrM+jNHQG6COkyQbVDXHKgQPxu38hp++e878OmNs5ZXkBJtGtH b3Nuz5/eZ0AMGw3AjfxhHoFwEE28rsd31s8wsILqOAlt5TNebvot7P0aeI5P8ZYsqxmx puqbJHpOw0UICfJb48X732RByNeRsP5WV9BfwqZqyHDBRxnQ89Gcv3NISleOF3ZancZ6 AhfceQ/SDF6k/GksLg0hxbIQNhNj2nbf/U0zgqSyRITw27utaHgyoG42qwOivfWraTvq Yh5X9IY2zsa3ZbI9nVKEfvKtbGJzxaDdq8hBxrjG1kF6tWyVpHf3RpE35ehSoVjQaLsn 8pQg== X-Gm-Message-State: AOAM533jQxq3THdATzH4wwk4gan9rjoLIS2wJQKP+sWJy1FIV7oTLptZ OyftAgNrPTXfL22QTqzCx24Iz4eXAMHQmB4LRcrkLw== X-Google-Smtp-Source: ABdhPJwoQw9Vl47TLxBrgmBEi/xtusretgfnfHYdSVwzHTc3V6ruwlW1PAhqOlHojuJ5oQFyotujR6vzN4+H9FKWle4= X-Received: by 2002:a05:651c:1342:: with SMTP id j2mr324143ljb.91.1610389040330; Mon, 11 Jan 2021 10:17:20 -0800 (PST) MIME-Version: 1.0 References: <01000176f28bbe25-64dc8d99-c769-4ff9-8b40-772c4ad11b0b-000000@email.amazonses.com> In-Reply-To: <01000176f28bbe25-64dc8d99-c769-4ff9-8b40-772c4ad11b0b-000000@email.amazonses.com> From: Andy Bierman Date: Mon, 11 Jan 2021 10:17:09 -0800 Message-ID: To: Kent Watsen Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b3111e05b8a3ea2d" Archived-At: Subject: Re: [netconf] Clarification on NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 11 Jan 2021 18:17:25 -0000 --000000000000b3111e05b8a3ea2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 11, 2021 at 9:43 AM Kent Watsen wrote: > > > On Jan 11, 2021, at 10:53 AM, Andy Bierman wrote: > > I guess the wording in both cases is not correct. > There is a description of the operation attribute in sec 7.2 (not very > good, but normative). > The default-operation text should just say that "merge" or "replace" is > the assigned value of > the operation when the attribute is not present in the representation of > the data node. > The value "none" indicates that no operation is assigned if the attribute > is not present. > > > Agreed. > > It seems odd that the "default-operation=E2=80=9D section provides (redun= dant) > behavioral descriptions, rather than pointing to the descriptions provide= d > in the =E2=80=9Coperation=E2=80=9D section above. > > Nit: replace "no operation=E2=80=9D with "no default operation" in Andy= =E2=80=99s last > sentence. > No -- default-operation=3D"none" means there is no operation on that node. If so, it must exist already (or be an NP-container). The algorithm is really: Start: effective-operation =3D none Setting effective-operation for a node in the config (hierarchically) (1) explicit: if operation attribute is present, then use that (2) parent: if parent node has an effective-operation set, then use that (3) default: if default-operation=3Dmerge or replace, use that (4) else effective-operation =3D none The RFC is silent about multiple (possibly conflicting) operations within the same subtree. > K. > > Andy --000000000000b3111e05b8a3ea2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 11, 2021 at 9:43 AM Kent = Watsen <kent@watsen.net> wrote= :


On = Jan 11, 2021, at 10:53 AM, Andy Bierman <andy@yumaworks.com> wrote:

I guess the wording in both cases is not correct.
<= div style=3D"font-family:Helvetica;font-size:14px;font-style:normal;font-va= riant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start= ;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;te= xt-decoration:none">There is a description of the operation attribute in se= c 7.2 (not very good, but normative).
The default= -operation text should just say that "merge" or "replace&quo= t; is the assigned value of
the operation when th= e attribute is not present in the representation of the data node.
The value "none" indicates that no operation is= assigned if the attribute is not present.

Agreed.

It seems odd that the "default= -operation=E2=80=9D section provides (redundant) behavioral descriptions, r= ather than pointing to the descriptions provided in the =E2=80=9Coperation= =E2=80=9D section above.

Nit:=C2=A0replace "no operation=E2=80=9D with "no default oper= ation" in Andy=E2=80=99s last sentence.
=
No -- default-operation=3D"none" means there is no= operation on that node.
If so, it must exist already (or be an N= P-container).

The algorithm is really:
<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Start: effective-operation =3D no= ne
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Setting effective-operation for a = node in the config (hierarchically)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (= 1) explicit: if operation attribute is present, then use that
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 (2) parent: if parent node has an effective-operat= ion=C2=A0set, then use that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (3) defau= lt: if default-operation=3Dmerge or replace, use that
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 (4) else effective-operation =3D none

The RFC is silent about multiple (possibly conflicting) operations wi= thin the same subtree.


K.


Andy
=C2=A0
--000000000000b3111e05b8a3ea2d-- From nobody Mon Jan 11 15:00:52 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 1A9B73A14FD; Mon, 11 Jan 2021 15:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWJyPSxopRNQ; Mon, 11 Jan 2021 15:00:48 -0800 (PST) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 244C63A14FC; Mon, 11 Jan 2021 15:00:48 -0800 (PST) Received: by mail-pj1-x102c.google.com with SMTP id v1so433583pjr.2; Mon, 11 Jan 2021 15:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=hC/4xpRFV2WmE36U9scsa73enis958b/02ly7CvEf4o=; b=dpo0KhVsVsRp9UnhNg+4CqZsnmM6YRp734vLz5y1U94oqcBuhhTWJ8B7pPy297sYxU FaaCrpJI7tXqF+DrPjbAj1JLlTD0+knZgc92dv3VDECIRABDNkXIoVLUEZvFpjUEO7DM EdIElamxA/tjbtWwLywvuXMT8+SDQfVQ+3DT/FF/rw4tx7yAN8RXRHZngMN19Aiytdkd YOOaT4wJ+ryDcsSms4DUpMabaYyfEONAQHN2SUlPNzcU8XCrFpR8wVHivdSHl9szRbmL 36ItfMJJjO9mWPF5l1+nkUIIfDTXZlRUff4WVr/r6pM0S3Flpb/G4Q2Awfztn5d+Qt+o asgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=hC/4xpRFV2WmE36U9scsa73enis958b/02ly7CvEf4o=; b=pHvlNIXiO7VDEc67aIkxGUUcY77pLzFnH+kPuGPcs7d4XFIi72dnZa98hMVG0MOo6+ HbJP92gLCJtGvoM8QXOUW61O83gx2zw2+H49npdmvcl5fFUqryHOw3nYNMDkRHbOmMrW ZE83m3FJ9tE2LH8jCotc0QvvBAP0kmIqOYNvCKo+J/pY1GyWLyo9I40YqoXe+CUIton/ oIzcIxYrm0jmbsoJJ6+9jBDJiZawTrl6BdglqIZj2iAWpbOslcOD0/9w+uMf5PXCpr1A KIuzI+XLJ1Lc5GywLrRTr8Q3VM3haiKh80sHR6DwDnD0sXeidgbfPMHkhoeZ+vgQa047 0+iA== X-Gm-Message-State: AOAM531gg/KjNrxAuHaKr/V/L5uEQc7BIK8Cq2bC6gr574wPiC4C0hX7 K7JaZLQNjHRzysVd6L/DPSPfNnCp97DutA== X-Google-Smtp-Source: ABdhPJwugZsZjK7Kn5b/YlS6eExW59QmwaARzoslW/2owS296t7WyKqTFxk5EtXd7DtoPOERnFVZ7w== X-Received: by 2002:a17:90b:4014:: with SMTP id ie20mr1149632pjb.95.1610406047362; Mon, 11 Jan 2021 15:00:47 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:e175:6fe0:4eec:fb3f? ([2601:647:5600:5020:e175:6fe0:4eec:fb3f]) by smtp.gmail.com with ESMTPSA id q206sm704062pfc.161.2021.01.11.15.00.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jan 2021 15:00:46 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_7F5D51E9-3B47-4626-8596-8D46F8520DA0" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Mon, 11 Jan 2021 15:00:45 -0800 Cc: netconf-chairs To: Netconf X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [netconf] WGLC on SZTP CSR draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 23:00:50 -0000 --Apple-Mail=_7F5D51E9-3B47-4626-8596-8D46F8520DA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We are starting a 2 week WGLC for draft-ietf-netconf-sztp-csr which is = at version -01. https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ Please respond on this thread indicating your support or concerns about = why this document should/should not be adopted. We are particularly interested in statement of the form: - I have reviewed the draft and found no issues.=20 - I have reviewed the draft and found the following issues =E2=80=A6 This WGLC will conclude on Monday, January 25. An IPR call has already = been issued separately. Thank you. Mahesh & Kent (as co-chairs) --Apple-Mail=_7F5D51E9-3B47-4626-8596-8D46F8520DA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We = are starting a 2 week WGLC for draft-ietf-netconf-sztp-csr which is at = version -01.

https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/

Please = respond on this thread indicating your support or concerns about why = this document should/should not be adopted.

We are particularly interested in = statement of the form:

- I have reviewed the draft and found no = issues. 
- I have reviewed the draft and found = the following issues =E2=80=A6

This WGLC will conclude on Monday, = January 25. An IPR call has already been issued separately.

Thank you.

Mahesh & Kent (as = co-chairs)






= --Apple-Mail=_7F5D51E9-3B47-4626-8596-8D46F8520DA0-- From nobody Tue Jan 12 04:13: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 8D6DC3A11DB; Tue, 12 Jan 2021 04:13:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder_via_Datatracker?= To: Cc: draft-ietf-netconf-crypto-types.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161045360252.14510.16755799701987783827@ietfa.amsl.com> Reply-To: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= Date: Tue, 12 Jan 2021 04:13:22 -0800 Archived-At: Subject: [netconf] Yangdoctors last call review of draft-ietf-netconf-crypto-types-18 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, 12 Jan 2021 12:13:23 -0000 Reviewer: Jürgen Schönwälder Review result: Ready with Issues The crypto modules aim at providing a flexible reusable infrastructure of groupings for modeling cryptographic keys and related concepts. The flexibility of the definitions provided of course comes with a certain amount of complexity. >From a YANG perspective, draft-ietf-netconf-crypto-types-18.txt is in a good and close to publish state (a couple of minor issues left). I also tried to understand what is being modeled here and hence I also have some questions concerning the concepts modeled and I hope these are easy to answer/resolve as well. - I have compiled the YANG modules using yanglint 0.16.105. - s/ietf-crypt-types/ietf-crypto-types/ - Does it make sense to have a new notation like | The diagram above uses syntax that is similar to but not | defined in [RFC8340]. or shall this simply become regular text? - "Identities use to specify uncommon formats are enabled [...]" is this correct or should it be "used to specify"? - Second bullet 2.1.4.1: Perhaps change [...] specified by the "format" identity Section 2.1.2 associated [...] to [...] specified by the "format" identity (see Section 2.1.2) associated [...] What is 'encoded in the format specified by the "format" identity' I assume this refers to the key value that is encrypted and stored in encrypted-value, no? - Same bullet in 2.1.4.1: The "encrypted-value" node is the key, encrypted by the key referenced by the "encrypted-by" node, encoded in the format specified by the "format" identity Section 2.1.2 associated with the ancestor node using this grouping. Do I understand correctly that the encrypted-value always holds an encrypted key? If so, a better name for the leaf would perhaps have been encrypted-key and for the grouping encrypted-key-grouping. I assume you did not pick this name since you wanted to use encrypted-key for other purposes? This makes sense and may have led to encrypted-key-value-grouping, in the sense of an encrypted 'key-value'? For the definition of the grouping, does it actually matter that the value encrypted is a key? Or would it make sense to rename the grouping to encrypted-value-grouping and then the second bullet becomes: The "encrypted-value" node holds the value, encrypted by the key referenced by the "encrypted-by" node, encoded in the format specified by the "format" identity (see Section 2.1.2) associated with the ancestor node using this grouping. Looking at the definition of encrypted-key-value-grouping, it seems that the name encrypted-value-grouping would actually be more appropriate, there is nothing in the definition that says that the value must be a key for something. And is it "the" ancestor node or "an" ancestor node? Perhaps the possible confusion here is that ancestor node may mean different things, schema tree versus data tree. What about this? The "encrypted-value" node holds the value, encrypted by the key referenced by the "encrypted-by" node, encoded in the format specified by the "format" identity (see Section 2.1.2) associated with the ancestor data node of the data node using this grouping. Hm. Did I reverse engineer this correctly? - In 2.1.4.2 last item, where do I see that the encrypted-password node is encoded using the CMS EnvelopedData structure? There is no "format" identity here, so this is hard coded to always have the CMS EnvelopedData structure (or is it CMS EncryptedData structure, see below)? OK, if I lookup the definition, it seems to use a hardcoded format. - Always use cleartext instead plain-text? I understand that some people make a distinction between plain text, plaintext, and cleartext. Does this document do that? I do not think so, and if so, we may reduce confusion by picking just one term. On the other hand, if there is a distinction made, then the document should perhaps be explicit about it somewhere and define how these terms are used. - The example in section 2.2 is helpful and much appreciated. - s/confugration/configuration/ - The encrypted-password description says that it uses a" CMS EnvelopedData structure, per Section 8 in RFC 5652, encoded using ASN.1 distinguished encoding rules (DER)". However, section 8 of RFC 5652 defined EncryptedData and not EnvelopedData. So what is the intention here? - Following up on the previous point, it seems that the EncryptedData format does not introduce a salt, i.e., if the same password is used multiple times and they are all protected by the same key, then this is visible since the encrypted formats will all be the same as well. Is this something to be concerned about? Well, this is not really a yang-doctor question... - The encrypted-one-symmetric-key-format again refers to the EnvelopedData per Section 8 in RFC 5652 but section 8 only defines EncryptedData. So either the type name is wrong or the reference is wrong. - The encrypted-password container description refers to the EnvelopedData and either the reference to section 8 is wrong or it should be EncryptedData (see above). Is it OK to have a fixed encrypted password format? Perhaps it is, I am just checking. (The password leaf in RFC 7317 uses the ianach:crypt-hash format, i.e., it is somewhat extensible but then this module may target different use cases as it deals with encrypted passwords instead of hashed passwords.) - I wonder why this is a SHOULD and not a MUST: "Identifies the symmetric key's format. Implementations SHOULD ensure that the incoming symmetric key value is encoded in the specified format."; This statement shows up several times when the key-format identities are used. I wonder what this means to an implementer. If I receive a key format (say one-symmetric-key-format) and a corresponding blob of data, do I have to decode this to see whether the format works out? If later the key-format is changed to something else (lets say octet-string-key-format), do I reject such a change or is it OK as long as the binary data I have would be a valid value given the new format? Perhaps this is implementation specific? Well, since we deal with keys, ... - The definitions of the features symmetric-key-encryption and private-key-encryption have copy and paste text from the definition of the feature password-encryption. I think they need to be changed to: feature symmetric-key-encryption { description "Indicates that the server supports encryption of symmetric keys."; } feature private-key-encryption { description "Indicates that the server supports encryption of private keys."; } - If I have a 'octet-string-key-format' key and I use it to create an encrypted key. How do I know which crypto algorithm is used? I have not digged into it, but do the various CMS structures provide this information somewhere? In the case of asymmetric keys, the format gives a hint whether I am dealing with RSA keys or EC keys. For symmetric keys, I am not sure in call cases how the algorithm is determined. - The asymmetric-key-pair-with-certs-grouping descriptions talk about 'IDevID' and 'LDevID' and 'TPM-protected asymmetric keys'. This seems to call for additional references to explain what these are. - s/is was unclear/it was unclear/ - RFC 8407 suggests that the XML registry Registrant Contact is: Registrant Contact: The IESG. This does not seem to be handled in a consistent manner if I look at recent RFCs but I think the idea was to give the responsibility to the IESG, assuming the IESG is a more stable entity than WGs. From nobody Tue Jan 12 10:41:25 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 851163A11BD; Tue, 12 Jan 2021 10:41:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder_via_Datatracker?= To: Cc: draft-ietf-netconf-trust-anchors.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161047687248.13931.17900123352005904827@ietfa.amsl.com> Reply-To: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= Date: Tue, 12 Jan 2021 10:41:12 -0800 Archived-At: Subject: [netconf] Yangdoctors last call review of draft-ietf-netconf-trust-anchors-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 18:41:19 -0000 Reviewer: Jürgen Schönwälder Review result: Ready with Issues The crypto modules aim at providing a flexible reusable infrastructure of groupings for modeling cryptographic keys and related concepts. The flexibility of the definitions provided of course comes with a certain amount of complexity. >From a YANG perspective, draft-ietf-netconf-trust-anchors-13.txt is in a good and close to publish state (a couple of minor issues left). I also tried to understand what is being modeled here and hence I also have some questions concerning the concepts modeled and I hope these are easy to answer/resolve as well. - I have compiled the YANG modules using yanglint 0.16.105. - The prefix 'ts' is rather short, the set of two letter prefixes is rather small limited. This comment also applies to the other documents, crypto-types uses 'ct. Perhaps this is not a problem since collisions can be handled but if we go for rather short prefixes, we will have to exercise the collision resolution. (I see that 'ct' has already been used by ietf-complex-types, RFC 6095.) A possible alternative could be to use sec-ct, sec-ts, sec-ks, ...). RFC 8407 provides the following guidelines (Section 4.2): Prefix values SHOULD be short but are also likely to be unique. Prefix values SHOULD NOT conflict with known modules that have been previously published. Well, having short and terse prefixes is actually nice and enhancing programmer readability. - s/is defines a truststore/defines a truststore/ - s/to be grouped references/to be grouped and referenced/ - In 2.2.1, I was not sure what CA certificates are and what EE certificates are. I then tried to guess EE = end entity cert, but this does not explain CA since the term used in crypto types is trust anchor cert. The description in the XML clarified that my guess was kind of correct. Perhaps explain upfront what these acronyms mean? Or perhaps the acronyms can be avoided by simply spelling things out? They do not appear to be used frequently. - s/

Hi all,

 

I noticed Jurgen's comment abou= t built-in trust anchors in his YANG doctor review of trust-anchors-13. I w= anted to pull that out into a dedicated thread/discussion here.<= /span>

 

Jurgen:

 

- Section 3 talks ab= out populating <running> with built-in trust

  anchors.=

 

   In orde= r for the built-in trust anchors to be referenced by

   configu= ration, the referenced certificates MUST first be copied into

   <run= ning>.  The certificates SHOULD be copied into <running> usin= g

   the sam= e "key" values, so that the server can bind them to the built-

   in entr= ies.

 

  Is the idea t= hat this copy operation is an explicit management

  operation or = can implementations populate <running> with this

  data automati= cally?

 

I suppose a server *could* populate this in running as part of a built-in startup datastore in the = absence of a startup datastore (i.e. as contents of a RFC8808 factory defau= lt). But I assume it is desirable to be able to delete the running copy of a built-in item. So the system would= have to avoid populating these unless it is loading the factory default.

 

But even if the system can popu= late these, we'd also want the client/user to be able to explicitly populat= e them as well (i.e. in case they delete one from running, and want to add = it back in to reference it).

 

In either case (system populati= on of running, or client population of running), do we really need to put t= he contents of the bag or the cert into running?  Or is populating the= list key enough since the operational copy shows what contents are in use for that list entry?

 

Jason

--_000_DM6PR08MB5084E8CF8D3D4D0E77C841CD9BAA0DM6PR08MB5084namp_-- From nobody Tue Jan 12 11:59:59 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 B353A3A1124 for ; Tue, 12 Jan 2021 11:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OmI-F2m77oD for ; Tue, 12 Jan 2021 11:59:55 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B1E3A1123 for ; Tue, 12 Jan 2021 11:59:54 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 23E28670; Tue, 12 Jan 2021 20:59:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id PunA56Q4rdUm; Tue, 12 Jan 2021 20:59:52 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 12 Jan 2021 20:59:52 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F78320156; Tue, 12 Jan 2021 20:59:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id gp47Erx2ZABy; Tue, 12 Jan 2021 20:59:52 +0100 (CET) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id F0C5620154; Tue, 12 Jan 2021 20:59:51 +0100 (CET) Date: Tue, 12 Jan 2021 20:59:51 +0100 From: Juergen Schoenwaelder To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: Netconf Message-ID: <20210112195951.oi7dlnnqpda7wavm@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Sterne, Jason (Nokia - CA/Ottawa)" , Netconf References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [netconf] built-in trust anchors X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 12 Jan 2021 19:59:58 -0000 Jason, since the leafref typedefs are weak references that do not require that the certs/keys exist (there is no 'require-instance true'), it may be OK to not have the certs/keys in in terms of validity of the datastore. Oops, I had to reread RFC 7950 (section 9.9.3): if require-instance is not present, it defaults to true, so my review comment about weak references is incorrect, these are actually strong references and hence there is the need to copy what is referenced. Setting require-instance to false may resolve this (but we loose the ability to catch references to certs/keys that do not exist). /js On Tue, Jan 12, 2021 at 07:02:04PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi all, > > I noticed Jurgen's comment about built-in trust anchors in his YANG doctor review of trust-anchors-13. I wanted to pull that out into a dedicated thread/discussion here. > > Jurgen: > > > - Section 3 talks about populating with built-in trust > > anchors. > > > > In order for the built-in trust anchors to be referenced by > > configuration, the referenced certificates MUST first be copied into > > . The certificates SHOULD be copied into using > > the same "key" values, so that the server can bind them to the built- > > in entries. > > > > Is the idea that this copy operation is an explicit management > > operation or can implementations populate with this > > data automatically? > > I suppose a server *could* populate this in running as part of a built-in startup datastore in the absence of a startup datastore (i.e. as contents of a RFC8808 factory default). But I assume it is desirable to be able to delete the running copy of a built-in item. So the system would have to avoid populating these unless it is loading the factory default. > > But even if the system can populate these, we'd also want the client/user to be able to explicitly populate them as well (i.e. in case they delete one from running, and want to add it back in to reference it). > > In either case (system population of running, or client population of running), do we really need to put the contents of the bag or the cert into running? Or is populating the list key enough since the operational copy shows what contents are in use for that list entry? > > Jason > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 12 14:59:34 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 214193A1373 for ; Tue, 12 Jan 2021 14:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V1rcpI9ROdm for ; Tue, 12 Jan 2021 14:59:31 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2132.outbound.protection.outlook.com [40.107.92.132]) (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 4E5A03A136C for ; Tue, 12 Jan 2021 14:59:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hUxVPnUCEvxcVG6jPr4DCfSAN6PGRY/ASIWeeIxvGuQVreHeTnBey/Dp8u6+QFsW4yklXXO6yd7Ql+IAiCPhkGaiiidfY+BhQqq36wb63Xhxa0shMroLgx0qRwJdPLf6NEfy5vEuexyKd2iLu0pDAeZKJMGzSDV7cumjIIlGCxiTx4wgnc7FHxiatCoTmyX28W9pGgPx5CwuLVl91qPkLt7LEspyD4FA0ZG7eD5DUkUTwKyqHXK/xvuBTGimNd7LxuDNdjUHQ9DRo8ZJa+9hVnvSb44iS4oRdwX0BeLIQOnWgX1CYFRxdv441TlOvazVNQ2uTMaig+kerNecDVEu8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MuNhft9+tA0ul53guen7wFb7JKfaUpqtqm9aqIXKKjY=; b=CO2wTAMPYQ1lDEz2bwfU1iP12VYIL4DhjQr6r600fTblS+HPSMygnidB+F61V2c1smsR2/DpwP8vGWQq5BKXDQww3LppiBX1GafHaXCJ17I6oH33iash+evT+tLc6w7X2CYh4Sqz2VwxiK7eLMldmZUbNBwtMJhkH1QLN4QBN4Qe+/1v4p7M4Qexcod78GHevDaov3Ps8MLglKT7htI8NmuRdSSVkRCKzb4sy2WoYxwfgdD80b0OyAys1H0gS6t/ETb2qDRSCLNt4f5IDpJdDVVf64N66NXf1U28LDZEBCznRiAUbK08/K6wLxVGdLtops2Xb9zLIUDkrG8qo+ZVFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MuNhft9+tA0ul53guen7wFb7JKfaUpqtqm9aqIXKKjY=; b=M+NVk4IJ3KSvKrB/4aztllmn+gVFB20AHZ3YML6P39KvW5s1HtYwN2XAvS1QG57OVimtSLuU24V+ZkTbPmi/hyt2ebLK86feOSjbuXRbQhpKHNVgCld4Q9d6I+OKbYTXhQNHjZNugyHPcXH+EeHWB4Epy0JMVAlr5ertdpOfn2s= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM5PR08MB3324.namprd08.prod.outlook.com (2603:10b6:4:65::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.12; Tue, 12 Jan 2021 22:59:28 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::e9d5:c438:1c73:8ca3]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::e9d5:c438:1c73:8ca3%5]) with mapi id 15.20.3742.012; Tue, 12 Jan 2021 22:59:28 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Juergen Schoenwaelder CC: Netconf Thread-Topic: [netconf] built-in trust anchors Thread-Index: AdbpFFL2IioTw935RTC9hP47Cn7q7QACSnGAAAYuKwA= Date: Tue, 12 Jan 2021 22:59:28 +0000 Message-ID: References: <20210112195951.oi7dlnnqpda7wavm@anna.jacobs.jacobs-university.de> In-Reply-To: <20210112195951.oi7dlnnqpda7wavm@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2607:fea8:e324:8d00:f965:4ae3:4b56:123b] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0f665033-31ec-4573-76ed-08d8b74db704 x-ms-traffictypediagnostic: DM5PR08MB3324: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tY93dCcPPMFN2D63FHmx4Jih+8ZlpLFGKsRXDCtXtuQc3UQchyQvwqesTSF+vDRhMTJcxEkMs9n0Dxj5LJuiG5ZGA119Gr+GtKClLfoxdlBPAk4dSOQvq/kOuCdufSZc8T9XwPJVxEK2EL/Zpcop43C5YtLYgxvREhD9I9Zf9/qqnrFT0QirRuxzJRbKSXBTkxHVkvj9gM+W2UXzayd9PzOm+Rig1jWynH9EaBanrOdmx2F6iGmT2N5fWnYrkf0ZhCW5Rv6KUJpCMbCQNCX7IvrXSD5qXVlA1lxYGBGefLY9FsqW+P5Spp4k1sROHFgYp70y1y7QACqDMUUDAkgX/2QoC2iARtiZNg8JVKPLG1OUc3aNhW2vU+6O6o2WmVqadwWAn0XIx1xCvk+cSkhb6GkhOTyW76dXAxhGhvTaIBeIS7JaKntQEqABZEiL0EvUpunMAiql2AbtWQ4cd/KjRKq5APBinh0iDTBoiTXdX9u+rkrlUUqiTcEiOV3vaG1UlQGT2V1NwlpLL9FueXbSTQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(396003)(346002)(39860400002)(136003)(4326008)(8676002)(33656002)(316002)(7696005)(66476007)(55016002)(2906002)(53546011)(83080400002)(86362001)(186003)(6506007)(83380400001)(9686003)(71200400001)(8936002)(966005)(478600001)(5660300002)(52536014)(66556008)(66946007)(76116006)(64756008)(66446008)(6916009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?SE2t42sq352rK4Lb/6tYB95X/lnLYmmFHPn3unIgEwNJjk1W6I2LIQqT4DVO?= =?us-ascii?Q?fSv7h3fcUn8/vvI+BNvTWGcx5uB+L+qrHOT6f6mlpZSK8I5ifITHuIRzZ6qc?= =?us-ascii?Q?0Ys3gczqMeIq0FiDyQ4ZlIxBwuALkidh/4T0lH819g7xB3nXkCkCa/UvDTyN?= =?us-ascii?Q?gAzjqYIeZgmOrr5Kf6M4CPhjiVY5GdTzfjJIiDbWJURAnUaH9GLBIu0YIDiM?= =?us-ascii?Q?VLDsj9JdfqxB+41QyZa4DpjDUwq2vFWbGlYYb4eqQrjeZgt0o9H8B0C523b/?= =?us-ascii?Q?7nK1PwzEb9D4fsIzRTQQr17EbBqrFh7eUvIj2mZdDHegK4R1RqSa5/OBr0Yi?= =?us-ascii?Q?5bHqWn72iLEbX980MNRqLyQRgjCpZ5/DPjHKXy0bDDl8zfFqrYQdf835CjfJ?= =?us-ascii?Q?4pmd7e0x6SOoPKV6/Uc3+bqPoTDWBMjBjA9S17/oK3DUDbwhHB6yCiuiszRo?= =?us-ascii?Q?5DxdjVJQSTXb/pGsZow1Xsi/7oXv72qiqzqHHixosLVexd8Bz40j+SEwcqX9?= =?us-ascii?Q?QEyQkgPY8bzOjMpUX5GC6l+bbkKLFd6SsggJOVKLIRg2PwJ+F/nDra3AsKyh?= =?us-ascii?Q?lbojOyrnEcSwQhbRnjBlSRb9bgx8thOr1rY785QuWEC8jUlnEGz/0SqwsbSO?= =?us-ascii?Q?Vb6WOpax6l0ospxdTJZsyYEYJdv4i3XZSaQKOrvKxrUTMPys9Cm4o8vJAuPO?= =?us-ascii?Q?sudh11Pra6SlPid8X4LBI+VNRpSylt3IcYsi8q97j5SHZsfBVLZ4PGKMoZcd?= =?us-ascii?Q?Xq7dNc8yzMyInmS9AvYQ3tHQqJLJCUJ1dAMV2jQHqKrQVQDUsCqMDF4MK2iT?= =?us-ascii?Q?KdQdVLCA0quC4oAPjNDghxtEipy7zb03AzNH0diKoh9H/BSHggxI0L2eaNEP?= =?us-ascii?Q?LqMb0Sg6k29ZOZlekWy9jBj+JyoZlFlO3A2UcDpFZcfG/Riny7lABhVa918v?= =?us-ascii?Q?xwhXV2DtbhBvLoyUyTL+t9bosmM3sCfDOCDNXed7ISgaf7L6xh7LU9R24hSe?= =?us-ascii?Q?SG3cJ8PwG2hsrPza5o0nixZeRT3zTQwY6CYCcKA2ofTlYEHNVVU7fhWoYtGK?= =?us-ascii?Q?GGtoLfDE?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f665033-31ec-4573-76ed-08d8b74db704 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2021 22:59:28.3163 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NIuwoCYz2ZHu7jrphMFskBk3Ik8r1j28uLWP2HbWfUjuk7HgHCW6uNxSyxJucAuDSTxpSOrjx/0dQuQMXeoVig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB3324 Archived-At: Subject: Re: [netconf] built-in trust anchors X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 12 Jan 2021 22:59:33 -0000 Yes - adding require-instance false would eliminate the issue about built-i= n anchors in . But there are useful advantages to keeping require-= instance true. I don't have a strong feeling though one way or the other. But assuming we keep require-instance true then the question still remains = of how built-in items get into (and are they deletable, and do we= only need keys in running, etc). Jason > -----Original Message----- > From: Juergen Schoenwaelder > Sent: Tuesday, January 12, 2021 3:00 PM > To: Sterne, Jason (Nokia - CA/Ottawa) > Cc: Netconf > Subject: Re: [netconf] built-in trust anchors >=20 > Jason, >=20 > since the leafref typedefs are weak references that do not require > that the certs/keys exist (there is no 'require-instance true'), it > may be OK to not have the certs/keys in in terms of validity > of the datastore. >=20 > Oops, I had to reread RFC 7950 (section 9.9.3): if require-instance is > not present, it defaults to true, so my review comment about weak > references is incorrect, these are actually strong references and > hence there is the need to copy what is referenced. Setting > require-instance to false may resolve this (but we loose the ability > to catch references to certs/keys that do not exist). >=20 > /js >=20 > On Tue, Jan 12, 2021 at 07:02:04PM +0000, Sterne, Jason (Nokia - CA/Ottaw= a) > wrote: > > Hi all, > > > > I noticed Jurgen's comment about built-in trust anchors in his YANG doc= tor > review of trust-anchors-13. I wanted to pull that out into a dedicated > thread/discussion here. > > > > Jurgen: > > > > > > - Section 3 talks about populating with built-in trust > > > > anchors. > > > > > > > > In order for the built-in trust anchors to be referenced by > > > > configuration, the referenced certificates MUST first be copied into > > > > . The certificates SHOULD be copied into using > > > > the same "key" values, so that the server can bind them to the built= - > > > > in entries. > > > > > > > > Is the idea that this copy operation is an explicit management > > > > operation or can implementations populate with this > > > > data automatically? > > > > I suppose a server *could* populate this in running as part of a built-= in > startup datastore in the absence of a startup datastore (i.e. as contents= of a > RFC8808 factory default). But I assume it is desirable to be able to dele= te the > running copy of a built-in item. So the system would have to avoid popula= ting > these unless it is loading the factory default. > > > > But even if the system can populate these, we'd also want the client/us= er > to be able to explicitly populate them as well (i.e. in case they delete = one > from running, and want to add it back in to reference it). > > > > In either case (system population of running, or client population of > running), do we really need to put the contents of the bag or the cert in= to > running? Or is populating the list key enough since the operational copy > shows what contents are in use for that list entry? > > > > Jason >=20 > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Tue Jan 12 17:15: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 CE5E53A1542; Tue, 12 Jan 2021 17:15:32 -0800 (PST) X-Quarantine-ID: <0v7690H3V19v> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...AA0@DM6PR08MB5084.namprd08.prod.outlook.com> X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 0v7690H3V19v; Tue, 12 Jan 2021 17:15:31 -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 E48613A1540; Tue, 12 Jan 2021 17:15:30 -0800 (PST) Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DFqDZ4FVkz67b2m; Wed, 13 Jan 2021 09:12:30 +0800 (CST) Received: from fraeml745-chm.china.huawei.com (10.206.15.226) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 13 Jan 2021 02:15:28 +0100 Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Wed, 13 Jan 2021 02:15:28 +0100 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.18]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0509.000; Wed, 13 Jan 2021 09:15:19 +0800 From: Qin Wu To: "Sterne, Jason (Nokia - CA/Ottawa)" , Netconf CC: "draft-ma-netconf-with-system@ietf.org" Thread-Topic: built-in trust anchors Thread-Index: AdbpR3BVyU6dINBtRDqjLKPEfMuxVgAAD8+Q Date: Wed, 13 Jan 2021 01:15:19 +0000 Message-ID: References: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.101.103] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAADCD04AAdggeml531mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] built-in trust anchors X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 13 Jan 2021 01:15:33 -0000 --_000_B8F9A780D330094D99AF023C5877DABAADCD04AAdggeml531mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 t6K8/sjLOiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFN0 ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EvT3R0YXdhKQ0Kt6LLzcqxvOQ6IDIwMjHE6jHUwjEzyNUg MzowMg0KytW8/sjLOiBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPg0K1vfM4jogW25ldGNvbmZd IGJ1aWx0LWluIHRydXN0IGFuY2hvcnMNCg0KSGkgYWxsLA0KDQpJIG5vdGljZWQgSnVyZ2VuJ3Mg Y29tbWVudCBhYm91dCBidWlsdC1pbiB0cnVzdCBhbmNob3JzIGluIGhpcyBZQU5HIGRvY3RvciBy ZXZpZXcgb2YgdHJ1c3QtYW5jaG9ycy0xMy4gSSB3YW50ZWQgdG8gcHVsbCB0aGF0IG91dCBpbnRv IGEgZGVkaWNhdGVkIHRocmVhZC9kaXNjdXNzaW9uIGhlcmUuDQoNCkp1cmdlbjoNCg0KDQotIFNl Y3Rpb24gMyB0YWxrcyBhYm91dCBwb3B1bGF0aW5nIDxydW5uaW5nPiB3aXRoIGJ1aWx0LWluIHRy dXN0DQoNCiAgYW5jaG9ycy4NCg0KDQoNCiAgIEluIG9yZGVyIGZvciB0aGUgYnVpbHQtaW4gdHJ1 c3QgYW5jaG9ycyB0byBiZSByZWZlcmVuY2VkIGJ5DQoNCiAgIGNvbmZpZ3VyYXRpb24sIHRoZSBy ZWZlcmVuY2VkIGNlcnRpZmljYXRlcyBNVVNUIGZpcnN0IGJlIGNvcGllZCBpbnRvDQoNCiAgIDxy dW5uaW5nPi4gIFRoZSBjZXJ0aWZpY2F0ZXMgU0hPVUxEIGJlIGNvcGllZCBpbnRvIDxydW5uaW5n PiB1c2luZw0KDQogICB0aGUgc2FtZSAia2V5IiB2YWx1ZXMsIHNvIHRoYXQgdGhlIHNlcnZlciBj YW4gYmluZCB0aGVtIHRvIHRoZSBidWlsdC0NCg0KICAgaW4gZW50cmllcy4NCg0KDQoNCiAgSXMg dGhlIGlkZWEgdGhhdCB0aGlzIGNvcHkgb3BlcmF0aW9uIGlzIGFuIGV4cGxpY2l0IG1hbmFnZW1l bnQNCg0KICBvcGVyYXRpb24gb3IgY2FuIGltcGxlbWVudGF0aW9ucyBwb3B1bGF0ZSA8cnVubmlu Zz4gd2l0aCB0aGlzDQoNCiAgZGF0YSBhdXRvbWF0aWNhbGx5Pw0KDQpJIHN1cHBvc2UgYSBzZXJ2 ZXIgKmNvdWxkKiBwb3B1bGF0ZSB0aGlzIGluIHJ1bm5pbmcgYXMgcGFydCBvZiBhIGJ1aWx0LWlu IHN0YXJ0dXAgZGF0YXN0b3JlIGluIHRoZSBhYnNlbmNlIG9mIGEgc3RhcnR1cCBkYXRhc3RvcmUg KGkuZS4gYXMgY29udGVudHMgb2YgYSBSRkM4ODA4IGZhY3RvcnkgZGVmYXVsdCkuIEJ1dCBJIGFz c3VtZSBpdCBpcyBkZXNpcmFibGUgdG8gYmUgYWJsZSB0byBkZWxldGUgdGhlIHJ1bm5pbmcgY29w eSBvZiBhIGJ1aWx0LWluIGl0ZW0uIFNvIHRoZSBzeXN0ZW0gd291bGQgaGF2ZSB0byBhdm9pZCBw b3B1bGF0aW5nIHRoZXNlIHVubGVzcyBpdCBpcyBsb2FkaW5nIHRoZSBmYWN0b3J5IGRlZmF1bHQu DQoNCltRaW5dOkludGVyZXN0aW5nIGRpc2N1c3Npb24sIGVpdGhlciBsb2FkaW5nIHRoZSBmYWN0 b3J5IGRlZmF1bHQgZnJvbSBmYWN0b3J5IGRhdGFzdG9yZSBvciBkZWZpbmUgYSBuZXcgc3lzdGVt IGRhdGFzdG9yZSwgSSB0aGluayBib3RoIGNhbiBlbmFibGUgdGhlIHNlcnZlciB0byBwb3B1bGF0 ZSB0aGUgZGF0YSBhdXRvbWF0aWNhbGx5LCBvbmUgb2YgaW5kaXZpZHVhbCBkcmFmdCBpbiBORVRD T05GIChkcmFmdC1tYS1uZXRjb25mLXdpdGgtc3lzdGVtKSBzZWVtcyB0byB0YXJnZXQgdG8gYWRk cmVzcyB0aGlzIGlzc3VlLCBpLmUuLCBhdm9pZCBkdXBsaWNhdGVkIGRhdGEgaXRlbXMgdG8gYmUg Y3JlYXRlZCBpbiB0aGUgcnVubmluZywgSSBoYXZlIGNvcGllZCB0aGlzIGVtYWlsIHRvIHRoZSBh dXRob3Igb2YgZHJhZnQtbWEtbmV0Y29uZi13aXRoLXN5c3RlbSBmb3IgdGhlaXIgZmVlZGJhY2su DQoNCkJ1dCBldmVuIGlmIHRoZSBzeXN0ZW0gY2FuIHBvcHVsYXRlIHRoZXNlLCB3ZSdkIGFsc28g d2FudCB0aGUgY2xpZW50L3VzZXIgdG8gYmUgYWJsZSB0byBleHBsaWNpdGx5IHBvcHVsYXRlIHRo ZW0gYXMgd2VsbCAoaS5lLiBpbiBjYXNlIHRoZXkgZGVsZXRlIG9uZSBmcm9tIHJ1bm5pbmcsIGFu ZCB3YW50IHRvIGFkZCBpdCBiYWNrIGluIHRvIHJlZmVyZW5jZSBpdCkuDQoNCltRaW5dOiBTZWUg ZGV0YWlscyBpbiBkcmFmdC1tYS1uZXRjb25mLXdpdGgtc3lzdGVtLiBJdCBoZWxwcyBkZWZpbmUg Y29uc2lzdGVudCBiZWhhdmlvciBmb3Igc3lzdGVtIGRhdGEgaGFuZGxpbmcsIGp1c3QgbGlrZSB3 aGF0IFJGQzYyNDMgZGlkLg0KDQpJbiBlaXRoZXIgY2FzZSAoc3lzdGVtIHBvcHVsYXRpb24gb2Yg cnVubmluZywgb3IgY2xpZW50IHBvcHVsYXRpb24gb2YgcnVubmluZyksIGRvIHdlIHJlYWxseSBu ZWVkIHRvIHB1dCB0aGUgY29udGVudHMgb2YgdGhlIGJhZyBvciB0aGUgY2VydCBpbnRvIHJ1bm5p bmc/ICBPciBpcyBwb3B1bGF0aW5nIHRoZSBsaXN0IGtleSBlbm91Z2ggc2luY2UgdGhlIG9wZXJh dGlvbmFsIGNvcHkgc2hvd3Mgd2hhdCBjb250ZW50cyBhcmUgaW4gdXNlIGZvciB0aGF0IGxpc3Qg ZW50cnk/DQoNCkphc29uDQo= --_000_B8F9A780D330094D99AF023C5877DABAADCD04AAdggeml531mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

=B7=A2=BC=FE=C8=CB: netconf [mailto:netconf-bounces@ietf.org] =B4=FA=B1=ED Sterne, Jason (Nokia= - CA/Ottawa)
=B7=A2=CB=CD=CA=B1=BC=E4: 2021= =C4=EA1=D4= =C213=C8=D5 3:02
=CA=D5=BC=FE=C8=CB: Netconf <netconf@ietf.org>
=D6=F7=CC=E2: [netconf] built-in trust anchors

 

Hi all,

 

I noticed Jurgen's comment abou= t built-in trust anchors in his YANG doctor review of trust-anchors-13. I w= anted to pull that out into a dedicated thread/discussion here.<= /span>

 

Jurgen:

 

- Section 3 talks about populating <running> with built-in trust

  anchors.

 

   In order for the built-in trust anchors to be referenced by

   configuration, the referenced certificates MUST first be copi= ed into

   <running>.  The certificates SHOULD be copied into= <running> using

   the same "key" values, so that the server can bind = them to the built-

   in entries.

 

  Is the idea that this copy operation is an explicit management=

  operation or can implementations populate <running> with this=

  data automatically?

 

I suppose a server *could* populate this in running as part of a built-in startup datastore in the = absence of a startup datastore (i.e. as contents of a RFC8808 factory defau= lt). But I assume it is desirable to be able to delete the running copy of a built-in item. So the system would= have to avoid populating these unless it is loading the factory default.

 

[Qin]:Interesting discussion, either loading the factory default from= factory datastore or define a new system datastore, I think both can enabl= e the server to populate the data automatically, one of individual draft in NETCONF (draft-ma-netconf-with-system) seems to= target to address this issue, i.e., avoid duplicated data items to be crea= ted in the running, I have copied this email to the author of draft-ma-netc= onf-with-system for their feedback.

 

But even if the system can popu= late these, we'd also want the client/user to be able to explicitly populat= e them as well (i.e. in case they delete one from running, and want to add = it back in to reference it).

&n= bsp;

[Qin]: See details in draft-ma-netconf-with-system. It helps define c= onsistent behavior for system data handling, just like what RFC6243 did.

 

In either case (system populati= on of running, or client population of running), do we really need to put t= he contents of the bag or the cert into running?  Or is populating the= list key enough since the operational copy shows what contents are in use for that list entry?

 

Jason

--_000_B8F9A780D330094D99AF023C5877DABAADCD04AAdggeml531mbschi_-- From nobody Tue Jan 12 17:24:49 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 E79AA3A07E2; Tue, 12 Jan 2021 17:24:46 -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, RCVD_IN_DNSWL_BLOCKED=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 nGj5lwt4qIAx; Tue, 12 Jan 2021 17:24:45 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B573A046B; Tue, 12 Jan 2021 17:24:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 91EFB38982; Tue, 12 Jan 2021 20:26:13 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2UEtQkuwWY3q; Tue, 12 Jan 2021 20:26:13 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2A0273897F; Tue, 12 Jan 2021 20:26:13 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B35701F9; Tue, 12 Jan 2021 20:24:42 -0500 (EST) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3Fb=3FSsO8cmdlbiBTY2jDtm53w6RsZGVy=3F=3D?= cc: yang-doctors@ietf.org, last-call@ietf.org, netconf@ietf.org, draft-ietf-netconf-trust-anchors.all@ietf.org In-Reply-To: <161047687248.13931.17900123352005904827@ietfa.amsl.com> References: <161047687248.13931.17900123352005904827@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [netconf] [Last-Call] Yangdoctors last call review of draft-ietf-netconf-trust-anchors-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2021 01:24:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable J=C3=BCrgen Sch=C3=B6nw=C3=A4lder via Datatracker wrote: > - In 2.2.1, I was not sure what CA certificates are and what EE > certificates are. I then tried to guess EE =3D end entity cert, but > this does not explain CA since the term used in crypto types is > trust anchor cert. The description in the XML clarified that my > guess was kind of correct. Perhaps explain upfront what these > acronyms mean? Or perhaps the acronyms can be avoided by simply > spelling things out? They do not appear to be used frequently. > - s/ --_000_beee731475d94261b495c7e1bc3357fahuaweicom_-- From nobody Wed Jan 13 05:17:15 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 4754C3A0D78; Wed, 13 Jan 2021 05:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sr_pbebxBD28; Wed, 13 Jan 2021 05:17:12 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D661F3A0D70; Wed, 13 Jan 2021 05:17:11 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 123BD670; Wed, 13 Jan 2021 14:17:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 2pePKPDaHdbr; Wed, 13 Jan 2021 14:17:09 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 13 Jan 2021 14:17:09 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8CB9D20166; Wed, 13 Jan 2021 14:17:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id 6blcjKJs-8DP; Wed, 13 Jan 2021 14:17:09 +0100 (CET) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id EB03A20164; Wed, 13 Jan 2021 14:17:08 +0100 (CET) Date: Wed, 13 Jan 2021 14:17:08 +0100 From: Juergen Schoenwaelder To: tom petch Cc: Michael Richardson , "yang-doctors@ietf.org" , "netconf@ietf.org" , "draft-ietf-netconf-trust-anchors.all@ietf.org" Message-ID: <20210113131708.pkjh6rhbak2xnxlr@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: tom petch , Michael Richardson , "yang-doctors@ietf.org" , "netconf@ietf.org" , "draft-ietf-netconf-trust-anchors.all@ietf.org" References: <161047687248.13931.17900123352005904827@ietfa.amsl.com> <22275.1610501082@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] [Last-Call] Yangdoctors last call review of draft-ietf-netconf-trust-anchors-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2021 13:17:14 -0000 To clarify my comment: I was confused by the acronyms that were never expanded, not by the expanded terms themselves. In other words, this is mostly an editorial nit to get fixed. /js On Wed, Jan 13, 2021 at 12:54:55PM +0000, tom petch wrote: > From: netconf on behalf of Michael Richardso= n > Sent: 13 January 2021 01:24 >=20 > J=FCrgen Sch=F6nw=E4lder via Datatracker wrote: > > - In 2.2.1, I was not sure what CA certificates are and what EE > > certificates are. I then tried to guess EE =3D end entity cert, b= ut > > this does not explain CA since the term used in crypto types is > > trust anchor cert. The description in the XML clarified that my > > guess was kind of correct. Perhaps explain upfront what these > > acronyms mean? Or perhaps the acronyms can be avoided by simply > > spelling things out? They do not appear to be used frequently. >=20 > > - s/

Hi Mahesh,=

 

Since draft-ietf-netconf-notification-messages is in parked sta= te, and expired 8 months ago, should the netconf-https-notif document be usi= ng bundled messages? But I don=E2=80=99t know the reason why it=E2=80=99s in parked stat= e and whether it=E2=80=99ll be in drive mode soon.

 

Regards,

Reshad.

 

From: netconf <netconf-bounces@ietf.org> on behalf of Mahesh Jethanandani= <mjethanandani@gmail.com>
Date: Friday, January 22, 2021 at= 2:08 PM
To: Henning Rogge <hrogge@gmail.com>
Cc: = Netconf <netconf@ietf.org>
Subject: Re: [netconf] netconf-ht= tps-notif-draft HTTP "pipelining"

=

 

Hi Henning,=

 

The draft was trying to address the question of =E2=80=9Cpipelining=E2= =80=9D using two methods. One is the equivalent of =E2=80=9CHTTP 1.1 pipelining=E2=80=9D and= the other is concept of =E2=80=9Cbundled-messages=E2=80=9D introduced by draft-ietf-net= conf-notification-messages. In the process it mixed both of them, and thus t= he contradiction in the example in section 1.5.1.

<= p class=3DMsoNormal> 

Let me = update the document to fix the example(s), at which point the WG can decide = if they want to support one or both the methods.

 

Thanks.<= o:p>



On Jan 13,= 2021, at 11:29 PM, Henning Rogge <hrog= ge@gmail.com> wrote:

&nbs= p;

Hi,

I had a longer discussio= n with Kent Watsen yesterday and he asked me
to get the questions about t= he netconf-https-notif-draft to the
mailing list:

In section 1.5.1= the draft talks about "pipelining" of messages. Is
this meant = equivalent to "HTTP 1.1 pipelining" or is this just a
technique= unique to the draft? If this is not something reused from
HTTP, maybe th= ere should be some advice on how this interacts with
normal HTTP server/c= lient code.

Also the example in 1.5.1 seems to contradict each other.=

The overview (page 5) shows the Publisher sending HTTPS POST message=
once for each notification (which I think is important because the URLis part of the context of the message)... but the content description
(= page 6) does only show a single POST with multiple responses. Same is
tru= e for chapter 8.3.

Henning Rogge

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

 

Mahe= sh Jethanandani

 

 

 

 

__________________________________= _____________ netconf mailing list netconf@ietf.org https://www.ietf.org/mai= lman/listinfo/netconf

--B_3694171615_2112389587-- From nobody Sun Jan 24 23:39:23 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 831803A0BE9 for ; Sun, 24 Jan 2021 23:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.802 X-Spam-Level: X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 hs2gL74-Ik3o for ; Sun, 24 Jan 2021 23:39:20 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D8A3A0BDB for ; Sun, 24 Jan 2021 23:39:19 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id f2so8884101ljp.11 for ; Sun, 24 Jan 2021 23:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ysHK8pxAtpR5Yr8FVKn20zESuzR56CJW7aZF79M5Yvk=; b=HNUzqOBKVh4O4F7GfysWPYxMCMLsZmQ/0tIqZbyNHqlnfnkti9R2Hc3UepjnkEx8z1 GV/c2hFXu60CiFyiXZ36/X0ok5WsJHTpliBVgFr6D7W+RAUpoWWE3Fg7yN0KN1TG/Sak PB37W0ajYZsscfpFpPqtFZbE+KTZDXiF6DpUt75KPtBELdP5SvnW2CnFb+nKOzhG1A3f p8zpaTpJ50o57UwW1xfA+/gMESTZMV3DqxoC9RnFDCiElBnJWkbu2zEiwIK+Ii/JoNos ZFCGhtkmulSxphKZ4zVqhAf/3DOErcsAC7j6kJBI5hZ7D80RLUV9O3R6otVCotKCcSKB 0+RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ysHK8pxAtpR5Yr8FVKn20zESuzR56CJW7aZF79M5Yvk=; b=Y08F0yVb2zXuHMkAOkUNIEZBzz1dEbLoQ4TyiOr2odWalI7632r9Jj9bAo9WCZnzme rUeRZVjl8nCPfI+c8p3GqaB5J3B/fzOQ9hkVRHUGB7nO2VLxC9Jssjl5RRea0/8QdLzM zI+lw+TBn4tK+4cGfvo2o32a1pbZdr71GFDFjyboqqI1NGvJ6nkeKun+X+q8xJitBd/B 0nlGE61Fx3KRfVKfbyNhA2Emzh1l8iAKsB7roGzThn1+o3/X/QjZPTHzBsP8R+ioeTZx N0x2j6RtkH55Jg19O96kHEeUHUkF5A1nAF8Ui8B8/uFQVYq30DtNh6H2Lftrb5CF9z/k T/wA== X-Gm-Message-State: AOAM533x97fHqL3/dr5TnYuoaOrbMJiWwnczhr9tmNZeYYsE5cdHzzR4 uZql1kkI+cKfhSeUy4MKk1Wvj2LKGKvZuXvu7+4= X-Google-Smtp-Source: ABdhPJy8AVAiSveyj+D9WX89SGnJiVAyJ/SS5mAN+lIk5Mi9HdVFiSnCue2xd3EI+GozQjgNinZXdvENJ3v0xjnI5dE= X-Received: by 2002:a2e:b88b:: with SMTP id r11mr209914ljp.187.1611560357661; Sun, 24 Jan 2021 23:39:17 -0800 (PST) MIME-Version: 1.0 References: <43B054E1-8834-4178-985F-DB2660E4BAE0@yahoo.com> In-Reply-To: <43B054E1-8834-4178-985F-DB2660E4BAE0@yahoo.com> From: Henning Rogge Date: Mon, 25 Jan 2021 08:38:51 +0100 Message-ID: To: Reshad Rahman Cc: Mahesh Jethanandani , Netconf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] netconf-https-notif-draft HTTP "pipelining" X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 25 Jan 2021 07:39:21 -0000 Hi, The problem I see with the "bundled messages" method is that it seems to transmit the URL once... which contains an important part of the Restconf Semantics... that feels like a strange restriction and something easy to get wrong. Henning On Fri, Jan 22, 2021 at 8:47 PM Reshad Rahman wrote: > > Hi Mahesh, > > > > Since draft-ietf-netconf-notification-messages is in parked state, and ex= pired 8 months ago, should the netconf-https-notif document be using bundle= d messages? But I don=E2=80=99t know the reason why it=E2=80=99s in parked = state and whether it=E2=80=99ll be in drive mode soon. > > > > Regards, > > Reshad. > > > > From: netconf on behalf of Mahesh Jethanandani= > Date: Friday, January 22, 2021 at 2:08 PM > To: Henning Rogge > Cc: Netconf > Subject: Re: [netconf] netconf-https-notif-draft HTTP "pipelining" > > > > Hi Henning, > > > > The draft was trying to address the question of =E2=80=9Cpipelining=E2=80= =9D using two methods. One is the equivalent of =E2=80=9CHTTP 1.1 pipelinin= g=E2=80=9D and the other is concept of =E2=80=9Cbundled-messages=E2=80=9D i= ntroduced by draft-ietf-netconf-notification-messages. In the process it mi= xed both of them, and thus the contradiction in the example in section 1.5.= 1. > > > > Let me update the document to fix the example(s), at which point the WG c= an decide if they want to support one or both the methods. > > > > Thanks. > > > > On Jan 13, 2021, at 11:29 PM, Henning Rogge wrote: > > > > Hi, > > I had a longer discussion with Kent Watsen yesterday and he asked me > to get the questions about the netconf-https-notif-draft to the > mailing list: > > In section 1.5.1 the draft talks about "pipelining" of messages. Is > this meant equivalent to "HTTP 1.1 pipelining" or is this just a > technique unique to the draft? If this is not something reused from > HTTP, maybe there should be some advice on how this interacts with > normal HTTP server/client code. > > Also the example in 1.5.1 seems to contradict each other. > > The overview (page 5) shows the Publisher sending HTTPS POST message > once for each notification (which I think is important because the URL > is part of the context of the message)... but the content description > (page 6) does only show a single POST with multiple responses. Same is > true for chapter 8.3. > > Henning Rogge > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > > _______________________________________________ netconf mailing list netc= onf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jan 25 06:36:34 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 4CA8D3A136C; Mon, 25 Jan 2021 06:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.721 X-Spam-Level: X-Spam-Status: No, score=-7.721 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=U8XDYDW4; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=JrhI30E+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg7fasjLZTzU; Mon, 25 Jan 2021 06:36:30 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4ECB3A136B; Mon, 25 Jan 2021 06:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8545; q=dns/txt; s=iport; t=1611585390; x=1612794990; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=T8eZK/6H1Q6Ta2TiVt2eKiuvs5M4HZZSow84dckHck8=; b=U8XDYDW4PGdsbtz8G0Ubr61C6thd7fUlJKBkDhZtWBzT1pPfNOC8tP2O SRkTYryZb5Wsg1Y3LLerd1mx2cpQ4Q/z/+6jgYC+kaQzoVqUBEaeTDu2u Gfg5QQ+DBANr/3nbP2hkTNZ+xKnKRzfnQIOb+vNtdYX24Hw3r1KeyG20E Y=; X-Files: smime.p7s : 3975 X-IPAS-Result: =?us-ascii?q?A0CDAAAe1A5g/40NJK1YCh0BAQEBCQESAQUFAUCBOwgBC?= =?us-ascii?q?wGBUlEHdi0uLy8Kh34DhFmJNAOPEYoGgS6BJQNUBAcBAQEKAwEBGA0IAgQBA?= =?us-ascii?q?YQGRAKBeAIlNAkOAgMBAQEDAgMBAQEBBQEBAQIBBgRxhWEBC4VzAQEBBAEBP?= =?us-ascii?q?gEBKwELAQsEAgEIEQQBAQ4hAiULHQgBAQQOBQgGgxmBflcDHw8BDqdRAoold?= =?us-ascii?q?IE0gwUBAQaBMwEDAoNoGIILBwMGgTgBgVKBJIpHJhuBQT+BEUOBWH4+gl0BA?= =?us-ascii?q?QOBLy8FM4MTgiyCSD4bCwRDDgEBUAsYDgEWMxcwnFecMgqCd4EZg0eCaYFnk?= =?us-ascii?q?mGDK4o0lRmUHosfkWUTCYQ2AgICAgQFAg4BAQaBVjqBV3AVO4I1AQEyUBcCD?= =?us-ascii?q?Y4hg3GFFIVEdDcCBgoBAQMJfIoIAYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3A/idX/BClqZDMAK5ueC6RUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw01g3IUJnVrfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtUFdrwIVrIrS764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D=?= =?us-ascii?q?3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,373,1602547200"; d="p7s'?scan'208";a="632382055" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jan 2021 14:36:29 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 10PEaTkn024787 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jan 2021 14:36:29 GMT Received: from xfe-aln-001.cisco.com (173.37.135.121) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 25 Jan 2021 08:36:29 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 25 Jan 2021 08:36:29 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 25 Jan 2021 09:36:28 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zk1GfLMGMGOcsvKqDWQ/39423dj/defcy3yox19E+j2Rit95iGFRr9fMv522VO8Rq70n+YvNNFbSiLQP3MFxuHAL6l9p126UbBN6w9QCuAN89PlaIGRvo5Za/KdcN2KOwi4tTzi7sjk5j8/CPlTnvq+c1rFq83ZVoZaEhkMcucOGVXBPka1UIqjZwm8EDiHugzLDXsG9LMN/ga038iSgYSGAvbDfyeRP6p++X81yE+XN5flEfTq0Z6d1msOcIbR/1LUrQmJNCKJWfipSRuqJtnfbMgJaGAx68ni/EGRU+hm6ZMxuugJknoE9mJ2AkyL/8qoOsqRssEPBlkj1vEVXsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TwS/EONUUzRy5jvnF5JGq/n0ICIufHxxJx0+LR5XLkg=; b=jkDVt8IU95LZIBxCCvpsSamDOFSTJr3jBBsjYmwLok3L0LzV/sHclEzMnUXY+cT22D1fTcm6KNPya1OJ6HE7LfrUWqW33QwQDwNMcnD59sDrno+SCxzOhVNw3fjLTPRrwG+QRmPE4UbiJAQxL+AqpFCPgyKcT/T2l4lmQEhrMKX9NF4SD15ZCRV8GCRNLYdiPvdmpu0DH7tSeYrfeKLjWAM9zUvcbnZMqbANPJrpMzA7QRecFvS5Xb6+mJaYG/ylaEzkgDHwD7snCNGbYNwbZpAyvLGihFCzRFXxh3vEFsEddYOoMgyOl3J5uAIwQy+MaocbBGUC8sNzXF+cLca90Q== 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=TwS/EONUUzRy5jvnF5JGq/n0ICIufHxxJx0+LR5XLkg=; b=JrhI30E+tOBZ+Lcim0yyYPO6i4p5R0A/1JbNM7lJXQIErKO+q2UF/adjXJVI8U1Oy0+2pp+3HZURUoUIgJoN3UZ1FWRLiTm0H/CMYvFJprTV8shpSzsBy5DZKj+G13lkKmBDpd5hJ99+RmnPevQanVtBkOcPJ0VuPXsqMAy3/Sc= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3521.namprd11.prod.outlook.com (2603:10b6:208:7b::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.17; Mon, 25 Jan 2021 14:36:27 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::88f5:c7e1:3338:cecf]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::88f5:c7e1:3338:cecf%3]) with mapi id 15.20.3784.017; Mon, 25 Jan 2021 14:36:27 +0000 From: "Eric Voit (evoit)" To: "draft-ietf-netconf-https-notif@ietf.org" CC: "Rob Wilton (rwilton)" , "netconf@ietf.org" Thread-Topic: WGLC: draft-ietf-netconf-https-notif-06 Thread-Index: AdbqdYOgUz15Gs1wTZ6RgVXH+iq7RQGk0X5Q Date: Mon, 25 Jan 2021 14:36:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [108.18.114.139] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d16007d3-255c-4d0a-e5e9-08d8c13e98f1 x-ms-traffictypediagnostic: BL0PR11MB3521: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3PaCRP7xVnHHw46SLxd/wkS7qpy1kSCacL4ldHs2DyD/ePJ75BHu3TlfilmX/WYwemxCz+p+b+syNqd8NM2AfC9R8LIZ0U39bgLE1z43EFARnjkQFCCplRjyPiLkG0TYrjtG2LBG/elMTCY/llIwzFBYHhZKkCOSW+GshsBgaJua3izIF//Io1EpGn7YoF5g0yxiB4xh+dS3puoClIkgJ9FhnU2UQEabZ5aHQwQtRDnBWPd1PY1XQClGRM1z4fMRz2Q6/4QngZY2yQ2bUbNvAy/Svcuc1GKpNvWcYXXCQk4glrSFk3kJT8L6wyL8TKXo34uAKgyMcmuEEbwuS8kz0dIYVkNxEPbcb77u4uFXDDrPb/uhDUQk9ks1MlwIJaHBlgFmg7iXdvnY1awy5auQ6b8JJhSfhz1dJeF/8+ulh05UvCm+rp+jjAdrSP9JB+Uror9VRBZBKNCX2Lm3s2Le3Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(376002)(366004)(136003)(39860400002)(186003)(71200400001)(478600001)(86362001)(66446008)(52536014)(2906002)(66946007)(66556008)(66476007)(5660300002)(966005)(316002)(64756008)(66616009)(54906003)(83380400001)(33656002)(7696005)(6916009)(9686003)(4326008)(450100002)(6506007)(53546011)(76116006)(8936002)(55016002)(8676002)(26005)(99936003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Km7e7y3hI6ZW7ZSp2xh0ltwt3wWVNQ63ffcpkJmNv0QX3N95v+Qy0D6HSdIs?= =?us-ascii?Q?EJ5sstwCWApnoTece3OI1iCTQgH2Z9iHMji6aJn76DQXjZhWX4QaWQjT8Rvc?= =?us-ascii?Q?3BB/0WkxNZ4rJVoQTP0s2xeB1vNAuiTanS1WOGnEVnWFWEBI/yq0asa+gSES?= =?us-ascii?Q?IH64jfzM5YGlm0MocPAz3SlxKpRshmxe0uWanqp33YIAbZMJjIyRE7z2Pdpx?= =?us-ascii?Q?+vosMAJfhUcWzm3xjHwIYo6BQfgjNlX4obpTCQXQgrZtOmWRBzHsf3zL9ohM?= =?us-ascii?Q?foZwh/kBReN4CP5WEFPvgNngDniTyMm89J+/MswnPnvKauph+mPD4vFDJ69m?= =?us-ascii?Q?oow1EsznwNf/QnLeRF2jZF79eFUKxcxyv8akAflKuPfXJAaMuhkADy3OD3f5?= =?us-ascii?Q?KDenjvcnd7oZM3ziCVn+38/sVwlYWkNpCAYjinIndP4Xolexg456e6uAXxDj?= =?us-ascii?Q?2CeVu7QpSD1dAVE/2Bxf2b2vR9S0b4BIjsTyNhhzlyDnMUxH6OaHf5Y4HTd9?= =?us-ascii?Q?5iUs/83D6kmdoLCpDVPpIjwps/71HTzkAccIF28oNXvKpty8O3croH07qKXT?= =?us-ascii?Q?v8Kwi4iwDnYOI3iXeCEMYsa6bcFZEp7W8SOZg0Z18/6X2wyh+OgZuRfa5IaW?= =?us-ascii?Q?N36eh0MCtqEOprwC8Fl5jWpbp0CDwe29ZO747gfAkSWw8g1C6dYdMXg4Mm/R?= =?us-ascii?Q?JOP8OMCEon1WqAZZis804vPL1+izGHia8A949HKiqaGTHMVPr8VmnTuIwh/q?= =?us-ascii?Q?McRjYFaKkPBAl2QBgRQb6+gt08T2NpxOtU8VgWwobP8UBWMBX2lvIrOMFZ33?= =?us-ascii?Q?FBlcKsL+B6fobaVea1oWIwtUPq5v5wI9RnsVMstJWM6lwFzBIpUbggLQslo0?= =?us-ascii?Q?neWnItxXz62IctEfHWuBsFkDXnrZmWd9arYETUnSW93dTq81uElWx0sXzIle?= =?us-ascii?Q?E28rYATckJva2x06rEEplzQ/eSgDwrEn5HU9+NuDEu/SC3/v6mbvxOBcw7CH?= =?us-ascii?Q?wtwnB822mY5hEyEfDF36jYQFYVF6sqmh9Wk4XK9Ce0nS/LGQDAK+sCUDwTW6?= =?us-ascii?Q?yAmWRcdd?= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0529_01D6F2FD.8B396350" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3122.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d16007d3-255c-4d0a-e5e9-08d8c13e98f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2021 14:36:26.6920 (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: CMNLCMvOjSdxl4TuFdY69dk2st0571YNPb2cnESFTPw87fyZ084NfV36Gm3a7ie0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3521 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 25 Jan 2021 14:36:32 -0000 ------=_NextPart_000_0529_01D6F2FD.8B396350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have reviewed this document. I believe it close to being ready. I do have three comments: (1) Section 1.1 There was an interaction in July 2020 about describes why subscription state change notifications are not included within the draft. https://mailarchive.ietf.org/arch/msg/netconf/K0jnMW3GZknxihnNjKL4UlFTfoY/ https://mailarchive.ietf.org/arch/msg/netconf/CYOosxZy_-tKKsrCCoLmQeFvEuI/ Actually, we are talking only about a subset of the subscription state change notifications, as is include within examples of this document. Per Alex and my earlier requests, it would be good to include which state change notifications are included, and why, so that others have this context. This would allow receivers to understand that the control plane messages which identify the current state of the subscription on the subscriber are not available. Perhaps it might even drive others who might want this functionality to add this upon the current http-notif. This might be worth including in Section 1.1, Applicability Statement. (2) Section 2.1 Learning Receiver Capabilities is critical, as Configured Subscriptions can DOS a receiver if adequate protections are not on the publisher. It would be useful to list this here so that the topic is not missed in an implementation. Alternatively this could be addressed in Section 5. (3) In Sections 1.5 and 8.3 there is a reference to I-D.ietf-netconf-notification-messages. I am not sure how this impacts the eventual completion of this draft, but defer to others who know the IETF process better. Thanks, Eric > -----Original Message----- > From: netconf On Behalf Of Rob Wilton (rwilton) > Sent: Thursday, January 14, 2021 8:12 AM > To: netconf@ietf.org; draft-ietf-netconf-https-notif@ietf.org > Subject: [netconf] WGLC: draft-ietf-netconf-https-notif-06 > > This message begins a two-week WGLC for draft-ietf-netconf-https-notif-06 > ending on Jan 28. Here is a direct link to the HTML version of the draft: > > https://tools.ietf.org/html/draft-ietf-netconf-https-notif-06 > > Positive comments, e.g., "I've reviewed this document and believe it is ready for > publication", are welcome! This is useful and important, even from authors. > Objections, concerns, and suggestions are also welcomed at this time. > > Please note, the reason that I am making this request rather than the WG chairs > is because both chairs are listed as authors on this document. > > Thank you, > Rob Wilton, OPS AD > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_0529_01D6F2FD.8B396350 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMTI1MTQzNjIzWjAjBgkqhkiG 9w0BCQQxFgQUKQCZUqjUV3dr7dmslvnnePt1YdQwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQB0My+OPHQGzKv5JJKbyc/4GV8omkAReBhClMJ2GQ03Z+kPi96pStLbZ6E/Bx4qGdln i5wjuYcm4xWubJgnLN3XATjEdHf72uAuYsRWfUbefkyEHy1XkoQdzF4T4FbHt5Pw/79I+mbLdfuS mocet9htEfi46r0dgs9hfvbnf6Vzq5CIBoMumN0QLdcmDDC8Jy0nj02ToD2XYRscayAw6ZDi/i2R sPo84pO8VqF+17Xl45KCt+KfdNo5wly0oxegST55MhB5M63woTjabTodaQOSHPdh4HwmepVPTQP1 HjEAlvUEhZZhzd2uKk3FtbwISIg++ySaXSrP28eqdP4bQlXnAAAAAAAA ------=_NextPart_000_0529_01D6F2FD.8B396350-- From nobody Mon Jan 25 17:57:44 2021 Return-Path: <010001773c692875-2c22a9f2-80e8-4a16-81f3-c17fbb95b50e-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 7137E3A1ABD for ; Mon, 25 Jan 2021 17:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5Q0uk7xaCjX for ; Mon, 25 Jan 2021 17:57:42 -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 ED4DC3A1AB4 for ; Mon, 25 Jan 2021 17:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1611626260; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=BdUdSteI2ph/UL0qr7wtmXI9KADR2ctdAljvrN0s1M0=; b=aJzFycGJpl+LwAS3V8CHdi8U/gkO01hygdL7Rr0lEx2Mwd5xs9mu1xDJrAiza0xr bw37IS2ItGVskJjvR0TBRsahAmF4r62s7B0/jnkA/OzRKYDqtYNwm+Fc40eAYrVBuUm ka+2KXDCPKNgjdgaEeLhIjAl3xVbzjBCJveMUN44= From: Kent Watsen Message-ID: <010001773c692875-2c22a9f2-80e8-4a16-81f3-c17fbb95b50e-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_18EA960C-6134-48A2-878D-C6AEEECB93DD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 26 Jan 2021 01:57:40 +0000 In-Reply-To: <43B054E1-8834-4178-985F-DB2660E4BAE0@yahoo.com> Cc: Mahesh Jethanandani , Henning Rogge , "netconf@ietf.org" To: Reshad Rahman References: <43B054E1-8834-4178-985F-DB2660E4BAE0@yahoo.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.01.26-54.240.48.110 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] netconf-https-notif-draft HTTP "pipelining" X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 26 Jan 2021 01:57:43 -0000 --Apple-Mail=_18EA960C-6134-48A2-878D-C6AEEECB93DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Reshad, et. al., > Since draft-ietf-netconf-notification-messages is in parked state, and = expired 8 months ago, should the netconf-https-notif document be using = bundled messages? But I don=E2=80=99t know the reason why it=E2=80=99s = in parked state and whether it=E2=80=99ll be in drive mode soon. There=E2=80=99s an open question as to what extent this draft supports = draft-ietf-netconf-notification-messages. Section 2 (Learning Receiver Capabilities) describes how a Publisher can = discover what optional capabilities a Receiver supports. The section = includes an example that shows the URN =E2=80=9Cbinary-encoding:1.0=E2=80=9D= being returned. =20 What=E2=80=99s missing, however, is the creation of something like an = IANA maintained registry for all of the URNs that can be returned by the = Receiver. This registry would need to, for instance, contain an initial entry to = indicate the Receiver supports XML-encoded notifications. It was/is an = oversight that it=E2=80=99s not in the draft now. Mahesh and I are = working on an update for that. Back to the "notification-messages=E2=80=9D draft, it also is the case = that there needs to be a URN for Receivers to use to advertise their = support for bundled-messages. The question is if this draft should be = the one to register the =E2=80=9Cbundled-messages=E2=80=9D capability = into the new registry, or if the "notification-messages=E2=80=9D draft = should. We believe that the "notification-messages=E2=80=9D draft should = register it because: 1) In general, the I-D that defines a thing (e.g., a binary-encoding = for notifs) should be the one that registers hooks as needed for the it to be = used. =20 2) That this draft and "notification-messages=E2=80=9D are both WG = docs doesn=E2=80=99t change that, especially given that the "notification-messages=E2=80=9D= draft is expired.=20 3) We feel uncomfortable having a "notification-messages=E2=80=9D = example in this draft knowing that it will likely be wrong (as already a quick = review shows potential problems) 4) We prefer this draft not be held in the MISREF state by RFC Editor. Thusly, we propose to remove the "notification-messages=E2=80=9D = references from the draft, leaving it to that draft to register a = capability (for the Receiver to return to the Publisher) and provide = usage examples. Comments? Kent and Mahesh --Apple-Mail=_18EA960C-6134-48A2-878D-C6AEEECB93DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Reshad, et. al.,

Since draft-ietf-netconf-notification-messages is in parked state, = and expired 8 months ago, should the netconf-https-notif document be = using bundled messages? But I don=E2=80=99t know the reason why it=E2=80=99= s in parked state and whether it=E2=80=99ll be in drive mode = soon.

There=E2=80=99s an open question as to what = extent this draft supports = draft-ietf-netconf-notification-messages.

Section 2 (Learning Receiver Capabilities) = describes how a Publisher can discover what optional capabilities a = Receiver supports.  The section includes an example that shows the = URN =E2=80=9Cbinary-encoding:1.0=E2=80=9D being returned. =  

What=E2=80=99s missing, = however, is the creation of something like an IANA maintained registry = for all of the URNs that can be returned by the Receiver.

This registry would need to, for instance, contain = an initial entry to indicate the Receiver supports XML-encoded = notifications.  It was/is an oversight that it=E2=80=99s not in the = draft now.  Mahesh and I are working on an update for = that.

Back to the = "notification-messages=E2=80=9D draft, it also is the case that there = needs to be a URN for Receivers to use to advertise their support for = bundled-messages.  The question is if this draft should be the one = to register the =E2=80=9Cbundled-messages=E2=80=9D capability into the = new registry, or if the "notification-messages=E2=80=9D = draft should.

We believe that = the "notification-messages=E2=80=9D draft should register it = because:

  1) In general, the = I-D that defines a thing (e.g., a binary-encoding for = notifs)
      should be the one that registers = hooks as needed for the it to be used.  

  2) That this draft and "notification-messages=E2=80=9D = are both WG docs doesn=E2=80=99t
      change that, = especially given that the "notification-messages=E2=80=9D= draft is
      = expired. 

  3) = We feel uncomfortable having a "notification-messages=E2=80=9D example in = this
      draft knowing that it will likely be = wrong (as already a quick review shows
  =     potential problems)

  4) We prefer this draft not be held in the = MISREF state by RFC Editor.


Thusly, we propose to remove the "notification-messages=E2=80=9D references from the draft, leaving it to that draft = to register a capability (for the Receiver to return to = the Publisher) and provide usage = examples.

Comments?

Kent = and Mahesh


= --Apple-Mail=_18EA960C-6134-48A2-878D-C6AEEECB93DD-- From nobody Wed Jan 27 09:01: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 84A6F3A0C8A; Wed, 27 Jan 2021 09:01:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Acee Lindem via Datatracker To: Cc: draft-ietf-netconf-https-notif.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161176691048.5494.2373231790931856179@ietfa.amsl.com> Reply-To: Acee Lindem Date: Wed, 27 Jan 2021 09:01:50 -0800 Archived-At: Subject: [netconf] Yangdoctors last call review of draft-ietf-netconf-https-notif-06 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, 27 Jan 2021 17:01:51 -0000 Reviewer: Acee Lindem Review result: Almost Ready The document is almost ready for WG Last Call. I have the following comments: Model ietf-sub-notif-recv-list: Seems odd to have a model that adds a choice statement without any valid options. I realize you expect other transports in the future but having a separate module the one defined in the same draft seems like a profligate design choice. Model ietf-sub-notif-recv-list: 1. The prefix "hn" seems inconsistent to lose the context. I'd use "snrlhn". This wouldn't be an issue if you combined the modules. 2. This comment is incomprehensible: // create the logical impossibility of enabling "tcp" // transport In the IANA section, the security considerations for the media types point to this draft's security considerations. However, they don't include the referenced information. It seems these IANA references should point to other RFCs. It should be noted that ietf-subscribed-notifications has a number of YANG errors and warnings. I also have the following editorial comments: Acee-Lindems-iMac-2:Desktop acee$ diff -c draft-ietf-netconf-https-notif-06.txt.orig draft-ietf-netconf-https-notif-06.txt *** draft-ietf-netconf-https-notif-06.txt.orig 2021-01-27 10:06:29.000000000 -0500 --- draft-ietf-netconf-https-notif-06.txt 2021-01-27 11:57:13.000000000 -0500 *************** *** 17,23 **** This document defines a YANG data module for configuring HTTPS based configured subscription, as defined in RFC 8639. The use of HTTPS maximizes transport-level interoperability, while allowing for ! encoding selection from text, e.g. XML or JSON, to binary. Status of This Memo --- 17,23 ---- This document defines a YANG data module for configuring HTTPS based configured subscription, as defined in RFC 8639. The use of HTTPS maximizes transport-level interoperability, while allowing for ! encoding selection from text, e.g., XML or JSON, to binary. Status of This Memo *************** *** 103,109 **** documents. This document defines two YANG 1.1 [RFC7950] data modules, one for augmenting the Subscription to YANG Notifications [RFC8639] to add a transport type, and another for configuring and ! managing HTTPS based receivers for the notifications. --- 103,109 ---- documents. This document defines two YANG 1.1 [RFC7950] data modules, one for augmenting the Subscription to YANG Notifications [RFC8639] to add a transport type, and another for configuring and ! managing HTTPS-based receivers for the notifications. *************** *** 118,124 **** the same receiver instance. The second module describes how to enable the transmission of YANG modeled notifications, in the configured encoding (i.e., XML, JSON) over HTTPS. Notifications are ! delivered in the form of a HTTPS POST. The use of HTTPS maximizes transport-level interoperability, while the encoding selection pivots between implementation simplicity (XML, JSON) and throughput (text versus binary). --- 118,124 ---- the same receiver instance. The second module describes how to enable the transmission of YANG modeled notifications, in the configured encoding (i.e., XML, JSON) over HTTPS. Notifications are ! delivered in the form of an HTTPS POST. The use of HTTPS maximizes transport-level interoperability, while the encoding selection pivots between implementation simplicity (XML, JSON) and throughput (text versus binary). *************** *** 196,202 **** In the case of "pipelining", the flow of messages would look something like this. This example shows the flow assuming that ! Subscribed Notifications is used and therefore a notification is sent before sending the first notification. The example would be the same for when Subscribed Notification is not used by removing the first POST message for . --- 196,202 ---- In the case of "pipelining", the flow of messages would look something like this. This example shows the flow assuming that ! Subscribed Notification is used and therefore a notification is sent before sending the first notification. The example would be the same for when Subscribed Notification is not used by removing the first POST message for . *************** *** 342,350 **** 2.1. Introduction ! To learn the capabilities of the receiver, the publisher can issue a HTTPS GET request with Accept-Type set to application/ietf-https- ! notif-cap+xml or application/ietf-https-notif-cap+json, with latter as the mandatory to implement, and the default in case the type is not specified. If the receiver supports capabilities such as binary encoding of data, it can return that as a capability in a response. --- 342,350 ---- 2.1. Introduction ! To learn the capabilities of the receiver, the publisher can issue an HTTPS GET request with Accept-Type set to application/ietf-https- ! notif-cap+xml or application/ietf-https-notif-cap+json, with the latter as the mandatory to implement, and the default in case the type is not specified. If the receiver supports capabilities such as binary encoding of data, it can return that as a capability in a response. *************** *** 450,456 **** Internet-Draft HTTPS Configured Subscription November 2020 ! Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject --- 450,456 ---- Internet-Draft HTTPS Configured Subscription November 2020 ! Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject *************** *** 536,545 **** This YANG module is a definition of a set of receivers that are interested in the notifications published by the publisher. The ! module contains the TCP, TLS and HTTPS parameters that are needed to communicate with the receiver. The module augments the ietf-sub- notif-recv-list module to define a transport specific receiver. As ! mentioned earlier, it uses POST method to deliver the notification. The attribute 'path' defines the path for the resource on the receiver, as defined by 'path-absolute' in URI Generic Syntax [RFC3986]. The user-id used by Network Configuration Access Control --- 536,545 ---- This YANG module is a definition of a set of receivers that are interested in the notifications published by the publisher. The ! module contains the TCP, TLS, and HTTPS parameters that are needed to communicate with the receiver. The module augments the ietf-sub- notif-recv-list module to define a transport specific receiver. As ! mentioned earlier, it uses the POST method to deliver the notification. The attribute 'path' defines the path for the resource on the receiver, as defined by 'path-absolute' in URI Generic Syntax [RFC3986]. The user-id used by Network Configuration Access Control *************** *** 639,645 **** description "YANG module for configuring HTTPS base configuration. ! Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject --- 639,645 ---- description "YANG module for configuring HTTPS base configuration. ! Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject *************** *** 704,710 **** container receiver-identity { description ! "Specifies mechanism for identifying the receiver. The publisher MUST NOT include any content in a notification that the user is not authorized to view."; --- 704,710 ---- container receiver-identity { description ! "Specifies the mechanism for identifying the receiver. The publisher MUST NOT include any content in a notification that the user is not authorized to view."; *************** *** 791,801 **** 6. Receiving Event Notifications ! Encoding notifications for the HTTPS notifications is the same as the encoding notifications as defined in RESTCONF [RFC8040] Section 6.4, with the following changes. Instead of saying that for JSON-encoding purposes, the module name for "notification" element will be "ietf- ! restconf, it will say that for JSON-encoding purposes, the module name for "notification" element will be "ietf-https-notif". With those changes, the SSE event notification encoded JSON example --- 791,801 ---- 6. Receiving Event Notifications ! Encoding notifications for the HTTPS notifications is the same as for encoding notifications as defined in RESTCONF [RFC8040] Section 6.4, with the following changes. Instead of saying that for JSON-encoding purposes, the module name for "notification" element will be "ietf- ! restconf", it will say that for JSON-encoding purposes, the module name for "notification" element will be "ietf-https-notif". With those changes, the SSE event notification encoded JSON example *************** *** 815,826 **** 7. IANA Considerations ! This document registers two URI, two YANG module and two Media Types. 7.1. URI Registration in the IETF XML registry [RFC3688]. Following the format in RFC ! 3688, the following registration is requested to be made: URI: urn:ietf:params:xml:ns:yang:ietf-http-notif URI: urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list --- 815,826 ---- 7. IANA Considerations ! This document registers two URIs, two YANG modules, and two Media Types. 7.1. URI Registration in the IETF XML registry [RFC3688]. Following the format in RFC ! 3688, the following registrations are requested to be made: URI: urn:ietf:params:xml:ns:yang:ietf-http-notif URI: urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list *************** *** 854,860 **** 7.3. Media Types ! 7.3.1. Media Type "application/ietf-https-notif-cap+xml Type name: application --- 854,860 ---- 7.3. Media Types ! 7.3.1. Media Type "application/ietf-https-notif-cap+xml" Type name: application *************** *** 917,923 **** Provisional registration? (standards tree only): no ! 7.3.2. Media Type "application/ietf-https-notif-cap+json Type name: application --- 917,923 ---- Provisional registration? (standards tree only): no ! 7.3.2. Media Type "application/ietf-https-notif-cap+json" Type name: application *************** *** 1106,1112 ****

Hi , Qin,

 

Thanks for bringing up this topic.

You are right, the mechanism defined in our draft aims at solving this= issue.

We proposed a "system" datastore,  and  there are = two system configuration data handling basic modes. One is automatically &nbs= p;loading system into running,

The other is the client explicitly populates running with system confi= guration.

It allows the client to identify how system configuration are processe= d by the server, and also define a new mechanism for client control of serv= er processing of system configuration data.

 

Any suggestions and comments would be greatly appreciated.<= /span>

 

Qiufang Ma

 

 

=B7= =A2=BC=FE=C8=CB: Qin Wu
=B7=A2=CB=CD=CA=B1=BC=E4: 2021=C4=EA1=D4=C213=C8=D5 9:15
=CA=D5=BC=FE=C8=CB: Sterne, Jason (Nokia= - CA/Ottawa) <jason.sterne@nokia.com>; Netconf <netconf@ietf.org&= gt;
=B3=AD=CB=CD: draft-ma-netconf-with-syst= em@ietf.org
=D6=F7=CC=E2: RE: built-in trust anchors=

 

=B7= =A2=BC=FE=C8=CB: netconf [mailto:netconf-bounce= s@ietf.org] =B4=FA=B1=ED Sterne, Jason (Nokia - CA/O= ttawa)
=B7=A2=CB=CD=CA=B1=BC=E4: 2021=C4=EA1=D4=C213=C8=D5 3:02
=CA=D5=BC=FE=C8=CB: Netconf <netconf@ietf.org>
=D6=F7=CC=E2: [netconf] built-in trust a= nchors

 

Hi all,

 

I noticed Jurgen's comment about built-in trust anch= ors in his YANG doctor review of trust-anchors-13. I wanted to pull that ou= t into a dedicated thread/discussion here.

 

Jurgen:

 

- Section 3 talks about populating <running> with built-in trust

  anchors.

 

   In order for the built-in trust anchors to be referenced by

   configuration, the referenced certificates MUST first be copi= ed into

   <running>.  The certificates SHOULD be copied into= <running> using

   the same "key" values, so that the server can bind = them to the built-

   in entries.

 

  Is the idea that this copy operation is an explicit management=

  operation or can implementations populate <running> with this=

  data automatically?

 

I suppose a server *could* populate this in r= unning as part of a built-in startup datastore in the absence of a startup = datastore (i.e. as contents of a RFC8808 factory default). But I assume it = is desirable to be able to delete the running copy of a built-in item. So the system would have to avoid pop= ulating these unless it is loading the factory default.

&nbs= p;

[Qin]:Int= eresting discussion, either loading the factory default from factory datast= ore or define a new system datastore, I think both can enable the server to= populate the data automatically, one of individual draft in NETCONF (draft-ma-netconf-with-system) seems to tar= get to address this issue, i.e., avoid duplicated data items to be created = in the running, I have copied this email to the author of draft-ma-netconf-= with-system for their feedback.

&nbs= p;

But even if the system can populate these, we'd also= want the client/user to be able to explicitly populate them as well (i.e. = in case they delete one from running, and want to add it back in to referen= ce it).

 

[Qin]: Se= e details in draft-ma-netconf-with-system. It helps define consistent behav= ior for system data handling, just like what RFC6243 did.=

&nbs= p;

In either case (system population of running, or cli= ent population of running), do we really need to put the contents of the ba= g or the cert into running?  Or is populating the list key enough sinc= e the operational copy shows what contents are in use for that list entry?

 

Jason

 ! 8.2. Non Subscribed Notification based Configuration In the case that it is desired to use HTTPS notif outside of Subscribed Notifications, there would have to be a module to define --- 1106,1112 ---- ! 8.2. Non-Subscribed Notification based Configuration In the case that it is desired to use HTTPS notif outside of Subscribed Notifications, there would have to be a module to define Thanks, Acee From nobody Wed Jan 27 15:33:02 2021 Return-Path: <01000177463160fb-8dd3e153-dd68-4eba-b370-49aed4d02a87-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 945863A0D60; Wed, 27 Jan 2021 15:33:00 -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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUzV39IHvAwi; Wed, 27 Jan 2021 15:32:59 -0800 (PST) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832B23A0D64; Wed, 27 Jan 2021 15:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1611790377; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=40yNJK1r5WqPRwwAwXrbbDBJ0hRRjym+UlJzylnCe3w=; b=cGTHHuq5tiaj7NxqtHwBAWzEJOX+yroHhTpOE4160TcvnGXyCRr/iDFlV9l1dwZp EfP19lo6weVZWLehNrIFlsTc2BOLLHjclVqZRcThl1pHFQLZyO1bKAqOTwfgpXsG4fl E3CH5SJbnjxybGyD2cRLARa+NSq1hKoGKoZrtg28= From: Kent Watsen Message-ID: <01000177463160fb-8dd3e153-dd68-4eba-b370-49aed4d02a87-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9B6F05B5-F72C-414B-8564-8C142E4E68B1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 27 Jan 2021 23:32:57 +0000 In-Reply-To: <01000176b576c690-7bb22a7a-1fb1-485f-bb06-51f3c08d0fdc-000000@email.amazonses.com> Cc: draft-ietf-netconf-trust-anchors.all@ietf.org, "netconf@ietf.org" , Yoav Nir , secdir@ietf.org To: Benjamin Kaduk References: <160107496501.14047.597283542214697710@ietfa.amsl.com> <01000174e90a9186-0a4edb66-4120-44b7-a79f-7b9935f6d48f-000000@email.amazonses.com> <010001768d05bf5b-eb6d3807-2d23-45c8-a905-dfdaf9fe5bb3-000000@email.amazonses.com> <20201230011701.GO89068@kduck.mit.edu> <01000176b576c690-7bb22a7a-1fb1-485f-bb06-51f3c08d0fdc-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.01.27-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [secdir] [Last-Call] Secdir last call review of draft-ietf-netconf-trust-anchors-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 23:33:01 -0000 --Apple-Mail=_9B6F05B5-F72C-414B-8564-8C142E4E68B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben/Yoav, I forgot to mention before that the draft supports two ways to store = symmetric keys and two ways to store private keys. In general, the two = ways are =E2=80=9Craw=E2=80=9D and =E2=80=9CCMS=E2=80=9D. The good = news, when using CMS, the structure internally includes a field for the = key's usage. So, perhaps the resolution is for the Security = Considerations section to say =E2=80=9CCMS keys are RECOMMENDED=E2=80=A6=E2= =80=9D? Details: 1) for asymmetric keys - the =E2=80=9Craw=E2=80=9D value is an RSAPrivateKey, = ECPrivateKey, etc. - the =E2=80=9Ccms=E2=80=9D value is an OneAsymmetricKey (from RFC = 5958) - the OneAsymmetricKey structure includes a field called = =E2=80=9Cattributes=E2=80=9D - the =E2=80=9Cattributes=E2=80=9D field is of type = OneAsymmetricKeyAttributes - attribute values van come from, e.g., RFC 7906 2) for symmetric keys - the =E2=80=9Craw=E2=80=9D value is an octet string - the =E2=80=9Ccms=E2=80=9D value is an OneSymmetricKey (from RFC = 6031) - the OneSymmetricKey structure includes a field called = =E2=80=9CsKeyAttrs=E2=80=9D - the sKeyAttrs field is of type Attributes - SKeyAttributes include "at-pskc-keyUsage" Kent > On Dec 30, 2020, at 4:03 PM, Kent Watsen wrote: >=20 > Hi Ben, >=20 >> This doesn't really fill me with joy. In short, constraints are = going to >> have to be applied at *some* level, even if it's not this one, or the >> system as a whole is likely to have some very surprising security >> properties. I recognize that coming up with a new language to = describe >> this sort of constraints is neither fun nor easy (and trying to = repurpose >> an existing language, such as that used by X.509, is not without = issues >> either), but I'd hope we could come up with something to say about = how to >> effectively use constraints on raw public keys. >=20 > You say constraints have to be applied at some level, but is this true = when TLS uses a raw key? Likewise for SSH keys (e.g., ~/.ssh/id_rsa)? >=20 > I=E2=80=99m extremely hesitant to make this change. Already this work = (9 drafts in total) has been in progress for more than 5 years. Will = you object during the IETF Last Call if it=E2=80=99s not added? >=20 > One thing not mentioned before, is that, while the keys are = unconstrained in the three base drafts (crypto-types, keystore, and = truststore), the =E2=80=9Ctis-client-server=E2=80=9D and = =E2=80=9Cssh-client-server=E2=80=9D drafts refine the base YANG models = to assert that the raw public key must be a SubjectPublicInfo structure = or an SSH public key, respectively. In fairness, this only constrains = the format of the data, not how the keys are used. That said, this = approach works with OpenSSH and OpenSSL keys, apparently indicating that = specifying the raw key=E2=80=99s use isn=E2=80=99t always necessary... >=20 >=20 >>=20 >> Thanks, >>=20 >> Ben >=20 >=20 > Kent >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_9B6F05B5-F72C-414B-8564-8C142E4E68B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ben/Yoav,

I forgot = to mention before that the draft supports two ways to store symmetric = keys and two ways to store private keys.  In general, the two ways = are =E2=80=9Craw=E2=80=9D and =E2=80=9CCMS=E2=80=9D.  The good = news, when using CMS, the structure internally includes a field for the = key's usage.  So, perhaps the resolution is for the Security = Considerations section to say =E2=80=9CCMS keys are = RECOMMENDED=E2=80=A6=E2=80=9D?

Details:

1) = for asymmetric keys
      - the =E2=80=9Craw= =E2=80=9D value is an RSAPrivateKey, ECPrivateKey, etc.
  =     - the =E2=80=9Ccms=E2=80=9D value is an OneAsymmetricKey = (from RFC 5958)
      - the OneAsymmetricKey structure includes a field = called =E2=80=9Cattributes=E2=80=9D
      - = the =E2=80=9Cattributes=E2=80=9D field is of = type OneAsymmetricKeyAttributes
    =   - attribute values van come from, e.g., RFC 7906

2) for symmetric keys
  =     - the =E2=80=9Craw=E2=80=9D value is an octet = string
      - the =E2=80=9Ccms=E2=80=9D value = is an OneSymmetricKey (from RFC 6031)
      - = the OneSymmetricKey structure includes a field = called =E2=80=9CsKeyAttrs=E2=80=9D
      - the sKeyAttrs field is of = type Attributes
      - SKeyAttributes include = "at-pskc-keyUsage"

Kent



On Dec 30, 2020, at 4:03 PM, Kent Watsen = <kent+ietf@watsen.net> wrote:

Hi Ben,

This doesn't = really fill me with joy.  In short, constraints are going to
have to be applied at *some* level, even if it's not this = one, or the
system as a whole is likely to have some very = surprising security
properties.  I recognize that = coming up with a new language to describe
this sort of = constraints is neither fun nor easy (and trying to repurpose
an existing language, such as that used by X.509, is not = without issues
either), but I'd hope we could come up with = something to say about how to
effectively use constraints = on raw public keys.

You say constraints have = to be applied at some level, but is this true when TLS uses a raw key? =  Likewise for SSH keys (e.g., ~/.ssh/id_rsa)?

I=E2=80=99m extremely = hesitant to make this change.  Already this work (9 drafts in = total) has been in progress for more than 5 years.  Will you object = during the IETF Last Call if it=E2=80=99s not added?

One thing not = mentioned before, is that, while the keys are unconstrained in the three = base drafts (crypto-types, keystore, and truststore), the = =E2=80=9Ctis-client-server=E2=80=9D and =E2=80=9Cssh-client-server=E2=80=9D= drafts refine the base YANG models to assert that the raw public key = must be a SubjectPublicInfo structure or an SSH public key, = respectively.  In fairness, this only constrains the format of the = data, not how the keys are used.   That said, this approach works = with OpenSSH and OpenSSL keys, apparently indicating that specifying the = raw key=E2=80=99s use isn=E2=80=99t always necessary...



Thanks,

Ben


Kent


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

= --Apple-Mail=_9B6F05B5-F72C-414B-8564-8C142E4E68B1-- From nobody Fri Jan 29 02:34:59 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 ACF873A0A2E for ; Fri, 29 Jan 2021 02:34:56 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 0fOPx5VE2bjz for ; Fri, 29 Jan 2021 02:34:54 -0800 (PST) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 0F8E33A0A2C for ; Fri, 29 Jan 2021 02:34:54 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id s24so5574021pjp.5 for ; Fri, 29 Jan 2021 02:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Ff67dPbedsY3xy90TFx93zN0wD+dkAzhiwodawaKFvo=; b=EVmZKb077L2eSNplWTQ5xzzJsOVdVzaxejhQ/rO8l1T3QveW4uOgt58+dx7ro/IgTG hYZZ49AokgOcE/+/JcyYjDFPTUhmOUmuo4mCGJI2p6pT8KlDBlX0DoOUsDtIIZlUyLXO LkPO/21v6zPyJBf1PbqGM9Uu2RZNKJw4dkQYwZhp1EAI776dBy5QjugK55HppjF59deI 9JIEnoL+jxACnRNL3awl+OoKSON47iFrQu5ffLD4ppRgstOa4M4Ujyn3vHp4aXmoCi7f FxaJRKykUUuqltJmwVRfvYTTsmxSh23EoRWmYWEksw5m4NWa5XDn1c3j3DBUZoUIIS6F ZsrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ff67dPbedsY3xy90TFx93zN0wD+dkAzhiwodawaKFvo=; b=B5RQU++BGg6awRDGdp0Du1pqdNBGwF+xk0smBuGm5abM0zAaKhyU2LWVegTScbNn1K +aZhdVMyWnLrHQ348e5G3S4s+Tcgl1JQIi0FrHKPK8WeRetvtCWOZzLE9frQ9lc8cCSz e58zKytKq40QwfxPKmenVMreG/epCtYIFqZAVmr6NzEXrhGQJLn0OnYP6A3rNi1x1sU6 5s5GWQvLHtkzZqy6OeEbmxsvnccZ3pOPT06i8EZzAr+pBA17twSqkMKVDgMwbhq+mus5 BiMorWkw8D7rjtAdjLRG95me+GklPYA6D4zPvmkhbqRVPSYqqNmLLbcR05mS5uJkOl2N 16Xw== X-Gm-Message-State: AOAM533Crwo4xzlYaYWpxNwoIIpePeOTXOwt0um69H0VVEeU7ATZOYcI JTsbzphYMrmNnurXP2XSpuCn8POEAYq6ysbL7eRtNc+hDvA= X-Google-Smtp-Source: ABdhPJyH+ONBqnFs4CnNuRwenobelL9t3MN3aWHZErql/HZST78509rmODu7h6bAkdwkuSzOdAisrJ7TfSFb2sUKOio= X-Received: by 2002:a17:902:b597:b029:e1:54c:634c with SMTP id a23-20020a170902b597b02900e1054c634cmr3529826pls.5.1611916493315; Fri, 29 Jan 2021 02:34:53 -0800 (PST) MIME-Version: 1.0 From: Roman Dodin Date: Fri, 29 Jan 2021 11:34:27 +0100 Message-ID: To: netconf@ietf.org Content-Type: multipart/alternative; boundary="000000000000fde43905ba078d20" Archived-At: Subject: [netconf] creating multiple list entries within a single YANG-PATCH edit-id? X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 29 Jan 2021 10:34:57 -0000 --000000000000fde43905ba078d20 Content-Type: text/plain; charset="UTF-8" Hello all, is it possible in a YANG-PATCH body to target an entire list with a goal to create multiple list-entries in a single edit-id? Or should rather the target be a specific list entry and not the whole list? Best regards, Roman --000000000000fde43905ba078d20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,
is it possible in a YANG-PATCH body to target an entire list with a= goal to create multiple list-entries in a single edit-id?
Or should rather the target be a specific list entry and not= the whole list?

Best regards,
Roman
--000000000000fde43905ba078d20-- From nobody Fri Jan 29 10:20:05 2021 Return-Path: <010001774f5f7df0-89830501-6d1a-465b-a172-dd95e98e8a3e-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 D3B813A11F8 for ; Fri, 29 Jan 2021 10:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPCodTOAgwFy for ; Fri, 29 Jan 2021 10:19:56 -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 79C4C3A11F0 for ; Fri, 29 Jan 2021 10:19:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1611944394; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=Ja7xbD023Wjbsje6FfgWY9RXK9+BrboB37ZRnCJ5RpA=; b=GNtrxtWDqWM4rveKjTBlLKWrIbMTk6geh1caMbxdbTqSo6j+kZeZNSiM41Z17qHI aCM4M7u9Os0nZfJfigs+VKHmb0CHL1Dj9xcX3d3jnUZQZDpxhrgtz1Qo0gDMneQe5IQ RHKfYEokQTI0ZHZxBbkOUEQKG14Mmh1zNSVPa22I= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_AEF8B755-B1CA-481C-B512-D0C42A4DB39D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <010001774f5f7df0-89830501-6d1a-465b-a172-dd95e98e8a3e-000000@email.amazonses.com> Date: Fri, 29 Jan 2021 18:19:54 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.01.29-54.240.48.93 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] base64encodedvalue== is an invalid base64 value X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 18:19:58 -0000 --Apple-Mail=_AEF8B755-B1CA-481C-B512-D0C42A4DB39D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m unsure if this issue warrants a fix, but be aware that using = "base64encodedvalue=3D=3D=E2=80=9C in code doesn't roundtrip correctly: $ echo "base64encodedvalue=3D=3D" | base64 -d | base64 base64encodedvaluQ=3D=3D Specifically, there is no binary input that results in =E2=80=9Cue=3D=3D=E2= =80=9C. $ echo "ue=3D=3D" | base64 -d | base64 uQ=3D=3D The reason is a more detailed than this message warrants, but = effectively, the second sextet is quantized and, worse, none of three = different implementations I tested against raise a warning, much less an = error...which is reasonable, IMO. Options: 1) stick with "base64encodedvalue=3D=3D=E2=80=9C for the examples. 2) use a different value that is a valid base64 string. Thoughts? With regards to option #1: - still seems okay, as the value never occurs in practice With regards to option #2: - if it is desired to end with =E2=80=9C=3D=3D=E2=80=9C: - the last character must be one of [A, Q, g, w] - options: b64tag=3D=3D, BASE64DATA=3D=3D - if it is desired to end with =E2=80=9C=3D=E2=80=9C: - the last character must be one of [A, E, I, M, Q, U, Y, c, g, k, = o, s, w, 0, 4, 8] - options: BASE64VALUE=3D - if it is desisired to end with no padding: - any alphanumeric string with length%4=3D=3D0 works - options: base64encodedval, anybase64val, b64value, base64string K. --Apple-Mail=_AEF8B755-B1CA-481C-B512-D0C42A4DB39D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I=E2=80=99m unsure if = this issue warrants a fix, but be aware that using "base64encodedvalue=3D=3D=E2=80=9C in code doesn't roundtrip = correctly:

$ echo "base64encodedvalue=3D=3D" | base64 -d | base64
base64encodedvaluQ=3D=3D

Specifically, there is no binary input = that results in =E2=80=9Cue=3D=3D=E2=80=9C.

$ echo "ue=3D=3D" | base64 -d | base64
uQ=3D=3D

The = reason is a more detailed than this message warrants, but effectively, = the second sextet is quantized and, worse, none of three different = implementations I tested against raise a warning, much less an = error...which is reasonable, IMO.

Options:

1) stick with "base64encodedvalue=3D=3D=E2=80=9C for the = examples.
2) use = a different value that is a valid base64 string.

Thoughts?


With regards to option = #1:
  = - still seems okay, as the value never occurs = in practice


With regards to option #2:

  - if it is desired = to end with =E2=80=9C=3D=3D=E2=80=9C:
      - the = last character must be one of [A, Q, g, w]
      - = options: b64tag=3D=3D, BASE64DATA=3D=3D

  - if it is desired to end = with =E2=80=9C=3D=E2=80=9C:
      - the last = character must be one of [A, E, I, M, Q, U, Y, c, g, k, o, s, w, 0, 4, 8]
    =   - options: BASE64VALUE=3D

  - if = it is desisired to end with no padding:
      - any = alphanumeric string with length%4=3D=3D0 works
    =   - options: base64encodedval, anybase64val, b64value, base64= string


K.





= --Apple-Mail=_AEF8B755-B1CA-481C-B512-D0C42A4DB39D-- From nobody Fri Jan 29 11:11:50 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 930DF3A123D for ; Fri, 29 Jan 2021 11:11:48 -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, MSGID_FROM_MTA_HEADER=0.001, 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=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xrrqp6BCNzM for ; Fri, 29 Jan 2021 11:11:46 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150079.outbound.protection.outlook.com [40.107.15.79]) (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 3288A3A112A for ; Fri, 29 Jan 2021 11:11:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=csBKNCfN1tZ7Z6/5JuKsmuLSpue/u99+YBbM8u/VMa6gyrIQ6Rdj7mQHlF37saXHQSkNB4XrVqkfJV5zRX9qRylmxzS7bYgi1a9oX0Eov6BlAIXVAR91eEyxqGEPvzMKoWmiKLyXG0uPR9hHKkSE5ewjOw7lzECQtX5AaAl1J74W3cCBSn/cSJtvL5UJTboLhsc5kNNsem9MEszat8waPnxjHuJSX6I93cONycHijItLBtChVhlAIgRO7LNa3J5OHdKYmVnSUu46TLNYHl87EoEtBaVlA67VPyEM8RjXpc/Y43Zz8tx0DL90qnbrPx3zYNuP99dnstsyqu8WiTIZ7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oQPxa4luraVkp6U/06PO1AZRuGnVd/v8no+pK/719pY=; b=GZrAucDqa7BXcePmbVECEKa/si+HXBlywEyujJ0E3z5sVY+UQ0yh+vZP5rxUU0Bv93qGZlyyO7D1Qk+ROYDroClCsB6Rrv9u2FcsxnKx8Ge7RR7Fe1ZB+NyZePoaGHJaR+11I+QrbMg6YJIeVmrAH2nwxem3EkkbCQjwP9fPm4KxQwTtPghaFVxT44Ti5vkHQ9irFfFuglzzo3l6s58s/E4Iwir7YQpiBqSzzHrtpu/DmWXHWRLVwIJjZPYVLMQeIuJ9y3qJtx9cNx8KMjdKfTgrgdPZi70pMeNHtlUoy2iQRUEriHnGd2A/ZM6JYxV3jJE9Zn4JL+3SyS/G6e4XCA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oQPxa4luraVkp6U/06PO1AZRuGnVd/v8no+pK/719pY=; b=bzd+cZqMFPDOphThsHLnWFYRGzNBAUvlfmHhCBWIFOX8hVipqWMLhCZdhJbPF/i/bm6SDiXx3oAwymoun9knB43my8hWwUhhmQgyUCOnIVElc0riSPPA+xDC0Ue9DSn6meybWgrc/stCYiSROki4VEbNdTf4WAJ5GFWctWqCDjw= Authentication-Results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM8P190MB0820.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1c5::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.13; Fri, 29 Jan 2021 19:11:43 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::1ce1:49e3:3e54:804d]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::1ce1:49e3:3e54:804d%4]) with mapi id 15.20.3805.019; Fri, 29 Jan 2021 19:11:43 +0000 Date: Fri, 29 Jan 2021 20:11:42 +0100 From: Juergen Schoenwaelder To: Kent Watsen Cc: "netconf@ietf.org" Message-ID: <20210129191142.lxhtegbkgan37oyj@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <010001774f5f7df0-89830501-6d1a-465b-a172-dd95e98e8a3e-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <010001774f5f7df0-89830501-6d1a-465b-a172-dd95e98e8a3e-000000@email.amazonses.com> X-Originating-IP: [212.201.44.247] X-ClientProxiedBy: AM0P190CA0003.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::13) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.247) by AM0P190CA0003.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.16 via Frontend Transport; Fri, 29 Jan 2021 19:11:42 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b7f3b810-8b6f-4514-d894-08d8c489b6b9 X-MS-TrafficTypeDiagnostic: AM8P190MB0820: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ib7jSKSdKxfSRoaGcOWSPhB4ohod7mhHYiFvbeyPcs0s37kMxdcNfCjIk/lWY4ElNGthcOeWfHdISb/ReAW59/jwXl8WE+JmOMxSQacDzhTRCz7FzSDn/MvLr9/H+k4Li1YXSu+pAD66IdgNeLuUvEf9Bhp8Uab2ChQ9Z4ftE41nHWcT9lbpbY9kPoZiCvWHyJJkC0R3HZ1CqZ96Qmab6lta6bpSIa94DTq+PWv4DchWZWNsZKED05crDUbsih5/Ljr1ap7XjfOtCSGiHRtLgGBTKdKClyICD7arOxQeSQnDVdXtEUdLHNWteHnS4viE/52/6yb1rvhNJapfTYmS8O6e7CnRy4mI6h2A16fmxZkYx+5Cj4/Ht3O7gfpYGKDUO7W0MzzKzjpOj243u6eglK3LP8P6HA1qmegqWENWwL0CF3VLSJLvKjwui/96VJ5TyGtdZ79Cw6+rSbGNICBDFkw7afpJnBkpbgZMACL14xinj5PkR1A+AuAJlf3i/hCMcaPZB+SoFwIBd4575yQAfE13G/xEKWj/aZLKmgZYeTdlDSKGN613S1lOZyjWx4lGLqvNseLNXcZPJVLFel0lbIxqyzx1L4JCUdaStPDe1+LxuzOrDTdyA1lANhRd0ZZjxrH3xt4dPDPrqX+yGost4A== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(39850400004)(396003)(346002)(136003)(366004)(83080400002)(966005)(3450700001)(2906002)(5660300002)(8936002)(186003)(66946007)(956004)(6496006)(8676002)(52116002)(16526019)(4326008)(66476007)(66556008)(86362001)(478600001)(786003)(26005)(1076003)(316002)(83380400001)(6486002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?RjArUWtCWUZBMHl2bWpJRms1TW43NGFTTWgwYWl2VTkrKzhJaldmajl6eWRW?= =?utf-8?B?SDdMQTZTNC9Td0lTUHdsRzNSSDZheGdOdlRqdDFPeEtZUWozbU5hbjZSZi9W?= =?utf-8?B?Q2JjRCsxeThCbjdrNDZxMmUyRlJDa0pyTmFRQnM4SUp3NDBHOThucVdpVUgy?= =?utf-8?B?WXNKSlRTdUxjVE1YZW9SS0txbjc0YWh5Y2ZvSWRtbk1RNUxVWUs0MjJNVzFy?= =?utf-8?B?aE5NK3hzaUExUjRGTVVnV0xnSHQzV0Z6Z3NubkVCbW9hTjMxa21QOHZEd0p2?= =?utf-8?B?b1BEYVYxWStTZmdENlh4bkFkVU1wdUZtWEwzS2hVbXJESFI5bGdYQk9lQmpr?= =?utf-8?B?YkN3TWZiTXJJalpyN1lzakk1bE9kVFBSL0hsRVk4ZWM1WTVSVTMxVEU3Rnh4?= =?utf-8?B?TnBEeVZXMjNxMmdMNGZCcVpKcER4Y24yeE1MQWZWaitXcmJoeE1ic1FTd1Jw?= =?utf-8?B?NUlCK0h4amJLWWxrNXhPQ1c5QTBGUCtXQXBpaFVRU1d3UlhGWGVnM3N3N2d5?= =?utf-8?B?ZW1CZHdMQk9DZHRJUmpVQVloa1EyNnFJZTYyVEt5SzhpOFlVOUJrOWJFY2U5?= =?utf-8?B?ekYxaTNqeEdxWG03M2pmalVGcVdQdE0zbVF3WFdaRW9aU0JqZnRraUh0RURI?= =?utf-8?B?NldZa2NoREVlOEhkM3FLZ0JHMXVmOHJSVGtOanpYY0FWMXA2NkRGbTU5bzI4?= =?utf-8?B?dmdDcHhhejZLYTBRN2hubnNtU0RqUkJwWTNCR3V0UlIvd3lhY2h0cFFVcWRl?= =?utf-8?B?VTBDQW53Mk9sRzNobVg0MitvWGdoWUZ2WDZ3Q0hMajdvQTYxZFlvS0cySm8y?= =?utf-8?B?OHZpLzBYcFF1cUhzMHJ2UWg0K1o1WUs2TXM2RHdkWmVrN2VDblFtSktrditB?= =?utf-8?B?VGJXQkxXZ3N4YjVVUDNCK2tOZDdNMWs3VkJqQThUVW1TMG8rTERqdnpKUzVt?= =?utf-8?B?TTlUd3A5T29HdEdCKzVMeWpLTXVlN0pxMGNYK2FERk4xZ1Q5SS9WdXpxRktQ?= =?utf-8?B?Q1dlUCtsNGlHZU9acW1NRk12N1B4WllITkRSWWEyTHR5RDFyMWcvbFV4UHB1?= =?utf-8?B?d1RjbXZuSmlCMHF2ZHNmRWhGZmQyclpESllUK2gyWmEvY1A4WXU3ZksrSllZ?= =?utf-8?B?bHoyN2FIWHpSRlM5bWNZOTFrRGl5NDBBK1FTcW1Ib2JQRkp3UUx5S3YwZTA0?= =?utf-8?B?dy92SlBWeHhYM0ZWWC9rLyt3SEFLQzJLZU81ZFZwUFFxa21QU0x4ZGRvSXVQ?= =?utf-8?B?TktndWh4dGJVSmtuNDNtemg4LzVwZ0k3STJLZjdHK1YxWDBPTklmMkdqc1BU?= =?utf-8?B?Nngwb2IySUdCWjhNUm1LeVlmZjhWSGwzZzNZaXpXQnc5ckp2M0cyQzc0RGR0?= =?utf-8?B?dEpseE1VWTBZNmIzTEtHWmdneDJERnJsSXB6d1FTNVhLQ3dncFFxSjBwQW9m?= =?utf-8?Q?VBliGFgv?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: b7f3b810-8b6f-4514-d894-08d8c489b6b9 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2021 19:11:42.9764 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: C/UuhuEMTD4OIj6hX7M3UPKT5FTP06Q7jiX2orS+LUr2YaoAd5pfo5eqOe24V6BlTRVPLAkR8V404oFp3r4nFM+DYPEu3O/6hDXkghgWCtU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P190MB0820 Archived-At: Subject: Re: [netconf] base64encodedvalue== is an invalid base64 value X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 19:11:49 -0000 Who cares whether this value roundtrips in an examples?? /js On Fri, Jan 29, 2021 at 06:19:54PM +0000, Kent Watsen wrote: > > I’m unsure if this issue warrants a fix, but be aware that using "base64encodedvalue==“ in code doesn't roundtrip correctly: > > $ echo "base64encodedvalue==" | base64 -d | base64 > base64encodedvaluQ== > > Specifically, there is no binary input that results in “ue==“. > > $ echo "ue==" | base64 -d | base64 > uQ== > > The reason is a more detailed than this message warrants, but effectively, the second sextet is quantized and, worse, none of three different implementations I tested against raise a warning, much less an error...which is reasonable, IMO. > > Options: > > 1) stick with "base64encodedvalue==“ for the examples. > 2) use a different value that is a valid base64 string. > > Thoughts? > > > With regards to option #1: > - still seems okay, as the value never occurs in practice > > > With regards to option #2: > > - if it is desired to end with “==“: > - the last character must be one of [A, Q, g, w] > - options: b64tag==, BASE64DATA== > > - if it is desired to end with “=“: > - the last character must be one of [A, E, I, M, Q, U, Y, c, g, k, o, s, w, 0, 4, 8] > - options: BASE64VALUE= > > - if it is desisired to end with no padding: > - any alphanumeric string with length%4==0 works > - options: base64encodedval, anybase64val, b64value, base64string > > > K. > > > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jan 29 12:05:13 2021 Return-Path: <010001774fbfd0f5-ffebda16-f672-4f31-8b3d-4dd0c404e12e-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 56FBC3A1290 for ; Fri, 29 Jan 2021 12:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv_M8lm9I1Nq for ; Fri, 29 Jan 2021 12:05:08 -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 537453A125E for ; Fri, 29 Jan 2021 12:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1611950707; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=t7+U+pBvBpsKOlVetTnixMiOBlXf9+VCgys4OL5MACE=; b=VZa0N+VcYYyfs3NJmMv8GdRnDxd3mHAnBUDzVHckj16MH3/usGfhD8G4rgu1YhWy WG53c2cUPdGcIb+frbjA3kNpeecHjhqGgvmiOWVubkCjsZmOaszcY8x04c6fmmo2fZb RNB8tlw8zjylz1+MdvpzUjkJgMejFRvgLpVQiuhE= From: Kent Watsen Message-ID: <010001774fbfd0f5-ffebda16-f672-4f31-8b3d-4dd0c404e12e-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_71EF96D3-EEC1-400A-9BE4-C7A98C8A64EB" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 29 Jan 2021 20:05:06 +0000 In-Reply-To: <20210129191142.lxhtegbkgan37oyj@anna.jacobs.jacobs-university.de> Cc: "netconf@ietf.org" To: Juergen Schoenwaelder References: <010001774f5f7df0-89830501-6d1a-465b-a172-dd95e98e8a3e-000000@email.amazonses.com> <20210129191142.lxhtegbkgan37oyj@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.01.29-54.240.48.93 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] base64encodedvalue== is an invalid base64 value X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 20:05:11 -0000 --Apple-Mail=_71EF96D3-EEC1-400A-9BE4-C7A98C8A64EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Who cares whether this value roundtrips in examples?? That is why I asked ;) It may matter to implementers of a client or a server writing unit tests = that don=E2=80=99t require valid base64 values, other than that = they=E2=80=99ll roundtrip correctly. If they assume this value will = work, they=E2=80=99re in for a surprise. I don=E2=80=99t care anymore, = as I=E2=80=99ve adjusted all my test cases already. K. --Apple-Mail=_71EF96D3-EEC1-400A-9BE4-C7A98C8A64EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


Who cares = whether this value roundtrips in examples??

That is = why I asked  ;)

It may matter = to implementers of a client or a server writing unit tests that don=E2=80=99t require valid base64 = values, other than that they=E2=80=99ll roundtrip correctly.  If = they assume this value will work, they=E2=80=99re in for a surprise. =  I don=E2=80=99t care anymore, as I=E2=80=99ve adjusted all my test = cases already.

K.


= --Apple-Mail=_71EF96D3-EEC1-400A-9BE4-C7A98C8A64EB-- From nobody Fri Jan 29 14:15:42 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 613F63A132D for ; Fri, 29 Jan 2021 14:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOzgb_pNquMe for ; Fri, 29 Jan 2021 14:15:38 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3DB3A1324 for ; Fri, 29 Jan 2021 14:15:37 -0800 (PST) Received: from [192.168.217.152] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DSBVV4r4qzyXv; Fri, 29 Jan 2021 23:15:29 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Carsten Bormann In-Reply-To: <20210129191142.lxhtegbkgan37oyj@anna.jacobs.jacobs-university.de> Date: Fri, 29 Jan 2021 23:15:17 +0100 Cc: Kent Watsen , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6A06C21C-70F1-40D7-A690-B2AC94BC9CB3@tzi.org> References: <010001774f5f7df0-89830501-6d1a-465b-a172-dd95e98e8a3e-000000@email.amazonses.com> <20210129191142.lxhtegbkgan37oyj@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [netconf] base64encodedvalue== is an invalid base64 value X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 22:15:40 -0000 On 29. Jan 2021, at 20:11, Juergen Schoenwaelder = wrote: >=20 > Who cares whether this value roundtrips in an examples?? I=E2=80=99d expect at least some decent implementations will check for = RFC 4648=E2=80=99s mandate "These pad bits MUST be set to zero by conforming encoders=E2=80=9D, just like some check for the = right number of equals signs. Examples that fail in decent implementations are suboptimal. (They might even be used in arguments to claim that this decency needs = to be removed.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jan 29 15:26:48 2021 Return-Path: <0100017750786b5f-6f9004c8-d56f-4f67-802b-09154dce9f3c-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 72EA83A1388 for ; Fri, 29 Jan 2021 15:26:47 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsVevdf4eLZI for ; Fri, 29 Jan 2021 15:26:46 -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 6560D3A1387 for ; Fri, 29 Jan 2021 15:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1611962805; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=gzQnBeTKDiPEOJ+F47OMhyn0xLVE+OBlnkItAnhw+Og=; b=D/1kzMTI1fklmNiJr0Ir1A4txjIIz5jPFwrImG1KYrTMNFyen3XVySmRsgUbWQha KiFUkTc5rl4QXTsILw9T+JZK9kePkLWBdVSD9dPSSO1BfTgFz6EoHxoK5CKLhNQ3LNB 4rieC/Lh3MZ/L1BHmBLy7rRePsx1xokBk87QzOx0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <6A06C21C-70F1-40D7-A690-B2AC94BC9CB3@tzi.org> Date: Fri, 29 Jan 2021 23:26:45 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017750786b5f-6f9004c8-d56f-4f67-802b-09154dce9f3c-000000@email.amazonses.com> References: <010001774f5f7df0-89830501-6d1a-465b-a172-dd95e98e8a3e-000000@email.amazonses.com> <20210129191142.lxhtegbkgan37oyj@anna.jacobs.jacobs-university.de> <6A06C21C-70F1-40D7-A690-B2AC94BC9CB3@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.01.29-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] base64encodedvalue== is an invalid base64 value X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 23:26:47 -0000 >> Who cares whether this value roundtrips in an examples?? >=20 > I=E2=80=99d expect at least some decent implementations will check for = RFC 4648=E2=80=99s mandate "These pad bits MUST be set to > zero by conforming encoders=E2=80=9D, just like some check for the = right number of equals signs. > Examples that fail in decent implementations are suboptimal. > (They might even be used in arguments to claim that this decency needs = to be removed.) `base64` doesn=E2=80=99t produce a warning: $ echo "base64encodedvalue=3D=3D" | base64 -d | base64 base64encodedvaluQ=3D=3D `openssl` doesn=E2=80=99t produce a warning: $ echo "base64encodedvalue=3D=3D" | openssl enc -d -base64 -A | = openssl enc -base64 -A base64encodedvaluQ=3D=3D Python doesn=E2=80=99t produce a warning: $ printf "import = binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('base64encodedvalu= e=3D=3D'), newline=3DFalse).decode('ascii'))" | python - base64encodedvaluQ=3D=3D From nobody Fri Jan 29 17:48:09 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 3FE193A1485 for ; Fri, 29 Jan 2021 17:48:07 -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, HTML_MESSAGE=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 MB6fmEKHy2ah for ; Fri, 29 Jan 2021 17:48:03 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301983A1484 for ; Fri, 29 Jan 2021 17:48:02 -0800 (PST) Received: from [192.168.217.152] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DSHCh36z2zyfX; Sat, 30 Jan 2021 02:48:00 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_359AE3E3-93E5-4869-B1F5-DB95972534BF" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Carsten Bormann In-Reply-To: <0100017750786b5f-6f9004c8-d56f-4f67-802b-09154dce9f3c-000000@email.amazonses.com> Date: Sat, 30 Jan 2021 02:47:59 +0100 Cc: "netconf@ietf.org" Message-Id: References: <010001774f5f7df0-89830501-6d1a-465b-a172-dd95e98e8a3e-000000@email.amazonses.com> <20210129191142.lxhtegbkgan37oyj@anna.jacobs.jacobs-university.de> <6A06C21C-70F1-40D7-A690-B2AC94BC9CB3@tzi.org> <0100017750786b5f-6f9004c8-d56f-4f67-802b-09154dce9f3c-000000@email.amazonses.com> To: Kent Watsen X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [netconf] base64encodedvalue== is an invalid base64 value X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2021 01:48:07 -0000 --Apple-Mail=_359AE3E3-93E5-4869-B1F5-DB95972534BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 30. Jan 2021, at 00:26, Kent Watsen wrote: >=20 >=20 >>> Who cares whether this value roundtrips in an examples?? >>=20 >> I=E2=80=99d expect at least some decent implementations will check = for RFC 4648=E2=80=99s mandate "These pad bits MUST be set to >> zero by conforming encoders=E2=80=9D, just like some check for the = right number of equals signs. >> Examples that fail in decent implementations are suboptimal. >> (They might even be used in arguments to claim that this decency = needs to be removed.) >=20 >=20 >=20 > `base64` doesn=E2=80=99t produce a warning: >=20 > $ echo "base64encodedvalue=3D=3D" | base64 -d | base64 > base64encodedvaluQ=3D=3D >=20 >=20 >=20 > `openssl` doesn=E2=80=99t produce a warning: >=20 > $ echo "base64encodedvalue=3D=3D" | openssl enc -d -base64 -A | = openssl enc -base64 -A > base64encodedvaluQ=3D=3D >=20 >=20 >=20 > Python doesn=E2=80=99t produce a warning: >=20 > $ printf "import = binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('base64encodedvalu= e=3D=3D'), newline=3DFalse).decode('ascii'))" | python - > base64encodedvaluQ=3D=3D Thanks for the data points; adding 1=C2=BD more: $ ruby -rbase64 -e 'puts = Base64.encode64(Base64.decode64("base64encodedvalue=3D=3D"))'=20 base64encodedvaluQ=3D=3D $ ruby -rbase64 -e 'puts = Base64.strict_encode64(Base64.strict_decode64("base64encodedvalue=3D=3D"))= ' :281:in `unpack1': invalid base64 (ArgumentError) from = /opt/homebrew/Cellar/ruby/3.0.0_1/lib/ruby/3.0.0/base64.rb:74:in = `strict_decode64' from -e:1:in `
' Checking conformance is a MAY(*) for a decoder, so I=E2=80=99m not = surprised that many don=E2=80=99t do that. (Or check only on specific request, as in Ruby.) I would strongly expect any decoder that is used in a security context = to actually check, so I *am* surprised by the openssl example above. (Well, not that much surprised; it is, well, openssl.) I wouldn=E2=80=99t have reacted to this thread if I hadn=E2=80=99t years = ago, when writing a random test case generator, been surprised by a = base64 implementation that did check. I don=E2=80=99t recollect the details of that, though=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten (*) https://tools.ietf.org/html/rfc4648#section-3.5 = For those not familiar with RFC 2119 interoperability keywords: MAY means that an implementation is free to do so. Which raises the interoperability requirement that any peer = implementation MUST be able to interoperate with an implementation that = does. This would be unnecessary to state in this case because that MUST is in = the paragraph before. So the intent here apparently was stressing the optionality of checking = in a decoder. --Apple-Mail=_359AE3E3-93E5-4869-B1F5-DB95972534BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 30. Jan 2021, at 00:26, Kent Watsen <kent+ietf@watsen.net> wrote:


Who cares whether this value roundtrips in an examples??

I=E2=80=99d expect at least some = decent implementations will check for RFC 4648=E2=80=99s mandate "These = pad bits MUST be set to
 zero by conforming = encoders=E2=80=9D, just like some check for the right number of equals = signs.
Examples that fail in decent implementations are = suboptimal.
(They might even be used in arguments to claim = that this decency needs to be removed.)



`base64` doesn=E2=80=99t = produce a warning:

   $ = echo "base64encodedvalue=3D=3D" | base64 -d | base64
=    base64encodedvaluQ=3D=3D



`openssl` doesn=E2=80=99t = produce a warning:

   $ = echo "base64encodedvalue=3D=3D" | openssl enc -d -base64 -A | openssl = enc -base64 -A
   base64encodedvaluQ=3D=3D


Python = doesn=E2=80=99t produce a warning:

=    $ printf "import = binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('base64encodedvalu= e=3D=3D'), newline=3DFalse).decode('ascii'))" |  python -
   base64encodedvaluQ=3D=3D

Thanks for the data points; adding 1=C2=BD= more:

$ ruby -rbase64 -e 'puts = Base64.encode64(Base64.decode64("base64encodedvalue=3D=3D"))' 
<= div class=3D"">base64encodedvaluQ=3D=3D
$ ruby -rbase64 -e 'puts = Base64.strict_encode64(Base64.strict_decode64("base64encodedvalue=3D=3D"))= '
<internal:pack>:281:in `unpack1': invalid = base64 (ArgumentError)
from = /opt/homebrew/Cellar/ruby/3.0.0_1/lib/ruby/3.0.0/base64.rb:74:in = `strict_decode64'
from -e:1:in = `<main>'

Checking = conformance is a MAY(*) for a decoder, so I=E2=80=99m not surprised that = many don=E2=80=99t do that.
(Or check only on = specific request, as in Ruby.)

I would strongly expect any decoder = that is used in a security context to actually check, so I *am* = surprised by the openssl example above.
(Well, not = that much surprised; it is, well, openssl.)

I wouldn=E2=80=99t have reacted to this = thread if I hadn=E2=80=99t years ago, when writing a random test case = generator, been surprised by a base64 implementation that did = check.
I don=E2=80=99t recollect the details of = that, though=E2=80=A6

Gr=C3=BC=C3=9Fe, Carsten

(*) https://tools.ietf.org/html/rfc4648#section-3.5
For those not familiar with RFC 2119 interoperability = keywords:
MAY means that an implementation is free = to do so.
Which raises the interoperability = requirement that any peer implementation MUST be able to interoperate = with an implementation that does.
This would be = unnecessary to state in this case because that MUST is in the paragraph = before.
So the intent here apparently was stressing = the optionality of checking in a decoder.

= --Apple-Mail=_359AE3E3-93E5-4869-B1F5-DB95972534BF-- From nobody Sat Jan 30 14:18: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 E1CC33A11DB for ; Sat, 30 Jan 2021 14:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 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, MALFORMED_FREEMAIL=1.591, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 BwH6L7N0sZAI for ; Sat, 30 Jan 2021 14:18:41 -0800 (PST) Received: from sonic308-2.consmr.mail.bf2.yahoo.com (sonic308-2.consmr.mail.bf2.yahoo.com [74.6.130.41]) (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 265493A11DC for ; Sat, 30 Jan 2021 14:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612045116; bh=QEmo0cUUlZkjaPEWGbUKwIYfwuJrxY1yKedSukvFQ80=; h=Date:Subject:From:To:CC:References:From:Subject:Reply-To; b=Y7KKhPvzJEIl8QErsdvkdA+NoATFsOJV2LxzGBd3k/HILG7WxLKnmNpQhDiwv/WYsb5/GhaZ18/ae9Mr/iC/gOYdQFKzAyTwbVh81rMsXOk9EIhqNrAZ7L+uH6D2L4ucEwsJVR1BusK4zB4viz2s6bzsPtveuLcxkgetcf9SiHijka0GAXM742pGFrE6gWMejs0TckawpT2HpyBRdoaGXqKKJZHdY5C19lMFiyjV04SIOqyJu5A5yURHSpTNU+CmNAn4uo1SjLtyw0/PBCogmH3em8BfpbxWYIyFeEcPmu9bzqNJsLVi6g7tdJWFm96Rrf3EHZhajifcPyEEA7ZRIg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612045116; bh=DNUpXAsRCxi4VrtNzyDqkDJB99esOZhol1bhtZ5EAIE=; h=Date:Subject:From:To:From:Subject:Reply-To; b=f0HXt8fDEZt+VryEEi4wE7Kjem804WlY1F2xxGP/9M6O7namfyIY3rOAXztKs/xJN/pQzXaDBVlMkD7/lqYwSTwSXuRgAxgEvF12MWkdV5hHum+h1C2CBNi3oCKaTBOtdoXZVcj+S840o2607s+4TgQ5+Gy9ujxlo6Mye42vTrqHyK/SLWC8DQZ1hHN7eeXUE+cXrMc2BTOMzahANnO5oKa8lOkPkfbZk45Ba/jY36+w9px1e3xc4EB86gJlXGtcR4sZp8S6QgF7DFgP5Y8YLIl6OWRZ7oGtGYnnHR7dQ7eJwDf7DGbyP0Pv5/T+pTBJjdUVaICn+QG6J5yyICAOWQ== X-YMail-OSG: teLloakVM1k8lx.MpzM5GdmToN2Hhn74SEEMybeClMbbXLTMkABW73IPHWFFUMb lVEBsS6phcImqgS839lZceebmBia7kXlVfKJZlnDy8Y_kGj4huFkDDD9uMNzQVhymfe0ksYZ_3TC 9NPZw_46KeUxsUe5P27CvzqZb81Pe2m2BqHiok1O7S0rsBFJqrerUUgsko8_rJQxapu0ApCGnRF2 N2hSvmVoeFY6DvYEsK5_kHFZ43dU0HYp2QHox_jFauOndnbOG9hPdiUXjOIj52dMmAFtBZ9WBxO7 L1swpRbOe3_VnZqMvyCnPI6KsP.g5etoTotGZTQBifj8zhL4hRMoPyv_cp.sRMQ6GFUOGKs5UFKh nSmpOzbJ8uGyljVWF45FqbsQJskogtXpRGQRwiXAoOLl6KITZPSv8mMZI.uiDnxxjn6ebiR7Aevd M5jBZgsLgifPx2GY7fl3uSQyXVaB3LuklSDf7MKkWP55eoOT.wGB6pUvRrB6zWaL2cmG29n4z9PT vmV1IsEJLvtE65YGbe34RregWVwQRcjFM7cy1TforA29x6wyO_74Bq7GTfkblIzCG0sFYEPqHkxv lI5iGaBFR.uPX_MxWbE1Tuo7TvSWw2sRETFJSKq_.22a0p_qNOaZ7H8kQJPRDF_xoN3.uoEHlcQL apCgF_aRfja1FL5.bbtMHohNPEG7DY9YSeRZaF2zilmtRoOW7sfBqoS8Mu8lGMqgu7uV4.HtY4mO rik_vihzdagmLwzCnPGtUNHetpBNpiTCx3igoYH9O20nYNo74EkjgnvLVvSGk5nRp7I6Rllpe4H. 8U_g.64SzWIsWX8hNonq6RaLF1LbiInNZBZk_3ilYilLIQmRiwbnhFTVgYTvQf2s7SpDmrLcq54O FAqpFyPGL48hAe1M71eU_0SN9KaHJC.2bML20rGNG9POaLsES2.JfF32zSBXGWJpwuVT9Y.zqfio Q8eIyh6UTrazu7iTHr2MjZoXdJWe8P0oXYFl3WJrApCWyQfuvZ0EBaoCeuQdiBpsBLSaxGl1DXqz oyhNl3ZtBPXqsYkx08oz4FHz0R9IzMf1YIesKmaYn8RjQcuURQtQrP_f0tKX0IhShz61Zi9txRRT 4wWOmQ90nasiIDdwiJxsWWQkytuLql5Fe0_.klEtO6A0qSB5SF2KdCusjHpYehHNKdABJaVq6YuD W57p68U8LiKVsoF1QQe_EPw6vOnXqhmQ88W2jDEX2a37I1M_9JPA.8mMmBZj6xg_4s6wbwo.cmEr IF_OkRxmYlfkNV7zliZA9VrnaSfZrIg0peOat7FshGJfKDtTUrlAEjT4ujXulhvtWA94lK_9Ok5t Fl3fZBfF6ZaNifxI0sN07MxNt.EJ0Ma06FozGixSd.ikIfMZceThfbZCMt7nX2bCH8fFi8Awgueo wI5.j7efTgqQxGdOhqHmeh.38Qdq7epfMZ9FEbSTS9kGvTctdXLIRiys7hEZ6QdakIvh828ur8tX 6cQyVnQto.n1KCDx_1hHmgxnXy_fI.xpCkVfO_i1kuUHqMhGJebq8c0KlPuG_tYe8m7T2IDs2jF3 ZUILWqPmfRb1Mu2nIbnz6xmUqGF2sqdUFkPEYlyYR6xkWI57X6AH8154nGWQmvQMWbKLvXLiE9Ny 0Qzn2YZdrCHCRsrQgS0XNK78oxeuuEfRgipJc_c2Vc9WiJ.239XXEHTm.HtHwBgadQAfqg7llBbp o4DUgI8CEVtq01bLchYK_HPvb9XmdfF5tc1hkB_uPgEAWJiDSkIbRy_5ejYKpHxVSG3KqY.uLiEN Wv0KDRtAeaBtYXxlQyEbhkPw7SbdZqHRSQ2Gss1MpotLxiNqJhXhGkjBfB8q7napjuMlJvO_Ienv lUSvjcp39T_UKp.Y20.m5CMe8ImJjrbuG1R.dljaFTk_L48gW7baiBojHQsGcYvrcxqvVLIoWzOG 3g4sF1idDURYNDsBtY2YFq.HW0UpuFS.y.YmoZzUEwnBXYTsF0siMbG9LwN0tJnhSjkW50bmk9iM lfJxvlcCzEX6V4Pc9exHu1HDKXbOH89zX0pdoDysn4ZzvTPxY9vBYr75cGJZJhLN09P.MalB_I.0 0ebXeb0IBCcwYXucjf_NshyW9f.9NpvqpF5dPiF58vRlUylfcA8.S4uDD6t.sW40.ed67I5FZfZp Xt47XQDyacatvqM2NKUZbT4cCnXIpKiEE.AqtBtqwwt1cx86PB7bstIdurse87GAyzkYT9S39223 6kgCDNbN_6Q0WFKb8AP4F70_Idb.yrNKcczPuiZHDub7ytd4oOPKzDMgQoaC3FiVQ8wwIvDYHC6I ZMuuxOLJLp53urNxbeyR3zxyzk6MFkH_nKjAAEwJtEkRyV9vhbjkZB06f27ZPIrqXkC7peunnhou CXED8E4N9vc.gBvaxy3S5aDHm_LcuBy204dYsARlhguQQTGn82pR7ZCtpVL0VZYQ7c6CreU1C5O2 8MsYN58vElip7fuemGcXzEl03bES62OLKR5_Li4FjeG3oPbEDSmeCM1OMXJKDpYmseNmKsKwo7x_ BrHD_rNUVhFDJcLekwc9MMXR2VoYn3sDchGR2.vtcWxAwpBw6nFriM5ukrEBSs5eQ19km2zakFGI 3Ra3kgjZM73MwNxUdCViwMkZqg173ECgWtLs8OVxNZv8k8wkermaqAVyIYQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Sat, 30 Jan 2021 22:18:36 +0000 Received: by smtp414.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8c8de3c754f8ab063a1fcfba346eeb13; Sat, 30 Jan 2021 22:18:31 +0000 (UTC) User-Agent: Microsoft-MacOutlook/16.44.20121301 Date: Sat, 30 Jan 2021 17:18:29 -0500 From: Reshad Rahman To: "Rob Wilton (rwilton)" , "netconf@ietf.org" CC: "draft-ietf-netconf-https-notif@ietf.org" Message-ID: <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6@yahoo.com> Thread-Topic: [netconf] WGLC: draft-ietf-netconf-https-notif-06 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable References: <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6.ref@yahoo.com> X-Mailer: WebService/1.1.17648 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 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, 30 Jan 2021 22:18:46 -0000 Hi, I've reviewed this document and I think the document will be ready once the= changes planned by the authors (regarding notification-messages) are made. I have a question on the following YANG description. Section 4.1 mentions '= path-absolute' for the URI but the description below says "Relative URI...".= Should this description be clarified/corrected or am I missing something? augment "transport/tls/tls/http-client-parameters" { leaf path { type string; description "Relative URI to the target resource."; } description "Augmentation to add a path to the target resource."; } Formatting nit: Trust anchors (i.e. CA certs) that are used to authenticat\ e Regards, Reshad. =EF=BB=BFOn 2021-01-22, 6:27 AM, "netconf on behalf of Rob Wilton (rwilton)" wrote= : Just to bump this thread as a reminder that the WGLC finishes in 6 days= . Please make time to review this document. Regards, Rob > -----Original Message----- > From: netconf On Behalf Of Rob Wilton (rwi= lton) > Sent: 14 January 2021 13:12 > To: netconf@ietf.org; draft-ietf-netconf-https-notif@ietf.org > Subject: [netconf] WGLC: draft-ietf-netconf-https-notif-06 >=20 > This message begins a two-week WGLC for draft-ietf-netconf-https-noti= f-06 > ending on Jan 28. Here is a direct link to the HTML version of the d= raft: >=20 > https://tools.ietf.org/html/draft-ietf-netconf-https-notif-06 >=20 > Positive comments, e.g., "I've reviewed this document and believe it = is > ready for publication", are welcome! This is useful and important, e= ven > from authors. Objections, concerns, and suggestions are also welcome= d at > this time. >=20 > Please note, the reason that I am making this request rather than the > WG chairs is because both chairs are listed as authors on this docume= nt. >=20 > Thank you, > Rob Wilton, OPS AD >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Sun Jan 31 04:54:23 2021 Return-Path: <01000177588220b4-e69a027b-360a-4e2b-af1c-e681d9bd881e-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 15B823A0CE8; Sun, 31 Jan 2021 04:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb_8mC8O8U43; Sun, 31 Jan 2021 04:54:20 -0800 (PST) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8D73A0C93; Sun, 31 Jan 2021 04:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1612097659; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=TsNaMwjHkgfpJ1e4Z+brRCMJ9JXyjgkApuadw6vIk6c=; b=fxt7EFIEFHMQ5g1NgB8QF8eYn/KF1k2/epreyqRCpqjuaJtwnvuS+y4Ym3ZMPiJ0 8J5+AmzEVw/f/T/Fin4Y30eLtwiM1nCd6xNFqyJTaBTuI90tD8TIck008d1lnRKL1VY V6+lKDOD3ds3q8F+6yFMLPx7xoidf9CyzaehGY/Y= From: Kent Watsen Message-ID: <01000177588220b4-e69a027b-360a-4e2b-af1c-e681d9bd881e-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D82A3DE0-B375-4A89-8F32-60AAC0E2D5A9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 31 Jan 2021 12:54:19 +0000 In-Reply-To: <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6@yahoo.com> Cc: "netconf@ietf.org" , "draft-ietf-netconf-https-notif@ietf.org" To: Reshad Rahman References: <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6.ref@yahoo.com> <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6@yahoo.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.01.31-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 12:54:22 -0000 --Apple-Mail=_D82A3DE0-B375-4A89-8F32-60AAC0E2D5A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > I've reviewed this document and I think the document will be ready = once the changes planned by the authors (regarding = notification-messages) are made. Thanks, but a couple more problems: 1) the URLs are bad. Specifically, the example in the =E2=80=9CLearning = Receiver Capabilities=E2=80=9D section uses a nonsensical URL (=E2=80=98/=E2= =80=98). The authors propose to instead use a sub-resource to the = user-configured =E2=80=9Cpath=E2=80=9D (e.g., GET = /some/path/capabilities) and move the POST URL to another sub-resource = (e.g., /some/path/relay-notification). [see below for more on this] 2) the media-types are bad: =E2=80=9Capplication/yang-data+[xml/json]=E2=80= =9D is used for notifications, which is wrong since they are not = YANG-defined, and the custom media-types for capabilities = (application/ietf-https-notif-cap+[xml/json]) is a way overkill. The = authors propose to use =E2=80=9Capplication/[xml/json]=E2=80=9D for both = cases. > I have a question on the following YANG description. Section 4.1 = mentions 'path-absolute' for the URI but the description below says = "Relative URI...". Should this description be clarified/corrected or am = I missing something? >=20 > augment "transport/tls/tls/http-client-parameters" { > leaf path { > type string; > description > "Relative URI to the target resource."; > } > description > "Augmentation to add a path to the target resource."; > } Agreed. How about this? leaf path { type string; mandatory true; description "URI prefix to the target resources. Under this path the receiver must support both the 'capabilities' and 'relay-notification' resource targets, as described in RFC XXXX."; } So, if path=3D=3D=E2=80=9C/som/path=E2=80=9D, capability-discovery would = be to "/some/path/capabilities=E2=80=9D and notifications would be sent = to =E2=80=9C/some/path/relay-notification=E2=80=9D. Thoughts? > Formatting nit: > Trust anchors (i.e. CA certs) that are used to authenticat\ > e Fixed, but the other example cannot be fixed because the =E2=80=9Cxmlns=E2= =80=9D strings alone are too long, and XML doesn=E2=80=99t internally = support folding, and the =E2=80=9Cstring=E2=80=9D type doesn=E2=80=99t = allows for whitespace (include =E2=80=98\n=E2=80=99) both at the = beginning and end of strings (recall my request for rfc6991-bis to = define a =E2=80=9Ctoken=E2=80=9D type that would enable the parser to = discard any found, so our examples could more often be manually-folded). K. --Apple-Mail=_D82A3DE0-B375-4A89-8F32-60AAC0E2D5A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I've reviewed this document = and I think the document will be ready once the changes planned by the = authors (regarding notification-messages) are made.

Thanks,= but a couple more problems:

1) the = URLs are bad.  Specifically, the example in the =E2=80=9CLearning = Receiver Capabilities=E2=80=9D section uses a nonsensical URL (=E2=80=98/=E2= =80=98).   The authors propose to instead use a sub-resource to the = user-configured =E2=80=9Cpath=E2=80=9D (e.g., GET = /some/path/capabilities) and move the POST URL to another sub-resource = (e.g., /some/path/relay-notification).  [see below for more on = this]

2) the media-types are bad: = =E2=80=9Capplication/yang-data+[xml/json]=E2=80=9D is used for = notifications, which is wrong since they are not YANG-defined, and the = custom media-types for capabilities = (application/ietf-https-notif-cap+[xml/json]) is a way overkill. =  The authors = propose to use =E2=80=9Capplication/[xml/json]=E2=80=9D for both = cases.


I have a = question on the following YANG description. Section 4.1 mentions = 'path-absolute' for the URI but the description below says "Relative = URI...". Should this description be clarified/corrected or am I missing = something?

=             au= gment "transport/tls/tls/http-client-parameters" {
=             &n= bsp; leaf path {
=             &n= bsp;   type string;
=             &n= bsp;   description
=             &n= bsp;     "Relative URI to the target = resource.";
=             &n= bsp; }
=             &n= bsp; description
=             &n= bsp;   "Augmentation to add a path to the target = resource.";
=             }<= br class=3D"">

Agreed.  How about this?

      =   leaf path {
      =     type string;
      =     mandatory true;
    =       description
      =       "URI prefix to the target = resources.  Under this
      =        path the receiver must support both = the 'capabilities'
          =    and 'relay-notification' resource targets, = as described
          =    in RFC XXXX.";
      =   }

So, if = path=3D=3D=E2=80=9C/som/path=E2=80=9D, capability-discovery would be to = "/some/path/capabilities=E2=80=9D and = notifications would be sent = to =E2=80=9C/some/path/relay-notification=E2=80=9D.
=
Thoughts?


Formatting nit:
=            Trust = anchors (i.e. CA certs) that are used to authenticat\
=  e

Fixed, but the other example cannot be fixed = because the =E2=80=9Cxmlns=E2=80=9D strings alone are too long, and XML = doesn=E2=80=99t internally support folding, and the =E2=80=9Cstring=E2=80=9D= type doesn=E2=80=99t allows for whitespace (include =E2=80=98\n=E2=80=99)= both at the beginning and end of strings (recall my request for = rfc6991-bis to define a =E2=80=9Ctoken=E2=80=9D type that would enable = the parser to discard any found, so our examples could more often be = manually-folded).

K.


= --Apple-Mail=_D82A3DE0-B375-4A89-8F32-60AAC0E2D5A9--