> On 4. Aug 2022, at 14:06, Vittorio Bertola > <[email protected]> wrote: > > > >> Il 04/08/2022 08:40 CEST Martin Schanzenbach <[email protected]> ha >> scritto: >> >> Anyway, going to ICANN in order to collect a TLD is not a reasonable process >> for >> publishing our draft. >> We would not even know what the process would be (after the RFC? before >> writing it? While writing it? What if ICANN denies a request? All the >> work is moot?) >> Similarly using "www.example.com!gns" et al. is not a reasonable change. >> As that impairs usability and is incompatible with applications that >> expect domain names. > > The problem is that your entire project is conceptually and politically > flawed. > > If you want to establish an alternative namespace to the DNS, then you should > not use DNS-compatible names. >
There are a lot of "DNS compatible" names that are not names in DNS. And namespaces. I hope you do not want me to start a list. > ... and you should be damned. > Oh great. > If you want to establish a different way to resolve actual DNS names, then > you should come here and propose a revision of the DNS protocol, or an entire > new protocol to replace it, and have it standardized by the IETF, or rejected > if the community disagrees with you. > We went through the proper channels and procedures of the IETF regarding deconflicting before going the IS route. > Also, if you think that your project requires a valid TLD in the existing DNS > namespace, then you should get one following the same procedures as everybody > else, which means either applying for a string to ICANN, or getting an IETF > Standards Action specification as required by RFC 6761 section 4. We did. Just to refresh everybody's memory: https://datatracker.ietf.org/doc/html/draft-grothoff-iesg-special-use-p2p-names-04 IETF decided to not follow their own procedures. > An independent RFC would not meet these requirements, and I do not see why > the ISE should ever publish it, except to create more confusion and more > arguments. Why did .onion meet those requirements? In fact, what requirements? .onion does not even have a specification for the name system it provides published. > > More generally speaking, the DNS today is both a several billion dollars > industry and a fundamental, regulated instrument for the political and > socioeconomical stability of the entire world, way more than it is an IETF > protocol. People are free to introduce politically motivated attempts to > disrupt the current balance, but they should not expect cooperation, not any > well-behaved global institution should provide any. Even if some of us may > individually like the idea, as an institution the IETF is part of a bigger > arrangement that it cannot unilaterally challenge without losing its face. And IESG is able to identify a conflict right at this moment as part of the conflict review and prevent publication. It is our goal to trigger discussions and show how an alternative protocol to resolve domain names could work and possibly how they can be experimentally integrated into the Internet infrastructure. If that has no place in the RFC series (we are not even talking IETF/Standards Track here), then so be it. Are you the authority to decide? I think it is still a matter of discussion if there is a conflict at all. And this discussion is currently held here. You are trying to kill it using, what, political arguments? Is the DNS namespace and its billion dollar industry so fragile that it cannot handle experimental alternative domain name resolution mechanisms that may be used for resolve "DNS-compatible" names as well? And if the IETF is, as you insinuate, some kind of guardian of that industry that relies on the existing infrastructure, what chances would any proposal have going through the respective processes in the future? BR > > -- > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > [email protected] > Office @ Via Treviso 12, 10144 Torino, Italy
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
