APNIC 32 - Destination::IPv6

Transcript - Policy SIG


Due to the difficulties capturing a live speaker's words, it is possible this transcript may contain errors and mistranslations. APNIC accepts no liability for any event or action resulting from the transcripts.

APNIC 32 Conference
Wednesday, 31 August 2011
11:00 (UTC +9)
Policy SIG

Sunny Chendi: Good morning and welcome back to APNIC 32 Conference, Policy SIG session.

We have a long agenda in Policy SIG this time because we moved the NRO NC elections from the APNIC Member Meeting to Policy SIG.

I would like to remind you once more -- I know the previous chairs have reminded you -- when you approach the microphone, please speak clearly, state your name and affiliation.  Affiliation is optional.

We have one remote hub joining the session from Cambodia, so we have some participants in Cambodia who will be watching the proceedings.  I would like to request you all to appreciate their comments.  We have a good video and audio link with them, as of now, and we will try to maintain that link with them throughout the session.

I would like to invite Paul Wilson, Director General of APNIC, to explain about the NRO NC elections.

Paul Wilson: Thank you very much, Sunny.  Good morning, everyone.  I have been asked to run through the election procedures for the NRO Number Council election which is happening today, so the procedures are clear to everyone in the room who may be participating in the election today.

The procedures that I am going to describe, there are quite a few slides, and I will get through them fairly briskly.  If there are any questions, there will be a chance to do that.

The procedures are based on what we have done in the past.  As usual, that is based on a history of NRO elections as they have been held and documented in the past, and some changes that were made 12 months ago for the last NC election that was held.

I will be talking about online voting, on-site voting, what is the counting procedure, how the results are declared, dispute resolution, and there will be an opportunity for candidate speeches after that.

The Number Council is defined by the NRO MoU, the agreement amongst the NIRs that forms the NRO.  There are three members of the Number Council from each region, one of them being appointed by the board of each RIR, two of them being selected by elections like the one we are having today.

Each RIR defines the details of its own procedures and these are documented on the NRO website at the URL that you see here.

This presentation is on the APNIC Meeting website at the moment, so if anyone wants to look -- if you do not have time to note the URLs, you can see the presentation details on the APNIC Meeting website.

The APNIC procedure for electing our NC members have been determined by the APNIC EC, as previously explained in previous meetings.  The APNIC EC appoints one member annually for a one-year term.  Two Members are elected during the APNIC Meeting, and we are conducting that election today during the policy session, because this is a community event, it is a community election rather than an APNIC Member election.

There is one member elected through the process each year for a two-year staggered term.  We are just electing one member today, and that member will serve for two years.

This election is not governed by the APNIC By-laws but it is being conducted, as decided by the EC, in the general manner of our normal APNIC EC elections under the by-laws and the procedure.

This election, as I say, will elect one candidate to serve until the end of 2013.  We have a strict schedule of events that lead up to this election, so there was a call for nominations which closed according to the schedule on 28 July, and the announcement is linked here.  There is both on-site and online voting available, and that is explained in more detail in the second URL you see on the screen here.

This election has an individual serving as Election Chair, and that individual is appointed by the APNIC EC to serve in this capacity, with the responsibilities of overseeing the process, appointing the scrutineers for the election, resolving disputes and declaring the election result.

The Election Chair for today is Prof Kilnam Chon, who is a well known individual here in the Korean Internet community.  He has very kindly agreed to serve in this capacity today and I will be handing over to Kilnam to open the election after I have finished with the slides.

There are staff positions appointed by myself as the election officers.  They simply administer the process, the call for nomination, the on-site and online voting, supervising the ballot box, performing the counting of votes, and reconciling with the online voting results.

So the election officers, as they have been for some time, today the election officers are Connie Chan and George Kuo from APNIC staff.

Election tellers are those who are also appointed by me from the Secretariat staff responsible for supervising the ballot box, validating and counting of votes, and reporting the results to the Chair.  Annaliza Mulingbayan and Guangliang Pan will be serving as the election tellers today.

The scrutineers are those who are appointed by the Election Chair to observe the counting process, in fact the whole election process.  They are entirely independent from any APNIC member or candidate.  They also do not vote.  The procedure is that those election scrutineers are selected from the staff of other RIRs, of ICANN, or ISOC, who are here on site.  They observe the election tellers, without touching or handling the papers, and they notify the Election Chair in case there is any anomaly or issue identified in the process.

Online voting has started and finished.  It ended at 9.00 am, Korea time, on Tuesday this week, 30 August.

The online voting is accessible to APNIC member organizations via MyAPNIC and each APNIC Member organization is entitled to just one vote on MyAPNIC.

I will stress that these are member organizations voting, as distinct from individuals who vote here in this room.

The system -- we are familiar with it by now -- preserves anonymity of the vote, the voting record, it stores a record of who has voted and a separate record of the votes cast.  The reports are available in the counting process today, to be examined by the scrutineers.

On-site voting will start shortly.  It will be announced by the Election Chair.  It will end today at 4:00 pm Korea time, Wednesday, 31 August, and, in accordance with procedure, that ending time is announced here; whether or not the meeting itself ends at that time, the ending time for on-site voting will be 4:00 pm.

Each registered APNIC 32 attendee is entitled to vote as an individual.  So you are entitled to a ballot paper, a single ballot paper, as a registered attendee to this meeting here.

The on-site voting is conducted as follows: there is a voting desk just outside the meeting room here today.

It is placed there after the opening of on-site voting.

The box is supervised by the tellers at all times and any inquiries need to go to the election officers who are there at that voting desk.

There is a single ballot paper for each individual, as I mentioned.  They should have very clear instructions.  But, just in case, I will stress that the ballot paper will be deemed invalid if you do not mark any boxes, if you mark more than one box, if it has an ambiguous marking on it or if it does not bear a validation stamp which has been manually applied to each paper.

There is an image of the paper that you should have received or that you will be entitled to receive today.

The counting procedure, supervised by the election scrutineers at all times, is carried out by the tellers.

They check all ballot papers, they use tally forms to record and verify the check marks that they count.

There are always multiple tellers involved with validating and recounting the votes.

The voting reports from the online system are printed during the vote counting process, and they are available to the tellers, of course, for counting and also to the scrutineers.  So the total votes for each candidate is simply the total of online and on-site votes that they have received.

The result will be declared by the Election Chair, and that declaration will include the name and vote count for every candidate, the total number of valid and invalid ballots.  He will also advise of any disputes and the resolution of those disputes that may have occurred during the process, they will also disclose any communications from the scrutineers about any anomaly or issue that they have detected.

If you wish to raise a dispute, any complaint at all regarding the conduct of this election, that must be lodged in writing with the Election Chair.  They need to be lodged no later than one hour before the scheduled declaration of the election.  So that is by 3:00 pm today.

Notices of dispute can only be lodged by members through their authorized voting representative.

The Election Chair is responsible for resolving those disputes according to his or her discretion and judgment.  As I have said, the Chair will provide a notice of any such disputes and the resolution of the disputes when the result is declared.

That is it for the election procedure.  I am sorry if I have taken a little bit of your time to explain that, but it does seem to be important that we go through those details.

I would like to now ask Prof Chon to come and take over the election process, to open the election for voting.  I think first we will have the opportunity for the candidates in the election to speak here.  Thank you very much.  Thanks again, Kilnam, for your service.

Kilnam Chon: We are having the election today.  First, let me introduce the election scrutineers who have been nominated.  Will you stand up.  Vymala Thuron of AfriNIC, Sofia Silva Berenguer of LACNIC, Elise Gerich of ICANN and Ping Wong of the Internet Society of Hong Kong.  Would you stand up?  You have to do the work today.  Thank you.

Next, any dispute you have to make one hour before the declaration of the winner.  The declaration of the winner will be done around 5:30.  So if you have any dispute, you have to make it by 4:30 or before.

Let me introduce the candidates.  Out of seven, we have only two who are here today.  To those two people, we will give about 3 minutes each for their speech.

Shall we start with Nilesh Prasad.

The second person is Andy Linton, who is here.

After I introduce the seven, would you be ready to make up to a three-minute speech.

The third person is Hanumanthappa.  The next person is Kiran Kumar.  The next person is Ren-Hung Hwang, who is here.  Please be ready for a three-minute speech.

Tomohiro Fujisaki is here.  Please be ready.

The last person is Decka David.

I will give the three persons three minutes each.

Andy, would you like to start?

Andy Linton: I know many of you here, but I don't know all of you.

I was given, I think, the honour of being involved in this process during this year, there was a vacancy on the NRO, and I was asked to fill the vacancy.  I have been doing it for about six months.  I'm actually just starting to understand what's going on.  So I would like to continue that work and do that work on your behalf.

It's an interesting time to be involved with the NRO and the ASO because our role with ICANN is one that I think will develop over the next few years.  So I would appreciate your support.  I'm not going to keep you too long on this.  Thank you.


Kilnam Chon: Thank you.  Next is Ren-Hung Hwang.

Ting-Yun Chi: I am sorry, because Prof Hwang is not available right now, so I just introduce Prof Hwang here.  Is that OK?

Actually, Prof Hwang has worked in the Chung Cheng University in Taiwan for 20 years, and his major research is network routing, QoS and the next generation network.

He has also worked for the allocation network for more than 15 years and he has helped Taiwan to build the next generation network and provide IPv6, IPv6 relay work.  He also joined TWIP and the protocol community in 2005 and he joined the APNIC Meeting as a delegate of TWNIC in 2009.

He would like to share his time and energy to serve you and share with APNIC.  Thank you.

Kilnam Chon: Could you tell me your name?

Ting-Yun Chi: My name is Ting-Yun Chi from Taiwan.

Kilnam Chon: If you have any questions for Mr Hwang, please ask him.

Next is Tomohiro Fujisaki.

Tomohiro Fujisaki: Good morning, everybody.  My name is Tomohiro Fujisaki from Japan.  I have been joining the APNIC Meeting for 10 years and during these 10 years I have been involved in APNIC activities as a Co-chair of SIG and the APNIC Program Committee, and as an APNIC-appointed NRO EC member.

As we know, we are now facing very, very important and big changes, such as IPv4 exhaustion, necessity to implement IPv6, and we are having many, many policy issues.  I would very much appreciate it if you all give me a chance to tackle these problems as NRO.  Thank you very much.


Kilnam Chon: Before we start voting, does anybody have any comments to make or questions?  Now it is open to the floor.  Anybody?

OK.  Then we will show you how to do the voting.

Here is the box.  It will be outside of this room.  You will get the card at the voting desk near the entrance here, and put it in the box here, until 4:00.  We close at 4 o'clock.

Then we do the counting and we declare the winner around 5:30.  If you don't have any more questions, let's start the voting now.  Thank you.


Paul Wilson: There was just one aspect of the process that I misreported in my summary.  The close of voting here is 4:00 pm, the declaration of the result is 5:30 pm.

Therefore, as Prof Chon correctly reported, the dispute deadline is 4:30 pm today, not 3:00 pm, as I mentioned.

Apologies.  Thanks.

Sunny Chendi: Thank you, Paul, and Prof Kilnam Chon.

I would like to invite Prof Kilnam Chon again back to the stage to run the SIG Chair elections.  We have the Chair and Co-chair elections in this session today, and Kilnam Chon agreed to run the election as well for us.  We much appreciate your support.

Kilnam Chon: OK, one more.  This is far more difficult.

We have to elect the Policy SIG Chair, and I was invited as the Election Chair.

We have a call for nominations, sent to the Policy SIG mailing list, first announced on 9 June, then the second announcement made on 15 August.  The nominations closed on 22 August, about a week ago.

The nominee for the position of Chair, we have only one person, Andy Linton.  Would you like to stand up again.

Since we have only one candidate, the procedure is we accept him or not.  So if you accept him, could you just give him a hand.


Kilnam Chon: I guess we have a majority.  Now you are the Policy SIG Chair.  Would you like to make any comment?


Sunny Chendi: Thank you once again, Prof Kilnam Chon, for running the SIG elections.

I would like to congratulate Andy Linton for being appointed as Chair of Policy SIG and I would like to invite Andy Linton to run the Co-chair elections.

Andy Linton: I would like to thank you all for your support on this.  You didn't have much choice, I suppose.

I take it as an endorsement that nobody else stood, or else nobody else is crazy enough to do this.  Thank you anyway.

I would like to thank the previous Chair, Gaurab, who you know, and I would also like to thank Terence Zhang, who has been our Co-chair.  Terence's term ends at this meeting but he is also standing for the position of Co-chair, along with two other candidates, and we will come to that shortly.

Just to remind you what my responsibilities are and so on.  My job here is to Chair the SIG session, to try to keep the session running for you in a smooth and fair way and to develop the agenda.

The agenda comes, of course, from input from you, you put proposals in, and there are issues that come up, so we work on that, and also to post things to the mailing list and make sure that runs.

I think, in a way, the really important one is to encourage and facilitate discussion.  As we go on later on this afternoon, we will have a number of issues we want to talk about, and my job is to help you do that in a fair and reasonable way.

This slide says "SIG Chair Elections", but it is actually the SIG Co-chair Elections.  We have three candidates and they will have three minutes each to speak.

The two candidates will be decided by a show of hands.

The election will be conducted with those people who are here in the room and those people in the remote hub in Cambodia.  My welcome to them, of course.  I had forgotten to mention them.  Also my welcome to the meeting to those people who are watching remotely and participating on Jabber.  Those in Cambodia will take part in the discussion and the election.

The count will be taken by the APNIC Secretariat staff and the candidate with the largest show of hands is elected.  Because we have three candidates, we will have an election for the first position and see who has the largest show of hands, then run it again for the second position.

I think there will be some people who want to vote -- obviously everybody wants to vote for the two candidates.

The Co-chair responsibilities are assisting the Chair, allowing me to not have to do everything, which is good, and again working with the Chair and other Co-chair to develop the agenda; just the same responsibilities, if you like, that the Chair has.  They are there to sort of be my assistants, to be my colleagues on this, and it is also really useful to have other people to bounce ideas against and so on.

The three nominees are Terence Zhang, Skeeve Stevens and Masato Yamanishi.  If I have butchered your names, I'm really sorry.  I will call them up in that order.

We do require staggered terms.

The Co-chair position is open for two years.  But if we do not stagger the terms, what we will end up with in two years is a possible turnover of the Chair and the two Co-chairs, and that's not good for continuity.

In the original guidelines, when we established the second Chair, we put in the mechanism to allow that to be staggered.

What I propose to do with your agreement is that the person who is elected first will be in for two years and the person elected on the second round will be elected for one year, and that means we then will have a staggered process later on.  So in a year's time we will get a new Co-chair who will be there for two years and we don't have a complete turnover of the system at one go, which would not be a good idea.

Let me ask you: are people comfortable with the idea of having the staggered term of two years and one year?

APPLAUSE Is anybody uncomfortable with that, does anybody think it is unfair?

OK, I will take it that you agree with me on that.

That's good, thank you.

I am going to ask Terence to come up first for two minutes, then I'll ask Skeeve and then Masato to come up for two minutes, why they think they should do this work and why they will help the position and so on.

Terence Zhang.

Terence Zhang: Good morning, everyone.  My name is Terence Zhang.  I am from CNNIC.

I have over 10 years experience in service provider network solution design and operational support.

I started my career in IBM networking department and worked for RCN Telecommunications for a few years as a network engineer and I worked at Grandcycle Technology as a network consultant.

I have participated in several service provider network architecture design and operational support in both China and the United States.

I have ample experience in IP address planning, Internet routing architecture and service provider networking solution design and operations.

After joining CNNIC, I have been working in the areas of IP address allocation and policy research.

I have actively participated in APNIC meetings and policy discussions since 2009 and I have served as Policy SIG Co-chair since APNIC 28.

I would like to continue to make a contribution in such a way as Policy SIG Co-chair in the coming two years.  I hope I get your support on this.  Thank you.

Andy Linton: Thank you very much, Terence.

The next candidate who will give us his sales pitch or speech is Skeeve.

Skeeve Stevens: (Speaks in Korean).  Hello to everyone and all the delegates here at APNIC 32.

APPLAUSE I am Skeeve Stevens.  I think many of you know me, probably some of you don't.  I have been part of the Internet Community for about 15 years, being involved in building the infrastructure of dozens of ISPs.  It is also still what my company does today.

This is my seventh Conference in a row, and the third anniversary from APNIC 26, that I have been here.

I came along to APNIC 26 based on the recommendations of my friend James Spenceley, who advised me that it was an important community to get involved with.  But he warned me -- don't rush in, be a part of the process, become involved and earn the respect you will need in this community, and do your time.

That's what I have been doing.  I have been watching, participating in discussions, asking the questions from my peers, debating the merits of policy proposals and becoming a part of creation process.  This is fuelled by a passion for Internet governance over the last few years, especially in the Asia Pacific Region.

See who I am.  Three years later, my heart for this community is significant.  I believe in this region, I believe in the policy, I believe in what APNIC does.

Why me?  Over the past several years, my company, which is a network engineering company, has joined up dozens of new APNIC Members, getting them set up, training them in IP addressing, conservation, ethical resource applications and much more.  I'm also a speaker on many topics in a variety of forums all over the Asia Pacific Region, other than APNIC; things like OZNOG, NZNOG, APRICOT, IPv6 Summit, iNETs and so forth.  I'm a director of the Internet Society in Australia and during this event now I'm the Co-chair of the working group examining the APNIC voting system.

Today I would ask you to support me in this position to allow me to serve you guys, and give back some of what this community has given me.  (Speaks Korean).

Thank you.

Andy Linton: Thank you, Skeeve.

Now we will have some words from Masato Yamanishi.

Masato Yanamishi: Hi, everybody.  I am Masato.  My current affiliation is Softbank, which is one of the largest carrier ISPs in Japan.  Before joining there, I used to work for a small start-up datacentre, so I can understand the situation of both small and large operators.

