[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