ICANN | Transcript - ICANN Public Forum, 29 March 2007, ICANN Meeting, Lisbon Portugal

ICANN Meetings in Lisbon Portugal

Transcript - ICANN Public Forum

29 March 2007

Note: Although transcript output is largely accurate, in some cases it is incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but should not be treated as an authoritative record.

Good morning, ladies and gentlemen. Welcome to the Thursday public forum. This is a new format for the public forum. And, in particular, a number of reports which had been in the past presented orally have been put up on the network for your information, and time has been allocated in the agenda for any questions with regard to those reports.

Specifically, the audit committee report, which was prepared by Vanda Scartezini, the chair of the audit committee; the Board Governance Committee report, by Roberto Gaetano; the conflict of interest committee, by Demi Getschko; the finance committee, by Raimundo Beca; the meetings committee, by Susan Crawford; and the Reconsideration Committee, by Rita Rodin.

So those six people are all here before you on the dais and are prepared to respond to any questions you may have, presuming that you've read the reports. And if you have any.

If there are no questions on those reports this morning, then I will proceed to the next item of the agenda, which is the reports from the supporting organizations and advisory committees.

So let me pause now and ask if there are any questions from the floor or from the board concerning the six reports that have been posted.

I would suspect that it was wise of us to post them this way and save all of the time that we would have spent hearing them presented orally.

In that case, I will call on Ray Plzak, who is the CEO of ARIN and the chair of the ASO, or at least representing the ASO this morning, to present that report.

I saw Ray here earlier this morning, but -- oh, there he is. Okay.

So, Ray, your time accelerated. You're now traveling faster than the speed of light. And you may have to pause for approximately 12 minutes in order to let the light beam catch up with you.

But thank you for taking the time to join us today. And we look forward to your report.

>>RAY PLZAK: Thank you, Vint.

>> Can't hear you.

>>RAY PLZAK: Hello. There we go. Better.

Actually, this is the speed of the Internet, which is different from the speed of light. So we're well in hand here.

Give me a moment to get hooked up here.

And --

>>VINT CERF: Does this mean that PowerPoint runs at lower than the speed of limit somehow?

>>RAY PLZAK: You'll have to take that up with Mr. Gates.

>>VINT CERF: Yes. I will let him know.

>>RAY PLZAK: Okay. Good morning. As Vint said, I'm Ray Plzak, president and CEO of ARIN. And this year I am the chairman of the executive council of the Number Resource Organization, which is the organization that performs the functions, missions of the Address Supporting Organization as specified by the Address Supporting Organization MOU between the NRO and ICANN.

So I am here this morning to provide a status report. And I'm going to cover four items this morning. Actually, I will not be presenting all of them. I will be assisted by Sebastian Bellagamba, who is the chair of the address council.

But I will begin with a -- or general report about the status of the Internet number resources. Then I will discuss for a while the IPv4 consumption. Then I will turn the lectern over to Señor Bellagamba to provide the address council report. He will report on two things, the recent policy activity in all the regions. There will also be an ASO policy activity report. And then he will also provide a report on one of the most important duties that the address council discharges, which is the selection of a board member to the ICANN board of directors.

Then I will return to the microphone for a closing thought.

And with that, let us proceed.

I won't dwell on these numbers, but this is the -- other than to say that we prepare this report quarterly. This is the last quarter report, which is the 31st of December of 2006. And so there may be slight variations to these numbers that have occurred over the last two months.

As of the end of last year, this is the current status of IPv4 address space. And at the end of last year, the available pool in the IANA was 55 /8s.

This is the trend in distribution of IPv4 to the various regions by the IANA since 1999.

And you can see that there has been an upturn in consumption. So demand for IPv4 exists and is increasing.

This is the cumulative totals as far as the distribution. And you can see the three larger registries are pretty much equally divided as far as consumption of address space. If you've been following this trend over the last several years, you will notice that there's been significant increases particularly in Latin America, but also in Africa. Both of these are representative trends of what happens when you're able to regionally deal with address space allocations.

From a standpoint of Autonomous System Numbers, this is the statistics. And the consumption. ARIN continues to have the largest portion of consumption of address -- excuse me, Autonomous System Numbers. However, you will note that it is now below 50%. Up until this time, it had been more than 50% of the total. It's been a significant growth in the European region.

IPv6, I'm actually going to show this portion of it in two ports.

Prior to the implementation of the adoption implementation of the global IPv6 policy last year, IANA was issuing IPv6 address space to the RIRs in units of a /23. And so this represents that consumption up to October of last year. And as you can see, at that time, most of the address space had been allocated in Europe.

Since that time, the policy called for an equity of distribution initially, so each RIR was given a /12. You will note from the asterisk that APNIC, ARIN, LACNIC, and RIPE NCC, their previous allocations were included inside that /12 that was initially allocated to them.

And so in the future, you will probably see just this chart, and you will see probably different variations of this chart, which shows you the regional consumption of IPv6.

We are working on different ways of keeping you informed as far as the rate of consumption on a regional basis.

And looking at the aggregate total, you can see that about 50% of the IPv6 space has been allocated in Europe.

If you are one that likes to do things with statistics, they are available in a raw form, both through the NRO Web site, and also historical and the allocations to the RIRs' information is available via the IANA Web site.

And so let me now turn to an issue that has been lurking for some time. It's been talked about over the last several years. There have been various predictions and so forth in terms of this is going to happen. Well, yes, indeed, actually, IPv4 is being consumed. And as I have just shown you, that it is being consumed at a faster rate.

Just as a reminder, this is the consumption of the allocations to ISPs of IPv4 space since 1999. And, again, you see an increasing demand -- well, actually, this is a good thing because of the fact that it means the Internet is growing, which is something that we want, and is being more widely deployed.

However, along with demand, you have the other aspect, which is supply. This shows the evolution or devolution, as the term may be applied, of the central pool maintained by the IANA. The last bar to the right is number 48. If you recall from the slide I showed earlier, that showed the central pool of 55. Well, that was 55 at December of 2006. This 48 figure represents the data as of yesterday.

So you can see that supply is diminishing.

And so we are in that -- coming up on that bind as far as not being able to meet our needs.

This is a chart that's provided and is updated periodically by Geoff Huston. The red line is the consumption of the central pool. The green line represents the central pool of the RIRs.

Now, you'll note that the RIR pool line tends to be relatively constant. That's because the RIRs are managing a supply in terms of being able to satisfy demand. And so as you would hope, they would try and keep that pool as level as possible so they can meet the demand, meet the need as it arises.

But you'll note that it drops off. And it drops off because the central pool starts to drop off. And they start losing their supply.

So, from a projection based on current rate -- and I have to emphasize the word current rate -- that we would expect the central pool to be depleted somewhere around 2011, and we would expect the RIR pools to be depleted about 2012, 2013. From the IANA perspective, this means that they would no longer have allocation units to provide to the RIRs.

However, from the standpoint of the RIRs, they would still have IPv4 address space, but they would not have it in sufficient aggregate quantities to issue to providers in the same manner they do today. Numbers would be less than whatever the minimum allocation sizes.

And so they could meet some demand, but they couldn't meet the general demand.

So, in general terms, the pool gets depleted.

So, obviously, this will have consequence.

So what could happen?

Well, there's no reason to expect that the demand for IPv4 won't continue. It will, for a variety of reasons. There's well-established infrastructure. People in their business models will continue to do so.

We can expect an increased use of network address translation devices to help mitigate the depletion of IPv4 by more people adopting the use of perhaps private address space.

You can see also a growth -- and I'll use the term "growth" here -- of a secondary or gray market. Some people would like to use the term "black market."

This is a naturally expected phenomenon when the legitimate supply is not available to meet a legitimate demand.

This poses a few problems. One is, is that it's -- obviously, this would probably take place in a barter or trading system, something like that. The characteristic of I.P. addresses, as a spouse in RFC 2008, is that they are not property. They can't be bought, sold, traded, bartered, whatever. And, therefore, you now have the creation of a market that's going to attempt to do that.

More importantly, as secure routing becomes more and more important to more people, the problem exists that the person that receives this address space may not be viewed by the legitimate, if you will, operator community as being the legitimate user of the address space. That legitimacy is only provided by the registration of that address space to an organization in an RIR database.

That becomes more significant as the RIRs continue along with their program that they've been developing to attach certificates as an attestation of a routing object, in other words, an I.P. network identifier, to a specific organization.

So what this means is that if someone obtains I.P. addresses through this secondary market, they may not be able to use it in the manner to which they'd expect, because they would not be viewed as a legitimate user. And this becomes more and more problematic as people are being faced with liabilities for allowing unwanted content to be processed and passed through their networks.

So there is this deleterious effect.

So this is one of the major issues that's facing the RIRs, is how to work in this environment, how to mitigate it and make it work.

The last thing is the panic, IPv6 frantic deployment, everyone waiting until the last minute to do this.

This in itself is also a dangerous situation, because this is where people will lose customers, this is where portions of the network could have problems as someone hurriedly attempts to renumber, excuse me large amounts of resources they wouldn't necessarily have to because they weren't prepared.

So I can't say that all of these are going to happen. I generally would say that they all probably will happen in some way, shape, or form. And it's really up to us to find ways of mitigating and countering these expectations.

So what's been done so far is a good question.

Before I get on to that, this chart, the line shows the address space, IPv4 address space, that's advertised. In other words, it's present in the routing tables. This is address space that is expected to be routed, because it means that someone has placed it in a routing table with the expectation of being able to communicate across the Internet.

If you look at that number, you will -- and compared it to the other charts, you would see that this number is somewhat less than what's been allocated. It's a difference between what's being advertised and what's being allocated, which would be the fuel for the secondary market.

This address space exists for two reasons. One is that some people have obtained, validly, IPv4 address space and are using it privately, behind NATs, or not even connected to the Internet.

But an example would be, for example, a large-scale corporation or a university, someone of that nature, who basically would be operating a private network but still has a desire and a need for unique I.P. address space and the use of private address space doesn't work for them.

The second thing is, is that there's a large amount of legacy address space that was allocated prior to the implementation of a few things to allow it to be aggregated and issued in smaller blocks. And a large amount of that address space is, in a sense, lying fallow.

However, the dichotomy here is that, for example, an early adopter received what at the time was called a class A address, a /8. And that gives them the ability to have approximately 16 billion networks.

Well, if -- or somewhere in the -- a million networks.

>>VINT CERF: Yeah, excuse me. It's 16 million terminations. And they can be divided up into however many networks you want.

>>RAY PLZAK: Right, it's terminations. But it amounts to 4 billion computers. 2 to the 32nd; right?

Anyway, the number is larger. Let's -- the point I'm going to try and make here is -- and let's not -- is that it's a large number. And if they are only consuming 10% of that, that is still a large number of termination points, networks, and so forth.

And to renumber out of that address space so they can give the whole block back to an RIR is a costly proposition in terms of time, people, and money.

I'll give you an example of such an activity.

Around the year 2000, Stanford University was the holder of one of these original /8s, class A addresses. And they decided, as good denizens, to give it back to ARIN, and in turn, ARIN would provide it back to the IANA.

