TM+50 PICs On Tue, Apr 22, 2014 at 8:38 AM, Avri Doria <[log in to unmask]> wrote: > hi, > > for those not on ISOC's transfer email list. > > anyone want to help me create a list of examples of where > >> ICANN corporate behave without the benefit of the >>> bottom-up policy processes, and even on occasion contrary to those >>> bottom-up processes. > > > Steve has asked: > >> Would you care to provide specifics? > > > cheers. > > averi > > > > -------- Original Message -------- > Subject: Re: [IANAxfer] updated model for IANA transition > Date: Tue, 22 Apr 2014 09:36:05 -0300 > From: Steve Crocker <[log in to unmask]> > To: Avri Doria <[log in to unmask]> > CC: [log in to unmask] <[log in to unmask]> > > Would you care to provide specifics? > > Steve > > Sent from my iPhone > >> On Apr 22, 2014, at 7:32 AM, Avri Doria <[log in to unmask]> wrote: >> >> >> >>> On 21-Apr-14 16:28, Steve Crocker wrote: >>> >>> On Apr 21, 2014, at 2:57 PM, Avri Doria <[log in to unmask]> wrote: >> ... >>>> >>>> From the perspective of that question we have two things, IETF >>>> negotiating with ICANN and trusting the ICANN interface, and the >>>> ICANN insiders saying that this interface cannot be trusted without >>>> NTIA oversight or an adequate replacement. >>> >>> ?? I do not understand the latter half of this. What do you mean by >>> “ICANN insiders saying that this interface cannot be trusted without >>> NTIA oversight or an adequate replacement.”? >> >> There are a number of people inside the ICANN community, myself among >> them, who have seen ICANN corporate behave without the benefit of the >> bottom-up policy processes, and even on occasion contrary to those >> bottom-up processes. While NTIA's ability to affect ICANN behavior is >> limited and not the best mechanism, it is the only real oversight for >> ICANN, especially since the bottom-up oversight mechanisms of the AOC >> have yet to be proven sufficient. Losing the trust anchor of NTIA means >> those that cannot trust ICANN to behave properly as a bottom-up >> multistakeholder organization now, will have even less reason to trust >> ICANN in the future. >> >> Given that, there needs to be something to replace this trust anchor >> with regard to TLDs. To put is more bluntly. People trust, for the >> most part, that NTIA would not let ICANN make changes to the root that >> might be in ICANN corporate interests, e.g. arbitrary changes to ccTLD >> entries - though if course they are not happy about the national >> character of the check and balances. Would that trust be there if ICANN >> was able to directly translate ICANN decisions, especially those made >> without benefit of bottom-up processes, directly to IANA change orders >> without any checks and balances? >> >>> >>>> If IANA is to remain a single entity handling all of the >>>> directories that it currently handles we have a conundrum. Some >>>> clients, like IETF*, who trust ICANN want to keep the status quo, >>>> whereas the status quo is no possible for the TLD clients. TLD >>>> Supporting Organizations would need to accept a new situation of a >>>> ICANN without NTIA oversight, which some do not trust. >>> >>> Minor nitpick: For the IETF relationship you’re saying it is possible >>> to maintain the status quo but for the TLD operators you’re saying >>> it’s (structurally) impossible. >>> >>> Since the NTIA has not actually taken any actions regarding TLD >>> updates to the root for either gTLDs or ccTLDs, in what sense is >>> maintenance of the status quo not possible? >> >> As mentioned before, the trust anchor of checks and balances is lost. >> While for the most part NTIA is a pass-through mechanism, it is am >> important check and does provide balance and an address for any concerns >> that would be gone. >> >>>> One solution is to split it. IETF can continue to contract with >>>> ICANN for its directory services and GNSO and ccNSO can work with >>>> an externally accountable IANA oversight entity. >>> >>> The gTLDs are contracted with ICANN. Are you suggesting the gTLDs >>> would somehow modify their contract to insist on some arrangement >>> other than the one that exists for updating their entries in the root >>> zone? >> >> no >> >>> >>> >>>> I don't think this is optimal, though it is one of the paths >>>> explored several years ago by the NTIA comments process. One could >>>> ask what business ICANN has running a service for protocol >>>> parameter in its scope, but that is another topic for another list >>>> on ICANN's scope and mission. >>> >>> ICANN was purpose-built to operate the IANA function, which includes >>> publishing the parameters for the IETF-defined protocols. Perhaps >>> the question you might be asking is how NTIA came to be overseeing a >>> relationship between the IETF and ICANN without any meaningful way of >>> doing so. >> >> I thought it was purpose built to create policies by which the Assigned >> names and number would be governed. But yes, it has also been under >> contract to NTIA to provide the TLD directory service. And is also >> under 'contract' to other entities, e..g IETF, to provide them services >> as well. >> >>>> If however, IANA is to remain a single entity, which I support, we >>>> have to take into the account both IETF being happy with its >>>> current service provider contract, and the TLD market not >>>> necessarily trusting the situation post NTIA. >>> >>> As noted above, the gTLDs don’t really have much choice, nor is there >>> any indication that they have not been very well served under the >>> current arrangement. The ccTLDs share the same root zone, so it >>> would be peculiar and perhaps impossible to imagine two distinct >>> entities updating the root zone. And, like the gTLDs, they have been >>> well served. What protection are you looking for? (More >>> properly,what protection are THEY looking for?) >> >> To start with, a corporate ICANN that functions consistently in >> accordance with its bottom-up multistakeholder processes. >> >>> ... >> >> avri >> _______________________________________________ >> IANAxfer mailing list >> [log in to unmask] >> https://elists.isoc.org/mailman/listinfo/ianaxfer -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel