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).
This sounds good. ..I'm trying to remember if this is what was
first discussed for RSID when John Kelsey first proposed a counter
for this.
The original intent of RSID is an opaque unique value that could be
used in a number of ways. It had no original semantics, beyond the
obvious ones needed for a counter.
Later, you and I observed that a timer more-or-less works as it's
monotonically increasing and thus not going to repeat. We added in the
SNMP things in Jan 2002.
Here's text:
4.2.2. Reboot Session ID
.... 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. Hence, an originator needs to retain the previous Reboot
Session ID across reboots. .....
If the value reaches 9999999999, then manual
intervention may be required to subsequently reset it to 1.
Implementors MAY wish to consider using the snmpEngineBoots value as
a source for this counter as defined in [RFC3414].
Kelsey's solo -01 draft says in its entirety:
2.3.4 Reboot Session ID
The reboot session ID is a 48-bit quantity encoded in base 64 as
eight bytes, which is required to never repeat or decrease in the
lifetime of the device.
That text remains in my -04 unaltered. In -05, the reference to
snmpEngineBoots appears, and I remember you (Chris) and I discussing
beforehand that it could be a timer (which meets the requirements of
the original) or an SNMP equivalent.
I will also note that it doesn't take a lot of lawyering to note that
there are other implementations that meet the original requirements
including a hash or hmac with frosting and sprinkles to manage
collisions, (or even just ignoring the collision issue, in some
cases), a 48-bit finite field, and many other things that are more
complex than and technologically inferior to the naive reboot counter.
I'll also note that if we went back to John's original of a 48-bit
number in base64, then a 48-bit timestamp (truncate 64-bit time_t) is
good enough, too.
Jon
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
