Hello,

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.

Summary: not ready

I am new to LISP and reviewing this ID is also an opportunity to have a new fresh look at it.
In practice, I got stuck on the "Overview" (section 3) and could not go any further, too many open questions.

My comments:

-- Section 3 "Overview": I was expecting an overview of the ID, its goals, key principles, some technical aspects but not too much (it's an overview).
The first two high level paragraphs provide some insights but do not achieve the above objectives.
And the following are technical details not easy to read.
Even if I'm not necessarily the target reader, an overview should be understandable for someone knowledgeable in security.


-- using a single list of 1. to 6. items that mixes several notions complicates the understanding.
I suggest splitting into 2 distinct parts: Registration (1. to 4.), then Request (5. and 6.).
Also item 2. is badly placed (see below).


-- Item 1.
I don't understand the distinction here between entity vs. client (these terms are not defined in section 2).
What is meant by "A 3rd party entity that provides a service": what service? What relationship with the EID? Why 3rd party?
Is the "client" of this item the same "client" as in paragraph 2 ("client of the mapping system")?


-- I don't understand Item 2.
It's a bit contradictory, since it starts with "Anyone can lookup" and later it explains that there's a "group level auth".
If there's a group access control, do not say anyone can lookup, it's not the case.
I also do not understand why this item 2. is here rather than later, in the "Request" part.


-- Item 3., why are non-Crypto-EID mentioned?
If I understand, this ID is proposing the Crypto-EID (Intro says: "In this proposal the EID is derived from a public key").
So why should the ID give so much importance to the non-Crypto-EID? 
If it's similar, it's sufficient to say so rather than duplicating the description as if it was a new mechanism.
Also is "any EID type" equivalent to "non-Crypto-EID"?
Choose the right terminology and stick to it throughout the ID.


-- Item 4., first sentence says: "from the **registered** Crypto-EID".
This item describe the processing of a registration request, whereas it refers to an **already registered** Crypto-EID.
If you mean: "the Crypto-EID contained in the Map-Request message", say so.
Also, the whole description of the verification process is unclear to me.


-- I think Section 3 could benefit from a high level figure, that shows the actors, which one sends registrations or requests, where the mapping DB is, what it contains, plus key info in the registration and requests messages, etc.


-- Section 3, 1st paragraph:
Last sentence of 1st paragraph gives the objectives of the ID: "providing a more granular level of authentication as well as a simpler way to manage keys and password".
That's fine, but after reading items 1. to 6. I don't understand how this is achieved, how "granular and simple" it is, and to what it needs to be compared to assess these benefits.
Please give just a little bit more context.


-- Abstract says that "no new PKI infra" is required, and Section 3, paragraph 2, says that the "clients of the mapping system" are authenticated using Public Key crypto.
Perfect, but if there is no PKI, how can LISP prevent any entity to pretend to be an official client of the mapping system, a Pub/Priv key pair is not sufficient alone.
Items 1. to 6. do not answer and something is missing.
Please clarify the claim.


I'll wait for your updated ID before reading the rest of the ID.
And sorry for the delay.

Regards,    Vincent