Looking again at this draft, and at the example Dino points to, I think
there is a basic problem with the work and the usage.
the problem is not a problem for the mapping system per se. It is a
problem for usage.
The draft does not define any mechanism for structuring, allocating, or
otherwise managing the space of names. It does not say "URIs". It does
not say "DNS names" It syas "ASCII string, terminated by 0".
If there is to be standard usage of this, and if there is to be more
than one such usage, how are collisions avoided? It is not sufficient
to say "just don't" as different problems may end up needing overlapping
name spaces. The hash usage (below) assumes that the solution is to
prepend the string "hash:' on the front. But that is not formally
defined, and as such is not actually a reliable mechanism.
(Frankly, for the hashes I would prefer to use a different EID LCAF that
carries the binary hash.)
I suspect that the people supporting this have expectations on how this
will work. But it seems sufficiently basic that the semantics, rather
than the encoding, is where I would expect the WG to start. Encodings
are easy.
I will also acknowledge that as chair I have concerns about turning LISP
into an arbitrary database system. Our charter is a mapping system in
support of routing. I understand why the ECDSA keys need to be in
there. But I do not want to fall into the BGP trap of trying to solve
every problem with the hammer in my hand.
Yours,
Joel
On 9/28/2020 10:48 AM, Dino Farinacci wrote:
As chair, I would really like to see something more than just +1. For example,
what do you see this as being useful for?
There are several Internet Drafts that show uses for distinguished names. Case
in point is the draft-ietf-lisp-ecdsa-auth working group Internet Draft.
And as Albert said for labeling RLOCs. It makes it easier for operators to run
and debug the overlay system.
Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
