[Internal-cg] Early draft for a charter

Paul Wilson pwilson at apnic.net
Wed Jul 16 09:42:53 UTC 2014

I’m with both Milton and Alissa in this discussion.

- Members of the CG are not in any position to invent solutions for other constituencies (other than their own), and neither will they succeed by trying to do so.  

- To me this means that realistically, the CG can only consider substantive parts of the eventual plan that have been supplied by the affected constituencies, and our role in reconciling differences cannot introduce substantial changes to individual plans.  Well, we can try, and we can try to judge the difference between substantial changes and lesser adjustments, but in the end that judgement is not ours to make.

- I believe that in soliciting plans from the individual communities we must be very clear on what is expected: giving as much guidance as we can on the structure of the plan, on the information that is must contain, the questions which must be addressed, etc.  This could be in the form or a checklist, a questionnaire, or a survey monkey form.  :-)

- To allow us to find the “best compromise” in case of differences, we may also need to identify in advance the likely areas of difference, and structure our questions so as to drill down into those areas.

- We might also ask that the plans submitted to us respond very specifically in identifying negotiable or non-negotiable elements (preferences versus requirements).  Sure, some folks will actually be more negotiable than they are prepared to admit, but it is important I think to phrase this whole exercise as one of compromise rather than demand.

- Finally I think that one thing we can do is to make a distinction, both in our own minds and in our communication with constituencies, between those aspics of the transition plan that are essential to the transition, and those which may be able to be deferred for later resolution.   This process will certainly not succeed if participants try to use it as an opportunity to make ambit claims for a whole raft of demands or reforms which are not strictly related to the transition.


Paul Wilson, Director-General, APNIC                      <dg at apnic.net>
http://www.apnic.net                                     +61 7 3858 3100

See you at APNIC 38!                      http://conference.apnic.net/38

On 16 Jul 2014, at 12:48 am, Milton L Mueller <Mueller at syr.edu> wrote:

> Thanks Alissa for the well-considered response. My replies below in line
>> -----Original Message-----
>> board, which is far from ideal for many reasons. For the IANA stewardship
>> transition, I think the first key question is what the cross-community decision
>> mechanism will be. I think such a mechanism is absolutely necessary.
> A Cross Community Working Group is being set up within ICANN. There are three problems with it: 
> a) like the CG, it contains members from outside the names communities (e.g., RIRs, ASO, ALAC)
> b) its composition almost exactly mirrors that of the CG, only it is larger
> c) it is almost entirely ICANN oriented
>> You have suggested that the CG should be that mechanism.
> Incorrect! Not at all what I proposed! Here is a simple cut and paste of what I proposed: 
> I think the CG has to be chartered to review proposals:
> * to provide a reality check on their workability,
> * to assess their compatibility and interoperability with the numbers and protocol part of the problem, and
> * to assess their levels of support.
> In other words, my idea assumes that the CG is a "taker" not a "maker" of proposals, but it also evaluates them, and may need to tweak them to achieve compatibility. It does NOT propose to make the CG the mechanism for initial development of proposals. It DOES assume that whatever we do is subject to public comment. The difference is just that I am assuming (based on sober realism) that there is unlikely to be consensus among the DNS communities, and that there is still a need for assessment of the way the proposals coming out of the 3 communities relate to each other. I also believe that, given the size, complexity and non-DNS-based nature of the CCWG, that there will be a need for an independent assessment of the level of support enjoyed by proposals that emerge from the CCWG, and indeed, for all 3 sectors. 
> The DNS part is also likely to receive input from non-ICANN based sources. IMHO, some of those proposals may need to be taken as seriously as whatever comes out of the CCWG. There is also some possibility that there will be US Congressional legislation that impacts our work.
>> 2. The problem described above is a show-stopper for protocol parameters.
>> That is, it will not be acceptable for the CG to modify the substance of an IETF
>> community consensus proposal for protocol parameters if the IETF
>> community produces such a proposal. The ultimate authority over the
> Of course. Again, you are misunderstanding my conception of the role of the CG. If indeed a community produces a firm consensus then none of the problems I am worried about are invoked. The three functions mentioned above (check on workability, assessment of compatibility and interoperability, and levels of support) would not justify changing an IETF proposal that had consensus & was workable. If, however, there proved to be incompatibilities with the proposal coming out of IETF, DNS and numbers, then the the CG could send the proposal back to IETF with an explanation of what the problem was, and await modification. I am sure you would not suggest that an IETF solution should dictate the form or structure preferred by other communities? 
>> substance of the protocol parameters proposal must reside with the IETF
>> community, not the CG. If the CG observes problems with any proposal it
>> receives from the IETF, the remedy for that is to send the proposal back to
>> the IETF community to get fixed, not to fix it ourselves.
> Exactly what I had in mind (see above).
>> 3. If the core of the difficulty in the names community is that views are so
>> diverse as to be irreconcilable, I’m not sure I understand why the subset of
>> the CG reps from names organizations would be more likely to agree on one
>> proposal than would the organizations they represent. 
> It is possible, of course, that both entities would be deadlocked; however, it is a well-known feature of politics and working groups that a smaller, higher-level committee one step removed from the direct constituencies may find it easier to find accord - especially since they are in more direct communication with each other and with the other communities. For a very rough analogy, think of the differences between the House and the Senate in the U.S. Congress, or the difference between an expert commission and a Congressional committee. 
>> 4. NTIA has specified that the final transition proposal needs to have broad
>> community support. It’s not clear to me that, if presented with, say, four
>> different proposals from four different constituency groups, the CG choosing
>> one of them would actually result in a proposal that could be claimed to have
>> broad community support. Same goes for if we stitch together pieces of
>> different names proposals.
> The CG is in the best position to assess which of the 4 has the most support and fits in the best with the other communities' plans, don't you think? And I think it is also in the best position to determine which modifications could be made in a viable proposal that had some, but not quite enough, support, to increase its standing. As for stitching together, there is no avoiding it -- even in the ideal case that you seem to be contemplaying, we will "stitch together" the DNS, numbers and protocol proposals into a single integrated proposal. And there will be a public comment period for reviewing whatever we do. 
> Hope this clarifies my position, and I think it shows that we are not that far apart, I am, imho, simply a bit more detailed and realistic about what we are likely to face. 
>> I will end this novel now. 
> Hope chapter 2 contains battle scenes, romance and a happy ending
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg

More information about the Internal-cg mailing list