Skip to main content

Last Call Review of draft-ietf-tcpm-rfc3782-bis-

Request Review of draft-ietf-tcpm-rfc3782-bis
Requested revision 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
I-D 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
Request Last Call review on draft-ietf-tcpm-rfc3782-bis by General Area Review Team (Gen-ART) Assigned
Completed 2011-11-21
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at <>.

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

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:


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: " 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?