Sorry, formatting was odd, so resending

Olivier,

 

Thanks for this input.  I’d like to take a step back so that we are all on the same page.  I hope everyone with take the time to review this post.  I think we are making this work unnecessarily complicated.

 

Under the straw man I’ve suggested the “Council” or “Body” or whatever it is called is responsible for negotiating and interacting with IANA on technical issues.  As defined by the IANA functions contract, IANA’s naming-related tasks include the following:

 

Root Zone File Change Request Management— The Contractor shall receive and process root zone file change requests for TLDs as expeditiously as possible.  This does not include a policy role at all.  A new TLD is entered into the root only after the ICANN Board directs IANA to do that.  Policy remains in ICANN, not the IANA function.

 

Root Zone “WHOIS” Change Request and Database Management –The Contractor shall maintain, update, and make publicly accessible a Root Zone “WHOIS” database with current and verified contact information for all TLD registry operators.  Again, this involves no policy role.  ICANN makes policy on WHOIS, not IANA.  IANA just follows ICANN’s orders.

 

Delegation and Redelegation of Generic TLDs and Country Code TLDs.  Again, the role is administrative and not policy making.  IANA adds or removes a TLD from the root only at the direction of the ICANN Board.  It is responsible for documenting that the action was consistent with established ICANN policy, but has no role in formulating that policy.

 

Root Zone Automation--The Contractor shall work with NTIA and the Root Zone Maintainer, and collaborate with all interested and affected parties to deploy a fully automated root zone managements system.  This is an administrative/operations task, not a policy task.

 

Root Domain Name System Security Extensions (DNSSEC) Key Management—The Contractor shall be responsible for the management of the root zone Key Signing Key (KSK), including generation, publication, and use for signing the Root Key set.  Again, DNSSEC policy is set by ICANN, informed by all stakeholders, the SSAC, etc.  IANA simply administers the ICANN policy.

 

Customer Service Complaint Resolution Process (CSCRP)—The Contractor shall work with NTIA and collaborate with all interested and affected parties to establish and implement a process for IANA function customers to submit complaints for timely resolution that follows industry best practice a and includes a reasonable time frame for resolution.  This relates to complaints about IANA doing its technical job in a timely and competent fashion, not policy, which remains with ICANN.

 

Perform Administrative Functions Associated With Root Zone Management.  Facilitate and coordinate the root zone of the domain name system, and maintain24 hour-a-day/7days-a-weekoperationalcoverage.

 

I would agree with you that a conflict of interest could emerge if IANA was developing policies for the registries, but that is not what’s being proposed.  Rather, all policy work would remain with ICANN subject to multi-stakeholder processes – just as it is now.   What conflict of interest arises in this situation?  Registries will be in the best position to know whether or not IANA is processing name server changes in a timely fashion.  Registries are harmed if it takes forever to do that.  To the limited extent this kind of thing might impact end users, registries have all of the necessary incentives to get it fixed.  In the early years of ICANN, when IANA was performing very poorly, registries were unhappy, but most of the rest of the ICANN community was not impacted in any way.  Today, the ICANN board - NOT IANA - promises stakeholders that IANA will do its work in accordance with ICANN policy.  If it doesn't, I am going to look to the ICANN Board and not the IANA staff for redress.   

 

I don’t see a conflict of interest in registries performing an oversight role with respect to IANA’s purely technical and operational functions.  Remember, the IANA function contract specifies that IANA’s role is technical and operational, not policy development.  If IANA does something that is inconsistent with ICANN policy, I want the ICANN Board to be accountable.   

 

Again, to be clear, I am not unalterably opposed to having other parts of the community participate, but I don’t understand why they would want to.

 

Becky

J. Beckwith Burr

Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer

1775 Pennsylvania Avenue NW, Washington, DC 20006

Office: + 1.202.533.2932  Mobile:  +1.202.352.6367  / becky.burr@neustar.biz / www.neustar.biz


From: <Burr>, Becky Burr <becky.burr@neustar.biz>
Date: Wednesday, October 29, 2014 at 1:16 PM
To: Olivier MJ Crepin-Leblond <ocl@gih.com>, "cwg-stewardship@icann.org" <cwg-stewardship@icann.org>
Subject: Re: [CWG-Stewardship] [IANA-issues] Fwd: Names Community vs the other two communities

Olivier,

Thanks for this input.  I’d like to take a step back so that we are all on the same page.  I hope everyone with take the time to review this post.  I think we are making this work unnecessarily complicated.

