Hi Dino, Brian, and All, 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. The document is acceptable for an Experimental RFC. I don't follow LISP so I'm not sure if there is an actual mechanism for a device receiving a map request packet to decline an offered cipher suite. If there is, I didn't see it explained in the draft. You should address this in a future draft. This will be needed for when new cipher suites are added and a receiving device does not have the capability to handle the new cipher suite, or the case where an old cipher suite has been administratively disabled; like if it's been compromised and shouldn't be used. There are several ways to do this. There are a few nits in the draft you may want to take care of. First, Section 6 talks about setting the R bit to 0. Current: The 'R' bit is not used for this use-case of the Security Type LCAF but is reserved for [ LISP-DDT ] security. Therefore, the R bit is transmitted as 0 and ignored on receipt. Proposed:    The 'R' bit is not used for this use-case of the Security Type LCAF but is    reserved for [ LISP-DDT ] security. Therefore, the R bit SHOULD be transmitted    as 0 and MUST be ignored on receipt. A few other things I found: s/assymmetric/asymmetric/ s/Soon as an ETR or RTR/As soon as an ETR or RTR/ s/followed by key-id 2, an finally key-id 3/followed by key-id 2, and finally key-id 3/ Best regards, Chris