Well chairs - can you make a decision? Dino
> On Sep 29, 2020, at 1:58 PM, Dino Farinacci <[email protected]> wrote: > > 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