And because they only really had the need for two /16s, class B addresses.

Well, it took them about two years to do this. And they were doing this in a benign environment, taking their time, with no pressure to get it done, and did it properly.

And so it was a priority for them. And certainly they were devoting resources and so forth to do it.

But you can see how careful of a proposition this really is.

And to look at a business to all of a sudden decide that it's going to interrupt its activities to go through a similar activity, in some cases, having a much more diversely applied amount of address space, it could take longer.

And from a standpoint of a business, the return of investment is very low, because I'm expending money and resources, and I'm really gaining nothing other than being a good guy and giving address space back to the community.

And for those people in the accounting offices and stockholders, they don't understand sometimes what munificence means. And it's not a bad thing, but it is a fact of life.

So that's a part of the problem of the renumbering.

So the real question is that the real solution is IPv6: Well, why don't we have IPv6? IPv6 has been around and available for unicast address space from the RIRs since 1999. The statistics point that out.

But it's not been widely adopted.

Well, there's a few reasons for that. Some of them are technical. And the others I've kind of mentioned already are economic, incentives.

The solutions to date have been to try and solve these issues not -- I -- I have to be -- I want to be careful here with the technical solution is that it's not been solved in a rapid manner, but the fact is that the market and the businesses that want to use IPv6 in order to surmount these technical difficulties have used the RIR allocation policies as a means of solving a technical problem.

And in addition, the economic incentives for the deployment of IPv6 almost exclusively have been dealt with through a matter of the RIRs allocation policies and their fee policies.

The economic incentive problem exists in both the developing and developed world. A lot of people will say, well, the solution for the developing world is just use IPv6. Well, unfortunately, IPv6 from the standpoint of a startup, it's probably a little more expensive than IPv4. Just as it's easier to buy a used car and cheaper to buy a used car than a new car, it's cheaper to buy used IPv4 equipment than new IPv6 equipment.

So when you are faced with those kind of cost decisions, and that would be one of them, it becomes a difficult thing, decision to make.

In addition, because of the less-than-desired deployment of IPv6 at this time, there's a general requirement that you have to dual stack a lot of stuff. In other words, be capable IPv4 and IPv6.

This in turn is another cost, because the amount of used IPv4, IPv6 dual stacked equipment is not that great.

And there are other things associated with it.

There are developing countries that already have IPv4 networks. The costs that I mentioned associated with converting to IPv6 from a numbering standpoint in a short order may be a little bit difficult as well.

So clearly you need economic incentives in this area to help mitigate that situation.

In a developed world you it is just the opposite. You have a well established infrastructure. And here the problem is that there's no reason to convert to IPv6 that's economically desirable. And perhaps the best term there is "desirable."

And so if it's not desirable, it's not going to be done, and it won't be done until I have to.

And so here again now, the incentives have to be something that makes it economically desirable to do so.

And as I've said so far, the attempt to solve these issues has been to use the allocation policies of the RIRs. And you can see from the nature of those problems that I discussed, this is not exactly the best way to do this. In fact, it's probably inappropriate to proceed much further down the line other than what's already been done.

A careful analysis of the IPv6 policy proposals over the last several years will clearly demonstrate that most of these policies have been directed towards trying to solve these problems. So the time really is to start looking to other ways to do it.

So what has been done? Well, the NRO, I.E., all five of the RIRs, have been active.

The history of the policy activity on IPv6 since 1999 will show you these policies have become more and more liberalized to the point that the criteria to obtain IPv6 from an RIR is very, very liberal. Some people have characterized it as being you are alive and say give it to me, you qualify. It might not be quite that liberal but it is very liberal.

The IPv6 fees in all the RIRs have been waived. Speaking from the standpoint of ARIN, it has been waived since the year 2000.

So basically, you get it if you want it, and you pay no service fees associated with it.

So in essence, the RIRs through their policies have been attempting to give it away.

In addition, the RIRs have been consistently conducting training and workshops trying to raise the awareness level of IPv6, and have been actively engaged in helping people to understand how to implement it and use it.

So there's been a lot of activity and support by the RIRs in this area. And the RIRs will never claim that they are supporting or promoting one particular technology over another. But, on the other hand, we don't stand in the way of its deployment. So we do what we can to facilitate it and we facilitate it depending on the wants, needs and desires of our communities.

One of the other things that the RIRs are very concerned about is to ensure equity. That's why when the proposal was handed to the address council from the NRO for the global policy, one of the things we insisted upon was an initial allocation of a /12 to every region. That put every region of the globe on an equal fitting with IPv6 in that space. And as we move forward and as we have done in the past, we will do what we can to make sure there is an equity of distribution, that resource is available to all.

Mitigating negative impacts, there are things we can do, could do, so this is something that we are actively engaged in. And where it can be done we will do so. But again, we have to do it consistently with the wants, needs and desires of our communities.

And lastly, one that people -- some people see as a panacea is recovering IPv4 address space. Well, the RIRs do recover IPv4 address space. And in the case of Stanford University, it was a beneficial munificence on the part of an organization. We fully expect other organizations to do so as well, and they have.

The RIRs through the normal course of business also recover address space. For example, through people that are discovered to no longer use it and the request is to give it back and they receive it back. Sometimes organizations default on payment of service fees and in the end don't pay the fees, and the address space is reclaimed. But there is no active go out after every single piece of IPv4 address space.

None of our communities have expressed a desire for us to expend resources in this area. And in the end, you are only going to put off the inevitable depletion of the central pool by a few years at the most.

So while this is being done, it has not really been necessarily that effective.

I will point out, though, that when the RIRs embarked on a redistribution of the DNS responsibilities for the legacy address space, a project we called ERX, for early registration transfer, we uncovered 17 /8s that no one knew about and we turned them back to the IANA. It took a while procedurally for this to occur because ICANN, the IANA, did not know what to do with this gift, didn't know how to accept it. But it was, in the end, done.

We have recovered through these other means I have talked about probably the equivalent of about five or six /8s but it hasn't been able to be aggregated into single /8s.

So this activity does occur.

And as I said, from here on out we are basically using a policy process to try to fix other problems. So what else can be done? Well, to the technical community the call to action is keep on working but maybe accelerate your pace of work. The IETF has undertaken increased effort and level in this area, but they probably do, indeed, to do more.

This is a point where businesses could become involved and provide a little bit, maybe, more technical expertise into the IETF process. Let those engineers have some more time to work this problem. So this is where you actually get businesses involved as well.

The other big guy, the hidden elephant in the room are the governments. And what can they do?

Well, they can coordinate with industry, there's things that they can do to encourage industry to be a participant in solving these processes.

They can adopt incentives. Only they can do regulatory incentives, only they can really do economic incentives, whether it be in the form of loans or grants or tax relief or some other thing.

They are the only ones that can say, through a policy of adoption of IPv6, that people who do business with us must use IPv6.

So they have got to be a strong supporter.

They have got to stand up and support and promote activities in the IPv6 deployment area.

I gave this presentation to the Governmental Advisory Committee on Tuesday, in fact using the same slide set.

This slide set was also used in the Address Supporting Organization workshop that was conducted by the address council yesterday.

So we thought it was important to bring it before you so you could hear what's going on, and actively tell you that we are ready to assist where we can to help make these things happen, and we will continue to do so. And we look forward to a stronger partnership in this area to make things happen.

So that's my little discussion on IPv4 consumption. And I would like now to turn it over to Sebastian Bellagamba to provide the address council report. He will be discussing two things, a report on the current policy activity in the various regions and also a selection -- what's going on with the selection of the ICANN board member.

Sebastian.

>>VINT CERF: Thank you very much, ray. Sebastian, you have the floor.

>>SEBASTIAN BELLAGAMBA: Thank you very much.

I will go through these two topics very quickly.

And here's a summary of the current policy discussions on the RIR communities in the different five areas on the screen right now.

Basically, AfriNIC is discussing about the allocation period, about two months and it's in discussion right now. APNIC has adopted a policy on 4 byte ASN and it's another policy that ray already mentioned about IPv4 that's called IPv4 countdown.

And there is also now under discussion in the ARIN region as well as the private and independent minimum size. In LACNIC we have micro-allocations for critical infrastructure. And RIPE has the increase on the allocation window, the allocation period, and PI assignments as well.

As for IPv6, you have a summary here. Some of the policies I presented to you in Sao Paulo has been adopted. Some of them are under discussion and there is some new ones over there.

In the other policy discussions, the topics is 4 byte ASN, basically, has been adopted. That is in force, actually, in all the RIRs.

ARIN has another policy that is in other policy discussions, as well as LACNIC.

I would try to concentrate now -- sorry. The next policy public fora for the RIR community. The next one is -- I think it's ARIN in San Juan, Puerto Rico late April. After that, RIPE in Tallinn, Estonia -- Abuja, thank you very much. Abuja before that in Nigeria, an AfriNIC meeting. After that is RIPE in Tallinn, Estonia, in the second week of May. LACNIC in Isla Margarita, Venezuela in late May. And APNIC had a meeting a month ago, so it is having their second one this year in August. End of August, first week of September.

Always if you would like to check our policy archives are publicly available, the URLs.

One of the main tasks of the address council is to select a board member for the ICANN board. And I will give you an update on the process we are facing now. Here is the schedule for selecting our new board member.

We called for nominations on December the 20th, and we are now into the comments phase, and we just started the interview phase. Actually, some interviews has been made here in Lisbon.

As per ICANN bylaws, we need to announce the candidate selection on May the 8th. So we will end up our procedure, our selection process, on May the 7th.

We have it is publicly available eight candidates available that met the candidacy criteria. Four of them, the one in blue has been interviewed here in this one. And as I said before, the comment period is still open and will be open until April the 20th. You will find here the URL for stating some comments on the candidates and look for comments on them, too.

What would be the next steps in this process. We have a period, as I mentioned, interviews have been done. We are going to meet in the ARIN meeting in late April as an address council meeting. And we are going to face internal discussions on candidates. And we are going to select a candidate for May the 7th.

For the first time since we approved our new procedure -- actually, in Sao Paulo we approved it, and the NROEC ratified it as the ASO MOU.

We are going to be able to conduct our voting via electronic means, which is actually great.

And all the archives for these discussions about the board selection processes are available in the ASO Web site. Here you have the URL again. There you will find all the minutes of all the address council meetings we had so far.

And that would be it.

I would like to invite to Ray again for a closing thought.

Thank you very much.

>>RAY PLZAK: Thank you, Sebastian. Actually, this closing thought is a participatory event that I would ask Paul Twomey to stop doing e-mail long enough to participate in.

As many of you are aware, over time ICANN and the NRO have been discussing and negotiating terms of agreement.

We concluded a Memorandum of Understanding several years ago, and we were proceeding down the path to provide a little bit more formal definition of some of the areas of that.

And so we have been making what we consider to be some good progress on it. We have had some very, very productive meetings over the last several months and we hopefully can conclude this thing sometime this year, as we said last year. No, last year we said we would do it this year. No, no, no, no, no. Although some people say this seems to be an ongoing hobby that ICANN and the RIRs are participating in. So this actually keeps us talking to each other, and maybe, I don't know.

