Last Call Review of draft-ietf-tcpm-rfc3782-bis-
review-ietf-tcpm-rfc3782-bis-genart-lc-campbell-2011-11-21-00

Request Review of draft-ietf-tcpm-rfc3782-bis
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2011-11-21
Requested 2011-11-08
Authors Andrei Gurtov, Tom Henderson, Sally Floyd, Yoshifumi Nishida
Draft last updated 2011-11-21
Completed reviews Genart Last Call review of -?? by Ben Campbell
Genart Telechat review of -?? by Ben Campbell
Secdir Last Call review of -?? by Taylor Yu
Assignment Reviewer Ben Campbell 
State Completed
Review review-ietf-tcpm-rfc3782-bis-genart-lc-campbell-2011-11-21
Review completed: 2011-11-21

Review
review-ietf-tcpm-rfc3782-bis-genart-lc-campbell-2011-11-21

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-tcpm-rfc3782-bis-03
Reviewer: Ben Campbell
Review Date: 2011-11-21
IETF LC End Date: 2011-11-21

Summary: This draft is almost ready for publication as a proposed standard.

Major issues:

None

Minor issues:

-- Appendix A refers the reader back to RFC 3782 for additional information. But this draft purports to obsolete that RFC. If there is important info in it that is not covered by this draft, then it doesn't really obsolete it. Is there a reason that information was not brought forward into this draft?

-- There is very little 2119 normative language. On a quick scan, I see one capitalized SHOULD NOT and one MAY. Yet it seems like there are other statements that are just as important for correct behavior as those. For the sake of consistency, it might be easiest to just drop 2119 language entirely.

-- section 6, 2nd to last paragraph: "...it is important that the sender not execute the Fast Recovery steps..."

This sounds like a SHOULD NOT (example of previous comment.)


Nits/editorial comments:

-- IDNits mentions several references that have no citation in the body. I note that the PROTO write up indicates these have been considered and are relevant to the draft even though they are note cited. My understanding, however, is that the RFC editor style guide either requires or strongly suggests that each reference be cited.

-- section 4, paragraph 2: "For a TCP that implements…"

a TCP _sender_ ?

-- Appendix A, last paragraph: "Section 11 of [RFC3782] listed changes relative to [RFC3782]."

relative to itself?