Subject: Re: [Syslog] Mib-13

From: "Glenn M. Keeni" <[email-masked]>
Date: Fri, 02 Feb 2007 10:53:50 +0900

Hi,
   Thanks for the comments. A revised I-D mib-14.txt has been
posted to the drafts archives. The response to the comments
are given in line below.

   Cheers

   Glenn

David Harrington wrote:
> Hi,
> 
> [speaking as a contributor]
> 
> Glenn, thanks for the new revision.
> A few comments.
> 
1-1.
  >1) I find the use of entity an unnecessary abstraction.
  >"In this document we refer to a syslog application as a syslog
  >entity."
  >Since -protocol- uses application, why not just use syslog
  >application instead of syslog entity? That will make the
  >terminology more consistent.
  >
I disagree. We have been through device, demon and applications. It
does appear that "entity" is the most appropriate reference. Let me
hear more from the WG on this.

1-2.
  >In the MIB itself, let's change the hierarchy to be
  >
  >                            syslogObjects
  >                               |
  >           -----------------------------------------
  >           |                   |                    |
  >syslogSystem(1)      syslogControlTable(2)   syslogOperationsTable(3)
  >
  >We don't need the syslogEntity node, or the syslogEntity prefix. This
  >change will make it easier to read, and eliminate the extra sub-oid
  >in every varbind.
  >
  I am not sure that this is the right design. It certainly does not
  look elegant to me.
  Done.

2.
  >2) "The discussion in this document in general applies to a generic
  >syslog entity."
  >If we get rid of all the generalities, we get "This document applies
  >to syslog applications."
  >Of course, once you remove the indirection, I'm not sure it is needed
  >because it is obvious.
  >
  See 1.

3.
  >3) the Copyright in the MODULE-IDENTITY needs to be for the IETF
  >Trust, not the Internet Trust. (I'm surprised the ID editor didn't
  >catch that one; they always catch incorrect copyrights on my
  > documents ;-)
  Done.

4.
  >4) section 2 mentions the UDP transport. It doesn't really need to.
  >If you keep it there, then you should also mention TLS and BEEP
  >transports in the same paragraph.
  >
  Removed the reference to UDP transport in section 2.

5.
  >5) I do not find Figure 1 enlightening. I suggest you have 2 (or 3)
  >figures:
  I want to make this clear - we are not trying to show the
  relationship between the various roles. That is left for the Protocol
  (and other) documents.
  I will be keen to know if some part of the text in the MIB document is
  obscure or unclear due to insufficient explanation in the diagram.

  >- One that shows the relationship of senders and relays and receivers
  >
  >(section) 2.1 Syslog Applications
  >
  >      +--------+                  +----------+
  >      | Sender |--syslog message->| Receiver |
  >      +--------+                  +----------+
  >
  >      +--------+                  +-------+
  >+----------+
  >      | Sender |--syslog message->| Relay |--syslog message->|
  >Receiver |
  >      +--------+                  +-- ----+
  >+----------+
  >
  >     Fig. 1: syslog applications
  >
  >   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".
  >
  >
  >- One that shows the relationship of facilities to senders.
  >(section) 2.2 Facilities
  >
  >                          +---------+
  >                          | Sender1 |----syslog message-->
  >                         /+---------+
  >        Facility-1-->|  /
  >                  -->| /  +---------+ /
  >        Facility-N-->|+---| Sender2 |----syslog message-->
  >                  -->| \  +---------+ \
  >      SyslogHost-N-->|  \
  >                         \+---------+ /
  >                          | Sender3 |----syslog message-->
  >                          +---------+ \
  >     Fig. 2: Facilities
  >
  >Facility: an application or device that asks a syslog sender to send
  >a message. Sometimes the facility and the sysog sender are built into
  >the same application; sometimes they are separate applications.
  >
  >Since we plan to modify the collector definition in protocol, is the
  >collector always the same as the receiver, or is the collector the
  >application(s) behind the syslog application (e.g. syslogd)? If they
  >are separate, then we should probably show that relationship:
  >
  >- One that shows the relationship of receivers and collectors
  >(section) 2.3 Collectors
  >
  >                           +-----------+
  >      ----syslog message-->| Receiver1 |\     |--> Collector1
  >                           +-----------+ \    |
  >                                          \   |
  >                                           +--|--> Collector2
  >                                          /   |
  >                           +-----------+ /    |
  >
  >Can one receiver (one port) support multiple collectors, or is this
  >always a 1:1 relationship? Can a collector ask multiple receivers
  >(different ports, presumably) to listen for traffic?
  >