But in any event, periodically from time to time, we like to talk about this, and actually give you a report of what's happening. And what we actually would like to do at this point in time is to show you what our expected outcome of it is by actually, Paul, if you would step up here, I have a check for about 50% of the money that's in escrow, which we will give to ICANN as a good faith contribution of our expectations of this being a successful outcome.

[ Applause ]

>>PAUL TWOMEY: Well, Ray, I knew from Bart Boswinkel and all the discussions that this was on the table, but I didn't know it was on the table so quickly. So thanks very much for that. That's excellent. Good.

>>VINT CERF: Thanks very much, Ray.

>>RAY PLZAK: So with that, Mr. Chairman, this concludes the Address Supporting Organization report. And we are available for questions whenever you desire to have them.

>>VINT CERF: I'd ask you to stay in the room, not at the podium, though. The questions will come later after some of the other presentations have been made. And I can warn you ahead of time, I have several of my own. So I'd appreciate it if you would remain with us.

>>RAY PLZAK: Sure.

>>VINT CERF: Thank you.

The next report comes from the ccNSO Supporting Organization -- the country code Supporting Organization, and that's to be presented by Bernie Turcotte. Bernie, are you here? Yes, he is coming from the back of the room now.

>>BERNIE TURCOTTE: I don't have a check Paul, sorry.

>> That's the standard from now on.

>>BERNIE TURCOTTE: Good morning, ladies and gentlemen. Whoops, I have to stand away from the mike. My name is Bernard Turcotte and I am here with the very difficult task of trying to replace Chris Disspain to give this report.

There will be no PowerPoint slides, but simply a brief recap of our activities this week, which have been many.

ccNSO is pleased to present its support for the meeting in Lisbon, Portugal, on the 26th, 27th, and 28th of March. Approximately 30 ccTLDs were represented at the meeting, as well as several observers.

All of those present expressed their appreciation for the work done in facilitating the meeting by the members of the local host organizing committee, and it has been absolutely a great meeting. So congratulations to the local host.

Joint session with the GAC on IDNs. IDNs seem to have kept us quite busy this week.

The ccNSO met with the GAC to discuss the draft issues paper. The selection of IDN ccTLDs associated with the ISO 3166 dash one two letter codes, prepared jointly the joint ccNSO/GAC working group.

Part was related to the use of mandated lists for IDN ccTLDs, and as part of this discussion, presentations were given by Elisabeth Porteneuve of AFNOR and Debbie Gossign {?} of World Language Documentation Center.

The group agreed on a way forward to continue their joint work on IDNs.

The joint session with the GAC on regions and other topics. The groups met again to discuss other topics of interest, both ccTLDs and the Governmental Advisory Committee. David Archbold, ccTLD manager for Cayman islands, gave a presentation on some issues with the current definition of ICANN regions from ccTLD manager's point of view.

Useful discussions took place and the GAC was encouraged to provide input.

The group then received an update on the development of the dot TZ TLD, the Tanzanian government passed a resolution in 2003 to turn it into an I.T. infrastructure.

The group held a discussion on retiring IANA's discussion paper on retiring country codes top-level domains. The GAC expressed concern that IANA follows the ISO list when retiring TLDs.

Although the list proves to be extremely reliable when introducing country codes, it was seemed this was not the best way to proceed when a country ceases to exist.

ICANN CEO and president of the ICANN board. The meeting was joined by Vint Cerf and Paul Twomey who discussed the work of the ICANN board. Paul Twomey identified the main issues within ICANN at the moment and mentioned the e-IANA effort and thanked the Polish registry NAT for their help and commitment to the project. He also highlighted the fact that once e-IANA is in place, IANA will introduce an authentication regime to ensure robust mechanism for updating requests for the zone file.

Chris Disspain raised concerns about a draft paper prepared for the U.S. homeland security, which suggests amongst other things that the U.S. government be the sole signer of the DNSsec root. He suggested that it may be time for the broader community to consider this issue and possible solutions.

Registry failover. Patrick Jones of ICANN introduced the group to the registry failover project. This was initiated in the ICANN operational plan.

Although it's primarily for gTLDs, comments and information from ccTLDs on their experience with the failure scenarios would be appreciated.

General manager, public participation. We were quite pleased to have Kieren McCarthy give an overview on what his role involves. Kieren defined filtering of community input as well as a lack of interaction has created frustration in some communities.

To change this, fact sheets and newsletters with relevant information will be produced. An interactive Web site has already been launched where the community can follow the ICANN meetings and give their immediate input. And we, our community, has certainly felt the changes and would like to congratulate everyone on that because I think it is really a wonderful initiative, with a lot of positive results quickly.

IANA update. Olivier Guillard, dot FR, chair of the IANA working group, reported that the IANA working group had conversations with IANA on issues such as the accuracy of the data in the IANA database for ccTLDs, and what the term Supporting Organization actually means.

The next major issue for the group is to revise the list of CC concerns with IANA. However, I should point out that it is the general sentiment that here, also, there has been significant progress made and improvements, and that Kim and Dave had just been wonderful and we are very pleased with the performance on many issues and look forward to fixing many of the other issues.

Kim Davies gave an overview the of the most important topics on IANA's agenda. The main project has been to start the root zone management work flow automation. During the next few weeks, a first functioning version will be available for testing. However, the main server function will only begin in May, we are told. We are greatly encouraged by this and look forward to this.

Our second IDN session-to, two further sessions on IDN issues, (saying name) of Greece explained how the Greek registry opened registrations for ancient and current Greek characters at the second level in July 2005. The problems that the registry had to face due to linguistic complexities were outlined. These problems will have to be tackled again when IDN registrations open at the top level.

The group also received presentations from Jonathan Shea of Hong Kong and Minjung Park of Korea on second level issues in ccTLDs and crossover issues with the work being undertaken by the GNSO which had been identified within the IDN working group.

A further session was dedicated to discussing the draft issues paper prepared by the joint ccNSO/GAC working group. It was agreed that a great deal more discussion is required on this issue and that a full day session would be scheduled for the San Juan, Puerto Rico meeting to deal only with this issue, so we can hopefully move forward quickly.

There were updates from regional organizations. The group received presentations from the regional organizations on their current work. Don Hollander, APTLD, Michuki Mwangi of AfTLD, Peter Van Roste of CENTR and Margaret Valdes from LACTLD all emphasized their commitment to cooperate with each other and the ccNSO on relevant issues.

ICANN's global partnership perspectives. Representatives Giovanni Seppia, (saying name), and Baher Esmat, please forgive me for mangling your names, updated the group on their efforts to establish relations with country code operators around the globe and we are getting a lot of good feedback on that. It was noted since the liaisons began their work they have assisted in accountability framework discussions and have assisted several countries with their ccNSO applications. So we are seeing some real progress on the ground and we think that, again, is a good thing.

Accountability and transparency. Paul Levins, executive officer and vice president of corporate affairs, presented outcomes of a report completed by One World Trust examining the accountability and transparency of ICANN. The outcome showed that ICANN in many ways was a very transparent organization, but improvement is still required in some areas.

The report will be published to the public and their comments implemented in a response to the One World Trust report.

The draft will be ready before the ICANN meeting in Puerto Rico.

I should note that we will be happy to see the terms of reference for the work being posted also, and I have discussed this with Mr. Levins and he has agreed to it. So we are very pleased.

Since I'm a little bit involved in this, I will add a personal comment. I think on the transparency side it has been an incredible amount of work. We have yet to undertake some serious discussions about the accountability side.

But wonderful and significant progress, nonetheless.

ccTLD updates. The group received interesting updates from (saying name) of dot EU, (saying name) of Czechoslovakia and (saying name) of the dot RS domain on the latest developments of their respective registries.

Updates from ccNSO board members. The last session was devoted to updates from the ccNSO's board members Peter Dengate Thrush of New Zealand and (saying name) of Brazil. They discussed the significant work the ICANN board has to face.

Discussion followed where was suggested that the ICANN board should focus on policy and should concentrate on key issues to try and diminish the workload.

The group thanked Donna Austin for her commitment and hard work as the ccNSO policy officer.

Donna is leaving her position after two years and hands over her post to Bart Boswinkel, who was welcomed onboard.

So this, for us, is significant, because Donna has put in a significant amount of work over the years, from the very early days, where it's always a little bit more difficult. And it is with heartfelt warmth that we wish her the best in her new function. And we are very sorry to see her go.

We would also like to welcome back our friend Bart, who we will certainly appreciate being with again.

This completes my report, unless there are questions.

>>VINT CERF: Thank you very much, Bernie. And certainly on behalf of the board and staff, your complimentary bouquets are very much appreciated, to say nothing of your own contributions to the ICANN process.

We will have questions, but it will be a little bit later, so I'll ask you to remain with us in the room this morning.

Thank you very much.

I should warn everyone that the speed of light has not only caught up with us, but surpassed us, because it's now approximately 9:30, and according to the schedule, it's only 9:15.

So I'll ask Janis Karklins if he's in a position to present the Government Advisory Committee report, and try to keep us a little closer on schedule.

Janis.

>>JANIS KARKLINS: So thank you, Vint.

I apologize if my voice will tremble since this is the first time when I do this.

Let me start -- or before starting the report on the work of the GAC, I would like to say that during the meeting, GAC warmly thanked its outgoing chair, Sharil Tarmizi, for tireless efforts and loyal service to the GAC in the past four years.

And I would like to invite the community here to do the same.

[ Applause ]

(Standing ovation).

>>JANIS KARKLINS: So the Governmental Advisory Committee met in Lisbon from 24th to 28th of 2007. 46 members and three observers participated in the meetings. It's an incredible turnout.

The GAC expressed warm welcomes to the government of Portugal and the organizers, Foundation for Computer -- Computacao Cientifica Nacional for hosting the meeting in Lisbon.

On WHOIS, the GAC adopted a set of principles regarding generic top-level domains WHOIS service.

The principles are annexed to the communique.

The GAC held a joint session with the GNSO Council regarding the recently completed WHOIS task force final report.

The GAC noted that the recommendations included in the report indicate a significant division of views regarding the appropriate approach to WHOIS services and urges the GNSO Council to continue its efforts to develop consensus-based proposals.

In this regard, having completed the principles, the GAC is committed to continue consultations on the WHOIS issues, including providing additional advice, as appropriate, prior to the further consideration of any recommendations by the board.

On new gTLDs, the GAC adopted principles regarding new gTLDs -- and these principles are annexed to the communique -- which are intended to provide the ICANN board and the wider global community with a clear indication of the government priorities for the introduction, delegation, and operation of new gTLDs.

I would like to clarify that these principles do not address new IDN gTLDs, but only new strings written in Roman script.

The principles respond directly to several agreed provisions resulting from the World Summit on the Information Society and will provide a coherent framework for future interaction on these issues, particularly in relation to the ongoing ICANN policy development process on new gTLDs.

On IDNs, Mr. Chairman, the GAC acknowledges with satisfaction ICANN's 7th March announcement of its successful conduct of laboratory tests on Internationalized Domain Names.

