ARIN XVII Public Policy Meeting Draft Transcript - Tuesday, 11 April 2006
"This transcript of the meeting may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting."
MR. PLZAK: Okay, and so, as a reminder -- and for those of you that are from the LACNIC region. Anyway, I hope those of you that went to the social last night had a good time. If you did, clap your hands.
We've got on tap some policy proposals and a few other things. First of all, let's thank all of our sponsors. And we are going to do this -- I will do this right now.
Remember, yesterday, we had a raffle drawing and so -- I've got that here and I think we've got a fish bowl of things and could I get someone from the audience to come up here and pull one of these things -- So, if I could get the fish bowl brought up here by someone and just come up on stage and hold it. And can I get a volunteer to come forward to do it? Ah, Owen will do it.
So -- have you been to the Cyber Cafe? Ah, okay. That doesn't make any difference. If you pulled your name out of it, it would have been okay with me too. So --
And I know someone else -- Okay. The other person in the room that's definitely favored in this raffle is Andrew Dul.
Okay. And so, as a reminder, it is still open and tomorrow we will have another drawing and this is for a backpack and Registration Services Help Desk is open. I don't know how many people have been there. I understand there's been a few and setting of appointments and so forth and I don't know if Leslie is in here -- She's what? Oh, she's working.
SPEAKER: I'm glad about it.
MR. PLZAK: Yes. So -- and the Billing Help Desk is back there as well. So, please take advantage of the opportunity, if nothing else, just to meet and greet, talk with the people you work with.
Leslie, what's been the traffic load in the RSD help desk? So, she says a lot of people and she'll tell me later. I hear that every day, okay.
So, anyway, don't forget to complete those meeting surveys. There's another raffle for that one too and two guys -- two people will win and I've had --
Okay. Reminder: If you're not on the PPML, this would be a good time to do so. It is the forum -- your forum to raise and discuss policy- related issues. And for those of you who are on it, you have been active participants in it and you've seen a lot of good discussion go on.
So, remember, all policy proposals are always introduced on the PPML. So, if you're not a subscriber, subscribe.
And remember the rules of the road and do as Owen did. State your name, affiliation and whether or not you support or don't support what is being discussed.
So, before we move on and start through the agenda, John yesterday said, "Eh! I'm not going to be here tomorrow." So, it's your last chance to take a shot at him. So -- anyway, if you noticed, John has changed to Scott Bradner. So -- I don't know what -- if you want to say a few words, go right ahead.
MR. BRADNER: Good morning. I'll convey to John your pleasure of him not being here.
SPEAKER: Do you support this discussion?
MR. BRADNER: So far! A while back, the ARIN board decided that they wanted to have stand-by equipment for the Chair and so they designated that the Secretary be that vice-Chair. That's not chair of vice, which I prefer, but it's actually the assistant Chair of hot stand-by equipment. And so, here I am performing a function.
John had a day job thing which could not -- he could not avoid. A customer called up and said, "We're going to meet on Tuesday". He said, "Can we do this on Thursday?" and the answer was, "What part of Tuesday didn't you understand?"
So, he's back there or he's on his way right now. So, you can browbeat me as we go along.
MR. PLZAK: Thanks, Scott. A few moments ago, we applauded our sponsors, the major sponsors for this event and as far as I'm concerned, they've been doing a very good job. It is Teleglobe. And so, Henri Alexandre from Teleglobe, the vice-president of network engineering is here and so, Henri, would you -- do you want to come up and say a few words and -- to the group?
MR. ALEXANDRE: Bonjour a tous. I'm Henri Alexandre, vice-president of Network engineering in Teleglobe, now VSML International Company. Teleglobe stands by ARIN and recognizes the very important role of Internet resources allocation and policy development it plays in the North American Internet community.
We're proud to show our support by hosting ARIN XVII here in Montreal, Teleglobe's hometown for more than 55 years.
We hope you have enjoyed your Montreal Street Festival last night. We wanted to sample for you our most famous summer festivals, namely the Jazz Festival, the Just for Laughs Festival, our world- class Cirque du Soleil, the Formula 1 Grand Prix du Canada which is being held as the end of June this year. It's a great event. The fireworks festival which takes place most weekends and Wednesday nights during the summer. And some of you even had the chance to enjoy the soccer de table festival which is more a -- more of a -- in relation with the fact that soccer has quite developed in Montreal in the last few years. It became the most popular sport now with the youngsters and probably with the older ones also in terms of attendance -- in terms of participation to the sport. Hockey remains, I guess, our favorite but -- there's no such festival for hockey.
We hope you have enjoyed your culinary experience adventure and tasted local cheese, enjoyed beers from our local breweries and we trust you're all this morning still cruising on the sugar rush induced by our maple coffee.
I want to recognize the sponsors that are making the running of the ARIN meeting so smooth. So, Shafik Hirjee and his team for IP Connectivity and the router; Dell for the PC and printers at the Cyber Cafe; Force 10 for the switches for the network; Cisco Systems for wireless access equipment; and all of ARIN's staff for making a fantastic job of making our life as a sponsor easy. So, thanks for the great support of ARIN's folks.
Special thanks for people of Teleglobe who contribute more directly with the event. So, John Sweeting, Sylvie Laperriére and Diane Godin. So, to all the sponsors from other companies and those from Teleglobe, I think we can give a hand --
For those attendees interested, we will offer a tour of our NOC and IP POP on Wednesday afternoon, tomorrow afternoon. So, if you're interested, please look at the ARIN website. The info is there.
Lastly, no true Canadian experience would be complete without discussing about weather. We love to discuss weather so much and brag about it, the up and down of it, we even created a windchill factor, a humidex factor and some other factors which I'll spare you.
The windchill factor is a factor used to make you feel much colder or much warmer than it is on the real thermometer. So, upcoming forecast, today and tomorrow, and I would like to take credit for the weather so far and hope it stays as planned.
So, for tomorrow -- for today, sorry, a high of 16 and even better tomorrow with a high of 18. Mostly sunny for today, possibly some scatter but we're working on it right now.
So, what does -- how does the windchill factor apply there? I means that if you stay in the sun, it's bearable, but if you go in the shade, bring your coat.
Enjoy your meeting. The agenda is packed with registry updates and there are four proposals to discuss. I better leave you to do it and au revoir, a la prochaine et merci beaucoup de votre participation.
MR. PLZAK: Thank you, Henri. Okay. As Henri just mentioned, we do have a rather full agenda today and we will get to see when we get into the policy proposals about how tyrannical the Chair will be too. So --
MR. PLZAK: Anyway, we will begin the morning with the RIR updates. This is the chance for you to learn what's going on in the other regions directly from our colleagues from the various RIRs. So, we will begin with AFRINIC. So, Adiel, if you are somewhere -- ah, here he is over there. And he will be followed by APNIC, LACNIC and then the RIPE NCC. So --
MR. AKPLOGAN: Thank you. That will be a very short status update on AFRINIC. This meeting coincides with our one- year anniversary of being fully recognized by ICANN, so this report will talk about what we have done since April last year.
I will start this presentation with numbers actually, about how we have grown since April last year, our membership, our requests.
You can see that our requests for Internet resource have grown a lot since the beginning of the year and what is more encouraging is the number of new members we had.
We have doubled the number of new LIRs from last year -- from 2004, I mean, because I'm talking here about 2005 numbers. We have more than 100 percent growth from our membership in 2005 which is very interesting but this membership growth is not only small members, we have also noticed a very substantive growth in resource allocation and assignment in the region.
At the top side, you can see the comparative IP before allocation, so we compare month by month between 2005 and 2004 and you can see all along the year, we have allocated more than -- the double of the number of /24 all along 2005. Same for AS number which means for us that the fact that we are more closer to our network operator and we have conducted some amount of training and awareness about RIR and resource allocation has produced some positive results.
Financially too, we think we are doing well so far. If you remember at the beginning of our process, one of our challenge also is to be able to sustain the organization and being able to have sufficient reserve in our account to be able to take over the whole operation of AFRINIC after two year of incubation which has passed the transition process.
So, all along the past two years, 2004 and 2005, one of our goal and our focus was to build a reserve on our budgets to be able, at the end of 2006, to take over the whole operation in the three countries which are running AFRINIC meaning South Africa and in Egypt.
So, you can see that at the end of this year, our reserve will be consequent to be able to cover the whole budget 2007.
This year already, we are funding 50 percent of the budget of South Africa plus our budget in Mauritius, so for us, it's something very encouraging.
As I was saying before, we have conducted some training in 2005 because it was one of our challenge to make our community more aware about IP resource allocation, what is the RIR system and how they can improve the infrastructure by getting their own IP address, doing a multi- homing with -- in a good condition by getting their own AS number.
We have conducted a training in 2008, the country in red -- in orange there are countries where we had training in 2005.
This year also, we have already started implementing our training plant, we had two trainings this year, one in Sudan, which has been done with an IPv6 one day, we had also another training in Cape Town this year.
To make the training more attractive also for the community and based on some feedback we get from them, we had some specific subjects to each LIR training, so it's not only LIR training but we have like IPv6, one day, IPv6 along with the LIR training or DNS -- or DNS, just DNS training.
In Sudan, we had a two-day training, one day for LIR and the other day was an IPv6 because we noticed that many members from our region are interested in knowing more about IPv6 and the results are there, everywhere, we have a IPv6 training, we have many requests for IPv6 allocation and we have also some IPv6 native connection from those countries.
Training was, as you know, Africa has more than 50 different countries, so it's not very easy for us to travel everywhere in a very short period of time, so we feel like it should be very interesting for the community to have a computer-based training material where they can have access to the basics of a resource allocation.
So, with the support of ARIN, we have released a computer-based training material which is available on-line, we have it also on CD, so every new LIR get a copy of the CD-ROM which is a training on how they can interact with AFRINIC, how they could use our WHOIS database and get their request properly done.
So, it's something which has been very successful, we have noticed a lot of downloads from the CBT on our Website and many people are using the CD we have released.
A French version of that CD is also on the way and will be available soon. So, we are trying harder to make the community aware of what we are doing and that is also -- would be -- will contribute to the success of the organization.
As a full RIR, we started having a policy meeting and our last meeting was in December in Cairo where we have discussed some open policy.
We had discussions in Cairo about four policies which got consensus: temporary assignments, direct allocation of -- or PI allocation to assignments, excuse me, to end user. We have update also our criteria for AS number allocation and we have also discussed about the IPv6 allocation from IANA to LIR which is the global policy.
All those policies got consensus and are now on the table of the Board for final ratification.
We got a proposal also for 4-byte AS number policy which has been submitted by Geoff. That policy is still opened, it's still -- I mean, on that discussion. We couldn't discuss that further in Cairo because in our policy development process, each policy has to be discussed at least 30 days on the mailing list before we discuss formally about it during the face-to-face meeting, so the discussion doesn't happen in Cairo because it was submitted less than 30 days before. So, probably we will discuss about that in Nairobi, our upcoming meeting.
Other activities, at the registration service level, beside the regular request evaluation, we also start cleaning our database.
As you know, we got our member and database information from various RIRs during our transition period and we now try to consolidate all those informations, clean our internal database against the WHOIS and make them consistent.
So, it has been a work we have done the past three months and it's quite finished now. At the engineering level, we -- at first, a lot of problems, especially last year with spamming because we got very high number of spam hitting our different mailing -- mail address which we use for evaluation of different kinds of activities.
So, we have tried different solutions and at the beginning of this year, we have experimented gray listing for requests -- especially for our public e-mail address and I would say that since a few weeks, we have implemented on all the e-mail which has allowed us to decrease very significantly the number of spam hitting those e-mails which make the work of IP analyst more efficient.
We have also started developing a Web interface for our member to manage their resources. This includes the membership process itself. Because one of our goal this year is to make the membership process very easy. It's to say that you can become member of AFRINIC by clicking two or three times on the web, filling the information and providing most of the information online. This includes an online payment too, which we don't have now. So, that development is also ongoing. And, probably, we'll have the first version available in Nairobi.
We have also reverse engineer the WHOIS server that we are using. As you know, we start using RIPE NCC WHOIS server, so far our server at the beginning. So, we start re-adapting that server to our process and our policy, which is also a very deep and top activity we are undertaking right now.
The last thing we have done is the data recovery center in Egypt. We have deployed the first infrastructure in Egypt where our server are now up and running. The first thing we are going to do is to mirror our WHOIS server in Egypt location and move ahead with other sensitive server and data we have in South Africa and Mauritius.
At the financial level, we got income tax exemptions from Mauritius government last year, which is very, very interesting for us.
As you know, we have an invoice process which make us invoice all our old members at the beginning of the year. So, we have a very specific invoice period. So, we invoice them at the beginning of the year for the whole year. So, we have invoiced all our members, our 2005 members in January. And, up to now, we had 80 percent of collection rate, which is for us very encouraging. So, we have collected already 80 percent of our 2006 invoices. Our goal is to reach around 90 to 92 percent for this year. So, we are continuing to chase those members and collect the invoices.
We have also started our process for 2005 account auditing. It will be done in the coming week.
Staff update. When we got recognized at ICANN, we were three people working at AFRINIC. Today, we are six, including one traininee - a hostmaster. Two are working in South Africa and four in Mauritius, including our second hostmaster.
We are launching requirement of new staff in the coming week, one as a system engineer, a database manager, and a membership liaison and communication officer. That will allow us to strengthen our structure, our investment structure and work in a more efficient way to tackle our different goals.
Other specific projects, we now, as one of the first official organization dealing with Internet resource management and Internet governance -- we're trying to build a strong relationship with other organizations working in the same technical engineering environment. We have signed an MOU with AfNOG in Cairo to support each other activities and especially supporting AfNOG training program.
We are discussing with other organizations like education network, association of ISP to get a more stronger relationship and work together toward more awareness in our community.
We have also decided to be part of ITU-D, to be ITU-D sector member. Why? Because it allows us to be closer to policy maker in Africa and being able also to reach out to political environment, because, in Africa, as you know, ITU has a very powerful influence on everything related to technology and especially telecommunication and Internet. So, being member allow us to attend meeting and talk about what we are doing about Internet resource management. And it has been very successful so far.
We have also launched a program called 6Mandela, which is the program on awareness. And part of it is the training we are providing along with our LIR training. So, the 6Mandela Project is very, the idea is very wide. It's from training to more -- I mean, more technical thing around activities. So, we are still working on some details about that. And it will be formally launched soon.
That's all as updates. Our upcoming meeting is in Nairobi, 16 to 17 May. It will be held back to back with AfNOG 2007. And our second meeting for 2006 will be in Mauritius from 27 November to 1st December. So, you are all invited to attend those meetings. Thank you. I have nothing more. We're happy to answer any question if there is.
MR. PLZAK: Okay. Next topic is APNIC. And it's Save.
MR. VOCEA: Greetings from APNIC community. My name is Save Vocea. I'm the policy development manager for APNIC. On the recent APNIC 21 meeting held last month, we had discussion on applying HD- ratio to IPv4. There was no clear decisions made during the discussion. So, let's say that we decided to give it a four week comment, final comment which expires on the 14th of this month. So, that's this Thursday. So, after that, we'll make a decision to abandon these policy proposals or carry it forward.
There's been what's going on in all the other discussions is the 4-byte ASN policy proposal. This was endorsed at the APNIC 21 over the final comment period, month of May. In 2005, these were the successful policy proposals that have been endorsed in the APNIC community. Some of them have been implemented. There's the URL if you want to see more or read more about the proposals.
I'd like to just now share with you the secretariat activities since they were last presented last time by Paul Wilson. Staff are embarking on what is called a client first project to relocate how we can stimulate some of the procedures and even offer better services to the community and to our membership. And this is looking into how we can improve resource request, interaction with members. And what we've done is -- new home page has been redesigned for faster loading.
There continues to be request for training from our community. And our training team has been very busy with delivering of courses of Internet resource management, also offering workshops in routing and DNS. And they're delivered in 34 locations last year, covering 22 economies.
Aside from the physical training, we have also developed e-learning, which is on the way. And the first module for this will be ready by APNIC 22 so that anyone in the community or from the ISP can do his training on line.
We've also engaged Jordi Palet to come APNIC secretariat and offer a train-the-trainers workshop on IPv6. And that's next month.
As you've heard yesterday from the panel on resource certification using X.509 certificate and what APNIC is doing, how it's involved, we would have to facilitate a workshop for the RIRs staff and others that were interested and this was done in APNIC office after the APNIC 21. You heard Geoff Houston yesterday. He updated on what APNIC strategy is.
Also, the secretariat has been able to cutover now to using VOIP telephone services and, you know, it's really important for us to do it because of cost savings that's involved because of the Asia Pacific region is quite a big region, people calling in. So, there is a SIP address for the Help Desk so that people can contact APNIC directly through VOIP.
One of the projects that the members have been involved in is a debogon project as well as today, what people -- and what they're currently doing is try and investigate with a test group on how they can better this service for the members without facing these problems
We have MyAPNIC as an ISP portal for management of IP resource and we've also developed a MyAPNIC lite version. It is to provide a faster access to the IP resource portal. And especially for those economies that face the difficulties.
I must say that -- ourselves, we have some very creative minds, the staff. We have developed Flash movies about APNIC activities and these are all downloadable from the website just to help people understand better what APNIC activities are. And during the last meeting in APNIC 21, we also developed and provided APNIC interactive CD which has resource material in it. People can use that as well in training and also during our outreach-
In the areas of research activities, there's going on like Geoff is our research scientist in that and he's been doing a lot of work in 4-byte ASN, continuously bringing out BGP reports and he's working on IETF.
Now, ICON which is an on-line portal for ISPs was developed in response to a community feedback and what I've put up here is the web site and the URL and I'd like to this community to also have a look and see if you want to subscribe. It's like one-stop shop for ISPs and please do come in and participate and contribute and see how you can help the community develop, please.
In the areas of outreach this is an important area that APNIC has also embarked in to outreach to the operative group, we have a few operator groups in the region, like China, New Zealand and the Pacific Islands and also in South Asia. And we've kind of helped in the programming and resource stuff and also to support the content in some of the events that these NOGs operate.
IPv6 summit, APNIC secretariat staff do get to attend some of the summits to update the community on what APNIC is doing in terms of v6, all the -- in the different countries and economies in the Asia Pacific and this week, some staff are in China to also present on this and following on that later in the month, there will be an APNIC summit in Thailand.
Internet governance has been around and APNIC through the NRO has been participating in the WSIS and also, as a result of that, they'll continue to participate in the Internet governance forum. But there is a report, I think later on this morning. So, I won't talk too much.
APNIC has been involved in the Pan Asia ICT research and development grants program. We provide some field money to the program so that we can help the region with ICT programs.
APNIC has also forged relationships with a lot of other industries stakeholders and there is -- has been signing with a lot of ISP associations and just recently, we've had a memorandum of understanding signing to the ISOC chapter of Australia, NIDA in Korea and the Pacific Islands Chapter of Internet Society that's based in Fiji.
Now, I think most of you are looking forward to this and this is where the APNIC's next open policy meetings will be, two upcoming ones, APNIC 22 in Taiwan and also in 2007, with APRICOT, the meeting will be in Bali so, I'd like to cordially invite you to come and participate, either physically or via remote participation.
So, thank you for listening and any questions?
MR. PLZAK: Now, LANIC.
MR. ECHEBERRIA: Thank you very much. Good morning everybody.
I will -- My name is Raúl Echeberría, I'm the CEO of LACNIC. I will report the LACNIC activities in the last period. It will be a very brief report because many things have been said by other speakers.
As usual, I don't know if it is useful to show this graph but I do always and I will continue doing it until somebody tells me to stop please.
But as you can see in this graph, it's the same that Adiel showed in the AFRINIC's report, it is that the growth in terms of allocations of IPv4 in the region. This graph shows the number of allocations made semester by semester.
It's clearly -- there is a continued growing in the allocations in the region. But I don't know if it's good or not but it's what's happening.
Now, it's good because in the developing regions it means two things. The first one is that the market is growing and the second one is that we are serving the community in a better way.
This is the same graph but in /24 numbers of allocations. It also shows that the number of IPv4 allocations is also growing in the region.
The most interesting thing maybe is what's happening in relation with IPv6 in Latin America. As I reported in the last ARIN meetings, LACNIC has started to work in 2004 doing many actions intending to promote the IPv6 in Latin America, not only because IPv6 itself, but for creating an innovation spirit in the community.
The research has been very good and you can see there, we have made 34 allocations of IPv6 in the last year, that is much more than all the allocations that we have made in the previous four years.
As we have worked very much, we organized many activities, workshops and other things that I will comment in the next slides.
The 57 allocations of IPv6 that we have made are distributed and the distribution of IPv6 is more interesting than IPv4 because we have made allocation in most of the countries in the region.
The membership is also growing, we have created some more categories as we have six categories depending on the sizes of the space of the space the ISPs are managing but we also have other categories like end-users or members that are only members but they don't have IP addresses allocated.
Then the total number of members until today is 339 members but it's very interesting in Latin America.
LACNIC, besides the part of doing or trying to do it's core business very well and better every day, it's also involved in many activities in the region and to promote the information society and the growing of the Internet.
This is because there are not many organizations like LACNIC that act in all the regions.
This is because we have leaded the work in matters like IPv6, as I said in previous ARIN meetings, we organized last year what we named a IPv6 tour that consisted in 10 meetings in 10 different cities in 10 different countries.
In total, we had more than 2,500 participants. People from governments, technical communities, students or professionals, ISPs. Different kinds of people- it was very broad and very public. And this was one of the reasons for the growing of IPv6 allocations.
We also host the Latin American IPv6 Forums, the IPv6 Task Force, we have organized many workshops, and so we found persons also related with IPv6.
We have also another project that is named RAICES Project. RAICES means fruit in Spanish and the goal of this project is to deploy root servers in Latin American.
We have launched the first root server in this project in Chile in last December together with the Internet Consortium and we are planning to fund three more this year, one in Venezuela, one in Argentina and one in Panama.
I have talked many times in the past about FRIDA Program, FRIDA Program is a program that is ran by LACNIC with the support of two organizations that is good to remark that are funded by the Canadian government, that they are IDLC and the Institute for Connectivity in the Americas.
And also, we with important contribution from Internet Society and the Global Knowledge Partnership.
Through this program, we are funding at this moment 26 research projects in different areas, social, technologies, public policies and relation and technical approach.
We are, at this moment, finishing the Frida program in its first version and we are preparing the Frida 2 to be launched in the second part of this year.
And we hope to continue having the important sponsorship and support from the organizations that have participated in the first part of Frida.
We are organizing three meetings in issues not exactly related with IP addresses but in the interest of the community, one that has been done in Uruguay in the past month and other two in Bolivia and Colombia. So, we are supporting two new communities, NAPs and Security. And both committees will meet during LACNIC IX, our next meeting and we still hold cooperations with many other organizations, CLARA, ccTLDs, and also a federation of ISPs that promote the use of electronic commerce.
I explain that because this is very interesting in Latin America. There is -- eLAC-2007 is a set of verifiable goals related with the development of the information society in Latin American region.
And it was the -- of the regional conference that was held in 2005 in Rio de Janeiro as part of the proprietary process of the WHOIS.
The government then has met in 2005 and they approved this document with 70 -- I don't know if goals is the right word but 70 achievements that they expect to have before 2007 regarding -- promote the development of the information society.
Governments are still working on implementation of the plans and we have taken what we do against this document and we have discovered that LACNIC has activities that directly contributes with the achievements of 25 of the goals.
Then it shows clearly that LACNIC is a key player in not only in addressing issues but also in the promotion and development of the information society in the region.
And so we show that as a clear example that the only way to develop information society is through the private and public partnerships and this is a concept, an idea that we promote in Latin America.
We expect to have our new facilities for 2006, we have bought a house in -- a new house in -- very well located in Montevideo in Uruguay, that's -- we are -- we will restore this house, it's something that is going slowly because it's an area that is protected by many roles by the municipality and we are trying to get the project that it could be accepted for the authorities.
But hopefully, the second picture shows the -- what will be my -- the view from my desk in some moment of this year.
And so, of course, all of you are invited for the opening in the -- I hope in the last quarter of 2006. Oh, it's beautiful.
Okay, now, Einar already informed about the policies that are being discussed in every region but this is -- I believe it would have seven proposals that are opened and under discussion and they will be considered in our next meeting: WHOIS privacy, how to do end-user resources, the allocation period -- that is the time that we consider in which we evaluate the needs for making the size of the allocations, the ASNs like here and HD ratio on IPv6, there is -- the discussion is similar to the discussion that has been hit in this meeting. And also HD ratio applies for IPv4, the size of the locations in IPv6. There are some concerns that have been expressed in the community and not only in the public list but also directly to the staff or the board of LACNIC.
One of them is regarding the harmonization of allocation practices in all the regions, basically the main concern is regarding the allocation period that we are using different allocation periods in different regions.
And this is something that is being addressed by the NRO and we are very optimistic that we would have improvements, important improvements very soon in this point.
The other concern that we have received and it will be present in the next meeting is regarding the usage of HD ratio and IPv4 that is -- has been discussed in other regions.
The comment is that the people see HD ratios as something that if you say in all the regions, it will increase the consumption of IPv4 addresses dramatically and you use it in only in some regions, it would produce bigger inequities in the distribution of IP addresses among regions. But this is also that we think that it's been understood by everybody as we are also optimistic in this point.
We will have many activities during LACNIC IX, our next meeting, our annual member assemblies that we consider the annual report of 2005, some changes in the fee structure, and also the relationship between LACNIC and other regional stakeholders.
We will host, as I said before, a security Latin America forum that is looking for better coordination among operators in this specific matter. We will host also the annual Internet exchange point meeting, the open policy forum as well, sure, and Latin American IPv6 forum, and, also there will be meetings -- organizations that will meet together with -- in parallel with the LACNIC meeting. That I think, all that make our next meeting very interesting.
Meeting will be held in Guatemala City from 22nd to 26th of May. Guatemala is a very exciting country, it's the main source of the Mayan culture, and I think that's all the people that will join us in the meeting will then show you also the country. That's all. Thank you very much.
MR. PLZAK: And now RIPE NCC, Axel?
MR. PAWLIK: Good morning everybody. I'll be rather brief. I've heard threats made against me if I would take longer than five minutes, I would be dead. So I'll be rather quick.
I have taken out all stuff that would have been discussed otherwise, policy stuff and the like, so I'm not talking much about that. Well, we have an office on the water as well. Wouldn't want to swim in there though.
All right. Basically this year we are in maintenance mode. We do lots of little things to improve our documentation, to improve our infrastructure and the like, so here is a list of things that we have been done to our documentation.
Training. Our training material has been revised. We also hear that our training is just very, very, very popular, so we are trying to reach out to other audiences. What we are doing also is, what we have been doing for quite some time is we have handed out leaflets saying that "If you need a speaker for your event, we are happy to come." So we see that's flowing back very gently and we are being invited through to other audiences, other parties there as well.
All right, I said our training was rather popular, so we thought we cannot really go out and go to all the places that want us, so we do this e-learning thing basically over the web. We have started to do that, some of the plans are on the slide here, and it proves quite popular.
All right. Systems upgrades internally, what we are doing is basically we are with the view of being able to develop our services and to give our services to our members more smoothly and more gently, we are looking at our back office basically, and, well, that's what we've been doing.
Also, we are looking at ways of shuffling our organization a little bit, but you know, we'll talk about that next time, whenever we decided what we are going to do. But it will be always better.
Membership liaison. We do these regional meetings to reach out to our members, or sections of our members in the non middle and western European part, so we have been going to the Gulf region for quite some while, and also to Moscow, and those things prove quite popular. We've been -- or just someone to go already, been in Qatar and now we are looking at another meeting in Moscow, probably during the September period, and also looking ahead into late this year, or probably earlier next year, January, into the Gulf region.
Also, we have been doing for quite some time round tables for government, and governments and regulators. On a relatively small scale, we just invite everybody that we can think of, and about 40 people came this time to Amsterdam in February, and we hear comments routes or other channels that those things are seen and are appreciated quite a lot, so we will continue to do them.
Also, as you've just heard is that some of the governments love them, but find them a bit too remote from RIPE meeting, so they would prefer some integration of the RIPE meetings. My theory is just when it comes to the big party of the Thursday night, which is great, and it's good governmental relationships there, so what we do this time, we'll have a bit, not quite above, an hour, or 90 minutes, probably on the Friday morning, where we'll discuss and see a presentation or two from those government people, how they think that that should be working. So we are quite happy to see them streaming through into the RIPE framework there.
All right. Also, apart from the regional meetings, we'll also do these governmental things in Russia and the Gulf region. I have been approached two weeks ago, where was it -- at the ICANN meeting, right, by a gentleman from Iran who says that they are going to convene 15 governments from within their region, and wouldn't we like to come there and contribute to that, and I said absolutely. So we'll see what that brings.
Covered governments. Basically, yes, earlier this year, we had our general meeting with the planning for this year -- no, that was last year -- It's too much traveling, too many meetings.
So last year we planned for this year, obviously, and now this year, we are looking back at last year - that is confusing, isn't it -- so we just have our annual report out, and it is being published on the web as we speak basically. The interesting thing here is that it's going very well. We have managed again to have more than two and a half million year of surplus, which we try not to do really but we always fail. Our board has decided they want to have about 12 months of reserve, operational costs reserve, and we are going past that, beyond that, so we'll again have to drive down the fees this year, later this year, with the view of producing that reserve, and then of course, we'll make more members come.
Currently we have 4,300 and a few members, and commence to adhere a very nice growth graph there. That's a very good thing, we've decided to do similar things, make it easy for new members to sign up, and we have been terribly successful with that, maybe too successful. We have heard -- we have heard from one person calling in and begging us to credit this invoice because he doesn't really want to become a member, it was his 13 year old son who signed up, and, well, apparently it's too easy.
Okay, let's see. Right. We will also be talking about the certification activity that probably we are going to take up as well, and that, as I see it, will also have an impact on our membership relations, maybe the financing model that we are using, accounting will be affected, or maybe will change, so we'll talk about that in this membership relationship governance part of it.
Right. Enhanced corporation, that comes out of the WSIS. That seems to work quite well. And what we also find, it's a bit annoying when it comes to those big, let's say UN governed, UN-process governed meetings, and everybody has nice little name plates in front of their seats, and we don't. So we don't like that. We thought we'll also go the way that APNIC has gone before us, and accredit in the UN- way, basically to be recognized as a body that has something to contribute to in this field. So we'll see how that goes. Paul is busy doing that, and there is a deadline looming, so, well, we'll see. I'll report on that next.
Okay, in two weeks time, there's way too many meetings, in two weeks time, we'll all come to Istanbul, I hope. No? We'll all come to Istanbul.
The meeting is bursting at the seams already in terms of time. We are a little bit pressed there. And, of course, you also see that all the evenings are full with exciting side events, apart from governmental relations at the big party. So, there are -- every evening, we have something, I think the address council is meeting everywhere all over the place there. So, it's full. But it cannot be full enough. You're all of course happily invited to come, if you have the time, if you don't get too confused afterwards the meeting you have been at, and let's meet.
If you have any questions or any comments on what you would like to hear from us, then I'm happy to take that on. Also, if you give me any comments of what you don't like to hear from me here, then I'll make it even shorter next time. Thank you very much. Thank you.
MR. PLZAK: Okay. We'll be making a slight agenda modification at this point. The NRO NC report is not ready at this time. So, we'll now call upon David Conrad to put on his black jacket and come up here and provide the IANA activities report. Now, let me check, is Geoff in the room to throw springs and arrows at you? Yes, there he is right there.
MR. CONRAD: So, I'm David Conrad. Some of you might remember me, I was here once. Now, I'm general manager of IANA's. I'm working for the evil empire known as ICANN. Over here, I'll just talk a bit about statistics, because everybody really loves seeing numbers, and graphs, and stuffs, so I have to do that.
Vancouver, I sort of gave - the Vancouver ICANN meeting - I gave a presentation that describes some of the issues that I found at IANA as I joined it. And I'm just giving sort of a little update of that. Talking a bit about some of the projects that are ongoing at IANA and some goals that we have for the next ICANN meeting. Just so you know that I'm actually trying to do something as opposed to taking back, watching my yacht in marina Del Ray Harbor.
This is the current structure of the IANA. I report to Paul. To me, and I currently have Barbara Roseman and Kim Davies on staff reporting directly to me. I have a software developer who is helping us out with some projects. And I'm right now looking for -- to fill two slots. And then, the normal IANA staff, Michelle Coven, which many of you might know. And Yosha Patron who actually was with me at APNIC not long ago has -- didn't want in the first time and has rejoined the nightmare that is something that I run. Yes.
The two little boxes down there at the bottom, one of the problems that we've had is maintaining staff to do reviews of IETF related resource request, simply because they tend to be perhaps not the most exciting jobs in the world as well as the fact that being in the LA area results in people like wanting to go work for movies and stuff. And strangely enough, they prefer movies over reviewing Internet drafts.
So, what we've done is take an approach where we bring in part time people, get a raft of people to try to do this, since it doesn't require a whole lot of technical knowledge. But it does require some experience with the IETF. So, we go to IETFs and figure out who's bored and sleeping on the hallways and ask them if they'll help us. If you're interested, let me know, with that sort of buildup.
So, most of the statistics you'll see follow these sort of patterns, you know, you've got stuff measure going up, and that's bad. Or you got stuff going down, that's good. That pretty much describes all the statistics, and I won't talk anymore about that. Okay. Ah, but I lied! All right, our statistic's really boring, because actually bother me that much. You know, it's like three requests, you know, we processed three requests in March. Wo! Well, you know, I got to have time for my yacht.
Root zone management, this is where we go and scribble all over the root zone and the DNS. Maybe we got a few request of that, and it's, you know, again, yes, it's going down, see. That's good.
Internet drafts, we have to actually review every Internet draft for IANA considerations. And, for some reason, in March, there was a spike in the number of requests, Internet drafts that were posted. That's causing us to actually fall a little behind. But I don't expect that to last, because the IETF members produce that many documents.
Port requests, yet another yeah line. See, it's going down, that's good. We still have quite a few in queued. This is due to the fact that at certain points in the past, for some reason, there was a decision that we didn't really need the process port requests. That has since been remedied. And we are actually kicking the queue down. Right now, I believe we're actually working on some port request that went back to 2001. So, if you happen to have submitted a port request a long, long time ago, you might get mail from us. This is sort of a --
MR. WOODCOCK: Does that mail that we're going to get from you say the request has been honored or --
MR. CONRAD: Yes.
MR. WOODCOCK: -- does it want more information?
MR. CONRAD: Sometimes, we -- well, we actually request more information, you know: Do you really want to continue with this? Yes.
SPEAKER: Does that hold true for Bill?
MR. CONRAD: Except for Bill.
MR. WOODCOCK: Okay, and then, it's an automatic accept?
MR. CONRAD: Yes, every one else. I'm sorry?
MR. WOODCOCK: And then, it's an automatic accept?
MR. CONRAD: Yes, that's right, yes -- As with everything with you, Bill, automatic accept, yes. So, this is one of these yeah kind of -- because it's going down eventually. PIN requests, these are all IDs for people afternoon. We get quite a few of these, fortunately, they're sort of easy to process. And we're actually, this is a process that we're already almost automated. So, that number will eventually go down to hopefully zero. So, those were statistics. Wasn't that exciting?
So, when I first joined ICANN, I had the opportunity to sort of see where things were -- how things were working or not. And, in Vancouver, I gave this sort of table that showed the things that I saw. And, in general, we're still working on a lot of them. The management focus -- That's not me as being the manager, because I'm completely unfocused, but my boss and above.
That was a problem in the past with IANA. ICANN did not have a full understanding of the role of IANA in the Internet. That has -- actually was resolved by the time I joined. I have never had any difficulties getting any of my cross-requests, including the 40 foot yacht in Marina Del Ray honored. No -- There we go.
We also moved to single ticketing system when I joined IANA. Various resource requests were either in no ticketing system or in two ticketing systems which seemed a bit sub-optimal to me.
That's been fixed, trying to migrate some of the historical data that existed in the multiple ticketing systems and to one.
The two things that are sort of outstanding at this point, we have problem that the IANA data is spread out over a whole variety of different databases, everything from Access database, believe it or not, to my sequel to text files to a couple of MFLs and all of this makes things a little more complicated than they need be, we're in the process of trying to reduce the number of databases and part of the process of automating a lot of our stuff will be to actually immigrate into a single database or two. Other stuff.
SPEAKER: Excuse me --
MR. CONRAD: Yes.
SPEAKER: Could you read the target date --
MR. CONRAD: Oh yes, target date.
SPEAKER: We certainly want internationalized domain names, not date.
MR. CONRAD: Well, it's sort of close, but actually -- when you're at ICANN, you actually measure things and meetings. Time is measured in meetings and that is Marakesh.
The next ICANN meeting in Marakesh which, of course, if you're going to Marakesh, you want to go at the end of June.
SPEAKER: When they're filming the next Star Wars movie --
MR. CONRAD: Yes, that was Tunisia, yes. So, moving right along. Actually I did that because I didn't want to be -- I didn't want to commit to a particular date so I wrote it in Arabic.
IANA projects, we currently have a whole bunch of things going on, trying to clean up or improve efficiencies in various areas.
This table sort of provides a listing of -- well, you can almost see the colors, of the major projects that we have ongoing, we're going to have 24 x 7 x 52 availability which means that we're going to have a call centre who can -- perhaps people in various odd times and no, I'm not going to give that to Bill.
Let's see, the other ones of interest, the X.509 addressing -- stuff. IANA is participating in meetings, it's not entirely clear to me at this stage what role the IANA should play, whether we're five or six or, you know, where the one -- binds them all or whatever.
We will continue to participate in meetings until, you know, someone figured -- someone tells me what to do because that's what I live for.
The other thing that's sort of significant that I would actually request help on is this: we are -- the IANA Web page is -- the inability to define anything that anyone actually wants on the IANA Web page is probably the most consistent request or complaint that I have gotten --
MR. PLZAK: It's traditional.
MR. CONRAD: Yes, it is traditional, however, I don't like that particular tradition because I have to find stuff on the Web page and it drives me absolutely insane.
So, we've actually gone to the effort of producing a draft, proposed IANA home page and I have to put all these words in front in order to keep people from screaming at me that, my God, you changed something without getting community input, you nasty conspiratorial bastard, you.
I guess the conspiratorial bastard, anyhow, it's just the nasty part I'm trying to avoid. So, that URL is why it will actually put you at a page that thrives to explain what we're doing, we are requesting input on sort of the design.
We know that it's not complete yet, there are things that are missing, you know, it's a work in progress.
But we would appreciate any input that you could provide on -- you know, what you like, what you don't like.
Kim Davies is a name today, is on volunteer exactly, sort of shepherd this project, he intelligently put his e-mail address as the contact point for any suggestions or comments and I told him he'd probably regret that and he said, "Oh, no, no one will care, no one will send me e-mails".
So, it's now been my goal to see that he is buried in e-mails about comments, so please, comment on the Web page.
I'm intent on hiring two additional people within IANA. My goal is to make everyone's life who works for me a living hell. So, I have to spread that pain. We are putting some automation projects into limited production. We have this back log of requests of various kinds that I have committed to clearing by the Marakesh meeting.
Many people have complained that they actually don't know what ICANN or IANA does. Well, ICANN as well, but that's a separate issue. So, I've actually committed to update and publicly document all the IANA resource allocation related processes. This has actually been requested by not only people within the Internet, but also people within the government advisory committee. So, there's probably a good chance it'll actually be able to get it done.
We are in process of recording data more consistently and comprehensively and the intent is to actually provide that publicly. And, eventually, we will publish that web page. So, if you want to see your name that lights up on the web or something, provide comments and we'll provide an acknowledgement or something. So, any question? Oh oh. No.
MR. HUSTON: You're probably going to say no anyway. Geoff Huston, APNIC. It would be really helpful for those of us poor victims who have to pause the weirdly inconsistent outcomes of your work to actually ask for some degree of structure and authenticity in your registries. When are you going to give us external structured data and sign us?
MR. CONRAD: Oh, that would make things too easy.
MR. HUSTON: So, the answer's no?
MR. CONRAD: No, the answer is yes.
MR. HUSTON: I'm shocked.
MR. CONRAD: In fact, I was just speaking with someone who was sitting in this meeting about that very issue while I ate a cookie just out there. We are in the process of -- part of the process of the automation, where I said we were going to try to raise the number of databases, is to actually go into the data and XMLise that data. I'm not an expert in XML. So, I'm looking for XML experts who will help me come up with the scheme, if necessary, to take the data, present it in an XML structured XML format as well as presenting it in the classic fashion in that some people at least are help people who really want to see, they're not programmers. So, that is something that I've committed to. But, because I don't know XML, I'm not willing to commit to a date at this point in time. It is one of our more exhaustive goals that we're attempting to meet.
MR. HUSTON: And signing it?
MR. CONRAD: Signing it? Sure.
MR. HUSTON: Great!
MR. CONRAD: It's easy. Do you want that with my signature or --
MR. HUSTON: Kim Davies, I believe, is --
MR. CONRAD: There we go, very good. Yes. Yes, Bill.
MR. WOODCOCK: Yes, my signature --
MR. CONRAD: Oh, Bill's signature. How does Bill's signature sound?
SPEAKER: Or Bart?
MR. CONRAD: Or Bart! Any other questions? Thank you very much.
MR. PLZAK: So, thank you for that very comprehensive report, David. Actually probably the best report I've ever seen at this meeting from a person claiming to be from IANA and will admit to it. Yes, I'm damning him with faint phrase. Okay.
SPEAKER: Yes, reverence is not generally and I can't relate it virtue.
MR. PLZAK: Right. So -- Yes, David, we do miss your presence on the ARIN board, one last person to harass Bill, but, you know, we're getting along. So, anyways, we are at the magic time in the morning for the first coffee break. So, let's do that and please be back at ten 10:45 when the bell tolls. Thanks.
MR. PLZAK: The NRO Activities Report by Raúl, wherever he is. Okay, I guess we ought to toll the bell again and go -- I'm going to go get the gong. Here comes Raúl with all his stuff, so I guess he's going to bring it up here for his presentation on his coffee and cookie.
Yes, it's your turn. You're a very popular person, you were so entertaining earlier this morning, we had to bring you back for an encore. We can give you one minute. We got a little heavy metal back there, Jason? We could always bring David back up here to give us some more IANA statistics too, couldn't we?
Okay, Raúl is going to be doing the NRO Activities Report.
MR. ECHEBERRIA: Okay, it's me again, but with a different hat. Now I will make the report of the Number Resource Organization.
When I saw that yesterday the statistics that Ray presented about the participants, I realized that there were more than 50 persons that came to the meeting for the first time, then I had to change some slides to give some more information about the NRO. But don't be afraid, I will be very short.
The Number Resource Organization is an organization that was formed by the Regional Internet Registries in October of 2003. The goals of the organization is to formalize through corporative efforts among the RIRs and protect the unallocated number resource pool, promote and protect also the bottom-up policy development process, and to act as a focal point for internal community in input into the RIR systems. I should add that not only to act as a focal point for receiving inputs, but also to represent the addressing community in different international forums.
Then, the Number Resource Organization will also form at that time for existing RIRs and AFRINIC joined the NRO when it was formally recognized.
The structure of the NRO is the following. We have an Executive Council who is the body who represents the NRO, the Numbers Council and the secretariat. And also, the Executive Council creates coordination groups in different areas.
The Executive Council is formed by one representative from each RIR, usually the representatives are the TOs, and this is list of the members of the Executive Council. I'm the Chair this year, Ray Plzak is the secretary, Paul Wilson is the treasurer, and Adiel Akplogan and Axel Pawlik are happily waiting for new responsibilities in the next years.
The offices rotate every year, what it means that next year, Ray Plzak, if he continue being the representative of ARIN, will be the Chair of the NRO, Paul Wilson will be the secretary, and I will have two years of vacation.
This is the picture of the EC members. You can realize that all of us look a bit younger than now, this is because the picture was taken more than one year ago. I think that it was the last time that we met face to face all together.
The EC meets periodically by teleconference and/or face to face. Last year, we had 10 meetings, as all the meetings are available at the web site, it's a good idea to access the web site and look not only at the meetings of the EC, but also at all the documents and information that there is available in the web site.
In October 2004, one year after being formed the NRO, we signed an agreement and memorandum of understanding with ICANN. And with this memorandum of understanding, the NRO fulfils the role and responsibilities and functions of the ICANN address supporting organization. As you know, the ICANN has different supporting organizations in different areas, and the address supporting organization is one of them than the NRO, because this agreement fulfils the responsibilities of the address supporting organization.
This supporting organization has a council that is named the Address Council, and I will not speak very much about that because there will be a report of the Address Council, the Number Council activities in the -- after me, then, but I will mention something, the -- because this memorandum of understanding that we have signed with ICANN, the NRO Number Council fulfil the functions of the address council of the ASO. The Number Council is an advisory body in number resource policies. It is composed by 15 members, three from each region, and two of those three representatives of each region and community are elected in a large way by the community, and the other is appointed by the respective RIR Boards.
Also, observers from the RIR staff and ICANN observers participate in the address council, Number Council.
The term of office is three years, the Number Council advises ICANN Board, select ICANN Board members too, select also one member to the nomination committee of ICANN. This is the list of the address council members, but as I said before, I think that Martin Hannigan will make a presentation later about the Address Council.
The NRO also has, as I mentioned, coordination groups. At this moment, we have three coordination groups, the communication coordination group, engineering coordination group and the legal team.
The communication coordination group is chaired by Susan Hamlin from ARIN, she's here. The engineering coordination group is chaired by Ginny Listman. She's also here. This is because the chairs of the coordination groups rotate together with the secretariat of the NRO. The coordinator of the legal team, therefore, is Steve Ryan is the general counsel of ARIN. He's also here. I don't see him, but -- okay, he's in the last row in the --
This is the list of the current main topics that are under consideration of the NRO. Some procedural issues, like procedures for the address report and organization, the Executive Council is responsible for setting up the procedures for Address Support in Organization Address Council, then we have been dealing with procedures like how to select the -- how to appoint people for the ICANN board, how to call meetings, and many other issues. As we are discussing the charters for the coordination groups that are being under consideration right now.
Regarding Internet governance, we are busy in all the tasks related with the WSIS follow up. The WSIS, I don't know if all of you know, but is a Summit on the Information Society that was filled in the -- okay, also speaking about that. Thank you very much. As we are also dealing with the establishment of relations with ITU and with a relationship with other bodies like the Governmental Advisory Committee of ICANN.
We are also discussing the NRO incorporation, and a possible contract with ICANN IANA about the services that IANA provides.
This is a set of links that probably you will find useful. The website of the NRO and the websites of all the RIRs. That's all. Thank you very much. Any question?
MR. PLZAK: How many people want to see Raúl come back for a third time? Sorry, Raúl, you cannot leave to go to Montevideo to work on your new house. Your family can stay on vacation without you.
MR. PLZAK: Okay. Now, we're going to have an information presentation by Lynn St. Amour who's the president, CEO of the Internet Society and -- where is she? Oh, she's back there. Okay.
Lynn was supposed to be here Sunday to participate in the foosball tournament but was unable to get here. I mentioned yesterday that there was a challenge that would have been issued last night to the bean counters and it did occur. And I'll let Lynn come up here and talk the trash but the bean counters that they had the trophy there, they would no longer have it in their possession because they were -- So, Lynn, could you please come and talk to us about the foosball match and if you have some time, we can hear about the IGF.
MS. ST-AMOUR: As I'm not going to talk about the foosball match or the soccer table match and I've never heard Internet governance referred to quite so directly as trash before but --
SPEAKER: You need to get out more.
MS. ST-AMOUR: He thinks it was a late night last night.
MR. PLZAK: We have pictures, Lynn.
MS. ST-AMOUR: I have to admit: That I'm sincerely afraid of.
Just one or two quick slides on WSIS because WSIS is in fact the context for the Internet governance.
It's actually a process that was started in 2001. It was a full United Nation's World summit held in two parts in 2003 in Geneva, 2005 in Tunisia and its initial intent, and in fact ISOC participated in the brainstorming session that preceded the definition of WSIS and it was actually meant to tackle issues of ICTs and bringing the Internet to developing countries.
The secretariat was in fact the ITU which is the first place some mischief started to be introduced into the overall topic. Three issues in fact dominated WSIS: Internet governance was first and foremost - despite how it started and how it was built - financing strategies and ICT development and capacity building. And that order is probably a fair representation of the time and attention that it actually got from many of the world's governments.
Certainly from ISOC's perspective and many other folks, we talk about the Internet community, that being many people and organizations in this room, felt very clearly that that was backwards and worked very hard over the course of those four, five years to in fact reverse that focus with relatively little success in terms of reversing the focus, relatively good success in terms of damage control.
One of the outputs of WSIS was in fact calling for an Internet governance forum to meant to be a multi-stakeholder forum for dialogue, not an advisory body, not a policy setting body, a multi-stakeholder forum for dialogue, what we'd probably call a conference.
It also called for a process of enhanced cooperation and that touches the area that has the most concern going forward. I'll talk about both the IGF and the enhanced cooperation in a few minutes.
So, some of the key results from WSIS -- maybe this is the last WSIS slide. For Internet governance, there was minimal impact on the Internet structures for now. Any of you that participated in the process and certainly the RIRs, NRO, ICANN, IETF representatives, ISOC, many, many other organizations participated over the course of the four or five years, will recognize how serious the threat of damage was to the Internet until a lot of our structures and mechanisms.
Much of it is focused on ICANN and ICANN's responsibility. If you go back to its beginning, there was a lot of confusion over ICANN and their role and it was at one point, I think many governments assumed to be complete control of the Internet and covering everything to do with the Internet which, of course, we all know, isn't true.
It's clear that they were also interested in moving on to Internet standards and, in fact, you can find documents that actually talk about their intent to be much more active in Internet standards. It's pretty clear that telephony standards are slowly being replaced by IP standards and that clearly gives them some concern.
But back to a few results. One of the key results is there was a recognition of the role and the importance of the existing Internet governance structures organizations, processes, mechanisms. Very, very, very large education effort went on by many organizations in the room, the RIRs and NRO were very active. ISOC was obviously very active. IETF is active through ISOC as we are in fact their public face with respect to policy and education.
However, one of the things we didn't accomplish which we had, in fact, set out was to be recognized as an equal stakeholder, equal to government, private sectors, civil society. If you participate in those forums, you know that there are very prescribed roles and very specific definitions with respect to what those groups are, whether allowed to participate and when they're allowed to participate.
As one brief example, the United Nation's World Summit, the governments get six hours of participation and private sector and civil society got 15 minutes each for every six hours the governments got and it was extremely regulated, very -- arduous process in terms of lists. Your interventions are usually prescribed, written weeks in advance. So, it's a very formal process and not one which many people in this room actually find comfortable, as Scott just said.
One of the other key results was they did eventually, with some caveats, understand that there's a need to move the debate beyond technical aspects. As I said, they focused on many issues with respect to ICANN. Even in 2004, 2005, the key topics were still on IP address allocation and, in fact, one of the most heated topics was national allocation methods for IPv6 and that's still on the table in many areas. Route servers, DNS , -- for the moment, within the IGF context, they've agreed to set those aside. I don't know that that will hold if we actually go through the next six months and prepare the final agenda, but that is a tacit agreement that, you know, we just spent three, four years coming through that. We need to allow a year or two to let some of that settle in. It's clear that the Internet community heard some of the messages and are striving to make up processes even more accessible and even more open and even more understandable and by those enlightened governments recognize that time is appropriate in terms of letting that process advance and that it's time to focus on some other areas.
Some of the general results was there certainly was an increased focus on ICTs for economic development and capacity building, not nearly enough by many of our desires and wishes, but there was increased focus.
Very good collaboration with the Internet community. In fact, in Tunisia, at WSIS II, the IETF, ISOC, NRO, some of the CCtlds, Internet exchange points all actually shared a booth which is actually called the Internet and it was specifically to show people who are the organizations making Internet work web development continue to operate key aspects of it in one place and make it as understandable as possible.
We all work really well in this model. We have come used to with respect to -- we understand organization structures and boundaries and responsibilities and we actually respect them very well and we know who to turn to for different types of problems.
If you're outside this community it's not at all evident and in either field completely disorganized, completely, you know, by -- and, so one of the things we intended to do and we continue to do through a lot of our communications and really do need our, all of us, individually as well as some things we do collectively, just educate the world on the Internet, how it works, who makes it work, why it works, what are the principles and characteristics we actually feel strongly about is really protected.
The outcomes of WSIS was characterized as everyone was happy which in political circles means it was vague enough that everybody can translate the outcomes into whatever they'd like it to mean to them personally.
As I said earlier, one of the main areas to watch the enhanced collaboration, the IGF is moving along, data move along, I'm sure they'll be some rough spots, we know how to work in that process and we can manage that the enhanced collaboration is the one that's going to be a lot more difficult to understand, more difficult to participate in and possibly the most dangerous.
Different views on what the IGF is. A lot of people believe there should be a place to affect policy or government practices, that it should focus on things like multi -- policy dialogue or government civil society, private sector, all participate as equals and that that is enough as an end in another self.
There are others that feel that -- international policy, not operations but the policy for cost cutting international policy areas, that a forum such as that would, in fact, be helpful.
Others believe that it should be used to advance development agendas. The process for the -- to establish the IGF going forward, if it's actually lead by a representative of the United Nation Secretary General, that's Mr. Nitin Desai, who was, in fact, the -- the Chair and very active in WSIS too, for those of you who participated in either of those forums.
There's a small focus secretary in Geneva lead by Markus Kommer who is from the Swiss government and the IGF advisory group will be appointed by the United Nation Secretary General, he will prepare a slate of 40 people based on the work of Nitin and Markus.
It will have 20 governments, 10 civil societies and 10 private sectors. And if you notice what's missing there, the Internet community is not the fourth and equal sub-group, and we all argued very very hard that we needed to be separate -- a separate sub-group, separate group.
We don't fit easily in the private sector, we don't fit easily in the civil society according to the way the United Nations actually defines those groups and allowed to participation.
The goods news is that they didn't go to some civil society head and some private sector head and there are people that would count themselves as heads of those organizations who said, give me 10 names and got a government who say, give me 20 names.
In that case, we would have found ourselves in a difficult position of having to work within these other two -- two structures.
There's a tacit agreement that they will look for seven to eight Internet Community folks to participate in that group of 40 and they will manage the politics of pulling a group together and getting support from those three groups that are there.
So, we're looking for candidates, this is not an effort lead by anyone organization, the RIRs, I think through the NRO but I'm not certain, are actually going to be submitting some suggestions, ISOC will we're working with the IETF on that, we're also working with civil society in private sector as well, we're working with governments, we have good relationship with a number of governments, everybody is submitting their own short list of candidates and then Nitin and Markus will -- the same thing they did in the WGIG process, which is basically go to a period of socialization with key groups to make sure that the list is represented enough and everybody is happy enough.
The first meeting is in Athens very end of October. WSIS too actually called for five years of IGF, five IGF meetings.
It's pretty clear that that's not a firm requirement, if in fact, this one should turn out not to be useful and not well supported, they will certainly revisit whether or not there is ever a second IGF, third, fourth and fifth. Our contributions have emphasized focusing on development and the areas and impact access to in the availability of the Internet.
When it was pretty clear that we actually weren't going to get with this to stick fully to a development agenda, then collectively and again, you know, a lot of the organizations in this room started arguing that the IGF would be a reasonable place to discuss cost-cutting international public policy issues, those that don't fit neatly into any other form or body or process today and I think the rest of the items on there are pretty clear.
We also have been very very strong in saying that they should limit any new organizational structures or new meetings, I think we're already largely meeting out -- I said to somebody last night, given the Internet, you know, for everyone and it's developing the way it is, it's always the same few 100 people that go to RIR meetings, to IETF meetings, to ICANN meetings, to -- one meeting after the other, so I think there's more work certainly we all could do and I wished the United Nations would focus more on bring the Internet to more people.
I said earlier the IGF is not the end, it's simply one component of Internet government's activities.
The enhanced cooperation really will be the most important area to watch and if you speak to people that have been in United Nations -- and circles for some time, that's the area that -- concerned about and they do use words such as that is a place for mischief.
If there were any threats which we're going to come to, you know, we can loosely refer to it as the intermodal, it will come to that in enhanced cooperation process.
Some of the text and you can find out is on the WSIS site which is at ITU/WSIS, says that the enhanced cooperation is the process whereby governments, on an equal footing, et cetera, et cetera, will carry out their roles and responsibilities in international public policy issues pertaining to the Internet, including the development of globally applicable principles and public policy issues associated with the coordination and management of critical Internet resources.
And it's those last six or seven words that give us the most positive thought. There's a very very large range of interpretation as to what this means.
Negotiations are under way already with governments across the world through their established UN processes and procedures to influence that process.
At the moment, Nitin, again, he's the IETF Chair, is consulting informally and how to start that process.
One of the key elements, I think, people are looking for is to understand what happens within the ICANN and the GAC space.
ICANN has a Government Advisory Council and they've undertaken a process of evolution and reform and if that process should prove -- evolution should prove successful enough, the GAC will either become a vehicle for ICANN with respect to their specific area of responsibility, actually the main name system.
There are some people that believe that the GAC would be the natural place for other issues of Internet policy to establish itself.
There are even some government officials that talk about ICANN and the GAC as anything from becoming some sort of UN structure which would oversee coordination, management, et cetera of critical Internet resources.
So, we're all staying very very close to both the individuals as well as the individuals that are actually responsible for this within the United Nations process as well as working very actively with governments of the world, both those that share our views and those that don't, to our chapters through organizations like NRO, through meetings such as this, through meetings such as the right round table, to participate in that process and influence it, you need to influence it through participation.
Basically staying on the outside and saying, this is a bad thing and this is a bunch of people who don't understand the engine, don't know what they're doing, it's not going to stop the --
So, I think we've all recognized this as distasteful as we have found some of the meetings practices, processes, time wastefulness, et cetera, that it really is the only way to actually influence it.
One of the other things that we should all be aware of is there's a lot of discussions on the forum of the ITU, ITU, as a couple of critical meetings come up, they have something called the -- potentiary which happens late this year, November, I think that's also in Istanbul, if I remember correctly.
It happens every four years, it is where the ITU revisits their four-year strategy, four-year plan and four-year budget. There are a lot of preparatory meetings happening now, there was just one in Dowa with respect to the development agenda, there are a lot of sub-meetings with respect to next generation Internet meetings, spam meetings, every kind of meeting and regional meeting, et cetera, you could imagine, it's a very very intensive playing process, we actually did establish that plan and budget.
So, we are all participating very actively in it, you saw some of the presentations this morning, AFRINIC and folks are becoming members in various sectors of the ITU, that's specifically to participate in those processes and work influence them from -- from the inside.
Last comment, just -- this is really my opinion extremely, unfortunately, the beginning. Certainly success of the Internet is driven -- it's clear that engineer resources are considered by nations to be a strategic asset, I don't think most of us would argue with that point.
It's also clear that the -- has caused us concern amongst some governments which leads them to focus on governance.
So, what should we expect - and this is the last side - in the IGF that it will show immediate value or fail -- of the WSIS will turn away key governments and stakeholders. There are some that argue that's not a bad thing. If it fails, it fails because there's not then a proven need for or it was not successful in addressing needs that other people felt were important.
There will be significantly more activity enhance cooperation. I should say this is an important area of rights for -- Then, earlier, much rise on the ICANN and a GAC evolution. A lot of governments see enhanced cooperation as already under way, as I mentioned earlier through a lot of efforts that were all undertaken. I've been listening very carefully to what we heard through WSIS too.
Other governments in UN Organization see it as a tool to either achieve control objectives or give themselves a new mission instead of activities for the years coming forward. And, certainly, the latter group are very concerned by the Internet and its development. They're very, very active and very serious. And that's it. I don't know if you have questions or --
MR. BRADNER: I just want to follow up just a little bit on that and then maybe a discussion a little bit, because this is important. I talked about it at an ARIN meeting recently and put it -- and there was an article in -- had an article in the ARIN paper here. Basically, the message that we're getting is the Internet is too important to leave to the people who know what they're doing. And that's a very important message we're going to be getting and again, and again.
The ITU is going to be off and contemplating its navel and figuring out what its future is. But it feels that it has the power to do that. In the last ITU penny pot, they came up with a resolution that said fundamentally the ITU was the place to do Internet standardization. And so, they've gone off and proceeded along that line because they have decided that they are the place. And they are -- by God or governments or something to do that.
This is not something to ignore. This is something that could affect us all a lot. Not only ARIN and the potential of real confusion is indeed the ITU proposal of allocating prefixes, P6 prefixes to governments and letting them allocate within countries comes true. Or just in your day job of the ITU deciding that it's going to figure out how to do Internet settlements. So, you transfer traffic to another ISP. They're going to tell you how you charge the other ISP. Now, you collect money from the other ISP.
These are the kinds of things that are on their agenda. Don't ignore them. Please, if you have any discussion, Lynn has been doing a lot of work in this space and command her for that, but help if you can. I can almost see somebody standing at the microphone.
MR. HOWARD: Lee Howard, Stanley Associates. And, firstly, I just want to say: Yeah!
SPEAKER: Thank you. Feel a little better now?
MR. HOWARD: Second --
SPEAKER: Were you playing football last night?
MR. HOWARD: What?
SPEAKER: Were you playing foosball last night?
MR. HOWARD: No, I don't remember any foosball last night. Second, I wanted to ask: Given that I am not a government representative or even an employee of a major multinational telecommunication's corporation, it seems to me my options for participation are somewhat limited. And these are not -- Many of these organizations are not such that they have a public policy mailing list type of mechanism for participation. What would you suggest?
MS. ST. AMOUR: The private sector actually participates through the International Chamber of Commerce. And they're actually evaluating, as far as I know, some of their process with respect to participation. They actually work through a lot of national chamber of commerce structures. That's an option. I mean, if you seriously want to participate, you can send me an e-mail and I can help direct you into the right people to figure out what the right process is. It's email@example.com.
MR. HOWARD: Thank you for the horror story.
MR. PLZAK: I think Lynn would rather be playing foosball or, excuse me, the table soccer we now call it, than dealing with this better. So -- And Lynn, I also would like to thank you for the work you've been doing in this area.
So, we are now ready to move on to our first policy proposal discussion of the day. And that's proposal 2006-3 - capturing originations in templates. And we get to see somebody's removable diskette. And trying again. Ah ah. Okay. This proposal says that ARIN would in all IPv4 and IPv6 number transactions, collect, and display the autonomous system numbers which are permitted to originate a prefix. The AC shepherds to this are Mark Kosters and Suzanne Woolf.
This was first introduced on PTML in February of this year. It designated a form of proposal about a week or so later. The first public policy meeting discussion of this is at this meeting. There have been no revisions to the text since it was originally submitted. From the staff's perspective, significant resource impact, requires template changes, registration software change, directory services change, guidelines change and staff training.
Legal. From a legal perspective, counsel says none. However, counsel has an asteric note here. It says that the third staff comment, which I'll show you staff comments in a minute, indicates a potential issue by increasing ARIN legal responsibility in that as ARIN agrees to verify anything, it may create a legal liability if it is done badly. Staff comments 1, this could be addressed by alternatively enhancing the Internet routing registry. The proposal admitted the network modification template from this listing of template.
And there's a reminder. ARIN can verify that the request was submitted by a an authorized POC representing a vetted organization. ARIN cannot verify specifically the list of ASs that the user permits originally to address prefixes within the address block. In other words, ARIN cannot verify that a specific address ASN can be paired with a specific IP address.
We can tell you that the person that is claiming to be able to do that has in fact received those resources from ARIN. But that is as far as we can go with that. And that's why counsel commented as well.
So, discussion about 33 posts, 10 people, and I won't go through the comments. And so, I believe Sandy -- Oh, she snuck up behind me. Hi Sandy.
MS. MURPHY: Hello.
MR. PLZAK: You're on.
MS. MURPHY: Okay. It's an interesting aspect the way that the proposal process works that I did not have an opportunity to see either the staff or legal comments before I prepared my slides or before I got here. So, none of the slides specifically address the staff or legal comments.
I wanted to tell you where this proposal came from. There are a bunch of people who've been participating in a set of workshops addressing the problem of securing the routing infrastructure. We all know that this has been a problem that's been discussed widely for a long time. There have been a plethora of different solutions suggested, none of which have maintained or even gotten any interaction at all.
So there were three workshops held and the participants were operators, router vendors, researchers, people from the registry trying to come to some idea of what a deployable solution might be. DHS was the host, and this was reported on at a directory services round table at the last ARIN meeting. There's a web site there that you can go to for some of the papers that were presented at some of the workshops.
Okay, so, there was a strong call, one of the things that ran through the workshop was that it would be very, very good from the operators standpoint to be able to come up with an authenticated list of authorized prefix originations, which ASs are authorized by the prefix holder to originate a route to that prefix. This would be useful in many different ways. It would be useful in responding to customers' requests to route a prefix. It would be useful in debugging routing difficulties who is actually supposed to be announcing that prefix. It would be useful for those people who are building routing filters to have an authenticated authorized list from which to generate their routing filters. And it is also the necessary first step for any of the routing security proposals that have been put forth, the very necessary first steps in protection of BGP advertisements.
Okay, so the operator's suggestion was why don't we add a field to the ARIN templates to collect the ASs that the prefix mentioned in that template are allowed, the ASs, the prefix holes are allowed to originate a route to that prefix, and then publish this in a collected list so the people could download it and use it in a way that's described. Possibly this might also be individual queries.
So, I was told that you needed to have a slide with a proposal text, so this is the eye chart, and then here it is spread out over two slides, it will be a little easier to read, and I've underlined what I believe to be the really key phrases here.
The requirement is that ARIN would add an optional additional field to the IPv4 and IPv6 address block transactions, and I originally had a list of all the transaction templates, and it was suggested that that was putting restrictions on what might happen in the future with the ARIN directory services, so I expanded that to try to describe them, and in the process, managed to not have a description which matches the NETMOD template. I beg your pardon. But the additional -- the optional additional field would have in it a list of the ASs that the prefix holder says are allowed to originate routes to that prefix.
This is an advisory field only, it is information from the prefix holder, it is not something that ARIN is validating anymore than ARIN validates and verifies the net name that you put in a template.
ARIN is asked to produce a collection of these mappings from prefix to AS number, a list where every entry would include the address block, the list of ASs, or allowed to advertise that address block, and a tag indicating what type of delegation this is.
Then there's how is this to be publicized, made available to the public? It would be required that ARIN make it available as a bulk transfer with the provisions that if this is included in the bulk WHOIS transfer, that this data is not subject to the redistribution and acceptable use policies that apply to the bulk WHOIS transfer. It would be something that would be redistributable at will, and allow ARIN to also make other means of access to this information. For example, query services, like WHOIS queries, are provided.
So, we need this authenticated list of authorized prefix origination, something I like to call ALAPO. Why ARIN? Well, if we have it done at ARIN, this inherits any scrutiny ARIN is doing on the direct allocations and direct assignments. We also know that the operators are very used to using templates in their ordinary daily operation of their network, so this inherits any self-discipline that the operators have in filling out templates. They're filling out the templates, the field is there, they can put it in. We all note that the operators have not been as disciplined in putting route objects in the various different routing registries.
We need to have ARIN's identification of the proper prefix holder anyway. ARIN is the only person who can state which person is the prefix holder for any particular address block. And of course, it is a potential way to populate the IRR with good data. Nothing in this proposal says that the information collected has to reside in WHOIS database, or in the routing registry, or in some other different data structure.
Okay, why not do this through the IRRs themselves? Well, the difficulty is that the desired authority is that only the prefix holder can speak to who is allowed to originate a route to that prefix. Well, the IRRs don't have any access to the authentication mechanism that they IRRs have with their membership, so the IRRs do not have a way to say the person coming to them attempting to register a route object is the authorized person to speak for that prefix. They don't have access to the authentication mechanisms that the registries have with their members.
Now, there are IRRs run by the RIRs, and by the way, anyone -- the persons responsible for choosing those two three-letter acronyms have -- you know, I try to type them correctly, and I still manage to get them wrong. But the RIR IRRs can validate the authority of the route objects that are being registered in those routing registries for their own members. They have the ability to do that. I understand that RIPE does do that check, if you attempt to register a route object, RIPE follows the suggestions of RFC2725 - I know the number because I just looked it up - to say that both the prefix holder and the AS have to approve of that route object. You have to be able to authenticate from both of those people, so they go even a step further. But as I understand it, entries into the ARIN IRR are validated to being from the correct point of contact. If you're registering the INET NUM or the OT NUM for an address block or an AS number but no validation is done for the route object, it's potential that ARIN could do that, but it is not presently being done.
Furthermore, any of the RIR IRRs that allow registrations for prefixes or ASs that are not in their own membership have the similar problem with the non-RIR IRRs, that they can't do the authentication steps, they don't have access to the authentication.
Okay. So what about the PKI proposal? There was a tutorial on Sunday evening, there was a panel presentation yesterday about doing a PKI that would have a hierarchy attesting to the authorization for the resource hierarchy, the IP addresses and the AS numbers. Well, the PKI resource hierarchy and the WHOIS resource hierarchy really should be the same. You saw yesterday in the panel presentation that there's some dispute as to whether or not these will be the same, will necessarily be maintained to be the same, will be kept parallel, whether they'll be separate, so there's a question there, but they're really intended to map the same hierarchy.
Now, this AS capture in templates addresses the same need that you heard Steve Kent refer to as a ROA, a route origination attestation. It's the prefix holder saying which ASs are allowed to originate a route for that prefix.
Okay, so what are the differences? Okay, well, there's one surmountable difference, the PKI hierarchy is based on very strong cryptography. Use of strong cryptography in accessing the ARIN WHOIS database is weak, to use a phrase. There is a potential for getting certificates that would be used to protect your communication with the ARIN WHOIS database; not many people have taken ARIN up on that possibility, so right now, the authentication for entries in the WHOIS database is based, as I understand it, on mail from, which cryptographically speaking, is not strong.
But there is also a design difference. The assurance of the entries in the WHOIS database is based on ARIN having a method of authenticating to people who communicate with them and doing the validation as a step that the entry is provided, and then storing the information in the database. So, the assurance relies on ARIN's validation of the authentication mechanism at that time.
PKI entries can be validated at any time and at any point, so what that means is, is to maintain the full original assurance of the data that you get from ARIN, you have to get the data from ARIN. If you UUNET gets the data from ARIN and makes it available to their customers, the customers have to decide whether they trust UUNET as well as trusting ARIN, because they can't validate the information. The PKI entries, the CERTS, can be validated by anybody at any time. And I also wrote down here that implementation of this and deployment in use ought to be easier than the PKI, but then the staff proposal was that -- the staff comment was that this would be a significant resource impact, so -- easier might just be a relative term.
And that's the end, and I'm ready to take questions.
MR. DELONG: Owen Delong, Netli Networks, and I completely oppose this policy. I think that the things this policy seeks to accomplish can be accomplished by a lot less effort and improvement in the IRR interface, and the RIR IRRs have all the resources necessary to accomplish the goal here. Making it optional makes it even less effective and less useful, and we should look more at improving the IRR usage and process, and less at changing this.
MS. MURPHY: So, I have three answers to that comment.
The first about whether it's an optional field, I actually got a private comment that it should have been a required field. That could be a change in the proposal if it was something that everybody thought. About making this IRR, I reiterate, only IRRs that are associated with RIRs have a way of authenticating entries, and then only those entries from their members, so this data could be collected in the template and put in the IRR; that would at least inherit the benefits of operator familiarity with using templates and perhaps some self- discipline in actually filling out the field where we know that the route objects are not being presented to the routing registries.
MR. DELONG: We can agree to disagree on that, but I think fixing the IRR process is a more useful method.
MS. MURPHY: Well, I don't know that the IRR process is broken, so -- I don't know. Okay. Next.
MR. PLZAK: Centre-most microphone, back.
MR. BLUNK: Larry Blunk, Merit Network. I oppose this proposal. I think the effort would be better spent on doing the certificate support first, and making use of that. I can see this data getting stale just as the IRR data gets stale. I mean, you may require that people enter it initially, but there's no requirement to update it as the origin AS changes. I'm not exactly sure how you would import the data into an IRR. I mean, would it replace existing IRR data? I don't know if you're talking about the ARIN IRR or other IRRs when you talk about --
MS. MURPHY: I was speaking about the ARIN IRR.
MR. BLUNK: Okay.
MS. MURPHY: Yes.
MR. BLUNK: Let's see -- so I think with the certificates, you could actually use those to -- you talked about authenticating the IRRs with a public certificate, you could use that information to assign data in IRRs and then have a strong form of validation there. Right now, as you mentioned, there's no way of using ARIN information with IRRs, but with the certificates, you could potentially add a signature field to the RPSL objects, and then retain that information in the IRRs, and that seems like a much stronger way of certifying objects. And then, from there, you could progress to something like secure BGP, so again, the certificates seem to be the best direction.
MS. MURPHY: Are you talking about the certificates with respect to the resource PKI that was presented yesterday, or are you talking about the certificates in general?
MR. BLUNK: No, the resource --
MS. MURPHY: If you had the resource PKI, you wouldn't --
You would use that mechanism to sign the route origination, you wouldn't mess around with the IRRs.
MR. BLUNK: Well --
MS. MURPHY: Yes.
MR. BLUNK: -- yes. Okay. I guess that's it. Oh, also, there's no -- we're talking of them as mechanism for AS resources, for AS holders to register prefixes. It seems like you would want a mechanism to do that as well.
MS. MURPHY: The intent here is to prevent ASs from being the ones who speak for what prefixes are being originated. The problem we're trying to solve is that ASs start routing prefixes they're not supposed to. So, if we let the ASs say "and here are the prefixes that I can originate", we have just inherited the problem that we're trying to solve.
MR. BLUNK: Well, you could verify one against the other and compare it and make sure that they match.
MS. MURPHY: Why? I don't understand why that would be of benefit to have the ASs speak, publicly saying what prefixes they originate. They publish each update --
MR. BLUNK: LACNIC is a similar mechanism. I don't know if --
MS. MURPHY: I'm sorry?
MR. BLUNK: -- have you looked at the LACNIC database?
Because they have fields for both AS holders and prefix holders --
MS. MURPHY: Yes.
MR. BLUNK: -- to register information.
MS. MURPHY: Okay.
MS. AZINGER: Marla Azinger, Frontier Communications. First I'd like to thank you for bringing awareness to what obviously is an issue and something we need to work on. However I can't support your proposal because I don't see this as being the answer to resolving the issue that clearly we have about stale information. However, if this proposal were to go forward, I would strongly encourage that it is a mandatory, like you mentioned, and not an optional, because optional kind of equals --
MS. MURPHY: Okay.
MS. AZINGER: Thank you.
MR. SEASTROM: Robert Seastrom, Inter.net, and ARIN Advisory Council. We don't have valuable, or useful data, it becomes less useful over time in the IRRs. It seems to me that this seems to be a framework for cryptographically authenticating data which is simply going to be allowed to go stale anyway. And so I wonder why we don't just have the IRR authenticate, and have something that you have to pass back to the IRR that you got with the prefix that validates that you're the person who's got the prefix. I mean, this seems like a huge infrastructure involving X.509 and, you know, PKI infrastructure when that's really not necessary for the scope of the problem that we're trying to solve.
MS. MURPHY: I'm not suggesting a PKI hierarchy. This proposal does not suggest a PKI hierarchy. It's a capturing AS template --
MR. SEASTROM: It's not clear to me that it needs to be in WHOIS either. We already have an Internet routing registry and ARIN already runs a piece of it. All that needs to be done is validating that people are registering what belongs to them.
MS. MURPHY: Yes, the intent of the suggestion from the operators of putting the things in the templates was that this would inherit the operators comfort level of using templates and the fact that they use the templates all the time as a means of getting them to record this data that's not being recorded. So, it's a --
SPEAKER: Data gathering mechanism method.
MS. MURPHY: It's a data gathering mechanism that's a socialization of the process of the data gathering so that people will do it more often.
MR. SEASTROM: You must be talking about a different IRR than I'm used to dealing with. Thank you.
MS. MURPHY: Well, I'm talking about the templates. I'm not talking about the IRR.
MR. WEILER: Sam Weiler, SPARTA.
MS. MURPHY: Yes.
MR. WEILER: Full disclosure, I worked with Sandy and drafted an earlier version of this proposal. I do support this proposal. I also support the PKI work that was talked about yesterday. I'm puzzled by the opposition to this proposal on the grounds that the effort could be better spent on the PKI stuff. I see this bit of data collection as necessary to support the PKI stuff, necessary but not sufficient. Ah, Geoff shaking his head. I look forward to that explanation.
And I'm not hearing objections as to why this is harmful. If it's necessary but not sufficient, why not just go forward with it. Where's the harm?
And, also, by way of explanation, I don't know if Sandy covered this, I think ARIN could, if the data collected were sufficient, ARIN could use this to populate its routing registry.
MS. MURPHY: Yes.
MR. WEILER: There's nothing in the proposal that would prohibit that. We drafted it in this way to make it simpler to implement.
MR. BRADNER: It seems like it has been presented as a precursor from doing anything with the PKI work that we heard about. It's not that it's necessary, but not sufficient. It's got to be done in order to do the --
MR. WEILER: But Geoff has a different idea, which I look forward to hearing.
MR. BRADNER: Well, Geoff's known for his different ideas.
MR. DILLON: Michael DILLON, BT Radiance. And I do support this proposal, even though, on the mailing list, earlier, I made a comment, something like: "Why are you doing this? This seems to be -- Why aren't you spending more effort in improving the IRRs instead of doing this?" But I think now that I understand what is actually being proposed, I fully support the proposal.
We've also talked a little bit about the PKI stuff here. It's something that I really don't like. I think it's a big complex confusing mess with no clear requirements, no clear path, et cetera, et cetera. However, what Sandy has presented is nice, and simple, and clear, and straightforward. It's a nice incremental step. It's something that makes things better. It's something we can do now. We don't need to worry about big complex architectural changes.
And even though it might involve some ARIN spending some money and putting some effort into a little bit of development on the back office stuff, I think it's fully warranted, because it gives us something we do not have today.
And, because there's so much misunderstanding, I'd like to say what I understand this proposal is. And maybe you'll correct me if I'm wrong, but ARIN allocates addresses to address holders. Address holders may or may not also hold ASs. They may or may not be involved in routing. But one thing is clear, they all hold the right to use a specific address block.
And this proposal is to ask those address holders to inform ARIN which ASs they intend to use, they intend for this address block to be announced through, so that that information can be recorded somewhere, probably in WHOIS. But, hey, once it's recorded and available, you can put it anywhere you want. ARIN can put it in their IRR. Anybody else can grab it and stick it in their own OSS systems or whatever. That's really irrelevant.
But the fact is that ARIN, who is the only organization who has a relationship with all address holders in our region will ask those address holders to supply an additional piece of useful information and then record it and make it available to the people who do routing. Is that correct?
MS. MURPHY: I believe that's a nice summary, yes.
MR. DILLON: Okay. Thank you.
MS. MURPHY: Thank's.
MR. HUSTON: Geoff Huston, APNIC. I don't think I support this proposal. Certainly there are some weaknesses here that I think are quite difficult. Trying to introduce trust and authentication and authority in the routing system requires parties to be able to validate what the information is in a manner of their satisfaction.
MS. MURPHY: M'hm.
MR. HUSTON: What you're doing is, I still think, another instance of security pantomime. That weak, imprecise, unclear, partial, and potentially stale data is not very helpful to anyone. And this kind of mechanism, how do I know that the data that's being passed into ARIN and republished was authentic? How do I have any means of gauging that the process is being used behind some wall that I can't see the details of is useful or reasonable? I can't.
Part of the reason why a PKI structure tends to work is it makes the elements of authenticity and validation a lot clearer. That what the certificate structure does is does the original binding of a keyhold into the resource. And, after that, the public announcement, because it's not just announcing to ARIN, when I am saying, is the control of a resource, I am the valid control of that resource, and I give the authority to originate -- That's, if you will, an announcement to my routing peers, the folks who are actually going to negotiate that route rather than -- to ARIN.
When you take this model and make it even broader and start thinking about the diversity of IRRs, LIRs, and NIRs, and so on, and the level of indirection, the number of players that have direct relationships with an IRR is limited. The routing space is a much more diverse piece of biological floor than that. So, you know, this doesn't seem to actually cut to the issue.
Then comes the issue of: well, if we're going to do something, how do we harness energy, amounts of it to actually solve the problem? And is pantomime a useful step put forward in actually bringing real authenticable validatable informations to the routing system?
As it stands, I don't think this is a useful solution insofar as it merely replicates the known weaknesses we see in the IRR system of partial and out of date information with little real motivation by industry to keep it comprehensive and up to date. So, in that respect, I think this is not a solid way forward for us to really get a routing system that we can trust.
MS. MURPHY: Okay.
MR. BRADNER: Can you get to take a -- thing is actually that's the concept that you understand to say what it is that you do think the right process is to get this information bound and accessible?
MR. HUSTON: I think the information actually has to come through certification systems, as we discussed yesterday. I cannot see any other ways. Now, as an initial step, you could use that certification information to make entries into net routing registries. But if you included the key information, you'd at least be able to understand the accuracy.
MR. BRADNER: Certification meaning that the address holder gets token from the registry and then uses that to make the assertion?
MR. HUSTON: The address holder holds a private key.
MR. BRADNER: Okay. Thank's.
MS. MURPHY: So, I think you echoed the comments that I made about the difference in the design option of this information you have to get from ARIN to maintain the assurance, because ARIN did the validation. And with the PKI structure, anyone can validate the information as they --
MR. HUSTON: ARIN did the validation?
MS. MURPHY: Yes.
MR. HUSTON: Through some process of which I --
MS. MURPHY: Yes.
MR. HUSTON: -- know nothing, and I just trust?
MS. MURPHY: Yes.
MR. HUSTON: Okay, cool.
MS. MURPHY: To this trust part, I'm not agreeing with, but --
MR. BICKNELL: Leo Bicknell, ARIN advisory counsel, Harrah's Entertainment. I'm going to speak with two different hats. The first hat is as an operator who could potentially use this data. I do not support the proposal because it seems to only affect things going forward. We have an awful lot of networks that have already been allocated.
MS. MURPHY: M'hm.
MR. BICKNELL: And they have no information with them today.
And, if we get no process to get information with them in the future, the few new ones are going to allocate, it'd do me no good to have that information. I either need it for everything or nothing.
As a user, I have simply a comment, as an address holder. If this proposal were to go through, I would suggest that ARIN make it easy on the template that is actually used for this to allow me to specify that ASs 1 through 65000 can announce my route. Because that would be very convenient for me.
MS. MURPHY: Incredibly insecure, but, yes, convenient.
MR. BRADNER: One last chance at the microphones, closing the microphones after another minute or two.
MS. MURPHY: I did want to say one other thing. Any of the proposals that we have as trying to come up with a way of securing the prefix originations has to deal with the fact that we have 20,000 ASs already allocated and a gazillion different prefixes and how we actually do the securing of the stuff that's already out there is the very first boot strapping part of the problem is of concern.
And whether we couple this with something that's devoted to extracting stuff and routing history and go forward with new stuff from that point, it is a question of how -- something gets deployed. It's a comment that applies not only to the -- but to the PKI and to any manner as different other sort of solution.
SPEAKER: Actually, I have --
MS. MURPHY: No, I'd suggest you go through the mikes first but I want to comment on --
MR. SCHILLER: Jason Schiller of UUNET/Verizon Business. I want to echo the comments about incompleteness and optionality of this, but putting those aside, what I want to talk about is it's seems to me what you're trying to do here is be able to automatically write a policy to secure the routing infrastructure and if that is the intention of how this would be used, why aren't we looking to folks who are already doing this such as our colleagues over in --
And the reason why I bring this up is because it seems to me that we're collecting too little information. Go doing WHOIS, my age, WHOIS dot right dot net AS702 and watch it scroll up your screen. There's a lot of information collected about the AS to AS relationships and the policies between the AS to AS relationships.
MS. MURPHY: M'hm.
MR. SCHILLER: And what I can't understand is if you want to try to autogenerate securing the routing infrastructure, why would you want to collect less information than what RIPE is currently doing? And if I could ask somebody who's doing this in Europe who's autogenerating their configs, if they could maybe come to the mic and comment on whether all that information is needed or not.
MS. MURPHY: This suggestion is intended to gather the one piece of data that's needed to start off the process of validating BGP announcements and that's validating the route origination. It's not intended as a mechanism that will provide the ultimate security of BGP announcements. That's a much more complicated system.
But this one piece of data which ASs are allowed to announce with a prefix is the necessary first step for any of the security proposals.
So, the data has to be collected somehow. One mechanism is using the PKI resource hierarchy we heard described yesterday which is a cryptographically strong way of doing this but isn't yet in operation. This is a suggestion of doing something that is already in operation and very accustomed for people who are operators to use to collect the necessary piece of information.
Not all the AS policies have impact on BGP security. You don't need all of that stuff. RIPE is actually doing -- at least providing the proper security mechanisms for the route objects that are placed in RIPE.
So, they've got a better handle in that situation. I don't know how complete their data is. I understand it's a little more populated than other routing registries in other regions. But not all of that stuff is necessary to satisfy this one first step of the security requirements.
MR. SCHILLER: I guess my concern is that -- I understand that long journeys start with small steps but I think maybe we have to take many more steps before we even get the beginnings of payoff.
MR. BRADNER: The microphones are now closed. Randy?
MR. BUSH: Randy Bush, IIJ. One comment first which is you'll note in the PKI space system which was being discussed yesterday and I presume discussion will continue --
MS. MURPHY: M'hm.
MR. BUSH: -- that actually making the binding between a prefix and the AS which may announce it is the last thing, not the first.
MS. MURPHY: Yes.
MR. BUSH: And is dynamic, not static. And this -- well, the static nature sticking in WHOIS makes me nervous in the presence of people wanting to move during DOS attacks, et cetera. But -- Sandy, to be honest, I'm just a country boy and a geek here and you know more about the security stuff than I do and -- so, let me phrase my question this way, which is: Is this all actually an incremental first step on the path to strongly secure the securing resource allocation routing --
MS. MURPHY: M'hm.
MR. BUSH: -- or is this a temporary patch, I think, Geoff sees it -- security -- And please reassure me that it's not a wrong step or a step that will delay or mislead us on -- away from a strong and more assured path. In other words, a) if it's a patch that -- if it's called -- you know, even if it's a security pantomime and isn't going to do damage, fine if it'll make some people happy. But, please, tell me it's not going to mislead us to expand resources that --
MS. MURPHY: It would be better since --
MR. BUSH: Yes.
MS. MURPHY: Both mechanisms are trying to accomplish the same goal: Authorize prefix origination. Information that is put into the WHOIS database may go stale information that's put into a certificate is -- at least the certificate has expiration times on it which are not in WHOIS entries. I'm not certain about RPSL objects.
So, the only possible misleading thing would be if you put an entry into the WHOIS to say it's at an AS who is allowed to originate your prefix and, at some later point, in the certificate system, said something different.
There is a potential -- I tried to talk about this yesterday. We have two hierarchies. The WHOIS hierarchy for address blocks and this potential PKI --
MR. BUSH: Redundant data will get out of synch.
MS. MURPHY: Right. There is something to be solved here about what the relationship is between these two pieces of information. During -- until the PKI is deployed, while the PKI is deployed for those people who don't seem to be able to do PKIs for reasons of cluelessness or government policies, who knows, this is a mechanism to attest to the same data. As I tried to point out, there is a difference in the assurance that you get from the data that's in the WHOIS held by ARIN than a data that's in the PKI and --
MR. BUSH: You know more about this than I do. Just tell me we're not doing harm.
MS. MURPHY: I don't believe that this does harm.
MR. BUSH: Thank you.
MR. BLUNK: Larry Blunk, Merit. One thing that I noticed wasn't specified is whether a net block, if all the more specifics are covered or if you have to register a separate template for each more specific? One of the things we see in RIRs is people -- we have like a /16, we'll go and register 256/24s because they potentially want to announce more specifics at some point and they want to allow those through filters so, they just go ahead and create a bunch of objects and I think it would be useful to have that specified whether it covers more specifics or if you need a separate template for each more specific.
MS. MURPHY: If you intended different -- let's see. If you wished to have different more specifics routed by different ASs, then you would need a separate indication of that and so, you need to either have two templates, one for each -- one for the more specific that are being originated separately or create a complication in the templates that indicate which list of ASs -- which more specifics of the address block as a template.
MS. WOOLF: Susan Woolf, ISC and ARIN advisory counsel.
Scott is probably about to pull the room on support for the specific proposal as written because we need to do that.
Do you think it would be useful also to the advisory counsel if you could ask a slightly separate question about where there is consensus support for a role for ARIN in moving forward with this issue in any sense because I think there's kind of a separate question about the --
Is there a role for ARIN as far as gathering this kind of data, figuring out it should be gathered and used in efforts to secure our system?
Because aside from the specifics of this proposal, you know, we may decide, you know, is this somebody else's problem or is there a role here for ARIN and it's just a matter of how do we want to go forward with it, how do we want to detail it?
Because if the room -- you know, if the membership, the public feels that there's no role here for ARIN, it's somebody else's problem, that's -- you know, sort of a different directions to us than -- there's interest in ARIN playing a role here and it's about the specifics.
MR. BRADNER: Okay, now it's that time. Show of hands, exercising time. So, I'll ask four different questions: one is those in favor of this proposal as written, those who are against this proposal as written, those that think that ARIN has a role to play in this general space and those that do not.
So, first, those that believe that support this proposal as written, 2006-3. Yes, I'm channeling, John, hold them up high. Or highish, I guess. Okay, do we have a count? We have a count.
Those who do not believe that this should go forward as is. Keep them up. This is the exercise before lunch. Somebody signal me when it's all done. Okay, it's all done?
All right, how many believe that ARIN should play -- have some role as yet not particularly defined in this area of figuring out how to bind prefixes to people or ASs. Is this something ARIN should be doing, if so, stick your hand up. Everybody got the counts?
Okay, how many do not think this is a role that ARIN should play? I expect we have a count, so, do we have the counts here?
For reference sake, there was no comments on the -- no remote comments and there are 114 people in the room. So, as we gather the information here.
SPEAKER: Scott, how many people are in the room?
MR. BRADNER: 114.
MR. BRADNER: You weren't listening two and a half minutes ago.
SPEAKER: I was thinking about voting.
MR. BRADNER: You were thinking about voting, okay. All right, so what do we have here now? This is in -- well, this is no ARIN -- which is which here?
Okay, so I'm supposed to sum these all, that's what I'm trying to do, yes, we're supposed to add these things together.
So, 8 in favor, 20 -- 37 against -- no, 38 against -- 39 against.
ARIN role -- is the ARIN role -- so, there's too many pieces of paper here. Role to play, here we go.
Yes, well, I need totals too, yes. So, there's a lot of support for a role and one person against.
John is better at some of this job than I am. Well, I'm going to hand it over now. Thank you.
MR. PLZAK: And now, you can see the advantage of being in Harvard.
MR. BRADNER: Yes, right.
MR. PLZAK: Okay. So, we get ready to take a lunch break here, so, please, remember to take your valuables with you, this room is not locked or secured.
Of course, if you don't want them, you can leave them, there will be a small sale afterwards this evening.
Cyber Cafe is opened and come by and see if you can get that backpack. Lunch is the same place as it was yesterday and where breakfast was this morning.
And we'll see you back here at 1:30.
(Whereupon, a luncheon recess was taken.)
MR. PLZAK: Okay, we got Stacy up here so we're going to have some fun this afternoon, all right. All right. So, you can tell it's the last afternoon because you have the announcement about the wireless cards.
If you're not attending the meeting tomorrow and you happen to be one of those people that got those wireless cards and if you don't want it to be an expensive souvenir of your trip to Montreal, turn it in. One more time, let's thank him.
Okay. Glad to see that -- could make it this afternoon.
SPEAKER: He was here earlier.
MR. PLZAK: Yes.
SPEAKER: I asked the Chair for permission.
MR. PLZAK: You asked the Chair for permission, okay, that was a legitimate party break. Okay, let's remember the rules of the road.
Okay, among those, who you are, what your affiliation is and whether you support or don't support or intend to support or not support the proposal.
Also, remember you don't direct your questions to anyone else in the room except the Chair, you don't direct your comments to any one else in the room except the Chair.
So, and make your point. Okay. So, in the agenda note, Don Blumenthal who was to present the presentation at 1:30, unfortunately, had a minor medical emergency and had to go visit the hospital, thankfully he was in, checked out and so, as I said, it was minor, he is back home.
So, consequently, Don will not be here this afternoon. So, we are just going to slide everything forward a little bit and so, first thing we will do is take up the matter of policy proposal 2006-5 which is IPv4 Micro-allocations for Anycast services (temporary).
Okay, what does it do? It adds any cast services to the IPv4 Micro-allocation policy. And it's limited to 16 allocations and two years.
The AC shepherds are Susan Woolf and Matt Pounsett. History, this was introduced on the mailing list on February this year and designate a formal proposal at the AC meeting following that submission and this is the first meeting which this proposal is being discussed.
There's been no revisions to text since it was originally submitted. Now, we're not changing -- there we go.
The -- we're back to removal -- oh, it's now a disk E, this morning, it was disk F, okay, so -- all right.
Minimum impact, guidelines changed, this is staff training. In March, legal assessment was no legal risks.
One staff comment: shouldn't it be either 16 allocations or two years instead of 16 allocations and two years? It's a question we have. Not too much activity on the discussion this time around, 11 posts by five people. Comments are as stated, four of them being in favor. And so, with that, we will now discuss the proposal. David.
MR. WILLIAMSON: I'm David Williamson with Tellme Networks. As usual, there is the obligatory hinge of proposed text. I suppose hopefully at this point I can suggest that you've all read it already since it's in the packets.
I'm actually not going to talk about the text dimension. I'm going to talk about the actual intent and actual impact.
The intent for this proposal is to provide a method for organizations that wish to deploy an Anycast service that are not already qualified under the existing micro-application policy to actually get space.
This is very similar and the next slide will show you, it's very similar to a proposal introduced at the last meeting which was abandoned, mostly because there was a perceived abuse problem with that.
Let me try to address that with this one. It's also, at least in part driven by the interest for preserving IPv4 space -- available space obviously is one of them and we -- efficient use of that. And we believe there's actually a real need for a policy of this nature because there are now multiple entities out there that are offering DNS services, VoIP points and things of that nature that Anycast is well suited for dealing with.
The difference is ironically, there numbering for this cannot -- on the computing side. The previous one had some vague requirements for actually getting the space, I mean, for new accounts service. The company described the service to some extent. We actually added a much stricter requirement with this round of it where direct allocations are required from an appropriate body and we also tried to limit the abuse by eliminating the term and scope of this change in order to actually get operational experience which will hopefully guide future policy.
There's a few assumptions that went into this. We assumes that generally the audience for this would probably not be ISPs. ISPs usually, but not necessarily always, have a fair amount of space and are generally well connected internally. I have a couple of cases that demonstrates some of that.
The primary audience is probably holders of PI space. We also made some assumptions about what people would actually use Anycast services for: Reliability, routing, routing efficiency, looking for, you know, a best route system nearby and some operational flexibility because you have considerable operational advantages to offering some types of Anycast services for DOS prevention, on- line maintenance, that sort of thing.
And, again, this is directly aimed at organizations that don't already qualify under the existing micro-allocation policy.
I want to address some of the prior objections. There was some discussion about abuse in LA. It was illustrated to me and, in hindsight, it was pretty obvious that just by simply being multi-homed, even if you had PA space, you could be Joe's Autobody with, you know, pair of addresses from different places and say they're multi-homed and suddenly you need a /24 for your Anycast service of some variety and that might have qualified under the previous version of this, that's probably not acceptable.
The intention here was the wording of this version is that you're required to have direct allocations and be advertised from multiple sites.
Since we're mostly aimed at DPI audience, this shouldn't be a real problem. We were trying to find a way to make this more general without allowing for abuse. It's actually a fairly hard policy to write in that regard -- location is required and direct allocation should decrease the opportunity for abuse significantly.
Some other objection that came up in various places, mostly on the PPML, there was a suggestion that any /24 would just work.
Our experimentation that we did with our site found that in general most /24s that you just kind of pick out of random IT space are widely routable but don't necessarily have a global penetration. Because of the existing policy that has been turned into operational policy by many large ISPs, you still need at least a /22 or shorter prefix in order to have really global routability without obviously the exception of /24s from legacy --
There's also a suggestion that announcing /24 from a larger aggregate would cover the need. To a certain extent, that's probably true if you have an aggregate of that nature. There was some discussion overnight on the PPML for -- those were caught up -- about this particular point. One of the problems here is we have several use cases, I'll show you one in a moment here, where it might be the case that an organization doesn't have a suitable aggregate already in all of their data centers or at all of their announcement points. So, in aggregate, it wouldn't really solve the problem there.
And also, and this is the point a little bit about Anycast with operational flexibility and reliability.
So, part of my quick doodles with this PowerPoint here but -- here's a couple of examples. This is probably not a good use for this policy. It's feasible that an organization might qualify, you know, with this type of set up but one would hope that an organization that is well connected internally and has -- backbone and is announcing the same aggregates from all of their hedges from a common AS would probably not need just a /24. They're probably already unto larger allocations anyway.
On the other hand, there are numbers of sites out there and they're mostly content providers that don't necessarily have a substantial backbone among their various sites and they're often consuming multiple ASs. Each one has a separate set of prefixes that it announces.
Aside from this type who wish to announce an Anycast address or block are kind of out of luck and need current policy set up. With our current policy, there is no possible way to acquire a block that's suitable here without basically lying to the ARIN's staff and try to justify a /22, that will just -- a minimum allocation size. That's clearly behavior we should not try to encourage among the community.
Full disclosures, a couple of problems I still see with this. Some of these are somewhat in transient and I'm not quite sure how to deal with these. From the outside of a given network, Anycast looks like a multi-home network. There's no easy way to tell them apart and I've struggled for -- well, more than I should, to try to find a good policy to identify the differences and it's actually kind of hard.
In addition to just address the concern that came up in Los Angeles, there is still opportunity for abuse here. The intent here was to minimize that opportunity by making the scope and time allocations pretty heavy and that should give us enough operational strings. I'm hoping that this will be a successful policy if implemented and we can come back in a year or a year and a half, and look at modifications that make sense.
If we find that there is abuse, obviously, the sunset clause in this policy will cause it to expire and that should take care of the problem.
And with that, I'll give it back to the Chair.
MR. BRADNER: Okay. The microphones are open.
MR. MANNING: Do you want me to go -- I'm sorry, Mr. Chairman, would you like me to go down to the microphone or can I do it from here?
MR. BRADNER: No, Bill, you can go from where you are.
MR. MANNING: Okay.
MR. BRADNER: But state who you are.
MR. MANNING: Okay. My name is Bill Manning and I'm a little concerned about two aspects of this particular proposal. One of them is the terminology used about guaranteeing routability. For the last several years that I have paid attention to this, I don't believe that an RIR has the ability to guarantee routability and so couching a proposal in terms of that seems a little awkward to me.
The second one is the limited time frame. Prefix recovery is not always the easiest thing to do and the enforcement mechanisms for that are, in some sense, outside of the scope of the original registry because, again, it really depends on the ISPs cooperating.
Have you thought about this in the construction of this proposal?
MR. BRADNER: You were just admonished to talk to the Chair.
MR. MANNING: Oh! Mr. Chairman, have you thought about these things? Am I completely out to lunch here, Mr. Chairman?
MR. BRADNER: I actually have not thought about these things but I will ask somebody who might have.
MR. WILLIAMSON: The first point about guaranty and reliability, I completely agree, ARIN has no way to guaranty the reliability of any prefix anywhere.
It's more about the opportunity for global routability, if you will, since our experiments already show that a random 24 is not generally routable.
In serie -- the blocks reserved for micro- allocations should be more so, obviously, ARIN has no way to guaranty that and I understand that, I don't believe the word "guaranty" exists in the text of the proposal itself, if it does, that's probably an error, I think it's more in the justification.
On the second points, I agree that there is a -- problem with recovery of addresses, part of the -- this will hopefully come out of a well understood walk and because of its limit in size, hopefully the recovery will be relatively easier and, you know, it will require some coordination with ISPs and such but it's a difficult problem all the way around.
In addition, it also might help that we don't need to recover them but --
MR. MANNING: Let me see if I can clarify the -- in this thing. Having participated in an address recovery activity more than once in the past, there is always this idea about letting an address block fallow in, you know, in some sort of resting state so that you can be assured that it's cleaned up before it goes out again into the big -- you know, the big bad routing, you know, fib world.
And it's unclear if there is going to be an high enough demand that you actually have enough time to let the thing go in fallow, so, anyways.
MR. BICKNELL: Leo Bicknell, ARIN advisory counsel. On the PPML mailing list, Mr. Woodcock made a comment that he potentially could use eight of these, he may be off easily preparing his justifications now so he can send them as soon as the policy goes through.
I wonder, as a result of his message, something I hadn't thought about before then, if it would make sense to add to this policy a statement that each applicant may get one and only one since there are only 16 to give out in the first place.
MR. BRADNER: The last sentence -- he's putting out the last sentence which already says that.
MR. BICKNELL: Well, but Bill's specific comment was that Bill could submit for all of the organizations he worked for and I'm concerned if the goal is to get operational experience that having all the operational experience come from one person would not be very much operational experience.
MR. BRADNER: It depends on the quality of the person, I would expect, but --
MR. BICKNELL: Well, obviously, some better than others.
MR. BRADNER: I won't go into the particular details of this particular proposer but -- back microphone?
MR. DUL: Andrew Dul, Boeing. I oppose this policy on a couple of different grounds, I don't understand why 16 is a magic number, I know it was just picked out of a hat.
I also -- I'm opposed to this because it -- to me, this doesn't really seem very, quote, experimental, unquote.
It seems like Anycast services generally work fairly well, this is a question of resource allocation, I would -- I would support a policy that allows a current address holder to justify the use of a single /24 for Anycast users among their existing allocation or assignment.
With any experimental policy, I would expect that we receive a report on why and how this went and I don't see that there's a requirement for any of this type of activity.
The other thing I was thinking was that while back, we passed an experimental policy type process thing and one of the things that that required was a buy-off from a IETF like organization and as far as I know, there is no buy-off for an IETF like organization for this experiment.
MR. BRADNER: Before you go, you said that an existing holder could justify use for Anycast, what would ARIN's involvement be in something like that?
MR. DUL: ARIN's involvement, would that be if, say, I'm a /20 assignment holder and I decide to set aside one of that /24 as in Anycast address and announce it separately, when I came back to ARIN asking for an additional assignment, they would take into account that this is an Anycast block and ignore the utilization requirement for that specific Anycast block.
MR. BRADNER: Sounds like a really neat way to get around being checked on by announcing the whole thing as an Anycast block.
MR. DUL: If we think that Anycast services are required and that they demand special treatment, I see that as a valid way to deal with those concerns.
There is certainly abuse possibilities, I think there's abuse possibilities with this, the only reason why the abuse possibilities are low is because there's a number 16 there.
MR. BRADNER: Okay.
MR. DUL: If this was a real experiment, I would expect that there would be more.
MR. BRADNER: Okay.
MR. DILLON: Michael DILLON, PT Radiance, I support this policy, I think it's a nice straightforward simple easy to understand policy and the only odd little bit I can see in there is that number 16 and I would encourage the ARIN advisory counsel to simply do away with it because if you got one limit, two years, I don't see why you need another limit, it's a little bit too much like market manipulating -- market manipulation things, that we will only create a mark-up for 16 organizations to do this stuff and I don't see that you need to do that --
SPEAKER: There are not discriminatory for the first 16 applicants.
MR. DILLON: Yes, there shouldn't be any reason to give the first 16 applicants any special benefit. If -- when there's only three months left in this two-year period, if somebody comes along and says, we'd like and address and we can do some great stuff in the next couple of months, we should be able to get it, I mean, the two -- two years is the limit, it sets the cap that makes -- it makes it clear to everybody all concerned that, you know, this is a temporary thing that you're buying into.
There's no need to put -- have another number.
SPEAKER: Temporary thing or if it is judged by future policy meeting to be a successful experiment, it wouldn't necessarily be --
MR. DILLON: Yes.
SPEAKER: -- temporary.
MR. DILLON: However, a future policy meeting can decide to change anything, any element of the policy, so -- and really, I think that we spend a lot -- too much time trying to micro-engineer policies whereas we should really just get something that's reasonable out there, work with it and if there's a problem, fix it the next time around because there's always a next time around.
MR. BRADNER: Okay.
MR. BUSH: Randy Bush, IIJ. Scott, this one really confuses me, if Anycast works, it doesn't -- you know, and if it works, why do we have this experimental -- it seems the -- if they need all the criteria required to receive a -- space, why don't we give him IPv4 space and stop telling us it's pink with lace.
MR. BRADNER: I think actually the answer to my previous question comes into that and that it's the -- it's ARIN's procedures for verifying usage which would be modified by this -- by implication.
MR. BUSH: Well then, if all it's needed is to say that Anycast -- that utilization is the space by Anycast, it can be used as justifications that -- utilization of space, then why don't we just say that instead of having this kinky constructed policy out the side?
MR. BRADNER: Just as a data point, your previous policy proposal was for a change to policy, not an experiment, so the idea -- this -- a change to policy was proposed before and shut down so this is an experiment to see whether the camel's nose sticks under the tent.
MR. BUSH: It just seems like it's compromised in 30 ways so it's this weird shaped thing and there are one or two point solutions that would have solved it, one is -- Anycast as valid utilization of space problem, another is, you know, just Anycast micro-allocations and be done with it, it's a legitimate service.
And what we've got here is this confusing thing.
MR. BRADNER: So just the --
MR. BUSH: I think, by the way, to clarify a question --
God, I forget who the previous person of this mic was, is that this is an experimental policy, it is not a policy for experimental allocations and therefore, the requirements for reporting afterwards and blessing by the Internet vendor task force, et cetera, are not applicable.
MR. BRADNER: Or even necessarily retrievable. It's experimental policy, it does --
MR. BUSH: Right.
MR. BRADNER: -- and it's not --
MR. BUSH: The policy is experimental and if it's not experimental --
MR. BRADNER: Just to be precise, do you support or not support this proposal?
MR. BUSH: I don't support it, I would -- I believe there's something necessary in the space, I think this is a confusing camel.
MR. BRADNER: Front mic.
MR. DELONG: Okay. I think Heather was actually standing there before me.
MR. BRADNER: Name who you are and --
MR. DELONG: Owen Delong, Netli Networks. And I kind of support this policy with some reservations. I think that there is a need for Anycast policy or at least an ability to get /24s allocated for Anycast if there isn't the other more conventional utilization --
MR. BRADNER: And I'll ask you the same question. What do you mean by "allocated for Anycast" in terms of what would ARIN do differently in order to do that?
MR. DELONG: Well, a lot of times, you're going to end up needing a /24 for Anycast where you probably have two to three actual addresses out of that /24 that are pinnable. That's generally not going to be -- by ARIN as 50 percent or 80 percent --
MR. BRADNER: So, it's the same thing from changing the verification rules?
MR. DELONG: Correct. In terms of the experimental allocation basis, I've got a couple of questions. Number 1, I think that 16 is way to small a number for a meaningful experiment. And I'm not sure having a number on there makes sense anyway.
Number 2, I'm unclear as to whether the limitation of two years means that at the end of two years, everybody who got the 16 allocations gives the space back or whether it means that, at the end of two years, even if all 16 allocations have somehow miraculously not been issued, no more allocations are issued and that's the only impact of the two year limit.
MR. BRADNER: You don't state one way or the other what happens at the end of two years to the allocations that were made. Is that correct?
SPEAKER: That's correct.
MR. BRADNER: So --
MR. DELONG: I find this ambiguous.
MR. BRADNER: Okay. Leaving it to the wisdom of the advisory counsel. There is a man with trust.
MR. DELONG: Okay. So, I'd like to know where that would go, because it would probably influence how I would prefer to vote on this policy.
MR. BRADNER: Well, it's not stated in the proposed policy.
So, you have to take that into consideration in your show of hand a little later on.
MS. SKANKS: Heather Skanks from MCI. I asked this question the last time at the last ARIN meeting and that is: what is the -- I'm not seeing the technical requirement for having to have a PI allocation for Anycast. So, sort of what another person said, which is: if we change the policy to say that any task is an acceptable justification for requiring a /24, is there a technical reason why you need that 24 to be PI space as opposed to getting it from an existing provider, an LIR? That's my first question.
MR. BRADNER: Want a chance on that one?
MR. WILLIAMSON: Just to plump my corporate hat for a moment and actually represent Tellme Networks, we're in no way interested in the lock end of PA space. We want to have control of our own routing. I know that's not a -- RSPs, and I understand that. It's against your business case. But that's very much where we stand. I mean, it's kind of like -- to 55-1, for example, for v6. We want to have control of our own testing and routing, its hardware.
MS. SKANKS: Okay. So, let me interrupt you right there and say that, if that's the case, then what's stopping you from 24, 23 or 22, and why not just say: anybody who wants PI of any kind should be able to justify it for some reason that has no technical basis. Just because they don't want to --
SPEAKER: I may be able to answer that for you.
MS. SKANKS: Okay.
MR. BRADNER: Why don't we -- Start off by saying who you are.
MR. WOODCOCK: So -- I'm Bill Woodcock. So, Heather --
MR. BRADNER: Is that right?
MR. WOODCOCK: As UUnet --
MS. SKANKS: M'hm.
MR. WOODCOCK: -- do you really want your customer coming and getting address space from you and advertising out through, say, three dozen other ISPs in different locations where they're not your customer?
MS. SKANKS: Internet.
MR. WOODCOCK: If you like that, is that a really good use of space? I mean, a good use of your services?
MS. SKANKS: So, what --
MR. WOODCOCK: What happens when they stop being your customer?
MS. SKANKS: When they stop being our customer, they have to -- number. And that's --
MR. WOODCOCK: Into what?
MS. SKANKS: Into some other provider space --
MR. WOODCOCK: Which one?
MS. SKANKS: But I think the point I'm trying to make is that --
MR. BRADNER: We're not supposed to be having a dialogue out there.
MS. SKANKS: Yes. So, to me, you're kind of -- the problem of renumbering is now becoming the center point for saying justifications for PI. So, it's not really Anycast, it's not really the service that you want to offer. It's that you want to be independent of a provider. Correct? And you want to be able to get 24. So, why not then just amend the PI -- the requirements for getting provider independent space to say you should be able to get a 24 and not be wasteful. So -- But that's not what you've done. You're trying to sneak it in under saying that you need this for Anycast service, but there's no technical reason for why you actually need it for -- to run Anycast.
MR. BRADNER: Okay. I think the summary is that you don't believe that there's a technical justification for the proposal.
MS. SKANKS: For Anycast.
MR. BRADNER: So, are you in favor or against the proposal?
MS. SKANKS: I'm against it.
MR. BRADNER: Okay.
MS. SKANKS: So, that's my first question. The second question that I had had to do with the fact that you said that there's no global penetration of /24s. And my question is: can you provide information about providers that filter up to a 22 level, like who's not accepting 24s? Because if you're going to -- That should be in your justification, to say that there's some number of providers and provide that information about who's not accepting 24s.
And then, my third question was that you provide an example, and the very first thing you've said about your example was: this isn't a very good example of how this would work. So, show us the good example. Show us what -- I mean, don't give us an example and then say it's not a good example. Show us how you really want to use it and have a good example.
MR. BRADNER: I don't think she likes proposals.
MS. SKANKS: I just -- I'm sorry, like --
MR. BRADNER: No, it's fine, actually --
MS. SKANKS: I'm asking all the technical reasons for, like, like I said, if you're saying that we need to make Anycast --
MR. BRADNER: I think we got the question. I think we got the question.
MS. SKANKS: You're not -- I mean --
MR. BRADNER: Hold on, hold on.
MR. WILLIAMSON: So, actually, I gave two examples. And it was explicitly current use cases where the first one is not where the policy would be applicable. And the second one is placed where it would. Maybe that wasn't very clear up front. But the first example is a core example of the policy, because it's a place where it shouldn't apply. The second one is a place where I think it applies. Hopefully that addresses that.
If I thought there was support within the community for moving the PI space minimum allocation from 22 to 24, I would have proposed that. Instead of writing this, you know, kind of unusual hunk of small
9 policies to fit into my calculation space, because I don't think there is general support for sliding two more bits down on the PI space allocation. If you think there is, I'd be happy to -- I mean, I'd be up for that.
MR. BRADNER: Okay, well --
MS. SKANKS: Can you answer the question also about the providers who don't -- 24s?
MR. WILLIAMSON: Our experiments were actually fairly limited.
We found two large providers that don't. And I don't think naming names is particularly appropriate in this forum. So --
MR. BRADNER: Certainly, people have stated for a long time that this happens, whether without much backing sometimes, but it's been long time stated.
MR. SCHILLER: Jason Schiller, UUnet/Verizon business. I have a question about my understanding of what the problem's base is. And a lot of people are talking about, you know, how is Anycast broke in or Anycast just works. And, from my perspective, correct me if I'm wrong, but what I understand to be the problem has really nothing to do with Anycast, but really has to do with the routability of a particularly small block that you have, whether it's used for Anycast of for some other purpose. Is that correct or am I missing something?
MR. WILLIAMSON: No, it's actually very close, but it's not correct. I have in my possession as a company no suitable block for producing Anycast announcement. There is no way for me to acquire one at this point under existing policy without going and asking for a minimum size PI allocation, which is a 22. Using three addresses out of 22 strikes me as far more wasteful than three addresses out of 24. I think that's, it's still horribly wasteful. So, I think I'd really like a 29, but I'm not going to pretend that that's going to be routable anytime soon.
What I have is an anycast service -- deploy. I have no way to deploy it now within the existing infrastructure and the existing policy. So, I'm looking for a way to modify policy as minimally as possible such that my organization and other organizations that are like it, and there's been several that have contacted me about that, can get an allocation.
MR. BRADNER: Would there be any way for ARIN to actually verify its being used for Anycast rather than unicast services?
SPEAKER: Yes --
MR. BRADNER: Well, technically and practically are two different things. So, we'll get to that in a second. So --
MR. SCHILLER: So then I guess the follow up question I have is I'm guessing these two ISPs are filtering /24s to reduce the size of the routing cable. Do you think that if you get a separate block, that they're going to not eventually want to filter that space as well?
MR. BRADNER: I think that's a hypothetical, it would be very difficult for somebody to impugn the motives and future activities of an ISP. I think even within the ISP, that might be difficult.
MR. SCHILLER: Fair enough.
MR. BRADNER: But do you support or not support the proposal?
Sorry for the hard question.
MR. SCHILLER: I'm not sure. I don't think so, I think if I more clearly understood the problem space and more clearly understood the severity of the problem space, if -- I mean, if there's just two bad actors on the Internet that are dropping, you know, routes that begin with the number three, that may very well be the case. If this is something that's fairly widespread, and not having a large sample size myself, we do listen to /24s. I just don't see the problem. If the problem was clearly illustrated, and the scope of the problem was clearly illustrated, I probably would be much more on board.
MR. BRADNER: Thank you.
MR. SCHILLER: Sorry for the long answer.
MR. BRADNER: It's all right. Thanks.
MR. WOODCOCK: Bill Woodcock. So, first of all, I'm very strongly in favor of this, probably not a surprise to anybody, I've done about as much Anycast deployment as anybody out there, and I've consulted on a lot of different Anycast deployments, and the whole PI versus PA thing is, it's a straw man, it's not an issue. I don't know of anybody who's ever successfully deployed one of these things, or would even think of starting on PA space, right, it's not -- it's not even conceivable. So, what everybody does is they go out and they get swamp space, right, you acquire some little company, you get somebody to sign something over, whatever, right? Everybody's done this on swamp 24s, or small blocks like that.
There are a limited number of these. Anycast continues to sort of increase in viability, demand, et cetera. The number of swamp 24s out there is not increasing. We have, you know, two things running into each other, here, right? There's demand from the public for service, there is, you know, we've run out of supply of swamp seas, and we need a way of getting more little blocks for this.
Yeah, sure, we could do it all out of 22s instead of 24s, it seems like a heck of a waste for no reason at all, like everybody else who does this, it just seems straightforward to me, there's no cost to it, you know, it's just a savings measure, 24s instead of 22s, seems like a winner.
MR. PETERSON: Alec Peterson, ARIN Advisory Council. I am not in favor of this specific policy. Those who know me know that I have too a large amount of experience historically with Anycast, I'm a big fan of it. I think this is a poorly conceived policy, and I believe that the Anycast is a great thing, but I am also not a fan of this constant argument of, "Oh, there's some filtering going on somewhere, and just trust me, it's there," but not being able to provide details. I understand not wanting to name names, that's just not practical if it's going to be part of your argument. If it's not part of an argument, fine, but then just don't make it part of the argument. Thank you.
MR. BRADNER: Just one question, you say -- would you be in favor of some other proposal, like a permanent process, or something else relative to Anycast?
MR. PETERSON: The temporal nature of the proposal isn't particularly what I have objection to. I think 16 in two years is not right. I think that no number of allocations in six months, so maybe look at it coming up on the next meeting, if it's going to be experimental and really get feedback. I don't think it would -- if this were to be implemented, I don't think it would take two years for us to figure out if it's working or not. That's four meetings. I think one would be enough. But I think that making Anycast doable is good. I do not agree with Bill Woodcock's assertion that it is impossible to do, and a poor idea to do with PA space. It's not ideal, but I believe it's possible.
MR. BRADNER: Now, now, don't talk over there, you've got to be at the microphone.
MR. PETERSON: Bill, you have your opinion, I have mine. Thank you.
MR. BUSH: Randy Bush, IIJ. Luckily Bill won't interrupt me since I have used PA space for Anycast experiment, and that makes me inconceivable, so therefore he might mind his manners.
MR. BRADNER: We've known that for years, Randy.
MR. BUSH: Therefore you might also, and not insult speakers from the platform. I think I have a question first, especially I think it would be to ARIN, through you, the speaker, of course, to the ARIN actually allocation folk: does ARIN have a stash of swamps 24s and at least 16 of them? Can somebody answer that?
MS. NOBILE: Yes, Leslie Nobile from ARIN. Yes, we do have some swamp space, and yes, 16.
MR. BUSH: I would suspect as much, but I just wanted to make sure. So, I think in the constructive sense, that I would suggest, as you know, I'm against this proposal because I find it complex, confusing and so on and so forth, that a proposal that just says ARIN will allocate /24s out of swamp space for this purpose wouldn't meet the needs of the community in a much simpler direct and so unfashioned, I also think your point, Scott, about being -- being good, to be verifiable that resources used in a way it was justified, i.e. that its Anycast-ness is verifiable, is also a reasonable part of a substitute proposal. But this one's just kinky.
MR. BRADNER: Microphones, anybody else want to go to the microphone and follow up kinkiness? No? Okay, all right, so very simple, well -- I think we'll just ask the questions on this particular proposal. Randy suggested and others have suggested maybe an alternate proposal could be provided, produced if this one doesn't pass muster, but let's do that in the future.
So I'll ask who supports this proposal and who is against this, who opposes this proposal. And yes, I have asked for summary numbers rather than individual pieces of paper because I learned the first time. So, how many support this proposal? Okay, and how many oppose this proposal? I don't have to admonish you to keep your hands up because you're doing it. Okay, we've got a count? Okay, thank you. Wait for the summation to be done by the experts. We contract it out to the trade school down the street called MIT. Yale is also a liberal arts college, so they can't count either.
MR. SEASTROM: I understand MIT has been really good at training moving companies lately.
MR. BRADNER: Anyway, seven in support, 19 opposed out of a room of 100-ish sort of folks, so a lot of people don't really know what they think.
MR. PLZAK: Thanks, Scott. Okay, moving on to the next proposal, 2006-2, Micro-allocations for Internal Infrastructure. This proposal is to change the IPv6 micro-allocation policy to provide non-routed allocations for internal infrastructure. AC Shepherds are Stacy Taylor and Bill Darte. Introduced on the PPML in February of this year and designated formal proposal shortly thereafter, this is the first meeting that it's being discussed at. No revisions. Staff sees a minimum impact to implement it, requiring just guidelines, change and staff training.
Legal says there are none. However, note that staff comments 3 and 5 indicate legal questions, must switch, must be answered. The staff comments are: An inconsistent policy statement will cause ambiguity in that ARIN will make micro-allocation for critical infrastructure and the RIRs and IANA as defined in subsections below. Then, neither the RIRs nor IANA are listed in those sub-sections.
The second comment refers to Core DNS providers: Needs clarification. Can be difficult to identify exactly who is an ICANN-sanctioned CCTLD or GTLD operator. There are CCTLD operators who outsource at least part of the DNS service to commercial DNS providers.
Who holds the allocation? The CCTLD or the contractor? If the contractor, does this policy qualify the contractor for a micro-allocation? Does the contract to return the allocation to ARIN or transfer it to successor contractor when the contract is terminated? Justification must include why a sub-allocation of a currently held IP space cannot be utilized is somewhat nebulous. How is the justification to be measured by ARIN's staff? What could be considered to be a viable justification?
Eleven posts by eight people. No clear statements were made either for or against this. There's a couple of examples or comments. And so I believe Jason is going to be making the presentation.
MR. SCHILLER: So what I want to do is just kind of summarize what the intention of this policy was. Basically what we're trying to do is to allow for a small additional non-continuous IPv6 allocation which will be used by internal infrastructure. Primarily loopbacks but could be extended to additional things. And that needs to be in addition to an already preexisting v6 aggregate.
And the reason for this is because of BGP convergence issue. If you are BGP next-hops are not out of a non-continuous aggregate, you can end up with up to three minute blackholing. It can also additionally be used to address some security considerations.
So, the BGP convergence issue basically is if the BGP route, which is your destination that you're trying to get to, if it has a next-hop which is reachable through a pull-up or a less specific route, then when the actual destination goes away, the route still remains and the next-hop is still reachable and that next-hop is reachable through the aggregate.
What this means is the route never gets invalidated due to next-hop unreachability. You have to wait for the iBGP session time out hold times by default drop to three minutes and while that happens, you're either potentially routing traffic to the wrong place or blackholing it.
If in your network today your BGP next-hops are out of a network address that you have a less specific routed somewhere or routed to discard or no zero, you have this problem today.
So, the next two slides, I'm going to go into the technical details of why exactly this is a problem.
So, in this case, we take a multihomed BGP customer. They have a /24 192.0.2.0 and they've got two links too, in this case, a single upstream ISP but it could just as easily be multiple upstream ISPs.
I have a solid line which indicates the primarily link where they want all their traffic to flow and a dotted line which is their backup link which is used for fail over.
So, what you'll note here is I have 137.39, 1.x/32, there's my loopbacks. Those are all in the IGP.
I've also got pull-up routes in my core for 184.108.40.206/16. A pull-up route is basically a route that ties down your aggregate so that you can advertise your aggregate to all of your peers and all of your customers.
So, if you take a look at the routing table on some of these routers, you'll see on every core router, there is a static route for all of the aggregates that are owned, in this case there's only one as an example and that's routed to discard.
We also have all of our loopbacks in the IGP. You'll also note that the edge routers don't have a pull-up route. Instead, they learn the pull-up via BGP from the nearest core router.
So, now, what happens is the customer announces his primary route to edge-router1 over the primary link and that's 192.0.2.0/24 with a -- of zero.
Edge-router1 readvertises that route to the iBGP and he sets next-hop self. That's not required to make this problem happen but it's a little easier to talk about because you don't have to do a double regression in BGP.
So, the edge router sets next-hop self, he advertises it to all the other routers in the network. They all have a route for 192.0.2.0/24 with a -- of zero with a next-hop of 220.127.116.11, the loopback of edge-router1.
The customer also advertises its backup route to edge-router2 but within net of 10 to make it less preferred. We can see that route in edge- router2 but it is a non best route. In fact, the entire network believes the best route right now is 192.0.2.0/24 with a next-hop of 18.104.22.168. Traffic is being sorted over the primary link. Everything is great.
Now, all of a sudden, edge-router1 fails and it fails in such a way that it cannot communicate that it is failing. Somebody powers off the router, the router gets unplugged from all of its upstream links, the router falls over, catches fire, dies, whatever. The router fails.
Fairly quickly, the /32 disappear out of the IGP. The problem is at this point the best route for 192.0.2.0/24 is the one with the net of zero with the next-hop of 22.214.171.124.
That next-hop is reachable through a route that we have which is 126.96.36.199/16. So, if you're somewhere in the network that's not a core router, you are going to see in BGC your route for 188.8.131.52/16 with a next-hop of the nearest core router and you're going to forward to the nearest core router.
If you are a core router, you're going to have a static route for that /16 pointing to discard. You're going to throw those packets away. This is going to happen for three minutes. Three minutes.
So, basically what happens is the stale route is going to hang around in the routing table until the iBGP sessions with edge-router1 times out. The hole time, by default, is three minutes. Possibly those numbers could be turned down a little bit but there's not a lot of room. There's a lot of other timers that are underlying that are dependent on it.
After three minutes, what finally happens is the iBGP session times out and the route gets retracted from the routing table and all the routers in the network.
When the route gets retracted from edge- router2, he has to announce you any best router which happens to be this blue one here with a net of 10, with a next -- well, with a net of 10. Edge-router2 selects a new best route because its best route is now an eBGP route as opposed to an iBGP route. He advertises that to the rest of the network. The rest of the network learns 192.0.2.0/24 net of 10 with a next-hop of 192.0.2.1. Traffic is now forwarded across the back-up link after almost three minutes of blackholing the traffic.
So, how could you solve this problem? Well, what are we doing today in IPv4 to mitigate this? We have the same similar set up but you'll notice here I've changed my loopback -- my potential next- hop. They're now 157.130.1.x and these next-hops are not going to be aggregated. There will not be a pull-up route for it and this space will not be advertised to the Internet because I can't aggregate it.
So, here, I still have all of my core routers with all of their pull-up routes pulling up all of our space, except for our loop-backs.
Again, if you look at the routing tables, you see the same thing. You see our 184.108.40.206/16 pull- up route in -- in a static route on all of our core routers in BGP and the non-core routers.
You see, on the one side, 7131.x routes in the IGP but again, they're not more specific of anything pulled up in the core.
Now, what happens is the customer advertising in the /24 net of 0 to edgerouter1, edgerouter1 sets next-hop self of 157131.1, I have a typo down the slide, so I note that.
And that is advertised to all of the routers in the network. He advertised the backup path with a net of 10 which reaches edgerouter2 which is a non-best path.
All the routers select 192.0.2.0/24 with the next-hop of 157131.1, edgerouter1.
Now, when edgerouter1 fails, you immediately take the /32 out of the IGP. As soon as that happens, you also invalidate the 192.0.2.0/24 with the next-hop of 157131.1 because you have no routes to that next-hop.
As soon as that route is invalidated on edgerouter2, he chooses a new best router and advertises that to the rest of the network.
If we think about this in an IPv6 context, you noticed I used -- four addresses on those slides partly because it's easier for people to understand but partly to illustrate a point and that point is in v6, you're only supposed to have a single aggregate.
If you have just a single aggregate, there is no way to have your next-hops to be out of a non- contiguous face, your next-hops won't be out of your single aggregate.
So, how do you manufacture your next-hops being out of non-contiguous face? Well, you've got two choices. Let's take, for example, I am an ISP and I have a /28 and I want my loop backs to be out of non- contiguous face.
Well, one of the things I can do is I can take my /28 and I can break it in half and advertise the /29 to the Internet, advertise a /30 to the Internet, advertise a /31 to the Internet, advertise a /32 to the Internet and then keep one /32 that's not pulled up, that's not aggregated, that's not advertised to the Internet, that I use for my non- contiguous next-hops.
The other choice I have is I take my /29 and I divide it in half. I'm sorry, I take my /28 and divide it in half, advertise a /29 to the Internet and use a /29 for my next-hops.
So, the problem with these two approaches is they both add routes to the global routing table and they don't uphold that aggregation as important and that efficient use is important.
So, either you're going to have lots of advertisements in the global routing table or you're going to have half of your space wasted.
So, there's some additional security considerations and I see Chris Morrow in the back, did you want to take these last few lines?
MR. MORROW: Sorry for being late, my alarm clock didn't work. So, yes, for security considerations, we looked at a bunch of different -- oops! sorry, we looked at a bunch of different security issues we currently have in v4 and the ways we're kind of solving them and some of the biggest things we're doing is we're not -- or we're trying to do is not advertise the space that are internal services, things like IBGP and SNNP, all this stuff.
All that those things uses, we're not -- that we use, we're not trying to advertise to the rest of the network, so we -- to the rest of the Internet.
So, we're trying to do kind of the same thing with v6 if we can because we have a brand-new network, more or less -- earliest address, we'd like to be able to do that from the get-go as opposed to, you know, hacking it in after the fact because we were -- into it the wrong way the first time or a way we don't like.
So, we can also protect our network equipment by not letting the address space leak beyond our own network, so at least, people that are only directly connected can attack us and get default routes, so, it's a little bit easier on us in that case.
So, this is like -- kind of in the security stuff. Additionally, for the net engine, Off Skis, they really enjoy not having, you know, 65 terms in a parallel filter or an Access list for, you know, every little net block that we have so being able to say, well, anything that goes to this address base, just don't let it in.
So, in the future, when we have equipment who can actually filter things, on the edge, well, we'd be able to, you know, possibly permit even directly connected customers from sending traffic to our -- loop back from point to point and -- for equipment or other services that are internal, we don't want -- to use.
And one of the standard answers is why don't you just use private address base and why don't you use the -- you know, to guaranty unique crazy formula -- almost guarantied, right.
We have, you know, 100,000 customers today, we have, you know, hopefully a lot more tomorrow and that doesn't count the DSL customers.
There is really no way we can guaranty that it will be unique and if we have an overlap with a customer, we can't tell the customer, on one of our private networks or other things, we can't tell them, I'm sorry, you lose, we're bigger than you, you have to renumber.
We tried that in the past and it really didn't go very well. So, we would rather avoid that entirely by just using global unique space and if -- you know, allocate space and if something bad happens and a customer happens to, for whatever reason, pick our IP space to use in our internal network, we're going to say look, we went down because you're bigger and because you're a provider but we also registered this space to ARIN so, you know, we -- you know, it's ours to use while we exist and you shouldn't be doing this.
So, it's a little bit easier to have a confrontation with a customer if you can show that they actually are wrong as opposed to just -- pick the crazy number, that was your crazy number.
There's -- additionally, folks will complain about private address space, you see it every once in a while on e-mail lists, you know, private EP space or crazy stuff like that.
It just confuses the issue, that makes it complicated for customer support, it makes it complicated for customer, everybody else.
So, in the end, we would like to not use private address base, if at all possible, and we don't really think it's such a good idea. So, and -- Jason --
MR. SCHILLER: So, I wanted to end on the last line, there were a few posts on PPML and I wanted to kind of get this summary of the comments.
I'm certainly willing to accept most if not all of these into the policy but I didn't want to use them until they were -- and I'm not sure that there was enough discussion to indicate that we wanted to move in a particular direction.
So, these were roughly the comments unless -- I guess the Chair can take questions.
MR. BRADNER: Okay, the microphones are opened. He was wandering towards the mic before you were, I think.
SPEAKER: I think so too, after you.
MR. BRADNER: Mr. Bush?
MR. BUSH: Randy Bush, IIJ. Jason, all that BGP stuff just confuses me so it seems to me if you got a BGP problem, you should fix BGP.
I'm confused by the proposal again, it's for internal use and yet it talks about ccTLD servers. Aren't those external?
And those aren't -- so, in one sense, I'm smelling again golden address space for special services which is not something of which I'm very fond.
And in another, I'm hearing echos of RFC 1918 and I have some sympathy for the internal use stuff but -- thing in the private address space use that you don't mention is that somehow it never stays private and the routing announcement seems to leak out and all that kind of stuff.
So, it just seems -- I'm confused, it's not a crisp simple attack on the problem -- the proposal is not a crisp simple attack on the problem.
MR. BRADNER: So, at this point, are you --
MR. BUSH: I'm confused.
MR. BRADNER: You're confused, you don't either support or --
MR. BUSH: Yes.
MR. BRADNER: -- not support?
MR. BUSH: Well, I generally don't vote unless something is really ugly anyways, so don't worry about it.
MR. BRADNER: Okay, you're non-vote will be noted.
MR. HAIN: Okay, Tony Hain. I just wanted to make the note that, you know, the unique local space that's not guarantied to be unique is only half of the space that was specifically set aside and there was a section that was intended to be registered space for services like this that was tabled because this community didn't want that to become an -- for PI space.
Right, so, it could be resurrected and used specifically to solve this problem, right, you just have to decide which is more important, trying to avoid PI space which we think we agreed yesterday we need to do or this, and so I think we're at the point where we just need to resurrect it and use it for this.
MR. DILLON: Michael DILLON, BT Radiance. I basically support this proposal. Yesterday we did more or less agree that we were going to have a PI policy that will give out /48s for small organizations to do stuff, and these guys are, you know, even though there's a lot of complex technical justification behind it, they have a fairly straightforward policy where they want to get a /48 to do some stuff with it, and they're not even going to inject a route in the routing table, which is unlike the PI people, so as long as we do it a sensible way, take it out of a larger aggregate so that everybody knows that all of these strange private globally registered /48s are out of this one big aggregate, most of this must not, should not language disappears because ARIN simply publicizes that all of those 48s are never going to appear on the Internet, filter them at will, and at that point, we don't need to mandate anything, we replace them. The mandate about routing and announcing with simply a bit of information about the attributes of this larger aggregate out of which the /48s are allocated from. So --
One thing I'd also like to say is that this proposal, unlike many other proposals, had five authors, and I congratulate you on getting together five people to hash this out before bringing it to us, even though it was a bit of a hard slough to read through the justification, it showed that it was -- somebody had put a lot of thought into it, and that was good. That was nice.
MR. BICKNELL: Leo Bicknell, ARIN AC, Harrah's Entertainment.
I'd like to divide it sort of into two halves because I see two different problems here. On the routing side, your first example with the BGP behavior, it seems to me that there may be a better solution there in that from my experience, the two primary vendors for equipment today do seem to require that you have a pull-up route in your fib to be able to announce a prefix. And there are a number of implementations that do not have that requirement, and in fact, I know of no technical reason for it. There is no reason you shouldn't be able to, in software, tell your device to advertise or out without having to have an actual forwarding entry underneath. And so I would wonder on that problem if working with your vendors to get code that allowed you to do that wouldn't make the problem go away without having to do any addressing anything, planning-wise, allocation-wise, anything.
On the other side of that is the security stuff, and I would think if we want to go down that route, that I would agree with Tony. If we feel for needs like the security reasons, it is important to have a globally unique, you know, prefix per whoever that's simply not routed, we should resurrect the proposal to put them all in one place and keep them together so we can all filter them and hand them out in some organized fashion.
MR. BRADNER: So can you do your high order bid of support or not?
MR. BICKNELL: I think I probably don't support, but I'm still deciding.
MR. BRADNER: Okay.
MR. RICH: Yurie Rich, Command Information. I don't claim to be a routing expert, far from it, but what I don't understand is the possibility of having a non-unique ULA address coming into your network from one of your customers, and that would interfere with your ability to do what you're trying to do here, seems -- small so it doesn't seem like it's appropriate to try and create an awkward policy when there may be other technical solutions. So, I'm sorry, I guess I don't fully understand all of this, but I don't think that I support it given I think there are other technical alternatives.
MR. BRADNER: Okay, thank you.
MR. DUL: Andrew Dul, Boeing. This is sort of a comment about the way we're doing things in this meeting as well. There was a comment earlier about the -- oh, and I mostly support this policy. There was a comment earlier about how the staff comments were not revealed to the authors until right before the meeting. There's obviously some comments that would be helpful if they were revealed to the authors before the meeting, so I'd like to request in the future that the staff comments be posted to the mailing list or somewhere, maybe a week or two before the meeting, so that the authors have a chance to respond to that, or the community has a chance to discuss those issues.
MR. PLZAK: When I introduced this on Monday morning, I specifically said that we were introducing it here at this meeting and at all future meetings, it would be posted through the e-mail list weeks ahead of the meeting.
MR. DUL: Okay. I don't remember hearing that, I apologize, but I appreciate that we will do that in the future.
MR. BRADNER: I think there was an attempt to facilitate expediting the proposal, and that was at the expense of some of the communications, but the intent is to communicate well in advance.
MR. WILLIAMSON: David Williamson, Tellme Networks. One quick note, Ray, thank you. I think I generally support this policy. I think your enunciation of the problem is actually fairly clear, even though, you know, it's kind of a lot of technical -- and little tiny fonts, and you know, that whole thing, but I understand the problem statement pretty well.
I'm wondering how the authors see this reflected with the PI space discussion yesterday? I kind of see this as a common problem for just about anyone who owns an AS, and basically if you're running a BGP, you have this problem. So I'm wondering if it would be kind of -- reduction of the whole thing is do you get a 48 handed to you every time you get a new AS? I mean, that's taking it to the extreme, I know, but it kind of seems like the, you know, logical conclusion of this. I'm not sure I'm really against that, and actually it seems like a good idea for, I know I'd want -- and probably the reason I support this is I see the problem, and within the ASs that I control, it would be really cool to have exactly this kind of construct where I have reserved space just for internal infrastructure. Just curious how that might fit with PI space. It might be an interesting on-going discussion.
MR. BRADNER: So getting a /48 but not having the requirement to announce it under a single aggregate is basically the question?
MR. WILLIAMSON: Yes, I think that's the conclusion.
MR. BRADNER: Do either of you want to just address that particular point?
MR. SCHILLER: Yes, so, we've thought long and hard about the problem in our network. The problem really exists by virtue of the fact that when you ask for IP space, you get a single aggregate, and the only way you can make the problem go away is to get two aggregates. Potentially the one for the internal infrastructure can be much smaller, certainly. I wasn't really thinking about it, specifically about PI, just because probably my stance on PI, frankly. I was thinking about it in terms of PA addressing though, and I was thinking about if we give a /48 to every customer, and they also have BGP in their network and they also aggregate their routes, they have this problem. And the only way I can solve it prior to this week was to give a second /48. And I've talked to some folks as to whether or not that would be acceptable justification for getting a second block, I'm not sure that it is or that it isn't, to be honest. But I think the PI space is exactly identical, and I think if you're looking for PI space, you potentially should be able to qualify for two blocks, one for internal that's not routed, and one that is, if we think the aggregation for PI space is a good idea, and apparently it sounds like we do.
MR. BRADNER: Okay.
MR. BLANCHET: Marc Blanchet, Viagenie. Can you go back like one or two slides, the ones that were -- okay, yes, thanks.
I'm against unless, you know, against proposal unless I don't understand, or being convinced, but it appears to me that the solution of this problem is unique local, because it's not guaranteed, but it's roughly there as unique.
And second, the second bullet, to me, I'm not sure it's really an issue in v6 given that, you know, routers know how to handle multiple addresses on the same interfaces, and they should probably do the right thing, which is source address selection the right way, if they confirm it, but -- so I'm not sure about this one, I would need to verify that. But I'm kind of not sure where we're trying to solve a very detailed -- well, you know, on the overall scheme, a small problem or a specific problem of, you know, routing with the policy where it appears that unique local, you know, most do it, so --
MR. LOCH: Yes, Kevin Loch from Carpathia Hostings. I support the internal address component. I'm not sure why there was DNS stuff included that -- since that didn't seem to be addressed in the presentation. Particularly the ULA space, I don't think would be appropriate for this. I really do prefer to see address, an interface addresses that have reverse DNS associated with them, which is not possible -- that is strongly recommended going down that road.
To the extent that there's no other technical solution that might -- inferred or might be some other way to do this with PGP, I strongly object to any language as to what can and cannot be routed being included in the ARIN policy manual. While I certainly strongly support the idea that these would not be routed, I think that, historically that comes from RFCs and IANA assigning a space that matches up with --
MR. BRADNER: Okay. Thank you.
MR. HUSTON: Geoff Huston, APNIC. Marc Blanchet actually did trigger something in my mind here. It seems to me that what you want to centrally assign unique local addresses which are unique can be put into reverse DNS and for some reason got -- the way through the IETF and then silently died. It's not exactly completely dead. It could be revived. Are we trying to push through, if you will, the reality of centrally assigned ULAs, but trying to sneak it through a policy process of different kinds of addresses.
And my question is, I suppose, for clarification: If you had centrally assigned unique local addresses available to you, would they be used for this kind of purpose, and would it be useful?
MR. MORROW: Yes, I just want to be able to point at somebody and say: I can use this because ARIN says so.
MR. HUSTON: Well, we seem to have an IETF liaison person somewhere in this room, don't we? Thank you.
MR. BRADNER: Does the IETF liaison person want to say anything?
SPEAKER: I can wait in line. No.
MR. BRADNER: He wants to postpone saying anything.
MR. DILLON: Michael DILLON, BT Radiance.
MR. Chairman, would it be fair to say that, if there's an operational need for these types of addresses, that rather than wait for the IETF to work through its ponderous and mysterious processes, which those of us who are operators don't understand, or is it fair to say that we should simply forge a head and do what we're able to do, which is decide how to allocate a chunk of address space ARIN has to allocate?
MR. BRADNER: Speaking as one of the authors of the ponderous process, I think either is legitimate, depending on the aim and the environment. And it would not be appropriate for ARIN to come up with the idea of centrally assigned random number kind of thing. But, as you say, ARIN has a block of addresses to assign and to allocate. And creating policies for dealing with that is quite reasonable within ARIN structure.
MR. DILLON: So, you would agree that doing this is not sneaking anything around anybody?
MR. BRADNER: This is a public meeting. It can't hardly be sneaking.
MR. DILLON: Exactly. Thank you.
MR. RITTER: Harold Ritter, Cisco Systems. I oppose this proposal based on the fact that I think there would be better ways to handle the BGP issue from an implementation standpoint.
MR. BRADNER: Do you have anymore detail on that other than just --
MR. RITTER: Well, actually, you know, like, the /32s are advertised in the IGP. And I think that the BGP session could actually go down as soon as your /32 disappears from the routing table.
MR. BRADNER: You think that's supportable under the current environment, the current --
MR. RITTER: Absolutely.
MR. BRADNER: Okay. Thank you. Not universal agreement, but that's okay. Thomas.
MR. NARTEN: Thomas Narten here. And, just to be clear, I might run around looking like an IETF liaison person at times, I'm not one in any kind of official capacity. Though I clearly have an interest and go to the IETF and come here and try to, you know, have information go both ways. But this is an interesting discussion, especially about centrally allocated unique addresses, given the history of the IETF effort.
And I think it's worth noting that, even though it didn't, you know, got seven -- the way to he IETF is asserted, the last eight was here in some sense where we start. And it was kind of the speaker we ought to do this and the ARIN community saying: this is a horrible idea. And I think, you know, was a lot stronger than that, shall we say, at the time is what stopped the effort.
Now, having said that, if the community here actually thinks this is a reasonable way to go and actually wants to revisit that, I suspect that the IETF and the registry would come to complete agreement in a fairly rapid order on details of making that happen.
But one thing that I think we should keep in mind is also maybe go back and look at the discussion that took place about what concerns people had. Because, essentially, allocated -- was really intended for insights with respect to of their being, you know, perhaps tens of thousands or hundreds of thousands, a large number. And what you're talking about here for this problem is much more narrowly -- in terms of who would need to get an allocation. So, it's just something to think about and keep it mind.
MR. BRADNER: So, I'll amplify Thomas's report there. Yes, the process -- this was going through the IETF. And the IETF, I believe, would have approved it, yet, except for the push back from this community, which, as Geoff alluded to, push back because they felt this was going to create another class of globally unique addresses, which the ISPs would be pressured to route. And that's what stopped it. So, if indeed, that pressure was removed, then, I don't see any particular reason that the IETF wouldn't reassess the community support for such an idea, if indeed that's what people think is a good idea.
MR. PETERSEN: Alec Petersen, ARIN advisory counsel. I am not in favor of this proposal as such. I believe -- I agree that this is largely a routing protocol implementation issue that stems from having the routing protocol use the same rib as forwarding production traffic. I believe that the problem could be solved by changing that. But I'm not anything close to a router engineer. So, I'm probably missing something there.
I also don't quite understand why site local -- why non global unique site local addresses could not be used for this purpose.
MR. BRADNER: Well, site global is no longer a supported concept within IPv6 in the IETF.
MR. PETERSEN: Well, then, there's my IPv6 naivete showing there.
MR. MARTEN: What do you mean, unique local?
MR. BRADNER: Thomas, did you want to say anything else?
After Thomas, the microphones are closed.
MR. NARTEN: Yes, actually, it is a good question. So, what we have today is we have -- I forget the exact term now. They're statistically unique or almost unique, where addresses are generated to be globally unique, but it's done through -- basically, it's making up a random number. So, there's no absolute guarantee that your number won't collide with somebody else. Probabilistically, if you use a proper algorithm and don't just pick the number 1, you'll be in pretty good shape.
And, you know, the discussion that the IETF had and I believe is really at the crust here is that's not good enough for some people, because they want to be absolutely certain, kind of in a legal sense that this is an address that's been assigned to me. And, if somebody else uses it, they didn't follow the proper process in following it. So, therefore, I'm the right party as opposed to: If two people generate an address the same way at random, there's no way to resolve who really owns it.
MR. BRADNER: Okay. Did you have one follow-up comment, either of you standing over there?
SPEAKER: No. I was just going to make the point for those who --
MR. BRADNER: And you are?
MR. HAIN: Tony Hain, sorry. For those who don't know exactly what the distinction here is, and /7 was set aside out of the IPv6 space for - quotes - "non routable space". It was, you know, defined to be such. And half (of that space was to be allowed to be randomly assigned and the other half was intended to be centrally assigned. The centrally assigned half has been tabled for the moment.
So, that's the point. If we do this, we've already got the space set aside. It's just not being used right now. And this is a perfect use for it, one of the things it was intended for.
MR. BRADNER: Okay --
SPEAKER: Oh, did you close --
MR. BRADNER: I closed them. Do you have a burning thing to say? Okay, no burning going on. Okay. So, I'm going to ask who supports and who does not support this proposal. So, stick your hands up if you support this proposal as written. We've got to count you all the way back here. So, all the way up. Nod when you have a count. Okay. We have a count. How many do not support this proposal as written?
From eyeballing it, it looks like we have a plurality, not a majority, meaning most people don't seem to care, or -- or understand, or whatever. You have a follow-up comment?
SPEAKER: May I have a question for supporting this proposal with changes, because --
MR. BRADNER: Okay.
SPEAKER: Thank you.
MR. BRADNER: Yes, okay. How many believe that there's enough meat in this proposal if it goes in the right direction that you would support it with changes? Stick your hands up if that's -- if you would support it with changes. It shouldn't be thrown out with the bathwater. Okay, we have a count? All right. Thank you. Thank you.
All right, support, 14; do not support, 16; support with change, 29, and thus endeth the policy discussions.
MR. PLZAK: Thanks Scott, thanks Jason. Okay, we are at the point to take a break. Now, after the break, we have one more piece of business, that's the NRO NC report from this morning, and also we have an open mic, just a reminder the open mic is your opportunity to talk on anything that's happened so far, with the exception of anything that pertains to the business of tomorrow. So, I'm sure there are a lot of things that people will still want to talk about, so we will see you at the break -- after the break, at 3:15.
MR. PLZAK: Okay. Is Marty in the room? Ah, there he is. Right there. Okay. Martin Hannigan will do the NRO NC report. Marty.
MR. HANNIGAN: Bienvenue and welcome to Canada and I'd like to thank Teleglobe. This has been really great and last night was most excellent.
I'd also like to thank the chairman for rescheduling my presentation and accommodating my business needs.
So, I am the newest member of the ICANN Address Supporting Organization Address Council, ASOAC, and I am being indoctrinated by fire so I'm going to go a little slow here but it should be brief.
Okay. Basically, the ASO Address Council, ICANN Supporting Organization formed by the RIRs, the foundation of it all is the MOU in attachment A which is posted on our website by the way. Our function is we advise the ICANN board on addressing policy, we review global IT address policy proposals and we appoint two ICANN board of director members as well as -- and our website address is www.aso.icann.org.
Who are the ARIN region members? Well, one of them is me. The other is Sandy George over in the corner there and Louis Lee and he's right over here. The complete list can be found on the website and the address is here now.
Sandy and Louis were elected and I was appointed by the Board of Trustees. Here's the meat.
Since the last update, we engaged in the process for nominee eligibility. We submitted processes -- nominees to the board of directors. ICANN. That's -- no, I appreciate the help, Scott.
Submitted -- we submitted processes to the NRO EC to support our work. We are involved in some early awareness of IPv6 global policy. We work on global policy process that's due to the NRO EC and we appointed Sandy George to the ICANN NOMCOM this term -- this period.
On the nominee eligibility, we established a working group. We -- our secretary, which this year is ARIN -- the secretary rotates year by year and, this year, it's the ARIN folks. Secretary had made announcements to the community about the nominee period for the ICANN Board of Directors appointments. Nominees were told to respond to an e-mail address. Our Chair reviewed and forwarded the responses to our working group. Our working group basically compiled the data and verified the accuracy and ensured openness, transparency and full disclosure. We -- what we did was we created a form letter and each person that was nominee -- we nominated received this form letter and the form letter was designed to basically establish the most minimum eligibility requirement based on the ICANN by-laws and procedures of ASO ACSO. They were basically some questions that were asked, for example: Have you ever attended an RIR meeting? Yes or no. And what we did was compile this into a spreadsheet and send it out to the entire AC.
We sent out a call for responses three different times to make sure that we tried to capture all the nominees and coerced them into responding or not responding or, at least, not accepting nominations.
We completed data compilation. We verified, commented and packaged it up and sent it off to our AC.
Some demographics from this process. We had two nominees who declined the nomination. Nine accepted. One was unreachable. We did everything we could to reach the unreachable person. He was in the right domain but his e-mail bounced. We had the addresses of the nominator; we mailed him. So, unfortunately, this particular candidate was ineligible and the nominees that did accept were from the ARIN, RIPE and AFRINIC regions.
We're missing a LACNIC candidate only because the -- Mohamed Diop is from the AFRINIC region. He's the guy that -- he's the director whose term is up and the by-law specified that you cannot have two directors from the same region on the Board of Trustees.
What's left to do? We declared eligibility with the data that we compiled, we've opened a public comment period and I have the Website address coming up soon, Scott.
The interview period has begun, our AC can contact individuals directly or as in the case of the meeting, we have Dave Wodelet and Jordi Palet who are nominated here and we've all -- can, will or have spoken to each one.
And then the appointment will happen on our three May -- by three May, 2006.
And these are the candidates that were declared eligible. So, basically, what our job was in this period was to get the notices out, get the list of nominees, establish their eligibility and during this next period, decide who we're going to nominate to fill the slat.
So, we have Dave -- Dave Wodelet, he's over here. And we have Jordi Palet and he is -- he's over there. We have Uchenna Ibekwe and Envir Fraser.
Obviously, as you hear many times, we need your participation. The nominee bios in a common area are at this URL http://so.icann.org/elections/ candidates.html.
We would really appreciate it if you would go, read the bios and make comments if you feel it's necessary or required.
What's next? We have a face-to-face meeting in -- at RIPE in Istanbul and then we also have a face-to-face meeting at ICANN in Latin America.
During our face-to-face meetings, we discuss our road map for the year, any issues that may have arisen are in that period and we continue to work on processes that support the MOU in attachment A.
We'll -- well, right, we'll continue to work on internal process and we will -- especially during the next face-to-face meeting, we'll finish the board work and we'll appoint somebody on May 3rd and that's it. Any questions, any questions?
MR. WEILER: Sam Weiler. Does the ASO have -- basically have the option if you don't like any of the board nominees to reopen nominations? If you were to get in a public lack of support for all of the nominees?
MR. HANNIGAN: I highly doubt it but I can check on that and my -- the easy way to do that, I think, would be to post a comment on each one that you think that they're not acceptable and --
MR. WEILER: I'm just wondering if that was the option --
MR. HANNIGAN: -- that would be taken into consideration as you raised stepping up here.
MR. PLZAK: The problem we ran into is that the ICANN by-laws are very specific about when this guy has to be appointed and when he has to assume office.
And so, that's where the problem is, meeting that deadline is specified inside the ICANN by-laws.
MR. WEILER: Okay, then I'll revise the question. If because of negative comments on all the candidates, the SO were to fail to select one, would it have an opportunity to select one even after the deadline specified in the ICANN by-laws?
MR. PLZAK: The answer to that question is that we turn over to that numerous pile of people in the ICANN staff who are lawyers and ask them to answer the question.
MR. WEILER: I'd be interested in hearing both answers, when there's a chance.
MR. PLZAK: Okay.
MR. HANNIGAN: Any other questions? Thank you.
MR. PLZAK: Okay. Ah-ah! okay, we are now at open mic, remember the rules of the road and I will turn over to Scott to conduct the session.
MR. BRADNER: Right, we have an open mic, anybody who wants to come up and show up or pose a good question. Okay, what's -- that was a question you think is good.
MR. DELONG: Owen Delong, Netli Networks. I'd like to ask the Chair if we could possibly get an informal show of hands on seeing if there would be support or desire to look at a policy shifting the bit -- proposed in two thousand -- or -- and implemented in 2002-3 right by an additional two bits to /24 as sort of a resolution to all of the various debates around Anycast and all the other stuff for micro- allocations.
MR. BRADNER: Does anybody want to discuss that -- that question before asking -- Yes, why don't you be a little more specific since people don't necessarily memorize numbers.
MR. DELONG: Sorry, 2002-3 was the policy by which we implemented /22 assignments to end-users and before.
MR. BRADNER: And you're proposing to push it over at /24?
SPEAKER: Correct. Well, I'm considering --
MR. BRADNER: You want to know what is the sense of the room to support that. Anybody want to discuss that?
MR. BICKNELL: Leo Bicknell, ARIN advisory counsel, Harrah's Entertainment. I'm wondering if ARIN staff could present any statistics on how many allocations have been made of the /20 to 22 size where we moved that right two bits before which would help me determine if moving it two more bits would be a really bad or a really good thing.
MR. PLZAK: Leo, you make a fantastic straight man, that's part of Leslie's presentation tomorrow. So, do you need to see it now?
MR. DELONG: I would like to know just that one number.
MR. PLZAK: You want to see the numbers in terms of --
What's the percentage in rough numbers -- absolute numbers, it's not much.
So, that's one less slide for tomorrow, Leslie. Well, you want to take some more comments while we're waiting?
MR. BRADNER: We'll get that data when it comes up. Randy, do you want to --
MR. BUSH: Randy Bush, IIJ. It seems to me we're supposed to be -- the scarce resources, one of them is routing tables and this one affects that and I have heard a number of proposals that -- to solve specific problems with open up -- yes, I think it's -- what's just been proposed is a general -- let them just go forth and the hell with it.
And again, I'd like to make sure it's being used for what's really needed.
MR. BRADNER: And it's really needed for?
MR. BUSH: We're not going to go into examples, I think Anycast might very -- Anycast services might well be one but on that particular subject, I think Anycast is currently seen as a rare thing and might not remain so and if so, um, you know, how much of that are we going to do and then I go back to the PA argument on it. Leslie, I'm sorry.
MS. NOBILE: Leslie Nobile, ARIN. Since it was implemented in June of -- May of '04, thank you, there's been a 179/21 issued and 257/22.
MR. BRADNER: So it is used. Any other discussions? Any other comments? Certainly one of the ARIN's principles is to be a custodian of the address base and of the routing table space and it's always been a conflict as to how to balance that out.
If you look at 2050, there's a language at the beginning of it saying that this is technically necessary to preserve to -- to be careful of the routing table space.
MR. BUSH: There were ARIN proposals for 45 years from now?
MR. BRADNER: RST --
MR. BUSH: You're in the wrong place, Scott.
MR. BRADNER: RFC 2050, well, that's our rule set, right, that's our original rule set. So, no more comments on that, no more discussions on that?
It's hard to say we've had a full inadequate discussion of the question.
MS. TAYLOR: Stacy Taylor, ARIN advisory counsel. I would categorically not support that just by virtue of how many customers I turn up on a weekly basis who are multi-homing, so, if multi-homing would be the criteria for getting a /24, I would not support that.
MR. BRADNER: Anybody else? Well, I think we can do -- we can call a sense of the room, but because we haven't had a great deal of discussion, it'll just have to be a sense of the room. I can almost see you in the light here, they've positioned them particularly well.
MR. BICKNELL: Leo Bicknell, the only comment I was going to make is if we were going to move it, perhaps one bit would be more appropriate than two this time. It's kind of that elevator coming to a slow stop thing.
MR. BRADNER: Slowly killing the routers. Okay, well, actually why don't I modify your sense of the room to is -- I'm going to ask if folks in the room support the idea are shifting again without saying how much, and then how many don't.
So first, how many think that it's time for ARIN to think about shifting the allocation boundary to some amount at this time? And how many oppose the idea? Randy's working his hand up. I don't think we need a count on that, but I think we got the gist of the message.
I was asked at the break to ask another question, another sense of the room question, I'd like a discussion of it first, which is the question about Anycast. Should ARIN be doing something special on the question of Anycast and allocations therefore? You want to talk to that question?
MR. DILLON: Michael DILLON. The thing about Anycast is that I don't think there is a lot of discussion, a lot of material out there that explains what people do with it, so I think to most people, when they hear Anycast, they know that's something you do with DNS servers, and that may or may not be true, that may or may not be only restricted to DNS servers, and if it is, that may or may not be a temporary thing. I've often wondered whether or not ARIN should look at, and people wanting to do Anycast something is, we used to look at a web hosting provider, or beginning of web hosting providers addresses because they were providing a service to somebody else, and hosting lots and lots of services in that address space. And should we be doing something similar with Anycast? Should we be only giving Anycast addresses out to Anycast service providers who host lots and lots of services in that space? So if an Anycast provider has a /24, they don't have just one IP address in use, they have hundreds of them, but they're all different services.
MR. BRADNER: Okay, any other comments? Bill?
MR. WOODCOCK: Yes, and that just goes back to David's point that really, if there were a way of doing this with 29s, we'd be a lot better off, right? The whole point of doing 24s is to not waste a whole 22s worth of space for one or two addresses, right?
MR. BRADNER: Bill, can you -- the comment was made that not everybody knows what Anycasts are used for other than DNS. Do you have specific examples that you can give?
MR. WOODCOCK: Anycast is principally in the field used for DNS services. So, pretty much any big robust production, authoritative name service at this point is done with Anycast, and now there are public recursive ones getting going as well, plus within a lot of the backbones, the recursive stuff is done Anycast. So obviously inside backbones, people do their own IP address allocation, but for publicly visible stuff, you need to advertise it, AGP, somehow, and that means you need a block to do it from, and it may be that your entire business is advertising one or two or three IP addresses, right? So like for instance, ".ca", right, I don't know how many servers ".ca" has, some of them they maintain themselves presumably, and you know, that's probably just a couple of IP addresses. They also have an office, right? The office is not all over the world. The name servers might be all over the world, they might have 15 servers sharing two addresses, and you know, ".ca" might not be a good example, I don't know, but there are a lot of CPTLDs done this way, and a lot of PTLDs done this way. Mark Kosters can speak to this probably just as -- or more so than I can.
But basically the idea here is that we don't need to advertise a whole lot of empty space to make this work.
MR. BRADNER: We have a policy on micro-allocations for infrastructure services. Why not that?
MR. WOODCOCK: That would be fine also, as long as you're fairly liberal about what you consider infrastructure, right? I mean, if anybody who decides to set up a commercial DNS service provider is suddenly infrastructure, that's fine, but if what you're really trying to do is allow these people to not lie on their applications, and to not waste a lot of space, both of these things are things that benefit the community more than they benefit the person doing it, right? This is not Anycast people trying to get something special out of the community, this is Anycast people trying not to lie to ARIN and trying to not waste space. These are both good things, these are both resource conservation. On the one hand, staff time, and on the other hand, addresses, okay. Both good things, this is not somebody trying to get something special.
MR. BRADNER: All right, thank you. I think you were next.
MR. DELONG: I think that doing something special for Anycast is probably worthwhile. There are actually a handful of things besides DNS that Anycast is useful for. Certain types of sub-proxy registration and services, for example, which we all know are a declining market, but be that as it may. The end result is that people are going to do Anycast one way or the other. I like Michael's idea of an Anycast service provider, but I don't think ARIN can create that out of thin air, and I think that is ARIN straying way too far into setting business models in order to do that, as much as I like the idea.
Certainly if somebody came up with an Anycast service provider, model, that looked viable, I would encourage my company towards using it for what we're about to use Anycast for, but that's, again, an outside of ARIN issue. So I think there needs to be some sort of policy to facilitate Anycast services where we're going to have a whole lot of 22s being used for Anycast with false information and whatever it takes to make that happen. I have no intention of doing that and don't need to do that for my scenario, but I also see the rest of the real world too, and that is what will happen and has happened.
MR. BRADNER: Good, thank you. You had intimated earlier that there was -- that you were wanting to deploy some Anycast services, so --
MR. WILLIAMSON: Just a follow up on what both Bill and Owen said. There are definitely services out there beyond DNS, a lot of them, well, maybe more specific, I think the DNS that Bill is referring to is the DNS we all know and love for our name resolution. In addition to that, there are things like RC 3263 services, which are basically specifies a method for finding -- points via DNS, and that, for example, large VOIP providers is a clear service that would be perfect for Anycast.
And I'll echo Owen's comments, I think the policy direction I've been running down for the last eight, nine months, all stems from the fact that I seem to have a sense of ethics and didn't just lie to ARIN for a 22 up front. That would have been perhaps more expedient, but it's clearly not the right thing.
I want to echo Bill's comment that the point here is to try to be efficient, and not continue to add additional bogus information to what ARIN has collected in their templates. That's really the overriding driver for all the policy changes that I've proposed.
Some of the details are difficult to sort out in a way that's acceptable to the broad community. I'd be happy to discuss, you know, in terms of that and even who's interested, but I think there's a clear need, and I'm hoping that perhaps in the next round we'll find a way to make that work. Thanks.
MR. BRADNER: Thank you. Mark, did you want to say something?
MR. KOSTERS: I am Mark Koster from Verisign. We run Anycast and there's numbers of others that do as well for DNS, but there are plenty of other applications, as other people are saying; the question is whether or not their infrastructure to say value-added services for companies and that starts -- the line blurs fairly quickly, so we need to be careful about that.
What's really evil is when people start using Anycast for stateful services, and that I would be very reluctant to see happen.
MR. WEILER: Sam Weiler, Sparta. Scott, would you restate the question just to make sure we're all on the same page?
MR. BRADNER: I haven't raised a question. I have raised an issue. The question will really be to the -- to give advice to the AC as to what they should do with the Anycast proposal. Is it just something to be dumped because there's no interest in the space or is it something that the AC should work with the author to try and come up with something that should be brought back and forth in front of the community?
MR. WEILER: Okay. ARIN has a policy for micro-allocations for network infrastructure that's based on the service provided to the community, the community value of that service.
It would appear that an Anycast base policy makes that decision independent of the value to the community based purely on the technology. If my company were to come along off -- wanting to run its own server farm on Anycast -- it could do that even if it provides no value to the community.
I don't want to see ARIN -- other people coming up with other technologies, "Oh, we'd like to get micro-allocations because this technology is cool." ARIN should not be in the place of judging: Is your technology this tall? Oh, yes, it's worthy of micro-allocations. People can get micro-allocations to use your technology. That's not space I want to see ARIN making decisions.
MR. BRADNER: Meaning that ARIN shouldn't be doing micro-allocations or that they should be doing it for anybody?
MR. WEILER: Meaning that the decision should not be based on the technical pool used.
MR. BRADNER: On the business -- yes.
MR. WEILER: It should be based on what we have now which is the social value provided.
MR. BRADNER: Okay.
MR. WEILER: If anything at all.
MR. BRADNER: Okay. Thank you. Leslie, you have some numbers about Anycast request?
MS. NOBILE: I don't know if they're significant but I just -- we've been tracking Anycast request because we know that we've had to deny them in the past. So, in the past year and a half, we got nine requests specifically for Anycast services and we had to deny three because they needed a /24 and could not meet any other policy.
We filled six of them. We gave them /22 or /21 or /20 and what really ended up happening is we gave them more space than they actually needed because they qualified. And they really only needed a single or two single /24s but couldn't get them. So, I just --
MR. BRADNER: All right. Thank you. I think Bill was first.
MR. MANNING: Thank you. Bill Manning. A few minutes ago, we were talking about changing the minimum allocation size and there were people that were like -- wholesale, we don't want to consider that and now we seem to be wanting to consider it on a piecemeal basis.
This seems a bit incongruous to me. I think that if we want to consider special cases that it's okay for this particular range that we're going to -- golden space that you can inject /32 from this space because they're so special is one thing as opposed to saying, "And the rest of you, since you don't have these golden things, you have to -- you know, you have to carry around this extra baggage".
So, I think that it would be reasonable to reconsider what ARIN's responsibility is if we're supposed to be managing the address space. We're supposed to be good stewards of the address space. Maybe we should consider the suggestion made earlier about just delegating or changing the floor, if you will.
MR. BRADNER: A few years ago, I suggested that we change the floor to a /32 and it was -- cemented my reputation. I'll stand by that. I think that, you know, we ought to consider saying, you know, if these are really that golden, people will carry the /32. If they're not, they won't. And then things will adjust appropriately. ARIN really --
MR. MANNING: Because we don't run routers. It's kind -- it's dicey for us to couch a lot of our policy discussions in terms of what's the current routing policy -- because they will change over time.
MR. BRADNER: Okay. Thank you, Bill. Randy?
MR. BUSH: Randy Bush, IIJ. It's just I heard it too many times. I had to comment. Anycast had been induced for the last -- over a decade for things other than DNS. In certain circumstances, -- for Anycast services, i.e. using TCP as opposed to ADP has been deployed quite successfully.
So, let's not just solely focus on DNS and -- services. I said in constrained circumstances, Mark --
SPEAKER: If I can, Randy, I've done it just by --
MR. BUSH: Anybody wants the examples, come see me, I'll fly it out. I don't think we need to bore everyone.
MR. BRADNER: I have played with that -- Any other discussion? No? Yes?
MR. WILLIAMSON: David Williamson, Tellme Networks. Concerning -- logical stream, I'll support the -- you know, verbal proposal thereof, moving the floor to /32. That seems to be the logical extension of the direction we're heading. I'm all in favour of moving it to /24 as a stop count if that's what makes people happier. I'm looking for consensus on any policy. But I'm not really interested in -- my specific need that I have is not currently addressed by policy. I was trying to modify the micro- allocation policy but -- the point is correct. There shouldn't be necessarily special cases for specific technologies. Anycast is a technology that is horrible wasteful of space in the current environment. It should really fit into a /29, you know, a /28 if you're using a lot of Anycast space which would be unusual.
Things that are particularly -- should be /32. I think that's not crazy. The question is: What are we trying to be efficient with? Are we trying to be efficient with the very, you know, limited available remaining address resource or the currently very limited available routing slot resource? And the conflict between those two is something that I think is the cause of a lot of the ongoing policy discussion.
MR. BRADNER: Any other comments? All right. I would like to ask the sense of the room for giving advice to the AC. Does the room believe that we should be doing something -- two questions. It was: Does the room believe that we should be doing something special for Anycast? And as part of that, work with the author of the proposal we heard today to revise it. Or does not believe we should be doing anything special for Anycast, the technology.
So, first, how many of you think that we should be doing something special for Anycast? Keep them up. Okay. We have a count here. Okay. Now, the people who think we should not be? Oh. Some counting was being done.
Well, the sense of the room is clear that the majority of the people in the room didn't raise -- didn't express an opinion. Of those that expressed an opinion, considerably more felt that we should be doing something with Anycast than didn't -- than not. So, I think that can be guidance to the AC even without numbers.
MR. HAIN: Scott, could I ask for one further clarification point to the questions?
MR. BRADNER: And you are?
MR. HAIN: Oh, I'm sorry. Tony Hain. You made that question very generic as in terms of Anycast where the discussion had been very specific in terms of IPv4 Anycast. So, my point is was the question you just asked Anycast applicable to both IPv4 and IPv6 or was it just IPv4? I know the sense of the discussion but if you just look at the text of the question that the AC will be given, that's not clear.
MR. MANNING: Scott, may I respond? Tony?
SPEAKER: And your name is?
MR. MANNING: Oh, my name is Bill Manning and I would like to respond to you. I did in fact say the floor should be a /32.
MR. HAIN: And my immediate response to Mark was a /32 in IPv6?
MR. MANNING: Yes, absolutely, /32 --
MR. HAIN: I have no problem with that. The issue is the question going to the AC and the -- you know, the sense of the room is not clear given the discussion.
MR. BRADNER: Okay. I will ask whether the room thinks that ARIN should be doing something different with Anycast for v4 and v6. Yes? No. Transport agnostic wins by a hair. Mics are still open. Anybody else want to bring up something else?
MR. BRADNER: I think that's actually quite a -- that clarifies the question considerably from the discussion we had the other day, which was a mixture of -- I keep this from ARIN so it won't be published, which to me are two very different issues. So, asking the question of whether an end- user or others - and we'll do those separately - residential customer should be able to indicate in some fashion mechanism not to be discussed that ARIN should not publish in a public way who is or whatever else any information it has about that residential customer, that's the question you want asked?
MR. WEILER: That'll do.
MR. BRADNER: Okay. Anybody want to talk about that? Do you think it's a good idea, a bad idea?
SPEAKER: Could you say that again?
MR. BRADNER: Sure. Can a residential customer indicate to ARIN directly or indirectly that ARIN should not publish any information it has about the allocation to that customer or about that customer? I.E. you can block it from WHOIS?
SPEAKER: I see confused faces.
MR. BRADNER: But Mike is the only one that actually got to the mic.
MR. DUL: Andrew Dul, Boeing. I think this echoes back to Leo's -- last year about what is the purpose of WHOIS and that, what you collect and what you display, it may be necessarily different. And I think we need to start thinking in those terms and I would encourage us to consider collecting but not displaying.
MR. POUNSETT: Yes, I'd agree -- Sorry, Matt Pounsett, CIRA and the advisory counsel. I agree with that completely, that they're not -- what you display and what you have are not necessarily the same things. I'd probably go a step further though and say that residential data at the very least should default to private. And, I guess, personally, the only argument for publicly posted WHOIS information that gets me, that I would ascribe to is operational contact information. I see absolutely no use in contacting a residential customer about their assignment.
MR. BRADNER: Their hacked machines.
MR. POUNSETT: Yes.
MR. HANNIGAN: Martin Hannigan, Rensys. So, I have the same position that I had yesterday, that I'm basically opposed to a change in any way, shape or form. But I got to -- I wanted to make a clarification on the GEO comment I made yesterday. And so, GEO location for folks, and I got a lot of people that kind of said: How does that work? And I'll be very brief.
So, GEO location, basically, takes multiple inputs and tries to, in a simple fashion, trying -- user in. The WHOIS data is part of that sort of triangulation where, for example, if information piece A says you're in Boston, and information piece B says you're in Boston, and then it says WHOIS referenced, and that says you're in Boston, it's likely that you're in Boston.
And my specific comments related to the three digit versus five digit zip code. For those who may not know, the USPS, the first three will give you the city and state, or the postal region and state, which could be different sometimes. For example, it could be O2143 is Winterhill, Massachussetts, or it's really the city of Summerhill, Massachusetts, but anyways.
I don't see -- I understood Sam's point about how that increased the factor of privacy when you did not have the full zip code, and his example of Washington DC 2O2, 239, or whatever, where there were 27 or 29 residences. But, if you reduce that five to three, you increase the factor of privacy base, if I understand what he said correctly. And, by the way, I appreciated that presentation, Sam. Those numbers were good. I'd like to see that in three digits, but I think this is really a balance issue more than anything. And I agree people need to be private. But, if I find someone, if I am able to get a piece of information and locate you down to the city of Boston with O21 and I need to, like, for example, kill that person, I'm going to have to kill 892,000 people. So -- Thank you.
MR. BRADNER: I'm not quite sure how we'll take that last part. Okay.
MR. LOEVNER: Michael Loevner, Verizon Internet Services. I think that one of the reason that I use the WHOIS database often is for customers who have previous IP address base and they're coming to Verizon for service, to determine if they are the legal registered users of that address base or that it's reassigned to them from their ISP.
That would be information that could be lost if -- Not residential information, but information in general were privatized, including reassignment information --
MR. BRADNER: At this point, I just want to stick to residential information.
MR. LOEVNER: Okay, I didn't realize there was a clarification.
MR. BRADNER: Yes, that's -- The other question is an open question, but sticking only to the residential information question right now.
MR. LOEVNER: Okay, I'll pass right now.
MR. BRADNER: Okay.
MR. SCHILLER: Jason Schiller, UUnet/Verizon Business. I just wanted to point out that there is a policy for not having to document very small allocations. And I suspect that a lot of the residential customers would get caught in this policy. If we slid the boundary up a little bit, say anything smaller than a /27 doesn't need to be documented in WHOIS, would that cover enough of the residential customers that we wouldn't have to worry about this other discussion?
MR. BRADNER: Well, note that I was separating out what information ARIN might get about something which would be the documenting question with the ability for residential customer to block whatever information ARIN has. I think they're separate questions. And I think it's unfortunate and fabulation of those two things yesterday which led to a lot of confusion. And so, I'm not -- while that might have an effect, I still want to know the base question of whether you think a residential customer should be able to say: Don't show me.
MR. SCHILLER: I guess what I was driving at was maybe asking a different question might give you another insight into a solution to this problem's base. So, when you take a sense of the room, maybe an additional question like the one I phrased might also be useful to the authors.
MR. BRADNER: Note that, at this point, I do not believe that ARIN is required to get specific information about, for example, residential customers. That may change. Under US law, if you register a domain name, you have to give full, and complete, and accurate information about yourself when registering that domain name. Because the trademark lawyers managed to persuade Congress that this was a good thing to do.
I would not be surprised that, if that indeed became a factor in US law in the future for IP address assignments as well, considering the way Congress views, the law enforcement needs -- needs of law enforcement. So, at this point, this is more the question of making a public or not versus the question you raised of not collecting in the first place. We can have that discussion. We may not be able to have that discussion in the future.
MR. DELONG: Owen DeLong, Netli Networks. I would like to see us clean ups the marass of privacy issues with WHOIS in general. I don't feel the corporations or companies have much of a right to privacy, if any. In terms of residential customer privacy, I've changed my opinion a little bit. I do favor to some level of residential customer privacy, but I think it should be entirely and only at the choice of the customer, not because the ISP decided that they want to make a policy of residential customer records private, which is at least the current practice at some ISPs. And I think that there does need to be more discussion on the distinction between what ISPs are required to provide the ARIN and what ARIN publishes in WHOIS, and I think perhaps one possible way to address that is to add a flag in the SWIP or other template of what is presented to ARIN that says publish or not, and fill that in appropriately based on the customer's desire with regard to that record.
Certainly I would suggest that the default, unless otherwise expressed by the customer, should be publish and not not publish, but that's my own opinion.
MR. BRADNER: Okay, thank you.
MR. BICKNELL: Leo Bicknell, Directory Services whipping boy.
I have some experience in this area. Specifically, to answer your question first, personally, I absolutely support the question as asked, that the information should not be public for a residential user. I think privacy is very important.
MR. BRADNER: The question that was asked was whether residential customers should be able to specify whether it's public or not.
MR. BICKNELL: Yes. That would be acceptable. Having it simply not be public would also be acceptable to me. More interesting to me when I hear these discussions, and I've been part of a lot of them, is we seem to be very passionately talking about the unimportant piece of the problem in that we don't actually know how many residential users there are in the ARIN region. I have not been able to find anybody who can give me a good number of that, because you don't know, for instance, if a cable modem user gets a DHTP address, then they get one, they may get five. We have no way of knowing. So, we can make a guess based on addresses that have been assigned, but we really don't know.
But when we look at the ones that actually have WHOIS records, because you have to have the static assignment of a /29 and larger size, what you discover is that somewhere between a very small and an infinitesimal percentage of the residential users are listed. And I don't have a number because we don't have the total, but it would not at all surprise me if we got those numbers to find that perhaps one in 10,000 residential users was actually listed.
And so, as we had this discussion, I take two fascinating things away from this: We have people like Martin standing up and saying he's using us for one in 10,000 users, or we have a situation that, as time marches forward and users get larger and larger allocations, I assume they're going to want to use more boxes, we will have all of those users in the database. And those are really the two points we're arguing about. Is it useful to have this very, very small amount of data, and if it's not and we want more, then are we prepared to have every residential user in the US listed in the database, because that's the end goal, right? Everyone will eventually have Internet, they'll have a /29 or bigger, they'll be listed. I personally don't think that's a good thing for ARIN or for privacy.
MR. DILLON: This whole idea of geo-location really needing this data, this is sort of one element of a thread that goes back quite a while, even back when I was proposing policies related to the scope of the WHOIS directory. Researchers sometimes use it for -- and I'm not just talking -- I'm talking about people in the research community, academic community use it -- like to use this data to identify how the addresses are used or where they're used, or whatever. But there is a way that we could meet those needs without disturbing individual people's privacy, because I think in most cases, this type of geo- location, or research could just -- work just as well if they could identify a larger aggregate and the location, the city in which it was used, or in which it was being allocated.
So rather than identifying the location of each residential customer in each small business that is using a small block of a larger aggregate, why can't we, the ARIN members, supply say every quarter an entire listing of all of our address space and which cities we're using it in. Most of us have all this stuff in the database, so generating a report like that would be fairly trivial. And the data would then be able to go and be published by ARIN in a form that people like Renesys could use for geo- locations, researchers could use for their research, and then all the name and address stuff, which is irrelevant anyway, wouldn't be there.
MR. HANNIGAN: So, the point isn't that a /32 would, not being able to geo-locate it, would break anything. The point is, in my opinion, this is a precedent. So once we go ahead and eliminate anything useful from /32s or 27s or 29s, the next step is when we get to the business policy, so what if we did it for the residential folks as well, and now we have two different data sets, some empty, some not empty, et cetera, and you know, with the name missing, I just -- I really don't understand why there's this level of confusion, but Michael is right, I mean, we can geo-locate on larger aggregates, and we do.
MR. BRADNER: Last comment on this.
MR. WEILER: As often as privacy aggregates have to fall back to slippery slop arguments to advocate some of their positions, I'm very amused to hear a slippery soap argument used to advocate we should be publishing information.
MR. BRADNER: Okay. So we've had a full discussion, I think.
I will ask the question. Note that the question I will ask is whether the residential customer should be able to directly or indirectly indicate that ARIN should not publish information that ARIN has about that residential customer, not whether ARIN should have any information about that residential customer, because I believe that's a separate, different question.
So how many people believe that a residential customer should be able to indicate directly or indirectly to ARIN that any information ARIN has about them should not be published? We're not doing a count here, we're just doing a sense of the room. And how many believe that that's not needed? You're a big man, and two hands I guess. Okay, the sense of the room was overwhelming, that residential customers should be able to do that, assuming ARIN has any information about them.
MR. WEILER: Thank you, Mr. Chairman. I do have a second version of this, which is, given that 2006-1 is a very incremental change to existing policy, it changes one little thing, it does not address the ambiguity about whether ARIN gets the data, it doesn't discuss moving the boundary, it doesn't change the default from user privacy on, off, or other. It doesn't set a default. Is this incremental change by itself a positive one or a negative one? That is the question I'd appreciate you asking.
MR. BRADNER: So you would like the sense of the community for the benefit of the AC to know where the community thinks that 2006-1 is something that's worth working on --
MR. WEILER: No. Is the incremental change as proposed --
MR. BRADNER: Is the incremental change as proposed something that should be done?
MR. WEILER: Beneficial or not, yes.
MR. BRADNER: Beneficial or not. Anybody want to discuss that?
MR. DELONG: Point of order on that, I believe we voted on it earlier today.
MR. BRADNER: We voted on whether the policy as written was -- how many people were in support of it or not, and --
MR. DELONG: Right, and he's now asking how many people think that the incremental change proposed by that policy is a positive one versus not. Presumably everybody who thought it was a positive one voted for it, and everybody who thought it was not voted against it.
MR. BRADNER: You want to clarify the reason for your question?
MR. WEILER: Yes, I do. I heard -- we had a few voices speak in opposition to the policy yesterday. Some of them spoke against it for different reasons, including that it didn't go far enough, it didn't set a default of user should get privacy or it didn't --
The reasons for opposing it yesterday could have been many. And the question asked yesterday, I thought, was should we move forward with this proposal as is or not?
MR. BRADNER: We didn't ask the question of this early thing here.
MR. WEILER: In some ways, the question asked yesterday is: Is this the idea of proposal or not? And very clearly, it's not, there are ambiguities left unaddressed, the question is: is this change a good idea or not?
MR. BRADNER: Is that the right question or is it: should the AC work with the author to try and continue to work on this or not bother?
MR. WEILER: That's not the question I would have asked.
SPEAKER: As an AC member speaking for my own sense, that's the question that I'd like answered.
MR. NARTEN: So, Thomas Narten, I may be jumping into something I don't want to jump into but I think what you're trying to get at is -- you know, the question we should hold off on doing anything in the space until we get the right policy figured out or should we -- would it be sensible to go ahead with this one knowing that its flaw has limitations and continue to work on the problem going forward, is that what you're trying to sort of get at?
MR. WEILER: Not necessarily but I would take that question, I'll adapt my question to be the one Thomas asked.
MR. BRADNER: Well, I got that question to be the same gist that the one that I asked which is: should the AC work on this proposal or should not bother. Because it's a practical question for input to AC.
MR. WEILER: I would -- I'm looking for something different which is: we know this proposal is imperfect, it makes a very small change which may not go far enough, may go too far.
The question is is it better than what we have now, should the AC adopt this proposal as written right now knowing full well that some of the things raised in the last couple of days could be addressed in the next policy cycle.
MR. BRADNER: Well, I think we did have a vote on whether the AC --
MR. WEILER: Okay.
MR. BRADNER: -- should adopt this proposal as written.
MR. WEILER: Then I withdraw the question.
MR. BRADNER: Yes. But I think that the question of whether the AC should try and work on this proposal is not a bad question to ask because I don't think that question was asked yesterday.
MR. HANNIGAN: I think that's a good question.
MR. BRADNER: Okay. So anybody want to discuss whether the AC should work on 2006-1?
MR. HOWARD: As I recall and somebody else may have better numbers than mine, the count taken yesterday was almost exactly fifty-fifty for and against, is there any reason to believe that the AC would not work on this proposal given that count?
MS. AZINGER: This is -- oh, I'm sorry, Marla Azinger, Frontier Communications, I'm speaking as a AC member.
Historically, when we have something that's a split vote and we have different suggestions, how to try and find a balance in the policy, we will ask the author, if they wish to work with us on rewriting it, to find a balance.
If they say no and -- for somebody else that wants to set forth, we'll take it and try and find a balance policy, otherwise, sorry, the main point is with -- the way it is right now, it's safe to assume we will move it forth and try to adjust it and not totally kill the policy.
The author could also ask us to totally just abandon the policy which is another move we can do. If they request us to do that, we will but that doesn't mean somebody else can't write a proposal to create a balance policy and have that at the next --
Also, he could do a petition to just keep it the same way he wants it and that's another way we can go about it but the way it is right now, we all voted, we had a fifty-fifty split basically, the AC will look at it and most likely, we'll say, everybody has a fifty-fifty, there are suggestions to balance it, so let's try and balance it and then we'll see where it goes.
MR. BRADNER: So it sounds like there's no question here.
MS. AZINGER: There really is no question at this time.
MR. BRADNER: Anybody have any other things to bring up, the microphones are still opened.
MR. KOSTERS: So I have a question for Sam because Sam and I talked about this.
MR. BRADNER: And you are?
MR. KOSTERS: I'm Mark Kosters, AC member. Well, this actually came up because you wanted to actually -- you wanted to drop it if it wasn't going to be accepted, are you willing to change your position now?
MR. WEILER: Marla spoke about writing a balance proposal, I think that before we took the first vote here this afternoon, I was unclear on how to do that because most of the things I heard yesterday about balancing the proposal had to do with number of bits of postal codes.
And I saw her going down that road, giving the number of jurisdictions involved and the number of corner cases, it's being an intractable raffle.
The poll that we took earlier this afternoon suggests to me that we're actually on the right track as far as suppressing all the data but there's something else we need to tweak, I hope that's what I'm saying in the rough shorthands we did this afternoon.
I'm not quite sure what it is we need to tweak in that case but yes, I hope that we'll come to something that we'll get a majority supporting.
MR. BRADNER: Okay, I think that -- I think that answers the question so -- so you're not going to abandon it?
MR. WEILER: I do not plan to abandon it.
MR. BRADNER: Okay, thank you.
MR. WEILER: If the AC thinks that we will be unlikely to -- this policy and should choose to abandon it, that's certainly an option --
MR. BRADNER: Yes.
MR. WEILER: I believe they have.
MR. BRADNER: Okay, thank you. Are you heading towards the microphone? Yes, you are.
MR. DA SILVA: Yes, I am. Ron Da Silva, Time Warner Cable also, member of the AC. Regarding what the AC will or will not do, we will meet this evening to discuss what we believe the consensus is on all these different proposals and we'll report on that tomorrow.
To expand a little bit though on Marla's submission of the process, when there is a split vote, clearly the process currently says that if there isn't a consensus, then there's no real grounds to move a policy proposal forward.
However, the reason why we generally ask for some straw poll of the room, if there's interest in any particular policy that has some split vote, if there's some work that should be done there that's motivation that typically the AC will use to instead move it into an editing process of a way to capture, what the essence is and get it to a state where we can get consensus clearly.
MR. BRADNER: Well, in this case, where there was a split vote and pretty strong expressions of interest in both camps, or disinterest, I would think you'd already have a sense of this community that there -- at least a good chunk of it thinks there's something there to work on.
MR. DA SILVA: Exactly.
MR. BRADNER: Back microphone.
MR. BUSH: Mind to change the subject?
MR. BRADNER: Please.
MR. BUSH: In the interest of creating serious trouble in the universe, would people encourage Geoff, George, myself to make more trouble along the dimension of formal crypto work on resource allocation towards long term secure routing and verification of allocations?
MR. BRADNER: So you're asking for a sense of the room of whether the -- this community should encourage the work that you've been encouraged -- you to continue to work on the problem you've been working on?
MR. BUSH: And then is there an interest in -- also the people have constructive comments on, you know, what flavor of Kool-Aid we should be drinking.
MR. BRADNER: Okay, just as a note, I'm planning to ask the ARIN meeting tomorrow whether the meeting believes that ARIN should expand resources in this space but I think it's a reasonable question to ask here now whether this community thinks that it's worth to encourage continued work in this space and to engage the ARIN community as the work progresses. Did anybody want to discuss that?
MR. BUSH: And also and the actual content comments on work would be greatly appreciated.
MR. BRADNER: Technical comments welcome if present.
MR. DARTE: I sort of have a tangential question of the people who are working on this, it's -- I heard them speak yesterday about the development of open source tools and such for this work and I didn't hear whether they were actually encouraging people to join that open source development effort or not.
MR. BRADNER: Randy, do you want to speak to that or Geoff?
MR. HUSTON: Geoff Huston, APNIC. Certainly, I can respond in terms of the trial work that APNIC is doing that we are basing ourselves on existing open source software.
We have found some issues with that open source software and it does need some modification in order to -- 377 certificate extensions.
It is certainly our intention, absolutely, that code work we would do would be placed into the open source arena. So, our intent here is to create as much open source certification software as we can possibly encourage and certainly in the spirit of multiple implementations, if there is interest in other areas in doing this open source work, certainly that would be, I think, a very, very good thing to do.
MR. BRADNER: I think Bill was also asking whether he could help with the project that's underway.
MR. BUSH: With the nano surgery that's being done at the moment, that's not clear to me. As the components get in place and we start getting near building applications and tools for ISPs and so on and so forth, I would certainly hope so because I can't see -- the -- currently playing is feeling very missioned in that dimension and I think -- the many solutions -- What I worry about though is -- I think there will be two modes -- I've sat here for 10 years and I've been in router configuration and I know there are handful of ISPs and series router configuration software and that's all proprietary. Sorry, by the way, I forgot to say I'm Randy Bush from IIJ.
And so -- maintaining open source as far as possible in these dimensions is desirable but I can also see that as folks take a tool kit and start bearing it into their processes, they're not going to want to consider that open source. So, how that's balanced will be fun. But I think, you know, demo apps and people doing open source implementations for tool kits for ISPs, et cetera, et cetera. It'll be wonderful. It'll be wonderful.
I think, uh -- there's a lot of stuff and I don't think anybody wants the monopoly on it.
MR. BRADNER: Okay. And you are?
MR. WOODCOCK: Bill Woodcock.
MR. BRADNER: For the people out there in voice land.
MR. WOODCOCK: It seems to me like there are sort of three parts to this problem. The first part is figuring out what belongs to whom and what contact we have with them so that we know who it is that is getting something signed.
And we haven't heard much about that but that's probably because it's really dull gregarious work and it will take a long time.
The middle part, we've heard quite a lot about which is the swapping x.509 fairy dust on everything and making crypto people happy and that's fun and I'm sure we'll hear a lot more about that.
The third part is implementing this in routers, one way or another, so it has some practical effect. And we haven't heard much about that yet and that's not dull gregarious stuff. That is in fact much closer to all of our hearts I think. And I'd be very interested to see this work focus a little bit more on that than on the crypto or rather have more visibility of that because that's the part that, I think, I'm probably more prepared to understand.
And I think the big question that I have is it's seems like there are two poles, right? One pole is something that looks a lot more like an RIR clean-up where, you know, stuff gets assigned and so forth and then you have a tool set that sits on a box that goes and gets data from several sources, authenticate it, builds filters and puts the filters into the router or something kind of like that and then the other end of the spectrum is you have code running in the router, in your router operating system or in a coprocessor or whatever that is looking at inband cryptographic communication within BGP or something and operating on that. And those seem to me to be quite different models and I'm sure you guys have talked all this out and I'd be really curious to hear more about what's going on there because it seems like most of the conversations focused on the crypto.
MR. DILLON: Michael Dillon, BT Radianz. This whole thing -- yes, it seems to be focused a lot on crypto. It seems to -- it's all kinds of incomprehensible stuff about certificates and signing and the ins and outs of stuff that I, as a non-crypto person, really don't need -- normally need to deal with and I think most people in the room are probably in the same position. Most of the people who would be involved in making policy really are not crypto experts.
One question that continually comes to mind when I hear this stuff is: Why X.509 certificates when in this industry PGP, public key signing seems to be the standard way of doing things? And of course, over here, on the side, we have DNS SEC which is different but -- why are we coming up with something that's different again? And I don't expect that to be answered here, but I think it's a question that should be answered in any kind of an overall presentation of: This is what we want to do on router security and we've made a crypto decision here and this is why we didn't choose PGP or so on -- or maybe they will reconsider. Who knows!
And the other thing is this whole thing seems to be -- dive right into the -- what seems like a -- sounds like a research project because even the crypto experts are very unsure about what works and how to do things and haven't made various decisions along the way and -- it all seems rather -- not only just hairy fairy but rather amateurish, if I can say that.
I would like to see a statement of what we do today and how we -- how people intend to change that. What we have today because we have some means of router security today and that can be ascribed and somebody can draw diagrams, show communications path and relationships and so on and what bits of it do we want to change and why do we want to change them and why do we want to apply crypto to this section and that section, and so on. I think if we did that, a lot more people would understand what this is all about and, in fact, it might even turn out to be an easy sell.
MR. BRADNER: Geoff, do you want to -- or Randy, whichever was first here.
MR. BUSH: Randy Bush, IIJ. Clearly one component of this needs to be education as the knowledge base in computer science seems a little weak in some of this audience and if they have to go through the exercise to understand the proposal, then that's necessary. And I think it's very worthwhile, one of ARIN's chartered goal is education.
For the majority of the membership and the majority of the use as the current plan is, understanding cryptology -- cryptography and even using it is unnecessary.
As I tried to hint yesterday, as the panel did, and I guess we need to do more is most people will go to the ARIN website and push a couple of buttons and get the allocation. The difference is that instead of a text bunch of stuff that -- there's something that is formal in the computer science sense and mathematical sense verifiable. And that should reassure people.
I don't think though, as Bill Woodcock suggested, we should be going into protocol design to how routers work. I think that's a little beyond ARIN's reach. But having rigorous methods of storing our data and being able to verify the data for which we are by charter responsible probably is a worthwhile effort.
MR. BRADNER: Geoff, you were next in line.
MR. HUSTON: Thank you. Geoff Huston, APNIC. I'd like to respond a little bit here Bill to your question around, you know, how would you use it? And use cases is certainly something that has occupied a fair deal of our attention. How would you use it?
MR. HUSTON: We're actually thinking about what's being used today and how could this make life cheaper and easier, more verifiable, and more accurate. So, it's not as if we're going to design open source tools that put, if you will, filters into routers, absolutely not. But, in looking at the front end from an ISP's perspective, a customer says: please route this prefix. The tool would be -- In other words, allowing the person with the prefix to be able to sign a request and allowing the ISP to use a tool to validate that signed request. After that, it's in their existing processes as to how they handle it. So, it's not as if we'd reinvent how they handle it. It's that request that we would look at tools to enable someone to say: please generate a routing request with my signature. Bang, up it comes.
MR. WOODCOCK: Does that mean that you're assuming that this would be done out of band and not out of the VP extension?
MR. HUSTON: Let me finish.
MR. WOODCOCK: Okay.
MR. HUSTON: The next tool that we have around are Internet routing registries. And we'll be looking at tools to be able to say: Can I sign a submission to a routing registry? So, again, what would you need to do to be able to say: Here's a block of -- routing registry, oh, sign it, click? And then, from the other side, looking at an admission tool at the routing registry, say: Do the signatures next. So, simple additions to where we are now.
The bit about the routing protocol is actually standardization work. And the good news I suppose is that the IETF, in looking at standardization have entered a main routing protocols with security, has made some headway, but not complete. At the last IETF meeting, the RP6, the routing protocol security working group did manage to come to a consensus that they had rough consensus over origination. They did not have rough consensus over path validation.
On the strength of that, there is a new working group that's currently being proposed to the ISG called SIDR, S-I-D-R, on security into the main routing. The initial charter is actually to work on bits that RP6 has actually agreed upon, which is the area, so far as I can tell, of the structure, of the inputs, i.e. certificates, and on authentication of origination information.
The bit where we're still waiting is to understand what are the requirements for path validation. So, you can expect that if CIDR were chartered, it would be looking at standardization of origination information at this point.
MR. WOODCOCK: And do you feel that there's enough operator participation in that process to give them feedback as to whether this is a valuable path to take?
MR. HUSTON: RP6 has had a lot of the input from operators, theoreticians, researchers, and others. And I think part of their sole searching on path is that path is a damn hard problem when it's combined with operational realities as to the work load. There is however, I think, an adequate amount of input that says origination is something we can roughly agree upon.
So, RP6 still has a problem to work on. And we won't be standardizing anything until they come to a consensus. Origination, however, is looking much stronger as a standardized means of input of trust.
MR. WOODCOCK: And just to be clear, not the need for authentication of origination --
MR. BRADNER: Hello, you at the microphone controls!
MR. WOODCOCK: But the need for having that be done in band in BGP?
MR. HUSTON: The need for standardizing the inputs to that, I'm not sure at this point how far we would get with consensus on which way it could be carried in BGP. But we are deeply down an IETF issue at this point. I simply wanted to point out from the standardization community's view point origination is a here and now issue where standardization activity is forming.
MR. DELONG: Owen DeLong, Netli Networks. To address some of Michael's comments, one of the reasons BGP wouldn't be a good solution for this is that BGP is moderately good at verifying the day chunk of text originated from someone who has control of a particular private key. But it is not good for verifying the association of multiple things, such as an IP address, an autonomous system number, and the person who has authority over the two of them. That is what x.509 certificates theoretically do. And I'll leave it as an exercise for the consumers to how well x.500 works for anything like that in general.
MR. BRADNER: Okay. More? Okay.
MS. MURPHY: Sandy Murphy, SPARTA. I've heard a couple of mentions of the word crypto with the word scary as undertext. The presentations that have been put forth about PKIs and x.509 certificates, I looked at Randy's presentation very quickly, he has the word "sign" in there. And I believe that Steve Kent's presentation actually had the crypto algorithm that would be used in the signature. That's as heavy as they've gotten into cryptography.
Don't get blinded by that fact. There's a very important issue here of how you decide who is authorized to be the prefix holder. It's being encapsulated in x.509 certificates. And there's a structure of how that authority is represented and what constitutes passing the authority, delegating it on to someone else, that kind of mirrors the number allocation and suballocation.
But that aspect of it has nothing to do with cryptography. And it is an incredibly important aspect of the problem, of how you decide it. And it people here who understand the allocation of prefixes and how much authority you're passing over when you suballocate to a customer, who know what that authority structure should be and should not be -- should not turn their minds off when they see that it has something to do with cryptography.
The authority structure doesn't have any cryptography associated with it. And that's something that needs very careful focus. People should pay attention to it a lot, and comment, and screen, et cetera. Okay?
MR. BRADNER: Okay. Any other comments? So, Randy asked me to ask this community whether we should encourage him and others who are working on this to continue to do so. We've heard a number of different aspects of that. The last one is particularly important. A lot of what is there is encouraging ourselves to work on aspects which have nothing to do with security technology, it has to do with processes and understandings.
So, I'll ask the question. How many here think that -- I'll ask whether people think that this is something that we should encourage. And I'll ask that -- if it's something you think we should not encourage -- But we have the treasurer. Is he running to the microphone? No, he's running to the bathroom. Okay. I'm glad I kept that low profiled. Okay.
I'd like to ask how many here think that this community should encourage the work that Randy and others are doing. And how many think that it's not worth encouraging? I sense the room is very strong. Thank you, Randy. And thank you, Geoff. And, the rest of you, keep doing it. Randy is being -- Well, there is an interesting image, Randy as a groupie.
I think that's about the time we should close now when we have that image in mind. And, so, I want to thank you for your participation in the open mic. And here is Ray.
MR. PLZAK: Thank's Scott. Let's see. I'm not going to ask any questions before the room. Well, I'm going to do that one time, I think. Gee, I got to the end of the slides already. Great. Wo! As I said, all the room, what do you think about these guys? Okay. One final reminder on the wireless cards. If you want, they're yours, if you don't turn them in, you'll pay for them. Network shutdown will be at noon tomorrow after the members meeting. So, just a word. Remember meeting surveys and, Sam, this is the other raffle. And you can only enter once but two chances to win and it's an iPod nano.
So, the registration services help desk is open until 18:00 which is 6:00 p.m. Cyber Cafe is open until the same time. Members' meeting starts tomorrow with breakfast at 8:00, same place as it's been the last two mornings. Meeting will begin at 9:00 in here which reminder: tomorrow you'll find out maybe a little bit more about who are these guys because I sure can't tell you. Susan knows everything. Yet, a couple might chance to pump her for information so -- she apparently hasn't told anybody anything yet.
So, with that, enjoy the evening. The AC and I and a few other people are going to have a fun evening ourselves, it looks like. And we'll see you all tomorrow morning bright and early.
(Whereupon, the PROCEEDINGS were adjourned.)