Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 1 Dec 2017 15:50:55 +0000

Hi Rohit,

From: Rohit R Ranade, November 30, 2017 11:07 PM

Hi Eric,

In your case , then there is a corner case where in if the dampening period is short, the device may have still not finished sending all its notification fragments and the next update record is already ready to get assembled.

<Eric> Yes, this corner case is common across all solutions, including periodic subscriptions.   (E.g., What if a routing table gets bigger all of a sudden?  What if a key publisher process is taking lots of CPU?)   The question is what is the level of exposure the admission control process permits.

Whether we can have a lower limit on the dampening period interval to avoid such a scenario ?

<Eric> Yes, a lower limit on the dampening period is a potential way to approach this.  But I believe there to be a few issues:

·        The maximum latency in seeing a change (as determined by when a push-change-update is assembled) would not be deterministic to applications.  This possibility would have to be accounted for when designing application behavior.

·        It would not be easy for a receiver application to distinguish when dampening periods are degrading longer and longer.  And this will likely be due to CPU/other impacts on the publisher which are invisible to the receiver.

·        A periodic subscription might also have the delayed assembly problem, and we can’t delay those updates.  So the any solution approach for both on-change & periodic couldn’t be common between the two.

·        A longer and longer assembly window makes it harder to ensure the included patch operations all can be tagged with the same time-of-update.

There are currently mechanisms in the solution to deal with the corner case.

·        “updates-not-sent flag”, which has the same meaning for both push-updates and push-change-updates.  (And which would still be needed if we made the dampening  period a lower limit.)

·        Suspending a subscription with the “datatree-size” identified as an issue (also the same for periodic & on-change)

·        The resynch RPC, which can be invoked as needed.

So as there are interesting aspects to your “lower limit” proposal, but it has unexplored impacts from the point of view of expected behavior as seen by applications, my recommendation would be to look at this as possible follow-on work.

Thanks,
Eric

With Regards,
Rohit R

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: 30 November 2017 20:32
To: Rohit R Ranade <[email-masked]<mailto:[email-masked]>>; Alexander Clemm <[email-masked]<mailto:[email-masked]>>; Andy Bierman <[email-masked]<mailto:[email-masked]>>; Martin Bjorklund <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Randy Presuhn <[email-masked]<mailto:[email-masked]>>
Cc: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Netconf] review of draft-ietf-netconf-yang-push-11

Hi Randy,
Hi Rohit,
Hi Alex,

Thanks for the thoughts.

Randy, on your point: it is true previous wording of the YANG description can be tightened up.  And your paraphrasing for the YANG description provided good guidance.  Below I give an attempt reframing yang description, also taking into account Alex & Rohit’s comments...

YANG Description

Specifies the minimum interval between the assembly of successive update records for a single receiver of a subscription. Whenever subscribed objects change, and a dampening period interval (which may be zero) has elapsed since the previous update record creation for a receiver, then any subscribed objects and properties which have changed since the previous update record will have their current values marshalled and placed into a new update record.

Rohit, on your point: to cover any such a possibility, it might be better to reset the dampening period after a specific update record is assembled.   This way any bundling of updates into notification messages, or fragmentation delays won’t result in an irregular or unpredictable dampening period.   Look below at my attempt to frame this within Section 3.10 text...

Alex, on your point: yes we need to be explicit about just the last value being sent.  I tweak it into the description in the 3.10 below.  I think I also covered in it the YANG description above...

Section 3.10

Dampening period: In an on-change subscription, detected object changes should be sent as quickly as possible.  However it may be undesirable to send a rapid series of object changes.  Such behavior has the potential to exhaust of resources in the publisher or receiver.  In order to protect against that, a dampening period MAY be used to specify the interval which must pass before successive update records for the same subscription are generated for a receiver.  The dampening period collectively applies to the set of all data nodes selected by a single subscription and sent to a single receiver.  This means that when there is a change to one or more subscribed objects, an update record containing those objects is created either immediately when no dampening period is in effect, or at the end of a dampening period.  If multiple changes to a single object occur during a dampening period, only the value that is in effect is included as part of the update record.  A dampening period is reset every time an update record has completed its assembly.

Eric

From: Rohit R Ranade, November 30, 2017 1:30 AM
Hi Eric,

We need also consider that commit maybe very big or in the dampening time so many records are updated that the <notification> message may need to be split across fragments.  I suggest reframing of the sentence to

“A dampening period is reset every time the last fragment of a new notification message is passed to transport”

With Regards,
Rohit R

From: Netconf [mailto:[email-masked]] On Behalf Of Alexander Clemm
Sent: 30 November 2017 06:29
To: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>; Andy Bierman <[email-masked]<mailto:[email-masked]>>; Martin Bjorklund <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11

This works for me.  Perhaps one additional item we might add (for crystal-clear clarification) is that when the notification message is sent, it contains the most recent update for that object (i.e. the value that is in effect when the update is sent).  If there are some quickly oscillating values we don’t send the whole sequence of updates/values.

--- Alex

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Wednesday, November 29, 2017 4:51 PM
To: Alexander Clemm <[email-masked]<mailto:[email-masked]>>; Andy Bierman <[email-masked]<mailto:[email-masked]>>; Martin Bjorklund <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Netconf] review of draft-ietf-netconf-yang-push-11

The Section 3.1 text I proposed in my response to Martin on the dampening question:

Dampening period: In an on-change subscription, detected object changes should be sent as quickly as possible.  However without adequate protections, a rapid series of object changes might exhaust of resources in the publisher or receiver.  In order to protect against that, a dampening period MAY be used to specify the interval which must pass before successive update records for the same subscription are generated for a receiver.  The dampening period collectively applies to the set of all data nodes selected by a single subscription and sent to a single receiver.  This means that when there is a change to a subscribed object, an update record containing that object is created either immediately when no dampening period is in effect, or at the end of a dampening period.  A dampening period is reset every time a new notification message is passed to transport.

With the YANG description of:

"Specifies the interval which must pass before successive update records for the same subscription are generated for a receiver.  The dampening period collectively applies to the set of all data nodes selected by a single subscription and sent to a single receiver.  This means that when there is a change to a subscribed object, an update record containing that object is created either immediately when no dampening period is in effect, or at the end of a dampening period.  A dampening period is reset every time a new notification message is passed to transport.  A dampening period is reset every time a new notification message is passed to transport.  A zero value indicates no dampening period, and all subscribed object changes are sent immediately."

Does this work for everyone?

Eric

From: Netconf [mailto:[email-masked]] On Behalf Of Alexander Clemm
Sent: Wednesday, November 29, 2017 3:17 PM
To: Andy Bierman <[email-masked]<mailto:[email-masked]>>; Martin Bjorklund <[email-masked]<mailto:[email-masked]>>
Cc: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11

I thought we decided that we have combined dampening for all objects in the subscription.  In this case, we would send updates at 2, 12 (containing 3,4,11), and 22 (containing 13, 14, 15).

If the scope of the subscription becomes sufficiently large, this almost reverts back to a periodic subscription (since there is always going to be a change somewhere).  This is why I originally argued to have it indeed on a per-object basis, but I lost that argument.  For such fine-grained updates, where a client is indeed interest in getting delays of individual objects without delay,  a client could simply need to establish multiple “micro” subscriptions.

TCAs in RMON are something different altogether.  This is something we are trying to address with smart filters.

--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Wednesday, November 29, 2017 10:18 AM
To: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>
Cc: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11

On Tue, Nov 28, 2017 at 1:37 AM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

....

o  3.1

  I'm not sure I understand the dampening period concept.  Let's
  assume that the dampening period is 10s.  Then changes happen at
  times:

    2  3  4  11  13  14  15

  From the description, it seems I would receive 4 notifications, from
  times:

    2  (containing only change from 2)
    12 (containing change from 3,4,11)
    13 (containing only change from 13)
    23 (containing changes from 14,15)

  Is this correct?

  In any case, I suggest the description in the YANG module is
  clarified - currently the RFC text contains more details than the
  YANG module.

Seems to me (from a client POV) that I want the dampening to apply
to the entire subscription, not to each node within the subscription.
I want "at most, 1 notification per second".  I don't see why I would want
to be told about an individual data node once per second.  I could still
get 10,000 events/sec but for different data nodes.  The receiver does not
really care whet nodes are being reported in each notification. The goal
is to simply limit the network and processor load.

From a server POV, I do not want a timer on every data node instance
and complex code to construct the next on-change notification.

RMON handles dampening very differently.
The rising and falling thresholds are used to arm and re-arm an event trigger.
The time between changes is not used at all to determine how many events to send.
(Not suggesting all yang-push use-cases are threshold-based.)

IMO, the operator should put events that require low-latency into a separate subscription,
and the dampening period should apply to the entire subscription.

 ...

/martin

Andy

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Dec 2017 12:40:01 +0100 (CET)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> Hi Martin,
> 
> Thanks for the comments.   Many thoughts in-line...
> 
> > From: Martin Bjorklund, November 28, 2017 4:38 AM
> > 
> > Hi,
> > 
> > 
> > I have now reviewed draft-ietf-netconf-yang-push-11.  I have one
> > somewhat
> > more important comment, and several others.
> > 
> > Important issue:
> > 
> > o  3.10
> > 
> >   I don't think the proposed YANG extension is the correct solution to
> >   the stated problem, for several reasons:
> 
> In general we agree there are several alternatives to solve this
> issue.  And any mechanism supported by the WG would be fine.
> 
> My read of your proposal below is that it does reuse elements of 3.10.
> For example, I *think* you are proposing hierarchical inheritance of
> on-change property markings of the parent rather than making every
> instance.

Yes.

> Because marking every instance within a routing table would
> be prohibitively expensive.  So based on whatever commonality we can
> establish across the proposed alternatives, perhaps we can come to a
> common way to set this information.  If not, we can back out on-change
> marking as something implementation-specific for this current
> specification.
> 
> Stepping back a minute, it is good to think about who would use this
> on-change support data.  Application developers are going to make
> subscription requests.  And they are far more likely to want to design
> based on the schema level information exposed rather than instance
> data.

Agreed.  See also my reply to Alex.

> Driven by that constraint, the current proposal is framed as is
> -- mostly since there was no interest in Balazs'
> https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-00
> which was designed to support application developers needing this
> information.  Without this draft, at the time this was proposed the
> next-best thing was an extension which works based on the established
> pattern of deviations.
> 
> To cover this issue, I have re-opened YP#10 to track and resolve...
> https://github.com/netconf-wg/yang-push/issues/10 
> 
> Below are some specific pros/cons I see...
> 
> >     1.  In most cases, this is not a property of the data model, but
> >         of the implementation, and possibly even the deployment.  So
> >         having a YANG extension statement is not a good solution.
> 
> Fully agree this can be implementation level issue.  But then again,
> so is any deviation.
> 
> So to cover "property of the implementation" case, the proposed
> extension would typically be included in deviations file per
> implementation.  Such an approach does mirror existing mechanisms for
> deviations, and has the benefit of not requiring another a new totally
> separate file to document the desired behavior.
> 
> As for times this might be deployment specific, we saw potential
> capacity issues determining whether something might not be on-change
> subscribable.  Here it would be up to the implementation to determine
> whether to use the error "on-change-unsupported" from YANG Push, or
> the error "insufficient-resources" from subscribed notifications.  A
> choice between the two can be driven based on whether a deployment
> would *ever* have capacity for the requested subscription.
> 
> >     2.  With NDMA, the same schema node is present in different
> >         datastores.  It might be the case that an implementation
> >         supports on-change for the node in a configuration datastore,
> >         but not in operational.  Again, marking a node in the schema
> >         is not a good solution.
> 
> As the current solution was developed before NMDA, we didn't consider
> differences in on-change support for different datastores.  So this is
> a real consideration.
> 
> If for a minute we assume we are going to follow the current approach
> in the draft, the extension proposed in 3.10 could have a default of
> the operational datastore.  And we could add the option of including a
> list of datastores in the extension whenever on-change for something
> else is needed/supported..
> 
> >     3.  Since the on-change property is implementation dependent, it
> >         means the information will be available to clients only in
> >         deviation modules.  This is quite an expensive and complicated
> >         way to pass the information to the clients.
> 
> Visibility to application developers was one reason we went down this
> path.  Any solution needs to frame this visibility as a key element.
> Considering this, I actually see a need both for the schema based
> solution as framed, and the possibility of an instance based mechanism
> if someone wanted the lower level of granularity.  Per above, I don't
> think instance data within all instance objects like routing entries
> is possible anyplace datastore size becomes a factor.
> 
> >   An alternative solution could be to have an ordered list of
> >   instance-identifiers that list this property, per datastore, for
> >   example:
> > 
> >    <entry>
> >      <path>/sys:system/sys:system-time<path>
> >      <notifiable-on-change>false</notifiable-on-change>
> >    </entry>
> >    <entry>
> >      <path>/sys:system<path>
> >      <notifiable-on-change>true</notifiable-on-change>
> >    </entry>
> 
> This could work.  Several questions which would need to be addressed
> with this approach:
> 
> (1) how would application developers easily know what objects are
> on-change subscribable?
> 
> (2) If this is per-instance, is the property inherited from a parent?
> If no, how do we deal with the size of the resulting information?
> 
> (3) If this is per-instance, how is this information populated?  Don't
> you need schema level guidance recorded somewhere anyway?
> 
> (4) Are there any issues with things like Schema mount?
> 
> >   Yet another alternative would be to leave this to future work.
> 
> If necessary, we can push this out.  I am hoping we can come up with
> something here, especially as the on-chance implementations I have
> seen have all used phased introduction of on-change for different
> schema objects.
> 
> > Other comments:
> > 
> > 
> > o  2
> > 
> >   The document uses the term "YANG datastore" (it is even in the title
> >   of the document).  This term is not used elsewhere, and it is not
> >   defined in this document.  I suggest you change this to simply
> >   "datastore".
> 
> In general, I am fine with making the change to "Datastore" throughout
> the document.

Ok.

> For the title, I think it better to keep YANG to allow
> casual readers easy access to the context.
> 
> >   Also, I think you should "import" the term "datastore" from
> >   draft-ietf-netmod-revised-datastores, instead of having a slightly
> >   different term in this document.
> 
> Can do.

Ok.

> >   It is also unfortunate that you use the term "data node" in a
> >   different meaning than RFC 7950.  Maybe use "datastore node"
> >   instead?
> 
> Can do.

