Avri and CWG members / participants, Lise and I discussed this and we propose to have this as a substantive agenda item at the CWG call on Tuesday. I suggest that you come prepared to present the thinking and rationale behind the model and the CWG members / participants come prepared to question / discuss. Thanks, Jonathan From: Avri Doria [mailto:avri@acm.org] Sent: 20 February 2015 15:32 To: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Update on the Integrated model. Hi, On 19-Feb-15 18:13, Gomes, Chuck wrote: Thanks Avri. Forgive me if this was already discussed by I haven’t been able to keep up on this very well. No it has not been discussed in the CWG yet. I have hopes for the future and glad for the present opportunity. There have been many informal conversations with diverse people, i.e. anyone we could find free in Singapore and could buttonhole long enough to explain the model, but nothing formal. · Has this approach been vetted with the protocol and numbers communities? Vetted, no. Discussed informally with some participants from those operational communities, yes. Two points: -the first configuration is pretty much an ICANN internal model and other than being coordinated by the ICG probably does not need a whole lot of vetting by the other operational communities. - even the other models do not require a whole lot of change from the other operational models. But lining up the operational community's solutions is the main task of the ICG once we have come up with our solution. We were careful to keep changes required by those communities limited mostly to the degree of control they had over IANA and the contracting point of contact. Finally, there are many members of those operational communities on our lists so hopefully they have been taking a look at it as it was developing. We received anonymous comments from many people in the docs, no idea who most of them were. I would not expect any sort of formal answer from the other operational communities before the CWG has even reviewed it. At this point this is just a proposal by an ad hoc, self selected drafting team looking for an solution to the apparent impasse between the Inside and Outside models. Something for all to question and hopefully discuss in an open manner. Finally we are always happy to talk to those communities and their members, if they have an interest that predates a possible CWG decision to accept this model. As I say, there are representatives of those communities on this list and I would be happy to hear from them. As would our my partners in this project, though they are more taciturn than I am, and have given me leave to use the word 'we' (though be assured they will correct me anytime I step wrong). · What does it mean that “ICANN establishes SLAs/MoU with Post Transition IANA”? Why would ICANN be involved in this? Because in any of the configurations of the model there is a degree of separation. The fully owned subsidiary confirguartion does include full structural separation into the subsidiary. Often the interface, in cases of an fully owned entity, is an SLA/MOU. One of the stresses for the Outside model people in the CWG is that fact the the relationship between the ICANN operational community and IANA has no externalized rigor. SLAs/MOUs between a parent company and a subsidiary are one way to establish such a controlled relationship. So even in the fully owned subsidiary of ICANN, it is possible for ICANN, the parent company, to establish SLA and MOUs with its Post Transition IANA (PTI) subsidiary. In the Shared Service Arrangement, ICANN would be one of 3 operational community joint owners* establishing SLA/MOUs with their jointly owned subsidiary. · With regard to the overall status of the IANA functions operator, I understand the need for parity between the three organizations, but when it comes to each of their specific functions, I don’t see the value of parity. For example, couldn’t parity become a problem with regard to issues related to the naming functions from a naming community point of view? The CSC, in support of its SLAs with recourse to the IAP is the main point for naming community issues. The only parity issues there might be those within the CSC in terms of Registry priority within that committee and the balance within ICANN's PTI Board representation. The Post Transition IANA (PTI) Board function is limited to IANA internal operational issues, finances and exception processing. By the time an issue gets passed the IAP, which I personally hope has binding arbitration capabilities, to the Board of the PTI as an exception processing issue, it is one that would probably be broader that just a naming community issue and warrant the check and balances a board with full parity brings. · Without in any way criticizing the proposed approach, isn’t the new IANA board a new architectural feature Criticism is fine, this is an out of the box proposal meant to solve a nearly intractable problem amongst the Inside model, the Outside model and Republicans in the US congress. If it can't deal with criticism it isn't going to get very far. Criticism is the fuel of improvement. And this model, as all models, needs improvement only broader discussions, i.e. criticism, self criticism and further work, can bring. Yes the model includes new architectural features, just as the CSC, MRT and IAP are. In fact it is a variation on the mainstream theme, though like in the internal models, the Contract Co has been eliminated, so one less new feature to deal with. But indeed it does need meet the accountability test that Strickling mentioned for new components. Working on a draft on that now. Pretty close too, just waitng for one of the team to get back from vacation and check it out before opening it up for wider criticism and discussion. · Has any thought been put into the source of funding? Yes. In the wholly own subsidiary, ICANN subsidizes, as it owns it. Really no diffferent that it does now, just with a more transparent and specific budget. In the Shared Service Arrangements, it is shared between the owners (IETF/IAB/ISOC, ICANN & RIRs/NRO) in some way they agree on. I understand that the numbers community already contributes a significiant sum to ICANN operations, perhaps some part of it is intended for IANA operations and would be redirected. As for the protocol community, I expect the others would continue to carry them given their nature as a subsidized volunteer group that takes in no income but which remains critical to the IANA ecosystem and the Internet itself. In the Free Standing configuration, I haven't really thought about funding, though perhaps others in the team have. I would assume a model that included startup investment from the operational communities, and perhaps others, and the development of a fund raising, or income producing, strategy by its Board. Just like any other free standing company. I think anyone who championed that confdiguration would need to get mode specific on those details. · Who would have MOUs with the Post Transition IANA? They would be between Post Transition IANA (PTI) and each its customers: IETF/IAB/ISOC, ICANN, & RIRs/NRO Not sure what you mean by "who holds them?" I suppose in the fully subsidized configuration, the parent compnay ICANN could still hold the SLA/MOUs the for the protocol and number operational communities, if they wanted to continue contracting with ICANN instead of PTI. This would require a slight variation on the subsidiary configuration, but could be defined. Ie. ICANN would remain repsonsble for meeting the SLA, and it would use its fully own IANA subsidiary to do the work. · In the ICANN subsidiary, shared services and free-standing diagrams, why is ICANN shown as one of three elements of the Post Transition IANA Board? The Board is made up of the three operational communities, each of which brings it paticualr multstakeholder mix to the table. ICANN, our CWG community, is one of the 3 operational communities and thus should bring its multistakeholder mix to the PTI Board. I appreciate the thought that has gone into this. And I yours. Thanks avri * The model also allows for separate SLA/MOUS with the the non participating ccTLDs if necessary - the the PTI Board makes no accommodation for that at this point - a complexity we did not tackle. The model is based on the notion that each of the operational communities internalizes its own multistakeholder churn, but we recognize that some of the churn cannot always be internalized. Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Avri Doria Sent: Wednesday, February 18, 2015 2:09 PM To: 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

