Last Call Review of draft-ietf-tcpm-1323bis-19
review-ietf-tcpm-1323bis-19-opsdir-lc-baker-2014-02-14-00

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

As background, I'll note that RFC 1323, which draft-ietf-tcpm-1323bis replaces,
has quite of bit of history in the Internet; when I look at traces, the
question isn't whether window scaling and timestamps are used, but the scaling
factor in use. The authors are recognized experts in TCP, having among them
early contributors to the specification and a more recent worker with
significant accomplishments. The bibliography of the document cites significant
research behind the recommendations, and an rfcdiff shows changes, minor or
major, throughout the document. As near as I can tell, the specification
documents current practice in deployed TCP implementations and/or makes
language more accessible (such as changing the variable in which the window
scale value is stored from "scale" to "shift"; the operation is to shift the
advertised window left the stated number of bits).

idnits notes the possibility of pre-2008 text and recommends ensuring that the
authors of any such text sign off on its publication. The first version of the
draft is indeed dated January 2008, and it replaces draft-borman-1323bis, which
is a 2007 document. David is a principle author on this document, so I think
the concern is likely unwarranted, but it would be worthwhile for the authors
to ask themselves that question and deal with it as it deserves.

Important information is included in the document regarding the recommendations
of RFC 1323 and other documents, and how they have worked out in practice over
time. For example, it was originally thought that including a timestamp in all
or many TCP segments would improve estimates of the retransmission timeout. It
turns out that, while they help, they don't help as much as expected. Hence, a
timestamp once or twice per RTT probably produces the same benefit as a
timestamp option on every packet. These observations contribute enormously, in
my opinion, to the value of the document.

Security Considerations and Privacy Considerations are included; RFC 1323
didn't consider security. The sections appear well thought through and reach
essentially the same conclusions that I would were I writing them. They include
not only end to end considerations, but considerations related to middle boxes,
which are an operational aspect of the Internet that the IETF likes to overlook.

Regarding the questions from RFC 5706:

The document is grounded in significant operational experience with
well-understood and widely-used code. It has not had scaling issues in
deployment; it is in fact a response to scaling issues. It does not change the
options or their interpretation, so co-existence should not be an issue.

Configuration is not discussed in the document per se. In implementations I am
aware of, configuration varies. In some, there is simply a standard value used
for all peers; in others, different settings are used on a per-address or
per-prefix basis derived either from history or manual settings. There is
really only three values that *can* be set: whether or not scaling is in use, a
recommended shift value (which may or may not differ based on the peer), and
whether or not timestamps are in use. I believe that this is adequate for known
purposes.

With respect to the other questions in the list, in my opinion the answer is
"it is satisfactory".

I consider the document to be "Ready" for IESG consideration.

Attachment:

signature.asc

Description:

 Message signed with OpenPGP using GPGMail