Under the straw man I’ve suggested the “Council” or “Body” or whatever it is called is responsible for negotiating and interacting with IANA on technical issues.  As defined by the IANA functions contract, IANA’s naming-related  tasks include the following:

  1. RootZone FileChangeRequestManagement-- TheContractorshallreceiveandprocessrootzonefile changerequests forTLDsas expeditiouslyas possible.  This does not include a policy role at all.  A new TLD is entered into the root only after the ICANN Board directs IANA to do that.  Policy remains in ICANN, not the IANA function.
  2. RootZone“WHOIS”ChangeRequestandDatabaseManagement --TheContractorshallmaintain,update,and make publiclyaccessible aRootZone“WHOIS”databasewithcurrentand verifiedcontact informationforallTLD registryoperators.  Again, this involves no policy role.  ICANN makes policy on WHOIS, not IANA.  IANA just follows ICANN’s orders.
  3. DelegationandRedelegationofa Generic TLDs and CountryCode TLDs.  Again, the role is administrative and not policy making.  IANA adds or removes a TLD from the root only at the direction of the ICANN Board.  It is responsible for documenting that the action was consistent with established ICANN policy, but has no role in formulating that policy.
  4. RootZone Automation--The Contractor shallworkwithNTIA andtheRootZoneMaintainer,and collaboratewithall interestedandaffectedparties todeploya fullyautomated rootzonemanagementsystem.  This is an administrative/operations task, not a policy task.
  5. RootDomainNameSystemSecurityExtensions(DNSSEC)Key Management--TheContractorshallbe responsiblefor themanagementof the rootzoneKey SigningKey(KSK),includinggeneration,publication,andusefor signingthe RootKeyset.  Again,  DNSSEC policy is set by ICANN, informed by all stakeholders, the SSAC, etc.  IANA simply administers the ICANN policy.
  6. CustomerServiceComplaintResolutionProcess(CSCRP)--TheContractorshallworkwithNTIAand collaboratewithallinterestedandaffectedpartiestoestablishandimplementaprocessforIANAfunctioncustomerstosubmitcomplaintsfortimelyresolutionthatfollows industrybestpracticeandincludesareasonabletimeframeforresolution.  This relates to complaints about IANA doing its technical job in a timely and competent fashion, not policy, which remains with ICANN.
  7. PerformAdministrativeFunctionsAssociatedWith RootZoneManagement.  Facilitateand coordinatetherootzone ofthedomainnamesystem,and maintain24 hour-a-day/7days-a-weekoperationalcoverage.

I would agree with you that a conflict of interest could emerge if IANA was developing policies for the registries, but that is not what’s being proposed.  Rather, all policy work would remain with ICANN subject to multi-stakeholder processes – just as it is now.   What conflict of interest arises in this situation?  Registries will be in the best position to know whether or not IANA is processing name server changes in a timely fashion.  Registries are harmed if it takes forever to do that.  To the limited extent this kind of thing might impact end users, registries have all of the necessary incentives to get it fixed.  In the early years of ICANN, when IANA was performing very poorly, registries were unhappy, but most of the rest of the ICANN community was not impacted in any way.  Today, the ICANN board - NOT IANA - promises stakeholders that IANA will do its work in accordance with ICANN policy.  If it doesn't,  I am going to look to the ICANN Board and not the IANA staff for redress.   

I don’t see a conflict of interest in registries performing an oversight role with respect to IANA’s purely technical and operational functions.  Remember, the IANA function contract specifies that IANA’s role is technical and operational, not policy development.  If IANA does something that is inconsistent with ICANN policy, I want the ICANN Board to be accountable.   

Again, to be clear, I am not unalterably opposed to having other parts of the community participate, but I don’t understand why they would want to.   



J. Beckwith Burr

Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer

1775 Pennsylvania Avenue NW, Washington, DC 20006

Office: + 1.202.533.2932  Mobile:  +1.202.352.6367  / becky.burr@neustar.biz / www.neustar.biz


From: Olivier MJ Crepin-Leblond <ocl@gih.com>
Date: Wednesday, October 29, 2014 at 11:50 AM
To: "cwg-stewardship@icann.org" <cwg-stewardship@icann.org>
Subject: Re: [CWG-Stewardship] [IANA-issues] Fwd: Names Community vs the other two communities

Hello all,

irrespective of whether an "Oversight Council" is a desirable thing or not (I have not yet made up my mind about this, only having very basic information about it), I see a serious conflict of Interest where only the directly affected parties oversee operations that concern them directly.
There was much discussion about the GAC having seats. Although I have not asked them, I am pretty much sure that end users, as affected parties, would need a number of seats too.