The GAC has taken note of the draft issue paper on selection of IDN ccTLDs associated with the ISO 3166, slash, 1, two-letter codes prepared within the joint ccNSO/GAC IDN working group.

In the spirit of collaborative effort, it was adopted -- that was adopted in Sao Paulo meeting, GAC has asked all its members to evaluate the sociopolitical and cultural implications of the issues outlined in the aforesaid paper in terms of languages and characters that may be used for IDN ccTLDs and respond directly to the ccNSO Council.

The GAC has similarly taken note of the outcome report of the working group on IDN constituted by the GNSO Council.

The GAC recognizes that the IDN ccTLD standard development processes can be slow and would encourage early action to develop methodology to prepare these standards.

The GAC and its members, along with the ccNSO and GNSO Council, will work towards the global deployment of IDNs, which will expand the spread of IDN -- of Internet, and enable a vast number of people to exchange information in their local languages.

On interaction with ccNSO, the GAC had a useful exchange with the ccNSO on ccTLD issues. The GAC heard views from ccTLD community on ICANN's regions and noted the sensitivities associated with this issue.

The GAC received a presentation of national case study highlighting questions being addressed in the country. The GAC intends to continue this dialogue with ccNSO on sharing good practices.

The GAC noted that the consultations on retiring country code raises public-policy issues and intends to provide advice in due course.

The GAC reminds the board that the applicable version of the GAC principles and guidelines for the delegation and administration of ccTLDs is the one dated 5th April, 2005, adopted in Mar Del Plata meeting, and attaches these principles to communique for information.

Mr. Chairman, on ICANN's board and GAC cooperation, the GAC welcomes the introduction of master calendar, which will allow all constituencies to participate in ICANN's policy development processes in a coordinated fashion. The GAC also welcomes the formulation of extensive outreach program and looks forward to contributing in this ongoing work.

On transparency and accountability principles, the GAC recalls the paragraphs of WSIS Geneva declaration of principles and Tunis Agenda for the information society relevant to international management of Internet.

The GAC took note of the affirmation of responsibilities for ICANN's private sector management approved by the ICANN board of directors on 25th September, 2006. The GAC encourages ICANN to continue posting advanced notice of the board meetings and agenda and full minutes of such meetings and maintain a spirit of transparency in its deliberations.

The GAC intends to provide advice to the board on the development of ICANN's transparency and accountability management operating principles and looks forward to the report commissioned by the board from the One World Trust.

On other matter, Mr. Chairman, we had a discussion on the status of application on ICM on triple X. In this regard, the GAC reaffirms the letter sent to the ICANN board on 2nd February, 2007.

The Wellington communique remains a valid and important expression of the GAC's views on triple X. The GAC does not consider the information provided by the board to have answered the GAC's concerns as to whether the ICM application meets the sponsorship criteria.

The GAC also calls the board's attention to the comment from the government of Canada to ICANN's online public forum and expresses concern with the revised proposed ICANN ICM registry agreement the corporation could be moving towards assuming an ongoing management and oversight role regarding Internet content, which would be inconsistent with its technical mandate.

As requested last meeting, GAC made a nomination for representation in ENAC, Emergency Numbers and Addresses Committee, with the expressed hope that this committee would never come together.

So the following members have been designed to serve as the GAC representatives to ENAC, namely, Mr. Pankaj Agrawala, from India; Mrs. Mainouna Diop from Senegal; Mr. Augusto Gadelha, from Brazil; Mr. Bill Graham, from Canada; and Mr. Stefano Trumpy, from Italy.

Concerning President's Strategy Committee report, the GAC welcomes, with interest, the final report of the President's Strategy Committee, and would appreciate receiving information from the board on how it intends to associate the GAC and its members with any follow-up activity to this report.

The GAC expects that any such follow-up activity will fully take into account relevant provisions of the Tunis Agenda for the information society.

The GAC warmly thanks all those among the ICANN community who have contributed to the dialogue with the GAC in Lisbon. The next GAC meeting will take place during the ICANN meeting in San Juan, Puerto Rico, from 24th to 28th of June.

I would like also to note that this communique and its annexes constitute a formal advice to the board from the Government Advisory Committee.

And, in closing, I would like personally to thank ICANN for assigning a liaison to the GAC. And I'm looking forward to fruitful cooperation with Donna Austin.

Thank you, Mr. Chairman.

>>VINT CERF: Thank you very much, Janis. It was nice brevity and concise. So you need not tremble any further. It was a well-done report. And, of course, we appreciate the advice of the GAC and will take it into consideration as appropriate.

The next report comes from Bruce Tonkin, the chair of the generic names supporting organization.

We are now only 15 minutes late. So the GAC, incredibly, has gained five minutes on the speed of light. We appreciate that.

>>BRUCE TONKIN: Hopefully, this will appear in a moment.

Okay. The GNSO, like the ccNSO and the GAC, has had a busy week, which started early on Saturday morning and has pretty much been working nonstop ever since.

The, I guess, main issues that we've been considering have been issues relating to new gTLDs. And we had a workshop on new gTLDs on Monday afternoon. And also, considering what our next steps would be in considering the WHOIS task force report. And we've had a number of meetings with -- also with the GAC and also within the GNSO, to consider next steps. So I'll try and sort of cover mainly the -- I guess the outcomes or the new material for this meeting rather than cover some of the material that we've presented previously during the week.

Firstly, on new gTLDs --

Perfect timing (Phone ringing) -- I think just to put it in context with new gTLDs is to also put new gTLDs in the context of global trends. And I think what we're seeing is that now many people in the world have access to convenient travel and also communication technologies. And this has meant that people no longer necessarily associate themselves with countries, because their community of interest is often distributed around the world, and they often meet people via travel in many different places. So we're seeing this sort of growth of international communities of interest that are cross-border.

We also see individuals increasingly have multiple citizenship, and increasingly have multiple language skills.

Companies and organizations are also now global and operate across many borders. So that's, I think, the context within which we're operating today.

The background of new gTLD work is that there was an initial ICANN working group on new gTLDs in June of 1999. And the arguments for and against new gTLDs have pretty much stayed consistent with that original working group report of 1999. To summarize some of the for and against, I think there are a range of arguments for, and they probably include increasing choice, improving diversity of the network, competition reasons, encouraging creativity, allowing innovation, providing an opportunity for global communities to have their own domain name hierarchy under the root.

I think the reasons against is it's unnecessary, because people can just register at the second level in the existing hierarchy. And also, there's seen as a requirement for defensive registrations to protect corporate brands.

I guess -- so the history, then, is, in 1999, there was an agreement to introduce new gTLDs and begin with a test bed with six or ten -- six to ten TLDs to sort of test to see what the impact would be on the network and whether it was a good idea or not.

In the first round, we had quite a diversity. We had fairly open names like biz and info, and more restrictive names like dot museum specifically for the museum community. Then again in 2004, we had another limited round, and we had dot travel, dot cat, and dot Asia. And it's interesting that they are three completely different types of TLD, if you like. Travel is obviously a particular industry type or recreational type. Cat is a -- relating to a particular language community. And Asia is obviously related to a geographic community. So we've seen quite different approaches there.

So this then leads to should we try and structure this top level in some way, should we go along commercial grounds and use things like finance, manufacturing, all the different commercial sectors? Should we look at different user groups, so we could have PC users, Mac users, other users. Or should we talk about food types, we have fish eaters, meat eaters, and in fact there are some that don't really eat very much.

Or should we allow communities to identify the strings that are most useful to their users and really not try and impose what any of our views might be on what that hierarchy looks like.

And I think the general decision of the GNSO back in around 2003, 2004, was the latter, that it wasn't possible to reach agreement on a structured hierarchy, there are just so many possibilities for how that might look.

So that comes down to why new gTLDs.

And I think this is one reason that I've chosen out of the range of reasons I've heard so far, but I think this is particularly relevant when we start considering IDN-based gTLDs. And that is, essentially, that we want to support the functional, geographic, and cultural diversity of the Internet by allowing globally distributed communities the opportunity to have their own hierarchy of names starting at the top level and recognize that not only communities identify themselves with either countries, in other words, the existing ccTLDs, or by the original broad com, net, org categories. Com was for commercial, net was for network operators, and org -- and I checked the RFC -- was for miscellaneous.

And it was interesting that I don't really think they have envisaged that individuals would own domain names. I think it was in the sense that it was big organizations that had domain names. And so we had commercial organizations, network operators, and other types of organization.

So the new gTLD committee accepted the outcomes of the 1999 work, taking into account the experience with introducing new gTLDs so far and focused on lessons learned and creating a process for introducing new gTLDs in a scalable manner.

And throughout that process, we've used the ICANN mission and core values to guide that work.

While this work on new gTLDs has been conducted, international domain names have been a hot topic of the last few years. And the committee supports the introduction of IDNs once the technical testing has been completed. And the intent is that they will be treated the same as any other new gTLD in the process. But we do recognize that, obviously, it makes implementation more complex.

An example of that is that we have a requirement that strings at the top level should not be confusingly similar. And we recognize that once we open that up into different scripts, that we need to get advice from people that have expertise in those scripts and expertise in the languages that use those scripts. So there's certainly going to be a need, I guess we'll see a lot more diversity even in the decision-making processes and in the evaluation panels that are used in the process.

We did establish a GNSO IDN working group. And that completed its report last week. And mostly it's identified many areas of implementation. And a lot of those recommendations for implementation will be incorporated into our final new gTLD report.

Which brings me to the next steps. And I'm not going to attempt to take people through -- in this session through the process, because that was done on Monday in depth.

But we're seeking to finalize our recommendations by May of this year and produce a final, final report. And then we will submit what's called the board report to the board by early June of this year. And then available for the board to consider at its meeting in Puerto Rico.

Now, we recognize that not every element of implementation will be dealt with. But we feel at that time it's appropriate to formalize the policy of introducing new gTLDs and recognize that the staff will continue to work with the GNSO to examine matters such as dispute resolution details, et cetera.

The other big topic before us this meeting was WHOIS, as it is at every meeting. And I think, again, I just want to go back to a bit of the background and what WHOIS is and what its requirements are.

I think there are really two requirements in terms of the policy process. The first one is that the contact information must be adequate to facilitate timely resolution of any problems that arise in connection with a registered name. And, secondly, that we need to take reasonable precautions to protect personal data from loss, misuse, unauthorized access, or disclosure, alteration, or destruction. So I think those are the fundamental requirements.

We -- the council received the final report of the WHOIS task force in the last week or two, and the -- that task force report has recommendations with a narrow majority of support in the task force. And, essentially, three of the six GNSO constituencies are in favor of those recommendations as they stand. And the other three constituencies have remaining issues that need to be considered before they feel comfortable in supporting those recommendations.

We also met with the GAC on Sunday and heard similar concerns as has been raised by some of the opposing constituencies. And so what we've decided to do is first thank the WHOIS task force for the work that they have done. And they have been working on this for a couple of years. And I'd like to particularly thank the chair of that task, Jordyn Buchanan. And at times, he probably felt that he was trying to chair a meeting between Attila the Hun and Ghengis Khan.

