> The document looks to me underspecified. I'm sorry, it is completely specified. I'll respond to a subjective comment with a subjective reply.
> There is no formal definition of “Distinguished Name”, for what is worth the > document can be renamed "LISP LCAF String encoding” I provided a reference in the document to th Address-Family-Identifiers document. Where it is listed. That creates the code point. And this document says how LISP will use AFI=17. > 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. You can do partial match lookups on strings. If a distinguished-name "luigi" is registered as an EID to the mapping system, and a lookup is done on "luigi-iannone", the map-server can decide if partial or exact matches are performed. I can make this more clear in the document. > 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. Zero termination of the string creates the length for implementation that can support AFI=17. For implementation that do not, it uses the EID mask-length to skip over an EID in an EID-record. For RLOC-records if you don't understand an AFI, you drop the packet. > I think the draft should include some specific use cases that prove that LCAF > strings are really useful. Strings are useful. How they are encoded is another topic. > 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….) That makes name uses more bytes in the packet. We want to encode a string of length 5 in 8 bytes. 2 bytes for AFI and 1 byte null-character. You can encode it more efficicently than that. And that is why AFI=17 was chosen. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
