Subject: Re: [Netconf] LC on subscribed-notifications-10

From: Kent Watsen <[email-masked]>
Date: Thu, 15 Mar 2018 01:51:38 +0000

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

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

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.

Also, in the last sentence, s/Effectively/Combined/ and s/request/request for/?

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)

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.

  s/document includes/document include/

  in the 2nd bullet, remove "statically"?  the word "static" hardly appears...

  in the 3rd bullet point: would appending "in progress" be okay?

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.

  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.

  For the "Event" term, remove the parenthesis and spell out "e.g."?

  Remove the term "NACM", since it only appears in the Security 
  Considerations section.

  For the "Notification message" term, is the beginning important?
  Maybe s/A set of transport encapsulated information/Information/?

  For the "Publisher" term, why is "Subscription" capitalized?  Is it
  (and all other terms) capitalized consistently throughout the draft?

  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.

  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.

  For the "Subscriber" term, shouldn't you have a 2nd sentence like in
  the "Receiver" term?

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

Solution Overview

  what does "instantiated" mean in the 1st paragraph.  suggest removing
  if not needed.

  in (1), s/RPC/an RPC/.  Also, is "wants" the right word, maybe "is able"?
  same with "wish" in the next sentence.  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/?

  in (2), s/a configuration interface/configuration/.  Also, replace "this
  capability" with "configured subscriptions", and maybe append "based on
  the use of a YANG feature"?

  "For connection-oriented stateful transport" : s/For/For a/ or 
  s/transport/transports/?

  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?

  Last paragraph, s/The publisher/A publisher/

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)

  The 4th bullet point isn't true (see Event Streams 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?

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?

  s/treated a distinct/treated as a distinct/

Event Stream Filters

  The 1st and 2nd sentences seems to be at odds with each other.

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?

Dynamic Subscriptions

  s/RPC/RPCs/

  Please provide more detail about how extensibility is accomplished,
  or an example showing the augmentation occurring.

  For all the subsections, should the title be s/Subscription/Dynamic Subscription/?

Dynamic Subscription State Model

  What does "asserted" mean?  - remove/replace?

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

  Only two notifications?  Looking at the graphic, how is the reader to
  distinguish these as notifications?

  The last sentence of the last bullet doesn't square with what's in the
  graphic.  is "modify-subscription" suppose to be bidirectional?

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?
  If so, then please say so.

  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.

  Are your tree diagrams dynamically-generated?  - is there any concern
  that they are out-of-date?

  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.

  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?

  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?

Replay Subscription

  Should the title being "Replaying Subscriptions", to match the verb
  tense of the other subsections?

  s/Replay puts no/Supporting replay puts no/ or /The document puts no/?

  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?

  OLD: it MAY also be earlier than the current time and MUST
  NEW: it MAY be earlier than the current time, but MUST

  "subscribers can perform a get on" - rephrase, and use "RPC" somewhere

Modifying a Subscription

  First sentence, no need for the word "previously"

  s/one or multiple times/multiple times -or- any number of times/?

  s/via RPC using/via an RPC on/?

  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.

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"

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.

  Replace the paragraph beginning with "The tree structure of" with the
  actual tree diagram for this RPC.

RPC Failures

  Please also call-out RESTCONF error handling (RFC8040 Section 7.1).

  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?

  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.  Perhaps the
  examples in that draft need to be split into examples related
  to yang-push vs examples related to subscribed-notifications.

Configured Subscriptions

  1st paragraph: s/configuration interface/configuration/g  (two cases)

  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.

  s/In addition to subscription/In addition to the subscription/
  s/as described in/described in/

  where is the tree diagram for the configuration data 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."?

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

  s/publisher evaluation/evaluation by the publisher/?

  Please move text regarding how to interpret the diagram (uppercase,
  dashed boxes, parantheses, etc.) into a preamble or postamble element.

  s/itself might itself/itself might/
  s/in no longer/is no longer/

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

  Is it "any active or suspended receivers" or "any receivers for an
  active or suspended subscription"?

  s/During any times a/When a/?

  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?

  why is "receiver" in each box?  Again, you might look to having a 
  preamble or postamble to describe the syntax used in the diagram.  

  1st paragraph below diagram: s/to connecting/to "connecting" -or- to CONNECTING/?

  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?

  This text is again difficult to reconcile with the diagram.  I again 
  recommend numbering labels and then describe the numbers below.
  
  s/ mechanisms described above is/ mechanisms described above are/
  What does this mean, how are mechanisms mirrored for RPCs and
  notifications?

  Regarding " provides an example of such an extension" - which section?

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.

  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?

