From nobody Fri Dec 4 00:40:11 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBB73A15C7 for ; Fri, 4 Dec 2020 00:40:10 -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=BI6B7kTW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vY8Jhp5+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJx8y0NGuKVl for ; Fri, 4 Dec 2020 00:40:07 -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 9EE923A0B3B for ; Fri, 4 Dec 2020 00:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15606; q=dns/txt; s=iport; t=1607071207; x=1608280807; h=from:to:subject:date:message-id:mime-version; bh=dK12XpldbFoFbcIbrrxv/GKB3Guvi8LSFcI3fAAMlbo=; b=BI6B7kTW6L6EQEw81fUNbyKvF6nS7Isu7GaiJNqB4BFW4OuUu+lObJKh Gvo5LP83VStA/hvzLu2fJTwo4a0ZovSztEbQZgoEj+0xpRsNMnjq3Zt/5 Aye2A9cpR3dFBDKkVvWUjtkfiUKVlIeiCGDQbhjMSpdUG8a1IOBLH/iUQ E=; X-IPAS-Result: =?us-ascii?q?A0ApAgDH9MlfmIwNJK1igQmBT4EjL1F8Wy8uCod6A41Zl?= =?us-ascii?q?BqEcYEuFIERA1QLAQEBDQEBLQIEAQGESgKCFQIlNAkOAgMBAQEDAgMBAQEBB?= =?us-ascii?q?QEBAQIBBgQUAQEBAQEBAQGGNgELhgsuAQE4EQGBACcEGxqDBAGBflcDLgEDo?= =?us-ascii?q?D0CgTyIaXSBNIMEAQEFhTYYghAJgTiCc4pNG4FBP4ERQ4c4G4NIgiyBTwk6L?= =?us-ascii?q?32BTnEbJY9BPoongzKIdpEwCoJym1eDIY92jw6TcpwfPQmEMAIEAgQFAg4BA?= =?us-ascii?q?QWBVjgsgS1wFYMkUBcCDY47g1eKWHQ3AgYKAQEDCXyOLwGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AuLdRiha1SjtLzLCNMJLzAF7/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaTD4TW9/wCjPDZ4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8fze1OUpWe9vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,392,1599523200"; d="scan'208,217";a="608257655" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Dec 2020 08:40:06 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B48e5GL023666 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 4 Dec 2020 08:40:06 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 4 Dec 2020 02:40:05 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 4 Dec 2020 03:40:04 -0500 Received: from NAM10-MW2-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; Fri, 4 Dec 2020 02:40:04 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P7QCUUjerGy2dlhSiME5dUS+GBnOICR8VKpHt+ym3u4ckMdb3u5I5BRMKJrwmQ43C9RL6J8cg+V/xXir6a6tmMc+ZjoMI8KO87Z/ywZFEgv8UqAf0t7kPq+Pet8TwnHvF8UxYtPUqUIQat1KSMkMJ0mIiR8eANGIU1WcxD/VKF63XdpUvVErqQq4bCrSsrywmMNGC3F4xBbF4QHzJWuEyM2sSwvdZqfH7QBOaMiwZGAvPQAmub6qEfBAIWcr1zaWQW3yNxnRHNqUxb1i9QZjsni2zzY8fRNkQKQ3hzrChU8IiOgsRkbrMrgjeqzKV2SFi7TqOjr4Lz14CJgACFSFOw== 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=tfs4V/p6fwbXlPQZzOTahik7Iso9ZU9k1UKRdMFSseI=; b=hkIKN11W93b4JdwBHriYrk5xpOG2+ARUOUaaewuMUYEUyy7RMiIMOKd4p0is5CQeUelmJoPD5UcPFK/kf3VStvglhFkvhDP8nbGoOgrCCUI2OxBQhG9ie/VYVYSkveDGSQ0x2NHF0ezYRkBSWTL7uK9q/5cQHpIEh3aMT2VMSPlKdoxXeLCnbn7Rv/paZWDJ0SCsu+lLCOQPq/7EaOeLQwVQ/kT4JVeRsjkSuZRtUNSVGe2BAsbwMulDEX1rTOGBOxo3iNbCxQ2sl3258QR4iiAz4kYgOWAv1M90Hg+gziR5uKSVHb5flD0O96OXsz7VFJudWsxpudc/v1CntuTKJw== 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=tfs4V/p6fwbXlPQZzOTahik7Iso9ZU9k1UKRdMFSseI=; b=vY8Jhp5+bWHx7z+F4eIeV8W3l5TjxHzrvDn8CgyMFN70+ORIkC7gZu8u7RwaoNWwE+Ih0l4OVMlOclm7LOz0G5lbR8BI64CXaq+UkLNa9m33l0I8ZAi4p3HZaKrdou7/fGq2UTYdk0lHKqG1pq83uLB6pZQIvwmsGoSCoMyYt8A= Received: from BYAPR11MB3573.namprd11.prod.outlook.com (2603:10b6:a03:fe::33) by BYAPR11MB2614.namprd11.prod.outlook.com (2603:10b6:a02:cc::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.21; Fri, 4 Dec 2020 08:40:03 +0000 Received: from BYAPR11MB3573.namprd11.prod.outlook.com ([fe80::880c:73b9:2be3:2031]) by BYAPR11MB3573.namprd11.prod.outlook.com ([fe80::880c:73b9:2be3:2031%5]) with mapi id 15.20.3632.021; Fri, 4 Dec 2020 08:40:03 +0000 From: "Christofer Tornkvist (ctornkvi)" To: "netconf@ietf.org" Thread-Topic: NACM read access for actions Thread-Index: AQHWyhe8pG7lD1hfBEGgzpuUtjTj9A== Date: Fri, 4 Dec 2020 08:40:03 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [195.84.96.183] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 56a55f79-670c-4e7b-88eb-08d8983031af x-ms-traffictypediagnostic: BYAPR11MB2614: 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: MxKt5FV66HKkDDgTloep01uZAYQ1S4n6HnG98l7PyLrACV62f8DKO65qfA9xbJnu4YHddiJcxtfyMRZm9hSWnNq4Qjv6EHK/LaUYJPFHNYJP4n2CaqLFlqRpzBJMBC1zXelwc1mrt77DqB9kUtVdM4zDT2CpeY9apedlioEEicSemMBj3TksPys6N03oZimudvO2vKm9MR5CsUXzGDuydvqbqJkfRbIxNDPSYxqlAg1CskxjbGGpqwfCpgV3BW1lvbrA/l2KfoRb5z8q/iM2KSfLI/2GmJvRU+NnhdUa9xRRWM6N09Mf81weACR1ipwnprM2wTRPZTTSzhOTJxuGsQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3573.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(39860400002)(376002)(366004)(136003)(346002)(64756008)(9686003)(66446008)(66556008)(83380400001)(55016002)(66476007)(91956017)(66946007)(7696005)(316002)(76116006)(478600001)(2906002)(33656002)(6506007)(6916009)(26005)(86362001)(52536014)(8936002)(5660300002)(186003)(71200400001)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?phdZ/HJpVAsaElJ17xbCDcSHmNrho31hJYiwOxUOrql4SxcItP9PY+JSBalH?= =?us-ascii?Q?lNfqBy2MfPhCSawBPDqEAFrAr2EWM6wP2MuHdsHZSHd+tDIwOCWwLRTwv4W+?= =?us-ascii?Q?FfeJyRjHZ2/4eus29lkSh/NniactbrvcQTIpg4oIQodIMoyyCjBWbqCdS6fM?= =?us-ascii?Q?efpIJ7wznf5Zz+FitfsCDT4ciCWc9H8/rlxQaCDFJPjSDty2Di8M2EeCdrWn?= =?us-ascii?Q?3a04WSlghKYAM15fqgU7MBW536yVviiSqOwhjstu9CKBGRA342QOCObb6iTv?= =?us-ascii?Q?pT85e5LePVHM/E/M+TL/othLPfhg/QAny43q2hHO504dhqcDrHXTa7IP4mSo?= =?us-ascii?Q?oQnVdVrIMGxDh+LajT49N2oUZ4Ecy3kC+M7wVwnchWvQW9Uo2Ewy028vRr6k?= =?us-ascii?Q?p1Ql1EH+TDqLpMIFiCgU8BEwhBRWL3X3+1BjPsKwvl+lFSDdR5pNLSb/s/ee?= =?us-ascii?Q?IA6i5oJxvUOweJV2bngy4jhK17Fcytrqgw2JfGiwmjPoGwVNpJQ8u/nxdDI1?= =?us-ascii?Q?atHcMPXO0Oc3O51mt+Ntk8bT7vJCSNPFRA4y9pHP3AcR2t1pRWEn15YtzY/h?= =?us-ascii?Q?USkNvb76xbLLDuOGYxycHmVos7UM1oJBtE4h8FUcW6LNjYJWSs/e9X94KGPT?= =?us-ascii?Q?yFwUz+AFGa5MOGPZj9Q6ZGCqeZEv+HJSRiZ10lU7eIXl5QkdzaJluuUyjtDF?= =?us-ascii?Q?jwJdfp3GljJOw06Z/2AdghFZKjJ5Z5o6VIFs05oUqB4oGs5t+FlJ+UDoW57Y?= =?us-ascii?Q?cgkGMBt/B442v2pfJh5RhGUQLktSzMOoQx6VLBmQjC28C77GdkSb5oOjh8ae?= =?us-ascii?Q?FEUeSJ3Z0QeW5qfUtG+B8cqWNprKgl2n0OsmDW52zzd2rKyaqgb0bg5Psspg?= =?us-ascii?Q?FPc8KhuPW4Gqqh3I8clfNfK54zGdib4RO0VNrxYnch2tJBpm6XZtA+Sc56rO?= =?us-ascii?Q?8SqsYeiKAFdJSjHoSPuDXlrNgHIOwscKIYzPRA5zGsBFgXbQC78utRureBv/?= =?us-ascii?Q?+Uum?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3573D000CDD08B1CA22C907ED0F10BYAPR11MB3573namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3573.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56a55f79-670c-4e7b-88eb-08d8983031af X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 08:40:03.1755 (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: 6/IkZw9EbrvdtA1ajVFB6N3DRZo++vV897ob/d88sdqBuDOtNrRkJiWoMwRPW/lLJP3X6Jw+zPhcjF2tkbO/Dg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2614 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: [netconf] NACM read access for actions 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, 04 Dec 2020 08:40:10 -0000 --_000_BYAPR11MB3573D000CDD08B1CA22C907ED0F10BYAPR11MB3573namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I read in the NACM RFC 8341 that for actions to not be rejected they both must have execute access and also read access for all its parent (instance) nodes along the node hierarchy up to the top node -described by the path for the action node. The read access property, is that equivalent of having NACM rules stating read access for all parent (instance) nodes? If that is the case, does not that open up the node tree structure unnecessarily much? I support the idea of just having to state one NACM rule containing read and execute access for the action node itself for it to be able to be run, and also that all the parent (instance) nodes will be readable only along the path up to the action node without any additional NACM rules. And if there is a read access deny rule on any parent (instance) node the action will be rejected. Would appreciate a clarification. Below are references to RFC 8341. Regards /Christofer Tornkvist References in RFC 8341 are: Ch. 3.1.3 s.3 The new "pre-read data node acc. ctl" boxes in the diagram below refer to group read access as it relates to data node ancestors of an action or notification. As an example, if an action is defined as /interfaces/interface/reset-interface, the group must be authorized to (1) read /interfaces and /interfaces/interface and (2) execute on /interfaces/interface/reset-interface. Ch. 3.1.3 p.12 bullet 2 o If the operation defined in [RFC7950] is invoked, then read access is required for all instances in the hierarchy of data nodes that identifies the specific action in the datastore, and execute access is required for the action node. If the user is not authorized to read all the specified data nodes and execute the action, then the request is rejected with an "access-denied" error. --_000_BYAPR11MB3573D000CDD08B1CA22C907ED0F10BYAPR11MB3573namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I read in the NACM RFC 8341 that for actions to not be rejected

they both must have execu= te access and also read access

for all its parent (insta= nce) nodes along the node hierarchy

up to the top node -descr= ibed by the path for the action node.

 <= /p>

The read access property,= is that equivalent of having NACM rules

stating read access for a= ll parent (instance) nodes?

 <= /p>

If that is the case, does= not that open up the node tree

structure unnecessarily m= uch?

 <= /p>

 <= /p>

I support the idea of jus= t having to state one NACM rule

containing read and execu= te access for the action node itself for it

to be able to be run,

and also that all the par= ent (instance) nodes

will be readable only alo= ng the path up to the action node without

any additional NACM rules.

And if there is a read ac= cess deny rule on any parent (instance) node

the action will be reject= ed.

 <= /p>

 <= /p>

Would appreciate a clarif= ication.

 <= /p>

Below are references to R= FC 8341.

 <= /p>

Regards=

/Christofer&nbs= p;Tornkvist

 

 

References in RFC 8341 ar= e:

Ch. 3.1.3 s.3<= /span>

   The new= "pre-read data node acc. ctl" boxes in the diagram below

   refer t= o group read access as it relates to data node ancestors of an

   action = or notification.  As an example, if an action is defined as<= /o:p>

   /interf= aces/interface/reset-interface, the group must be authorized

   to (1) = read /interfaces and /interfaces/interface and (2) execute on

   /interf= aces/interface/reset-interface.

 <= /p>

Ch. 3.1.3 p.12 bullet 2

   o =  If the <action> operation defined in [RFC7950] is invoked, then=

      = ;read access is required for all instances in the hierarchy of data

      = ;nodes that identifies the specific action in the datastore, and=

      = ;execute access is required for the action node.  If the user is<= o:p>

      = ;not authorized to read all the specified data nodes and execute=

      = ;the action, then the request is rejected with an "access-denied"=

      = ;error.

 

 

--_000_BYAPR11MB3573D000CDD08B1CA22C907ED0F10BYAPR11MB3573namp_-- From nobody Fri Dec 11 12:34:22 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECBA3A0EBB for ; Fri, 11 Dec 2020 12:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=ndt-inc.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 HwJBrmgLO7t7 for ; Fri, 11 Dec 2020 12:34:19 -0800 (PST) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [146.66.121.81]) (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 3C5233A0EBA for ; Fri, 11 Dec 2020 12:34:19 -0800 (PST) Received: from 108.134.209.35.bc.googleusercontent.com ([35.209.134.108] helo=usm9.siteground.biz) by se17.mailspamprotection.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1knp7I-0006Tf-Ce for netconf@ietf.org; Fri, 11 Dec 2020 14:34:18 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ndt-inc.com ; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:To:From:Reply-To:Sender:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Fw4PpUoHZLrtKpxBWRKOW3sYg/nVj9YW9d/gUv/booo=; b=XIxs1bVPcKLZnrs9OKqOW5T1/5 h6KKYmYBYva29AN0MeRngxRLp5sxeg7SmFuPGzczBQJHDloJ9JArNq4cBVVSFeKRqLUKEMDvoICEX wkfE5xB+gvGLxaxWCIvmtdkscZXnx3uDItJPUU1DnZJBOMMXeOwBim7bf/X8Ig2G/4NWWN956epJD 8MiT+1K7sNTVUjc6tJOAHy460xYdNW+NEbLsea4iMCdXD+2NDyMcW2H37Bo/PDVbr04qgaSnG/xID jCAECaV8jG73ULzGwA6XBMUotXNlu3wHtOyqO0x7YRwgtLns6NAvr/IosJe4HJYBtUUeXAtM0taKq cVXWB6vg==; Received: from [76.68.22.33] (port=55593 helo=StanPC) by usm9.siteground.biz with esmtpsa tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.90devstart-1178-b07e68e5-XX) (envelope-from ) id 1knp7I-000LCD-4J for netconf@ietf.org; Fri, 11 Dec 2020 14:34:16 -0600 Reply-To: From: "Stan Kmiec" To: References: In-Reply-To: Date: Fri, 11 Dec 2020 15:34:16 -0500 Organization: NDT Message-ID: <00c201d6cffc$ff16a270$fd43e750$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C3_01D6CFD3.16409A70" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: AdbP+uiiFejajzSeTYe6i0JtngMVbgAAeyiQ X-Originating-IP: 35.209.134.108 X-SpamExperts-Domain: usm9.siteground.biz X-SpamExperts-Username: 35.209.134.108 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.209.134.108@usm9.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8aYAGbZeE8CYT4yLNUxRWoPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5w+SJzRtEQwO4n6+8/g0CWk8wOq2zirMPonLyKNm5/pIoEU BxmBy9xZs9GJXx4QVrsk4Ndu06h2Q8QP5GQeNUYfFRth/Byc3JFltXUjMSNDfjcmZFuxTRO4+xy4 GspSqlztmz3xatm0dHPWss/dXmEnyzngJGhbi/Y9OHM+mXUShSdM1HQZkMf12e/uCFbfnS0jf+/T iFfEZgqyoRZq3TYjRI32L6Pl/MwW60+mEIcar4hSnw9YyoGHx/ukuag1WKCIIeyaJS8ubrzvkuRY m5rPFyrtVW4KaRSURqFyxA+5hxTHswbbB/ha+ZWrSAi8Skyxe17QIfgTGOgXzm19/3QDUdShXBqj IqKx5jnB7z3Yhhp3eWzGQOuNjEBo/WEbPRDIZwKDK1Qy7Yn0clcDVSjgq0HLIlsrt1nO9vVVYT6c 8cXlMOKH98vFz4WTpHp46A9Qef6Ceaw0tyEeHKZjklTreHL+whhAdKuW1jHRpItetjZU1dhNAjHG Sz8wA7wGPYp6PH5kQfzcPe5Psb29XFKglV8hheRjmhoo1FCEuljRlhkgoL0bckEue7jwJnlVscnY 5Qx4fJOk03R5fJtf/Dv/9m9+uP0zyEETyQahh1k9u2om0xVb9oL3R5o7ogdd/Z2jkSKWpdRxDdtf qq7ogl89nZocEwUWn3pl1GF/MpR/1woqRgT89NxfhhZheX75APDwQN5Uf2fZ1qOg+SPjT+BOO4cY iObT0Rj/YMafIyBtwbYB2txk8CJC/KMhngtCqeop03re2gJFeUkgE+W2A+eAFQf17EtkbrRrF1MZ gd29kNUJJqJ699MXxS5tr+TbdHpxfpYDjGTZ0x3acMshIoiR1/wHKtMfMgXVF96EFpfQrYjKFojr vUjjKLsywQkk4eoTAsVZ1pnsskEXLcdxuBSoMbuFCnOyeJRTotBWH8GsKiUKRK6Obnxr/EH5cLWQ JzrUFfqy+Fwgv8uwUCBDUV9ghQHpG0bD2zAJ8ipxBZatr5PNryPhH4lKeinv12/T+iWceXZNG0EU bELA0uv9YhdO7yCUgX8YuF5WBQr1Bq86197wOsO4MsdV9Y8oHgWtVfLu1XlYo8oQA7fdrkM8i3+x X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Archived-At: Subject: [netconf] question re: NACM, rfc8341 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, 11 Dec 2020 20:34:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C3_01D6CFD3.16409A70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit A quick question regarding NACM, rfc8341... say in a multi-tenant network, and I'm admin for my "slice" and I have a "read-update" permission to one node and a permission to execute protocol operation. I just updated a value of that one node in Running. If I now execute , will that result in that one node's value being updated and all other values in Startup shall remain unchanged, even if some are different from the current Running object's values? Thank you, Stan Kmiec ------=_NextPart_000_00C3_01D6CFD3.16409A70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A quick question = regarding NACM, rfc8341... say in a multi-tenant network, and I'm admin = for my "slice" and I have a "read-update" permission = to one node and a permission to execute <copy-config> protocol = operation.  I just updated = a value of that one node in Running.

 

If I now execute = <copy-config Running Startup>, will that result in that one node's = value being updated and all other values in Startup shall remain = unchanged, even if some are different from the current Running object's = values?

 

Thank = you,

 

Stan = Kmiec

 

 

 

------=_NextPart_000_00C3_01D6CFD3.16409A70-- From nobody Mon Dec 14 14:36:18 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C70C3A11D6; Mon, 14 Dec 2020 14:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 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, 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 AA4q-ZqOFAPF; Mon, 14 Dec 2020 14:36:15 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 EA2C33A11D4; Mon, 14 Dec 2020 14:36:11 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id t8so13159870pfg.8; Mon, 14 Dec 2020 14:36:11 -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=Dj49YmKR8p3c26L//o9jA9pbU2Lr8RM1k5jT2XJ5prc=; b=dm60UMgQD/X+hWLSdfMu2rd5156VR2/LtCYIXAj5ZXT8atVreVyFvJ2mMO4MscEv+y zOs7fmNMPxSGEikWbMYkjKz2B3amHZgl64JvX24my4G473OiD7wbp7qvYkMHwIMcUOEJ RF3G2DlvWBiDreTL/wb6z+IyZXdSIEpt+NQn/314NJpd61E0k8/EI5qy1AcaCiHh9wUy iTEkmVquGbJUKFLcwoTA7NzUhuLmu0MvfK7UbbNXmgcnCpXpaZcyXtopnfBIDKEXL0HH /K1pJD752iVMtbk4ZqlY7SSkEvCSUmxWKkAlpr0CdtgVjh6Jigesw8flcgqdSYOEUx2t 3Lkg== 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=Dj49YmKR8p3c26L//o9jA9pbU2Lr8RM1k5jT2XJ5prc=; b=ALHJJjknhtCIfv3BbnPM3Bu2xW8y/q+aSNBuGtrPmXc6gDnDFF222j+1XDZ+2b2Nvu FQJRxuOWBhTVfFwsfoq7cnIq29tiHPk3EeupIEWKL/ru1iE+QDuUzhUGJHIUvJc/vaRu GzExfO7CQPKnVfO2fnfajLsS9km012tyBH3kSUpyU1WoeUzOCAYKqefmOa1030GVerVL mkcNC+l4/xbDmL7YTDAzFbtAr8H3K78kGWsgD1Xv8VPj3ihK+7E3xJbF5bAasyPaDXmj 080f27nAxgzh/cPtyGDnoaPRHPdh/8e79e8KFwYNUIyqIT3U6E74r5cQhS/whbvvreeq CTXA== X-Gm-Message-State: AOAM5333LrNOIuHjKWIDFeuQlGWmRmIBJLx7zoqpCg/nRo2RwAltQIlq 6W/fk/IbG5eUX+m6wsQrzxv78FADr9I= X-Google-Smtp-Source: ABdhPJxyq1vg1itv/hySv3AdzpHiqXaPTlqJS/smgwqEFXEjFyP/jr22wrNiXkhPoWLHG9A5kk+PFQ== X-Received: by 2002:a63:4703:: with SMTP id u3mr26595284pga.199.1607985370921; Mon, 14 Dec 2020 14:36:10 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:1142:ad9:dab3:7838? ([2601:647:5600:5020:1142:ad9:dab3:7838]) by smtp.gmail.com with ESMTPSA id s7sm21926132pfh.207.2020.12.14.14.36.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Dec 2020 14:36:10 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_124A8E95-0F2F-4C90-BE74-7A1A98D74BB2" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <9E04947B-8F6B-4899-9185-2BA07EB4CE40@gmail.com> Date: Mon, 14 Dec 2020 14:36:09 -0800 Cc: draft-ietf-netconf-sztp-csr@ietf.org To: Netconf , sean@sn3rd.com, Russ Housley , Kent Watsen X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [netconf] IPR on draft-ietf-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2020 22:36:17 -0000 --Apple-Mail=_124A8E95-0F2F-4C90-BE74-7A1A98D74BB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Authors, Contributors, Working Group, In preparation of sending the above documents for WGLC, we need to find = out if ... Are you aware of any IPR that applies to above stated draft? Please state: "No, I'm not aware of any IPR that applies to these draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules = (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think = appropriate. If you are listed as a document author or contributor please answer the = above by responding to this email regardless of whether or not you are = aware of any relevant IPR. This document will not advance to the next = stage until a response has been received from each author and listed = contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty = . Mahesh & Kent (as co-chairs) --Apple-Mail=_124A8E95-0F2F-4C90-BE74-7A1A98D74BB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Authors, Contributors, Working Group,

