tom.petch wrote: > <inline> > Tom Petch > > ----- Original Message ----- > From: "Glenn M. Keeni" <[EMAIL PROTECTED]> > To: "tom.petch" <[EMAIL PROTECTED]> > Cc: "Chris Lonvick" <[EMAIL PROTECTED]>; "'Sam Hartman'" > <[EMAIL PROTECTED]>; "syslog" <[EMAIL PROTECTED]> > Sent: Saturday, June 02, 2007 7:11 AM > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on > draft-ietf-syslog-protocol-20 > > >> tom.petch wrote: >>> Chris >>> >>> I am fine with the layer diagram given below but I am less clear about the >>> consequences for the MIB. >>> >>> Currently, there is a table with an arbitrary integer index which contains >>> application name, application control file name, receive address and > statistics. >>> I have never been too clear on what an entry in this table represents, as I > have >>> queried before. >> There are two tables. I presume that you are referring to >> syslogControlTable. The DESCRIPTION for syslogControlEntry >> should answer your question >> DESCRIPTION >> "The configuration parameters pertaining to a syslog >> application. >> " >> Let me know which part is unclear, I will try to clarify. > > Since syslogOperationsTable is an SMI augmentation of syslogControlTable, I > was > treating them as one table. And I do not understand what a row in the table There is no problems treating the two tables as one. > represents; applications to me is the like of SMTP, FTP, Web access. > > I see syslog in network devices where arguably there are no 'applications', > SNMP, TFTP, telnet, HTTP and such being there for device management, with > syslog > messages relating to happenings at link or network level, or perhaps OS (eg > storage/addressing); or I see syslog in non-**ix servers as a separate > process/daemon. In either case, it is the process that is configured, not > what > I think of as an application; so I don't understand:-(. (And, in earlier > I-Ds, > I got the impression that these applications could be on different boxes with > some protocol transferring the messages to the syslog originator). Right. The syslog-wg has decided to call "it" an "application". [ I did not think that "application" is the most appropriate term.] One row in the table represents information about one "application". > >>> The details below suggest that messages sent and received at the transport > level >>> become scalars (digression: need to be clear what a message is when this is > TLS >>> over TCP) with a table with an entry per relay destination (per > application?). > > <snip> > >>> Doubt two; should we be - we should be! - providing a similar table for >>> originators since they too can send to multiple destinations. >> In the table for relay destinations- we have a destination-priority >> pair. Application A1 will relay Priority P1 to destination D1 etc. > >> I am not clear about what exactly you want in a similar table for >> originators. Could you explain that? > > Chris wrote of reconciling counts of messages sent by one syslog stack with > those received by another stack to see if some were lost. I like this idea - > and > am assuming that the reconciliation would be done on a 5-tuple of > protocol/portnumbers/IPaddresses basis or something similar - but can only see > it working if we know where an originator is sending messages to. I think of > an > originator as having the capability to send the same message to more than one > place (relay or collector), or to send different messages to different places > eg > based on severity, so reconciliation must depend on having a table in the > originator of how many were sent where, must it not? > > As I said before, I like the idea of being able to reconcile counts, but fear > it > may end up too complex to implement since, to do it properly, you would need > to > extract such tables from potentially every syslog stack in the management > domain > at the same point in time and then later repeat the process in order to get a > diff between the counters; and then start reconciling. I will agree with you. Reconciling the counts of multiple applications, possibly on multiple servers, is complex. I would say it is impractical if not impossible. > > Tom Petch > > <snip> >
Glenn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
