David I see the problem slightly differently. I think that there is adequate expertise on this list to turn a data model into suitable SMI and that what is lacking is the data model for syslog; from the MIB doctor reports I have read, that is one thing they rarely bring to the party. Rather they focus on the SMI and on asking pointed questions about the meaning and representation of objects in the model.
We have progessed, producing a better defined syslog stack, what I think is needed now is to take that a stage further - no SNMP expertise needed - in defining what management data users would like to know or what implementers are prepared to offer. The existing MIB module is obviously an example of this; my problem with it is in not understanding it as well as I think I need to in order to use it. And of course the lack of others saying 'it's obvious what it means' (or not) or whatever so that a consensus may form. Tom Petch ----- Original Message ----- From: "David Harrington" <[EMAIL PROTECTED]> To: "'tom.petch'" <[EMAIL PROTECTED]>; "'Chris Lonvick'" <[EMAIL PROTECTED]> Cc: "'Sam Hartman'" <[EMAIL PROTECTED]>; "'syslog'" <[EMAIL PROTECTED]> Sent: Friday, June 01, 2007 8:46 PM Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 > 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
