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

Mahesh Jethanandani <mjethanandani@gmail.com> Mon, 26 November 2012 01:56 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC6D21F869B; Sun, 25 Nov 2012 17:56:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyswiWmSVs4S; Sun, 25 Nov 2012 17:56:46 -0800 (PST)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E043E21F8661; Sun, 25 Nov 2012 17:56:42 -0800 (PST)
Received: by mail-vb0-f44.google.com with SMTP id fc26so3108193vbb.31 for <multiple recipients>; Sun, 25 Nov 2012 17:56:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=uawVPv3zf6hdvvSh8dyA8OCbxFSvGJx61e6TmJZ3CLs=; b=D9mcBIKitEFHZVQNhgf38xWQ5vEI1eH40268Jcnq0FUQtZYfTW3JR7uDAFtoFId3ns 6F8clc/psVXjNgmC5/yoBhbFLoEr/Y3AkT10pSZj+N7lKsVWDUsgrGBzM+2rZlTPNUta p1jtOxRRJb8+JPX5AHjScYX9w63KWcmEqEsS0fhO8rE8vTsM7EAG61WRI5cwsunomq5B gOnitbMCLfZOLpBCHjQ8/xLb+GaEJW+F63Vjz4xLx/6m4RY/H/R0I50A06rUhmTqBPwq LgFu204M6OnQs7Lbq6SGWDXPCSPE+T3eVryS6W4G2y0LdvRpPOfTS2MMF+Cq7kNlfX4z Pj3A==
Received: by 10.220.220.7 with SMTP id hw7mr16705849vcb.17.1353895002265; Sun, 25 Nov 2012 17:56:42 -0800 (PST)
Received: from txw-scook-01.ciena.com (c-24-6-180-144.hsd1.ca.comcast.net. [24.6.180.144]) by mx.google.com with ESMTPS id y15sm7549351vdt.9.2012.11.25.17.56.40 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Nov 2012 17:56:41 -0800 (PST)
Subject: Re: Gen-ART LC Review of draft-ietf-karp-routing-tcp-analysis-05.txt
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary="Apple-Mail-8--221838846"
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <3B3FEC40-3D96-4F77-A628-E80DFAEB2278@nostrum.com>
Date: Sun, 25 Nov 2012 17:56:39 -0800
Message-Id: <F60EDDFC-0612-4636-AFC7-3D7FD9052D74@gmail.com>
References: <18E6B18A-D465-47C6-9E06-886DFBFA1F67@nostrum.com> <F53DCC9A-8AA1-42D4-BF19-88ABCCCA68A7@gmail.com> <3B3FEC40-3D96-4F77-A628-E80DFAEB2278@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.1085)
X-Mailman-Approved-At: Mon, 26 Nov 2012 08:23:30 -0800
Cc: draft-ietf-karp-routing-tcp-analysis.all@tools.ietf.org, "gen-art@ietf.org Review Team" <gen-art@ietf.org>, "ietf@ietf.org List" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Nov 2012 01:56:47 -0000

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.

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