Ok.

> Should be 2, 12, & 22.  I have updated the definition (below) in a way
> which hopefully clarifies the proper behavior
> 
>          + Dampening period: In an on-change subscription, detected object
>          changes should be sent as quickly as possible.  However without
>          adequate protections, a rapid series of object changes might exhaust
>          of resources in the publisher or receiver.  In order to protect
>          against that, a dampening period MAY be used to specify the interval
>          which must pass before successive update records for the same
>          subscription are generated for a receiver.  The dampening period
>          collectively applies to the set of all data nodes selected by a
>          single subscription and sent to a single receiver.  This means that
>          when there is a change to a subscribed object, an update record
>          containing that object is created either immediately when no
>          dampening period is in effect, or at the end of a dampening period.
>          A dampening period is reset every time a new notification message is
>          passed to transport.

I understand what you want to achieve, but I don't think the text is
quite correct.  I'll think about this some more to see if I can come
up with a better wording.

> I have updated the YANG module text as:
> 
> "Specifies the interval which must pass before successive update
> records for the same subscription are generated for a receiver.  The
> dampening period collectively applies to the set of all data nodes
> selected by a single subscription and sent to a single receiver.  This
> means that when there is a change to a subscribed object, an update
> record containing that object is created either immediately when no
> dampening period is in effect, or at the end of a dampening period.  A
> dampening period is reset every time a new notification message is
> passed to transport.  A dampening period is reset every time a new
> notification message is passed to transport.

This last sentence occurs twice.

> A zero value indicates
> no dampening period, and all subscribed object changes are sent
> immediately."
> 
> > o  3.2
> > 
> >   The text says:
> > 
> >      Therefore, in order to minimize the number of subscription
> >      iterations between subscriber and publisher, dynamic
> >      subscriptions SHOULD support a simple negotiation between
> >      subscribers and publishers for subscription parameters.
> > 
> >   To whom is this "SHOULD" directed?  I mean, dynamic subscriptions as
> >   specified in this draft does indeed support simple "negotiation".
> >   Maybe s/SHOULD support/supports/ ?
> 
> Yes.  Will remove the SHOULD, showing just "supports".
> 
> > o  3.4
> > 
> >   The text says:
> > 
> >     Please see [promise] for
> >     more on the transactional basis underlying the publisher and
> >     subscriber interactions within this document.
> > 
> >   So I did that.  But I didn't find any text in the referenced
> >   document that talked about "the transactional basis".
> > 
> >   I suggest you remove this sentence from the draft.
> 
> As this is informative, I can remove.  

Ok.

> > o  3.5
> > 
> >   The text says:
> > 
> >      A publisher MUST support XML encoding and MAY support other
> >      encodings such as JSON encoding.
> > 
> >   I don't think this is correct.  A RESTCONF sever is not required to
> >   support XML.  I think you should remove this sentence.
> 
> ok
> 
> > o  3.5.1
> > 
> >      In a periodic subscription, the data included as part of an update
> >      corresponds to data that could have been simply retrieved using a get
> >      operation and is encoded in the same way.
> > 
> >   What is "a get operation"?  Do you mean RESTCONF GET or NETCONF
> >   <get/> or something else?  Whatabout other protocols?
> 
> As YANG Push is intended to be transport independent, it is better not
> to provide a specific transport.  Instead, how about the following
> text:
> 
> In a periodic subscription, the update record MUST include the
> datastore nodes which would have been retrieved using an equivalent
> datastore selection operation over that subscription's transport.

Or maybe

   In a periodic subscription, the data included as part of an update
   corresponds to data that could have been read using a retrieval
   operation over that subscription's transport.

(no need for MUST here)

> >   (In 3.6, you use simply "a GET" for probably the same thing.)
> 
> If you are good with the text above, I will change 3.6 to:
> 
> " to what is available with a datastore selection operations".

Hmm, that paragraph is:

   It is not expected that implementations will support comprehensive
   filter syntax and boundless complexity.  It will be up to
   implementations to describe what is viable, but the goal is to
   provide equivalent capabilities to what is available with a GET.

What is a "comprehensive filter syntax"?  Maybe this paragraph can be
removed.

> > o  3.6
> > 
> >      Subscription policy specifies both the selection filters and the
> >      datastores against which these selection filters will be applied.
> >      The result is the push of information necessary to remotely maintain
> >      an extract of the publisher's datastore.
> >
> >   It seems this paragraph defines the term "Subscription policy".  But
> >   this term is not used in the document. 
> 
> We don't intend to define a new term in this paragraph.  And you are
> correct, policy only appears elsewhere in the document as part of the
> YANG model group names.  (more below)
> 
> >  What does it means that the result of a policy is "the push of
> >  information"?
> > 
> >   I think I don't understand what this paragraph tries to tell me.
> 
> What if I changes the first paragraph of Section 3.6 to:
> 
> An objective of YANG push is to allow the replication of a subset of a
> publisher's datastore within a receiver.  The datastore selection
> filter defines this subset.  Only a single selection filter can be
> applied to a subscription at a time.  The selection filter types
> defined in this include:

