On Oct 31, 2014, at 8:17 AM, Avri Doria <avri@acm.org> wrote:
Hi,
I find this sort of setup appealing if we decide that there must be a standing oversight, something I am still not sure about. It seems far better than a setup controlled by registries. Focusing on necessary skill set instead of client with vested interest makes good sense.
If we want to explore the .nz example some further, it might be good to hear more about the history - issues/disputes, how issues have been resolved and what if any enforcement mechanisms are possible.
I see no reason why it shouldn't scale, what are the scaling factors that make you think it might not? there are almost alwasy fewer names at the top level than at even the smallest 2nd level.
More staff and likely more issues involved at IANA vs. NZ. Yes, less names.. Robert
On 31-Oct-14 00:24, Robert Guerra wrote:
Joy,
Thanks for sharing the experience in .nz. Curious to hear from others if the example from NZ could scale to what we have in mind for the IANA transition.
Robert
On Oct 29, 2014, at 6:31 PM, joy <joy@apc.org> <mailto:joy@apc.org> wrote:
hi all In .nz I have direct experience of structures developed for handoff oversight of an SLA negotiated with a single shared registry service. The oversight function is by a small board of directors (which until recently I chaired) on which no registries or registrars are represented. Instead, a small group of persons with the skills needed to oversee the function in the public interest do so - there are no government persons . It used to be called the .nz Oversight Committee, but is now the Domain Name Commission Limited (a charitable public interest company). There is a separate registrar advisory committee. of course, it is a small and discrete example, but it works and works well. My point, is that an oversight committee can operate to ensure day to day oversight of a technical SLA. To do so, it's important to focus on the skills the oversight function needs, not simply the stakeholders it can represent or the clients it might serve.
Regards
Joy Liddicoat
On 30/10/2014 6:16 a.m., Burr, Becky 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 Contractorshall receive and process root zone file change requests for TLDs asexpeditiously 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 DatabaseManagement -- 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 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. Root Zone Automation -- The Contractor shall work with NTIA andthe Root Zone Maintainer, and collaborate with all interested andaffected parties to deploy a fully automated root zone managementsystem. This is an administrative/operations task, not a policy task. Root Domain Name System Security Extensions (DNSSEC) KeyManagement --The Contractor shall be responsible for themanagement of the root zone Key Signing Key (KSK), includinggeneration, 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) --TheContractor shall work with NTIA and collaborate with all interestedand affected parties to establish and implement a process for IANAfunction customers to submit complaints for timely resolution thatfollows industry best practice and includes a reasonable timeframefor 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 ZoneManagement. Facilitate and coordinate the root zone of the domainname system, and maintain 24 hour-a-day/7 days-a-weekoperational 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 t! he 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 <mailto:becky.burr@neustar.biz> <mailto:becky.burr@neustar.biz> <mailto:becky.burr@neustar.biz> / www.neustar.biz <http://www.neustar.biz/> <http://www.neustar.biz/> <http://www.neustar.biz/>
From: Olivier MJ Crepin-Leblond <ocl@gih.com <mailto:ocl@gih.com> <mailto:ocl@gih.com> <mailto:ocl@gih.com>> Date: Wednesday, October 29, 2014 at 11:50 AM To: "cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> <mailto:cwg-stewardship@icann.org> <mailto:cwg-stewardship@icann.org>" <cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> <mailto:cwg-stewardship@icann.org> <mailto: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 <mailto:becky.burr@neustar.biz> <mailto:becky.burr@neustar.biz> <mailto:becky.burr@neustar.biz> / www.neustar.biz <http://www.neustar.biz/> <http://www.neustar.biz/> <http://www.neustar.biz/>
From: Guru Acharya <gurcharya@gmail.com <mailto:gurcharya@gmail.com> <mailto:gurcharya@gmail.com> <mailto:gurcharya@gmail.com>> Date: Wednesday, October 29, 2014 at 9:35 AM To: Allan MacGillivray <allan.macgillivray@cira.ca <mailto:allan.macgillivray@cira.ca> <mailto:allan.macgillivray@cira.ca> <mailto:allan.macgillivray@cira.ca>> Cc: Becky Burr <becky.burr@neustar.biz <mailto:becky.burr@neustar.biz> <mailto:becky.burr@neustar.biz> <mailto:becky.burr@neustar.biz>>, "cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> <mailto:cwg-stewardship@icann.org> <mailto:cwg-stewardship@icann.org>" <cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> <mailto:cwg-stewardship@icann.org> <mailto:cwg-stewardship@icann.org>>, "Lindeberg, Elise" <elise.lindeberg@npt.no <mailto:elise.lindeberg@npt.no> <mailto:elise.lindeberg@npt.no> <mailto: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 <mailto:allan.macgillivray@cira.ca> <mailto:allan.macgillivray@cira.ca> <mailto: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:From:cwg-stewardship-bounces@icann.org> <mailto:cwg-stewardship-bounces@icann.org> <mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org <mailto:cwg-stewardship-bounces@icann.org> <mailto: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 <mailto:cwg-stewardship@icann.org> <mailto:cwg-stewardship@icann.org> <mailto: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 <mailto:Becky.Burr@neustar.biz> <mailto:Becky.Burr@neustar.biz> <mailto: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.org <mailto:CWG-Stewardship@icann.org> <mailto:CWG-Stewardship@icann.org> <mailto:CWG-Stewardship@icann.org>https://mm.icann.org/mailman/listinfo/cwg-stewardship <https://mm.icann.org/mailman/listinfo/cwg-stewardship> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li... 1G1SnLtk Zg7UeOAZjWdPj8&e=> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...>
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> <mailto:CWG-Stewardship@icann.org> <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship <https://mm.icann.org/mailman/listinfo/cwg-stewardship> <https://mm.icann.org/mailman/listinfo/cwg-stewardship> <https://mm.icann.org/mailman/listinfo/cwg-stewardship>
CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> <mailto:CWG-Stewardship@icann.org> <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship <https://mm.icann.org/mailman/listinfo/cwg-stewardship> <https://mm.icann.org/mailman/listinfo/cwg-stewardship> <https://mm.icann.org/mailman/listinfo/cwg-stewardship>
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship <https://mm.icann.org/mailman/listinfo/cwg-stewardship>
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship