[lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-eid-block-12: (with COMMENT)

"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Mon, 15 February 2016 17:07 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160215170730.24481.67897.idtracker@ietfa.amsl.com>
Date: Mon, 15 Feb 2016 09:07:30 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/ZTSmxLSbdrwRxQonJJ2uDPHYRrQ>
Cc: draft-ietf-lisp-eid-block@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org
Subject: [lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-eid-block-12: (with COMMENT)

Spencer Dawkins has entered the following ballot position for
draft-ietf-lisp-eid-block-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

[lisp] Spencer Dawkins' No Objection on draft-iet… Spencer Dawkins
Re: [lisp] Spencer Dawkins' No Objection on draft… Luigi Iannone