CWG Design Teams - Status 21 April 2015.docx

CWG Design Teams - Status 21 April 2015.pdf

CWG IANA Transition Design Teams – Status 21 April 2015

 

Index

Design Team A

IANA Service Level Expectations

Lead

Paul Kane

Status [1]

Provisionally Complete

Note

 

 

Design Team B

Appeal Mechanism for ccTLD Delegations / Redelegations

Lead

Allan MacGillivray

Status

Completed

Note

 

 

Design Team C

CSC

Lead

Donna Austin / Staffan Jonson

Status

Completed

Note

 

 

Design Team D

Authorization Function

Lead

Cheryl Landon-Orr

Status

Completed

Note

 

 

Design Team E

SAC 69

Lead

TBC

Status

Completed

Note

 

 

Design Team F

Relationship between the NTIA, IANA and the Root Zone Maintainer

Lead

Alan Greenberg

Status

Provisionally Complete

Note

 

 

Design Team G

IANA Intellectual Property Rights, including the IANA Trademark and Domain Name

Lead

Greg Shatan

Status

Not Needed/Covered Elsewhere

Note

Priority 2 -- Chairs recommend that this dealt with through dialogue with other communities, as it is not limited to naming community. Should there be an IPR issue that is naming specific, the CWG would obtain input from the legal advisors. Call has been scheduled with chairs of CRISP team to co-ordinate, not only on this issue but also broader conversations.

 


 

Design Team H

.INT Operations

Lead

Elise Lindeberg

Status

Not Needed/Covered Elsewhere

Note

Priority 2 – Chairs understand that this issue is being dealt with by the GAC.

 

Design Team I

Competition policy and Conflicts of Interest

Lead

(Proposer: Christopher Wilkinson)

Status

Not Needed/Covered Elsewhere

Note

Priority 2 – Chairs consider that this issue is adequately addressed by DT-C. Furthermore, legal advisors have provided input on antitrust matters. If needed, additional guidance could be sought from the legal advisors concerning best practices governance guidance.

 

Design Team J

CSC/MRT confidentiality and the perception of conflicts of interest

Lead

TBC

Status

Not Needed/Covered Elsewhere

Note

Priority 2 – Chairs consider that this issue is adequately addressed by DT-C. Furthermore, legal advisors have provided input on antitrust matters. If needed, additional guidance could be sought from the legal advisors concerning best practices governance guidance.

 

Design Team K

OFAC Licensing

Lead

TBC

Status

Not Needed/Covered Elsewhere

Note

Priority 2 – Issue is being dealt with by ICANN as a whole. Proposed language will be circulated that should cover this commitment.

 

Design Team L

Framework for Transition to Successor IANA Operator

Lead

James Gannon (Matt Shears)

Status

Complete

Note

 

 

Design Team M

Escalation Mechanisms

Lead

Chuck Gomes

Status

Complete

Note

 

 

Design Team N

Periodic Review of the IANA Functions

Lead

Avri Doria

Status

Complete

Note

Cross-reference with CCWG to avoid potential overlap

 

Design Team O

IANA Budget

Lead

Chuck Gomes

Status

Complete

Note

Submit comments to FY16 Budget & Operating Plan Public Comment

 

Design Team A.  

IANA Service Levels Expectations

Draft Transition Proposal Reference

III.A.1.4.2 Accountability functions which require IANA to report on specific aspects of its performance.

Summary Description

Section C.4.2 of the IANA Functions Contract for NTIA outlines the requirements for the monthly performance progress report. The transition proposal will need to detail how these requirements are continued and/or modified post-transition.

Currently, these reports are public and list the current SLEs - these can be found at: http://www.iana.org/performance/metrics/20130915

Detailed description

This design team is expected to provide the following deliverables to be included in the draft transition report following CWG agreement:

  1. Review the IANA functions and their current SLEs
  2. Document, list and detail how these current SLEs should be modified, if at all, as part of the transition proposal to address any gaps or issues that were identified
  3. Document and detail escalation steps that should e available for direct customers in relation to these SLEs
  4. Document and detail how future review of SLEs is expected to take place

Following the completion of this specific task, this DT may continue if directed by the CWG Co-Chairs (in the same, or in a slightly modified composition) to address other elements that closely relate to the SLE namely escalations if the escalation steps identified under 3. are not sufficient to remedy the issue, documentation, reporting and collaboration.

Proposed Membership

3 gTLD registry representatives (Jeff Eckhaus, Jeff Neuman, Elaine Pruis)

3 ccTLD registry representatives (Jay Daley, (AP Region), Patricio Poblete (LAC Region) and Paul Kane (Europe).

Proposed by / Lead

Paul Kane

Staff Support

Bart Boswinkel / Bernie Turcotte

Status

Provisionally Complete

Determination by CWG Chairs

Priority 1 (Final)

Mailing list archives

http://mm.icann.org/pipermail/dt1/

Wiki Page

https://community.icann.org/x/CA4nAw

Target delivery date

17 April 2015

 

Design Team B.     

Assessment of the Level of Consensus within the ccTLD Community in Regard to a Possible Appeal Mechanism for ccTLD Delegations and Redelegations

Draft Transition Proposal Reference

III.A.1.1.3 – Independent Appeals Panel

Summary Description

The focus of the Design Team will be assess the level of consensus within the ccTLD Community in regard to a possible appeal mechanism on ccTLD Delegations and Redelegations.

Detailed description

On January 30 th CWG RFP3 reviewed a detailed document (available here ) summarizing the status of the IAP proposal and information flowing from the survey.  During the RFP3 discussion, it was noted that the IAP is in response to a request from ccTLDs.  RFP3 concluded with the following ‘Request/Action:” “ccTLD members and participants in CWG to come up with a consistent proposal on IAP” (see https://community.icann.org/pages/viewpage.action?pageId=52232278

Later that day, January 30, the CCWG of Accountability sent a letter to the CWG indicating that it has begun to elaborate is own work and that it will include consideration of binding redress mechanisms.  It has subsequently established an ‘Appeals and Redress’ work stream.  In their January 30 th letter, the CCWG also said that it has no intention to give an accountability mechanism decision-making powers relating to the (re)delegation of ccTLDs. 

The survey that the CWG undertook in January indicated that at a high level, there appeared to be a consensus on the desirability for such a mechanism, but when issues such as who should have standing to appeal, e.g. managers, governments etc. the level of consensus was considerably reduced.   In light of this, it is proposed that a Design Team assess, likely by means of a survey, whether there is any reasonable level of consensus in the ccTLD community for a ccTLD delegation and redelegation appeal mechanism and whether there might be design attributes that might lead to an acceptable level of consensus.

Proposed Membership

It is proposed that the Design team be made up of two to three ccTLD representatives (Allan MacGillivray, Maarten Simon, Paul Szyndler) and one or two GAC representatives/obervers (Elise Lindeberg). 

The DT will investigate the potential to include an expert that may have been identified to work with the CCWG on Accountability.

Proposed by / Lead

Allan MacGillivray, CIRA - ,ca, supported by Maarten Simon SIDN - .nl

Staff Support

Bart Boswinkel/ Grace Abuhamad

Status

Complete

Determination by CWG Chairs

Priority 1 (Final)

Mailing list archives

http://mm.icann.org/pipermail/dt2/  

Wiki page

https://community.icann.org/x/GhEnAw

Target delivery date

10 April 2015

 

 

Design Team C.    

CSC

Draft Transition Proposal Reference

III.A.1.3 – Administration / oversight of Statement of Work (SOW)

Summary Description

This design team will develop proposed language for inclusion in the draft proposal relating to section III.A.1.3 – Administration / oversight of statement of work.

Detailed description

NTIA currently provides and ensures the administration and day-to-day oversight of the statement of work. It was agreed that these functions will have to be replaced following the transition. 

 

Building on the 1 December Draft Transition Proposal (section 3.4.2.1) and taking into account the work undertaken by RFP3 in particular the functional analysis of the CSC, the design team is expected to describe the:

a)        Role and responsibilities of the CSC in relation to the administration and oversight of the statement of work;

b)        Identify and list IANA reports that are currently provided to the NTIA or provided as a result of the IANA Contract and specify and list those that are expected to be provided by the IANA Functions Operator post-transition;

c)        Specify an instruction for CSC, describing a process how, post transition, the CSC will review these reports, and

d)       Specify an instruction for CSC, describing a process how, post transition, the reporting requirements will be reviewed.

e)        Specify an instruction for CSC, describing remedial action in the event of poor performance of IANA against specified SLAs.

f)         Specify an instruction for CSC, of what is not mandated or out of scope.

g)        Consider whether it would be appropriate for the CSC to be an initial point of escalation for TLD operators who are experiencing IANA performance issues.

h)       Consider the extent to which the CSC could engage with IANA on emerging issues, that is those issues that are currently unforeseen, that impact registry operators and IANA services.

i)         Composition of the CSC taking into account the agreed role and responsibilities of the CSC by the Design Team.

 

The Design Team will work on the assumption that the status quo should be maintained as much as possible throughout the transition, while a process / mechanism should be put in place that will allow for review and possible changes to the reporting requirements based on that review after the transition on an ongoing basis. 

 

Following the completion of these specific tasks, the DT may continue if directed by the CWG Co-Chairs (in the same, or in a slightly modified composition) to organizational structure, confidentiality and possible conflict of interest concerns.

Proposed Membership

  • At a minimum two gTLD registry representatives with operational knowledge of IANA Functions and current reporting requirements (Donna Austin, Stephanie Duchesneau, Sarah Falvey )
  • At a minimum two ccTLD registry representatives with operational knowledge of IANA Functions and current reporting requirements (Staffan Johnson, Martin Boyle)
  • One IANA staff member (current or former) (Kim Davies)
  • One non-direct customer representative with operational knowledge of IANA Functions and current reporting requirements (Kurt Pritz)
  • One liaison from NTIA to verify NTIA’s current responsibilities (Ashley Heineman)

Proposed by / Lead

Donna Austin / Staffan Jonson

Staff Support

Bart Boswinkel / Bernie Turcotte

Status

Complete

Determination by CWG Chairs

Priority 1

Mailing list archives

http://mm.icann.org/pipermail/dt3/  

Wiki page

https://community.icann.org/x/HxEnAw

Target delivery date

10 April 2015

 

Design Team D.  

Authorization Function

Draft Transition Proposal Reference

III.A.2 Oversight and Accountability - NTIA acting as Root Zone Management Process Administrator

Summary Description

Currently the NTIA acting as the Root Zone Management Process Administrator must approve all changes to the Root Zone itself or the Root Zone Whois database that are proposed by IANA before they can be implemented.

The CWG needs to decide if this function needs to be replaced post-transition and if so how.

Detailed description

The design team is expected to review the current process and role of NTIA in relation to authorization and recommend whether or not to replace the NTIA (in part or in total) for the authorization of IANA requests. As the DT considers the options it should note that:

  • If the recommendation is not to replace the NTIA authorization function, IANA will submit its change requests for the Root Zone directly to the Root Zone Maintainer for implementation and will implement changes to the Root Zone Whois database directly.
  • If the recommendation is to replace the NTIA authorization function IANA will submit its proposed changes to the Root Zone or the Root Zone Whois database to the NTIA replacement (for the purposes of the Approval Function) for approval in a process that is expected to be similar to what is currently in place.

 

If the DT recommends not replacing the NTIA authorization function, the DT is expected to detail what additional verifications, if any, should be implemented by IANA as a result of removing the NTIA authorization function.

 

If the DT recommends replacing the NTIA authorization function, the DT is expected to propose a draft process for the selection of the replacement(s) that include a list of desired characteristics for the replacement entity.

Proposed Membership

  • At a minimum one gTLD registry representatives with operational knowledge of IANA Functions 
  • At a minimum one ccTLD registry representatives with operational knowledge of IANA Functions 
  • One IANA staff member (current or former)
  • At a minimum one non-direct customer representative with operational knowledge of IANA Functions

Expressions of Interest Received

Danny Younger (At-Large CWG Participant), Jaap Akkerhuis (SSAC Member of the CWG), Milton Mueller (GNSO CWG Participant and ICG Member),David Conrad ( IANA Expertise CWG Participant),  Maarten Simon (ccTLD Registry Representative and CWG Participant),  Jian- Chuang Chang (gTLD Registry Representative)

Proposed by / Lead

Cheryl Langdon-Orr

Staff Support

Bernie Turcotte / Grace Abuhamad

Status

Complete

Determination by CWG Chairs

Priority 1

Mailing list archives

http://mm.icann.org/pipermail/dt5/

 

Design Team E.     

SAC 69

Draft Transition Proposal Reference

Not a direct requirement of the transition proposal

Summary Description

Ensure that proposal is in line with SAC 69

Detailed description

 

Proposed Membership

 

Expressions of Interest Received

Jaap Akkerhuis

Proposed by / Lead

TBC

Status

Complete

Determination by CWG Chairs

As a first step, staff will review the draft transition proposal against SAC69. Based on that review, next steps will be determined.

 

Design Team F.     

Relationship between the NTIA, IANA and the Root Zone Maintainer

Draft Transition Proposal Reference

III.A.1.2.1

Summary Description

The IANA functions contract describes and uses the current tri-party arrangement to get changes to the root zone and its WHOIS database implemented. A revised mechanism for getting these changes implemented post transition will have to be developed assuming that the NTIA is no longer part of the process and that the Root Zone Maintainer, currently Verisign, continues to perform that function.

Detailed description

 

Proposed Membership

 

Proposed by / Lead

Alan Greenberg

Staff Support

Bernie Turcotte / Grace Abuhamad

Expressions of Interest Received

Jaap Akkerhuis, Gary Campbell, Milton Mueller, Rudi Vansnick, Jordan Carter

Status

Provisionally Complete

Determination by CWG Chairs

Priority 1

Mailing list archives

http://mm.icann.org/pipermail/cwg-dtf/

 

Design Team G.  

IANA Intellectual Property Rights, including the IANA Trademark and Domain Name

Draft Transition Proposal Reference

Issue not in transition proposal 2.0

Summary Description

The Number Community has proposed that the IANA trademark and the iana.org domain name be transferred to an independent entity, such as the IETF Trust.   This Design Team will review this proposal and provide a report back to the CWG discussing issues and pros and cons of this proposal and providing a written draft recommendation to the CWG regarding how to deal with this proposal.

 

The Number Community has also stated that it would be preferable if certain data associated with the IANA were in the public domain.   The team would examine this proposal, and would also determine what if any other IPR is involved in the NTIA-IANA relationship.   The team would provide a written draft recommendation regarding these points in a second deliverable.  

Detailed description

The proposal submitted by CRISP on behalf of the Numbers Community contains the following paragraph:

 

With regards to the IANA trademark and the IANA.ORG domain, it is the expectation of the Internet Number Community that both are associated with the IANA Numbering Services and not with a particular IANA Numbering Services Operator. Identifying an organization that is not the IANA Numbering Services Operator and which will permanently hold these assets will facilitate a smooth transition should another operator (or operators) be selected in the future. It is the preference of the Internet Number Community that the IANA trademark and the IANA.ORG domain name be transferred to an entity independent of the IANA Numbering Services Operator, in order to ensure that these assets are used in a non-discriminatory manner for the benefit of the entire community. From the Internet Number Community’s perspective, the IETF Trust would be an acceptable candidate for this role.

 

The ICG has issued a question to the Protocol Parameters Community, asking (in essence) whether this proposal was acceptable.   The Protocol Parameters Community responded that this was not inconsistent with their proposal.   The ICG also issued a question to the IETF Trust, asking whether the IETF would be willing to take on this role.   The IETF Trust responded that it would be willing to do so.   As of today, the ICG has not issued a question to the CWG regarding this proposal.

 

This proposal may raise various operational and legal concerns. It does not appear that the CRISP Team, the ICG or the IETF Trust have examined these concerns.   This Design Team will review this proposal with regard to how it could work and with regard to operational and legal concerns, and will provide a report back to the CWG discussing issues and pros and cons of this proposal and providing a draft recommendation to the CWG regarding how to deal with this proposal.

 

The Number Community has also stated that it would be preferable if certain data associated with the IANA were in the public domain.   The team would examine this proposal, and would also determine what if any other IPR is involved in the NTIA-IANA relationship.   The team would provide a written draft recommendation regarding these points in a second deliverable.

Proposed Membership

NA

Proposed by / Lead

Greg Shatan

Status

Not Needed/Covered elsewhere

Determination by CWG Chairs

Priority 2 -- Chairs recommend that this dealt with through dialogue with other communities, as it is not limited to naming community. Should there be an IPR issue that is naming specific, the CWG would obtain input from the legal advisors. Call has been scheduled with chairs of CRISP team to co-ordinate, not only on this issue but also broader conversations.

 

Design Team H.  

.INT Operations

Draft Transition Proposal Reference

III.A.1.4.1

Summary Description

The contract foresees that the IANA functions operator operates the .INT TLD within the current registration policies for the TLD (act as the registry operator). The contract specifies that ICANN is to “develop and undertake an open process, that will include the current registrants of .INT, to identify a new registry operator and transfer responsibility for the  .INT registry to it. Upon designation of a successor registry operator by the above process, IANA shall cooperate with it to facilitate the smooth transition of operation of the INT TLD. Such cooperation shall, at a minimum, include timely transfer to the successor registry operator of the then-current top-level domain registration data”. With NTIA withdrawing from the IANA Functions Contract the section “upon designation of a successor registry by the Government” would no longer be valid post transition.

Detailed description

 

Proposed Membership

 

Expression of Interests received

Olivier Crepin-Leblond, Andrew Sullivan, Bill Manning, Martin Boyle

Proposed by / Lead

Elise Lindeberg

Status

Not Needed/Covered elsewhere

Determination by CWG Chairs

Priority 2 – Chairs understand that this issue is being dealt with by the GAC.

 

Design Team I.       

Competition policy and Conflicts of Interest

Draft Transition Proposal Reference

III.A.1.3

Summary Description

Without prejudice as to what specific new institutional structure, or none, emerge from the IANA/NTIA transition, the resulting power within the decision-making entities is a relevant consideration. 

At least in Europe and the United States, if not elsewhere, each recent attempt at de-regulation, self-regulation and hands-off public policy has resulted in questionable outcomes, not least in the financial sector, resulting in a global recession. This has inevitably and rightly led to greater scrutiny of the relevant institutions within each sector, including the Internet.

 

Accordingly the Design Team would review, discuss and quickly conclude as to the merits or otherwise of a balanced and independent stakeholder composition of the relevant entities (existing or future).

The Detailed description below illustrates the scope of the issue.

Detailed description

CSC/MRT confidentiality and the perception of conflicts of interest - Developing conflict of interest requirements for the CSC like body. Most discussions have proposed that the membership of a CSC type body have, as a minimum, significant representation from registries. Is this desirable in a context where members of the CSC will be provided with access to information that is confidential and sensitive with respect to all registries?

Detailed description: IANA confidentiality and the perception of conflicts of interest - The oversight manager (MRT?), or a subset (CSC?), could be placed in a privileged position (as is currently the case with NTIA) with respect to accessing IANA performance information, issues with specific requests or security matters. This was not an issue with the NTIA given that it is part of the USG and is not involved in any commercial activities related to the DNS. Transferring this responsibility to representatives of registry operators at a minimum creates the potential for conflict of interest situations in that they could gain access to sensitive or confidential information of their competitors or use their position to negatively influence requests from competitors. The reverse situation is also a concern in that members of the oversight manager if composed of registry representatives could be perceived as being in a potential conflict of interest situation given they could use their position to influence requests from their respective registries. As such the CWG should decide if those individuals that will be responsible for the regular monitoring of IANA performance and interfacing with IANA on a regular basis to discuss and resolve any potential issues or escalating them can be in a conflict of interest position. If the recommendation is to avoid conflict of interests for those individuals it would then be important to decide who should carry out these responsibilities.

Proposed Membership

Convener: Secretariat (ICANN)

Members:

one Large Registrar, owning several gTLDs

one Small gTLD Registry, independent of any Registrar

one ccTLD

one independent Internet user (At Large or equivalent)

one delegate from one GAC member with practical experience in anti- trust/competition policy.

Proposed by / Lead

(Proposer: Christopher Wilkinson)

Status

Not Needed/Covered elsewhere

Determination by CWG Chairs

Priority 2 – Chairs consider that this issue is adequately addressed by DT-C. Furthermore, legal advisors have provided input on antitrust matters. If needed, additional guidance could be sought from the legal advisors concerning best practices governance guidance.

 

Design Team J.       

CSC/MRT confidentiality and the perception of conflicts of interest

Draft Transition Proposal Reference

III.A.1.3

Summary Description

Developing conflict of interest requirements for the CSC like body. Most discussions have proposed that the membership of a CSC type body have, as a minimum, significant representation from registries. Is this desirable in a context where members of the CSC will be provided with access to information that is confidential and sensitive with respect to all registries?

Detailed description

IANA confidentiality and the perception of conflicts of interest -  The oversight manager (MRT?), or a subset (CSC?), could be placed in a privileged position (as is currently the case with NTIA) with respect to accessing IANA performance information, issues with specific requests or security matters. This was not an issue with the NTIA given that it is part of the USG and is not involved in any commercial activities related to the DNS. Transferring this responsibility to representatives of registry operators at a minimum creates the potential for conflict of interest situations in that they could gain access to sensitive or confidential information of their competitors or use their position to negatively influence requests from competitors. The reverse situation is also a concern in that members of the oversight manager if composed of registry representatives could be perceived as being in a potential conflict of interest situation given they could use their position to influence requests from their respective registries. As such the CWG should decide if those individuals that will be responsible for the regular monitoring of IANA performance and interfacing with IANA on a regular basis to discuss and resolve any potential issues or escalating them can be in a conflict of interest position. If the recommendation is to avoid conflict of interests for those individuals it would then be important to decide who should carry out these responsibilities

Proposed Membership

 

Proposed by / Lead

TBC

Status

Not Needed/Covered elsewhere

Determination by CWG Chairs

Priority 2 – Chairs consider that this issue is adequately addressed by DT-C. Furthermore, legal advisors have provided input on antitrust matters. If needed, additional guidance could be sought from the legal advisors concerning best practices governance guidance.

 

Design Team K.    

OFAC Licensing

Draft Transition Proposal Reference

To be added

Summary Description

IANA requires OFAC licensing to operate with certain countries or territories. Would anything change post transition? If so what and how would it be addressed?

Detailed description

 

Proposed Membership

 

Proposed by / Lead

 

Status

Not Needed/Covered elsewhere

Determination by CWG Chairs

Priority 2.
Issue   is   being   dealt   with   by   ICANN   as   a   whole.   Proposed
language   will   be   circulated   that   should   cover   this   commitment.  

 

Design Team L.     

Framework for Transition to Successor IANA Operator

Draft Transition Proposal Reference

III.A.1.1.1

Summary Description

The purpose of Design Team L is to examine existing transition planning documents available within ICANN and IANA and assess their ability to be operationalized and included within the work of the CWG. If documents are found to lack sufficient details DTL will provide additional details around the core concepts that exist to allow the option of separability of the IANA functions to be examined by the CWG.

Detailed description

Design Team L will work in three phases:

 

Phase 1: Acquire and examine existing documentation relating to transition/succession planning of the IANA functions within ICANN. A critique of the suitability of these documents for purpose will be compiled identifying possible weaknesses or areas of concern.

 

These documents will include but are not limited to:

  • IANA Function Contract Section C.7.3 Plan
  • Root Zone KSK Operator Function Termination Plan
  • Contingency and Continuity of Operations Plan

 

Phase 2: Using the documentation examined in Phase 1 as a base, design a detailed and functional transition plan that the team feels will meet the requirements of the ICG as specified in Section III of the RFP : “Description of operational requirements to achieve continuity of service and possible new service integration throughout the transition”

 

Phase 3: Deliver an initial plan back to the CWG and work iteratively on any comments received and any risks or concerns identified until broad consensus has been reached as to the suitability of the new transition plan. At that point the DT may be disbanded.

 

Deliverables:

A peer reviewed and complete transition planning

document examining the following areas:

1. Documentation published on IANA.org

2. IANA Functions registry data

3. Root Zone Automation System

4. Historical Data relating to IANA requests

5. Secure Notification System

6. Root KSK Transition Process

7. IANA Staff Knowledge Transition

8. Management of Transition Process

 

These areas of examination are broadly based on the areas identified in the current IANA functions contract and have been referenced in C.7.3 currently.

 

Timeline:

 

Phase 1 will be dependent on receiving the documents from ICANN as they will all likely be subject to the DIDP process. Phase 1 and 2 will run concurrently as documents are received.

 

Phase 2 will be broken down further into specific bodies of work relating to the various areas of the IANA functions. The work on each of these areas will be reported back on a weekly basis to the CWG on one (Or more as required) of the standing CWG calls.

 

Note that CWG and DTL are competent for the naming aspects of the transition. The numbering and protocol areas of the IANA functions have already been addressed by the corresponding stakeholders. (RIR’s, IETF). DTL will not be addressing aspects other than naming.

 

Phase 3 will be iterative depending on the volume of comments received and/or risks identified and cannot be estimated at this time however it will be planned taking into account the overall timeline of the CWG when refining the transition plan.

 

Working Methods :

 

The team will work primarily from the DTL Mailing List located at https://mm.icann.org/mailman/listinfo/dt4.

The team may request the use of the Adobe Connect conferencing system to facilitate discussion, this may particularly be required prior to presenting work to the

CWG and during the inclusion of comments in Phase 3.

 

If the members of the DT encounter an issue that requires legal input or analysis a set of questions will be prepared for the Client Committee and will be delivered by the DT Lead to a designated representative of the Client Committee, It should be noted due to the technical nature of the DT it will not be expected that extensive legal issues will be encountered.

Proposed Membership

Current membership:

  • James Gannon
  • Guru Acharya
  • Matthew Shears
  • Christopher Wilkinson
  • Jaap Akkerhuis
  • Allan MacGillivray

Members of DTL will have experience in transition planning and/or expertise in one of the functional or related areas that the transition plan will examine.

Expressions of Interest Received

Jaap Akkerhuis, James Gannon, Guru Acharya, Matthew Shears, Christopher Wilkinson, Allan MacGillivray, Graeme Bunton

Proposed by / Lead

James Gannon (replaced by Matt Shears)

Staff Support

Grace Abuhamad / Marika Konings

Status

Complete

Determination by CWG Chairs

Priority 1 (Provisional)

Mailing list archives

http://mm.icann.org/pipermail/dt4/

 

Design Team M.  

Escalation Mechanisms

Draft Transition Proposal Reference

III.A.1.1.2

Summary Description

Note:  there were no formal escalation mechanisms described in the IANA Functions Contract for the NTIA any new arrangement will require these.

 

The purpose of this DT is to develop a set of escalation mechanisms for any cases where IANA naming services fail to meet the responsibilities to its direct customers both on a case by case basis and on a trending basis.

Detailed description

The design team is expected to propose a progressive set of escalation steps that can be performed as applicable by individual ccTLD or gTLD registry operators, registry organizations  such as the ccNSO and RySG, the Customer Standing Committee (CSC) and any other TLD related entity that may be part of the final CWG IANA proposal for the IANA Stewardship Transition.  The steps may address but not be limited to any or all of the following:

a)        What can an individual registry operator do if IANA service is not provided in a timely and/or satisfactory manner (e.g., if SLEs are not met)?

b)        What can be done if there are multiple instances of untimely and or unsatisfactory IANA naming services?

c)        What role, if any, can existing registry organizations such as the ICANN ccNSO or the ICANN gTLD Registries Stakeholder Group (RySG) have in escalating IANA naming services problems?

d)       What role should the CSC play in the escalation process for IANA name services problems?

e)        If IANA naming services problems cannot be solved at the CSC level, how and to whom should the problem be escalated?

f)         What role, if any, do the other SOAC have in escalating IANA name services issues?

 

Additionally, the design team is expected to identify any areas that may require coordination with the CCWG and describe how that coordination should happen?

 

Finally, the design team should collaborate with DT-A (SLEs), DT-C (CSC) and any other DTs that may deal with escalation mechanisms to synchronize its recommendations with the work of those DTs.

Proposed Membership

  • At a minimum two gTLD registry representatives with operational knowledge of IANA Functions
  • At a minimum two ccTLD registry representatives with operational knowledge of IANA Functions
  • One IANA staff member (current or former)
  • One non-direct customer representative with operational knowledge of IANA Functions

Expressions of Interest received

Avri Doria, Staffan Jonson, Erick Iriarte

Proposed by / Lead

The first draft of this was prepared by Chuck Gomes; Chuck is willing to serve as Lead but is also willing to serve as a participant if someone else wants to be the Lead.

Staff Support

Marika Konings / Berry Cobb

Status

Complete

Determination by CWG Chairs

Priority 1

Mailing list archives

http://mm.icann.org/pipermail/dt6/

 

Design Team N.  

Periodic Review of the IANA Functions

Draft Transition Proposal Reference

III.A.1.4

Summary Description

Regardless of the model selected to implement the transition the IANA Function, including the SOW, will have to be reviewed on a regular basis.

The SOW review  requirement brings on several additional requirements:

         What period (duration) should be covered by the first SOW post transition?

         What should be the standard period for reviewing SOWs post transition?

         What should be the process for reviewing or amending SOWS (including approval by the community and acceptance by ICANN)?

The current definition and operational parameters (including the format of request and reporting requirements) for these functions in the IANA Functions contract and IANA Response have to be reviewed to ensure they meet all the post transition requirements.

 

Additional issues to be covered includes defining the reviews that may be needed of IANA Function beyond what is defined in the SOW. The substance of other reviews would need to be defined in other DT efforts.

Detailed description

Consideration of the various reviews and how these reviews and their schedules interact with each other.

 

Considerations that need to be included in the considerations of the SOW review length include:

  • What is a sufficient length to avoid the thrash of constant SOW review?
  • What would be so long as to create too much of a status quo assumption?

 