While my first participation in Policy SIG was in 2009, which was APNIC 27, I have been attending policy discussions in APNIC and JPNIC community in the last three years very actively.  In particular I actively contributed to address transfer discussions and also I am one of the authors of prop-097, which proposed the IPv4 address allocation mechanism post-exhaustion in IANA, and it reached consensus in the last meeting.

Also, from 2010 I am a member of the APRICOT PC and also APNIC Meeting PC.

In addition, I was the Chair of APNIC plenary in the last meeting and also I was one of the Co-chairs of the APNIC community consultation in Kuala Lumpur, which discussed IP address management by IT.  To be honest, the APNIC community consultation meeting was a very tough meeting, but I believe I conducted the meeting to a very successful result.

I think the role of Co-chair is to assist a consensus of all interested parties and it is a very challenging task, since we are still in the middle of the transition period between IPv4 and IPv6, and the policy development process is vital for the sustainable growth of the Internet.

If you would support me, I would very much appreciate it.  Thank you.


Andy Linton: Thank you, Masato.

The process from here will be that we have three scrutineers from the APNIC staff, Louise, Miwa and German, and they will come to the front and take a note of your votes.

We also have the group in Cambodia, and we will see what is going on on the screen.  I will also ask Jeffrey there, who is the APNIC staff person in Cambodia, to keep track of that for us as well.

What I would like to do now is ask you to show your preference for the three candidates.  I think at this stage, do people need the names up there or are people happy they know who the three candidates are?

You are happy.  I'm taking silence as assent here.

I will ask you to show your support for the three candidates in the order in which they have spoken and I will get the staff to count that, then we will do the arithmetic and see what happens for the second position after that.

Any questions?  OK.

Gaurab Raj Upadhaya: We are electing two Co-chairs now, which means we raise our hands twice for the three people or how do you want to do it?

Andy Linton: I would like us to express our view on the three candidates, elect one candidate in that round.

Then when we have done that, we will come back again with the remaining two candidates and have a second election and pick someone who comes out first in that group.

I think that is the simplest way to do it, or do people have any other suggestions?

Gaurab Raj Upadhaya: I just wanted the clarification of how I was going to vote.  So we do it once.  It's up to you as the Chair.

Owen Delong: Vote for one candidate, two rounds.

Randy Whitney: In other words, vote for the candidate you want the most, one hand per round?

Andy Linton: That's correct.  Two rounds.

In this round, there are the three candidates.

I will call the names in order.  Put up your hand for who you think should be the first Co-chair we will elect today, and this will be for two years.  OK?

Louise is prompting me: if you vote for Terence, don't put your hand up again after that for Skeeve and then for Masato, because that will screw up the thing completely.

Those people who want to see Terence as the Co-chair, will they put up their hands?

The remote hub.  Put your hands up nice and high so we can get the numbers.

Remote hub, can you indicate that you can hear me in Cambodia?

No show of hands in Cambodia I'm seeing.

OK, you can put your hands down now.

Those people who want to see Skeeve as the Co-chair for the next two years?

And in Cambodia?  You must have some opinion there.

I am seeing some hands up in Cambodia.  OK, we have got that.

Finally, those people who want to see Masato as the Co-chair for the next two years.

And in Cambodia as well?

That's fine, thank you.

Adam, you have the numbers from Cambodia.  Can you pass them to the tellers.

We have answer for the first one.  I declare that Skeeve has been elected as the first Co-chair.


Andy Linton: Now we need to do the next part of the process, which is to make a selection between Terence and Masato for the second position.  This position will be for one year.

If you can bear with us, we will do the same thing again.  For this round, the first candidate is Terence Zhang, and those people who would like to see Terence as the Co-chair for the next year, please put up your hands now.

And in Cambodia, you too can take part in this part of the election as well.

Nice and high, please, because people are trying to make sure they count your vote.

If you voted for Skeeve in the last election, you can vote in this part.

Those people who would like to see Masato as the Co-chair for the next year, please put up your hands.

And in Cambodia as well, please.

Jeffrey, if you can get the numbers from Cambodia back to Adam, that will be fantastic.

The result of that part of the poll was that Masato has been elected as the second Co-chair.


Andy Linton: I'm going to ask the two successful candidates to come up to the front and take their positions behind the desk here.  Give them a big round of applause.


Andy Linton: While they are doing that, I would like Terence to come up, because we have a small token of appreciation for him for his work over the past two years.  Terence, if you would come up, thank you.


Terence Zhang: Congratulations to the new Chair and Co-chairs, and thank you for your support for the past two years, and I will continue work in the policy area.

I really enjoy working here.  Thank you.


Sunny Chendi: Before we begin the Policy SIG session, I would like to invite Raimundo Beca to come and explain about the ASO review process.

Raimundo Beca: Good morning, everybody.  I'm Raimundo Beca, I am a former ICANN board member and also a former member of the Address Council.  At this moment I am here as a reviewer of the ASO MoU.  The review of the ASO MoU is a different process to other reviews in the ICANN system.

In this case, we are conducting, in parallel two questions: one is directed to a number of 100 people in the community, who are concerned with the ASO MoU, and the other one is a massive online survey.  You can see on the screen the massive inquiry.  This massive inquiry, we hope all the people who are attending this meeting, either here or in Cambodia or online, will fill in this survey.

I encourage you to do it, because as the reviewers we want to know the opinion of the community on the questions that are raised, and it is very important that all the attendees to the APNIC 32 Meeting fill in this questionnaire.

I just checked, before coming to the stage, this morning there was only one answer to the survey.  But I hope that at the end of tomorrow all the attendees will do it.  So I encourage you to do it.  Please do it.

Thank you so much.

Sunny Chendi: Thank you, Raimundo Beca, for informing us about the ASO review process.

Now I would like to officially hand over the floor to the Chair and Co-chairs of Policy SIG to proceed with the SIG sessions.  Thank you.

Andy Linton: Thank you, Sunny and thank you, Raimundo, for reminding us of that.  We will do another reminder later.  Please take part in this.  The reviews they do on the various working groups and advisory councils on ICANN provide some useful input to the process.  Thank you.

The first thing I want to talk through is the policy development process.  Many of you here are familiar with this, some of you are newcomers -- I met some of those newcomers on Saturday evening at the newcomers' session -- but I think it's always useful to remind ourselves what we do and why we are here.

I won't dwell on this for too long, it is on the website.  So if you are a newcomer, I would encourage you to go and look at that.

Our job here is to develop policies and procedures that relate to the management and use of Internet address resources by APNIC, NIRs and ISPs within the Asia Pacific region.

Most of you are familiar, there are two mailing lists, the SIG Policy list, where people put proposals and we have discussions, and everybody is very friendly to everybody else, and so on.  We have a good time there.  But it is a place for discussion.

Then there is the SIG Policy Chair list, where the three Co-chairs can have conversations about what to do next and so on.

Just to go over the process here, the steps we have for implementing a policy: someone submits a proposal on the mailing list.  That comes in as, "I think there is a problem and here is some background on it and here is a proposed solution and here are some pros and cons for it," and so on.  There is some discussion on that immediately prior to the meeting, then we bring the discussion to the meeting and we continue that process and sometimes that changes people's views and sometimes people continue to hold the views they have held nonetheless.

Our job here is to try to reach consensus.

Consensus for many people, if they have never been to this, is a difficult concept or a novel concept.  This is not a vote, it's not us putting up our hands and saying the majority won.  We have to take everybody with us.  We have to persuade everybody this is a reasonable approach and an approach that will not do any harm and in fact will do some good.

We try to reach that consensus on the proposals, then tomorrow at the AMM we reiterate that process, but hopefully in a much shorter time frame.  It's more of a formality, but it's to give us a second chance to think again: was there anything that came up?

We go again and talk about the proposals tomorrow at the meeting and say, this is what we did yesterday, yes, we did reach consensus and we approve that process.

Then we go back to the mailing list with any proposal that has reached consensus and ask the people who weren't able to be here and who weren't able to be part of the remote dialogues, like the remote hub in Cambodia or people who are currently watching this online, what they thought.

That gives us a chance to think again, make sure we have made considered decisions.  And if there are any strong objections in that consensus period then that actually will break the consensus and so on.

The job of the Chair and Co-chairs is actually to examine that and look at that.

If we go through that whole process, then any proposal that we have reached consensus on goes to the executive, to the EC, for endorsement, and then there is an editorial comment.  So the Secretariat have to implement these policies, and it's always working thinking about when you think about any policy you propose, that somebody will have to put it into action.

So you have to think about how that will work.  They get a chance to look at the document and say, "Well, actually, there's a really significant problem here in implementation."

We then go into implementation, and in a relatively short period of time after we have reached consensus here and gone back to the list, we see those policies in action.

Just to reiterate on consensus decision-making, it is described as general agreement.

We can agree to differ on things, but we get to the point where we are comfortable with each other that this is a reasonable decision.

My job and the job of the Co-chairs is to take into consideration comments on the mailing list and at the meeting.  That's what I think is one of the hardest parts of this job, to try to understand what is meant by consensus.  It requires partly you to trust the Chairs, but also requires me and the other Co-chairs to observe carefully what your feeling is and what you think about this.

When I ask you to show hands, it's not a vote, it's a way for you to indicate what you think about this.

It's a way of broadly gauging opinion.  So clearly, if we have a show of hands with very equal numbers of people who are on one side or the other, that's clear, we haven't reached consensus.  But we can reach consensus where some people object.  It's just a balance that you have to allow us to strike here in this thing.

One of the reasons we do that is our community is much larger than the people in this room.  You can say we are the lucky ones who have been able to get some funding to come here and take part in this, you can say we are the committed people who have bothered to come and take part in this, but our community is much larger than this, so if we vote here, it would disadvantage all the people who take an interest in what APNIC does but can't be part of the process.  That's why we go down this path.

Just quickly again, we use this in the policy development process, because we work on a process of being open, multistakeholder involvement, we have people here who are technical, people here from the social and in some circumstances political sphere, anyone can make a proposal.  We discuss policies and we all participate in this decision-making process.

We are transparent.  This meeting is happening here, it is also public and documented, it's available on the net, and we document all our discussions and decisions.

That's so that no one can ever say there was a secret group who went off and did something that was detrimental.

It really is bottom-up.  You will see when we discuss the proposals, the proposals come from a range of people and a range of groups, and they have seen a problem which they have proposed a solution to.  Then we will discuss that.

Just to remind you again of my and the Co-chairs' responsibility, we are not here to make a decision for you, we are not the judge and jury, we are here to help provide a neutral overview of the proposals.  Sometimes we will ask for clarification, "Do you mean such and such?", or try to tease out a summary, "The views seem to be X and Y and Z," and probably a lot more as well.

We just generally keep people on track here.  We will attempt to control the time, and the order, and I intend to attempt that fairly well, because we have a relatively short time to do this.

When you come up to the microphone, there is a little sign reminding you to give your name and your affiliation.  Can I also ask you, when you start to speak, to say whether you support something or whether you oppose or strongly support or conditionally support.

You can certainly come up and say, "I'm not sure" or "I would like some more information before I can decide here," or you can say, "Over my dead body will we do this or not do this."

It is really useful for people here to understand what you think about this.  Sometimes when people get up, they make a statement and it's not completely clear whether they are for or against and how strongly for and against.  So that is useful, and let's see where the room is going.

Just some rules of engagement.  Everybody who submitted a proposal here has thought about it before they did it, they have done it with good intentions.

You may not agree with them, and opinions will vary.

The reason people have bothered to support a proposal and come here is because they believe what their proposal does is try to promote a strong and healthy Internet.

If you disagree with them, then that's fine, but be polite and professional, respect each others' opinions.

When you get up, as I reiterate, make sure we know who you are.

There is a saying that we have, certainly in parts of the English speaking world, play the ball not the man.  If you are playing rugby, you don't hurt the other player, you are after the ball.  Play the idea.  It's the idea that is important here, and let's keep any strong feelings -- and I know people do have them -- off the personal.  This is not about individuals here, this is about the ideas.  Our job is to debate the ideas.

There are some references here.  I don't propose to read those out to you.  You can go and look at those.

This whole process is much more rigorously documented in the links.  I'm sure most of you will have had a look at at least some of these and it's probably not a bad thing to look at them again every now and again, to remind you what's going on.

I am going to skip over the slide and if we get to the point where we have to talk about objections, we will have another look at it.

Any questions on that?  Anybody not clear about what we want to do here?

My lovely assistant will change the slides.  Sorry, Sunny! The next item is just for us to quickly have an overview of the open action items.  Effectively, this is just to remind you this is what we are going to be looking at.

I will try to do this in a factual way and just talk about the mechanics of the proposals and so on.

These are past ones, these are the old ones.  This is now in place, this was pending approval at each stage.  We looked at this idea of alternative criteria for subsequent IPv6 allocations.  This one was implemented not that long ago, in early August this year.

We also had one which was prop-087, IPv6 address allocation for deployment purposes.  That one was withdrawn by the author, so we do not have to consider that any more.

Again, prop-084, which was about frequent Whois information update, the author withdrew that one.

I spoke to him and he thinks that there are other developments happening and it's not timely to talk about this now and will probably come back with something else and, if he does, then we will talk about it.

As you know, in the last period we moved into the last /8, and we had a prop-088, which was about the distribution of IPv4 addresses, once the final /8 period starts.  That was implemented on 8 May because we had to.  It's as simple as that really.

We had also considered a proposal earlier, this prop-093, about reducing the minimum delegation size for the final /8 policy, so that people could, instead of saying, "I would like a /22," they could say, "I will take a /24 and come back for further ones."  I tested that out about three weeks ago, and it works -- wearing one of my other hats.

Prop-094 was about adding alternative criteria to renumbering requirement in the final /8 policy.  Again, that was implemented once we got into the final /8 stage of the process.

Prop-095, which was about inter-RIR transfer proposals, was implemented on 9 August, a few weeks before this session.

Prop-097, of course, is still on the table, and perhaps we can make some progress today to help with that.  We are at the position where the other RIRs are in different stages of considering this -- shall we say that.  Some of them have accepted this, I understand LACNIC have passed this, the same proposal.  If anyone can give me information about what the others have done, I'm happy to repeat that.  ARIN is still considering it, I know, and AfriNIC and RIPE, I think it is still under consideration.

Prop-096 was on the table last time.  We had got to a point where we were relatively close to a decision on it, and then we effectively couldn't reach consensus on it, so it went back to the mailing list for further consideration.  Now it's back.  So later on today we will talk about this one.  When we get to it on the agenda, we will see what's going on.

We also had prop-069, which if you are looking at the numbers, we are dealing with 98, 99, 100 -- this was some time ago.  There was an attempt to have a global policy agreement some time ago.  This was the first attempt on this proposal for the allocation of IPv4 blocks to Regional Internet Registries.  That proposal can't continue, not everybody agreed to it, but we still have it on the books.  Later on today we are going to have a look and see if we can tidy it up.  It's an administrative issue that we need to tidy up.

That's the end of those.

We will do a quick overview of the policy proposals, and these are the ones we will talk about later.

The proposals we have under discussion will be prop-096, prop-098, prop-099 and prop-100.  Prop-096, maintaining demonstrated needs requirement in transfer policy after the final /8 phase; prop-098, optimizing IPv6 allocation strategies (simplified);  Prop-099, IPv6 reservation for large networks; and prop-100, a proposal about a national IP address plan, allocation of country-wide IP address blocks.

I will summarize what each of these is about.

Prop-096, maintaining demonstrated needs requirement in transfer policy after the final /8 phase: APNIC is the first RIR that has got into the final /8 phase.  We have grown rapidly in this region, and other RIRs have not reached that stage.  APNIC is the only RIR that doesn't require a demonstrated need for transfers.

Other RIRs are reluctant to recognize any inter-RIR transfer policy with APNIC.

I think most people can probably see there's a problem there.  They have something and we want to take some advantage of it.  If they don't recognize the policy to transfer them to us, it can't happen.

The proposal really, to put it simply, proposes that recipients of transfers be required to justify their needs for IPv4 address space.

This really isn't anything new for us.  In the last however many years, when you were applying for addresses from APNIC, you had to justify your needs, and this is an echo of that, to say that you will still need to do that on transfers.

Prop-098 -- and the authors are here and they will do a fuller description of all these proposals later on -- aims to address LIRs feel they must fit their entire subscriber base in a single /32.

There are some issues with bit math errors in calculating boundaries using subnet masks which aren't on what's called nibble boundaries -- so multiples of 4.

Bit-wise arithmetic is something that the people who do it and do it on a regular basis, in general find they get used to it, but it is relatively easy to make mistakes in this scenario and I think the idea of the proposal is to eliminate those risks.

There is also an issue, the author believes that the HD-ratio leaves much to be desired as a tool for address administration.

The proposed solution is utilization be measured in provider allocation units, which is the smallest reassignment unit, and that 75 per cent or more utilization or one or more facilities has reached a 90 per cent utilization and no blocks available to expand.

I am probably butchering Owen's proposal.

Owen Delong: No, you have done it very well.

Andy Linton: I will butcher the other ones equally well.

Allow LIRs to request nibble-aligned blocks of any size greater than or equal to /36.  This means our default minimum is /32 so people will be asking for blocks in /32, /28, /24, /20, /16.  Let's stop there.

The maximum they can talk about here is to look at a five-year plan.

There is also the notion of subordinating the LIR block count as fully utilized.

Owen Delong: If you allocate to an ISP, it's fully utilized.

Andy Linton: If you allocate to an ISP, it's fully utilized.

When you come back for more address space -- and sometimes it's inconceivable for some of us that we will need more than a /32 -- you expand to the next nibble.

If you come back after having had a /32, you would come back for a/28; you wouldn't come back for a /31, a /30 or a /29.

The allocation should not be bigger than a /16 but a provider might need more than one /16 to meet justified needs.  None of this eliminates anything to do with justified needs.  Justification is still required on all of this.  This is needs based assessment, but it's looking at the boundaries and thinking of it being slightly different.

Prop-099: we currently have a slow start policy which allocates /32 at a time and then reduces the bit mask one bit at a time.  That can cause fragmentation and complexity in large networks and POPs growing at different rates.  The IPv6 policy does not take account of long term.  In this proposal, the term the authors are talking about is 10 years, whereas in the previous proposal it was five years -- long term, much longer than we have done in the past.  Certainly we have had a much smaller window that we have looked at these things.

The proposed solution is to allow multiple prefix requests.  Those are separately justified, and we have covered that off in a previous prop-083.  Subsequent allocations are made within a reserved space, as extensions to existing prefixes and/or new prefixes.

It basically allows someone to know what will happen with their address space, where it will come from, and they can manipulate that accordingly.

The idea under prop-099 is that you would make a reservation request for your projected network up to a long period, 10 years, you would need long-term network plans, and it would allow you to bring environmental factors in there.

I note that this is a reservation, not an allocation, it's not handing over the block to the person who made the request, it's basically putting it on the shelf in the APNIC database or registry and saying, "They will get their blocks out of this space."

It's not handing over the whole thing and saying, "Go for it."

So that there are some checks and balances in here, after a two-year period, your reservation would expire unless you re-justify it.  We don't really know what the future holds for us here.  If somebody projects 10 years and gets it wrong, we really need a chance to look at this.  The idea would be after two years, APNIC and the person who asked for the reservation would work together to look at this and say, "Were your plans justified?

Are you growing as fast as you thought?  Have we got this right?"

Prop-100, in a sense, is similar to prop-099.  It addresses the problem of IPv6 currently is allocated in a similar way to IPv4, and it is allocated to organizations rather than geographies, and it is based on this one year demonstrated need.

The authors believe that this will cause the same problems in IPv6 as we have in IPv4, we get fragmentation, and they also have a question about whether law enforcement and other agencies who need to know what is going on have difficulty tracking down abusers.

They have proposed in their document -- there has been some rework on this document while we are here, but what they have proposed is that there be a large block of addresses reserved for India in this case, but they are also asking for this to be something that is available to everybody else.

This is not a proposal for India, it's a proposal from India.  I think perhaps there has been some confusion about that.  I have had some discussions and that's certainly my understanding about this.  It is a size to be based on future requirements for the next 20 years.  We have seen proposals here talking about the next 5, 10 and 20 years.  People are looking ahead and saying long-term thinking about this, long-term strategies, and if only we had really good crystal balls we could look at it and work out what will happen.

Sometimes we can't do that.

The idea would be that if there was a block reserved for India, it would be set aside.  I note the slide says "allocated", but I think "reserved" is a better word that we should be using here.  It is reserved for the Indian NIR once it is established and would work in a similar way to prop-099.  It is set aside for the entity and they draw down from it on a needs basis.  That block would be used for all TSPs and ISPs and other organizations in India.

Those are the proposals.

We are not going to debate those now, that is just food for thought, you can sit and think about these over lunch.  Looking at the time, we are getting close to that now.

We have one more to do.

The next one is much more relaxed and so on.

Sunny Chendi: Thank you, Andy.  This is the early bird prize draw for those who registered and received the discount for the Conference by the cut-off date, and we would like to appreciate those delegates, and we have got a small gift for them.  I'm going to do the draw.

We usually do this one in AMM, on the last day of the conference, but we noticed that most of them depart after the Policy SIG Session finishes.  So we thought we would do it in the Policy SIG Session, just before we go for the lunch break.

This draw is very simple.  I will press the button and it picks out a name out of a list of those candidates who registered by the cut-off date and paid for it.

The first one up is Ravi Singh, registration number 26361.  Is he in the room?

I hope I have some luck today to give away the prize.

OK, 1, 2, 3, gone.  I'm going to do it again.

25651, registration number, Ben Steele.

Maybe it's the party effect last night -- they are still sleeping.

Final chance, Ben Steele.

Sorry for holding up for the lunch break.

26915, Benoit Morel.  He is here.


Sunny Chendi: I think some of you know, it's a 7-inch Android pad with 2.3 on it.


Sunny Chendi: Thank you once again to all those who registered early.  We will take the lunch break and resume at 2:00.  Lunch is served in the same room at the end of the hall.  Come back at 2:00 pm and we will proceed with the rest of the Policy SIG session.

Thank you.  Thank you, Cambodia, for joining us.

Please stay tuned after 2:00 pm.  Thank you.

APNIC 32 Conference
Wednesday, 31 August 2011
14:00 (UTC +9)
Policy SIG

Andy Linton: We'll get back to this session.  A few more people are coming in, but we'll just start.

Just before lunch, I had to eat humble pie and make an apology that prop-100 when I talked about it, we had actually got the wrong slides.  I'm going to get Adam up in a second to talk about IPv6 policy documentation, but just before he does that, I'm quickly going to take the two slides for prop-100 and give you the correct ones.

These were the slides that we should have had on prop-100.  The authors did a major rewrite on this and put a revised version up on the list, which you all have access to.

The two main points that they are seeking to address with this proposal is that currently APNIC policy doesn't allow address blocks to be reserved at the economy level.  This proposal calls for adequate IPv6 address space per economy to be reserved for future allocations to the organizations and stakeholders within that economy.

In a sense, similar to prop-099 except we're using the word "economy" rather than "large ISP", but very similar.

Also in their proposed solution they're citing that there is a problem of analysis and projection of requirements.  They certainly say that if various economies or large ISPs come to APNIC and say, "We would like to reserve this and reserve that," then that also puts that problem on to APNIC.  They have to think about that.  I think it's fair to say they are also recommending that other economies think about this issue.

Their other proposed solution is the reservation of IPv6 address space for different economies.  They're suggesting that that's something that should be available to everybody.  So, although the proposal came from India, it's not a solution purely for India.

I think that's a much better assessment of what they're proposing than the stuff I talked about earlier.

So I hope you have forgotten it and this has now replaced that in your minds.

I'm going to get Adam to come up now and talk about IPv6 policy stuff.

Thank you.

Adam Gosling: Good afternoon.  My name is Adam Gosling, as you can tell from the slide.  I have recently taken over the policy function at APNIC Secretariat.

I wanted to firstly introduce myself to you, but also to talk about some changes in the documentation that we have begun to make and want to take further.

I just want to run through that and get some feedback from the community.

When the SIG last met, this was pretty much the structure of the resource policies at APNIC.  When we were in Hong Kong, an independent policy for each of the three main resource areas.

With the IPv4 exhaustion hitting immediately after Hong Kong, working with Sam Dickinson, who was the previous policy person, we decided it was probably an appropriate time to look at the policies, with the v6 policy becoming more important and the v4 policy generally becoming less important.

We decided it was a good time to do a major edit on the document.  That v4 policy, which ran to about 5,500 words, was cut in two and a new policy was created, a policy document called "Policy Environment for Internet Number Resource Distribution in the Asia Pacific."  Its document number is apnic-125-v001.  It was published on 9 May.

The old IPv4 policy was replaced, superseded by 124-v001 on the same date.  Basically, what that did was to take a lot of the goals and definitions and principles that we govern address space with in the Asia Pacific and put them into their own document.  But it didn't affect the v6 or the ASN policies.

This sort of stuff we migrated into the environment policy -- and all we did was cut and paste it, it wasn't edited -- was the hierarchy of IP address space distribution, how IANA holds the free pool and the registries draw down from that, all the definitions that are used in the documents and the general goals of address space management that APNIC manages, the policy framework, how address requests are evaluated and the reminder that you don't own the space, you are just licensing it.  That is included the URL there, just in case anyone wants to have a look at it.

This is what we want to do, though.  This is what I want to do.  That environment content is spread out and replicated in the v6 and the ASN policy documents.

With the v6 policy document, it's about 5,500 words as well; the ASN document is not quite so hefty.  But there is a lot of replication between the three documents.

To make it easier for people to access and actually see the policies, I cut down the IPv4 policy to around 2,000 words, which makes it quite a reasonable document to sit down and read, rather than the 5,500 words it used to be.  So I would like to do that to the v6 policy, as the next thing.

A little bit of history about the current v6 policy at APNIC.  The original document, there was provisional-ipv6-policy-1999, it was never given a document number, so it was kind of an informational, as much as anything, back in 1999.  The current policy as it substantially stands today, apnic-089-v001, was first published in mid-2002.

That document was put together by a joint task force of community members and Secretariat members from APNIC, RIPE, and ARIN communities and it's substantially the same today.  We're up to version 10, but there have been a number of tweaks.  The document is still pretty much the same in RIPE as well.  In ARIN, it's subsumed into their policy manual.  But substantially, a lot of the content is similar across the regions.

ARIN at the beginning of last year made some editorial changes to it, which I'll come back to in a minute.

My next step after this meeting is to do, as I said, the same that I did with the IPv4 document and split the environmental, the guiding goals and principles that are in the v6 document and put that into the environment document, the existing 125 document, and just leave the juicy stuff in the IPv6 policy.

Obviously, that will mean we will be removing the duplication from the environment document and probably tidying that up a little bit as well, because there is a bit of duplication in the existing document.

As I mentioned, ARIN at the beginning of last year did some editorial changes to that old v6 document that was produced in 2002.  It's called Appendix B and the background to how the document came about, it was a jointly developed document and acknowledges the effort of the authors, some of which are probably in the room.

I guess I'm interested in whether, while we still acknowledge and appreciate the effort they put in, we need to keep that content in there going forward.  There are also some very outdated references to documents that no longer exist on the Internet.

Then my next goal is to tackle the ASN policy as well.  But, as I say, that's a much smaller one.  If anyone would like to comment on my plans, please let me know.

Obviously, any changes done to the documents, they're official documents, would go through the four-week comment period.  We post it to the drafts section of the APNIC website.

OK.  Thank you.

Andy Linton: Thank you, Adam for that.  I think that's a useful task for Adam to spend his time on, because it makes the documentation more straightforward.  I know it's certainly been, for me, interesting to try and wade your way through this stuff.  It's a good exercise, I think, to do.

As you can see on the agenda, and now on the screen, the next thing that I would like to look at is this idea of a Policy SIG working group.  I raised this on the list in the run-up to the meeting and I got enough positive feedback from people to make me think that this was probably worth a look.

I think in discussions with people here over the last few days, I haven't shifted really from that view.

I think it probably will be useful, but I'll put some ideas in front of you and let's talk about it and see if we can make something work from it, and then I'll ask for your ideas on whether we should or shouldn't or what.

The reason I have thought about this was I'm very conscious that we have three proposals on the table today about IPv6 allocation.  We had a number at the last two APNIC meetings about IPv6, I think that's fair to say, but certainly a number of proposals in recent times which are talking about the basic allocation of a /32 to a regular size organization is pretty straightforward, but there are other people who are coming back and saying, "Yes, but, I have this different position" or "I have these other needs."  And we keep writing these little corner case policies that say if there's an "R" in the month and somebody has a green hat, they should be able to get some more address space and so on.

So just some complicated things that -- I'm not sure that the best way to deal with that is in a piecemeal one policy and then another one and then another one.

I have no desire or no intention to remove the process of people having been able to bring a proposal to this meeting -- none whatsoever.  I'm not talking about that.  But I think this is one where it's probably worth a little bit of an extra look at this stuff.

The proposals we are seeing on the table today, certainly, and those other ones are telling me that people are slightly concerned about exactly what the address space they're going to get is going to look like.  I hope they're not concerned that there won't be enough, but I think they're concerned about what their piece of it is going to look like.

So existing practices don't allow for the reservation of large blocks of space to anybody and we have established those principles over a long period, based on RFC 2050 and other operational experience.  We have had to think about that.

There are three important principles spelled out in RFC 2050, this notion of conservation, routability and registration.  I think our experience tells us that these three things work in some sort of tension with each other.  The idea of conservation is one that we say, let's keep the addresses under tight control as they're a scarce resource.  But the engineers who are trying to deal with writing tables are also saying, yes, but we don't actually want them fragmented up into lots and lots of /24s.

In a perfect world, aggregation on the backbone of the net would be done properly and done well and we would have 100,000-something routes instead of -- we could cut the blocks, the number of announcements dramatically.

Philip has posted some stuff, and I think Geoff has as well, that said there is a large problem with lack of aggregation.  I know the organization I work at is guilty of it and I know plenty of others are guilty of it too.

The other one, I think, in recent times, the registration one -- it's important, but it's sort of a third cousin.  You have a tripod that has legs that aren't quite the same length.  It's important to get registration right and so on, but we have started saying to ourselves that registration is an important task and one of the things as we go ahead here, especially with the v4 space and the v6 space, keeping track of these resources is going to be an important task.

I wonder do we need to slightly consider what the emphasis is here; conservation under the v6 regime will be one not of dealing with a very scarce resource, that doesn't mean we become cavalier and just throw it out and say, here you go, you know, and waste it.  But we should be thinking about how we allocate this.

Our expertise is in doing v4 allocations.  V6 is a new beast and I know at times I struggle just looking at the numbers and think about exactly how big they are.

I was going to show you a graphic, but I didn't get around to doing it, where somebody showed me a picture of a white square which is this sort of size, and it's as though someone has taken a pen and just gone and done a couple of dots in one corner of it and said, that's the v6 space and that's what we have allocated at the moment.  That doesn't mean it's open slather and we waste it, but let's think about that.

Those proposals we have had so far make it clear or are asking the question: do we need to make it clear and explicit that an organization or an entity of any sort can expect to be able to grow into that block in the future?  Prop-099, prop-100, prop-098, all these things are in and around this space.

One of the hard questions is: how large should that potential growth be?  What should it look like?  Geoff pointed out in his talk -- in one of his talks, because he's done several, but I think it was the keynote -- where he said we're rubbish at this prediction game.  We don't really know.  If we were really good at this prediction game, we wouldn't have to have these agonizing things.  We would just say, "This is what you're going to need."

The other thing that's come up is about the registration function.  In New Zealand, I'm involved with the .nz administration for the domain name and we got approached by New Zealand police, who are interested in who has domain names.  Not everybody who has a domain name behaves very well and not everybody who has an IP address behaves very well.  They are interested in knowing who has what and what it means.

Now, some of us will look at it and think: well, it's pretty easy to go off to the various Whois servers, the various web pages and look that stuff up, but these people don't know about that.

Certainly when I showed them the information that they could get on numbers, just through publicly available tools and so on, they went, "OK, I see."

They're not looking for absolutes, they're looking for pieces in the chain of evidence.  They're looking for, if that was the case and this happened and that and that, then it's highly probable that somebody was doing something.  So they're not looking for the absolute truth here, they are looking for snippets and pieces.

There is some information in the IPv6 in the APNIC database, if people use MyAPNIC which is public, but there is also the option for some of that information to be marked as private.

They were certainly concerned about that, and I would be very surprised if other law enforcement agencies want to know that as well.

We are not in the job of being the police, we're not in the job of being law enforcement, but we probably have a responsibility to cooperate with them in a responsible way.

Certainly if we don't do that, we're going to have some interesting times ahead of us, I think.

I would like us to think about forming a working group to look at these issues.  I'm not saying I know all the answers, but I think there are some questions here which could do with just a step back.  I don't know how you propose a policy document which would actually deal with these issues.  Maybe you could.  But for me anyway at the moment, I'm not sure I know how to do that and I would like to think about a small group.

I'm thinking of a working group of five to seven people who would actually look at this problem.  We would have a public mailing list where all of you can contribute, both people in the room and people who are on line remotely here and on the mailing list.  The working group would consider people's opinions and seek some information, perhaps commission people in the Secretariat to help us with that in terms of working some stuff out for us and so on.

I'm reluctant to ask for volunteers, because I know you're all going to rush forward right now and I'm going to get trampled in the rush -- OK.  I think what I would like to do is have perhaps some people, say, OK, I could be interested in that.

Now, if it's necessary, if I get 500 volunteers or even 20, I don't think that makes a working group.

I don't think we can do that.  What I would ask you to do is allow myself and the other co-chairs to select those volunteers, if we have to do that.  What I will do is make that process quite clear among all the people who volunteer and say, we have decided that we want people who are expert in this, this and this.

I really don't know who's going to put their hand up here.  So if this group is willing for us to do that or think that this is an idea that we could work with, then I would like to seek approval from you to do that.  If anybody has any comments they want to make about that, before we go ahead or any questions, I'm very happy to hear those questions now.


Owen DeLong: I like the idea.

Andy Linton: I'm conscious that there are people in Cambodia and people on line, so if they want make comments on that, if they pass the comments back via Jabber, then that would be useful.  I'm not hearing anybody who is against it too much.

If you want to comment, the mics are open.  I'm quite happy to hear that.  But if you are happy with that, I'll carry on.

If you want to volunteer, just send email me.

I think that's the easiest at the moment.  You don't have to put your hand up publicly in the SIG Policy mailing list.  I'll share that with the co-chairs and we'll work out who is going to be there and we'll announce some details on the Policy SIG mailing list.

I talked with Sunny about this and I think we will probably look to have a separate mailing list to keep the traffic, so people can subscribe or we may just do it on the SIG Policy list.  I'm not quite sure yet.

Let's see how we go with that.

If you're happy about that, then we'll continue and I think that's the last slide.  There aren't any more.

Our next item on the agenda is prop-069, and this is a procedure for removing this failed global policy.

It's got some slides on it, so we'll put those up.

While we get the slides up, we'll just carry on with this.

What to do with prop-069?  Sunny is going to drive the slides for me.

What was prop-069?  It was our first attempt at a global policy proposal for the allocation of v4 blocks to the Regional Internet Registries.  It was produced by this team.  I'm not going to read all the names out, but you can quite clearly see that it was put together by people from all five regions.  This proposal was passed in four of the five regions and has stalled.  One of the clauses in this proposal was that it was subject to approval in all the regions.

This proposal is effectively an orphan that's got left behind in this global policy proposal process.

