IETF Logo Mail Archive

[Gen-art] Gen-ART Review of draft-ietf-lisp-impact-04

Russ Housley <housley@vigilsec.com> Wed, 14 October 2015 16:51 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F97C1ACE12; Wed, 14 Oct 2015 09:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DPP4JW3RUxg; Wed, 14 Oct 2015 09:51:11 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 177BF1ACDEA; Wed, 14 Oct 2015 09:51:11 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 62BFB9A4049; Wed, 14 Oct 2015 12:51:00 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id bQhQi7ZReFDW; Wed, 14 Oct 2015 12:50:04 -0400 (EDT)
Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 1E9B49A4040; Wed, 14 Oct 2015 12:50:46 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com>
Date: Wed, 14 Oct 2015 12:50:34 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <4AC8F4E6-B5A6-46B0-9B0C-28350DAED68B@vigilsec.com>
References: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com>
To: draft-ietf-lisp-impact.all@ietf.org
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/6RxXXc5_iQ64zBtOw015a6H7bmI>
Cc: IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>
Subject: [Gen-art] Gen-ART Review of draft-ietf-lisp-impact-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Oct 2015 16:51:13 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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/

v2.23.0 | Report a Bug | By Email