The initiation problem is the belief IETF needs a mechanism to identify non-use of the DNS or special use of the DNS demanding a break-out from normal gethostbyname() and related processing.
The second order problem is that people come to the table with proscriptive ideas about the specific label: where it is in the DNS hierarchy, and what string value the label bears. The latter, is the decision-role of ICANN. Under advisement, yes. respecting IETF process yes. But the mechanism as written in 6761 vests IETF with a process outcome which specifies where the label is, and what value. Thats just wrong. Consider IANA codepoints. You don't tell IANA "I want 42" -You ask IANA to reserve one and in draft status, you use a $nonce and in publication its assigned BY IANA AT THAT TIME or, if pre-reserved, we understand how and why. The current 6761 breaks this model. It breaches process badly inside ICANN and the worlds vesting of 'value' in DNS labels, (rightly or wrongly) Thats why I wrote the shut it down draft. The problem is not the desire to reserve labels, its the way we've specified it, promoting (a) top level and (b) specific strings into ICANN driven decision logic. -G On Fri, Sep 30, 2016 at 3:08 AM, John R. Levine <jo...@iecc.com> wrote: >> If the process was a success, we would have had the other candidates go >> through as well. The process was a failure because it has been rather >> arbitrary - which is why it needed to close down as it did. > > > Some of us think that the process worked OK, and the other candidates > don't meet the requirements that .onion did. > > This isn't to argue that 6761 is perfect, but that we have little > agreement on if or how it's broken. > > R's, > John > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
