Subject: [Syslog] TIMESTAMP and leap seconds

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 2 Jan 2006 11:41:31 +0100

Hi all,

first of all, I would like to whish a happy new year to each of you!

I am now back in the office and at final edits to syslog-protocol. I
discovered one more thing: The current draft supports leap seconds.
There already is a lot of discussion whether or not leap seconds should
be introduced in the future. However, the way leap seconds are handled
will be largely invisible to a syslog sender (except where it is sitting
on a time-tracking device, which is highly unlikely). On the other hand,
leap second processing can be pretty complicated at the receiver side. I
expect that most implementations will not abide strict handling in any
case.

As such, I suggest that leap second support be removed from the
TIMESTAMP. Similarily, a sender with unknown time should then not use
the special TIMESTAMP but "-", which also keeps it consistent with the
rest of the header NIL values.

If nobody objects, I'll change this during the edit.

Rainer

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

---

From: "Andrew Ross" <[email-masked]>
Date: Tue, 3 Jan 2006 22:32:02 +1300

Hi Rainer,

Happy new year!

Your idea of ignoring the leap seconds sounds very sensible to me.

Cheers

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Rainer Gerhards
Sent: Monday, 2 January 2006 11:42 p.m.
To: [email-masked]
Subject: [Syslog] TIMESTAMP and leap seconds

Hi all,

Rainer

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 5 Jan 2006 21:16:14 +0100

I have had a look at the syslog MIB, and am confused, at a fairly fundamental
level, about the relationship of the MIB to the other documents, RFC3164 and
syslog-protocol.  The last two have a common framework/architecture, spelt out
at the beginning of each, with a common terminology of device, relay, collector,
server.  The MIB is different.

Thus, it is a device MIB (not a protocol MIB) (quoting) 'to monitor a group of
syslog devices' and 'One or more syslog devices which may be on the same host'.
'"facilities" generate messages indicating their own status or the occurance of
events. These messages are handled by what has come to be known as the syslog
process or device'

Which leaves me with the impression of a loosely-coupled system of hosts
communicating via proprietary protocols with multiple instances of a syslog
daemon per host forwarding messages onward.  Really? could be but I think I am
lost here and that the introduction should be recast in the language of
RFC3164/syslog-protocol (even if it is intending to convey the above).

Tom  Petch

---

From: Glenn Mansfield Keeni <[email-masked]>
Date: Thu, 19 Jan 2006 11:36:42 +0900

Tom,
  Apologies for the delay in responding.
> events. These messages are handled by what has come to be known as the syslog
I agree with you that the definition of "syslog device" is NOT consistent with
RFC3164 and syslog-protocol-17. I will fix this in the next draft. Thanks for
pointing that out.
  As far as management is concerned the syslog daemon [receiver/relay] is an
application ( doing a specific task viz. receiving and forwarding syslog messages).
There may be several syslog daemons on a host. That has been provisioned for in the
MIB.
> daemon per host forwarding messages onward. Really?
There is nothing that prohibits one from using multiple syslog daemons.
> could be but I think I am> lost here and that the introduction should be recast 
> in the language of RFC3164/syslog-protocol (even if it is intending to convey the
> above).
Right. I will find a better name for the entity that we intend to manage using the
MIB and of course must not conflict with the terms used in 3164/syslog-protocol. In
the absence of a better name I may use the term "entity" itself. It receives, stores
and forwards syslog messages. Let me know if I have missed out something.

Cheers

Glenn

-- 
+----------------------------------------------------------+
 Cyber Solutions Inc.               Phone  022-303-4012
 6-6-3, Minami Yoshinari            Fax    022-303-4015
 Aoba-ku, Sendai, Japan 989-3204    e-mail [email-masked]
+----------------------------------------------------------+

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 20 Jan 2006 09:34:31 +0100

Although these comments are a response to Glenn, I would appreciate others on
the list reading and commenting on pp3-4 of the syslog-mib which describes
syslog (nothing MIBby, honest) in terms I am struggling with, if only to say
'yes, that is exactly how I see syslog being used'.

Recall that IESG tends to require a MIB to allow protocols to advance so unless
we agree on a MIB, we may not have a syslog-protocol:-(

Glenn

Ok so far but ...:-)
you talk of 'receiving and forwarding syslog messages', that is of relay and
collector in syslog-protocol terms; what about sender?  Do you envisage any use
of this MIB for an entity that is only involved in sending packets conforming to
syslog-protocol?

And when the document talks of receiving messages, are these messages ones that
conform to syslog-protocol or does it include messages in a proprietary format
that may or may not be emitted as syslog-protocol messages?

