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