----- Original Message ----- From: "David Harrington" <[EMAIL PROTECTED]> To: "'Rainer Gerhards'" <[EMAIL PROTECTED]>; "'Chris Lonvick'" <[EMAIL PROTECTED]> Cc: "'syslog'" <[EMAIL PROTECTED]> Sent: Friday, June 01, 2007 9:06 PM Subject: [Syslog] tc-mib poll
> Hi, > > [speaking as co-chair] > <snip> > > I would like to do a poll: > > 1) Should these textual conventions be accepted as they are? Yes, fine by me > > 2) Would this WG like to see us define a normative set or a > non-normative set of facilities and severities? > I do not understand this; normative means that is part of a protocol which must be adhered for for conformance and I do not see what protocol we are talking of here > 3) Whether normative or non-normative, which is more important? > efficient allocation of the limited facility values, or backwards > compatibility with existing (and historic) implementations? > Compatibility - this list has been around and stable for a long time and I see similar proprietary ones (albeit with an added one or multiplied by eight) going back further. Tom Petch > Thanks > > David Harrington > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > co-chair, syslog wg > > > -----Original Message----- > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > Sent: Friday, June 01, 2007 10:38 AM > > To: Chris Lonvick > > Cc: syslog > > Subject: [Syslog] > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > > > > 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 > > > > > > _______________________________________________ > 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
