Thanks Avri, your response is helpful. On the use of the word capture: my intent was more aligned with ‘part of the ICANN community’. Donna [Description: Description: Description: ARI Logo]DONNA AUSTIN Policy and Industry Affairs Manager ARI REGISTRY SERVICES Melbourne | Los Angeles P +1 310 890 9655 P +61 3 9866 3710 E donna.austin@ariservices.com<mailto:donna.austin@ariservices.com> W www.ariservices.com<http://www.ariservices.com/> Follow us on Twitter<https://twitter.com/ARIservices> The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Avri Doria Sent: Thursday, 19 February 2015 3:15 PM To: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Update on the Integrated model. Hi, In this model, that question is left up to each of the operational communities and the way in which they pick their representatives to the Community Board. As you know there are varied opinions on the degree to which the G and C registries are the only relevant customers. Personally I tend toward a multistakeholder customer view, but the model does not predicate a particular mix and those of us who worked on it probably have different points of view on this. You say It seems that ccTLD and gTLD registries are captured under the ICANN community. I tend to see them as part of the ICANN community. Not captured by it. In terms of the CSC, the Registries have already achieved the majority voice as was requested - it was my understanding that Registries would be more sharing with the rest of us when it came to the MRT or MRT like bodies. In terms of the MRT, the mainstream discussion is ongoing: Registries vs. Multistakeholder. This model lists one possible way of distributing the community board. In this form, it allows for 3-5 votes per operational community according to their own multistakeholder decision - though they can field a bigger group of participants if necessary and have normalized representation. How we in ICANN decide to split those votes is up to us. There are modes that are multistakeholder (5 votes distributed across the SOs and ACs, perhaps with some rotation) or we could have a mode where there were only 3 votes (1 to each registry type and one to the rest of us). In some sense it is a continuation of the MRT disagreement over the degree of the multistakeholder participation in the Community Board representatives for ICANN. Of course we could also expand the Community Board to 7 from each operation community, but that seems like too large a Community Board to me. But not necessarily to others. What is important in the model for accountability checks and balances to work is parity among the operational communities. How each of them parses their votes, and in our case how ICANN does it, is up to us and not determined in the model. Our goal was to make a simpler model and to find a path toward resolution on the inside/outside dichotomy. Solving the balance between Registries as 'direct' customers, and a distributed multistakeholder model, remains on our plate. We offer one way to think about it, but it is not a structural element of the model or of any of the configurations. It is also important to remember that this Board has very little to do with the SLAs themselves and is more about budget, continuity and exceptions processing. One additonal point, this model, in all of the configurations, requires the creation of specific SLA for the G&C Registry operations. Determining those would most probably be primarily a Registry affair and would be monitored by the Registry dominant CSC. avri On 18-Feb-15 21:55, Donna Austin wrote: Hi Avri I’m interested to know how the primary ‘naming’ customers of the IANA services are recognised under your model. It seems that ccTLD and gTLD registries are captured under the ICANN community. Could you elaborate on the role or voice of the customer under your proposed model. Thanks, Donna DONNA AUSTIN Policy and Industry Affairs Manager ARI REGISTRY SERVICES Melbourne | Los Angeles P +1 310 890 9655 P +61 3 9866 3710 E donna.austin@ariservices.com<mailto:donna.austin@ariservices.com> W www.ariservices.com<http://www.ariservices.com/> Follow us on Twitter<https://twitter.com/ARIservices> The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Avri Doria Sent: Thursday, 19 February 2015 6:09 AM To: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: [CWG-Stewardship] Update on the Integrated model. Hi, As mentioned in an earlier email, Matthew Shears, Brenden Kuerbis and I have been working on a model that attempts to integrate solutions to some of the various sets of concerns by those favoring internal models and those preferring external models while trying to make the model simpler and more accountable to the IANA ecosystem and the wider community. During Singapore week we spoke to as many as we could about this model and have received, and worked through, a number of comments on the open drive draft document, which we announced on the list. The working draft, which is still a work in progress and remains open for comment can be found at: https://docs.google.com/document/d/1SvKDEIaeHdre3BQXHNe1K3hCA95dsFWqWAz2Kg5Y... I have attached a pdf version of a snapshot draft of the doc as of today. We would like to be able to present this at the next RFP3 meeting. Or anywhere else that is appropriate. We are also working on drafts to document the means by which this model responds to NTIA requirements, but we will able to speak those on list and during the meeting. In the draft we present three possible configurations for the model. The authors believe that Shared Service Arrangement (page 6) is the preferred configuration, as it offers the most accountability for the least amount of change or complexity. We would also be interested to see how these models fare under the stress testing - we have not done that in any focused way yet, though we have kept those tests in mind. It should be noted that this model would require a minimal amount of accommodation by the Protocols and Number communities, but believe that this accommodation while not disturbing their current model in any significant way would make IANA more accountable to them as well. Thanks avri