We passed at our last session prop-097, which is our current global policy proposal for the allocation, and it clearly supersedes this policy.  So this policy has no business being still on our books.

Here is the history of it.  23 January 2009, version 1; then we had version 2 to the mailing list; then we reached consensus at APNIC 27.  Then we had obviously made some changes there and we got version 3 on the comment period and the APNIC EC endorsed that after the end of the comment period because it went through.

Other RIRs -- AfriNIC, LACNIC, RIPE -- accepted or worked with this proposal, introduced it, approved it in the same way.  I think if we go to the next slide -- it was introduced in ARIN, but it didn't make it unscathed through the ARIN process and had some changes made to it, so there was this stumbling block that the version didn't include mandatory return of address space to IANA.  I think the word "may" was used instead of "must".

At the ASO AC, the Address Supporting Organization Address Council to ICANN, this global proposal has been effectively "abandoned" -- and we use inverted commas there.  We discussed this in the ASO and said this clearly can't go ahead because it doesn't match, the versions don't match.

What I would like us to consider as a proposal here, the membership of the APNIC Policy SIG recognizes that prop-069, global policy proposal for the allocation of IPv4 blocks to the Regional Internet Registries, has been superseded by prop-097 and that prop-069 should be abandoned.

Is there anybody who has any comment on that or thinks that's a really bad thing to do or doesn't understand why we're doing this?

I'm seeing everybody keeping their heads down.  Can we see some hands, see if we can reach consensus on abandoning this, just an indication?  Who's in favour of abandoning this?

And who is against abandoning this?

All those people who are happy to express an opinion, we all agree.  Some people feel they don't care or don't want to commit, and I know there are staff here as well and so on.

I'm seeing the nod from the other two here, so I think we can safely say this has reached consensus.

Our next step now is to pass this to the EC and tell them that this is what we have recommended and reached consensus on, and the ball is now in their court and we'll see them later today and we'll tell them this is what's happened.

Thank you.  That's great.  Let's get that out of the way.


Andy Linton: I hope the next four are going to be as straightforward.  Let's see.

I'm just getting a piece of information here.

I have just got an update that the secretary to the Cambodian Information Minister, his Excellency Ouk Kimseng, is planning to visit the remote hub around 1 pm Cambodia time, so about 3:00.  I think at that point, if we can get a reminder, we'll flip over to the remote link, so let's just watch our time here for 3:00.

I have Tomohiro up to talk about pro-096, maintaining demonstrated needs requirement in the transfer policy after the final /8 phase.  This was presented at the last meeting.  We got a long way down the track with this and then it sort of stumbled at the last moment.  We took it back to the list.

There hasn't been substantial discussion on the list in the meantime.  There hasn't been much discussion.  So initially, we weren't going to have this here, but there have been some things going on in the rest of the world and I made a call that we would bring this back here.

So Tomohiro is going to go through the presentation for us and then we'll have some discussion on it afterwards.

Tomohiro Fujisaki: Good afternoon, everybody.  I'm Tomohiro Fujisaki and this time I propose to explain prop-096 again, to refresh your memories and to explain new all this proposal.

The proposal is very simple.  I propose to restore the requirement for recipients of IPv4 transfers to justify their need for address space.

There is a current problem, I think, that the current APNIC transfer policy have no demonstration needs for transfers.  I think this is problem because this makes APNIC the only RIR that does not have the requirement to demonstrate the need for transfer.

One point -- this was just mentioned by Andy -- some inter-RIR address transfers require to demonstrate needs.  So I propose to justify the need for IPv4 address when they want to transfer IPv4 address.

This is the slide to show my proposal.  Now we are at stage 3 and just now we don't have demonstrated needs for address transfer, but I propose to restore the previous situation to transfer IPv4 address.

This is the situation of other RIRs.  All other RIRs except for APNIC -- AfriNIC ARIN, LACNIC, and RIPE -- have demonstration needs requirement in address transfer.

I'm sorry, but Emile points out that this document number in RIPE is a little old, the current number is 524, but this section has not changed.  So, except for APNIC, all other RIRs have the demonstration needs requirement in transfer.

So this is the advantage of my proposal, that it will put APNIC policy in line with other RIRs and might satisfy the other inter-RIR transfer policy.

This is the advantage of my proposal.  Justifying the needs is probably making something like a barrier to resist the address transfer, so this is one of the problems.

About the implementation, just restore the demonstration of need to the APNIC transfer policy document.

I propose to restore the requirement for demonstration of need in the case of address transfer and I think this will make the APNIC transfer policy equivalent with other RIRs and it will be necessary to conduct an inter-RIR transfer policy.

Andy Linton: Thank you for that.  That, for me, summarizes this fairly well.

Has anybody got any questions or comments here?

OK.  Let's just gauge what the feeling of the room is here.  How many people would be content for us to agree to this proposal that we put this policy back in place?

I'm seeing a number of hands here.  Are there any strong feelings that we should not do this?

The Jabber room or the remote hub in Cambodia, are we hearing anything?

Let me just ask the question again for the Cambodia.

The screens that I have here, I can't see what's going on.  Just a moment.

In Cambodia, how many people are in favour of adopting this proposal?

And how many people are against adopting this proposal?

Can you hear me?  Can someone wave their hand if they can hear me in Cambodia?

George Michaelson (APNIC): Andy, while you are waiting for the network delay effect, there has been one observation on the Jabber chat saying that they are in favour of the proposal.

Andy Linton: I'm not seeing dissent here.  I'm seeing consensus, that people are content for us to proceed with this.  I think it's a good pragmatic decision that we make here and I think we should get on with it.

Yep.  Thank you.

Tomohiro Fujisaki: Thank you.

Andy Linton: I'm declaring we have reached consensus on this.


Andy Linton: Our next item is prop-098, which is Owen DeLong.  It is 2:45, and if we are going to do that flip over to Cambodia at 3:00, I'm conscious, but you won't need that length of time to present.

Owen DeLong: I can present in less than 15 minutes.  I'm not sure how long the discussion afterwards will be.

Andy Linton: We can do Owen's presentation and then we can do the flip over to Cambodia.

George Michaelson (APNIC): There were 13 supporters of the proposal in Cambodia.

Andy Linton: That's fantastic.  Thank you.  I hope you all heard that.  George noted that 13 people in Cambodia, which is probably most of the people there, I think, were in favour of that.  So I think that's quite clear that we're agreed we should do this.

I'll let Owen talk about his optimizing IPv6 allocation strategies (simplified).

Owen DeLong: I apologize, I forgot to update the slide title, but they are the new slides for the new proposal.

Why do we need this?  First of all, I have actually gotten a lot of questions from people since I have been here, believe it or not, on what is a nibble boundary.

For anybody that doesn't know what a nibble boundary is, it's a single hex digit or four bits or half an octet, half a byte, whatever you want to call it, it basically works out to a single hex digit, so it's a single digit in an IPv6 address, so it makes a nice easy division.

It also happens to align with the DNS delegation boundaries in IPv6.

Other reasons we need this: it's meant to address the common misconception that, no matter what size ISP you are, you should fit in a /32 and scale your users down as needed to make that work.  We need to not squeeze networks to make everything fit; instead, we need to expand allocations to meet the needs of the end users.

We have some rather odd aggregation boundaries occasionally rearing their ugly heads and causing people to have to do a lot of bit-math.  While many of the people in this room are very good at bit-math and doing bit-math in their head, there are many people in the world who are not, and many Internet outages have been the result of midnight efforts at bit-math.

Nibble aligned allocations, as I said, get rid of the odd aggregation boundaries.  I'm not sure why I listed that twice.

ISPs can choose any minimum allocation unit they want.  They are not restricted.  This is not me telling you how to run your network.  This is not a policy proposal to try and tell you how to run your network.

This is a policy proposal to try and give you much more flexibility in how you design and run your network and allow you to get enough space to run it the way you want to.

You have the ability to assign more than a /48 to a given end site if you can justify that an end site needs that.

It allows you to define serving site to fit your topology.  Whether that's a POP or an aggregation router or a co-location facility is entirely up to you.  The policy is very flexible in this regard and it allows you to align that where it makes the most sense for your network and allows you to do the best aggregation in your routing infrastructure.

This actually allows you to reserve some fairly vast amounts of room for growth, by combining both a 25 per cent minimum free space in your overall allocation as well as providing for things to be on nibble boundaries at two levels of scaling with a significant round up at each of those levels possible.

It allows you a five-year planning horizon, so hopefully that will contribute to better aggregation as well and it provides consistent sized divisions so that you don't have to worry about carving your address space up into different sizes for all of your smaller versus larger POPs.  You can say, OK, my largest POP needs a /36, therefore I need a /36 for every POP and just go forth and do it that way.

It simplifies your subdivisions and it reduces your likelihood of fragmentation.  It provides consistent expectations across your network.

You are not required to do it this way, it provides you the option of doing it that way.  You can do anything smaller that you want to any of your POPs.

It allows for asymmetric growth in your POPs.  If you get to 90 per cent utilization at a single site or 75 per cent overall utilization, you can get more space.

If you run out of the number of POPs or serving sites, however you define serving site in your particular network, you can get more space.

It allows oversized subsequent allocations.

Basically, if you can't just extend your current allegation from /28 to /24, for example, you get an entire additional /24 to work with, with the idea that you'll make all your future allocations in that additional /24, and if you do eventually vacate the old /28 through attrition, you have the option of returning that.

The downside is it will actually increase IPv6 prefix consumption slightly.  Without this policy, the 50-year estimate based on current allocation policies, the best estimates I have been able to see show that in 50 years IPv6 will still be 99.9975 per cent unallocated.

With this policy, some of the worst case projections that I tried to run, showed that we would actually allocate 0.46 per cent of the IPv6 address space over the next 50 years.

So I really don't think that the address consumption issue here is particularly significant, but if I am wrong, there is an additional safety valve in that if we consume more than a few /12s, we still have a lot of time to react and still have 7/8ths of the total address space reserved for future address policies that can be more restrictive.

Why am I recommending that we look at straight percentages instead of the HD-ratio?  I realize ISPs in this region are well versed in the HD-ratio.  However, it is confusing to a lot of end users and other organizations.  This policy affects both ISPs and end users, so we should make some accommodations there.

I think everybody understands percentages reasonably well.  For medium to large networks, this works out very close to the same numbers with the included round-ups and minimum free calculations that are built into the policy.  For smaller networks, the HD-ratio actually penalizes them.  They actually have to get much denser utilization before they can get more space.

In summary, I believe this policy provides for better aggregation, it allows you to have more flexibility in better structuring your network to meet the needs in your environment, hopefully it can lead to fewer outages by not requiring operators to do as much bit-math in their head late at night in emergency maintenance windows, it provides for bigger prefixes and this should allow better aggregation and faster deployment.

There should still be plenty of free space for way more than 50 years.  So I think we're OK there.

At this point, I'll pass it back to Andy for the discussion.

Andy Linton: Thanks, Owen.  That's a good, clear explanation of what you're proposing.

I certainly don't believe we have squeezed Owen's time there.  It's only 2:55, so that's worked out quite well.

Owen, do you want to stay up there in case there are questions or what do you want to do?

Owen DeLong: I can stay up here.

Andy Linton: I think it's probably useful to do that.

Has anybody got any questions on this?

In these things, if you can actually let us know whether you support or oppose a particular proposal or if you don't, if it's neutral.

Lorenzo Colitti (Google): Speaking mostly in a personal capacity, I do not support this.  I think there is a risk of encouraging people to be lazy when designing their address plans.  If you look at the amount of space that Google has, we are being quite conservative, and we have a fairly large network.

I don't think we should be trying to do something that will increase the chance of this industry having to go through a very painful transition again 30 years from now, because 30 years ago, we basically said, yeah, it will last forever, same as we're saying now.

I don't know that the advantages in terms of easier ways to think about your network actually outweigh the risk of us limiting the lifetime of this thing that we haven't even deployed yet.

Andy Linton: Thank you.

Izumi Okutani (JPNIC): There are bits and pieces of this proposal that we can support, but we still have some concerns, so I asked around about the nibble boundary and it seems that most people feel that making allocation size based on nibble boundaries is useful, so we support this part of the proposal, but with the rest there are some concerns.  We don't really hear that we need a change from HD-ratio based allocation, at least from operators in Japan.

From the perspective of the Hostmaster, I also discussed with the JPNIC Hostmaster that it might make the criteria a little bit vague on how much space we have actually given out.  HD-ratio is a really transparent way, so we can explain to other ISPs why we have distributed a certain size, whereas this one gives a lot of flexibility on the size and leaves a lot of decision on the side of the applicant.  That might be a good thing, but then, we have that concern from the administration point of view.

So if people feel that we should go ahead with this and support it, we want to ensure that it allows APNIC and NIR Hostmaster to ask for justification on why they require certain size for -- I can't remember the exact term, was it serving unit? -- why you need a certain size for the serving unit, which might actually cause more administrative work and documentation necessary than the current HD-ratio criteria.

As a whole, like as a whole part, we are against this proposal and we support the part about changing the size based on making allocations based on nibble boundary.

Andy Linton: Owen, do you want to comment on any of this?

Owen DeLong: Yeah, I would like to comment on that.

I think the serving site thing is actually relatively clear.  It's based on the number of provider allocation units that you assign out of a serving site, so if a serving site serves 12,000 end sites, then you count that as 12,000 provider allocation units, unless they can justify a larger end site in some cases and you count that up and you figure out that as a percentage of the particular nibble that you're going to allocate, say it's 12 bits or whatever, and if it's more than 75 per cent, then you round up to the next nibble.  It's just that simple.

Andy Linton: OK.  Gaurab.

Gaurab Raj Upadhaya (Limelight Networks): Speaking in my individual capacity, there are two things on this proposal that I'm not really in favour of.  (a), I agree with Lorenzo, we are not learning from history.  I was not there 30 years ago, but I have read plenty and heard plenty that they thought that 4 kilobytes of RAM was enough and 32 bits of address space was enough.

Maybe we are not learning from that mistake.  So I agree with Lorenzo, why do you need to do it.

But at the same time, are we going back to becoming a glass full on addressing again, because RFC 2050 -- thanks, Andy, for putting that up -- I read it up and now realize that it explicitly says it should be on CIDR, not something else.  Right?

I have to go and say that we'll not follow what's there, there's other things about demonstrated needs and slow start and a bunch of stuff in that RFC, and this proposal goes against some of those principles.  That is (a), whether it is worth going on a nibble boundary.

The other reason that I oppose this is I'm very much against setting this kind of limit with a policy on something that could be very administrative in nature.

Today APNIC has a /12, they have a limit, they do the reservation, they do binary chop, if we need to change the boundary to, say, we will do it on a CIDR, they are restricted, they can't do it.

If there is a certain address space left at the end of next five years, on the current /12, which can't be allocated on a nibble boundary, then they are stuck.  It will be like the situation we have with IANA now where they can't allocate anything smaller than a /8 because there is a policy there that says, "IANA will only delegate at /8s."  We put that condition in there instead of saying they can allocate whatever they have.

On that basis, on that principle, I'm very much against setting a policy that hard codes what size APNIC can allocate.  I think that this is a completely operational matter.  We could give suggestions and it could be something for the working group to decide on how we decide on this, but setting it as a policy I think is a bad idea, because then we will have to find another policy, maybe 30 years from now, to change it and why do we want to do that, because we just have an example that we are going through with prop-069 and other proposals, that's trying to change the fixed limit that we don't want.


Owen DeLong: If I can address that, Andy.

Gaurab, I would like to point out that the smallest nibble boundary that this allows for is a /36, and the current policy only allows APNIC to allocate on /32s.

Gaurab Raj Upadhaya (Limelight Networks): I have a /48 from APNIC.

Owen DeLong: Yes, this isn't intended to affect the end user /48 policy, but the smallest ISP allocation that they give out now is a /32.

Gaurab Raj Upadhaya (Limelight Networks): I think in APNIC now it's called a delegation now, instead of assignment or allocation.  But the principle is the same.  It is a policy for the Hostmaster to set, and that is probably coming back to what Izumi said, if it complicates matters for the Hostmasters, it means it burdens the end user with more documents, and we just heard from Izumi on that.

That's the basis of my -- I think it's a good idea.

We probably do a lot of nibble boundary stuff on most of our planning, but on a policy level, I'm pretty much opposed to it on that basis.  Thanks.

Andy Linton: OK.  Thanks for that.

I'm just conscious that I got a sign from Randy at the back there which I assume means it's 3:00.  We have scouts out in Cambodia who are going to tell us when our visitor arrives, so we should be OK.

Sanjaya, go ahead.

Sanjaya (APNIC): I'm neutral, neither pro or con, to this proposal.  I just need some clarification on the subsequent request 75 per cent or 90 per cent, because we set our system to be able to track utilization.  I'm more concerned with 90 per cent utilization at any single site.  So this is assuming the serving site, right?

Owen DeLong: Correct.

Sanjaya (APNIC): Any serving site that reaches 90 per cent they can come?

Owen DeLong: Correct.

Sanjaya (APNIC): That means I have to structure our internal tracking to also consider that there is a thing called serving site.

Owen DeLong: Yes.

Sanjaya (APNIC): OK.  That's all I need.

Jordi Palet (Consulintel): I totally agree with this proposal.  I am doing consultancy for customers in other regions and doing the addressing plan with existing policies which is basically the same in all five RIR regions, it's a real problem.  I really think we should move away in IPv6 from the HD-ratio and I don't share the concerns of the previous people at the mics that we are going to waste again the space.  I don't think we can compare at all the space that we have with IPv4 and IPv6 and I think this is not a valid comparison.

I don't think also that we should have any concern that this is more overhead for the Hostmasters because at the end the Hostmasters need to do whatever the community decides.  I agree that it may mean extra work, but this is something that needs to be worked out at the Hostmaster level.  So that is not a valid reason to be against a proposal.

Andy Linton: OK.  Anybody else?  I'm seeing a mixed thing, probably with people tending towards agreeing with this, but perhaps one or two people have concerns.

I'm also hearing that some people are agreeing with parts of it.  Is that a fair assessment of what's going on?

Randy Whitney (Verizon): It seems that the policy is a little bit too complicated.  Perhaps if you consider splitting off the ratio issue with the other, you might get more consensus.

Andy Linton: Randy, can you get closer to the mic.

Randy Whitney (Verizon): Consider splitting off the EC ratio, removal with the bit nibble boundaries into two policies, perhaps.

Owen DeLong: The difficulty there is that we need some way to measure the utilization at the two different levels, the serving site level and the overreaching level and if you start applying HD-ratio to both of those, it gets pretty strange.  If you start applying percentage to both of those, it works out reasonably well on the boundaries that I have set here.  So that was one of the reasons I went with percentage.  Another reason is, again, if you're not an ISP or a Hostmaster that does this all day long, HD-ratio is actually pretty hard to wrap your head around, in my experience, dealing with a lot of end user organizations and such.

Again, to address a couple of other things I did not mention: this is very similar to ARIN policy 2011-3 which, while it is not yet implemented in the ARIN region, has been ratified by the board of trustees and, as you saw yesterday, is expected to be implemented no later than February 15, I think it is.  John can correct me if I'm wrong.  But I believe it's to be implemented no later than mid February in the ARIN region.

Finally, if we burn through more than a few /12s with this policy, in the next 10 years, I'll be pretty surprised and we still have plenty of room to change the policy before we get into any real trouble.  So with that, I'll turn it back to Andy.

Randy Whitney (Verizon): Basically, I'm in support of the nibble boundaries but not necessarily in support of removing the HD-ratio.  That's my point.

Dean Pemberton (NZNOG): I'm just wondering, will this place any more of a burden on the end users, when they want to come back and apply for slightly more space, will they have to show a justified need for a nibble more space before they get any more or will they just have to show one or two bits more space?

Owen DeLong: For example, if a provider uses a /48 as their end site provider allocation unit, if you have one building, you get one /48.  If you need more than one /48, you'll have to show justification that you need more than one /48 for that building, but you can do that and you can get however many /48s you need for that building.

If you have two buildings, you automatically qualify for two /48s.  If you have five buildings, you automatically qualify for five /48s.  And in fact there isn't consideration in this policy, but I would be perfectly willing to accept that if you have more than one building and less than /12, you get a /44, and if you have more than /12 and less than 192, I think it works out to, you get a /40.

I would not have a problem with adding that to the policy for the end site justifications.  It wasn't considered to scale the end sites up on nibble boundaries because they're kind of individual things.

Dean Pemberton (NZNOG): Thank you.

Andy Linton: OK, thanks for that, all of you.

I understand that our visitor has arrived in Cambodia, so if we could just flip over to the video feed to Cambodia, perhaps we'll take the chance to welcome him and see if there are any questions on this from Cambodia, perhaps, at the same time.

OK.  So I understand that in Cambodia, welcome to you all who have already been there for a large part of the day and I believe we have a visitor, the Secretary to the Cambodian Information Minister Information Minister, his Excellency Ouk Kimseng, so we would like to welcome you to our meeting.  I'm not sure whether you have been to any of our meetings before, but you're very welcome and I am not sure we can actually talk.  We can only do Jabber.  Is that correct, George?

Well, if you would like to say a few words, then we would love to hear.

George Michaelson (APNIC): Anki, the facilitator over there reports that he has no planned speech.

Andy Linton: That's fine.  I have no desire to put anybody on the spot here.  Really all I want to make sure is that we do appreciate you coming to the meeting and taking part in our discussions and listening to what we are doing and welcome you and it's great to have both you and the remote participants in Cambodia and we hope we can do this again soon.  I'm certainly looking forward to our meeting roughly this time next year in Cambodia.  I believe that's what's happening.  I hope I'm not giving any secrets away here, but certainly I'm looking forward to that.

George has some message for us here.

George Michaelson (APNIC): Yes, I have two observations, not from Cambodia, to the meeting from the Jabber chat.

The first is from Yu Chi from Sprint, he wishes to say that he supports delegation on nibble boundaries, but is against the 90 per cent rule for one side, which he thinks would encourage bad planning, so that is one observation.

Separately, Vantha from Cambodia, it is a Cambodian participant, who works at easy.com would like to confirm if the /36 is propagatable when the /32 is the default minimum allocation from APNIC.

Andy Linton: OK.  I'm going to let Owen come back to the stand here and have a go at those two comments and questions.

Owen DeLong: It's hard for me to predict what he means by the 90 per cent at an end site would facilitate bad planning.  What I'm trying to say is that you don't have to get completely full up across your whole network, you don't have to move address space around, if you fill up one POP to the 90 per cent point, you can expand everything to try and make that easier to aggregate.  To the gentleman from Cambodia, RIRs don't run routers other than a very small subset of them that control the actual ability of the RIR to reach the Internet.  So I don't think they have a lot of control over what is allowed into the routing table out in ISP land.  I would expect that some equilibrium will be reached in routing land among what people are trying to advertise and what is accepted, but I don't think that RIR policy can significantly affect that directly or really influence it.

Andy Linton: OK.  George, if you hear any more from the Jabber chat based on what we're saying, you'll let us know, I'm quite sure.

So what I'm hearing here is that the vast majority of people who have spoken are in favour of the idea of the nibble boundary.  I think we had one person who was not so happy about that.  But there is some concern about the change from an HD-ratio assessment to the averages assessment.

So it might be interesting, this has been adopted in the ARIN region and I know Owen is going to say it's a good idea, but is there anybody else in the ARIN region who is here who has been involved in this who would like to make a comment on that about why they adopted it or why they felt it was a reasonable stance.

We are familiar with the HD, but we are not familiar with the averages.

Owen DeLong: One clarifications, it's not averages, it's a straight percentage of each site and a straight percentage overall.

Andy Linton: My apologies on that.  It's a percentage, yes.

David Farmer (ARIN AC): This policy doesn't stand on itself in the ARIN region.  There was another policy that we started with v6 allocations for end users and that's where we started asking the question for end users as to whether they understood what an HD-ratio was and how it affected their allocations and HD-ratio -- I personally think the HD-ratio makes a lot of sense for an ISP allocation where the ISP is delegating to a large number of end users.

In an end user situation, the end user is consuming resources within their network and unless they have a large number of buildings or a large number of whatever units you carve up under, HD-ratio gets rather complicated and so what does it mean to meet the HD-ratio for an end user's assignment?  The HD-ratio on the number 64 is being used, the number 48s being used.

So there was a whole number of questions and within the ARIN policy, it was extremely unclear.  So that's where we ended up with the percentage because end users seemed to understand that much better and we could conceptualize it better.

The other thing that is part of that end user policy, a site was clarified as being basically a premise, you know, something with an address, et cetera.

So an end user didn't have to fit his entire network in an entire nationwide network just because it was an end user into a /48.  It was much more clear how an end user would get more addresses.

This, then, triggered some questions for the ISP allocations, being more generous to end user allocations.  Well, shouldn't that apply to the ISP allocations?  So that generated this whole other round and as Owen was referring to, with the round-up from nibble boundaries and the 75 per cent is equal to or better than the capabilities that HD-ratio gives you, as far as having a useful address space and clearly defined where you can get more address space.  I hope that helps clarify that.

Andy Linton: Thanks for that.

Gaurab, you have something to quote to us.

Gaurab Raj Upadhaya (Limelight Networks): Yes, I'm speaking in an individual capacity.

I'm still opposed, but I like to point out to the members that going from a /32, which costs roughly AU$2,000, to a /31, will increase your fees to $2,600.But if you are forced to receive a /28, then you are going to roughly pay $5,700.  So is that very significant for a lot of our countries?  It basically takes the fees five times whatever your needs might just be an extra /32 and that would be a really big concern for me, because you need a /31, you are being forced to a /28, because the policy says so and suddenly your fees are blown four or five times and that will probably restrict the adoption of v6 because people don't want any more space than a /32.  Thank you.

Andy Linton: OK.  So that would certainly mean implications for the way we do our cost structure if we go down this path, as we stand at the moment.  Is that what you're saying?

Gaurab Raj Upadhaya (Limelight Networks): As a member and as a member representing a lot of small members, it is a big concern for me.  As I said, if I have to pay five times more just to get a little bit of address space which I could get by paying only 150 per cent, that is probably going to stop me from getting more address space even though I need it.  Because cost is a big concern, $5,000 is not cheap.

Andy Linton: Owen, would you like to respond what's happened in ARIN on that.

Owen DeLong: In the ARIN region, the fee structure is quite a bit different from the way APNIC has done the fee structure.  We don't use a logarithmic based on your total aggregate space structure.  So this actually didn't result in a significant cost difference.  I would actually suggest that if this policy is adopted, there probably should be some consideration by APNIC of modifying the fees accordingly because I do agree with Gaurab that that would be a real concern.

Andy Linton: Jordi.

Jordi Palet (Consulintel): Actually, I think that could be sorted in a very easy way.  It's not forcing the members to go to the nibble boundary, they could choose.  That's one possible way.  But in any case, I think it's wrong, totally wrong, to associate the membership fee structure with the policies.  As you just said, this probably will need to be adjusted if this policy proposal is adopted.

But we cannot measure the good and the bad things of a policy depending on the actual fee structures, because that could change anyway even if we don't change the policy.

Sanjaya (APNIC): I am neutral.  Thanks to David Farmer for explaining the motivation behind the discussion in ARIN.

So I would like to highlight the difference between what we have in this region basically with that.

In the portable assignment policy that we have, that has three targets: one is multi-homing assignment; the second one is ISP; the third one is critical infrastructure.  We actually don't require HD-ratio if they want to come back.  They actually consider as given whatever they need at the moment, so if somehow they need more, then they just come back and explain to us, so there's not really a HD-ratio in the policy document.

The HD-ratio is actually applicable to the allocation, which is to the ISPs.  And it seems to me from this discussion that the ISPs are quite happy with the HD-ratio.  The end users are never faced with HD-ratio problem.

Andy Linton: Sanjaya, before you go, in terms of operational impact, what sort of impact would going into a policy like this have?

Sanjaya (APNIC): We track percentage in IPv4, so if we were to implement this, we can track based on percentage, not a problem.  It could be tricky, because we need to track two, you know, not only the overall percentage, but also individual serving side.  It could be more complex, but it's doable.

We need time, of course, to implement, because our calculation now is based on HD-ratio, but it is doable.

Andy Linton: Thank you.

Gaurab Raj Upadhaya (Limelight Networks): I think, finally, Owen and I agree on something on this proposal.

This is a real reason.

I don't agree with Jordi when he says the membership policies should be separate from fees because that's how it's structured.  If you like that, then go out and propose another change in how we do our fees, and I will guarantee it will take at least five years.  So I just wanted to say that.  The fees are a big concern and maybe you want to look at that.

That's why still -- what Jordi said, you can get the member to still only receive a /1 increment, that's what he said first, instead of having to receive the entire /28.  But that's something that is an operational decision.  As has been seen on the mailing list, APNIC already has a sparse allocation, they keep aside a /28.

This policy doesn't change their sparse allocation at all.  If somebody is there, gets their address space, suddenly somebody big buys them or goes around a big expansion, then if they don't fit into the space reserved for them, then they of course have to go and get another block.  So that will never change.

That's why my insistence that rather than trying to define hard code policies, maybe we should try to help the Secretariat and the Hostmasters to define an internal working procedure that would incorporate some of these things as best practices but not be bound by it.  That has been my primary resistance.  I don't want something in a policy that we can't change operationally.  You pass a policy, it's there, the Hostmasters have no recourse to it.

You know, the fees is one, they can't do anything, they have to give a /28 or say go back, we can't give you anything other than a /32.  So that has been my primary objection on this proposal.  As I said, I like some of the concepts, but I don't like this thing hard coded in a policy.

Jordi Palet (Consulintel): Just one small clarification.

What I meant is that the fees are not set up by policy; right?  So you cannot associate both things.

Gaurab Raj Upadhaya (Limelight Networks): But fees are set with address holdings, so that's what we do.

Sala Tamanikaiwaimaro: I would just like the record to reflect that Internet Services Fiji Ltd, if we could go on record saying that we concur with Gaurab's earlier sentiments.  Thank you.

Andy Linton: Thank you.

Izumi Okutani (JPNIC): I was just wondering if we could resolve the issues that you're trying to solve by providing, as Gaurab mentioned, guidelines or explain how things work in terms of reverse DNS setting or also for the HD-ratio calculation rather than changing the policy and criteria, because I think that is also still possible with the current policy.

The impression I got from the explanation from a person from the ARIN region was that it's a little bit different situation we are facing from ARIN region, so I'm not really fully convinced that we should change the policy in our region as ARIN region did.

Andy Linton: Izumi, could you just clarify for me, because earlier you said you liked the idea of the nibble boundary, but you were less enthusiastic about the percentage solution.

Would a solution with the nibble boundary retaining HD-ratio as the calculation, would that work for you; and Owen, would that work for you?

Izumi Okutani (JPNIC): Yes, that would work for me and I do note some concerns over changing the allocation size to nibble boundary as well.  So in that case, I was thinking that maybe we can also, you know, first have them as guidelines for both nibble boundary and also for HD-ratio.

Andy Linton: Thank you.

Owen DeLong: I'm fine with whatever works best for the community.  My goal is to make sure that it is possible for providers in this area to deploy v6 without having to squeeze their customers such that they can fit all their customers in a 32.

Andy Linton: OK.  That's good.  Thank you.

We are getting very close to the time when we're supposed to go and have tea.  I'm not sensing that we're quite ready to make a call on this, but I think we're not very far away from -- unless I have many other people who want to make comments here and I'm not trying to stop this discussion here -- is there anybody else who has comments on this that they would like to bring to this?

What I'm trying to sense is what we want to do here.

I don't want to rush this, I want to give people a chance to think about this.

Let me ask where we are in the room with who is in favour of this proposal?


And who is against this proposal?

I'll ask another question in a moment, who is against this?

I'm certainly seeing more people against this.

Who in the room thinks that if we had a little bit more time or they need some more time to think about this?

Is there anyone here who needs some more time to think about this?  If we have some more discussion on this, will people's minds change or are we pretty much split on this?  I'm seeing not strong support really in either direction.  What support I'm seeing is pretty much split down the middle here.

But I'm also seeing a willingness to explore this.

I'm also seeing that people, a large number of people, this is something that still is worth looking at.

Is that a fair assessment?  Can people give me an indication that that's a fair assessment?  People would like to talk some more about this?

Yes?  No?

There are a few people who would like to talk some more.

Sanjaya (APNIC): May I suggest that because there's some really good ideas, I think, that some people agree with, in part of this, so I would suggest that the good ideas be discussed, further discussed by the working group, incorporated in the working group discussion.  That's just a suggestion.

Andy Linton: Let me ask the room that.  Would people be content for us to take this further, let the working group who are going to look at some of these issues about the larger block allocation look at this and come back and make a report in Delhi?  That doesn't preclude anyone, of course, discussing this on the SIG Policy list if they want to.

I don't think this is a dead issue.  I think there's some life in this and I think we should discuss it, but I don't think we have actually got all the things nutted out here.  That's my impression from the room here.

Gaurab Raj Upadhaya (Limelight Networks): I agree with what Sanjaya said.  Given that we have already proposed a working group -- I definitely like aspects of the proposal, there are things there that are good, like a lot of us have said, but this is probably something that should be discussed in the working group and not done as a policy.  Then you can come back with a big overview, that's what it proposes, do an overhaul of the whole system.  This definitely needs to go to the working group and take the good part out of it and discuss it there, not now, thank you.

Andy Linton: Let me ask the question: how many people think this will a good idea to take to the working group and come back with further information in Delhi on this?

The proposer is saying the same thing.  I think I'm seeing enough people in the room in favour.

Is anybody opposed to that idea?

Thank you, Randy.

Randy Bush (IIJ): Have you seen the ARIN AC?  That's what you're creating.

Andy Linton: OK.  Look.  We will take this to the working group and we'll discuss it and we'll come back with some more background, perhaps a proposal.  We'll look at this again for Delhi and let's see if we can reach a solution on this.

So I think what we'll do now is take a break for tea -- wait a minute.  Somebody has pointed out to me that I have to tell you that the NRO elections will close at 4 pm, so you have about 25 minutes, if you haven't done the work, to do that.  I have a vested interest, so I'm going to tell you this, but other people in the room depend on you exercising your vote too, so that's a good thing to do.

So we'll take a break, we'll come back at 4 o'clock.

This proposal hasn't reached consensus.  We will take it back to the mailing list, but we'll also refer it to the working group.

George Michaelson (APNIC): The Cambodian participants want to record nine people in favour of sending it to the working group.

Andy Linton: They approve sending it to the working group?

Yes, OK.  So that's what we'll do with this.

Adam, have you got what you need?

Adam Gosling: Yes.

Andy Linton: Go and have tea and we'll see you back at 4:00.

Owen DeLong: Thank you.


APNIC 32 Conference
Wednesday, 31 August 2011
16:00 (UTC +9)
Policy SIG

Kilnam Chon: I remind everybody that there is only one more minute left to vote.

(4.00 pm)

Kilnam Chon: The ballot is closed.  Thank you.

Andy Linton: Can I remind you about the review of the ICANN Address Supporting Organization.  The link is on the screen at the moment.  Raimundo tells me you have gone in droves and filled it in, except that only three of you have managed to do that.  Only three people have filled in the review.  If you would do that today or do it soon, because if you are like me, you will get home and think: what was that link?  You will forget about it.  So, please have a go at it.  Some people have said there's quite a lot to do in it, but go and make the comments that you can.

The link is on the agenda page now.  It is up there on the screen right now.  You can click on the asosurvey on the agenda page and that will be there after proceedings have closed.