6.
  >6) I am not sure we had consensus to remove all the objects you
  >removed. I will check further and consult with Chris.
  >
  With the departure of rfc3164 from informational to history, these
  objects have lost their the raison d'etre.
  I have put back the TCs for SyslogSeverity and SyslogFacility as per
  our discussions.

7.
  >7) MsgDropped counts messages that could not be queued by a relay;
  >but it will be zero if this is not a sender. The WG distinguishes
  >between senders and relays, so this does not make sense. If we only
  >count these on a relay, then it should be zero if it is a reciever
  >or sender, and non-zero only on a relay.
  >OR we need to change our definition for relay to be a syslog
  >application that includes both a sender and a receiver, so a relay
  >also increments counters specific to a sender and those specific to a
  >reciever.
  >
  If you look at the diagram in Fig.1 and the explanation that follows -
  this will be clear. 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."

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.)

9.
  >9) MsgsReceived - should we count messages recived by receivers and
  >relays?
  >
  I recommend that we do not. We have separate counters on MsgsReceived
  and MsgsRelayed. The difference is the number of messages received for
  local consumption.

10.
  >10) MsgsReceived. This description doesn't have the note that this
  >value will be zero if the entity is not a reciever.
  >
  Done.

11.
  >11) should we also have a MsgsSent?
  >
  Yes. I have added this.

12.
  >12) MsgsDiscarded - you changed the terminology from ignored to
  >discarded. The description in MsgsRecieved needs to be changed to
  >match.
  >
  Done.

13.
  >13) MsgsDiscarded - relays should also count these.
  >
  Yes. A relay is a receiver too. So it is counted.

14.
  >14) LastMsgRecdTime - the locally or from a remote entity is
  >confusing. Locally appears to refer to the non-syslog-message
  >communication between a facility and a sender. Is that correct? If
  >that is not what locally means, I don't know how to interpret this
  >text. I think we need to distinguish between the on-the-wire (i.e.
  >syslog messages) and the off-the-wire communications (i.e. non-syslog
  >messages).
  >
  >
  I have removed the part that was confusing "locally or from a remote
  entity".  There is no other way the syslog receiver can receive a
  message. Nothing is lost by removing that text.

15.
  >15) local management system - since both SNMP and syslog are local
  >management systems, I think this should be the SNMP management
  >system.
  >
  Done.

16.
  >16) OperationsReference - can we change this to OperationsRunIndex? I
  >think that will more meaningful.
  Done.

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "David Harrington" <[email-masked]>
Date: Fri, 2 Feb 2007 13:27:31 -0500

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:

>   >      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")

>   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

---

From: "tom.petch" <[email-masked]>
Date: Mon, 5 Feb 2007 10:42:34 +0100

I am with David on this one.  Since RFC3164, -protocol, -sign, -tls etc all
manage without reference to 'entity', then I think there needs to be good
justification for introducing a new technical term eg it should label a
distinctly different concept and that  I do not see.

Tom Petch

----- Original Message -----
From: "Glenn M. Keeni" <[email-masked]>
To: <[email-masked]>
Sent: Friday, February 02, 2007 2:53 AM
Subject: Re: [Syslog] Mib-13

>   >Of course, once you remove the indirection, I'm not sure it is needed
<snip>

---

From: "tom.petch" <[email-masked]>
Date: Mon, 5 Feb 2007 11:32:04 +0100

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

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 05 Feb 2007 22:30:14 +0900

Tom,
  I do not understand what you mean by a technical term. Perhaps
entity is as technical as "it". It is convenient and appropriate
since we do not know or do not want to predict whether a syslog
message will be generated by a "application", "device", "organism",
"machine" or whatever.

  Glenn

tom.petch wrote:
> manage without reference to 'a technical term. entity', then I think there needs to be good

---

From: "David Harrington" <[email-masked]>
Date: Mon, 5 Feb 2007 12:42:40 -0500

Hi,

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
But Glenn's email says this:
> We basically have syslog senders and syslog

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-masked] 
[email-masked]
[email-masked]

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> Sent: Monday, February 05, 2007 5:32 AM
> To: David Harrington
> Cc: 'Glenn M. Keeni'; [email-masked]
> Subject: senders and receivers nothing to do with Mibs was 
> Re: [Syslog] Mib-13
> 
> David
> 
> > >   whether the malformed message was meant for local consumption
or
> > for
> > >   forwarding. (I am not saying that the information is useless.
We
> > are