Subject: [Syslog] Mib-13

From: "David Harrington" <[email-masked]>
Date: Thu, 18 Jan 2007 21:13:40 -0500

Hi,

[speaking as a contributor]

Glenn, thanks for the new revision.
A few comments.

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.

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.

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.

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

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.

5) I do not find Figure 1 enlightening. I suggest you have 2 (or 3)
figures:
- 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
                                          /   |
                           +-----------+ /    |
      ----syslog message-->| Receiver2 |/     |--> Collector3
                           +-----------+

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) I am not sure we had consensus to remove all the objects you
removed. I will check further and consult with Chris.

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.

8) Malformed - The WG distinguishes between receivers and relays;
should we have both receivers and relays count malformed headers?

9) MsgsReceived - should we count messages recived by receivers and
relays?

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

11) should we also have a MsgsSent?

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

13) MsgsDiscarded - relays should also count these.

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

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

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

Thanks,
David Harrington
[email-masked] 
[email-masked]
[email-masked]

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

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 22 Jan 2007 22:33:41 +0900

Hi,
  I have received this mail but I am yet to go through it. I
hope to get back before the end of the week. Meanwhile let the
comments coming.

  Cheers

  Glenn

---

From: "David Harrington" <[email-masked]>
Date: Wed, 24 Jan 2007 15:19:02 -0500

Hi Glenn,

In rev13, you removed the textual conventions for SyslogFacility and
SyslogSeverity. Can you add those back in, even though we do not use
them in the module? 

Developers of other MIB modules that want to reference these syslog
concepts would likely look in the syslog-mib for such TCs. The IPCDN
event messaging MIB already has a dependency on these TCs.

I discussed this with the other MIB Doctors and they concur this would
be an appropriate thing to do.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Thu, 25 Jan 2007 07:53:22 +0900

David,
> be an appropriate thing to do.
Thanks. I will add the two TCs.

Glenn