Re: [Netconf] Subscription State Notifications

[Alexander Clemm <[e-mail]>]

OK, we will keep it.  Will doublecheck the description text so that the intended use is very clear to address your concerns.  
Thanks
--- Alex

> -----Original Message-----
> From: Kent Watsen [mailto:[e-mail]]
> Sent: Tuesday, June 12, 2018 2:57 PM
> To: Alexander Clemm <[e-mail]>; Martin Bjorklund
> <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Netconf] Subscription State Notifications
> 
> 
> If you want to keep the extension statement, then can you add a note to its
> description statement that the extension is not to be used outside this module,
> lest otherwise you trigger the client-complexity I mentioned before.  And BTW,
> the issue isn't with the SN-clients, it's with clients that do read the NETCONF
> stream.
> 
> Kent // contributor
> 
> 
> ===== original message =====
> 
> Thanks, Martin.
> 
> Kent, are you okay with this as well?  We are about to post an updated revision
> to incorporate Tom Petch's comments in the coming days; it is our goal for that
> one to have all known issues closed.
> 
> Thanks
> --- Alex
> 
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:[e-mail]]
> > Sent: Thursday, June 07, 2018 6:30 AM
> > To: Alexander Clemm <[e-mail]>
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > Subject: Re: [Netconf] Subscription State Notifications
> >
> > Alexander Clemm <[e-mail]> wrote:
> > > Hi Kent, Martin,
> > >
> > > please let us know if we can keep it as-is (our preference), or if you
> > > insist on removing the extension and going the description text route,
> > > in which case we will post another revision.
> >
> > I'm ok with the extension statement.
> >
> >
> > /martin
> >
> >
> > >
> > > Is there anything else?
> > >
> > > Thanks
> > > --- Alex
> > >
> > > From: Netconf [mailto:[e-mail]] On Behalf Of Alexander
> > > Clemm
> > > Sent: Thursday, May 31, 2018 2:38 PM
> > > To: Kent Watsen <[e-mail]>; Eric Voit (evoit)
> > > <[e-mail]>; Alexander Clemm <[e-mail]>
> > > Cc: [e-mail]
> > > Subject: Re: [Netconf] Subscription State Notifications (RE: LC on
> > > subscribed-notifications-10)
> > >
> > > Hi Kent,
> > >
> > > sure, the wire behavior is clear.
> > >
> > > It just seems to me cleaner and more desirable to me to make the
> > > distinction explicit through formal means, rather than relying on
> > > description text.  Contrary to SMIv2, YANG does provide the ability to
> > > define extensions that allow us to more formally cover this.  Why not
> > > take advantage of it – this is one important way in which YANG IMHO is
> > > better than SMIv2.  I have one more point to your comment inline,
> > > <ALEX2>.
> > >
> > > Now, that said, appreciate trying to simplify it; I am not sure this
> > > changes complexity either way – as you mention, it all results in the
> > > same on-the-wire behavior, the only question is if we want to specify
> > > it informally (description text) or formally (YANG-extension).  In any
> > > event, at this point, I believe it is more important to bring this to
> > > a conclusion that is acceptable to everyone than to one that may be
> > > the “best” (and we all have different opininions on what that would
> > > be).  If this is the last thing that is holding this up, I will be
> > > happy to compromise and spin a new revision without the extension.
> > > Please let us know.
> > >
> > > Thanks
> > > --- Alex
> > >
> > > From: Kent Watsen [mailto:[e-mail]]
> > > Sent: Thursday, May 31, 2018 11:43 AM
> > > To: Alexander Clemm
> > > <[e-mail]<mailto:[e-mail]>>;
> > Eric
> > > Voit (evoit) <[e-mail]<mailto:[e-mail]>>; Alexander
> > > Clemm <[e-mail]<mailto:[e-mail]>>
> > > Cc: [e-mail]<mailto:[e-mail]>
> > > Subject: Re: Subscription State Notifications (RE: [Netconf] LC on
> > > subscribed-notifications-10)
> > >
> > > Hi Alex,
> > >
> > > No one is suggesting there would be an on-the-wire change.  With or
> > > without the extension, the subscription state notifications would
> > > still only by sent in the dynamic/configured subscription sessions.
> > > The only discussion is *how* this understanding is conveyed.  Martin
> > > and I are of the opinion that it can be conveyed by document-text,
> > > without introducing an extension.
> > >
> > > As I see it, it makes no difference to server-implementers, as they're
> > > going to hard-code it one way or another, but I think it does make a
> > > difference to client-implementers, as one approach allows them to
> > > hard-code it while the other approach introduces a need for their
> > > infrastructure to look for and act on the presence of this extension.
> > > Am I misunderstanding anything?
> > >
> > > <ALEX2> Client implementers can hard code it either way.  The presence
> > > of this extension (defined just in this module) makes it more explicit
> > > that there is behavior that needs to be coded (ensuring that the
> > > description text is not simply ignored, which would result in
> > > noncompliant implementations).  If your concern is that “now that the
> > > extension is there, some other module might try to use it as well”,
> > > well, how they choose to model and define their behavior is up to the
> > > fictitious other model, and if they do need the same behavior, I would
> > > consider it all the more reason not to get on the slippery slope of
> > > the description clause path that became one of the demises for SMIv2.
> > > </ALEX2>
> > >
> > > FWIW, my goal is to try to simplify this work where possible, as it is
> > > rather complex as it stands.  This (and configurable
> > > replay-start-time) seems like a low-hanging item that could be removed
> > > with little impact.
> > >
> > > Kent
> > >
> > >
> > > On 5/30/18, 8:41 PM, "Alexander Clemm"
> > > <[e-mail]<mailto:[e-mail]>>
> > wrote:
> > >
> > > Apologies for the late reply.
> > >
> > > IMHO, option (b) (having an extension) is clearly preferable.
> > > Subscription state notifications are in essence a signaling channel.
> > > It makes a lot of sense to clearly distinguish a signaling channel
> > > from general notification/event messages.
> > >
> > > The option to make subscription state notifications a part of the
> > > regular NETCONF stream is not desirable because:
> > > - It opens up the possibility that subscription state notifications are
> > > - shared with _any_ subscriber, not just with the “owning” subscriber”.
> > > - It would require subscribers having to explicitly subscribe for
> > > - subscription state notifications (and allow accidental filtering of
> > > - those notifications), making this harder to a user.
> > >
> > > Option (a) basically involves putting a lot of descriptions into
> > > notifications to override “normal” notification behavior. It will not
> > > be picked up by tooling and IMHO is more likely to result in incorrect
> > > implementations and resulting usability etc issues.  Back in the SMIv2
> > > days this type of thing might have been acceptable, but we moved on to
> > > YANG for a reason.  Option (b) is much cleaner.
> > >
> > > --- Alex
> > >
> > > From: Eric Voit (evoit) [mailto:[e-mail]]
> > > Sent: Thursday, April 26, 2018 5:51 PM
> > > To: Kent Watsen <[e-mail]<mailto:[e-mail]>>;
> > > Alexander Clemm
> > > <[e-mail]<mailto:[e-mail]>>;
> > > Alexander Clemm <[e-mail]<mailto:[e-mail]>>
> > > Cc: [e-mail]<mailto:[e-mail]>
> > > Subject: RE: Subscription State Notifications (RE: [Netconf] LC on
> > > subscribed-notifications-10)
> > >
> > > Does anyone else want to chime in on whether we should:
> > > (a) hard-code filtering rules for specific subscription state
> > > notifications, or
> > > (b) have a “subscription-state-notif” extension
> > >
> > > More people seem to prefer (b) at this point.  I am good if we close
> > > it wither way.
> > >
> > > Eric
> > >
> > > From: Kent Watsen, April 23, 2018 3:19 PM
> > > On 4/18/18, 4:40 PM, "Eric Voit (evoit)"
> > > <[e-mail]<mailto:[e-mail]>> wrote:
> > >
> > > I don’t think anyone has an issue with excluding them from the NETCONF
> > > stream, or just sending them to individual receivers.
> > >
> > > <KENT> correct
> > >
> > > I think Kent’s question is that he is trying to understand the
> > > possible downsides of using this extension construct for this purpose.
> > > And specifically, should we permit reuse of this construct beyond the
> > > confines of the family of subscription drafts (I.e., will in other
> > > YANG models use this extension to exclude items from the NETCONF
> > > stream which they shouldn’t).
> > >
> > > <KENT> correct
> > >
> > > Personally I don’t see a downside in allowing this flexibility under
> > > “subscription-state-notif”.  This notification has a very defined
> > > purpose plus definition in the YANG model.  And whether or not this
> > > extension exists, model makers and implementers can choose exclude
> > > certain notifications.  At least this if this extension is used, it
> > > would make such exclusions quite a bit more visible.
> > >
> > > <KENT> downside is added complexity.  I don't want to add things that
> > > aren't absolutely needed.
> > >
> > > Eric
> > >
> > > From: Alexander Clemm, April 18, 2018 3:08 PM
> > > Hi Kent,
> > >
> > > I am not sure of what your question is anymore.  The earlier
> > > discussion concerned providing explanation regarding why subscription
> > > state notifications are not part of the regular NETCONF stream.  This
> > > was my attempt at additional explanation.  I am not sure what options
> > > we need to discuss at this point.  These issues were closed and IMHO
> > > we should not open them again.
> > >
> > > The option to make them part of the regular NETCONF stream is not
> > > desirable because:
> > > - It would potentially “share” subscription state notifications with any
> > > - subscriber, not just their own.
> > > - It would require subscribers having to explicitly subscribe for
> > > - subscription state notifications, making this harder to user.
> > >
> > > Hope this clarifies
> > > --- Alex
> > >
> > >
> > > From: Kent Watsen [mailto:[e-mail]]
> > > Sent: Tuesday, April 17, 2018 3:05 PM
> > > To: Alexander Clemm
> > > <[e-mail]<mailto:[e-mail]>>;
> > Eric
> > > Voit (evoit) <[e-mail]<mailto:[e-mail]>>; Alexander
> > > Clemm <[e-mail]<mailto:[e-mail]>>;
> > > [e-mail]<mailto:[e-mail]>
> > > Subject: Re: Subscription State Notifications (RE: [Netconf] LC on
> > > subscribed-notifications-10)
> > >
> > > Is this the result of the "I will open up a thread now" comment below?
> > > This reads more like a statement than a question.   Please try again,
> > > this time presenting the pros and cons of the various options.
> > >
> > > Thanks,
> > > Kent  // contributor
> > >
> > >
> > > On 4/10/18, 7:17 PM, "Alexander Clemm"
> > > <[e-mail]<mailto:[e-mail]>>
> > wrote:
> > >
> > > Hi,
> > >
> > > regarding the question of subscription state notifications that is
> > > embedded in the long thread below:
> > >
> > > As discussed earlier, subscription state notifications are different
> > > from “regular” notifications in that they only apply to the target of
> > > a subscription (and should not be subscribable by anyone else).  For
> > > this reason, they are not placed onto the NETCONF stream, where they
> > > would be subscribable by anyone.
> > >
> > > At the same time, they should not require being subscribed to
> > > explicitly, but simply be automatically delivered as part of the
> > > subscription control channel – automatically “included” with the
> > > subscription whose state is being notified.  To denote these specific
> > > semantics, the model contains the “subscription-state-notification”
> > > extension, by which subscription state notifications are tagged.
> > >
> > > HTH
> > > --- Alex
> > >
> > > From: Netconf [mailto:[e-mail]] On Behalf Of Eric Voit
> > > (evoit)
> > > Sent: Monday, April 09, 2018 3:32 PM
> > > To: Kent Watsen <[e-mail]<mailto:[e-mail]>>;
> > > Alexander Clemm <[e-mail]<mailto:[e-mail]>>;
> > > [e-mail]<mailto:[e-mail]>
> > > Subject: Re: [Netconf] LC on subscribed-notifications-10
> > >
> > > Hi Kent,
> > >
> > > Thanks for the feedback.  Look for thoughts at <Eric2> In-line...
> > >
> > > Also everything documented below which made it into the working copy
> > > can be seen at:
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_netconf-2Dwg_rfc5277bis_blob_master_draft-2Dietf-
> 2Dnetconf-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=2
> ZAWwt38BLRzZXn66-
> kWUPEWuw26F0Uqjsvtmi_oRiQ&s=CRujuBUHMKBXxcF9b6pYHZs1ymTsVWVJq
> lGSy_1hxIA&e=
> > subscribed-notifications-
> > 12.txt<https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__github.com_netconf-2Dwg_rfc5277bis_blob_master_draft-2Dietf-
> > 2Dnetconf-2Dsubscribed-2Dnotifications-
> > 2D12.txt&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=8
> > SC9EE43RlHG68Oyp-zOqWCQ3RTjFqQJdzR_OSyqSvs&s=Yi-
> > KexLmb4wsVjjBDcM9ybo2emjF11UUjA1GXfKNedE&e=>
> > >
> > >
> > > From: Kent Watsen, April 6, 2018 11:33 PM
> > > Alex/Eric,
> > >
> > > I apologize for the long delay, but I just got back from PTO.  Please
> > > find my comments below (<KENT>), and know that I'm not up to speed on
> > > conversations you've been having with others, so please just let me
> > > know of the current status of things where applicable.
> > >
> > > Thanks,
> > > Kent  // as a contributor
> > >
> > >
> > > On 3/18/18, 5:53 AM, "Alexander Clemm"
> > > <[e-mail]<mailto:[e-mail]>> wrote:
> > >
> > > Kent, thank you for your thorough review and Eric, thank you for your
> > > thorough responses!
> > >
> > > I agree that most of these are for the most part very small items and
> > > Eric has really answered all of them already.  Just adding some small
> > > points on a few items, look for <ALEX>
> > >
> > > Thanks
> > > --- Alex
> > >
> > > From: Netconf
> > > <[e-mail]<mailto:[e-mail]>> On Behalf
> > > Of Eric Voit (evoit)
> > > Sent: Friday, March 16, 2018 11:41 AM
> > > To: Kent Watsen <[e-mail]<mailto:[e-mail]>>;
> > > [e-mail]<mailto:[e-mail]>
> > > Subject: Re: [Netconf] LC on subscribed-notifications-10
> > >
> > >
> > > Hi Kent,
> > >
> > >
> > >
> > > Thanks so much for the detailed review.  Thoughts in-line.  At this
> > > point there doesn’t seem to be anything insurmountable...
> > >
> > >
> > >
> > > A working copy draft which embeds / covering the points documented
> > > below is at:
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_netconf-2Dwg_rfc5277bis_blob_master_draft-2Dietf-
> 2Dnetconf-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=2
> ZAWwt38BLRzZXn66-
> kWUPEWuw26F0Uqjsvtmi_oRiQ&s=CRujuBUHMKBXxcF9b6pYHZs1ymTsVWVJq
> lGSy_1hxIA&e=
> > subscribed-notifications-
> > 11.txt<https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__github.com_netconf-2Dwg_rfc5277bis_blob_master_draft-2Dietf-
> > 2Dnetconf-2Dsubscribed-2Dnotifications-
> > 2D11.txt&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=
> > DoO-FEinwnsQ1xowtT-
> >
> 9KNCYTYuzNrC979exYSodTS0&s=63Abs5RCtg85f0BkF6fUWZe7vLlQ2su2BKhdV
> > vzHdN0&e=>
> > >
> > >
> > >
> > > Also a legend for the comments below:
> > >
> > >
> > >
> > > **** indicates a significant item (others might want to read/chime in).
> > >
> > > Blue indicates text which is now in the draft (verbatim).
> > >
> > > Orange indicates an open question, where I am asking for feedback
> > > before making changes.
> > >
> > > Note: where I use colors, the wording should still be fine for those
> > > WG members using plain text email clients.
> > >
> > >
> > >
> > > Still pending:
> > >
> > > - Martin’s comments
> > >
> > > - YANG doctor comments
> > >
> > >
> > >
> > > > Kent Watsen, March 14, 2018 9:52 PM
> > >
> > > >
> > >
> > > > Here's my review of this draft.
> > >
> > > >
> > >
> > > > I'm aware that there may be some overlap with recent messages from Rob
> > > > and
> > >
> > > > Martin.  Please respond to them anyways, if only to explain the
> > > > resolution
> > >
> > > > made.
> > >
> > > >
> > >
> > > > BTW, when I make an open-ended question, what I'm many times looking
> > > > for
> > >
> > > > is draft-text that answers the question.  Yes, I want to know the
> > > > answer but,
> > >
> > > > more importantly, I want the answer recorded in the draft.
> > >
> > > >
> > >
> > > > PS: I'm prioritizing reviewing all three drafts over trying to reply
> > > > to responses
> > >
> > > > from earlier reviews.
> > >
> > > >
> > >
> > > > Thanks,
> > >
> > > > Kent // contributor (but revving-up for shepherd write-up)
> > >
> > > >
> > >
> > > >
> > >
> > > > <chair-hat> Authors, can you please start planning a presentation to
> > > > review any
> > >
> > > > of the larger open issues during the meeting in London? </chair-hat>
> > >
> > >
> > >
> > > Will do
> > >
> > >
> > >
> > > > Title: the word "custom" is throwing me, what does it mean?  I see the
> > > > word in
> > >
> > > > the Abstract and similar text in the Introduction.  In total, the
> > > > substring
> > >
> > > > "custom" appears six times in the draft, all in the Title, Abstract,
> > > > and
> > >
> > > > Introduction, so the word doesn't seem to carry much weight in the
> > > > body of
> > >
> > > > the draft itself.  Is there a better word?  Perhaps
> > > > "Subscriber-specific" or
> > >
> > > > "Receiver-specific"?  Or maybe you want to say "Customized
> > > > Subscriptions to a
> > >
> > > > Publisher's Event Streams"?
> > >
> > >
> > >
> > > Both paths work.  I switched it to:
> > >
> > > Customized Subscriptions to a Publisher's Event Streams
> > >
> > > <KENT> fine
> > >
> > >
> > >
> > > > Abstract: The first sentence has three issues: first, there's the
> > >
> > > > custom/subscriber-specific comment from before; second, the word
> > >
> > > > "capabilities" in the first sentence is unclear (if you mean
> > > > NETCONF/yang-
> > >
> > > > library capabilities, this document does not define any); and third,
> > > > the word
> > >
> > > > "operations" is ambiguous, the draft uses this word sometimes to mean
> > > > RPCs,
> > >
> > > > but other times not.  Putting it all together, maybe this is better?
> > >
> > > >
> > >
> > > >    This document defines mechanisms enabling subscriber-specific
> > >
> > > >    subscriptions to a publisher's event streams.
> > >
> > >
> > >
> > > Based on Robert's comments on add the YANG Data model, I morphed your
> > > proposal to:
> > >
> > >
> > >
> > > This document defines mechanisms and a YANG Data Model enabling
> > > subscriber-specific subscriptions to a publisher's event streams.
> > >
> > > <KENT> first, "data model" shouldn't be capitalized here.  That said,
> > > I question if "YANG data model" is needed at all, since "mechanisms"
> > > is even more general, and saying both seems like a mouthful.  Perhaps
> > > the two could be turned around. something like "This document defines
> > > a YANG data model and associated mechanisms enabling…"?
> > >
> > >
> > >
> > > <Eric2>  Your text is adopted.
> > >
> > >
> > >
> > > > Also, in the last sentence, s/Effectively/Combined/ and
> > > > s/request/request for/?
> > >
> > >
> > >
> > > Tweaked
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > > Introduction: Similar issues with the first sentence as with the
> > > > Abstract.  Also,
> > >
> > > > missing is a statement regarding this draft's compatibility to NMDA
> > > > (see
> > >
> > > > rfc6087bis)
> > >
> > >
> > >
> > > Replicated the first sentence of the abstract to the introduction.
> > > Also added a final sentence to the Intro which says:
> > >
> > >
> > >
> > > The YANG model in this document conforms to the Network Management
> > > Datastore Architecture defined in
> > > [I-D.ietf-netmod-revised-datastores].
> > >
> > > <KENT> thx, but be sure to also replicate any change to the Abstract
> > > from above to the Introduction again…
> > >
> > >
> > >
> > > <Eric2>  Your text is adopted.
> > >
> > >
> > >
> > >
> > >
> > > > Motivation:
> > >
> > > >
> > >
> > > >   How about this?
> > >
> > > >   OLD: There are various [RFC5277] limitations, many of which have been
> > >
> > > >        exposed in [RFC7923] which needed to be solved.
> > >
> > > >   NEW: Various limitations in [RFC5277] are discussed in [RFC7923].
> > >
> > > >        Resolving these issues is the primary motivation for this work.
> > >
> > >
> > >
> > > updated
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   s/document includes/document include/
> > >
> > >
> > >
> > > updated
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   in the 2nd bullet, remove "statically"?  the word "static" hardly
> > > >   appears...
> > >
> > >
> > >
> > > updated
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   in the 3rd bullet point: would appending "in progress" be okay?
> > >
> > >
> > >
> > > updated
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > > Terminology: I think you want to use this one:
> > >
> > > >
> > >
> > > >       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> > >
> > > >       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
> > >
> > > > RECOMMENDED",
> > >
> > > >       "MAY", and "OPTIONAL" in this document are to be interpreted as
> > >
> > > >       described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
> > >
> > > >       appear in all capitals, as shown here.
> > >
> > >
> > >
> > > Updated
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   For the "Configured subscription" term, I think that replacing "a
> > >
> > > >   configuration interface which" with "configuration that" is clearer.
> > >
> > > >   If necessary, we could import the term "configuration" from the
> > >
> > > >   revised-datastores draft.
> > >
> > >
> > >
> > > I have added the following:
> > >
> > >
> > >
> > > Configuration: defined in [I-D.draft-ietf-netmod-revised-datastores]
> > >
> > > Configuration datastore: defined in
> > > [I-D.draft-ietf-netmod-revised-datastores]
> > >
> > > Configured subscription: A subscription installed via configuration
> > > into a configuration datastore.
> > >
> > >
> > >
> > > This addresses the reboot persistence subsystem question (which came
> > > up in Robert's review) by more tightly coupling the terms to the
> > > revised datastore work.  Let me know if there are still concerns.
> > >
> > > <KENT> works for me
> > >
> > >
> > >
> > >
> > >
> > > >   For the "Event" term, remove the parenthesis and spell out "e.g."?
> > >
> > >
> > >
> > > How about:
> > >
> > >
> > >
> > > Event: An occurrence of something that may be of interest. Examples
> > > include, a configuration change, a fault, a change in status, crossing
> > > a threshold, or an external input to the system.
> > >
> > > <KENT> better, but I don't think the first comma is needed…
> > >
> > >
> > >
> > > <Eric2> Comma removed.
> > >
> > >
> > >
> > > >   Remove the term "NACM", since it only appears in the Security
> > >
> > > >   Considerations section.
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   For the "Notification message" term, is the beginning important?
> > >
> > > >   Maybe s/A set of transport encapsulated information/Information/?
> > >
> > >
> > >
> > > Done.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   For the "Publisher" term, why is "Subscription" capitalized?  Is it
> > >
> > > >   (and all other terms) capitalized consistently throughout the draft?
> > >
> > >
> > >
> > > Very early iterations of these drafts had all terminology capitalized.
> > > Earlier reviews resulted in downshifting the terms because it hindered
> > > readability.  The large "S" is likely something left over which got
> > > missed.  It is now a lower case 's'.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   For the "Stream" term, I'm wondering if this should be renamed "Event
> > >
> > > >   stream" (matching what's in the title), and then search/replace
> > > >   instances
> > >
> > > >   of just "stream" with "event stream" everywhere else in the document.
> > >
> > > >   This seems better, less ambiguous.
> > >
> > >
> > >
> > > ****
> > >
> > > We went back and forth on this.  The term is used so often that always
> > > saying "event stream" just made the document more cumbersome to read.
> > > In the end, RFC-5277 used both in the terminology, in a similar way.
> > > For example:
> > >
> > >
> > >
> > > In RFC 5277: "stream" appears 104 times, and "event stream" 47 times.
> > >
> > > In this doc: "stream appears 297 times, and "event stream"  39 times.
> > >
> > >
> > >
> > > As using both terms made things more humanly readable, and it seemed
> > > ok for RFC-5277, we choose that path.  Let me know if *not* adding
> > > event before every use of the word stream is ok with you.
> > >
> > >
> > >
> > > <ALEX> Yes, we had multiple discussions on this.  “Stream” certainly
> > > seems more general.  If anything, we could discuss replacing some
> > > instances of “event stream” with “stream”, but I think in general from
> > > the context it is clear what was meant.  I don’t feel strongly either
> > > way.  </ALEX>
> > >
> > >
> > >
> > >  <KENT> when it comes to terms in technical documentation, I have found
> > >  that being annoyingly long-winded and yet completely unambiguous is a
> > >  win.  I would personally do it, but I'm okay with getting others
> > >  opinions and going with the WG consensus.
> > >
> > >
> > >
> > > <Eric2> To make thing unambiguous, and to progress towards closure, I
> > > converted to “event stream”.  You can see the results in:
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_netconf-2Dwg_rfc5277bis_blob_master_draft-2Dietf-
> 2Dnetconf-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=2
> ZAWwt38BLRzZXn66-
> kWUPEWuw26F0Uqjsvtmi_oRiQ&s=CRujuBUHMKBXxcF9b6pYHZs1ymTsVWVJq
> lGSy_1hxIA&e=
> > subscribed-notifications-
> > 12.txt<https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__github.com_netconf-2Dwg_rfc5277bis_blob_master_draft-2Dietf-
> > 2Dnetconf-2Dsubscribed-2Dnotifications-
> > 2D12.txt&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=8
> > SC9EE43RlHG68Oyp-zOqWCQ3RTjFqQJdzR_OSyqSvs&s=Yi-
> > KexLmb4wsVjjBDcM9ybo2emjF11UUjA1GXfKNedE&e=>
> > >
> > >
> > >
> > >
> > >
> > > >   For the "Subscribed event records" term, I recommend removing it, as
> > >
> > > >   it only appears three times in the draft and, besides, you already
> > > >   have
> > >
> > > >   the "Event record" term.
> > >
> > >
> > >
> > > Done.  (Re-reading, I don't think anything is lost by removing the
> > > term either.)
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   For the "Subscriber" term, shouldn't you have a 2nd sentence like in
> > >
> > > >   the "Receiver" term?
> > >
> > >
> > >
> > > Added the same sentence to the receiver term.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   Since the tree diagrams are scattered throughout the document, it
> > > >   would
> > >
> > > >   be good to add the following here:
> > >
> > > >
> > >
> > > >      Tree diagrams used in this document follow the notation defined in
> > >
> > > >      [I-D.ietf-netmod-yang-tree-diagrams].
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >
> > >
> > > > Solution Overview
> > >
> > > >
> > >
> > > >   what does "instantiated" mean in the 1st paragraph.  suggest removing
> > >
> > > >   if not needed.
> > >
> > >
> > >
> > > It just meant "which exists".  Removed.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   in (1), s/RPC/an RPC/.  Also, is "wants" the right word, maybe "is
> > > >   able"?
> > >
> > >
> > >
> > > Made: "is able"
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   same with "wish" in the next sentence.
> > >
> > >
> > >
> > > Made "is not able"
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >  Also, in the last sentence,
> > >
> > > >   s/ which would have been accepted/ that, had they been present, would
> > >
> > > >   have enabled the dynamic subscription request to be accepted/?
> > >
> > >
> > >
> > > Updated
> > >
> > > <KENT> thanks
> > >
> > >
> > >
> > > >   in (2), s/a configuration interface/configuration/.
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >  Also, replace "this
> > >
> > > >   capability" with "configured subscriptions", and maybe append "based
> > > >   on
> > >
> > > >   the use of a YANG feature"?
> > >
> > >
> > >
> > > Made it:
> > >
> > > Support for configured subscriptions is optional, with its
> > > availability advertised via a YANG feature.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   "For connection-oriented stateful transport" : s/For/For a/ or
> > >
> > > >   s/transport/transports/?
> > >
> > >
> > >
> > > Chose: transports
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   Looking at "Also note that transport specific transport drafts based
> > >
> > > >   on this specification MUST detail the life cycles of both dynamic and
> > >
> > > >   configured subscriptions." - do the netconf-event-notifications and
> > >
> > > >   restconf-event-notifications drafts do this?
> > >
> > >
> > >
> > > Yes.  It is in non-normative text, but the flow diagrams in both
> > > drafts' appendices do this.
> > >
> > > <KENT> okay
> > >
> > >
> > >
> > > >   Last paragraph, s/The publisher/A publisher/
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > > Relationship to RFC-5277:
> > >
> > > >
> > >
> > > >   In the first bullet point, the "data model" for what, configuration
> > >
> > > >   or a notification?   (same issue is in the last bullet point as well)
> > >
> > >
> > >
> > > As there is no configuration of RFC-5277 subscriptions, it was for the
> > > notifications.  So I made the bullet:
> > >
> > >
> > >
> > > the data model in this document replaces the Notification Management
> > > Schema of [RFC5277], Section 3.4.
> > >
> > > <KENT> how about this instead?  "the data model in this document
> > > replaces the notification management schema described in Section 3.4
> > > of [RFC5277]."
> > >
> > >
> > >
> > > <Eric> Further tweaking of the wording happened with Martin.
> > > Including your suggestion above, it now says:
> > >
> > >
> > >
> > > “the data model in this document is used instead of the data model in
> > > Section 3.4 of [RFC5277] for the new operations.”
> > >
> > >
> > >
> > > And I made the last bullet:
> > >
> > >
> > >
> > > a publisher MAY implement both the Notification Management Schema and
> > > RPCs defined in [RFC5277] and this new document concurrently,...
> > >
> > > <KENT> hmmm, is there an easier way to say this?  perhaps: " a
> > > publisher MAY implement both [RFC5277] and this new document
> > > concurrently,…"
> > >
> > >
> > >
> > > <Eric> As RFC5277’s notification capability is still always used, some
> > > modifier is needed to show what actually can and cannot be used
> > > together between the drafts.  Not sure how to simplify more.
> > >
> > >
> > >
> > >
> > >
> > > >   The 4th bullet point isn't true (see Event Streams below)
> > >
> > >
> > >
> > > ****
> > >
> > > I believe that it is true.   See discussion below.
> > >
> > > <KENT> okay, I'll wait for the discussion below…
> > >
> > >
> > >
> > >
> > >
> > > > Solution:
> > >
> > > >
> > >
> > > >   Can you add a paragraph here to introduce what all is in Section 2,
> > >
> > > >   how it's organized, or whatever might be helpful?
> > >
> > >
> > >
> > > <KENT> no response to this comment?
> > >
> > >
> > >
> > > <Eric2> I should have pointed out that comments very early in the
> > > review cycle had me pull the introduction of Section 2 just above into
> > > Section 1.3 “Solution Overview”.  So placing details here initially
> > > seemed redundant.
> > >
> > >
> > >
> > > So to cover your request, I just added to the beginning of Section 2:
> > > “Per the overview provided in Section 1.3, this section details the
> > > overall context, state machines, and subsystems which may be assembled
> > > to allow the subscription of events from a publisher.”
> > >
> > >
> > >
> > > > Event Streams:
> > >
> > > >
> > >
> > > >   The 2nd paragraph says "except for where it has been explicitly
> > >
> > > >   indicated that this the event record MUST be excluded from the
> > >
> > > >   NETCONF stream".  This is a redefinition of what RFC5277 says,
> > >
> > > >   has this been discussed?  How is this done (syntax/text)?  Has
> > >
> > > >   it been done already?
> > >
> > >
> > >
> > > ****
> > >
> > >
> > >
> > > <ALEX> I believe it is true by virtue of the fact that we are not
> > > defining the NETCONF stream anywhere in this document.  You can refer
> > > to the NETCONF stream by name.  The NETCONF stream simply refers to
> > > the stream defined in RFC 5277.
> > >
> > >
> > >
> > > Note that in an earlier revision we were using identityrefs and
> > > identities to refer to stream.  At that point, we were defining a
> > > NETCONF stream as part of the datamodel here (even then, referring to
> > > the definition of RFC 5277).  However, the WG decided to take it out
> > > and have a reference by string.  We were also defining other streams
> > > at that point, but again the WG decided to remove the definition of
> > > streams as part of the model, leaving it to implementations to
> > > introduce arbitrary streams.  (As a side note, I would not be
> > > surprised if at some point in the future there will be an attempt to
> > > standardize the definition of new streams).
> > >
> > > </ALEX>
> > >
> > >
> > >
> > > Subscription state change notifications as per Section 2.7 are
> > > explicitly excluded from anyone but the target receiver.  Since the
> > > notifications are per-receiver, they cannot be placed into any NETCONF
> > > stream (for either RFC-5277 or subscribed-notifications).  And as they
> > > are excluded from the NETCONF stream, I do not see an issue with the
> > > Bullet 4 comment above.
> > >
> > >
> > >
> > > To make this clearer in the draft text, here is some proposed/tweaked
> > > text for the start of Section 2.7...
> > >
> > >
> > >
> > > Subscription state notifications are unlike other notifications in
> > > that they are never included in any stream.  Instead, they are
> > > inserted (as defined in the section below) within the sequence of
> > > notification messages sent to a particular receiver.  Subscription
> > > state notifications cannot be filtered out...
> > >
> > >
> > >
> > > <KENT> this is better for s2.7, but my concern is here in 2.1.
> > > perhaps instead of " except for where it has been explicitly indicated
> > > that this the event record MUST be excluded from the NETCONF stream",
> > > you mean "except for the subscription state notifications described in
> > > Section 2.7."???
> > >
> > >
> > >
> > > <Eric2> Made this change.  Text now says:
> > >
> > >
> > >
> > > There is only one reserved event stream name within this document:
> > > "NETCONF".  The "NETCONF" event stream contains all NETCONF XML event
> > > record information supported by the publisher, except for the
> > > subscription state notifications described in Section 2.7.  Among
> > > these included NETCONF XML event records are individual YANG 1.1
> > > notifications described in section 7.16 of [RFC7950].  Each of these
> > > YANG 1.1 notifications will be treated as a distinct event record.
> > >
> > >
> > >
> > >
> > >
> > > >   s/treated a distinct/treated as a distinct/
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > > Event Stream Filters
> > >
> > > >
> > >
> > > >   The 1st and 2nd sentences seems to be at odds with each other.
> > >
> > >
> > >
> > > ****
> > >
> > > I don't believe they are at odds.  But I can tweak the wording.  How
> > > about making the second sentence:
> > >
> > >
> > >
> > > A match on a filter always results in an action upon a complete event
> > > record. Information is never stripped from within an event record
> > > prior to that event record being encapsulated within a notification
> > > message.
> > >
> > > <KENT> I like it
> > >
> > >
> > >
> > > > QoS
> > >
> > > >
> > >
> > > >   What does " MUST work identically" mean?
> > >
> > > >   is HTTP a mandatory  transport?
> > >
> > > >   RFC 7540 Section 5.3.3 talks about a PRIORITY frame,
> > >
> > > >   which is  defined in Section 6.3 of that draft.  How is this
> > >
> > > >   suppose to work in a transport-agnostic way?
> > >
> > >
> > >
> > > ****
> > >
> > > It would be excellent if we can adopt the a subset of prioritization
> > > types in HTTP2 without having to redefine the details of the algorithm
> > > in this document.  I believe this is possible, but I understand that
> > > you want refined wording to make sure this is accomplished explicitly.
> > > Proposed are two snippets of revised text which hopefully accomplishes
> > > this:
> > >
> > >
> > >
> > > Snippet 1:
> > >
> > > Dequeuing of notification messages across independent subscriptions to
> > > a receiver SHOULD be allocated bandwidth proportionally based on each
> > > subscription's weight.  For more information on the proper treatment,
> > > see stream dependency weighting within RFC 7540, section 5.3.2.
> > >
> > > <KENT> fine
> > >
> > >
> > >
> > > Snippet 2
> > >
> > > If a subscription has a dependency, then any buffered notification
> > > messages containing event records selected by the parent subscription
> > > SHOULD be dequeued prior to the notification messages of the dependent
> > > subscription.  If notification messages have dependencies on each
> > > other, the older notification message MUST go first.  For more
> > > information on the proper treatment to stream dependency as described
> > > within [RFC7540], section 5.3.1.  If a dependency included within an
> > > RPC references a subscription which does not exist or is not visible
> > > to that subscriber, that dependency may be silently removed.
> > >
> > > <KENT> also fine
> > >
> > >
> > >
> > > Also HTTP is not mandatory.  In fact with the text change, the
> > > reference to RFC-7950 now becomes informative rather than normative.
> > >
> > > <KENT> good
> > >
> > >
> > >
> > > > Dynamic Subscriptions
> > >
> > > >
> > >
> > > >   s/RPC/RPCs/
> > >
> > >
> > >
> > > ok
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Please provide more detail about how extensibility is accomplished,
> > >
> > > >   or an example showing the augmentation occurring.
> > >
> > >
> > >
> > > ****
> > >
> > > Rather than talk about how augmentation might be done in theory, it
> > > should be cleaner to the reference to YANG-Push augmentations.  So I
> > > added the following sentence...
> > >
> > >
> > >
> > > For examples of such augmentations, see the RPC augmentations within
> > > [I-D.ietf-netconf-yang-push]'s YANG model.
> > >
> > > <KENT> I generally shy away from upward refs, but yang-push is an
> > > informative ref, so I'll blink on this one.
> > >
> > >
> > >
> > >
> > >
> > > >   For all the subsections, should the title be s/Subscription/Dynamic
> > >
> > > > Subscription/?
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > > Dynamic Subscription State Model
> > >
> > > >
> > >
> > > >   What does "asserted" mean?  - remove/replace?
> > >
> > >
> > >
> > > Removed
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   I'm confused by the diagram and subtitle's use of the word "receiver",
> > >
> > > >   when the first sentence of the paragraph above says that the SM is for
> > >
> > > >   the publisher...
> > >
> > >
> > >
> > > This is for the Publisher: the publisher must maintain the state of
> > > whether a receiver is currently active or suspended.
> > >
> > >
> > >
> > > I changed the title to: "Publisher's state for a dynamic subscription"
> > > which should help here.  Other reviewers requested the addition of the
> > > word receiver to the states themselves.  This is so people could make
> > > a 1:1 correlation with the states of the configured subscription state
> > > machine.
> > >
> > >
> > >
> > > <KENT>title is better, though maybe "Publisher's state for a
> > > receiver's dynamic subscription" would be better?  (not sure)
> > >
> > >
> > >
> > > <Eric2> I kind of like the simplicity of the current text.  Will
> > > change if you have a very strong preference.
> > >
> > >
> > >
> > >
> > >
> > > >   Only two notifications?
> > >
> > >
> > >
> > > Only two notifications indicate a change in the state of the
> > > subscription.
> > >
> > > <KENT> okay, but then can you add somewhere that only two
> > > notifications are represented because they're the only ones indicating
> > > a change in the state of the subscription?
> > >
> > >
> > >
> > > <Eric2> Text now says:
> > >
> > >
> > >
> > > The two state change notifications "subscription-suspended" and
> > > "subscription-resumed" are shown.  These are under the control of a
> > > publisher. These are the only two state change notifications which
> > > indicate a change in state of a dynamic subscription.
> > >
> > >
> > >
> > >
> > >
> > > >   Looking at the graphic, how is the reader to
> > >
> > > >   distinguish these as notifications?
> > >
> > >
> > >
> > > Added a * to the two notifications, and text at the bottom of the
> > > drawing which says:
> > >
> > >
> > >
> > > * indicates a state-change-notification
> > >
> > >
> > >
> > > <KENT> better, but somehow not satisfying… Mentally removing these two
> > > notifications from the diagram entirely, I notice that there is no
> > > other arrow going from ACTIVE to SUSPENDED; it seems like you might
> > > need one, perhaps labeled something like "<internal state event>"?
> > > Assuming this is done, could we then remove listing these
> > > notifications from the diagram?
> > >
> > >
> > >
> > > <Eric2> My reading of your comment is that you don’t like the
> > > identification of the “suspend subscription” transition cause via the
> > > “subscription-suspended*” notification.  To clarify, I have removed
> > > all state change notifications from the diagram, and described them in
> > > the text below...
> > >
> > >
> > >                         .........
> > >                         : start :
> > >                         :.......:
> > >                             |
> > >                    establish-subscription
> > >                             |
> > >                             |   .------modify-subscription-------.
> > >                             v   v                                |
> > >                       .-----------.                        .-----------.
> > >            .--------. | receiver  |--suspend-subscription->| receiver  |
> > >        modify-       '|  ACTIVE   |                        | SUSPENDED |
> > >        subscription   |           |<--resume-subscription--|           |
> > >            ---------->'-----------'                        '-----------'
> > >                             |                                    |
> > >                  delete/kill-subscription                   delete/kill-
> > >                             |                               subscription
> > >                             v                                    |
> > >                         .........                                |
> > >                         :  end  :<-------------------------------'
> > >                         :.......:
> > >
> > >           Figure 1: Publisher's state for a dynamic subscription
> > >
> > > Of interest in this state machine are the following:
> > > ...(snip)...
> > >
> > >    o A publisher may choose to suspend a subscription, this is notified
> > >    to a subscriber with a "subscription-suspended" state change
> > >    notification.
> > >
> > >    o A resume subscription state change is notified to a subscriber
> > >    "subscription-resumed". There are no direct external controls over
> > >    resuming a subscription other than for a subscriber to attempt the
> > >    modification of a subscription in a way which reduces the resources
> > >    consumed.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > <KENT> Separately, can you left indent "modify-subscription" a column
> > > or two? - it's difficult to read when up against the "receiver ACTIVE"
> > > box…
> > >
> > >
> > >
> > > <Eric2> Done, above
> > >
> > >
> > >
> > > >   The last sentence of the last bullet doesn't square with what's in the
> > >
> > > >   graphic.  is "modify-subscription" suppose to be bidirectional?
> > >
> > >
> > >
> > > The diagram is correct.    I have changed the sentence to:
> > >
> > >
> > >
> > > There are no direct controls over resuming a subscription other than
> > > to attempt a modification of a subscription in a way which reduces the
> > > resources consumed.
> > >
> > > <KENT> okay
> > >
> > >
> > >
> > >
> > >
> > > > Establishing a Subscription
> > >
> > > >
> > >
> > > >   I take it that the last two sentences of the first paragraph are
> > >
> > > >   intended as requirements for transport-bindings.  Is that correct?
> > >
> > >
> > >
> > > Yes
> > >
> > >
> > >
> > > >   If so, then please say so.
> > >
> > >
> > >
> > > Morphed to:
> > >
> > >
> > >
> > > The transport selected by the subscriber to reach the publisher MUST
> > > support multiple establish subscription RPC requests made within the
> > > same transport session.  In addition, the transport MUST support the
> > > pipelining of RPC requests made on independent subscriptions.
> > >
> > > (As interleave seems to have NETCONF implications, am trying to move
> > > ay from that to pipelining which is a general computer science term.)
> > >
> > > <KENT> good
> > >
> > >
> > >
> > >
> > >
> > > >   The tree diagram is not identified as a tree diagram.  Nowhere in this
> > >
> > > >   document is the tree-diagrams draft referenced.  This needs to be
> > > >   fixed.
> > >
> > >
> > >
> > > Tree diagram reference added to the definitions section.  And also
> > > added as part of each figure name.  And each tree diagram also has
> > > text and a hyperlink near it pointing to the YANG model for more
> > > details.
> > >
> > > <KENT> better
> > >
> > >
> > >
> > >
> > >
> > > >   Are your tree diagrams dynamically-generated?  - is there any concern
> > >
> > > >   that they are out-of-date?
> > >
> > >
> > >
> > > Generated from Pyang.  Manually snipped from the output.  Concerns are
> > > discussed more below.  Next drafts I am certainly changing my
> > > integration environment.
> > >
> > > <KENT> the question more regards if they've been generated (via pyang
> > > or whatever) recently…
> > >
> > >
> > >
> > > <Eric2> With the tool Martin pointed me to for automatically
> > > generating to a fixed column width, life is much easier now.
> > >
> > >
> > >
> > > >   Since you're not describing the contents of the data model here, the
> > >
> > > >   text should say that a complete description of all the nodes is
> > > >   provided
> > >
> > > >   in the YANG module, with a reference.
> > >
> > >
> > >
> > > Every tree in the document now has something like:
> > >
> > >
> > >
> > > Below is a tree diagram for "establish-subscription". All objects
> > > contained in this tree are described within the included YANG model
> > > within <xref target="data_model"/>.
> > >
> > > <KENT> good.
> > >
> > >
> > >
> > >
> > >
> > > >   why is this "establish-subscription-error-stream" yang-data name
> > > >   having
> > >
> > > >   "-stream" at the end?  (same issue with the other yang-data).  It's
> > >
> > > >   a rather confusing name.  Maybe "-info" would be better?
> > >
> > >
> > >
> > > ****
> > >
> > > We have to have a different yang-data structures for hints provided on
> > > datastores and on streams.  Because of that -info is not sufficient.
> > > And while it is possible to place stream and datastore at the
> > > beginning of the yang-data name, it is kind-of nice to have the
> > > error-info hints start off with the same characters.
> > >
> > >
> > >
> > > That said, I have no problem if people want to rename the yang-data
> > > both here and in yang-push to:
> > >
> > >
> > >
> > > stream-establish-subscription-error-info
> > >
> > > and
> > >
> > > datastore-establish-subscription-error-info
> > >
> > >
> > >
> > > Is this what you prefer?
> > >
> > >
> > >
> > > <ALEX> I think this can be renamed.  Really, these are hints, not
> > > streams.  Maybe call this “establish-event-subscription-info” and
> > > “establish-datastore-subscription-info”?
> > >
> > > </ALEX>
> > >
> > > <KENT> I recall this being discussed in London.  What's the current
> > > thinking on this?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >   Also, just so I'm clear, each transport-binding needs to indicate if
> > > >   and
> > >
> > > >   how the yang-data structs are returned, right?  Where is this done in
> > >
> > > >   the netconf-notif and restconf-notif drafts?
> > >
> > >
> > >
> > > Yes
> > >
> > > <KENT> what about the second question?
> > >
> > >
> > >
> > > <Eric2> In the netconf-notif draft, it is in Section 8.  The text
> > > including this is not yet published in Restconf-notif.
> > >
> > >
> > >
> > > > Replay Subscription
> > >
> > > >
> > >
> > > >   Should the title being "Replaying Subscriptions", to match the verb
> > >
> > > >   tense of the other subsections?
> > >
> > >
> > >
> > > Tweaked to "Requesting a replay of event records".  Because this is
> > > not a new RPC, I figure such differentiation from the other
> > > subsections is helpful.
> > >
> > > <KENT> fine
> > >
> > >
> > >
> > >
> > >
> > > >   s/Replay puts no/Supporting replay puts no/ or /The document puts no/?
> > >
> > >
> > >
> > > Chose the " The document puts no "
> > >
> > > <KENT> the current sentence doesn't read right, it looks like you
> > > accidentally dropped the word "restrictions"…
> > >
> > >
> > >
> > > <Eric2> Yes, I dropped it.  Re-added.
> > >
> > >
> > >
> > >
> > >
> > > >   Current text says:
> > >
> > > >     """
> > >
> > > >     The inclusion of a replay-start-time within an "establish-
> > >
> > > >     subscription" RPC indicates a replay request.  If the "replay-start-
> > >
> > > >     time" contains a value that is earlier than content stored within the
> > >
> > > >     publisher's replay buffer, then the subscription MUST be rejected,
> > >
> > > >     and the leaf "replay-start-time-hint" MUST be set in the reply.
> > >
> > > >     """
> > >
> > > >   Why not just start with what you have, prepended by a special "event
> > >
> > > >   record" that says there is a gap?
> > >
> > >
> > >
> > > ****
> > >
> > > This discussion went around on the alias a few times.  E.g., the
> > > thread from mid-October titled " Martin's thoughts on
> > > subscribed-notifications"
> > >
> > >
> > >
> > > An underlying design goal of subscribed-notifications and yang-push is
> > > to deliver no less than what subscriber explicitly requested.
> > > Especially when YANG-Push is layered in, if we start delivering less
> > > for some combination of parameters, we have no certainty that the
> > > subscriber is getting what it needs.
> > >
> > >
> > >
> > > For this parameter, if we start replaying more recently than what has
> > > been requested, we don't really know if that is what the subscriber
> > > wants.  This doesn't give them the chance to reject the subscription
> > > while being sent stuff which is not helpful to them without the
> > > earlier history.  And you are correct, while we could define a special
> > > event record replay actually began on success, we are not delivering
> > > on the implicit promise of the subscription "ok".  But by using the
> > > no-success result with the included "replay-start-time-hint", we are
> > > matching the design paradigm without adding special constructs.
> > >
> > >
> > >
> > > <KENT> I understand what you're saying, but I think that I disagree
> > > with the conclusion.  I think that the common case is the receiver
> > > wanting to pickup where it left off, or the best the publisher can,
> > > and if not lossless, to be informed that there's a gap (and the size
> > > of the gap) for its records.  The current logic optimizes for what I
> > > think is an unusual case and, assuming it's flipped to be as I'm
> > > suggested, such receivers can themselves immediately cancel the
> > > subscription as soon as being told that there is a gap.  Besides, by
> > > forcing the receiver to have to perform another round-trip, doesn't
> > > that potentially increase the size of the gap?
> > >
> > >
> > >
> > > <Eric2> Yes later dialogs with Martin convinced me exactly that
> > > another round-trip can drive churn unnecessarily.  The latest version
> > > posted starts replay immediately.  To cover the issue discussed above,
> > > there is a new parameter returned *only* if the replay start time has
> > > been modified.  This parameter is: “replay-start-time-revision”.
> > >
> > >
> > >
> > >
> > >
> > > >   OLD: it MAY also be earlier than the current time and MUST
> > >
> > > >   NEW: it MAY be earlier than the current time, but MUST
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT>better, but you missed removing the word "also"
> > >
> > >
> > >
> > > <Eric2> I don’t see “also” in the current v11.
> > >
> > >
> > >
> > >  <KENT> separately, it looks like to touched the next paragraph (not
> > >  sure why, but I'm okay with it) and accidentally introduced a typo:
> > >  "after the after"
> > >
> > >
> > >
> > > <Eric2> corrected before the current v11.
> > >
> > >
> > >
> > > >   "subscribers can perform a get on" - rephrase, and use "RPC" somewhere
> > >
> > >
> > >
> > > Made it:
> > >
> > >
> > >
> > > To assess the availability of replay, subscribers can retrieve the
> > > "replay-log-creation-time" and "replay-log-aged-time" objects from the
> > > YANG model.
> > >
> > > <KENT> better, but maybe s/objects/nodes/?
> > >
> > >
> > >
> > > <eric2> Based on other comments, it now is: To assess the timeframe
> > > available for replay, subscribers can read the leafs
> > > "replay-log-creation-time" and "replay-log-aged-time".
> > >
> > >
> > >
> > >  With that, I don't think RPC is needed.
> > >
> > > <KENT> agreed.
> > >
> > >
> > >
> > >
> > >
> > > > Modifying a Subscription
> > >
> > > >
> > >
> > > >   First sentence, no need for the word "previously"
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   s/one or multiple times/multiple times -or- any number of times/?
> > >
> > >
> > >
> > > Chose "any number"
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   s/via RPC using/via an RPC on/?
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   The tree diagram is not identified as a tree diagram.  And since the
> > >
> > > >   data model isn't explained, there should be a statement for the reader
> > >
> > > >   to look at the YANG module for details, ideally with a hyperlink.
> > >
> > >
> > >
> > > Now done for every tree diagram in the document
> > >
> > > <KENT> excellent
> > >
> > >
> > >
> > >
> > >
> > > > Deleting a Subscription
> > >
> > > >
> > >
> > > >   First sentence, no need for the word "previously"
> > >
> > > >
> > >
> > > >   Under what conditions could a publisher reject a delete-subscription
> > >
> > > >   request?  should there delete-subscription-error-stream hints?
> > >
> > > >
> > >
> > > >   The tree diagram is not identified as a tree diagram.  And since the
> > >
> > > >   data model isn't explained, there should be a statement for the reader
> > >
> > > >   to look at the YANG module for details, ideally with a hyperlink.
> > >
> > > >
> > >
> > > >   Last paragraph, no need for the word "previously"
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > > Killing a Subscription
> > >
> > > >
> > >
> > > >   Regarding:
> > >
> > > >     "This operation MUST be secured so that only connections with
> > >
> > > >      sufficiently privileged access rights are able to invoke this RPC."
> > >
> > > >   This needs to be in the Security Considerations section and, given
> > >
> > > >   that, doesn't need to be here, right?  If you really want it here,
> > >
> > > >   then please indicate that such guidance is provided in the SC section.
> > >
> > >
> > >
> > > Moved to Security Considerations
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Replace the paragraph beginning with "The tree structure of" with the
> > >
> > > >   actual tree diagram for this RPC..
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > > RPC Failures
> > >
> > > >
> > >
> > > >   Please also call-out RESTCONF error handling (RFC8040 Section 7.1).
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   The 2nd paragraph is confusing.  mechanism?  how are the 1st and 2nd
> > >
> > > >   sentences related? What does the 2nd sentence really mean, esp. wrt.
> > >
> > > >   the MUST?
> > >
> > >
> > >
> > > Rewrote the paragraph to:
> > >
> > >
> > >
> > > Specific errors included within this document's YANG model MUST be
> > > returned as part of the RPC error response. Following are valid errors
> > > which can occur for each RPC:
> > >
> > > <KENT> better
> > >
> > >
> > >
> > >
> > >
> > > >   I can't find any examples of these errors in use.  The
> > >
> > > >   netconf-event-notifications draft only has examples for
> > >
> > > >   the "establish-subscription-error-datastore" and
> > >
> > > >   "modify-subscription-error-datastore" errors.
> > >
> > >
> > >
> > > Figure 10 in the netconf-event-notifications draft works equally for
> > > subscribed-notifications, as well as yang-push.  I have identified
> > > that example in that document as being relevant to either streams or
> > > datastores with the sentence in that draft: "This subscription may
> > > have been to either a stream or a datastore."
> > >
> > > <KENT> okay…
> > >
> > >
> > >
> > > Here this document, I have added the sentence:
> > >
> > >
> > >
> > > To see a NETCONF based example of an error response from above, see
> > > [I-D.draft-ietf-netconf-netconf-event-notifications], Figure 10.
> > >
> > > <KENT> good.  Better would be to also have a reference to a
> > > RESTCONF-based example.
> > >
> > >
> > >
> > > <eric2> Understood.  Didn’t know how to do that and not introduce a
> > > publication dependency.
> > >
> > >
> > >
> > > >   Perhaps the
> > >
> > > >   examples in that draft need to be split into examples related
> > >
> > > >   to yang-push vs examples related to subscribed-notifications.
> > >
> > >
> > >
> > > As the error mechanisms are identical between the drafts, splitting
> > > things in that document might prove more confusing.  That is one
> > > reason I identify the error response as being identical for streams
> > > and datastores above.  Perhaps additional examples, git repositories,
> > > or applications located outside the drafts?
> > >
> > > <KENT> maybe, dunno, I'd have to look at that draft again…
> > >
> > >
> > >
> > >
> > >
> > >  > Configured Subscriptions
> > >
> > > >
> > >
> > > >   1st paragraph: s/configuration interface/configuration/g  (two cases)
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   the note under the 3rd bullet point seems unnecessary but, if keeping
> > >
> > > >   it, then just say that receivers are unaware of the existence of any
> > >
> > > >   other receivers.
> > >
> > >
> > >
> > > Done.  Used your proposed text.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   s/In addition to subscription/In addition to the subscription/
> > >
> > > >   s/as described in/described in/
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   where is the tree diagram for the configuration data model?!
> > >
> > >
> > > ****
> > >
> > >
> > >
> > > It is in the section "Subscriptions Container".  It seemed better to
> > > introduce the state machines before getting into the details of the
> > > tree.  But if you really want to have it early, it certainly can be
> > > moved up.
> > >
> > >
> > >
> > > So do you want it moved here, or is a reference to the later section
> > > sufficient?
> > >
> > > <KENT> as I recall reading this section, all the previous 2.x sections
> > > had tree diagrams and I found it rather odd that there wasn't one
> > > here, nor is there any reference to where one can be found.  Perhaps
> > > you can add a forward-reference to s3.3, but forward-references are
> > > discouraged.  Do we need to rearrange sections to make this right?
> > >
> > >
> > >
> > > <Eric2> I placed a two forward references in v11.  One is to Figure 20
> > > for the tree, the other is to the YANG model.
> > >
> > >
> > >
> > >
> > >
> > > >   I don't understand the last bullet point.  First, I'm having trouble
> > >
> > > >   parsing the implicit parentheses..  Next, the last sentence seems
> > >
> > > >   complicated, maybe just say "unless directed otherwise, the
> > >
> > > >   notification messages MUST egress the publisher's default
> > >
> > > >   interface towards the receiver."?
> > >
> > >
> > >
> > > Used your text.  Done.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > <Eric2> Based on further comments on the various options, broke
> > > specific parameters to bulleted text.  Your text is still used.
> > >
> > >
> > >
> > > > Configured Subscription State Model
> > >
> > > >
> > >
> > > >   A better first sentence is needed, something introducing that there
> > >
> > > >   exists a state machine for each configured subscription, and states
> > >
> > > >   that there are three states (VALID, INVALID, and CONCLUDED), etc.
> > >
> > > >   Also should state where this state machine is maintained (publisher,
> > >
> > > >   receiver, both?)
> > >
> > >
> > >
> > > Now says:
> > >
> > > Below is the state machine for a configured subscription on the
> > > publisher.  This state machine describes the three states (VALID,
> > > INVALID, and CONCLUDED), as well as the transitions between these
> > > states. Start and end states are depicted to reflect configured
> > > subscription creation and deletion events.
> > >
> > > <KENT> better (ps: the last part, "Start and end states are depicted
> > > to reflect configured subscription creation and deletion", isn't
> > > there)
> > >
> > >
> > >
> > > <Eric2> Good catch.  Not sure where that went.  Re-added.
> > >
> > >
> > >
> > >
> > >
> > > >   s/publisher evaluation/evaluation by the publisher/?
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Please move text regarding how to interpret the diagram (uppercase,
> > >
> > > >   dashed boxes, parantheses, etc.) into a preamble or postamble element.
> > >
> > >
> > >
> > > Added underneath the diagram.  See diagram below.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   s/itself might itself/itself might/
> > >
> > > >   s/in no longer/is no longer/
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   The first paragraph under the diagram doesn't match what the diagram
> > >
> > > >   shows.  Looking at the diagram, I also see two possible sequence of
> > >
> > > >   transitions that get VALID to INVALID, but I'm unsure how they relate
> > >
> > > >   to the two mentioned in the text..
> > >
> > >
> > >
> > > Updated paragraph text as per below.  Hopefully it is clearer now.
> > >
> > > <KENT> yes
> > >
> > >
> > >
> > > >  The text should call out which
> > >
> > > >   parts of the diagram it's referring to.  Many times I number labels
> > >
> > > >   in diagrams and then, under the diagram, provide a more thorough
> > >
> > > >   explanation for each number.
> > >
> > >
> > >
> > > Added numbers within the diagram, and added text references as per
> > > below:
> > >
> > > <KENT> better
> > >
> > >
> > >
> > > .........
> > >
> > > : start :-.
> > >
> > > :.......: |
> > >
> > >      create  .---modify-----..----------------------------------.
> > >
> > >           |  |               |                                  |
> > >
> > >           V  V          .-------.         .......         .---------.
> > >
> > >  .----[evaluate]--no--->|INVALID|-delete->: end :<-delete-|CONCLUDED|
> > >
> > >  |                      '-------'         :.....:         '---------'
> > >
> > > |----[evaluate]--no-.      ^                ^                 ^
> > >
> > >  |        ^          |      |                |                 |
> > >
> > > yes       |          '->unsupportable      delete           stop-time
> > >
> > >  |      modify         (subscription-   (subscription-   (subscription-
> > >
> > >  |        |             terminated*)     terminated*)      concluded*)
> > >
> > >  |        |                 |                |                 |
> > >
> > >  |       (1)               (2)              (3)               (4)
> > >
> > > |   .---------------------------------------------------------------.
> > >
> > > '-->|                         VALID                                 |
> > >
> > >      '---------------------------------------------------------------'
> > >
> > >
> > >
> > > Legend:
> > >
> > > dotted boxes: subscription creation and deletion events
> > >
> > > dashed boxes with uppercase letters: valid states for a subscription
> > >
> > > [evaluate]: decision point on whether the subscription is supportable
> > >
> > > (*): resulting subscription state change notification
> > >
> > >
> > >
> > > Also the text below now says:
> > >
> > >
> > >
> > > A valid subscription may become invalid on one of two ways.  First, it
> > > may be modified in a way which fails a re-evaluation.  See (1) in the
> > > diagram. Second, the publisher itself might determine that the
> > > subscription is no longer supportable.  See (2) in the diagram.  In
> > > either case, a "subscription-terminated" notification is sent to any
> > > active or suspended receivers.  A valid subscription may also
> > > transition to a concluded state via (4) if a configured stop time has
> > > been reached.  In this case, a "subscription-concluded" is sent to any
> > > active or suspended receivers.  Finally, a subscription may be deleted
> > > by configuration (3).
> > >
> > > <KENT> better
> > >
> > >
> > >
> > >
> > >
> > > >   Is it "any active or suspended receivers" or "any receivers for an
> > >
> > > >   active or suspended subscription"?
> > >
> > >
> > >
> > > The current wording is correct.  A configured subscription is never
> > > suspended.  It can be INVALID, or it can be ACTIVE and all its
> > > receivers suspended.  But in the second case, at least the receivers
> > > get subscription-suspended notifications.
> > >
> > > <KENT> okay
> > >
> > >
> > >
> > > >   s/During any times a/When a/?
> > >
> > >
> > >
> > > <KENT> you didn't say you did this one, but I see that you did, thx.
> > >
> > >
> > >
> > >
> > >
> > > >   Regarding "Below is the state machine for each receiver of a
> > > >   configured
> > >
> > > >   subscription." - where is this state machine maintained, on the
> > > >   publisher
> > >
> > > >   or on the receiver?
> > >
> > >
> > >
> > > Updated the title to show it is a Publisher state model.
> > >
> > > <KENT> did you?  I see " Receiver state for a configured
> > > subscription", which seems misleading
> > >
> > >
> > >
> > > <Eric2> Tweaked to “Receiver state for a configured subscription on a
> > > Publisher”
> > >
> > >
> > >
> > >
> > >
> > > >   why is "receiver" in each box?
> > >
> > >
> > >
> > > To drive home the idea that this state machine was for each individual
> > > receiver, rather than for the subscription as a whole..
> > >
> > >
> > >
> > > <KENT> okay, I guess, I don't know, it seems confusing, but I see that
> > > you explain it in the legend, so that's better…
> > >
> > >
> > >
> > >
> > >
> > > >   Again, you might look to having a
> > >
> > > >   preamble or postamble to describe the syntax used in the diagram.
> > >
> > >
> > >
> > > Per figure below, added the legend as a postamble:
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   1st paragraph below diagram: s/to connecting/to "connecting" -or- to
> > >
> > > > CONNECTING/?
> > >
> > >
> > >
> > > Now says CONNECTING.   And all receiver states moved to uppercase.
> > >
> > > <KENT> good
> > >
> > >
> > >
> > >
> > >
> > > >   Regarding "and event records are not being dropped due to a publisher
> > >
> > > >   buffer overflow" - this seems like it's from out of nowhere.  If not
> > >
> > > >   normative, then maybe delete?
> > >
> > >
> > > ****
> > >
> > > It is normative.  This is needed to maximize the number of concurrent
> > > subscriptions without enforcing continuous transport keep-alive
> > > overhead when no event records are being passed, as well as to not
> > > prematurely declare a subscription as suspended while there is a
> > > chance that transport may be established before event records do get
> > > lost.  This allows a configured subscription’s receiver to exist
> > > across an intermittent connection, and the receiver can remain active
> > > on the publisher as long as events aren’t being lost.  While this can
> > > be done with NETCONF, it is probably more likely to be seen in
> > > practice with HTTP connections.
> > >
> > >
> > >
> > > Based on that, I rephrased the words above so that it doesn’t feel
> > > from out of nowhere.  See the text below the updated figure below...
> > >
> > >  <KENT> thx
> > >
> > >
> > >
> > > >   This text is again difficult to reconcile with the diagram.  I again
> > >
> > > >   recommend numbering labels and then describe the numbers below.
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >      .-----------------------------------------------------------------.
> > >
> > >      |                         VALID                                   |
> > >
> > >      |   .----------.                           .--------.             |
> > >
> > >      |   | receiver |------------------timeout->|receiver|             |
> > >
> > >      |   |CONNECTING|<------------------reset---|TIMEOUT |             |
> > >
> > >      |   |          |<-transport---.            '--------'             |
> > >
> > >      |   '----------'  loss,reset  |                                   |
> > >
> > >      |      (1)          |         |                                   |
> > >
> > >      |  subscription-   (3)        |                                   |
> > >
> > >      |  started*    .--------.     |                       .---------. |
> > >
> > >      |       '----->|        |     '--------------------(3)|         | |
> > >
> > >      |              |receiver|(2)-subscription-suspended*->|receiver | |
> > >
> > >      | subscription-| ACTIVE |                             |SUSPENDED| |
> > >
> > >      |   modified*  |        |<--subscription-resumed*,----|         | |
> > >
> > >      |        '---->'--------'    subscription-modified*   '---------' |
> > >
> > >      '-----------------------------------------------------------------'
> > >
> > >
> > >
> > >   Legend:
> > >
> > >    dashed boxes which include the word 'receiver' show the possible
> > >
> > >    states for an individual receiver of a VALID configured subscription.
> > >
> > >    * indicates a state change notification
> > >
> > >
> > >
> > > Individual receivers are moved to an ACTIVE state when a
> > > "subscription-started" state change notification is successfully
> > > passed to that receiver (1). Configured receivers remain ACTIVE if
> > > both transport connectivity can be verified to the receiver, and event
> > > records are not being dropped due to a publisher buffer overflow. The
> > > result is that a receiver will remain ACTIVE on the publisher as long
> > > as events aren’t being lost, or the receiver cannot be reached.
> > > However if there is buffer overflow, or the publisher cannot generate
> > > events for a receiver, the receiver MUST be suspended (2).  In
> > > addition, a configured subscription's receiver MUST be moved to
> > > CONNECTING if transport connectivity cannot be achieved, or if the
> > > receiver is reset via configuration operations (3).
> > >
> > > <KENT> yes, better, esp. w/ the numbering
> > >
> > >
> > >
> > >
> > >
> > > >   s/ mechanisms described above is/ mechanisms described above are/
> > >
> > > >   What does this mean, how are mechanisms mirrored for RPCs and
> > >
> > > >   notifications?
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Regarding " provides an example of such an extension" - which section?
> > >
> > >
> > >
> > > Revised text to:
> > >
> > >
> > >
> > > The YANG model [I-D..ietf-netconf-yang-push] Section 4.1, provides
> > > many such extensions, this includes the augmentation of
> > > "/sn:modify-subscription/sn:input/sn:target".
> > >
> > > <KENT> better, but:
> > >
> > > 1) I didn't review yang-push, but I hope that someone pointed out that
> > > section 4.1 needs to point to section 5 and, additionally perhaps
> > > section 5 should be moved to section 4.5…
> > >
> > >
> > >
> > > <Eric2> I think you are suggesting that the YANG push tree model in
> > > 4.1 needs to point to the YANG model section number.  And that perhaps
> > > the YANG model section itself shouldn’t be in an independent top level
> > > section, but rather fall into section 4.  I have no issues with that.
> > > **Alex, do you want to update, this should be a very minor update?
> > >
> > >
> > >
> > > 2) sentence structure needs help, how about: "For instance, the YANG
> > > module defined in Section 5 of [I-D..ietf-netconf-yang-push] augments
> > > "/sn:modify-subscription/sn:input/sn:target".  ???
> > >
> > >
> > >
> > > <Eric2> Adopted your text.
> > >
> > >
> > >
> > > > Creating a Configured Subscription
> > >
> > > >
> > >
> > > >   1st paragraph: let the first sentence be its own paragraph as with
> > >
> > > >   the other 2.5.x sections.
> > >
> > >
> > >
> > > >   For the remainder, I think this is the
> > >
> > > >   3rd time that the draft has discussed the differences between
> > >
> > > >   configured and dynamic subscriptions.  Please eliminate unnecessary
> > >
> > > >   redundancy.  Factor out into another section if needed.
> > >
> > >
> > >
> > > I agree that the following paragraph can be deleted.
> > >
> > >
> > >
> > > There are two key differences between the new RPCs defined in this
> > > document and configuration operations for subscription
> > > creation. Firstly, configuration operations install a subscription
> > > without question, while the RPCs are designed to the support
> > > negotiation and rejection of requests. Secondly, while the RPCs
> > > mandate that the subscriber establishing the subscription is the only
> > > receiver of the notification messages, configuration operations permit
> > > specifying receivers independent of any tracked subscriber.
> > >
> > >
> > >
> > > I have just removed this.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Regarding 2nd/3rd paragraphs, how resilient is the solution to the
> > >
> > > >   resumption of the underlying transport?  If messages lost in the
> > >
> > > >   write-buffer are lost, could the receiver ever be helplessly out
> > >
> > > >   of sync without a full restart?
> > >
> > >
> > >
> > > I think we are clean here.  I have updated the text against the
> > > diagram per-above which hopefully provides more descriptive text on
> > > why the resumption of underlying transport is covered.
> > >
> > > <KENT> I don't understand this response, can you provide more
> > > information?
> > >
> > >
> > >
> > > <Eric2> For a configured subscription, transport can safely come/go as
> > > long as events are not lost or delayed because a connection with a
> > > receiver is unavailable.  Instead it is whether events are dropped
> > > before they can be transmitted.
> > >
> > >
> > >
> > > To support this, the text says:
> > >
> > >
> > >
> > > “However if there is buffer overflow, or the publisher cannot generate
> > > notification messages for a receiver, the receiver MUST be moved to
> > > SUSPENDED (2).”  The result is that a receiver will know that event
> > > records may have been lost if a subscription-suspended and/or
> > > subscription-resumed are received.  On such a resume, a subscriber can
> > > attempt a replay if it needs the older events.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > Modifying a Configured Subscription
> > >
> > > >
> > >
> > > >   s/ ././    ;)
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > > Resetting a Configured Receiver
> > >
> > > >
> > >
> > > >   But *how* is it reset? - via a configuration operation?  which one?
> > >
> > > >   Should this be part of "Modifying a Configured Subscription"?
> > >
> > >
> > >
> > > Added the sentence:
> > >
> > >
> > >
> > > This is accomplished via the "reset" action within the YANG model at
> > > "/subscriptions/subscription/receivers/receiver/reset".
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > > Event Record Delivery
> > >
> > > >
> > >
> > > >   First paragraph, last sentence.  I think I commented on similar text
> > >
> > > >   before.  Is this a requirement for the transport binding?
> > >
> > >
> > >
> > > Perhaps the word interleave is the wrong choice here, and intermixing
> > > is better in this case.  I made that change.
> > >
> > > <KENT> okay, but where did the following new paragraph come from?
> > >
> > >
> > >
> > > <Eric2> WG threads/dialogs with Martin.
> > >
> > >
> > >
> > > Also:
> > >
> > >    - s/passed receiver/passed to the receiver/?
> > >
> > >
> > >
> > > <Eric2> Don’t see that text.  Looks like it was cleaned up already.
> > >
> > >
> > >
> > > >  Do the netconf-notif and restconf-notif drafts satisfy this
> > > >  requirement?
> > >
> > >
> > >
> > > Yes
> > >
> > > <KENT> good
> > >
> > >
> > >
> > >
> > >
> > > > where?
> > >
> > >
> > >
> > > Netconf-notif supports interleaving of requests as described in
> > > Section 3.
> > >
> > > <KENT> okay
> > >
> > >
> > >
> > > Restconf-notif doesn’t need to explicitly call for pipelining support
> > > as it is a basic capability of HTTP.
> > >
> > > <KENT> but the question isn't about pipelining.  Even NETCONF supports
> > > pipelining, something extra is needed to support "intermixing", right?
> > >
> > >
> > >
> > > <Eric2> Yes.  And we do have that intermixing included in document
> > > requirements within this section.  Text says:
> > >
> > >
> > >
> > > “In all cases, a single transport session MUST be capable of
> > > supporting the intermixing of RPCs and notifications from different
> > > subscriptions.”
> > >
> > >
> > >
> > > I think that change was made after conversations with Martin, so it
> > > didn’t come back explicitly via this subthread.
> > >
> > >
> > >
> > > >   2nd paragraph: "able to traverse" --> "not blocked by"?
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Also, for
> > >
> > > >   the 3rd sentence, call out the "RPC response" is for dynamic and
> > >
> > > >   "state-change notification" is for configured?
> > >
> > >
> > >
> > > Yes.   Made text:
> > >
> > >
> > >
> > > A subscription's events MUST NOT be sent to a receiver until after a
> > > corresponding RPC response (in the case of a dynamic subscription) or
> > > state-change notification (in the case of a configured subscription)
> > > has been passed receiver indicating that events should be expected.
> > >
> > > <KENT> good
> > >
> > >
> > >
> > >
> > >
> > > >   Last two paragraphs, this text needs to be removed,
> > >
> > >
> > >
> > > removed
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   or else we might
> > >
> > > >   need to block this draft on notification-messages.   What do you mean
> > >
> > > >   by " this document will be updated to indicate support".
> > >
> > >
> > >
> > > At some point when notification-messages is complete, this draft
> > > should be updated as it is a more robust solution (as a subscription
> > > id can be provided for event records provided on streams.)
> > >
> > >
> > >
> > > <KENT> you misunderstood, I know what it means, I was questioning why
> > > we'd say such a thing.  Anyway, you removed the paragraph already, so
> > > it's no longer an issue.
> > >
> > >
> > >
> > >
> > >
> > > > Subscription State Notifications
> > >
> > > >
> > >
> > > >   OLD
> > >
> > > >    In addition to subscribed event records, a publisher MUST send
> > >
> > > >    subscription state notifications to indicate to receivers that an
> > >
> > > >    event related to the subscription management has occurred.
> > >
> > > >   NEW
> > >
> > > >    In addition to sending event records to receivers, a publisher MUST
> > >
> > > >    also send subscription state notifications when events related to
> > >
> > > >    the subscription management has occurred.
> > >
> > > >   ???
> > >
> > >
> > >
> > > Done.  (Removed the extra ‘the’)
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   2nd paragraph: s/directly//
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Also, I'm unsure about the "subscription-state-notif" extension, how
> > >
> > > >   is it expected to be used by a YANG processor?
> > >
> > >
> > >
> > > Per above, it ensures that these YANG notifications if encoded in XML
> > > are not placed onto the NETCONF stream.
> > >
> > >
> > >
> > > <KENT> actually, I thought that before it only said that the
> > > Subscription State Notifications (s2.7) were not placed into the
> > > NETCONF stream???
> > >
> > >
> > >
> > > <Eric2> Subscription state notifications are a type of YANG
> > > notification, as they are encoded in the YANG model.  Per the London
> > > WG discussion on slide “Question 2”, I believe it easier to mark
> > > these.  See next comment below.
> > >
> > >
> > >
> > >
> > >
> > > >   Perhaps a generic
> > >
> > > >   notification-filtering GUI is envisioned whereby the logic could
> > >
> > > >   automatically remove these notifications from selection, but coding
> > >
> > > >   for this extension has very limited use, as no other drafts are ever
> > >
> > > >   likely to define any.  I suppose it does no harm, but I also think
> > >
> > > >   that the text sure be clear.  Personally, I'd rather the extension
> > >
> > > >   be removed unless there is a good reason to keep it.
> > >
> > >
> > >
> > > ****
> > >
> > > The three choices seem to be:
> > > (a) current solution
> > >
> > > (b) hardcode the these notifications so none ever go on the NETCONF
> > > stream
> > >
> > > (c) make the extension “exclude-from-NETCONF-stream”.  As it is quite
> > > possible that other drafts will want to do that.
> > >
> > >
> > >
> > > I am good with any of these.  But the first seems the cleanest, and
> > > most self contained.  Let me know it the current doesn’t work for you.
> > >
> > >
> > >
> > > <ALEX> Just to add on: A reason for the extension (and different
> > > solutions were discussed at different points in time) was that since
> > > this is a “meta-notification”, it should be treated differently from
> > > other notificaitons.  For example, a subscriber should receive these
> > > even if not explicitly subscribing to them – they are simply part of
> > > the “control protocol” for managing the subscriptions.  They also
> > > apply if a subscriber subscribes to something other than the NETCONF
> > > stream.
> > >
> > > </ALEX>
> > >
> > >
> > >
> > > <KENT> yes, Alex, part of the control protocol, this is why I'm
> > > thinking maybe Eric's choice (b) is best.  Is this being discussed
> > > elsewhere?
> > >
> > >
> > >
> > > <Eric2> We had a discussion on this in London:
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__youtu.be_KJtg-2DJ-
> 2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=2
> ZAWwt38BLRzZXn66-
> kWUPEWuw26F0Uqjsvtmi_oRiQ&s=D7QvpoertL3rgQvIYHzpWfBeuq_KizPBp7V
> QKJLelXc&e=
> > 6CZM?t=1963<https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__youtu.be_KJtg-2DJ-2D6CZM-3Ft-
> > 3D1963&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=8
> > SC9EE43RlHG68Oyp-
> > zOqWCQ3RTjFqQJdzR_OSyqSvs&s=0OGkT5cNK9aY8v5z4CwNWj-
> > 9A079WseJ6sBcL7veA9c&e=>
> > >
> > > As there was no comment in the room, I was hoping we had actually had
> > > some form of consensus between us on (a).  So I hadn’t spun up a
> > > separate question on this yet.
> > >
> > >
> > >
> > > But it seems there is an issue.  I will open up a thread now.
> > >
> > >
> > >
> > > > subscription-started:
> > >
> > > >
> > >
> > > >   Regarding the 2nd paragraph, Section 2.4.2.1 implies a contradiction
> > >
> > > >   to this statement.
> > >
> > >
> > >
> > > ****
> > >
> > > A replay subscription can be set for a configured subscription.  There
> > > was some carrier on the NETCONF alias who requested this many months
> > > ago.  See also dialogs with Martin.
> > >
> > >
> > >
> > > Looking at your comment, it probably isn’t a good idea to embed this
> > > fact within the replay text embedded as part of the dynamic
> > > subscription section.
> > >
> > > The best way to tease this apart is first to separate any configured
> > > subscription context the 2.4.2.1.  This can be done simply by
> > > replacing the ‘after the "subscription-started" notification’. With ’
> > > after the after a successful establish-subscription RPC response’.
> > >
> > >
> > >
> > > <KENT> okay, modulus the "after the after" typo.
> > >
> > >
> > >
> > > <Eric2> I can find no “after the after” in v11.  Perhaps I already
> > > fixed this.
> > >
> > >
> > >
> > > And then to be more explicit that this is supported, we could add move
> > > contradicting statement into a new section 2.5.6 where it would no
> > > longer appear contradicting.  Replay in a new section looks like this:
> > >
> > >
> > >
> > > 2.5.6 Replay for a Configured Subscription
> > >
> > > It is possible to place a start time on a configured subscription.
> > > This enables functionality like immediately streaming boot log
> > > information off of a publisher immediately after restart.
> > >
> > > <KENT> "immediately used twice, suggest removing first instance.
> > > Actually, this needs a rewrite, perhaps "This enables streaming of
> > > logged information immediately after restart." ???
> > >
> > >
> > >
> > > <Eric2> Adopted your text.
> > >
> > >
> > >
> > > When any such configured subscription receivers become ACTIVE,
> > > buffered event records (if any) will be sent immediately after the
> > > “subscription-started” notification.  The first event sent will be the
> > > most recent following the latest of four different times: the
> > > "replay-log-creation-time", "replay-log-aged-time",
> > > "replay-start-time", or the most recent publisher boot time.
> > >
> > > <KENT> I don't understand the 2nd sentence here
> > >
> > >
> > >
> > > <Eric2> Rewrote to: “The leading event record sent will be the first
> > > event record subsequent to the latest of four different times: the
> > > "replay-log-creation-time", "replay-log-aged-time",
> > > "replay-start-time", or the most recent publisher boot time.”
> > >
> > >
> > >
> > > All other replay functionality remains the same as with dynamic
> > > subscriptions as described in Section 2.4.2.1
> > >
> > > <KENT> I'm not sure I like having to look at 2.4.2.1 and trying to
> > > figure out what this means.  Can you make this more explicit or, since
> > > 5.6 is pretty small, copy the parts into this section?
> > >
> > >
> > >
> > > <Eric2> I initially had all the text in 2.4.2.1.  But this hid the
> > > fact that you can do replay on a configured subscription.  So your
> > > comment above lead to this section being introduced.  Which is a good
> > > thing.  But as 2.4.2.1 is not very small, to me it feels like
> > > repeating all that text here might be overkill.
> > >
> > >
> > >
> > >
> > >
> > > The good news is that all of this is consistent with text is already
> > > reflected in the YANG model.
> > >
> > > <KENT> thankfully!
> > >
> > >
> > >
> > >
> > >
> > > >   The tree diagram is not identified as a tree diagram.  And since the
> > >
> > > >   data model isn't explained, there should be a statement for the reader
> > >
> > > >   to look at the YANG module for details, ideally with a hyperlink.
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Why is all this sent to the receiver?  Doesn't it already know the
> > >
> > > >   protocol and encoding?  What about the other parts?  Which parts
> > >
> > > >   are actually useful?
> > >
> > >
> > >
> > > The complete state of the subscription is sent, which can also be
> > > useful for debugging.  But beyond that, based on what I am hearing
> > > from the CBOR people, even the protocol and encoding might be
> > > different between.
> > >
> > > <KENT> okay
> > >
> > >
> > >
> > >
> > >
> > > > subscription-modified
> > >
> > > >
> > >
> > > >   1st paragraph: the same parameters, or data model / tree diagram?
> > >
> > > >   Also, is "provided" the right word?  Maybe it would be better to
> > >
> > > >   have the tree diagram itself, even though only the name changes?
> > >
> > >
> > >
> > > Provided the full tree.  It does chew up space, but that is not really
> > > an issue.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   Last two paragraphs, why put "First" and "Second" when they are
> > >
> > > >   bullet points.  Maybe you want to use a numbered-list or otherwise
> > >
> > > >   rephrase these?
> > >
> > >
> > >
> > > Made a numbered list
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   Last paragraph, the last sentence doesn't flow with the first.
> > >
> > > >   It seems as if it was copy/pasted from somewhere else.  Is this
> > >
> > > >   intended to be a normative statement here?
> > >
> > >
> > >
> > > Yes it is a normative statement, and it is in the correct place.
> > >
> > >
> > >
> > > I added text to smooth the transition.  It now is this:
> > >
> > >
> > >
> > > While this state change will be most commonly used with configured
> > > subscriptions, with dynamic subscriptions, there is also one time this
> > > notification will be sent. A "subscription-modified" state change
> > > notifications MUST be sent if the contents of a filter identified by a
> > > "stream-filter-ref" has changed.
> > >
> > > <KENT> better
> > >
> > >
> > >
> > >
> > >
> > > > subscription-terminated
> > >
> > > >
> > >
> > > >   1st paragraph, 1st sentence: -e a/The publisher/A publisher/ and
> > >
> > > >   also s/the pushing of/pushing/?
> > >
> > >
> > >
> > > Done
> > >
> > >  <KENT> thx
> > >
> > >
> > >
> > > >   1st paragraph: "Such a decision may be made for" - should this
> > >
> > > >   be "A publisher may terminate a subscription for" ?
> > >
> > >
> > >
> > > Done
> > >
> > >  <KENT> thx
> > >
> > >
> > >
> > > >   1st paragraph, for the "first type of reason": does the subscription
> > >
> > > >   terminate when the first or last referenced objects are no longer
> > >
> > > >   accessible?
> > >
> > >
> > >
> > > This refers to any either any leafref going missing, or the
> > > subscription-id being removed.  More in next comment
> > >
> > >
> > >
> > > >  BTW, what do you mean by "via the YANG model", aren't
> > >
> > > >   these instance objects in <operational>?
> > >
> > >
> > >
> > > I have updated the text in this section to be much more explicit to
> > > cover the intent.  The section now says
> > >
> > >
> > >    A publisher MAY terminate pushing subscribed event records to a
> > >    receiver.  This notification indicates that no further notification
> > >    messages should be expected from the publisher.  A publisher may
> > >    terminate a subscription for the following reasons:
> > >
> > >    1.  Configuration which removes a configured subscription, or a "kill-
> > >        subscription" RPC.  These are identified via the reason "no-such-
> > >        subscription".
> > >
> > >    2.  A referenced filter is no longer accessible.  This is identified
> > >        by "filter-unavailable".
> > >
> > >    3.  The stream referenced by a subscription is no longer accessible
> > >        by the receiver.  This is identified by "stream-unavailable".
> > >
> > >    4.  A suspended subscription has exceeded some timeout.  This is
> > >        identified by "suspension-timeout".
> > >
> > >
> > > Each of the reasons above correspond one-to-one with a "reason"
> > > identityref specified within the YANG model.
> > >
> > > <KENT> good
> > >
> > >
> > >
> > >
> > >
> > > >   1st paragraph, what do you mean by " Identities within the YANG
> > > >   model"?
> > >
> > > >   Can the text be more clear that it is referring to the "reason"
> > >
> > > >   identityref in the tree diagram?
> > >
> > >
> > >
> > > Text attempted just above.
> > >
> > > <KENT> okay
> > >
> > >
> > >
> > > >   The tree diagram is not identified as a tree diagram.
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   last paragraph: remove "established".  Also, the first 2 sentences
> > > >   would
> > >
> > > >   benefit moving to singular, as plural leads to some ambiguity.
> > >
> > >
> > >
> > > Done.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > Note: a subscriber can terminate an existing subscription via a
> > > "delete-subscription" RPC. In such a case, no
> > > "subscription-terminated" state change notification is sent.
> > >
> > > <KENT> good
> > >
> > >
> > >
> > >
> > >
> > > > subscription-suspended
> > >
> > > >
> > >
> > > >   Please replace the 2nd paragraph with the actual tree diagram, and
> > > >   then
> > >
> > > >   speak to that.
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > >    This notification indicates that a publisher has suspended the
> > >
> > >    sending of event records to a receiver, and also indicates the
> > >
> > >    possible loss of events.  Suspension happens when capacity
> > >
> > >    constraints stop a publisher from serving a valid subscription.  The
> > >
> > >    two conditions where is this possible are "insufficient-resources"
> > >
> > >    and "unsupportable-volume".  These conditions are encoded within the
> > >
> > >    reasons.  No further notification will be sent until the subscription
> > >
> > >    resumes or is terminated.
> > >
> > >
> > >
> > >    Below is a tree diagram for "subscription-suspended".  All objects
> > >
> > >    contained in this tree are described within the included YANG model
> > >
> > >    within Section 4.
> > >
> > >
> > >
> > >        +---n subscription-suspended
> > >
> > >           +--ro identifier    subscription-id
> > >
> > >           +--ro reason        identityref
> > >
> > >
> > >
> > >         Figure 11: subscription-suspended notification tree diagram
> > >
> > >
> > >
> > > <KENT> good
> > >
> > >
> > >
> > >
> > >
> > > > subscription-resumed
> > >
> > > >
> > >
> > > >   The tree diagram is not identified as a tree diagram.
> > >
> > >
> > >
> > > Updated.  As are all other tree diagrams now..
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > > subscription-completed
> > >
> > > >
> > >
> > > >   Please replace the 2nd paragraph with the actual tree diagram, and
> > > >   then
> > >
> > > >   speak to that.
> > >
> > >
> > >
> > > Updated.  As are all other tree diagrams now..
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > > replay-completed
> > >
> > > >
> > >
> > > >   2nd paragraph: s/ If subscription/ If a subscription/ and
> > > >   s/which/that/
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Please replace the last paragraph with the actual tree diagram, and
> > > >   then
> > >
> > > >   speak to that.
> > >
> > >
> > >
> > > Done as identical to above.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > > Subscription Monitoring
> > >
> > > >
> > >
> > > >   1st paragraph: s/Container/The container/.
> > >
> > >
> > >
> > > Done.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   How can container "subscriptions" (config true) contain entries for
> > >
> > > >   dynamic subscriptions?  Are you assuming in <operational>?
> > >
> > >
> > >
> > > Updated the start of paragraph 1 to:
> > >
> > >
> > >
> > > In the operational datastore, the container "subscriptions" maintains
> > > the state of all known subscriptions.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > Updated paragraph 2 to:
> > >
> > >
> > >
> > > Each subscription is represented as a list element.  While many
> > > subscription objects are "config true", dynamic subscriptions are only
> > > included within the operational datastore. Operational information
> > > which may be monitored includes receiver counter information, the
> > > state...
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Also,
> > >
> > > >   does it include configured subscriptions that are currently not
> > >
> > > >   active for whatever reason?
> > >
> > >
> > >
> > > Yes.   First paragraph above uses the word ‘all’.
> > >
> > > <KENT> but if not active, aka operational, why are they in the
> > > operational datastore?  This needs to be explained.
> > >
> > >
> > >
> > > <Eric2> Two thoughts.  First, a configured subscription can be VALID
> > > without having any ACTIVE receivers. Second, the status of a
> > > configured subscription is a “config false” element which includes
> > > both the INVALID and CONCLUDED states that are not configurable.
> > > (text below)
> > >
> > >
> > >
> > > Also, maybe you need to be more explicit than just having "all" …
> > >
> > >
> > >
> > > <Eric2> You are correct, some more detail is needed.  And more
> > > description of the counters is needed.  I shook things up.  Here is
> > > what it says now:
> > >
> > >
> > >
> > > In the operational datastore, the container "subscriptions" maintains
> > > the state of all dynamic subscriptions, as well as all configured
> > > subscriptions.  Using datastore retrieval operations, or subscribing
> > > to the "subscriptions" container via [I-D.ietf-netconf-yang-push]
> > > allows the state of subscriptions and their connectivity to receivers
> > > to be monitored.
> > >
> > >
> > >
> > > Each subscription in the operational datastore is represented as a
> > > list element. Included in this list are event counters for each
> > > receiver, the state of each receiver, as well as the subscription
> > > parameters currently in effect. The appearance of the leaf
> > > "configured-subscription-state" indicates that a particular
> > > subscription came into being via configuration.  This leaf also
> > > indicates if current state of that subscription is VALID, INVALID, and
> > > CONCLUDED.
> > >
> > >
> > >
> > > To understand the flow of event records within a subscription, there
> > > are two counters available for each receiver.  The first counter is
> > > "pushed-notifications" which shows the quantity of events actually
> > > identified for sending to a receiver.  The second counter is
> > > "excluded-notifications" which shows event records not sent to
> > > receiver.  "excluded-notifications" shows the combined results of both
> > > access control and per-subscription filtering.  For configured
> > > subscriptions, counters are reset whenever the subscription is
> > > evaluated to VALID (see (1) in Figure 8).
> > >
> > >
> > >
> > > Dynamic subscriptions do not appear outside of the operational
> > > datastore, and are removed from the operational datastore once they
> > > expire (reaching stop-time) or when they are terminated.
> > >
> > >
> > >
> > > >   You mention NETCONF's <get> (wait, I
> > >
> > > >   thought this draft was suppose to be transport agnostic), but not
> > >
> > > >   NMDA's <get-data>, so it make me wonder if this paragraph regards
> > >
> > > >   the contents of <running> or <operational>...
> > >
> > >
> > >
> > > Yes, we want to make it want to make it agnostic.  So it now says:
> > >
> > >
> > >
> > > Using datastore retrieval operations , or subscribing to...
> > >
> > > <KENT> better
> > >
> > >
> > >
> > >
> > >
> > > >   The 2nd paragraph would make more sense if I was looking at a tree
> > >
> > > >   diagram.  But then I realize that this would be the same tree-diagram
> > >
> > > >   that should've been presented in Configured Subscriptions.
> > >
> > >
> > >
> > > The tree is in the subscriptions container section just below.  I will
> > > gladly reference it wherever it ends up.
> > >
> > > <KENT> you already need to be referring to it regardless.  As for
> > > where it is, see my previous comment on this topic
> > >
> > >
> > >
> > > <Eric2> References to Figure 20 has been made.  If the tree must be
> > > moved up, it can be.  I think it fits better where it is.
> > >
> > >
> > >
> > >
> > >
> > > > Advertisement
> > >
> > > >
> > >
> > > >   The second paragraph seems to be mostly NETCONF specific and
> > >
> > > >   therefore belongs in the netconf-binding draft.
> > >
> > >
> > >
> > > Good point.  Moved the first sentence to the end of that draft’s
> > > “Compatibility with RFC-5277's create-subscription” section.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   In a transport-
> > >
> > > >   agnostic draft, maybe only features should be discussed?
> > >
> > >
> > >
> > > Makes sense
> > >
> > > <KENT> did you do this, or is this entire paragraph missing now?
> > >
> > >
> > >
> > > <Eric2> I did this.  Current section “Compatibility with RFC-5277's
> > > create-subscription” of NETCONF-notif says:
> > >
> > >
> > >
> > > If a publisher supports this specification but not subscriptions via
> > > [RFC5277], the publisher MUST NOT advertise
> > > "urn:ietf:params:netconf:capability:notification:1.0".
> > >
> > >
> > >
> > >
> > >
> > > > YANG Data Model Trees
> > >
> > > >
> > >
> > > >   s/top level YANG Data Node containers/protocol-accessible nodes/
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   " If you would rather see" - please use more formal language.
> > >
> > >
> > >
> > > Made it:
> > >
> > >
> > >
> > > For tree diagrams of state change notifications,
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > > Event Streams Container
> > >
> > > >
> > >
> > > >   1st paragraph, last sentence: perhaps rephrase as "This enables
> > >
> > > >   clients to discover what streams a publisher supports."?
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >  BTW, is
> > >
> > > >   the " and against which subscription is allowed" part important,
> > >
> > > >   if so, why?
> > >
> > >
> > >
> > > Not really.  I was just trying to highlight that different clients
> > > might have visibility for different streams.  As this is implicit, I
> > > just dropped it and used your text.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   This tree-diagram does not match what I generate.  This indicates
> > >
> > > >   that the tree diagrams are not being dynamically-generated.  I
> > >
> > > >   strongly suggest updating your build script to dynamically generate
> > >
> > > >   the tree diagrams.  We cannot afford to have them be out of alignment.
> > >
> > >
> > >
> > > At the WG request, I segmented the YANG tree into different sections.
> > > However I do not have the tooling which automatically extracts
> > > portions of the YANG tree.
> > >
> > >
> > >
> > > Is there a git repository which recommends a continuous integration
> > > for sub portions of a YANG tree?  For future drafts, I have certainly
> > > built a strong desire for such a continuous integration environment.
> > >
> > >
> > >
> > > <KENT> I have my own tooling using Makefiles and shell scripts to
> > > dynamically generate and include the tree diagrams every build.  You
> > > should be looking to create similar now, for this draft (not next
> > > drafts).  Again, we cannot afford for these things to get out of
> > > alignment, and these drafts still have a way to go yet…
> > >
> > >
> > >
> > > <Eric2> I have not seen automated tooling from pyang which pulls
> > > individual RPCs and Notification Trees into extracts.  Not finding a
> > > way to do this with –tree-path, I tried guessing.  But didn’t get
> > > there.  As the majority of my trees are RPCs and Notifications, I
> > > don’t see a fully automated solution available as yet.
> > >
> > >
> > >
> > > > Event Stream Filters Container
> > >
> > > >
> > >
> > > >   "and validated" - is this needed, since *all* configuration is
> > > >   validated?
> > >
> > >
> > >
> > > Removed
> > >
> > >
> > >
> > > >   s/ which/ that/
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   "referenced and used" - is there a difference?  - can you just use
> > > >   one?
> > >
> > >
> > >
> > > Now just referenced
> > >
> > >  <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >
> > >
> > > > Subscriptions Container
> > >
> > > >
> > >
> > > >
> > >
> > > >   This tree-diagram does not match what I generate.  This indicates
> > >
> > > >   that the tree diagrams are not being dynamically-generated.  I
> > >
> > > >   strongly suggest updating your build script to dynamically generate
> > >
> > > >   the tree diagrams.  We cannot afford to have them be out of alignment.
> > >
> > >
> > >
> > > I would love to have fully generated scripts.  That is hard for a few
> > > reasons here:
> > >
> > >
> > >
> > > (a) The automatically generated trees are getting mangled because they
> > > are so wide.  Especially with yang-push, the automatic trees must all
> > > be fixed manually each time.
> > >
> > >
> > >
> > > <KENT> pyang already supports folding and pathing, what else are you
> > > doing?  Sometimes I need to tweak the pyang output, but I scripted
> > > that too and make it part of my build scripts
> > >
> > >
> > >
> > > <Eric2> Martin taught me how to fold/path.  So that is a welcome fix.
> > >
> > >
> > >
> > > (b) I have no insights on how to pull portions of a tree into a XML
> > > document.  Is there a tool site which provides this?
> > >
> > > <KENT> my Makefiles call a shell script to do the insertions…
> > >
> > >
> > >
> > > <Eric2> My environment has certainly shown itself to be insufficient.
> > > If WG requires Makefiles rather than what many of us use (yes, I
> > > really built most of this via NOTEPAD++, and I know there are multiple
> > > others doing this), then the WG should document expected toolsets to
> > > be used.  Note that based on my pain here that I do have my eye on an
> > > alternative tooling after these 3 drafts complete WGLC.  If there is a
> > > lull subsequent review cycles, perhaps I will convert if my
> > > experiences with the next set of drafts work.
> > >
> > >
> > >
> > > The delta I see is “rw” vs “ro”.  Fixed now.  I have brought in the
> > > current tree.
> > >
> > > <KENT> better, but not a lasting fix
> > >
> > >
> > >
> > > <Eric2> Would the NETMOD WG be willing to put together a wiki of the
> > > development tool recommendations?  As a user, I know it would be
> > > welcomed.
> > >
> > >
> > >
> > > > Data Model
> > >
> > > >
> > >
> > > >   I going to skip this part, for now at least, as I assume the YANG
> > >
> > > >   Doctor will scrutinize it.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > Implementation Considerations
> > >
> > > >
> > >
> > > >  s/ For a deployment/To support deployments/
> > >
> > >
> > >
> > > Done
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >  s/split subscription/it is recommended to split subscription"
> > >
> > >
> > >
> > > Done
> > >
> > >  <KENT> thx
> > >
> > >
> > >
> > > >  is " unlikely" the right word?  doesn't it eliminate the concern
> > > >  altogether?
> > >
> > >
> > >
> > > Yes it does solve it.
> > >
> > >
> > >
> > > That way it eliminates the possibility of collisions if…
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >  Regarding the 2nd-half of the 1st paragraph, is it necessary for
> > >
> > > >  interoperability reasons for this draft to define how to split the
> > >
> > > >  subscription identifiers into static and dynamic parts.
> > >
> > >
> > >
> > > Not necessary, just a best practice.
> > >
> > >
> > >
> > > >   Is the
> > >
> > > >  normative text needed here?  Maybe just describe the current
> > >
> > > >  approach as a possible way to go about doing it?  - I think it
> > >
> > > >  achieves the same goal without using normative text.
> > >
> > >
> > >
> > > Agree.  Text now says:
> > >
> > >
> > >
> > > A best practice is to use lower half the "identifier" object’s integer
> > > space when that "identifier" is assigned by an external entity (such
> > > as with a configured subscription). This leaves the upper half of
> > > subscription identifiers available to be dynamically assigned by the
> > > publisher.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >  For the 2nd paragraph, this sounds like normative text from earlier
> > >
> > > >  in the document.  If so, then is it needed here again?
> > >
> > >
> > >
> > > No.  Deleted.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >  For the 3rd paragraph, I'm not sure if the second sentence needs to
> > >
> > > >  be said at all, but at least s/SHOULD/should/ so it's not normative.
> > >
> > >
> > >
> > > Made it non-normative
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > > Security Considerations
> > >
> > > >
> > >
> > > >   Regarding the 1st paragraph, aren't *all* operations (configuration
> > >
> > > >   or RPCs) always authenticated and authorized?
> > >
> > >
> > >
> > > Yes.   Deleted as redundant.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > > >   Please restructure to follow, in part, the template provided here:
> > >
> > > >   https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D20-23section-
> 2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=2
> ZAWwt38BLRzZXn66-
> kWUPEWuw26F0Uqjsvtmi_oRiQ&s=C2O9om1_tyvSQy8m-
> imWE1KOfWJk31fflmgJUDkr_cA&e=
> > 3.7.1<https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D20-
> 23section-
> > 2D3.7.1&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=
> > DoO-FEinwnsQ1xowtT-
> >
> 9KNCYTYuzNrC979exYSodTS0&s=vFecrV4fFJjob2uIQQHfofpCl8aczBrzbWdOFCE
> > hshQ&e=>
> > >
> > >
> > >
> > > Restructured to this:
> > >
> > >
> > >
> > > 5.3.  Security Considerations
> > >
> > >
> > >
> > >    The YANG module specified in this document defines a schema for data
> > >
> > >    that is designed to be accessed via network management protocols such
> > >
> > >    as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF
> layer
> > >
> > >    is the secure transport layer, and the mandatory-to-implement secure
> > >
> > >    transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
> > >
> > >    is HTTPS, and the mandatory-to-implement secure transport is TLS
> > >
> > >    [RFC5246].
> > >
> > >
> > >
> > >    The NETCONF Access Control Model (NACM) [RFC6536bis] provides the
> > >
> > >    means to restrict access for particular NETCONF or RESTCONF users to
> > >
> > >    a preconfigured subset of all available NETCONF or RESTCONF protocol
> > >
> > >    operations and content.
> > >
> > >
> > >
> > >    There are a number of data nodes defined in this YANG module that are
> > >
> > >    writable/creatable/deletable (i.e., config true, which is the
> > >
> > >    default).  These data nodes may be considered sensitive or vulnerable
> > >
> > >    in some network environments.  Write operations (e.g., edit-config)
> > >
> > >    to these data nodes without proper protection can have a negative
> > >
> > >    effect on network operations.  These are the subtrees and data nodes
> > >
> > >    and their sensitivity/vulnerability:
> > >
> > >
> > >
> > >    Container: filters
> > >
> > >
> > >
> > >    o  stream-subtree-filter: updating a filter could increase the
> > >
> > >       computational complexity of all referencing subscriptions.
> > >
> > >
> > >
> > >    o  stream-xpath-filter: updating a filter could increase the
> > >
> > >       computational complexity of all referencing subscriptions.
> > >
> > >
> > >
> > >    Container: subscriptions
> > >
> > >
> > >
> > >    o  address: can be used to attempt to send traffic to an unwilling
> > >
> > >       receiver.
> > >
> > >
> > >
> > >    o  dependency: can force important traffic to wait behind the
> > >
> > >       unimportant.
> > >
> > >
> > >
> > >    o  dscp: can send traffic with a higher priority marking that
> > >
> > >       warranted.
> > >
> > >
> > >
> > >    o  encoding: none
> > >
> > >
> > >
> > >    o  identifier: can overwrite an existing subscription configured by
> > >
> > >       another entity.
> > >
> > >
> > >
> > >    o  port: none
> > >
> > >
> > >
> > >    o  protocol: none
> > >
> > >
> > >
> > >    o  purpose: none
> > >
> > >
> > >
> > >    o  replay-start-time: can be used to push very large logs, wasting
> > >
> > >       resources.
> > >
> > >
> > >
> > >    o  source-address: address might not be able to reach a receiver.
> > >
> > >
> > >
> > >    o  source-interface: interface might not be able to reach a receiver.
> > >
> > >
> > >
> > >    o  source-vrf: can push subscribed traffic into a virtual network
> > >
> > >       which might not contain receivers able to see the subscribed
> > >
> > >       content.
> > >
> > >
> > >
> > >    o  stop-time: none
> > >
> > >
> > >
> > >    o  stream: none
> > >
> > >
> > >
> > >    o  stream-filter-ref: none
> > >
> > >
> > >
> > >    o  stream-subtree-filter: a complex filter can increase the
> > >
> > >       computational resources for this subscription.
> > >
> > >
> > >
> > >    o  stream-xpath-filter: a complex filter can increase the
> > >
> > >       computational resources for this subscription.
> > >
> > >
> > >
> > >    o  weighting: placing a large weight can overwhelm the dequeuing of
> > >
> > >       other subscriptions.
> > >
> > >
> > >
> > >    Some of the readable data nodes in this YANG module may be considered
> > >
> > >    sensitive or vulnerable in some network environments.  It is thus
> > >
> > >    important to control read access (e.g., via get, get-config, or
> > >
> > >    notification) to these data nodes.  These are the subtrees and data
> > >
> > >    nodes and their sensitivity/vulnerability:
> > >
> > >
> > >
> > >    Container: streams
> > >
> > >
> > >
> > >    o  name: if access control is not properly configured, can expose
> > >
> > >       system internals to those who should have no access to this
> > >
> > >       information.
> > >
> > >
> > >
> > >    o  replay-support: if access control is not properly configured, can
> > >
> > >       expose logs to those who should have no access.
> > >
> > >
> > >
> > >    Container: subscriptions
> > >
> > >
> > >
> > >    o  pushed-notifications: will show the amount of events a particular
> > >
> > >       subscriber actually received from a stream.
> > >
> > >
> > >
> > >    o  excluded-notifications: will show the results of access control,
> > >
> > >       and how many event records have been filtered out.
> > >
> > >
> > >
> > >    Some of the RPC operations in this YANG module may be considered
> > >
> > >    sensitive or vulnerable in some network environments.  It is thus
> > >
> > >    important to control access to these operations.  These are the
> > >
> > >    operations and their sensitivity/vulnerability:
> > >
> > >
> > >
> > >
> > >
> > >    RPC: all
> > >
> > >
> > >
> > >    o If a malicious or buggy subscriber sends an unexpectedly large
> > >    number
> > >
> > >        of RPCs, the result might be an excessive use of system resources on
> > >        the
> > >
> > >        publisher just to determine that these subscriptions should be
> > >        declined. In
> > >
> > >        such a situation, subscription interactions MAY be terminated by
> > >
> > >        terminating the transport session.
> > >
> > >
> > >
> > >    RPC: delete-subscription
> > >
> > >
> > >
> > >    o  No special considerations.
> > >
> > >
> > >
> > >    RPC: establish-subscription
> > >
> > >
> > >
> > >    o  Subscriptions could overload a publisher's resources.  For this
> > >
> > >       reason, Publishers MUST ensure that they have sufficient resources
> > >
> > >       to fulfill this request or otherwise reject the request.
> > >
> > >
> > >
> > >    RPC: kill-subscription
> > >
> > >
> > >
> > >    o  The "kill-subscription" RPC MUST be secured so that only
> > >
> > >       connections with administrative rights are able to invoke this
> > >
> > >       RPC.
> > >
> > >
> > >
> > >    RPC: modify-subscription
> > >
> > >
> > >
> > >    o  Subscriptions could overload a publisher's resources.  For this
> > >
> > >       reason, Publishers MUST ensure that they have sufficient resources
> > >
> > >       to fulfill this request or otherwise reject the request.
> > >
> > >
> > >
> > > <KENT> better, though I'm unsure the "none" nodes need to be listed.
> > >
> > >
> > >
> > >  <Eric2> The template text “These are the subtrees and data nodes and
> > >  their sensitivity/vulnerability” appears to make the list of all node
> > >  mandatory.  As this was not your intent, I pulled the “none” out.
> > >
> > >
> > >
> > > >   Regarding the 2nd and 3rd paragraphs, this sounds good, but isn't
> > >
> > > >   this behavior already defined by the draft?  (or should be?)
> > >
> > >
> > >
> > > Yes they are.  I actually refined / incorporated these points in the
> > > template above.  As this is what the template appears to be asking to
> > > have.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Regarding the 4th paragraph, why would the publisher need to the
> > >
> > > >   terminate the transport session?  wouldn't it have started to
> > >
> > > >   reject dynamic subscriptions when it became overloaded?  Or is
> > >
> > > >   this trying to say something specific about dropping the transport
> > >
> > > >   session as a club?  ;)
> > >
> > >
> > >
> > > Yes, as a club.  Moved this up into the template as part of “RFC: all”
> > > and fixed the text to show why the club might need to be used
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Re: the 5th paragraph, this is better than the 1st paragraph, but
> > >
> > > >   may not be needed if following the template.
> > >
> > >
> > >
> > > Agree.  This is redundant, and the point is covered as per the
> > > template above.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Re: the 6th paragraph, I'm surprised that requirements for transport-
> > >
> > > >   bindings wasn't discussed before in its own section.  It seems like
> > >
> > > >   a new thing here, that a receiver's transport might not be secure.
> > >
> > > >   I'm okay with and support this, btw, as its sometimes better to
> > >
> > > >   offload devices thru the use of a local collector node, for which
> > >
> > > >   encryption may not be needed...
> > >
> > >
> > >
> > > Agree with your comments.
> > >
> > > <KENT> but where's the change?  Shouldn't this have been discussed
> > >
> > > previously in the draft somewhere?
> > >
> > >
> > >
> > > <Eric2> The vast majority of transport binding discussions are
> > > addressed in the transport document.  So I see this as guidance to a
> > > documenter of a transport document.  Perhaps that is unnecessary for
> > > this document, and the paragraph should be removed.  I would be fine
> > > with that.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >   Re: the 7th paragraph, this was said before also, right?
> > >
> > >
> > >
> > > Correct, removed.
> > >
> > > <KENT> thx
> > >
> > >
> > >
> > >
> > >
> > > >   Re: 2nd to last paragraph, what is the " very-secure" tag?
> > >
> > >
> > >
> > > Removed, and the overall points moved up into template.  As for the
> > > very-secure tag, Andy had mentioned that a few years ago.  It looks
> > > like it wasn’t standardized.
> > >
> > > <KENT> gotcha
> > >
> > >
> > >
> > > <Eric2> Thanks again for your time on this.  I see these as good
> > > additions...
> > >
> > > Eric
> > >
> > > Eric
> > >
> > >
> > >
> > > /kw
> > >
> > >
> > >
> > >
> > >
> > >
>