> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Chris Lonvick > Sent: Sunday, March 22, 2009 11:10 PM > To: [email protected] > Cc: [email protected] > Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits > > Hi, > > There does seem to be some conflicts in the section; if it SHOULD start > with 1 and increment by 1 then how do we get to SnmpEngineReboots?
What if we just say "must start at 1 and be strictly monotonically increasing"? I think this is the essence of what we need and permits any value to be used as seed as long as it can be assured that a higher RSID will be emitted later in time than a lower one. This would also permit any other second-counting time base reference to be used, e.g. creation/compilation date of the software in question. If we refer to the POSIX timestamp, I am not sure if we refer to the 32 or 64 Bit version of it (I even think I remember the bitness is not preciesley defined?). In any case, we have subtle issues: if we talk about 32 bit, the well-known 2038 problem is carried over to this draft. While 28 more years to go sound reasonable, I'd still think it is worth pointing out. With 64 Bit, the RSID will latch ~ 2110 when 64 bit Unix time goes beyond 9,999,999,999 - that is probably not a real concern ;) With any time-based counter based on seconds, there is always the subtle issue of two or more restarts within a single second, which means the RSID will not necessarily be strictly monotonically increasing. While the probability is (very) low for this case, it is not 0. So we cannot outrule it. I have not yet checked if that can lead to permanent problems (counters related to RSID which may occur twice). SNMP, as I understand RFC3414, seems to have solved this by requiring the device to actually increment the counter and store it in non-volatile memory. I think this is a good compromise and would suggest the we mandate this, too, except that we permit any increment as long as the resulting sequence will be strictly monotonically increasing (this is necessary to permit simply copying over the SNMPEngineBoots counter from the SNMP subsystem, if syslogd has access to it). Also, RFC 3414 uses 2147483647 as a special value, while we use 0. I suggest that we use 2147483647, too. Otherwise, a naive implementation may forget to convert 2147483647 to 0 when copying over the SNMPEngineBoots from the SNMP engine (this sounds natural to do if the syslogd has access to a SNMP subsystem). Rainer > > PROPOSED: > === > 4.2.2. Reboot Session ID > > The Reboot Session ID is a decimal value that has a length between > 1 > and 10 octets. The acceptable values for this are between 0 and > 9999999999. Leading zeroes MUST be omitted. > > A Reboot Session ID is expected to increase whenever an originator > reboots in order to allow collectors to distinguish messages and > message signatures across reboots. There are several ways in which > this may be accomplished. In one way, the Reboot Session ID may > increase by 1, starting with a value of 1. Note that in this case, > an > originator is required to retain the previous Reboot Session ID > across > reboots. In another way, a value of the unix time (number of > seconds > since 1 January 1970 [reference?] may be used. In yet another way, > implementors wish to consider using the snmpEngineBoots value as a > source for this counter as defined in [RFC3414]. > > In cases where an originator is not able to guarantee that the > Reboot > Session ID is always increased after a reboot, the Reboot Session > ID > MUST always be set to a value of 0. If the value can no longer be > increased (e.g., because it reaches 9999999999), then manual > intervention may be required to subsequently reset it. > > If a reboot of an originator takes place, Signature Block messages > MAY use a new PROCID. However, Signature Block messages of the > same > originator MUST continue to use the same APP-NAME and MSGID. > === > > Does this work for everyone? > > Thanks, > Chris > > On Sun, 22 Mar 2009, [email protected] wrote: > > > > > Hi Alex, > > > > By "timestamp", at least I've meant "POSIX timestamp (seconds since > > 1/1/1970) when the syslog daemon started". But even with the new > > text, I'm still having trouble determining whether this would be > > an acceptable value for RSID... > > > > Best regards, > > Pasi > > > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected]] On Behalf Of ext Alexander > >> Clemm (alex) > >> Sent: 22 March, 2009 19:06 > >> To: Martin Schütte; [email protected] > >> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits > >> > >> Hello Martin, > >> > >> I have clarified in the text that what I think it is you are > >> suggesting will be allowed. But it is not a time stamp. A time > >> stamp would be something like 2008-10-16T20:23:03+02:00. > >> > >> While it still suggests that the RSID should increase by 1, it is > >> not required. It is merely required to simply increase (no problem > >> with an RSID reflecting a "time stamp"), unless it is set to 0. > >> Here is what the section in question reads now: > >> > >> The Reboot Session ID is a decimal value that has a length > >> between 1 and 10 octets. The acceptable values for this are > >> between 0 and 9999999999. Leading zeroes MUST be omitted. > >> > >> A Reboot Session ID is expected to increase whenever an > originator > >> reboots in order to allow collectors to distinguish messages and > >> message signatures across reboots. The Reboot Session ID SHOULD > >> increase by 1, starting with a value of 1. Note that in this > case, > >> an originator is required to retain the previous Reboot Session > ID > >> across reboots. > >> > >> In cases where an originator is not able to guarantee that the > >> Reboot Session ID is always increased after a reboot, the Reboot > >> Session ID MUST always be set to a value of 0. If the value can > >> no longer be increased (e.g., because it reaches 9999999999), > >> then manual intervention may be required to subsequently reset > >> it. Implementors MAY wish to consider using the snmpEngineBoots > >> value as a source for this counter as defined in [RFC3414]. > >> > >> Does this accommodate your concern? > >> --- Alex > >> > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected]] On Behalf Of Martin Schütte > >> Sent: Thursday, March 19, 2009 1:15 PM > >> To: [email protected] > >> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits > >> > >> Alexander Clemm (alex) schrieb: > >>> On the first item, yes, the first item (RSID) is clearly a > >> counter; a > >>> time stamp cannot be used, nor can a value that is arbitrarily > >>> generated. > >>> > >>> To use a time stamp would require a parameter that is differently > >>> defined than the current RSID. > >> > >> Excuse my persistance here, but: why? > >> Especially if they do not have to be sequential. > >> > >> Is there any reason to define RSID as a counter instead of an > >> increasing > >> ID? When is a counter like 1-2-5-6 better than IDs like > >> 1234400000-1234500000-1234600000-12374700000? > >> > >> -- > >> Martin > >> _______________________________________________ > >> Syslog mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/syslog > >> _______________________________________________ > >> Syslog mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/syslog > >> > > > > _______________________________________________ > > Syslog mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
