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

["Yutianpeng (Tim)" <[e-mail]>]

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.

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

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

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

-------------------------------

Regards,
Tim