[CWG-RFP3] Is separability possible under an internal solution
Milton L Mueller
mueller at syr.edu
Sat Jan 10 09:11:57 UTC 2015
Donna:
It would be easy to solve the fee problem in a new IANA contract. It could specify that ICANN’s IANA-related costs needed to be explicitly separated out from other costs, and registry fees reduced by the appropriate amount if or when it was no longer the IANA functions provider.
Responding to another message you sent, you said:
“I don’t see any harm in raising potential edge cases in order to have them discussed, dismissed and taken off the table. One of the challenges for this CWG has been the compressed timeframe that we are working to, which has compromised our ability to thoroughly explore a number of scenarios rather than hone in on and refine one.”
MM: I think it’s fine to raise edge cases, and I appreciate the way you are thinking about it. My negative reaction comes from that fact that you seem to be focused exclusively on the alleged risks of separability, and you seem to be completely oblivious to the risks of not having separability, or of having dramatically limited, “nuclear option” separability. Perhaps this is because you are comfortable with the status quo. I would remind you that we have separability now. Recurrent contracting IS the status quo, and removing it could radically change the way ICANN behaves. In other words, the internal option is perhaps the most radical, riskiest change. History is rife with sad tales of how organizations behave after achieving a perpetual monopoly on a critical infrastructure function. Registries, being completely dependent on IANA for RZF updates and new TLD implementations, would be most affected by this. I’d encourage you to raise some potential edge cases about that.
--MM
From: Donna Austin [mailto:Donna.Austin at ariservices.com]
Sent: Friday, January 9, 2015 6:19 PM
To: Milton L Mueller
Cc: RFP3
Subject: RE: [CWG-RFP3] Is separability possible under an internal solution
Milton
You are correct; however, the registry operator has a registry agreement with ICANN in which they agree to pay ICANN a quarterly fee + an additional fee based on number of domain names. The registry agreement does not itemise what costs those fees cover.
Should ICANN no longer be the IANA Functions Operator, the registry operator would continue to pay ICANN the current level of fees required in the registry agreement. There is nothing to suggest that ICANN would be obligated to funnel $10m in registry operator fees to an external third party that becomes the new IANA Functions Operator; and there is currently no provision for the registry operator to pay a portion of their ICANN fees to a new IANA Functions Operator. So, in my mind, the $10m to fund a new IANA Functions Operator would be above and beyond the fees that registry operators pay to ICANN. That’s not to say that a reduction in fees could not be negotiated, but a formal negotiation would be required—it is certainly not a given.
The ccTLDs are different because their financial contribution to ICANN is voluntary.
Thanks,
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 at ariservices.com<mailto:donna.austin at 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: Milton L Mueller [mailto:mueller at syr.edu]
Sent: Friday, 9 January 2015 2:56 PM
To: Donna Austin
Cc: RFP3
Subject: RE: [CWG-RFP3] Is separability possible under an internal solution
Donna:
Your fees to ICANN are ALREADY paying for IANA. Why would ICANN keep charging you fees to cover the costs of a service it was no longer providing? I cannot fathom what you are saying when you claim there are no costs. There are about $9-10 million in costs, and you and the registrars are paying it, supplemented by a few donations from ccTLDs.
--MM
From: cwg-rfp3-bounces at icann.org<mailto:cwg-rfp3-bounces at icann.org> [mailto:cwg-rfp3-bounces at icann.org] On Behalf Of Donna Austin
Sent: Friday, January 9, 2015 1:58 PM
To: Kieren McCarthy; Avri Doria
Cc: RFP3
Subject: Re: [CWG-RFP3] Is separability possible under an internal solution
Hi Kieren
I’m not so sure I agree with your following statement:
It would cost roughly $10m a year to run and it shouldn't be that hard to get the registries to agree to cover the cost. It wouldn't be very hard to get the necessary staff - you could just offer current IANA staffers a pay rise.
$10m is not an insubstantial amount, and I’m not as confident as you that it ‘shouldn’t be that hard to get the registries to agree to cover the cost’. It most certainly would if it is an additional cost to the fees already been paid to ICANN. Many of the ccTLD accountability framework agreements make reference to the fact that the fee associated with the arrangement is for the IANA service that ICANN provides, so you might be able to raise $1m or so from the ccTLDs, but there’s a downside to that too – they would likely walk away from ICANN as it is no longer relevant to their business operations.
Let’s not forget that, in theory anyway, there is no cost currently associated with the IANA service that ICANN provides.
Thanks,
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 at ariservices.com<mailto:donna.austin at 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-rfp3-bounces at icann.org<mailto:cwg-rfp3-bounces at icann.org> [mailto:cwg-rfp3-bounces at icann.org] On Behalf Of Kieren McCarthy
Sent: Friday, 9 January 2015 10:50 AM
To: Avri Doria
Cc: RFP3
Subject: Re: [CWG-RFP3] Is separability possible under an internal solution
I agree with Avri.
When the NTIA put the IANA contract out to rebid I spoke to a few companies and organizations that I thought might be considering a bid (some of them even registered within the US government system).
A number of them said that they would consider it if they honestly thought that the NTIA would move the contract away from ICANN. But the feeling generally was that the NTIA did the rebid as a way to get ICANN to raise its game and they didn't want to go to all the trouble of creating a serious bid for IANA with no real likelihood of winning the contract.
Other details I gleaned: IANA is not that difficult to do on a technical level. And because the policy aspect is separate it can be a fairly pure technical job. It would cost roughly $10m a year to run and it shouldn't be that hard to get the registries to agree to cover the cost. It wouldn't be very hard to get the necessary staff - you could just offer current IANA staffers a pay rise.
So if people are seriously wondering whether anyone other than ICANN would offer to run IANA the answer is an unequivocal Yes, of course they would. It's a good contract. And it would provide massive kudos to a tech company.
I can also see why it might be nicer to see IANA moved away from ICANN, and why the tech community might love it: it would pull out a lot of the political BS.
IANA should be a pure customer-led technical function. I don't think even ICANN's biggest advocates would argue that is the case right now.
Kieren
On Fri, Jan 9, 2015 at 9:44 AM, Avri Doria <avri at acm.org<mailto:avri at acm.org>> wrote:
Hi,
Why would you assume that the ITU or the UN would be the next home for IANA?
Those are the least likely possible bidders I can think of. I think what is more likely is a consortium type affair made up of RZO, RSP, ISPs or some such.
avri
On 09-Jan-15 12:35, Donna Austin wrote:
Greg
I have some sympathy for Seun’s scenario, because we don’t know what the consequence of moving the IANA function out of ICANN would be. From a registry perspective, it adds an element of risk to operation that I expect most would want to understand. While you may believe that there’s no reason that moving the IANA functions out of ICANN means or implies changing policy and implementation functions in any significant way, this is only true if you can replicate what currently happens. Once you take the IANA function out of ICANN to another entity, for example the ITU or another UN organisation, in my mind it becomes more difficult to maintain the current arrangement and you will most certainly end up with turf battles about who is responsible for what.
The proposal that we have developed is largely designed to enable the IANA function to be removed from ICANN. It is my understanding that RFP4 will be trying to understand some of the consequences of the transition proposal and this is one element that I will be interested to understand. As I stated in the early days of the CWG, I do have concerns about moving the IANA function out of ICANN, because of the potential to fragment the multi-stakeholder model that is at the heart of ICANN.
It is largely this concern that I am looking forward to understanding what the ‘internal to ICANN’ proposition looks like.
Thanks,
Donna
[Description: Description: Description: ARI Logo]DONNA AUSTIN
Policy and Industry Affairs Manager
ARI REGISTRY SERVICES
Melbourne | Los Angeles
P +1 310 890 9655<tel:%2B1%20310%20890%209655>
P +61 3 9866 3710<tel:%2B61%203%209866%203710>
E donna.austin at ariservices.com<mailto:donna.austin at 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-rfp3-bounces at icann.org<mailto:cwg-rfp3-bounces at icann.org> [mailto:cwg-rfp3-bounces at icann.org] On Behalf Of Greg Shatan
Sent: Friday, 9 January 2015 7:56 AM
To: Seun Ojedeji
Cc: RFP3
Subject: Re: [CWG-RFP3] Is separability possible under an internal solution
There's no reason that moving the IANA Functions out of ICANN means or implies changing policy and implementation functions in any significant way. Nor has anyone proposed such a wholesale move. Indeed, given the longstanding requirement that IANA be separated from policy, moving them together would be far fetched and separating them structurally would be quite logical. So, before throwing the word "disaster" around, let's please stay in the realm of reality.
Greg
On Friday, January 9, 2015, Seun Ojedeji <seun.ojedeji at gmail.com<mailto:seun.ojedeji at gmail.com>> wrote:
Hi Chris,
Kindly find below
sent from Google nexus 4
kindly excuse brevity and typos.
On 9 Jan 2015 07:07, "Chris Disspain" <ceo at auda.org.au<mailto:ceo at auda.org.au>> wrote:
>
> Hi Suen,
>
> There is also the other not insignificant fact that the current IANA function contract is a zero cost one.
>
> And, I'm interested in your point that moving the operations of IANA also means moving the policy body. Could you expand on that please?
>
Speaking in the context of IANA function related to names i will use a scenario; if the function gets moved to another operator then it will mean either of the 2 options below:
- The new operator will have to create another source of instruction to use for IANA implementation which requires creating a new community structure. So that is what I mean by moving; the people that made the ICANN will now makeup the new operator's community and ICANN crease to become the policy source
Or
- The new operator will rely on the ICANN community developed processes which will fix noting since the ICANN board and processes will still remain the same.
There are lots of implications for names if operation of IANA moves to another operator. The fact that we have not witnessed it moved may not help us appreciate the kind of disaster it could bring. So if IANA function operator is changing then it has to change in it's totality which also implies starting afresh!
Regards
> Cheers,
>
> Chris
>
> On 9 Jan 2015, at 16:51, Seun Ojedeji <seun.ojedeji at gmail.com<mailto:seun.ojedeji at gmail.com>> wrote:
>
>> sent from Google nexus 4
>> kindly excuse brevity and typos.
>> On 8 Jan 2015 10:22, "Milton L Mueller" <mueller at syr.edu<mailto:mueller at syr.edu>> wrote:
>> >
>> > Chris:
>> >
>> > Brief answer due to time constraints:
>> >
>> >
>> >
>> > I will take another, closer look at the AuDA proposal and try to do a comparison of it to the CWG proposal with respect to complexity and risk.
>> >
>> >
>> >
>> > We disagree on periodic re-tendering (remember that is what we have been doing for the past 15 years), and it’s unlikely you will convince me otherwise.
>> >
>> >
>> Well they have the independent resources to do so even though deep inside they know the bidding process is only going to yield 1 result. I also saw the contracting then as a way of protecting the young ICANN. We should also bear in mind that NTIA has never exercised transferring to another operator because no sane organisation will want to abandon a construction at 20th floor to start building another one; moving to another IANA operator is not only about the function but also the policy body (as it fixes noting if ICANN still runs the policy). multistakeholder should not set itself on such a path but should make possible a way to get the current builder to improve and if no improvement, a way to change the builder (board removal) so building can continue from 20th floor
>>
>> Hope that convinces Milton ;-)
>>
>> Regards
>> >
>> >
>> >
>> > From: Chris Disspain [mailto:ceo at auda.org.au]
>> > Sent: Wednesday, January 7, 2015 5:04 PM
>> >
>> > To: Milton L Mueller
>> > Cc: RFP3
>> > Subject: Re: [CWG-RFP3] Is separability possible under an internal solution
>> >
>> >
>> >
>> > Hello Milton,
>> >
>> >
>> >
>> > Speaking entirely in my capacity as CEO of auDA, some responses to your paragraph below.
>> >
>> >
>> >>
>> >> Second, the internal advocates seem to want to have their cake and eat it, too. They say, “let’s not go to all the trouble of creating complex institutional mechanisms such as Contract Co. to achieve separability, let’s just improve ICANN’s accountability. That is a coherent position, but it is not what you, or Chris Disspain, or Martin of SIDN seem to be advocating.
>> >
>> >
>> >
>> > On the contrary, that is what I am advocating. I am saying that I believe ICANN is the right organisation to perform the IANA function and that a series of IANA specific accountability mechanisms can be built to ensure that the ccTLD and gTLD customers of the IANA function can get good service at agreed levels and have disputes resolved in a fair and binding manner.
>> >
>> >
>> >
>> > I am opposed to the concept of creating some entity in some, to be identified, jurisdiction that would have the "right" to grant the contract to perform the IANA function. I am especially opposed to the concept of this critical function being re-tendered every X years.
>> >
>> >
>> >
>> > However, I recognise that a number of my ccTLD and gTLD colleagues believe that there should be a mechanism for the IANA function to be moved elsewhere. The auDA alternative proposal sets out a way in which that could happen that would be acceptable to us.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >> You seem to be saying, “we hate the idea of Contract Co., but we also support separability, so let’s create a Contracting entity through an internal process of ICANN that we can magically pull out of a hat when we need it.”
>> >
>> >
>> >
>> > Well, kind of, yes. But, just so we are crystal clear:
>> >
>> >
>> >
>> > a) I do not believe that separability can only be achieved by utilising the concept of a contracting entity. It is entirely possible to be opposed to the current proposal but to believe in separability,
>> >
>> >
>> >
>> > b) our alternative proposal does not involve the use of magic nor of hats of any description. It contemplates a "nuclear" option of the IANA function leaving ICANN and provides a mechanism that can indeed be used "when we need it" and,
>> >
>> >
>> >
>> > c) the alternative proposal it is not an internal ICANN process but rather a process controlled by the IANA function customers together with representatives from other parts of the multistakeholder firmament.
>> >
>> >
>> >
>> >
>> >
>> >> And far from avoiding complex institutional mechanisms, the internalists end up creating even more complex, difficult to understand and less well-defined mechanisms than the CWG proposal.
>> >
>> >
>> >
>> > Whilst I may be cast as an "internalist" out proposal is not an "internalist" proposal. And it is certainly no more complex and no less well-defined than the current CWG proposal.
>> >
>> >
>> >
>> > Cheers,
>> >
>> >
>> >
>> > Chris Disspain | Chief Executive Officer
>> >
>> > .au Domain Administration Ltd
>> >
>> > T: +61 3 8341 4111<tel:%2B61%203%208341%204111> | F: +61 3 8341 4112<tel:%2B61%203%208341%204112>
>> >
>> > E: ceo at auda.org.au<mailto:ceo at auda.org.au> | W: www.auda.org.au<http://www.auda.org.au>
>> >
>> >
>> >
>> > auDA - Australia's Domain Name Administrator
>> >
>> >
>> > On 7 Jan 2015, at 08:01, Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>> wrote:
>> >>
>> >> Martin,
>> >>
>> >> I am having trouble understanding your comment. Let’s break it down one by one.
>> >>
>> >>
>> >>
>> >> First, ICANN has been promoting the internal solution, both in Steve Crocker’s comments here and in the written comments ICANN submitted. Crocker has stated quite explicitly that “NTIA did not ask whether ICANN should continue to provide the function. That’s not really in question.” Obviously, there is no concept of separability there. So it is not only the opponents of the internal solution who believe that an internal solution implies no separability – the primary advocates of an internal solution are saying that, too. When I see ALAC and you actively criticizing these kinds of statements then and only then will I take seriously the idea that interal solutions and separability are compatible.
>> >>
>> >>
>> >>
>> >> Second, the internal advocates seem to want to have their cake and eat it, too. They say, “let’s not go to all the trouble of creating complex institutional mechanisms such as Contract Co. to achieve separability, let’s just improve ICANN’s accountability. That is a coherent position, but it is not what you, or Chris Disspain, or Martin of SIDN seem to be advocating. You seem to be saying, “we hate the idea of Contract Co., but we also support separability, so let’s create a Contracting entity through an internal process of ICANN that we can magically pull out of a hat when we need it.” And far from avoiding complex institutional mechanisms, the internalists end up creating even more complex, difficult to understand and less well-defined mechanisms than the CWG proposal.
>> >>
>> >>
>> >>
>> >> I frankly think that an internal solution that provides for separability is legally incoherent and cannot exist under California law. For many years now ICANN legal has been contending that it cannot have a binding independent review process because under Cal law no subunit of ICANN’s process can overrule the board. Yet you are saying that a subcommittee formed within ICANN, or even called into existence by ICANN, can issue a recommendation that strips ICANN of something that it really, really wants to hold on to, against the wishes of the board. When you start looking at the internal reforms required to make that possible, believe me, the CWG proposal will look simple and straightforward by comparison.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> From: Martin Boyle [mailto:Martin.Boyle at nominet.org.uk]
>> >> Sent: Tuesday, January 6, 2015 4:20 AM
>> >> To: Seun Ojedeji; Milton L Mueller
>> >> Cc: RFP3
>> >> Subject: RE: [CWG-RFP3] Revised Survey
>> >>
>> >>
>> >>
>> >> I am even more concerned that there is the idea being pushed that an internal solution implies no separability.
>> >>
>> >>
>> >>
>> >> I see no reason why there could not (should not) be an internal solution with a nuclear clause that failure by the IANA functions operator and inability to correct leads to a bid process. This would essentially be the equivalent to the nuclear button process with instructions to the Contract Co. That you set up Contract Co. at this stage in response to a failure, rather than at the transition, will obviously have some downsides, but then so does the immediate creation of Contract Co.
>> >>
>> >>
>> >>
>> >> So I’m sorry, I do not see Contract Co. as the only solution to separability any more than I see an internal solution as the antithesis.
>> >>
>> >>
>> >>
>> >> What it does mean is that the separation process might be slightly longer with an internal solution model as a contract company would need to be created at the stage of last resort. But then for stability interests, I would not feel uncomfortable with anything that did not have a cooling off period or a significant process barrier before making such a momentous and potentially disruptive step.
>> >>
>> >>
>> >>
>> >> Cheers
>> >>
>> >>
>> >>
>> >> Martin
>> >>
>> >>
>> >>
>> >> From: cwg-rfp3-bounces at icann.org<mailto:cwg-rfp3-bounces at icann.org> [mailto:cwg-rfp3-bounces at icann.org] On Behalf Of Seun Ojedeji
>> >> Sent: 06 January 2015 08:32
>> >> To: Milton L Mueller
>> >> Cc: RFP3
>> >> Subject: Re: [CWG-RFP3] Revised Survey
>> >>
>> >>
>> >>
>> >> Well, as far as i am concerned summing up public comments by indicating Yes or No on separability is just not an appropriate way to review inputs otherwise you would have just asked people to provide comment on separability as that could have different meaning in this context.
>> >>
>> >> However, as you have said, maybe i have not looked at the comments and "your compilation" with professorial eyes like yours ;-), but i can assure you that the layman eyes of mine tells me that people's comments about the CWG proposal is beyond just a concern that can be quantified and qualified with a Yes or No as you have presented it.
>> >>
>> >> Regards
>> >>
>> >>
>> >>
>> >> On Tue, Jan 6, 2015 at 4:57 AM, Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>> wrote:
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> From: Seun Ojedeji [mailto:seun.ojedeji at gmail.com]
>> >>
>> >> Thanks for the share...i missed that particular meeting. However, I just randomly picked one of the submissions(that of USCIB) that has Yes on both column and i come to conclude that whatever metrics used in determining what is Yes and what is No is absolutely flawed.
>> >>
>> >>
>> >>
>> >> Seun
>> >>
>> >> The Yes in the first column means they support separability; the Yes in the second column means they have serious concerns about the MRT.
>> >>
>> >>
>> >>
>> >> Here is a direct quote from the USCIB:
>> >>
>> >>
>> >>
>> >> “we support the concept that a new structure may need to oversee various administrative functions set forth in the IANA Functions Contract, which is currently performed by NTIA. And we concur that it is appropriate that direct consumers of the IANA naming functions should be vested with such oversight functions.”
>> >>
>> >>
>> >>
>> >> To me, that qualifies as a clear Yes for separability.
>> >>
>> >>
>> >>
>> >> Regarding the MRT, the USCIB comments are, admittedly, more vague and do not directly address the composition of the MRT, but they do very strongly emphasize the need to avoid duplicating accountability functions. So we marked them a yes there, too. In effet, the USCIB was critical of the structure, but supported the principle of separability.
>> >>
>> >>
>> >>
>> >> Thanks for your input, I hope you go through the comments and our compilation more carefully next time.
>> >>
>> >>
>> >>
>> >> Milton L Mueller
>> >>
>> >> Laura J. and L. Douglas Meredith Professor
>> >>
>> >> Syracuse University School of Information Studies
>> >>
>> >> http://faculty.ischool.syr.edu/mueller/
>> >>
>> >> Internet Governance Project
>> >>
>> >> http://internetgovernance.org
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> ------------------------------------------------------------------------
>> >>
>> >> Seun Ojedeji,
>> >> Federal University Oye-Ekiti
>> >> web: http://www.fuoye.edu.ng
>> >> Mobile: +2348035233535<tel:%2B2348035233535>
>> >> alt email: seun.ojedeji at fuoye.edu.ng<mailto:seun.ojedeji at fuoye.edu.ng>
>> >>
>> >> The key to understanding is humility - my view !
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Cwg-rfp3 mailing list
>> >> Cwg-rfp3 at icann.org<mailto:Cwg-rfp3 at icann.org>
>> >> https://mm.icann.org/mailman/listinfo/cwg-rfp3
>> >
>> >
>> > _______________________________________________
>> > Cwg-rfp3 mailing list
>> > Cwg-rfp3 at icann.org<mailto:Cwg-rfp3 at icann.org>
>> > https://mm.icann.org/mailman/listinfo/cwg-rfp3
>> >
_______________________________________________
Cwg-rfp3 mailing list
Cwg-rfp3 at icann.org<mailto:Cwg-rfp3 at icann.org>
https://mm.icann.org/mailman/listinfo/cwg-rfp3
_______________________________________________
Cwg-rfp3 mailing list
Cwg-rfp3 at icann.org<mailto:Cwg-rfp3 at icann.org>
https://mm.icann.org/mailman/listinfo/cwg-rfp3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20150110/9c6448c6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 3765 bytes
Desc: image003.png
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20150110/9c6448c6/image003-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5486 bytes
Desc: image001.png
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20150110/9c6448c6/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 5502 bytes
Desc: image002.png
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20150110/9c6448c6/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 8085 bytes
Desc: image007.png
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20150110/9c6448c6/image007-0001.png>
More information about the Cwg-rfp3
mailing list