[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

David T. Perkins wrote:

HI,



thanks for this email Dave.
I think it helps a lot.
Your diagram gets to the architecture issue that
Dave H> and I have raised.
but I don't see the key distinction as off-box or on-box,
or historical vs. live events.


IMO, if you change "off-box" to "traditional syslog service"
(NV-configured syslog feature on a NE device) and "on-box"
to "netconf session",  it represents the real architecture
that is going to be present in the agent:



                                  traditional
      +----+              ------->delivery via
      | c1 |---+         /        syslog protocol
      +----+   |    +------+
      +----+   |    |      |
      | c2 |   +--->|syslog|  netconf    +-------+     +-------+
      +----+   |    |daemon|  session    |netconf|<--->|netconf|
       ...     |    |      | ----------> |server |     |client |
      System   |    +------+  delivery   +-------+     +-------+
     Components|        |                  //
       ...     |        |                 //
      +----+   |        |       (------------)
      | cn |---+        |       (notification)
      +----+            +-----> (  logging   )
                                (  service   )
                                (------------)





I'd like to reinforce my previous message with some
tweeks to the conceptal model found in Phil's document.
(Yes, already I've lost half or more of the readers.)

There is the unmodified figure from section 2.1:

     +----+
     | c1 |---+
     +----+   |    +------+                        (off-box)
     +----+   |    |      |
     | c2 |   +--->|syslog|          +-------+     +-------+
     +----+   |    |daemon|--------->|netconf|<--->|netconf|
      ...     |    |      |         >|server |     |client |
     System   |    +------+        / +-------+     +-------+
    Components|          \        /
      ...     |           v      /
     +----+   |         (----------)
     | cn |---+         (historical)
     +----+             (  events  )  (e.g. log files)
                        (----------)

And here it is with a few modifications that change how
you might want to look at it:
off-box +----+ ------->collection of 
     | c1 |---+         /        "syslog servers"
     +----+   |    +------+                        (off-box)
     +----+   |    |      |
     | c2 |   +--->|syslog|          +-------+     +-------+
     +----+   |    |daemon|          |netconf|<--->|netconf|
      ...     |    |      |         -|server |     |client |
     System   |    +------+        />+-------+     +-------+
    Components|          \        //
      ...     |           v      v/
     +----+   |         (----------)
     | cn |---+         (collection)
     +----+             (of on-box )
                        (log files )
                        (----------)

The configuration for the syslog daemon is the
addresses of the off box syslog servers, and
the on-box "logs", and the filtering to apply
before sending to a syslog server or saving
in a log. The document calls each paired
target and filter an "event stream". 
I see setting up the event streams as
configuration. However, I see that getting
syslog data as monitoring status (and
state).

If you compare the two pictures, you will notice
that there is no longer a direct connection
between the syslog daemon and the netconf server.
I did this to clarify that getting syslog
data via netconf was a "monitoring" operation
and not a "configuration" operation.
Note that the event streams may be filtered
before saved in a log file, and that data
from a log file may be filtered before
it is returned to the netconf client.

Now it seems like what is being argued about
is how to specify a filter for a monitoring
operation. And this could be done in two
ways. First, one could configure named filter
expressions on the system. Then when a
monitor operation was started, it could specify
the name of an existing filter expression.
Secondly, one could allow a monitor operation
to specify an unnamed filter expression as
a parameter to the monitor operation.

I believe that either one provides the same result.

Hope this helps.

Regards,
/david t. perkins


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