[CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May

[Martin Boyle]

So Milton:  In spite of your analysis of my concerns, I still do not agree.  In your defence of your assertions, you continue to miss my point completely.

For ccTLDs, ICANN’s sole role is to provide the framework for policy development.  (Caveat:  as Paul Kane would note, actually only for those ccTLDs that were members of the ccNSO.  And actually the policy document did not come from ICANN anyway.)  It is the IANA functions operator’s obligation to base its decisions on the policy in place – as identified below.

In making its decisions:


·         Neither the ccNSO nor the GAC has any say over the decisions except in that they might (I suppose – to my knowledge this has never happened) raise questions with the Board about conformity to policy).  In particular, I would hope that GAC members (in line with paragraph 63 of the Tunis Agenda) would not see it as their role to comment – it would be interfering with a country’s national sovereignty.


·         The current Board view (and one that I feel greatly comfortable with) is that its role is simply to ensure that due process has been followed and documented.  It uses a traffic-light metric and recognises that there might be different interpretations (for example on how multi-stakeholder engagement takes place).  In essence and for national sovereignty reasons, any role for the Board is simply to assure itself that the decision has been properly made.  It has taken us a long time to get there, and I do not want to see us return to ICANN having a decision making role for ccTLD delegations:  been there and it doesn’t work.



·         All the analysis, document checking, evaluation, discussion with the interested parties in a ccTLD amendment is currently carried out by the IANA functions operator.  I failed to notice where we decided that the PTI as new IANA functions operator would only do the clerical and technical bit and I would love to know who does the detailed work in the new model.  It seems to leave behind in ICANN a key IANA functions operator role in the existing model.


You can claim indignation all you like, but you still do not address my concerns about the appropriateness of your model of ICANN Board instructions for ccTLDs.  I stand to be corrected, but I’m not convinced yet.

As for your interpretation of the new model:  if this is right, then Nominet for one will not be able to accept the current proposal.  I suspect other ccTLDs will have similar problems.  Incidentally, I seriously wonder why we have put all this effort in on separability if the only thing we are able to separate is the mechanical bit (which could all be done automatically).

The learning process has taken place on the ICANN side of the divide over the years.  ICANN is currently the IANA contractor and the learning is also in place in the IANA team.  I’ve given no thought to date about who validates changes – up to now I’ve assumed it would be the PTI Board as responsible for the IANA functions operator’s work.  Placing it elsewhere gives me two concerns:


1.       The validation body (remember that we’ve agreed there should not be an authorisation function in the new model) is the responsible agent:  if it is in ICANN we cannot hold PTI responsible for any failure.


2.       The validation body operates a gatekeeper function outside the direct surveillance of the mechanisms we have been discussing for so long.  We will have additional work to make pretty clear what the limitations of that function actually are:  I think it should only be able to refer decisions back to the IANA functions operator (the operational team) on the basis that the process has not been followed or that the necessary documentation is not present or correct.


So I’m still unconvinced by your arguments.  They might work for gTLDs – and I’m happy for existing arrangements for gTLDs to stay in place.  But I don’t think what you assert works for ccTLDs,

Martin


From: Milton L Mueller [mailto:mueller at syr.edu]
Sent: 01 May 2015 14:53
To: Martin Boyle; 'Gomes, Chuck'; 'CW Lists'; 'Grace Abuhamad'
Cc: 'cwg-stewardship at icann.org'
Subject: RE: [CWG-Stewardship] A few additional comments for … Two additional webinars on 6-7 May

From: Martin Boyle [mailto:Martin.Boyle at nominet.org.uk]
Boyle: Obviously then I’m misunderstanding something Milton.

MM: You are.

> The IANA Functions operator (IFO) should simply take ICANN’s instructions.

Boyle: Err, no!  The IANA functions operator should base its decisions on agreed policy.  In ccTLD cases, rfc1591 is now supplemented (informed) by the work of the Framework of Interpretation Working Group.

MM: which is part of the ccNSO, which is part of….ICANN. Or are you asserting it is part of IANA?

Boyle: It also has advice from the GAC 2005 Principles.

MM: GAC is part of….ICANN. Or are you asserting it is part of IANA?

Boyle: ICANN (as the Board) does not have a role in telling the IANA functions operator what to do in the case of ccTLD delegations or revocations.

MM: This is where the misunderstanding resides. When I said “ICANN” I meant the policy-making side of the ICANN/IANA split, which includes not just the board, but the policy making entities such as ccNSO, GNSO, the ACs. When I say IANA “takes instructions” there could still be ambiguities about the exact way in which those instructions are issued, and by whom, and when, but clarifying that is one of the virtues of separation. I think we both agree that once a policy is set, IFO should implement it, and that IFO does not make the policy or have discretion as to whether to implement it.

Boyle: This is fundamental – clear separation of policy and the IANA functions operator should not be undermined by ICANN giving instructions.

MM: Agreed. My goal is precisely the clear separation of policy and the IFO. This should be clear.

Boyle: The issue – and hence the complexity – is about who actually has the right to make the decisions and direct the IANA functions operator.  The role of the IANA functions operator is to identify that a decision is appropriate – and the SOW gives some guidance to that, as does the work of the FOIWG.  But it is absolutely not ICANN’s decision.

Boyle: Your failure to understand this is perhaps why you feel quite casual about re-bidding the IANA functions operation and I do not.  The ccTLD community has seen the friction caused by ICANN imposing arbitrary conditions or questioning legitimate national decisions.  (This history of this high-handed approach was one of the motivations for the 2005 GAC Principles.)  I do not think that I’m alone in wanting to avoid as much as possible having to start the learning process again with a new contractor.

MM: I think it’s clear from this exchange that you are failing to understand my point, and you are overreacting - it’s not me failing to understand the risk of arbitrary and high-handed actions by ICANN. Really, that’s a pretty insulting and uninformed assertion for you to make, given my role in analysing and leading attempts to reform the accountability problems at ICANN.

MM: As for “starting this learning process over with a new contractor,” the learning process has to take place on the ICANN side of the divide, not at the IANA contractor, and be reflected in the ICANN-IFO contract. The problems you mention have occurred precisely because IANA has been a wholly controlled department of the ICANN board. Any contract between ICANN and an IFO could and should clearly account for the concerns you have and make sure that ICANN’s board cannot issue “instructions” that are not authorized or approved by the proper parties on the policy making side of the divide.

--MM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150502/6eed40ec/attachment-0001.html>