Management Information Base for the Transmission Control Protocol (TCP)
RFC 4022

[Ballot comment]
No further objection; I think Steve's point should be addressed (privacy implications). And Allison's review points out a generic issue (not about this document, but about review).

[Ballot discuss]
Despite several efforts to get TCP review from the TSVWG, we failed :( and there
are a few places where we needed to.  I hope objects can be modernized now.



tcpRtoAlgorithm OBJECT-TYPE
    SYNTAX      INTEGER {
                    other(1),    -- none of the following
                    constant(2), -- a constant rto
                    rsre(3),    -- MIL-STD-1778, Appendix B
                    vanj(4)      -- Van Jacobson's algorithm [VANJ]

  Update with (5) --RFC 2988

Replace tcpRtoMin Description

Old:


    DESCRIPTION
          "The minimum value permitted by a TCP implementation for the
            retransmission timeout, measured in milliseconds.  More
            refined semantics for objects of this type depend upon the
            algorithm used to determine the retransmission timeout.  In
            particular, when the timeout algorithm is rsre(3), an
            object of this type has the semantics of the LBOUND
            quantity described in RFC 793."


New  "The minimum value permitted by a TCP implementation for the
            retransmission timeout, measured in milliseconds.  More refined
            semantics for objects of this type depend upon the algorithm used
            to determine the retransmission timeout; in particular, the IETF standard
            algorithm rfc2988[5] provides a minimum value."


tcpRtoMax Description Replace with

New  "The maximum value permitted by a TCP implementation for the
            retransmission timeout, measured in milliseconds.  More refined
            semantics for objects of this type depend upon the algorithm used
            to determine the retransmission timeout; in particular, the IETF standard
            algorithm rfc2988[5] provides an upper bound (as part of an adaptive
            backoff algorithm).

I'll second SMB's comment about privacy - in the Security Considerations section
about the connection table allowing a lot of access to information about active
connection, add a note of concern about privacy to the considerations about attack
that are already there.

Chair write-up:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

I have reviewed this MIB as both a chair and as a contributing author.
I feel that it is ready for advancement to the IESG.

2) 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?

The document has been reviewed by several MIB-aware members of
the IPv6 WG.  In addition, multiple reviews from management experts
on the ipv6mib mailing list have been done.

No concerns on the reviews.

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

4) 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 whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.
 
No concerns.

5) 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?

My perception is that there is strong support from the small number
of people in the working group who are MIB-literate.  I have asked
others for their opinion and most state they trust those members
who are MIB-literate.

There is a strong consensus on the ipv6mib mailing list which has
strong representation from the management area.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.
 
No.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

8) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

    This memo defines a portion of the Management Information Base (MIB)
    for use with network management protocols in the Internet community. 
    In particular, it describes managed objects used for implementations
    of the Transmission Control Protocol (TCP) in an IP version
    independent manner. This memo obsoletes RFCs 2012 and 2452.

    It accomplishes this by utilizing the InetAddress TC to provide
    IP address-independence on the management objects.  This allows
    a single MIB to provide the same level of management for IPv4
    and IPv6.

  - Working Group Summary

    There was strong WG consensus for this document in both the IPv6
    working group and the IPv6 MIB design team.

  - Protocol Quality

    This document has undergone significant review by management
    experts.  In particular, Kristine Adamson has raised several
    important points from an implementation point of view.