Re: draft-shafer-netconf-syslog-00.txt

[Andy Bierman <ietf@andybierman.com>]

>..
> >   
> A few comments and questions:
>
> I don't really understand the design choice of the get-syslog-streams 
> operation because I think it breaks the idea of the get-config operation.
> IMHO, even if it is feasible and allowed by Netconf, nothing here 
> justifies the need of a new operation.
> >
...

I agree with you.
I don't understand how specialized <get> functions for standard data
really helps here.  It sure can't be because there are so many
standard data models for netconf that specialized <get> functions
help us navigate the vast quantity and complexity of this data.

I also don't understand the obsession with calling everything
"subscription data" instead of "configuration data", and insisting
that NV-storing this subscription data is not important, not useful,
or not "simple enough" for the manager to use.

IMO, this problem is pretty simple:

 * Use configuration data and standard existing RPCs to set and get
   the notification generation parameters, what has been called a
   "profile" and now called a "stream"

 * Use a special RPC to start generation of notifications,
   which has a parameter to indicate the stored profile to use.

 * Some parameters like "retrieve since time N" are session-specific,
   and belong only in the RPC, not the config (obviously).  Some
   parameters like "get me the next 3804 notifications" seem pretty
   complicated and not very useful.  I prefer only 1 mode:

     - get since time N (or sequence-id X) and keep going until the session
       is shut down


> Regards,
> Vincent
>
>
> > Thanks,
> >  Phil


Andy

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