Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 30 September 2019 14:44 UTC

Return-Path: <rwilton@cisco.com>
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 6689312008B for <netconf@ietfa.amsl.com>; Mon, 30 Sep 2019 07:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=jyoTCd1W; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=taLkkHjR
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 v_EAfkgLBTb4 for <netconf@ietfa.amsl.com>; Mon, 30 Sep 2019 07:44:52 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECF81200B9 for <netconf@ietf.org>; Mon, 30 Sep 2019 07:44:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28020; q=dns/txt; s=iport; t=1569854692; x=1571064292; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=atejsqRNxDlxctaiz/D6xxyrDZkYofCoPqUbBLf5eVg=; b=jyoTCd1WRKNcMF/AnjzgztlmW3vv5uP8wN5rvtZ8pUgj4HYGlIoAD6fb ApxCVzDaHoz7FZd0lTM2ZP3+gUVzFV4Jm7crPrasiCR9iJ0MXfSDOeoZR A4+NzyGPtXXoTevZkvrEEUHt05P4iXgpCFcoSaAVGk6DmHiuQ9FkDrF+d A=;
IronPort-PHdr: =?us-ascii?q?9a23=3A2W3HGRNvmvk8Tg/2t7El6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhM//ucys8NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAAB5FJJd/4wNJK1cChsBAQEBAwE?= =?us-ascii?q?BAQwDAQEBgVMGAQEBCwGBGy8kLANtViAECyqEIoNHA4RShgdNgg9+iGmOD4E?= =?us-ascii?q?uFIEQA1QJAQEBDAEBJQgCAQGBTIJ0AheDLCM0CQ4CAwkBAQQBAQECAQUEbYU?= =?us-ascii?q?tDIVLAQEBAQMSEQoTAQE1Aw8CAQYCDgMEAQEOEwcDAgICHxEUCQgCBAESCBq?= =?us-ascii?q?DAYEdTQMdAQIMkWqQYQKBOIhhdYEygn0BAQWBOAKDSA0LghcDBoE0AYpigSs?= =?us-ascii?q?YgUA/gRFGgU5JNT6CGkcBAQOBMwUOAhgrCYJXMoImjS+CNoUtl1BBCoIihwW?= =?us-ascii?q?KBIQdgjeHTo1SgV+OIYE9hluCCo59AgQCBAUCDgEBBYFSOSqBLnAVgydQEBS?= =?us-ascii?q?BT4NzhRSFP3SBKY0mASQHgicBAQ?=
X-IronPort-AV: E=Sophos;i="5.64,567,1559520000"; d="scan'208,217";a="418772938"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Sep 2019 14:44:51 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x8UEip2i014430 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Sep 2019 14:44:51 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 30 Sep 2019 09:44:50 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 30 Sep 2019 09:44:49 -0500
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 30 Sep 2019 10:44:49 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=miOm3LKgWm34TnH7TN9plB4PWxXGjfT+epd2QH6Dm68B7r7ehGaISb8DAgG6Ng/j/04ZCM4V7kFiQorXHYf3YEArdDPbAp5uJJoVez+IjXJlosP2JzOs3xmRlfcroD1C0k27ODFEaX8xFSfgHExOs1omIYzVRBCmvuS8IJbF+doqfAsXoFay3GRbRbUYmHj7HsXjkA664F6SdND/Tn1UIhpooYsiCC7iYmxSJ8xeSmcT97PyOxG+zk1SVwOHf9AmBlicc8NFtws67Ix1v5z6z0W4WYX5eWdiGpVwsWkQrmXVKvbV4ZKT7UzcRY7Q635UTrKh8PSL7m8Lgexjwc4FGw==
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=atejsqRNxDlxctaiz/D6xxyrDZkYofCoPqUbBLf5eVg=; b=P30iA4U4UEEjV2b5wzXS9GK09QMhlLoy0eRyE5AqfP0O4Q9lSx8Xp9ddjxpJvMi6BfHQeywd+/CGR8oxNiJR0mpK6E+9N285xxtgLQPVeHLpLOC2gT9dSnbpMDnPwB1s0o8nmEMDujN5zanmtpHIuAKCSqpAO+KwYUNtmS/b0gByei27VNQZCqTTxvO/L+g1rqPzxsBGOMv5S99fFolsQRcoPKu9AVd1ArH1te2jSNs7aJ/2S53hJpaXvHD5lemvw8v5h50SkhINvEnASBylCSzbybn1ZSOzh5NFfOW8V7j7dtOJAhYqmUy9LdXrYiC5DgcNtB6vbAsFwaMD8cS8Wg==
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=atejsqRNxDlxctaiz/D6xxyrDZkYofCoPqUbBLf5eVg=; b=taLkkHjRx84ieJW4pxDZtfnRz0t3aVDpmXrqyI/Jtt4/bvN82xztMXZ2shO7ah/CMqXmwAvyCDCATkKvw0MVTb32WaEeT04ID2h2mrC2awcpL5D/RvoIHSQRhiKaxQPHzBiP550A7QtDocfUU/5wIhPY1pGfSFmDTT02LHfON9M=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3693.namprd11.prod.outlook.com (20.178.252.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Mon, 30 Sep 2019 14:44:48 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::cca:41bd:b0bb:c549]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::cca:41bd:b0bb:c549%2]) with mapi id 15.20.2305.017; Mon, 30 Sep 2019 14:44:48 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>, =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= <balazs.lengyel@ericsson.com>
Thread-Topic: [netconf] WGLC for draft-ietf-netconf-notification-capabilities
Thread-Index: AQHVaCiuRGm9KKbjG02ELVvMwRO/n6c7MLcAgAkj1tA=
Date: Mon, 30 Sep 2019 14:44:48 +0000
Message-ID: <MN2PR11MB43663B72FBA8D839E539A001B5820@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <D3B39347-DFB7-4BEE-8B22-0EE07AEB1F5A@gmail.com> <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com>
In-Reply-To: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [2001:420:c0c0:1005::147]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 492a0696-aa15-47ca-af40-08d745b4be27
x-ms-traffictypediagnostic: MN2PR11MB3693:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR11MB36937D0213B9CEDEA7B66568B5820@MN2PR11MB3693.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01762B0D64
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(366004)(39860400002)(376002)(396003)(189003)(199004)(51444003)(71200400001)(46003)(76176011)(6306002)(7110500001)(54896002)(236005)(55016002)(25786009)(6436002)(14454004)(71190400001)(15650500001)(2420400007)(6246003)(9686003)(66446008)(66476007)(476003)(64756008)(33656002)(66556008)(9326002)(606006)(14444005)(76116006)(81156014)(790700001)(81166006)(66946007)(8936002)(52536014)(256004)(186003)(6116002)(86362001)(229853002)(6506007)(11346002)(99286004)(110136005)(102836004)(5660300002)(7736002)(2906002)(316002)(446003)(486006)(7696005)(53546011)(478600001)(8676002)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3693; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /XlPYqbuNVfLJeBDqzEJY2tMRQXzM5r4aN+WQmunwARJjbmR1zE67B4W4RRYcHBiclEU/H0VerqwEOcOq7pVOY2kcDxS03CgZUEZVs7frlKayofrB3CHZHFZY31LCxzB5ENa2vAgM0ytk6GJ+2Fqgfj+DMOmMIfGwV8ZdJw2UFYAg3VmJ6Ia7qxfS8xN51RnKBxZxh3RCpFwWa3aVoPfNmARyLmOkN3sr/f2DFZvZyWEIf1/6n1M2PpbWgtmhpdTw14K/d7ddICNTLEinW91yQn02SC+Oy8WdbEop8MtRB3Ss6Bj/8pP65MUlz1i/jt43Ixhu+h+bXlS+17F0QoCMc6UyQa5abcrzIUzZquj8fDF6NVGOMHKN5jzNySTxbJrqSPA9SaAkpOd8w9ltfgNPIFLCPfxrkmaSyjKeRp3HjsEaztOSwf7emJmJmqRijammjOBwGiBfliHRPaAD7czqA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43663B72FBA8D839E539A001B5820MN2PR11MB4366namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 492a0696-aa15-47ca-af40-08d745b4be27
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2019 14:44:48.2546 (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: r1aF7xw65/kA+I6ZcP3VVp4Jldis9CHPi0S3tYkD6xR5+glPr6wF3PvkyJQx5Lyt7KHPrJ76Qn7B4p7QX3w/tw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3693
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Q3ZWeTZ7TwCudtFoESLpsIBq8tc>
Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Sep 2019 14:44:55 -0000

Hi,

I have reviewed version -05b of this document.

I am supportive of this document, and its general approach of making subscription capability information available both online and offline.  I believe that this information is valuable to making YANG-Push more usable.

A few comments:

  1.  Terminology and Introduction.  I wasn’t sure whether “implementation-time information” is the best description, or whether “offline information” would be a better description.   I believe that the key is that the information is available offline without requiring access to all the network devices.  Although I can see that providing this information at implementation time is useful and should be RECOMMENDED, I don’t think that it should be a MUST/SHALL (e.g. as per section 3).
  2.  Another benefit of having information available offline is that if there are classes of devices running the same software and hardware then they should all have the same capabilities without having to check each and every one.  To this end, it would be nice if there was some sort of simple checksum mechanism that could be used to ensure that the information stored in the instance-data file exactly matches the equivalent information provided by the server.  This would allows NMS implementations to be coded to the instance-data document, and then just validate that the checksums match those provided by the server without having to fetch and check that a portion of the data tree matches.  As a side note – YANG packages has a similar requirement.
  3.  Section 3, by “formal”, do you mean “machine readable”?  Otherwise expanding what is meant by formal might be useful.
  4.  Section 3, instead of “amount of notifications” would “throughput of notification data” be better?

In terms of the YANG model, I think that it is possible to design this in a slightly more regular (and arguably simpler) way:

  *   Rename “datastore-subscription-throughput-capabilities grouping” to “subscription-throughput-capabilities” (since the grouping is also used at the subscription level)
  *   Add “on-change-supported” leaf to “subscription-throughput-capabilities” grouping, but change its type to an enum of “all-nodes, config-only, state-only” – this could then work in a fully hierarchical way.  (I.e. the existing on-change-supported-for-config, on-change-supported-for-state , on-change-supported could be removed).
  *   Instead of having a set of “datastore” level parameters, could these just be expressed as the set of parameters that apply to “/” within a datastore (e.g. as described in NACM YANG module “leaf path“)?  I.e. given that you support hierarchical paths within a datastore, it just means that you need two levels, per device and per datastore.
  *   Ideally, it would be better to have a dependency on RFC6991-bis for node-instance-identify rather than on NACM.  Although I guess that you may not want to delay this RFC.
  *   Currently “leaf on-change-supported” is marked as mandatory true, but I’m not sure why it should be so.
  *   Is “max-objects-per-update” optional.  What if the server doesn’t have any hard limit - can they just not return a value here?  If so, perhaps assigning a default value of uint32_max might make sense?

In the security section, are these capabilities sensitive information?  E.g. could it be used by an attacker to more effectively DDOS a server (by knowing which paths to target susbscriptions towards)?

Thanks,
Rob


From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh Jethanandani
Sent: 24 September 2019 18:50
To: Netconf <netconf@ietf.org>
Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

We were supposed to have closed on the WGLC today. However, between the document becoming a WG item and it going into LC, we have not received too many comments on the draft. As such, we are extending the LC by another week. Please review the draft and provide any comments you might have.

Mahesh & Kent (as co-chairs)



On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> wrote:

Authors have published -04<https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-04> version of the draft, which addresses comments they received in IETF 105. If you provided comments please check to make sure your comments have been addressed. At this point, the authors believe that the document is ready for WGLC.

This therefore starts a two week LC, ending on September 24th. Please provide any technical comments you might have on the document. If you believe the document is not ready for LC, please state your reasons.

We will issue a IPR poll separately.

Mahesh & Kent (as co-chairs)