[CWG-Stewardship] [IANA-issues] Fwd: Names Community vs the other two communities

Thu Oct 30 15:16:20 UTC 2014

Becky,

Thank you for the email and laying out the processes defined in the IANA functions contract. Good that you remind us that the existing technical/ operational processes work well now. 

The challenge is adding accountability, which is the non-technical oversight role that NTIA can exert over ICANN now. 

Robert

> On Oct 29, 2014, at 1:16 PM, Burr, Becky <Becky.Burr at neustar.biz> wrote:
> 
> 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 a 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 management 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 Keyset.  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 and includes a reasonable timeframe 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 maintain 24 hour-a-day/7 days-a-week operational coverage.
> 
> 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 at neustar.biz <mailto:becky.burr at neustar.biz> / www.neustar.biz <http://www.neustar.biz/>
> 
> From: Olivier MJ Crepin-Leblond <ocl at gih.com <mailto:ocl at gih.com>>
> Date: Wednesday, October 29, 2014 at 11:50 AM
> To: "cwg-stewardship at icann.org <mailto:cwg-stewardship at icann.org>" <cwg-stewardship at icann.org <mailto:cwg-stewardship at 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 at neustar.biz <mailto:becky.burr at neustar.biz> / www.neustar.biz <http://www.neustar.biz/>
>> 
>> From: Guru Acharya <gurcharya at gmail.com <mailto:gurcharya at gmail.com>>
>> Date: Wednesday, October 29, 2014 at 9:35 AM
>> To: Allan MacGillivray <allan.macgillivray at cira.ca <mailto:allan.macgillivray at cira.ca>>
>> Cc: Becky Burr <becky.burr at neustar.biz <mailto:becky.burr at neustar.biz>>, "cwg-stewardship at icann.org <mailto:cwg-stewardship at icann.org>" <cwg-stewardship at icann.org <mailto:cwg-stewardship at icann.org>>, "Lindeberg, Elise" <elise.lindeberg at npt.no <mailto:elise.lindeberg at 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 at cira.ca <mailto:allan.macgillivray at 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 at icann.org <mailto:cwg-stewardship-bounces at icann.org> [mailto:cwg-stewardship-bounces at icann.org <mailto:cwg-stewardship-bounces at icann.org>] On Behalf Of Guru Acharya
>>> Sent: October-29-14 8:32 AM
>>> To: Becky Burr
>>> Cc: cwg-stewardship at icann.org <mailto:cwg-stewardship at 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 at neustar.biz <mailto:Becky.Burr at 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 at icann.org <mailto:CWG-Stewardship at icann.org>https://mm.icann.org/mailman/listinfo/cwg-stewardship <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_cwg-2Dstewardship&d=AAMF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=TdVuaup5FYNO7Kbzw-WeiPL40WR6uQHvHCZH8wY06S4&s=yoOCQp_8bldp5dAaRtsRf1G1SnLtkZg7UeOAZjWdPj8&e=>
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org <mailto:CWG-Stewardship at icann.org>
> https://mm.icann.org/mailman/listinfo/cwg-stewardship <https://mm.icann.org/mailman/listinfo/cwg-stewardship>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141030/3bb73eca/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141030/3bb73eca/smime-0001.p7s>