On 07/17/2015 03:10 PM, Paul Vixie wrote: > > i apologize for the lack of a pre-existing syntactic framework into > which tor's names could have been encapsulated from the outset. i > apologize even more for the fact that tor's perfectly reasonable request > for .onion is now causing this working group to consider scaling factors > which tor by itself would not have cared about. > *** I apologize that you feel the need to apologize.
There's certainly a need to adapt RFC6761 to the realization of the community of its transformational power. But it's unfair to put the lack of foresight of the community that adopted RFC6761 on the people who are using it, especially with good reasons. I think it's important that the IETF recognizes that the free software community of developers of peer-to-peer systems spontaneously came together to approach the IETF and solve an operational issue of their systems with the DNS, causing problems to the DNS and posing security issues to the users of P2P systems. This is a concrete example of the Internet community cooperating to make things better. This has nothing to do with future issues of scalability: it's a distinct problem that we have now and are trying to solve together. We already identify that RFC6761 causes problems and that it needs to be worked on, clarified, etc. But that should remain a separate issue. If there is an RFC and when people come to use it, suddenly it's not valid anymore, because people realize in hindsight that it's flawed or that oops, it's not what we expected, it poses a serious doubt about the validity of the institution. The danger I see, much before a scalability issue in DNS, is that developers who are more interested in running code than rough consensus will simply run the code and ignore the human part of the process, leading to a transformation of the Internet like everywhere else in society: where cold reductionist views tramp the human and leaves us outside of the living sphere, until we're redundant, useless, uncared for bloodless servo-units. I get the gravity of the situation. But I doubt that trying to fix the issue by tying the existing applications to a non-sequitur by fear of creating a precedent will achieve anything good at all. On the contrary I believe that now the jack is out of the box, it's important to realize that new applications will not be treated the same way that they were until now, pending a new version of RFC6761 that updates or obsoletes it; that among existing applications there are different cases, some of which are pretty easy to solve (e.g., .onion) for they only seek to prevent useless and potentially dangerous requests, while others are more complicated because they involve ICANN processes, SSAC recommendations, etc. (e.g., .corp, .mail, .home). Treating all the Special-Use Domain Names requests as they were a monolithic block did not work, and won't work (I'm talking from first-hand experience given that this WG has postponed to death tackling the single P2PNames draft), so it would be much more effective if we would take one step at a time, and not project future conditions where they do not exist yet and are likely to change drastically once RFC6761 is revised. My 2 satoshi. == hk _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
