[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Syslog] Mib-13
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
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog