[Netconf] RGW YANG push -18 LC comments [part 2]
Robert Wilton <rwilton@cisco.com> Mon, 10 September 2018 10:19 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 0158C130E59 for <netconf@ietfa.amsl.com>; Mon, 10 Sep 2018 03:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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, T_DKIMWL_WL_HIGH=-0.01, 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 TUz4X6OCani3 for <netconf@ietfa.amsl.com>; Mon, 10 Sep 2018 03:19:00 -0700 (PDT)
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 8BBC7130DEB for <netconf@ietf.org>; Mon, 10 Sep 2018 03:18:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14129; q=dns/txt; s=iport; t=1536574739; x=1537784339; h=from:subject:to:message-id:date:mime-version; bh=d5e8DrJPMeplIGWdxje+BeL+6R0wPvmlmAVK7GzdUNI=; b=Egdf4jwJUSD7Tk60LLZd33ovzUeTgA2UglDJgNZxqquQK6jPYxGcZFu7 Ywy3olPGBiJKz6O3dvWZuWT6kAGqzvng4UME3C2+4qenZheWv98srmwhv moKeIiNnnxfCu6h/LGo68BOXWljdmZ8//vb8+por9Zhq8yYssm1CAuLk9 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D0AQAmRJZb/xbLJq1bGgEBAQEBAgEBAQEIAQEBAYJXgkkShBqIco0jCINUjVKFR4FmC4kGOBQBAgEBAgEBAm0ohWKBFh0CXwEMCAEBgx2CAqRHgS4fhE2FDIp8gUE/gRInDIciJYMXglcCiAVDhH2BM40QCY98BheBQIcYhhiISYVPhXWBWSGBVTMaCBsVO4JtkFM+jkkBAQ
X-IronPort-AV: E=Sophos;i="5.53,355,1531785600"; d="scan'208,217";a="6462521"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2018 10:18:57 +0000
Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w8AAIub0005611; Mon, 10 Sep 2018 10:18:57 GMT
From: Robert Wilton <rwilton@cisco.com>
To: 'Alexander Clemm' <alexander.clemm@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <e9fc3dc9-f73e-9279-8042-401b3797a434@cisco.com>
Date: Mon, 10 Sep 2018 11:18:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------DC38323796E2C22D59D40FD8"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Jawuv8gIYAW5uOPSzAS-Y9BdC1o>
Subject: [Netconf] RGW YANG push -18 LC comments [part 2]
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing 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, 10 Sep 2018 10:19:02 -0000
Hi Alex, authors, Here are my remaining comments from my WG LC review of the YANG push draft. Again, I think that these are all minor. 1. Sec 4.3.2, paragraph 2. "resulted in a particular push" => "resulted in a particular update record"? 2. Sec 4.4.1, after Figure 7, "MAY respond" => "may respond". This is just an example from that normative behaviour. 3. Sec 4.4.1, paragraph starting "If a request is rejected ...". Is it really right for this to be "SHOULD" rather than "MAY"? Early text (e.g. 3.2. paragraph 2 uses "may be inserted". Also in section 4.4.2, paragraph after Figure 11. 4. Sec 4.4.1, "Optionally, an "error-severity" of "error" (this MAY but does nothave to be included).", I don't think that the last clause is required (given that it is predicated by Optionally, so suggest deleting the clause in parenthesis. Otherwise it is also inconsistent with the following "error-info" description. If this change, it should also be changed for "error-severity" in Sec 4.4.2. 5. Sec 4.4.1, NETCONF specific text about errors. Should that text really be in this draft? Would it not be nicer to keep all of the NETCONF specifics to a NETCONF protocol draft? Perhaps this is not practical, but the WG is currently experiencing some pain where NETCONF protocol specific normative text is in RFC 7950. Hence, it would be nice to avoid introducing that issue here if possible. This same comment also applies to Sec 4.4.2. 6. Sec 4.4.2, description paragraph. Suggest the following change to match the actual example: "modify the "period" of a subscription." => "modify the "period" and "datastore XPath filter" of a subscription." 7. Sec 4.4.2, first paragraph after figure 11: Possible rewording: Old: The publisher MUST respond explicitly positively or negatively to the request. If the subscription modification is rejected, the subscription is maintained as it was before the modification request. In addition, the publisher MUST send an RPC error response. This RPC error response SHOULD contain hints encapsulated within the yang-data structure "modify-subscription-error-datastore". A subscription MAY be modified multiple times. NEW: The publisher MUST respond to the subscription modification request. If the request is rejected, the existing subscription is left unchanged, and the publisher MUST send an RPC error response, which MAY|SHOULD contain hints encapsulated within the yang-data structure "modify-subscription-error-datastore". A subscription MAY be modified multiple times. 8. Sec 4.4.4, no figure number under the example. 9. Sec 4.4.5, paragraph 1: I think that it would be better if this just referred to YANG library, hence suggest changing the first two paragraphs: OLD: To make subscription requests, the subscriber needs to know the YANG module library available on the publisher. The YANG 1 module library information is sent by a NETCONF server in the NETCONF "hello" message. For YANG 1.1 modules and all modules used with the RESTCONF [RFC8040] protocol, this information is provided by the YANG Library module (ietf-yang-library.yang from [RFC7895]. This YANG library information is important for the receiver to reproduce the set of object definitions used within the publisher. The YANG library includes a module list with the name, revision, enabled features, and applied deviations for each YANG module implemented by the publisher. The receiver is expected to know the YANG library information before starting a subscription. NEW: To make subscription requests, the subscriber needs to know the YANG datastore schemas used by the publisher, which are available via the YANG Library module, ietf-yang-library.yang from [RFC7895]. The receiver is expected to know the YANG library information before starting a subscription. YANG module: 10. Top level description statement, it looks like the copyright has accidentally been indented by 4 chars. Identities: 11. I suggest renaming "no-such-subscription-resynch" to just "no-such-subscription". I would have thought that this error could also be returned to cancel an unknown subscription. 12. "synchronization-size" doesn't sound like an error, perhaps "synchronization-too-big" or "resync-too-big" might be better? Type definitions: 13. Change all instances (create, delete, insert, move, replace) of "data node" to "datastore node". 14. grouping selection-filter-types, anydata datastore-subtree-filter, perhaps add a reference to "RFC 6241: Network Configuration Protocol, Section 6.", mirroring draft-ietf-netconf-nmda-netconf. 15. grouping update-policy-modifiable, container on-change description statement, needs to be indented by 2 spaces. 16. grouping hints, description, indent the second description line by 1 space. 17. rpc resynch-subscription, description statement, last two lines require alignment. Thanks, Rob
- [Netconf] RGW YANG push -18 LC comments [part 2] Robert Wilton
- Re: [Netconf] RGW YANG push -18 LC comments [part… Eric Voit (evoit)
- Re: [Netconf] RGW YANG push -18 LC comments [part… Robert Wilton
- Re: [Netconf] RGW YANG push -18 LC comments [part… Eric Voit (evoit)