W.r.t. > 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. > Good point!
> 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. > OK, that is what we need to know. > 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?) > You can understand that those "other MIB modules" will also use argument 1) to not have to change, rigth? > 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 can live with that if that is the consensus. Bert > /js -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