I would follow on Jonathan & Lise's note and suggest that a "stable" draft of this proposal be ready for circulation on Monday, at least 24 hours before Tuesday's call. It should either be distributed with the agenda or with a cover email expressly stating that this will be discussed on the Tuesday call and should be reviewed beforehand so that we have an informed set of participants. Greg On Fri, Feb 20, 2015 at 12:01 PM, Avri Doria <avri@acm.org> wrote:

Hi,

Thanks. Happy to do so.

avri

On 20-Feb-15 11:56, Jonathan Robinson wrote:

Avri and CWG members / participants,

Lise and I discussed this and we propose to have this as a substantive agenda item at the CWG call on Tuesday.

I suggest that you come prepared to present the thinking and rationale behind the model and the CWG members / participants come prepared to question / discuss.

Thanks,

Jonathan

*From:* Avri Doria [mailto:avri@acm.org <avri@acm.org>] *Sent:* 20 February 2015 15:32 *To:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Update on the Integrated model.

Hi,

On 19-Feb-15 18:13, Gomes, Chuck wrote:

Thanks Avri. Forgive me if this was already discussed by I haven’t been able to keep up on this very well.

No it has not been discussed in the CWG yet. I have hopes for the future and glad for the present opportunity.

There have been many informal conversations with diverse people, i.e. anyone we could find free in Singapore and could buttonhole long enough to explain the model, but nothing formal.

· Has this approach been vetted with the protocol and numbers communities?

Vetted, no.

Discussed informally with some participants from those operational communities, yes.

Two points:

-the first configuration is pretty much an ICANN internal model and other than being coordinated by the ICG probably does not need a whole lot of vetting by the other operational communities.

- even the other models do not require a whole lot of change from the other operational models. But lining up the operational community's solutions is the main task of the ICG once we have come up with our solution. We were careful to keep changes required by those communities limited mostly to the degree of control they had over IANA and the contracting point of contact.

Finally, there are many members of those operational communities on our lists so hopefully they have been taking a look at it as it was developing. We received anonymous comments from many people in the docs, no idea who most of them were.

I would not expect any sort of formal answer from the other operational communities before the CWG has even reviewed it. At this point this is just a proposal by an ad hoc, self selected drafting team looking for an solution to the apparent impasse between the Inside and Outside models. Something for all to question and hopefully discuss in an open manner.

Finally we are always happy to talk to those communities and their members, if they have an interest that predates a possible CWG decision to accept this model. As I say, there are representatives of those communities on this list and I would be happy to hear from them. As would our my partners in this project, though they are more taciturn than I am, and have given me leave to use the word 'we' (though be assured they will correct me anytime I step wrong).

· What does it mean that “ICANN establishes SLAs/MoU with Post Transition IANA”? Why would ICANN be involved in this?

Because in any of the configurations of the model there is a degree of separation. The fully owned subsidiary confirguartion does include full structural separation into the subsidiary. Often the interface, in cases of an fully owned entity, is an SLA/MOU. One of the stresses for the Outside model people in the CWG is that fact the the relationship between the ICANN operational community and IANA has no externalized rigor. SLAs/MOUs between a parent company and a subsidiary are one way to establish such a controlled relationship.

So even in the fully owned subsidiary of ICANN, it is possible for ICANN, the parent company, to establish SLA and MOUs with its Post Transition IANA (PTI) subsidiary.

In the Shared Service Arrangement, ICANN would be one of 3 operational community joint owners* establishing SLA/MOUs with their jointly owned subsidiary.

· With regard to the overall status of the IANA functions operator, I understand the need for parity between the three organizations, but when it comes to each of their specific functions, I don’t see the value of parity. For example, couldn’t parity become a problem with regard to issues related to the naming functions from a naming community point of view?

The CSC, in support of its SLAs with recourse to the IAP is the main point for naming community issues. The only parity issues there might be those within the CSC in terms of Registry priority within that committee and the balance within ICANN's PTI Board representation.

The Post Transition IANA (PTI) Board function is limited to IANA internal operational issues, finances and exception processing.

By the time an issue gets passed the IAP, which I personally hope has binding arbitration capabilities, to the Board of the PTI as an exception processing issue, it is one that would probably be broader that just a naming community issue and warrant the check and balances a board with full parity brings.

· Without in any way criticizing the proposed approach, isn’t the new IANA board a new architectural feature

Criticism is fine, this is an out of the box proposal meant to solve a nearly intractable problem amongst the Inside model, the Outside model and Republicans in the US congress. If it can't deal with criticism it isn't going to get very far. Criticism is the fuel of improvement. And this model, as all models, needs improvement only broader discussions, i.e. criticism, self criticism and further work, can bring.

Yes the model includes new architectural features, just as the CSC, MRT and IAP are. In fact it is a variation on the mainstream theme, though like in the internal models, the Contract Co has been eliminated, so one less new feature to deal with.

But indeed it does need meet the accountability test that Strickling mentioned for new components.

Working on a draft on that now. Pretty close too, just waitng for one of the team to get back from vacation and check it out before opening it up for wider criticism and discussion.

· Has any thought been put into the source of funding?

Yes.

In the wholly own subsidiary, ICANN subsidizes, as it owns it. Really no diffferent that it does now, just with a more transparent and specific budget.