Andrew, One concern I have about your proposed variation is the use of a NomCom like approach. The NomCom as it is configured today is made up of people who are selected by the multi-stakeholder community but once they are selected they are really not accountability to the groups that select them. They are presumably accountable to the public interest but that is an ill-defined concept that means different things to different people and I am not sure that will ever change and maybe it shouldn't except with regard to the issues of security and stability, which I think there is broad agreement. Chuck -----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Sunday, February 22, 2015 1:11 AM To: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Update on the Integrated model. Greetings, On Wed, Feb 18, 2015 at 02:09:28PM -0500, Avri Doria wrote:

The working draft, which is still a work in progress and remains open for comment can be found at: https://docs.google.com/document/d/1SvKDEIaeHdre3BQXHNe1K3hCA95dsFWqWA z2Kg5YZCU/edit?usp=sharing

I've read this. I want to thank the contributors for a serious and earnest effort. It's good to be talking about specific text.

In the draft we present three possible configurations for the model. The authors believe that Shared Service Arrangement (page 6) is the preferred configuration, as it offers the most accountability for the least amount of change or complexity.

I can see why that might be the authors' preference, but I have pretty grave doubts that it is an achievable configuration. In particular,

It should be noted that this model would require a minimal amount of accommodation by the Protocols and Number communities

at least for the protocol parameters community, I disagree pretty strongly that the accommodation is "minimal". Right now, the IETF has a simple system: it runs the policy, and it outsources the entire operation of the registry to ICANN. The IETF has to process the service statistics from IANA, and once a year there's some effort on SLAs, but this is a pretty low-overhead, outsourced-operator approach. The model in the document, particularly in the "shared service arrangement" configuration, requires significantly more effort on the part of the IETF. It's a little hard for me to see why the IETF would go for this: more work for no more benefit is always harder to sell, and the IETF has been quite clear that it is happy with the arrangements as they are. Moreover, the proposal seems to work from the assumption that the IETF's ability to leave and go elsewhere is a thing to be "mitigated", but the IETF appears to like that arrangement. I wonder, however, whether the model might not be modified slightly to deliver most of the same benefits, while still not upsetting the existing arrangements between ICANN and the RIRs or ICANN and the IETF. (This really is wondering: in the interests of getting a reaction out quickly, I haven't allowed this to bake.) In order to do this, one would start with the ICANN subsidiary configuration. But instead of changing the MOU & SLAs from the RIRs and from the IETF, those just remain with ICANN. In other words, the non-names communities see no difference. ICANN, however, would (sub)contract all IANA functions to the PTI subsidiary. Since ICANN would be the only customer, the governance of PTI could be undertaken by a board appointed by a nomcom rather than appointed by the three communities. This might well mitigate some of the worries about ICANN accountability that are listed as issues with the "subsidiary" configuration. It automatically provides a structural separation because ICANN's policy function remains firmly inside ICANN, and would put ICANN in the position of having to negotiate its agreement, SLAs, and so on with PTI. (Presumably, these negotiations would be driven by the GNSO and ccNSO, but I think that's a detail to be worked out if this approach seems promising.) The IAP, if needed, would I think be relevant to policy disputes in ICANN but not necessarily relevant to the PTI (since the latter has a nomcom-appointed board, and that could function as the appeal mechanism). A significant benefit to this approach is that it drastically minimizes changes. Indeed, for two of the three affected communities, the effect is practically nothing. The names community of course has more work to do, but it is the community has the most confused current arrangements, so this only clarifies the arrangements in the case where they need it. Because it puts IANA into a different organization that ICANN, it requires an agreement between the policy authority (or authorities) for names (within ICANN) and the IANA operator strictly construed. Presumably ICANN would also need to contract with PTI for the SLAs to satisfy ICANN's obligations to the IETF and RIRs, but I am assuming for these purposes that would be easy to do. What do people think of this somewhat more modest approach? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship

