Chris,
Sorry, but I have missed the point of the "layer diagram".
It is not clear to me what the layers and the layering signify.
There are 2 problems-
(a) It seems odd that "content", an inert entity, sits on top
of "application", an active entity. Is this OK ? In my
understanding, in the layer model, we have layered
entities each interact with the adjacent layer. Should we
call it something else ?
(b) It is not clear how the "layer diagram" will help in the
understanding of the mib counters. Correct me if I am
wrong - there is no way the
transportSenderCounter and
syslogApplicationSenderCounter will be different.
Also,
transportReceiverCounter and
syslogApplicationReceiverCounter
will always be the same. So we do not need an extra
set of "transport" counters. Then the transport layer in
the diagram is redundant.
Having said that, I must add that if we are interested in
the transport-level granularity, then and only then, the
transport layer is significant, as far as the mib counters
are concerned. Is that what we are looking for ?
Glenn
> What I'm seeing is that our effort to add granularity for mib accounting
> has made the document less clear. My apologies for that.
>
> Does the following make more sense:
>
> +---------------------+ +---------------------+
> | content | | content |
> |---------------------| |---------------------|
> | syslog application | | syslog application | (originator,
> | | | | collector, relay)
> |---------------------| |---------------------|
> | syslog transport | | syslog transport | (transport sender,
> | | | | (transport receiver)
> +---------------------+ +---------------------+
> ^ ^
> | |
> --------------------------
>
>
> In this, the "content" will be developed by some application and handed
> to syslogd (using *nix as an example device). syslogd will format the
> message adding in the PRI, timestamp, etc., and will hand it to the
> transport.
> - For udp transport, the "transport sender" will encapsulte it within udp
> and put it onto the wire.
> - For the case of tls, the "transport sender" will establish a new, or use
> an existing session with the "transport receiver".
>
> For discrepancies (if any) between the IP address of the "originator"
> and the "transport sender", the originator can use the [origin ip=...]
> SDE (Section 7.2).
>
>
> If this makes sense, then the mib counters can be:
> - the number of messages sent and received by the "syslog application"
> (syslogd)
> - the number of messages sent and received by the "transport sender" and
> "transport receiver".
> The tricky part here is that the counters of the "transport sender" and
> "transport receiver" are not going to be useful to counting messages
> that are relayed. Only the counters of the "syslog application" are
> going to be useful for that. To deal with that, I'll propose that that
> a table be set up to associate the messages sent to each relay destination.
>
> As an example from syslog.conf:
>
> kern.crit @loghost
> kern.info @loghost2.example.com
>
> The relay destinations will have to be enumerated.
> get "numOfRelayDests" would return "2"
> get "relayDest(1)" would return "loghost"
> get "relayDest(2)" would return "loghost2.example.com"
>
> What is to be sent to those destinations would have to be quantified.
> get "priOfRelayDest(1)" would return "2" (from kern.crit as the filter)
> get "priOfRelayDest(2)" would return "6" (or "kern.info")
>
> When the device receives a "<2>..." syslog message (PRI=2, kern.crit),
> it will relay it to the two relay destinations.
> Then
> syslogOperationsMsgsReceived will be incremented by 1
> syslogOperationsMsgsRelayed(0) will be incremented by 2
> (the message went to two destinations)
> syslogOperationsMsgsRelayed(1) will be incremented by 1
> (it sent one copy to "relayDest(1)" which is loghost)
> syslogOperationsMsgsRelayed(2) will be incremented by 1
> (it sent another to ""relayDest(2)")
> syslogOperationsMsgsTransmitted will be incremented by 2
> (it transmitted both)
>
> Also, on loghost, syslogOperationsMsgsReceived will be incremented by 1
> and on loghost2.example.com syslogOperationsMsgsReceived will also be
> incremented by 1.
>
> This gives an administrator a way to balance out messages sent and
> received.
> - If our device shows 3 messages relayed to loghost, and loghost shows 3
> messages received, then we have a balance, even if MsgsTransmitted from
> our device is 482.
> - If our device shows 3 messages relayed but loghost shows 2 messages
> received, then we might have a discard on our device, or the message may
> have been dropped by some intermediary.
> - If our device shows 3 messages relayed but loghost shows 46 receieved
> then we likely have another device sending messages to loghost.
>
> To be clear on this, the counters for "transport sender" and "transport
> receiver" will NOT be associated with a peer - they will just count the
> number of messages sent and received. It will be up to the counters
> associated with the "syslog application" to associate the messages with
> peers so that the count of messages relayed will have some meaning.
>
> Does this make sense? As David said, we're not doing our job unless
> we're clear on the concepts, terminology and have a way to manage the
> devices.
>
> Thanks,
> Chris
>
>
>
> On Fri, 18 May 2007, tom.petch wrote:
>
>> Not sure where this draft is heading, but as a WG member, comments
>> <inline>
>>
>> Tom Petch
> ---remainder elided for brevity---
>
> _______________________________________________
> 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
