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

Request Review of draft-ietf-tcpm-1323bis
Requested rev. no specific revision (document currently at 21)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-02-18
Requested 2014-02-08
Authors David Borman, Robert Braden, Van Jacobson, Richard Scheffenegger
Draft last updated 2014-02-14
Completed reviews Genart Last Call review of -19 by Scott Brim (diff)
Genart Telechat review of -20 by Scott Brim (diff)
Secdir Last Call review of -19 by Kathleen Moriarty (diff)
Opsdir Last Call review of -19 by Fred Baker (diff)
Assignment Reviewer Fred Baker 
State Completed
Review review-ietf-tcpm-1323bis-19-opsdir-lc-baker-2014-02-14
Reviewed rev. 19 (document currently at 21)
Review result Ready
Review completed: 2014-02-14

Review
review-ietf-tcpm-1323bis-19-opsdir-lc-baker-2014-02-14

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