Hi, [speaking as co-chair]
We asked Glenn to split the two textual conventions into a seperate document because other working groups are developing MIB modules that reference syslog facility and severity textual conventions, and we don't want our complete syslog MIB discussions to hold up their work. Chris and I felt that there was consensus on the non-normative values defined in the facility and severity textual conventions. If this WG decides to debate these values, then I will recommend that other working groups simply define their own textual conventions for these values. I consider that sub-optimal, but no other WG should be held up by the syslog WG, which has a horrible track record for reaching consensus on anything. I would like to do a poll: 1) Should these textual conventions be accepted as they are? 2) Would this WG like to see us define a normative set or a non-normative set of facilities and severities? 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? 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
