[CWG-RFP3] Policy authority

Guru Acharya gurcharya at gmail.com
Tue Nov 18 08:51:52 UTC 2014


Excellent point Malcolm.

I think this also raises an issue of recursiveness. If the members of the
Oversight Body are drawn from ICANN's (the incumbent Policy Authority)
organisational structures (SO/AC), and this Oversight Body chooses to
change the Policy Authority in the IANA Functions Contract, then it would
automatically dissolve the legitimacy of the incumbent members of the
Oversight Body. This would lead to a transition phase where both the
membership of the Policy Authority and the Oversight Body are to be
reconstituted, possibly a risky situation.

However, I agree that the Policy Authority should not be immutable or
perpetually granted to ICANN.

Regards,
Guru

On Tue, Nov 18, 2014 at 1:08 PM, Malcolm Hutty <malcolm at linx.net> wrote:

> Dear all,
>
> I hope I have not come too late to this party to participate. I have
> carefully read the mail archive before posting.
>
> Before I dive in with my suggestions, I have a question regarding
> Strawman 2 and Strawman 3. Both these strawmen envisage that the IANA
> Functions Contract would continue, with two different types of new
> entity as the counter-party to replace NTIA, "PROC" and "PROSI". Both
> these strawmen entertain the the possibility that someone other than
> ICANN could be awarded the IANA Functions Contract.
>
> My question is this: in the event that the new counter-party (PROC or
> PROSI) placed the IANA Functions Countract with a new operator, would it
> be open to the counter-party to direct the IANA operator to a new source
> of policy authority for gTLDs?
>
> The existing policy authority of ICANN derives from paragraph C.2.9.2.d
> of the IANA Function Contract, which states:
>
> * C.2.9.2d      Delegation and Redelegation of a Generic Top Level
> * Domain (gTLD) -- The Contractor shall verify that all requests
> * related to the delegation and redelegation of gTLDs are consistent
> * with the procedures developed by ICANN. In making a delegation or
> * redelegation recommendation, the Contractor must provide
> * documentation verifying that ICANN followed its own policy framework
> * including specific documentation demonstrating how the process
> * provided the opportunity for input from relevant stakeholders and was
> * supportive of the global public interest. The Contractor shall submit
> * its recommendations to the COR via a Delegation and Redelegation
> * Report.
>
> This paragraph appears to be of core importance. As I understand matter,
> it is this paragraph which gives ICANN policy authority over gTLDs as a
> practical matter: subjective claims about community support may explain
> why the NTIA chose to grant ICANN this authority, but that community
> will was only given effect through this paragraph.
>
> So my first question is, do the current strawmen (2 & 3) intend that
> this provision be a fixed and wholly immutable provision of any future
> IANA Functions Contract, or could ICANN be replaced by the counter-party
> (either at-will or in defined circumstances)?
>
> I would like to point out that this is not explicitly clear from the
> strawmen as drafted, and that is a weakness that should be addressed.
> My sense is that you intend it to be immutable, and I do consider that
> problematic, but before diving into why I would like to confirm your
> intentions (and discover whether there is an existing consensus on this
> point).
>
>
> Malcolm.
>
> --
>             Malcolm Hutty | tel: +44 20 7645 3523
>    Head of Public Affairs | Read the LINX Public Affairs blog
>  London Internet Exchange | http://publicaffairs.linx.net/
>
>                  London Internet Exchange Ltd
>            21-27 St Thomas Street, London SE1 9RY
>
>          Company Registered in England No. 3137929
>        Trinity Court, Trinity Street, Peterborough PE1 1DA
>
>
> _______________________________________________
> Cwg-rfp3 mailing list
> Cwg-rfp3 at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-rfp3
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20141118/eeb528a8/attachment-0001.html>


More information about the Cwg-rfp3 mailing list