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

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

I made it 'is'.   I posted the version as well.

Eric

> Eric
> 
> Looks good but I do agree with Benjamin about the grammar of
> 
> "And per [RFC5277]'s "eventTime" object definition, the
>    "eventTime" populated with the event occurrence time."
> 
> I cannot make that into a sentence. 'populated' seems to be a past participle
> making ' populated with the event occurrence time' into an adjectival clause and
> the whole lacking a main verb; IMHO it needs a verb before 'populated' such as
> 'is', 'will be', 'MAY be',  ' MUST be'
> etc.  I await with interest the views of the RFC Editor whose word on these
> matters I treat as gospel.
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Eric Voit (evoit)" <[e-mail]>
> Sent: Tuesday, May 14, 2019 3:59 PM
> 
> > Hi Tom,
> >
> > > From: tom petch, May 14, 2019 7:48 AM
> > >
> > > Eric
> > >
> > > A quick browse tells me that in the RFC I regularly refer to,
> 'binding'
> > > is used in over 300 of them but that in all those that I looked at,
> it is always
> > > binding an element of a set to an element of the same or a different
> set, where
> > > the sets are similar in nature.  Thus ARP binds an IP address to a
> MAC address or
> > > a bidirectional MPLS LSP binds one unidirectional LSP to another and
> so one.
> > >
> > > What I do not learn here is what is being bound to what.
> > >
> > > Perhaps
> > >    This document specifies the binding of a stream of events which
> form part of a
> > > dynamic subscription to the NETCONF
> > >    protocol [RFC6241].  Dynamic subscriptions are defined in
> > >    [I-D.draft-ietf-netconf-subscribed-notifications].
> >
> > I am assuming that you are referring to the first sentence of the
> Intro here, as document references are not in abstracts.
> >
> > This text works for me.   Any objections anyone?
> >
> > > The crux is "binding ... to ..." which is currently lacking.
> > >
> > > More generally:-(
> > > I do find this I-D hard to understand.  I think that the key is that
> this I-D, more
> > > than any other I can think of, is so dependent on one of its
> Normative
> > > References, to whit, subscribed notifications; I think that that
> needs calling out
> > > so I would add "This memo assumes that the reader is familiar with
> the
> > > terminology and concepts defined in [subscribed-notifications]"
> >
> > As the last sentence in the Intro section, I have added:
> > "This document assumes that the reader is familiar with the
> terminology and concepts defined in
> [I-D.draft-ietf-netconf-subscribed-notifications]."
> >
> > > Yes, that is what a Normative Reference means but I find this
> example so
> > > extreme that I think it needs calling out.  Each time in the past
> six months I have
> > > turned to this I-D (it is the smallest of the very large set of
> netconf I-Ds:-), I have
> > > given up, eventually working out that first I must master the 80
> pages of
> > > subscribed notifications.  This may not be so obvious to those
> involved at Last
> > > Call time.
> >
> > Understood.  And it is true that understanding
> subscribed-notifications is a prerequisite.
> >
> > Eric
> >
> > > Tom Petch
> > >
> > >
> > > ----- Original Message -----
> > > From: "Eric Voit (evoit)" <[e-mail]>
> > > Sent: Friday, May 10, 2019 7:39 PM
> > >
> > >
> > > > 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
> > > > > > 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > >
> >
> >