<html>
<body>
Paul/Avri/All<br><br>
Fair enough ... I shouldn't complain about over-complications without
having some ideas about where the "over" comes from ...
<br><br>
I agree with you that the two ideas -- a Fundamental Bylaws, and an IRP -
are both conceptually simple. I'm making my way through the draft now,
and I'll take you up on the challenge to try to identify places where the
structure could be simplified, maybe even radically simplified.  A
few things occur to me, and I'll try to flesh these out in more detail;
it's not clear to me, for instance, that we really need a Mission
Statement, Core Values, <i>and </i>Commitments (and all the accompanying
specifications for how they are to be played off against one another, and
which takes precedence, etc.) - and I do wonder whether the detailed
specifications about reviews and reports is really valuable or just
over-complicating.  More to follow on those -<br><br>
David<br><br>
<br><br>
At 03:27 PM 5/6/2015, Paul Rosenzweig wrote:<br>
<blockquote type=cite class=cite cite="">David<br><br>
Let me second Avri's question with the hope of a real answer.  To my
mind the fundamental bylaw idea and the IRP idea are both conceptually
pretty simple.  They may be complex in implementation but they are
otherwise straightforward.<br><br>
I share your perception that the membership/designator structure of the
new community oversight structure is complex, indeed even rococo. 
But nobody in the CCWG or on the legal team at Sidley and Adler can think
of a simpler way to achieve the objective -- community control.  If
you have ideas, we are all ears!!<br><br>
Paul<br><br>
Paul Rosenzweig<br>
paul.rosenzweig@redbranchconsulting.com <br>
O: +1 (202) 547-0660<br>
M: +1 (202) 329-9650<br>
VOIP: +1 (202) 738-1739<br>
Skype: paul.rosenzweig1066<br>
Link to my PGP Key<br><br>
<br>
-----Original Message-----<br>
From: Avri Doria
[<a href="mailto:avri@ACM.ORG" eudora="autourl">mailto:avri@ACM.ORG</a>]
<br>
Sent: Wednesday, May 6, 2015 12:14 PM<br>
To: NCSG-DISCUSS@LISTSERV.SYR.EDU<br>
Subject: Re: Ominous update on the IANA transition<br><br>
Hi,<br><br>
How do you suggest it be made simpler?<br><br>
I think most of the people working on designing these solution have been
trying to simplify.  What further simplification can be done and
still have the checks and balances and paths of redress?  Without
resorting to a Deus ex Machina, that is.<br><br>
avri<br><br>
On 06-May-15 08:45, David Post wrote:<br>
> At 11:04 AM 5/5/2015, Paul Rosenzweig wrote:<br>
>> IsnΓ’€™t the real problem here that there is no no way of
knowing, ex <br>
>> ante, whether the mechanisms will actually work?Γ‚  I have
spent a lot <br>
>> of time on the IRP and if it works as I hope it will, it would
be a <br>
>> strong bulwark against mission creep ­ but what if it 
doesnΓ’€™t?<br>
?<br>
>>  <br>
>> Part of me wants to say that the formal transition should be
delayed<br>
>> 5 years until ICANN has lived under an implemented transition
system <br>
>> and has adequate experience.Γ‚  I fear, however, that such
a solution <br>
>> is untenable, politically and practically.Γ‚  We must, I
think, take a <br>
>> leap (of faith?) … Paul<br>
><br>
> It's a big problem - there is absolutely no way to know precisely
how, <br>
> e.g., the IRP is actually going work, let alone the whole
mechanism.<br>
> The best one can do is making sure it stays as transparent as
possible <br>
> (so that at least we'll be able to figure out how it's working and
<br>
> what's going on in real time) and that there's some kind of
reasonable <br>
> error-correction mechanism so that the scheme can be adjusted (or
<br>
> adjusts itself) over time.<br>
><br>
> It's also an argument, I think, for simplification - for my money,
the <br>
> whole scheme as it is developing seems vastly over-complicated (as
<br>
> ICANN itself seems vastly over-complicated).  I think that will
make <br>
> it much harder to guard against mission creep and/or other abuses of
<br>
> power down the road.<br>
><br>
> D.<br>
><br>
><br>
>  <br>
>> *From:* David Post [mailto:david.g.post@GMAIL.COM <br>
>>
<<a href="mailto:david.g.post@GMAIL.COM" eudora="autourl">
mailto:david.g.post@GMAIL.COM</a>>]<br>
>> *Sent:* Tuesday, May 5, 2015 8:44 AM<br>
>> *To:* NCSG-DISCUSS@LISTSERV.SYR.EDU<br>
>> *Subject:* Re: Ominous update on the IANA transition<br>
>>  <br>
>> At 07:17 AM 5/5/2015, Brenden Kuerbis wrote:<br>
>><br>
>>     Hi, David, <br>
>>     [SNIP]<br>
>>     On this point, please see the recently
releasedΓƒ‚  Cross Community<br>
>>     Working Group (CCWG) Accountability
Initial Draft Proposal for<br>
>>     Public Comment,Γƒ‚<br>
>>     <br>
>>
<a href="https://www.icann.org/en/system/files/files/cwg-accountability-draft" eudora="autourl">
https://www.icann.org/en/system/files/files/cwg-accountability-draft</a>
-<br>
>> proposal-with-annexes-04may15-en.pdf<br>
>><br>
>>     Would you agree that the proposed update
to ICANN's Mission<br>
>>     Statement (pg 15) which limits ICANN
scope, in conjunction with<br>
>>     proposed community empowerment
mechanisms address this concern<br>
>>     adequately?<br>
>><br>
>><br>
>> Brenden<br>
>><br>
>> The Mission Statement changes do go a long way to addressing
this <br>
>> concern - so the question becomes: will it actually serve as an
<br>
>> effective constraint on ICANN's powers, or, Soviet <br>
>> constitution-style, just a bunch of nice words?<br>
>><br>
>> It's a little too early, for me, to say whether the proposed
<br>
>> community empowerment mechanisms will do the job adequately; the
<br>
>> devil really is in the details, and a lot - everything, actually
- <br>
>> depends on how those details get fleshed out.  The proposal
has a lot <br>
>> of good things in it - the enhanced Independent Review Panel,
recall <br>
>> mechanisms for Directors, community power over the budget - and
is a <br>
>> good step forward, in my view; but there are lots of substantial
gaps <br>
>> and open questions about how it all will actually work [No
criticism <br>
>> at all of the many folks who worked on this is intended, but
just as <br>
>> a statement of fact]. There's a fine line between, say, an IRP
that <br>
>> is effective and one that isn't (as the last 15 years have
shown), so <br>
>> I guess I'm not ready to say it's been adequately addressed
quite<br>
>> yet.   <br>
>><br>
>> David<br>
>><br>
>><br>
>><br>
>>     Γƒ‚<br>
>>     On Mon, May 4, 2015 at 2:49 PM, David
Post<br>
>>     <david.g.post@gmail.com
<mailto:david.g.post@gmail.com> > wrote: <br>
>>     [Apologies for cross-posting]<br>
>>     This really is starting to look, as
Milton said, ominous -<br>
>>     coupled with the pressure being placed
upon ICANN to regulate<br>
>>     message content, see <br>
>>    
<a href="http://www.internetcommerce.org/senate-judiciary-to-ip-czar/" eudora="autourl">
http://www.internetcommerce.org/senate-judiciary-to-ip-czar/</a><br>
>><br>
>>     my take on this is here: <br>
>>    
<a href="http://www.washingtonpost.com/news/volokh-conspiracy/wp/2015/05/04/internet-governance-what-if-the-sky-really-is-falling/" eudora="autourl">
http://www.washingtonpost.com/news/volokh-conspiracy/wp/2015/05/04/internet-governance-what-if-the-sky-really-is-falling/</a>
<br>
>>     <br>
>>
<<a href="http://www.washingtonpost.com/news/volokh-conspiracy/wp/2015/05/04/i" eudora="autourl">
http://www.washingtonpost.com/news/volokh-conspiracy/wp/2015/05/04/i</a>
>> nternet-governance-what-if-the-sky-really-is-falling/><br>
>><br>
>>     If the final proposal does not have real
safeguards against<br>
>>     ICANN's content-regulation powers, we're
all in trouble.<br>
>><br>
>>     On this point, please see the recently
releasedΓƒ‚  Cross Community<br>
>>     Working Group (CCWG) Accountability
Initial Draft Proposal for<br>
>>     Public Comment,Γƒ‚<br>
>>     <br>
>>
<a href="https://www.icann.org/en/system/files/files/cwg-accountability-draft" eudora="autourl">
https://www.icann.org/en/system/files/files/cwg-accountability-draft</a>
-<br>
>> proposal-with-annexes-04may15-en.pdf<br>
>><br>
>>     Would you agree that the proposed update
to ICANN's Mission<br>
>>     Statement (pg 15) which limits ICANN
scope, in conjunction with<br>
>>     proposed community empowerment
mechanisms address this concern<br>
>>     adequately?<br>
>>     Γƒ‚ <br>
>>     And I am starting to wonder whether the
USG is interested in<br>
>>     making sure those safeguards are in
place, or, as suggested in<br>
>>     the above, making sure that they're NOT
in place. . . .<br>
>><br>
>>     I agree there will continue to be
pressure put on ICANN by IP<br>
>>     rightsholders interests, using any
available route. But if the<br>
>>     above is adopted it seems it would go a
long way toward<br>
>>     mitigating that pressure.<br>
>>     -- Brenden<br>
>>     Γƒ‚ <br>
>>     David<br>
>>     At 09:27 AM 4/30/2015, Milton L Mueller
wrote:<br>
>><br>
>>         Γƒ‚ Γƒ‚ Γƒ‚ ƒβ€š
Γƒ‚ Γƒ‚ Γƒ‚ Γƒ‚  Γƒβ€š Γƒ‚ Γƒ‚ Γƒ‚ Γƒ‚  Γƒβ€š Γƒ‚ Γƒ‚ Γƒ‚
Γƒ‚  Γƒβ€š Γƒ‚ Γƒ‚ Γƒ‚ Γƒ‚  Γƒβ€š Γƒ‚<br>
>>         Γƒ‚ Γƒ‚ Γƒ‚ ƒβ€š
Γƒ‚ Γƒ‚ Γƒ‚ Γƒ‚  Γƒβ€š Γƒ‚  <br>
>>         Dear NCSG: <br>
>>         ItҀ™s now
official: l: ICANN NN doesnҀ™t even want to let<br>
t<br>
>>         the IETF have a
a choice of its IANA functions operator. <br>
>>         Γƒ‚ <br>
>>         Those of you who
read my blog post on ICANNҀ™s interactions<br>
s<br>
>>         with the he
numbers community<br>
>>        
<<a href="http://www.internetgovernance.org/2015/04/28/icann-wants-an-iana-functions-monopoly-and-its-willing-to-wreck-the-transition-process-to-get-it/" eudora="autourl">
http://www.internetgovernance.org/2015/04/28/icann-wants-an-iana-functions-monopoly-and-its-willing-to-wreck-the-transition-process-to-get-it/</a>
><br>
>>         will already
know that ICANN is refusing to accept the<br>
>>         consensus of the
numbers community by recognizing its<br>
>>         contractual
right to terminate its IANA functions operator<br>
>>         agreement with
ICANN. In that blog, I referred to second-hand<br>
>>         reports that
IETF was encountering similar problems with<br>
>>         ICANN. Those
reports are now public; the chairs of the IETF,<br>
>>         IAB and IETF
Administrative Oversight Committee have sent a<br>
>>         letter to their
community<br>
>>        
<<a href="http://www.ietf.org/mail-archive/web/ianaplan/current/msg01680.html" eudora="autourl">
http://www.ietf.org/mail-archive/web/ianaplan/current/msg01680.html</a>
><br>
>>         noting that
ICANN is refusing to renew their supplemental<br>
>>         service level
agreement because it includes new provisions<br>
>>         designed to
facilitate change in IANA functions operators<br>
>>         should IETF
become dissatisfied with ICANN. <br>
>>         Γƒ‚ <br>
>>         These are truly
shocking moves, because in effect ICANNҀ™s<br>
s<br>
>>         legal staff is
is telling both the numbers and the protocols<br>
>>         communities that
they will not accept the proposals for the<br>
>>         IANA transition
that they have developed as part of the IANA<br>
>>         Stewardship
Coordination Group (ICG) process. In both cases,<br>
>>         the proposals
were consensus proposals within the affected<br>
>>         communities, and
were approved by the ICG as complete and<br>
>>         conformant to
the NTIA criteria. Thus, ICANN is in effect<br>
>>         usurping the
entire process, setting itself (rather than ICG<br>
>>         and NTIA) as the
arbiter of what is an acceptable transition<br>
>>         proposal. <br>
>>         Γƒ‚ <br>
>>         The key point of
conflict here seems to be the issue of<br>
>>         whether ICANN
will have a permanent monopoly on the provision<br>
>>         of IANA
functions, or whether each of the affected<br>
>>         communities ­
names, numbers and protoocols ­ €“ €β€œ will have<br>
>>         the right to
choose the operator of their global registries.<br>
>>         Separability is
explicitly recognized by the Cross community<br>
>>         working group on
Names as a principle to guide the<br>
>>         transition, and
was also listed as a requirement by the CRISP<br>
>>         team. And the
IETF has had an agreement with ICANN giving<br>
>>         them
separability since 2000 (RFC 2860<br>
>>        
<<a href="https://tools.ietf.org/html/rfc2860%3E).%C3ƒ‚%A0" eudora="autourl">
https://tools.ietf.org/html/rfc2860>).Γƒ‚ </a> Yet  despite
the<br>
>>         wishes of the
community, ICANN seems to insist on a monopoly<br>
>>         and seems to be
exploiting the transition process to get one. <br>
>>         Γƒ‚ <br>
>>         Of course, a
severable contract for the IANA functions is the<br>
>>         most effective
and important form of accountability. If the<br>
>>         users of IANA
are locked in to a single provider, it is more<br>
>>         difficult to
keep the IANA responsive, efficient and<br>
>>         accountable.
Given the implications of these actions for the<br>
>>         accountability
CCWG, I hope someone on that list will forward<br>
>>         this message to
their list, if someone has not noted this<br>
>>         event
already.Γƒ‚  <br>
>>         Γƒ‚ <br>
>>         Milton L Mueller
<br>
>>         Laura J. and L.
Douglas Meredith Professor <br>
>>         Syracuse
University School of Information Studies <br>
>>        
<a href="http://faculty.ischool.syr.edu/mueller/" eudora="autourl">
http://faculty.ischool.syr.edu/mueller/</a><br>
>>        
<<a href="http://faculty.ischool.syr.edu/mueller/" eudora="autourl">
http://faculty.ischool.syr.edu/mueller/</a>> <br>
>>         Internet
Governance Project <br>
>>        
<a href="http://internetgovernance.org/" eudora="autourl">
http://internetgovernance.org</a>
<<a href="http://internetgovernance.org/" eudora="autourl">
http://internetgovernance.org/</a>> <br>
>>         Γƒ‚<br>
>><br>
>>       <br>
>>     ******************************* <br>
>>     David G Post - Senior Fellow, Open
Technology Institute/New<br>
>>     America Foundation <br>
>>     blog (Volokh Conspiracy)<br>
>>    
<a href="http://www.washingtonpost.com/people/david-post" eudora="autourl">
http://www.washingtonpost.com/people/david-post</a><br>
>>    
<<a href="http://www.washingtonpost.com/people/david-post" eudora="autourl">
http://www.washingtonpost.com/people/david-post</a>> <br>
>>     book (Jefferson's Moose)Γƒ‚  
<a href="http://tinyurl.com/c327w2n%C3ƒ‚" eudora="autourl">
http://tinyurl.com/c327w2nΓƒ‚</a> Γƒ‚ €š Γƒ‚ Γƒ‚<br>
š<br>
>>     Γƒ‚ Γƒ‚  š 
<<a href="http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0%A0" eudora="autourl">
http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0%A0</a>> <br>
>>     music
<a href="http://tinyurl.com/davidpostmusic" eudora="autourl">
http://tinyurl.com/davidpostmusic</a><br>
>>    
<<a href="http://tinyurl.com/davidpostmusic%A0" eudora="autourl">
http://tinyurl.com/davidpostmusic%A0</a>>publications etc.Γƒ‚ <br>
>>    
<a href="http://www.davidpost.comΓƒ‚/" eudora="autourl">
http://www.davidpost.comΓƒ‚</a> Γƒ‚ €š Γƒ‚ Γƒ‚ Γƒ‚ Γƒ‚  Γƒβ€š Γƒ‚
Γƒ‚  <??.htm> <br>
 <br>
>>     *******************************<br>
>><br>
>><br>
>> *******************************<br>
>> David G Post - Senior Fellow, Open Technology Institute/New
America <br>
>> Foundation blog (Volokh Conspiracy) <br>
>>
<a href="http://www.washingtonpost.com/people/david-post" eudora="autourl">
http://www.washingtonpost.com/people/david-post</a><br>
>>
<<a href="http://www.washingtonpost.com/people/david-post" eudora="autourl">
http://www.washingtonpost.com/people/david-post</a>>book
(Jefferson's<br>
>> Moose) 
<a href="http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0" eudora="autourl">
http://tinyurl.com/c327w2n     </a> <br>
>>
<<a href="http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0%A0" eudora="autourl">
http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0%A0</a>><br>
>> music
<a href="http://tinyurl.com/davidpostmusic" eudora="autourl">
http://tinyurl.com/davidpostmusic</a> <br>
>>
<<a href="http://tinyurl.com/davidpostmusic%A0" eudora="autourl">
http://tinyurl.com/davidpostmusic%A0</a>>publications etc.<br>
>>
<a href="http://www.davidpost.com       /" eudora="autourl">
http://www.davidpost.com       </a> <br>
>>
<<a href="http://www.davidpost.com        +/" eudora="autourl">
http://www.davidpost.com%A0%A0%A0%A0%A0%A0%A0%A0+/</a>><br>
>> *******************************<br>
><br>
> *******************************<br>
> David G Post - Senior Fellow, Open Technology Institute/New America
<br>
> Foundation blog (Volokh Conspiracy) <br>
>
<a href="http://www.washingtonpost.com/people/david-post" eudora="autourl">
http://www.washingtonpost.com/people/david-post</a><br>
>
<<a href="http://www.washingtonpost.com/people/david-post" eudora="autourl">
http://www.washingtonpost.com/people/david-post</a>>book
(Jefferson's<br>
> Moose) 
<a href="http://tinyurl.com/c327w2n%A0%A0%A0%A0" eudora="autourl">
http://tinyurl.com/c327w2n    </a> <br>
>
<<a href="http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0" eudora="autourl">
http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0</a>><br>
> music
<a href="http://tinyurl.com/davidpostmusic" eudora="autourl">
http://tinyurl.com/davidpostmusic</a> <br>
>
<<a href="http://tinyurl.com/davidpostmusic" eudora="autourl">
http://tinyurl.com/davidpostmusic</a>> publications etc.<br>
>
<a href="http://www.davidpost.com      /" eudora="autourl">
http://www.davidpost.com      </a> <br>
>
<<a href="http://www.davidpost.com        /" eudora="autourl">
http://www.davidpost.com%A0%A0%A0%A0%A0%A0%A0%A0/</a>><br>
> *******************************<br><br>
<br>
---<br>
This email has been checked for viruses by Avast antivirus software.<br>
<a href="http://www.avast.com/" eudora="autourl">http://www.avast.com</a>
</blockquote><br>
*******************************<br>
David G Post - Senior Fellow, Open Technology Institute/New America
Foundation<br>
blog (Volokh Conspiracy)
<a href="http://www.washingtonpost.com/people/david-post" eudora="autourl">
http://www.washingtonpost.com/people/david-post<br>
</a>book (Jefferson's Moose) 
<a href="http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0%A0" eudora="autourl">
http://tinyurl.com/c327w2n       </a> <br>
music
<a href="http://tinyurl.com/davidpostmusic%A0" eudora="autourl">
http://tinyurl.com/davidpostmusic </a> publications etc. 
<a href="http://www.davidpost.com         /" eudora="autourl">
http://www.davidpost.com        
</a> <br>
******************************* </body>
</html>