In preparation of sending the above = documents for WGLC, we need to find out if ...

Are you aware of any IPR that applies = to above stated draft?

Please state:

"No, I'm not aware of any IPR that applies to these draft"
or
"Yes, I'm aware of IPR that applies to this = draft"

If so, has this IPR been disclosed = in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and = 5378 for more details)?

If yes to the = above, please state either:

"Yes, the IPR = has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you = think appropriate.

If you are listed = as a document author or contributor please answer the above by = responding to this email regardless of whether or not you are aware = of any relevant IPR. This document will not advance to the = next stage until a response has been received from each author and = listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS = MESSAGE'S
TO LINES.

If you = are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your = obligations under
the IETF IPR rules which encourages you = to notify the IETF if you are
aware of IPR of others on an = IETF contribution, or to refrain from
participating in any = contribution or discussion related to your
undisclosed = IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPro= perty.

Mahesh & Kent (as co-chairs)





= --Apple-Mail=_124A8E95-0F2F-4C90-BE74-7A1A98D74BB2-- From nobody Mon Dec 14 14:50:30 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C873A1225 for ; Mon, 14 Dec 2020 14:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNDEAfGmmjXc for ; Mon, 14 Dec 2020 14:50:27 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360CB3A122C for ; Mon, 14 Dec 2020 14:50:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B7A45300BC9 for ; Mon, 14 Dec 2020 17:50:24 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 82rl4tzkOZL4 for ; Mon, 14 Dec 2020 17:50:22 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 0DA61300A48; Mon, 14 Dec 2020 17:50:22 -0500 (EST) From: Russ Housley Message-Id: <921F9DCF-C862-4A2C-B7BE-F267164237EF@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2FCF70CF-4337-40F8-A428-8C9B264E5A54" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Mon, 14 Dec 2020 17:50:23 -0500 In-Reply-To: <9E04947B-8F6B-4899-9185-2BA07EB4CE40@gmail.com> Cc: Netconf , Sean Turner , Kent Watsen , draft-ietf-netconf-sztp-csr@ietf.org To: Mahesh Jethanandani References: <9E04947B-8F6B-4899-9185-2BA07EB4CE40@gmail.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [netconf] IPR on draft-ietf-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2020 22:50:29 -0000 --Apple-Mail=_2FCF70CF-4337-40F8-A428-8C9B264E5A54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No, I'm not aware of any IPR that applies to these draft Russ > On Dec 14, 2020, at 5:36 PM, Mahesh Jethanandani = wrote: >=20 > Authors, Contributors, Working Group, >=20 > In preparation of sending the above documents for WGLC, we need to = find out if ... >=20 > Are you aware of any IPR that applies to above stated draft? >=20 > Please state: >=20 > "No, I'm not aware of any IPR that applies to these draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules = (see RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think = appropriate. >=20 > If you are listed as a document author or contributor please answer = the above by responding to this email regardless of whether or not you = are aware of any relevant IPR. This document will not advance to the = next stage until a response has been received from each author and = listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS = MESSAGE'S > TO LINES. >=20 > If you are on the WG email list or attend WG meetings but are not = listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed = above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty = . >=20 > Mahesh & Kent (as co-chairs) >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_2FCF70CF-4337-40F8-A428-8C9B264E5A54 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
No, I'm not aware of any = IPR that applies to these draft

Russ

On Dec = 14, 2020, at 5:36 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Authors, Contributors, = Working Group,

In = preparation of sending the above documents for WGLC, we need to find out = if ...

Are you = aware of any IPR that applies to above stated draft?

Please state:

"No, I'm not aware of = any IPR that applies to these draft"
or
"Yes, = I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF = IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance = with IETF IPR rules"
or
"No, the IPR has not = been disclosed"

If you answer no, please = provide any additional details you think appropriate.

If you are listed as a document author or = contributor please answer the above by responding to this email = regardless of whether or not you are aware of any relevant IPR. = This document will not advance to the next stage until a response = has been received from each author and listed contributor. NOTE: = THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO = LINES.

If you are on the WG email list or = attend WG meetings but are not listed
as an author or = contributor, we remind you of your obligations under
the = IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain = from
participating in any contribution or discussion = related to your
undisclosed IPR. For more information, = please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPro= perty.

Mahesh & Kent (as = co-chairs)






= --Apple-Mail=_2FCF70CF-4337-40F8-A428-8C9B264E5A54-- From nobody Mon Dec 14 17:53:26 2020 Return-Path: <01000176641a2021-bb9cee25-40e1-4ba0-bcdd-fd7d5b718cfc-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 7560C3A132C; Mon, 14 Dec 2020 17:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.006 X-Spam-Level: X-Spam-Status: No, score=0.006 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0YOeyMH4P5d; Mon, 14 Dec 2020 17:53:24 -0800 (PST) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09913A132B; Mon, 14 Dec 2020 17:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1607997202; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=jXYe0ygZnnRe8tjTnaM2zX6u9gty9n+OOXd9zybjw5U=; b=GfteZMwgk6TEmP3OsiCTgWjg22QipAG9iZvPLfB2X+eH2MxX8ZmDft7BOM+8xupf BBysDsTwZv21j628u/fcoLzeG7q/mP05kdpd3RV3o1ITlDyL3jpQmJPqMk9Pq8Eq6rd MstD3K6i14En/kdqv5xEZNeJ+cqXE4EYSMcd4NlA= From: Kent Watsen Message-ID: <01000176641a2021-bb9cee25-40e1-4ba0-bcdd-fd7d5b718cfc-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E5ABCBF5-6F58-4FC5-8414-635CD5A737C2" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 15 Dec 2020 01:53:22 +0000 In-Reply-To: <9E04947B-8F6B-4899-9185-2BA07EB4CE40@gmail.com> Cc: "netconf@ietf.org" , Sean Turner , Russ Housley , draft-ietf-netconf-sztp-csr@ietf.org To: Mahesh Jethanandani References: <9E04947B-8F6B-4899-9185-2BA07EB4CE40@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.12.15-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] IPR on draft-ietf-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 01:53:25 -0000 --Apple-Mail=_E5ABCBF5-6F58-4FC5-8414-635CD5A737C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No, I'm not aware of any IPR that applies to this draft. Kent (as co-author) > On Dec 14, 2020, at 5:36 PM, Mahesh Jethanandani = wrote: >=20 > Authors, Contributors, Working Group, >=20 > In preparation of sending the above documents for WGLC, we need to = find out if ... >=20 > Are you aware of any IPR that applies to above stated draft? >=20 > Please state: >=20 > "No, I'm not aware of any IPR that applies to these draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules = (see RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think = appropriate. >=20 > If you are listed as a document author or contributor please answer = the above by responding to this email regardless of whether or not you = are aware of any relevant IPR. This document will not advance to the = next stage until a response has been received from each author and = listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS = MESSAGE'S > TO LINES. >=20 > If you are on the WG email list or attend WG meetings but are not = listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed = above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty = . >=20 > Mahesh & Kent (as co-chairs) >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_E5ABCBF5-6F58-4FC5-8414-635CD5A737C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii No, = I'm not aware of any IPR that applies to this draft.

Kent (as co-author)


On Dec 14, 2020, at 5:36 PM, Mahesh = Jethanandani <mjethanandani@gmail.com> wrote:

Authors, Contributors, = Working Group,

In = preparation of sending the above documents for WGLC, we need to find out = if ...

Are you = aware of any IPR that applies to above stated draft?

Please state:

"No, I'm not aware of = any IPR that applies to these draft"
or
"Yes, = I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF = IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance = with IETF IPR rules"
or
"No, the IPR has not = been disclosed"

If you answer no, please = provide any additional details you think appropriate.

If you are listed as a document author or = contributor please answer the above by responding to this email = regardless of whether or not you are aware of any relevant IPR. = This document will not advance to the next stage until a response = has been received from each author and listed contributor. NOTE: = THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO = LINES.

If you are on the WG email list or = attend WG meetings but are not listed
as an author or = contributor, we remind you of your obligations under
the = IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain = from
participating in any contribution or discussion = related to your
undisclosed IPR. For more information, = please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPro= perty.

Mahesh & Kent (as = co-chairs)






