[CCWG-ACCT] Our timetable -- some personal observations

Dr. Tatiana Tropina t.tropina at mpicc.de
Wed Dec 16 08:47:01 UTC 2015


Hi Jordan

I think the question about delay is the choice between:
- Making significant changes based on the board comments and watering
down major accountability mechanisms - this will cause delay in any case.
- Rejecting board's comments in order to save some of the recommendation
we made (or go on with the current proposal) and face the risk of delay
if the board will bring the issue of GPI, etc.
Basically, "lesser evil" choice.
I rather prefer the second option since it looks to me that in any case
there is no other choice but delay (or is there?). I would rather resist
the idea of making the proposal worse by incorporating all the feedback
given by the board.

Best regards
Tanya
 

On 16/12/15 09:22, Jordan Carter wrote:
> Hi all, Nigel: a couple of points in line below.
>
> On Wednesday, 16 December 2015, Nigel Roberts <nigel at channelisles.net
> <mailto:nigel at channelisles.net>> wrote:
>
>
>
>     On 12/16/2015 03:57 AM, Jordan Carter wrote:
>
>
>     > tests. So the fundamental quality of the work is not in question.
>
>     I regret to say that I am afraid it is.
>
>
> I don't agree, but I may have not been quite clear. More time and work
> will always lead to higher quality. But the current proposal works.
>  
>
>     >
>
>
>
>     > be clear - and that is the basis on which I have been happy to
>     accept
>     > the truncated process for this phase.
>
>     By 'truncate process' you mean the consistent, deliberate and
>     largely successful attempts to subvert the Chartered Process.
>
>
> No: I don't agree the shortened comment period does any such thing. 
>  
>
>
>     >
>     > Third, the drivers. To me the following have helped leave me able to
>     > deal with the compressed timeframe:
>     >
>     > - pressure from senior ICANN staff and directors to "get it
>     done" - and
>     > clear paintings, as recently as Dublin, of "horror" scenarios if the
>     I don't understand this statement.
>
>     Firstly, the alleged pressure to 'get it done at all costs' does
>     not appear to emanate from the Board. It comes from unstated and
>     unnamed actors.
>
>
> If the Icann board allows its  staff to argue for things it does not
> support, that tells an interesting story.
>
>
>     I do not agree with the Board's bombshell tactics in Santa Monica.
>
>     I do not agree with some of the Board's more recent fundamental
>     objections, published on the 14th.
>
>     But I submit, the Board would have done neither of these things if
>     it was hell bent on "get 'er done" at all costs.
>
>     Therefore I feel that's a misrepresentation.
>
>
> As above.
>  
>
>
>     Furthermore, I fail to see how the (very real) pressure on the WG
>     allegedly from the Board (doubtful, see above) can give you comfort.
>
>
> Where did I express comfort? The point of my email has been to signal
> in the clearest possible terms my *discomfort*  with the pressure that
> has been applied.
>
> <snip> 
>
>       
>     > - a new intervention now with further substantive changes
>     proposed, some
>     > of which are fundamental to the Third Draft (esp. the human rights,
>     > voting thresholds, inspection rights and IANA budget) that cannot be
>     > incorporated without further delays to the process.
>
>
>     Are you saying that you prefer no delay, to creating an ICANN that
>     has no obligations to respect fundamental rights?
>
>
> I prefer sticking with the current proposa and no delay, to delay and
> weakening that commitment. 
>  
>
>
>     > cannot imagine numbers and protocols being happy about further time.
>     > (That is a deliberate understatement. I think they would be
>     furious.)
>     >
>
>     Personally, to borrow a phrase often used by a much more critical
>     observer of the process, "I do not give a dead rat's fuzzy behind"
>     how furious they get. It is not for them to interfere in how the
>     names community works.
>
>
> You are welcome to take that point of view, but since Icann
> accountability is tied up with the transition, and the transition
> affects all three communities, I think it is probably an unreasonable
> one for the ccwg as a whole to take.
>
> <snip>
>
>
>     Numbers and protocols don't need ICANN. I think they will look
>     with some bemusemnt on what we are up in the names part, but the
>     fact is, their area is easy, and ours isn't.
>
>
> That's fine, but NTIA has very clearly told the other two communities
> that in fact they do need ICANN - that they won't accept a transition
> that splits the Iana functions into different operators.
>  
>
>
>     > - do you think substantive changes such as those of the Board would
>     > require delays if adopted following the close of public comments?
>     >
>
>     Jordan, this a clever formulation, but its designed to predicate
>     the answer. In other words 'it begs the question'
>
>
> No, Nigel, it does not, and it is not better put by your version -
> which certainly does beg the question.
>
> On my view the answer to the question I posed above is 'yes'. 
>
>
>     A better way of putting is, is "Should we do this right, or should
>     we accept a defective proposal. Which do you prefer?"
>
>
> I don't believe the proposal is defective. I believe it would become
> worse if some of the feedback the board has offered was incorporated.
>
> Jordan  
>
>
> -- 
> Jordan Carter
> Chief Executive, InternetNZ
>
> +64-21-442-649 | jordan at internetnz.net.nz
> <mailto:jordan at internetnz.net.nz>
>
> Sent on the run, apologies for brevity
>
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151216/394942b0/attachment-0001.html>


More information about the Accountability-Cross-Community mailing list