[netconf] Comments on draft-ietf-netconf-netconf-event-notifications-16

Rohit R Ranade <rohitrranade@huawei.com> Wed, 13 February 2019 04:23 UTC

Return-Path: <rohitrranade@huawei.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 BCB0A12D4F3 for <netconf@ietfa.amsl.com>; Tue, 12 Feb 2019 20:23:41 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4a-k6856CnD for <netconf@ietfa.amsl.com>; Tue, 12 Feb 2019 20:23:40 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E69B212D4EC for <netconf@ietf.org>; Tue, 12 Feb 2019 20:23:39 -0800 (PST)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A0EE4AA0F11E37D80828 for <netconf@ietf.org>; Wed, 13 Feb 2019 04:23:37 +0000 (GMT)
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 13 Feb 2019 04:23:37 +0000
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0415.000; Wed, 13 Feb 2019 12:23:29 +0800
From: Rohit R Ranade <rohitrranade@huawei.com>
To: Netconf <netconf@ietf.org>
Thread-Topic: Comments on draft-ietf-netconf-netconf-event-notifications-16
Thread-Index: AdTDTNHz0tddb+pOReG4UYkemLiJQA==
Date: Wed, 13 Feb 2019 04:23:28 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCF5FE8@dggeml510-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BCF5FE8dggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/x_CgDK8HKr3nJ1WYD1RMClcLW2k>
Subject: [netconf] Comments on draft-ietf-netconf-netconf-event-notifications-16
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: Wed, 13 Feb 2019 04:23:42 -0000

Hi All,

Editorial:

1.       "resynch-subscription" is used in 4 places with an additional 'h' after sync. It is "resync-subscription" in draft-ietf-netconf-yang-push-22

2.       Section 7  bullet 3, "this MAY but does not have to be included", can be replaced with just "optional" ?

3.       Section 7, bullet 4,  "section 2.4.6" link looks to be broken.

4.       Section 5 refers to many RPCs, but there is no reference to the documents which define these RPCs.

5.       Since there are many RPC names used, there are too many hyperlinks pointing to their sources in the document. Whether we can have a separate section which provides the list of RPCs used in this draft and their source document. The increase in hyperlinks leads to distraction while reading.


Technical:

1.       Section 3 "reply with the [RFC6241] error "operation-not-supported"". I think this should be an "<rpc-error> element is returned with an <error-tag> value of "operation-not-supported". Similar occurrence in another place in same section.

2.       Is the intention that RFC5277 be implemented and then this draft be supported on top of it ? I see that there are 7 references to RFC5277 , including definitions of <notification> and its encoding mechanism. Whether we can add a statement regarding this point ?

With Regards,
Rohit R