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

[Andy Bierman <[e-mail]>]

On Tue, Sep 4, 2018 at 8:22 AM, Robert Wilton <
rwilton=[e-mail]> wrote:

> 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.
>
>
+1 -- this change should not be made.
This is not a useful optimization.



>
>
> -----------------------------
>
> 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.
>
>
+1 -- the server does what it is told and does not decide to change the
subscription on its own



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

Andy


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