TCP-ESTAT-MIB Completed Issues See TODO.txt for pending issues and context These are in forward order (oldest at the top) ================================================================ Issue: 200402ka1 disallow listen state DONE > - Since there is a separate table for Listeners, I assume that no TCP > connections in Listen state should be supported in any of the other > tables, correct? If so, should the description of > tcpEStatsConnectionState indicate that listen(2) should never be used, as > is stated in the version-neutral TCP-MIB for object tcpConnectionState? Correct. I will update the document. ================================================================ Issue: 200402ka2 explain final completion stats DONE > - The tcpEStatsConnectIdTable description states that "Entries are > retained in this table for at least 30 seconds after the TCP connection > first enters the closed state." Is this true only of this table and not > the entries in the other tables? If so, why does this apply to this > table? Doesn't this mean that there could be entries in this table, for > which there are no corresponding entries in the other tables? This is a feature to make it possible to collect completion stats (total packets, bytes, retransmissions, etc) for each connection. To be sure that you see everything you want to be able to read the stats after the connection is really dead. I don't think the other tables are useful after the connection is closed, but I will think about it. ================================================================ Issue: 200402ka3 explain not writable state DONE > - tcpEStatsConnectionState has a MAX-ACCESS of read-only, but > tcpConnectionState in the version-neutral TCP-MIB has a MAX-ACCESS of > read-write. Should they both have the same MAX-ACCESS value? Writing to tcpConnectionState supports a special function to force connections closed (as in an mechanism to remotely abort connections). This has always been subject to debate (and as far as I know, never implemented). It doesn't seem useful in the extended statistics MIB. ================================================================ Issue: 200402ka4 TOS has been replaced by DSCP DONE > - tcpEStatsDataIpTos: Haven't IPv4 TOS and IPv6 traffic class been > superceded by DSCP? Since TOS seems to belong to IPv4, wouldn't it be > better to use a different name for this object, one that applied to both > IPv4 and IPv6? Ooops I am out of date here. Can you provide a pointer to a similar object in some other MIB? ================================================================ Issue: 200402ka5 explain SndNxt not counter DONE > - tcpEStatsDataSndNxt: Should this object have a syntax of > ZeroBasedCounter32 instead of Integer32? Nope, because SndNxt in not monotonic. During a "Tahoe" style loss recovery SndNxt is pulled back to SndUna. In modern TCPs this generally happens only following a timeout, but it is a required part of the TCP specifications. For the other sequence numbers, the standard specification for the TCP state variables happens to be consistent with SNMP counters, even though the TCP specification predates SNMP by about a decade. The description should emphasize this point. ================================================================ Issue: 200402ak6 clarify start time DONE > - tcpEStatsDataStartTimeStamp: What does "start of the connection" mean? > Does it mean the time the connection entered the Established state? Correct. I will fix it. ================================================================ Issue: 200402ak7 Add notification control DONE > - Notifications: with lots of short-lived web connections, couldn't there > be a flood of notifications for this MIB? Should there be a scalar object > that controls whether notifications should be created or not? From: Rajiv Raghunarayan As I understand what Kristine is asking for is some way to control the notifications i.e. an enable/disable key. For this we could define one/two TruthValues to control the generation of notifications from the MIB. This is on the same lines as the object mplsL3VpnNotificationEnable in MPLS-VPN-MIB: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mpls-vpn-mib-02.txt mplsL3VpnNotificationEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is true, then it enables the generation of all notifications defined in this MIB." DEFVAL { false } ::= { mplsL3VpnScalars 4 } Further, I think we might also want to document the fact that a large no. of notifications could be generated, depending on connection initiation and termination rate in the object descriptions.. This should help keep users aware of the fact that there could be a notification storm on enabling these notifications. ================================================================ Issue: 200402mm1 sequence numbers are not zero based counters DONE Sequence numbers are not zero based - review all counter types ================================================================ Issue: 200406mm1 Inspect for @@ and other author tags DONE ================================================================ Issue: 200401mm0 Inspect prior TODO list for unresolved items DONE Prior TODO list The TODO list at www.web100.org/mib is a sanitized version of this list DOC Issues Overhaul the introduction ToC DONE Add terminology section (includes a pointer to 1122). Disable hyphenation. DONE Fix form feed Consider adding refs for ALL TCP algorithms (Is there a ref attribute?) Always the opportunity to discover missing instruments. (Most recent: 26 Feb 2003, by "Jamshid Mahdavi" ) Through review by the transport community. Review conformance issues and specifications Add discussion of polling frequencey, e.g. requirement for 64 bit counters Common Var and table issues: Different conformance specifications for HC scalars and HC objects in the per connection tables. Zero Based counters DONE Consider adding flags for ALL TCP algorithms (really a RFC2012bis issue) Per *connection* subtable enables Reverse lookup table Connection table vs other tables Note in the draft from Rajiv: why is the tcpEStatsDataStartTimeStamp a part of the tcpEStatsDataTable?? Why not tcpEStatsConnectionTable - Because all stuff pertaining to times and rate appears here. Mail: Rajiv->Matt, Mar 2 tcpEStatsHCInSegs and tcpEStatsHCOutSegs HC description text tcpEStatsConnectionState duplicated between tables tcpEStatsSynOptsMSSSent: Integer32 v Unsigned32 also tcpEStatsSynOptsMSSRcvd tcpEStatsDataHCDataBytesOut & In Why 10M b/s? Missing "excluding headers" from tcpEStatsDataDataBytesOut and tcpEStatsDataHCDataBytesOut Ref for RFC2012bis is out of date Informative Refs for 2018, 1323 (others1) Mail: Reddy->Matt, Mar 2 tcpEStatsSynOptsEntry, missing "has" tcpEStatsPathSndDupAckEpisodes and tcpEStatsPathNonRecovDA seem to be the same event? One description is botched StartTime: TimeStamp or DateAndTime (make uniform) Duration sec + usec Mail: Rajiv->Matt, Mar 1 Perhaps we could add that "This counter is the 64-bit version of tcpInSegs." rename * to tcpEStatsDataRecInitSeqNum. Mail: Reddy->Matt Feb28 Should "tcpEStatsPathSendStall" be plural? ================================================================ Issue: 200406mm3 Update status page (www) DONE Does not affect the document per se, but might confuse people trying to find the current draft. ================================================================ Issue: 200406rr1 counters were dropped from the TCP-MIB DONE > 1. Some counters were dropped from the TCP-MIB (to constrain > the update to a basic IPv6 update). We might want to include > these in the ESTATS MIB. > > Objects dropped from the tcpConnectionTable include > tcpConnectionInSegs, tcpConnectionOutSegs, > tcpConnectionInOctets, tcpConnectionOutOctets, > tcpConnectionHCInSegs, tcpConnectionHCOutSegs, > tcpConnectionHCInOctets, tcpConnectionHCOutOctets, > tcpConnectionAge and tcpConnectionId. I think these are already present, but under different names. Are they really taking out tcpConnectionId? If so this makes the table useless as far as I am concerned. Due to the different timing stuff we can't even AUGMENT the table in TCP-MIB. > > Objects dropped from tcpListenerTable include > tcpListenerTimeOuts, tcpListenerEstablished and tcpListenerAge. Also there. Confirm! ================================================================ Issue: 200406rr2 update tcpEStatsConnectIdTable to 3291bis DONE > 2. Index of tcpEStatsConnectIdTable needs to comply with > updated version of 3291 (3291bis). > > In addition we need to remove the SIZE restrictions on the > InetAddress objects, and state the same in the description > (as done for 2012bis). ================================================================ Issue: 200406mm4 Review against revised ID checklist DONE http://www.ietf.org/ID-Checklist.html This is really a standing item ================================================================ Issue: 20040615rr1 Update InetAddress objects DONE - Remove size constraint i.e. SIZE(0..36), on InetAddress object. Instead add text to the *Entry descriptions to state restrictions on the length of the OID (as stated in 3291bis i.e. draft3291-05). Further, we should also do away with specifying limitations in the IntetAddressType object e.g. remove the IPv4(z), IPv6(z) limitations below. tcpEStatsConnectLocalAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of tcpEStatsConnectLocalAddress. Only IPv4, IPv4z, IPv6 and IPv6z address types are expected." ::= { tcpEStatsConnectIdEntry 1 } tcpEStatsConnectLocalAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(0..36)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local IP address for this TCP connection." ::= { tcpEStatsConnectIdEntry 2 } ================================================================ Issue: 20040615rr2 text alignment DONE - The following text seems slightly misaligned (especially the "or received" part) "If one of these techniques is in use, then the row may be created when the connection enters the established state, otherwise the row should be created when the first SYN is sent or received." ================================================================ Issue: 20040615rr3 blank page DONE - Is page 6 of the draft intentionally blank? ================================================================ Issue: 20040615rr4 add copyright within the MIB DONE - A copyright statement like the foll. needs to be added to the MIB module description. " Copyright (C) The Internet Society (2004). This version of this MIB module is a part of RFC xxxx; see the RFC itself for full legal notices." -- RFC Ed : replace xxxx with actual RFC number & remove note ================================================================ Issue: 20040615rr6 wcStatsListen description DONE - tcpEStatsConnectionState still seems to have the listen state in the list i.e. wcStatsListen(2), even though the change section mentions that this has been removed. ================================================================ Issue: 20040615rr7 type of tcpEStatsSynOptsMSSSent & Rcvd DONE - Should tcpEStatsSynOptsMSSSent and tcpEStatsSynOptsMSSRcvd be Gauge32, or Unsigned32? Since they are values sent with SYN/SYN-ACKs shouldn't they be Unsigned32? ================================================================ Issue: 20040615rr9 update "snd_nxt" DONE - Minor comment - change snd_nxt to SND.NXT to be consistent in the following description (of the object tcpEStatsDataSndMax) "The farthest forward (right most) SND.NXT value. Note that this will be equal to snd_nxt except when snd_nxt is pulled back during a recovery." ================================================================ Issue: 20040615rr10 update "snd_una", "rcv_nxt" DONE - A similar correction in the description of tcpEStatsDataThruBytesAcked. snd_una => SND.UNA, and tcpEStatsDataHCThruBytesReceived, rcv_nxt => RCV.NXT ================================================================ Issues above resolved prior to -05 draft 20040717 ================================================================ Issue: 20041220mm00 Make active open 3 state NIXED Active, Passive, delayed Passive Nixed - no useful definition for delayed passive that applies to some connections. All implementation now do syn-flood defenses that are some for of delayed passive open. ================================================================ Issue: 20041220mm00 Improve commentary DONE define accept time DONE start time == accept time DONE Expand on Soft Error Reason DONE ================================================================ Issue: 20041220mm00 Improve commentary DONE discuss no headers in Byte stats Triage instrumnets in overview ================================================================ Message: 20041111ka further clarifications Message: 20041104dj (zero based) 32 and 64 bit counters Message: 20041028kaC comments on RTO instruments Message: 20041028kaB will do overview Message: 20041028kaA smilint issues Message: 20041014ka 2 clarifications Message: 20040928ka 11+ issues ================================================================ Issue: 200406mm2 Inspect for missing references DONE Review current tcpwg draft on TCP RFC statuses and put all relevant RFCs into the Bibliography with citations in approporate places. See: draft-duke-tcp-roadmap-00.txt Use "ckrfc all" ================================================================ Issue: 20040716mm1 Replace tcpEStatsListenerStartTime by tcpListenerAge? NIXED Prior to removing ListenerStartTime from 2012bis is was changed to tcpListenerAge. Should the change be made here as well? ================================================================ Issue: 200406mm5 Keep stats for 30 seconds after close? DONE Consider making the delay to delete stats implementation selectable. ================================================================ Issue: 20040615rr11 Should ElapsedSecs, etc be Unsigned32 NIXED - Also wondering if tcpEStatsDataElapsedSecs and tcpEStatsDataDurationMicroSecs should be expressed as ZeroBasedCounter32? Or should they be in terms of Unsigned32? MM: I don't understand the issues ================================================================ Issue: 20040716mm1 describe codes for SoftErrorReason DONE SoftErrorReason - need to describe all error codes ================================================================ Issue: 20040615rr5 Need tcpListenerHCTimeOuts tcpListenerHCEstablished DONE - Should there be 64-bit counter equivalents of tcpListenerTimeOuts, tcpListenerEstablished? (btw, sorry I missed these when I looked last time). This was done as part of the Listener table restructuring ================================================================ Issue: 20040615rr8 Need tcpConnectionHCOutSegs DONE - We also have the connection stats.. that I seemed to miss!! Sorry about that! I think the only set of things missing are tcpConnectionHCInSegs, tcpConnectionHCOutSegs equivalents. Do we need this? ================================================================ Issue: 20040716mm2 smilint error NIXED ./mib.mib:277: [5] {index-exceeds-too-large} index of row `tcpEStatsConnectIdEntry' can exceed OID size limit by 399 subidentifier(s) (Caused by IPAddress in row indexes.) seems to be normal ================================================================ Issues above resolved prior to -06 draft 20050220 ================================================================ Issue 20050314ka01 Questions about sequence variables NIX Introduction: We would also like to support a _basic_ set of per connection performance data, that is, that data which most helps to indicate performance problems. We went through the latest tcpEStatsPerfTable from draft-ietf-tsvwg-tcp-mib-extension-06.txt and here is our feedback on the performance-oriented MIB objects in the table. This feedback is based on debugging performance problems on our platform. tcpEStatsPerfSndUna - not that useful for performance purposes tcpEStatsPerfSndNxt - not that useful for performance purposes tcpEStatsPerfSndMax - not that useful for performance purposes tcpEStatsPerfRcvNxt - not that useful for performance purposes Subject: Part 1 response to 17 Feb 05 ESTATS comments >>>> No action ================================================================ Issue 20050314ka03 Questions about congestion instruments NIX/DONE tcpEStatsPerfCongSignals - not that useful for performance purposes tcpEStatsPerfTimeouts - not that useful; tcpEStatsPerfOctetsRetrans is better tcpEStatsPerfSegsRetrans - not that useful; tcpEStatsPerfOctetsRetrans is better tcpEStatsPerfSumRTT - Not that useful for performance purposes tcpEStatsPerfHCSumRTT - not that useful for performance purposes tcpEStatsPerfCountRTT - not that useful for performance purposes tcpEStatsPerfSampleRTT - not that useful for performance purposes tcpEStatsPerfMaxRTO - not sure how useful this is tcpEStatsPerfMinRTO - not sure how useful this is >>> NIX to CongSignals, Timeouts, SegsRetran >>> Move ..RTT to path table >>>>Proposed action: Move SampleRTT, Min/MaxRTO to Stack table ================================================================ Issue 20050314ka04 Questions about reveiver window instruments NIXED tcpEStatsPerfCurRwinSent - not that useful for performance purposes tcpEStatsPerfMaxRwinSent - not that useful for performance purposes tcpEStatsPerfCurRwinRcvd - not that useful for performance purposes tcpEStatsPerfMaxRwinRcvd - not that useful for performance purposes tcpEStatsPerfZeroRwinSent - useful but other counters track something similar tcpEStatsPerfZeroRwinRcvd - useful but other counters track something similar >>> Cur is critical for debugging application performance problems. Max is critical for distinguishing between app problems and tuning problems ================================================================ Issue 20050314ka06 Questions about Dup ACK instruments DONE/NIXED tcpEStatsPerfDupAckEpisodes - not that useful; tcpEStatsPerfDupAcksOut seems better tcpEStatsPerfDupAcksOut - could be useful >>>> Update descriptions Suggest adding back into perf table - tcpEstatsPathAckAfterFR - along with tcpEstatsPathSndDupAckEpisodes, lets us know if data is arriving out of order on the other side. >>> done tcpEStatsPerfRetranThresh - not that useful for performance purposes >>> required for some stacks ================================================================ Issue 20050629mm01 Add FlightSize DONE Add PipeSize and MaxPipeSize, inRecovery ================================================================ Issue: 20040716jh1 Missing support for tuned application windows DONE We need to add support for applications that need to know the network pipe size. Examples include protocols that rely on pipelining requests (how deep of queue do they need for optimal performance) and multiplexing protocols, which have their own internal flowcontrol windows. (e.g. ssh). None of the current instrumnts are suitable for this task. See 20050629mm01 ================================================================ The above addressed prior to -07 (July 15, 2005) ================================================================ Issue 200507ka split required and non-required within tables DONE This was the most recent table restructuring ================================================================ Issue 20050217ka01 move stuff to ConnectIDTable OBE I don't think the following belong in the ..PerfTable: tcpEStatsPerfState SV tcpEStatsPerfSACK SV tcpEStatsPerfTimeStamps SV tcpEStatsPerfECN SV tcpEStatsPerfNagle SV tcpEStatsPerfActiveOpen 1 bit, SE tcpEStatsPerfSegsOut tcpEStatsPerfDataSegsOut tcpEStatsPerfDataOctetsOut tcpEStatsPerfHCDataOctetsOut tcpEStatsPerfSegsIn tcpEStatsPerfDataSegsIn tcpEStatsPerfDataOctetsIn tcpEStatsPerfHCDataOctetsIn I think it would be better to put these in the ..ConnectIdTable. A management app is going to have to go through the ..ConnectId table anyway to retrieve the ..ConnectIndex to use for the rest of the tables. They could retrieve this basic data while they were doing that. And if they didn't want more detailed information on the connections, they would be done. One of my basic concerns has been that the counters should have been added to the tcpConnectionTable in the new version of the TCP-MIB. If they are going to be defined in the TCP-ESTATS-MIB instead, then let's make it easy for management apps to get the data. They shouldn't have to go through the 2 passes (get ..ConnectIndex and then use it to get counters from ..PerfTable) to get basic counters. I suggested multiple locations for the counter objects. ================================================================ Issue 20050217ka02 Limit PerfTable to 22 items OBE I think we should aim for a ..PerfTable that has a minimum amount of performance data, especially is we are going to recommend that the table be mandatory. I think there are 48 objects in the current table. I don't know, at this time, how many our kernel already supports (except for those objects that we originally suggested for the ..PerfTable). I think we originally suggested 22 objects but we could probably remove a couple of the Max/Min objects and just keep the Cur objects. We thought our list of 22 objects was a set of basic performance data for a TCP connection. Do you not agree with this? >>> Add summary on types of instruments in the introduction e.g. stats on classifications: "state variable" - this object exposes a TCP state variable which is defined in some other standards track document. There is no additional overhead to collect or store the object. "saved variable" - this object exposes a TCP variable that is defined in some other standards track document, but it might not be stored in the TCP state block. These objects introduce one extra memory reference during protocol processing, plus memory overhead to store the object. "simple expression" - this object is computed by a simple expression (typically a comparion or increment) during protocol processing and plus memory overhead to store the object. "complex expression" - This object requires more significant processing overhead to implement. ================================================================ Issue 20050314ka02 Questions about Triage instruments NIXED tcpEStatsPerfSndLimTransRwin - useful tcpEStatsPerfSndLimTransCwnd - useful tcpEStatsPerfSndLimTransSnd - useful tcpEStatsPerfSndLimTimeRwin - not that useful for performance purposes tcpEStatsPerfSndLimTimeCwn - not that useful for performance purposes tcpEStatsPerfSndLimTimeSnd - not that useful for performance purposes Subject: part 2 >>>>Proposed Action: move ..Trans.. to stack table or delete entirely ================================================================ Issue 20050314ka07 questions about rate variables tcpEStatsPerfHCThruOctetsAcked - may be useful tcpEStatsPerfHCThruOctetsReceived - may be useful if this is queried on a fixed interval basis, could give a rough estimate of how fast data is being received tcpEStatsPerfElapsedSecs - not that useful for performance purposes tcpEStatsPerfElapsedMicroSecs - not that useful for performance purposes ================================================================ Issue 20050314ka08 Questions Application Queue OBE - tcpEStatsAppCurAppWQueue and tcpEStatsAppCurAppRQueue - lets us know how well the application is behaving - either sending too quickly or receiving too slowly. ================================================================ The above addressed prior to -08 (Sun Oct 23 12:48:11 EDT 2005) ================================================================ Issue: 20051127bw01 Fix up references DONE !! Missing citation for Informative reference: P067 L039: [RFC3291] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder, "Tex- The reference itself can just be removed; you already have RFC4001 in the list, which obsoletes 3291. But RFC4001 should be NORMATIVE (all docs from which you IMPORT must be normative) And very often, when RFCs are listed in REFERENCE clauses (or should be listed as Dan points out in his comments), they are also normative. In otehr words, one has to understand that REFERENCEd RFC in order to proberly implement the object that includes the REFERENCE to that RFC. !! Missing citation for Normative reference: P065 L013: [RFC2574] U. Blumenthal, B. Wijnen, "User-based Security Model (USM) for RFC2574 is obsoleted by RFC3414. And RFC2575 is obsoleted by RFC3415 RFC2021 and RFC2856 must be normative, you IMPORT from them! DOIT [Issue: 20051127bw02 (extends 20051127dr18)] ================================================================ Issue: 20051127bw03 Sequence numbers as counters DONE I find it strange that these object have a Counter32 SYNTAX: tcpEStatsAppSndMax OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The farthest forward (right most or largest) SND.NXT value. Note that this will be equal to tcpEStatsAppSndNxt except when tcpEStatsAppSndNxt is pulled back during recovery." ::= { tcpEStatsAppEntry 3 } tcpEStatsAppRcvNxt OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of RCV.NXT from [RFC793]. The next sequence number expected on an incoming segment, and the left or lower edge of the receive window." ::= { tcpEStatsAppEntry 6 } DISCUSS which is more important? ================================================================ Issue: 20051127bw04 Words about discontinity DONE I am missing any words about discontinity Timers/possibilities for COunter32, ZeroBasedCounter32 and ZeroBasedCounter64 objects !!?? DISCUSS ask for example ================================================================ Issue: 20051127bw05 Two Address Type fields DONE (nixed) When I see: TcpEStatsConnectIdEntry ::= SEQUENCE { tcpEStatsConnectLocalAddressType InetAddressType, tcpEStatsConnectLocalAddress InetAddress, tcpEStatsConnectLocalPort InetPortNumber, tcpEStatsConnectRemAddressType InetAddressType, tcpEStatsConnectRemAddress InetAddress, tcpEStatsConnectRemPort InetPortNumber, tcpEStatsConnectIndex Unsigned32 } I always wonder if Local and Remote Address types can be different!?? And if not, then I personally would use just one InetAddressType object. About the InetAddressType/InetAddress objects. I see no indication (at least not in the MIB module itself, which is where I looked) about any restrictions. So theoretocally one could use 'dns' as the InetAddressType. In that case, you MUST specify when such a DNS name gets resolbed (as RFC4001 explains). DOIT [Issue: 20051127bw06 (extends 20051127dr14)] ================================================================ Issue: 20051127dr01 does not pass Idnits DONE 1. idnits has problems with the lack of an IANA considerations section (which is mandatory even if no action is required from IANA) and formatting. idnits 1.82 tmp/draft-ietf-tsvwg-tcp-mib-extension-08.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: * The document seems to lack an IANA Considerations section. Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: - It seems as if not all pages are separated by form feeds - found 0 form feeds but 70 pages Miscellaneous warnings: None. COPY text from draft-ietf-pwe3-pw-mib-07.txt DOIT ================================================================ Issue: 20051127dr02 experimental OID & IANA considerations DONE 2. you must leave the assignment of an OID under 'experimental' to IANA and use placeholders instead: So, please include ::= { experimental yyy } Editor's Note (to be removed prior to publication): the IANA is requested to assign a value for "yyy" under the 'experimental' subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace "yyy" (here and in the MIB module) with the assigned value and to remove this note. The IANA Consideration section must include the request to assign yyy. Note: also moved to mib-2 DOIT ================================================================ Issue: 20051127dr03 UNITS clauses DONE 3. Usage of the UNITS clause wherever relevant, especially for counter objects (e.g. 'seconds', 'octets', etc.) although not mandatory would be helpful. DOIT ================================================================ Issue: 20051127dr04 REFERENCE clauses DONE 4. There are numerous instances where references are described in the DESCRIPTION clause of the objects ('see RFC ...') , instead of the optional REFERENCE clause being used. See for example tcpEStatsStackSACK or tcpEStatsStackTimeStamps. I would recommend to fix this. DOIT ================================================================ Issue: 20051127dr05 InRecovery description DONE 5. The following phrase in the DESCRIPTION clause of tcpEStatsStackInRecovery is hard to understand, vague (what algorithms, what conditions?) and looks without value in its current form. tcpEStatsStackInRecovery is a required precondition for some algorithms on other instruments. E.g. Some algorithms to estimate path properties may not be valid during recovery I suggest either to clarify or to remove it. DOIT ================================================================ Issue: 20051127dr06 numerical values in SoftErrorReason DONE 6. In the DESCRIPTION clause of tcpEStatsStackSoftErrorReason while clarifying the enumeration, the numerical values need to be mentioned. e.g. belowDataWindow(1) DOIT ================================================================ Issue: 20051127dr07 Security of read-write MAX-ACCESS DONE 7. Although there are a number of objects in the MIB module with a MAX-ACCESS of read-write the Security Consideration section does not include an explicit list of these objects, and the security hazards incurred by inappropriate configuration of these objects, but only the generic boilerplate text. This is insufficient. DOIT ================================================================ Issue: 20051127dr08 Obsolete Security Considerations DONE 8. It looks that the editors did not use the latest version of the recommended Security Considerations boilerplate text, or that this text changed since the last version of the I-D. The most update text can be found at http://www.ops.ietf.org/mib-security.html. DOIT ================================================================ Issue: 20051127dr09 smilint warnings DONE 9. smilint returns two warnings: tcp-mib.txt:417: [5] {index-exceeds-too-large} warning: index of row `tcpEStatsConnectIdEntry' can exceed OID size limit by 399 subidentifier(s) This problem derives from the fact that the tcpEStatsConnectIdTable has indices with a SYNTAX InetAddress and is addressed by the text in the DESCRIPTION clauses of the index objects. tcp-mib.txt:2177: [4] {group-membership} warning: node 'tcpEStatsAppCurAppWQueue' must be contained in at least one conformance group This needs to be fixed, I believe that the problem is known. Sent: 20060216mm I don't get the second message - was it corrupted? Rcvd: request for non-ID MIB: presume passed DISCUSS I get only the first warning ================================================================ Issue: 20051127dr10 obsolete text in the introduction DONE 10. The following paragraph in the Introduction section looks odd and may be removed: This document is automatically generated from a database of potential TCP instruments. Beware that the OIDs are still likely to change with future versions. The most current version can be obtained from http://www.web100.org/mib/ . Please use tsvwg@ietf.org to send comments to the entire TSV WG. DOIT ================================================================ Issue: 20051127dr11 Misplaced security text DONE 11. The following text in the Overview section seems to rather belong in the Security Considerations section: The tcpEStatsConnTableLatency object determines how long table rows are retained after connection close, to permit reading final connection completion statistics. Changing any of these controls may affect the correctness of other management applications accessing this MIB. Generally local policy should only permit limited write access to these controls (e.g. only by one management station or only during system configuration). DOIT ================================================================ Issue: 20051127dr12 Replace Stats Operation TC DONE 12. The DESCRIPTION clause of the TcpEStatsOperation TC is confusing and needs to be re-edited. It is not clear why a new TC needs to be created for the objects using this TC, instead using the TruthValue TC DISCUSS w/ rar ================================================================ Issue: 20051127dr13 Listner Cur Backlog vague and wrong type DONE 13. There are some problems with tcpEStatsListenerCurBacklog. First, the DESCRIPTION clause speaks about a Counter, although the SYNTAX of the object is Gauge32. Then I am concerned by the fact that the text mentions that 'MAY include connections in SYN-RECEIVED state'. How can two reads performed on two different entities in similar conditions lead to the same number? Done, but still.... DISCUSS not "constant" for all implememtations ================================================================ Issue: 20051127dr14 Obsolete address description DONE 14. The DESCRIPTION clause of tcpEStatsConnectLocalAddress and tcpEStatsConnectRemAddress still mentions SNMPv1, SNMPv2c and SNMPv3. The first two are Historical, SNMPv3 is the recurrent standard track version of SNMP, the text should be replaced by simply 'SNMP'. Also Issue: 20051127bw06 W.r.t. to Dan's comment 14. (and comment 9 -MM) I know that we have such statements in other MIB modules (when all the SNMPv1,v2c,v3 text just refers to the fact of those SNMP versions are not allowing more than 128 subids.). So personally I think I can live with it. I am checking with the set of MIB doctors. DISCUSS clarify w/ doctors ================================================================ Issue: 20051127dr15 Pipesize vague DONE 15. I am confused about how tcpEStatsPerfPipeSize is to be implemented. What determines if RFC 3517 is in effect, and how does a management application know this? Is there a MIB object that provides this information, if not should there be one? Sent: 20060209mm question asked Rcvd: 20060210bw "whatever" Rcvd: 20060214dr too vague for standardization Sent: 20060216mm It is vague because the standards are vague - Will update discription DONE - Will update overview NOT DONE Sent: 20060222mm to Jheffner draft "relationship to TCP" section (done but not vetted). DISCUSS Not standardized ================================================================ Issue: 20051127dr16 Add RFC3517 to Normative references DONE 16. RFC 3517 must be added to Normative References DOIT ================================================================ Issue: 20051127dr17 Improper use of 'our' DONE 17. In the text 'The following objects instrument our receiver window'. What 'our' means? DOIT ================================================================ Issue: 20051127dr18 read-write persistence across reboots DONE 18. Do we expect any of the read-write objects to keep their value persistent over re-boots. If this is a requirement, it should be mentioned in the DESCRIPTION clauses of each of the respective objects. If all or none, a general notice should be made either in the MIB module DESCRIPTION clause, or in section 3 Also Issue: 20051127bw02 Add object persistence I'd like to extend on Dan's comment 18, in that I think it is BEST to add in every DESCRIPTION clause of read-write or read-create objects what the expected persistency behaviour is. For objects in a ROW, you can use a an object with a SYNTAX of StorageType TC, in which case it is clear that all writable objects in the row follow the value of the StirageType object. FOr a row, you can also describe the persistency behaviour of writable objects in the xxxEntry DESCRIPTION clause. DISCUSS normal TCP semantic: no state preserved across reboots ================================================================ Issue: 20051127dr19 ECNsignals vague DONE 19. I am unconfortable with the definition of tcpEStatsPathECNsignals: "The number of congestion signals delivered via all forms of explicit congestion notification including the ECE bit and failing the ECN nonce check, etc." This looks to open-ended to me, I would prefer an enumeration or clear references to what is supposed to be counted here. DISCUSS ECN experimental ================================================================ Issue: 20051127dr20 Ratios w/o explicit deltas DONE 20. The following comment is problematic: The ratio of tcpEStatsPathDupAcksOut to tcpEStatsPathDupAckEpisodes is an indication of reorder or recovery distance'. As the two objects are counters, at some point in time roll-over is a possibility. Users should be warned that they need to use deltas of consecutive readings with correction upon roll-over and not the absolute values of tcpEStatsPathDupAcksOut and tcpEStatsPathDupAckEpisodes. DOIT ================================================================ Issue: 20051127dr21 Proprietary usage of non-allocated error codes DONE 21. I do not like the proprietary usage of the non-allocated enumerated errors in tcpEStatsStackSoftErrorReason: "Implementers are permitted to assign additional codes greater than 8 such that all SoftErrors in their implementation have unique codes. Management stations are to accumulate all unassigned codes as 'otherSoftErrors'". What does 'accumulated' mean, this is not a counter object? No interoperability can be ensured for two different implementations. If there is a need to extend this object there are multiple ways to do it, for example an IANA maintained object. To pass proprietary codes proprietary objects may be defined. DISCUSS as part of other non-standard issues ================================================================ The above completed prior to -09 ================================================================