= --Apple-Mail=_E5ABCBF5-6F58-4FC5-8414-635CD5A737C2-- From nobody Mon Dec 14 18:21:02 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6723A09EF for ; Mon, 14 Dec 2020 18:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoNcwnbDLBoh for ; Mon, 14 Dec 2020 18:20:58 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 CE9C63A09E9 for ; Mon, 14 Dec 2020 18:20:57 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id a6so13527489qtw.6 for ; Mon, 14 Dec 2020 18:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g8Ps+lnv5BCwZiAgG9EkMkRbhzA+qFSdAkGphPOK3bc=; b=iukGqwxG5L0yWtx/R/DdddRaD3g9cXlExNDVC6qxq0L355p79LOY3v/3VQJeWXsPrR 839Jd1r4nBqKnjFjWg15Ju3Ip2v3HsQ3tgFGQvN7way31FgYYfTvZXZIjbuA/oeP/3W2 BAUw6OYhD+XiyCT/cXvLWBi62GC1TDqB0US3E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g8Ps+lnv5BCwZiAgG9EkMkRbhzA+qFSdAkGphPOK3bc=; b=ai+ZII8sPqWcv6BbCUdqomFUColyGrqFisBqPbU0HH5Um6u5qvMNIgvtTP9ZskDjjk hsqEoPPJjtmzEPiQ4UaXZWn8znGvW2w/JfLCv+PhQB0tDVR0SSc9Ycwm39zHFjzAcQjy mZo3dby4xc4e/e0y5KcG02Rj+Xx/oxdj74FxbLfQ4ZxdZD4y21B5SeTX7nlE0oplLyAQ NmIQ6bryhN0DFoHbJltn6ZXZC2PNOel3CjUsf8nKZksUk90fUpeH8LX0x3s6XHclNjBu a+74HodO2y0C8seWfr8vEh8bGm9mdzBJXoNrOh47HsXWzdlDA92IlMius+FoQHWhVjRl Urgg== X-Gm-Message-State: AOAM530F+VDWHhEuVMmni0Xagtlz/Om9z90t2R0pOiJ/dJFOKlRVcD9z 9vwZAkc/dzN5CthyMYYdf9wvpA== X-Google-Smtp-Source: ABdhPJyoJ6PV6lHu4TpYhfrbtdFPHkyoiCmyLsuPDsXwaum69bY6uq/Q+HRNS1guK7wd76iRR0ZTIA== X-Received: by 2002:ac8:5c0e:: with SMTP id i14mr34071929qti.328.1607998856671; Mon, 14 Dec 2020 18:20:56 -0800 (PST) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id w30sm16297156qkw.24.2020.12.14.18.20.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Dec 2020 18:20:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Sean Turner In-Reply-To: <9E04947B-8F6B-4899-9185-2BA07EB4CE40@gmail.com> Date: Mon, 14 Dec 2020 21:20:54 -0500 Cc: Netconf , Russ Housley , Kent Watsen , draft-ietf-netconf-sztp-csr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9E04947B-8F6B-4899-9185-2BA07EB4CE40@gmail.com> To: Mahesh Jethanandani X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netconf] IPR on draft-ietf-netconf-sztp-csr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 02:21:00 -0000 No I am not aware of any IPR that appleis to this draft. spt > On Dec 14, 2020, at 17:36, Mahesh Jethanandani = wrote: >=20 > Authors, Contributors, Working Group, >=20 > In preparation of sending the above documents for WGLC, we need to = find out if ... >=20 > Are you aware of any IPR that applies to above stated draft? >=20 > Please state: >=20 > "No, I'm not aware of any IPR that applies to these draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules = (see RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think = appropriate. >=20 > If you are listed as a document author or contributor please answer = the above by responding to this email regardless of whether or not you = are aware of any relevant IPR. This document will not advance to the = next stage until a response has been received from each author and = listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS = MESSAGE'S > TO LINES. >=20 > If you are on the WG email list or attend WG meetings but are not = listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed = above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Mahesh & Kent (as co-chairs) >=20 >=20 >=20 >=20 >=20 From nobody Tue Dec 15 09:43:20 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238083A12D2; Tue, 15 Dec 2020 09:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=QDXdPVlT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DwOx+DXV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqUxyj4rEtr0; Tue, 15 Dec 2020 09:43:14 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B4A3A12BE; Tue, 15 Dec 2020 09:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1790; q=dns/txt; s=iport; t=1608054194; x=1609263794; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=hw7C7C3BvHbr1d6eoK9GldbOMrBt7DsxYkT8d9cSk3Y=; b=QDXdPVlTIhMR6wcyvMU5eBCkeNwAsMOJIPV19LN6PZeSvazO2kgN1E47 +TkRVidGquuydiqRrpPVPQ1bCcGWhBKcnO75GPpSR6eknaUYv+rDoCj9s 5jdl32b9YWYGX8VO+mSkwqsuV7PuHmTlhCfIZ0cCQfDiKBhnVgKaLfQ9e k=; IronPort-PHdr: =?us-ascii?q?9a23=3AQMquYhG27yrW5FfwE5fnrp1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QObUoDS6vYCgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8n7blzW5Ha16G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DICgDP9Nhf/5NdJa1iHgEBCxIMQIM?= =?us-ascii?q?hIy4HdVsvLgqHfQONWpkNgUKBEQNUCwEBAQ0BASMKAgQBAYRKAoFwAiU4EwI?= =?us-ascii?q?DAQELAQEFAQEBAgEGBHGFYQyFdRYoBgEBMgUBEQEWKEImAQQBDQ0agwWCVQM?= =?us-ascii?q?uAQMLoj0CgTyIaXSBNIMEAQEFhSgYghAJgTiCdYovJhuBQT+BEUOCVoMQCwK?= =?us-ascii?q?BKgESASODSIIsgViBTwRSAYEAAlSQOKhJCoJ0iSOSSoMmgS6IeJRxlAWLDZF?= =?us-ascii?q?ogUaCbQIEAgQFAg4BAQWBbSNncHAVO4JpCUcXAg2OIYNxhRSFRHQCNQIGCgE?= =?us-ascii?q?BAwl8iEMBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.78,422,1599523200"; d="scan'208";a="815267389" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Dec 2020 17:43:13 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BFHhDgk010898 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Dec 2020 17:43:13 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Dec 2020 11:43:12 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Dec 2020 12:43:12 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 15 Dec 2020 11:43:11 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IrhoXwZ/k59LCzdgqoQH54/iq7wDmACE03/HCxUTjzbL9hd8ivvfmYQ0pqdlcmde8AbC8EvspXuwiSbtpYg2Fag5QOpRXEoq3YdsI/6YLZ3RfJa13dA3dd9fER28aq0Y+q/qx++3fofglVpDscaf10A582S+RpzqSjhivyqzdoSannI8rH8T8YD9kOuEkKeb/1Xyh/7NZEeywqiDf3Hd7le+4dB2tNoyw8TYObyJpM0RVmqoNKoswN0EhekdskPb/9MXVsx5vpmHfEz1vPXloXTCSPSlnYeNnOy3neV0oBLxbDYaFwxgCzmWJXvEiV3oGGDCS8RXvyDrGYONYLHIAg== 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=hw7C7C3BvHbr1d6eoK9GldbOMrBt7DsxYkT8d9cSk3Y=; b=fdLXbVjrrhIoe9Gc/ya7MzYJTxHuk5yvaXbgcFs/sfZZ/MDXl/f6wV3YqJpIDNmOddHlWQDCOHeQd953XF7x0YsbaZBmLGNfzO8QrVqEh8qmQTOKV7PfePCHhqY0Mjy6SN22sE6zMzRx+pe/Z/ntOR5zNxf5IpESMcsrixWoE+0DdeQV1tSpB+pXP7oJh6n6Lz5aNn/mggzTvccD4BWL/gAtxNaybASucGZ9CK/uAK3B1qoXzkWRHbP6bKaeKdcgRIC4POvwnFKVHbK+Ah7SouIEU8j3oHwDbrmYmKNFtRcxca0uBIVrBdxinAbQlJt/6r8sdIVXgo7D7axpqMj4uw== 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=hw7C7C3BvHbr1d6eoK9GldbOMrBt7DsxYkT8d9cSk3Y=; b=DwOx+DXV4GAfdpzTxEDtGH0M9JmTq35kTXP7l90fgf0wfYJJlo39lY9bN7kXJNwefcpueP3ucfjOGsM22oAmm18nHiGHrsZ76Ku1/hIsrvJQlO5RQSJP7mnmPjIL3w0gBwhWt7MOAszQgu2Ok8kd8QWW9fYTFokXw9ZtC/zzP1Q= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4581.namprd11.prod.outlook.com (2603:10b6:208:26c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Tue, 15 Dec 2020 17:43:10 +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.3654.021; Tue, 15 Dec 2020 17:43:10 +0000 From: "Rob Wilton (rwilton)" To: Mahesh Jethanandani , "kent+ietf@watsen.net" CC: "draft-ietf-netconf-https-notif@ietf.org" , "netconf@ietf.org" Thread-Topic: Regarding IPR on draft-ietf-netconf-https-notif-06 Thread-Index: AdbTAj0iURuLkQzDRvyS5K8t2uw06g== Date: Tue, 15 Dec 2020 17:43:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.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: 6edb0bd3-adff-46da-517a-08d8a120e3b2 x-ms-traffictypediagnostic: MN2PR11MB4581: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: x0WxVSb9d/9m10iDx6ahrNawjWcpmrc14U2V01HPiPYw+OVGcrJKV3ZTSxG1aPerfh/D+mY36i0D2s1g/5OJrUKifdpGeQDWP03UQLoWt7NWjWCIOzHhVGgFzsApMM6sdsbFpZe6tOaHoGxihMwdJpIoq96cfnraVkXIgHjvSa4xq68QasCuCreuPDi749EepwkoQ8qx6G/FAR9IxcFKa1Ht2+UZZCJFZx4RLFdihXIOh9dzRFJ+DrE23f6yGCT2R28tH6kiGffTvHK+fsEd7Ftmp5q+F8zhL2T3yPfwzFgmjbO2VjVC1mbBH/CQUNX126kb4Ns7CwmT+m3wWT1ewDC1RsAq0VogiD6ty6zxalRR9gWFxs7bw0WbAslLxVtLhvzWxYXX2IcgrAHR8ug95A== 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)(366004)(376002)(346002)(110136005)(76116006)(55016002)(6506007)(26005)(52536014)(83380400001)(33656002)(5660300002)(4326008)(8936002)(54906003)(71200400001)(186003)(66946007)(66446008)(66476007)(7696005)(8676002)(966005)(86362001)(64756008)(9686003)(508600001)(2906002)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?c7rFHKkeBRMgygYmZLDqn2J9hGqVCixqyWRexbcdE0p6wGaXdCQtcwr61W0p?= =?us-ascii?Q?FSDKgYKHKeW8OQBH81BXi1dtPM4S8tHavOoAhSaJ9Yp76kP1c/tNBGlqcFuJ?= =?us-ascii?Q?y5D+HaOiCMkk/RAa/ys0o9we0Inj6FYumEfThKB0mxhAa5L/BnqaweaqjqNQ?= =?us-ascii?Q?9akK0Pp58RDt8TOeZdYoTCC4vrClXLEGSf/tAVvMk3coCuHP18awJ+kqDNJR?= =?us-ascii?Q?Wda4F+3gqfG/iJAa7+/NCRJ27MkHOj2C89tDySyzF7yRZ5bDqGGGOIVN1EYI?= =?us-ascii?Q?IwYCNGb7UE5UZ+18A7wIVTaVBaNaXtWL/vQq+VlgLyykqFfdh7lzJRqjDdpZ?= =?us-ascii?Q?yxN0dSO2w3Bo1vgIC69ZYuh8e+3RfgHylDTrU0Pcmh6Wknqb75uchaSdwHrl?= =?us-ascii?Q?Dewg7Ol/Q8kNAnx6G/gCoXmd0VxzP46vDNg7W/gPwlXgoMjCwfFbNgi3yJf/?= =?us-ascii?Q?K5yPOCPJCm17rV8w0XN6YerjlZQErqJN0Pk32LUHihRK89qemgI5Kj0Ntp+O?= =?us-ascii?Q?fsILP1GlupW4jLUV03Ww4LXrXN6PiAwt6K489763asxiwelXFwHMZuSYM/dn?= =?us-ascii?Q?oua491G5z/wYsKAlgQnwXhfFZAKLMyEQRDrnXiBsvEdEj7vRSCunvxU+W4UM?= =?us-ascii?Q?7TAzi4ICIYoHWJPFIZgFCWIqeF2zRpmUivF/ChENtjdrpdCtpWc0MwfWRjpd?= =?us-ascii?Q?UksEKZVIlW3ypLPeeg+ZA0YLQ7Hic3FCRHpruJkcwBkcfmQFeRDlDjeikGbu?= =?us-ascii?Q?MW8ihy8SijmnYkiQv+4zlcMu2s+zZdgsgp4wQCQlaDxg8vAGWhUozxeCpxQL?= =?us-ascii?Q?B75YY20qqr+Y62CRUT/M/j8HCb+U3AzSs2snh8N2XIyf6rhGLV3FFgDAEJfw?= =?us-ascii?Q?QrfItwI9CX68vC45SarcjVsLIum/P1wKQde7R4imiHh5EoHgDwUIrU49BJOA?= =?us-ascii?Q?Nw0ooAxUoMNNnv9ai4/7H9uynPY34jRRB2Jw4dTGzvw=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: 6edb0bd3-adff-46da-517a-08d8a120e3b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2020 17:43:10.3185 (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: h/nzY1SQc1rcAMdXDfOQL0LipJz7qZ/1NwhtzIrn983ZZ9blPA+JRUroZ1fBJbOdi1rQBubDQ0cKIbs2NFHdzg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4581 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: [netconf] Regarding IPR on 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: Tue, 15 Dec 2020 17:43:19 -0000 Authors, Contributors, WG, As part of preparation for WG LC (which is planned for after the holidays): Are you aware of any IPR that applies to the draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. 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 (OPS AD) PS Please include all listed in the headers of this message in your response. From nobody Tue Dec 15 10:38:02 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482933A14EA; Tue, 15 Dec 2020 10:38:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tOKWdSEralsl; Tue, 15 Dec 2020 10:37:58 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 988863A14D7; Tue, 15 Dec 2020 10:37:58 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id 11so15018988pfu.4; Tue, 15 Dec 2020 10:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UVF/j75w7+L7XIEcn9yaMInNOe1nVFz06mDECI0/wSI=; b=c6WHHEuzyxJQJO6vl7daYP7pRnJJ2ZxsFRQF/Cvezf7LYl9z9IWDrEu7FWCmvsAdB9 RrKGPNdybGHoq4YZ/ROMfyvCIgNnmgNe2NhKluqg0bumRs8qUIxb+A8J15u9sObzJyRH yZnoq2CBtnEKa8xwHkXg4ms7/bBsZsDP/GVk9bLG71qnkLFKqz++q74wDEaXVBQaVnRl IYhQIYEfauPKeL6YrgULQf/dahnojCc5rdo/GeIl6rpPUS6oPUADwt+i7uakJjfdcgcq VhQ9BtkFYejcmQPuwtmrCuJu2LRYxeVe8l19xJYPp7a+OF6AL8DSUes4NLwiYZe97rk+ A4nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UVF/j75w7+L7XIEcn9yaMInNOe1nVFz06mDECI0/wSI=; b=uGis5J9xjaxDWTgDfq4y6idp4jt6FrRxEybXPBbJ1ucfvXu0YaR8jQ0Lh6vVUXQvTW 8jVHrkzwdGJRNjRo7nUIivr7655ejiV8CU8zgaphdapZrrfgqecR7h8aK5JnAAjp2N1z OU3Vi5n/0gb5YlxfFYKPsenXslC9WCpuQ+oAS3bJH/iR04Gq/Qopk7XCbGPE70/JfNx4 l8DW02eBFifzEiXUaPCfyckmsvJuQEhGFvBJWubO+/iX7XDi6XsgEwKWYaBponkXZAPi RLfdL9OrqmCkhJ8bwsfPzTGVkHeLQyxukOBtEwIEVUtIXzt/gwisq7XlZ/KU8ZFcAXeA lzfw== X-Gm-Message-State: AOAM532t3fKtr8RPXc7esH9tq0WKq6WTDu21JQRArv572108bP9geXqn GI/UFRwD3mzzO4WBKpeoQQ0= X-Google-Smtp-Source: ABdhPJzm6MxfNNfa81ZWC4s3RG+s+KnzCREwTCKa2c/JNFBHVlDL6qyg3z6oQ3jV4fngXKJM/fsHfg== X-Received: by 2002:a65:44c2:: with SMTP id g2mr30269975pgs.256.1608057477948; Tue, 15 Dec 2020 10:37:57 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:1142:ad9:dab3:7838? ([2601:647:5600:5020:1142:ad9:dab3:7838]) by smtp.gmail.com with ESMTPSA id f7sm23032942pfe.30.2020.12.15.10.37.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Dec 2020 10:37:57 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_22CF8D52-B6B2-4848-91D2-7C597AC88A86" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 15 Dec 2020 10:37:56 -0800 In-Reply-To: Cc: "kent+ietf@watsen.net" , "draft-ietf-netconf-https-notif@ietf.org" , "netconf@ietf.org" To: Robert Wilton References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netconf] Regarding IPR on 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: Tue, 15 Dec 2020 18:38:00 -0000 --Apple-Mail=_22CF8D52-B6B2-4848-91D2-7C597AC88A86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No, I am not not aware of any IPR that applies to this draft. Thanks. > On Dec 15, 2020, at 9:43 AM, Rob Wilton (rwilton) = wrote: >=20 > Authors, Contributors, WG, >=20 > As part of preparation for WG LC (which is planned for after the = holidays): >=20 > Are you aware of any IPR that applies to the draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 >=20 > If you are listed as a document author or contributor please answer = the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author. >=20 > NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. >=20 > If you are on the WG email list or attend WG meetings but are not = listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed = above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=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 = document. >=20 > Thank you, > Rob (OPS AD) >=20 > PS Please include all listed in the headers of this message in your > response. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_22CF8D52-B6B2-4848-91D2-7C597AC88A86 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii No, = I am not not aware of any IPR that applies to this draft. Thanks.

On Dec 15, 2020, at 9:43 AM, Rob Wilton (rwilton) <rwilton@cisco.com> = wrote:

Authors, Contributors, WG,

As = part of preparation for WG LC (which is planned for after the = holidays):

Are you aware of any IPR that = applies to the draft identified above?

Please= state either:

"No, I'm not aware of any = IPR that applies to this draft"
or
"Yes, I'm = aware of IPR that applies to this draft"

If = so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance = with IETF IPR rules"
or
"No, the IPR has not = been disclosed"

If you answer no, please = provide any additional details you think
appropriate.


If you are listed as a document = author or contributor please answer the
above by = responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to = the next
stage until a response has been received from = each author.

NOTE: THIS APPLIES TO ALL OF = YOU LISTED IN THIS MESSAGE'S TO LINES.

If = you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your = obligations under
the IETF IPR rules which encourages you = to notify the IETF if you are
aware of IPR of others on an = IETF contribution, or to refrain from
participating in any = contribution or discussion related to your
undisclosed = IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPro= perty.

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 (OPS AD)

PS Please include all listed in the headers of = this message in your
response.

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_22CF8D52-B6B2-4848-91D2-7C597AC88A86-- From nobody Tue Dec 15 11:40:19 2020 Return-Path: <0100017667eade5b-5276e200-ffc8-4236-9771-4ff0abc621fa-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 405CA3A16EA; Tue, 15 Dec 2020 11:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JQYRIRJqwbk; Tue, 15 Dec 2020 11:40:15 -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 9A0033A16E9; Tue, 15 Dec 2020 11:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1608061214; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=9/qV1R8BdDnZAPQIeWXoT0IEH2HXeaRRuz8BvaHfmMQ=; b=iMcC/NiKHI73Xba0XtScKsQnUDxlxMAPhCBfptGj/wgyoWmA3QJZadJOCNcSCozE 3ZcnjbNb4/20IpwxkFyWEsODu/Q4WLrDpTzKDiS9aZiSHpfT0d4Yhn/HJnqi5Ukp/71 LGAn1s2nd60eq863QqFus+Y1Uvg5iMGdMJytiKY8= From: Kent Watsen Message-ID: <0100017667eade5b-5276e200-ffc8-4236-9771-4ff0abc621fa-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C08203F7-7AD3-476D-BA1F-6840C1643A3A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 15 Dec 2020 19:40:14 +0000 In-Reply-To: Cc: Mahesh Jethanandani , "draft-ietf-netconf-https-notif@ietf.org" , "netconf@ietf.org" To: "Rob Wilton (rwilton)" References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.12.15-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Regarding IPR on 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: Tue, 15 Dec 2020 19:40:17 -0000 --Apple-Mail=_C08203F7-7AD3-476D-BA1F-6840C1643A3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No, I am not not aware of any IPR that applies to this draft. Kent (as co-author) > On Dec 15, 2020, at 12:43 PM, Rob Wilton (rwilton) = wrote: >=20 > Authors, Contributors, WG, >=20 > As part of preparation for WG LC (which is planned for after the = holidays): >=20 > Are you aware of any IPR that applies to the draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 >=20 > If you are listed as a document author or contributor please answer = the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author. >=20 > NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. >=20 > If you are on the WG email list or attend WG meetings but are not = listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed = above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=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 = document. >=20 > Thank you, > Rob (OPS AD) >=20 > PS Please include all listed in the headers of this message in your > response. --Apple-Mail=_C08203F7-7AD3-476D-BA1F-6840C1643A3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii No, = I am not not aware of any IPR that applies to this draft.

Kent (as co-author)


On Dec = 15, 2020, at 12:43 PM, Rob Wilton (rwilton) <rwilton@cisco.com> = wrote:

Authors, Contributors, WG,

As = part of preparation for WG LC (which is planned for after the = holidays):

Are you aware of any IPR that = applies to the draft identified above?

Please= state either:

"No, I'm not aware of any = IPR that applies to this draft"
or
"Yes, I'm = aware of IPR that applies to this draft"

If = so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance = with IETF IPR rules"
or
"No, the IPR has not = been disclosed"

If you answer no, please = provide any additional details you think
appropriate.


If you are listed as a document = author or contributor please answer the
above by = responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to = the next
stage until a response has been received from = each author.

NOTE: THIS APPLIES TO ALL OF = YOU LISTED IN THIS MESSAGE'S TO LINES.

If = you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your = obligations under
the IETF IPR rules which encourages you = to notify the IETF if you are
aware of IPR of others on an = IETF contribution, or to refrain from
participating in any = contribution or discussion related to your
undisclosed = IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPro= perty.

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 (OPS AD)

PS Please include all listed in the headers of = this message in your
response.

= --Apple-Mail=_C08203F7-7AD3-476D-BA1F-6840C1643A3A-- From nobody Tue Dec 22 06:34:40 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296A13A10DA for ; Tue, 22 Dec 2020 06:34:39 -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 zvHL8nReYyvw for ; Tue, 22 Dec 2020 06:34:36 -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 906E03A107C for ; Tue, 22 Dec 2020 06:34:36 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 775F6F40744; Tue, 22 Dec 2020 06:34:14 -0800 (PST) To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, 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: <20201222143414.775F6F40744@rfc-editor.org> Date: Tue, 22 Dec 2020 06:34:14 -0800 (PST) Archived-At: Subject: [netconf] [Technical Errata Reported] RFC8040 (6362) 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, 22 Dec 2020 14:34:39 -0000 The following errata report has been submitted for RFC8040, "RESTCONF Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6362 -------------------------------------- Type: Technical Reported by: Muly Ilan Section: 4.3. Original Text ------------- The client might request the response header fields for an XML representation of a specific "album" resource: GET /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com Accept: application/yang-data+xml The server might respond as follows: HTTP/1.1 200 OK Date: Thu, 26 Jan 2017 20:56:30 GMT Server: example-server Content-Type: application/yang-data+xml Cache-Control: no-cache ETag: "a74eefc993a2b" Last-Modified: Thu, 26 Jan 2017 14:02:14 GMT Corrected Text -------------- The client might request the response header fields for an XML representation of a specific "album" resource: GET /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com Accept: application/yang-data+xml The server might respond as follows: HTTP/1.1 200 OK Date: Thu, 26 Jan 2017 20:56:30 GMT Server: example-server Content-Type: application/yang-data+xml Cache-Control: no-cache Notes ----- Removed the "ETag" and "Last-Modified" header fields. According to Appendix B.3.1. : To retrieve only the configuration child resources, the "content" parameter is set to "config". Note that the "ETag" and "Last-Modified" headers are only returned if the "content" parameter value is "config". Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8040 (draft-ietf-netconf-restconf-18) -------------------------------------- Title : RESTCONF Protocol Publication Date : January 2017 Author(s) : A. Bierman, M. Bjorklund, K. Watsen Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Dec 22 06:40:10 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E21D3A10DA for ; Tue, 22 Dec 2020 06:40: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 rtIiNlFi99E7 for ; Tue, 22 Dec 2020 06:40:06 -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 E4B263A10D4 for ; Tue, 22 Dec 2020 06:40:06 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id F33E8F40744; Tue, 22 Dec 2020 06:39:49 -0800 (PST) To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, 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: <20201222143949.F33E8F40744@rfc-editor.org> Date: Tue, 22 Dec 2020 06:39:49 -0800 (PST) Archived-At: Subject: [netconf] [Technical Errata Reported] RFC8040 (6363) 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, 22 Dec 2020 14:40:08 -0000 The following errata report has been submitted for RFC8040, "RESTCONF Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6363 -------------------------------------- Type: Technical Reported by: Muly Ilan Section: 4.8.2. Original Text ------------- By default, the server will include all sub-resources within a retrieved resource that have the same resource type as the requested resource. The exception is the datastore resource. If this resource type is retrieved, then by default the datastore and all child data resources are returned. Corrected Text -------------- By default, the server SHOULD include all sub-resources within a retrieved resource that have the same resource type as the requested resource. The exception is the datastore resource. If this resource type is retrieved, then by default the datastore and all child data resources are returned. Notes ----- Substitute "will" by "SHOULD". Use one of the keywords of RFC2119 to clarify the expected server behavior. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8040 (draft-ietf-netconf-restconf-18) -------------------------------------- Title : RESTCONF Protocol Publication Date : January 2017 Author(s) : A. Bierman, M. Bjorklund, K. Watsen Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Dec 22 06:57:57 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D0B3A10ED for ; Tue, 22 Dec 2020 06:57:55 -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 GLcO1Byejw1j for ; Tue, 22 Dec 2020 06:57:53 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFB33A10E9 for ; Tue, 22 Dec 2020 06:57:53 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id a12so32634136lfl.6 for ; Tue, 22 Dec 2020 06:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YxOEu5ciGxQnEJy/HExvlZKB+quTxiOq83PF3BYrzYc=; b=oxRsAxgXSQZZr06jxhKys+AfhJNsct+7bTaGd1hHSckv4/qOB3riSJSL1iSq9MH0Ij xlIxuP48qNm5eT69i/5OI58Gq8h3uWLZsc0tWuEaiu3jRy5QCgqn1bwADGuxulIrMbLX x9HcSzzKtJ3URW/FTs08oWxoaNw1U+hk5mtQRE9GIYxqrBpDsD2GUn98QdiUb6ODlm1Z MYHjw/SJbA+Ug18JoD6P19PeoY0Skj26Nt2CnzZ23/FPYguCoqbVA3u7/WMpX8WeIj5o 930xQsapsHIDFVkDo6elUDae82fBmLHSpYmkgFbEvKQ8o9U0HCxNly3hyFwu36FWonOc Nb9w== 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=YxOEu5ciGxQnEJy/HExvlZKB+quTxiOq83PF3BYrzYc=; b=HQstcrQmfFrTXmm432OPBLpAcCVqBFqYg5N2hJwDJxd3TPxXRVq1ck4LVXxriDePRi 62mdmnAY8tdL5dBzqZfTFpoHqiqrE+P0IECz9DrzepKK3NnS776o2VY+MA6JsIYIMZpB Kcjn/A1t3cxO6Nlp56FtYJZlmJfy6wU4LiYUxQZEJknTJzLc7s84rhxZV3OyiS30mw5o wfYd61kgMWAdDch61yS06D9GLAwILw+efWnfQPM/N1pCOil3ITcgkDhjlxT2yMbZxdJ5 YstAhz9tQxj9a8bcd3PVWyZyRcQAtAKoNYO53pUykeZb3LeeiK8ZTl8w9daQpXRU6BiZ 2sZA== X-Gm-Message-State: AOAM531oTezVDuGwTYiV14gyP8KMBkA+9hd8/M1zQru2PMz13mv2YEMT ROEtSSbFMayXBEcZ9/ZljIpQDXAY3NXQT7Io0KJDbQ== X-Google-Smtp-Source: ABdhPJzHmbuHweaQRFDfaQRED7yHxY++ybFgsmqoTMik4YJtsr6a0wCUmgxdqHkR0ptIMmg6WYnn+eap4oBZGPGJXPg= X-Received: by 2002:a05:651c:1342:: with SMTP id j2mr10552955ljb.91.1608649071607; Tue, 22 Dec 2020 06:57:51 -0800 (PST) MIME-Version: 1.0 References: <20201222143414.775F6F40744@rfc-editor.org> In-Reply-To: <20201222143414.775F6F40744@rfc-editor.org> From: Andy Bierman Date: Tue, 22 Dec 2020 06:57:40 -0800 Message-ID: To: RFC Errata System Cc: Martin Bjorklund , Kent Watsen , Warren Kumari , Robert Wilton , Kent Watsen , Mahesh Jethanandani , muly_i@rad.com, Netconf Content-Type: multipart/alternative; boundary="0000000000007b590e05b70eccc8" Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6362) 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, 22 Dec 2020 14:57:55 -0000 --0000000000007b590e05b70eccc8 Content-Type: text/plain; charset="UTF-8" Hi, This Errata should be rejected. The cited text in non-normative Appendix B.3.1 is actually wrong. The parameter content=all can also return these fields for configuration data. The normative text in 3.5.2 explains what to do. 3.5.2 . Entity-Tag For configuration data resources, the server SHOULD maintain a resource entity-tag for each resource and return the "ETag" header field when it is retrieved as the target resource with the GET or HEAD methods. If maintained, the resource entity-tag MUST be updated whenever the resource or any configuration resource within the resource is altered. If not maintained, then the resource entity-tag for the datastore MUST be used instead. Andy On Tue, Dec 22, 2020 at 6:34 AM RFC Errata System wrote: > The following errata report has been submitted for RFC8040, > "RESTCONF Protocol". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6362 > > -------------------------------------- > Type: Technical > Reported by: Muly Ilan > > Section: 4.3. > > Original Text > ------------- > The client might request the response header fields for an XML > representation of a specific "album" resource: > > GET /restconf/data/example-jukebox:jukebox/\ > library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 > Host: example.com > Accept: application/yang-data+xml > > The server might respond as follows: > > HTTP/1.1 200 OK > Date: Thu, 26 Jan 2017 20:56:30 GMT > Server: example-server > Content-Type: application/yang-data+xml > Cache-Control: no-cache > ETag: "a74eefc993a2b" > Last-Modified: Thu, 26 Jan 2017 14:02:14 GMT > > Corrected Text > -------------- > The client might request the response header fields for an XML > representation of a specific "album" resource: > > GET /restconf/data/example-jukebox:jukebox/\ > library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 > Host: example.com > Accept: application/yang-data+xml > > The server might respond as follows: > > HTTP/1.1 200 OK > Date: Thu, 26 Jan 2017 20:56:30 GMT > Server: example-server > Content-Type: application/yang-data+xml > Cache-Control: no-cache > > > Notes > ----- > Removed the "ETag" and "Last-Modified" header fields. > > According to Appendix B.3.1. : > To retrieve only the configuration child resources, the "content" > parameter is set to "config". Note that the "ETag" and > "Last-Modified" headers are only returned if the "content" parameter > value is "config". > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8040 (draft-ietf-netconf-restconf-18) > -------------------------------------- > Title : RESTCONF Protocol > Publication Date : January 2017 > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > --0000000000007b590e05b70eccc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This Errata should be re= jected.
The cited text in non-normative Appendix B.3.1 is actuall= y wrong.
The parameter content=3Dall can also return these fields= for configuration data.


The normat= ive text in 3.5.2 explains what to do.


<= div>
3.5.2.  Entity-Tag


   For configuration data resources, the server SHOULD maintain a
   resource entity-tag for each resource and return the "ETag" he=
ader
   field when it is retrieved as the target resource with the GET or
   HEAD methods.  If maintained, the resource entity-tag MUST be updated
   whenever the resource or any configuration resource within the
   resource is altered.  If not maintained, then the resource entity-tag
   for the datastore MUST be used instead.


An= dy

On Tue, Dec 22, 2020 at 6:34 AM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
=
The following errata repo= rt has been submitted for RFC8040,
"RESTCONF Protocol".

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

--------------------------------------
Type: Technical
Reported by: Muly Ilan <muly_i@rad.com>

Section: 4.3.

Original Text
-------------
=C2=A0 =C2=A0The client might request the response header fields for an XML=
=C2=A0 =C2=A0representation of a specific "album" resource:

=C2=A0 =C2=A0 =C2=A0 GET /restconf/data/example-jukebox:jukebox/\
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0library/artist=3DFoo%20Fighters/album=3DW= asting%20Light HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 Host: example.com
=C2=A0 =C2=A0 =C2=A0 Accept: application/yang-data+xml

=C2=A0 =C2=A0The server might respond as follows:

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK
=C2=A0 =C2=A0 =C2=A0 Date: Thu, 26 Jan 2017 20:56:30 GMT
=C2=A0 =C2=A0 =C2=A0 Server: example-server
=C2=A0 =C2=A0 =C2=A0 Content-Type: application/yang-data+xml
=C2=A0 =C2=A0 =C2=A0 Cache-Control: no-cache
=C2=A0 =C2=A0 =C2=A0 ETag: "a74eefc993a2b"
=C2=A0 =C2=A0 =C2=A0 Last-Modified: Thu, 26 Jan 2017 14:02:14 GMT

