In message <5d60ceeb-a781-4db4-aad6-9ef57a482...@difference.com.au>, David Cake writes: > > > On 16 Jul 2015, at 4:11 am, Francisco Obispo <fobi...@uniregistry.com> > wrote: > > > > > >> This was proposed in the working group. It obviously doesn't work, > >> first because TOR can't come up with that kind of money, but second > >> because TOR doesn't want a TLD (hellekin's erroneous statements > >> notwithstanding). What they want is a special-use name. A domain name > >> does not accomplish the intended purpose, because it has to be resolved > >> by sending a query to a DNS server. A third objection was one Ed raised > >> earlier for an unrelated reason: we can't assume that the TOR project > >> will continue to exist as an entity that can own a delegation. What > >> happens when that stops? Does the Church of Anatman get to buy the > >> domain and start snooping on TOR connections? > >> > > > > Well do they want a TLD but they donât have the money? or donât want a > > TLD? perhaps the problem is in how the TLD program treats them, in which > > case the answer should be on the ICANN side. > > The ICANN process is designed towards the goal of delegation, and > has a great deal of steps in the process of application that make no > sense at all if delegation is not the goal. Tor do not want delegation, > and delegation is not appropriate for this intended use (the mitigation > of privacy leakage that the Tor Project would be able to provide as > delegated register is considerably less than that proposed in the draft). > I do not think there is anything useful in demanding that ICANN create a > slew of separate processes to roughly replicate Special Use Names that > will never deliver what is wanted, when the Special Use names process > already exists, and will.
Actually it needs a *insecure* delegation to a empty zone. This allows local recursive servers to generate NXDOMAIN responses *locally* rather than having to recurse and leak the query name in the process further still and to allow those responses to validate. The alternative to that is to stop growing the root zone so that every recursive server on the planet can successfully load it. > >> A fourth objection which I don't think was raised is that this doesn't > >> work for .local or any of the other special-use names, and if it doesn't > >> work for them, it doesn't make sense to try to make it work specifically > >> for .onion. Why is .onion special? Should Apple or Microsoft be asked > >> to pay $200k to reserve the .local TLD? > > > > Having this mechanism for reserving special use names, creates two > > different authorities managing the same namespace, this will require > > tight coordination as well as clear and transparent guidelines to make it > > work. > > In this case, there seems to be no reason why we canât manage the > necessary coordination by having people participating in both spaces, and > there have been several involved, in that several people involved in > DNSOP discussion are also active in ICANN processes. After this case, it > may be worth considering how the process can be improved - we still have > several other potential special use names to consider. > > David -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
