Balazs Lengyel writes:
I wonder how Juniper solved this? They had Junos-script and operational mode commands like
ping for a long time.
We do operational commands as simple RPCs, like:
<ping>
<host>10.1.2.3</host>
<count>5</count>
<no-resolve/>
<interval>4</interval>
<wait>10</wait>
</ping>
We avoid putting actions as attributes of data. This was done
primarily as the Junoscript API (and our netconf implementation)
leverages the existing plumbing of the UI. The above RPC is
the equivalent of the CLI command:
ping 10.1.2.3 count 5 no-resolve interval 4 wait 10
I continue to believe that netconf will fail if it becomes the
"third way" (where first=cli and second=snmp). This was discussed
at length in the prelude to netconf's creation. One of our goals
was allowing the vendor to reuse their cli implementation to the
greatest extent possible.
Given the overwhelming use of syslog and snmp to handle notifications
in the current service provider world, the idea of netconf rolling
its own notification mechanism seems to swim against this logic.
We started this notification discussion with the idea of just
carrying syslog messages over a beep channel using an existing
standard. Have we wandered to far from this idea of reusing something
that's already there? Will folks really revisit their entire source
code tree and code every syslog call or snmp trap creation to
generate netconf events?
Thanks,
Phil