[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fw: senders and receivers nothing to do with Mibs was Re: [Syslog] Mib-13
Ah. lost the syslog address off this one; my comments are at the beginning.
Tom Petch
----- Original Message -----
From: "tom.petch" <cfinss@dial.pipex.com>
To: "David Harrington" <ietfdbh@comcast.net>
Sent: Monday, February 05, 2007 8:37 PM
Subject: Re: senders and receivers nothing to do with Mibs was Re: [Syslog]
Mib-13
> David
>
> Yes, I am with you on this, the key is to resolve the ambiguity..
>
> I believe that the collector/relay/device terminology has a life outside the
> IETF that we should respect, as we are documenting that life, rather than
> creating something new within the IETF.
>
> For example, look at the liaison from the OIF, 'file228' in the IETF
repository,
> which says
> "The three operational roles for the syslog service are designated devices,
> relays and collectors"
> and goes on to explain those terms in the same way as RFC3164 does. This
> reference comes immediately to hand, but I recall seeing others from different
> organisations. Perhaps they all derived from RFC3164; no matter, they still
> have a life.
>
> So while collector/relay/device may not be the ideal terminology, I believe it
> has currency and we should stay with it. The corollary, for me, is that
sender
> encompasses relay and device, receiver encompasses collector and relay and I
> would then write -mib, -tls et al. based on that understanding.
>
> Tom Petch
>
> ----- Original Message -----
> From: "David Harrington" <ietfdbh@comcast.net>
> To: "'tom.petch'" <cfinss@dial.pipex.com>
> Cc: "'Glenn M. Keeni'" <glenn@cysols.com>; <syslog@ietf.org>
> Sent: Monday, February 05, 2007 6:42 PM
> Subject: RE: senders and receivers nothing to do with Mibs was Re: [Syslog]
> Mib-13
>
>
> > 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
> > dharrington@huawei.com
> > dbharrington@comcast.net
> > ietfdbh@comcast.net
> >
> >
> > > -----Original Message-----
> > > From: tom.petch [mailto:cfinss@dial.pipex.com]
> > > Sent: Monday, February 05, 2007 5:32 AM
> > > To: David Harrington
> > > Cc: 'Glenn M. Keeni'; syslog@ietf.org
> > > 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" <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
> > >
> > >
> >
> >
>
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog