Hi, [speaking as co-chair]
I would like to recommend that the WG ask the OPS ADs for a MIB Doctor to work as a Technical Advisor to the WG. I think a MIB Advisor can help guide the WG about designing the MIB. Obviously I am a MIB Doctor, but it makes it difficult to keep the functions separate when I work as contributor, as co-chair and as MIB Advisor. I would like to have an independent MIB Advisor providing guidance on the MIB design. David Harrington co-chair, syslog wg > -----Original Message----- > From: tom.petch [mailto:[EMAIL PROTECTED] > Sent: Friday, June 01, 2007 6:19 AM > To: Chris Lonvick > Cc: David Harrington; 'Sam Hartman'; syslog > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] > Comments on draft-ietf-syslog-protocol-20 > > 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. > > 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?). > > Doubt one: we currently do not have any destination > information in the table, > only a receive address to bind to; will this be added? > > Doubt two; should we be - we should be! - providing a similar > table for > originators since they too can send to multiple destinations. > > Doubt three; should we have a table for different origins, > else balancing > counters will be difficult? If a collector receives 30 > messages when the > various relay and originator not relayed counters add up to > 25, how do you know > which stream has gone missing? or do you parse the message > and expect there to > be helpful data in the SDE? > > This is all getting complicated and I am unclear about the > benefits of going > down this road. > > Tom Petch > > ----- Original Message ----- > From: "Chris Lonvick" <[EMAIL PROTECTED]> > To: "tom.petch" <[EMAIL PROTECTED]> > Cc: "David Harrington" <[EMAIL PROTECTED]>; "'Sam Hartman'" > <[EMAIL PROTECTED]>; "syslog" <[EMAIL PROTECTED]> > Sent: Tuesday, May 22, 2007 7:22 PM > Subject: Layer diagram & mib counters - was:Re: [Syslog] Comments on > draft-ietf-syslog-protocol-20 > > > > Hi All, > > > > What I'm seeing is that our effort to add granularity for > mib accounting > > has made the document less clear. My apologies for that. > > > > Does the following make more sense: > > > > +---------------------+ +---------------------+ > > | content | | content | > > |---------------------| |---------------------| > > | syslog application | | syslog application | (originator, > > | | | | > collector, relay) > > |---------------------| |---------------------| > > | syslog transport | | syslog transport | > (transport sender, > > | | | | > (transport receiver) > > +---------------------+ +---------------------+ > > ^ ^ > > | | > > -------------------------- > > > > > > In this, the "content" will be developed by some > application and handed to > > syslogd (using *nix as an example device). syslogd will format the > > message adding in the PRI, timestamp, etc., and will hand it to the > > transport. > > - For udp transport, the "transport sender" will encapsulte > it within udp > > and put it onto the wire. > > - For the case of tls, the "transport sender" will > establish a new, or use > > an existing session with the "transport receiver". > > > > For discrepancies (if any) between the IP address of the > "originator" and > > the "transport sender", the originator can use the [origin > ip=...] SDE > > (Section 7.2). > > > > > > If this makes sense, then the mib counters can be: > > - the number of messages sent and received by the "syslog > application" > > (syslogd) > > - the number of messages sent and received by the > "transport sender" and > > "transport receiver". > > The tricky part here is that the counters of the "transport > sender" and > > "transport receiver" are not going to be useful to counting > messages that > > are relayed. Only the counters of the "syslog application" > are going to > > be useful for that. To deal with that, I'll propose that > that a table be > > set up to associate the messages sent to each relay destination. > > > > As an example from syslog.conf: > > > > kern.crit @loghost > > kern.info @loghost2.example.com > > > > The relay destinations will have to be enumerated. > > get "numOfRelayDests" would return "2" > > get "relayDest(1)" would return "loghost" > > get "relayDest(2)" would return "loghost2.example.com" > > > > What is to be sent to those destinations would have to be > quantified. > > get "priOfRelayDest(1)" would return "2" (from > kern.crit as the filter) > > get "priOfRelayDest(2)" would return "6" (or "kern.info") > > > > When the device receives a "<2>..." syslog message (PRI=2, > kern.crit), it > > will relay it to the two relay destinations. > > Then > > syslogOperationsMsgsReceived will be incremented by 1 > > syslogOperationsMsgsRelayed(0) will be incremented by 2 > > (the message went to two destinations) > > syslogOperationsMsgsRelayed(1) will be incremented by 1 > > (it sent one copy to "relayDest(1)" which is loghost) > > syslogOperationsMsgsRelayed(2) will be incremented by 1 > > (it sent another to ""relayDest(2)") > > syslogOperationsMsgsTransmitted will be incremented by 2 > > (it transmitted both) > > > > Also, on loghost, syslogOperationsMsgsReceived will be > incremented by 1 > > and on loghost2.example.com syslogOperationsMsgsReceived > will also be > > incremented by 1. > > > > This gives an administrator a way to balance out messages sent and > > received. > > - If our device shows 3 messages relayed to loghost, and > loghost shows 3 > > messages received, then we have a balance, even if > MsgsTransmitted from > > our device is 482. > > - If our device shows 3 messages relayed but loghost shows > 2 messages > > received, then we might have a discard on our device, or > the message may > > have been dropped by some intermediary. > > - If our device shows 3 messages relayed but loghost shows > 46 receieved > > then we likely have another device sending messages to loghost. > > > > To be clear on this, the counters for "transport sender" > and "transport > > receiver" will NOT be associated with a peer - they will > just count the > > number of messages sent and received. It will be up to the counters > > associated with the "syslog application" to associate the > messages with > > peers so that the count of messages relayed will have some meaning. > > > > Does this make sense? As David said, we're not doing our > job unless we're > > clear on the concepts, terminology and have a way to manage > the devices. > > > > Thanks, > > Chris > > > > > > > > On Fri, 18 May 2007, tom.petch wrote: > > > > > Not sure where this draft is heading, but as a WG member, > comments <inline> > > > > > > Tom Petch > > ---remainder elided for brevity--- > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
