I'm glad to see this thread on the list. First, a plug for this draft which is an attempt to lay a foundation for the discussion. There's at least one outstanding edit for it, it's not complete and is intended to be changed via discussions like this. The document hasn't been considered for WG adoption, I'm not sure whether it is mature enough or if it really belongs in a DNS working group.
https://tools.ietf.org/html/draft-lewis-domain-names-01 There are a few points in the thread I want to address, based on what I've learned in assembling the draft to date. 1) The fact that ONION names are created by the result of cryptographic functions, as opposed to the way the way the DNS manages names through a zone and zone administrator model is pretty significant in an architectural sense. A lot could be written about this, where each model has its advantages over the other. They are in parallel universes, I can't say one is necessarily better than the other. I'd venture that the DNS model is simpler to implement, hence it emerged first. 2) "Everything can be solved by yet another layer of indirection." I see this emerge in the discussion between the merits of attaching special meanings to top-level names (".magic" per GGM) versus the discussion of "struct sockaddr-onion" (appearing in Philip Homberg's message). The former talks about changing within what has been considered the remit of the IETF (protocols) and the latter talks about changing something external to the IETF's remit (API). Because of this, arguing in different remits, I don't see this as a solvable difference. (I.e., let's move the discussion one way or the other.) IMHO, I believe that there can be a way to attach resolution semantics to top-level names and implement this in the API level. IOW, for DNS "above the DNS" in the software stack. This is just a belief, not a certainty. 3) That URLs do not have DNS names, per Mark's thread kick-off message...if this isn't clear in my draft, it should be. My draft also tries to look across as many protocols/applications as possible for how the use of identifiers/domain names have evolved over the past two decades. 4) When comparing naming systems, it's tempting to sound competitive. The DNS is an established system with many practices built around it and a considerable economic (non-tech) investment in it. Newer systems ought not try to compete with DNS but emphasize coexistence with it. And discussions about the DNS ought to keep in mind that there is room for innovation in this space. ('Cuz, frankly, the protocol running over port 53 is pretty old and cranky.)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
