[IPsec] RtgDir review: draft-ietf-ipsecme-ad-vpn-problem-07

Martin Vigoureux <martin.vigoureux@alcatel-lucent.com> Fri, 21 June 2013 13:11 UTC

Return-Path: <martin.vigoureux@alcatel-lucent.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D4A11E817D; Fri, 21 Jun 2013 06:11:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlyhnteDIaud; Fri, 21 Jun 2013 06:11:50 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2A821F9C47; Fri, 21 Jun 2013 06:11:49 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r5LDBmg5006172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Jun 2013 08:11:48 -0500 (CDT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r5LDBfCs029105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Jun 2013 09:11:48 -0400
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 21 Jun 2013 09:11:44 -0400
Received: from [172.27.205.220] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 21 Jun 2013 15:11:18 +0200
Message-ID: <51C450F5.10506@alcatel-lucent.com>
Date: Fri, 21 Jun 2013 15:11:17 +0200
From: Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: rtg-ads@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [135.239.27.41]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Mailman-Approved-At: Fri, 21 Jun 2013 08:02:41 -0700
Cc: draft-ietf-ipsecme-ad-vpn-problem.all@tools.ietf.org, rtg-dir@ietf.org, ipsec@ietf.org
Subject: [IPsec] RtgDir review: draft-ietf-ipsecme-ad-vpn-problem-07
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jun 2013 13:11:56 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-ipsecme-ad-vpn-problem-07
Reviewer: Martin Vigoureux
Review Date: June the 21st, 2013
IETF LC End Date: June the 21st, 2013
Intended Status: Informational

Summary:
This document is basically ready for publication, but has nits that 
should be considered prior to publication.

Comments:
The document is well written, well scoped and clear.
The "nits" are more questions for clarifications rather than identified 
bugs.

Major Issues:
No major issues found.

Minor Issues:
The draft defines and uses the term "endpoint" and "gateway" while RFC 
4301 apparently employs the terms "host" and "gateway" (although there 
are few occurrences of "endpoint"). While I doubt that this difference 
be misleading, it might be wise to seek for consistency in terminology 
between the documents, or alternatively state the differences and 
similarities between the functions these terms refer to.

Nowhere is a requirement for (backward) compatibility with regards to 
existing specifications. Is this intentional?

Requirement 1 is unclear with regards to the type of configuration 
changes that must be minimized. It should be clarified if these changes 
are manual configuration changes or simply configuration changes.
If not, out of this requirement both the solutions of having no/few 
change or having as many changes as today but all/most of them done 
without human intervention, are possible.
I can not state if any of these makes sense or is feasible but they are 
surely substantially different from a design and engineering perspective.
As an illustration, Requirement 2 has the same ambiguity but resolves it 
by means of the second sentence where the configurations are explicitly 
qualified as "manual".

Isn't requirement 8 too strong? The keyword "MUST" is used, while 
"SHOULD" would seem more appropriate. Indeed, follows the requirement a 
description of situations in which it might not be possible to meet the 
requirement, or where it might be but by means of external factors.

While requirement 12 is not an unusual one, its presence in a document 
that focuses on point-to-point can be discussed.

As a general comment it is difficult to estimate how much some of these 
requirements scope/guide the design of a solution.

Nits:
Section 2.2:
"It is for this purpose spoke-to-spoke tunnels are dynamically created 
and torn-down."
This sentence seems difficult to read.

Regards,
Martin