Dino and Brian:   I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the  IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.   Status of draft:  Ready with nits Caveat:  I am not a crypto expert.  I am not a lisp expert.   Nits (#1-#4), #5 nit/minor   #1 Introduction p. 2 – It would be nice to expand the definitions of ITR, PITR, ETR, RTR in their first use.  This is common editorial usage.    #2 p. 3 – it would really nice if this document indicate why the requirement were chosen for the solution space on page 3 paragraph 1.  I realize that once you choose these requirements, the rest of the work falls out.   What’s important for OPS-DIR is whether you believe these requirement help make the system with crypto operate faster, with less overhead, or make it easier to manage.  If this is stated in an architecture document, a reference would be nice.   #3 Again, inquiring minds want to know on page p 5 – why you decided not to use the “R” bit for this use case and reserve it for the LISP-DDT security.  If there was an architectural choice, it would be nice to know it links to that point.   #4 p. 9 last paragraph (editorial/   /When an ITR or PITR receives a packet to be encapsulated, they will/ To /When an ITR or PITR receives a packet to be encapsulated, the device will/   #5 p. 11, section 1.    Does the changing of keys via RLOC-probing cause of a problem if the ITRs or ETRS are mobile or going up/down at the time a map-cache is added?  Or in another way, is there any chance that fluctuation in the systems connectivity can get the system into a state where the keys are out of date between peers.  If so, how do devices in the system get back in sync.  [#5 – may be understood better by crypto expert]   Sue Hares shares at ndzh.com