[Gen-art] Gen-ART LC review for draft-ietf-lisp-eid-block-mgmnt-04

"Peter Yee" <peter@akayla.com> Wed, 29 April 2015 00:58 UTC

Return-Path: <peter@akayla.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 84B7A1A9112; Tue, 28 Apr 2015 17:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.31
X-Spam-Level:
X-Spam-Status: No, score=0.31 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 ManfXeMnTInS; Tue, 28 Apr 2015 17:58:16 -0700 (PDT)
Received: from p3plsmtpa11-09.prod.phx3.secureserver.ne (p3plsmtpa11-09.prod.phx3.secureserver.net [68.178.252.110]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0DE1A9110; Tue, 28 Apr 2015 17:58:16 -0700 (PDT)
Received: from spectre ([173.8.184.78]) by p3plsmtpa11-09.prod.phx3.secureserver.ne with id McyF1q0011huGat01cyFJK; Tue, 28 Apr 2015 17:58:16 -0700
From: "Peter Yee" <peter@akayla.com>
To: <draft-ietf-lisp-eid-block-mgmnt.all@tools.ietf.org>
Date: Tue, 28 Apr 2015 17:58:17 -0700
Message-ID: <056b01d08217$94c595e0$be50c1a0$@akayla.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdCCCs+rK7o74lcCS9O40/C1EuaNzQ==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/H1tO-Gk6VzLdYSfjNgEIhrrdMIM>
Cc: gen-art@ietf.org, ietf@ietf.org
Subject: [Gen-art] Gen-ART LC review for draft-ietf-lisp-eid-block-mgmnt-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: <http://www.ietf.org/mail-archive/web/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, 29 Apr 2015 00:58:18 -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-eid-block-mgmnt-04
Reviewer: Peter Yee
Review Date: Apr-28-2015
IETF LC End Date: Apr-28-2015
IESG Telechat date: TBD

Summary: This draft has serious issues, described in the review, and needs
to be rethought. [Not ready]

The draft attempts to specify the framework for the management of
experimental LISP EID sub-prefixes, but really could use some additional
work to flesh out the management aspects that are left unsaid.

Major issues: 

This draft does not give much management perspective nor many procedures,
perhaps because it calls itself a framework for management.  It mostly lists
data to be captured and discusses renewals periods.  It does not discuss how
requests are vetted or what would cause one to be disapproved, if that's
even a possibility.  It does not give any recourse for disapproved requests.
It does not specify how a request (whether pending or approved) is abandoned
or surrendered.  Consider section 3 of RFC 5226 as possibly being useful,
for example.  Given the details that the draft does discuss, it really needs
to have an actual discussion of management procedures or give a pointer as
to where these are discussed or how they are to be executed in concert with
the framework.

Section 10 (IANA Considerations): This section seems inadequate from an RFC
5226 perspective as well as simply throwing a lot on IANA to provide the
lookup mechanism without giving any further guidance than a bunch of
protocols (RDAP, WHOIS, HTTP, etc.)  Also see RFC 5226, Section 4.2.
Specific requirements for IANA need to be clearly spelled out in this
section, especially as there are potentially multiple registry operators
that are somehow involved in prefix allocation requests.  This is not at all
made clear in the document how coordination between registry operators and
IANA is to be carried out.  It's not even clear whether users are supposed
to be directly requesting prefixes from IANA or whether IANA should reject
such requests.  There's no guidance on how IANA recognizes valid requests.
There's no guidance on whether there is a limit to the number of requests
that may be made by an organization or individual.  The document notes a
hierarchical distribution of the address space but gives no further guidance
to IANA on how this hierarchy is to be organized and how registration
requests impact the hierarchy.  In short, a whole lot more needs to appear
in this section and in the text leading up to it.

Then again, I'm no LISP expert, so I could be completely off-base here.  :-)

Minor issues: 

Page 1, Abstract, 2nd sentence, "sub-prefixes": This term is not defined and
suffers from the same problem as ietf-lisp-eid-block in that is also used
once in that document but not further described.  There appears to be some
confusion between the use of prefix and sub-prefix that should be rectified.
Prefix in this document appears to generally mean sub-prefix with regards to
the experimental block, but this is not made clear.

Page 4, Section 5, items 1 and 2: considering that multiple registries may
be assigning these (sub-)prefixes and that they must be globally unique, is
there a mechanism to ensure this other than waiting for the inevitable IANA
clash between simultaneous registrations?

Nits:

Page 3, Section 2, 1st paragraph, 1st sentence: change "separates" to
"separate".

Page 3, Section 2, 3rd paragraph: change "organisation" to "organization".
All other uses of the word in the document have been spelled "organization",
so make this usage consistent with the others.  Or change them all to
"organisation" if that's preferred.  Pick one.

Page 3, Section 3, 1st sentence: delete an extraneous space after the open
parenthesis.

Page 3, Section 4, 1st sentence: insert "for" between "request" and
"registration".

Page 4, 1st full paragraph, 4th sentence: insert "be" between "should" and
"no".

Page 4, Section 5, item 3: insert a comma after "information".  Change
"though" to "through".  Change "I-D.ietf-weirds-rdap-sec" to RFC 7481.
Change "whois" to "WHOIS".  Change "http" to "HTTP".

Page 5, Section 6, 2nd paragraph: delete the comma after "registry".

Page 5, Section 6, item 1: insert "the" between "In" and "case".  Append a
comma after "prefix".

Page 5, Section 6, item 1: despite being based on the IANA PEN form, how
about adding a sub-item (d) for the organization's website?  This might
allow for user disambiguation of registrants with similar names.

Page 7, 1st partial paragraph, 1st partial sentence: insert "as" between
"so" and "to".

Page 7, 1st full paragraph: delete the comma after "allocation".

Page 7, Section 8, 2nd paragraph: delete the comma after "reasons".

Page 7, Section 10, 2nd paragraph, 2nd sentence: insert "an" between "for"
and "EID".

Page 8, Section 11.1, [I-D.ietf-lisp-eid-block]: change the "-09" to "-11".

Page 9, Appendix A: This appendix is almost wholly superfluous and
unnecessary to understanding the core of the document.  Most terms that
appear in the appendix make no other appearance in the body of the document
and the definition of these terms does not inform a reading of the body of
the document.  I'd recommend dropping the appendix and elsewhere in the
document throwing in a pointer to RFC 6830.