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

[Ballot comment]
[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?

[Ballot comment]
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

[Ballot discuss]
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

IANA Last Call comments;

Upon approval of this document, the IANA will make the following
assignments in the "NETWORK MANAGEMENT PARAMETERS" registry
located at

http://www.iana.org/assignments/smi-numbers
in sub-registry "Prefix: iso.org.dod.internet.mgmt.mib-2
(1.3.6.1.2.1)

value Descriptor OBJECT IDENTIFIER value
TBD tcpEStatsMIB TCP Extended Statistics MIB
[RFC-tcp-mib-extension-12]

We understand the above to be the only IANA Actions for
this document.

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the
Internet Draft (ID), and in particular, do they believe this ID
is ready to forward to the IESG for publication? Which chair
is the WG Chair Shepherd for this document?

Yes, the shepherd for this document is James Polk

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

Yes, this has been reviewed extensively. There are no concerns about the
reviews.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

I have no concerns with the existing reviews, or requests for additional
reviews.

1.d) Do you have any specific concerns/issues with this document
that you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the document, or have concerns whether there really is a need
for it. In any event, if your issues have been discussed in
the WG and the WG has indicated it that it still wishes to
advance the document, detail those concerns in the write-up.

No.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There was solid WG consensus. It has been reviewed by a number of people.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).

There are no threats of appeal to my knowledge.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Version -12 has 11 experimental nits referring to unused references (which
do not appear to be nits at all).

The boilerplate checks good

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publication). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative
references that are downward references, as described in BCP
97, RFC 3967 RFC 3967 [RFC3967]? Listing these supports the
Area Director in the Last Call down ref procedure specified in
RFC 3967.

References are split (section 7 for normative references, section 8 for
informative references)

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

This document describes extended performance statistics for TCP. These
statistics are designed to use TCP's ideal vantage point to diagnose
performance problems in both the network and the application. If a
network based application is performing poorly, TCP can determine if
the bottleneck is in the sender, the receiver or the network itself.
If the bottleneck is in the network, TCP can provide specific
information about its nature.

* Working Group Summary

There is strong consensus in the WG to publish this document. It has
been reviewed by several people before and during WG last call.
Comments raised have been addressed.

* Protocol Quality

This document has been well reviewed in the WG and comments raised has
been addressed.

Additional review of revision 8:

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Sunday, November 27, 2005 15:44
To: Romascanu, Dan (Dan); tsvwg@ietf.org
Cc: Wijnen, Bert (Bert); mathis@web100.org; rreddy@psc.edu; jheffner@psc.edu; raraghun@cisco.com; Allison Mankin (E-mail); TCP ESTATS MIB team
Subject: RE: Review of draft-ietf-tsvwg-tcp-mib-extension-08.txt


Thanks for your review Dan!

So I expect we'll see a new revision that addresses you comments as much as possible,
and probably also a summary to the WG list explaining how your concerns are addressed,
or why (if such is the case) they should not cause changes.

Let me also add some of my comments after a quick check of myself):

  !! 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!

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.

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 }

I am missing any words about discontinity timers/possibilities for COunter32, ZeroBasedCounter32 and
ZeroBasedCounter64 objects !!??

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).

W.r.t. to Dan's comment 14.
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.



Authors, pls copy Dan and myself explicitly on any responses.

Bert

MIB doctor review of revision 8 posted to the WG mailing list:

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Sunday, November 27, 2005 14:19
To: tsvwg@ietf.org
Cc: Wijnen, Bert (Bert); mathis@web100.org; rreddy@psc.edu; jheffner@psc.edu; raraghun@cisco.com; Allison Mankin (E-mail); TCP ESTATS MIB team
Subject: Review of draft-ietf-tsvwg-tcp-mib-extension-08.txt



At the request of the O&M AD I have reviewed draft-ietf-tsvwg-tcp-mib-extension-08.txt.

As a general assessment, I appreciate the effort of the document editors, as well as the improvements in quality in the last few versions of this document. I do not believe however that the document is yet ready and I would recommend another round of editing to fix the problems described below, as well as resolve other comments that may have been received during the review period.

Here are my detailed findings:

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.

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.

3. Usage of the UNITS clause wherever relevant, especially for counter objects (e.g. 'seconds', 'octets', etc.) although not mandatory would be helpful.
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.
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.
6. In the DESCRIPTION clause of tcpEStatsStackSoftErrorReason  while clarifying the enumeration, the numerical values need to be mentioned. e.g. belowDataWindow(1)
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.
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.
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.

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.



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).



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

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?

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'.

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?

16. RFC 3517 must be added to Normative References

17. In the text 'The following objects instrument our receiver window'. What 'our' means?

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

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.

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.

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.

22. The table tcpEStatsStackTable has 50 columns, which would make a read operation of simultaneous objects in one PDU problematic. On the other side, many of the objects in this table are optional, which makes me suspect that breaking this table in multiple tables with similar indexation organized according to the conformance options would be a better solution.





Regards,



Dan

[Note]: 'Scott and I had this on the Atlanta TSVWG agenda - one issue is clear relationship to the revision of the TCP MIB undertaken in draft-ietf-ipv6-rfc2012-update-01.txt and another is to get MIB Doctor help asap [2002-Nov-30]' added by Bert Wijnen

Scott and I had this on the Atlanta TSVWG agenda - one issue is clear relationship to the revision of the TCP MIB undertaken in draft-ietf-ipv6-rfc2012-update-01.txt
and another is to get MIB Doctor help asap