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