Subject: AW: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 27 Jun 2006 19:54:32 +0200

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" <[email-masked]>
An: "Phil Shafer" <[email-masked]>
Cc: "Sharon Chisholm" <[email-masked]>; "[email-masked]" <[email-masked]>
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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 28 Jun 2006 19:39:36 +0300

> -----Original Message-----

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

(speaking as a contributor)

This seems to me contrary to the principle of separation between
protocol operations and data models, which - if I read the Charter - is
one of the basic design principles in Netconf. 

'The Netconf protocol should be independent of the data definition
language and data models used to describe configuration and state Data.'

Dan