He has been patient and made his best efforts to try to incorporate all the suggestions and work of the different constituencies in that group.

What we've decided to do now is to create a -- what we call a GNSO working group. And a working group's a little bit different to a task force. A task force is very structured and has a set number of representatives from each constituency. And we've also allowed the At-Large Advisory Committee to appoint someone to those task forces. And typically, we've appointed one of our council members that has been appointed to the council by the Nominating Committee. And the way that has worked out in the WHOIS task force is it's really just acted as a casting vote, that the three constituencies have consistently opposed each other through most of the work, and the Nominating Committee member effectively has a casting vote.

So we feel that we need to sort of open that group up a bit wider and, naturally, continue to include constituency members, but perhaps not limit it to one or two reps per constituency, but allow broader participation.

We're really encouraging direct participation with some people that have law enforcement expertise. They don't have to be representing in the sense of, you know, presenting the official line of a particular law enforcement body, but what we're trying to seek is people that have worked in that sector that are prepared to provide us with expertise in their area.

And also, more broadly, allow community participants at what we call an observer level. They don't have a vote, but they may participate and contribute their knowledge and experiences.

And many of the things that we study in WHOIS I think have been studied in many other parts of the community, particularly in governments, where governments store data and make data available on a basis based on sets of rules to legitimate users.

So there's many models out there, I think, with adding some additional expertise we can consider.

And the idea is to cap the length and time this working group will work for, so it will be 120 days. And that will work to examine the issues raised with respect to the policy recommendations of the task force and then make recommendations to the council concerning how those policies may be improved to address the issues that have been raised by those that have concerns with the current recommendations.

So the working group tasks, then, that we have focused on is basically focusing on the concerns that members of the community have raised this week with the current task force recommendations. And that is to define the roles, responsibilities, and requirements of the contact point. And today that contact point, for those that are familiar with today's WHOIS, is essentially similar to the admin contact. Currently, it's not defined what the role of the admin contact is. We're now calling this the operational point of contact. But, essentially, it's similar. And provide some clarity on what those roles are. But also provide clarity for what happens if those roles are not fulfilled. So if you contact this point of contact and they just ignore you, you know, what are the next steps?

The other issue is that where some data is removed from public access, we do need to identify how the legitimate interests -- and these legitimate interests include law enforcement, intellectual property, Internet Service Providers, individuals that may be concerned about some bad action as they perceive it related to the use of the name -- so we need to look at how we continue to provide access.

And also, we want to consider whether a distinction should be made between the registration contact information that's published based on the nature of the registered name holder, so is it appropriate to distinguish between legal persons, which is generally being referred to as companies and organizations and so forth, or natural persons, being individuals? Or should it be in some way related to the use of the name, if it's used for commercial or noncommercial purposes, for example.

Now, these are not easy distinctions to make at a registration level for a registrar, but -- at the time of registration, but those distinctions may be useful when it comes to complaints. So, as part of a complaint, you may be able to show that this person is of a certain type, and based on that type, there's certain action that can be taken in those circumstances, or certain data that can be made available.

So that's basically the end.

So I'll leave it there, Mr. Chairman.

>>VINT CERF: Thank you very much, Bruce.

Ask you also to remain in the room in case there are questions as we complete all of the reports for this morning.

The next report is from the root server system advisory committee. And I'll ask Suzanne Woolf to present that report. Suzanne, do you want to do that from where you are?

>>SUZANNE WOOLF: Yeah. Which microphone? There we go.

Yeah, I was planing to stay here and maybe save some time, out of respect for our schedule, although, I'll note, Mr. Chairman, that network people have been asking for faster light and slower time for decades now.

[ Laughter ]

>>SUZANNE WOOLF: We'll do our best.

Okay. I'd like to present just a brief overview of some of the recent activities by RSSAC. I'll try keep it quick.

>>VINT CERF: But remember to speak at a moderate pace.

>>SUZANNE WOOLF: Yes. I had that conversation with the transcriptionist yesterday in the SSAC meeting. They promised me chocolate.

Just to recap, for those who may not know us, we're one of the original ICANN advisory committees, including root name server operators, the RIRs, researchers, and interested others.

RSSAC does not represent the root name server operators but serves as a forum for interaction between operators and ICANN.

Provides written recommendations and informal advice to IANA. Meets regularly at IETF, most recently in Prague just a week ago.

A couple of updates on current activities.

First, the summary, and some more detail to follow on a couple of these items. On IPv6 addresses for the roots, we have, in a joint effort with SSAC, report to the board has been finalized. There's a -- there will be a little more detail on that in a couple of minutes. And also spent some time on that in the SSAC meeting yesterday. So the archive of that more lengthy presentation will be available.

On DNSsec for the first time at this meeting all of the root server's report ready to serve signed data. So we regard that as a critical step to signing the root and are very happy to report that.

We also have been working on a consensus statement. We have been working at the last couple of meetings with Tina and the other staff and interested parties on IDN. So we have a statement that I hope to have finalized today or tomorrow on IDN.

But before we go into the current -- the formal work items, the results of this meeting, I'll note there was some discussion of a recent event that involved some of the root name servers, made some headlines. On February 6, several of the root name servers observed an unusual amount of traffic to some locations. A distributed denial of service attack, an attempt to overwhelm servers and network links.

It lasted for a couple of hours, and presented a standard DDOS profile. It did not look unusual to security experts we saw -- we talked to as far as what we saw.

The impact of the attack was very limited. Some users saw some delay. We think in DNS resolution.

But there were several reasons why the damage was confined, was limited.

First, only some operations were attacked, which meant that if you couldn't reach one, you could still see the others. The DNS is designed to be redundant that way, and there are, in fact, 13 different ways -- different entry points into the system and many, many more than 13 servers that provide DNS service for the root.

For operators that use Anycast, Anycast compartmentalized the impact. So even when one location saw a significant impact, other locations belonging to the same operator did not.

The discussion in the RSSAC meeting centered primarily around shared monitoring and analysis capabilities and possibly closer coordination in the future with TLD operators and an agreement to continue discussion on both of those items.

For the formal agenda of the meeting, we spoke on the IPv6 work item. We have some news on that.

This seems especially timely in view of the RIRs report on IPv4 address supplies and future of the IPv4 address space.

The need for the DNS infrastructure to be fully IPv6 compatible was identified some time ago, but there was also a significant due diligence to undertake as there is anytime we add new capabilities to the existing service.

We just completed the recommendation to IANA to IPv6 addresses to the root for TLDs several years ago. Several of the roots are ready to put the service into operation. However, we haven't yet added v6 addresses for the root name servers themselves until this report was done, this due diligence was done.

There have been concerns about backwards compatibility for the installed base. It wasn't clear that older software on the Net was ready for this, and of course there is no flag day you can impose on the Internet. There's no way to make sure everyone upgrades. So there's a need to make sure there's no inadvertent harm done to holders of older DNS software in the name of enabling the future.

Not to go into technical details on that, they are in the report, but RSSAC and SSAC together did the due diligence and have made a recommendation to the IANA to proceed with IPv6 addresses for the root servers. And we are very pleased to report that.

IDN, we report IDN for the Internet is a very complex undertaking. DNS in the root is only a very small part.

We have been -- we are forwarding a consensus statement to the board, including a few technical and operational points.

There is no problem that we can see with a proposed test of standard delegations of name server records for IDN. We request that ICANN, and particularly IANA, keep us informed as test plans and implementation go forward.

RSSAC is happy to provide advice on DNS specific technical aspects of test and deployment, and on the specific issue of aliases for existing names in the IDN space. Should aliasing become a requirement, RSSAC would work with ICANN to identify how to meet it. But it's our understanding that such a requirement has to come out of the policy processes undertaken by other bodies.

A couple of odds and ends.

One work item that we've recently taken on is a revision of RFC 2870. An obscure technical document that some of you know is the most recent formal best practices for root name servers. It's been a useful guideline document for us but was written in 2000 and is seriously obsolete. It was written before DDOS, before Anycast, before significant employment of IPv6.

We've observed that having it out there can lead to misunderstandings, since the provisioning and operations guidelines it suggests are often somewhat naive for the current environment.

So we're working on a revision that will provide some more realistic guidelines both for what we do today and for the evolution of the service going forward.

The other item is RSSAC has always had very little need for formal process, but we do see a few things evolving as we go forward.

The current item being a succession plan with a little more formality.

We've also recently appointed a vice chair. He ran the Prague agenda. Jun Murai remains as our chair, Matt Larson is our vice chair. So we have a little more process in place and we will be delivering a draft of a succession plan as an item for our next meeting.

A few administrative notes.

Next meeting in conjunction with IETF 66, July 9th of this year.

Particular reviews and updates we expect at that time, any further discussion with ICANN on IDN. The usual operational updates on Anycast and any service deployment, and the presentation here will have the usual URLs for further information which I will not go through now. Although note that our committee page on the ICANN site is part of the revision of the new Web site launch this week. I'm not sure if the new content is up yet, but will be soon.

And that completes my report, Mr. Chairman.

>>VINT CERF: Thank you very much, Suzanne.

Gained a few more minutes. We may actually catch up.

I noted that Steve Crocker just came in, and so Steve, if you are actually prepared, I'm happy to ask you to present the Security and Stability Advisory Committee report.

You can do it either from where you are seated. We can pass the projection dongle, or you could go to the podium if you wish.

We have a little fishing expedition here to complete.

>>STEPHEN CROCKER: So I apologize for not being here from the beginning.

>>VINT CERF: Steve, is your microphone on?

>>STEPHEN CROCKER: Now it is.

So thank you. I apologize for not being here earlier. I was drafted into giving a keynote speech on IPv6, which I'm not actually a major expert on, down the hall at our hosts IPv6 meeting. And I was very pleased to be able to do that.

I chair the -- let's see. We're having a little trouble with the -- Are you seeing the same flashing that I'm seeing?

>>VINT CERF:It seems to be okay on the screen, Steve.

>>STEPHEN CROCKER: Here it's showing flashing. Oh, just the ones right next to me.

[ Laughter ]

>>STEPHEN CROCKER: How do they know that it's me?

>>VINT CERF: I'm sure that it's a Bluetooth effect.

>>STEPHEN CROCKER: I chair the Security and Stability Advisory Committee. I had to count all the way up to five to figure out how long I have been doing this, which is getting to be a long time. I was talking to Hagen Hultzsch the other day who had been on the board, I'm sure many of you know, and he -- it was in another context, but he may have been talking to me, he said, "You know the rule of three, five and seven. After three years you are permitted to leave, after five you should, and after seven you must."

And so I took it to heart.

So sometime, sometime, not instantly, no announcement here, but one of the things on my mind is the ultimate transition and stabilization of SSAC so that it doesn't just have a single personality to it.

I'd like to do a very brief introduction of what we are about, and then I want to talk about three things. Two very big results, and then one thing starting up.

We are a source of security and stability expertise. We give advice to the board. We are chartered under the board. We give advice to staff, Supporting Organizations, and also to the community at large.

