[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Syslog] Mib-13
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
David Harrington wrote:
> 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
> dharrington@huawei.com
> dbharrington@comcast.net
> ietfdbh@comcast.net
>
>
>
> _______________________________________________
> 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