Considerations on the standard period for a SOW review include:

  • Is the SOW reviewed at intermediate stages or just on reconsideration of the SOW
  • Is a regular period, like yearly, necessary? If so, what is the periodicity?

 

What other reviews need to be carried out as the overall review of the IANA function?

  • What is being reviewed
  • Where is it defined?
  • How often

 

Consideration on process for all reviews and renewal include:

  • Who are the relevant stakeholders?
  • What sort of process structure is warranted?
  • Do periodic reviews of  the various definition of the IANA Function, including the SOW, have a different structure from each other  and from a review for renewal?
  • What are the objective issues any such review should take up?
  • How is the wider community involved in such a review?
  • Is it done by a standing committee of some sort (for example the MRT or any of its model  based analogues) or a team built for purpose like an ICG or CWG.

Proposed Membership

 

Expressions of Interest Received

Matthew Shears, Alan Greenberg, Stephanie Duchesneau, Greg Shatan, Jordan Carter

Proposed by / Lead

Avri Doria

Staff Support

Grace Abuhamad / Marika Konings

Status

Complete

Determination by CWG Chairs

Priority 1 (Provisional)

Mailing list archives

http://mm.icann.org/pipermail/dt7/

 

Design Team O.  

IANA Budget Reporting

Draft Transition Proposal Reference

None

Summary Description

Consider CWG requirements in relation to IANA budget reporting (which could potentially be transmitted to CCWG?)

Detailed description

(see Wiki)

Proposed Membership

Cheryl Langdon-Orr; Olivier Crepin Leblond; Alan Greenberg; Chuck Gomes; Mary Uduma; Vika Mpisane

Proposed by / Lead

Chuck Gomes

Staff Support

Grace Abuhamad

Status

Complete

Determination by CWG Chairs

Priority 1 (Provisional)

Mailing list archives

http://mm.icann.org/pipermail/dto/

 

 

Red Team

Draft Transition Proposal Reference

IV

Summary Description

To examine whether there are any issues with respect to meeting NTIA's criteria, particularly with respect to security and stability and prevention of capture. This is a particular form of stress testing

Detailed description

 

Proposed Membership

Siva Muthusamy

Proposed by / Lead

Matthew Shears

Staff Support

Grace Abuhamad

Status

Step 0

Determination by CWG Chairs

To be addressed as a committee of the whole CWG


Annex A – DT Step-by-step process

 

CWG IANA Stewardship Transition

Step-by-Step Process for a CWG Design Team

Step 0

Issue identified

Step 1

Proponent / Lead completes the template (see Annex I) with all of the minimum required information; proposed title, summary description, detailed description, proposed membership (description of expertise required, e.g. ccTLD registry rep, technical expert) and reference to relevant section of the draft transition proposal

Step 2

Proponent / Lead submits the completed template to the CWG mailing list

Step 3

Co-Chairs of CWG review template for completeness and may ask proponent / lead for additional details prior to further review

Step 4

Co-Chairs of CWG to review proposal within two working days of receiving the proposal, taking into account any comments or suggestions that may have been received on the CWG mailing list in response to the DT proposal

Step 5

Co-Chairs of the CWG share their recommendation on whether to proceed with the DT or reject the DT proposal stating their rationale for doing so with the CWG

Step 6

If the recommendation is to proceed with the DT, the Co-Chairs will assign the DT a priority from 1 to 3, where 1 is the highest level

Step 7

Priority 1 recommendations will move forward to a call for volunteers. Call for volunteers will close after two working days (23.59 UTC of the second working day)

Step 8

Volunteers for the DT are expected to share their Statement of Interest (SOI) or provide a link to the existing SOI as well as their qualification for the DT with the CWG mailing list (SOIs will also be linked on the Wiki)

Step 9

The Co-Chairs, in co-ordination with the DT Lead, will review the volunteers that have come forward and determine the membership of the DT, ensuring sufficient expertise and a balanced membership (Note: a DT should typically involve at least 5 participants, but not more than 7)

Step 10

The DT will be convened by the DT Lead as soon as possible to commence its deliberations and is expected to report back to the full CWG on a regular basis (at least once a week, during a full CWG call).

Step 11

The DT will submit proposed language for inclusion in the relevant section of the draft transition proposal, for review by the CWG, ideally within 2 weeks from start

Step 12

If generally accepted by the CWG, the agreed language will be included into the transition proposal and the DT decommissioned (unless there are other linked tasks that need to be completed)

 


[1] See Annex 1 for DT step-by-step process

 

 

 

  • No labels