Modifying a Configured Subscription

  s/ ././    ;)

Resetting a Configured Receiver

  But *how* is it reset? - via a configuration operation?  which one?
  Should this be part of "Modifying a Configured Subscription"?

Event Record Delivery

  First paragraph, last sentence.  I think I commented on similar text
  before.  Is this a requirement for the transport binding?  Do the
  netconf-notif and restconf-notif drafts satisfy this requirement? where?

  2nd paragraph: "able to traverse" --> "not blocked by"?  Also, for
  the 3rd sentence, call out the "RPC response" is for dynamic and
  "state-change notification" is for configured?

  Last two paragraphs, this text needs to be removed, 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".

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

  2nd paragraph: s/directly//

  Also, I'm unsure about the "subscription-state-notif" extension, how
  is it expected to be used by a YANG processor?  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.

subscription-started:

  Regarding the 2nd paragraph, Section 2.4.2.1 implies a contradiction
  to this statement.

  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.

  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?

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?

  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?

  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?

subscription-terminated

  1st paragraph, 1st sentence: -e a/The publisher/A publisher/ and 
  also s/the pushing of/pushing/?

  1st paragraph: "Such a decision may be made for" - should this 
  be "A publisher may terminate a subscription for" ?

  1st paragraph, for the "first type of reason": does the subscription
  terminate when the first or last referenced objects are no longer
  accessible?  BTW, what do you mean by "via the YANG model", aren't
  these instance objects in <operational>?

  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?

  The tree diagram is not identified as a tree diagram.

  last paragraph: remove "established".  Also, the first 2 sentences would
  benefit moving to singular, as plural leads to some ambiguity.

subscription-suspended

  Please replace the 2nd paragraph with the actual tree diagram, and then
  speak to that.

subscription-resumed

  The tree diagram is not identified as a tree diagram.

subscription-completed

  Please replace the 2nd paragraph with the actual tree diagram, and then
  speak to that.

replay-completed

  2nd paragraph: s/ If subscription/ If a subscription/ and s/which/that/

  Please replace the last paragraph with the actual tree diagram, and then
  speak to that.

Subscription Monitoring

  1st paragraph: s/Container/The container/.   

  How can container "subscriptions" (config true) contain entries for
  dynamic subscriptions?  Are you assuming in <operational>?  Also, 
  does it include configured subscriptions that are currently not 
  active for whatever reason?  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>...

  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.

Advertisement

  The second paragraph seems to be mostly NETCONF specific and 
  therefore belongs in the netconf-binding draft.  In a transport-
  agnostic draft, maybe only features should be discussed?

YANG Data Model Trees

  s/top level YANG Data Node containers/protocol-accessible nodes/

  " If you would rather see" - please use more formal language.

Event Streams Container

  1st paragraph, last sentence: perhaps rephrase as "This enables
  clients to discover what streams a publisher supports."?  BTW, is
  the " and against which subscription is allowed" part important,
  if so, why?

  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.

Event Stream Filters Container

  "and validated" - is this needed, since *all* configuration is validated?

  s/ which/ that/

  "referenced and used" - is there a difference?  - can you just use one?

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.

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/

 s/split subscription/it is recommended to split subscription"

 is " unlikely" the right word?  doesn't it eliminate the concern altogether?

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

 For the 2nd paragraph, this sounds like normative text from earlier
 in the document.  If so, then is it needed here again?

 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.

Security Considerations

  Regarding the 1st paragraph, aren't *all* operations (configuration
  or RPCs) always authenticated and authorized? 

  Please restructure to follow, in part, the template provided here:
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.7.1

  Regarding the 2nd and 3rd paragraphs, this sounds good, but isn't 
  this behavior already defined by the draft?  (or should be?)

  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?  ;)

  Re: the 5th paragraph, this is better than the 1st paragraph, but
  may not be needed if following the template.

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

  Re: the 7th paragraph, this was said before also, right?

  Re: 2nd to last paragraph, what is the " very-secure" tag?