Corrected Text
--------------
=C2=A0 =C2=A0The client might request the response header fields for an XML=
=C2=A0 =C2=A0representation of a specific "album" resource:

=C2=A0 =C2=A0 =C2=A0 GET /restconf/data/example-jukebox:jukebox/\
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0library/artist=3DFoo%20Fighters/album=3DW= asting%20Light HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 Host: example.com
=C2=A0 =C2=A0 =C2=A0 Accept: application/yang-data+xml

=C2=A0 =C2=A0The server might respond as follows:

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK
=C2=A0 =C2=A0 =C2=A0 Date: Thu, 26 Jan 2017 20:56:30 GMT
=C2=A0 =C2=A0 =C2=A0 Server: example-server
=C2=A0 =C2=A0 =C2=A0 Content-Type: application/yang-data+xml
=C2=A0 =C2=A0 =C2=A0 Cache-Control: no-cache


Notes
-----
Removed the "ETag" and "Last-Modified" header fields.
According to Appendix B.3.1. :
=C2=A0 =C2=A0To retrieve only the configuration child resources, the "= content"
=C2=A0 =C2=A0parameter is set to "config".=C2=A0 Note that the &q= uot;ETag" and
=C2=A0 =C2=A0"Last-Modified" headers are only returned if the &qu= ot;content" parameter
=C2=A0 =C2=A0value is "config".

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

--------------------------------------
RFC8040 (draft-ietf-netconf-restconf-18)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: RESTCONF Prot= ocol
Publication Date=C2=A0 =C2=A0 : January 2017
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A. Bierman, M. Bjorklun= d, K. Watsen
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Configurat= ion
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operations an= d Management
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--0000000000007b590e05b70eccc8-- From nobody Tue Dec 22 07:06:36 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F68A3A10FD for ; Tue, 22 Dec 2020 07:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rad365.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 zJM1HIjo7zDI for ; Tue, 22 Dec 2020 07:06:31 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80072.outbound.protection.outlook.com [40.107.8.72]) (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 EB5243A10F3 for ; Tue, 22 Dec 2020 07:06:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hj2Op36GSNaH9wllteLrEILrosZ78ZMO+x5iXFqBLSJQmVYRdJzaqN/gnVxDF2BWgOjro14XRG4KVPPeyV20EZEO34LY5zx+ObOQgclJvMVBeP0nEOSJp9AHdECPlS93+QWCBfA/qapZDih58IfkJc2SFeU1FSqVlKJ+3V3AqsNAGSMTWi41t8eg7sukM5vm8l5P6hPLweOHa+B0T4Rob8epxtmSfGK91xGcbyANRV9twxS7ScxuPfURIH4BLAoHDKkNq3TkPnG3l23mlBbGb+B0acQs7LEosLSxVljlGD6aZrfELz0Rv3Yet3hSimwneRocmIgxWTtovcGmpHGXCQ== 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=eVIe7JUZDC4hmH/IkljqbmyOpn9JFXcbe5Hcf3iVjNY=; b=Go4w42Zhn48IAIrSA/YUhiBGLp+yLPlj8dCrFgxFLpymIH3Y0bSeSOb2kU59S38M/wX+K9ZUbDwrZs682OOKfBk8qfbZc3+l98cGPnjcciPH34Hkek5WBPmlpQ7aOsBnAf2X6Y4DCBw0BJoTLTxzxfoVQHmw3/4VMbHyYQmUHtZ7Mt18hC7Nc+wHlZgR2OXLx6JjoYg3Ahv/M2qIRO8lnYkBSFOwaXdG3iB6MHfiGZp8wGLGfHRYVIMuRWrVw8nZsydNNHrw7i2C/CXNEh33VNBD7pHQWx/1wZ+sLD6FsBXYlycVTT/ZxtqSDjdFA/Q7r0ezmZNZ2nvlMJt0r7SInQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rad.com; dmarc=pass action=none header.from=rad.com; dkim=pass header.d=rad.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rad365.onmicrosoft.com; s=selector1-rad365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eVIe7JUZDC4hmH/IkljqbmyOpn9JFXcbe5Hcf3iVjNY=; b=AJuqOa9zpkVMRJCWllO6X6b7F/oL89aNgoIGR/uBtaFpf8vbwQ4idQTD2saYR5Vz26MbIT2SNmb8zKCuNI9gDOfF8q9ehtLYe0Mh/HELStgmUlq+MYVRdbcDrVX/8/spPyN7HO/QUW9ZVS+I4FXSWPyS736TxqS4yxFghhla99k= Received: from AM0PR0302MB3348.eurprd03.prod.outlook.com (2603:10a6:208:b::19) by AM0PR03MB5779.eurprd03.prod.outlook.com (2603:10a6:208:171::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.33; Tue, 22 Dec 2020 15:06:21 +0000 Received: from AM0PR0302MB3348.eurprd03.prod.outlook.com ([fe80::eccb:ec09:89e2:cd70]) by AM0PR0302MB3348.eurprd03.prod.outlook.com ([fe80::eccb:ec09:89e2:cd70%5]) with mapi id 15.20.3676.033; Tue, 22 Dec 2020 15:06:21 +0000 From: Muly Ilan To: Andy Bierman , RFC Errata System CC: Martin Bjorklund , Kent Watsen , Warren Kumari , Robert Wilton , Kent Watsen , Mahesh Jethanandani , Netconf Thread-Topic: [Technical Errata Reported] RFC8040 (6362) Thread-Index: AQHW2G+T4dcPBAr/1UuNVk6Y0Yvs3aoDNLcAgAAAv5A= Date: Tue, 22 Dec 2020 15:06:21 +0000 Message-ID: References: <20201222143414.775F6F40744@rfc-editor.org> 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=rad.com; x-originating-ip: [185.223.3.181] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2ce69fc1-4d7f-4edc-8399-08d8a68b2484 x-ms-traffictypediagnostic: AM0PR03MB5779: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: z3oiQNJZJrn7SGn11Xr4dlZuQjjk22TLxrPKJ75YVMz8W+UYgPEpGb9gMinH6uNnAolLmHeWkhZoLS+CR3zLI4fX+d5tfzf8TOJgOxuBbw7jJX4tGmAnw3UJaDtZmHnQnSuFr/tSHIfUF2UZpj10PMxb/Ob1tfSMmVfhhUzm6ao3CYYkazwOrvvvMuBwDG16vTUUfP4y6WDwES5VJRF6zBbkAcsO8iEkWM5JQ7cYqFx4G8izLLYxAK/CHkdf8urSmvY4DZr0gAgESa8KLAXOe1IGdG0zOt8lbqRXf3YT1EiyzxsT18UgzSYPWGaUlpqnRYraFrZodBwsGIfQ6yzhKsxnMjW8BjzzrkZvllocybfXCZlekagHf9pG4J9Wk7G5EIzGUCh9C6PDW/5lKaihnkx8Z6uYHfs/y9rQVDhgvN7fYcfWwD3fbqi3GHhFtsqUsQgjI4GTKEyQSmtVrtQtMQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0302MB3348.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(376002)(136003)(39850400004)(346002)(186003)(66476007)(5660300002)(166002)(71200400001)(52536014)(76116006)(8936002)(966005)(33656002)(26005)(478600001)(9326002)(8676002)(54906003)(4326008)(64756008)(86362001)(53546011)(83380400001)(66446008)(316002)(6506007)(66556008)(55016002)(66946007)(7696005)(2906002)(110136005)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?WGhzHgmQ3CBL9+R440jeRwckYZ8KDWirR6+LK69Ltce0hcCI6C3dxEmJx2O2?= =?us-ascii?Q?L8v7xbtUDjLE0f5HwmlMoXa6ecIdzIPZClBPBxwWb3oWfUMorM9OAT/B4Yum?= =?us-ascii?Q?VVvhYK8s0Js0ciQ2bFtBr7U787KZGZibcVcUyJKo3SsfTzi/6W2JYs3ngea7?= =?us-ascii?Q?3Gq6rivuz6M0D/Kpwk5X6JQnV4QByrTPUJugHDhHmc4FRXnofETkNppRqpLw?= =?us-ascii?Q?HdD0fm9QNTlSgNoHjrazxRSDdb+jn6t7er7RtIncoTGXoiJnV5NDDROGYknz?= =?us-ascii?Q?EWC5Ij070XXQBTyUrNwQQECWPik6gGxbOpKihCY03R8h0ITrpNMejbs9qwfB?= =?us-ascii?Q?WjKSKzWn+jAPiRxy045yd3icaML4b3VtQt9McHks7OHqq8IMwT+F4nHW+Wxc?= =?us-ascii?Q?9g+/oePQlb+E5PIJnaSc6TqH9Uv2A+j6ZpbZkRydlxUN1B24ZHGmhz+pgpZ7?= =?us-ascii?Q?pbq2H4HVWxpF2XprRnvcgiYrsdXbvJmjiykZQUIdgGU+hZtf4gAlXJtD7MzN?= =?us-ascii?Q?kSNsw+n4kCvMIMai2g/hACRdAz71hqkKRbv3eCjpJZkZIqFhjA8WChKkUBkn?= =?us-ascii?Q?+CmhSEapW0DIhuVR5in0qNJF7287ZuQoJTCQoMjhWUDmuMcJ3hadh6l9ZRhy?= =?us-ascii?Q?qWvJmvKV/53dzKt+wd0OsmL2BS/0pr/taEARslsiU+ikYHibrh9/l7ak43OS?= =?us-ascii?Q?xcdZO7kxVTAJNbJU87F9LP6aDhCxw/Ry0zgTLlXeFUo5vW0cJeJGvknTJ+Od?= =?us-ascii?Q?yEB472bnAUAhYT7PxOxWVmBDHxmSZlmaVuRW/FcQ3CM2/4tBXHpxvL7gBNf3?= =?us-ascii?Q?TwdpiuLPncQqRSxdddMu09Zy7B1hI+CPM7V04nroFlB41wpNSzJAfHkGxk29?= =?us-ascii?Q?7WY3NCBxBxHwO/3eV8qA4/lqUQI1OOthBTd1NOs7QDqTVgqZ1txeHmUbEneP?= =?us-ascii?Q?/66k2wY5JoSz/srryUpvES0d+DCX497Zmt0bcP8JmVE=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR0302MB334880AA27135AD9F4394663F9DF0AM0PR0302MB3348_" MIME-Version: 1.0 X-OriginatorOrg: rad.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR0302MB3348.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ce69fc1-4d7f-4edc-8399-08d8a68b2484 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2020 15:06:21.5154 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f9047108-cc2c-4e48-97a3-43fad1b3bf9d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZapsPxu1JvKhm841pXli6zw/lNQhMEnQCAwwezmCHSPi9W3ySPcJgR2pCmcj8qad X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB5779 Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6362) 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, 22 Dec 2020 15:06:34 -0000 --_000_AM0PR0302MB334880AA27135AD9F4394663F9DF0AM0PR0302MB3348_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, You are saying that the text in Appendix B.3.1 is wrong. Understood. Please note that there's a specific example for "content=3Dall" in Appendix= B.3.1. In this example the "ETag" and "Last-Modified" header fields are n= ot used. I was looking for a well-defined behavior for all the three options of the = "content" query parameter. Thanks, Muly From: Andy Bierman [mailto:andy@yumaworks.com] Sent: 22/12/2020 16:58 To: RFC Errata System Cc: Martin Bjorklund ; Kent Watsen ; W= arren Kumari ; Robert Wilton ; Kent W= atsen ; Mahesh Jethanandani = ; Muly Ilan ; Netconf Subject: Re: [Technical Errata Reported] RFC8040 (6362) Hi, This Errata should be rejected. The cited text in non-normative Appendix B.3.1 is actually wrong. The parameter content=3Dall can also return these fields for configuration = data. The normative text in 3.5.2 explains what to do. 3.5.2. Entity-Tag For configuration data resources, the server SHOULD maintain a resource entity-tag for each resource and return the "ETag" header field when it is retrieved as the target resource with the GET or HEAD methods. If maintained, the resource entity-tag MUST be updated whenever the resource or any configuration resource within the resource is altered. If not maintained, then the resource entity-tag for the datastore MUST be used instead. Andy On Tue, Dec 22, 2020 at 6:34 AM RFC Errata System > wrote: The following errata report has been submitted for RFC8040, "RESTCONF Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6362 -------------------------------------- Type: Technical Reported by: Muly Ilan > Section: 4.3. Original Text ------------- The client might request the response header fields for an XML representation of a specific "album" resource: GET /restconf/data/example-jukebox:jukebox/\ library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 Host: example.com Accept: application/yang-data+xml The server might respond as follows: HTTP/1.1 200 OK Date: Thu, 26 Jan 2017 20:56:30 GMT Server: example-server Content-Type: application/yang-data+xml Cache-Control: no-cache ETag: "a74eefc993a2b" Last-Modified: Thu, 26 Jan 2017 14:02:14 GMT Corrected Text -------------- The client might request the response header fields for an XML representation of a specific "album" resource: GET /restconf/data/example-jukebox:jukebox/\ library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 Host: example.com Accept: application/yang-data+xml The server might respond as follows: HTTP/1.1 200 OK Date: Thu, 26 Jan 2017 20:56:30 GMT Server: example-server Content-Type: application/yang-data+xml Cache-Control: no-cache Notes ----- Removed the "ETag" and "Last-Modified" header fields. According to Appendix B.3.1. : To retrieve only the configuration child resources, the "content" parameter is set to "config". Note that the "ETag" and "Last-Modified" headers are only returned if the "content" parameter value is "config". Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8040 (draft-ietf-netconf-restconf-18) -------------------------------------- Title : RESTCONF Protocol Publication Date : January 2017 Author(s) : A. Bierman, M. Bjorklund, K. Watsen Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG --_000_AM0PR0302MB334880AA27135AD9F4394663F9DF0AM0PR0302MB3348_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 

You are saying that the text in Appen= dix B.3.1 is wrong. Understood.

 

Please note that there’s a spec= ific example for “content=3Dall” in Appendix B.3.1.  In th= is example the “ETag” and “Last-Modified” header fi= elds are not used.

I was looking for a well-defined beha= vior for all the three options of the “content” query parameter= .

 

Thanks,

 

Muly

 

From: Andy Bierman [mailto:andy@yuma= works.com]
Sent: 22/12/2020 16:58
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: Martin Bjorklund <mbj@tail-f.com>; Kent Watsen <kwatsen= @juniper.net>; Warren Kumari <warren@kumari.net>; Robert Wilton &l= t;rwilton@cisco.com>; Kent Watsen <kent+ietf@watsen.net>; Mahesh J= ethanandani <mjethanandani@gmail.com>; Muly Ilan <muly_i@rad.com&g= t;; Netconf <netconf@ietf.org>
Subject: Re: [Technical Errata Reported] RFC8040 (6362)

 

Hi,

 

This Errata should be rejected.

The cited text in non-normative Appendix B.3.1 is ac= tually wrong.

The parameter content=3Dall can also return these fi= elds for configuration data.

 

 

The normative text in 3.5.2 explains what to do.

 

 

3.5.2.  Entity-Tag

 
 
   For configuration data resour=
ces, the server SHOULD maintain a
   resource entity-tag for each =
resource and return the "ETag" header
   field when it is retrieved as=
 the target resource with the GET or
   HEAD methods.  If mainta=
ined, the resource entity-tag MUST be updated
   whenever the resource or any =
configuration resource within the
   resource is altered.  If=
 not maintained, then the resource entity-tag
   for the datastore MUST be use=
d instead.

 

 

Andy

 

On Tue, Dec 22, 2020 at 6:34 AM RFC Errata System &l= t;rfc-editor@rfc-editor.org> wrote:

The following errata report has been submitted for R= FC8040,
"RESTCONF Protocol".

--------------------------------------
You may review the report below and at:
h= ttps://www.rfc-editor.org/errata/eid6362

--------------------------------------
Type: Technical
Reported by: Muly Ilan <muly_i@rad.com>

Section: 4.3.

Original Text
-------------
   The client might request the response header fields for an XML=
   representation of a specific "album" resource:

      GET /restconf/data/example-jukebox:jukebox/\
         library/artist=3DFoo%20Fighters/album=3DW= asting%20Light HTTP/1.1
      Host: example.com
      Accept: application/yang-data+xml

   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server
      Content-Type: application/yang-data+xml
      Cache-Control: no-cache
      ETag: "a74eefc993a2b"
      Last-Modified: Thu, 26 Jan 2017 14:02:14 GMT

Corrected Text
--------------
   The client might request the response header fields for an XML=
   representation of a specific "album" resource:

      GET /restconf/data/example-jukebox:jukebox/\
         library/artist=3DFoo%20Fighters/album=3DW= asting%20Light HTTP/1.1
      Host: example.com
      Accept: application/yang-data+xml

   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server
      Content-Type: application/yang-data+xml
      Cache-Control: no-cache


Notes
-----
Removed the "ETag" and "Last-Modified" header fields.
According to Appendix B.3.1. :
   To retrieve only the configuration child resources, the "= content"
   parameter is set to "config".  Note that the &q= uot;ETag" and
   "Last-Modified" headers are only returned if the &qu= ot;content" parameter
   value is "config".

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

--------------------------------------
RFC8040 (draft-ietf-netconf-restconf-18)
--------------------------------------
Title               : RESTCONF Prot= ocol
Publication Date    : January 2017
Author(s)           : A. Bierman, M. Bjorklun= d, K. Watsen
Category            : PROPOSED STANDARD
Source              : Network Configurat= ion
Area                : Operations an= d Management
Stream              : IETF
Verifying Party     : IESG

--_000_AM0PR0302MB334880AA27135AD9F4394663F9DF0AM0PR0302MB3348_-- From nobody Tue Dec 22 07:07:04 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1953A10FD for ; Tue, 22 Dec 2020 07:07:02 -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 TQuZzJnVXTV4 for ; Tue, 22 Dec 2020 07:07:01 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 BE2383A10FA for ; Tue, 22 Dec 2020 07:07:00 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id o17so32745796lfg.4 for ; Tue, 22 Dec 2020 07:07:00 -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=5m/OUZHPvsaOOqOIcImWoqZEHyzz6kjUx4fYJzHYCe0=; b=xgPUHIVVS8eJCUTkbWC/DFqw+tkL2pbqS7fhH70H8WKIeCluNl+3trh4ybyFe04Dlp 9wWJtfcQd4O2NG3uhwE7ZAcLG0evY19c8XVKR6Pyl7kQonmHuPXjLJ/nSwryTGQkqrQx rpji0XGSvICUiS9RdA5LjsqhIaebYwyVkmSXoGiQ9yaR29e6EKiPQsSLrmPXyBn4zvKa SBNqK5gu/3JnZO94NkN3MVDZZM+PnH7sFgGiBppur4NFiCfc8iltbP2DqlLjM7qpNA0G 93jP2W+sUP51RGqx+NEix8thJFIggm9Ebh2mQUvYGgcH9eNjnvPrdeUOXUioxwtW3IFL 4T8Q== 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=5m/OUZHPvsaOOqOIcImWoqZEHyzz6kjUx4fYJzHYCe0=; b=jNsHya1H8JS9z7/byzm+Jg+fD0C3Uq8vvTSJ1YN2NzeSwyao1RzsLUb23vXwYLNTtb /N8gvHyR6CcJBfs2fY2DdSS+eergtl4lH5E5QoP9qhoPVBAhRKVXnFvjxI+b87WRpVGs QtwE/AkV1GcsTdEUpUg40wWZ9k25v9KFLdnfh0QW7UqG5mk0y/S3DU7h9MAEZwqWuUOj /BgMTAIduYpieJfAqPcDC4zaEUvFgTIZ1lOBXFAJC6OEzZMUzTqsTC2W/P0eTsDcQ2o+ YRu+2p+0aI+OilAX7UbJUtQz32/KyIkiWaaCgWuMqwkMS+2SXC9QVMefKcf0AbIeYulE FyrA== X-Gm-Message-State: AOAM533KpxEVgG3q8neuTzZOoirLf54bS+j2/hZzu+qK/ftTOdCh+4bT bnQgmG5UQzBPdOf8Bx+fuS99qol6FkQTS1tyBflFiA== X-Google-Smtp-Source: ABdhPJz/Xq7CKj4X1lJdr5YA6rBedQXOZqxlIsYtF23d1NyiOvrPG8xZJrVLajD8zP+dEEWvc+qq20R6Q7y9WrTVVrw= X-Received: by 2002:ac2:598f:: with SMTP id w15mr8334335lfn.577.1608649618911; Tue, 22 Dec 2020 07:06:58 -0800 (PST) MIME-Version: 1.0 References: <20201222143949.F33E8F40744@rfc-editor.org> In-Reply-To: <20201222143949.F33E8F40744@rfc-editor.org> From: Andy Bierman Date: Tue, 22 Dec 2020 07:06:48 -0800 Message-ID: To: RFC Errata System Cc: Martin Bjorklund , Kent Watsen , Warren Kumari , Robert Wilton , Kent Watsen , Mahesh Jethanandani , muly_i@rad.com, Netconf Content-Type: multipart/alternative; boundary="0000000000001a89d705b70eed10" Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6363) 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, 22 Dec 2020 15:07:03 -0000 --0000000000001a89d705b70eed10 Content-Type: text/plain; charset="UTF-8" Hi, This errata should be rejected. The proposed text changes the semantics of the paragraph. The original word "will" is not ambiguous or used in error. Andy On Tue, Dec 22, 2020 at 6:40 AM RFC Errata System wrote: > The following errata report has been submitted for RFC8040, > "RESTCONF Protocol". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6363 > > -------------------------------------- > Type: Technical > Reported by: Muly Ilan > > Section: 4.8.2. > > Original Text > ------------- > By default, the server will include all sub-resources within a > retrieved resource that have the same resource type as the requested > resource. The exception is the datastore resource. If this resource > type is retrieved, then by default the datastore and all child data > resources are returned. > > Corrected Text > -------------- > By default, the server SHOULD include all sub-resources within a > retrieved resource that have the same resource type as the requested > resource. The exception is the datastore resource. If this resource > type is retrieved, then by default the datastore and all child data > resources are returned. > > Notes > ----- > Substitute "will" by "SHOULD". > > Use one of the keywords of RFC2119 to clarify the expected server behavior. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8040 (draft-ietf-netconf-restconf-18) > -------------------------------------- > Title : RESTCONF Protocol > Publication Date : January 2017 > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > --0000000000001a89d705b70eed10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This errata should be rejected.
The proposed text changes the semantics of the paragraph.
= The original word "will" is not ambiguous=C2=A0or used in error.<= /div>


Andy


=
On Tue, De= c 22, 2020 at 6:40 AM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been= submitted for RFC8040,
"RESTCONF Protocol".

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

--------------------------------------
Type: Technical
Reported by: Muly Ilan <muly_i@rad.com>

Section: 4.8.2.

Original Text
-------------
=C2=A0 =C2=A0By default, the server will include all sub-resources within a=
=C2=A0 =C2=A0retrieved resource that have the same resource type as the req= uested
=C2=A0 =C2=A0resource.=C2=A0 The exception is the datastore resource.=C2=A0= If this resource
=C2=A0 =C2=A0type is retrieved, then by default the datastore and all child= data
=C2=A0 =C2=A0resources are returned.

Corrected Text
--------------
=C2=A0 =C2=A0By default, the server SHOULD include all sub-resources within= a
=C2=A0 =C2=A0retrieved resource that have the same resource type as the req= uested
=C2=A0 =C2=A0resource.=C2=A0 The exception is the datastore resource.=C2=A0= If this resource
=C2=A0 =C2=A0type is retrieved, then by default the datastore and all child= data
=C2=A0 =C2=A0resources are returned.

Notes
-----
Substitute "will" by "SHOULD".

Use one of the keywords of RFC2119 to clarify the expected server behavior.=

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

--------------------------------------
RFC8040 (draft-ietf-netconf-restconf-18)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: RESTCONF Prot= ocol
Publication Date=C2=A0 =C2=A0 : January 2017
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A. Bierman, M. Bjorklun= d, K. Watsen
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Configurat= ion
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operations an= d Management
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--0000000000001a89d705b70eed10-- From nobody Tue Dec 22 08:57:14 2020 Return-Path: <010001768b621522-b52104a2-019e-45b2-96b8-bbe29caefb05-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 9A4703A1184 for ; Tue, 22 Dec 2020 08:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcKudbBYJ7XY for ; Tue, 22 Dec 2020 08:57:11 -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 05CE03A1180 for ; Tue, 22 Dec 2020 08:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1608656229; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=eVC5LwCtuGo63apd2dJOvUHU8jkFQrzheFhid+WJ3RM=; b=YKbAzPbpUmJeQaPXalBdxSPIXSPZ1+J0ddWBL8vjbGOwqDAs7qUsDtKvls27fWSi J2d0TExgQodSp6zphN8sjJDO90CizbCC2moPznT5RB5dPnfG2sNTAUHp803U91wjdZc w/fKUmdn7/zgw3vVZqTb9mgFT2cTKJr9L6fnXjWI= From: Kent Watsen Message-ID: <010001768b621522-b52104a2-019e-45b2-96b8-bbe29caefb05-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_12E2DDD9-5D32-45D0-824D-605667E19D6A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 22 Dec 2020 16:57:09 +0000 In-Reply-To: Cc: RFC Errata System , Martin Bjorklund , Kent Watsen , Warren Kumari , Robert Wilton , Mahesh Jethanandani , muly_i@rad.com, "netconf@ietf.org" To: Andy Bierman References: <20201222143949.F33E8F40744@rfc-editor.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.12.22-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6363) 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, 22 Dec 2020 16:57:13 -0000 --Apple-Mail=_12E2DDD9-5D32-45D0-824D-605667E19D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 > On Dec 22, 2020, at 10:06 AM, Andy Bierman wrote: >=20 > Hi, >=20 > This errata should be rejected. > The proposed text changes the semantics of the paragraph. > The original word "will" is not ambiguous or used in error. >=20 >=20 > Andy >=20 >=20 > On Tue, Dec 22, 2020 at 6:40 AM RFC Errata System = > wrote: > The following errata report has been submitted for RFC8040, > "RESTCONF Protocol". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6363 = >=20 > -------------------------------------- > Type: Technical > Reported by: Muly Ilan > >=20 > Section: 4.8.2. >=20 > Original Text > ------------- > By default, the server will include all sub-resources within a > retrieved resource that have the same resource type as the = requested > resource. The exception is the datastore resource. If this = resource > type is retrieved, then by default the datastore and all child data > resources are returned. >=20 > Corrected Text > -------------- > By default, the server SHOULD include all sub-resources within a > retrieved resource that have the same resource type as the = requested > resource. The exception is the datastore resource. If this = resource > type is retrieved, then by default the datastore and all child data > resources are returned. >=20 > Notes > ----- > Substitute "will" by "SHOULD". >=20 > Use one of the keywords of RFC2119 to clarify the expected server = behavior. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8040 (draft-ietf-netconf-restconf-18) > -------------------------------------- > Title : RESTCONF Protocol > Publication Date : January 2017 > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG --Apple-Mail=_12E2DDD9-5D32-45D0-824D-605667E19D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1

