[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime
Is that decimal digits? Hexadecimal?
Is there a decimal point?
Are the digits represented in ASCII characters? EBCDIC? UTF-8?
Suggested text:
"value MUST be represented as a decimal integer (no decimal point)
using only the ASCII characters for the range 0..9."
David Harrington
dbharrington@comcast.net
> -----Original Message-----
> From: syslog-sec-bounces@www.employees.org
> [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of
> Rainer Gerhards
> Sent: Friday, May 06, 2005 6:27 AM
> To: syslog
> Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime
>
> Hi all,
>
> I have not received any objection to my post below, so I now define
> sysUpTime as follows:
>
> ####
> 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].
>
> As syslog does not support the SNMP "integer" syntax directly,
the
> value MUST be represented as a string of digits.
> ####
>
> Rainer
>
> > -----Original Message-----
> > From: syslog-sec-bounces@www.employees.org
> > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of
> > Rainer Gerhards
> > Sent: Tuesday, April 26, 2005 12:04 PM
> > To: syslog
> > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime
> >
> > Hi all,
> >
> > please let me elaborate a little on my experience with syslog
> > use cases.
> > As far as I have seen, there are two major use cases:
> >
> > #1 trouble shooting/setup
> > This is an activity done close to real-time. Here, the raw syslog
> > messages are reviewed by the administrator. The most
> important part in
> > this use case is the free-form message. It tells the
> > administrator which
> > problems the device is experiencing or other status data that is
> > valuable at that very instant. Common scenarios are setting up or
> > troubleshooting router filter settings or firewall rule sets.
> > Here, the
> > device is telling via syslog which rules fired and which
> ones not. So
> > the administrator can check his setup. Also, this use case
> > often applies
> > if a new application/device/whatever is being setup in a
> > network and the
> > admin checks messages from the new device and/or existing devices
-
> > especially if it doesn't work as it should. This use case might be
> > called the "tail -f /var/log/messages" case - just to stress
> > my point...
> >
> > The common thing about this scenario is that the
> administrator reviews
> > raw message in more or less real time.
> >
> > #2 reporting/analysis
> > In this use case, consolidated syslog data is viewed. Raw
> data is NOT
> > viewed. Typically, the analysis is not real-time but acting
> > on past data
> > (though there are some analysis tools which work in real-time or
> > close-to-real-time and then issue alerts based on the
> result of their
> > ongoing analysis). In this use case, a program/script/whatever
> > programmatically reads the syslog entries and somehow
> transforms them
> > into a format that is more understandable by a human. The
> > administrator
> > views the (transformed) end result.
> >
> > Of course, these use cases do not exclude each other. For
> example, it
> > might very well be that an administrator detects an anomaly in a
> > consolidated report (use case #2) and then investigates its
> cause via
> > real-time trouble shooting (use case #1). Eventually, he
> will generate
> > other reports on the fly before he looks at the raw data.
Eventually
> > he'll never look at any raw data because it is not required for
that
> > troubleshooting purpose.
> >
> > Obviously, there are a lot of different use cases. But based on my
> > experience the two above apply to the majority of cases.
> >
> > Now if I look at what the administrator actually does, I
> would expect
> > that in use case #1 sysUpTime will be of little to no help.
> The reason
> > is that the administrator either has recently set up / rebooted
the
> > device and so he knows how long it is up. Or he might have
> come from a
> > transformed report which included the information. In any
> > case, I think
> > sysUpTime will not be the admins prime focus. In fact, I'd say
that
> > he'll probably ignore STRUCTURED-DATA at all and just focus on the
> > human-readble part of the message (MSG).
> >
> > In case #2, sysUpTime will be helpful, but primarily to the report
> > logic. I assume that a decent reporting engine will convert any
> > user-unfriendly data type into information that the admin can
easily
> > make sense of.
> >
> > Again, there are more use cases than the two outlined above.
> > Also, I do
> > not claim to have absolute knowledge about what users do with
their
> > syslogs. However, I am working for a long time in this field
> > and this is
> > honestly what I have seen in practice.
> >
> > If (and only if) my observations are true, that would mean we
> > could use
> > the "user-unfriendly" SNMP integer and only need to specify
> > that it must
> > be represented in string form (because syslog does not
> support binary
> > fields).
> >
> > Any feedback is highly appreciated.
> >
> > Rainer
> >
> > > -----Original Message-----
> > > From: syslog-sec-bounces@www.employees.org
> > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of
> > > David B Harrington
> > > Sent: Saturday, April 23, 2005 2:28 PM
> > > To: 'Tom Petch'; 'syslog'
> > > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime
> > >
> > > If the expectation is that syslog messages will be read in
> > syslog raw
> > > format by humans more than by programs, then I agree it
> > should be done
> > > in a presentation format in the message. Under those conditions,
I
> > > suggest breaking out the days, hours, minutes, etc.
> > >
> > > If the expectation is that this field will be used by prgrams
more
> > > than humans, then the raw format woul dbe better.
> > >
> > > Of course, if there are suitable use-cases for each, you
> could also
> > > achieve both a human-friendly and a machine-friendly approach:
> > > "142days:2hr:8min:13sec:9 (123456789)".
> > >
> > > David Harrington
> > > dbharrington@comcast.net
> > >
> > > > -----Original Message-----
> > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]
> > > > Sent: Saturday, April 23, 2005 6:03 AM
> > > > To: ietfdbh@comcast.net; syslog
> > > > Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime
> > > >
> > > > David
> > > >
> > > > Yes, your wish to clarify the intended users of syslog
> > > > messages is best done
> > > > first. I assume it is humans like myself (even though I have
> > > > coded log
> > > > analysers).
> > > >
> > > > Having clarified the users, then I will press again for a
> > > > defined presentation
> > > > format. In syslog, sysUpTime is an SD-ID so it is encoded in
> > > > UTF8 and as far as
> > > > I know, UCS only has the concept of characters, not of
> > > > integers, so if the
> > > > presentation format is
> > > > to be standardised, we must do it.
> > > >
> > > > Tom Petch
> > > > ----- Original Message -----
> > > > From: "David B Harrington" <ietfdbh@comcast.net>
> > > > To: "'Tom Petch'" <nwnetworks@dial.pipex.com>; "'Rainer
> Gerhards'"
> > > > <rgerhards@hq.adiscon.com>; <syslog-sec@employees.org>
> > > > Sent: Thursday, April 21, 2005 11:48 PM
> > > > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime
> > > >
> > > >
> > > > > 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
> > > > > dbharrington@comcast.net
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: syslog-sec-bounces@www.employees.org
> > > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf
> > > > Of Tom Petch
> > > > > > Sent: Thursday, April 21, 2005 4:12 PM
> > > > > > To: Rainer Gerhards; syslog-sec@employees.org
> > > > > > Subject: 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
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > 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
>
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec