[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: requirement: agent initiated session support



<Andy>

Good luck with your model in an actual network after a power outage. In
the subscribe model, none of the agents can send any notifications until
a manager connects to them and asks for notifications.  The startup
notifications are critical to have, to check for any config/image/HW
mismatches that occurred during boot-up.
</Andy>

If a tree falls in the forest ... what's the point of someone sending
out notifications if no one is listening to them? How exactly would that
work in the absence of a Netconf session anyways? (Note that on-device
logging and replay works fine with non-persistent subscriptions)

<Andy>
IMO, this approach is complicated -- not the traditional model. There
will probably be 2 or 3 tables, not 100. I never said "over-engineer it
to death" like SNMP did.
</Andy>

How is not requiring persistency more complicated?

Yes, there are always ways to keep things simple in theory. My favourite
is that if we do decide to allow persistency, that we also keep the
command line options. 

Sharon
=



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>