[Internal-cg] Early draft for a charter

[Milton L Mueller]

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