Subject: [RTG-DIR] RtgDir review: draft-ietf-ipsecme-ad-vpn-problem-07

From: Martin Vigoureux <[email-masked]>
Date: Fri, 21 Jun 2013 15:11:17 +0200

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