Moving to the final session, we have two proposals, both of them talking about reservations for large networks.

Prop-099 is our first one.  I think there is a lot of stuff in common with the emphasis behind these two proposals -- the desire to see the ability to assign large networks.  Prop-099 we will hear first, and Xing Li will come and present to us on that.  After that, we will listen to prop-100.

If we move to that one now, we will hear that and have some discussion on it, see where we go with it, then consider prop-100.  Thank you.

Xing Li: Good afternoon.  I am Xing Li, I work for CERNET, China Education Research Network.  My co-authors are Song Jiang from China Telecom, Xiaomin Zhou from China Unicom and Haijin Li from China Mobile.

You may see the proposal already, so here is the chart to illustrate the meaning of that.

First, the problem.  Based on the current APNIC IPv6 address allocation policy, like the first allocation, for example for relatively large sized ISPs, that will be /29.  However, because it is a large ISP there will be headquarters and several POPs.  If, based on this first allocation /29 actually the addresses are getting scattered to the headquarters POP1, POP2, POP3, et cetera.

Later, when the network grows, the ISP will come back to APNIC and ask for the second allocation based on slow start policy, then APNIC will allocate another continuous /29.  However, inside the ISP infrastructure, each POP headquarters is not a continuous address block, so that is the second allocation.

Later, for the third allocation, you can see similar things, and the slow start, so /29, /29, /28.  However, when you get into the ISP's infrastructure you will see scattered addresses for each POP.

Based on this standard allocation, the problem is fragmented space in each POP, resulting in a complex internal routing configuration.  You can see the distributions of those addresses.

This is the problem.

We propose a solution, based on the current allocation policy, but reserving a big pool.

This is the idea: reserve a bigger address space, for example /27, then actually each POP you can treat as a configuration member of this big ISP.  So for the headquarters, POP1, POP2, POP3, they will be noncontinuous allocations, and each one from the reserved space, you can see this plan.

Later, the second allocation, you can see that will grow, starting from each POP and adding more address space for each POP.

So inside each POP the address spaces are continuous.

Later, the third allocation, you can see the gap is filled, so there will be a continuous block back to the original idea, like /27, similar to the original.  So in this method, actually the address space is the same, however this makes the big ISPs have easier internal address allocation management.

You can see this solution: aggregated space in each POP, resulting in a simpler internal routing configuration.

The summary: allow reservation for large IPv6 networks; reservation size based on the network's long-term planning, up to 10 years; the reservation qualification gets reviewed every two years.  So every two years, review this.  If the growing ratio is not as this, then it can change.  And allocations can be made in single/multiple prefixes from the reserved space, as I described earlier.

Here are some questions and answers.

The first one: how many prefixes will we see globally announced from these large networks?  It will roughly correspond to the number of major POPs they have.  The number of prefixes will be reduced over time as the reserved space gets filled.

I can give you an actual number.  For example, because the co-authors are all from mainland China, there are 31 provinces, so for those big ISPs in the initial phase, instead of announcing a single prefix, there will be about 30 prefixes -- no more than that.

The second question is: why not just allocate the whole reserved space upfront?  The answer is that things might change during the five to 10 years planning window.  The reserved place might grow/shrink, so it is best to manage this space as part of the bigger pool available at APNIC during the development stages.

The third question: can the network announce the whole reserved space?  No, definitely not.  Whois will not show the reserved space.  The certification will only be given to the allocated blocks.

Basically, this is my presentation.  Comments or questions?

Owen Delong: I generally support the proposal.  I would like to recommend that this last question and answer be reversed.  I would like to see it done in such a way that the networks can announce the aggregate of the reserved space, at least until there is a need for them not to.  I think polluting the routing table with a bunch of disaggregates, in the hope that they eventually get filled in, is a really bad idea overall.  Making the routing table big up front and hoping it will shrink over time didn't work well in v4 and I see no reason to expect it will work better in v6.

I can see how you could give certificates only to the allocated blocks, but I think that giving an overreaching certificate makes a lot more sense and treating it as an aggregatable block is, I think, better for the community overall.

Other than that one little nip, I actually like the proposal.

Xing Li: Thanks for the comments.  This is to try to make the policy easier.

Izumi Okutani (JPNIC): I can understand the motivation and the intention behind the proposal, and would like to make a couple of clarifications.  One of them was the impact on routing, as Owen has mentioned.  I can see that in the case of China what you call a POP is big enough, for example, for an ISP in Japan.  So it is OK for you to maybe announce it on your POP basis.  But if we simply apply it in the case of Japan, we might have so many small POPs announced, making individual announcements.  So I have concern about that impact.

As a suggestion, to resolve this kind of issue, maybe add a clause saying to allow an independent prefix in the case where the address space would have been announced independently anyway.  So in that case, I can see that it doesn't add any additional concerns on routing.  That's one point.

The second point is I just want to make sure that this doesn't have any effect for APNIC to make additional allocation to IANA, by making these reserves.

It would be nice if somebody from IANA could make a clarification, or could confirm that this wouldn't cause any issue for APNIC to make an additional allocation.

The third is just a suggestion.  It is really difficult to evaluate the needs for 10 years, so it might be more useful to simply just make double or quadruple, so instead of evaluating the number of years, just simply doing it based on the actual allocation you make.

Andy Linton: Thank you.

Matsuzaki Yoshinobu (IIJ): I am generally positive for this proposal, but I have a question: how can you shrink the reserve space once it's allocated?

Xing Li: Are you asking me or APNIC?

Andy Linton: Do you want an answer to that?  OK.  Randy.

Randy Bush (IIJ): I really had promised myself not to go to the mic today.

This proposal and the previous proposal are complex solutions to problems that don't exist.  There is something called iBGP.  You might try it.

This is the internal routing problem.  The allocation is already handled by APNIC's sparse allocation policy.  Maybe there's a visibility problem that APNIC is not making sparse allocation as visible as they might, so people do not perceive it and are therefore trying to make complex policies.  Don't go there.

As far as announcing space that you haven't been allocated -- I'm searching for polite words -- don't announce what you can't sync.

As far as certifying space that you haven't been allocated, anybody who would issue a certificate for space they haven't allocated should have their ability to issue certificates revoked.  Because they are attesting to, signing and certifying a lie.  Don't do it.

Steve Kent (BBN Communications): I'm not making a comment on the policy, but just one of the items that appeared on one of your later slides with regard to certification.

I want to bring to your attention a document that is in the queue to be approved as an RFC, which describes IANA's policy with regard to unallocated and in particular reserved address space, to issue a certificate and a ROA using a convention or associating it with AS number zero, which is making a statement about the address not being in play to pre-empt other unauthenticated assertions about it.  So one could consider using that kind of convention at the RIR, NIR or even ISP level, to deal with an issue of, "I've been allocated a large block of space, I'm not really sub-allocating all of it or using it, and I want to make an assertion through the RPKI that will make sure that anyone else who tries to advertise it won't be believed, even if I'm not advertising that whole chunk at this time."

That's just an observation to keep in mind as a way of dealing with some of the certification issues.

I agree with Randy, though, you should not be issuing certificates for something unless you have allocated it to somebody.  That's really important.

Xing Li: Thanks.

Andy Linton: George.

George Michaelson (APNIC): I have a comment from Jabber, from Matthew Moyle-Croft.  He agrees with Randy Bush: sparse allocation solves this problem and doesn't create a new policy nightmare about reservations.  Such a scheme can work only when the state geographically allocates addresses for their regions and they allocate these addresses geographically between ISPs in each region.

Andy Linton: Thank you.  I heard a comment about sparse allocation.  Perhaps people don't understand exactly what goes on here.

I wonder if I could get Sanjaya to come to the mic and tell us a little bit about what's going on with sparse allocation in APNIC currently.

Sanjaya (APNIC): Probably Geoff will do a better job than me in explaining sparse allocation, but I'll try.

Andy Linton: I saw you; I didn't see Geoff.  Someone from the Secretariat who can explain this clearly to us.  If Geoff wants to do this, that's fine.

Sanjaya (APNIC): Yes, his language skills are much better than mine.

Geoff Huston (APNIC): The way the sparse allocation algorithm works is that I suppose it's best compared to how we used to do v4.  We used to do v4 by looking at the address space as sort of a long piece of tape, and the next person who came off the queue to get address space got ripped off some addresses and were handed them, and the person after got the next.

Not quite like that, because we actually left a little bit of space after each allocation, in case they came back in the near future.

In general, the windows were small.

In v6, it was never clear how big folk were going to get or whether the policies today would be the policies tomorrow.

So, instead, what we argued to IANA, and in this community in around 2003, was that the appropriate allocation was using an algorithm called sparse.  The first allocation starts at address zero but the second allocation actually starts halfway through the block.

In theory, if those were the only two allocations you made, both of them could subsequently come back and get a subsequent allocation right beside.  You can keep on doing that for half the space.

The third allocation would bisect, the fourth allocation would bisect.  So it was just chopping the space in half as we go along.

Basically, what it does is it ensures that every allocation at any point has the maximum amount of expansion space.  We don't need to reserve space because we are not deliberately allocating inside anyone's growth curves, we are deliberately using the /12, which is an enormous amount of space, to ensure that folk can grow at huge rates.

To figure out that we are on the right track, we also simulated -- this was back in 2003 -- the previous few years of v4 allocations if we were running v6 at the time under the policies.  So we were pretty confident that actually this algorithm could have accommodated growth as we understood it then, which is basically growth as we see it now, without necessarily making reservations.

Sparse was intended to cover all this automatically.

In many ways, yes, we do allocate sparse.  If you look at the addresses coming out in v6, you will find that the allocations over and above a /30 in size aren't sequential, they actually jump across the space, because that's the sparse algorithm in practice.

So you are actually maximizing the empty space between each allocation as you go along.  Is that clear?

Andy Linton: I think so.  I'm going to ask a question on behalf of everybody, because it fascinates me.

Where are the current boundaries happening?  If I apply for a /30 today, what's the gap that's likely to be there for me?  I know it will change over time, but what's the current picture, so people get an idea?

I think Sanjaya posted something on this.

Geoff Huston (APNIC): I think the gap is a /24.  We will tag team this.

Sanjaya (APNIC): We know we have some very large members and medium and small members, so we split it into two slices and do the bigger members on one space and the smaller members on the other space.  The smaller one now is down to /24, I think.  That's clarified by George here.

The large space, for the big providers, I think it's /16.  /16 is the largest we can go.

What this means is the next allocation we make would reduce that from a /24 to a /25 and then the /16 becomes a /17.  So it will be halved.

There are eight /16s in the /30, so once we make eight /16 allocations, the next one would get a /17 maximum, and the previous ones would all shrink to a /17.

My point is while sparse allocation helps us to distance the allocation as much as we can, it does not reserve space.

Andy Linton: Thank you both for that.  Randy.

Randy Bush (IIJ): Secretariat, do you think you can make sparse allocation work well enough to meet these needs in this and the previous proposal, without this group having to make complex policy?  The procedures should work.  So I think there's (a) making the procedure visible -- that you have to stand at the microphone now and explain it is a bad sign.  Everybody here should already know it.  I think it would be nice if I, as an APNIC allocatee could go and see what I would get next for my allocation, et cetera, for my next allocation.

What have I got?  What's the allocations out there?

What am I going to get?  And what's the process?

It seems to me that this and the proposal are actually addressing an information and process gap and aren't solving real problems.

Geoff Huston (APNIC): Do you want me to answer this, Andy, because I can answer it directly.

There is a variation on sparse called rate managed sparse.  My understanding is that the allocations that we make are based on 12-month projections.  If folk are growing at a rapid rate, they come back every 12 months, or even faster, for more.  As long as sparse is working, the block maintains being contiguous.  In this variation of the sparse algorithm, called rate managed sparse, the folk who are coming back constantly, you don't bisect their empty space, you actually preserve that.  So that if an ISP, if an account, is growing quickly, you never ever cut off their growth point, you continue to leave the space in sparse, and others who had this -- we came once, got an allocation and haven't come back for five years, you actually bisect their forward space at a faster rate because they are not growing as quickly.

In our simulations of rate managed sparse, we actually managed to look at ISPs which had hundreds of millions -- actually managing to work OK, as against ISPs with only 1 or 2 million, and the algorithm worked.

Indeed, I seem to remember a lass from China, from CNNIC, who had worked on rate managed sparse as well as ourselves at the time and we were pretty confident that if that was the way the policy group wanted to run it, yes, we could accommodate this easily inside the sparse algorithm.

Andy Linton: Just clarify for me one more thing.  In effect, what you are saying is if you go into the rate managed sparse mechanism, that that block for the fast growing ISPs in some way is reserved.

Geoff Huston (APNIC): It never gets bisected.  As long as you keep coming back every 12 months, because you are growing like crazy, you don't bisect the forward space, no.  You can call it reserved, but it's not formally reserved, it's just space in sparse.

Andy Linton: I understand.  Thank you.

Izumi Okutani (JPNIC): This question is related to what I want to say.

I agree with Randy's points and according to Geoff's explanation, it seems more reasonable to me to be able to extend the current -- you don't call it reservation, but sparse allocation practice that APNIC does.  If this practice can meet the needs that are being proposed, I think it is preferable to extend the current practice and maybe make some change, rather than make a formal policy about reservation.

I have a question to Prof Xing Li: do you think that extending the current practice on sparse allocation can meet your needs?

Xing Li: Well, it seems as I understand the sparse algorithm, I believe there is a probability that it will not work.  So I'm not sure if they are 100 per cent the algorithm can guarantee this policy.  Still I'm thinking it is better to have a policy.

If the APNIC practice is using the policy without a formal name of "policy" then it's better to make it transparent and open, rather than an internal thing.  So that's my point.

Owen Delong: I actually think this policy addresses a completely different issue from what the sparse allocation methodology at the RIR level addresses.  This policy allows for a large enough reservation with separate allocations, much like the proposal that I put forward, prop-098, allowed for a large allocation to an ISP so they can improve their internal aggregation within their own routing domain.  Because with IPv6, we will see scaling limits not only at the IDR level but also at the internal IGP level.

I think this proposal and/or prop-098 both seek to address the internal scaling limits, that networks that haven't yet deployed very much v6 may not have experienced or noticed yet.

With all due respect to Randy, who I know has deployed quite a bit of v6 in his network, I'm surprised he's not seeing this issue, but we very much are seeing it at Hurricane Electric, where we tried to do /37s for most of our tunnel brokers and outgrew the /37s in a lot of places and we only have room to do /38s in other places and we have users who are saying, well, you can't get a /48 here, you have to go over there, because we are out of /48s in this place.

All the mix and match we are having to do because we couldn't get a large enough allocation to do proper sparse allocation internally to properly aggregate things and move them around better within our IGP arena.

I think two separate issues are being discussed, we do need policy changes to deal with the needs for internal aggregation.

Xing Li: I fully agree.  Thanks.

Paul Wilson (APNIC): A couple of comments that clarify some of the internal practices and relationship with our global policy for IANA allocations.

We at APNIC historically have traditionally employed reservations often within -- we had previously often employed reservations within IPv4 distribution for the sake of aggregation of following future allocations.

Those reservations were never declared, they were only used internally and they were documented internally for the sake, as I say, where we could, of improving aggregation.

I think that represents a pretty common RIR practice.  In fact, in the global policy for IANA IPv4 allocations and in fact for IANA's IPv6 allocations, the policy specifically says that reservations are the internal administrative decision of the RIR, according to the RIR's own practices.

According to those global policies, reserved space, however we choose to reserve it, is simply considered to be allocated, not available for -- not free, and therefore treated like allocations in terms of whether or not we qualify for the next allocation.

Under IPv6, we need to have reserved or allocated 50 per cent of our current /12 before we go for the next block.

That's point number one.

Point number two is that, as Sanjaya said, we are doing sparse allocations, we are not doing reservations in IPv6.

The point we are at now, the largest new allocation or reservation we could make, within our sparse pool, is a /17.  So tomorrow we could immediately reserve /17 blocks discontiguous for the purpose of these large ISPs.

Now, we can only reserve /17s.  We would need a new /12 from IANA in order to make larger reservations -- whether or not those reservations are justified, I won't comment.

We can't get a new /12 until we have reserved or allocated half of the current /12.  We could go straight home and reserve a whole stack of IPv6 address spaces to the extent that we are qualified for another /12 to allow ourselves to make the larger future allocations, but I think that may be considered to be gaming the system, to be artificially reserving for the sake of getting more space from IANA and then I assume unreserving that space and going back to normal.

When the concept of large reservations came up, and it came from discussions that were going on in China, for the sake of really long-term aggregation management, I think it does seem beyond our current accepted practices, for APNIC to suddenly start reserving very large amounts of address space.  To have reservations and the need for some degree of large reservation, to have that need recognized in the Policy SIG here would be quite helpful, because I don't think we want to go and shock the world by suddenly requesting more space from IANA, without explanation or without internal process, because the common assumption about IPv6 is that none of the RIRs are going to be going back for another /12 for a long, long time.

In short, if we suddenly go back to IANA on any basis, let alone on a basis of some sort of artificial excess reservation for the sake of getting larger pools, I think that would, as I say, shock the world in terms of what exactly APNIC is doing.

I think it would be useful in terms of the way we are doing our work for the freedom for APNIC staff, if we are given the freedom, to make those large reservations, for that freedom to be approved or enshrined in the policy process somehow would be useful.

I'm not going to propose how that should be done.

Xing Li has come along with a proposal that allows it, but whether or not it's the right proposal, I won't comment on that.

I'm trying to give the background in terms of the dynamics of our reservation practice versus the global policy of how we get space from IANA and whether we can suddenly receive this additional space in order to fulfil these needs.

Skeeve Stevens (eintellego): For the information of the room and perspective, do you know the percentage we are currently at?

Paul Wilson (APNIC): I don't, I'm sorry.

Andy Linton: Thanks for that, Paul.

