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

[Robert Wilton <[e-mail]>]

Hi Tim,

Please see comments (as a non author) inline ...


On 29/08/2018 16:28, Yutianpeng (Tim) wrote:
>
> 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.
>
I'm not keen on this change.  This does not seem like a good separation 
of concerns.  Besides, I'm not convinced why this should really be a 
performance issue given that config changes are relatively rare compared 
to all the operational state in the system that may be changing.

> -----------------------------
>
> Both “subscriber” and “receiver” are used, bit confusing sometimes. 
> Shall we only use “subscriber”
>
They are different entities, the definitions are in 
draft-ietf-netconf-subscribed-notifications:

    Receiver: A target to which a publisher pushes subscribed event
    records.  For dynamic subscriptions, the receiver and subscriber are
    the same entity.

    Subscriber: A client able to request and negotiate a contract for the
    generation and push of event records from a publisher.  For dynamic
    subscriptions, the receiver and subscriber are the same entity.



> ------------------------
>
> 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.
>
I don't think that this is how the dampening that is currently defined 
should work, since it is expected to provide a strong guarantee that it 
will either deliver the notifications to the receiver, or otherwise 
notify to the receiver that some updates [may] have been lost.

I could imagine that another, softer type of dampening, could 
potentially be defined in future as a separate extension/augmentation, 
but I don't think that should go into this document, because it would 
massively slow it down, and the industry already needs this standard now.

> -----------------------------
>
> It would be appreciated if suggestions can be given on how push shall 
> be used on running, startup and candidate datastores
>
It should work the same way as YANG push on any other datastore. The 
mechanism described in the draft seems to be entirely datastore 
agnostic.  In what way do you think it may behave differently?

Although I could imagine that implementations may not support 
subscriptions on startup or candidate, in which case I would expect that 
the subscription would be rejected.

Thanks,
Rob


> -------------------------------
>
> Regards,
>
> Tim
>
>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf