A Roadmap for Transmission Control Protocol (TCP) Specification Documents
RFC 4614

[Ballot comment]
It might be good to update:
  RFC 2452 S: "IP Version 6 Management Information Base for the
  Transmission Control Protocol" (December 1998)

      This document [RFC2452] augments RFC 2012 by adding an IPv6-
      specific connection table.  The rest of 2012 holds for any IP
      version.
Into:
  RFC 2452 S: "IP Version 6 Management Information Base for the
  Transmission Control Protocol" (December 1998)

      This document [RFC2452] augments RFC 2012 by adding an IPv6-
      specific connection table.  The rest of 2012 holds for any IP
      version. It is now obsoleted by RFC 4022.

I.e. add a sentence to make clear it has been obsoletetd by 4022.

[Ballot comment]
Section 3.3 says:
  >
  > A draft that is currently in the RFC Editor's
  > queue for publication [tcpmd5app] deprecates TCP MD5 for use
  > outside BGP.
  >
  This document has been published, and the wording of the
  sentence does not allow a simple substitution.  Please
  reword.  I propose:
  >
  > RFC 4278 deprecates the use of TCP MD5 outside BGP [RFC4278].

  Please change [tcpmd5app] to reference RFC 4278.

[Ballot comment]
From Gen-ART review by Spencer Dawkins:

- In Section 3.1, the following text seems confusing:

  Since TCP traditionally (in the absence
  of ECN) uses losses to infer congestion, there is a rather intimate
  coupling between congestion control and loss recovery mechanisms.

Isn't it more correct to say that TCP always infers congestion from losses, and may also infer congestion from ECN? The current text makes it seem like TCP does not use losses to infer congestion when ECN is being used - I wish this could be true, but it's not.

BC: I think the phrasing could be better, although I won't insist. For example,
  TCP traditionally treats lost packets as indicating congestive loss,
  and cannot distinguish between congestive loss and loss due to
  transmission errors. Even when ECN is in in use, there is a rather
  intimate coupling between congestion control and loss recovery mechanisms.

Proto Write-up (Mark Allman):

A Roadmap for TCP Specification Documents
draft-ietf-tcpm-tcp-roadmap-05.txt

  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?

        Yes.  The chairs have read the document and believe it is
        solid and ready for publication.

  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?

        The document has received a large amount of review from WG
        members.  The WGLC was also announced on the tsvwg and
        end2end-interest mailing lists.  This did not result in any
        known objections to the document progressing.  Finally,
        previous to WGLC the document was discussed within the
        transport area directorate with no resulting major
        objections.

  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, etc.)?

        We do not have cross-area review concerns---mostly since the
        document is an informational roadmap to existing mechanisms
        and does not change protocols or protocol behavior.

  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.

        We do not have any specific concerns about the document.  We
        are not at odds with the WG on any particular points in the
        document.

  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?

        The consensus behind the roadmap document is both strong and
        broad within the WG.  There was little to no dissent in the
        WG about whether this document is needed or the contents of
        the current document.

  1.f) Has anyone threatened an appeal or otherwise indicated
        extreme discontent?  If so, please summarise the areas of
        conflict in separate email to the Responsible Area Director.

        We are aware of no imminent appeals or extreme discontent
        with this document.

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

        The draft passes idnits-1.82 with "no nits found".

  1.h) Is the document split into normative and informative
        references?  Are there normative references to IDs, where
        the IDs are not also ready for advancement or are otherwise
        in an unclear state?  (note here that the RFC editor will
        not publish an RFC with normative references to IDs, it will
        delay publication until all such IDs are also ready for
        publication as RFCs.)

        (a) The references are all listed as "informative" since
            this is an informational document.

        (b) There are no normative references in this
            internet-draft.  However, the WG reached consensus that
            only TCP-related RFCs would be cataloged in this
            document.  This excludes current items on the WG's
            plate.  However, one reference is included that is
            currently in the RFC Editor's publication queue, as this
            item is "finished" and stable text can be written about
            the documents.  Therefore, we would like the ensure that
            the following reference is published before the roadmap
            is published:

            [tcpmd5app] draft-iesg-tcpmd5app-01.txt


  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:
        *    Technical Summary
        *    Working Group Summary
        *    Protocol Quality

        This is not a standards track or BCP document.  The following
        short synopsis can be used if required:

        The TCP roadmap document synthesizes the vast array of
        TCP-related documents in the RFC series to aid implementers
        and newcomers in navigating the documents.  The goal is to
        summarize each document's contributions and to give the
        reader a flavor of which items are (a) vital to implement,
        (b) are recommended, (c) potentially useful and (d) no
        longer recommended at all.  In addition, the document
        provides summaries of the various TCP-related information
        that has been published inside and outside of the RFC
        series.

        There is strong consensus within the TCPM WG to publish the
        current version of the document as an informational RFC.
        The disagreements involved within the WG centered around
        both the structure of the document and the placement of
        various RFC descriptions within that structure.  While every
        WG member may not agree with every decision there is strong
        consensus in the WG that this document is ready for
        publication.