Re: Gen-ART LC Review of draft-ietf-karp-routing-tcp-analysis-05.txt

[Mahesh Jethanandani <mjethanandani@xxxxxxxxx>]

Ben,

See inline. If you are ok with these changes, I will go ahead and submit an updated version of the draft.

On Nov 25, 2012, at 5:56 PM, Mahesh Jethanandani wrote:

Further trimming it to sections that require a response.

On Nov 21, 2012, at 3:12 PM, Ben Campbell wrote:

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

No. It implies the use of IKEv2 protocol for performing mutual authentication and establishing SA. There is no suggestion of using IKE with IPSec.

How about this?

For point-to-point key management IKEv2[RFC5996] protocol provides ...

5996 describes IKEv2 as a component of IPSec, and a key-management mechanism for ESP and AH SAs. Now, I won't claim to be an IKE expert by any extent, but I think that if you mean to use IKE _without_ IPSec it would be good to add a sentence or two pointing that out. Or is there some other reference that could be used that describes using IKEv2 for non-IPSec SAs?

Added this sentence.

Although IKEv2 is discussed as a component of IPsec, KMP can use just the mutual authentication and SA establishment portion of IKEv2.

This statement has been further modified to:

For point-to-point key management IKEv2 [RFC5996] provides for

 automated key exchange under a SA and can be used for a comprehensive

 Key Management Protocol (KMP) solution for routers.  IKEv2 can be used

 for both IPsec SAs [RFC4301] and other types of SAs. For example, 

 Fibre Channel SAs  [RFC4595] are currently negotiated with IKEv2. Using

 IKEv2 to negotiate TCP-AO is a possible option.

*** Nits/editorial comments ***:

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

Found one unused reference and have removed it.

Seems like there were more than one. From IDNits:

 == Missing Reference: 'IRR' is mentioned on line 92, but not defined

 == Unused Reference: 'RFC2409' is defined on line 585, but no explicit
    reference was found in the text

 == Unused Reference: 'RFC3547' is defined on line 588, but no explicit
    reference was found in the text

 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925)

 -- Obsolete informational reference (is this intentional?): RFC 2409
    (Obsoleted by RFC 4306)

 -- Obsolete informational reference (is this intentional?): RFC 3547
    (Obsoleted by RFC 6407)

I have removed these unused references.

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

sentence fragment.

Changed it to say:

In addition, the recommendations in Improving TCP's Robustness to Blind In-Window Attacks

Am I correct in assuming this merges with the following sentence? Otherwise, it's still a fragment.

Changed it to:

In addition, the recommendations in RFC 5961 should also be followed ...

Mahesh Jethanandani

mjethanandani@xxxxxxxxx