My problem with this style is that it seems to indicate that the
selection filter is only used for this use case ("replication of a
subset..."), but that would be a mistake.  I think you should explain
what these filters are first, and then (maybe) give examples of how
they can be used.

The title "Datastore selection filter" is also misleading; in fact the
best solution might be to keep the original text but change the title
of the section to "Subscription Policy".

> > o  3.6
> > 
> >      o  xpath: An xpath selection filter is an XPath expression which may
> >         be meaningfully applied to a datastore.
> > 
> >    What does "meaningfully applied" mean?
> 
> There are plenty of valid xpath expressions which don't select data
> nodes.  How about:
> 
> " xpath: An xpath selection filter is an XPath expression which
> references data nodes. When applied to a datastore, it is the results
> of this expression which will be pushed."

The text for subtree filters use the words "When specified, updates
will only come from the data nodes of selected YANG subtree(s)."  If
you use the same words here, the text is consistent and easier to
understand.  Maybe:

NEW:

  o  xpath: An xpath selection filter is an XPath expression that
     returns a node set. When specified, updates will only come from
     the selected data nodes.

> > o  3.6
> > 
> >      Selection filters are not intended to be used to filter objects
> >      based on a non-key property.  Supporting non-key property
> >      filtering so would have a number of implications that would
> >      result in significant complexity.
> > 
> >      [...]
> > 
> >      the goal is to
> >      provide equivalent capabilities to what is available with a GET.
> > 
> >   In GET you can filter on "non-key properties".
> > 
> >   I think you should remove the text about "non-key properties".  If
> >   anything, I think you can allow an implementation to reject a filter
> >   that would be too complex to implement / evaluate (in fact I think
> >   the text already allows a server to reject such filters.)
> 
> The issue with non-key properties is how to deal with the creation and
> deletion of objects when a non-key property goes in/out of the
> selection.  Others were uncomfortable with things like passing along a
> patch showing a node was deleted, when in reality the property simply
> changed from meeting the selection filter to failing the selection
> filter.  So people wanted to default to the simpler case of key
> properties for selection.

But you are constraining the entire solution to support just this use
case, when a simpler unconstrained solution just as easily supports
this use case, *plus other use cases* - if a client does not want
these "fake deletes", they can simply construct filters based on keys
only, which they would in the current solution anyway.

Note also that b/c of the last paragraph in section 3.9, a client must
deal with such deletes anyway, even if it specificied only keys.

But I do understand your point.  This is also related to my comment
below about when a filter is evaluated.  Based on you reply to that
comment, I think the conceptual algorithm is like this:

  Just before a change, evaluate the filter and any access control
  rules.  The result is a set "A" of nodes (including subnodes).

  Just after a change, evaluate the filter and any (possibly new)
  access control rules.  The result is a set "B" of nodes (including
  subnodes).

  Construct a YANG patch record for going from A to B.   If the record
  is non-empty, send it to the subscriber.

(this is conceptual, an implementation can do lots of optimizations to
avoid evaluating filters on un-related changes)

> Based on that I can delete the words "but the goal is to provide
> equivalent capabilities to what is available with a GET".
> 
> >   With the current text, is this filter ok:
> > 
> >      /interfaces/interface[contains(name, "eth")]
> > 
> >   It filters on a key, so it should be ok, right?
> 
> Yes

What about this one:

   /interfaces/interface[contains(name, //name)]

it also filters on a key is it ok?

[if the answer is "yes" we have a problem; and if it is "no", we
need to tighten the text]

All this makes me wonder if it is correct to have "subtree" and
"xpath" filters at all.  If they only can match on keys, they become
severely constrained.

An alternative could be to specify filters as
"nacm:node-instance-identifier" instead; these are
instance-identitifiers that allow missing keys.  For example:

  /if:interfaces/if:interface/if:oper-status

This would be easier to understand and probably easier to optimize for
in the server code.

> > o  3.7
> > 
> >   The XML examples are not using the correct XML namespace for the
> >   nodes from the "ietf-interface" module.
> > 
> >   The YANG Patch example also shows an interesting effect in the
> >   "patch-id" and "edit-id" leafs.  I think the draft should mention
> >   how implementations are suppose to fill in these leafs.
> 
> Will add how to populate.  In summary, sequential numbering of
> "edit-id" was from the RFC-8072.  And a null "patch-id" is because
> patch-id is mandatory in RFC-8072, and was originally supposed to be
> used for debugging of failed datastore write operations.

Maybe "patch-id" could be a sequential number, starting from 1 when
the first patch is sent?  Or simply any string that the server finds
appropriate.  In any case, "null" looks odd in the example.

> That really
> isn't the case here, plus we have subscription-id and other object
> available.
> 
> >   The "target" leaf is not specified correctly.  It should be:
> > 
> >          <target>/ietf-interfaces:interfaces-state</target>
> 
> Good catch.  Making change.
> 
> > o  3.8
> > 
> >   The example has:
> > 
> >    <establish-subscription
> >        xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
> >        xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
> >       <yp:datastore>
> >         <yp:source xmlns="urn:ietf:params:xml:ns:yang:ietf-datastores">
> > 
> >   This doesn't match the YANG model; there is no container called
> >   "datastore" in the model.
> > 
> >   Further is has:
> > 
> >         <yp:subtree-filter netconf:type="xpath"
> >             xmlns:ex="http://example.com/sample-data/1.0"
> >             select="/ex:foo"/>
> > 
> >   a subtree-filter of type xpath?  I think ot should be:
> > 
> >         <yp:xpath-filter xmlns:ex="http://example.com/sample-data/1.0">
> >            /ex:foo
> >         </yp:xpath-filter>
> 
> Yes
> 
> >   Also, it has:
> > 
> >         <yp:source xmlns="urn:ietf:params:xml:ns:yang:ietf-datastores">
> >           operational
> >         </yp:source>
> > 
> >   which should be:
> > 
> >         <yp:source xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
> >           ds:operational
> >         </yp:source>
> 
> At the last IETF, Kent pointed us to YANG Lint which should allow us
> to do example checking in ways not previously known to us.  I will
> install and attempt to use these to clear the example items you have
> listed.
> 
> > o  3.9
> > 
> >   This section lists three cases for which:
> > 
> >      the error identity "data-unavailable" SHOULD be returned.
> > 
> >   One of the cases is:
> > 
> >     o  the authorization privileges of a receiver change over the course
> >        of the subscription.
> > 
> >   But how can a server know this when "establish-subscription" is sent?
> 
> It cannot know this at "establish-subscription".  So a publisher will
> have to track whether the permissions on subscribed objects change.
> How is left to implementations.

Ok, but the error code is used as a return value for
"establish-subscription".  So if a server can't detect it at
"establish-subscription" it mean it will never be used.  Hence I
suggest you remove the text about "authorization privileges".

BTW, does this imply that I cannot create a filter for a currently
non-existing interface?   If this is true, my conceptual filter
evaluation algorithm above is not correct...

> > o  3.9
> > 
> >      The contextual authorization model for data in YANG datastores is
> >      the NETCONF Access Control Model [RFC6536bis], Section 3.2.4.
> > 
> >   Did you mean s/contextual/conceptual/ ?
> 
> Will make that change.
> 
> > o  3.11.1
> > 
> > 
> >   OLD:
> > 
> >        If
> >        this is not possible and the synch-on-start option is configured,
> > 
> >   NEW:
> > 
> >        If
> >        this is not possible and the "no-synch-on-start" option is not
> >        present for the subscription.
> > 
> > 
> >   (fixes incorrect name of leaf, and also covers dynamic
> >   subscriptions)
> 
> Yes, good catch.  Will fix.
> 
> > o  4.3.2
> > 
> >      A subscription-id MUST be transported along with the subscribed
> >      contents.
> > 
> >   Then the leaf "subscription-id" should be mandatory.
> 
> The requirement is that a subscription-id must be in the notification
> message, this doesn't mean that the subscription-id must be within the
> two new notifications.  The reason for this is that when we add
> support for the notification-messages draft, but having the
> subscription-id optional in the push-update and push-change-update, we
> can enable implementations which do not duplicate this header item.
> (And a duplication would be forced with the future header if we made
> this mandatory.)

Aha, ok.  But then it looks really weird to have "scubscription-id"
in the notifications defined in this module.  It will be redundant.

Or do you suggest that *all* YANG modules that publish notifications
must have a leaf "subscription-id", until the notification header
document is done?  If not, why is this document special?

> >      A "time-of-update" which represents the time an update record
> >      snapshot was generated.  A receiver MAY assume that a publisher's
> >      objects have these pushed values at this point in time.
> > 
> >   Should "time-of-update" be mandatory?
> 
> Two reasons it is not:
> (a) Other vendors have worried they can only support message-time,
> rather than notification-time.
> (b) Notification-time is the generalized name for "time-of-update" .
> Having "time-of-update" as optional allows for eventual migration to
> common headers of draft-ietf-netconf-notification-messages without
> information duplication
> 
> >   How is "time-of-update" different from "eventTime" in the
> >   notification?
> 
> I think that answer is above.  But there is some good guidance here
> from draft-ietf-netconf-notification-messages.  The new draft
> ultimately will define and support the following times:
> 
> message-time: 
>       "Header information consisting of time the message headers were placed
>       generated prior to being sent to transport";
> 
> notification-time
>       "Header information consisting of the time an originating process
>       created the notification."
> 
> Notification-time should be equivalent to eventTime from RFC-5277.

Ok.  So this means that when we have these new headers,
"time-of-update" is no longer needed, right?

But actually, currently we have "eventTime".  And since
"notification-time" is equivalent to "eventTime", and "time-of-update"
is "notification-time", it follows that "time-of-update" is redundant
and not needed today either.  Correct?

> But some other vendors have said they really only have message-time,
> and this is what they are populating in eventTime even though it
> doesn't explicitly fit the definition.  With the new definitions, at
> least they should be able to populate what they explicitly have.
> 
> > o  4.3.2
> > 
> >      If the application detects an informational discontinuity
> > 
> >   What is an "informational discontinuity"?
> 
> Will change to:
>   If the application detects any incompleteness in set of objects placed
>   into a "push-update" or "push-change-update"

I suggest you remove the sentence instead, and some more redundant
words to get:

OLD:

   An "updates-not-sent" object, which indicates that the update record
   is incomplete.  If the application detects an informational
   discontinuity in either notification, the notification message MUST
   include "updates-not-sent".  This object indicates that not all
   changes which have occurred since the last update are actually
   included with this update.

NEW:

   An "updates-not-sent" object.  This object indicates that not all
   changes which have occurred since the last update are actually
   included with this update.

> > o  4.4.1 / 4.4.2
> > 
> >   The XML examples are broken; compare with my comments for 3.8.
> 
> Will do.  I am hoping a new attempt using yanglint helps pick out
> everything I missed by hand previously.
> 
> > o  5
> > 
> >   OLD:
> > 
> >     "This module contains conceptual YANG specifications
> >      for YANG push.";
> > 
> >   NEW:
> > 
> >     "This module contains YANG specifications for YANG push.";
> 
> ok
> 
> > o  5 - identities
> > 
> >     identity qos-unsupported {
> >       base sn:error;
> >       description
> >         "Subscription QoS parameters not supported on this platform.";
> >     }
> > 
> >   This identity is not mentioned anywhere in the text.  Instead of
> >   having this identity, wouldn't it be better to define a feature for
> >   "qos", and mark the nodes you have in mind with an if-feature?
> 
> It is possible to expose QoS explicitly as a feature.  I will make
> that addition if you are ok with my other QoS comment described below
> about subscribed-notifications.
> 
> But even in that case if QoS is not supported, and someone includes
> QoS objects in an "establish-subscription" we need this identity as an
> error.

No.  See RFC7950, section 8.3.1, bullet 4.  And compare with all other
modules that use if-feature; no other module has invented such error
codes.

> This error allow an explicit identification of what was wrong
> in the RPC (such as a DSCP provided is not supported by the
> Publisher).  I will include this in the Identity description.
> 
> >     identity on-change-unsupported {
> >       base sn:error;
> >       description
> >         "On-change not supported.";
> >     }
> > 
> >   When will this identity be used?  There is already a feature
> >   "on-change" and corresponding if-feature statements.
> 
> Per our discussion above, this can be used if an RPC asks for
> on-change for an object which is not available at a platform
> deployment (either marked in the schema, or a specific deployment
> doesn't support an object which is included).  I will enhance the
> description based on the discussion on this earlier in this thread.

Ok; i.e., the text should explain that it is used if the client asks
for an obejct that does not support on-change.  The if-feature case is
already handled as described above.

> >     identity on-change-synch-unsupported {
> >       base sn:error;
> >       description
> >         "On-change synch-on-start and resynchonization not supported.";
> >     }
> > 
> >   The leaf is called "no-sync-on-start", which implies that sync on
> >   start is the default.  So when will this identity be used?
> 
> Can be used in two places:
> 
> (1) Will be used if an RPC asks to synch on start, but it can't be
> supported for any reason (e.g., no nodes identifiable within the
> selection filter will ever be support on-change

But in this case the error will be "on-change-unsupported", right?

> ).  Will enhance the
> definition.
> 
> (2) The resynch RPC is invoked on a periodic subscription-id, or on an
> on-change subscription which can't support synchronization.
> 
> >     identity reference-mismatch {
> >      base sn:error;
> >       description
> >        "Mismatch in filter key and referenced yang subtree.";
> >     }
> > 
> >   I don't understand the description of this identity.  Please
> >   clarify.
> 
> Will clarify description to explain that the key provided with the
> filter does not match the data type of the referenced yang subtree

Huh?  What does *that* mean?

> >      identity datatree-size {
> > 
> >   Should it be "result-too-big" or something?
> 
> Yes.   I will change the name.
> 
> >     identity no-such-datastore {
> > 
> >   I think this one should be removed.  The normal "invalid-value"
> >   error-tag covers this error.
> > 
> > 
> >       identity custom-datastore {
> >         base ds:datastore;
> >         description
> >           "A datastore with boundaries not defined within
> >            draft-ietf-netmod-revised-datastores";
> >       }
> > 
> >   This identity needs to be removed.  If someone defines a custom
> >   datastore, it would get a specific identity, and that identity can
> >   be used as "source".
> 
> Yes, any new custom datastore will get a new identity, but if that new
> identity uses this custom-datastore one as a base

It will use ds:datastore as base.  If we need some other generic base
from which custom datastores are derived, that identity should be
defined in a generic place (ietf-datastores probably), and not here.

> , then we have an
> umbrella identity which is a handle just for the custom ones.  That
> was the intent of this.  If you don't think that an identity which
> acts as a bundling mechanism is useful, we can remove.

Yes.  (At least from this document.)

> > o  5 - "change-type"
> > 
> >   The descriptions of the enums need to be improved.  This is about
> >   reporting a change in a datastore.  The value "create" is described
> >   as:
> > 
> >         description
> >           "Create a new data resource if it does not already exist.  If
> >           it already exists, replace.";

You didn't reply to this.  My point is 

> > 
> >   Also, the description of the typedef has:
> > 
> >       "RFC 8072 section 2.5, with a delta that it is ok to receive
> >       ability create on an existing node, or receive a delete on a
> >       missing node.";
> > 
> >   But what does this mean?  The type is used to *exclude* some changes
> >   from a yang patch record.
> 
> This is to identify churn within a datastore during a dampening
> period.
>
> Two examples of when this is needed:
> 
> (1) For security applications, it is an absolute requirement that you
> know if a node was added and then removed during a dampening period.
> For an example, a hacker adds a "permit any any" which is then quickly
> removed before the dampening period ends.  Remote applications need to
> know that churn occurred.

I think there's some confusion here.  How would the "excluded-change"
leaf-list be used in this case?  (the typedef we're discussing is only
used in "excluded-change")

If an application needs to know *every* change, it probably shouldn't
use a dampening period.

> (2) For network management applications when a physical interface is
> going down and then quickly back up.  If the up/down is transient, how
> do you know that this occurred if there is no notification that churn
> occurred?
> 
> To support this, the YANG patch definition is loosened to allow the
> new creation on an existing node (based on what resulted from the last
> patch), or a delete on a missing node.  This acts as an indication
> that some churn in the datastore happened even though the data is in
> the same state as a per the previous update.  And if an application
> get to sees this indication when comparing to the previous state, they
> have the option of looking more closely at some logs on the publisher
> to determine what actually happened.
> 
> I can see that this behavior is under-described in the text.  I will
> put a small section between sections 3.10 & 3.11 describing this.  The
> title will be "Identification of a transient change within dampening
> period"

Well, yes this certainly needs to be described.  I will have to think
about the implications of this change.

> > o  5 - selection filter
> > 
> >   The XPath expression is not properly defined.
> > 
> >   OLD:
> > 
> >           "This parameter contains an XPath expression identifying the
> >           portions of the target datastore to retrieve.";
> > 
> >   NEW:
> > 
> >           "This parameter contains an XPath expression identifying the
> >            portions of the target datastore to retrieve.
> > 
> >            If the expression returns a node-set, all nodes in the
> >            node-set are selected by the filter.  Otherwise, if the
> >            expression does not return a node-set, the filter
> >            doesn't select any nodes.
> > 
> >            FIXME: (*)
> > 
> >            The expression is evaluated in the following XPath context:
> > 
> >              o  The set of namespace declarations are those in scope on
> >                 the 'xpath-filter' leaf element.
> > 
> >              o  The set of variable bindings is empty.
> > 
> >              o  The function library is the core function library, and
> >                 the XPath functions defined in section 10 in RFC 7950.
> > 
> >              o  The context node is the root node of the target
> >                 datastore.
> > 
> > 
> >   (*) - We need to describe when the filter is evaluated.  This is
> >   also true for the subtree filter.  Is it evaluated when the
> >   subscription is started and explicitly modified, or everytime a
> >   change is detected?
> > 
> >   [Side note: this description is also missing from the "xpath-filter"
> >   leaf in "get-data" in draft-ietf-netconf-nmda-netconf.  I have
> >   updated the description in that draft.]
> 
> I will update the descriptions to match your draft.
> 
> As for when the evaluation occurs, I am not sure what you mean.  Every
> time a change occurs, you need to see if the changed object would have
> fallen within the selection.

So then that has to be explained.  Otherwise, one might think that
the filter is evaluated once, and then changes are reported whenever
any node in the selected subtrees are changed.

See also my conceptual algorithm above.  

> There is no attempt to support an
> event-condition-action context.
> 
> > o  5 - terminology
> > 
> >   The term "agent" is used a couple of times.  Use "publisher" or
> >   "server" instead.
> 
> Will update
> 
> > o  5 - dampening
> > 
> >           leaf dampening-period {
> >             type yang:timeticks;
> >             mandatory true;
> > 
> >    Should this instead be:
> > 
> >           leaf dampening-period {
> >             type yang:timeticks;
> >             default "0";
> > 
> >    So that the request is the same if the "on-change" feature is
> >    support or not.
> 
> I like it, will update.
> 
> > o  5 - no-synch-on-start
> > 
> >              When
> >              present, pushing a full selection per the terms of the
> >              selection filter MAY NOT be done for this subscription.
> > 
> >    Did you mean s/MAY NOT/MUST NOT/ ?
> > 
> >    MAY NOT is not a 2119 term.
> 
> Will change to MUST NOT.
> 
> > o  5 - QoS
> > 
> >   Why are the qos parameters defined in yang push, and not in
> >   subscribed notifications?  It seems that they are generic.
> 
> This question has come up before.  Basically current 5277 event
> streams haven't shown need for QoS to date.  We know that QoS has been
> requested to handle congestion issues for YANG push.  So for
> simplicities sake, we bundled all QoS elements together in YANG push
> where we knew there was demonstrable need.  If someone really is
> asking for these QoS constructs for events, we can revisit.

I think it is important to try to design a standard so that it is
useful for more than one current use case.  In this case, it seems to
me that the qos parameters logically belong to the subscribed
notifications layer, and thus should be defined there.

> > o  5 - establish-subscription params
> > 
> >   I think a "when" expression should be added to the first augment:
> > 
> >     augment "/sn:establish-subscription/sn:input" {
> >       when "sn:target/yp:datastore/yp:source";
> 
> So this is saying that the named datastore must exist before allowing
> the augment.  Works for me.

Ok.

> > o  5 - push-update
> > 
> >   What does the presence of "updates-not-sent" mean in "push-update"?
> >   "push-update" contains a snapshot, not a diff, so why is
> >   "updates-not-sent" present?
> 
> This is to indicate a system error where not all objects can be
> extracted from the datastore.  (e.g., the routing table got *lots*
> bigger, and the periodic extract cannot be performed as expected.)  At
> least some implementations have seen this.  I will add some clarifying
> text.
> 
> > o  5 - push-change-update
> > 
> >         "This contains an incremental set of datastore changes needed
> >          to update a remote datastore starting at the time of the
> >          previous update, per the terms of the subscription.
> > 
> >    What is an "incremental set"?  Probably s/incremental set/set/
> 
> I can change to "set".

Ok.

> > o  General
> > 
> >   Use double quotes for node names.  "push-update", "subscription-id"
> >   etc.  Quotes are currently used inconsistently, and it makes the
> >   text harder to read.
> 
> Will make the fix.
> 
> Thanks again for all the excellent thoughts!
> Eric

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 5 Dec 2017 03:02:33 +0000

Hi Martin,

Reducing to the open items...

> I understand what you want to achieve, but I don't think the text is quite
> correct.  I'll think about this some more to see if I can come up with a better
> wording.

After the latest interactions on the mailer, text reads:

Dampening period: In an on-change subscription, detected object changes should be sent as quickly as possible.  However it may be undesirable to send a rapid series of object changes.  Such behavior has the potential to exhaust of resources in the publisher or receiver.  In order to protect against that, a dampening period MAY be used to specify the interval which must pass before successive update records for the same subscription are generated for a receiver.  The dampening period collectively applies to the set of all datastore nodes selected by a single subscription and sent to a single receiver.  This means that when there is a change to one or more subscribed objects, an update record containing those objects is created either immediately when no dampening period is in effect, or at the end of a dampening period.  If multiple changes to a single object occur during a dampening period, only the value that is in effect is included as part of the update record.  A dampening period is reset every time an update record has completed its assembly.

>    operation over that subscription's transport.

Text updated as you proposed.

> What is a "comprehensive filter syntax"?  Maybe this paragraph can be

Paragraph removed.
 
> My problem with this style is that it seems to indicate that the selection
> filter is only used for this use case ("replication of a subset..."), but that
> would be a mistake.  I think you should explain what these filters are first,
> and then (maybe) give examples of how they can be used.
> 
> The title "Datastore selection filter" is also misleading; 

I have made the title "Datastore selection", as the section doesn't hit all the items of subscription policy (such as periods).

> in fact the best
> solution might be to keep the original text but change the title of the
> section to "Subscription Policy".

I have returned the text to something closer to the original text.  It now is:

"A subscription must specify both the selection filters and the datastore against which these selection filters will be applied.  This information is needed to choose and subsequently push the information necessary to remotely maintain an extract of the publisher's datastore."

If you have other examples of how the info might be used, what would you want to add?  (One thing is possible is to simply monitor a datastore for a specific event, like the creation of a node, but not its deletion.   More on this within the excluded change discussion further below.)

> The text for subtree filters use the words "When specified, updates will only
> come from the data nodes of selected YANG subtree(s)."  If you use the
> same words here, the text is consistent and easier to understand.  Maybe:
> 
> NEW:
> 

updated
 
> But you are constraining the entire solution to support just this use case,
> when a simpler unconstrained solution just as easily supports this use case,
> *plus other use cases* - if a client does not want these "fake deletes", they
> can simply construct filters based on keys only, which they would in the
> current solution anyway.

This is true.

> Note also that b/c of the last paragraph in section 3.9, a client must deal
> with such deletes anyway, even if it specificied only keys.

This is true.

> But I do understand your point.  This is also related to my comment below
> about when a filter is evaluated.  Based on you reply to that comment, I
> think the conceptual algorithm is like this:
> 
> (this is conceptual, an implementation can do lots of optimizations to avoid
> evaluating filters on un-related changes)

Yes, this is it.   The only tweak I would make is to add the dampening period.  As a result, I have added the following text at the end of the "On-Change Considerations" section

"Putting it all together, following is the conceptual process for creating an push-change-update notification:
		
  1.Just before a change, or at the start of a dampening period, evaluate any filtering and any access control rules.  The result is a set "A" of datastore nodes and subtrees.

  2.Just after a change, or at the end of a dampening period, evaluate any filtering and any (possibly new) access control rules.  The result is a set "B" of datastore nodes and subtrees.

  3. Construct a YANG patch record for going from A to B.   If the record is non-empty, send it to the receiver."
		  
> [if the answer is "yes" we have a problem; and if it is "no", we need to
> tighten the text]
> 
> 
> All this makes me wonder if it is correct to have "subtree" and "xpath"
> filters at all.  If they only can match on keys, they become severely
> constrained.
> 
> An alternative could be to specify filters as "nacm:node-instance-identifier"
> instead; these are instance-identitifiers that allow missing keys.  For
> example:
> 
> This would be easier to understand and probably easier to optimize for in
> the server code.

I want to generalize this "only-keys?" issue for the full WG.   It is too important to handle this deep in the thread.  Look for me to open an issue shortly.

> Maybe "patch-id" could be a sequential number, starting from 1 when the
> first patch is sent?  Or simply any string that the server finds appropriate.
> In any case, "null" looks odd in the example.

Agree "null" looks odd.  

Does *anyone* have an issue if I make an implementation recommendation that the definition the incremental number of the push-change-update for a particular subscription?   That would at least make the required field useful?

> Ok, but the error code is used as a return value for "establish-subscription".
> So if a server can't detect it at "establish-subscription" it mean it will never
> be used.  Hence I suggest you remove the text about "authorization
> privileges".

A publisher could choose to allow a subscription to an empty location where there might plausibly be objects someday.   (E.g., maybe where an interface might appear; even if there is no such interface currently existing.)

Likewise a publisher could choose to reject a subscription because it is obvious that a subscriber will never have access to the requested data.   (E.g., maybe always disallow subscription to YANG model which controls the configuration of private keys.)

Pretending they might have access someday and allowing the subscription will just waste resources.  So I think the error is useful for such situations.

> evaluation algorithm above is not correct...

It is ok to create a filter for a non-existent interface.  This is supported in Cisco's XE implementation.

> in the notifications defined in this module.  It will be redundant.

It isn't redundant *until* we have notification-messages available.  And this will take some time.  After that, it need not be populated where the new subscribed-notifications header is available.  So the logic to avoid per-update header redundancy is straight-forward.
 
> Or do you suggest that *all* YANG modules that publish notifications must
> have a leaf "subscription-id", until the notification header document is
> done?  If not, why is this document special?

No, I am not suggesting all notifications need to define this leaf.   It is often the case that a single application can prove the need for common infrastructure.  In this case yang-push has pointed the way for a generalization of subscription-id across all notifications.  
 
> Ok.  So this means that when we have these new headers, "time-of-update"
> is no longer needed, right?

Yes.
 
> But actually, currently we have "eventTime".  And since "notification-time"
> is equivalent to "eventTime", and "time-of-update"
> is "notification-time", it follows that "time-of-update" is redundant and not
> needed today either.  Correct?

I would be ok with that.  And yes several of us have talked about it.  One person on this thread has argued the other way on this before based on their implementation logic.  But if they don't chime in now, I am fine with getting rid of "time-of-update" (which already is optional for this very reason).

>    included with this update.

Ok, updated.

> modules that use if-feature; no other module has invented such error

Let's handle this on the separate errors thread.   The question of legitimate negotiation interactions which are not actually errors is a conversation needing more WG internalization.  And without this, we need to figure out how to send errors as part things like subscription-suspended notifications.
 
> > This error allow an explicit identification of what was wrong in the
> > RPC (such as a DSCP provided is not supported by the Publisher).  I
> > will include this in the Identity description.
> >
> Ok; i.e., the text should explain that it is used if the client asks for an obejct
> that does not support on-change.  The if-feature case is already handled as
> described above.

Have changed the definition to: 
"On-change is not supportable for any objects which may be provided through the selection filter.";
 
> But in this case the error will be "on-change-unsupported", right?

I mean to say "except for" rather that e.g.   My bad.

> > definition.

Current text is now:
"Neither synch on start nor resynchonization are supported for this subscription.  This error will be used for two reasons. First if an 'establish-subscription' RPC doesn't include  'no-synch-on-start', yet the publisher can't support sending a  'push update' for this subscription for reasons other that 'on-change-unsupported' or 'result-too-big'.  And second, if the 'resynch-subscription' RPC is invoked either for an existing periodic subscription, or for an on-change subscription which can't support resynchronization.";

> Huh?  What does *that* mean?

As an extreme example: if someone tries to provide a character for a key that only accepts integer.  

Definition is now:
      "Mismatch between selection filter key provided and the datatype of the referenced YANG datatree node.";

You might say this *should* be placed under normal error conditions, per the larger error condition thread.  And perhaps this is the case.  But there still is the case where a subscription is abnormally terminated or suspended because someone modifies a configured subscription to a non-viable filter which causes this error to pop up.    Such an option needs to be reported to a subscriber, and existing error mechanisms don't do this AFAIK. 

> It will use ds:datastore as base.  If we need some other generic base from
> which custom datastores are derived, that identity should be defined in a
> generic place (ietf-datastores probably), and not here.

Will you put it in that document then?   That makes it very easy to delete from here.

> You didn't reply to this.  My point is

I took the definitions straight from rfc8072, with the tweak about how to handle the dampening period as discussed previously.

> leaf-list be used in this case?  (the typedef we're discussing is only used in
> "excluded-change")

The typedef matches up to the types of elements which may be returned in a YANG patch operation.   If an entry appears in this list, it is excluded from the allowed list of patch operations which may be sent for that subscription.

While this is not interesting for receivers which are trying to maintain an extract of a datastore, it may be interesting for applications which are simply looking for specific types of datastore events.  I will add some text in the type definition.
 
> If an application needs to know *every* change, it probably shouldn't use a
> dampening period.

Exactly
 
> Well, yes this certainly needs to be described.  I will have to think about the
> implications of this change.

What I ended up doing is adding not a new section, but instead a new paragraph within "on Change considerations" section.   The paragraph now reads:

However a patch must be able to do more than just describe the delta from the previous state to the current state.  As per <xref target="on-change"/>, it must also be able to identify if transient changes have occurred on an object during a dampening period.  To support this, it is valid to encode a YANG patch operation so that its application would result in a no change between the previous and current state.  This indicates that some churn has occurred on the object.  An example of this would be a patch that does a "create" operation for a datastore node where the receiver believes one already exists, or a "merge" operation which replaces a previous value with the same value.  

> So then that has to be explained.  Otherwise, one might think that the filter
> is evaluated once, and then changes are reported whenever any node in the
> selected subtrees are changed.
> 

I have explicitly added your (slightly tweaked) algorithm to the on-change considerations section.  So this should be covered.

> > >    So that the request is the same if the "on-change" feature is

I forgot the reason why I had mandatory true.   It is so that the leaf dampening-period is explicitly there in the RPC to identify this subscription as explicitly on-change.   Without the leaf, you need to infer "on-change" through the absence of the "period" leaf.  And such a design leaves open a greater chance of unnecessary errors.

> I think it is important to try to design a standard so that it is useful for
> more than one current use case.  In this case, it seems to me that the qos
> parameters logically belong to the subscribed notifications layer, and thus
> should be defined there.

I am fine either way.  Will open an issue and start a thread with the larger WG.

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Dec 2017 11:02:55 +0100 (CET)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> > quite
> Dampening period: In an on-change subscription, detected object
> changes should be sent as quickly as possible.  However it may be
> undesirable to send a rapid series of object changes.  Such behavior
> has the potential to exhaust of resources in the publisher or
> receiver.  In order to protect against that, a dampening period MAY be
> used to specify the interval which must pass before successive update
> dampening period collectively applies to the set of all datastore
> nodes selected by a single subscription and sent to a single receiver.
> This means that when there is a change to one or more subscribed
> objects, an update record containing those objects is created either
> immediately when no dampening period is in effect, or at the end of a
> dampening period.  If multiple changes to a single object occur during
> a dampening period, only the value that is in effect is included as
> part of the update record.  A dampening period is reset every time an
> update record has completed its assembly.

What if you delete the last sentence?  It is not clear to me what it
means to reset a period.

> > selection
> I have made the title "Datastore selection", as the section doesn't
> hit all the items of subscription policy (such as periods).
> 
> > in fact the best
> "A subscription must specify both the selection filters and the
> datastore against which these selection filters will be applied.  This
> information is needed to choose and subsequently push the information
> necessary to remotely maintain an extract of the publisher's
> datastore."

I prefer text that describes *how* this is used rather than *why*.  So
maybe change the last sentence above to:

  This information is used to choose and subsequently push data from
  the publisher's datastore to the receivers.

> If you have other examples of how the info might be used, what would
> you want to add?  (One thing is possible is to simply monitor a
> datastore for a specific event, like the creation of a node, but not
> its deletion.  More on this within the excluded change discussion
> further below.)

See above; I don't think these examples are needed at this point in
the document.

> > will only
> > case,
> > *plus other use cases* - if a client does not want these "fake
> > *deletes", they
> > deal
> > below
> > avoid
> Yes, this is it.  The only tweak I would make is to add the dampening
> period.  As a result, I have added the following text at the end of
> the "On-Change Considerations" section
> 
> "Putting it all together, following is the conceptual process for
> creating an push-change-update notification:
> 		
>   1.Just before a change, or at the start of a dampening period,
>   evaluate any filtering and any access control rules.  The result is a
>   set "A" of datastore nodes and subtrees.
> 
>   2.Just after a change, or at the end of a dampening period, evaluate
>   any filtering and any (possibly new) access control rules.  The result
>   is a set "B" of datastore nodes and subtrees.
> 
> > "xpath"
> > "nacm:node-instance-identifier"
> > in
> I want to generalize this "only-keys?" issue for the full WG.  It is
> too important to handle this deep in the thread.  Look for me to open
> an issue shortly.

Ok!

> > the
> Does *anyone* have an issue if I make an implementation recommendation
> that the definition the incremental number of the push-change-update
> for a particular subscription?  That would at least make the required
> field useful?
> 
> > > > o  3.9
> > > >
> > "establish-subscription".
> A publisher could choose to allow a subscription to an empty location
> where there might plausibly be objects someday.  (E.g., maybe where an
> interface might appear; even if there is no such interface currently
> existing.)

I think the spec needs to be clear if servers are required to allow
filters to cover non-existing nodes or not (I think it should).
Hence, selecting a non-existing node should not be an error.

NOTE: we may want to handle the case that the client asks for a node
that can *never* exist (e.g. a node in a non-implemented module or a
misspelled node name) differently than the case that an instance
doesn't exist.

> Likewise a publisher could choose to reject a subscription because it
> is obvious that a subscriber will never have access to the requested
> data.  (E.g., maybe always disallow subscription to YANG model which
> controls the configuration of private keys.)
> 
> Pretending they might have access someday and allowing the
> subscription will just waste resources.  So I think the error is
> useful for such situations.

This is fine, but not what the current description says.  The text in
3.9 and the YANG module don't match.

Also, in the normal case, I don't think the server will know if a
client will *never* have access to some object.

> supported in Cisco's XE implementation.

Good.  See above.

> It isn't redundant *until* we have notification-messages available.
> And this will take some time.  After that, it need not be populated
> where the new subscribed-notifications header is available.  So the
> logic to avoid per-update header redundancy is straight-forward.
>  
> > must
> No, I am not suggesting all notifications need to define this leaf.
> It is often the case that a single application can prove the need for
> common infrastructure.  In this case yang-push has pointed the way for
> a generalization of subscription-id across all notifications.

This is fine.  But this doesn't mean that "subscription-id" should be
treated differently in this draft compared to others.

> > "notification-time"
> I would be ok with that.  And yes several of us have talked about it.
> One person on this thread has argued the other way on this before
> based on their implementation logic.  But if they don't chime in now,
> I am fine with getting rid of "time-of-update" (which already is
> optional for this very reason).
> 
> Let's handle this on the separate errors thread.  The question of
> legitimate negotiation interactions which are not actually errors is a
> conversation needing more WG internalization.  And without this, we
> need to figure out how to send errors as part things like
> subscription-suspended notifications.

I don't think this notification has to change.

> > for an obejct

s/any/all/ ?

> "Neither synch on start nor resynchonization are supported for this
> subscription.  This error will be used for two reasons. First if an
> 'establish-subscription' RPC doesn't include 'no-synch-on-start', yet
> the publisher can't support sending a 'push update' for this
> subscription for reasons other that 'on-change-unsupported' or
> 'result-too-big'.

What would that reason be?  I think that if the idea is that a server
may or may not support sync on start, you should make a feature for it
and call the leaf "sync-on-start" instead.  And OTOH, if the default
is sync on start (as it is now), it should be required to support it.

> And second, if the 'resynch-subscription' RPC is
> invoked either for an existing periodic subscription, or for an
> on-change subscription which can't support resynchronization.";

What would a leagal reason be for the latter case?

> > > (2) The resynch RPC is invoked on a periodic subscription-id

Ok.

> > > , or on an

Note that both subtree filter and xpath allows this and will just
return an empty node set.  I really don't think we should change how
XPath or subtree filter works.  So I propose you remove this error.

> You might say this *should* be placed under normal error conditions,
> per the larger error condition thread.  And perhaps this is the case.
> But there still is the case where a subscription is abnormally
> terminated or suspended because someone modifies a configured
> subscription to a non-viable filter which causes this error to pop up.
> Such an option needs to be reported to a subscriber, and existing
> error mechanisms don't do this AFAIK.
> 
> 
> > > >      identity datatree-size {
> > > >
> > from

That's a discussion for the nmda document, but personally I don't see
the need for such an identity.   In any case, it should be removed
from this document.

> I took the definitions straight from rfc8072, with the tweak about how
> to handle the dampening period as discussed previously.
> 
> > > >
> The typedef matches up to the types of elements which may be returned
> in a YANG patch operation.  If an entry appears in this list, it is
> excluded from the allowed list of patch operations which may be sent
> for that subscription.
> 
> While this is not interesting for receivers which are trying to
> maintain an extract of a datastore, it may be interesting for
> applications which are simply looking for specific types of datastore
> events.  I will add some text in the type definition.
>  
> > use a
> What I ended up doing is adding not a new section, but instead a new
> paragraph within "on Change considerations" section.  The paragraph
> now reads:
> 
> However a patch must be able to do more than just describe the delta
> from the previous state to the current state.  As per <xref
> target="on-change"/>, it must also be able to identify if transient
> changes have occurred on an object during a dampening period.  To
> support this, it is valid to encode a YANG patch operation so that its
> application would result in a no change between the previous and
> current state.  This indicates that some churn has occurred on the
> object.  An example of this would be a patch that does a "create"
> operation for a datastore node where the receiver believes one already
> exists, or a "merge" operation which replaces a previous value with
> the same value.

Hmm, I think that this is a very strange way to indicate "churn", it
is very implicit.  Is it really necessary to be able to indicate this
"churn"?  It seems quite complex on both the server and client side.
If a client needs to know this information, it can just not specify a
dampening period.

> I have explicitly added your (slightly tweaked) algorithm to the
> on-change considerations section.  So this should be covered.
> 
> > > > o  5 - dampening
> > > >
> > > >           leaf dampening-period {
> > > >             type yang:timeticks;
> > > >             mandatory true;
> > > >
> > > >    Should this instead be:
> > > >
> > > >           leaf dampening-period {
> > > >             type yang:timeticks;
> > > >             default "0";
> > > >
> I forgot the reason why I had mandatory true.  It is so that the leaf
> dampening-period is explicitly there in the RPC to identify this
> subscription as explicitly on-change.  Without the leaf, you need to
> infer "on-change" through the absence of the "period" leaf.  And such
> a design leaves open a greater chance of unnecessary errors.

I think the current data model has some other problems as well.
Specifically, the "update-trigger" choice is optional - what does it
mean if it no case is specified in this choice?   Here's a proposal
for a more explicit datamodel:

  choice update-trigger {
    when "../target/datastore/source";   (*)
    mandatory true;
    case periodic {
      container periodic {
        presence "indicates a periodic subscription";
        leaf period { ... }
        leaf anchor-time { ... }
      }
    }
    case on-change {
      container on-change {
        presence "indicates an on-change subscription";
        leaf dampening-period {
          type yang:timeticks;
          default "0";  // or mandatory if you prefer that the client
                        // must be explicit
        }
        leaf no-sync-on-start { ... }
        leaf-list excluded-change { ... }
      }
    }
  }

(*) this path shows another issue with the data model - in the
"target" you have a "source".  I think you should rename "source" to
"datastore"; so in the case "datastore" there's a leaf "datastore".
Also, it shows that it is not clear if the proper name in
establish-subscription is "target" or "source" - or something else.

> > useful for

Ok.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 5 Dec 2017 16:28:28 +0100

I very strongly object to excluding the issue.  There is a strong
and immediate need to be able to specify in vendor design time for
which data nodes will there be on-change notification be
generated.

When a vendor release a product they know which nodes will emit
on-change notifications in design time. System integrators need to
know this. Providing the same information in run-time as instance
data is not a good solution either as you would need to get a real
node to read the data from.

IMHO ignoring this need would just force the vendors (including
ericsson) to create an own solution.

Andy wrote: "I agree this is an implementation property, and not
a data model property."

I always thought that one of the main purposes of YANG was to
document vendor's implementation. That is exactly what a deviation
or  feature also does. They are both part of YANG.

regards Balazs

On 2017-11-28 18:10, Andy Bierman
wrote:

On Tue, Nov 28, 2017 at 1:37 AM,
Martin Bjorklund <[email-masked]>
wrote:

Hi,

I have now reviewed draft-ietf-netconf-yang-push-11.
I have one

somewhat more important comment, and several others.

Important issue:

o  3.10

I don't think the proposed YANG extension is the correct
solution to

1.  In most cases, this is not a property of the data
model, but

of the implementation, and possibly even the
deployment.  So

having a YANG extension statement is not a good
solution.

2.  With NDMA, the same schema node is present in
different

datastores.  It might be the case that an
implementation

supports on-change for the node in a configuration
datastore,

but not in operational.  Again, marking a node in
the schema

is not a good solution.

3.  Since the on-change property is implementation
dependent, it

means the information will be available to clients
only in

deviation modules.  This is quite an expensive and
complicated

An alternative solution could be to have an ordered list
of

instance-identifiers that list this property, per
datastore, for

example:

<entry>

</entry>

<entry>

<path>/sys:system<path>

</entry>

Yet another alternative would be to leave this to future
work.

I would prefer to leave this to future work.

I agree this is an implementation property, and not a
data model property.

Andy

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 5 Dec 2017 20:17:43 +0000

My preference is to keep the solution as-is, per the current solution with the extension we have defined.

That said, I have two comments related to how we can get closure?

-          If we cannot get agreement on this, I would not want to delay YANG-Push over it (like Martin has indicated as well). In that case, I would suggest we add an informational section that explains the issue, and outlines what a (proprietary) solution might look like.  Of course, unfortunately this will de-facto mean vendor-proprietary solutions at this point as this aspect will need to be addressed – I would fully expect that Ericsson in that case will define the same solution as an Ericsson-proprietary module with an Ericsson-proprietary extension (as opposed to have a standard solution).

-          I do think there is merit to also include the information of what is notifiable as part of the YANG-library.  This could be part of the permanent solution (although it does not address the aspect of how the information in the library would be populated, Balazs per your comment). This specific discussion should probably moved to the YANG-library discussion, not the one here.

--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Balazs Lengyel
Sent: Tuesday, December 05, 2017 7:28 AM
To: Andy Bierman <[email-masked]>; Martin Bjorklund <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: [Netconf] "notifiable-on-change" [was: Re: review of draft-ietf-netconf-yang-push-11]

I very strongly object to excluding the issue.  There is a strong and immediate need to be able to specify in vendor design time for which data nodes will there be on-change notification be generated.

When a vendor release a product they know which nodes will emit on-change notifications in design time. System integrators need to know this. Providing the same information in run-time as instance data is not a good solution either as you would need to get a real node to read the data from.

IMHO ignoring this need would just force the vendors (including ericsson) to create an own solution.

Andy wrote: "I agree this is an implementation property, and not a data model property."

I always thought that one of the main purposes of YANG was to document vendor's implementation. That is exactly what a deviation or  feature also does. They are both part of YANG.

regards Balazs

On 2017-11-28 18:10, Andy Bierman wrote:

Important issue:

o  3.10

   <entry>

I would prefer to leave this to future work.
I agree this is an implementation property, and not a data model property.

Andy

--

Senior Specialist

Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 6 Dec 2017 01:35:50 +0000

Hi Martin,

> From: Martin Bjorklund, December 5, 2017 5:03 AM
> 
> Hi,
> 
> > > >          A dampening period is reset every time a new notification
> > > > message
> > > is
> > > >          passed to transport.
> > >
> What if you delete the last sentence?  It is not clear to me what it means to
> reset a period.

The last sentence is important (per the comments with Rohit R .)    I will clarify it to:
"The dampening period goes into effect every time an update record completes assembly."
 
> > > > We don't intend to define a new term in this paragraph.  And you
> > > > are correct, policy only appears elsewhere in the document as part
> > > > of the YANG model group names.  (more below)
> > > >
> > > > An objective of YANG push is to allow the replication of a subset
> > > > of a publisher's datastore within a receiver.  The datastore
> > > > selection filter defines this subset.  Only a single selection
> > > > filter can be applied to a subscription at a time.  The selection
> > > > filter types defined in this include:
> > >
> > > subset..."), but that would be a mistake.  I think you should
> > > explain what these filters are first, and then (maybe) give examples
> > > of how they can be used.
> > >
> > > solution might be to keep the original text but change the title of
> > > the section to "Subscription Policy".
> >

Updated.

> See above; I don't think these examples are needed at this point in the
> document.

Ok. No change needed beyond text change above.

> > > > patch-id is mandatory in RFC-8072, and was originally supposed to
> > > > be used for debugging of failed datastore write operations.
> > >
> > > appropriate.

I have added the text:
" Of Note in the above example is the 'patch-id' with a value of '1'.  Per [RFC8072], the 'patch-id' is an arbitrary string.  With YANG Push, the publisher SHOULD put into the 'patch-id' a counter starting at '1' which increments with every 'push-change-update' generated for a subscription. If used as a counter, this counter MUST be reset to '1' anytime a resynchronization occurs (i.e.,  with the sending of a 'push-update').  Also if used as a counter, the counter MUST be reset to '1' the after passing a maximum value of '99999'. Such a mechanism allows easy identification of lost or out-of-sequence update records. "

> > > > It cannot know this at "establish-subscription".  So a publisher
> > > > will have to track whether the permissions on subscribed objects
> change.
> > > So if a server can't detect it at "establish-subscription" it mean
> > > it will never be used.  Hence I suggest you remove the text about
> > > "authorization privileges".

The subscription-terminated notification is valid for dynamically established subscriptions.   This is a valid error code for that situation.

> I think the spec needs to be clear if servers are required to allow filters to
> cover non-existing nodes or not (I think it should).

Agree.   The " Receiver Authorization" section now has a clarified sentence:
" A publisher MAY allow subscriptions which select non-existent or access-protected data."

> NOTE: we may want to handle the case that the client asks for a node that
> can *never* exist (e.g. a node in a non-implemented module or a misspelled
> node name) differently than the case that an instance doesn't exist.

Agree.  Such determination is up to the publisher.
 
> 3.9 and the YANG module don't match.

 on-change-unsupported  definition now is:
"On-change is not supported for any objects which are likely to be provided through the selection filter."

> Also, in the normal case, I don't think the server will know if a client will
> *never* have access to some object.

It will be interesting to see how different publishers optimize for this situation.
 
> > > > that addition if you are ok with my other QoS comment described
> > > > below about subscribed-notifications.
> > > >
> > > > But even in that case if QoS is not supported, and someone
> > > > includes QoS objects in an "establish-subscription" we need this
> > > > identity as an error.
> > >
> > > No.  See RFC7950, section 8.3.1, bullet 4.  And compare with all
> > > other modules that use if-feature; no other module has invented such
> > > error codes.
> >

Excellent.   Alex will be providing some suggestions on what to do with error interactions on a parallel thread.
 
> > > > This error allow an explicit identification of what was wrong in
> > > > the RPC (such as a DSCP provided is not supported by the
> > > for an obejct that does not support on-change.  The if-feature case
> > > is already handled as described above.
> >

Any.  Because this includes any objects which might come into existence under a subscribed subtree.   Tweaked the definition to:
"On-change is not supported for any objects which are likely to be provided through the selection filter."

> What would that reason be? 

One example might be the CPU capacity is prohibitively low at that immediate time.  Or there are too many subscriptions pulling counters or routing tables or MAC addresses from a specific line card.  Or other platform wide issues which shouldn't fall under 'result-too-big' because making the result smaller still won't result in the subscription being allowed to push the state of current nodes.

> I think that if the idea is that a server may or
> may not support sync on start, you should make a feature for it and call the
> leaf "sync-on-start" instead.  And OTOH, if the default is sync on start (as it
> is now), it should be required to support it.
> 
> > And second, if the 'resynch-subscription' RPC is invoked either for an
> > existing periodic subscription, or for an on-change subscription which
> > can't support resynchronization.";
> 

The first case of the RPC being invoked for the periodic case seems enough for this identity.  For an on-change, see the other reasons above.  Having a catch all error code which doesn't futilely drive a subscriber to attempt smaller subscriptions is worthwhile.
 
> Note that both subtree filter and xpath allows this and will just return an
> empty node set.  I really don't think we should change how XPath or
> subtree filter works.  So I propose you remove this error.

Ok.  Removed.
 
> > > > Yes, any new custom datastore will get a new identity, but if that
> > > > new identity uses this custom-datastore one as a base
> > >
> > > It will use ds:datastore as base.  If we need some other generic
> > > base from which custom datastores are derived, that identity should
> > > be defined in a generic place (ietf-datastores probably), and not
> > > here.
> >

Removed.  I will think about making the request to NMDA.
 
> Hmm, I think that this is a very strange way to indicate "churn", it is very
> implicit.  Is it really necessary to be able to indicate this "churn"?  It seems
> quite complex on both the server and client side.

Churn indication is an absolute *must* for security applications.  Both the SACM and I2NSF WGs have indicated need.  It is also highly useful for Network Management applications which simply cannot get a continuous stream of interface flaps.   This is a highly advantageous capability and I have quite a few customer requests for this.
 
>     when "../target/datastore/source";   (*)

I have integrated the when & mandatory.

>         leaf-list excluded-change { ... }

I included this as well.  Honestly the containers are mostly redundant at this point the information can be gleaned by the available objects.  But I can imagine future triggers which re-use some of the same object names.  This prepares for this time.

> (*) this path shows another issue with the data model - in the "target" you
> have a "source".  I think you should rename "source" to "datastore"; so in
> the case "datastore" there's a leaf "datastore".
> Also, it shows that it is not clear if the proper name in establish-
> subscription is "target" or "source" - or something else.

I have renamed source to datastore.

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Dec 2017 09:40:09 +0100 (CET)

Hi,

[...]

> " Of Note in the above example is the 'patch-id' with a value of '1'.
> Per [RFC8072], the 'patch-id' is an arbitrary string.  With YANG Push,
> the publisher SHOULD put into the 'patch-id' a counter starting at '1'
> which increments with every 'push-change-update' generated for a
> subscription. If used as a counter, this counter MUST be reset to '1'
> anytime a resynchronization occurs (i.e., with the sending of a
> 'push-update').  Also if used as a counter, the counter MUST be reset
> to '1' the after passing a maximum value of '99999'. Such a mechanism
> allows easy identification of lost or out-of-sequence update
> records. "
> 
> > > > > > o  3.9
> > > > > >
> The subscription-terminated notification is valid for dynamically
> established subscriptions.  This is a valid error code for that
> situation.
> 
> > filters to

So it seems you *didn't* agree with what I wrote :)

With the selection filter algorithm you have chosen, I think the
server MUST allow subscriptions that select non-existing instances.

At time t0 the filter might return a node set with a node.  Then at
time t1 the node set might be empty, this is then reported.  Then at
time t2 the node set contains a node again, this is then reported.
Etc.

> > that

See below.

> Any.  Because this includes any objects which might come into
> existence under a subscribed subtree.

Logically, "not for all" means that there exists one for which it
it false.  "not for any" is a bit unclear...

Compare:

  "not all integers in the range 1..10 are even"

with:

  "any integer in the range 1..10 is not even"

How about:

 "This value means that on change is not supported for some node that
  may be selected by the given filter."
 
> Tweaked the definition to:

"likely to be provided" is a bit confusing.

> One example might be the CPU capacity is prohibitively low at that
> immediate time.  Or there are too many subscriptions pulling counters
> or routing tables or MAC addresses from a specific line card.  Or
> other platform wide issues which shouldn't fall under 'result-too-big'
> because making the result smaller still won't result in the
> subscription being allowed to push the state of current nodes.
> 

You didn't reply to this comment.

> The first case of the RPC being invoked for the periodic case seems
> enough for this identity.  For an on-change, see the other reasons
> above.  Having a catch all error code which doesn't futilely drive a
> subscriber to attempt smaller subscriptions is worthwhile.
>  
> > return an
> > is very
> Churn indication is an absolute *must* for security applications.
> Both the SACM and I2NSF WGs have indicated need.  It is also highly
> useful for Network Management applications which simply cannot get a
> continuous stream of interface flaps.  This is a highly advantageous
> capability and I have quite a few customer requests for this.

Ok.  (so what do you do if you know that churn has happend, but you
have no idea what the churn was?)

Depending on the outcome of the filter issue (full XPath/subtree
filter vs. node-instance-identifier (BTW, will you crete a separate
thread for that discussion?)), I will have to come back to this
issue.  It seems awfully expensive to implement correctly.

> I included this as well.  Honestly the containers are mostly redundant
> at this point the information can be gleaned by the available objects.
> But I can imagine future triggers which re-use some of the same object
> names.  This prepares for this time.
> 
> > "target" you

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Dec 2017 09:45:53 +0100 (CET)

Hi,

Alexander Clemm <[email-masked]> wrote:
> My preference is to keep the solution as-is, per the current
> solution with the extension we have defined.
> 
> -          If we cannot get agreement on this, I would not want to
> delay YANG-Push over it (like Martin has indicated as well). In that
> case, I would suggest we add an informational section that explains
> the issue, and outlines what a (proprietary) solution might look
> like.

Since I don't think that a YANG extension is the right solution to
this problem (and others have indicated this as well), I do not think
that we should recommend anyone to do that even as a proprietary
solution, and not even in an informative appendix.

I think that either we spend time on figuring out an acceptable
solution to the WG and include it in the document, or else we write a
simple statement that this is out of scope and left for a future
specification.

/martin

> Of course, unfortunately this will de-facto mean vendor-proprietary solutions at this point as this aspect will need to be addressed – I would fully expect that Ericsson in that case will define the same solution as an Ericsson-proprietary module with an Ericsson-proprietary extension (as opposed to have a standard solution).
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Dec 2017 10:01:12 +0100 (CET)

Balazs Lengyel <[email-masked]> wrote:
> I very strongly object to excluding the issue. There is a strong and
> immediate need to be able to specify in vendor design time for which
> data nodes will there be on-change notification be generated.
> 
> know this. Providing the same information in run-time as instance data
> is not a good solution either as you would need to get a real node to
> read the data from.

The same argument applies to which YANG modules, features and
deviations a product supports.  In SMIv2 we had AGENT-CAPABILITIES
which was an off-line document with this information.  The experience
seems to be that it was rarely used by managers.  In YANG we provide
this information on-line with the YANG library (and at least our
experience so far is that this *is* used by clients).

It would probably be a good idea to combine these two approaches.

I think that this would be fairly straight-forward.  As a first
approximation, suppose we had a standard file format for a
"server-capabilities" document.  It could be something like this:

  <server-capabilities>
    // this identifier must also be available on the device, so that
    // a client can match the capability document with the device.
    <server-capability-identifier>some unique identifier</>

    // meta-data goes here
    <vendor> ... </vendor>
    <product-name> ... </product-name>
    ...

    <yang-library>
      // the contents of yang-library from this product
      // with modules, features, deviations
      // ... and possibly on-change info
    </yang-library>
  </server-capabilities>

Now, this won't be useful for all systems, for example if the server
is very dynamic and support dynamic loading of packages etc.

/martin

> I always thought that one of the main purposes of YANG was to document
> vendor's implementation. That is exactly what a deviation or feature
> also does. They are both part of YANG.
> 
> regards Balazs
> 
>     On Tue, Nov 28, 2017 at 1:37 AM, Martin Bjorklund <[email-masked]>
>     wrote:
> 
>     Hi,
> 
>

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 6 Dec 2017 11:11:40 +0100

Re: "notifiable-on-change"
--------------------------
We have an immediate strong use-case where we need to know
for which data nodes will the server emit push-change-update
notifications. Without a clean standard proposal the yang-push solution is
incomplete, not ready.

As noted by others too, servers will not send push-change-updates for 
every data node.
The usual reasons for not sending push-change-updates is:
- value of the data node changes frequently (e.g. in-octets counter)
- small changes are frequent and meaningless (e.g., a temperature gauge
changing 0.1 degrees),
- the implementation is not capable of on-change notification for a
particular object (specially relevant for state data)
All the above reasons are known in design time when the _vendor_ defines the
product.  All are related to a particular model or schema part.
There may be other reasons, in which case please list them and propose a 
solution covering them!

Often when you release a network node you also release an associated NMS
(network management system) with it. The NMS depends on receiving
push-change-update notifications. I can't write an algorithm that may or 
my not
receive data.

During NMS implementation the information about push-change-updates is 
needed.
If the information about push-change-updates is not available early in some
document, but only as instance data from the network node, the NMS 
implementation will be
delayed, because it has to wait for the network node to be ready. Also 
assuming
that all NMS implementors will have a correctly configured network node
available to retrieve data from, is very expensive. (An NMS may handle 
dozens
of node types.)

Beside NMS implementors, system integrators and many others also need 
the same
information early.  Model driven testing, generating documentation comes 
to my mind immediately.

The currently proposed notifiable-on-change extension is a simple 
solution that
solves a real problem. It does not preclude a later definition of a YANG 
model
about the same information. It is not the only possible solution, but a
reasonable one. During the work-group phase a number of other solutions were
discussed and not selected.

You write: "The same argument applies to which YANG modules, features and
deviations a product supports."
Yes, however this does not mean that the use-case is invalid, it only 
means that
YANG does not handle it well. Do we want to make a bad situation worse. 
Do we
care about NMS developers?

Yes you could document all this in plain English or vendor solutions, 
but IMHO
the IETF's task, our task is to create standardized, formal solutions 
for the
common use-cases.

--

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 6 Dec 2017 11:32:35 +0100

> experience so far is that this *is* used by clients).
BALAZS: I agree that yang-library is good. I am not arguing against it. 
Just it is
not enough, because it is only available in run-time, too late.
> It would probably be a good idea to combine these two approaches.
BALAZS: I agree. Early documentation and on-line documentation
combined would be a good solution.
IMHO the 2 could use the same format. E.g.
- Put all server-capabilities into yang-library (possibly augmenting it 
where needed)
- define an off-line format for YANG Instance data
     e.g. the data section of a <get> reply This way you don't even have 
to define a real new format
- declare that off-line instance data from yanglib is the format to 
define server capabilities
> is very dynamic and support dynamic loading of packages etc.
BALAZS: I would put server-capabilities in 3 bags:
1) capabilities that change only at upgrade
2) capabilities that change rarely (e.g. due to licensing)
3) capabilities that change frequently (???)
IMHO 1) covers 70% of the cases 2) covers 20% 3) is < 10%.
Many network nodes only have type 1) or type 1+2) capabilities.
So our main focus should be on stable capabilities

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 6 Dec 2017 11:51:53 +0100

Hello,

You could use a longer dampening period for detecting churn and later 
switch to a very short dampening period with a narrow filter.  Getting 
the information in two steps  sometimes maybe a problem.

regards Balazs

On 2017-11-30 23:16, Eric Voit (evoit) wrote:
> Hi Henk,
>
> YANG Push does identify that churn has occurred, but not how much churn has occurred during a dampening period.   This allows things like security applications to know things like temporary ACL changes.  Or things like network management systems knowing that there are transient outages on an interface.
>
> At this point, the thinking is that an application always has the option of going to Publisher to get the details of the churn.   Perhaps new drafts could also push the quantity of changes which occurred, or a histogram or changes, or some other metric.  At this point that topic is unexplored.  But there is no reason that such information couldn't be augmented into some header associated with the push-change-update record.
>
> Eric
>
>> From: Henk Birkholz, November 30, 2017 4:48 PM
>>
>> Hi all,
>>
>> Admittedly, I am relatively new to this domain and before I provide my
>> comment I want to acknowledge that:
>>
>> - it is important not to off-load to much complexity to the agents that are
>> part of the data store
>> - complex composite devices might create a lot of "noise" in wrt changes of
>> data node values and that has to be dealt with in a sane and reasonable
>> way
>>
>> That said, YANG Push caught a lot of attention outside of NETCONF. In a
>> nutshell, it is a solution that provides meaningful telemetry, which
>> simplifies post-processing of subscribed notifications significantly.
>>
>> But - there is always a but, I guess - "visibility" is a key capability in this
>> context, I think. Yes, there might be oscillating values, yes, they might be of
>> no value to most post-processing processes, but to exclude them entirely
>> might reduce the usefulness of the on-change capability significantly.
>>
>> There is the complementary topic of smart filters that might deal with
>> providing metadata about this "omitted notifications" (coming back to the
>> oscillating values example, Alex illustrated), but visibility of ongoing changes
>> should be supported somehow, I think. Maybe not in the top level draft
>> that is netconf-yang-push, but at some level, I hope.
>>
>> Again, this is coming from a fresh pair of eyes still relatively unfamiliar with
>> the emerging ecosystem around YANG Push.
>>
>> In a nutshell, I just want to highlight that visibility of past changes and
>> dealing with high frequency of changes of course requires a feasible
>> compromise. But from my POV, "the most recent update" might not cut it.
>> I only want to highlight that fine granular visibility is a vital characteristic of
>> on-change emission of notifications. Maybe there can be a knob, as Sue
>> might phrase it.
>>
>> If this is already addressed by another draft, I apologize for my wall of text.
>> If not, please take this POV into account :)
>>
>> Viele Grüße,
>>
>> Henk
>>
>> On 11/30/2017 01:59 AM, Alexander Clemm wrote:
>>> This works for me.  Perhaps one additional item we might add (for
>>> crystal-clear clarification) is that when the notification message is
>>> sent, it contains the most recent update for that object (i.e. the
>>> value that is in effect when the update is sent).  If there are some
>>> quickly oscillating values we don’t send the whole sequence of
>> updates/values.
>>> --- Alex
>>>
>>> *From:*Eric Voit (evoit) [mailto:[email-masked]]
>>> *Sent:* Wednesday, November 29, 2017 4:51 PM
>>> *To:* Alexander Clemm <[email-masked]>; Andy Bierman
>>> <[email-masked]>; Martin Bjorklund <[email-masked]>;
>>> [email-masked]
>>> *Cc:* Netconf <[email-masked]>
>>> *Subject:* RE: [Netconf] review of draft-ietf-netconf-yang-push-11
>>>
>>> of resources in the publisher or receiver. In order to protect against
>>> that, a dampening period MAY be used to specify the interval which
>>> must pass before successive update records for the same subscription
>>> are generated for a receiver.  The dampening period collectively
>>> applies to the set of all data nodes selected by a single subscription
>>> and sent to a single receiver.  This means that when there is a change
>>> to a subscribed object, an update record containing that object is
>>> created either immediately when no dampening period is in effect, or
>>> at the end of a dampening period.  A dampening period is reset every
>>> time a new notification message is passed to transport.
>>>
>>> notification message is passed to transport.  A zero value indicates
>>> *From:*Netconf [mailto:[email-masked]] *On Behalf Of
>>> *Alexander Clemm
>>> *Sent:* Wednesday, November 29, 2017 3:17 PM
>>> *To:* Andy Bierman <[email-masked]
>> <mailto:[email-masked]>>;
>>> Martin Bjorklund <[email-masked] <mailto:[email-masked]>>
>>> *Cc:* Netconf <[email-masked] <mailto:[email-masked]>>
>>> *Subject:* Re: [Netconf] review of draft-ietf-netconf-yang-push-11
>>>
>>> I thought we decided that we have combined dampening for all objects
>>> in the subscription.  In this case, we would send updates at 2, 12
>>> (containing 3,4,11), and 22 (containing 13, 14, 15).
>>>
>>> If the scope of the subscription becomes sufficiently large, this
>>> almost reverts back to a periodic subscription (since there is always
>>> going to be a change somewhere). This is why I originally argued to
>>> have it indeed on a per-object basis, but I lost that argument.  For
>>> such fine-grained updates, where a client is indeed interest in
>>> getting delays of individual objects without delay,  a client could
>>> simply need to establish multiple “micro” subscriptions.
>>>
>>> TCAs in RMON are something different altogether.  This is something we
>>> are trying to address with smart filters.
>>>
>>> --- Alex
>>>
>>> *From:*Netconf [mailto:[email-masked]] *On Behalf Of *Andy
>>> Bierman
>>> *Sent:* Wednesday, November 29, 2017 10:18 AM
>>> *To:* Martin Bjorklund <[email-masked] <mailto:[email-masked]>>
>>> *Cc:* Netconf <[email-masked] <mailto:[email-masked]>>
>>> *Subject:* Re: [Netconf] review of draft-ietf-netconf-yang-push-11
>>>
>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked]
>> [email-masked]
> [email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 6 Dec 2017 15:00:40 +0000

Hi Martin,

> From: Martin Bjorklund, December 6, 2017 3:40 AM
> 
> Hi,
> 
> 
> > > > > > > o  3.9
> > > > A publisher could choose to allow a subscription to an empty
> > > > location where there might plausibly be objects someday.  (E.g.,
> > > > maybe where an interface might appear; even if there is no such
> > > > interface currently
> > > > existing.)
> > >
> With the selection filter algorithm you have chosen, I think the server MUST
> allow subscriptions that select non-existing instances.

MUST forces a subscription to be accepted (even with other issues).   MAY gives the publisher the option of accepting a subscription (something it has the right to do with any subscription).

> At time t0 the filter might return a node set with a node.  Then at time t1
> the node set might be empty, this is then reported.  Then at time t2 the
> node set contains a node again, this is then reported.
> Etc.

Agree.  This is a valid case where a publisher chose allowed a subscription which might include empty node sets. 
 
> > > > Likewise a publisher could choose to reject a subscription because
> > > > it is obvious that a subscriber will never have access to the
> > > > requested data.  (E.g., maybe always disallow subscription to YANG
> > > > model which controls the configuration of private keys.)
> > > >

Any is correct.   Reasoning is also below.

> > > > > > deployment (either marked in the schema, or a specific
> > > > > > deployment doesn't support an object which is included).  I
> > > > > > will enhance the description based on the discussion on this
> earlier in this thread.
> > > > >
> > > > > Ok; i.e., the text should explain that it is used if the client
> > > > > asks for an obejct that does not support on-change.  The
> > > > > if-feature case is already handled as described above.
> > > >
> Logically, "not for all" means that there exists one for which it it false.  "not
> for any" is a bit unclear...
> 
> Compare:
> 

A selection filter need not be designed to explicitly remove nodes which are not-notifiable-on-change.  These are automatically removed without any knowledge of the filter, and need not be considered by the designer of the filter.  (I.e., you can on-change subscribe to interfaces, and will never see any counters.)

An on-change subscription should not be allow if it is unlikely there will be any on-change nodes ever within its domain of selection. 
 
> "likely to be provided" is a bit confusing.

"Likely to be provided" covers the case of nodes which don't exist as the time of subscription, yet appear later.   The "Likely to" is better than "Never will" since it is theoretically possible for a system to add a lightly protected node deep in a tree.

> > > > > > (1) Will be used if an RPC asks to synch on start, but it
> > > > > > can't be supported for any reason (e.g., no nodes identifiable
> > > > > > within the selection filter will ever be support on-change
> > > > >
> > > > "Neither synch on start nor resynchonization are supported for
> > > > this subscription.  This error will be used for two reasons. First
> > > > if an 'establish-subscription' RPC doesn't include
> > > > 'no-synch-on-start', yet the publisher can't support sending a
> > > > 'push update' for this subscription for reasons other that
> > > > 'on-change-unsupported' or 'result-too-big'.
> > >
> > > I think that if the idea is that a server may or may not support
> > > sync on start, you should make a feature for it and call the leaf
> > > "sync-on-start" instead.  And OTOH, if the default is sync on start
> > > (as it is now), it should be required to support it.
> 

Synch-on-start should be the default, and should be required for a platform to implement.  

> > > > However a patch must be able to do more than just describe the
> > > > delta from the previous state to the current state.  As per <xref
> > > > target="on-change"/>, it must also be able to identify if
> > > > transient changes have occurred on an object during a dampening
> > > > period.  To support this, it is valid to encode a YANG patch
> > > > operation so that its application would result in a no change
> > > > between the previous and current state.  This indicates that some
> > > > churn has occurred on the object.  An example of this would be a
> patch that does a "create"
> > > > operation for a datastore node where the receiver believes one
> > > > already exists, or a "merge" operation which replaces a previous
> > > > value with the same value.
> > >
> > > is very implicit.  Is it really necessary to be able to indicate
> > > this "churn"?
> > > It seems
> > > If a client needs to know this information, it can just not specify
> > > a dampening period.
> >
> Ok.  (so what do you do if you know that churn has happend, but you have
> no idea what the churn was?)

You will know the node has churned.  You will know the latest change.   If you need to find out more, about the current datastore you can do a get.   If you need to know more about each change, you could check the log.  Applications never could get this type of information efficiently before.

> Depending on the outcome of the filter issue (full XPath/subtree filter vs.
> node-instance-identifier (BTW, will you crete a separate thread for that
> discussion?)), 

If you means Balazs discussion, then yes.

> I will have to come back to this issue.  It seems awfully
> expensive to implement correctly.

For a good view of why this is essential, see slides 29 & 30 of the IETF 96 presentation on subscriptions at:
https://datatracker.ietf.org/meeting/96/materials/slides-96-netconf-5/

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 6 Dec 2017 17:04:44 +0000

I agree with Balazs that we really want this issue to be nailed right form the start.

I would be happy with defining an augmentation to ietf-yang-library to allow devices to return the data on what content is notifiable -on-change not this specific device at the specific time the data was retrieved.

For offline consumption, we should define that an XML document conforming to the XML schema defined by ietf-yang-library + augmentations is an appropriate format. This XML document would have at its root the element ietf-yang-library:modules-state. How this XML document is provided is out of scope. It may be a flat file, it could come from a URL, whatever.

Is this and acceptable approach?

Cheers,

Einar

> On 6 Dec 2017, at 10:32, Balazs Lengyel <[email-masked]> wrote:
> 
> 
> BALAZS: I agree that yang-library is good. I am not arguing against it. Just it is
> - Put all server-capabilities into yang-library (possibly augmenting it where needed)
>     e.g. the data section of a <get> reply This way you don't even have to define a real new format
> - declare that off-line instance data from yanglib is the format to define server capabilities
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Dec 2017 18:24:33 +0100

It probably makes sense to write a document that defines how datastore
content (or subsets of datastore content) in general can be stored in
a file. With that in place, we know how to store ietf-yang-library
content and as a side effect we know how to store datastore content
used as examples for YANG data models and likely several other
purposes. The root of the XML document would like be the datastore
identity name in the YANG module namespace defining the identity

<?xml version="1.0"?>
<operational xmlns="ietf-datastores">
  <modules-state xmlns="ietf-yang-library">
  </modules-state>
</operational>

Right now, it seems I have to feed instance data in slightly different
formats into tools. It would be nice if tools could actually converge
to common formats. [I am particularly interested in validations of
examples.]

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 6 Dec 2017 18:05:07 +0000

Juergen,

Thanks for this. Thanks for picking up that a top level containing element as you have is necessary. Otherwise we would would be limited to a single module, which is not so useful. I don’t think that the top level tag should be “operational”, though. Maybe something more like “<datastore-contents>”?

Cheers,

Einar

> On 6 Dec 2017, at 17:24, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Dec 2017 21:15:43 +0100

Einar,

I like to know which datastore content belongs to, hence I suggested
to use as the toplevel the datastore name (defined as a identity). If
you have content from <running>, the top-level would be

<?xml version="1.0"?>
<running xmlns="ietf-datastores">
</running>

Since YANG library is config false, I picked <operational> as the
top-level for the example.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 6 Dec 2017 23:31:57 +0000

Yes this works too.  Which is one reason both the selection filter and the dampening-period are both modifiable within a single subscription :-)

Eric

> -----Original Message-----
> From: Balazs Lengyel [mailto:[email-masked]]
> Sent: Wednesday, December 6, 2017 5:52 AM
> To: Eric Voit (evoit) <[email-masked]>; Henk Birkholz
> <[email-masked]>
> Cc: [email-masked]
> switch to a very short dampening period with a narrow filter.  Getting the
> information in two steps  sometimes maybe a problem.
> 
> regards Balazs
> 
> 
> > YANG Push does identify that churn has occurred, but not how much
> churn has occurred during a dampening period.   This allows things like
> security applications to know things like temporary ACL changes.  Or things
> like network management systems knowing that there are transient
> outages on an interface.
> >
> > At this point, the thinking is that an application always has the option of
> going to Publisher to get the details of the churn.   Perhaps new drafts could
> also push the quantity of changes which occurred, or a histogram or
> changes, or some other metric.  At this point that topic is unexplored.  But
> there is no reason that such information couldn't be augmented into some
> header associated with the push-change-update record.
> >
> > Eric
> >
> >> Admittedly, I am relatively new to this domain and before I provide
> >> my comment I want to acknowledge that:
> >>
> >> - it is important not to off-load to much complexity to the agents
> >> that are part of the data store
> >> - complex composite devices might create a lot of "noise" in wrt
> >> changes of data node values and that has to be dealt with in a sane
> >> and reasonable way
> >>
> >> That said, YANG Push caught a lot of attention outside of NETCONF. In
> >> a nutshell, it is a solution that provides meaningful telemetry,
> >> which simplifies post-processing of subscribed notifications significantly.
> >>
> >> But - there is always a but, I guess - "visibility" is a key
> >> capability in this context, I think. Yes, there might be oscillating
> >> values, yes, they might be of no value to most post-processing
> >> processes, but to exclude them entirely might reduce the usefulness of
> the on-change capability significantly.
> >>
> >> There is the complementary topic of smart filters that might deal
> >> with providing metadata about this "omitted notifications" (coming
> >> back to the oscillating values example, Alex illustrated), but
> >> visibility of ongoing changes should be supported somehow, I think.
> >> Maybe not in the top level draft that is netconf-yang-push, but at some
> level, I hope.
> >>
> >> Again, this is coming from a fresh pair of eyes still relatively
> >> unfamiliar with the emerging ecosystem around YANG Push.
> >>
> >> In a nutshell, I just want to highlight that visibility of past
> >> changes and dealing with high frequency of changes of course requires
> >> a feasible compromise. But from my POV, "the most recent update"
> might not cut it.
> >> I only want to highlight that fine granular visibility is a vital
> >> characteristic of on-change emission of notifications. Maybe there
> >> can be a knob, as Sue might phrase it.
> >>
> >>> crystal-clear clarification) is that when the notification message
> >>> is sent, it contains the most recent update for that object (i.e.
> >>> the value that is in effect when the update is sent).  If there are
> >>> some quickly oscillating values we don’t send the whole sequence of
> >> updates/values.
> >>> --- Alex
> >>>
> >>> selected by a single subscription and sent to a single receiver.
> >>> This means that when there is a change to a subscribed object, an
> >>> update record containing that object is created either immediately
> >>> when no dampening period is in effect, or at the end of a dampening
> >>> period.  A dampening period is reset every time a new notification
> >>> message is passed to transport.  A dampening period is reset every
> >>> time a new notification message is passed to transport.  A zero
> >>> value indicates no dampening period, and all subscribed object
> >>> changes are sent
> >> immediately."
> >>> almost reverts back to a periodic subscription (since there is
> >>> always going to be a change somewhere). This is why I originally
> >>> argued to have it indeed on a per-object basis, but I lost that
> >>> argument.  For such fine-grained updates, where a client is indeed
> >>> interest in getting delays of individual objects without delay,  a
> >>> client could simply need to establish multiple “micro” subscriptions.
> >>>
> >>> TCAs in RMON are something different altogether.  This is something
> >>> we are trying to address with smart filters.
> >>>
> >>> --- Alex
> >>>
> *Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Dec 2017 09:20:01 +0100 (CET)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> > server MUST
> MUST forces a subscription to be accepted (even with other issues).

Of course not.  If there are other issues like out of resources or
don't support on-change or whatever the subscription must not be
accepted.

> MAY gives the publisher the option of accepting a subscription
> (something it has the right to do with any subscription).

The point is that we need to specify what the expected behavior of a
server is, so clients can code for that.  There are two alternatives:

  1.  this is a required feature that all servers must support

  2.  this is an optional feature.

If 2, how will a client know if the server supports the feature or
not?  Three alternatives:

  2a.  there's a YANG feature (or similar) that informs the client
       about this behavior

  2b.  the client doens't know and will have to guess

  2c.  the server informs the client in a way out of scope of this
       specification.

Personally, I prefer 1.  My reading of the currect document is 2b.

> > time t1
> Agree.  This is a valid case where a publisher chose allowed a
> subscription which might include empty node sets.
>  
> A selection filter need not be designed to explicitly remove nodes
> which are not-notifiable-on-change.  These are automatically removed
> without any knowledge of the filter, and need not be considered by the
> designer of the filter.  (I.e., you can on-change subscribe to
> interfaces, and will never see any counters.)

This behavior is not specified anywhere!  This must be explained.

Ok, so with this behavior I agree "any" is correct. I suggest:

  "This value means that on change is not supported for any node that
   may be selected by the given filter."

> An on-change subscription should not be allow if it is unlikely there
> will be any on-change nodes ever within its domain of selection.
>  
> "Likely to be provided" covers the case of nodes which don't exist as
> the time of subscription, yet appear later.  The "Likely to" is better
> than "Never will" since it is theoretically possible for a system to
> add a lightly protected node deep in a tree.

But in that case it probably should not return this error.

What does "provided through a filter" mean?  I think "selected by
a filter" is easier to understand.

> Synch-on-start should be the default, and should be required for a

At this point, I think I have to see the new draft to be able to
comment further.  I am a bit lost wrt what is required and what is
optional and how that is communicated to the client.

> You will know the node has churned.  You will know the latest change.
> If you need to find out more, about the current datastore you can do a
> get.  If you need to know more about each change, you could check the
> log.  Applications never could get this type of information
> efficiently before.
> 
> > filter vs.

On Tue, 5 Dec 2017 03:02:33 +0000, you wrote:

  I want to generalize this "only-keys?" issue for the full WG.  It is
  too important to handle this deep in the thread.  Look for me to
  open an issue shortly.

That's the issue I was referring to.

/martin

> For a good view of why this is essential, see slides 29 & 30 of the
> IETF 96 presentation on subscriptions at:

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 7 Dec 2017 11:58:00 -0800

Hi -

Regarding the "not ... all" vs "not ... any" vs other alternatives,
and given the emerging desire to provide at least at little support
for systems allowing hot-insertion, etc., there seems to be some
conflict between presumed use cases regarding what would be an "error."

Rather than treating the "no objects (currently) selected" case as
an error, perhaps one might consider providing an operation to query
the number of items selected (at the time of the operation) by an "on
change" subscription which have the instrumentation to support the
generation of the notification.

This would allow both use cases (nothing selected is ok because
we know the information objects of interest will come into being later;
vs. nothing selected is a problem because it means we're confused
about the system's configuration).

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Dec 2017 12:11:08 -0800

> about the system's configuration).
Agreed -- I am not up on this thread but it is never an error for
subtree/XPath
retrieval or NACM data rules if the resulting node-set is empty.

If we had actually designed NETCONF correctly so an rpc-warning could be
returned, this would be a good use-case for a server warning. (Maybe
NETCONF 2.0).

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 7 Dec 2017 22:52:12 +0000

Hi Martin,

> From: Martin Bjorklund, December 7, 2017 3:20 AM
> 
> Hi,
> 
> > > > > > location where there might plausibly be objects someday.
> > > > > > (E.g., maybe where an interface might appear; even if there is
> > > > > > no such interface currently
> > > > > > existing.)
> > > > >
> > > > > I think the spec needs to be clear if servers are required to
> > > > > allow filters to cover non-existing nodes or not (I think it should).
> Of course not.  If there are other issues like out of resources or don't
> support on-change or whatever the subscription must not be accepted.
> 
> The point is that we need to specify what the expected behavior of a server
> is, so clients can code for that.  There are two alternatives:
> 
> If 2, how will a client know if the server supports the feature or not?  Three
> alternatives:
> 

We really are not far apart.  Here is my view...  

It is mandatory that a publisher have the ability to handle selection filters referencing non-existent datastore nodes.   It is not mandatory that a publisher MUST accept at least one instance of such a request.  In fact I don't believe it is advantageous for us to define and expose such support as a 'feature' as it would be very hard to provide a subscriber with definitive guidance on where in various subtrees this might be attempted.    

As an example, for which users should a publisher allow subscription to:
(From RFC-7317)
            +--rw authentication
   --->        +--rw user* [name]
                   +--rw name        
                   +--rw password?   

Per the draft for any unauthorized user, the proper response would be the error identity "data-unavailable".    However for a system administrator, it might be ok to allow such a subscription.

As a result of this, the text I propose is:
"A publisher MUST allow for the possibility that a subscription's selection filter references non-existent or access-protected data...   A publisher MAY choose not to allow a particular subscription which selects non-existent or access-protected data."   

The latest draft version has placed these as the lead sentences in two sequential paragraphs.   (See link to draft version below)

> This behavior is not specified anywhere!  This must be explained.

New wording has been added to the bottom of the "Datastore Selection" section:

"When the set of selection filtering criteria is applied for periodic subscription, all selected datastore nodes for which a receiver has access are provided to a receiver. If the same filtering criteria is applied to an on-change subscription, only the subset of those datastore nodes supporting on-change are provided.  A datastore node which doesn't support on-change is never sent as part of an on-change subscription's "push-update" or "push-change-update"."

>    may be selected by the given filter."

Made it:
"On-change is not supported for any objects which are selectable by this filter."

My text was allowing for the possible but unlikely.  I am fine with removing this ambiguity via the text proposal below:

> What does "provided through a filter" mean?  I think "selected by a filter" is
> easier to understand.

Changed to:
"On-change is not supported for any objects which are selectable by this filter."

> > > > > > > > >         "On-change synch-on-start and resynchonization
> > > > > > > > > not
> > > > > supported.";
> > > > > > > > >     }
> > > > > > > > >
> > > > > > > > can't be supported for any reason (e.g., no nodes
> > > > > > > > identifiable within the selection filter will ever be
> > > > > > > > support on-change
> > > > > > >
> > > > > > this subscription.  This error will be used for two reasons.
> > > > > > First if an 'establish-subscription' RPC doesn't include
> > > > immediate time.  Or there are too many subscriptions pulling
> > > > counters or routing tables or MAC addresses from a specific line
> > > > card.  Or other platform wide issues which shouldn't fall under 'result-
> too-big'
> > > > > sync on start, you should make a feature for it and call the
> > > > > leaf "sync-on-start" instead.  And OTOH, if the default is sync
> > > > > on start (as it is now), it should be required to support it.
> > >
> At this point, I think I have to see the new draft to be able to comment
> further.  I am a bit lost wrt what is required and what is optional and how
> that is communicated to the client.

https://github.com/netconf-wg/yang-push/blob/master/draft-ietf-netconf-yang-push-12.txt

I believe this version contains the results of the dialogs from this thread.  But not including the scrub of examples, the error discussion which just resolved, and the items which will become numbered issues.

Eric
 
> > > > > > delta from the previous state to the current state.  As per
> > > > > > <xref target="on-change"/>, it must also be able to identify
> > > > > > if transient changes have occurred on an object during a
> > > > > > dampening period.  To support this, it is valid to encode a
> > > > > > YANG patch operation so that its application would result in a
> > > > > > no change between the previous and current state.  This
> > > > > > indicates that some churn has occurred on the object.  An
> > > > > > example of this would be a
> > > > > > already exists, or a "merge" operation which replaces a
> > > > > > previous value with the same value.
> > > > >
> > > > > Hmm, I think that this is a very strange way to indicate
> > > > > "churn", it is very implicit.  Is it really necessary to be able
> > > > > to indicate this "churn"?
> > > > > It seems
> > > > > If a client needs to know this information, it can just not
> > > > > specify a dampening period.
> > > >
> > > > Both the SACM and I2NSF WGs have indicated need.  It is also
> > > > highly useful for Network Management applications which simply
> > > > cannot get a continuous stream of interface flaps.  This is a
> > > > highly advantageous capability and I have quite a few customer
> requests for this.
> > >
> > > node-instance-identifier (BTW, will you crete a separate thread for
> > > that discussion?)),
> >

Yes, this is soon to be a numbered issue.

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 8 Dec 2017 00:03:03 +0000

Hi Andy,
Hi Randy,

From: Andy Bierman, December 7, 2017 3:11 PM

On Thu, Dec 7, 2017 at 11:58 AM, Randy Presuhn <[email-masked]<mailto:[email-masked]>> wrote:
Hi -

<Eric>  I am hoping that the all/any & must/may discussions is resolved with the latest wording tweaks.   We will see...

Rather than treating the "no objects (currently) selected" case as
an error,
<Eric> This is not (necessarily) an error.  The subscription is only rejected with an error if the publisher determines that there will never be a conceivable case where the filter will return objects.   This is a valid response, because it allows subscription to non-existent objects, and also allows the publisher to reject a subscription when there will never be anything selected.
perhaps one might consider providing an operation to query
the number of items selected (at the time of the operation) by an "on
change" subscription which have the instrumentation to support the
generation of the notification.
<Eric> If you can do a GET operation which is able to also able to retrieve just the on-change notifiable objects, this should also accomplish something useful pre-subscription.

Agreed -- I am not up on this thread but it is never an error for subtree/XPath
retrieval or NACM data rules if the resulting node-set is empty.

<Eric> Agree

If we had actually designed NETCONF correctly so an rpc-warning could be
returned, this would be a good use-case for a server warning. (Maybe NETCONF 2.0).

<Eric> That would have helped here for sure.

Eric

Randy

Andy

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 7 Dec 2017 21:30:20 -0800

Hi -

On 12/7/2017 4:03 PM, Eric Voit (evoit) wrote:
...
>     <Eric> This is not (necessarily) an error.  The subscription is only
>     rejected with an error if the publisher determines that there will
>     never be a conceivable case where the filter will return objects.  

In my experience developers are really bad at putting together logic
which can accurately make a determination of "will never be a
conceivable case".  This is particularly true of systems which
permit software upgrades/installations without requiring a reboot,
and of systems permitting hot insertion of (upgraded) line cards.
The "inconceivable" happens with about every third software update.
:-)

