Last Call Review of draft-ietf-lisp-impact-04

Request Review of draft-ietf-lisp-impact
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-10-19
Requested 2015-10-08
Authors Damien Saucez, Luigi Iannone, Albert Cabellos-Aparicio, Florin Coras
Draft last updated 2015-10-14
Completed reviews Genart Last Call review of -04 by Russ Housley (diff)
Secdir Last Call review of -04 by Hilarie Orman (diff)
Assignment Reviewer Russ Housley
State Completed
Review review-ietf-lisp-impact-04-genart-lc-housley-2015-10-14
Reviewed rev. 04 (document currently at 05)
Review result Almost Ready
Review completed: 2015-10-14


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-lisp-impact-04
Reviewer: Russ Housley
Review Date: 2015-10-14
IETF LC End Date: 2015-10-19
IESG Telechat date: unknown

Summary:  Almost Ready.

Major Concerns:

Section 3 says: "[KIF13] and [CDLC] explore different EDI prefix space
sizes, and still show results that are consistent and equivalent to the
above assumptions."  It seems like it would be valuable to include a
sentence or two about the way that EDI space is obtained.

Minor Concerns:

I found the Introduction and LISP in a nutshell sections a bit too
much like marketing material.  I think the document would be better
if the tone was more like an engineering analysis.

Perhaps this paragraph can be moved to the top:

   An introduction to LISP can be found in [RFC7215].  The LISP
   specifications are given in [RFC6830], [RFC6833],
   [I-D.ietf-lisp-ddt], [RFC6836], [RFC6832], [RFC6834].

Section 5 has very little content on "business models".  There is some,
but not much.  It seems odd that it appears in the section heading.

Other Comments:

Please spell out "DPI" and "DFZ" on first use.

Section 4 says: "Without LISP, operators are forced to centralize
service anchors in custom built boxes."  This seems a bit too strong.
Perhaps: "Without LISP, operators centralize service anchors."

Section 4.1: s/(non-LISP)routing/(non-LISP) routing/