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

[Dhruv Dhody <[e-mail]>]

Hi Eric,

> -----Original Message-----
> From: Eric Voit (evoit) [mailto:[e-mail]]
> Sent: 10 May 2019 02:18
> To: Dhruv Dhody <[e-mail]>
> Cc: Kent Watsen <[e-mail]>; [e-mail]; draft-ietf-
> [e-mail]; [e-mail]; Dhruv
> Dhody <[e-mail]>; <[e-mail]> <[e-mail]>
> 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) <[e-mail]> 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 <[e-mail]>
> > 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
> > > > >
> > > > >
> > > > >