Last Call Review of draft-ietf-lisp-deployment-08
review-ietf-lisp-deployment-08-secdir-lc-kumari-2013-08-23-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

This draft describes LISP deployment scenarios. It represents current thinking
and is expected to change (I guess be obsoleted / replaced?) as more experience
is gained with deployment.

Summary: I'm not sure what to do here.

The document is very well written, and the authors seem to have taken care to
consider the implications of various deployment scenarios. In spite of knowing
very little about LISP I found the document to be accessible and easily
understood. It clearly lays out the considerations for different deployments,
and provides some guidance as to how to select.

However, the security considerations section simply says:
"Security implications of LISP deployments are to be discussed in
   separate documents.  [I-D.ietf-lisp-threats ] gives an overview of
   LISP threat models, while securing mapping lookups is discussed in
   [I-D.ietf-lisp-sec]."

This is a deployment document, and so this may be perfectly acceptable; the
"separate documents" may completely cover everything. Or not. I am unclear if
the authors mean that I-D.ietf-lisp-threats and I-D.ietf-lisp-sec cover all
security considerations, or if the implication is that there will be other
documents that cover the security implications.

http://i.imgur.com/5rTHfRs.jpg

Section 2.4.  "Inter-Service Provider Traffic Engineering" says:
"Failure to follow these recommendations may lead to operational and security
issues when deploying this scenario." I think that a (short) explanation of
what the security issues are if you don't follow the recommendations would be
nice.

Nits:
Section 4.2:
"For more details on P-ETRs see the [RFC6832] draft." -- I think that this
could be better worded as "For more details on P-ETRs see [RFC6832]" (think
this was written while RFC6832 was still a draft).

ID NITs complains about use of RFC2119 language ("It is NOT RECOMMENDED for
deployment"), but no RFC2119 reference / boilerplate. I'm scraping the bottom
of the barrel here, 'tis well written..

--
It is impossible to sharpen a pencil with a blunt axe.  It is equally vain
to try to do it with ten blunt axes instead.
    --  E.W Dijkstra, 1930-2002