Subject: [Syslog-sec] RE: protocol-11.txt - sysUpTime

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 21 Apr 2005 20:59:06 +0200

David,

I did specify this based on Tom's comment that the SNMP definition could
not be used for syslog. I reviewed the SNMP RFCs once again and thought
the point was proved. As it looks, that was wrong. So I will revert back
to the previous definition which simply states that it should be RFC
3418 compliant. Thanks for pointing this out.

Rainer 

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]] 
> Sent: Thursday, April 21, 2005 7:51 PM
> To: Rainer Gerhards; 'syslog'
> Subject: protocol-11.txt - sysUpTime
> 
> Hi,
> 
> You state that semantics and syntax are as defined in RFC 3418, then
> proceed to define a different syntax. It is a bad practice to claim
> consistency with something, and then reinvent it but keep calling it
> the same thing. We should decide what we want here.
> 
> If the goal is consistency with SNMP, then we should use the syntax
> used for the SNMPv2-MIB sysUpTime [RFC 3418]. That syntax is a
> TimeTicks value (INTEGER 0..4294967295 hundredths of a second, with no
> decimal points) since reinitialization of the (SNMP) management
> system. 
> 
> If the goal is to define a syslog-specific version of sysUpTime, then
> we should skip the reference to RFC 3418, call it something else, and
> define it fully as a syslog field. If we go this route, then we should
> discuss what re-initialization of the management system means - is
> this re-initialization of the SNMP management system, or is it the
> re-initialization of (a particular part of) the syslog system? We
> might also want to document rollover behavior.
> 
> David Harrington
> [email-masked]
> 
> > ####
> > 7.3.2  sysUpTime
> > 
> >    The "sysUpTime" parameter MAY be used to include the SNMP 
> > "sysUpTime"
> >    parameter in the message.  Its syntax and semantics are as 
> > defined in
> >    RFC 3418 [12].
> > 
> >    In syslog, it is represented as a decimal string with a maximum
> of
> >    two digits for fractional seconds.  Full seconds and fractional
> >    seconds MUST be delimited by a period (".").  Leading 
> > zeros MUST NOT
> >    be used for full seconds.  For example, a "sysUpTime" of one
> minute
> >    MAY be represented as "60", "60.0", or "60.00", but not as "060"
> or
> >    "60.000".
> > ####
> > 
> > I am not so proficient with SNMP, but I think (as you said) 
> > TimeTicks is
> > actually integer. So we should have a maximum value defined plus a
> > rollover behaviour. Or does this mean we also need to include 
> > an epoch?
> > ;)
> > 
> > Rainer
> > _______________________________________________
> > Syslog-sec mailing list
> > [email-masked]
> > http://www.employees.org/mailman/listinfo/syslog-sec
> > 
> 
> 
> 
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 21 Apr 2005 22:11:44 +0200

I will try again.

I believe we need a specification of how sysUpTime is displayed in the syslog
message and I do not believe the I-D gives it. ( I am happy to use the concept
of sysUpTime as defined in RFC 3418).

The I-D refers to syntax and I see a problem here.When SNMP, as in RFC3418,
says it has a syntax of TimeTicks by this it means a data type, an object type,
in this case a integer of up to 32 bit (which can be encoded in one or two or
three or four octet) and not much more.  Elsewhere in the IETF I find syntax
used in a different, wider sense. So I was, and I am sorry I did not spell it
out more, suggesting that using syntax in the context of syslog when referring
to SNMP was likely to lead to confusion.  In which sense is the word being used?

Some definitions in SNMP have display hints associated with them; as far as I
know, there is none for sysUpTime (ie TimeTicks) - David will put me right if I
am wrong  - and I struggle to think of a useful one.  378 is fine when I am
analysing the log of the early stages of a reboot; 1576800000 is not very
friendly when the server has been up for six months.  (And even if there is a
display hint somewhere in tthe RFC, you might need the help of a MIB doctor to
find it:-).

So I see the reference to RFC 3418 as leaving the field wide open for any
representation of a time interval which could be as large as 2**32 - 1 /100
second or as small as 0.01.  I know of nothing in SNMP to stop it being
represented in days:hours:minutes:sec.onds.  And this feels right; sysUpTime is
not a user-friendly concept, rather something that a low cost agent can cheaply
handle; different SNMP managers present it differently (and yes, some do it in
days etc)..

I think we should nail the representation down. I do not have a good suggestion
for what that should be.  Probably ddddddd.hh in seconds; having an integer in
units of hundredths of seconds is more architecturally pure but will confuse
those not familiar with SNMP, which I suspect will be the majority of syslog
users.

Tom Petch

----- Original Message -----
From: "Rainer Gerhards" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, April 21, 2005 8:59 PM
Subject: [Syslog-sec] RE: protocol-11.txt - sysUpTime

David,

Rainer

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 21 Apr 2005 17:48:20 -0400

Hi Tom,

Thank you for the good desacription of your concerns.
You are correct; RFC3418 does not have a DISPLAY-HINT.

SNMP is designed to be a programmatic interface, not a human-friendly
interface; SNMP management applications often convert the unfriendly
sysUpTime into days: hours: minutes: seconds, and so on, as you
suggest. 

Syslog is designed to be more user-friendly. Syslog certainly can
convert the sysUpTime value into something more readily understood by
humans. One concern I have with that approach is that, in the SNMP
world, we try to keep all unnecessary processing out of the agent and
in the management application, so the device being managed can focus
on forwarding packets or whatever, and not on converting raw data into
friendlier forms. While minimizing the management processing of
internetworking devices was critically important in 1980, and is stil
important in resource-limited devices such as set-top boxes, many
systems now have at least some capability to spare.

So my question is, do the bulk of syslog users read the raw syslog
messages without any automation, or do the bulk of operators now use
tools to help filter syslogs, given the tremendous amount of
information available in the logs? I'm sure there are multiple
use-cases. [I do not know the answer to the question; it is not
rhetorical.]

If they are already using tools to view (and possibly correlate) the
messages, could those tools do the conversions of the raw sysUptime,
or is it really necessary for the originator to do the conversion of
sysuptime when logging the message? 

Do operators view the raw messages under certain circumstances, such
as when they are troubleshooting in real-time? Are they likely to also
be looking at the raw SNMP as well, say as an Ethereal packet capture
of both syslog and SNMP messages? If so, then having the syslng raw
sysUptime match the SNMP raw sysUptime might be useful; if they are
comparing syslog and SNMP traffic, and SNMP gives them an integer, and
syslog gives them a formatted string in
days:hours:minutes:seconds:hundredths format, that would make it
harder for them rather than easier.

This WG seems to be working toward improving the ability to correlate
syslog and SNMP events. What are the use-cases that this WG is trying
to target with this effort at consistency between syslog and SNMP?
What are we trying to achieve by having the SNMP sysUptime in the
syslog message?

Is there a real goal here, or is consistency with SNMP just
feature-creep?

David Harrington
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Petch
> Sent: Thursday, April 21, 2005 4:12 PM
> To: Rainer Gerhards; [email-masked]
> Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime
> 
> I will try again.
>