Last Call Review of draft-ietf-lisp-eid-block-mgmnt-04

Request Review of draft-ietf-lisp-eid-block-mgmnt
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-04-28
Requested 2015-04-16
Authors Luigi Iannone, Roger Jorgensen, David Conrad, Geoff Huston
Draft last updated 2015-04-29
Completed reviews Genart Last Call review of -04 by Peter Yee (diff)
Genart Last Call review of -06 by Peter Yee (diff)
Secdir Last Call review of -04 by Dacheng Zhang (diff)
Opsdir Last Call review of -04 by Susan Hares (diff)
Assignment Reviewer Peter Yee
State Completed
Review review-ietf-lisp-eid-block-mgmnt-04-genart-lc-yee-2015-04-29
Reviewed rev. 04 (document currently at 07)
Review result Not Ready
Review completed: 2015-04-29


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-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?


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

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

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

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

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.