Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17

Dhruv Dhody <dhruv.dhody@huawei.com> Fri, 10 May 2019 03:28 UTC

Return-Path: <dhruv.dhody@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 EC525120098; Thu, 9 May 2019 20:28:25 -0700 (PDT)
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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 ndpfxbhldtKR; Thu, 9 May 2019 20:28:24 -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 A8AEF12006E; Thu, 9 May 2019 20:28:23 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B184870B0F97F5C4BB1D; Fri, 10 May 2019 04:28:21 +0100 (IST)
Received: from BLREML703-CAH.china.huawei.com (10.20.4.172) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 10 May 2019 04:28:20 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.86]) by blreml703-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Fri, 10 May 2019 08:58:07 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>, Dhruv Dhody <dhruv.ietf@gmail.com>
CC: Kent Watsen <kent+ietf@watsen.net>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" <draft-ietf-netconf-netconf-event-notifications.all@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
Thread-Topic: RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
Thread-Index: AQHU/xDB/M0APTVwV06CgM5HTxBRkKZUnleAgAHkuICACVqOAIAABZqAgACOyoCAAJ1+AIAAzj2AgAEYzYCAAMiuUA==
Date: Fri, 10 May 2019 03:28:06 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com>
References: <CAB75xn4HiqYqeWu2tiOsfDwU4ePc+-6ym+4EpowqZ-YMgkRRMA@mail.gmail.com> <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com> <CAB75xn4vcHcu3pNBCntWjhw9s6RkgspsfWkQuW4AF3=P8v16cw@mail.gmail.com> <e488c7df0d8049b8aed02b3d240ebe35@XCH-RTP-013.cisco.com> <CAB75xn4it5rABU362p6--wECsc2NVvZqu-4Np1ZhLD72DB_s3Q@mail.gmail.com> <e68ea032d2c04a6383f9291080f33256@XCH-RTP-013.cisco.com>
In-Reply-To: <e68ea032d2c04a6383f9291080f33256@XCH-RTP-013.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.149.39]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/HlmOQp_dPYNEWsWyon2elqpT8NQ>
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
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: Fri, 10 May 2019 03:28:26 -0000

Hi Eric,

> -----Original Message-----
> From: Eric Voit (evoit) [mailto:evoit@cisco.com]
> Sent: 10 May 2019 02:18
> To: Dhruv Dhody <dhruv.ietf@gmail.com>;
> Cc: Kent Watsen <kent+ietf@watsen.net>;; rtg-dir@ietf.org; draft-ietf-
> netconf-netconf-event-notifications.all@ietf.org; netconf@ietf.org; Dhruv
> Dhody <dhruv.dhody@huawei.com>;; <rtg-ads@ietf.org>; <rtg-ads@ietf.org>;
> Subject: RE: RtgDir review: draft-ietf-netconf-netconf-event-
> notifications-17
> 
> Hi Dhruv,
> 
> > From: Dhruv Dhody, May 9, 2019 12:03 AM
> >
> > Hi Eric,
> >
> > Thanks for the update. I see one minor comment that is not handled.
> > Maybe you missed it? Or you disagree, that some more text is required?
> >
> > > Minor Issues:
> > > -------------
> > > (1) Abstract & Introduction, It is not clear what does the 'binding'
> > > mean and who are the parties to this binding? If this is the
> > > document that
> > mentions 'binding'
> > > first, so please add some more clarifying text.
> 
> This is not the first document which mentions 'binding'  first.  The
> document which does this first is draft-ietf-netconf-subscribed-
> notifications.   
[[Dhruv Dhody]] draft-ietf-netconf-subscribed-notifications says this in the Introduction - 

   While the functionality defined in this document is transport-
   agnostic, transports like NETCONF [RFC6241] or RESTCONF [RFC8040] can
   be used to configure or dynamically signal subscriptions, and there
   are bindings defined for subscribed event record delivery for NETCONF
   within [I-D.draft-ietf-netconf-netconf-event-notifications], and for
   RESTCONF within [I-D.draft-ietf-netconf-restconf-notif].

