I have reviewed this draft and have only one real concern: the facility names (e.g. kernel, mail) are somewhat *nix-specific. So far, we avoided making them normative. With only a few facilities available, IMHO, we should not dedicate two thrids of them to some historic function.
Rainer > -----Original Message----- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Friday, June 01, 2007 3:17 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
