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

["Eric Voit (evoit)" <[e-mail]>]

Hi Dhruv,
Hi Kent,

> From: Dhruv Dhody, May 9, 2019 11:28 PM
> 
> 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.

I really am ok with many options here:
 (a)  keep the current text.  
 (b)  use previous versions of the abstract.  
 (c)  replace the word binding with some other text.   

Getting the right words here nailed down hasn't been from lack of effort.  To give you an idea, below are four previous attempts at the abstract.

From -v5

   This document defines how to transport network subscriptions and
   event messages on top of the Network Configuration protocol
   (NETCONF).  This includes the full set of RPCs, subscription state
   changes, and subscribed content needing asynchronous delivery.


From -v6 
 
   This document provides a NETCONF binding for
   [I-D.draft-ietf-netconf-subscribed-notifications].  Included are:

   o  Transport mappings for subscription RPCs, state change
      notifications, and notification messages

   o  Functionality which must be supported with NETCONF

   o  Examples in appendices


From -v7

   This document provides a NETCONF binding for
   [I-D.draft-ietf-netconf-subscribed-notifications] and
   [I-D.ietf-netconf-yang-push].  Included are:

   o  transport mappings for subscription RPCs, state change
      notifications, and notification messages,
   o  functional requirements, and
   o  examples


From -v8

   This document provides a NETCONF binding to subscribed notifications
   and to YANG push.


Honestly I like the v5 version.   But previous reviewers have incrementally driven things to the current text.    If Kent you prefer something other than the current text, let me know what it is.  I am sure I will like it too.

Eric 


> 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
> > > > > >
> > > > > >
> > > > > >