Notes Call #3

1. Roll Call

Taking roll call from Adobe Connect room.

Only on audio: No one

2. Welcome

Recap from day#1:

Good progress made - taking input from the surveys to move forward in the conversations
Minute silence in recognition of events in Paris, France and other world events

Objective of call #3

Review remaining areas of the survey
Consider rationale / motivation for positions (what issue is being solved)
Call #4 will be dedicated to links with CCWG on Enhancing Accountability and accountability areas of focus for CWG
Chairs statement expected at the end of the meeting to communicate the results of weekend sessions and expected next steps

Note: questions in the surveys were derived from comments/suggestions from the public comment forum - to facilitate CWG review and response to those comments.

Remaining issues from yesterday:

MRT - yellow questions from survey 1

The MRT's primary function should be deciding whether to renew the IANA Functions Contract and whether the IANA naming functions contract needs to be amended (question 15)
Should be solutions oriented instead of only crisis management.
Question seemed to imply one single role, that may be too narrow. Remediation of problems should be first step before escalation.
How to avoid scope creep of MRT? Functions of MRT should pertain to renewal and staying with the provider, not going into the weeds. At the same time, MRT is multi-stakeholder platform where the community deals with issues related to the IANA Functions Operator whether these come via the CSC or annual reviews. IAP is ultimate escalation - needs two parties.

Composition and size of the MRT should be difficult to alter or amend (question 21)

Answer depends on whether MRT is internal or external to ICANN.
Avri: there should be a stakeholder process to do it, but it does not need to be difficult. --> Existence of a proper process is an appropriate "difficulty"

3. Review Survey 2

Contract Co - Green Items , areas of convergence(unless marked differently)

Whether Contract Co. should be incorporated or not, and subject or not to a particular jurisdiction's laws shuold be examined by a neutral, unaffiliated expert (question 17).
Contract Co should be extremely light-weight and its purpose should be limited to holding contracts for the names community (question 19)
The bylaws of Contract Co should narrowly and clearly limit its activities.
Contract Co should be responsible for ensuring that root zone changes are in compliance with prevailing policy and then pass that change along to the Root Zone maintainer to be implemented (Disagreement - yellow item). CWG will need to deal with who needs to deal with authorization function, if it needs to be carried over after the transition. Not contract co - based on responses to survey. May not need to be something that is carried over, just because it currently exists in the contract.
The separation of the IANA functions and removal from ICANN should be seen as a last resort (question 30 - yellow item)
Circumstances for re-awarding the IANA Functions Contract should be limited to issues of non-performance relating to the IANA Functio, such as a failure to execute against established SLAs or non-adherence to contract terms (question 32). Is there a purpose in doing an RFP if you are not intending to change vendors? Is this question coherent with the position to have regular RFPs (see also question 31).

Internal to ICANN - Green items, areas of convergence (unless marked differently)

If adequate accountability mechanisms are in place, an ICANN Internall option should be adopted (question 1 - yellow item). Further details may be needed to be answer this question, i.e. which accountability mechanisms. RFP3b will use RFP3 mailing list. Will schedule a first meeting on Tuesday or Wednesday coming week, possibly including a straw man to focus discussions. RFP3b focusing on options that do not have a Contract Co.
Adequate accountabilty mechanisms in an ICANN internal option should include the possiblity of removing the IANA Functions from ICANN. (question 2)
An ICANN Internal solution would be cheaper to implement and operate than the Contract Co. option (question 5 - yellow)
An ICANN internal solution should include a mechanism where the IANA Functions can be removed from ICANN for cause related to the IANA Functions and contraced out to a third party (question 6)
An ICANN internal solution should provide that Contract Co can be created if necessary (in order to contract out the IANA Functions (question 7 - yellow)
An ICANN internal solution should include a mechansims where the MS community may remove ICANN directors, or the entire Board for "cause" under specific circumstances related to the IANA Functions (i.e. serious and persistent issues of non-performance relating to the IANA Functions, such as a failure to execute against established SLAs or non-adherence to contract terms, and failure to follow applicable policy) (question 9 - yellow)

IAP - Green items, areas of convergence (unless marked differently)

There should be standard procedures for catching IANA process errors before resorting to an appeals process. (question 1)
Existing arbitration providers should be used instead of creating a new body (question 2 - yellow)
A mechanism for an affected party to appeal a decisioin relating to the Root Zone would be beneficial for Internet stakeholders and consumers (question 3 - yellow)
Appeals should be managed differently, depending on whether the appeal involves a gTLD or a ccTLD (question 4)
Terms of reference for the IAP and details on the compositioin of the panel should be defined (question 5)
The IAP component of the IANA CWG proposal is crucial, and its location outside of both ICANN And the IANA oversight function is necessary (question 6 - yellow)
An appeal mechanism is not needed (question 9 - yellow in the negative - disagreement)
The ground for an appeal should be limited to whether or not relevant policy was followed (question 10 - yellow). Need to define what 'policy' means - appeals should be directed at decision-maker not IANA Function which performs clerical function. But alslo need to foresee situation in which IANA doesn't do anything or delaying making certain changes.
The appeals process should only challenge whether established policies have been properly applied or adhered to by the IANA Functions Operator. It should not evaluate the merits of such policies. (question 12 - yellow)
The appeals process should be binding on the IANA Functions Operator (question 13)
Standing to file appeals should be defined (question 17)
gTLD REgistry operators should have standing to appeal delegation and re-delegatioin decisions to which they are a party that they believe are contrary to approved gTLD policy (question 18)
ccTLD registry operators should have standing to appeal delegation and re-delectation decisions to which they are party that they believe are contrary to applicable laws and/or applicable approved ccTLD policy (question 20)
The ccNSO or GNSO, as applicable, should have standing to appeal implementation of any approved policies relating to delegation of ccTLDs or gTLDs as applicable that they believe are inconsistent with those policies (question 22 - yellow).
Governments should have standing to appeal ccTLD delegation or re-delegation decisions that they believe are contrary to applicable laws only where that country's ccTLD is involved (question 24 - yellow). May need to measure this question and others against Framework of Interpretation WG work as it may already have been addressed there.