Thanks for the feedback. My comments inline.
Juergen Schoenwaelder wrote:
Rajiv Raghunarayan writes:
Rajiv> The IESG review suggested that we provide a discontinuity timer
Rajiv> for the counters in the mib - could be via sysUpTime or a new
Rajiv> discontinuity object. But we state it either way.
Here are my 3 thoughs on this:
1) So far, sysUpTime has been used by the existing TCP-MIB objects. Introducing a new discontinuity indicator now raises the question whether doing so breaks existing implementations.
Yep. It would probably break implementations if 2) were to be an incorrect assumption for any implementation. Else, I think we shouldn't be affecting other implementations (but those case wouldn't need a separate discontinuity indicator as well!)?
2) Personally, I doubt that there will be many implementations where TCP can experience discontinuities that do not also affect other parts of the networking stack or the whole system.
I suspected that, but wasn't sure.
3) I do see the problem that sysUpTime might be more frequently reset as we like due to some other MIBs which do not use explicit discontinuity indicators and experience more frequent resets. However, the root of the problem is then really in those MIBs, not in the TCP-MIB. (Sure, by introducing a discontinuity indicator for the TCP-MIB we can protect against other misbehaving MIBs - but is this going to set a precedence which at the end requires a CLR that better every MIB module has at least one, perhaps multiple discontinuity indicators?)
Agreed.
In the case of the TCP-MIB, I believe 1) is the killing argument. To introduce a new discontinuity indicator changes the implicit semantics of existing objects and would require to introduce new objects, which I think is prohibitive.
Conclusion: Spell out that sysUpTime is used as a discontinuity indicator for the counters.
I've modified the mib to indicate it - will submit the mib, if I do not receive any arguments to the contrary in the next couple of days.
Thanks, Rajiv.
/js
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