Kent // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 16 Mar 2018 18:41:26 +0000

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

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

> 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

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

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

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

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

> Also, in the last sentence, s/Effectively/Combined/ and s/request/request for/?

Tweaked

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

>        Resolving these issues is the primary motivation for this work.

updated

>   s/document includes/document include/

updated

>   in the 2nd bullet, remove "statically"?  the word "static" hardly appears...

updated

>   in the 3rd bullet point: would appending "in progress" be okay?

updated

>       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT

> RECOMMENDED",

>       appear in all capitals, as shown here.

Updated

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

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

>   Considerations section.

Done

>   Maybe s/A set of transport encapsulated information/Information/?

Done.

>   (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'.

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

>   the "Event record" term.

Done.   (Re-reading, I don't think anything is lost by removing the term either.)

>   the "Receiver" term?

Added the same sentence to the receiver term.

>      [I-D.ietf-netmod-yang-tree-diagrams].

Done

>   if not needed.

It just meant "which exists".  Removed.

>   in (1), s/RPC/an RPC/.  Also, is "wants" the right word, maybe "is able"?

Made: "is able"

>   same with "wish" in the next sentence.

Made "is not able"

>  Also, in the last sentence,

>   have enabled the dynamic subscription request to be accepted/?

Updated

>   in (2), s/a configuration interface/configuration/.

Done

>  Also, replace "this

>   the use of a YANG feature"?

Made it:

Support for configured subscriptions is optional, with its availability  advertised via a YANG feature.

>   s/transport/transports/?

Chose: transports

>   restconf-event-notifications drafts do this?

Yes.   It is in non-normative text, but the flow diagrams in both drafts' appendices do this.

>   Last paragraph, s/The publisher/A publisher/

Done

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

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

>   The 4th bullet point isn't true (see Event Streams below)

****

I believe that it is true.   See discussion below.

>   it been done already?

****

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

>   s/treated a distinct/treated as a distinct/

Done

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

>   What does " MUST work identically" mean?

>   is HTTP a mandatory  transport?

>   RFC 7540 Section 5.3.3 talks about a PRIORITY frame,

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

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.

Also HTTP is not mandatory.  In fact with the text change, the reference to RFC-7950 now becomes informative rather than normative.

>   s/RPC/RPCs/

ok

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

>   For all the subsections, should the title be s/Subscription/Dynamic

> Subscription/?

Done

>   What does "asserted" mean?  - remove/replace?

Removed

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

>   Only two notifications?

Only two notifications indicate a change in the state of the 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

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

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

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

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

>   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"/>.

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

>   the netconf-notif and restconf-notif drafts?

Yes

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

>   s/Replay puts no/Supporting replay puts no/ or /The document puts no/?

Chose the " The document puts no "

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

>   NEW: it MAY be earlier than the current time, but MUST

Done

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

With that, I don't think RPC is needed.

>   First sentence, no need for the word "previously"

Done

>   s/one or multiple times/multiple times -or- any number of times/?

Chose "any number"

>   s/via RPC using/via an RPC on/?

Done

>   to look at the YANG module for details, ideally with a hyperlink.

Now done for every tree diagram in the document

>   Last paragraph, no need for the word "previously"

Done

>   then please indicate that such guidance is provided in the SC section.

Moved to Security Considerations

>   actual tree diagram for this RPC.

Done

>   Please also call-out RESTCONF error handling (RFC8040 Section 7.1).

Done

>   the MUST?

Rewrote the paragraph to:

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

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.

>   Perhaps the

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

>   1st paragraph: s/configuration interface/configuration/g  (two cases)

Done

>   other receivers.

Done.  Used your proposed text.

>   s/as described in/described in/

Done

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

>   interface towards the receiver."?

Used your text.  Done.

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

>   s/publisher evaluation/evaluation by the publisher/?

Done

>   dashed boxes, parantheses, etc.) into a preamble or postamble element.

Added underneath the diagram.  See diagram below.

>   s/in no longer/is no longer/

Done

>   to the two mentioned in the text.

Updated paragraph text as per below.  Hopefully it is clearer now.

>  The text should call out which

>   explanation for each number.

Added numbers within the diagram, and added text references as per below:

.........

: 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).

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