In the Shared Service Arrangements, it is shared between the owners (IETF/IAB/ISOC, ICANN & RIRs/NRO) in some way they agree on. I understand that the numbers community already contributes a significiant sum to ICANN operations, perhaps some part of it is intended for IANA operations and would be redirected. As for the protocol community, I expect the others would continue to carry them given their nature as a subsidized volunteer group that takes in no income but which remains critical to the IANA ecosystem and the Internet itself.

In the Free Standing configuration, I haven't really thought about funding, though perhaps others in the team have. I would assume a model that included startup investment from the operational communities, and perhaps others, and the development of a fund raising, or income producing, strategy by its Board. Just like any other free standing company. I think anyone who championed that confdiguration would need to get mode specific on those details.

· Who would have MOUs with the Post Transition IANA?

They would be between Post Transition IANA (PTI) and each its customers: IETF/IAB/ISOC, ICANN, & RIRs/NRO Not sure what you mean by "who holds them?"

I suppose in the fully subsidized configuration, the parent compnay ICANN could still hold the SLA/MOUs the for the protocol and number operational communities, if they wanted to continue contracting with ICANN instead of PTI. This would require a slight variation on the subsidiary configuration, but could be defined. Ie. ICANN would remain repsonsble for meeting the SLA, and it would use its fully own IANA subsidiary to do the work.

· In the ICANN subsidiary, shared services and free-standing diagrams, why is ICANN shown as one of three elements of the Post Transition IANA Board?

The Board is made up of the three operational communities, each of which brings it paticualr multstakeholder mix to the table. ICANN, our CWG community, is one of the 3 operational communities and thus should bring its multistakeholder mix to the PTI Board.

I appreciate the thought that has gone into this.

And I yours.

Thanks avri

* The model also allows for separate SLA/MOUS with the the non participating ccTLDs if necessary - the the PTI Board makes no accommodation for that at this point - a complexity we did not tackle. The model is based on the notion that each of the operational communities internalizes its own multistakeholder churn, but we recognize that some of the churn cannot always be internalized.

Chuck

*From:* cwg-stewardship-bounces@icann.org [ mailto:cwg-stewardship-bounces@icann.org <cwg-stewardship-bounces@icann.org>] *On Behalf Of *Avri Doria *Sent:* Wednesday, February 18, 2015 2:09 PM *To:* 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

_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship

Hi, While the document is fairly stable, conceptually, as of the last PDF I sent out, I will send out an updated snapshot on Monday that tries to take into account the questions we are receiving. Some of the questions show that the document could be clearer. I will also include a snapshot of any other the other expository docs we are working on. avri On 20-Feb-15 12:13, Greg Shatan wrote:

I would follow on Jonathan & Lise's note and suggest that a "stable" draft of this proposal be ready for circulation on Monday, at least 24 hours before Tuesday's call. It should either be distributed with the agenda or with a cover email expressly stating that this will be discussed on the Tuesday call and should be reviewed beforehand so that we have an informed set of participants.

Greg

On Fri, Feb 20, 2015 at 12:01 PM, Avri Doria <avri@acm.org <mailto:avri@acm.org>> wrote:

Hi,

Thanks. Happy to do so.

avri

On 20-Feb-15 11:56, Jonathan Robinson wrote:

...

Avri and CWG members / participants,

Lise and I discussed this and we propose to have this as a substantive agenda item at the CWG call on Tuesday.

I suggest that you come prepared to present the thinking and rationale behind the model and the CWG members / participants come prepared to question / discuss.

Thanks,

Jonathan

*From:*Avri Doria [mailto:avri@acm.org] *Sent:* 20 February 2015 15:32 *To:* cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> *Subject:* Re: [CWG-Stewardship] Update on the Integrated model.

Hi,

On 19-Feb-15 18:13, Gomes, Chuck wrote:

Thanks Avri. Forgive me if this was already discussed by I haven’t been able to keep up on this very well.

No it has not been discussed in the CWG yet. I have hopes for the future and glad for the present opportunity.

There have been many informal conversations with diverse people, i.e. anyone we could find free in Singapore and could buttonhole long enough to explain the model, but nothing formal.

· Has this approach been vetted with the protocol and numbers communities?

Vetted, no.

Discussed informally with some participants from those operational communities, yes.

Two points:

-the first configuration is pretty much an ICANN internal model and other than being coordinated by the ICG probably does not need a whole lot of vetting by the other operational communities.

- even the other models do not require a whole lot of change from the other operational models. But lining up the operational community's solutions is the main task of the ICG once we have come up with our solution. We were careful to keep changes required by those communities limited mostly to the degree of control they had over IANA and the contracting point of contact.

Finally, there are many members of those operational communities on our lists so hopefully they have been taking a look at it as it was developing. We received anonymous comments from many people in the docs, no idea who most of them were.

I would not expect any sort of formal answer from the other operational communities before the CWG has even reviewed it. At this point this is just a proposal by an ad hoc, self selected drafting team looking for an solution to the apparent impasse between the Inside and Outside models. Something for all to question and hopefully discuss in an open manner.

Finally we are always happy to talk to those communities and their members, if they have an interest that predates a possible CWG decision to accept this model. As I say, there are representatives of those communities on this list and I would be happy to hear from them. As would our my partners in this project, though they are more taciturn than I am, and have given me leave to use the word 'we' (though be assured they will correct me anytime I step wrong).

· What does it mean that “ICANN establishes SLAs/MoU with Post Transition IANA”? Why would ICANN be involved in this?

Because in any of the configurations of the model there is a degree of separation. The fully owned subsidiary confirguartion does include full structural separation into the subsidiary. Often the interface, in cases of an fully owned entity, is an SLA/MOU. One of the stresses for the Outside model people in the CWG is that fact the the relationship between the ICANN operational community and IANA has no externalized rigor. SLAs/MOUs between a parent company and a subsidiary are one way to establish such a controlled relationship.