We have a fair amount of independence -- that is, we're not a public relations organ of ICANN, exactly. We're not adversarial, either, but we try, as I say, to be somewhat independent, to speak to the issues that we see, very often self-tasked.

The other side of that equation is we give advice. The advisory part of our title is, I think, extremely important. We don't have any formal authority built into our structure. There's no requirement to run things past us, nor is there any requirement to listen to what we say.

Of course, you are foolish not to pay attention, but that's a separate matter.

Here are the members and key people who are involved. It's a very distinguished group. With the exception of Dave Piscitello and Jim Galvin who are paid members of our staff, the rest of us all have regular day jobs in critical sections of the industry in registries, in address registries, in ISPs, in security research and so forth.

We don't have functionaries, we don't have bureaucrats and so forth whose job it is to be a member of SSAC.

There is another organization that we are strongly cooperative and coordinate with. Lyman Chapin chairs the registry services technical evaluation panel. This has come out of the revision about how changes in registry operations are handled through a funnel process, so-called, and that when there are security and stability issues raised with respect to the introduction of a new service by a registry, after an initial look, if it's determined that there is a substantive question, a very organized and very short-fused process takes place. The standing team of experts and a couple of months, 45 days I think is the interior of that process, and then it's got some time around the ends, the beginning and the end of that.

And in our public sessions, we have made a point of providing time for Lyman to present his results and we keep in quite close contact.

They did not have any transactions to report between the last meeting and this meeting, so his report yesterday in our public meeting was brief.

Okay. On to the good news.

Some of the root server -- some of the 13 root servers have IPv6 addresses. Some of those name servers. None of those IPv6 addresses currently are being advertised within the root zone.

Why is that? And the answer is that the historic -- historical design of the initiation process, the so-called priming process for getting a resolver going at the beginning of its operation, is that it would ask -- it would have an idea about where the root servers are built into a hints file or from some other source, and then it would ask one of those addresses in there for the official current list of root servers -- root server addresses. And the answer would come back all 13 addresses, and things were constructed so that those addresses fit within a single packet.

And a single packet historically has been 512 bytes, and so there was a constraint of how do you fit all of those addresses into that size packet. And they fit, but not by -- but not with very much room to spare.

Now, along comes IPv6, and if we start assigning IPv6 addresses, which are four times as long, and in addition have to retain the IPv4 addresses, how will they fit within a single packet?

And if they don't fit within a single packet, what happens? Does something break?

That's the question that has sort of hung in the air for a period of time.

That question needs to be answered in order to reach the point at which there is eventual smooth operation of IPv6, end to end, top to bottom, without dependence on IPv4. How soon will that be? Not very soon.

But it is a necessary piece of the planning so that one can begin to see IPv6 self-sufficiency instead of merely IPv6 as an adjunct to IPv4.

So that's the question we took up.

There are a number of technical details.

Are the end systems now able to handle larger packets in and the answer turns out to be generally yes. And in fact, more than generally. Almost uniformly. Small little details around the edges, but rapidly disappearing.

Another element that is not immediately visible, doesn't come obviously to mind, is that there are boxes in the middle of the processes, firewalls, address translation boxes and the like, some of which may not, or at least we were concerned might not be able to handle the longer DNS packets, or, conceivably, were not expecting to see IPv6 addresses within those packets.

We engaged in considerable amount of testing, of consultation, reaching out to vendors and to operators, and we got very, very good, very good results. These results are posted on the Web site, ICANN Web site. We did this work jointly with the root server system advisory committee, a very successful joint venture.

The basic recommendation is to move forward but to move forward in a very deliberate fashion with plenty of time and plenty of notice and interaction with the community.

And we will be polishing off the findings and recommendations and handing that up to the board and on to IANA for consideration, and that will proceed.

The other thing I need to mention is along the path of DNSsec adoption, Sweden and Bulgaria are now up. Sweden has done a formal commercial launch of DNS security service last month in Sweden. I was privileged to participate. And I was expecting a very well organized and professional operation.

It was all of that, but it was a great deal more.

In addition to the registry and the registrars being prepared, they worked with one of the major banks, Swede bank, and with the major ISPs who are running resolvers that are DNSsec compliant. And so that's a worked example that is serving really as a beacon around the world.

I have since, in the short time since then, encountered multiple groups that are traveling to Sweden or drawing from that experience and using that to move their own DNSsec implementations forward, including even a portion of what's happening inside of ICANN, which is very good.

And so over the next period of time, there will be additional adoption.

We still, of course, will have to wait and see for the very big players, for com, net and org, for the vendors like Microsoft and Apple and AOL and so forth. There is progress there. Little bits have been announced in the past, I won't go into it here, and more to come.

Finally, on the what's coming up side of things, we're initiating an IDN study. What in another IDN study, you say? That's kind of my reaction, too, but it's necessary.

The question has to be both asked and answered: Are there security and stability related to IDNs? If so, what are they and what limits do they suggest on the range of options? It is certainly not our job to dictate what the policy should be but it is our job to raise awareness of consequences of different paths and to try to make a distinction between things that will work and the things that are likely not to work and to provide that guidance to the users and decision-makers who have to choose what path to go.

We'll move as quickly as possible. We fully appreciate the urgency, and at the same time, there is this collision between physics and politics. And historically, no matter what the policies are, the physics usually wins, sometimes in an ugly way and sometimes not. But there we are.

So with that, I will get off the stage. I don't know whether I have helped or hindered the schedule here, but I have talked as fast as I can this morning.

>>VINT CERF: Well, I'm glad that you didn't speak any faster out of consideration for our scribes.

We are about ten minutes behind at this point. It's time now to call on the ALAC for its report, and my notes say that Jacqueline Morris is going to offer that report to us.

After which, we will open up the floor to questions on the reports that have been presented so far.

I'll also be asking Kieren McCarthy to relay any questions that may have come in the online forum or other means of asking them.

Jacqueline, please go ahead.

>>JACQUELINE MORRIS: Thank you.

Good morning, everyone.

The At-Large Advisory Committee has had a very busy three months since Sao Paulo. Today we will have the signing of the Memorandum of Understanding between ICANN and two new regional organizations, Africa and Europe.

Asia, Australia, and the Pacific Islands has also concluded their Memorandum of Understanding.

These new RALOs join the Latin America Caribbean RALO in making the ALAC truly representative of and responsible to the individual Internet users in these regions.

North America has been a challenge for the ALAC.

It has the lowest participation, even though it is among the largest in terms of number of Internet users.

We are working hard to form the North American RALO however, and hope to have some positive news for you by our next meeting.

These advances have led to many changes in the composition of the ALAC, as the interim ALAC members who have spent a long time getting these RALOs up and running are replaced by members rooted for by the regions.

At this meeting here in Lisbon we will have six new ALAC members out of the 15, and Latin America - Caribbean's two members who joined us in Sao Paulo. Familiar faces are moving on but most of them will remain involved with ICANN.

At this point I would like to thank the outgoing interim ALAC members for their dedication and hard work. We also have to thank our last chair, Annette Muehlberg, who resigned recently for personal reasons but who led us very capably through almost all of the RALO formation process to date.

ALAC has also been deeply involved in policy issues that affect the individual Internet users. We have drafted statements on three of these issues and I will expand a bit on them now. The statements will soon be available online.

>>VINT CERF: I'm sorry to interrupt. It's Vint. You might moderate the speed just a little bit. Thank you.

>>JACQUELINE MORRIS: Sure. I can go slow. Okay.

On domain tasting and domain monetization. These are two different issues, only one of which we believe falls within ICANN's purview. Namely, domain tasting.

We believe the five-day add/drop loophole is being exploited to the instability of the Internet addressing resources. However, we recognize more rigorous research is required to establish its effect in a completely convincing manner. ALAC is therefore taking the necessary steps to formally request the initiation of a PDP by GNSO on this matter.

I am happy to report that we are actively working on this with several constituencies within the GNSO. At the same time, we invite any other constituencies and groups who share our concern on this issue to work with us on achieving a common consensus position.

While many of us believe that domain monetization might cause confusion and does not benefit user experience, some of us consider it a content issue, and hence outside the realm of ICANN regulation.

On internationalization of domain names. Through ALAC's efforts, nearly 100 user organizations rooted in more than 40 language communities on all five continents have joined the ICANN community. You may have noticed recently ICANN has translated documents in the meetings into Spanish, French and Portuguese and has provided simultaneous interpretation at these meetings. More is needed, and we hope soon ICANN can function effectively in multiple languages.

Internationalized Domain Names will remove the last barrier that prevents non-Latin script users from conveniently and effectively using the Internet. Despite all the challenges and difficulties in implementation, IDNs are crucial to the achievement of true global participation in the Internet community.

ALAC has been actively participating in the IDN activities of the president's advisory council -- committee on IDNs, and on the policy-making activities in the GNSO and ccNSO.

>>VINT CERF:Jacqueline, I'm sorry, it's Vint again. Can you slow down just a little bit. Maybe a little bit more. Thank you.

>>JACQUELINE MORRIS: Okay.

ALAC is committed to bringing the users' voices to ICANN and facilitating relevant research and policy. Deployment of IDNs raises many technical problems and policy concerns.

We strongly suggest the following be taken into account in the policy-making and technical application processes.

One, representatives from the at-large community, particularly from the regional at-large organizations, be able to join all of the ICANN IDN policy-making processes with full membership and voting rights.

That local and regional preexisting developments regarding IDN gTLDs be taken into account when considering introduction of new IDN domains.

That support from the local language community be a key element considered for evaluation of IDN TLD applications.

And that ICANN IDN policy-making and implementation processes be substantively accelerated and no delay be tolerated.

In recent days, we have heard extensively about the RegisterFly issue. But we should recognize this is more than a singular incident.

Having examined the events connected with the RegisterFly case, noting the request for input made to the community by ICANN CEO Paul Twomey, and in its commitment to seeking the best interest of the individual registrants, the ALAC has resolved that ICANN, as the entity responsible for accreditation of gTLD registrars and registries, and for the related contractual conditions, should make it duty to ensure that such contracts guarantees the minimum protection and prerogatives of registrants, especially individual ones, that are necessary to keep the market effective and competitive by allowing consumers to freely select and change their domain name suppliers and to enforce such rights in a predictable and accessible manner.

Specifically, in regard to contractual agreements, recognizing that the public Internet users are intended beneficiaries of its contracts, ICANN should strike the no third-party beneficiary language from its registrar accreditation agreements and registry agreements. That ICANN should promptly adopt a schedule and provisions for escrowing of data from all registrars as envisioned in RAA36, and from all registries.

That ICANN should ensure that the agreements contain appropriate clauses that, while ensuring the security of the process, allow all registrants to promptly transfer their domain names away from registrars that provide an unsatisfactory level of service without financial or procedural burdens.

ICANN should ensure that the agreements require registrars and resellers, to the extent possible, to provide adequate information to all registrants about their contractual rights, and that ICANN should enforce its contracts, possibly while adding intermediate and graduated actions against breaches of contract.

The ALAC recognizes that much more can be obtained by adequate education of registrars, resellers, and registrants, and by the establishment of voluntary lightweight best practices regarding procedures and relationships between these parties.

