Hi, [speaking as a contributor]
My main concern is that if we are going to use three terms or four, then we need to make it clear which roles are responsible for incrementing counters regarding received messages, and for incrementing counters regarding sent messages. As currently written, only receivers (and not relays or collectors) increment the counters regarding received messages, and only senders (not relays) increment the counters regarding sent messages. Our definitions are missing the crucial info about which roles are senders and which are receivers; the description in your email does include this info: > sender sends, device or relay > receiver receives, relay or collector But Glenn's email says this: > We basically have syslog senders and syslog > receivers. A syslog relay is a special case - it "forwards some of the > received syslog messages to other syslog entities." Should a relay be incrementing the counters for received messages? Should a collector be incrementing the counters for received messages? Does a relay "forward" a syslog message by **sending** it to other syslog "entities"? Should a relay be incrementing the counters for sent messages? The answers to these questions are ambiguous given the current text in the protocol and in the mib documents. I don't care which way we modify the text to resolve the ambiguity; I care that we DO resolve the ambiguity. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -----Original Message----- > From: tom.petch [mailto:[EMAIL PROTECTED] > Sent: Monday, February 05, 2007 5:32 AM > To: David Harrington > Cc: 'Glenn M. Keeni'; [EMAIL PROTECTED] > Subject: senders and receivers nothing to do with Mibs was > Re: [Syslog] Mib-13 > > David > > I disagree with you here. I think that we should use four > terms, sender, > receiver, relay, collector. > > RFC3164 I find very clear. > > collector receives and does not forward > relay receives and forwards > > -protocol started off life with identical definitions but by > -10, two key > phrases had vanished leaving > > sender sends, > receiver receives, > > which would be ambiguous except that further down it says > " Senders send messages to receivers with no knowledge of > whether they are > collectors or relays" > which again I find very clear - receiver receives, relay or collector. > > So while the present text is not as clear as it used to be, I > still believe that > what we are saying is what we always have said, namely > > collector receives and does not forward > relay receives and forwards > sender sends, device or relay > receiver receives, relay or collector > > and I see this implicitly endorsed in the documentation of > other bodies; > collector, in particular, I see used, if not as precisely > defined as we used to. > > So, I conclude that we have four well-defined terms, in use > for many years, and > need a good reason to change them. Of course we could do > things differently, > but at the risk of confusing those who have not followed this WG. > > Tom Petch > > ----- Original Message ----- > From: "David Harrington" <[EMAIL PROTECTED]> > To: "'Glenn M. Keeni'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Friday, February 02, 2007 7:27 PM > Subject: RE: [Syslog] Mib-13 > > > > Hi Glenn, > > > > Some comments. > > > > First let me start out by noting that MIB modules are frequently > > implemented by junior developers, since the senior developers don't > > want to waste their time working on management stuff; they > want to go > > design new hardware and new protocols. So the implementer > of a syslog > > MIB module may not have much experience with syslog. > > > > As a result, it is important to be unambiguous in our terminology. > > This is especially true when describing what should be counted in a > > counter. This is a common problem in MIB module implementations - > > different implementations interpret the instructions slightly > > differently, and end up counting slightly different things, and as a > > result, the counters cannot be interpreted in an interoperable way > > across implementations. > > > > Protocol says there are three application types - senders, > receivers, > > and relays. -protocol- does NOT say that a relay is a > special case and > > that a relay IS a receiver and IS a sender: > > > > Per the protocol document: > > > > o A syslog application that can generate a syslog > message is > > > > called a "sender". > > > > > > > > o A syslog application that can receive a syslog message is > > > > called a "receiver". > > > > > > > > o A syslog application that can receive syslog messages and > > > > forward them to another receiver is called a "relay". > > > > > > > > Here's where ambiguity comes in as the result of terminology > > differences between -protocol- and -mib-. > > > > You know and I know that a relay really both recieves and > sends and it > > does some stuff in between, but protocol does not say that > a relay is > > both a receiver and a sender, and nothing says that when counting > > things, a relay should count things relevant to a receiver AND > > relevant to a sender. > > > > SyslogRoles is not clear on this point: If I am a relay, > then do I set > > all three bits ON (sender, receiver, relay) or do I only > set the relay > > BIT ON? > > > > Malformed says "The number of messages received by the syslog > > receiver which had malformed header. > > If this syslog entity is not a syslog receiver > > the this object will have a zero value.", > > Well, if I am a relay am I also a reciever? Protocol does not say > > that! In fact, protocol says there are three types of > applications, so > > if I am a relay then I can interpret this to mean I am not a > > "reciever" and I am not a "sender"; I am a "relay". Therefore, as a > > relay, I should not count malformed headers, because only receivers > > should count malformed headers. > > > > Am I just thick? No. I fully understand that a relay both > receives and > > sends; but the text in our specififcations does not say that this > > means a relay is both a "receiver" and a "sender". I am an > experienced > > MIB Doctor that has dealt with this same type of ambiguity > in WG after > > WG, where the WG members understand, but they are sloppy in > their MIB > > module specification work. > > > > We have an ambiguity: Does the Malformed counter include malformed > > headers received by a relay or not? This can be interpreted > as "relays > > should not count malformed headers that it receives; only receivers > > should count them." I think that would be a bad interpretation, but > > the ambiguity of the terminology allows for this interpretation. We > > need to modify the text so that such an interpretation is > not allowed. > > I recommend changing the text to: > > "The number of messages received by the syslog > > receiver or relay which had malformed header. > > If this syslog entity is not a syslog receiver > > or relay the this object will have a zero value." > > This way, whether the implementer interprets the terminology > > differences to be "I am a relay therefore I am NOT a receiver" or "I > > am a relay therefore I AM a receiver" makes no difference. > > > > An alternative is to change the protocol document to be clear that > > there are only two basic types of application- a sender and a > > receiver, and the relay is a special case that is both a > receiver and > > a sender plus other stuff. Right now the protocol document > definitions > > do not state that clearly. > > > > (also note the "the this" s/b "then this" > > (also note "had malformed" s/b "had a malformed") > > > > > > > > 8. > > > >8) Malformed - The WG distinguishes between receivers > and relays; > > > >should we have both receivers and relays count > malformed headers? > > > > > > I recommend that we do not. I would say that the > administrator is > > > interested in knowing that his/her syslog is receiving too many > > > malformed messages. The administrator is less interested in > > knowing > > > whether the malformed message was meant for local consumption or > > for > > > forwarding. (I am not saying that the information is useless. We > > are > > > trying to look at the cost benefits.) > > > > I think you misinterpreted me here. I was not suggesting > two separate > > counters, one for receivers and one for relays; I am trying to make > > sure the relays also increment this counter when they receive a > > malformed header. > > > > > > > > dbh > > > > > > _______________________________________________ > > > Syslog mailing list > > > [email protected] > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > _______________________________________________ > > Syslog mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
