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.