Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block
draft-ietf-lisp-eid-block-13

Substantive:

- section 6:
Predictions that the IETF will or will not do something  are risky propositions at best. I suggest stating a default result that will occur _unless_ the IETF chooses to take action.

Editorial:
There's quite a number of grammar and word choice errors. I list some below, but I am sure I did not catch everything. I suggest another pass at proofreading before publication.

-3:
s/"avoid penalize"/"avoid penalizing"
s/"ask an allocation"/"ask for an allocation"  ; or "request an allocation"
s/"avoid non-LISP domains to fragment " / "allow non-LISP domains to avoid fragmenting"
"... which would negatively impact the BGP routing infrastructure"
Which would cause negative impact, the fragmentation, or the avoidance of the fragmentation?
s/"worth to mention"/"worth mentioning"

-4
s/"Such prefix"/"Such prefixes"  ; or "This prefix"
/"As the LISP adoption progress"/"As the LISP adoption progresses"

"... the EID block will potentially help in reducing the impact on the BGP routing infrastructure with respect to the case of the same number of adopters using global unicast space allocated by RIRs "
Convoluted sentence. Can it be simplified?
s/"Such trend"/"Such trends" ; or "This trend"

"With the exception of PITR case (described above)"
Which case is the PITR case? This is the first use of PITR.

-5:
s/"looks as sufficiently large"/"appears sufficiently large"

-9:
s/"provided by IANA before published"/"provided by IANA before publication"

Could you expand EID as EID Endpoint IDentifier in the document title?

I'm seeing text that's fairly clear, but could use a native English speaker pass. For example,

   Transition Mechanism:  The existence of a LISP specific EID block may
         prove useful in transition scenarios.  A non-LISP domain would
         ask an allocation in the LISP EID block and use it to deploy
         ^^^ "ask for"? or "request"?
         LISP in its network.  Such allocation will not be announced in
                               ^^^^ "Such an"? or "This"?
         the BGP routing infrastructure (cf., Section 4).  This approach
         will avoid non-LISP domains to fragment their already allocated
                    ^^^ "fragmenting previously allocated non-LISP address 
                         space in non-LISP domains"?
         non-LISP addressing space, which may lead to BGP routing table
         inflation since it may (rightfully) be announced in the BGP
                                 ^^^^^^^^^^ "correctly"?
         routing infrastructure.