<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 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). > > > > 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. Tom Petch <snip> _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