So even in the fully owned subsidiary of ICANN, it is possible for ICANN, the parent company, to establish SLA and MOUs with its Post Transition IANA (PTI) subsidiary.

In the Shared Service Arrangement, ICANN would be one of 3 operational community joint owners* establishing SLA/MOUs with their jointly owned subsidiary.

· With regard to the overall status of the IANA functions operator, I understand the need for parity between the three organizations, but when it comes to each of their specific functions, I don’t see the value of parity. For example, couldn’t parity become a problem with regard to issues related to the naming functions from a naming community point of view?

The CSC, in support of its SLAs with recourse to the IAP is the main point for naming community issues. The only parity issues there might be those within the CSC in terms of Registry priority within that committee and the balance within ICANN's PTI Board representation.

The Post Transition IANA (PTI) Board function is limited to IANA internal operational issues, finances and exception processing.

By the time an issue gets passed the IAP, which I personally hope has binding arbitration capabilities, to the Board of the PTI as an exception processing issue, it is one that would probably be broader that just a naming community issue and warrant the check and balances a board with full parity brings.

· Without in any way criticizing the proposed approach, isn’t the new IANA board a new architectural feature

Criticism is fine, this is an out of the box proposal meant to solve a nearly intractable problem amongst the Inside model, the Outside model and Republicans in the US congress. If it can't deal with criticism it isn't going to get very far. Criticism is the fuel of improvement. And this model, as all models, needs improvement only broader discussions, i.e. criticism, self criticism and further work, can bring.

Yes the model includes new architectural features, just as the CSC, MRT and IAP are. In fact it is a variation on the mainstream theme, though like in the internal models, the Contract Co has been eliminated, so one less new feature to deal with.

But indeed it does need meet the accountability test that Strickling mentioned for new components.

Working on a draft on that now. Pretty close too, just waitng for one of the team to get back from vacation and check it out before opening it up for wider criticism and discussion.

· Has any thought been put into the source of funding?

Yes.

In the wholly own subsidiary, ICANN subsidizes, as it owns it. Really no diffferent that it does now, just with a more transparent and specific budget.

In the Shared Service Arrangements, it is shared between the owners (IETF/IAB/ISOC, ICANN & RIRs/NRO) in some way they agree on. I understand that the numbers community already contributes a significiant sum to ICANN operations, perhaps some part of it is intended for IANA operations and would be redirected. As for the protocol community, I expect the others would continue to carry them given their nature as a subsidized volunteer group that takes in no income but which remains critical to the IANA ecosystem and the Internet itself.

In the Free Standing configuration, I haven't really thought about funding, though perhaps others in the team have. I would assume a model that included startup investment from the operational communities, and perhaps others, and the development of a fund raising, or income producing, strategy by its Board. Just like any other free standing company. I think anyone who championed that confdiguration would need to get mode specific on those details.

· Who would have MOUs with the Post Transition IANA?

They would be between Post Transition IANA (PTI) and each its customers: IETF/IAB/ISOC, ICANN, & RIRs/NRO Not sure what you mean by "who holds them?"

I suppose in the fully subsidized configuration, the parent compnay ICANN could still hold the SLA/MOUs the for the protocol and number operational communities, if they wanted to continue contracting with ICANN instead of PTI. This would require a slight variation on the subsidiary configuration, but could be defined. Ie. ICANN would remain repsonsble for meeting the SLA, and it would use its fully own IANA subsidiary to do the work.

· In the ICANN subsidiary, shared services and free-standing diagrams, why is ICANN shown as one of three elements of the Post Transition IANA Board?

The Board is made up of the three operational communities, each of which brings it paticualr multstakeholder mix to the table. ICANN, our CWG community, is one of the 3 operational communities and thus should bring its multistakeholder mix to the PTI Board.

I appreciate the thought that has gone into this.

And I yours.

Thanks avri

* The model also allows for separate SLA/MOUS with the the non participating ccTLDs if necessary - the the PTI Board makes no accommodation for that at this point - a complexity we did not tackle. The model is based on the notion that each of the operational communities internalizes its own multistakeholder churn, but we recognize that some of the churn cannot always be internalized.

Chuck

*From:* cwg-stewardship-bounces@icann.org <mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] *On Behalf Of *Avri Doria *Sent:* Wednesday, February 18, 2015 2:09 PM *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

_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship

prematurely sent. needed to remove the dangling Finally and sign it. avri On 20-Feb-15 18:18, Avri Doria wrote:

On 20-Feb-15 16:50, Milton L Mueller wrote:

...

My question:

Does this model provide for separability?

First it provides structural separation in all configurations. That is a first level of severability and hopefully as much as really is ever needed. Additionally, in this model, ICANN would have the same ability to pick another provider, or perhaps a redundant provider, just as the names or protocols can now. This is made possible by virtue of structural separation and the defintion of SLA/MOUs across a corporate boundary.

Further levels of separability can, however, be obtained in the Shared Service Arrangement configuration or the finally in the Free Standing configuration.

Finally

_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship

On 21-Feb-15 01:08, Seun Ojedeji wrote:

Hi,

How does this proposal address the few points below:

- ICANN is running IANA properly and should continue to be the operator

This proposal rest upon the same team being able to continue handling the operator functions. The 12 person IANA team is what is doing the job properly and what needs protecting in a stewardship transition. In the fully owned subsidiary configuration, ICANN remains the operator, or rather the owner or the operator. In the Shared Service Arrangement ICANN remains one of the owners. In this operational control is shared with the other operational communities while ICANN remains a co-owner, has SLA/MOUs and a board seats. It is only in the Free Standing configuration that ICANN would cease being an owner of a subsidiary though would probably remain owners, perhaps even members, of the Free Standing company. And would retain Community Board seats.

- ICANN is purpose built with it's main purpose of centrally operating IANA for the 3 communities