Hi, In answer to the questions: First on Nomcom. This model rest on a notion of subsidiarity acccording to operational community; if a nomcom were used it should be the nomcom of the operational community. The idea of creating a new nomcom that was 3 operational communities wide scares me more than the creation of the Contracting Co. would - then again I once chaired a WG that rewrote the rules for a single operational community Nomcom. I share some of the concerns Chuck mentioned. I also worry that if a 3 community nomcom were established, it would be uncertan who they were accountable to and who their appointees were accountable to. That shared Board Community shared accountability is one of the important accountabilty anchors in the model. I have seen in the ICANN results an uncertainty at times of whom Nomcom Appointees were accountable to. In terms of the question about a different formulation of the ICANN subsidiary configuration. Sure, as I mentioned in a email to Chuck earlier this is one option, ICANN can remain the contractor for the protocols and numbers if necessary and just use the subsidiary to do the work. While I think that this can work, the accountability anchor, while as strong as any internal model, would not be as strong as if the SLA were moved to the Post Transition IANA (PTI). I think it is worthwhile as a fall back positon if the model gets some degree of traction in the CWG. I guess I would prefer to see a higher degree of particpation offered and to have the ICG pass on a request to consider the invitation to share a greater degree of IANA responsibility and accountability. But if the more modest configuration was needed, it could work. In terms of the Community Board, I do not think of this Board as doing that much more than the NTIA, except maybe the part where they oversee IANA as a business and make sure it has sustainable financing from the parent company(ies). Perhaps this could be done as a independent board (though I am not sure such really exists). As we see now with the Congress, the NTIA does have its own accountability issues that control its activities, so I hardly think of it as an the equivalent of an independent board. NTIA is a component in a system of check and balances. I think the Community Board needs to do that as well for this model to work. If the ICANN CWG can decides to take an Integrated model further, I would like to see the offer extended to the operational communuites to share the stewardship of IANA. I think it would have been hard for the IETF or CRISP to come up with their own Integratede model where they grabbed partial control of IANA from within ICANN. I think that if we can produce an Integrated model that allows us to invite them to do so, they might just give it serious consideration. avri On 22-Feb-15 10:44, Andrew Sullivan wrote:

Hi,

On Sun, Feb 22, 2015 at 02:06:08PM +0000, Gomes, Chuck wrote:

...

