[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Tweeks to draft-shafer-netconf-syslog-00.txt
I have made two other slight modification to the diagram:
1. I have removed the term "traditional", because that sounds like
it implies that only RFC 3164 syslog is supported. As far as I see
it, netconf-syslog can support any flavor of syslog, including the
upcoming standards.
2. I have added SYSLOG delivery on the receiving side of the
syslog daemon.
delivery
+----+ ------->via syslog
| c1 |---+ / protocol
+----+ | +------+
+----+ | | |
| c2 | +--->|syslog| netconf +-------+ +-------+
+----+ | |daemon| session |netconf|<--->|netconf|
... | | | ----------> |server | |client |
System | +------+ delivery +-------+ +-------+
Components| | //
... | | //
+----+ | | (------------)
| cn |---+ | (notification)
+----+ | +-----> ( logging )
| ( service )
delivery | (------------)
via syslog ---+
protocol
Rainer
> -----Original Message-----
> From: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Thursday, June 22, 2006 11:57 PM
> To: David T. Perkins
> Cc: netconf@ops.ietf.org
> Subject: 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/>
>
--
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/>