[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime
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" <rgerhards@hq.adiscon.com>
To: <syslog-sec@employees.org>
Sent: Thursday, April 21, 2005 8:59 PM
Subject: [Syslog-sec] RE: protocol-11.txt - sysUpTime
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:ietfdbh@comcast.net]
> 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
> dbharrington@comcast.net
>
> > ####
> > 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
> > Syslog-sec@www.employees.org
> > http://www.employees.org/mailman/listinfo/syslog-sec
> >
>
>
>
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec