TCP Extended Statistics MIB
draft-ietf-tsvwg-tcp-mib-extension-15

[These are questions asked in ignorance of what MIB-Dr. Review has gone on, from simply reviewing the document as is.  If they've been covered already, please accept my apologies.  Please don't just make changes willy-nilly, these are really requests to think about these topics, not necessarily change them]

There are a couple of objects that are clearly counters with syntax Gauge32 instead of ZeroBasedCounter32.  Is this on purpose?

tcpEStatsPerfZeroRwinSent
tcpEStatsPerfZeroRwinRcvd

Meta-question: tcpEStatsPerfElapsedMicroSecs is not TimeTicks because more resolution is required?

Should tcpEStatsPerfSndLimTimeRwin, tcpEStatsPerfSndLimTimeCwnd, tcpEStatsPerfSndLimTimeSnd be TimeInterval (from SNMPv2-TC:
            "A period of time, measured in units of 0.01 seconds."

Since tcpEStatsPathNonRecovDAEpisodes mentions an absolute value, implying that a single value has information content, should it be ZeroBasedCounter32?

Since tcpEStatsPathSumOctetsReordered describes a formula to calculate it, implying that a single value has information content, should it be ZeroBasedCounter32?

Unsigned32 feels like a better type for values that don't change for tcpEStatsStackSndInitial and tcpEStatsStackRecInitial - they're not counting anything (and you're not allowed to depend on the absolute value of a Counter)

It strikes me that Unsigned32 may be a more appropriate type than Gauge for the limiting values in tcpEStatsTuneTable - Gauge feels like it's for monitoring, not for limiting.


A meta-comment about HC counters - do we really expect that there are systems that can't do 10Mb/sec?  Given the conformance language, aren't the HC counters actually required?

I changed my DISCUSS into a COMMENT. RFC Editori, please make sure this is taken care. 

The copyright notice in the MIB module needs to mention The Internet Trust rather than The Internet Society, as per section 2.8 in rfc4748