Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block
Note: This ballot was opened for revision 12 and is now closed.
(Brian Haberman) Yes
(Jari Arkko) No Objection
(Deborah Brungard) No Objection
(Ben Campbell) No Objection
Comment (2016-02-17 for -12)
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"
(Benoît Claise) No Objection
(Spencer Dawkins) No Objection
Comment (2016-02-15 for -12)
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.