While this may have been the intention at day 0, the evolution of ICANN over the years has been anything but purpose built. ICANN has evolved into a much needed policy group that deals with the political, financial and other issues that grow out of its narrow technical mandate. The remaining issue that has not been solved in the Internal models is the one where the policy organization for gTLDS, the bulk of ICANN's 100+ MUSD operations is not separated from IANA.

- The task at hand is to transition IANA stewardship, is the proposal not doing more than that?

Not really. Especially the model is very much about stewardship and finding ways to distribute that stewardship in the light of losing NTIA. In one configuration, ICANN retains complete control, just of a structurally separated internal component that provides greater transparency. In the Shared Service Arrangement, IANA shares this ownership with the other 2 communities, if they are interested in sharing. If they aren't, I figure they will be fine with leaving it as a full Owned subsidiary of ICANN.

- Based on the response given by Milton, the practical implication of this proposal seem to imply absolute separation between IANA functions so names operation is no longer under ICANN oversight. If that is correct are we still within scope of our task by proposing that?

I do not speak for Milton, that is beyond my pay grade. While there is structural separation it is not absolute - currently some try to argue that there is functional separation at ICANN as required by NTIA in the RFP, though some of us have our doubts on this actually being the case, especially since IANA isn't even as separated as is GDD. Not all separation is the same or absolute. In two of the configurations, that structural separation is contained within the existing organizations and remains under ICANN protection. Even in the Free Standing configuration, ICANN remains on of the controling voices on the Community Board. ICANN retains its share of the stewardship role in all of the configurations in the model. In no part of the model, and in none of it configurations is the separation complete or absolute. And remember we allegedly have functional separation today. This model is just an evolution of current realities with as little disruption as possible. In fact for absolute or complete separation in this model, ICANN would have to utilize the same so-called nuclear option the other two operational communities are posting, the ability to take their business elsewhere. None of the configurations offered provides absolute separation. I see nothing that excludes this from our scope to find the best stewardship solution we can given the constraint of multistakeholder general agreement. We face an impasse with strong smart people insisting they are correct on two very opposed sides of the discussion. We can continue the tug of war about who is right; constantly worrying over who has the better argument of the day or the best allies. Perhaps we can even engage in some brinkmanship - just like US political leaders. We decided to try to find a solution that satisfies many of the concerns of both camps without scaring those who are watching.

- What does the proposal intend to address; separability OR separation?

It is attempting to balance the most critical requirements for a multistakeholder solution, an Internal solution and also for an External solution, and one that is solid, stable and safe from International capture enough to satisfy Republicans in Congress as well. It is meant to be a reasonable and based on a relatively standard business relationship that provides the multistakeholder control through ownership, sla/mous, and membership in the Post Transition Board. Separability is a principle that all solutions must satisfy, but it is not a goal. The goal is stewardship for a multistakeholder, stable, secure and resilient IANA. The secondary goal was making the solution as simple as possible with as little reliance on CCWG-Accountabilty fundamental change as possible. thanks avri

Thanks

Regards sent from Google nexus 4 kindly excuse brevity and typos.

On 21 Feb 2015 00:19, "Avri Doria" <avri@acm.org <mailto:avri@acm.org>> wrote:

On 20-Feb-15 16:50, Milton L Mueller wrote:

...

My question:

Does this model provide for separability?

First it provides structural separation in all configurations. That is a first level of severability and hopefully as much as really is ever needed. Additionally, in this model, ICANN would have the same ability to pick another provider, or perhaps a redundant provider, just as the names or protocols can now. This is made possible by virtue of structural separation and the defintion of SLA/MOUs across a corporate boundary.

Further levels of separability can, however, be obtained in the Shared Service Arrangement configuration or the finally in the Free Standing configuration.

Finally

_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship

Hey Seun, A quick comment on this paragraph:

Thanks for the explanation which was quite helpful. I must say the more i try to process this, the more it seem that the proposal attempts to practically create a new operator order than ICANN (re: PTI) being the operator and turns ICANN to a "policy only" organisation. That seem like a major change in the Internet Corporation for Assigned Names and Numbers (ICANN) mission and purpose. How will this work with ccTLDs who for instance are practically engaging with ICANN just because it is the IANA operator? how about existing gTLD contracts which were signed with the intent of ICANN being the operator?