Paul Wilson (APNIC): It's low.

George Michaelson (APNIC): I have a comment from Jabber.

This is from CVP RIPE.  It may be a new name of address allocations: geographical, aggregated, provider independent; that is, apply this policy not to PA but to PI.

Andy Linton: Thank you.

Izumi Okutani (JPNIC): Thank you, Paul, for clarifying the question I was going to ask.  I would like to confirm that if we implement this policy as it is clearly written that we will reserve a fixed amount of space then that would still allow APNIC to make subsequent allocations to IANA, and that doesn't really stop us from requesting, so that should get approved.  Thank you, I just wanted to clarify that point.

Andy Linton: James.

James Spenceley (APNIC EC): Have we considered the fact that maybe we are trying to fit -- to use an analogy -- a square peg in a round hole?  The issue seems to be the horizon for which we are letting people request address space.  In reality, in a year's time or two years' time, IPv6 will still not be fully deployed, we are talking a 10-year horizon.  Perhaps if we allow people to request space for a much longer period, it will solve a bunch of problems that policies are trying to resolve.  It will simplify the allocation procedure.  If you want to request 10 years of space, request 10 years of space.

For the larger countries, a /23 or a /24 will allow a /56 for every person in the population.

If you think your ISP needs to support the entire country in 10 years, request a /23 today.  I think this policy is probably shoe horned from a world where we particularly needed to conserve and base around a very short horizon because we were operating in an address environment that was growing significantly day to day.

The IPv6 space probably isn't growing at the same rate that IPv4 grew at any point in its lifetime at the moment.  Maybe as a room we could consider expanding that horizon to 10 years.

Andy Linton: Thank you, James.

Anybody else who wants to speak?

Masato Yamanishi (SoftBank): Let me ask one question for clarification.  In this proposal, you have simply used POP, but I think POP means several levels, like buildings or cities or prefectures or states or in some cases countries.

In your idea what have you assumed?  How many POPs have you assumed in this case?  I think it is very good information for us.

Xing Li: Here, POP means the POP which the customer that POP serves.  For example, in China that's the province, like Hebei province, which is 20 or 30 million people, so that's the POP.  I also answered, in mainland China there are 31 provinces, so there will be roughly 30-something POPs for each ISP.

Masato Yamanishi (SoftBank): How many provinces do you have in China?

Xing Li: Thirty-one.

James Spenceley (APNIC EC): I have a question for the author based on my previous comment.  How much address space do you think you require for your 10-year horizon?

What would you ideally like to see allocated that would solve all of your address problems?

Xing Li: That's basically the -- for example, in China, I'm from the education network, our network is not big, but China Telecom -- I can give you the numbers -- currently they have about 300 million subscribers, and there will be 10 million new subscribers adding each year.  So that's China Telecom's figure, so you can estimate.

James Spenceley (APNIC EC): In 10 years, how much address space -- what would you request?  Would you request a /23?  Would you request a /20?  I'm trying to understand how much address space would solve all your problems, rather than creating reservation policies or debating sparse allocation problem.

Xing Li: Well, for China Telecom, for 10 years, probably maybe reaching /17.  I believe.

James Spenceley (APNIC EC): I think addressing people's needs based on a longer horizon is quite a sensible policy.  I think this might be something we should explore.  If you can demonstrate in 10 years a need for a /17, we should allocate a /17.

Andy Linton: James, are you concerned about this policy because, while it talks about a 10-year horizon, it's overly complex?

James Spenceley (APNIC EC): I'm concerned in general that we are over-complicating an existing allocation policy.

I think we should be giving people the amount of address space they need on a much longer horizon, and this solves every issue we discussed today, we no longer need sparse or reservation -- people get the address space they need.  It solves a number of issues with developing nations worrying they don't get the amount of address space they need in the future, they get it today.  If they want to pay for the address space, they get the address space today.

Dean Pemberton (NZNOG): I am interested in the point that James is bringing up and whether allowing people to look at a much longer space, like 10 years, and allocate on that, whether that would be problematic for the community.  Without wanting to start talking about a proposal that hasn't even been proposed, would people be vehemently opposed to that and it's not even worth thinking about or would it (a) solve the problem proposed here and (b) would it be palatable to the community?  I would be interested in that.

Izumi Okutani (JPNIC): I generally like the idea of approving what's required beyond the needs of two years, if it can be justified.  But I don't really see much point of justifying two years', five years', 10 years' needs, because if it's difficult to estimate the needs for two years, then it's the same for five years or 10 years.

My suggestion is maybe make the default two years, as it is in the policy today, but in case the requester can clearly justify the need beyond those years and say that they have a concrete plan for a long-term future, then I think we should allow some room to approve the allocation that is needed beyond two years.  That's my suggestion.

Andy Linton: Has anybody else got anything they want to add here?

If nobody else has any other comments, I'm going to try to get a feeling from the room.

The discussions I'm hearing here are some people think this is too complicated and some people are saying that predicting the future is a pretty hard thing to do.

We are also hearing from James and perhaps Dean that perhaps a simpler thing, which was just defining what you want over the next 10 years and getting it.

Although that has some implications for costs, because if you get the block assigned to you, you would be paying for it upfront, I think.

James Spenceley (APNIC EC): I think the feedback here is you stop people asking for more address space than they need because they will have to pay for it.  If you truly believe you will need it, you will pay for it.  If you don't need it, you are unlikely to request more than you need.

George Michaelson (APNIC): I have a Jabber comment from Yi Chu from Sprint.  The RIRs have 10,000 members in total.  Do all of them get a /17?  There are only 120,000 /17s in the v6 space.  Giving out a /17 now that we have not started with v6 is reckless.  10-year projections is just black magic.

James Spenceley (APNIC EC): I think we proposed China Telecom as quite possibly the largest network and user of address space over the next 10 years would get a /17.

I think if Australian ISPs were to request a /17, that would be slightly unreasonable, given that they couldn't number the entire world over.

Is it ridiculous?  Is it black magic?  I don't think it is.  It's a new way of thinking of about things, maybe it's a simple way to think about things.  Maybe the maximum limit is you only get enough address space to number your entire country, and a /17 would qualify for no countries probably.

Lorenzo Colitti (Google): ISP A makes a 10-year projection and gets a /17 and ISP B makes a 10-year projection and gets a /17.  ISP A buys ISP B.  We now have two /17s.

Do they really cost money?  The comment from the floor was they are paying for both.

James Spenceley (APNIC EC): It may make sense if we start talking about millions of end users, rather than /16s or /17s.  We did some math with Geoff earlier, a /23 is 2 billion /56s.  Talking end users makes the whole thing move more into perspective.

Andy Linton: I don't think we have done this to death in any way at all, but I am trying to gauge from the room where we are and see where we go.

The Cambodians haven't made any comments to Jabber, George?  I'm assuming you will give us those every time they come in.

Clearly some people are in favour, some people aren't.  Let's see where we are with this.  Who is in favour of this proposal as it stands or perhaps with some minor changes?

A small number.

Cambodia?  I am seeing a hand up there.  I'm not sure.

George Michaelson (APNIC): I have a comment from Vantha in Cambodia: do we know how long sparse allocation will be preserved for /32 allocations?

Andy Linton: Perhaps you can give us a guess on that, George.

George Michaelson (APNIC): A long, long time.

Andy Linton: All those who are against this proposal as it stands?

Well, a similar number are opposed and against.

Nobody is really very excited about this.  I'm seeing a few people who are for, a few people who are against and a large number of people who don't know, don't understand.

Maybe people don't care about this.

George Michaelson (APNIC): We have two in favour in Cambodia and eight opposed.

Andy Linton: See how decisive they are in Cambodia, whereas we are all fence sitting here.

I'm certainly not seeing consensus on this.  I'm not seeing that people are really, really keen on this.

I'm guessing this is a discussion -- I don't think it has gone away.  We are certainly not reaching consensus.  Would people like to take it back to the mailing list and talk some more about it?

I don't want to keep lobbing these over the wall to the working group, because I don't think that's a default solution that I want to give to everything.

This is something that the whole community needs to discuss.  People have come with proposals about dealing with very large allocations, we are about to hear another one, so would people like to continue to talk about this?  I'm seeing some nods.  Can you put up your hand if you would like to continue talking about this?

One or two.  I'm seeing more support for that than I am for proceeding.  Dean, do you want to make a comment about this?

Dean Pemberton (NZNOG): I think you are right, we are seeing at least two communities coming here with what amounts to the same problem.  So we should look at a way of helping them address that.  If we haven't found it yet, then we should talk more about it and make sure we can solve the problem.

Andy Linton: OK.  Adam, do you have what you need in decision terms?

Adam Gosling: To go back to the mailing list?

Andy Linton: Let's go back to the mailing list, and we will revisit this or something like it at some point in the future.

I'm quite sure that the famous working group will think about these things, because it is part of what we talked about.

I don't want that always to be our default position, I want you people to be able to reach decisions as well, because I think that's what we are here for.

Thank you for the proposal.

We have one more proposal, which is for the national IP address plan allocation of country-wide IP address blocks, which is actually addressing effectively a problem that is similar.

We got from Xing Li that the POPs referred to in his proposal were very large geographic units within China.

For many of us, each of those geographic units is bigger than our countries.

I am going to ask Mr Agarwal to come and talk about his proposal, prop-100.  I know this has generated a lot of attention on the list.  They have restructured this and put together a different proposal.  So that's what we will hear about now.

Let's hear what they have to say on this.

Thank you.

Rakesh Mohan Agarwal: Very good evening to you all.

Myself, RM Agarwal, author of the proposal, and BK Nath, my colleague.

First of all, I would like to once again clarify that this proposal is for all the communities in the APNIC region, not only for the Indian community.

I will not go into the interpretive part of the proposal, as much has been said about prop-098 and prop-099.  My proposal is just the opposite of what prop-098 and prop-099 have already said, so I won't cover those parts that have been covered by prop-099.

Basically, right now, two problems we are forcing: contiguous IPv6 address block allocation is not ensured by APNIC to different organizations within an economy when they go back to APNIC for further allocation, that is applying after more than one year.

I think this problem has been taken care of by prop-098 as well as prop-099.

The second issue is no provision of reservation of IPv6 address space for organizations, both present and future -- by the way, I am adding this future organizations -- in economies who are not in a position or not aware to ask for addresses at present.  Many of the developing economies are still not aware of the problems faced by them and how many addresses may be required by them.

Of course, as far as positions in other RIR regions is concerned, no other RIRs presently have a program to assess the needs of individual economies in their region and reserve appropriately sized address blocks.

However, economies in other RIRs may have similar needs and a similar program of assessment may be appropriate for them also.

Directly coming to the proposal, prop-100 details: the focus of the proposal is to ensure that all economies and the different present and future organizations in those economies, will get a suitable share of the IPv6 address space, whether they need it now or at a later date.

Of course, in addition to it, reservation of suitable sized address blocks by APNIC for different economies to be used by different organizations, both present and future, in those economies.

Once we take the different types of economies, it can be further divided into two parts; economies which have NIRs and economies which do not have NIRs.  So the implementation would be easier for the economies which have NIRs.

As far as implementation mechanism by APNIC, because so many things have to be done by APNIC, definitely this needs more time.  There could be many factors which could be taken into consideration for assessing the IPv6 address needs of different economies.  These factors would help to make an aggregate estimate of the present and future IPv6 address requirements of all organizations and stakeholders in each economy.

Because it needs a detailed analysis, some of the proposed ways that we have indicated are like this: firstly, analysis and projection of requirements.  It can be done by APNIC, it can be done by any representative body in that economy or any other mechanism deemed fit by the APNIC Secretariat or the APNIC economic community.

Once we talk of reservation, how they will make the reservation, the reservation of suitable sized address blocks by APNIC for different economies, APNIC may also keep some suitable sized blocks unreserved for any sudden unforeseen requirements in future.

Allocation of reserved IPv6 address blocks -- that is the third part of the implementation.  Allocation of addresses from reserved blocks may be done directly by APNIC or through an NIR.  As I said, where the NIR is there, addresses can be allocated to the NIR and it can be further assigned or allocated by the NIR.

As far as this assessment, survey analysis is concerned, we have done a study in India.  It is an empirical, very basic study.  As India has a population of 1.2 billion now, and taking 20 years into account -- some people have taken five years and some 10 years -- we have taken 20 years into account, the projected population is 1.5 billion.  Right now, one project is going on, Unique Identification Development Authority of India, according to which each and every individual will be requiring an independent IP address and they may be requiring multi-addresses also.

Of course, the IPv6 deployment is in a very fast stage in our country.  Already one IPv6 Task Force is there.  All major service providers have been given a task, they have to ensure IPv6 services are started by December 2011.  All organizations, public and private also, they are supposed to start IPv6 services by March 2012.

Taking advantage of those IPv6 services, all these applications are the main advantage of IPv6: the smart buildings, smart grids, tele-education, these pilot projects are going on in a big way.  In 20 years' time, we understand a major part will be covered through these applications, so many addresses will be required for all those envisaged IPv6 applications.

Right now, the number of organizations, including everyone, is 27 million in India and we expect this to be 50 million in the next 20 years.

From feedback from service providers and other organizations, the figures are shown above: it is estimated that India will require initially at least a /16 address block for meeting all the needs of different organizations and stakeholders in the country.

This is a very empirical study done by a group in India.  On the same basis, these studies can be done by APNIC, by the economy or any other mechanism deemed fit by APNIC.

Basically, we are trying to say that everybody is saying that the addresses are in abundance, but from the discussions going on in this forum, people are talking of one year, two years, five years or 10 years -- one spoke about addresses for 400 years or more years -- but we never know how many devices, how technology will change and how fast the addresses will be exhausted.  So from the very beginning, we should have planning closely with us.

This proposal is nothing but a concept of very good planning.  In RIRs, addresses have been allocated by IANA, and /12 has been allocated to all the RIRs.

Suppose we take up this planning for all the economies, so we will have a very good concept paper of what is the economic requirement today, what is the different requirement of different economies and what it will be after 10 years or 20 years.  Definitely it must be planned.

So the planning time should take a longer period, not two years or just five years, it should be planned for 10 years, 20 years, 50 years.

Once IPv6 addresses are there in abundance, why should we not plan for a longer period?  Once we have these, the networks should be planned in a similar way.

This is our proposal details.  The advantages: the role of APNIC will be expanded to include planning and assessment of the aggregated requirements of the larger Internet for all economies in the APNIC region.  This will give a boost to IPv6 deployment in APNIC region because APNIC will have one-to-one dialogue with all the economies in the APNIC region.

There are 53 economies, and I think the moment of this IPv6 and IPv6 technology is going on only in some 20 or 25 countries, so not every APNIC economy will be very aware.

Through this APNIC forum, each and every country can be made aware, and this is the mandate given to APNIC also.  So through these things it can be expanded and APNIC will have a larger role to play in these economies.

APNIC will be in a better position to project suitable requirements to IANA.  Paul Wilson also said yes, but of course, how can we reflect this requirement to IANA, once we don't have any study with us?  Through the studies and different databases we can project a requirement in a better way to IANA for future reservation of IPv6 blocks for all organizations and stakeholders in different economies of APNIC region.

Suppose somebody asks for /16, /17 or /13, the addresses will be adjusted very soon and the economies who are not able to project their requirement right now may have a problem in the future.  Through this process, at least all economies will be taken care of.

Once this study is completed, the economies and organizations will have a fair idea of future allocations and they can plan accordingly with long-term perspective for IPv6 deployment.

Because this job is too large, and it is a short-term workload, there is a slow speed, and completing the study make take one or two years, because short-term workload and financial implications will be there for APNIC for analyzing and projection studies, training and awareness.  Of course, these should not be a constraint because otherwise also APNIC has to work for IPv6 awareness and its deployment in all economies in APNIC region.

This will be beneficial for the future of APNIC and IANA and the community of the Internet world in the larger shape.

As I said, this proposal is a futuristic proposal, so implementation schedule definitely is not for today, it's for tomorrow.  There are certain operational issues in different economies, like assessment and projection studies for various organizations, present and future.

As I said, it is the initial point, that for the countries where NIRs are existing right now, this can be implemented, in case the studies can be completed in the countries where NIRs are existing, this can be implemented on IP addresses.  If those countries can project their requirements for data, the blocks can be given to them or reserved for them by APNIC and addresses can be given by them.

I am just trying to say what prop-099 is saying.

Prop-099 is saying that the NIRs should be given addresses, addresses should be reserved for them.  But my proposal says, yes, studies will be undertaken of all the organizations, all the service providers, all the individual stakeholders in the country, and the aggregated requirement of all those organizations as stakeholders will be taken together and it will be done in a country block.  It is not like a block will given to the country.  A block will be given to individual organizations and individual stakeholders only.  I was misunderstood -- it may have been my fault -- but the block will be given to the individual organization only, but a country-wide block will be reserved, which can be done either at the NIR level or at the APNIC level.

As far as implementation is concerned, such issues will need deliberations and also time for collection of facts and figures from various stakeholders in different economies of APNIC region.  Other RIRs -- as I said, this is the new approach so other RIRs may also be able to be considered in this process.

The timeframe, of course, once it is approved, the timeframe for such a proposal, our understanding is three months APNIC may require to finalize the methodology, how this process will go ahead, how to take up the project.  Of course, six to nine months for assessment, evaluation and projections for IPv6 addresses for different economies.

Summarizing the proposal, prop-100 suggests a shift from immediate needs-based IPv6 policy framework to forward looking long-term planning based policy framework in APNIC region.  That is the first point.

Reservation of suitably sized IPv6 address blocks for all economies in the APNIC region for further allocation to organizations, existing and future, and other stakeholders from these economies.

Of course, finally, APNIC to carry out assessment studies to estimate the need for IPv6 addresses to be used by organizations and other stakeholders, present and future, in all economies.

That is from my side, and I invite questions.

