[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
Phil Shafer wrote:
Andy Bierman writes:
Unless standard data shows up in exactly the same place,
with the same syntax and same semantics, using the <get> operation,
then it isn't a standard that meets this requirement.
Does <get-config> pass that test?
Data model discovery becomes quite a nightmare if a manager
has to know priori, each different set of special RPCs to
use for every device it manages, and try them all to discover
the entire device configuration and state.
Yes, this is a hard problem. But thinking that all devices will
instantly converge on a new standard data model won't fly.
This is where we strongly disagree.
If they want to conform to the standard "notification" capability,
then they will do everything that is specified, including
implementing the tiny standard data model in the spec.
I will be even more clear -- the standard data models
for netconf will be usable with the existing standard netconf
operations. I doubt the co-Chairs and ADs will except
a solution that did otherwise.
If the data is particularly complicated (e.g., deeply
nested data structures with complex keys), then special
RPCs in ADDITION to the standard RPCs may be useful,
which do not redefine data, but rather simplify access to
the nested data instances within the overall target data model.
In this case, I don't think the notification data is complicated
enough to warrant additional special RPCs, but we haven't finalized
the data model at all, so who knows right now.
Andy
The
difference between the model and the device can be ignored or painted
over for monitoring (ala SNMP MIBs) but when you move into
configuration, it's the details that matter.
So my proposal is to fly little fish first. If your application
wants to get notification data, it has to know a priori that it
gets the list of streams via one RPC and gets the notification data
via another RPC. Come to think of it, even if you had all this
hidden under <get>, your application would still have to know the
magic filter to pass in to get the list of streams and the magic
filter to pass in to get the notification data. The difference is
whether you put this knowledge in the RPC (name and arguments) or
the filter's XML content (and the schema that defines it).
Thanks,
Phil
--
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/>