A belated but partial agreement with David ie specify that there is no decimal point. This, for me, helps to reinforce the point(:-) that this is in TimeTicks units and not seconds.
ASCII I don't think belongs there. I see that as specifying a transfer syntax and we already say that that is UTF8. What's the right term for the graphic representation (as opposed to the encoding)? glyph? character? Tom Petch ----- Original Message ----- From: "David B Harrington" <[EMAIL PROTECTED]> To: "'Rainer Gerhards'" <[EMAIL PROTECTED]>; "'syslog'" <syslog-sec@employees.org> Sent: Friday, May 06, 2005 3:11 PM Subject: 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 > [EMAIL PROTECTED] > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] 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 > > > > [EMAIL PROTECTED] > > > > > > > > > -----Original Message----- > > > > > From: Tom Petch [mailto:[EMAIL PROTECTED] > > > > > Sent: Saturday, April 23, 2005 6:03 AM > > > > > To: [EMAIL PROTECTED]; 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" <[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 > > > > > > > _______________________________________________ > > > 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
