Re: [Netconf] Subscription State Notifications

[Martin Bjorklund <[e-mail]>]

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://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-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=8SC9EE43RlHG68Oyp-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://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-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=63Abs5RCtg85f0BkF6fUWZe7vLlQ2su2BKhdVvzHdN0&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://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-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=8SC9EE43RlHG68Oyp-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://youtu.be/KJtg-J-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=8SC9EE43RlHG68Oyp-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://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-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=vFecrV4fFJjob2uIQQHfofpCl8aczBrzbWdOFCEhshQ&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
> 
> 
> 
> 
> 
>