I think this is only time binding is used in this context. 
And now this I-D says - 

   This document provides a binding for events streamed over the NETCONF
   protocol [RFC6241] for dynamic subscriptions as defined in
   [I-D.draft-ietf-netconf-subscribed-notifications].

And you don’t use this term ever again. 

To me this is bit circular and the term binding is used loosely. And thus I flagged it. I will let you and Kent decide the right approach. 

Thanks! 
Dhruv


> In the abstract of this document, that draft is not
> explicitly listed by reference (as I understood we are not supposed to use
> references in abstracts).  But it is listed in the Introduction.
> 
> To make this clearer for you in this document, perhaps "transport binding"
> instead of "binding"?   I really don't have many alternatives I can think
> of which also keeps the text brief.   This particular text has been
> frequently tweaked in the past.
> 
> Thanks.
> Eric
> 
> 
> > Thanks!
> > Dhruv>
> > On Wed, May 8, 2019 at 9:14 PM Eric Voit (evoit) <evoit@cisco.com>; wrote:
> > >
> > > Update posted as -v20.   With the corresponding change to draft-ietf-
> netconf-
> > subscribed-notifications posted as -v25.
> > >
> > > Eric
> > >
> > > > From: Dhruv Dhody, May 8, 2019 2:21 AM
> > > >
> > > > Hi Kent, Eric,
> > > >
> > > > Fine with me!
> > > >
> > > > Thanks!
> > > > Dhruv
> > > >
> > > > On Wed, May 8, 2019 at 3:19 AM Kent Watsen <kent+ietf@watsen.net>;
> > wrote:
> > > > >
> > > > >
> > > > >
> > > > > <eric> Based on my reading of your process suggestions Kent, I
> > > > > like best the
> > > > “mention” approach which you used for RFC-8071, Section 1.4.
> > > > >
> > > > > What I think could be done to cover this is:
> > > > >
> > > > > (A)  Remove Section 11: Notes to the RFC Editor
> > > > >
> > > > > (B)  Per Kent’s desire to also cover
> > > > > draft-ietf-netconf-restconf-notif, place the
> > > > following statement into
> > > > draft-ietf-netconf-subscribed-notifications
> > > > directly after Figure 10
> > > > >
> > > > > [RFC-5277] Section 2.2.1 states that a notification message is
> > > > > to be sent to a
> > > > subscriber which initiated a "create-subscription".   With this
> specification,
> > this
> > > > RFC-5277 statement should be more broadly interpreted to mean that
> > > > notification messages can also be sent to a subscriber which
> > > > initiated an "establish-subscription", or a configured receiver
> > > > which has been sent a “subscription-started”.
> > > > >
> > > > > Does this work for both of you?
> > > > >
> > > > >
> > > > > Works for me.
> > > > >
> > > > >
> > > > >
> > > > > The issue isn't consistency so much as meeting expectations, per
> > > > > `xml2rfc`, the
> > > > document should have something like the following in the
> > > > References section, which then auto-expands to the correct
> > > > reference text, as well as defining the anchor "I-D.ietf-netconf-
> subscribed-notifications":
> > > > >
> > > > >         <?rfc
> > > > > include="reference.I-D.ietf-netconf-subscribed-notifications"?>
> > > > >
> > > > > <Eric> That definitely makes things easier than what I have been
> > > > > doing.  I am
> > > > hitting an xml2rfc error trying this right now, but I will get there.
> > > > >
> > > > >
> > > > > Yes, it was an eye-opener when I figured it out.   Be aware that,
> though
> > some
> > > > external sources (e.g., ITU standards) are supported, many are
> > > > not, and so hand- coding the <reference> is still sometimes
> required...
> > > > >
> > > > >
> > > > > Kent // shepherd
> > > > >
> > > > >
> > > > >