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" <[EMAIL PROTECTED]> To: "'Tom Petch'" <[EMAIL PROTECTED]>; "'Rainer Gerhards'" <[EMAIL PROTECTED]>; <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 > [EMAIL PROTECTED] > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> > > 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:[EMAIL PROTECTED] > > > 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 PROTECTED] > > > > > > > #### > > > > 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
