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

[Mahesh Jethanandani <[e-mail]>]

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
[e-mail]