The ALAC proposes to work together with the registrar constituency and any other interested party to build consensus on a mix of useful additions to address these issues.

And that's it. Thank you, Mr. Chairman.

Thank you.

>>VINT CERF: Thank you very much, Jacqueline.

I must say that progress has been substantial in the ALAC sector, with the large number of ALSs and now new RALOs that are coming. In fact, at the end of the day, we'll be signing a collection of agreements. So that will be a very important milestone.

We're -- it's possible now to undertake responses to questions, if there are any from the board or the floor, to any of the speakers who have presented this morning.

So let me ask if there are any questions either from the floor, the board, or from Kieren, who is channeling people who are coming in from the outside.

Peter.

>>PETER DENGATE THRUSH: Thanks, Vint. Very belatedly, this is actually a question directed to the meetings committee. These were the reports that were put up. I want to hear from the meetings committee not necessarily now, but some feedback on what the changes to this meeting may have achieved, the way we started with the open forum and moving through finally to concluding with the forum and some of these other changes.

So --

>>VINT CERF: The meetings committee chair is not here.

So perhaps you could -- either we can get a public answer or you can check with Susan when you see her.

Thank you, Peter.

Other questions?

I have one or two for Ray Plzak. So let me ask Ray if he would please either take the microphone -- or if you're more comfortable, you can use the lectern.

Ray, first question, there was mention -- All right. While they're fuddling with the microphone, I'll ask the questions anyway.

There was mention of the 16-bit ASN number utilization. I think one of your charts showed that. Or it may have been in the ASO report.

I had thought that 32-bit ASNs were already in use. Have I misunderstood that? Because I see that there were still some consideration of policy for the 32-bit ASNs.

>>RAY PLZAK: The answer is, is that the report that you saw that Sebastian presented represented what has happened over -- since the last meeting that we had here with the board.

And, in fact, the 32-bit AS number has been adopted in all regions, and that policy called for a schedule of a transition. And that has been put into effect.

>>VINT CERF: Is it -- Well, okay. I'll take up some other specifics later on.

The second question has to do with getting IPv6 going. And you were eloquent, I thought, in your call for that.

Is there any possibility that the RIRs could work with the ISPs in order to help spur this along?

My impression that all of the software is there, but the ISPs often have not turned V6 on because they don't think anybody is asking for it.

What's your sense of that?

>>RAY PLZAK: My sense of that is that there has been work done in this area by the community in terms of policies. If you look at some of the policy, for example, the provider independent policy, the -- up until September of last year, it was not possible for anyone other than a service provider to receive I.P. addresses -- V6 addresses directly from a registry. Since September, that's been possible in the ARIN region and an actual discussion is occurring in the other four regions. And you can expect adoption of similar policies in them as we go forward.

There have been other things that have been discussed. In fact, over the last week and a half, there's probably been close to about 1,000 to 1500 e-mails discussing various aspects of this subject. And they have ranged from a number of things from different adjustments, again, of fees, perhaps escalating service fees associated with V4 and other things.

So the RIR community, which, basically, is a large part consisting of the ISPs, is engaged in this conversation.

But, again, as I said earlier, the use of the allocation policy process is perhaps becoming a little overtaxed in this area. And we need to find other solutions.

>>VINT CERF: Thanks very much, Ray.

Do we have any other questions? Peter.

>>PETER DENGATE THRUSH: Just a follow-up to yours, Vint.

Ray, thank you for that. I reacted, naturally, as I'm sure you intended, to the word "panic" in the IPv6 implementation side.

>>RAY PLZAK: The word was "frantic," Peter.

>>PETER DENGATE THRUSH: Sorry. Frantic.

First question, is this something that ICANN actually should be doing, this preparing the community for the expiration of IPv4 and introduction of 6? Or is this something that we just have to watch you dealing with? And you described the community, if it's -- the address registries are doing. Is this something that ICANN as a corporation needs to be doing in this area? And if there is, what?

>>RAY PLZAK: Okay. First of all, IPv4 is not going to expire. It'll be around for years and years and years to come. It's not going to go away.

Second thing is that IPv6 has been available as unicast address space to be consumed since 1999. It's the problem in getting people to adopt it that has been at issue here.

ICANN, as a facilitator, and with its ability to perform outreach in various areas in the business community, the government community, and so forth, should try and position itself in such a manner as it encourages things to occur.

I mentioned a couple of things in relatively simplistic manner, for example, encouraging businesses to maybe free up some resources to assist the technical community in their development solutions, to governments looking for different ways that they could participate, and so forth.

So I think ICANN's position and ability to be able to interact with these bodies on different -- and constituencies in different manners is probably the most effective thing that can be done. And certainly education that, for example, would help encourage the business community to begin planning and doing things so that they don't have to frantically deploy and so that they can come up with a gradual -- especially the entrenched people, the people who have been using it forever, before forever, they can make this transition a much smoother one. There are efforts underway, but whatever ICANN can do to encourage it, I think, is probably the best thing they can do.

>>VINT CERF: Susan, Suzanne, you had a comment to make.

>>SUZANNE WOOLF: Thank you, Mr. Chairman.

Just very briefly, exception has been taken, it was noted to me, to a word I used when I gave my update in the context of the update on RFC 2870. I'd like to revisit that in context, if I may.

It's been pointed out that the word "naive" may have sounded pejorative. That's one of the words I used to describe the requirements in 2870. It was not meant as a pejorative towards anyone, not the authors, not the implementers, not anyone involved in these service specifications and implementation.

The takeaway point that I meant to make was simply and only that recommendations that were timely, complete, and appropriate some years ago in a very different environment are not so anymore, as the situation has evolved. But certainly with no pejorative intent towards anyone involved, either past or present, in those standards or specifications.

>>VINT CERF: Thank you very much, Suzanne.

Steve Goldstein -- or Thomas, did you have something specific to this? Or -- all right. Steve first.

>>STEVE GOLDSTEIN: Ray, I enjoyed your talk immensely. It was exceedingly informative. And so I have one question, just from my personal experience, that may have some application for a larger business community.

And that is, all the computers in my office are dual stacked. A lot of the peripherals, for example, HP printers, are not, that connect to the network. So do you envision that firms like HP would issue firmware upgrades to be able to be dual-stacked? Or will NAT'ing be able to take care of this? Or is there any outreach that would be useful to the vendor community to help make adjustments to IPv6?

>>RAY PLZAK: Here again, I would suggest that the education, the outreach effort is the best way to go here.

Specifically, in companies that are in positions where they are singular, if you will, in only IPv4 things, such as printers, this is where they can begin an early transition and gradually move in that direction. It would be less costly to do so.

And there are things that are happening now that would facilitate the movement to IPv6. For example, the latest release of Windows Vista, it comes with IPv6 enabled as the default. And it automatically will switch over to IPv4 if it doesn't see an IPv6 network, for example.

So there are vendor operations and activities taking place that would enable it. But if they go into an environment that is not, I guess -- I guess an appropriate term would be "friendly" to that deployment, it's not going to be widely used.

So it's one of those probably, usually, normally, generally, depends upon the situation type things. It's going to be different.

And, again, I think that the outreach efforts and so forth and encouragements that can be done to get the people that are best positioned to offer the incentives and to do something is the best way to move forward from our perspective.

>>VINT CERF: Okay. Thank you.

I'm going to ask that we curtail any more questions other than the ones that are still in queue.

I had Thomas Narten and Paul Twomey.

>>THOMAS NARTEN: Okay. Let me just say a few things.

I mean, the first one is, you know, what can we be doing more to encourage IPv6 deployment? I think the reality is that there's not a whole a lot of levers that we can actually pull to force people to do this.

And it's a fact, for example, that the -- all of the TCP/IP standards and Internet standards are voluntary. People will only deploy them if they see value and products will only implement them if they see value and so forth. We need to have a continued focus on education and let people understand that the world of IPv4 is going to change in the next few years fairly radically in some sense. You know, the IETF and other organizations need to work on the technical issues that Ray sort of alluded to. And the real technical issue that people cite all the time is that the IPv6 solution to multihoming isn't any different than the IPv4 solution. And that's been widely viewed as problematic for ten years or longer.

And the same goes, it would be nice if you could switch providers without renumbering your networks. That's an IPv4 problem. IPv6 really hasn't solved it in a significant way to where the problem just goes away. And there's a lot of sort of feeling that if that were actually solved with V6, then people would deploy it quickly because they would see clear value over V4.

But in terms of rushing this, I think, Steve, your point about the printer is very real. The reality is that what we're trying to do now is upgrade an infrastructure, where the vast majority of people that are using the infrastructure don't really understand how it works, can't be asked to do firmware upgrades and so forth. So the only way it's going to happen is if it just sort of slowly happens as people buy new equipment and the old equipment fades away.

Okay.

Thanks.

>>VINT CERF: Thank you, Thomas.

Paul.

>>PAUL TWOMEY: Ray, thanks for your presentation. And thanks for the check. That was great.

My questions are not associated -- well, my comment about the check is not associated with....

First of all, I think we just -- I just want to say that all the work that's going on with this discussion about an SLA and trying to get the SLA agreement in place, I appreciate all the work that you and your colleagues are doing. And I know this is not an easy task. But we're still very committed to trying to be in that sort of relationship and being quite clear about what our accountabilities are to you and -- so thanks for all the efforts that you're making. I really appreciate that.

Can I just take you through -- now I'm separating it out.

Can I take you through a scenario?

It -- am I right in seeing from your presentation that although it's very important to promote V6 takeup, that we're going to be facing an environment of V4 in the network which is going to be years, if not decades?

>>RAY PLZAK: The answer to that question is simply "yes."

>>PAUL TWOMEY: Okay. If that's the case, we -- I was -- I was interested that you pointed out about black markets and gray markets and transfers.

But it's likely, is it not, that there is going to be some sort of market mechanism for what is going to be a finite resource for which there's not going to be high demand at the early stage and diminishing demand over time, while equipment's being upgraded? Is that --

>>RAY PLZAK: Yes. If I may take a few moments.

The fact that the market is going to exist is not a supposition. In fact, the market does exist. I can categorically point to an occurrence that happened in the ARIN region several years ago where we uncovered an IPv6 -- excuse me, V4 /16 class B for sale on eBay. And took action to have that stopped.

So it does exist. And it does exist through a number of different means. So it's not going to go away.

The problem is, is that if it's allowed to all of a sudden grow and bloom, it does offer a distinct disadvantage to small providers. It does offer a very distinct disadvantage to providers particularly in developing countries, because they won't have the capacity to be able to afford to get these addresses. And so that in itself is another danger of the market, it's going to become an inequitable distribution of V4 and will place a disadvantage on the developing world.

So there are obvious things that have to be done. And we need to figure out what it is to do to make that happen.

We have to learn how to deal and live in this market world. We also have to learn how to deal with it in such a way that numbers don't all of a sudden become property.

And so it is a challenge, and perhaps it is something that we can work on together as well.

>>PAUL TWOMEY: Good. Well, I think that's useful.

I mean, I certainly am very conscious of the very different roles we have in this environment, and our MOU shows clearly that the global policy development is bottom-up coming through the RIRs and your constituencies and your members.

