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

Hi Mahesh,

The proposed changes work for me.

Thanks!

Ben.

On Nov 30, 2012, at 11:03 AM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

> 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@gmail.com
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art