On Dec = 22, 2020, at 10:06 AM, Andy Bierman <andy@yumaworks.com> = wrote:

Hi,

This errata should be rejected.
The = proposed text changes the semantics of the paragraph.
The original word "will" is not ambiguous or used in = error.


Andy


On Tue, Dec 22, 2020 at 6:40 AM RFC = Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been = submitted for RFC8040,
"RESTCONF Protocol".

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

--------------------------------------
Type: Technical
Reported by: Muly Ilan <muly_i@rad.com>

Section: 4.8.2.

Original Text
-------------
   By default, the server will include all sub-resources = within a
   retrieved resource that have the same resource type as the = requested
   resource.  The exception is the datastore = resource.  If this resource
   type is retrieved, then by default the datastore and all = child data
   resources are returned.

Corrected Text
--------------
   By default, the server SHOULD include all sub-resources = within a
   retrieved resource that have the same resource type as the = requested
   resource.  The exception is the datastore = resource.  If this resource
   type is retrieved, then by default the datastore and all = child data
   resources are returned.

Notes
-----
Substitute "will" by "SHOULD".

Use one of the keywords of RFC2119 to clarify the expected server = behavior.

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

--------------------------------------
RFC8040 (draft-ietf-netconf-restconf-18)
--------------------------------------
Title               : RESTCONF = Protocol
Publication Date    : January 2017
Author(s)           : A. Bierman, M. = Bjorklund, K. Watsen
Category            : PROPOSED STANDARD
Source              : Network = Configuration
Area                : Operations = and Management
Stream              : IETF
Verifying Party     : IESG

= --Apple-Mail=_12E2DDD9-5D32-45D0-824D-605667E19D6A-- From nobody Tue Dec 22 09:16:00 2020 Return-Path: <010001768b7342d8-b52c94cf-2f1c-4031-84a1-d3641efdf88d-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 A4ECF3A119E for ; Tue, 22 Dec 2020 09:15:58 -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 wKXYOFtEbSd4 for ; Tue, 22 Dec 2020 09:15:57 -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 C8AD83A119D for ; Tue, 22 Dec 2020 09:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1608657355; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=RamAqZkL4THQ+K2OaTGRTvcc2paPFEkasAXPGUNCfaU=; b=XueE98DWRIfWgpqkfCgbGy9AVH8m530j936iIsMOzKoDscmAafK3gVNCp8kjz4V/ s5h0PL+F8wam3oOo5Z2x/nRXYr7EqyamCYJWn1BQf7UsVgSqdMYWBEHW9R40FEYLiqV 8HdxAq7706pa4WRI5JXJAd4NDZczWaJ5cqEy2FdA= From: Kent Watsen Message-ID: <010001768b7342d8-b52c94cf-2f1c-4031-84a1-d3641efdf88d-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6432279D-6406-4ACB-985E-C24B7CDF0638" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 22 Dec 2020 17:15:55 +0000 In-Reply-To: Cc: RFC Errata System , Martin Bjorklund , Warren Kumari , Robert Wilton , Mahesh Jethanandani , muly_i@rad.com, "netconf@ietf.org" To: Andy Bierman References: <20201222143414.775F6F40744@rfc-editor.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.12.22-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6362) 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, 22 Dec 2020 17:15:59 -0000 --Apple-Mail=_6432279D-6406-4ACB-985E-C24B7CDF0638 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The example uses =E2=80=9C/data=E2=80=9D, i.e., the unified datastore, = which may contain operational data. I guess that, for /data, it could = be said that any "ETag" and "Last-Modified=E2=80=9D headers only reflect = the =E2=80=9Cconfig true=E2=80=9D data present, in which case Andy=E2=80=99= s interpretation makes sense. But this is not true for NMDA=E2=80=99s , where said = headers likely should never be returned, even if the =E2=80=9Ccontent=E2=80= =9D parameter is =E2=80=9Cconfig=E2=80=9D. =20 For NMDA=E2=80=99s , it seems that the headers should always be = returned, even when the =E2=80=9Ccontent=E2=80=9D parameter is not = specified, as Andy states. I=E2=80=99m assuming content=3Dnonconfig on = is an error case, or at least a non-sensical case.. K. > On Dec 22, 2020, at 9:57 AM, Andy Bierman wrote: >=20 > Hi, >=20 > This Errata should be rejected. > The cited text in non-normative Appendix B.3.1 is actually wrong. > The parameter content=3Dall can also return these fields for = configuration data. >=20 >=20 > The normative text in 3.5.2 explains what to do. >=20 >=20 > 3.5.2 . Entity-Tag >=20 > For configuration data resources, the server SHOULD maintain a > resource entity-tag for each resource and return the "ETag" header > field when it is retrieved as the target resource with the GET or > HEAD methods. If maintained, the resource entity-tag MUST be = updated > whenever the resource or any configuration resource within the > resource is altered. If not maintained, then the resource = entity-tag > for the datastore MUST be used instead. >=20 >=20 > Andy >=20 > On Tue, Dec 22, 2020 at 6:34 AM RFC Errata System = > wrote: > The following errata report has been submitted for RFC8040, > "RESTCONF Protocol". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6362 = >=20 > -------------------------------------- > Type: Technical > Reported by: Muly Ilan > >=20 > Section: 4.3. >=20 > Original Text > ------------- > The client might request the response header fields for an XML > representation of a specific "album" resource: >=20 > GET /restconf/data/example-jukebox:jukebox/\ > library/artist=3DFoo%20Fighters/album=3DWasting%20Light = HTTP/1.1 > Host: example.com > Accept: application/yang-data+xml >=20 > The server might respond as follows: >=20 > HTTP/1.1 200 OK > Date: Thu, 26 Jan 2017 20:56:30 GMT > Server: example-server > Content-Type: application/yang-data+xml > Cache-Control: no-cache > ETag: "a74eefc993a2b" > Last-Modified: Thu, 26 Jan 2017 14:02:14 GMT >=20 > Corrected Text > -------------- > The client might request the response header fields for an XML > representation of a specific "album" resource: >=20 > GET /restconf/data/example-jukebox:jukebox/\ > library/artist=3DFoo%20Fighters/album=3DWasting%20Light = HTTP/1.1 > Host: example.com > Accept: application/yang-data+xml >=20 > The server might respond as follows: >=20 > HTTP/1.1 200 OK > Date: Thu, 26 Jan 2017 20:56:30 GMT > Server: example-server > Content-Type: application/yang-data+xml > Cache-Control: no-cache >=20 >=20 > Notes > ----- > Removed the "ETag" and "Last-Modified" header fields. >=20 > According to Appendix B.3.1. : > To retrieve only the configuration child resources, the "content" > parameter is set to "config". Note that the "ETag" and > "Last-Modified" headers are only returned if the "content" = parameter > value is "config". >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8040 (draft-ietf-netconf-restconf-18) > -------------------------------------- > Title : RESTCONF Protocol > Publication Date : January 2017 > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG --Apple-Mail=_6432279D-6406-4ACB-985E-C24B7CDF0638 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

The example uses = =E2=80=9C/data=E2=80=9D, i.e., the unified datastore, which may contain = operational data.  I guess that, for /data, it could be said that = any "ETag" and "Last-Modified=E2=80=9D headers only reflect the = =E2=80=9Cconfig true=E2=80=9D data present, in which case Andy=E2=80=99s = interpretation makes sense.

But this is not true for NMDA=E2=80=99s <operational>, = where said headers likely should never be returned, even if the = =E2=80=9Ccontent=E2=80=9D parameter is =E2=80=9Cconfig=E2=80=9D. =  

For = NMDA=E2=80=99s <running>, it seems that the headers should always = be returned, even when the =E2=80=9Ccontent=E2=80=9D parameter is not = specified, as Andy states.  I=E2=80=99m assuming content=3Dnonconfig = on <running> is an error case, or at least a non-sensical = case..

K.


On Dec 22, 2020, at 9:57 AM, Andy Bierman = <andy@yumaworks.com> wrote:

Hi,

This Errata should be = rejected.
The cited text in non-normative Appendix = B.3.1 is actually wrong.
The parameter content=3Dall = can also return these fields for configuration data.


The normative text in 3.5.2 explains what to do.


3.5.2.  Entity-Tag


   For configuration data resources, the server SHOULD maintain a
   resource entity-tag for each resource and return the "ETag" header
   field when it is retrieved as the target resource with the GET or
   HEAD methods.  If maintained, the resource entity-tag MUST be updated
   whenever the resource or any configuration resource within the
   resource is altered.  If not maintained, then the resource entity-tag
   for the datastore MUST be used instead.


Andy

On Tue, Dec = 22, 2020 at 6:34 AM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been = submitted for RFC8040,
"RESTCONF Protocol".

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

--------------------------------------
Type: Technical
Reported by: Muly Ilan <muly_i@rad.com>

Section: 4.3.

Original Text
-------------
   The client might request the response header fields for an = XML
   representation of a specific "album" resource:
=
      GET /restconf/data/example-jukebox:jukebox/\
        =  library/artist=3DFoo%20Fighters/album=3DWasting%20Light = HTTP/1.1
      Host: example.com
      Accept: application/yang-data+xml

   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server
      Content-Type: application/yang-data+xml
      Cache-Control: no-cache
      ETag: "a74eefc993a2b"
      Last-Modified: Thu, 26 Jan 2017 14:02:14 GMT

Corrected Text
--------------
   The client might request the response header fields for an = XML
   representation of a specific "album" resource:
=
      GET /restconf/data/example-jukebox:jukebox/\
        =  library/artist=3DFoo%20Fighters/album=3DWasting%20Light = HTTP/1.1
      Host: example.com
      Accept: application/yang-data+xml

   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server
      Content-Type: application/yang-data+xml
      Cache-Control: no-cache


Notes
-----
Removed the "ETag" and "Last-Modified" header fields.

According to Appendix B.3.1. :
   To retrieve only the configuration child resources, the = "content"
   parameter is set to "config".  Note that the "ETag" = and
   "Last-Modified" headers are only returned if the "content" = parameter
   value is "config".

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

--------------------------------------
RFC8040 (draft-ietf-netconf-restconf-18)
--------------------------------------
Title               : RESTCONF = Protocol
Publication Date    : January 2017
Author(s)           : A. Bierman, M. = Bjorklund, K. Watsen
Category            : PROPOSED STANDARD
Source              : Network = Configuration
Area                : Operations = and Management
Stream              : IETF
Verifying Party     : IESG

