Last Call Review of draft-ietf-lisp-sec-13
review-ietf-lisp-sec-13-opsdir-lc-ersue-2017-10-23-00

I reviewed the document "LISP-Security (LISP-SEC)"
(draft-ietf-lisp-sec-13.txt) as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  

These comments were written primarily for the benefit of the operational
area directors.  Document editors and WG chairs should treat these comments
just like any other last call comments.

 

Intended status: Experimental

Current IESG state: In Last Call (ends 2017-10-04) 

IANA State: IANA Review Needed

 

Summary: 

The document specifies LISP-SEC, which is a set of security mechanisms that
provide origin authentication, integrity and anti-replay protection to
LISP's EID-to-RLOC mapping data conveyed via mapping lookup process.  

 

There is one nit in the document. 

      ** Obsolete normative reference: RFC 5226

 

Without being a LISP expert, I think the document looks good and does not
cause any issues related to operations and management.

 

However, the document lacks a sentence in the abstract on the justification
for choosing the document type as Experimental (see
https://www.ietf.org/iesg/informational-vs-experimental.html for potential
reasons). If it is practical and implementable I don't understand why it
shouldn't be Standards Track. As case 3 in the IESG page above suggests, if
it is practical but has been dropped for some reason and is being published
for the record, the document type should be Informational.

 

In case the document type is indeed correct e.g. matching to case 4 in the
IESG page above, it would be helpful to the reader to know whether the
protocol extension has been implemented and is possibly available as open
source. In this case please provide a reference to the implementation. 

Furthermore it should be stated that the WG is planning to make it standard
once the specification results in successful usage. I have seen Experimental
RFCs including Abstract or Introduction text like: 

"If this experimental specification results in successful usage, it is
possible that the protocol extensions defined herein get updated to
incorporate implementation and deployment experience, then pursued on the
Standards Track."

 

Thanks,

Mehmet