One concern I have about your proposed variation is the use of a NomCom like approach. The NomCom as it is configured today is made up of people who are selected by the multi-stakeholder community but once they are selected they are really not accountability to the groups that select them. They are presumably accountable to the public interest but that is an ill-defined concept that means different things to different people and I am not sure that will ever change and maybe it shouldn't except with regard to the issues of security and stability, which I think there is broad agreement. I probably don't fully understand the worry here, but before I start I should note that this was sort of a throw-away. The real point I was trying to make is that the proposal as circulated is partly gated on getting the RIRs and IETF to appoint people to a newly-created board, on hammering out agreements (across three organizations) about how to structure that board, and maybe even on working out new legal agreements and so on. I am not convinced this will be easy. So, I was suggesting that, by using the straight subsidiary approach we might be able to skirt all those problems, and I said "nomcom" becuase it's a mechanism we're all at least somewhat familiar with. (Note that it needn't be the same nomcom as is used to build the ICANN board. These two boards ought to have different functions.)

Anyway, your worry suggests that the point of the PTI board is to represent the various groups. I suppose that's one approach, but another is to decide that the PTI board is just a board of PTI, and that representativity is not that important. This might be a practical answer if the IANA's remit is conceived narrowly enough. On the other hand, if various groups think that representativity is important enough, maybe the right thing to do is direct appointment from all the ICANN stakeholder communities, with right of recall. I wouldn't be opposed to that, _provided that_ the IANA board was clearly disempowered to be used as an appeals mechanism for policy disputes. That is, the PTI could function the way NTIA officially does in asking, "Did the ICANN process follow its own rules?" It should _not_ be permitted to try to re-examine the policy considerations that went into a decision. This is exactly the way the IANA works now. In my opinion, completely independent board appointments that cannot be recalled are actually more likely to ensure that sort of behaviour, but I can imagine an argument for the opposite conclusion.

Best regards,

A

-----Original Message----- Right now, the IETF has a simple system: it runs the policy, and it outsources the entire operation of the registry to ICANN. The IETF has to process the service statistics from IANA, and once a year there's some effort on SLAs, but this is a pretty low-overhead, outsourced-operator approach.

I really don't see how the proposed configuration differs much from that. I agree that there would be some initial setup costs, and I partially agree that IETF does not get an immediate tangible benefit from this, but I do think IETF has a very substantial long term interest in a more rational, well-structured approach to IANA. The integrated model establishes a symmetrical relationship for names, numbers and protocols and I think IETF people understand the logic and benefits of that. Also, in earlier NTIA proceedings the IETF has expressed a preference for keeping the IANA functions coordinated and under one roof, which Avri's model seems to think is very important (I personally don't agree with that). So it is in the public interest, if not the IETF's immediate private interest, to make these changes, and my experience with IETF leadership is that while they are often fiercely protective of their independence and 'self'-interest as an organization, they can also be responsive to broader calls for reforms that are in the general interest. An example of that would be the IETF's participation in the Montevideo Statement, which helped to kick this process of IANA globalization into motion.

Moreover, the proposal seems to work from the assumption that the IETF's ability to leave and go elsewhere is a thing to be "mitigated", but the IETF appears to like that arrangement.

I agree with you here, this is why I asked Avri about the separability issue.

In order to do this, one would start with the ICANN subsidiary configuration. But instead of changing the MOU & SLAs from the RIRs and from the IETF, those just remain with ICANN. In other words, the non-names communities see no difference.

I would see value in a modification of the integrated model in a way that did not require changing the IETF MoU and SLA (note that there currently is no RIR SLA/MoU, that is yet to be established afaik). But I share some of Chuck's concerns about a Nomcom.

A significant benefit to this approach is that it drastically minimizes changes. Indeed, for two of the three affected communities, the effect is practically nothing. The names community of course has more work to do, but it is the community has the most confused current arrangements, so this only clarifies the arrangements in the case where they need it. Because it puts IANA into a different organization that ICANN, it requires an agreement between the policy authority (or authorities) for names (within ICANN) and the IANA operator strictly construed. Presumably ICANN would also need to contract with PTI for the SLAs to satisfy ICANN's obligations to the IETF and RIRs, but I am assuming for these purposes that would be easy to do.

This is the kind of symmetry that I think the advocates of the integrated model, and advocates of structural separation more generally, are trying to achieve. So if you understand those benefits there is hope that a meeting of the minds can be arrived at

On 22-Feb-15 19:03, Milton L Mueller wrote:

...

...

Moreover, the proposal seems to work from the assumption that the IETF's ability to leave and go elsewhere is a thing to be "mitigated", but the IETF appears to like that arrangement. I agree with you here, this is why I asked Avri about the separability issue.

While I personally hate the idea of splitting IANA, and think it is a disastrous thing to do, it remains possible in this model as was foreordained by the ICG. I do hope the Integrated model* helps make that less likely. but if any of the 3 operational communities wants to leave, they could. avri * and it is not mine though I am representing it, at least over the weekend - i am one of three authors