[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
sender sends, device or relay
receiver receives, relay or collector.
-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" <ietfdbh@comcast.net>
To: "'Glenn M. Keeni'" <glenn@cysols.com>; <syslog@ietf.org>
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
> > 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