And when this document talks of this being used to manage a group of syslog
devices, what makes this a group?  Are they all running under the same instance
of an operating system (allowing sysplex as a single operating system)?  If not,
what makes it a group?

Tom Petch

---

From: Glenn Mansfield Keeni <[email-masked]>
Date: Mon, 23 Jan 2006 14:42:02 +0900

Tom,
> of this MIB for an entity that is only involved in sending packets conforming to
Hmm. I do not envisage the MIB being used for a pure sender. The Syslog daemon is
the target.
> that may or may not be emitted as syslog-protocol messages?
In the text "message" denotes "Syslog Message". I will add a sentence clarifying
that.
> of an operating system (allowing sysplex as a single operating system)?  If not,
It means that there may be more than one Syslog daemons running on different ports
/network addresses. The grouping is a feature not a necessaity. I think that it is
providing flexibility that will be needed. Am I missing something here ?

Glenn
>>>I have had a look at the syslog MIB, and am confused, at a fairly
> 
> fundamental
> 
>>>syslog-protocol.  The last two have a common framework/architecture, spelt
> 
> out
> 
>>>at the beginning of each, with a common terminology of device, relay,
> 
> collector,
> 
>>>Thus, it is a device MIB (not a protocol MIB) (quoting) 'to monitor a group
> 
> of
> 
>>>syslog devices' and 'One or more syslog devices which may be on the same
> 
> host'.
> 
>>>'"facilities" generate messages indicating their own status or the occurance
> 
> of
> 
>>>events. These messages are handled by what has come to be known as the
> 
> syslog
> 
>>>process or device'
>>
>>application ( doing a specific task viz. receiving and forwarding syslog
> 
> messages).
> 
>>There may be several syslog daemons on a host. That has been provisioned for
> 
> in the
> 
>>MIB.
>>
>>>could be but I think I am> lost here and that the introduction should be
> 
> recast
> 
>>>in the language of RFC3164/syslog-protocol (even if it is intending to
> 
> convey the
> 
>>>above).
>>
>>Right. I will find a better name for the entity that we intend to manage using
> 
> the
> 
>>MIB and of course must not conflict with the terms used in
> 
> 3164/syslog-protocol. In
> 
>>the absence of a better name I may use the term "entity" itself. It receives,
> 
> stores
>

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 24 Jan 2006 12:46:22 +0100

----- Original Message -----
From: "Glenn Mansfield Keeni" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 23, 2006 6:42 AM
Subject: Re: [Syslog] draft-ietf-syslog-device-mib-07.txt

> providing flexibility that will be needed. Am I missing something here ?

Getting there; recall that my initial problem is one of understanding what it is
the MIB caters for.  I had expected the MIB to cater for a pure Sender, in order
to configure it with where to send what, and I am slightly suprised at that
omission.  As ever, it is a question of reaching rough consensus on questions
like this.

Likewise, grouping is not something I am familiar with, seeing rather a single
Collector with proprietary features behind it to filter, disseminate etc.

Tom Petch

---

From: Glenn Mansfield Keeni <[email-masked]>
Date: Thu, 26 Jan 2006 14:43:56 +0900

Tom,
> omission.  As ever, it is a question of reaching rough consensus on questions

Right. I will reword the answer.
The MIB serves to monitor  entities that receive and/or forward syslog messages
e.g. the unix syslog daemon.
Note that the MIB allows us to monitor all the syslog messages even if we do not
monitor senders. [There is nothing in the MIB that prohibits one from monitoring
the senders for syslog messages, but it is better done by monitoring the entity
that receives syslog messages (from multiple entities) and forwards some of those
messages].
> Collector with proprietary features behind it to filter, disseminate etc.

We are focussing on the simple and primary task of monitoring syslog messages from
syslog entities. The MIB will support several syslog daemons which are probably using
various transports (UDP{4|6}, TCP{4|6}, on standard and non-standard ports.). This
situation does arise in practice. I think that the MIB does take care of that nicely
using the concept of grouping.

One good way to look at the MIB is as a collection of knobs and dials. Then we can
ask
    a. Do we need another knob or another dial
    b. Do we need this knob or that dial

Cheers

Glenn

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 26 Jan 2006 18:17:00 +0100

Understand; the knob and dial I was expecting to see and do not was for the
Sender.  I was expecting to be able to configure the Sender with where to send
what, what severity levels and such like.  Also, I was expecting to see
statistics from the Sender's point of view.  This is an insecure, unreliable
transport (UDP) so knowing what made it to the Collector is only half the story;
what left the Sender would tell us what did not make it or what got spoofed.

I will shut up for the time being and see if any one else chips in.  I do have
some comments on the SMI but that can wait until this is resolved.

Tom Petch