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

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 30 Nov 2012 09:03:15 -0800

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
[email-masked]

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Dec 2012 16:14:38 -0600

Hi Mahesh,

The proposed changes work for me.

Thanks!

Ben.

On Nov 30, 2012, at 11:03 AM, Mahesh Jethanandani <[email-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art