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