= --Apple-Mail=_6432279D-6406-4ACB-985E-C24B7CDF0638-- From nobody Tue Dec 22 16:35:50 2020 Return-Path: <010001768d05bf5b-eb6d3807-2d23-45c8-a905-dfdaf9fe5bb3-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 656D23A1375; Tue, 22 Dec 2020 16:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=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 Mj1VqA6cCeAF; Tue, 22 Dec 2020 16:35:43 -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 6E5E53A1374; Tue, 22 Dec 2020 16:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1608683733; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=QiNBCV7g484bZ7js2oMBN8//inWODaleTMeeVQC2WRc=; b=HDTcEue1gfAQPhfPtqWhInDYWdW3cpS6wVG7mOYAWvKnmr8L7v7l9PVho0KM/NC/ fLQbPh8ZD4hpUBWM15sp/3zE+rIl2IluQAobyGyg/A4ErUoXHs4kyEPYth39ssrxGaw iODBVW6EePE8v4GQYOYnNQ0ZSBrUkKHuNehn+Ctw= 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: <01000174e90a9186-0a4edb66-4120-44b7-a79f-7b9935f6d48f-000000@email.amazonses.com> Date: Wed, 23 Dec 2020 00:35:32 +0000 Cc: secdir@ietf.org, "netconf@ietf.org" , draft-ietf-netconf-trust-anchors.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-ID: <010001768d05bf5b-eb6d3807-2d23-45c8-a905-dfdaf9fe5bb3-000000@email.amazonses.com> References: <160107496501.14047.597283542214697710@ietfa.amsl.com> <01000174e90a9186-0a4edb66-4120-44b7-a79f-7b9935f6d48f-000000@email.amazonses.com> To: Yoav Nir X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.12.23-54.240.48.93 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [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, 23 Dec 2020 00:35:45 -0000 Hi Yoav, I finally found some time :sigh: ;) Please see below for responses to your comments. Kent > On Oct 2, 2020, at 7:20 AM, Kent Watsen wrote: >=20 > [-last-call] >=20 > Hi Yoav, >=20 > Thank you for your review! The takeaway for me is that some = clarifications are needed, but otherwise the draft is fundamentally = okay. I will post an update, or perhaps just a GitHub commit, for your = review, when I get a chance. That said, my getting a chance will be = delayed as I have a major engagement I need to focus on now. This email = is just to let you know that your review has not been forgotten. >=20 > Thanks again, > Kent >=20 >=20 >> On Sep 25, 2020, at 7:02 PM, Yoav Nir via Datatracker = wrote: >>=20 >> Reviewer: Yoav Nir >> Review result: Has Issues >>=20 >> I have reviewed this document as part of the security directorate's = ongoing >> effort to review all IETF documents being processed by the IESG. = These >> comments were written primarily for the benefit of the security area = directors. >> Document editors and WG chairs should treat these comments just like = any other >> last call comments. >>=20 >> The document defines a YANG model for managing a trust anchor store. = It allows >> two kinds of trust anchors: certificates and raw public keys. = However, >> certificates are not just containers for public keys. Certificates = include >> attributes about key usage, path constraints and name constraints, = all of which >> constrain the ability to use the public key, and are relevant for = trust >> anchors. As far as I can tell the document does not include any = attributes to >> equivalently constrain the use of the raw public keys. If the = intention is >> that raw public keys will not be constrained, the document should = state this >> explicitly. Good catch. You=E2=80=99re right that this document is not constraining = the raw keys in the truststore. Looking deeper, I see that the keys are = unconstrained in both the =E2=80=9Ckeystore=E2=80=9D draft and the = common =E2=80=9Ccrypto-types=E2=80=9D draft. It seems like the right = thing to do is to put a Security Consideration note into each draft. = Something like this? 4.2. Unconstrained Public Key Usage This module enables the configuration of public keys without constraints on their usage, e.g., what operations the key is = allowed to be used for (encryption, verification, both). This module also enables the configuration of certificates, where each certificate may constrain the usage of the public key = according to local policy. Thoughts? >> Perhaps this is clear to the people who worked on the document, but = it's not >> clear to me. Are the trust anchors managed with this module supposed = to be >> used to establish trust for the NETCONF or RESTCONF connections? = Section 1.1 >> seems to suggest that it does, but then how is the bootstrap problem = solved? >> How do we establish the NETCONF connection the first time, and if we = are able >> to do that, why do we need more certificates? If the answer is no, = and the >> certificates are to be used by other protocols, then perhaps some = re-wording in >> section 1.1 would help to show this. Currently, it says: "This = document >> presents ... YANG modules that are part of a collection of RFCs ... = define >> configuration modules for clients and servers of both the NETCONF and = RESTCONF >> protocols." Answering your question: Yes, the trust anchors may be used to establish = trust for NETCONF and RESTCONF connections. The trust anchors may also = be used by other models (e.g., other TLS-based protocols), created = outside the effort described in Section 1.1. For the bootstrap problem, Section 3 (Support for Built-in Trust = Anchors) shows how a system may be shipped from a Manufacturer=E2=80=99s = facility with preconfigured trust-anchors. FWIW, the =E2=80=9Ckeystore=E2= =80=9D draft separately defines how a system can be shipped from a = Manufacturer=E2=80=99s facility with preconfigured private keys (e.g., = using a TPM-protected key). You suggest rewording the first paragraph in 1.1. First, I have to = assume you saw the second paragraph, that says that the modules have = been defined to be used by other efforts, so my best guess is: OLD: This document presents one or more YANG modules [RFC7950] that are part = of a collection of RFCs that work together to define configuration = modules for clients and servers of both the NETCONF [RFC6241] and = RESTCONF [RFC8040] protocols. NEW: This document presents one or more YANG modules [RFC7950] that are part = of a collection of RFCs that work together to, ultimately, enable the = configuration of the clients and servers of both the NETCONF [RFC6241] = and RESTCONF [RFC8040] protocols. Please let me know what you had in mind, if something different. >> The security considerations section is OK, especially sub-section = 4.2. Thanks. >> Sub-section 4.1 has the following: >>=20 >> The YANG module defined in this document defines a mechanism called = a >> "truststore" that, by its name, suggests that it will protect its >> contents from unauthorized modification. >>=20 >> Perhaps this is my different perspective, but the name doesn't lead = me to >> expect that it protects its contents. I think that the document = should either >> just suggest that some mechanism to prevent unauthorized modification = should be >> used, or to present such a mechanism in detail. The current text = suggests is >> partially specific by mentioning digital signatures and non-volatile = storage, >> but not explaining where the trust for the digital signature comes = from and >> what policies govern its us: >>=20 >> In order to satisfy the expectations of a "truststore", it is >> RECOMMENDED that implementations ensure that the truststore contents >> are signed when persisted to non-volatile memory, to prevent >> unauthorized modifications from being made undetected. >>=20 >> It is too vague to be a specification, but still unnecessarily = constrains the >> solution space. I think the correct thing to do is to be explicitly = vague and >> to just suggest some mechanism for protecting the content. Agreed. OLD: In order to satisfy the expectations of a "truststore", it is = RECOMMENDED that implementations ensure that the truststore contents are = signed when persisted to non-volatile memory, to prevent unauthorized = modifications from being made undetected. NEW: In order to satisfy the expectations of a "truststore", it is = RECOMMENDED that implementations ensure that the truststore contents are = protected from unauthorized modifications when at rest. What do you think? Thanks, Kent (as editor/author) From nobody Thu Dec 24 06:33:13 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D2F3A1281 for ; Thu, 24 Dec 2020 06:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw6jrHvex8tf for ; Thu, 24 Dec 2020 06:33:10 -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 6DE8E3A1280 for ; Thu, 24 Dec 2020 06:33:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0CF77F40709; Thu, 24 Dec 2020 06:32:50 -0800 (PST) To: evoit@cisco.com, ludwig@clemm.org, alberto.gonzalez@microsoft.com, einarnn@cisco.com, ambtripa@cisco.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: <20201224143250.0CF77F40709@rfc-editor.org> Date: Thu, 24 Dec 2020 06:32:50 -0800 (PST) Archived-At: Subject: [netconf] [Editorial Errata Reported] RFC8639 (6366) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 14:33:12 -0000 The following errata report has been submitted for RFC8639, "Subscription to YANG Notifications". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6366 -------------------------------------- Type: Editorial Reported by: Muly Ilan Section: 4. Original Text ------------- feature subtree { description "This feature indicates support for YANG subtree filtering."; reference "RFC 6241: Network Configuration Protocol (NETCONF), Section 6"; } feature supports-vrf { description "This feature indicates that a publisher supports VRF configuration for configured subscriptions. VRF support for dynamic subscriptions does not require this feature."; reference "RFC 8529: YANG Data Model for Network Instances, Section 6"; } Corrected Text -------------- feature subtree { description "This feature indicates support for YANG subtree filtering."; reference "RFC 6241: Network Configuration Protocol (NETCONF), Section 6"; } feature supports-vrf { description "This feature indicates that a publisher supports VRF configuration for configured subscriptions. VRF support for dynamic subscriptions does not require this feature."; reference "RFC 8529: YANG Data Model for Network Instances, Section 6"; } Notes ----- In the HTML version the two hyperlinks "Section 6" (for 'subtree' feature and for 'supports-vrf' feature) point to wrong RFCs. 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. -------------------------------------- RFC8639 (draft-ietf-netconf-subscribed-notifications-26) -------------------------------------- Title : Subscription to YANG Notifications Publication Date : September 2019 Author(s) : E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Thu Dec 24 06:45:47 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762A23A1288 for ; Thu, 24 Dec 2020 06:45:45 -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 V83XCTuT8NQS for ; Thu, 24 Dec 2020 06:45:44 -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 32EF43A1286 for ; Thu, 24 Dec 2020 06:45:44 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D6976F40706; Thu, 24 Dec 2020 06:45:23 -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: <20201224144523.D6976F40706@rfc-editor.org> Date: Thu, 24 Dec 2020 06:45:23 -0800 (PST) Archived-At: Subject: [netconf] [Editorial Errata Reported] RFC8650 (6367) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 14:45:45 -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/eid6367 -------------------------------------- Type: Editorial Reported by: Muly Ilan Section: A.1.3 Original Text ------------- A.1.3. Deleting Dynamic Subscriptions The following demonstrates deleting a subscription. This subscription may have been to either a stream or a datastore. POST /restconf/operations /ietf-subscribed-notifications:delete-subscription { "delete-subscription": { "id": "22" } } Corrected Text -------------- A.1.3. Deleting Dynamic Subscriptions The following demonstrates deleting a subscription. This subscription may have been to either a stream or a datastore. POST /restconf/operations /ietf-subscribed-notifications:delete-subscription { "ietf-subscribed-notifications:input": { "id": "22" } } Notes ----- Encoding of RPC input parameters should follow RFC 8040 section 3.6.1 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 Thu Dec 24 06:56:41 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A2B3A1290 for ; Thu, 24 Dec 2020 06:56: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, RCVD_IN_DNSWL_BLOCKED=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 fwWOmEi0p-Xv for ; Thu, 24 Dec 2020 06:56:39 -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 850983A128B for ; Thu, 24 Dec 2020 06:56:39 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 30D1FF40705; Thu, 24 Dec 2020 06:56:19 -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: <20201224145619.30D1FF40705@rfc-editor.org> Date: Thu, 24 Dec 2020 06:56:19 -0800 (PST) Archived-At: Subject: [netconf] [Editorial Errata Reported] RFC8650 (6368) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 14:56:41 -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/eid6368 -------------------------------------- Type: Editorial Reported by: Muly Ilan Section: A.2.1 Original Text ------------- A.2.1. "subscription-modified" A "subscription-modified" encoded in JSON would look like: { "ietf-restconf:notification" : { "eventTime": "2007-09-01T10:00:00Z", "ietf-subscribed-notifications:subscription-modified": { "id": 39, "uri": "https://example.com/restconf/subscriptions/22" "stream-xpath-filter": "/example-module:foo", "stream": { "ietf-netconf-subscribed-notifications" : "NETCONF" } } } } Corrected Text -------------- A.2.1. "subscription-modified" A "subscription-modified" encoded in JSON would look like: { "ietf-restconf:notification" : { "eventTime": "2007-09-01T10:00:00Z", "ietf-subscribed-notifications:subscription-modified": { "id": 22, "uri": "https://example.com/restconf/subscriptions/22" "stream-xpath-filter": "/example-module:foo", "stream": { "ietf-netconf-subscribed-notifications" : "NETCONF" } } } } Notes ----- Subscription ID should be 22 instead of 39. An existing subscription ID cannot be changed. According to the previous examples in Appendix A the subscription got the ID 22. Also the example URI indicates ID of 22. 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 Thu Dec 24 07:14:23 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F0B3A12A3 for ; Thu, 24 Dec 2020 07:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=AWFHCq/p; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=InhYqJ4t Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKNdnVO33mHS for ; Thu, 24 Dec 2020 07:14:19 -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 97EF63A12A5 for ; Thu, 24 Dec 2020 07:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9374; q=dns/txt; s=iport; t=1608822859; x=1610032459; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VEkxl0r+7iWlhLLI+ECitsuOCL9bAlyX/+DH2V71stE=; b=AWFHCq/pPCPkn4NundMEzMKRZduIwCHf9SD7eLwlsDYWJHz1/rv8AHa4 f9C/0WjVhQZ3b4QpBddvSXGrlEaTnX5TDp+70Ujqgcls/gTRHErVxx++z Dg5OfMSdXSxzEpm7D+AfHcN2OxdHy/4jPhF2QR9awMHDAML2soV6BqW1o A=; X-Files: smime.p7s : 3975 X-IPAS-Result: =?us-ascii?q?A0BHAgAVr+RfkIkNJK1iHQEBAQEJARIBBQUBgg+BU1F9L?= =?us-ascii?q?S4vLgqENYNIA41dA4oahHKKAYJTBVIEBwEBAQoDAQEYCwoCBAEBhEoCgXICJ?= =?us-ascii?q?TgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBhjgMhXMBAQEEEhEdAQE3A?= =?us-ascii?q?QsEAgEIEQQBAQ4dAgICHxEdCAIEAQ0BBAgGFIMEAYF+VwMfDwEOpHICgTyIa?= =?us-ascii?q?XaBMoMEAQEGhQgNC4IJBwMGgTiBU4EiijQmG4FBP4ERQ4JWPoEEgRdCAYFig?= =?us-ascii?q?xY0giyCSAFjU1QtARUHRB0RR49RKYt1gW6ZYlgKgnaBGINGgmiBZI0RhT+DK?= =?us-ascii?q?YorlHyUC4sQgniOXw8ZhCQCBAIEBQIOAQEGgW0hgVlwFRqDClAXAg2OIRqDV?= =?us-ascii?q?4UUhQkBOnQQJwIGCgEBAwl8inkBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AehlKdxPIRDKGRiCjWool6mtXPHoupqn0MwgJ65?= =?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,444,1599523200"; d="p7s'?scan'208";a="618960980" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Dec 2020 15:14:18 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BOFEHvb014023 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Dec 2020 15:14:18 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 24 Dec 2020 09:14:17 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 24 Dec 2020 09:14:16 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 24 Dec 2020 09:14:16 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iuCWelEGTmJGhKC+pY3Q7Up5lAsa8iDTaY5xKYeDZUFsapl2S4wUy3j8ORqMmdHeD8iY1YO9mAsWqNEPG84S/1ExYgd6G1V2LfHYFNmX3HpMYBn0AfwtasLfYWPfpRouqW/oRXEot+k2Gz6hGnKXgMj8uakasP56GWjrATWXO1y+jJDzEq+iRFAyRS3yZMhUJGoqJTI5PFzNycjL6kbJhYk9JeDBqKOkNMHPiNE1VVur3QVXI8TVjh3lgn8bvqr+fK6Kc6Uu85T+PSLVJyRjM8AiwD2UZY2QPRbAY4518pQzwMs1qICufdoVxlHToKqXTF/CPE9tC9vorXwHws3LvQ== 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=QoqC28JMY2BvhjN0Sj9QYUcTjDjvPMbf/nFxesLZlh0=; b=A5q0wuvbH1p3nc3ehIVgbtOxf7wx6sEJLLwh1vzMl71OySccJj9m/whiSAH0LodrL3y7eytGTqaN9YFw6sOzbokZq+aSdSaRJVpGqrxgtIqrNY9cvtprIUS0YLYBR4LAGB8Tzv/3QoqssEJdrpay88i2DUA311TJhK2ywW4tB8tEYNaEEhHCOGYyRChjyezyh/tRmkMeM9OmDnQ+ZyHbx8NW5+pZcejtYQ62Ud9vsLtP4pv39zoDnxEXtHVJwAGqtxZ+o8Hmdl08hNNgwpLOopI9TD09NMbiDXFsW5r3VJKUxX4oY6AC+Zs4qGLCT7uDLfwgn8zfThQ7POBiOYEUUQ== 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=QoqC28JMY2BvhjN0Sj9QYUcTjDjvPMbf/nFxesLZlh0=; b=InhYqJ4t5GeUv/9Jn3ugWWVKCvduFr3XSOPypgF7jYNV+hf7f6iso3MnA5WD6YFicCr7Rkf6Uc3LKwF6j3GuaFGauCpv/BloBi8FUZoyBXCcJ1uwi0m3fb3V1ZuAeuUbaYB9Nt9tSzhIrjnEnNOlhDhr0cPoaI5Ok0QPJKR7R3U= Received: from SN6PR11MB3135.namprd11.prod.outlook.com (2603:10b6:805:d5::20) by SA0PR11MB4528.namprd11.prod.outlook.com (2603:10b6:806:99::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.27; Thu, 24 Dec 2020 15:14:16 +0000 Received: from SN6PR11MB3135.namprd11.prod.outlook.com ([fe80::d11a:edb6:5df1:c3a1]) by SN6PR11MB3135.namprd11.prod.outlook.com ([fe80::d11a:edb6:5df1:c3a1%3]) with mapi id 15.20.3700.026; Thu, 24 Dec 2020 15:14:16 +0000 From: "Eric Voit (evoit)" To: RFC Errata System , "Reshad Rahman (rrahman)" , "Einar Nilsen-Nygaard (einarnn)" , "ludwig@clemm.org" , "andy@yumaworks.com" , "warren@kumari.net" , "Rob Wilton (rwilton)" , "kent+ietf@watsen.net" , "mjethanandani@gmail.com" CC: "muly_i@rad.com" , "netconf@ietf.org" Thread-Topic: [Editorial Errata Reported] RFC8650 (6368) Thread-Index: AQHW2gUU6vzmeKJrf022U5YvMWOykaoGWg3g Date: Thu, 24 Dec 2020 15:14:15 +0000 Message-ID: References: <20201224145619.30D1FF40705@rfc-editor.org> In-Reply-To: <20201224145619.30D1FF40705@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: ea5dae2a-3bc0-40c7-debe-08d8a81e9425 x-ms-traffictypediagnostic: SA0PR11MB4528: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:785; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jLdLCRnEtUMQpAtQGnEq6Lv4W7UZHVG7jdPJYyKIj3kWzhqJwyjqIcvCan9SonAlq+TpUw4VYjdLdwxIpQb+6jLkOS1DrgzX2VcYO1c3GxwG7DFc7Dt8LXkk0p3swWXx4rj1OBObv2RB6GqmdbRjTE0itwoht2eX4EaXpvIaOUTACGx3q6LYwtlxxr+3IlbZfMbmDWf6pwJHJCI78K2OT6sG4Sg1weyFtoK8DuTr4Qny/PqzNYMUzpsFYr/RMeOX4ilfgpmKjmK00QAbwEiw9RyffHwShOTacmhdgXfuHEB+ZPgvfOJ+xy3cExhQQawCu5FnX11Febp5NHPUMdoL5iJxrsOo2dUDGyjqphLCgjXFlhVrH9Ou0gLqtXSJWJK73fgJSu5mTV935cWxdrDUMKXvNHnCZfX1vXgoKFcfsHocGIrZ5rYtza4b22qFvMV7shIOw1+jABq8pM2p1NcOxQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB3135.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(396003)(366004)(376002)(39860400002)(8936002)(71200400001)(2906002)(316002)(4326008)(26005)(186003)(52536014)(8676002)(33656002)(86362001)(5660300002)(64756008)(66556008)(66446008)(55016002)(66476007)(83380400001)(7696005)(66616009)(66946007)(6506007)(99936003)(966005)(478600001)(53546011)(54906003)(110136005)(76116006)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?RVBLaUowWnpuQXpxc2JQeWRBdnd1UmVzQ3Fyc1h3RlNHVVRYVitRMzZTbE1p?= =?utf-8?B?VjBVVWg4VTRsM0V3RWVzU1dXMFZUUzF5cGpqMCtUdVRCc1pQQnkrWGpYVmJq?= =?utf-8?B?WEpkMGlUb1k0V0w0SzloemxFbTdaZVB1TmswaXVpZ3N4V01BR0d1TE5SYTdu?= =?utf-8?B?VHJlakM1WDBTR2lPbTZMNEttYkRnT2s2alZJdG04QXI3ZDAzMERRK0J2WHFn?= =?utf-8?B?OFN1QjRJajRROG9aVnBPSE13VEFnajlRVUZIcHBxaEhkQU5KVWpvOWJxZDZC?= =?utf-8?B?OWZaRndyWTVaMmtEYTlJWkdZNkQrdWVJdFBzUmFGc3hvQ1hxMFEzVzF2M3Ny?= =?utf-8?B?N09waUpoWEJ6ZEtpcllNSnhOeGZ5QUFRb09RdDl6QWNwWXVMMTB0Z000MVFz?= =?utf-8?B?THNDMldCbWNuVXFYOTdpTk9RNnhwMithZTJEaGNUSk9NYmNzMXpOY29HQnBM?= =?utf-8?B?dDYycFpEZ2NvUURaaU1hbGJDNjgzbm1SS1NsVHFoQ2NaSEJ3ZEZMUmtYTHA0?= =?utf-8?B?UEg5ZzlRMDY5dUxwQkcvWWhsK0JnZDBHL0dzaWwyUU05a0NKTG1UN0tXK1hU?= =?utf-8?B?SEFzc2xrSVhpejhBb2U4aDFDZTg5RE1qV2d0TE5mSWFYa1lBOTBkN2pYTkJr?= =?utf-8?B?RTh5SCtpcW45UjhRMnR2NDQ4K1RWdmxEcExLTVZOZDhCNFVjdVFWRVhmTk5q?= =?utf-8?B?bDBXMGFyWlVtQ21KUUp4NXAvRTRNUGVyNUtheWoyMnh6VTNlS2xLengzOVVv?= =?utf-8?B?bWtLYlN6NVNmNGpKK2dXVTg5bk5jb2tWMnlldTVaYzBnNnZVS01NNFpZN0ps?= =?utf-8?B?bHVPdkh1T3hCTWtYU3BsaXErZmVvcktaTHNYc2VjY3U1Z01CVEJMTFljZDJp?= =?utf-8?B?VmllMzM0NDNzajM5dk9RenNFZGgycVRSR1U4TXZSbW40RmwwSFFuR3p2TDdy?= =?utf-8?B?OFVoRXlmWHM3eWhuT3RMc1ZLQm1rY3lHUnhBTzdSbUlYOGNleUpFZlRmUFZh?= =?utf-8?B?SnpBTWhNQ2FxUi9BenVhdjdIY0N6UnNmU0NNTnhyUmlyU1JESEVXZEE4d0Jr?= =?utf-8?B?YVFTZEFJRWxGWTRuTHNBSTdCOGR6NmVRcWV6aWg5a1ZJenlLY1pBYWovZFBZ?= =?utf-8?B?RHBwQkI3NWpXRVR6aitBUldLdUxkK3JldGp5QVpVU2o2Q1JJV25mSzdzQnEv?= =?utf-8?B?elBISUhzL1ppdGtLNk1SYVdiNnJvZy94S0ZESEhtRU00ZnQyVTQvMVJMSExq?= =?utf-8?B?Y2xTT0Y5TGY4V3Y0alhIdWJMUzBoZE9RMFU2OUxBNWpUQUFPTXl6bjRoekI5?= =?utf-8?Q?tkKIXqUCGQJ14=3D?= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0032_01D6D9DD.85F4A190" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB3135.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ea5dae2a-3bc0-40c7-debe-08d8a81e9425 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2020 15:14:15.9181 (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: EDOZcMTQHeCOvZWhCEe9hD2UFTEFET5TbIiOyWyaGsOzWSTNbzqlbX9VAl1oRxIn X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4528 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [netconf] [Editorial Errata Reported] RFC8650 (6368) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 15:14:22 -0000 ------=_NextPart_000_0032_01D6D9DD.85F4A190 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Rather than changing the subscription from 22 to 39, the URI should be made: https://example.com/restconf/subscriptions/39 Reasons: (1) There is no assumption that the subscription is the same one as for the previous example. (2) We want to keep the examples in lock-step with RFC8640. Eric > -----Original Message----- > From: RFC Errata System > Sent: Thursday, December 24, 2020 9:56 AM > To: Eric Voit (evoit) ; Reshad Rahman (rrahman) > ; Einar Nilsen-Nygaard (einarnn) ; > ludwig@clemm.org; andy@yumaworks.com; warren@kumari.net; Rob Wilton > (rwilton) ; kent+ietf@watsen.net; > mjethanandani@gmail.com > Cc: muly_i@rad.com; netconf@ietf.org; rfc-editor@rfc-editor.org > Subject: [Editorial Errata Reported] RFC8650 (6368) > > 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/eid6368 > > -------------------------------------- > Type: Editorial > Reported by: Muly Ilan > > Section: A.2.1 > > Original Text > ------------- > A.2.1. "subscription-modified" > > A "subscription-modified" encoded in JSON would look like: > > { > "ietf-restconf:notification" : { > "eventTime": "2007-09-01T10:00:00Z", > "ietf-subscribed-notifications:subscription-modified": { > "id": 39, > "uri": "https://example.com/restconf/subscriptions/22" > "stream-xpath-filter": "/example-module:foo", > "stream": { > "ietf-netconf-subscribed-notifications" : "NETCONF" > } > } > } > } > > Corrected Text > -------------- > A.2.1. "subscription-modified" > > A "subscription-modified" encoded in JSON would look like: > > { > "ietf-restconf:notification" : { > "eventTime": "2007-09-01T10:00:00Z", > "ietf-subscribed-notifications:subscription-modified": { > "id": 22, > "uri": "https://example.com/restconf/subscriptions/22" > "stream-xpath-filter": "/example-module:foo", > "stream": { > "ietf-netconf-subscribed-notifications" : "NETCONF" > } > } > } > } > > Notes > ----- > Subscription ID should be 22 instead of 39. > > An existing subscription ID cannot be changed. According to the previous > examples in Appendix A the subscription got the ID 22. Also the example URI > indicates ID of 22. > > 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_0032_01D6D9DD.85F4A190 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAxMjI0MTUxNDExWjAjBgkqhkiG 9w0BCQQxFgQUIvV8MYx7BAU84TzEvdVFBwb35+cwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAFQHiRxTHwUlppifSQioHbboQKy9Kg6ruPOs96Ioj/sr82kuBepGZbtXtEfgOLOEg/ ZAFcofUpSIkWNQI6LsiMH2/bCsa8/A0O8exqHCxNc9RSIIGu6f3g8LuJIYQ1Pu0WTbVhwtPNnV35 PNRLbk4kitdoWIQ8fq+C0vrs4KeVVp/Jm/WcDewcZxGP98toYJYpiGGJtFEYtTkGTT/xtALI2rIk 1XAIZgOZ9MYiYxxXwG4TTcUh1eXj5fJJvgyoljIxELem9F/0nYiTUpA2KdDoIOSxMBSsc2eZyNV6 DN+tRjkjny02Q2b3ouF8TkSTQf5iIH8OAXZhMCyXVeYc7/NRAAAAAAAA ------=_NextPart_000_0032_01D6D9DD.85F4A190-- From nobody Thu Dec 24 08:23:25 2020 Return-Path: <01000176958fd7e7-dffa0747-1473-4830-aec4-b66ad7a4cefd-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 E8EA23A12F6 for ; Thu, 24 Dec 2020 08:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRwlj6aj3cMY for ; Thu, 24 Dec 2020 08:23:22 -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 269F63A12F3 for ; Thu, 24 Dec 2020 08:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1608827000; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=5NM2NBhduciQSroGL+Gmqy5aYICYqs2hWDpC6TXNCtw=; b=KZ0DIsMY00+usnzAwmk73RazYHPxUejzgABJuSr4VzPsi/CBl6pZkU1vtX9zZhf7 yX45hs3TsDTeq6FD8ZOVcM2A/BaPfvXWn4r3tPBmGnbhPh0CIRx835N6qNM5OCr/Uo3 nY2kGUrqQod8b/1ggU1836n0ZeJ8G/xVGR1AOsrQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: Date: Thu, 24 Dec 2020 16:23:20 +0000 Cc: RFC Errata System , "Reshad Rahman (rrahman)" , "Einar Nilsen-Nygaard (einarnn)" , "ludwig@clemm.org" , "andy@yumaworks.com" , "warren@kumari.net" , "Rob Wilton (rwilton)" , Mahesh Jethanandani , "muly_i@rad.com" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000176958fd7e7-dffa0747-1473-4830-aec4-b66ad7a4cefd-000000@email.amazonses.com> References: <20201224145619.30D1FF40705@rfc-editor.org> To: "Eric Voit (evoit)" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.12.24-54.240.48.110 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Editorial Errata Reported] RFC8650 (6368) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 16:23:24 -0000 Hi Eric, Thank you for you comment. But note that the errata system is binary, = either an errata is accepted or rejected. To do what you say entails = rejecting this errata and submitting a different one to say it, Is this = what you advocate? Thanks, Kent > On Dec 24, 2020, at 10:14 AM, Eric Voit (evoit) = wrote: >=20 > Rather than changing the subscription from 22 to 39, the URI should be = made: > https://example.com/restconf/subscriptions/39 >=20 > Reasons: > (1) There is no assumption that the subscription is the same one as = for the=20 > previous example. > (2) We want to keep the examples in lock-step with RFC8640. >=20 > Eric From nobody Thu Dec 24 10:27:41 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518CD3A135B for ; Thu, 24 Dec 2020 10:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WY7jjsu7; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=GTArQ5r5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0GRYr2rI2B6 for ; Thu, 24 Dec 2020 10:27:38 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8E53A1070 for ; Thu, 24 Dec 2020 10:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7180; q=dns/txt; s=iport; t=1608834458; x=1610044058; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aMRWLf6os3eObthiZO1Qph/BQX1fhC5Yy3Qxe7SkOMw=; b=WY7jjsu7ENT4pcxV5ywkqcGZeENtb+Q2ko9Tvx9wV+0JyZ3Tfwh8QFps op1ZIAhBlxET72hFi4ZHNYuAForAX19chgnDeplDBDqHNLg0FCAf+aFzS XywiFXpTYs6ZnYFpliT9LTtLk0UV26bz4+U8NEpaYUjZn6Y0MfaRxB1/9 w=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AoHbKyBbSZ8nLFBNL9zudHq7/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD5rS9+lJjazQvryzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsuteFTOuXC0qzgfBk?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZBABI3eRf/5xdJa1iHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFPgVNRB3YtLi8uCod9A41iihqOc4JTBVIEBwEBAQoDAQEYCwoCBAE?= =?us-ascii?q?BhEoCgXICJTgTAgMBAQsBAQUBAQECAQYEcYVhDIVzAQEBBBIuAQE3AQsEAgE?= =?us-ascii?q?IEQQBAQENIQIfER0IAgQOAQQIBhSDBYF+VwMfDwEOpEgCgTyIaXSBNIMEAQE?= =?us-ascii?q?GhRUNC4IJBwMGgTiBU4EiijQmG4FBP4FUglY+gQSBF0IBgWIVgzWCLIJIgTd?= =?us-ascii?q?UQ0uQb4JCAYkygW6ZYlgKgnaBGINGgmiBZI0RhT+iUJ8bgniOX4RMAgQCBAU?= =?us-ascii?q?CDgEBBoFtI4FXcBWDJFAXAg2OIYNxilh0ECcCBgoBAQMJfIp5AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.78,444,1599523200"; d="p7s'?scan'208";a="845813143" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Dec 2020 18:27:33 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BOIRXZQ011742 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Dec 2020 18:27:33 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 24 Dec 2020 12:27:33 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 24 Dec 2020 12:27:32 -0600 Received: from NAM11-CO1-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; Thu, 24 Dec 2020 13:27:32 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SQ4A2QcxJyeX1FQMo5mIWKl7zmaNyNKH3EA53pNUcu4wJJVe3InkqFCw/XO0eJN6BXtITR58U7AOBvrzUewsk5C4z/0DqBS2uuZC5VgGTg2f85ZUnUMkN7EerYTvO9d3tvRhPfbw2j1xHxZZGR3r/V0poJnSDCP9h98q5MutT5mQO4rkoUiR7Z99fDnFIwoFZuxzO0g7N2u/xcVK1lcj+FTDhAVNyf//c2qKrh5/Z0GxaBbha1/b6Y0IcWuUJ0+O6xgilLIEm5a4UEqPdEbFjfm10VPznfM0uzlRpDkCI96Sq7I5Y+DnMzTavpcvzxBE0ToFW6sxhsn2tN0hXzwgDA== 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=qwziCq6wOclciT42gl/x1CEDSwC3cMnK88Ge66DPwVE=; b=Z0F7buioBSFGGUk9bIXGmsu2TLEDGtQcWCFvgjPn1iK4RVqBBf68p0Gn4gWVL4EjLMClInGXRUNXMbMcH57Adoyj8rPfbnXVmP/B0ICgaRIjLzCMECuG5XSDyCcQ8tplnbkKEivTuRhwAUNZDTmGwS3DrFdhKP4tzzS++IYqYtrSB3opd03yGMdryi+sh+49x/PVkGQ2yKS9xpeXfuj5kFPvxgg3cBSv516Wbz0/xW8FX6zfrkLjrD3+VJofLoh9oDsHUID2NWezZR9id+jJ2rRj5xle5AZ0x0D74NQcCJ0XdferFdcP5dv1pPCZNniul90iu9uW5ZDVHtQHln3c9Q== 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=qwziCq6wOclciT42gl/x1CEDSwC3cMnK88Ge66DPwVE=; b=GTArQ5r5CtGrVSBQk9QWAMGAqnfa4Z9SkmQmChcv7kCRjyw4QmH+AGkIKxHsHJmhQIyiNLVe5t53VOcqLFUwEIpbkjDIMbAkkADyYsgijsmz6IYp7ddlZ49XpM6BxL/JvrcQHLECZaPW8DbkUxlDIjtMKbuCfuDZppCcEpWqCGU= Received: from SN6PR11MB3135.namprd11.prod.outlook.com (2603:10b6:805:d5::20) by SA2PR11MB4779.namprd11.prod.outlook.com (2603:10b6:806:11a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.27; Thu, 24 Dec 2020 18:27:31 +0000 Received: from SN6PR11MB3135.namprd11.prod.outlook.com ([fe80::d11a:edb6:5df1:c3a1]) by SN6PR11MB3135.namprd11.prod.outlook.com ([fe80::d11a:edb6:5df1:c3a1%3]) with mapi id 15.20.3700.026; Thu, 24 Dec 2020 18:27:31 +0000 From: "Eric Voit (evoit)" To: Kent Watsen CC: RFC Errata System , "Reshad Rahman (rrahman)" , "Einar Nilsen-Nygaard (einarnn)" , "ludwig@clemm.org" , "andy@yumaworks.com" , "warren@kumari.net" , "Rob Wilton (rwilton)" , Mahesh Jethanandani , "muly_i@rad.com" , "netconf@ietf.org" Thread-Topic: [Editorial Errata Reported] RFC8650 (6368) Thread-Index: AQHW2gUU6vzmeKJrf022U5YvMWOykaoGWg3ggAAUGACAACJVEA== Date: Thu, 24 Dec 2020 18:27:31 +0000 Message-ID: References: <20201224145619.30D1FF40705@rfc-editor.org> <01000176958fd7e7-dffa0747-1473-4830-aec4-b66ad7a4cefd-000000@email.amazonses.com> In-Reply-To: <01000176958fd7e7-dffa0747-1473-4830-aec4-b66ad7a4cefd-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [108.18.114.139] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 81323356-0aec-465c-ccb8-08d8a8399382 x-ms-traffictypediagnostic: SA2PR11MB4779: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HNdBuruWC6i+YuKaQf0nciq0uBhnlnYFaC/nM7YzsMtEyenv7yyCU4Zg2Jby3H0+VCNi3Y8h6CgvxdDwdT8iDqmqkqyYnxQ4n+2pAprx5EQCd3v/r2Bpqi393SBFuoPua8bTFgNQACJnNHKS6b1JSGRSDm5x0DE8Qo4DeDIyG5GjrtbpwepM1rVw3H0RdL6Gkow+4r0Q/Ed0Mt+L5HMFUICOp3Ky0CZF99ASzH7GvA/5ReMO2VrpR35J5DMhzzBpl/MA76XbHq01zaVMOhtIbIsYLfrJi7eZpaIwLRIbuYWtfXKk1SLa+4WfUCNDGDAZXSTpKIZd2X9tVMasb9KBUtIFUa/ZMm8YUG6iRin9Tbpxcl1+PryXDTk64K9vHlTMZvEufty20PjUcEMiVpve6HC6mP7rWTLeDRtwr/tIPukigOOZ4UXf6R/s8Hlc2nIdaBjLQhOucUmLuqkPf0/8dw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB3135.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(39860400002)(396003)(136003)(366004)(346002)(966005)(86362001)(71200400001)(55016002)(186003)(9686003)(8676002)(2906002)(53546011)(6506007)(26005)(478600001)(316002)(8936002)(83380400001)(7696005)(66476007)(52536014)(66446008)(66946007)(66556008)(54906003)(4326008)(64756008)(99936003)(76116006)(66616009)(5660300002)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?5ruKGjgQPEOXZO8Ch6NLwdNaeWAMB5xcGZYevzlRF69wT6wvMq1zqEEGdn0d?= =?us-ascii?Q?MJ5KHeT/e+BQ19e5bo5m6hAZLPrgZk6ZuEis3aiJXouZguK4bKAPqcZv1hQR?= =?us-ascii?Q?sI8232VsY2SAILRnpHNfhdooIpdH+zAAnSCFTxcrGx1sRcr8LYT33zHGr3Fg?= =?us-ascii?Q?af9weMpqcSmnt5udE4uRAdoRSfzQQEwctWEbH0pU+KJxmc+akleqz5S+3a8T?= =?us-ascii?Q?+fw88bwybbRpgTyrWVKDQRWOgieBVxnZRH6TE+hPBg4rFTVPgNUO9CNdmw0+?= =?us-ascii?Q?TTjq232LaCAHCmrtlswzyEOzrliOm4+QU269+mB/sx5bEKlFvevqN27AkJrd?= =?us-ascii?Q?BJCnfgEMrU2akChWqmAl2UO5swO+UYcLmW3+9VD6NaeZ8xH6TcOBlhVa0DNY?= =?us-ascii?Q?bjjuMvnBNkcpYP0MkJADwxrbkZfHKXFjVXrbhMJVaaz2tno3G/YIaEDqJFai?= =?us-ascii?Q?mUl2icQUE1G2SkvaxDgeoMaNN7E+m7Cg3F5R9D6DjJjzLiVXa4N5d6sgAGDc?= =?us-ascii?Q?O9/CGjcwOLLYVYi0i4sqNlmegpvq7PUayvntQ5fBBR61XqwvIJ22i7FgzRaf?= =?us-ascii?Q?WH5bP4TScNc8wA27bcBBUjnSPs7lr5WMCOk6tjFnsPTnzylX051SIApqvFD+?= =?us-ascii?Q?IxwljkbDjqFFR0n1YmAY2/GSHBkKY2hH3vKIiWj/uy3EsVLbHWWWPVo2yRP8?= =?us-ascii?Q?vQjYAhT0Su19y+lwXuqCP/bV34MRju88FI5r8g+8zDkHjODoKXnIVTArQGGt?= =?us-ascii?Q?XkK+7ZUy+jXuBwyoC8rL17RJxcuuPXHKXwcpuols5LzgSNKV5Vloi91u4KKV?= =?us-ascii?Q?xVntXiv3Dot3fpysegNXKbpeyPUMHABxsMjPitWiWo4w1yGvvfrcSPk34uF0?= =?us-ascii?Q?hWqrLE1mYIij3w9r99gE0rGUoMeuXpfs85WI6xVNjKvfGvFHj3iHtyGU7C0r?= =?us-ascii?Q?KWSmk1aZmoZ1+9qhxVLgDEsJz+I+zTdC6qjm65T381g=3D?= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0055_01D6D9F8.81941250" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB3135.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 81323356-0aec-465c-ccb8-08d8a8399382 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2020 18:27:31.2741 (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: DWs9MDIVqXpIZQiGuwuTctGHuoZIzXU8uGQNB1/y1rL1PyZdscO/n5CGeL8IMDIM X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4779 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [netconf] [Editorial Errata Reported] RFC8650 (6368) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 18:27:40 -0000 ------=_NextPart_000_0055_01D6D9F8.81941250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes, that is what I suggest: that we change '22' to '39' in the URI. Eric > -----Original Message----- > From: Kent Watsen > Sent: Thursday, December 24, 2020 11:23 AM > To: Eric Voit (evoit) > Cc: RFC Errata System ; Reshad Rahman (rrahman) > ; Einar Nilsen-Nygaard (einarnn) ; > ludwig@clemm.org; andy@yumaworks.com; warren@kumari.net; Rob Wilton > (rwilton) ; Mahesh Jethanandani > ; muly_i@rad.com; netconf@ietf.org > Subject: Re: [Editorial Errata Reported] RFC8650 (6368) > > Hi Eric, > > Thank you for you comment. But note that the errata system is binary, either an > errata is accepted or rejected. To do what you say entails rejecting this errata > and submitting a different one to say it, Is this what you advocate? > > Thanks, > Kent > > > > On Dec 24, 2020, at 10:14 AM, Eric Voit (evoit) wrote: > > > > Rather than changing the subscription from 22 to 39, the URI should be made: > > https://example.com/restconf/subscriptions/39 > > > > Reasons: > > (1) There is no assumption that the subscription is the same one as > > for the previous example. > > (2) We want to keep the examples in lock-step with RFC8640. > > > > Eric ------=_NextPart_000_0055_01D6D9F8.81941250 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAxMjI0MTgyNzIwWjAjBgkqhkiG 9w0BCQQxFgQUQWHfRwe2Hjduh5s06G58tOcQHd8wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBRENvRULtt5xRFqt6vPfq2RXTXtAKowZsjbIlL6PP5KUnn/WEX7X0YhsMA8+W1zHKJ ANwFIq1IJkiEoTJ0s1UWkTT5QQ2M20+vpIogjAiNc0trMy7TiB+pFCNeJBQmQ6NHEOAgP0kZWstA dTzEvzoJQ1NpwQdv8zBHeKaSMRtEZ/g23LFifL0kA72uqmK5DH7J0aFPVAaIg9LqcmCIaj/IB9oB 7EkbvvC2PnqQenIGdgVzi+exoGutPo9UW7emrw4b0zWLOSscyPzh4gNEdOl80pjcT/O5cOHZyHma RrBrKg+nI9I3jkwBHmmruL8erAGlcxqtulymsZxo5Gjv4+PvAAAAAAAA ------=_NextPart_000_0055_01D6D9F8.81941250-- From nobody Thu Dec 24 10:55:40 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06513A07F0 for ; Thu, 24 Dec 2020 10:55:38 -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, MIME_QP_LONG_LINE=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 180DVAKW4zm9 for ; Thu, 24 Dec 2020 10:55:37 -0800 (PST) Received: from sonic306-2.consmr.mail.bf2.yahoo.com (sonic306-2.consmr.mail.bf2.yahoo.com [74.6.132.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 CD4C33A137F for ; Thu, 24 Dec 2020 10:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1608836135; bh=auNuEVzTXWKzKt1AuA0CZ+u/2BWE8to5e+y7InsM3F4=; h=Date:Subject:From:To:CC:References:From:Subject; b=bbKHdl3Ztx3qUqJKn8fTZIcqi/aGDfKsslfHzrYJOd5DPWZfOhh5EQjddOasyVGD1BpX3amyBL3GgzBvkdFePy5qn3pvO7N81+04h/YEA5l/c4MKrp6Qb9HYR2Z6Pbz4NSp65VZiw+Bh2yQFjIBXOfbe5QfTpl/zzUiNhUEpFQPoPWaRqayLB8ja5VCdgkwYk/iXz1xC6wwRk06fRdVCAXJogorB9eljqfZEs1Vls56G+O4CJTWbymSZoeAa1l+8M07yuzA6ZLdy20u5M7XSi252YCP9OkS5N+5Vcs6CI9cbWLmmN+FG4OuAdMscJJI1X99WnomgEiuA/xFAcxm0Fw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1608836135; bh=e/WBkMnsof3iSLCyIHkOr+MJdiB/Vc/8ZHU0xymyRFx=; h=Date:Subject:From:To:From:Subject; b=RtZrCdu4YwMkXDLMefps2CYprHS85Wyb6hvHS0IUYOXFKhtceG/T8e5xk5Jtb7SDssNE1I/j83rLpSayOa4in610zrg6EYvCccqXekws1KdFXu6MqbGTCO1nu508Nte0Y0X0VqrJwMg9dKLtdVqcEnFgD090TP3fm8zMudoRjSNWPp25vjJDHkOdsspoi+7GXhvCE/36/CjpcSPFas0BfdfAEvyOb80GsrKukjVE2OhAjw5z9fCkMWeX1X7B1piac3H07Poxbqlu+HmUaebDj1QQwjnVKLY7yVL1kLwKwJyBM1P9TZ7teAHlIYKahZAffWLsUvEHgHII9uYxoe+OGA== X-YMail-OSG: CdXmc.sVM1mT7oHQrzJZEnW7Qk5_T4C.RyAK9wLrRVMJFDWQohoySb0.jX4HD9T A497XGTE2VTLQpABDdsFJ1Ty6nOPfArqeFCEKzqX81bPZvlsKCoLv0cILHok3iS7gwyXOQzuo9ZM F8dxYNgPb64eAGbDEZPsKgwq6fSQxZTEJmGbkxUhb5uTakxw6Qbt_prVAGLWwQmxJPbJeRc7c.an ALydTnXtL8vyKQVxBK0NCkaLmlfDVI1o8uuS_xRTdU3puPx8rO_GwGDPy3E85fH92_Cz9j5iVCL4 CE9pDD1dN1fQcEk2B4zkTB5WiKS5XEvhyGlsnRhtYvKAYttbE89YXDctvSQQgmDM_yKkR4zKz.h7 .60n52rhwAHtbrGDijz8vOzIJBkzxL5rJfT0JLULLrpwZhiJ2gvmAsZYgC.VB1SV2qHJpefA5zgU IcUDv0eCVS6CFEO4iH0wnd0b5fh7.yRburIdgCqdYp68kD11EiWQuwoyQDYpuODSuEF7nr3VWOW. L.3wz.PN2zAE8JkUMmRK0P8TO22va1WK.l9hYYF5dgmSdowPFX38g_b750c7NcKG3MDFmvGKkn5a Q6efJZ72QtQ04GGpLA5X6psFudb2kd170ra4ae2zqScmUZwV7Qd8WkMJxpLZ59v72uWrLP91kcVC ZHogXnnu_NtFqftu6hlgECk6yEgs.5nKGJp0_pOC0dVWAnI1HAaEDA0V0U2Re8pdrBzKzd1FbbUR Z5p1UVcbtUHODCBk8iWkWhPuChOCn4U7hnCYglvTmBcgF22Btg59IjJ60bPbqAypoHTuY3HLcJaG OON8Al7gDYKyX6sBG.8OdkWqmgPJ2G6wX3W44d5atSO7kTUdW8wacvdQTaTwQy6xhojtq0I3Tptg _9N1epDF3DgaigTZUQwqbcGL0GTaej5veGqELYdnAzlY3LT.Q_ZdLHIRwv_vwLAj9yUOxNxL3_Ob lK2qvTX0sOsm9y9Rc5vMw040PK6G0kElyb8AcTacj0XyoRYPC4QVHtDdUtUj_sswE9_92HlhzHs8 AL7g0RwU1T7MM6bxPH84PV6frfvO6u61zUZnq_ZgjqAFyJKmlefzuqd6rdGxluPqGEIne_2xXa0O Iu9A9HexwFNcnA2DwWplgZp7YnyGwlxPy34kxGmZVg9FdoM4Q.ZQKUzzJaEqdsLISJcU5CDewwf0 i31sUxFBzcMWrlcYpxZyeogctrpOFuSFdozntPjsQcrghop1FDYUz21cy6FrtlYDgeILitpWjLhn KBU2AsTGSt1kAKUP.SrDV5xlJpBrryYZGBRPQiz9raGzbxcfm_JgL5f.e_tEqBDndLiNFQXmmewH Dma1SniUu.yZY2wpg1wbjmZKdwV77wmNGZBA2XkQRpFJEYLazkyAQ3BDz9zt9tLJoTRrXuVr9lC2 QdTI8CG2_9sJAi2AUflMEPDgPxWI.E_l3tZl5jD7jm.SIqeRB1N7cFY8asrjEEaDQsvC5P53iHDf CqUIgGujL.OigDbTX5wYaBzTP.m8rqHqC_SlXSD3jfddEwifRaL4jc_Av6CD.ouF7snmdTPJsP6u YAC6joHgnmIjlO6rKrDRyerPZ1SjLaRFZ7UUiNAy335idwGDbZsqQE4RWpr9BLHzpxbS.C4z3sVv Ek_NWT_8iVjgUJ0YqXRlC73YG.hYcqAR4gwYMvxHevonZlNnNCa_dmkyqe1LFv272.VjvvMAVaAR TxrGtqcFw_49H1jzuMUyIb.IYkcerAaKIImkDTH8jppABaLA1NjZAAFWS9NvAtrN45CnCNbvB43i 68RK1T6OhTqEEIr6PJLPIw1SXinWZmWnEgVtDpl6Rsw3ZN98YUo1aYvY2vINlbB77qE7IbBFhwLe P1fwV75oxk2o5IHelvEx_Kex3FIfJQ6AYW6VLSGSz_TS02eNTIV9eH36QFfV6mg1XQW8anby7psi 5B46AXYwq.rHEltJ.gFfHZC2ekjBy3M94tL29z_D9JHlMAEioF_UdBLbyg7uW6B_k_7X69OB.7zj dwCwhxoKTzy17AhX3GuCuaZsuhuNv4lrP7VPO6nKgCOVPO12_N7cp8wgqJGPoZH5UhtlpfYF34cV jtkbCjWWw9ccW6xCEvJorzxuxjhD7r.2d6o1u.QFiwoXAF0Y69Dkws_LULtOFm2KtIhch6LQZ2rV yiKvoYAKOCVICdNUjPLtlfI15JB4hiwJdHdrZE.0CStc5WoXk05F0YaXlGstRmqGPwTIW2KmwTQC 3Hh7Bk27dK6YB63Cvxhxi7uXLcXyXGZzgwoxRPKfg96UYGRCae19uY_ekFkvUiAZh08JQO_JjOwQ I2U2TcDXKuwtXJWii42Yrw2RjoqOysBV6sJ1Vj207wILywqNsWCCi7h5oijXXgVhgCr3wG9of2Bi uNL4lqZJc7GYc6pJcULJfkcXxAelAyYcHRSQCGfUUZhNUXytXr4_ZlQa_1OleFdKlX7leWs3sVKg ERWDVF8NA3N0jlGpAxQWIUDChPhETrUFsms6ZNmnYSSb.g7bssgIj6EDAuJ4lk5aDbCOeCykRcTX cqEoGS6jbhkb6ukC6UcP1i_0Cx7l.qz0qmG1NW2zVmKndXLdnix.kK2AuZ7egvRfbg.SGde7cJOb 1iZjC3ogMV3v7aL_HBt2wj7ReUEWrllR_AyHq5oZz_14M4.tQzuoHvz8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Thu, 24 Dec 2020 18:55:35 +0000 Received: by smtp421.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ca035ca17c3ba4d68511e7f16c16ca69; Thu, 24 Dec 2020 18:55:33 +0000 (UTC) User-Agent: Microsoft-MacOutlook/16.44.20121301 Date: Thu, 24 Dec 2020 13:55:30 -0500 From: Reshad Rahman To: "Eric Voit (evoit)" , Kent Watsen CC: "netconf@ietf.org" , RFC Errata System Message-ID: <8A1D1573-6DBB-4767-9C4C-944AFD6D3058@yahoo.com> Thread-Topic: [netconf] [Editorial Errata Reported] RFC8650 (6368) Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable References: <8A1D1573-6DBB-4767-9C4C-944AFD6D3058.ref@yahoo.com> X-Mailer: WebService/1.1.17278 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] [Editorial Errata Reported] RFC8650 (6368) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 18:55:39 -0000 +1.=20 =EF=BB=BFOn 2020-12-24, 1:27 PM, "netconf on behalf of Eric Voit (evoit)" wrote: Yes, that is what I suggest: that we change '22' to '39' in the URI. Eric > -----Original Message----- > From: Kent Watsen > Sent: Thursday, December 24, 2020 11:23 AM > To: Eric Voit (evoit) > Cc: RFC Errata System ; Reshad Rahman (rra= hman) > ; Einar Nilsen-Nygaard (einarnn) ; > ludwig@clemm.org; andy@yumaworks.com; warren@kumari.net; Rob Wilton > (rwilton) ; Mahesh Jethanandani > ; muly_i@rad.com; netconf@ietf.org > Subject: Re: [Editorial Errata Reported] RFC8650 (6368) >=20 > Hi Eric, >=20 > Thank you for you comment. But note that the errata system is binary= , either an > errata is accepted or rejected. To do what you say entails rejecting= this errata > and submitting a different one to say it, Is this what you advocate? >=20 > Thanks, > Kent >=20 >=20 > > On Dec 24, 2020, at 10:14 AM, Eric Voit (evoit) w= rote: > > > > Rather than changing the subscription from 22 to 39, the URI should= be made: > > https://example.com/restconf/subscriptions/39 > > > > Reasons: > > (1) There is no assumption that the subscription is the same one as > > for the previous example. > > (2) We want to keep the examples in lock-step with RFC8640. > > > > Eric _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Dec 24 11:00:12 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABDE3A137F for ; Thu, 24 Dec 2020 11:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=iecc.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 SS9Ivyf0Kkss for ; Thu, 24 Dec 2020 11:00:09 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 D26853A0F35 for ; Thu, 24 Dec 2020 11:00:08 -0800 (PST) Received: (qmail 81310 invoked from network); 24 Dec 2020 19:00:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=13d9a.5fe4e537.k2012; i=johnl-iecc.com@submit.iecc.com; bh=POJHSi50EEbHKVVo/Lh3H46vdRpQraFJvz9PfhtWyxI=; b=T9aJG+nG5sWGU8uWUwMBWbx6H+s3q9lFalLxGjm34cEnCM+aPpF6Iwic4cE51cBoeKMYDlWozwforaWmkje7uBBEQ6Xi9DC34IdG2LDg0o9HyPuhD978H56PNytFDc379+Gp6rjWFmkXPT47t9SFUYPwbY3irtnvArUJJO5LDY1UBBo5CcOJoRTjQM96nGSGOh9DEDMozao2yxgc9b8e9bwwlzb4QWAnFvhimtTVKfPA/nQT8apmEdX1N9Z7cb96J1lUODKg4Of6PUKRk3DgokpE+8maUJW38EqrsTcyiuSFHMTdkyzRFYIBFGVEQu5MtjSINbd8eiCOQxWxUH0f4Q== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 24 Dec 2020 19:00:07 -0000 Date: 24 Dec 2020 14:00:06 -0500 Message-ID: <62b91ed2-41a-61bf-daea-e37180172946@iecc.com> From: "John R. Levine" To: "RFC Errata System" , evoit@cisco.com, ludwig@clemm.org, alberto.gonzalez@microsoft.com, einarnn@cisco.com, ambtripa@cisco.com, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, mjethanandani@gmail.com Cc: muly_i@rad.com, netconf@ietf.org In-Reply-To: <20201224143250.0CF77F40709@rfc-editor.org> References: <20201224143250.0CF77F40709@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [netconf] [Editorial Errata Reported] RFC8639 (6366) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 19:00:11 -0000 This is a limitation of the script that mechanically generates HTML from legacy text RFCs. There are no hyperlinks in the RFC itself. Reject, please. On Thu, 24 Dec 2020, RFC Errata System wrote: > The following errata report has been submitted for RFC8639, > "Subscription to YANG Notifications". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6366 > > -------------------------------------- > Type: Editorial > Reported by: Muly Ilan > > Section: 4. > > Original Text > ------------- > feature subtree { > description > "This feature indicates support for YANG subtree filtering."; > reference > "RFC 6241: Network Configuration Protocol (NETCONF), > Section 6"; > } > > feature supports-vrf { > description > "This feature indicates that a publisher supports VRF > configuration for configured subscriptions. VRF support for > dynamic subscriptions does not require this feature."; > reference > "RFC 8529: YANG Data Model for Network Instances, > Section 6"; > } > > Corrected Text > -------------- > feature subtree { > description > "This feature indicates support for YANG subtree filtering."; > reference > "RFC 6241: Network Configuration Protocol (NETCONF), > Section 6"; > } > > feature supports-vrf { > description > "This feature indicates that a publisher supports VRF > configuration for configured subscriptions. VRF support for > dynamic subscriptions does not require this feature."; > reference > "RFC 8529: YANG Data Model for Network Instances, > Section 6"; > } > > Notes > ----- > In the HTML version the two hyperlinks "Section 6" (for 'subtree' feature and for 'supports-vrf' feature) point to wrong RFCs. > > 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. > > -------------------------------------- > RFC8639 (draft-ietf-netconf-subscribed-notifications-26) > -------------------------------------- > Title : Subscription to YANG Notifications > Publication Date : September 2019 > Author(s) : E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Dec 24 11:45:55 2020 Return-Path: <0100017696493c92-1a3c9143-3975-444f-b0f6-c12c39a58ef7-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 AC1A93A0657 for ; Thu, 24 Dec 2020 11:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r3rHqzZYWJN for ; Thu, 24 Dec 2020 11:45:52 -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 1F7CB3A061B for ; Thu, 24 Dec 2020 11:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1608839150; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=lCsS09B3r+3gbKbY41RzNfrDgRgGzdGmO2awocNaJIg=; b=gK7EQEfJn1jt8U3PU5feshV40ke+HC8COdHUOx9AQm5oeGgDmL9R0/VViwW9snAr fWTqBYElbcQqi4f9f6GKjopFK6j+RH3jeRpPGaXDJbQhiH7neUqTcAGtSVdAa7e3dk+ XVF1kE83LHhGFPLn3OC7xBmP3vdqQxEQPnQQd+6s= From: Kent Watsen Message-ID: <0100017696493c92-1a3c9143-3975-444f-b0f6-c12c39a58ef7-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2F571FD6-436B-459E-988A-B1080D62DFE5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 24 Dec 2020 19:45:50 +0000 In-Reply-To: <8A1D1573-6DBB-4767-9C4C-944AFD6D3058@yahoo.com> Cc: "Eric Voit (evoit)" , RFC Errata System , Reshad Rahman To: "netconf@ietf.org" , Muly Ilan References: <8A1D1573-6DBB-4767-9C4C-944AFD6D3058.ref@yahoo.com> <8A1D1573-6DBB-4767-9C4C-944AFD6D3058@yahoo.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.12.24-54.240.48.110 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Editorial Errata Reported] RFC8650 (6368) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 19:45:54 -0000 --Apple-Mail=_2F571FD6-436B-459E-988A-B1080D62DFE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Let it be noted that this Errata (6368) is rejected. Muly, please submit another Errata with the solution forwarded by Eric. Kent // as co-Chair > On Dec 24, 2020, at 1:55 PM, Reshad Rahman wrote: >=20 > +1.=20 >=20 > =EF=BB=BFOn 2020-12-24, 1:27 PM, "netconf on behalf of Eric Voit = (evoit)" wrote: >=20 > Yes, that is what I suggest: that we change '22' to '39' in the = URI. >=20 > Eric >=20 >> -----Original Message----- >> From: Kent Watsen >> Sent: Thursday, December 24, 2020 11:23 AM >> To: Eric Voit (evoit) >> Cc: RFC Errata System ; Reshad Rahman = (rrahman) >> ; Einar Nilsen-Nygaard (einarnn) = ; >> ludwig@clemm.org; andy@yumaworks.com; warren@kumari.net; Rob Wilton >> (rwilton) ; Mahesh Jethanandani >> ; muly_i@rad.com; netconf@ietf.org >> Subject: Re: [Editorial Errata Reported] RFC8650 (6368) >>=20 >> Hi Eric, >>=20 >> Thank you for you comment. But note that the errata system is = binary, > either an >> errata is accepted or rejected. To do what you say entails rejecting = this > errata >> and submitting a different one to say it, Is this what you advocate? >>=20 >> Thanks, >> Kent >>=20 >>=20 >>> On Dec 24, 2020, at 10:14 AM, Eric Voit (evoit) = wrote: >>>=20 >>> Rather than changing the subscription from 22 to 39, the URI should = be > made: >>> https://example.com/restconf/subscriptions/39 >>>=20 >>> Reasons: >>> (1) There is no assumption that the subscription is the same one as >>> for the previous example. >>> (2) We want to keep the examples in lock-step with RFC8640. >>>=20 >>> Eric >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 --Apple-Mail=_2F571FD6-436B-459E-988A-B1080D62DFE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Let = it be noted that this Errata (6368) is rejected.

