Hi, The IETF Management Framework makes a distcinction between management information and protocols used to carry information. The "content" layer provides an interface to the underlying instrumentation. A "content layer" concept is used in the Netconf architecture to represent this, and we carried that into this document to show a similar separation of the management information from the protocol.
I believe there can be differences between the number of messages that "applications" request be sent and the number that is actually sent, because there can be error conditions that prevent a message from actually being sent. For syslog deployemnts that send the same message to multiple addresses and to a file for storage, do you count the number of "messages" or the number of transport endpoints? Do you count the file-storage destinations as having been snet, or only the messages that have been sent across a transport protocol? In addition, an implementation might contain multiple "applications" that use the same transport sending library. So the counting of messages can be different depending on where you count them. What I am interested in seeing is counters that are implemented in a relatively consistent manner across implementations, so an SNMP NMS can compare/contrast the values of the counters from different hosts/servers/applications/whatever. If one implementer increments the only "sent" counter when a request is made, and another increments the "sent" counter when each outgoing message is put on the wire, this can result in counters that are comparing apples to oranges. The conceptual layering helps when trying to write DESCRIPTION clauses that are consistent across implementations. Describing the conceptual layering keeps the DESCRIPTION at an abstract concept level to avoid having the standard dictate specific implementation decisions. We need to be able to specify where in the conceptual process a counter should be incremented, without dictating implementation software designs, in order to minimize ambiguity in the counter specification to eliminate inconsistent implementer-interpretations that make the counters non-interoperable across vendors. dbh > -----Original Message----- > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > Sent: Monday, May 28, 2007 1:18 AM > To: Chris Lonvick > Cc: syslog; 'Sam Hartman' > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] > Commentson draft-ietf-syslog-protocol-20 > > Chris, > Sorry, but I have missed the point of the "layer diagram". > It is not clear to me what the layers and the layering signify. > There are 2 problems- > (a) It seems odd that "content", an inert entity, sits on top > of "application", an active entity. Is this OK ? In my > understanding, in the layer model, we have layered > entities each interact with the adjacent layer. Should we > call it something else ? > > (b) It is not clear how the "layer diagram" will help in the > understanding of the mib counters. Correct me if I am > wrong - there is no way the > transportSenderCounter and > syslogApplicationSenderCounter will be different. > Also, > transportReceiverCounter and > syslogApplicationReceiverCounter > will always be the same. So we do not need an extra > set of "transport" counters. Then the transport layer in > the diagram is redundant. > Having said that, I must add that if we are interested in > the transport-level granularity, then and only then, the > transport layer is significant, as far as the mib counters > are concerned. Is that what we are looking for ? > > > Glenn > > > > 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
