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

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

If I understood the spirit of the previous diagrams right, then how
about that:

                                     remote
       +----+             --SYSLOG-->syslog
       | c1 |---+        /           receiver
       +----+   |    +------+
       +----+   |    |      |
       | c2 |   +--->|syslog|       +-------+           +-------+
       +----+   |    |server|       |netconf|<-NETCONF->|netconf|
        ...     |    |      |------>|server |           |client |
       System   |    +------+       +-------+           +-------+
      Components|     ^  |              ^
        ...     |     |  |              |
       +----+   |     S  |              v 
       | cn |---+     Y  |      (------------)
       +----+         S  +----->(notification)
                      L         ( repository )
                      O         (------------)
       remote         G
       syslog --------+
       sender

Arrows with protocol names indicate message transport via the named
protocol. Arrows without names use no specific protocols and may be
internal APIs. SYSLOG terminology (sender, receiver) is defined in
draft-ietf-syslog-protocol-17. The arrow between the "netconf server"
and the "notification repository" indicates that the netconf server
accesses the repository. The arrow between "syslog server" and
"notification repository" indicates that the syslog server submits data
to the repository but is not expected to pull any data out of it. The
data flow shown is informative, only. It does not demand any specific
implementation.

Some more points:

1. I have changed the "notification logging service" to "notification
repository". IMO, the important point is that there is a repository for
notifications. In actual software, I'd expect this to be a data store
which is written by the syslogd and read by the netconf server. It could
(should?) also be written to (configured) by the netconf server (e.g.
expiration of log data, access policies). It could be discussed if the
netconf server should have other write capabilities (e.g. delete
events), but I think this is irrelevant wrt this draft).

2. I have replaced the term "syslog daemon" by "syslog server". Though
the former is well-known, the later is more generic and
platform-independent.

3. One word on the relationship of the syslog to the netconf
server.There is no pure syslog or pure netconf server on either side. A
pure syslog server can not talk netconf to a netconf server because it
does not know about that. Actually, I would expect both of them to be
inside a single app (at least from the architecture point of view),
talking to each other via API, local RPC or simple internal function
calls. Something like this:

                  +---------------------------+
                  |  syslog/netconf app       |
                  |  +------+      +-------+  |        
           --SYSLOG->|syslog|      |netconf|<-NETCONF->
                  |  |server|-API->|server |  |        
                  |  +------+      +-------+  |
                  +---------------------------+

One might now argue that this is the reason that all events should go
through the the event repository. IMHO this is not a practical option as
we would like to see realtime delivery. In any case it is nothing that
happens on the wire, so it is out of the scope of any IETF WG. I still
find it useful to have the conceptual data flow in the diagram.

Rainer

> I do not understand what "netconf session delivery" means. For me, a
> netconf session exists between a netconf server and a netconf client.
> It is also unclear what the double lines // mean. If the figure is
> meant to indicate the syslog data flow, then also the double arrow
> between netconf server and netconf client is wrong. If the arrows are
> supposed to mean something else, I think a legend is required to
> discuss the figure. Well, a legend is required in any case.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> --
> 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/>