A Roadmap for Transmission Control Protocol (TCP) Specification Documents
draft-ietf-tcpm-tcp-rfc4614bis-08

Thank you for doing this important update. I'm sure it wasn't easy.

I had some questions, but nothing we need to discuss. Please consider these along with any other feedback you receive and do the right thing.

In this text:

   Note that the category of an RFC does not necessarily reflect its
   current relevance.  For instance, RFC 5681 [RFC5681] is considered
   part of the required core functionality of TCP, although the RFC is
   only a Draft Standard.  Similarly, some Informational RFCs contain
   significant technical proposals for changing TCP.

Now that we've stopped using Draft Standard when advancing along the standards track, but we left existing Draft Standards in place, this unchanged text doesn't make as much sense (to me) as it did in 2006. If you dropped out the "For instance" sentence completely, you'd still be making the stronger point about Informational RFCs being relevant to a protocol that's a full Standard anyway.

In this text (but in a bunch of similar places):

   RFC 1122 S: "Requirements for Internet Hosts - Communication Layers"
   (October 1989)

      This document [RFC1122] updates and clarifies RFC 793 (see
      Section 2), 

"see Section 2" is ambiguous enough to refer to (1) RFC 793, (2) RFC 1122, or (3) the current draft. I can figure out which one you mean, but since you've added these section references since 2006, I'm sure you're trying to make things less vague, rather than more vague. Is it possible to use a less ambiguous style, perhaps "(see [RFCwhatever] Section 2)" - or whatever the format is that would give the reader hyperlinks to make chasing the cross-references easier in the HTML version ...

In this text, 

   RFC 5681 S: "TCP Congestion Control" (August 2009)

      Although RFC 793 (see Section 2) did not contain any congestion
      control mechanisms, today congestion control is a required
      component of TCP implementations.  This document [RFC5681] defines
      the current versions of Van Jacobson's congestion avoidance and
          ^^^^^^^
      control mechanisms for TCP, based on his 1988 SIGCOMM paper
      [Jac88].

is "current" the right word in 2014?

More broadly, I wonder if 

      Although RFC 793 (see Section 2) did not contain any congestion
      control mechanisms, today congestion control is a required
      component of TCP implementations.  This document [RFC5681] defines
      congestion avoidance and
      control mechanisms for TCP, based on Van Jacobson's 1988 SIGCOMM paper
      [Jac88].

might be a better phrasing.

In this text:

   RFC 3465 E: "TCP Congestion Control with Appropriate Byte Counting
   (ABC)" (February 2003)

      This document [RFC3465] suggests that congestion control use the
      number of bytes acknowledged instead of the number of
      acknowledgments received.  The ABC mechanism behaves differently
      than the standard method when there is not a one-to-one
      relationship between data segments and acknowledgments.  

Would you consider a TCP to have a "one-to-one relatioship between data segments and acknowledgments" if it does delayed ACKs? I think I know the point you/re making, but I'm not sure if I understand this text.

In this text in section 4.  Experimental Extensions

   At this point is worth mentioning that if the experimental RFC is a
                 ^^
   proposal for a new protocol capability or service, i.e., it requires
   a new TCP option code point, the implementation and experimentation
   should follows [RFC6994] (see Section 5), which describes how the
   ^^^^^^^^^^^^^^
   experimental TCP option code points can concurrently support multiple
   TCP extensions.

This might just be "it is worth mentioning" and "should follow" but the sentence structure was complicated enough that I wasn't sure I was following.

In this text in section 4.2.  Fundamental Changes

   Like the standard documents listed in Section 3.1 there newly exist
   also experimental RFCs that represent fundamental changes to TCP.

I just can't parse it. I can guess what it means, but I'm guessing. Perhaps 

   In addition to the standard-track documents listed in Section 3.1, there are
   also experimental RFCs that represent fundamental changes to TCP.

In the same paragraph,

   One example is TCP Fast Open that deviates from the standard TCP
   semantics of [RFC0793].

It's OK with me if you only include one example, but is there a good way for someone not skilled in the art to find other examples of proposals for fundamental changes? And if you don't have a ready answer, you might reasonably ask me/Martin the same question ...

Good stuff, thanks.