Hi Rainer, On Tue, 26 Aug 2003, Rainer Gerhards wrote:
> > John and Jon have updated syslog-sign: > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-12.txt > > > > I believe that Albert suggested that more characters be added > > to the TAG > > field. He said that "@" would be good. Are there any others > > that should > > be added in Section 2.2? I'd like to get that resolved and > > then move this > > work along to WG Last Call and then submission to the IESG as it is > > looking very complete now. > > I am sorry to eventually come into your way, but a quick question to > 3.4, the reboot session ID. My apologies if this already was discussed, > but the WG mailing lists archive search did not work and I did not find > a related post by browsing. It seems to be having toubles. :-( > > -sign says, the reboot session ID mus not be automatically reset to 0 if > it latches at 9999999999. I agree that this is a fairly big number. But > think about a tool like logger. As of my understanding, each > command-line invocation would create a new "reboot session". Now think > of it being used for years.... I am not sure if we would eventually hit > the high mark. On the other hand, it would take years to wrap back to 0. > So is it really that bad to allow for automatic rollover? I am asking > because I assume implementors would do it anyhow. Take my logger > example: when coding this, would I really stop processing when I hit the > highest number? I have to admit I would implement an automatic rollover, > simply because I would eventually loose vital log data if I would not do > it - which is in my point of view worse. That was mostly pulled from the SNMPv3 User-based Security Model: ---snip--- Whenever the local value of snmpEngineBoots has the value 2147483647 it latches at that value and an authenticated message always causes an notInTimeWindow authentication failure. In order to reset an SNMP engine whose snmpEngineBoots value has reached the value 2147483647, manual intervention is required. The engine must be physically visited and re-configured, either Blumenthal & Wijnen Standards Track [Page 14] RFC 2574 USM for SNMPv3 April 1999 with a new snmpEngineID value, or with new secret values for the authentication and privacy protocols of all users known to that SNMP engine. Note that even if an SNMP engine re-boots once a second that it would still take approximately 68 years before the max value of 2147483647 would be reached. ---/snip--- They chose 2147483647 because that fits nicely into a hex value. Since we are dealing with decimal, we could expand that. Since our number is about 3x larger, I figure that it should last over 200 years even at a reboot per second. I don't think that anyone has yet built a computing device with a life expectancy of 68 years - let alone 200. :-) Seriously, based on that would you recommend a change? Thanks, Chris