>     This is a valid response, because it allows subscription to
>     non-existent objects, and also allows the publisher to reject a
>     subscription when there will never be anything selected.

An accurate determination of "never" can be a dicey proposition.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Dec 2017 08:45:56 +0100

> Per the draft for any unauthorized user, the proper response would be the error identity "data-unavailable".    However for a system administrator, it might be ok to allow such a subscription.

What exactly is 'authorized user' here? I would expect that access to
data is controlled by NACM. A subscription to 'user' may be valid for
everybody (who is allowed to create a subscription) but access to
'user' data may be prohibited by NACM, i.e., the subscription never
returns data for some clients. Note that NACM rules can change
independently of the subscription (hence it is difficult to reject a
subscription on the ground there is _currently_ no access to data
under 'user').

In draft-ietf-netconf-yang-push-11.txt I read:

   A publisher MAY alternatively choose not to allow subscriptions which
   select non-existent or access-protected data.  Such a capability
   enables the publisher to avoid having to perform filtering of
   authorized content on each update.

   Then there is text following I do not know how to read:

     [...] Relevant scenarios here include:

      o  the rejecting of a subscription request to access-protected
         objects,

      o  the suspension of a subscription where new access-controlled
         objects are selected mid-subscription for which the receiver does
         not have the necessary authorization, or