Andy Linton: Before we go to comments and questions, Kilnam Chon has a result from the election.

I understand he has to go.  So if we can do that, get that out of the way, then we will pick up the discussion.  If we can do that, a brief interruption.

Kilnam Chon: There are no disputes and the result is here.

I haven't seen it yet.

Total ballot counted is 67.  One invalid.

The winner is Tomohiro Fujisaki, 46.  Andy Linton, 45.  Then Ren-Hung Hwang, 29.  Nilesh, 2.  The rest, one each -- Hanumanthappa, Kiran and Decka.  So by one, I declare Tomohiro Fujisaki as the winner.


Tomohiro Fujisaki: Thank you so much to everyone.  I will do my best for the NRO.  Thank you.


Kilnam Chon: Thank you.

Andy Linton: I would like to add my congratulations as well.  Well done.

George, your question from Jabber.

George Michaelson (APNIC): I have four questions, from Yi Chu from Sprint.  The first question: would an organization in India with network in other economies require more v6 blocks outside this Indian national block?  That's the first question.

Andy Linton: There are four questions, if we do them one at a time.  I have seen the questions, they were posted to the mailing list this afternoon.  I'm not surprised we've got them.

BK Nath: In our proposal, we have not said that we will not allow the blocks to be used or obtained from other RIRs, not to be used in India.  What we are saying is how many organizations of this type are there that would be using blocks from other areas, but the majority of the organizations would be using within India only.  So we are not restricting it.

Rakesh Mohan Agarwal: The proposal is not restrictive at all.  In case any multinational wants to come to India -- of course, right now, they are there, so they may take an address block from India, an Indian multinational can take an address block from other RIRs.

It is not a restrictive proposal, it is a facilitative proposal.  Most of the organizations are Indian using their address block from India, if they use in other RIRs also, they can take an address block from them.

George Michaelson (APNIC): The second question: would an organization in another economy, having network in India, be required to use IP in the Indian national block for the network in India?

Rakesh Mohan Agarwal: As I have just now answered, it is not restrictive.  They may take an address block from India also or they may use their already existing address block allotted from other RIRs also.  This is not a restrictive proposal, it is just a facilitating proposal.

George Michaelson (APNIC): The third question: would an organization in India be allowed to request, via the India NIR or directly via APNIC, v6 addresses outside of the Indian national block?  For instance, they do not wish to have the risk of a one-line ACL?

Rakesh Mohan Agarwal: I could not follow the question.

What is the question?

Andy Linton: George, would you re-read the question or maybe paraphrase it?

George Michaelson (APNIC): I think they are reading the screen.  Is it appropriate for me to paraphrase?

I would think not.  I am only a channel, I'm not an interpreter.

Andy Linton: OK.  I won't ask you to do that.  Re-read the question and we will see if someone else can clarify.

Randy will clarify it.

Randy Bush (IIJ): I believe the question is, if I am an Indian ISP or operator within India and I want to get an address block but I don't want to use the Indian address block, is it OK if I go to APNIC or whatever and get my own address block outside of the big Indian address block?

Rakesh Mohan Agarwal: Yes, this proposal very much allows these things.  This is in alignment with the APNIC policies only.

Andy Linton: George, you have one more.

George Michaelson (APNIC): I have one more question: if India would be reserved a /16, what criteria would APNIC apply for other economies to get equal amount of reservation?  Should CNNIC get a /16, or JPNIC or KRNIC?

How about smaller economies but with greater potential for growth?  Is the criteria population, political, economic or landmass?

I am channelling the question from the community, so I have finished with the questions.

Rakesh Mohan Agarwal: Of course, as I said, we have made a very empirical study and on the basis of those studies only we have come to know that this /16 may be required for another future time in India as a whole.

But as far as a study of other economies in the APNIC region is concerned, as I illustrate in my proposal, yes, this study has to be taken up by some entity.  It can be APNIC, it can be some empowered body in those bodies, it can be anybody authorized by APNIC.

So they may decide what are the factors, as prop-099 has indicated some factors.  It may be population, it may be population growth, it may be networking size, it may be their IT sector evolution, it may be many other factors also.

All these factors will be taken care of by an APNIC formed committee.  As I indicated, they may take three months time to find the methodology, what should be the methodology to find out the analysis and assessment and on the basis of those assessments and analyses they can find out what is the requirement of different economies in the APNIC region.

Of course, based on those requirements, based on those future requirements, they can reflect their proper requirement to IANA also.  As I said, this is not confined to the APNIC region.  Here they have to consult other RIRs also.

So this process is not a one shot process, this may take some time.

Brajesh Jain: All the various questions asked are about how allocation will be made.  That question is very clear: any allocation will have to be made within the framework of APNIC policies, and if an NIR, whatever block it gets, the allocation has to be as per the APNIC policy and whatever policies are being practised in other economies of APNIC, the same would be applicable here as well.  Similarly on the question that an ISP in India having foreign, is applicable to all the economies, not just in India.  Thank you.

Rakesh Mohan Agarwal: Yes, that is true.

Jordi Palet (Consulintel): What happens with the current allocations?  You are defining if they need to renumber or something like that?  I guess not, but just in case.

Andy Linton: I am going to paraphrase that.  If people already have IP address blocks, do they have to give them back?  The three comments I heard about nonrestrictive nature of this, I think that is --

Jordi Palet (Consulintel): I understood that from the previous response, but just in case.

Andy Linton: I will let them answer that.

Rakesh Mohan Agarwal: Basically, once any planning thing is taken care of, some small issues have to be sacrificed.  When you have a very big building, the smaller pieces on that plot have to be sacrificed.

Definitely once we are talking about big policies change in APNIC as well as NIR region, definitely until that time these numbers, these allocations may be used by those economies, by individual organizations.  But of course in case if they find it is better to go for what has been reserved for them by APNIC or by their own NIRs.  So it is an option for them.  It is not whatever allocations, whatever reservations have been given to them, it will go to waste.

This economies-wide allocation may be in addition to what they have right now, or it can be taken care of by them.  Again, this depends on the process and what the methodologies are.

Jordi Palet (Consulintel): The point is it gets really difficult to size, if you need a /16 for the country, without first asking the existing allocations if they will use inside of their actual locations or the new /16.  Just a comment.  So I really think that makes it almost impossible to size the real needs of a country.  That's one point.

The second question is: if you are asking to reserve, for example, a /16 for a given country, who is going to pay for the /16 according to the APNIC fees?

Or are you asking also to change the actual fees, so the reservations are not paid for?

Andy Linton: Can I just clarify that.  This is a reservation, and reservations happen all the time inside the database, and it doesn't attract fees until it's actually allocated out of the database.  So right now that isn't an issue.

Jordi Palet (Consulintel): My next point is probably also related to that.  If it's a reservation, is this accounting for IANA?  Because that may also create problems and at the end it means that maybe we need a global policy to say how this will work through IANA process, in case APNIC requires a new reservation or a new allocation.

Probably it's not just doing this policy but it requires a lot of extra work to make it possible.

Andy Linton: Jordi, I will bring you back to the message Paul gave us earlier, which addressed this, which said they could reserve stuff and if it was a clearly documented policy about why they were reserving stuff, it would give them the information to go back to IANA and ask for more.

Is that fair, Paul?

Jordi Palet (Consulintel): This is not a question, it's a comment.  I really think trying to make a prediction -- and this applies to the previous policy also -- for the next 10 years or 30 years as you are proposing, it is absolutely impossible.  We cannot even have a guess about what we are going to do, which for example on the Internet of Things in the next 10 years, let alone the next 30 years.  Whatever prediction you do, again, /16 for country X, Y or Z, it could not work.  I really believe it's not going to work in any case.

Again, it's not a question, it's a comment.

Andy Linton: Jordi, I have to stop you there, because there are several other people at the mic.

Jordi Palet (Consulintel): Last point.  Very quickly.

I don't think this is good, and this is the main reason I am opposed to this proposal, because having a single allocation for a country facilitates authorities from the country or from outside the country to block all the country, which is against freedom.

Rakesh Mohan Agarwal: The same holds good for IANA, which has allotted /12 to all five RIRs, the same holds good for RIRs also; the whole APNIC region can be blocked by a single clique.  This is a very hypothetical thing which we are seeing in so many emails.  These are very hypothetical things.

As far as you are saying it is impossible.

Everything is made on a planning basis, and how effective planning we can do.  It depends on us only.

It is not the individual, it is a complete community which will be involved in this planning process.  Thank you.

Andy Linton: Lorenzo.  Can we keep the comments tight.

I appreciate this is an interesting discussion, but we are now at 5.30, so officially we are at the end.  I'm happy to let it carry on for a while, but let's keep it nice and tight.

Lorenzo Colitti (Google): What is the problem we are trying to solve?  The only thing I have seen in these slides that indicates there is a problem that requires us to do anything is that we are worried that we won't have enough space left in 30 years.

While I'm very receptive to the arguments that we don't want to run out of space yet again, I think it's very premature to start thinking about the deck chairs when we haven't even deployed IPv6 at all yet.

I would suggest that when we figure out what is actually happening in the IPv6 Internet and people are deploying it, when we get to, say, 10 per cent of the space, and only 90 per cent of the space is left, then there is a case for this kind of proposal and we can start thinking about it.

I think it is premature and I think by reserving things for different purposes, it distracts us and causes all sorts of arguments that are not really productive, and there is no urgent problem to solve.  So I think we should do this later.

Andy Linton: Thank you.  Owen.

Owen Delong: Opposed to the proposal.  In order to achieve any of the benefits this proposal claims to offer, it would have to be restrictive and not as open as the gentlemen have clarified that it is.  Therefore it cannot possibly achieve the benefits that it purports to achieve.  If it were made restrictive in order to achieve the benefits, it would have the not hypothetical disadvantages of having an entire country behind a single aggregate.

Having an RIR behind a single aggregate is very different from having a country behind an aggregate.

You are not going to have an authority decide they want to go up against an entire region, nobody is going to block all of Europe, all of Africa, all of North America or all of Latin America.

The RIRs are so large in their scope that that single aggregate is not an issue for filtration.

On the other hand, it is very easy to see a case where one government might want to filter the economy of another government and/or drop them off their Internet access.  So I don't think that's hypothetical, I think it's a very bad idea, I think it is very risky and I think it is very contrary to the actual interests of the Indian people, in addition to the interests of the region and the network as a whole.  Thank you.

George Michaelson (APNIC): I have one more question from Jabber, from a remote guest on Jabber: if the national ID centre wanted to allocate IPv6 to citizens, what prefix size would be allocated?

Andy Linton: That's an interesting thought.

James Spenceley (APNIC EC): But speaking personally.  I'm against the proposal for the reasons previously that Owen outlined.  It is way too easy and too much of a security risk for one country to have one prefix.

Having said that, I understand that certainly the Indian community is concerned about having enough of the IPv6 pie.  That's understandable.  There are two groups in the world today, those that continue to grow the number of Internet subscribers and those that have pretty much reached or are close to reaching their maximum capacity.

For those of us sitting here with more IP addresses than people, we don't feel this is much of a problem, but I understand the developing nations that are growing Internet at rates larger than my entire population every year are concerned about this.

I wonder if there are not better ways to ensure that communities with fast growing Internet have access to more resources?  Previously, I proposed extending the allocation horizon to 10 years.  Would this go some way to reducing your concern about the Indian ISP community getting enough address space, if you could at least initially get 10 years of address space on your current growth requirements?  Would that take in the period of the largest growth that you think the country may be going through?

BK Nath: In our proposal, we have said we will ask for a /16 initially but that doesn't restrict us from asking for more.

Andy Linton: James, has that --

James Spenceley (APNIC EC): My question was: if we extend the horizon, so Indian ISPs can get more space from APNIC today, they can get 10 years' worth of space, rather than two years' worth of space, will that give some comfort to the Indian ISPs?

Andy Linton: Just so people are aware, there are three people at the mic.  I'm not going to let anybody else up, because we need to close it out.  There are more talks in here at 6.00.  I don't want to restrict debate but we have a time limit on here.


Naresh Ajwani (ISPAI): My request to this august gathering would be, if we can see the entire proposal from two different perspectives, perspective 1: big size scope projects which my friend has proposed a project of unique identification.  Perspective 2 is high grounds.

When we take ourselves to those grounds which addresses the concern from our fraternity like ITU, that we ourselves are concerned about every economy, then the entire situation is viewed very differently.  Either we keep waiting for somebody else to come and guide us, that we are supposed to be responsible for every economy of Asia Pacific, irrespective that they are in a situation to apply for the same today or not, or we ourselves take some kind of a position in this regard and say, yes, there will be a contiguous block for an economy or in case currently the situation is NIR, and the ones who are not NIR or are not interested to be an NIR, there is still a concern for them also.

I think the picture is bigger than getting into the operational aspects only on this issue.

I personally feel, I support this proposal because it brings a much bigger picture than what we are actually trying to dwell upon.  I can explain to you the project of unique identification, where it is very important for the department to bring a similar kind of a contiguous space for each and every citizen.  We can dwell more upon it in terms of its advantages and disadvantages.

My only concern and suggestion and request is that, again, once we think about it, how does it make a difference if big projects are coming and they are going to adopt IPv6, and they are in a position to adopt IPv6 because they can have that kind of a provision with them, and there was a question of how big the prefix size will be and all that.  I'm sure we all know when we allot any resource number, the size of the prefix may not be a bother.  It is not, because I was surprised to see that question.

We have to really go to the next level to understand what can be the situation, where we can counter any kind of a possible objection, not being concerned about globally in terms of our own Asia Pacific.  Thank you.

Andy Linton: Thank you.

Dmitri Burkov: I have a lot of concerns about these proposals but I don't want to repeat all the arguments against.  I want to point out only one issue.

I was really surprised at these ideas to use IP addresses for the personal identifications of citizens.

If you want to do this, I say you don't need just /64 because you fill all the paper.

First of all, I think it's improper usage in the wrong direction.  Thank you.

Andy Linton: If this is the question on Jabber?

George Michaelson (APNIC): It's another one, but if you have closed the lines.

Andy Linton: I'll take this last one.

George Michaelson (APNIC): This is a question from Vantha in Cambodia: if an ISP in India can get space from APNIC, what is the use of having an IP reservation for the NIR?

BK Nath: What we have proposed is that the vendor -- the address space is reserved by APNIC, the ISP can approach either APNIC or the NIR; but in either case it will be allocated from the same block.  It's just which way you are approaching to get allocated from that block.

There's no difference, I believe.

Andy Linton: I am sensing that we have a lot of -- there are a reasonable lot of issues, but I'm sensing that our colleagues here have said that prop-099 constituted a large chunk of what they were talking about, we couldn't reach agreement on prop-099, so certainly that part of it is dead.

The question they have raised here is not one that we can sensibly reach a decision on, because they are asking us to do some thinking about this and some planning, to get this on the table and get an agenda item that asks us to think about these things.

The whole idea of thinking about country blocks is something that we haven't done before.  I don't think we have enough evidence to say it is a good idea or a bad idea.  I'm hearing the same thing about prop-099.

I can ask the floor here about consensus and where they are on this, but I'm sensing -- let me not put words in people's mouths.

How many people are in favour of -- one question I had for the Secretariat earlier, was how would we implement this?  They have given me the advice it is not straightforward to implement because there are a number of suggestions and so on.  But how many people here are supportive of the ideas that we should be looking at this thing?

I think that is what we were asking in prop-099.

I will ask the remote centre in Cambodia in a second or two.

How many people think this proposal raises a serious question?

I think I have to clarify that more.

Let me put it in the formal sense.  How many people agree with this proposal and would like to see us accept it?  Put your hands up.

OK, there's a block of people at the back from India.  Their opinion is really important on this.

What about the rest of you?  Clearly a lot of people in the room don't think this is an issue.  Who are they?

Randy Bush (IIJ): That was a poorly phrased question.

Andy Linton: OK.  I'll take a suggestion for a better one.

If you don't support the proposal, put up your hands.

I'm seeing a balance of some people support this, some people don't support this.  That clearly means to me that we can't reach consensus on this, certainly not without a lot more discussion.  But I think that there are issues raised here -- I'm suspecting this issue will be one that gets raised again at the next meeting.

Let's keep this alive and keep it on the mailing list, in the sense that prop-099 is being kept alive on the mailing list and this is the same issue.

Geoff Huston (APNIC): You might want to poll the remote room on that.

Andy Linton: What is the opinion in Cambodia?  Those in Cambodia who are for this?  Those who are against this in Cambodia?

George Michaelson (APNIC): 11 opposed in Cambodia, and three additional in Jabber.

Andy Linton: OK.  I don't think this can reach consensus.

We might reach it if we stayed until midnight, but we can't do that.  I'm going to push this and prop-099 back to the list because I think it warrants more discussion.

It may be that you want to discuss that on the list, people may want to withdraw their proposals and come back and think again and submit something else.

I suggest that may be something you want to do.  I am going to leave it to the authors to think about.  This is something we can discuss on the mailing list.  The SIG Policy List is there for discussions, I believe these are important issues and I don't believe the policy list needs to be restricted to discussions eight weeks immediately prior to the meeting, which we tend to do.

Let's keep this ticking over and let's talk about it some more.

Adam, do you have what you need?

Adam Gosling: Yes, thank you.

Andy Linton: I think that's all our business.

Rakesh Mohan Agarwal: Thank you.

Andy Linton: Thank you for presenting on it.  Thank you.


Andy Linton: I would like to thank everyone for their attention, I thank you all for the comments and constructive debate on all the topics we have had.

I would like to thank those people who have been listening remotely and in the remote hub in Cambodia.

We have lightning talks here in 10 minutes.  If you are going to stay for those, you have 10 minutes to take a pit stop and refresh, and thank you all very much for coming.  Thank you.


Key Info


Paradise Hotel,
Busan, South Korea


28 August -
1 September 2011

Program included:

AMM, Policy SIG, IPv6 plenary, APOPS

Please wait...