Muly, please submit = another Errata with the solution forwarded by = Eric.

Kent // as co-Chair


On Dec = 24, 2020, at 1:55 PM, Reshad Rahman <reshad@yahoo.com> = wrote:

+1.

=EF=BB=BFOn 2020-12-24, = 1:27 PM, "netconf on behalf of Eric Voit (evoit)" <netconf-bounces@ietf.org on behalf of evoit=3D40cisco.com@dmarc.ietf.org> wrote:

   Yes, that is what I = suggest: that we change '22' to '39' in the URI.

   Eric

-----Original = Message-----
From: Kent Watsen <kent+ietf@watsen.net>
Sent: Thursday, = December 24, 2020 11:23 AM
To: Eric Voit (evoit) <evoit@cisco.com>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>; Reshad Rahman (rrahman)
<rrahman@cisco.com>; Einar Nilsen-Nygaard (einarnn) = <einarnn@cisco.com>;
ludwig@clemm.org; andy@yumaworks.com; warren@kumari.net; Rob = Wilton
(rwilton) <rwilton@cisco.com>; Mahesh Jethanandani
<mjethanandani@gmail.com>; muly_i@rad.com; netconf@ietf.org
Subject: Re: [Editorial Errata Reported] RFC8650 (6368)

Hi Eric,

