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

[Phil Shafer <phil@juniper.net>]

Most excellent feedback.  I'll update the draft accordingly.

Thanks,
 Phil


"Rainer Gerhards" writes:
>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/>

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