Dino, Speaking as an individual (not as a chair) I have few technical comments on the document.
The document looks to me underspecified. There is no formal definition of “Distinguished Name”, for what is worth the document can be renamed "LISP LCAF String encoding” The slides you presented during IETF 96 suggest that there some longest characters match (like longest prefix match but on strings) and this part is not documented in the draft. As an implementer, the fact that there is no explicit length field is worrisome, performance wise. Because if I need to skip through a LCAF AFI=17 record I have anyway to parse the string since I do not know where it ends. This can slow down operations. I think the draft should include some specific use cases that prove that LCAF strings are really useful. The ECDSA use case is not a compelling example since you can use LCAF AFI=XX that identifies public keys encoded in a specific way (the WG should think about proposing such encoding….) Ciao L. > On 29 Sep 2020, at 22:58, 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