Kind regards,

Olivier

On 29/10/2014 14:33, Burr, Becky wrote:
I’d envisioned the “Oversight Council” to be elected by registries (ccs and gs) organized in some fashion outside of the ICANN umbrella – so the IANA Oversight Inc. or other association we were talking about the other day.  It seems to me that the duties and authority of the Council would be determined by the membership of the organization (I.e., the registries) – so these questions would be resolved as part of structuring Oversight, Inc.  Let’s not create yet another separate mechanism.  Instead, figure out a way for the views of all stakeholders with respect to major decisions can be collected by Oversight, Inc. and taken into account in the process of developing major proposals.  


J. Beckwith Burr

Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer

1775 Pennsylvania Avenue NW, Washington, DC 20006

Office: + 1.202.533.2932  Mobile:  +1.202.352.6367  / becky.burr@neustar.biz / www.neustar.biz


From: Guru Acharya <gurcharya@gmail.com>
Date: Wednesday, October 29, 2014 at 9:35 AM
To: Allan MacGillivray <allan.macgillivray@cira.ca>
Cc: Becky Burr <becky.burr@neustar.biz>, "cwg-stewardship@icann.org" <cwg-stewardship@icann.org>, "Lindeberg, Elise" <elise.lindeberg@npt.no>
Subject: Re: [CWG-Stewardship] [IANA-issues] Fwd: Names Community vs the other two communities

Postulates emerging from Allan's remarks:

The Oversight Council will monitor compliance with day to day technical SLA type requirements.

Even though the final contracting authority of changing the IANA operator will rest with the Oversight Council:

1) There will be a "separate mechanism" for recommending any major decision to the Oversight Council, including change of IANA operator

2) The Oversight Council will be bound to accept/implement the decision of the "separate mechanism". 

3) That "separate mechanism" will necessarily involve the views of the GAC.

4) That "separate mechanism" will be at an arms length from ICANN so that the ICANN board can not interfere since ICANN is the present IANA operator.

How do we intend to codify these characteristics of the "separate mechanism" so that the GAC can be assured that they will be consulted in case of change of the IANA operator? Maybe as part of a MOU between the Oversight Council and GAC+ALAC+GNSO+CCSNO?



On Wed, Oct 29, 2014 at 6:32 PM, Allan MacGillivray <allan.macgillivray@cira.ca> wrote:

I see the “oversight council” as being a body that deals with IANA compliance with day-to-day SLA-type responsibilities e.g. the current performance metric that 80% of root zone file and WHOIS database change requests be completed within 21 days.  I would not expect that governments (other than those that are ccTLD operators) would have much interest in this. However, were there to be major review of these functions, such as that which the NTIA initiated in 2011 with its NOI, or to change the operator, then I would expect that the responsibility for conducting such a review would not fall on the ‘oversight council’ alone and that in whatever mechanism that would be established, there could be a role for governments.

 

 

From:cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Guru Acharya
Sent: October-29-14 8:32 AM
To: Becky Burr
Cc: cwg-stewardship@icann.org; Lindeberg, Elise
Subject: Re: [CWG-Stewardship] [IANA-issues] Fwd: Names Community vs the other two communities

 

Becky. I agree with your initial assessment that the "oversight council" would focus on "technical and operational issues" (as opposed to policy issues); and therefore GAC participation in the council will not be required even though GAC participation at an equal footing will not be inconsistent with the multi-stakeholder model. 

 

However, I think GAC participation in the council might be essential in the scenario where the oversight council decides to change the IANA operator in the future. If the council decides to contract a different operator (different from ICANN) in the future, would it not lead to various policy issues such as jurisdiction of the new IANA operator, financing of the new IANA operator etc - where the insight of the GAC may be beneficial?

 

Therefore I think GAC should be a part of the oversight council.

 

Regards,

Guru

 

On Tue, Oct 28, 2014 at 8:47 PM, Burr, Becky <Becky.Burr@neustar.biz> wrote:

Thanks Elise, very helpful.  I was thinking that the “oversight counsel” would focus on technical and operational issues as opposed to policy issues ... But policy for IANA would remain in existing ICANN processes.  Could you help me understand which technical/operational IANA services might raise “public interest” concerns?  I agree with you that having some GAC reps on a Oversight Counsel would not be inconsistent with the Strickling view, but I am curious about why GAC might want to participate in that kind of counsel. 

 




_______________________________________________
CWG-Stewardship mailing list
CWG-Stewardship@icann.orghttps://mm.icann.org/mailman/listinfo/cwg-stewardship