I think it’s important to remember that the IANA functions are not something that should be considered integral to ICANN, they are currently operated by ICANN under contract from NTIA, and it has been repeated on a number of occasions that the concept of separability is very important to a large number of people involved in this process. I think it may be a dangerous road to go down to suggest that IANA may never be moved out of ICANN as that would imply that any IANA accountability measures would have no recourse to move the IANA contract way from ICANN. If there are barriers to that separability then we need to example these as part of any model that has a separability clause. As has been developed within the RIR and IETF submissions, I think that it’s important that no matter what solution we end up deciding on that the ability for the IANA functions to sustain operations regardless of its home should be at the core of discussions. This needs to be captured as part of the stress tests and should be one of the core concepts in my opinion, the survivability of the IANA functions is paramount over any considerations of home/operator/jurisdiction. From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Seun Ojedeji Sent: Sunday, February 22, 2015 5:38 PM To: Avri Doria Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Update on the Integrated model. Hello Avri, Thanks for the explanation which was quite helpful. I must say the more i try to process this, the more it seem that the proposal attempts to practically create a new operator order than ICANN (re: PTI) being the operator and turns ICANN to a "policy only" organisation. That seem like a major change in the Internet Corporation for Assigned Names and Numbers (ICANN) mission and purpose. How will this work with ccTLDs who for instance are practically engaging with ICANN just because it is the IANA operator? how about existing gTLD contracts which were signed with the intent of ICANN being the operator? Looking at the proposal, how do we achieve accountability of the "community board"? i mean why should one be comfortable that the "community board" will be more accountable than the current ICANN board? even if they are, why can't some of the proposed characteristics of the "community board" be suggested within the CCWG in other to make ICANN board more accountable? I am overly concerned that we may be creating multiple structures and too many accountability points that could overall cripple the already efficient IANA department. As you have also noted in the proposal; the outcome of the CCWG activities may indeed handle the accountability issues that the proposal attempts to address, just that it seem you don't think the implementation of the outcome will be timely? and i believe you are speaking from experience (re: ATRT). However, i think things may be different this time and one could have faith in the CCWG process considering that NTIA categorically emphasised that outcome of ccwg with that of ICG is a prerequisite to transition. That said, i appreciate the intent of separating IANA operation from the policy side of ICANN. Although one may argue that such septation already exist (with IANA being a department in ICANN) and can be maintained "through relevant addition to the bylaw" in the absence of NTIA contract. Finally, its good to note that we now have 7 CWG proposals (yes Avri's is practically 3 in 1). From all the proposals, the IAP and CSC seem to cut across (in terms of their role). Maybe we should pick the CSC and review its role and composition to ensure that it transparently provides it outcome to the entirely community. Utilising the outcome of the CSC to keep the board/IANA staff accountable is what CCWG could then worry about. This would avoid duplication of accountability mechanism to ensure maintenance of a stable, secure and resilient IANA Regards PS: These are personal views only! On Sat, Feb 21, 2015 at 6:09 PM, Avri Doria <avri@acm.org<mailto:avri@acm.org>> wrote: On 21-Feb-15 01:08, Seun Ojedeji wrote: Hi, How does this proposal address the few points below: - ICANN is running IANA properly and should continue to be the operator This proposal rest upon the same team being able to continue handling the operator functions. The 12 person IANA team is what is doing the job properly and what needs protecting in a stewardship transition. In the fully owned subsidiary configuration, ICANN remains the operator, or rather the owner or the operator. In the Shared Service Arrangement ICANN remains one of the owners. In this operational control is shared with the other operational communities while ICANN remains a co-owner, has SLA/MOUs and a board seats. It is only in the Free Standing configuration that ICANN would cease being an owner of a subsidiary though would probably remain owners, perhaps even members, of the Free Standing company. And would retain Community Board seats. - ICANN is purpose built with it's main purpose of centrally operating IANA for the 3 communities While this may have been the intention at day 0, the evolution of ICANN over the years has been anything but purpose built. ICANN has evolved into a much needed policy group that deals with the political, financial and other issues that grow out of its narrow technical mandate. The remaining issue that has not been solved in the Internal models is the one where the policy organization for gTLDS, the bulk of ICANN's 100+ MUSD operations is not separated from IANA. - The task at hand is to transition IANA stewardship, is the proposal not doing more than that? Not really. Especially the model is very much about stewardship and finding ways to distribute that stewardship in the light of losing NTIA. In one configuration, ICANN retains complete control, just of a structurally separated internal component that provides greater transparency. In the Shared Service Arrangement, IANA shares this ownership with the other 2 communities, if they are interested in sharing. If they aren't, I figure they will be fine with leaving it as a full Owned subsidiary of ICANN. - Based on the response given by Milton, the practical implication of this proposal seem to imply absolute separation between IANA functions so names operation is no longer under ICANN oversight. If that is correct are we still within scope of our task by proposing that? I do not speak for Milton, that is beyond my pay grade. While there is structural separation it is not absolute - currently some try to argue that there is functional separation at ICANN as required by NTIA in the RFP, though some of us have our doubts on this actually being the case, especially since IANA isn't even as separated as is GDD. Not all separation is the same or absolute. In two of the configurations, that structural separation is contained within the existing organizations and remains under ICANN protection. Even in the Free Standing configuration, ICANN remains on of the controling voices on the Community Board. ICANN retains its share of the stewardship role in all of the configurations in the model. In no part of the model, and in none of it configurations is the separation complete or absolute. And remember we allegedly have functional separation today. This model is just an evolution of current realities with as little disruption as possible. In fact for absolute or complete separation in this model, ICANN would have to utilize the same so-called nuclear option the other two operational communities are posting, the ability to take their business elsewhere. None of the configurations offered provides absolute separation. I see nothing that excludes this from our scope to find the best stewardship solution we can given the constraint of multistakeholder general agreement. We face an impasse with strong smart people insisting they are correct on two very opposed sides of the discussion. We can continue the tug of war about who is right; constantly worrying over who has the better argument of the day or the best allies. Perhaps we can even engage in some brinkmanship - just like US political leaders. We decided to try to find a solution that satisfies many of the concerns of both camps without scaring those who are watching. - What does the proposal intend to address; separability OR separation? It is attempting to balance the most critical requirements for a multistakeholder solution, an Internal solution and also for an External solution, and one that is solid, stable and safe from International capture enough to satisfy Republicans in Congress as well. It is meant to be a reasonable and based on a relatively standard business relationship that provides the multistakeholder control through ownership, sla/mous, and membership in the Post Transition Board. Separability is a principle that all solutions must satisfy, but it is not a goal. The goal is stewardship for a multistakeholder, stable, secure and resilient IANA. The secondary goal was making the solution as simple as possible with as little reliance on CCWG-Accountabilty fundamental change as possible. thanks avri Thanks Regards sent from Google nexus 4 kindly excuse brevity and typos. On 21 Feb 2015 00:19, "Avri Doria" <avri@acm.org<mailto:avri@acm.org>> wrote: On 20-Feb-15 16:50, Milton L Mueller wrote: My question: Does this model provide for separability? First it provides structural separation in all configurations. That is a first level of severability and hopefully as much as really is ever needed. Additionally, in this model, ICANN would have the same ability to pick another provider, or perhaps a redundant provider, just as the names or protocols can now. This is made possible by virtue of structural separation and the defintion of SLA/MOUs across a corporate boundary. Further levels of separability can, however, be obtained in the Shared Service Arrangement configuration or the finally in the Free Standing configuration. Finally _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng Mobile: +2348035233535 alt email: <http://goog_1872880453> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view !

On Feb 22, 2015, at 1:22 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:

The IANA function is really extremely small. It's a critical but basically boring book-keeping function. As near as I can tell, there have been practically no cases where there was any accusation that IANA did not do exactly what it was supposed to do. There were historically some complaints that IANA didn't act expeditiously, and there were _lots_ of historic complaints that an IANA function was being used by ICANN to try to impose ICANN policies. The former is an SLA issue; the latter is actually a policy matter with enforcement attempts in the policy side of the organization, and is not actually an issue with IANA at all. So in my opinion, accountability _for IANA_ would help with the SLA stuff (and also with the case that IANA "goes rogue") but would not help with the policy issues.

Does that match the accountability concerns others have?

Possibly as a help in thinking about this question…. There's a question here of what people are being held accountable *for*. In addition to separability as a final backstop, the other feature of the model the IETF has, and the RIRs are seeking, is that their contractor for the IANA functions that affect them is held accountable for two things: 1. Doing what they're told, in a timely and correct fashion 2. Not doing anything else If the contractor doesn't do things they *are* supposed to do, or does things they are *not* supposed to do, they're accountable for their poor performance-- but the directions come from the policy body, as implementation of its policies, and the contractor's accountability is to the policy body. In ICANN's case, this is where the Board's accountability touches IANA as an operational function, and is separate from any role of the Board or accountability of the Board regarding ICANN as a policy body. The contractor is not accountable for following improper directions from the policy body, as long as the agreed-upon processes between the policy body and the contractor are followed. It doesn't matter whether those directions are improper because process wasn't followed internally to the policy body, or because properly-executed policy nonetheless leads to unacceptable outcomes. In both of those cases, there's no wrongdoing by the contractor, and the only accountability that matters is that of the policy body to its users. In the IETF model, accountability for making bad decisions about what to tell IANA to do is maintained in a number of ways, but they're outside of the IANA SLAs and I don't see any of them changing in the event that a new contractor is selected for the protocol parameters registries. Bluntly, isn't the major accountability concern for root zone management that ICANN will give inappropriate directions to IANA staff in the course of implementing policy? If so, in the case we're concerned about, what's broken is the policy body. Changing the status of IANA staff from employees to outside contractors, or changing contractors, wouldn't help at all; the problem is internal to the policy body, and any IANA contractor (internal or external) would be obligated just the same to follow its directions. The place to prevent or stop or fix the results of bad directions to IANA is in ICANN, not IANA. I think this argues that the group needs to refine the definition of what kind of accountability belongs in the IANA transition discussion. It also argues for some care in applying the IETF/RIRs' model for names, or expecting them to participate in a model that may fit names better than protocol parameters or addresses. Suzanne

On Feb 22, 2015, at 2:54 PM, "Jonathan Robinson" <jrobinson@afilias.info> wrote:

Suzanne,

Thanks for this.

The points you make below are interesting to me because they happen to align with my current understanding on the issue (of IANA accountability AOT ICANN accountability).

Moreover, it seems to me that dealing with an intransigent IANA here (i.e. a contractor that does not do things they *are* supposed to do, or does things they are *not* supposed to do) is the point where an Independent Appeals Process may be relevant. And this (the conditions for when an IAP may be relevant) represents to me a good example of the type of focused issue of what I had envisaged a design team might be able to work on.

From experience of outsourcing various services, it seems to me that it's important to understand where those risks lie-- an incompetent contractor, not following orders it's been given; or a policy body that's behaving incompetently or improperly by giving inappropriate direction for implementation. (An imperfect but easy analogy from the commercial world is in outsourcing certain administrative services, then discovering costs aren't going down and management overhead is going up because the Accounting department doesn't know how to generate proper direction for its outsourced A/R staff any more than it did for its employee A/R staff.) Much of the discussion we've been having may be placing some of the accountability in the wrong place, by assuming that firing the policy implementation body would fix issues that are really the result of inappropriate directions from the policy-making body. In any case I agree it's a reasonable discussion to have in the context of what we're really trying to accomplish in the CWG, and would benefit from some focus. Suzanne

From: Suzanne Woolf [mailto:suzworldwide@gmail.com] Sent: 22 February 2015 18:48 To: Andrew Sullivan Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Update on the Integrated model.

On Feb 22, 2015, at 1:22 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:

The IANA function is really extremely small. It's a critical but basically boring book-keeping function. As near as I can tell, there have been practically no cases where there was any accusation that IANA did not do exactly what it was supposed to do. There were historically some complaints that IANA didn't act expeditiously, and there were _lots_ of historic complaints that an IANA function was being used by ICANN to try to impose ICANN policies. The former is an SLA issue; the latter is actually a policy matter with enforcement attempts in the policy side of the organization, and is not actually an issue with IANA at all. So in my opinion, accountability _for IANA_ would help with the SLA stuff (and also with the case that IANA "goes rogue") but would not help with the policy issues.

Does that match the accountability concerns others have?

Possibly as a help in thinking about this question….

There's a question here of what people are being held accountable *for*.

In addition to separability as a final backstop, the other feature of the model the IETF has, and the RIRs are seeking, is that their contractor for the IANA functions that affect them is held accountable for two things: 1. Doing what they're told, in a timely and correct fashion 2. Not doing anything else

If the contractor doesn't do things they *are* supposed to do, or does things they are *not* supposed to do, they're accountable for their poor performance-- but the directions come from the policy body, as implementation of its policies, and the contractor's accountability is to the policy body. In ICANN's case, this is where the Board's accountability touches IANA as an operational function, and is separate from any role of the Board or accountability of the Board regarding ICANN as a policy body.

The contractor is not accountable for following improper directions from the policy body, as long as the agreed-upon processes between the policy body and the contractor are followed. It doesn't matter whether those directions are improper because process wasn't followed internally to the policy body, or because properly-executed policy nonetheless leads to unacceptable outcomes. In both of those cases, there's no wrongdoing by the contractor, and the only accountability that matters is that of the policy body to its users.

In the IETF model, accountability for making bad decisions about what to tell IANA to do is maintained in a number of ways, but they're outside of the IANA SLAs and I don't see any of them changing in the event that a new contractor is selected for the protocol parameters registries.

Bluntly, isn't the major accountability concern for root zone management that ICANN will give inappropriate directions to IANA staff in the course of implementing policy? If so, in the case we're concerned about, what's broken is the policy body. Changing the status of IANA staff from employees to outside contractors, or changing contractors, wouldn't help at all; the problem is internal to the policy body, and any IANA contractor (internal or external) would be obligated just the same to follow its directions. The place to prevent or stop or fix the results of bad directions to IANA is in ICANN, not IANA.

I think this argues that the group needs to refine the definition of what kind of accountability belongs in the IANA transition discussion. It also argues for some care in applying the IETF/RIRs' model for names, or expecting them to participate in a model that may fit names better than protocol parameters or addresses.

Suzanne

On the dividing line point -- are we as a group going to deal with "ICANN problem" accountability, or only with "IANA problem" accountability? I think we've strayed into the former and should pull back, but we can't pull back so far that we fail to deal with the latter. Finally, I think this also impacts the scope of the IAP (at least as a CWG program): should we be creating an appeals forum for an "ICANN problem" (e.g., a controversial delegation/redelegation decision) or should we limit ourselves to creating an appeals forum for "IANA problems" (e.g., action or inaction by the IANA team that results in a failure to carry out the task it was instructed to do). Here again, I think we should limit ourselves to the latter, more limited course of action. I am somewhat surprised at these questions. Of course this CWG deals only with IANA problem accountability, not with general “ICANN [policy process] accountability problems”. People advocating an external solution or structural separation have always understood that these two things cannot be mixed up. The confusion between the two is one of the artifacts of keeping everything inside ICANN. Absolutely the IAP associated with this CWG should only be fielding appeals related to IANA-related processes and decisions. So we are in agreement, and not only that, I was unaware of anyone who thinks otherwise. Yes, internalists have been arguing that improving general ICANN accountability will completely solve the IANA accountability problem, but I was unaware of anyone who thinks that IANA accountability can be used to fix ICANN’s policy process issues. Milton L. Mueller Laura J. and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/mueller/Home.html

On Mon, Feb 23, 2015 at 1:13 AM, Milton L Mueller <mueller@syr.edu> wrote:

seem that the proposal attempts to practically create a new operator order than ICANN (re: PTI)

MM: But the PTI is just ICANN’s current IANA department, is it not?

Well not for the free standing version. Nevertheless i guess the major point is that PTI is not just looking to become a department as we have presently, but rather an entity with its own board. Do we really need such level of management over 12 staff members that are merely operating on existing set of instructions.

being the operator and turns ICANN to a "policy only" organisation. That seem like a major change in the Internet Corporation for Assigned Names and Numbers (ICANN) mission and purpose.

MM: Not really, because the current IANA contract requires a significant level of separation.

I am not sure i get the distinction you are making here. The way i understand it, the contract is what makes ICANN operate IANA, and if by transition there will be a new board (irrespective of where it sits) that oversight on IANA, what would you say has happened to ICANN mission in that context? Maybe i should paste here the role of the "community board" for reference as i think its beyond a mere procedural oversight currently performed by NTIA: - Oversight of the IANA team, operations - Addressing escalation issues from IANA customers, i.e those with MOUs with Post Transition IANA. - Responsible for ensuring funding for operations - Budget approval for Post Transition IANA Implementing the above in practice would mean ICANN is now a policy making organisation and a new IANA operator has emerged. That was not its main purpose from day 0, its purpose is to operate IANA. How will this work with ccTLDs who for instance are practically engaging

with ICANN just because it is the IANA operator?

MM: It should make them very happy, because they can deal with IANA directly and independently and not through the medium of ICANN’s gTLD policy making morass

Well i doubt what is being proposed will lack some form of medium as well, will leave that for the CCs to determine. Perhaps its good to note that it seem you are implying that implementation of PTI will remove need for some existing internal procedures. I just hope i am wrong on that assumption; if there is something wrong with the current medium, then the process should be reviewed and corrected which is largely within the scope of the CCWG not that of the CWG.

how about existing gTLD contracts which were signed with the intent of ICANN being the operator?

MM: If IANA is a subsidiary of ICANN this is not an issue; if it is not the modifications required are minor as long as IANA is contractually bound to implement legitimately passed ICANN policies. IANA is an ancillary aspect of the registry agreement; it is referenced only once regarding emergency transition and in the final convenants where ICANN agrees to implement RZF changes within 7 days of request. I don’t see how that would be difficult to transfer that obligation to an SLA negotiated with the new IANA.

Well that does not remove the fact that those registries signed an agreement with ICANN as the IANA operator. Maybe i am the one seeing this differently so i will try to illustrate; a typical registry A enters into agreement with ICANN to oversee operation of its TLD, the registry does that based on the fact that it recognises that ICANN as the operator would execute what it has agreed upon. ICANN in this context is the board and if that is changing then it may require a change in contract writeup. Unless ICANN board, recognises that it is responsible for the "community board" which could mean exercising some form of oversight on it.

Looking at the proposal, how do we achieve accountability of the "community board"? i mean why should one be comfortable that the "community board" will be more accountable than the current ICANN board?

MM: That’s easy. In part, because it is directly accountable to IANA customers. And also because (I think) the functions contract could be transferred to someone else.

Do you mean there is going to be a contract somewhere; between who and who? ICANN and PTI? PTI and registries? Overall, the intent of maintaining the current separation (i.e IANA being a department) will be good. However it does not have to be achieved through creation of new structures. Creating multiple structures may not necessarily guarantee accountability, it may actually worsen it OR at least slow down processes which may not be good in ensuring stable, efficient and secure domain system. It may be good to task the CCWG to ensure current ICANN board's accountability once and for all. Regards -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>* The key to understanding is humility - my view !