So since there seems to be support and little or no objections, can we make this draft a working group document and continue the discussion. I can add more text to reflect Joel’s comments.
Thanks for the comments and discussion Joel. Dino > On Sep 29, 2020, at 1:23 PM, Joel M. Halpern <[email protected]> wrote: > > Another way of looking at my issue here is the many problems the DNS folks > have had with tXT records. They are free-form text. Making them useful has > proven to be a major challenge. hence, even as RLOCs rather than EIDs (where > the collision problem is not an issue), I am concerned that adding this is > opening a can of worms. > > Yours, > Joel > > PS: Dino, youa re correct that the hash probably won't collide with anything > else. But for anything that is not cryptographically random, collision seems > a major risk. > > PPS: Even for you hash case, you concluded that you needed a type > discriminator (hash:). Presumably so taht you would know which one you > needed for the ECDSA operation. Sensible. But if we need that, probably > eveyrone needs that. At which point it should be part of the definition. At > which point we get into defining the structure of these naems with sufficient > uniqueness. Or sub-typing, Or something. > > On 9/29/2020 3:58 PM, Dino Farinacci wrote: >>> I think it really needs more structure. One does not say "here is a shared >>> database; use any key you like and hope not to collide with other users." >> I can add that to the draft. >>> >>>>> 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.) >>>> The ecdsa-auth use-case assumes that the hash length is largest where >>>> collisions won’t happen. There are applications that use UUIDs and encodes >>>> them in distinguished-name EIDs. UUIDs do not have an allocation >>>> authority. And: >>> >>> the ECDSA draft assumes that no other uses will begin with hash:. This has >>> nothing to do with length. My concern is not collision amon hashes. It is >>> collision between hashes and other uses of the "distinguished name" LCAF. >> If the hash avoids collisions, then anything you put before it, in totality >> makes the name unique. >>> 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. >>>> So lets have a look at each Internet Draft that references >>>> draft-farinacci-lisp-name-encoding and lets review those semantic >>>> encodings. >>> >>> Looking at the couple of places you have chosen to use this, and have >>> therefore been careful not to collide with yourself really does not tell us >>> much. >> If you connect two IPv4 islands behind NATs and register their addresses to >> the same instance-ID to the same mapping system, those addresses will >> collide. The same goes for these names. That is what VPNs are used for and >> hence instance-IDs allows the registering entities to agree to not collide >> names. >> This is a general principle for the LISP mapping system for all EIDs being >> used. And note for RLOC-names, they do not have to be unique. They are >> free-form documentation based names. >>> If you want a sub-type under LCAF, then let's do that. trying to pretend >>> arbitrary strings have distinguishable semantics is asking for trouble. >> The AFI encoding is tigher and save less space in the packet and hence why >> it was chosen. Plus if you use it in LCAFs, there is less LCAF nesting. I'm >> sure many coders appreceiate this. >> Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