>   or on the receiver?

Updated the title to show it is a Publisher state model.

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

>   Again, you might look to having a

Per figure below, added the legend as a postamble:

>   1st paragraph below diagram: s/to connecting/to "connecting" -or- to

> CONNECTING/?

Now says CONNECTING.   And all receiver states moved to uppercase.

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

>   recommend numbering labels and then describe the numbers below.

Done

     .-----------------------------------------------------------------.

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

>   notifications?

Done

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

>   the other 2.5.x sections.

>   For the remainder, I think this is the

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

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

>   s/ ././    ;)

Done

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

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

>  Do the

>   netconf-notif and restconf-notif drafts satisfy this requirement?

Yes,

> where?

Netconf-notif supports interleaving of requests as described in Section 3.

Restconf-notif doesn't need to explicitly call for pipelining support as it is a basic capability of HTTP.

>   2nd paragraph: "able to traverse" --> "not blocked by"?

Done

>   Also, for

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

>   Last two paragraphs, this text needs to be removed,

removed

>   or else we might

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

Done.  (Removed the extra 'the')

>   2nd paragraph: s/directly//

Done

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

>   Perhaps a generic

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

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

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.

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.

All other replay functionality remains the same as with dynamic subscriptions as described in Section 2.4.2.1

The good news is that all of this is consistent with text is already reflected in the YANG model.

>   to look at the YANG module for details, ideally with a hyperlink.

Done

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

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

>   rephrase these?

Made a numbered list

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

>   also s/the pushing of/pushing/?

Done

>   be "A publisher may terminate a subscription for" ?

Done

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

>   identityref in the tree diagram?

Text attempted just above.

>   The tree diagram is not identified as a tree diagram.

Done

>   benefit moving to singular, as plural leads to some ambiguity.

Done.

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.

>   speak to that.

Done

   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

>   The tree diagram is not identified as a tree diagram.

Updated.  As are all other tree diagrams now.

>   speak to that.

Updated.  As are all other tree diagrams now.

>   2nd paragraph: s/ If subscription/ If a subscription/ and s/which/that/

Done

>   speak to that.

Done as identical to above.

>   1st paragraph: s/Container/The container/.

Done.

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

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

>   Also,

>   active for whatever reason?

Yes.   First paragraph above uses the word 'all'.

>   You mention NETCONF's <get> (wait, I

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

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

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

>   In a transport-

>   agnostic draft, maybe only features should be discussed?

Makes sense

>   s/top level YANG Data Node containers/protocol-accessible nodes/

Done

>   " If you would rather see" - please use more formal language.

Made it:

For tree diagrams of state change notifications,

>   clients to discover what streams a publisher supports."?

Done

>  BTW, is

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

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

>   "and validated" - is this needed, since *all* configuration is validated?

Removed

>   s/ which/ that/

Done

>   "referenced and used" - is there a difference?  - can you just use one?

Now just referenced

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

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

The delta I see is "rw" vs "ro".  Fixed now.   I have brought in the current tree.

>  s/ For a deployment/To support deployments/

Done

>  s/split subscription/it is recommended to split subscription"

Done

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

>  subscription identifiers into static and dynamic parts.

Not necessary, just a best practice.

>   Is the

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

>  in the document.  If so, then is it needed here again?

No.  Deleted.

>  be said at all, but at least s/SHOULD/should/ so it's not normative.

Made it non-normative

>   or RPCs) always authenticated and authorized?

Yes.   Deleted as redundant.

>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.7.1

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.

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

>   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

>   may not be needed if following the template.

Agree.  This is redundant, and the point is covered as per the template above.

>   encryption may not be needed...

Agree with your comments.

>   Re: the 7th paragraph, this was said before also, right?

Correct, removed.

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

Eric

> _______________________________________________

> Netconf mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Alexander Clemm" <[email-masked]>
Date: Sun, 18 Mar 2018 02:53:56 -0700

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 <[email-masked]> On Behalf Of Eric Voit (evoit)
Sent: Friday, March 16, 2018 11:41 AM
To: Kent Watsen <[email-masked]>; [email-masked]
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-subs
cribed-notifications-11.txt 

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

