In that case, going forward we will have two drafts for every MIB as it looks like. Which other MIB is using these TCs ?
Thanks Rohit -----Original Message----- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Monday, June 04, 2007 4:41 PM To: Rohit M (rrohit); Chris Lonvick (clonvick); 'tom.petch' Cc: 'syslog'; 'Sam Hartman' Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Commentsondraft-ietf-syslog-protocol-20 Hi, There are other WGs that are developing MIB modules that refer to syslog facility and severity textual conventions. By separating the facility and severity TCs from the rest of the syslog MIB, we reduce the dependency problem, by allowing the TC draft to advance independent of the rest of the syslog MIB document. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -----Original Message----- > From: Rohit M (rrohit) [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 02, 2007 9:56 PM > To: Chris Lonvick (clonvick); tom.petch > Cc: syslog; Sam Hartman > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] > Commentsondraft-ietf-syslog-protocol-20 > > 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
