[CWG-Stewardship] [IANA-issues] Fwd: Names Community vs the other two communities
Seun Ojedeji
seun.ojedeji at gmail.com
Wed Oct 29 21:23:22 UTC 2014
On Wed, Oct 29, 2014 at 6:39 PM, Burr, Becky <Becky.Burr at neustar.biz> wrote:
> 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.
>
Hmm...technical issue? so its assumed that the members of the council will
be technical folks right? or the council members will further employ people
to do their review? (Because i am positive that Larry of NTIA may not
necessarily be technical enough to follow-up with the terms of the
contract. However their oversight has been smooth because NTIA has access
to resources to get as much personnel as required)
> As defined by the IANA functions contract, IANA’s naming-related tasks
> include the following:
>
<snipped the functions>
And you don't think the community within ICANN can also perform those
functions?....isn't what we are doing right now a sample? wouldn't setting
up a cwg for this purpose achieve the same goal
>
>
> 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?
>
Multi-stakeholder group that also consist of the registries right.
Proposing a council consisting registries alone already create another
layer of decision making which generally means that the registries can
wake-up one day and decide that ICANN is not doing fine (since they are
presumably the contractor). How does the community's view get to influence
such decision making? Also recall that the transition by NTIA requirement
indicated that the role be transferred to multi-stakeholder and i don't
think the registry alone will fit such description.
> 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.
>
Well if they are then, they should raise it as a member of the community,
again performing this role should not make the registries the contractor;
they don't have to be a contractor to know/do this.
> I don’t see a conflict of interest in registries performing an oversight
> role with respect to IANA’s purely technical and operational functions.
>
Again i have no problem with them doing this, but i have a problem when i
don't have the opportunity to be part of the decision making (as an
end-user for instance).
> 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.
>
I think even an end-user who is involved in the process will detect this,
its not overly technical to know when something is going wrong.
>
>
> 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.
>
They want to because they utilise the names resources. Perhaps i should
refer to the numbers world where the oversight rest on community as much as
possible(does not mean there is no room for improvement). I think such
would be desired for the names world. Getting the registries to become the
contractor and then the same registries participate in the policy process
(with others) already is an indication of probable conflict in near future.
There is also the aspect of who determines the members of the council.
Registries are not fairly distribute accross regions, so how will that be
resolved to ensure there is fairness of representation. Who funds the
council to perform its operations? these are all questions that could help
us appreciate that we may be heading to creating a political council and
not necessarily a technical council
Regards
>
>
> 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 at neustar.biz / www.neustar.biz
>
> From: <Burr>, Becky Burr <becky.burr at neustar.biz>
> Date: Wednesday, October 29, 2014 at 1:16 PM
> To: Olivier MJ Crepin-Leblond <ocl at gih.com>, "cwg-stewardship at icann.org" <
> cwg-stewardship at 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-- *TheContractorshallreceive
> andprocessrootzonefile 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. *Root**Zone“WHOIS”ChangeRequestandDatabaseManagement --*The
> Contractorshallmaintain,update,and make publiclyaccessible aRootZone“
> WHOIS”databasewithcurrentand verifiedcontact informationforallTLD r
> egistryoperators. Again, this involves no policy role. ICANN makes
> policy on WHOIS, not IANA. IANA just follows ICANN’s orders.
> 3. *DelegationandRedelegation**ofa 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 andtheRoot
> ZoneMaintainer,and collaboratewithall interestedandaffectedparties to
> deploya fullyautomated rootzonemanagementsystem. This is an
> administrative/operations task, not a policy task.
> 5. *RootDomainNameSystemSecurityExtensions(DNSSEC)Key Management--*The
> Contractorshallbe 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)--*TheContractor
> shallworkwithNTIAand collaboratewithallinterestedandaffectedpartiesto
> establishandimplementaprocessforIANAfunctioncustomerstosubmitcomplaints
> fortimelyresolutionthatfollows industrybestpracticeandincludesa
> reasonabletimeframeforresolution. 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.
> F*acilitateand 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 at neustar.biz / www.neustar.biz
>
> From: Olivier MJ Crepin-Leblond <ocl at gih.com>
> Date: Wednesday, October 29, 2014 at 11:50 AM
> To: "cwg-stewardship at icann.org" <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 / www.neustar.biz
>
> From: Guru Acharya <gurcharya at gmail.com>
> Date: Wednesday, October 29, 2014 at 9:35 AM
> To: Allan MacGillivray <allan.macgillivray at cira.ca>
> Cc: Becky Burr <becky.burr at neustar.biz>, "cwg-stewardship at icann.org" <
> cwg-stewardship at icann.org>, "Lindeberg, Elise" <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> 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] *On Behalf Of *Guru Acharya
>> *Sent:* October-29-14 8:32 AM
>> *To:* Becky Burr
>> *Cc:* 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>
>> 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 listCWG-Stewardship at icann.orghttps://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
> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>
>
--
------------------------------------------------------------------------
*Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng
<http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email:
<http://goog_1872880453>seun.ojedeji at fuoye.edu.ng
<seun.ojedeji at fuoye.edu.ng>*
The key to understanding is humility - my view !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141029/60fb53d7/attachment-0001.html>
More information about the CWG-Stewardship
mailing list