[CWG-RFP3] Revised Survey

[Guru Acharya]

Thanks for the detailed input Steve. This was extremely helpful in
understanding your position; and your proposal that the following existing
mechanisms are sufficient:
(i) Board engagement with all the SO and AC.
(ii) Ability of NomCom to raise an issue when a board position becomes
vacant.

On a separate note, is it possible for ICANN to share the Continuity Plan
under clause C.7.3 of the IANA Functions Contract? This document will help
the CWG to understand the complexity involved in transferring IANA
functions to another operator.


On Mon, Jan 5, 2015 at 6:55 AM, Steve Crocker <steve.crocker at icann.org>
wrote:

> Guru,
>
> Thanks for your questions.  Answers below.  Let me emphasize I’m speaking
> personally and not officially on behalf of the Board.  (We haven’t had time
> to coordinate each of my submissions.  When we do coordinate, we will
> identify that a particular submission is on behalf of the Board.)
>
> On Jan 4, 2015, at 7:45 PM, Guru Acharya <gurcharya at gmail.com> wrote:
>
> Two questions:
>
> 1) Please engage me in an example to explain what "other existing
> mechanisms" will kick in once the naming and shaming happens? It would be
> great if you could do it step-wise starting from naming/shaming right up to
> to board putting itself to risk. I apologise for my ignorance but this will
> help us to have an informed position before we fill up the survey where you
> have suggested that there should be no MRT.
>
>
> Ok.  To keep this brief and bounded, I’ll focus on just one or two
> specifics.
>
> For the naming community, the IANA function consists of updating the root
> zone whenever the NS or DS records change for a TLD or updating the
> corresponding whois data base of contacts whenever the administrative or
> technical point of contact changes.  The two measurable criteria are
> whenever it’s done accurately and how long it takes.  There is a LOT of
> care taken to make sure it’s done accurately, and that sometimes requires
> some back and forth with the TLD operator if there’s any doubt or
> ambiguity.  The TLD operators range from major, large scale operations,
> e.g. PIR for .org and DENIC for .de, to very tiny operations in small
> countries with poor communications and limited technical knowledge.
>
> What can go wrong?  Well, it would be very bad if the wrong change is
> made.  If it ever does, in my view it would merit a careful investigation
> as to how it happened and what to do to prevent it in the future, more or
> less similar to an accident investigation after an airline crash.  I’m not
> aware of any such incidents in the last several years.
>
> The other thing that might cause concern is if it takes longer than
> expected for a requested change to be put into effect.  There are published
> statistics on this already.  I have not been tracking the full details for
> each and every change, and I don’t know if there have been any instances
> where a TLD operator has expressed unhappiness.
>
> As I indicated, I could imagine and support the creation of a review team
> that audits the performance of the IANA function and reports to the
> community if there are issues.
>
> Now, you’re asking what happens if the review team finds there has been a
> problem and reports on it to the community.  I would expect that would
> become a priority item for attention and response from ICANN management,
> probably starting with the senior official in charge of the IANA function.
>  (That’s currently Elise Gerich, IANA VP.)
>
> If the problem weren’t cleared up quickly or if the community felt that
> the response wasn’t sufficient, I would expect this would become a topic
> taken up in GNSO, ccNSO, GAC and SSAC.  The Board would have already been
> paying close attention.
>
> Besides the “soft” mechanisms of public attention, public forums, etc.,
> each of the SOs and ACs has a formal channel to the Board to set policy,
> give advice, or otherwise engage.
>
> If you further suggest that all of that hasn’t been successful, the
> community then has access to the operating plan and budget for the
> following years.  And finally, the Nomcom and the SOs and ALAC can make
> this an issue when they next choose Board members.
>
> I have carefully not mentioned decisions regarding delegation and
> redelegation of either gTLDs or ccTLDs.  Those decisions are outside of the
> IANA function, though under the current IANA contract with NTIA the IANA
> group provides input to the decision for ccTLD delegations and
> redelegations.  I expect the division of responsibility will get cleaned up
> after the transition.
>
>
> 2) Are you also opposed to the CRISP proposal for a service level
> agreement between the RIRs and ICANN? Wouldnt just naming and shaming work
> for them as well? I am asking this to understand whether your proposal is
> names specific (because we reside in ICANN) or also for the other two
> communities (which reside outside ICANN).
>
>
> I don’t have any problem with a SLA (service level agreement).  The IETF
> has long had one in place and there is a team from the IETF management that
> meets regularly with the IANA team to review the performance.
>
> Note that the SLA says what the service level is supposed to be.  It does
> not have much in the way of recourse mechanisms.  It’s main purpose is to
> make it clear to both parties what’s expected.  That way, if there is a
> complaint, it can be compared against what was promised.  Extreme and
> purposefully unrealistic example: Suppose a TLD operator sends in a change
> to add a new NS server.  Two hours later the TLD operator complains it
> hasn’t been done yet.  An SLA that says the IANA function may take up to N
> days will be helpful in telling the complainant his expectation is wrong.
>
> ==================
>
> I hope all of this helps.
>
> Steve
>
>
>
>
>
> On Mon, Jan 5, 2015 at 5:45 AM, Steve Crocker <steve.crocker at icann.org>
> wrote:
>
>>
>> On Jan 4, 2015, at 7:05 PM, Guru Acharya <gurcharya at gmail.com> wrote:
>>
>> Steve. In the absence of separability, what alternative accountability
>> mechanism are you suggesting? Just a "Limited CSC" (with MS composition) to
>> report and publish? Is naming and shaming sufficient?
>>
>>
>> Yes, naming and shaming is indeed adequate for the Limited CSC.  It is
>> very powerful by itself, and if the defects are not corrected strongly and
>> quickly, the other existing mechanisms will kick in.  The entire ICANN
>> organization, all the way up to the Board, will be held accountable.  If
>> there is a persistent problem that is not dealt with properly, I would
>> expect the SOs and ACs would start taking action, and, assuming the
>> unlikely situation where management does not fix the problem and the Board
>> does not fix management, the Board would be putting itself at risk.
>>
>> Steve
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jan 5, 2015 at 5:02 AM, Steve Crocker <steve.crocker at icann.org>
>> wrote:
>>
>>>
>>> On Jan 4, 2015, at 6:18 PM, Guru Acharya <gurcharya at gmail.com> wrote:
>>>
>>> *I also have a question for Steve: In your comments in a RFP3 meeting
>>> you suggested that ICANN should be the permanent home of the IANA function.
>>> In complete contrast, this CWG has listed separability as a principle,
>>> which allows the community to change the IANA operator if the need ever
>>> arises. Even the alternative proposal by ALAC accepts separability as a
>>> principle - it only differs in the method of implementation. So I am
>>> curious to know whether you agree or disagree with separability as a
>>> principle? If you agree with separability as a principle, how do you
>>> suggest we implement it?*
>>>
>>>
>>> Guru,
>>>
>>> Thanks for your question.  In my view, “separability” is not a
>>> *principle*, just a *premise* that has been put forth by its
>>> proponents.  And I do indeed disagree with it.  As I have said in earlier
>>> submissions, ICANN was created with the express purpose of being the home
>>> of the IANA function.  If there are issues with how the IANA function is
>>> carried out, either now or in the future, the right thing to do is identify
>>> those issues and address them.  Equally, if there are issues with how ICANN
>>> as a whole is performing, the right thing to do is to identify address
>>> them.  There are numerous mechanisms already in place and functioning for
>>> the purposes of identifying issues and dealing with them.  The existing
>>> mechanisms do not satisfy everyone, and it is perfectly sensible to discuss
>>> how to improve them.  However, in my view, the whole construct of Contract
>>> Co + CSC + MRT + IAP is an attempt to revisit the creation of ICANN and to
>>> create a set of structures that duplicate the multistakeholder structure
>>> that has been built with great effort and spectacular success over ICANN’s
>>> 16 years.
>>>
>>> Steve
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20150105/5fe456a5/attachment-0001.html>