[Netconf] Comments on Yang-push-18 //RE: I-D Action: draft-ietf-netconf-yang-push-18.txt
Rohit R Ranade <rohitrranade@huawei.com> Wed, 29 August 2018 05:01 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 CE0CF130E2A for <netconf@ietfa.amsl.com>; Tue, 28 Aug 2018 22:01:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 btW8f0ojpaft for <netconf@ietfa.amsl.com>; Tue, 28 Aug 2018 22:01:18 -0700 (PDT)
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 3000312D949 for <netconf@ietf.org>; Tue, 28 Aug 2018 22:01:18 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6A5899F34D84E for <netconf@ietf.org>; Wed, 29 Aug 2018 06:01:15 +0100 (IST)
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 29 Aug 2018 06:01:16 +0100
Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.129]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0399.000; Wed, 29 Aug 2018 13:01:08 +0800
From: Rohit R Ranade <rohitrranade@huawei.com>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: Comments on Yang-push-18 //RE: [Netconf] I-D Action: draft-ietf-netconf-yang-push-18.txt
Thread-Index: AdQ/VLvBsEuHunkySd2q4Mf8WxSa0A==
Date: Wed, 29 Aug 2018 05:01:07 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BC192DD@dggeml530-mbs.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/uHcyUvZxisT-bDGNDEKkgSXoMdI>
Subject: [Netconf] Comments on Yang-push-18 //RE: I-D Action: draft-ietf-netconf-yang-push-18.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 29 Aug 2018 05:01:21 -0000
Hi All, 1. In Section 3.3 The whole para from "To avoid flooding receivers .. the last change will still be sent." looks like a repetition of Section 3.1 , description of "Dampening period" 2. Section 3.3, Point 4 "insert into the YANG patch record the last change made for any object which otherwise wouldn't have appeared." I am not able to understand this statement clearly. Can this statement be simplified ? 3. Section 3.5.2 The para "A publisher will indicate a change to the effect ... this by a "move" operation." This is already defined in the YANG Patch RFC right ? What is the need to define this again in this RFC ? 4. Section 3.5.2 "To support this, it is valid to encode a YANG patch operation so that its application would result in no change between the previous and current state. This indicates that some churn has occurred on the object. An example of this would be a patch that does a "create" operation for a datastore node where the receiver believes one already exists, or a "replace" operation which replaces a previous value with the same value." Some points here need more clarification. a. If there is no change, but only a churn then why is it important to send this object in a YANG push ? What is the benefit ? b. If there was a "create" and "delete" on object X, within a dampening period, then what will be the patch record operation ? c. s/patch that does a "create" operation /patch that indicates a "create" operation ? Patch can indicate the operation not do it. 5. Section 3.7 "the counter MUST be reset to '1' the after passing a maximum value of '4294967295'" s/reset to '1' the after passing/reset to '1' after passing 6. Section 3.7 Figure 2: Push example for on change The "yang-patch" should be under the namespace "urn:ietf:params:xml:ns:yang:ietf-yang-patch" 7. In the ietf-yang-push, tree diagram " +--ro datastore-changes? +--ro ypatch:yang-patch +--ro patch-id string " There looks to be an indentation problem for "ypatch:yang-patch" 8. resynch-subscription-error I feel "sync" is a better abbreviation than "synch" for synchronization, because when reading this name, we may not pronounce this correctly or read correctly. I also feel "re-sync" is better when compared to "resync" 9. Section 3.9. "since the last notification message was sent to a particular each receiver.". s/sent to a particular each receiver/sent to a particular receiver 10. Section 3.9 "To accomplish this, implementations SHOULD support the conceptual authorization model of [RFC8341], specifically section 3.2.4.". The link to section 3.2.4 seems to be broken as it is taking the reader to the YANG Push draft and not to NACM 11. Section 3.9 I think here "access-protected data", is used to indicate that the receiver has "no access". I think this is misleading. "access-protected data" means that there are NACM rules to protect the data. Maybe we can replace it with "access-denied data" ? 12. Section 3.9 "If read access into previously accessible nodes has been lost due to a receiver permissions change, this SHOULD be reported as a patch "delete" operation for on-change subscriptions." I think we should not have such mechanisms. If a user does not have access, we should not try to evaluate what was the last update sent to such user, and how to send a subsequent patch which will stabilize the user's DB due to the access-control changes. With Regards, Rohit R Ranade -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: 29 August 2018 06:24 To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-push-18.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Datastore Subscription Authors : Alexander Clemm Eric Voit Alberto Gonzalez Prieto Ambika Prasad Tripathy Einar Nilsen-Nygaard Andy Bierman Balazs Lengyel Filename : draft-ietf-netconf-yang-push-18.txt Pages : 57 Date : 2018-08-28 Abstract: Via the mechanism described in this document, subscriber applications may request a continuous, customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-push-18 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-push-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf
- [Netconf] Comments on Yang-push-18 //RE: I-D Acti… Rohit R Ranade
- Re: [Netconf] Comments on Yang-push-18 //RE: I-D … Alexander Clemm
- Re: [Netconf] Comments on Yang-push-18 //RE: I-D … Rohit R Ranade
- Re: [Netconf] Comments on Yang-push-18 //RE: I-D … Rohit R Ranade
- Re: [Netconf] Comments on Yang-push-18 //RE: I-D … Alexander Clemm