[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
I am on the move, thus brief.
I think Sharons comment below applies to netconf-syslog as well: Streams need to be configured somewhere, so I think they are nv config data. Thus, querying should be done via get. A data model, of course, is required, but netconf-syslog should be a good starting point for that.
Polling the events (get-syslog-events) IMHO naturally asks for a verb and seems unnatural via get.
Rainer
--- Sharon Chisholm, 2006-06-22 on netconf notifications ---
I think you are missing the point.
Balazs and I are not saying that a verb to start
the delivery of notifications is a problem.
I totally agree with this approach, rather
than the SNMP MIB approach of turning the knob
to 'enabled' in the data model. Let's get past this point, okay?
The problem is that many of the parameters
(especially the most complicated part -- the filters)
should be implemented as a read-create standard
data model using the existing <edit-config> operation,
and retrieval of these parameters and notification
state information should be done with the <get> operation.
---------
----- Ursprüngliche Nachricht -----
Von: "Andy Bierman" <ietf@andybierman.com>
An: "Phil Shafer" <phil@juniper.net>
Cc: "Sharon Chisholm" <schishol@nortel.com>; "netconf@ops.ietf.org" <netconf@ops.ietf.org>
Gesendet: 27.06.06 19:36
Betreff: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
Phil Shafer wrote:
What vendors do with their proprietary CLI/XML data models
does not have a significant impact on what the IETF
or this WG should do wrt/ standard data models.
One significant operator requirement that came out
of RFC 3535 is that the entire device configuration
and state information could be retrieved as a whole tree,
or portions of the tree could be retrieved, in a single operation.
The concept of an ad-hoc collection of specialized RPCs
used INSTEAD of standard data models and standard operations
does not meet this requirement.
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.
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.
Andy
> Andy Bierman writes:
>> I think that managing 100s or 1000s of <get-foo> and
>> even <set-foo> functions, which ignores the <candidate>,
>> <running>, <startup> model variants, ignores <edit-config>,
>> and does not show up at all when I do a <copy-config>,
>> <get-config>, or <get> operation -- is a fairly broken design.
>
> I don't think it's broken at all. I think this is the point of using
> an RPC-based design. There are two reasons that I think this is a
> win. First, it's a better match for applications. More specific
> information in the API makes it a better API, both more readable and
> more easily implemented. Your unix program doesn't get filesystem
> information using get() or even ioctl(). It uses statfs() to get this
> data. It's a direct, easily documented mechanism for getting
> this particular content. The same is true for RPCs. I'd rather have:
>
> $results = $dev->get_syslog_streams();
>
> than:
>
> $results = $dev->get("netconf/notifcations/config/whatever");
>
> (or worse, having to build the xml object)
>
> It's similar to calling read() verses calling syscall() with the SYS_read
> system call number.
>
> Second, we're not making a green field solution. Device vendors have
> a ton of code supporting existing CLI commands, all brimming with
> information accessible via the command line. So I go in and make a
> <rpc-name> to "command line" mapping, and get all the fancy command
> line arguments, types, ranges, help strings, etc for free. All this
> is fairly trivial code.
>
> But to do this scoped generic stuff, I need to understand a _whole_
> lot more about the output of the commands, including not only which
> commands make which output tags, but which _options_ to those
> commands make the output. "show interfaces extensive" .vs. "show
> interfaces statistics". This is an immense pain.
>
> I'd basically have to build a completely new management system. I've
> said it before, but I continue to believe that netconf will fail if it
> becomes the "third way" (where first=cli and second=snmp). In the
> real world, the CLI gets implemented first, then SNMP (first
> proprietary MIBs, then standard MIBs). A completely disjoint netconf
> implementation will a distant third. We need to maximize the leverage
> we can get off the existing implementations, not become the third way.
>
> 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.
>
> In addition, the use of explicit RPCs gives you explicit arguments,
> which you need (or may need in the future) to refine the information
> retrieved. Or you may want your API for retrieving data to match the
> API for manipulating it, in the same way the <source> parameter for
> <get-config> matches the <source> parameter for <lock-config>,
> <unlock-config>, <edit-config>, <validate>, etc.
>
> 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/>
--
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/>