Last Call Review of draft-ietf-karp-routing-tcp-analysis-05

Request Review of draft-ietf-karp-routing-tcp-analysis
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-11-19
Requested 2012-10-25
Authors Mahesh Jethanandani, Keyur Patel, Lianshu Zheng
Draft last updated 2012-11-15
Completed reviews Genart Last Call review of -05 by Ben Campbell (diff)
Genart Telechat review of -06 by Ben Campbell (diff)
Assignment Reviewer Ben Campbell 
State Completed
Review review-ietf-karp-routing-tcp-analysis-05-genart-lc-campbell-2012-11-15
Reviewed rev. 05 (document currently at 07)
Review result Almost Ready
Review completed: 2012-11-15


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 receive.

Document: draft-ietf-karp-routing-tcp-analysis-05.txt
Reviewer: Ben Campbell
Review Date: 2012-11-14
IETF LC End Date: 2012-11-19

Summary: This draft is almost ready for publication as an informational RFC. There are a few minor issues and a number of editorial issues that should be considered prior to publication.

*** Major issues ***:


*** Minor issues *** :

-- section 2.2, last paragraph:

The IKE mention lacks context. Do you mean to suggest IKE with IPSec? I assume so, but there's been no mention of IPSec so far.

-- section 2.3.2:

It would be helpful for this section to describe whether privacy issues actually matter or not, rather than just stating the issues to be similar to those for other routing protocols.

-- section 3.1, 2nd paragraph:

Does this mean that privacy is really not needed, or just that LDP does not state a requirement for privacy?

-- Section 6 (Security Considerations), 4th paragraph:

If replay protection is required, shouldn't the draft discuss the details somewhere? I see only one mention in passing outside of this section.

*** Nits/editorial comments ***:

-- IDNits indicates some unused and obsoleted references. Please check.

-- The IANA considerations section is missing. If the draft makes requests of IANA, it should include the section and state that.

-- the short title is "The IANA considerations section is missing. If the draft makes requests of IANA, it should include the section and say that

-- The short title is "draft-ietf-karp-routing-tcp-analysis-05.txt". Is this draft in any way specific to TCP? If so, it would be helpful to mention that in the abstract and introduction.

-- Punctuation errors are pervasive, particularly in the early and late sections. These make it harder to read than it needs to be. In particular, I suggest the draft be proofread for missing commas and missing quotes (or other marks) around document titles.

-- Section 1, paragraph 1:

The cited doc name should be quoted, or otherwise marked. Also, it's not necessary to put the full reference here, since you are citing the references section.

-- Section 1, paragraph 1: "Four main steps were identified for that tightening:"

For what tightening? This is the first mention. Perhaps the previous sentence should have gone on to say "... and suggests steps to tighten the infrastructure against the attack"?

-- section 1, 1st paragraph after numbered list:

The end of the paragraph does not seem related to the beginning. I suggest a paragraph split before the sentence starting with "The OPSEC working group..." 

-- section 1, 2nd to last paragraph: "current state of security method"

Missing article before "security method".

-- section 1.1:

Why is 2119 language needed? I see two potentially normative statements--but both of those merely describe the existing MAC requirements in TCP-AO. It would be better to state those in descriptive language (e.g. TCP-AO requires…) and to drop the 2119 section entirely. 

-- section 2.1,  5th paragraph:

A mention of SHA1 seems needed here. Section states the concerns about TCP-md5 more clearly.

-- section, 1st paragraph: "As stated above..."

A section reference would be helpful.

-- section 4, 2nd paragraph: "In addition Improving TCP’s Robustness to Blind In-Window Attacks."

sentence fragment.

-- section 4, 3rd paragraph:

It would have been helpful to mention the MKT manual config issue back in the "state of the security method" sections.