Hi Chris, Do we really two separate Drafts/RFCs to define Syslog MIB. The TC MIB can part of the same Syslog Draft/RFC; both of the MIBs TC and Syslog MIB can be defined in the same Draft ?
Thanks Rohit -----Original Message----- From: Chris Lonvick (clonvick) Sent: Friday, June 01, 2007 6:47 PM To: tom.petch Cc: 'Sam Hartman'; syslog Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments ondraft-ietf-syslog-protocol-20 Hi Tom, I appreciate the thoughts. I see consensus in the WG on the layering diagram. I've asked Rainer to update -protocol with that diagram and definitions. Let's get that out the door at this time. I see that we are unclear on what we should be counting and the benefit of counting it. Glenn has separated the mib into textual conventions and the counters. The TC is now here: http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt Would everyone please review this? I would like for us to establish this as our base and then we can have discussions on counting messages. Thanks, Chris On Fri, 1 Jun 2007, 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. > > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
