Re: [Netconf] Comments on draft-ietf-netconf-yang-push-18

[Alexander Clemm <[e-mail]>]

Hello Tim,

replies below, <ALEX>

Thanks
--- Alex

From: Netconf [mailto:[e-mail]] On Behalf Of Yutianpeng (Tim)
Sent: Wednesday, August 29, 2018 8:28 AM
To: [e-mail]
Subject: [Netconf] Comments on draft-ietf-netconf-yang-push-18

Hi,
Some comments as below:

------------------------------
There is one point missing in the draft so far I think: what if the subscriber is the initiator of the configuration changes?
In this case, the subscriber is aware of configuration changes initiated by itself without relying on the push mechanism. Introducing push mechanism will dramatically impact the performance of the system in this case.
My suggestion is:
3.3.  On-Change Considerations
   5.  If the resulting patch record is non-empty, and it contains the records not initiated by the subscriber, select these records and send to corresponding subscriber.
We can have further discussion on this to make it optional instead of mandatory.

<ALEX>
Regarding automatic filtering of updates that concern configuration which was initiated by the same entity that has the role of receiver:  This would add significant complexity and very little actual gain.  For one, it is up to the subscriber to decide what information is of interest, and the receiver will be able to easily apply logic to differentiate updates concerning changes that it had initiated itself versus other changes.  Perhaps more importantly, there may be value to the receiver in receiving those updates as an additional validation/verification mechanism; who are we to second-guess the intention of the subscriber?  By filtering out some updates but not others, it will also be very hard to use the update records as a history log or "audit trail", which would require combining responses to configuration change / edit requests and update records.

In short, I do not think that this is a feature that should be introduced.  If it turns out this is of importance to someone after all, they are free to augment the model with a new filter type whose effect will be to ignore certain updates.
</ALEX>

-----------------------------
Both "subscriber" and "receiver" are used, bit confusing sometimes. Shall we only use "subscriber"

<ALEX>
Subscriber and receiver are different roles.  The subscriber is the entity that initiates the subscription, the receiver is the recipient entity for the updates.  Of course, both may be the same system.
</ALEX>

------------------------
3.11.1.  Robustness and reliability
   Note: It is perfectly acceptable to have a series of "push-change-
   update" notifications (and even "push update" notifications) serially
   queued at the transport layer awaiting transmission.  It is not
   required to merge pending update records.  I.e., the dampening period
   applies to update record creation, not transmission.
My suggestion is:
The publisher should increase dampening period automatically in case the message queue reaches a limit.
This is to avoid notifications lost due to queue limit in case subscriber is busy or temporarily unreachable.

<ALEX>
Again, this is an additional feature that we should not introduce at this point.  If one were to introduce it, there would be various additional ramifications, such as increased delay to let receivers know that some information has changed/ updates have happened, which may in many cases not be acceptable (with the dampening period being gated by the longest acceptable delay in reporting an update).  In addition, receivers would need to be informed of changing dampening periods.  Any benefits are not worth the additional complexity (not just for publishers, but for receivers) IMHO.
</ALEX>


-----------------------------
It would be appreciated if suggestions can be given on how push shall be used on running, startup and candidate datastores

<ALEX>

This is part of the model and specified at configuration respectively establishment of the subscription.  Defined in grouping datastore-criteria, which includes

      leaf datastore {

       type identityref {

         base ds:datastore;

       }

       mandatory true;

       description

         "Datastore from which to retrieve data.";

    }

</ALEX>
-------------------------------

Regards,
Tim