None of these named spaces would "fail" to work as sub-spaces of .ALT or .arpa or any other community-led IETF tech community managed label.
You haven't convinced me they innately need to exist as a TLD. The sole entrypoint into that model, is a belief in what happens in the browser bar and at the shell. You are the designer of systems of world scale, I do not doubt. But you are bringing an assumption to the table: all things of world scale do not have to exist at the top of the worldwide name space. I remain unconvinced. I remain of the belief, that shutting 6761 down is wiser than racionation over the problem space, without recognizing intractable elements to this problem because its not at root a technology problem: its a name problem. We gave that role to somebody else. -G On Thu, Sep 22, 2016 at 9:15 AM, hellekin <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 09/20/2016 01:33 PM, Stephane Bortzmeyer wrote: >> >> And I'm still not convinced there is a problem to solve >> (unless the real issue is "how to prevent the registration of .gnu and >> .bit?") >> > > Even if I supported the SUDN of P2P systems draft mentioning both .gnu > and .bit, I see a great deal of difference between them. .gnu (and > .zkey, .exit, .i2p, .onion) all require (and request) an unique NXDOMAIN > response from DNS, and use their respective protocols to resolve from > the "stub resolver" (as mentioned in draft-tldr-sutld-ps-04.) .bit is a > special case in our I-D because it proposes an alternate way of DNS > resolution, not using a delegated tree, but a blockchain. With regard > to DNS, .bit is different from the other five, besides the political > effects of its specific approach (which I think should be able to exist > anyway, for the sake of Internet End-to-End principle if nothing else.) > > None of the problem statement drafts took reference of the Special-Use > Domain Names of P2P Systems which initiated this years long discussion > that ended up with: should we revise or replace RFC6761. In my position > of editor of this draft, I don't really care what happens to RFC6761, > but I'm very much interested in .gnu & .zkey, .i2p, .onion & .exit, and > .bit. I don't think any of the proposed problem statement drafts > mention the perspective of actual P2P networks sharing their experience > and their existence, and coming to the table with the idea of abiding to > the IAB rule of a globally unique namespace. > > We say: hey, look, we exist, and we want to say that these are not > transactional names: they bear cultural value. They came from usage and > the history of the Internet. The DNS should know about them, so that > people won't ever get into trouble trying to resolve non-existing names, > or trying to resolve eventually delegated names that will collide with > existing networks if they keep being ignored by DNS. > > I had the time to appreciate the nuances that IETF members can find in > this seemingly simple approach, and try to generalize the issue: "what > if others come and do the same? Who's responsible? How to judge of the > legitimacy of those claims?" Etc. > > But what's been going on, from my point of view of volunteer who only > has one life (that at least we share) and doesn't get paid for this > work, is choking-by-bureaucracy. People whose profession is to sit on > IETF WGs can spend their time not solving issues, they still get food on > the table. And so production of norms is an endless process, and if not > this one, another. > > As I see it, the problem we're trying to address is whether these P2P > systems warrant some recognition from the Internet Community, is that > something we want to encourage, or is that something that belongs to > "the Deep Web", and we'd better leave that out of the picture? I'm not > talking about .mail, .corp, and .home, that belong to another category > (I like "toxic waste"), or "people trying to circumvent IANA processes", > or "don't want to pay", or "don't want to follow process". We did > follow process, once we realized there was one. And suddenly, after a > decade, everybody realizes there's an RFC6761 that really shouldn't have > become an RFC in the first place, and this process is flawed, and we > don't know how to handle this. But when the Browser Forum comes with a > deadline, consensus is easily achieved in no time, despite the draft is > flawed with idiotic requirements such as "Users are expected to...". > > My take is that none of the proposed statement drafts took care of > situating the debate in its (recent) historical context. The fear of > frictions between IANA and IETF have had more to do with how things > went, than actual ponder of the technical arguments put forth by the > various RFC6761-based drafts. Case by case is not necessarily evil: not > everything can nor should be automated. > > I believe that in the case of the 6 TLDs we asked for, there's little > doubt they make sense technically, historically, and culturally. That > others may take it as 'a way in' and flood the IETF with stupid drafts > 'just in case' seems to me the core of the problem, that was mentioned a > few times over the years, but didn't make it through the recent drafts. > >> The rest of this email is about >> draft-adpkja-dnsop-special-names-problem-06. Executive summary: no, no >> and no. >> > > This is a great summary, thank you! > > == > hk > > -----BEGIN PGP SIGNATURE----- > > iQJ8BAEBCgBmBQJX4xScXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 > ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg95ckP/0/Ub0IPt7VQWBbjH914gbAP > v1fKjQhuMSUiuYa+KJ7AyYTvTjqH6+NgEx5T/1a5F+tcTlD7rEQ6C4UDYqUTqUBS > fa+H0i3sGkJT7it6vV5sjB9LTLb2Dmxff6uZkeBVtUbrun2Xl9uzBq9+rBloBQN0 > 5WDr2ykEbnTIBIM2bbBlhJSpHO6jhLgXhYQkWiFK+7c1zI2X3qNp6dlCnwJ9Gy7d > KNQNUMmBllAepF6kF0kXv07I8cEPjx9bRc6LY5wIW08Sa3j3R0UEtzBoUODFr/oJ > RbIq0bJgK8COZfEzEv6oJ1iDT64JXi2FxlPflBdqgFHiPQSX1Ermm1UtJU1Wrrcb > S/Y6890dyJOa+014KUBdroGeH/MfZLHwKJELi6bs2wENkGp8ye6LwIOeJBOfJ47/ > 6Tt7ow+j9y05Xjh9lM1pOlQdlsusLmOHiBQ7cfWb1uo3XYCr5e86cUQ6S/3iBg17 > y0WfX1mFjWTvBnrLqMQrXTThiItMT+WN5JzkEcwfMv00oF62DQYh89WPzQ1SVSqQ > vCQbCi5a25JfLtbS/LgJo4diXlnayMhJ5RtQIdBEbej2kO971eoYLxwma8jDB3gv > mV8cJcjg4juj8Rpp0+eYsSNnOSlHcuZoaJBrpgd7XQNejuLZdR5/E3NmY1T+0Kif > vVimJR3aa0C5SQQVFDxM > =1b0u > -----END PGP SIGNATURE----- > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