What is this telling me? What do these 'relevant scenarios mean'? I
think we need to settle on clear definition of behaviour instead of
having descriptions of scenarios that someone needs to map to
behaviour of objects.

I also find the following text unclear. And this strikes me as odd:

   If read access into previously accessible nodes has been lost due to
   a receiver permissions change, this SHOULD be reported as node
   'delete' operations for on-change subscriptions.

Are you telling a subscriber that data was deleted while in fact only
access to it has been restricted? I think there is a huge difference
between these.

Then later I read this:

   If the access control permissions on subscribed YANG nodes change
   during the lifecycle of a subscription, a publisher MUST either
   transparently conform to the new access control permissions, or must
   terminate or restart the subscriptions so that new access control
   permissions are re-established.

Why is there not a single behaviour?

Frankly, a spec that says an implementation MAY to A but it also MAY
do not A is not really helpful. How do I know whether an
implementation does A or not A? ("MAY allow subscriptions which select
non-existent or access-protected data" and "MAY alternatively choose
not to allow subscriptions which select non-existent or
access-protected data").

I think the document should converge to a single set of rules that
give us interoperability and the text touching on authorization needs
to be streamlined and consistent throughout the document(s).

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 8 Dec 2017 14:41:24 +0000

Hi Randy,

> From: Randy Presuhn, December 8, 2017 12:30 AM
> 
> Hi -
> 
> In my experience developers are really bad at putting together logic which
> can accurately make a determination of "will never be a conceivable case".
> This is particularly true of systems which permit software
> upgrades/installations without requiring a reboot, and of systems
> permitting hot insertion of (upgraded) line cards.

Exactly!     To all your points above.

This is why a few days ago I floated the words "not likely".  But this inexactness was seen as confusing to implementers.

No matter what words are chosen, the good news is that:

(a) any decision to aggressively reject subscriptions which later prove interesting will cause requests from customers to vendors to improve their implementation, and

(b) any decision to aggressively allow subscriptions for subtrees which (almost certainly) will never have objects pushed will waste subscription's worth of  CPU/memory.  But shouldn't impact much else.

So to me this is a classic feature coverage and platform scale optimization which will play out over time.

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 8 Dec 2017 20:01:49 +0000

Hi Juergen,

> From: Juergen Schoenwaelder, December 8, 2017 2:46 AM
> 
> > Per the draft for any unauthorized user, the proper response would be the
> error identity "data-unavailable".    However for a system administrator, it
> might be ok to allow such a subscription.
> 
> What exactly is 'authorized user' here? I would expect that access to data is
> controlled by NACM. A subscription to 'user' may be valid for everybody
> (who is allowed to create a subscription) but access to 'user' data may be
> prohibited by NACM, i.e., the subscription never returns data for some
> clients. Note that NACM rules can change independently of the subscription
> (hence it is difficult to reject a subscription on the ground there is
> _currently_ no access to data under 'user').

An operator likely won't want to allow everyone who can subscribe to *somewhere* on a publisher to the ability to place a continuous subscription to 'user'.   Even if it wasn't a possible new vector for security leakage, it would needlessly consume resources.  

It makes sense to provide an implementer the option of denying such undesirable subscriptions up front.

> What is this telling me? What do these 'relevant scenarios mean'? I think
> we need to settle on clear definition of behaviour instead of having
> descriptions of scenarios that someone needs to map to behaviour of
> objects.

I see your point.  There are actually two cases in the examples.  The first bullet refers to denying an establish-subscription request.  The second and third bullets provide the publisher the option of terminating a subscription should access permissions change in a way impacting the subscription.

How about the following...

A publisher MAY choose reject an establish-subscription request which selects non-existent or access-protected data. In addition, a publisher MAY choose to terminate a dynamic subscription or suspend a configured receiver when the authorization privileges of a receiver change, or the access controls for subscribed objects change.  Such a capability enables the publisher to avoid having to support a continuous, and total filtering of an entire subscription's content.
 
> Are you telling a subscriber that data was deleted while in fact only access
> to it has been restricted? I think there is a huge difference between these.

This is absolutely true.  But differentiating these from the point of view of the receiver gives unwanted insights to access control permissions.  Therefore the definitions of what 'delete' is within the patch have been framed so receiver will not know which of these two have happened.    I.e., the patch only promises to allow a receiver to maintain a current extract of a subscribed datastore.  It does not promise to show what operations have occurred on that datastore.

> Why is there not a single behaviour?

Basically because there are YANG Push implementers who are active in NETCONF whose implementations cannot perform the changing of permissions during a subscription.  Therefore the text: "or must terminate or restart the subscriptions so that new access control permissions are re-established" was added to allow those implementations to achieve the overall security filtering objective without having to touch their access control filtering code.    We could delete this text block, but it would simply irritate those vendors who would rather be able to claim some reasonable form of security compliance.

> Frankly, a spec that says an implementation MAY to A but it also MAY do
> not A is not really helpful. How do I know whether an implementation does
> A or not A? ("MAY allow subscriptions which select non-existent or access-
> protected data" 

Per other parts of this thread, text has been updated to show that a publisher MUST be able to accept subscription requests for non-existent nodes, and MAY choose to reject such requests if there is no chance that the subscription will result in pushed data.  This is both useful and efficient for everyone.

> and "MAY alternatively choose not to allow subscriptions
> which select non-existent or access-protected data").
> 
> I think the document should converge to a single set of rules that give us
> interoperability and the text touching on authorization needs to be
> streamlined and consistent throughout the document(s).

I will continue to do my best in refining the words.   The new version due out shortly should have some improvements driven very much by the excellent comments made in this thread.

Eric

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Sun, 10 Dec 2017 15:45:37 +0000

Juergen,

I agree that knowing the source makes sense, and I didn’t read the text surrounding your example correctly, apologies. This approach is fine with me.

Cheers,

Einar

> On 6 Dec 2017, at 20:15, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Einar,
>