But I appreciate your closing comment, because I do think the responsibility of ICANN and the ICANN board in terms of stability, thinking about long-term stability, the issues you've just raised here are issues some of us have been worrying about as well. And that potentially we should pass this problem in two parts, at least.

One is -- has been the technical problem in the IPv6 takeup. But the other one is, what does the -- how should the environment operate in an equitable manner when the exhaustion has taken place?

And so it would be -- perhaps I could just put it on the table. It would be useful to have a dialogue about how could we best interact and start that thinking. Because we only have three or four years to think it through. And it's probably better to start thinking now rather than sort of being forced to think about it at the time or being given a fait accompli from the gray market.

>>RAY PLZAK: There have been discussions occurring over the last two or three years in the various RIR communities. And, in fact, in the upcoming ARIN meeting in San Juan Puerto Rico, we will be having another panel discussion on this very subject area.

So we need to very carefully figure out what our options are to go forward and figure out who is in the best position to have the greatest influence in the area.

Mr. Chair, if I can make one closing comment here. There's been some call that perhaps the RIRs should establish a deadline at which point they will stop to allocate IPv4 addresses, because that would provide a certainty to the market.

Well, -- and would force the issue of IPv6 deployment, perhaps.

I say that that's probably not a wise thing to do, because a certainty is already there. The certainty is that the central pool is going to be depleted. And to artificially establish a date will cause -- could cause other problems which would distract us from the real work that is ahead of us. Thank you.

>>VINT CERF: Thanks very much, Ray.

[ Applause ]

>>JORDI PALET: Could I say something, Vint?

>>VINT CERF: I have Francisco who was in the queue, and let me put you in there. Francisco.

>>FRANCISCO DA SILVA: Thank you, Vint.

Only -- I will not spend too much time, but in following what Thomas Narten was saying, which I confirm, and the question by Paul Twomey, there is a trend for the networks, infrastructure, the worldwide networks in telecommunications to be transformed into all-I.P. networks.

And the requirement that are put in the beginning was to function both for IPv4 and IPv6. I would say, why not two years ago?

And how this is being standardized in the medium term, in the five to six years, the functions that will be there provided with a low (inaudible), then I don't see a big problem.

And I would like also to comment about these developing countries, that, for instance, when operator of, I think, a country that has many representatives in this meeting, which is Guinea Bissau, was completely remade last year. And this -- all I.P. transfer mode, with which it is working. That means that I would not be very sure if there will be a very beginning difference with one part and other part of the world concerning the adoption of IPv6.

>>VINT CERF: Thank you. Your comment, please.

>>JORDI PALET: Jordi Palet.

Basically, I agree with what has been said, and I want to reinforce a couple of things.

Taking on the example of the network at home where you have everything enabled with dual stack and some devices, like printers or whatever, are not already using IPv6, I think it's important to realize that first that's happening already. I don't know exactly which printer models, but there are many already, including from HP, that support IPv6. And most of the time, people don't take the chance to go to the manufacturer's Web site and upgrade the freeware and so on. So that's one point.

But the most important thing is that we need to understand. And probably this is something that needs to be more reinforced in the education process that we are not taking out IPv4 from the network. And, actually, my suggestion when I train about IPv6 is, never take IPv4 from the local area networks. What it means, basically, is that you are still using everything that you have which is only IPv4 for whatever reason, and you use IPv4 when it's not possible to use IPv6. And you use IPv6 for new things or end-to-end communication, so on. I think that's really important.

We are not going to see IPv4 to disappear probably for many, many years.

The other question is, there is a feeling in general that getting IPv6, it's cost. And I think the key here is, it's not really that much, and especially if you plan ahead.

So the education we need to do is especially telling everyone, start getting used to IPv6, start making sure that when you do any acquisition, IPv6 is there, even if you don't turn on now, but get ready. Because the cost will be you need to do that overnight.

Thanks.

>>VINT CERF: Thanks, Jordi. I think it's time for us to take a break. And since we've run a bit late, let me suggest that we reconvene at 11:10. So I'll be back on the --

>>SUSAN CRAWFORD: Vint, Kieren might have some comments here.

>>VINT CERF: Oh, sorry. Okay.

>>KIEREN McCARTHY: Sorry. Yes, I was sitting down, because there are still comments coming in and I wanted to wait until the last moment.

I have two broad comments. One has come from the public on the Web site. One is with regard to RegisterFly. I see Kurt has answered some of that. And one is from Bret Fausett, who most of you know is an ICANN watcher.

>>VINT CERF: If Bret's comment is on triple X, there's time later on specifically for that purpose.

>>KIEREN McCARTHY: That's what I thought.

I'll take a comment on RegisterFly, is, what are we to do with the lost domain names we cannot renew and have not been able to renew with RegisterFly and eNOM?

Now, if you go to the chat room on public participation site, public.icann.org, there's a comment there from Kurt Pritz which is worth reading. I don't think it's worthwhile -- because, at the moment, we're rushed -- to read it all out. But I would encourage other people, if they wish, to, outside or in the room, if they wish to ask comments, to go to public.ICANN.org and click on the "public forum" link.

>>VINT CERF: Thank you very much.

So we'll take a break now until 11:10. And we'll reconvene at that point, when we will hear from colleagues from Puerto Rico.

(Break.)

>>VINT CERF: Is Marimar Lidin in the room, please? If so, could you please come to the stage.

Ladies and gentlemen, would you kindly take your seats? We will reconvene now.

We'll just wait for a moment while people find their chairs again.

It's a pleasure to introduce to you Marimar Lidin who is going to give you a brief introduction to what you can anticipate in June when we meet in Puerto Rico.

>>MIRIMAR LIDIN: Thank you, Mr. Cerf. Good morning to all of you again. I have been here since Monday during ICANN and I look forward to being able to answer your questions about Puerto Rico.

We are going to go ahead with our presentation and at the end of the presentation we will be glad to have any of your questions.

Here is a pre-registration that you already have within the WWW.ICANN San Juan Web site. It's already open.

Puerto Rico is a commonwealth of the United States, and therefore, entry requirements to Puerto Rico are exactly the same as entering the U.S.

We mention this because you will be able to already print out an invitational letter from the Web site and use it to take to your local U.S. embassy, should you require a visa.

There are 27 countries right now under the U.S. visa waiver program and these are mostly all of the EU countries, except for Greece and cypress and a couple others that I don't recall right now.

But 27 countries are under the visa waiver program.

Other countries do need a visa, and your local U.S. embassy can take the invitational letter to process that.

There's also a reservation code in the ICANN San Juan Web page that will help you with your reservations for ICANN San Juan.

Okay. For those of you who are not exactly sure where Puerto Rico is, it's right in the heart of the Caribbean. Puerto Rico is 9,000 square kilometers big. It's more or less three times the size of the island of Majorca. It's very mountainous in the central region. The north coast where San Juan, the capital, is is based by the Atlantic ocean, and the south coast is based by the Caribbean sea.

We will be meeting in San Juan, the capital city, and we'll take a look now at how beautiful and colonial and how Spanish, the Spanish flavor that we still have is very apparent.

Why Puerto Rico? In addition to the fact that you are going to meet there, it's a great destination for vacations and because of the dates, June 24th through the 29th when you will be there, why not make it a family vacation or a family gathering or just take a friend along.

The weather is very nice at that time of the year, because although our year-round climate is approximately 27 degrees Celsius or 85, 88 degrees Fahrenheit, at that time of the year it's still pretty much not that humid or hot as it does get more in July and August.

For those of how enjoy sailing, Puerto Rico has constant trade winds that blow constantly from the northeast which make it an ideal destination for sailing. And we'll be seeing a little bit more what the island has to offer.

As we mentioned a great place to go with your family and have some nice family bonding time.

Here we go. Top 13 must-see sites. Old San Juan is a colonial city which is a world heritage site.

The old San Juan is surrounded by Spanish forts and walls.

We have from rainforest to dry forest and a very pleasant surprise for those of you who do not know what a bio-luminescent bay is, we will be seeing it a little bit later.

Okay.

Why Puerto Rico again? Family, nature/adventure, golf, scuba diving, for honeymooners, pre/post cruise, this is very important as well. Puerto Rico is the second largest cruise port in all the Americas, including Miami, it's very nice to depart for the eastern Caribbean from San Juan because departing from San Juan allows you to not have two days sailing without getting to any islands as when you leave from Miami. When you leave on a cruise from San Juan, you arrive in a brand-new island each morning.

Our capital city, San Juan. As we mentioned.

The population of Puerto Rico is 4 million, but one and a half million of those live in the capital city of San Juan.

That's a very nice view of what our bay looks like, and that's our most important monument, the El Morro castle. A nice aerial view. That's what you see actually when you arrive on the plane because the airport is only about five kilometers south of this Fort.

That's another view of the walls.

All these walls in the night are lit, and there are very nice, romantic walks you can take outside the walls or inside the walls.

The cobblestone streets of old San Juan is something that is very well-known.

The city is over 500 years old.

This is the door, the main door entrance of San Juan.

The night life is very well-known in Puerto Rico. It's actually the happening place in all of the Caribbean. It's where people go out the most at night. Nice dining, a lot of salsa.

The shopping also. We have very well-known native wood carvings. But also, more recently, we are well-known for quality brands, international quality brands, especially in clothing that, in comparison to the prices that you find here in Europe, it's very, very interesting.

Okay. Botanical garden, rum distilleries, museums for children in Old San Juan. Lots of arts, lots of culture. Condado area is where the Caribe Hilton, the hotel venue we will see later, for ICANN located right where the old San Juan starts where the Condado area finishes.

Again, the north coast, some of the attractions there, nice golf. We have 23 golf courses in general, 22. 17 of them are champion courses. Greg Norman, Jones, they have all designed for Puerto Rico.

And this is very, very special. This is great to go with the family. This is the Rio Camuy cave parks. They are formed by the third longest underwater -- third longest river in the world that is still sunk, and you can walk around along the river and go down in a special little train and it's very, very nice.

This you have probably heard about. It's the largest radio telescope in the world. It's the Arecibo observatory. You can also visit it. It has a very interesting museum. It's run by the Cornell university, and you have probably seen it in films like "contact" and "golden eye."

The eastern part of Puerto Rico great for taking catamaran sailing. That's our rainforest, it's the only tropical rainforest within the U.S. forest system. It's less than an hour away from San Juan and it's filled with trails and flowers and our unique, tiny, native-free tree frog, called the coqui, sings in the day also in this rainforest whereas in the rest of the island you can only listen to it at night.

Our beaches are all white sand. We don't have volcanic beaches. All are white sand, palm fringed beaches.

And the Caribe Hilton has a nice small private beach, and after your meetings you can take a nice little dip right there on their beach.

Sailing as I mentioned is very big in Puerto Rico. Windsurfing, yachting, deep sea fishing for marlins also.

These are two sister islands that belong to Puerto Rico. Vieques and Culebra are known as the Spanish Virgin Islands, and they are the only islands left in the Caribbean which are still very

Internet Corporation for Assigned Names and Numbers