Thank = you for you comment.  But note that the errata system is binary,
   either an
errata is accepted or = rejected.  To do what you say entails rejecting this
   errata
and submitting a = different one to say it,  Is this what you advocate?

Thanks,
Kent


On Dec = 24, 2020, at 10:14 AM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

Rather than changing the = subscription from 22 to 39, the URI should be
   made:
https://example.com/restconf/subscriptions/39

Reasons:
(1) There is no = assumption that the subscription is the same one as
for = the previous example.
(2) We want to keep the examples in = lock-step with RFC8640.

Eric

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



= --Apple-Mail=_2F571FD6-436B-459E-988A-B1080D62DFE5-- From nobody Thu Dec 24 11:52:21 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C093A07F4 for ; Thu, 24 Dec 2020 11:52:19 -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 0CQ8FD_HQRKR for ; Thu, 24 Dec 2020 11:52:17 -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 AB43E3A07EA for ; Thu, 24 Dec 2020 11:52:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 04B14F4070D; Thu, 24 Dec 2020 11:51:57 -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: <20201224195157.04B14F4070D@rfc-editor.org> Date: Thu, 24 Dec 2020 11:51:57 -0800 (PST) Archived-At: Subject: [netconf] [Editorial Errata Reported] RFC8650 (6369) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 19:52:19 -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/eid6369 -------------------------------------- Type: Editorial Reported by: Muly Ilan Section: A.2.1 Original Text ------------- A.2.1. "subscription-modified" A "subscription-modified" encoded in JSON would look like: { "ietf-restconf:notification" : { "eventTime": "2007-09-01T10:00:00Z", "ietf-subscribed-notifications:subscription-modified": { "id": 39, "uri": "https://example.com/restconf/subscriptions/22" "stream-xpath-filter": "/example-module:foo", "stream": { "ietf-netconf-subscribed-notifications" : "NETCONF" } } } } Corrected Text -------------- A.2.1. "subscription-modified" A "subscription-modified" encoded in JSON would look like: { "ietf-restconf:notification" : { "eventTime": "2007-09-01T10:00:00Z", "ietf-subscribed-notifications:subscription-modified": { "id": 39, "uri": "https://example.com/restconf/subscriptions/39" "stream-xpath-filter": "/example-module:foo", "stream": { "ietf-netconf-subscribed-notifications" : "NETCONF" } } } } Notes ----- Change the URI to match the ID. 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 Dec 28 08:06:16 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEF43A0C4A for ; Mon, 28 Dec 2020 08:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.301 X-Spam-Level: X-Spam-Status: No, score=-10.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xa-tZRCDxsRi for ; Mon, 28 Dec 2020 08:06:13 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496693A0BF3 for ; Mon, 28 Dec 2020 08:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=285; q=dns/txt; s=iport; t=1609171573; x=1610381173; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=gQhJuWAJEIj8MZEPvRdzKug23Ke1O7QvnmPIJTkaaYE=; b=AHKwl6VqmZTvFrnqOyxwRHziWwBSsA6J1FjypLxDzccnw93hbbVocfd/ eJ474LsO2TDdeHz8zCGPYHEz8D0UhDB9aR7jHp++zjo5kFalA9Pcnmatl 0yBItHJ1nItvg1+ebQFid5N+ZIf/HvnxS2neHVWcbuIP4j3g7vouKtq+v w=; X-IPAS-Result: =?us-ascii?q?A0A/BwC4AepfjBbLJq1igQmBT4MhVwEgEoRtiQSHeZp/g?= =?us-ascii?q?WgLAQEBDQEBJQoEAQGGQCY3Bg4CAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBh?= =?us-ascii?q?joMhh0VdgImAl8NCAEBgyIBgwYPrTt2gTKEUwMPL0SDNoE8BoEOKo1qgUE/g?= =?us-ascii?q?TiGDQIDAYEhg1KCYASDKFOeRpwogwCJKolxiDEFBwMfgxcBj26PSp8big6MF?= =?us-ascii?q?QIKBxaBbCKBWTMaCBsVgyVPGQ2OO4hrhUVAA2cCBgoBAQMJjS0BAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,455,1599523200"; d="scan'208";a="32247928" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Dec 2020 16:06:09 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) (authenticated bits=0) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPSA id 0BSG68Ld020828 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Dec 2020 16:06:09 GMT To: NETCONF From: Benoit Claise Message-ID: <8cab99d7-e94e-8f3a-87f5-c23274e764df@cisco.com> Date: Mon, 28 Dec 2020 17:06:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Authenticated-User: bclaise X-Outbound-SMTP-Client: 10.55.221.37, ams-bclaise-nitro4.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [netconf] draft-claise-netconf-metadata-for-collection 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, 28 Dec 2020 16:06:15 -0000 Dear all, Unfortunately, I let draft-claise-netconf-metadata-for-collection die. This was a mistake, now corrected. https://datatracker.ietf.org/doc/draft-claise-netconf-metadata-for-collection/ Granted, only minor editorial changes at this point in time. Regards, Benoit From nobody Tue Dec 29 17:17:16 2020 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035E13A0D85; Tue, 29 Dec 2020 17:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmwkwdUEKo8i; Tue, 29 Dec 2020 17:17:11 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5164A3A0D82; Tue, 29 Dec 2020 17:17:09 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BU1H2Le015105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Dec 2020 20:17:06 -0500 Date: Tue, 29 Dec 2020 17:17:01 -0800 From: Benjamin Kaduk To: Kent Watsen Cc: Yoav Nir , "netconf@ietf.org" , draft-ietf-netconf-trust-anchors.all@ietf.org, secdir@ietf.org Message-ID: <20201230011701.GO89068@kduck.mit.edu> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <010001768d05bf5b-eb6d3807-2d23-45c8-a905-dfdaf9fe5bb3-000000@email.amazonses.com> 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, 30 Dec 2020 01:17:13 -0000 Hi Kent, I'm not Yoav, but... On Wed, Dec 23, 2020 at 12:35:32AM +0000, Kent Watsen wrote: > Hi Yoav, > > I finally found some time :sigh: ;) > > Please see below for responses to your comments. > > Kent > > > > On Oct 2, 2020, at 7:20 AM, Kent Watsen wrote: > > > > [-last-call] > > > > Hi Yoav, > > > > Thank you for your review! The takeaway for me is that some clarifications are needed, but otherwise the draft is fundamentally okay. I will post an update, or perhaps just a GitHub commit, for your review, when I get a chance. That said, my getting a chance will be delayed as I have a major engagement I need to focus on now. This email is just to let you know that your review has not been forgotten. > > > > Thanks again, > > Kent > > > > > >> On Sep 25, 2020, at 7:02 PM, Yoav Nir via Datatracker wrote: > >> > >> Reviewer: Yoav Nir > >> Review result: Has Issues > >> > >> I have reviewed this document as part of the security directorate's ongoing > >> effort to review all IETF documents being processed by the IESG. These > >> comments were written primarily for the benefit of the security area directors. > >> Document editors and WG chairs should treat these comments just like any other > >> last call comments. > >> > >> The document defines a YANG model for managing a trust anchor store. It allows > >> two kinds of trust anchors: certificates and raw public keys. However, > >> certificates are not just containers for public keys. Certificates include > >> attributes about key usage, path constraints and name constraints, all of which > >> constrain the ability to use the public key, and are relevant for trust > >> anchors. As far as I can tell the document does not include any attributes to > >> equivalently constrain the use of the raw public keys. If the intention is > >> that raw public keys will not be constrained, the document should state this > >> explicitly. > > Good catch. You’re right that this document is not constraining the raw keys in the truststore. Looking deeper, I see that the keys are unconstrained in both the “keystore” draft and the common “crypto-types” draft. It seems like the right thing to do is to put a Security Consideration note into each draft. Something like this? > > 4.2. Unconstrained Public Key Usage > > This module enables the configuration of public keys without > constraints on their usage, e.g., what operations the key is allowed > to be used for (encryption, verification, both). > > This module also enables the configuration of certificates, where > each certificate may constrain the usage of the public key according > to local policy. > > Thoughts? 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. Thanks, Ben From nobody Wed Dec 30 13:03:58 2020 Return-Path: <01000176b576c690-7bb22a7a-1fb1-485f-bb06-51f3c08d0fdc-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 B352E3A00C9; Wed, 30 Dec 2020 13:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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 FT-S0SSKOQwE; Wed, 30 Dec 2020 13:03:50 -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 2DC0E3A00C4; Wed, 30 Dec 2020 13:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1609362229; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=uJKDkbzRYh/Fcq3X5jfz1qH5xA6WAvBMcuLtSq4Lx8c=; b=R5vgIUWA9clb7xaGdH6gVz/GEidzeQYF+UOdyAXzm6buHO9/K4FWiFoUoFLO2IP0 JEeC59hW/OJLa99AQ5s/5GffT73ut1bvxK6UjLnIOxIvfmWoAxX/NZaqzWdS2SqOzay IsK64WMd3hbXJoC+RgU+Dme1x2hmxmjq0oWmWB7s= From: Kent Watsen Message-ID: <01000176b576c690-7bb22a7a-1fb1-485f-bb06-51f3c08d0fdc-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_05EA0C49-FECA-4115-A0B3-683577EDF065" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 30 Dec 2020 21:03:48 +0000 In-Reply-To: <20201230011701.GO89068@kduck.mit.edu> Cc: Yoav Nir , "netconf@ietf.org" , draft-ietf-netconf-trust-anchors.all@ietf.org, 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> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.12.30-54.240.48.93 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, 30 Dec 2020 21:03:52 -0000 --Apple-Mail=_05EA0C49-FECA-4115-A0B3-683577EDF065 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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... >=20 > Thanks, >=20 > Ben Kent --Apple-Mail=_05EA0C49-FECA-4115-A0B3-683577EDF065 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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


= --Apple-Mail=_05EA0C49-FECA-4115-A0B3-683577EDF065--