Hi Rohit, As a MIB Doctor, I may be more aware of this type of practice than you. So let me discuss some of the issues raised by your email.
1) Having a separate document for textual conventions for a technology is not uncommon. See RFC 2514, 2856, 3419, 3593, 3595, 3705, 3811, 4001, 4265, and 4801. I won't bother to list the relevant internet-drafts. So you should question your presumption that having two documents, one for TCs and another for the related MIB module, is a bad thing. It is often much easier to establish consensus on reusable textual conventions than on the rest of a MIB module design. One document's advancement can be delayed by dependencies on other documents, so allowing other documents to be dependent only on the reusable textual conventions, rather than on the complete SYSLOG-MIB document should make it easier to advance dependent MIB modules within the IETF process. 2) With regard to these specific textual conventions, one thing to be aware of is the fact that the SYSLOG-MIB actually doesn't use these textual conventions at all. (They are still defined in mib-15, but should be absent from mib-16.) So you should question your presumption that these textual conventions belong in the SYSLOG-MIB; if the SYSLOG-MIB doesn't use them, then why do they need to be defined in the SYSLOG-MIB? 3) If the SYSLOG-MIB doesn't use them, then why are we defining them in this WG? Well, because this WG is composed of syslog experts. The WG whose MIB module references these TCs is the IPCDN WG, which has a lot of cable data networking experts, but not necessarily the best personnel for defining syslog-specific textual conventions. As a MIB Doctor and co-chair of this WG, I had my own concerns about doing this work in the syslog WG, if the SYSLOG-MIB did not actually use these TCs. I consulted the MIB Doctors (including the area director for OPS), and the consensus was that the syslog WG was the corrrect place to define the textual conventions, even if we didn't use them in the SYSLOG-MIB. And I discussed having the separate document for the TCs with my co-chair and the responsible area director for the syslog WG, and we agreed that was appropriate. Hopefully, this gves you some of the background behind the decision to have this separate document. If the WG does not want to adopt this document as a WG draft, Glenn can always publish it as an individual draft. Persaonally, I think it makes sense to publish it a syslog WG draft. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -----Original Message----- > From: Rohit M (rrohit) [mailto:[EMAIL PROTECTED] > Sent: Monday, June 04, 2007 7:13 AM > To: David Harrington; Chris Lonvick (clonvick); tom.petch > Cc: syslog; Sam Hartman > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] > Commentsondraft-ietf-syslog-protocol-20 > > 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
