Last Call Review of draft-ietf-lisp-sec-13

Request Review of draft-ietf-lisp-sec
Requested rev. no specific revision (document currently at 21)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-10-04
Requested 2017-09-20
Authors Fabio Maino, Vina Ermagan, Albert Cabellos-Aparicio, Damien Saucez
Draft last updated 2017-10-23
Completed reviews Rtgdir Last Call review of -12 by Manav Bhatia (diff)
Secdir Last Call review of -13 by Takeshi Takahashi (diff)
Opsdir Last Call review of -13 by Mehmet Ersue (diff)
Assignment Reviewer Mehmet Ersue
State Completed
Review review-ietf-lisp-sec-13-opsdir-lc-ersue-2017-10-23
Reviewed rev. 13 (document currently at 21)
Review result Has Nits
Review completed: 2017-10-23


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



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 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."