Will do

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

Tweaked

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

updated

updated

updated

updated

Updated

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.

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.

Done

Done.

>   (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'.

****

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:  

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>

>   the "Event record" term.

Done.   (Re-reading, I don't think anything is lost by removing the term
either.)

Done

Made: "is able"

Made "is not able"

Updated

Done

Made it:

Support for configured subscriptions is optional, with its availability
advertised via a YANG feature.

Chose: transports

>   restconf-event-notifications drafts do this?

Yes.   It is in non-normative text, but the flow diagrams in both drafts'
appendices do this.

Done

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

a publisher MAY implement both the Notification Management Schema and RPCs
defined in [RFC5277] and this new document concurrently,...

****

****

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

Done

****

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.

****

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.

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.

Also HTTP is not mandatory.  In fact with the text change, the reference to
RFC-7950 now becomes informative rather than normative.

ok

****

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.

Done

Removed

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

>   distinguish these as notifications?

Added a * to the two notifications, and text at the bottom of the drawing
which says:

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.

Yes

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

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

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

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"/>.

****

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:

and

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>

Yes

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

****

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.

Done

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.

Done

Chose "any number"

Done

Done

>   actual tree diagram for this RPC..

Done

Done

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

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

To see a NETCONF based example of an error response from above, see
[I-D.draft-ietf-netconf-netconf-event-notifications], Figure 10.

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

Done

Done

 

****

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?

>   parsing the implicit parentheses..  Next, the last sentence seems

Used your text.  Done.

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.

Done

Done

>   to the two mentioned in the text..  

.........

: start :-.   

:.......: | 

     create  .---modify-----..----------------------------------.

          |  |              |                                  |         

 |        ^          |      |                |                 |        

 |        |                 |                |                 |        

 |       (1)               (2)              (3)               (4)

'-->|                         VALID                                 |

Legend:

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

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

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

****

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

Done

     |                         VALID                                   |

     |   .----------.                           ..--------.             |

     |      (1)          |         |                                   |

     |  subscription-   (3)        |                                   |

  Legend: 

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

Done

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

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.  

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

Done

Added the sentence:

This is accomplished via the "reset" action within the YANG model at
"/subscriptions/subscription/receivers/receiver/reset".

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

Yes, 

Restconf-notif doesn't need to explicitly call for pipelining support as it
is a basic capability of HTTP.

Done

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.

removed

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

Done

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

****

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

****

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

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:

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.  

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.

All other replay functionality remains the same as with dynamic
subscriptions as described in Section 2.4.2.1

The good news is that all of this is consistent with text is already
reflected in the YANG model.

Done

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

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

Made a numbered list

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.

Done

Done

>   accessible?

This refers to any either any leafref going missing, or the subscription-id
being removed.  More in next comment

>   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

       subscription".

       by "filter-unavailable".

Each of the reasons above correspond one-to-one with a "reason" identityref
specified within the YANG model.

Done

Done.

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.

Done

   within Section 4.

          +--ro reason        identityref

>   The tree diagram is not identified as a tree diagram.

Updated.  As are all other tree diagrams now..

>   speak to that.

Updated.  As are all other tree diagrams now..

Done

Done.

In the operational datastore, the container "subscriptions" maintains the
state of all known subscriptions.

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

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

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

Makes sense

Done

Made it:

Done

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

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

Removed

Done

Now just referenced

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

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

The delta I see is "rw" vs "ro".  Fixed now.   I have brought in the current
tree.

Done

Done

Yes it does solve it.

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.

No.  Deleted.

Made it non-normative

<https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.7.1>
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.7.1

Restructured to this:

 

   Container: filters

 
   Container: subscriptions

 
 
   o  encoding: none

   o  port: none
 
   o  protocol: none
 
   o  purpose: none

 

   o  stop-time: none
 
   o  stream: none

 

 
   Container: streams

 
   Container: subscriptions

 

   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

 
 
   RPC: kill-subscription

   RPC: modify-subscription

 

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

>   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

>   may not be needed if following the template.

Agree.  This is redundant, and the point is covered as per the template
above.

Correct, removed. 

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

Eric

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/netconf>