Phil Shafer wrote:
Andy Bierman writes: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.I don't understand this comment wrt my draft.
I prefer to use <edit-config>, <get-config>, and standard data models to configure aspects of this feature such as filtering parameters. Sharon started in the right direction with a data model, but just for monitoring. IMO we should really get out of the SNMP and CLI mindset that standard data models for configuration are either too hard or too proprietary for the IETF to touch. The notion that CLI is all "special command driven" and not actually data is not really true. ACLs, Dialer plans, static routes, etc. are all NV-stored data. (Imagine how well ACLs would work if there were none until the root user logged in and "configured" them all with RPC calls. ;-) Andy
The draft's model is that the device defines a set of streams. This is not subscription data, nor necessarily configuration data. What I like is that it gives the device control over what applications can see, and prevents applications from asking for everything if the admin denies it. The stream approach also gives a recording mechanism (the device records each stream, not all events) so that an application user can hit the "what went wrong" button and see a list of recent messages, possibly from before the application was launched.* 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 downThe two main scenarios I see are monitoring a stream and viewing the recorded data from a stream. Both are important facets of how syslog events are handled today. It's a "more" .vs. "tail -f" issue. ;^) 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/>