Policy session transcript

Thursday, 28 August 2008

Policy SIG

09:00-10:30.

(Start of meeting)

RANDY BUSH:

Good morning, my name is Randy Bush, IIJ Tokyo. Welcome to the policy group meeting which you will have to endure all day along with a few breaks and we're just sorting out some of the technology so we know what's happening here.

From the website, here's kind of what we're going to do today which Jian, my co-chair is going to do an overview of the policy development process. Then, we'll do a summary of the proposals and we have to do a SIG chair election too. Cover some open action items and then we will get to the protein.

We have some times set that are not yet on this foil, but will be and we would kind of like to stick to the schedule and make sure that everybody gets a chance to bring up their opinions and feelings and to explore the issues, because the purpose of this meeting is not presentations as much as it is discussion. So, we need to be open and sensitive to the peoples' discussion.

Then, in the afternoon, a technology advance, we will be joined by real, live, interactive participation from Manila and Hanoi and if I can figure out how to push buttons, they'll be projected on the screen as they talk and participate. And they'll show up on monitors and see us and actually be able to participate remotely, and I think this will be something we will maybe see more and more of in the future.

So, let me turn - because there are many people here who are new, let me turn it over to Jian to go over the policy development process itself.

So, Jian is going to present the process in which we, and how we make the sausage.

Back to contents

Overview of the policy development process

JIAN ZHANG:

I'm going to quickly go through our policy development process since some of you are new here.

Our SIG charter is to develop policies and the procedures which relate to the management and use of Internet address resources by APNIC, NIRs, and ISPs within the Asia-Pacific region. Here is our mailing list, so you can join our mailing list to discuss problems, proposals.

There are several principles we are following in our policy development process.

We're open, transparent, and bottom-up. Anyone can propose a policy. Anyone can discuss policy proposals. Also, APNIC publicly documents all policy discussions and the decisions. The community drives policy development.

So, this is the chart - first you submit a proposed policy or amendment to the APNIC Secretariat. Then the SIG chair will post proposals to the SIG mailing list and the community discusses proposals on the SIG mailing list.

Next, we're going to do the face-to-face discussion in APNIC meeting. Right now, we're here, we're doing face-to-face discussion today. Then, we're going to seek consensus. If we do get consensus, we're going to write a report to AMM. If we get consensus, then it goes through this after-meeting process. If we don't, at any stage if we can't get consensus, we go back to the process. We discuss putting back it to the mailing list again and we do the discussion on the mailing list again. So, if we get consensus, we're going to have final call for public comments, announcing SIG mailing list and to have the community discuss proposals on the SIG mailing list. The SIG chair posts the outcome of the SIG mailing list discussion. At this point, if we get consensus, proposal will be endorsed by the EC. If the EC get consensus, we're going to implement it here.

So, that's the whole process. There are a couple of things to please keep in mind. All proposals have been submitted with good intentions, we know that. Opinions may differ. But, we all want the same thing - a strong and healthy Internet. So play nice. And today, we're going to have nine proposals, so respect time constraints. So simply to say, be nice and be short. Thank you.

RANDY BUSH:

Thanks Jian. The usual, sorry, I didn't have enough coffee this morning! Some housekeeping notes. Our sponsor for the day, we wish to thank is Dot AUDA. I actually did so yesterday and they were helpful so I can vouch for the service with the Helpdesk. And the prayer room is in the Star Room next to Hall C, go out the door and turn right. Lunch will be provided in the Crowne Plaza, Victoria Cafe. Is that where we've been eating up until now? Yes. So come and see APNIC's learning environment during morning tea at about 10:30, and that's you know, how to learn how to deal with resources etc via the web at your own time space and so on. The APNIC vendor reception has been located to the Crowne Plaza hotel atrium and that's at 6:30 tonight and a light dinner will be provided. Tomorrow evening, there's an informal dinner at a restaurant on the Gondola. Transport is provided and the cost is AUS $70. Please register at the registration desk and more information is available at the registration desk.

Back to contents

Summary of proposals to be presented at APNIC 26 Policy SIG

Next, the overview of policy proposals. How are we going to do that one? As I said at the newcomer's meeting, a number of the proposals derive or are caused by the upcoming exhaustion of the IANA free pool. So, that puts pressure on how we're going to deal with the end of cheap and easy v4. So, a number of the proposals are related to that, and a number of the proposals are related to each other. So, unfortunately I don't have an SQ diagram showing that. My apologies - I should have done it. But I'll try to point them out as we go through.

The first proposals we'll discuss will be continuing work from last time. Which is prop-050, which I believe properly is not really a proposal, it is an informational presentation which is on transfer of IPv4 address space. Prop-055 is a very serious proposal on the policy for the allocation of the remaining IPv4 address space. Then, there are new proposals, prop-062 on how we would use that final address space. Prop-062 which is reducing the time frame of allocation - in other words, when you make a projection for your utilization to get address space, to reduce it from 12 months to six months.

Prop-066 says, it speaks to the use of historical IPv4 resources and unfortunately, now I'm going to go through them all in detail, but we need to frame them and understand how they relate to each other and then we'll go and address the proposals individually.

Prop-050 which again, Sam, this is really an informational proposal, correct? Or is it now a proposal?

SAM DICKINSON:

It is a proposal, I'm not sure if it is a still a proposal?

RANDY BUSH:

It is trying to deal with the current policies and the limitation of current transfers to mergers and acquisitions and I want to give it to Steve Cant. I can't, unless Steve Cant buys my company! There will be a demand after the exhaustion of the free pool, and definitely want the address registry and whoever is and how we want to talk about it to properly reflect who is actually using the address space. Therefore, 50 proposes that the restriction on transfers be lightened, so that address blocks could be transferred. I could transfer my /24 to Steve and there are still some restrictions that it must be a /24 or larger. It must be in the APNIC administered range. And subject to the normal policies at the time of transfer. So the source of the transfer, also, if I transfer to Steve, I would not be able to receive new IPv4 address blocks from APNIC for two years.

The proposal has - was presented at APNIC 24 the first time as an informational. No consensus was sought. The last time at APNIC 25, again, there was at APNIC 25, there was serious input and there has been between 25 and now, so the proposer who is Geoff Huston by the way, acting individually, not for APNIC, has modified the proposal. There is now Version 3 and it also summarizes the discussion that's been held in other regions. This is a topic going on in all regions. And there's discussion on the mailing list - not very many proposals.

Prop-055 - the problem is that at the end of the IANA free pool, we're all going to be, you know getting that last space or what happens if some other RIR gets it and we thought we would put in an application to the IANA for a /8 or the last four /8 s and they say, "we're out!" So, we would like, being APNIC, our community, would like a planning horizon. We would like to be able to know that there will be a last /8, and therefore, we can plan its use, prop-055 proposal will propose - is a global coordinated policy which has already passed in three other regions, but it started here, this proposal actually started I believe from JPNIC, and it says that there's one /8 reserved for each RIR. When it runs out, in other words, when IANA can no longer fulfil requests, it gives these five /8 s to each of the RIRs, one of them to each of the RIRs, and it's normal for the rest.

It's a combination - there used to be two proposals, prop-051 and prop-046 and they combined them and they mostly delivered. There was one proposal that said, two per register should be saved, what seems to have sold around the world is one each. It was presented again in APNIC 25. We got majority support at the last meeting but we didn't have - as Jian pointed out, our process is consensus and Jian and I have to judge that and we would like to see very few people saying no to - 1, 2, 3 saying no, to really say, yes, we agree on this. So we did not really achieve consensus. There has been no discussion on the mailing list of this.

One of the items of discussion that was raised last meeting and the meeting before is, if we're saving this last /8 for - so we can plan, then, what's the plan? We should have one. So, prop-062 is a plan. The plan is based on two things - number one is for the transition to IPv6 for the next 10, 20 years, people are going to need little bits of v4 space to sit in front of address translation, etc, etc. And secondly, we don't know in the second 10, 20 years, there may be some disruptive technology, some new and surprising thing that we did not think of, so don't ask me to describe, it which needs some v4 space. The Internet has been useful because it is a disruptive technology, so save a little for that too. The actual proposal is that each LIR can receive a single allocation. /22 is used here but I believe that the proposal says whatever the current minimum is. So each existing and each new can receive one allocation and a /16 is reserved for, we don't know who yet. There's the policy mailing list. Discussion has been fairly active for this region and I think we'll be discussing that and we've allocated a fair bunch of time for that today.

Prop-063, reducing the time frame of allocations from 12 to 6 months. As we get towards the end of the IPv4 free pool, it's problem that the needs for the next 12 months when you justify the space is that there's not going to be 12 months of free pool, so we want to - the proposal wants to make the period shorter to match the shorter expectations. So, the allocation in other words, when you come to APNIC and say, I need space. You say how much space you'll need for the next six months, not the next 12 months. There have been three posts from three people and one was very recent I believe.

So prop-066, ensuring the efficient use of historical space. In other words, space that you got before APNIC, ARIN, etc, you got it from SRI or John himself, so while the remaining free pool from IANA is exhausted, there's a lot of v4 space out there that is not being used. When an LIR comes to get space from APNIC, currently, they do not have to demonstrate that any historical space that they have is well utilized. So, they could hold back /16s and still get more space. As things get very scarce, there's a perception that this may not be fair. So the idea is that to include when ARIN or APNIC evaluate your utilization, include historical - this is the case in other regions by the way. Oops, did I just skip one? No, oh! Yes, there's been seven posts from five people, it's been discussed. And the discussion actually changes, etc.

4-byte AS numbers, you heard yesterday how they're coming in the plan. They want to hold three proposals here. One is that some of them be allocated for, saved for documentation purposes just like we use 192 something or another today or you know, some magic numbers you can put in documents that if people cut and paste them, they're not going to damage the operational Internet. Prop-64 is change to the assignment policy that was discussed some yesterday and will be discussed more. And prop-065 is, there has been a multi-year discussion about a dot. Whether there should be a dot in the middle of the number. I find this amusing but we'll continue to amuse ourselves today with it.

The documentation is that there's no reserved space to put in documentation, so any AS numbers now used in the Internet, in the future, somebody could get assigned that and it would hurt. So the solution being proposed is to designate.

It got an amazing amount of discussion. As I said, the other is the policy. Their slow take-up of the 4-byte AS numbers and little vendor support. So the proposal is to add a new date for introducing them to do it from July next year by default.

OK, prop-064 got a fair bit of discussion also. Now we come to the exciting - do we put a dot in a 32-bit AS number? It is incompatible with a number of operational systems and router configuration. So there's this proposal that APNIC adopt ASPLAIN. In other words, it is just an integer, no dot in it and for the AS numbers, there have been eight posts from five people. It was an exciting discussion.

OK, we have prop-059 using the resource public key infrastructure to construct validated IRR data. That has been withdrawn yesterday.

Prop-060, changing the criteria for the recognition of NIRs. In other words, how to create a new NIR. And well prop-61 we've already discussed.

So change in the criteria for the recognition of new NIRs. The problem is, that under the current policy, it has to have the support of both the community and the Government. So NIRs can be dominated by Government interests. The proposal says - allow NIRs to be approved with community approval only, no Government rule. And new NIRs are approved to a vote by APNIC members and limit Government positions on NIR boards. There has been no discussion on the mailing list. And that is the story.

Back to contents

Open action items

Open action items - 24, version 2. Having approval in each remaining stage of the policy proposal process, APNIC Secretariat to implement the proposal prop-049. This was ratified by the ICANN board of directors, done deal.

Prop-25-001, pending approval at each remaining stage of the policy proposal process, Secretariat to implement 57 - change IPv6 initial allocation criteria. Done. Implemented. That's the way the Secretariat runs things today.

25 - Policy SIG chair to return for discussion, global policy for the allocation of remaining IPv4 address space to the Policy SIG mailing list for further discussion. We have been discussing it on the list and it is on the agenda for today.

25, version 3, I'm misreading this. These aren't really policy numbers, so it is action item 25-003, Philip Smith and the proposal author proposed a simplified version of IPv4 address transfers, and this is being presented today.

25-004, pending approval of the remaining part of the policy proposal, the Secretariat to change the minimum allocation size to /22. This is implemented, the current size in the APNIC region is now /22.

25, David Conrad was to consider creating a proposal based on prop-056 with the IPv4 soft landing but he withdrew the proposal. Those are the open status action items.

Here is a presentation, I believe that the presentation is going to be for the first proposition, prop-060. There is now a version 2, this was given to us last night at 11:00. You will find it on the mailing list. These slides to the best of my knowledge have not been adjusted. Are you here to make the proposal? You have a choice of microphones.

Back to contents

Summary of proposals to be presented at APNIC 26 Policy SIG

VINH NGO:

I've been asked by Kusumba to help him with the proposal today. Unfortunately, due to some emergency medical condition, he was unable to attend today. So, as Randy was saying, we got it at about 11:00 last night, and so was I, so just put up with me here just in case I'm a little bit slow. That is Kusumba's note, apology note.

Actually, he highlighted his work. What he's proposing is that this proposal has been six and a half years old. It's time for a renewal, it's time to review. And he stated the condition of the proposal for review is that it is due to political, economic, operational, and growing economies. So, he would highlight it further down the track. So, you can read it on the slides there, I will try to highlight the main points. Government is trying to take a neutral position, like we said on the opening day, but refrain from controlling or manning of the actual NIR.

The current NIR recognition criteria require any industry representation and those of the proposal from the Government agency. So, in response to that, it is incomplete proposal and will not forward it to the Executive Council for the procession of approving an NIR. However, in a situation where such a proposal is originated by the unit of division or department of the Government, such proposals could go through since the Government endorsement is easily or sometimes automatically available to them.

He stated in there that the Government representative or agencies have control of the Internet resources allocation in the economy of the country. If such NIR is formed by the Government or by the controlled agency. But then, policy only indicates that it may not restrict the Government to enforce the rules to obtain resources from NIR and not APNIC directly.

Government understands the ambit of national security, so he's involved with national security, for the need of the services to only obtain the resources from regional NIR and not from APNIC, despite APNIC policy indications.

Members or user's community may lose opportunity to grow the network, largely due to the very reason that they may need to obtain Internet resources, only from such NIR. And the regulator who is also directly associated with such NIR. The policy maker may dismiss or delay such allocation requests against any pending issue or matter concerned to that service provider and the Government regulator.

Despite NIR proposals being sent through a Government controlled agency, the EC, the Executive Council may have the right to reject such a proposal if it has no suitable objection from members. However, in the current policy criteria, the scope of such objections is only external and not within the policy framework or workflow. What he's proposing in the change of policy is as follows.

Any NIR application must be put on a voting process. A voting process can either be online or in our annual meeting, and must achieve the support of its member. Any NIR application must be put on voting, and he expected that list to get about 75% support from the members within that economy. He expected to get a majority support from within the economy of the NIR proposal.

In section 3.2.2, it's mentioned that the Board composition of the NIR must have a majority representation from its members, followed by academic research organizations, etc. The Government or its participating agencies must have a minor role compared to other representations on the Board of NIR. So in other words, what he's saying there is that the Board have the consensus of the members but not from the Government or participating agencies.

OK, what is it affecting for APNIC? APNIC members would be benefited by such policy since they don't have a fear for undergoing conditional allocations of resources. At the same time, membership, communities in several countries, if eligible by this policy will be able to form an NIR. And an NIR is controlled by its community, rather than by Government.

So, what he's proposing, any NIR application must be put on voting. Either by online or by members in our annual meeting. Or at least they would have to achieve a 75% consensus within the members. And in section 3.2.2, it must mention that the Board composition again must have the majority representation from its members, not from governments. I think that's about it. That's all. Anyone have any questions?

RANDY BUSH:

Thank you, Vinh.

Are there comments? I know one person at least has already responded on the mailing list. And, I'd like to ask throughout today by the way, that as you cue up to make comments that some consideration and priority be give be to those who have not spoken before and also to those from the region. Would anybody care to comment on this proposal? Please also remember to say who you are and what your organizational affiliation is.

SYLVIA W.SUMARLIN: My name is Sylvia Sumarlin from IDNIC. I would like to comment on this proposal. Actually, what I would like to say is that I sort of agree with this because right now, in our country, there is a movement for the Government to get in control with the IDNIC and the Government right now is planning a proposal that our organization be partly controlled by the Government, so if this can be implemented first, then that will make the Government not controlling our community. That's all. Thank you.

AKINORI MAEMURA:

Akinori Maemura from APNIC. I would like to know what about changing it from the version 2 to the version 1. Can I get it?

SAM DICKINSON:

I'll just have a look, I only saw it at 7:00 this morning. I'm Sam Dickinson, APNIC. OK, some of the current problem was changed but that's not the actual details of the proposal. The following elements were removed in Version 2, and sorry if I'm out of breath because I just ran. The 0.1, NIR application from industry appointed agency may not need Government's endorsement and has been removed.

Number two in the original version, NIR application from Government represented agency may not need Government's endorsement has been removed.

Number four has been removed. - Any economy can apply for NIR only when there is a minimum of certain predefined members under each category since that will also justify the efficient application of IP resources. That has been removed.

Number six was removed - the Board may restrict its positions to not more than nine members since it is difficult to achieve coordination of the same for effective functioning or obtaining decisions for such NIR.

And number seven has been removed - having either APNIC's operational office or branch office should not restrict that economy in applying for the NIR.

Leaving basically number 3, which was about the voting and from the original, number 5 which was about the Board composition. Is that clear? Do you need more information?

AKINORI MAEMURA:

I think that's clear.

PHILIP SMITH:

Philip Smith from Cisco. I actually submitted to the list, but I guess people are listening to the presentations rather than reading e-mail so I will repeat my list here.

I don't see any problem statement. There's a long discussion of history, but no real - what is the problem we're trying to solve?

Section 4.2 says, "Members can vote". It's not clear what members, APNIC members? New NIR members? Other members? 4.3 is interesting, it says" APNIC can dictate to governments", that's an intriguing concept. I tend to think that partnership is the way forward. That's been experienced so far anyway.

I don't understand where any of the advantages came from. They're not really discussed anywhere else in the text. There was a fear of conditional allocations, I think I can understand that a little bit, but that all needs to be clarified. I'm not aware of APNIC members at the moment who have been given conditions for allocations, so I'm not quite sure what that's referring to.

And section 7, I'm afraid, I see this as having huge impact on the existing RIRs, because it could mean that somebody else could come along and set up a competing RIR. That's what it looks like to me.

RANDY BUSH:

Somebody needs to come to the mic, because we can't make ourselves nine minutes ahead of schedule so early in the day! Thank you for your manners.

LEO VEGODA:

Leo Vegoda from ICANN. I'm following up on the proposal i.e. I read the proposal and I wasn't entirely sure whether this was an intention that you could have multiple NIRs per country or not. I'm not sure if that is what the proposer intends or not, but it would be interesting either way and it would be great if that could be clarified.

RANDY BUSH:

OK. This is the first time we've had this proposal. So, I would like to get a sense of what people feel, you know. I think since it is the first time, especially you know how many people, I would like to ask how many people are seriously for it. How many people are seriously against it? And maybe how many people are undecided but might like to see it get some more work to answer what seemed to be fairly serious questions. For instance, Philip suggested. So, how many people support the proposal? Please?

How many people are against the proposal as it is? How many people think that it should be reworded? The reword, Sam.

By the way, I actually have a timeline here. I unfortunately don't have a Power Point and we'll try to rectify that during the game. So currently, we would like to discuss it now for 15 minutes, the change of assignment for AS numbers. That would be James Spenceley.

Back to contents

prop-064: Change to assignment policy for AS numbers

JAMES SPENCELEY:

All right, so this is prop-064, change to assignment policy for the AS numbers and this specifically relates to the assignment policy for 4-byte AS numbers.

It's a change to APNIC 094 which is a policy for autonomous system number management in the Asia-Pacific region. The existing policy is up there and it is on the APNIC website. This policy seeks to create awareness earlier in the community for the need to support AS numbers without mandating a final adoption of 4-byte AS numbers. The current policy is basically a three-stage policy: from January 1 2007, 4-byte AS numbers were available upon request, but 2-byte AS numbers were issued by default. From January 1 in four month's time, in 2009, APNIC will assign 4-byte AS numbers by default and will assign 2-byte AS numbers on request. The following year, in 2010, APNIC will cease to make a differentiation and will allocate numbers from an undifferentiated pool.

So the policy currently as it stands provides no initiative for people to adopt the 4-byte ASN. From next year, from January 1, they can simply request a 2-byte ASN from APNIC and get the 2-byte ASN and the Internet will continue to be happy on its merry 16-bit way. So the specific jump to 4-byte seems like a rather strong jump from the 1st of January 2010. It is basically, you know it's cut and dry to 4-byte ASN. So, we would like to put some pressure on those providers, upstream providers, peers, and equipment vendors to adopt those 4-byte ASNs earlier. As you can see in the diagram, the customer puts in a request to the LIR. The LIR does that from the provider and tries to use that 4-byte ASN from the provider who then contacts the vendor and says, all of the customers are coming with 4-byte ASNs and I would actually like some support for it.

From 01/07/09, so July next year, six months after the default allocation of 4-byte ASNs, APNIC is to allocate a 4-byte ASN by default, unless it is demonstrated that the 4-byte is not routable. So basically to show that you upstream provider or one of your peers that you're using and the AS justification is unwilling or incapable of accepting that 4-byte resource.

Here you can see the proposed policy, we've inserted the underlying policy which is July 1, that you know, you actually are required to show an unwillingness if you're a provider or peer to support the 4-byte resource.

So, I think that some of the key benefits, it makes more service providers aware of the requirement to support 4-byte ASNs. They have to tell the provider that they're not willing to accept it and there's some level of justification required to support the application, that can be in the form of an e-mail or a document from the upstream provider or peer that they not willing to accept that. I think it will also provide information on the readiness of the Internet. APNIC will have access to, effectively a list of providers and peers that are not willing to accept 4-byte ASNs. This will put additional pressure on vendors Which is something consider we're not seeing at the moment and will possibly create a transition to native 4-byte acceptance on the Internet.

Key disadvantages, it could potentially create more work for APNIC. There's probably, what between three or four ASes assigned on a daily basis from the APNIC region, so there is obviously more work in terms of requesting the justification from the LIR. But certainly, three or four resources aren't considered a huge amount.

So, the mailing list feed back seemed to be pretty positive. There was a request for APNIC to public providers lacking support. I felt this was sort of out of the scope of the document as it would sort of add particular confusion in terms of NDAs and creating a black list is never a good thing for a member body to do. There's also a suggestion that they have support for the same poster. In the JPNIC region, a suggestion to remove the request 2-byte stage, from January 1, to have an undifferentiated pool. This seems like a hard transition when a large router manufacturer still hasn't got 4-byte support, you know widely in the Internet router base. There's also a suggestion to push default allocation out until exhaustion. I would suggest that this is not a positive step, as we would like to have an orderly transition rather than a last-minute rush. As this resource runs out we would like to have support on the Internet.

Now for questions and comments?

ANDY LINTON:

Andy Linton, our company operating the Internet exchanges in New Zealand, APWIX. We make extensive use of the PSL, the tools like RT configure to build the configurations and lots of work to build. So that's work for the RIRs to do so that tool set is basically, the ball is firmly in their court on that one. And a lot of that stuff doesn't support 4-byte ASNs so that's another piece of work.

JAMES SPENCELEY:

Absolutely.

GEOFF HUSTON:

Geoff Huston APNIC, the author of the original policy that you are proposing to amend here. I actually don't understand why this is a change of policy and why it needs another policy, James. Because what's going on is that we tried, and I tried originally and the intent of the policy to actually create clear deadlines if you will to industry, saying, look, you really should work towards the targets. Now, it's not really the folk who have routers, nothing changes, because irrespective of what happens to someone else, the BGP systems simply do the work. So, to that respect, anyone running routers doesn't need to change a thing if we don't want to, it is actually their operating support systems. But the intent of the policy is different. What it says from now on, January 1, 2009 is, if you want to have a 2-byte AS in the next 12 months, ask for it. Provide a reason if you want, but say, I want one of those. You're giving them a template - I want one because...! So, you're saying you have to fill out the template. But in policy sense, what it's really saying is if you don't fill out the template, you get a 4-byte and if I fill out the template I get one. Nothing has changed.

You're not suggesting that APNIC publish what's going on there? No. So I just fill out a template to say, no, I just want one because AS 1 is bad, it won't be accepted. It doesn't matter what you say. So to that extent, why have you changed in this particular policy proposal? What has materially altered from the proposal which says as of January 1, you're going to have to explicitly say you want a 2-byte otherwise that you get a 4-byte.

JAMES SPENCELEY:

I draw the parallel that we have templates.

RANDY BUSH:

So you're saying from the Secretariat, that you do not as APNIC Secretariat, understand what this policy actually changes?

GEOFF HUSTON:

I'm saying, as the proposer of the original policy that was accepted by this process, I do not understand what the substantive change is in policy terms? Thank you.

RANDY BUSH:

So you're not speaking for the Secretariat?

GEOFF HUSTON:

If I was speaking for the Secretariat Mr Bush, I would have said so.

RANDY BUSH:

You said Geoff Huston APNIC.

GEOFF HUSTON:

I am Geoff Huston speaking as the author of the original proposal here adopted by the process.

JAMES SPENCELEY:

To answer the template question, we have the templates, when you request IP resources, you are required to fill out a template. You can either answer that honestly or deceptively depending on the result you want. I think we're saying that we're giving people a template to say, here's how you get around the fact that you need to use a 4-byte ASN if all your providers and peers support a 4-byte ASN. I see a direct parallel to the current IPv4 allocation policies. I don't see that being any different. I think this puts a little bit more pressure on LIRs and also on vendors and software manufacturers.

So to say, hang on, I actually need to get a letter or an e-mail or some level of information from my provider or my peer that says they're not going to support this. I as a provider, ask getting that request once a week or once a month, will sit up and take notice and that's what the intent of the policy change is, Geoff.

IZUMI OKUTANI:

Izumi Okutani from JPNIC. I understand the intention of the proposal and the number of people in the community support the intention and they think that it would be helpful and putting pressure on people to try to demonstrate that they actually really need 2-byte ASN if they are going to explicitly request it. And there was actually a comment made from one of the operators that maybe the current policy that says from January 1 next year, that you don't even have to give any justifications and you can just simply request for 2-byte if you think you need it. They feel that, well, everyone is going to request for 2-bytes anyway, so we might as well make one-year period for requiring the demonstration, so what you're suggesting in July, it should be maybe moved forward to have one-year period for pressuring people.

And another point that was made, was that it might not be - it is probably not a part of this proposal, but strong concerns were expressed if we are really going to make it by the year 2010 as in the current policy. But, they feel that if we change this now, then it is going to change the intention of the original proposal. So, I think it would be good to try to pressure people at this stage by passing this proposal, and that if we see the situation in it and feel that we are really, really, really not ready, then maybe we can reconsider the current deadline of January 2010. I hope I'm making my point clear, I spoke quite a bit.

JAMES SPENCELEY:

Absolutely, I think unlike some people, I guess I view policy as an ever-changing entity. I don't think that it needs to be fixed at the original intent, so if in six months time, at Manila, we see that the policy needs some level of change to increase the penetration or adoption of 4-byte ASN, there's no reason not to. As for changing the date, I suppose the requirement to justify the lack of support for the 2-byte from January 1, I think that's wishful thinking given that the major router vendor on the Internet doesn't support 4-byte ASN. So I do consider that, but I thought given the fact of the lack of support, it is probably better to make a realistic start on July 1.

IZUMI OKUTANI:

OK, thanks.

GUANGLIANG PAN:

From APNIC. I'm here not to support or not support this policy; I just want to give a view from the hostmaster's point. Actually I'm a resource services manager and also dealing with other RIR hostmasters; at our hostmaster workshop on Monday from a host master's point of view, what our concern is, when we assign the 4-byte AS number to our members, if they can't use it, they return it to us and it will double our work. So the concern is, the Internet community, are they happy or upset by the 4-byte AS number, if it is proper.

JAMES SPENCELEY:

I've also wondered what happens from January 1 if we allocate it.

GUANGLIANG PAN:

Yes, we have a lot of concern that we start from January. Next year, we start to allocate the 4-byte by default, so if there is a problem and they couldn't use it, or want to return it, that is the host master's concern.

JAMES SPENCELEY:

I think that is a very valid concern. You'll probably find, most of the first 10 or 20 or more will be returned and requesting a 2-byte ASN. But I think that's a little bit out of scope with this policy proposal but it's a valid concern, one that hasn't been addressed.

GUANGLIANG PAN:

Thank you.

RANDY BUSH:

Thank you, James. um... can somebody summarize the discussion on the list? Which I think we did? So, any last comments? How many people are seriously in favour of this? Raise your hand. Those in favour? Those who support this proposal?

And those who think this proposal is a bad idea? OK, for those who have not been here very often, unfortunately in this region, a small number of people expressing opinion is not abnormal. So, for the moment, I will take that as consensus. Paul are you walking towards the microphone or walking casually.

JAMES SPENCELEY:

So, this is probably the more contentious of the two policy it's I'm presenting. The delegation of the 4-byte AS numbers.

RANDY BUSH:

Can I interrupt? Excuse me; between Jian and I, we have a disagreement with how many people supported that last proposal. Those who supported it, please raise hands again. Thank you.

YI CHU:

I thought in the first proposal you had a third option, that is to modify working on the proposal and I was waiting for the third option for this one. My concern is about the deadline for 2010 that we're forcing 4-byte AS. From the ISP provider perspective, if my vendor doesn't support it, I basically put myself in a competitive disadvantage which I can't do that. So, I'm really concerned about the last 2010.

JAMES SPENCELEY:

OK, so out of the scope of my policy proposal, my policy proposal is to introduce an intermediary step with the hope that that actually creates the easier transition to the 1 of January date. You know, I think we all have concerns about January 1, 2010 date will cause us problems so the policy proposal to create more awareness by the providers for the transition to be smoother. So, if somebody wants to change that date, I think that's a source of a different proposal.

YI CHU:

So, on that ground, I'm voting against the proposal.

JAMES SPENCELEY:

So, to clarify that, you would prefer to see the proposal altered to push that date out from January 1, 2010?

YI CHU:

January 12010, that's the deadline, I'm against the deadline. That's the point.

JAMES SPENCELEY:

That's already existing policy. I'm not actually introducing that policy today; I'm introducing an intermediary policy. 2010 is already the date in the current policy.

YI CHU:

OK, in that case, I'm mistaken.

ALASTAIR JOHNSON:

Alastair Johnson from ALCATEL. I'm not directly for or

against this policy because I don't see it adding much value but I don't see any harm in implementing it. Speaking from the vendor, the hard-stop date of January 2010, we don't have much choice but to support by that time. I'm not sure that I actually see much value in bringing forward that date and asking for justification. Starting next year, the default is to get 4-bytes. Six months later, default is to get 4-bytes.

JAMES SPENCELEY:

Yeah, I guess I sort of assumed that most people would continue to request 2-bytes right up until the hard deadline. This just seeks to put some resistance in that process.

ALASTAIR JOHNSON:

I agree, you're probably correct. I'm just not sure that it will make much of a difference overall.

RANDY BUSH:

Izumi-San, you were standing.

IZUMI OKUTANI:

I was going to respond to an earlier comment from the person from Sprint, and I want to express that we have the same concern in the community, but as James has clarified, that part, January 2010, it's already in existing proposal so you know, based on the assumption that the deadline itself is January 2010, we support the proposal. But we would like to also consider the possibility of changing maybe the particular deadline, depending on the situation. But we support the proposal as it is at this stage.

RANDY BUSH:

Let me state what my understanding is. There is currently implemented policy, not proposal, that January 2010 it's 4-bytes. And my understanding is that that is partially based on the belief that there won't be very many 2-bytes ones left at that point, so it is not a choice. So what James is proposing is to put a six-month earlier position that you just don't ask for 2-bytes, you have to justify it. That's the essence of this change and the only essence of this change. Am I correct?

BILL MANNING:

Bill Manning.

RANDY BUSH:

From where?

BILL MANNING:

From Los Angeles, but I am an APNIC member so I feel it is OK for me to stand at the microphone. The proposal to extend the data recorded in the APNIC Whois Database records, and to return the records in either format. It's up there.

JAMES SPENCELEY:

This is the second proposal, I haven't introduced it yet.

RANDY BUSH:

Unfortunately we became very informal and went back to the previous proposal.

BILL MANNING:

Sorry about that.

RANDY BUSH:

We'll have fun with that soon. Would you mind if we resolve this one. Even if you do mind, tough!

BILL MANNING:

I'll wait.

RANDY BUSH:

Bill and I are old friends. Based on the discussion that just happened, I would ask again, now, we're back to the change to make on next July 1, you have to justify a request for 2-byte AS number, not just say that you want it. You have to justify it.

BILL MANNING:

I'm in favour of that.

RANDY BUSH:

The essence of that, could those people in favour please raise their hands. OK, could those people against please raise their hands? Thank you.

Back to contents

prop-065: Format for delegation and recording of 4-byte AS numbers

JAMES SPENCELEY:

Thank you for the clarification there, it brought a few more votes. So this is prop-065 and it was circulated on July 22. It is a request to change the format for delegation and recording of 4-byte AS numbers.

The policy in essence recommends that APNIC change its procedures to

standardize the delegation of 4-byte AS numbers in the ASPLAIN format rather than the current ASDOT format. The proposal extends to the data recorded in APNIC Whois Database record with the proposal recommending that whois returns the same record for queries made in either format. So ASPLAIN who for those who are not familiar with the dot is the current integer. As you can see from 0 to 65535. The new 4-byte AS pool is from 0 to that very large number (4294967295). ASDOT format is the and the separated by a delimiter and in this case, obviously being the dot. So in this case, what you would see is AS 1.4541 would be the representative of the ASPLAIN as 70077.

So the current problem as I see it is that APNIC records 4-byte ASN in the ASDOT format. The membership has not been consulted about this. It has certainly contributed to the adoption of ASDOT with routing manufacturers and vendors And the RIRs and IANA have adopted it with consultation with ARIN, but I think as we've learnt a little bit more and tried to implement 4-byte ASNs, the operating community is more in favour of ASPLAIN. So it seems like every operator I talk to is in favour of ASPLAIN.

So, there's a lot of talk on this topic in regard to ASDOT being incompatible with expressions. The dot in the middle matches the characters, so in an AS-PATH regex, 2.37 would match 2237 and 2337. And there's a problem with the dot with internal management systems like scripts and database system and there's obviously the dot problem with the current format.

So, there seems to be an overall lack of support for ASDOT in the operator community and these are issues which have been raised with REGEX. The introduction was formally given to the world in 4-byte AS representation and has now expired.

I guess my view is that ASDOT places more problems in front of the 4-byte AS adoption. It creates less backwards compatibility in terms of operator systems and that is obviously a bad thing for the adoption of 4-byte ASNs.

So router vendors are now picking up and adopting ASPLAIN. Cisco use ASPLAIN by default on all new code releases. Juniper now supports or supports ASPLAIN and 9.2 will include ASDOT. Force10 support ASPLAIN. Redback use ":" but moving to support ASPLAIN. If there are any vendors in the room, we would be happy to hear from you.

Today we have two formats, a couple of drafts in the IDL working group. Submitted one for ASDOT production and ASPLAIN and ASPLAIN was clearly more supported than the ASDOT. The option of a double colon, so we seem to be going down the path of complicating this, rather than simplifying this. Hence, we're raising this document here.

One of the major disadvantages is certainly from our perspective as we've been trialling 4-byte ASN is that we will use ASPLAIN, it breaks less in our systems internally and it basically worked from day one on our network. ASDOT didn't. So a customer will be allocated an AS in a format of the first 16 bits followed by the second 16 bits with a dot separator. And they will interact with us with the format and say, my AS is 2.37, and we'll say, we actually see your AS at 131109 so this is inconvenient for the staff but breaks a lot of the systems. What do they interact. What ASN does that come from? Are we going to ask them to convert that every time they interact with us or we going to have a different CRM field or OSS field to see how they think.

So timing is a little bit critical. As we heard from January 1 next year, 4-byte ASNs will be issued by default. The working group seems to be on track to adopt the draft plans for the ASPLAIN for the group. However, there is now the double colon idea. So the policy proposal is timely in that in the region, to adopt ASPLAIN which is what it seems most of the operators are wanting to use, so that the customer allocations or assignments are in line with how we configure the routers and network.

So, if we adopt this policy now, it will be two months before it is adopted and potentially a month before that before APNIC changes its internal systems so we're looking at potentially leaning towards December. Right in ahead January 1, adoption 4-byte by default.

As I mentioned, there's been some discussion for the representation draft-huston. There were 12 out of 14 responses supporting ASPLAIN. The 13th, I think David, changed his mind and now supports and only one has actually supported the Michaelson draft but proposed that it be changed to a double colon and last week, we decided that you may as well put a smiley face in there if you continue to change the format.

Here's some comments from the IDR mailing list. "Having read this list and having previously commented on the problems ASDOT format creates with SNMP and SMv2, I support the adoption of this draft." "The ASDOT formats will become a burden from the point of view of the network operator (specifically manipulation as subsets of strings)."

Until last night when we now put the double colon.

So that's the end of the formal part of the proposal. I guess one of the things I wanted to do today was actually see how much interest there is in ASDOT as a format from the APNIC community. So can I get a show of hands from anyone who would prefer and is using and or is using ASDOT format for configuration.

And can I get a show of hands that prefer or would like to use ASPLAIN?

RANDY BUSH:

Let me interject here. We have a message from the IETF which is that this issue has exposure. It's important, etc, and we're discussing which working group to put it in. So the IETF should solve this on the 64 bit AS numbers! It's the IETF! But again, I can't think of a better place to argue about a dot!

The question you really see in the proposal is that we really say, which is the issue that - the scepticism is that the IETF will come to a conclusion. It has operational impact in that time that we have varying vendor support and we have varying use in the field today.

JAMES SPENCELEY:

Correct.

RANDY BUSH:

Would somebody care to speak? Bill, come on up. Oh, by the way, while Bill is walking, I made a mistake. Sam has hit me on the side of the head. The Chairs believe that there was consensus for the last proposal.

SPEAKER FROM THE FLOOR:

He gets to speak first because his microphone is further away.

BILL MANNING:

Bill Manning again. Being an early adopter of the 4-byte AS system, I will be loathed to give up 6.0. That being said, the AS numbers themselves have always been 4-bytes, we've just always ignored the top half for the last number of years. And so, having monotonically numbers is fine, I think that's a good idea.

JAMES SPENCELEY:

Sorry, what's that?

BILL MANNING:

ASPLAIN. For those of you who don't understand monotonically increasing numbers. There are some interesting places where we are run into issues like how to tag the BGP because that's a 32 bit field. So, there's more interesting things, but for the dotted notation I think it is a reasonable thing and I would suggest, encourage APNIC to start representing all AS numbers in a database as 4-bytes. Even if they're only two.

BILL WOODCOCK:

APNIC member and operating network in 12 countries in the AP region. We create a lot of our own tools and feel that ASPLAIN is a simpler and better representation for any system that we have to code ourselves. If somebody else feels like coding it, they're welcome to speak.

LEO VEGODA:

From ICANN. Before I came to the meeting, I checked with David why he used ASDOT in the IANA registry when we allocated the first bunch of big AS numbers and he said it was just because the only implementation here is where they've used ASDOT. It's relatively easy for us to change to ASPLAIN if that is the thing that people want. It would be really nice if everyone used the same format so that includes the other RIRs as well. And later on today, I believe the IESG will be discussing that in a tele-chat.

RANDY BUSH:

That's tomorrow.

LEO VEGODA:

Is today the 28th? But anyway, we expect them to tell us something. So, I personally would just prefer that everyone used one format. I don't really care whether it is binary or octal or whatever, but I just want to keep one registry for AS members and not have two publish it using different representations for the same number.

DAVID WOODGATE:

David Woodgate from Telstra. As the only person on the mailing list who opposed the - initially opposed the proposal, my reasons for that were my concern that with opening up a four billion number field, what implications that - leaving that other structures had for routing going into the future. And as an operator, I'm obviously looking to make sure that we have full capability to have as many refinements of routing policy available to us as possible.

Having said that, I think the idea of a mailing list or the discussion going on in the IETF is the better place for a lot of that philosophical discussion, and as has been pointed out, most of that philosophical discussion has been along the lines that AS numbers will continue to be used for some time as they are now, and will apparently have and can be expected to have reasonably limited growth over the time. At least nobody is jumping up and saying that it is definitely and absolutely positively there. And while that's the case, I'm certainly comfortable with a straight, undifferentiated format for the AS number. And that's the basis on which I was happy to withdraw my opposition to this particular proposal.

JAMES SPENCELEY:

Thanks, David. I guess one of the concepts is that we're operators. We have two formats today. That's quite clear that we can configure routers in two different ways. We can represent these numbers in two different ways. We as the operators in this region really should decide which way we prefer to represent this resource, given that we're pretty much almost 100% in favour of representing it in AS plan and to allocate an AS plan. Given the policy proposal, I would suggest that with the policy proposal in other regions, now that seems like that's going to be a very painful process but a valid process. We're operators not the IETF. The IETF is going to argue about putting smiley faces in until the cows come home.

We have a hard and fixed deadline and that is January 1 and that's less than four months away so if we want to work as a region and potentially influence the rest of the regions, we need to do that firstly within our region.

RANDY BUSH:

Could I be rude and ask that we continue after the break?

TOMOYA YOSHIDA:

I support the idea, but I want to ask, you want to seek to propose to other RIRs. So this time, so you mentioned about the APNIC should use the ASPLAIN or you want to move to other RIRs. I think that it is better to unify every region.

JAMES SPENCELEY:

I think the thing is that operators are unified in their support of having a plain integer. It's very difficult to unify all in one day, so we need a starting point and this meeting is that starting point.

RANDY BUSH:

um... let's go to break. Two things, or three things. One is my impression here is that, we are going to and we are allocating these in some notation. But we can't be like the IETF, we've got one for you and next year, we will tell you what it is. We are actually allocating themselves and we have to have the notation and the choice of which notation and this proposal is one particular one. The other item that is, we have forgotten is the Chair election. The Chairs forgot it so I suggest that you remember how bad we are at chairing when we hold the Chair election after the break.

(End of session)

Policy SIG

Thursday, 28 August 2008.

1100-1230

RANDY BUSH:

Just going to do two pieces of administration first, there was fear you might have been confused by my accent when we spoke of the pricing for the dinner on Friday, it is $70 New Zealand, we are in New Zealand, we are not in Australia, we are not in the US, it is New Zealand dollars.

Back to contents

SIG Chair election

JIAN ZHANG:

We forgot the chair election, so we just have one nominee for policy SIG chair, it is Randy. So I think because there is no competition, so he is going to be it. So I just announce Randy is going to be the chair of the policy SIG.

*APPLAUSE*

RANDY BUSH:

OK. We will continue with the exciting subject of whether we have a dot or not. How many people read the NANOG mailing list? There has been a deep discussion over the last 24 hours of how to convert an IP address from a dotted quad to an integer and back. So I'm sending a message there to say maybe they could answer this question for us and give us code to convert from notation.

JAMES SPENCELEY:

It seems to me the majority, if not all, the operators in the room are wanting to support a service provider ASPLAIN, the intent of the proposal is to match what our RIR allocates to what we will configure and support. I didn't see anyone in the region wanting to support ASDOT, so we adopt the same format to configure our routers as the allocation format, sorry, the assignment format.

YI CHU:

Just a quick question, can convert 16.0 easily to a service provider ASPLAIN?

JAMES SPENCELEY:

0.0.

YI CHU:

I just did it for 576. A service provider ASPLAIN 10 digit number is hard for humans to deal with, and when you configure the router for the floor, I'm sure there is going to be a mistake. So the dot format is a really good for humans. APNIC assignment is for membership. Converting the dot to a service provider ASPLAINs, it is a matter for implementation, you can convert easier, but for human communications, the dot is much better.

JAMES SPENCELEY:

For human interaction and for router reaction, keeping the two aligned is probably the best thing we can do, in my personal opinion.

YI CHU:

In my opinion as well, the vendor giving you choices, you can do DOT or PLAIN. It is an implementation issue, and what we try to address here is human communication. I would propose we do not adopt PLAIN.

BILL WOODCOCK:

Fortunately the policy process is organic and changes over time and none of us will be alive when we get to that many AS allocations and, yes, I realize it is one of those predictions that I will probably regret.

JAMES SPENCELEY:

I'm writing that one down, Bill.

JONNY MARTIN:

Jonny Martin from New Zealand, indeed, it is completely a human communication issue. The big problem we have is the sender listens to the standards. So if APNIC is handing them out in dot ASN, the vendors are going to follow that. So we need to do as much as we can to guide the vendors to do the right thing. So take an ASPLAIN, we are sending a message that is what to do. It is hard getting support at all so we don't want to make it harder.

JAMES SPENCELEY:

It is about backwards compatibility, we want the simplest thing to make it work, the work the IETF did comes to fruition.

JONNY MARTIN:

Support it entirely.

DEAN PEMBERTON:

I take the point that, dot 0 looks easier to handle whatever than ASPLAIN but that is because the numbers we are dealing with are small today. They are not going to look that beautiful in a dotted format either. So looking at the proposal over the long term, I think the, not having to deal with all the scripts changing, and all the inputs changing to a dot in the middle is a lot better than just being able to have 16.0 or 6.0 as being nice today, let's look at it being nice, long term, in the future.

JAMES SPENCELEY:

If we move past 6 digits, it is over a million ASes. It is going to a while, I assume, as Bill says.

TOMOYA YOSHIDA:

I don't think that the ASPLAIN is not easy to understand for humans. So if we study something like the 1,000 or 70,000 I don't think that it is not difficult to understand for us. Again, I support the ASPLAIN, that is it.

JAMES SPENCELEY:

Thank you. That came out of a conversation we had earlier saying there is no reason we can't start allocating; I can't speak for APNIC but there is no reason we can't start allocating with a double in front to make it slightly more human readable for those who are interested in human readable ASes.

DAVID WOODGATE:

I would like to acknowledge my colleague, I agree about the human readability factor, I think it is very important, but as I said before, I believe that if we are expecting that growth of ASes will remain fairly low and remain at six digits for a while, ASPLAIN will remain humanly readable for some time. I would get very concerned if we extend with up of 7 digits for AS numbers.

JAMES SPENCELEY:

I suspect from those comments if we are at the point of using 7 and 8 digit 4 byte, we have made fundamental changes to the rounding system. It is almost a moot point.

RANDY BUSH:

Due to time constraints and lack of people at the microphone, I would like to see if we can move ahead. We are still two minutes ahead of schedule, it is a secret schedule, none of you are allowed to see it. It is because it is in email and we haven't got it in PowerPoint. So I would like to try to gauge the consensus of the room again. I think choices are pretty clear so we don't need - should we work on it some more. It is pretty much a yes or no. How many people in the room are in favour of this proposal, which essentially says use the ASPLAIN over dot notation? Please raise their hands.

Excuse me if I don't bother to count, I can't count that high. How many people are against it? OK, I believe we have particular consensus. Thank you. Thank you, James. And now, as we see, the next agenda item will be, woops, I don't want to hit you with this, George. Do not look at laser with remaining good eye.

I guess we have Gaurab and Philip on reserving a couple of AS numbers for the purposes of documentation.

Back to contents

prop-061: 32-bit ASNs for documentation purposes

GAURAB RAJ UPADHAYA:

Good morning, everyone. So in view of ongoing 4-byte discussion, my proposal for you guys, the propose prop-061 is a policy to reserve at least four 32-bit ASNs for documentation and training purposes. I say at least four, it might be more, it depends on the members' agreement. The problem we face is currently there are no, 4-byte AS numbers for documentation purposes. Documentation writers have problems actually explaining how interworking with 4 byte and 2-byte ASNs happens. The private ones are not 4-byte ASN and it is clear. In the existing world, the private ones have been used extensively for documentation and training but we can't use it for 4-byte ASNs. Of course, has experiences have shown that both IPv4 addresses and v6 addresses and the AS numbers, we don't want to use production ASNs in any documentation.

We also should not use currently unallocated resources from the IANA free pool of AS numbers because it is not for us to use.

The situation in other RIRs, the other RIRs don't have any formal policy for making a 32-bit ASN allocated for documentation exclusively. I think it is the first time it has come up. We are bringing up the study, we are looking in our phase, the 4 byte ASN starting next year.

The proposal is APNIC set aside a common block of 32-bit ASNs for the purpose of documentation solely. The 32-bit ASN block should include a minimum of four ASNs, sufficient for any decent network policy that uses multi-homing because the existing APNIC number policy requires you can demonstrate you can multi-home for any AS numbers. So as I said, it is a minimum of 4 ASNs but allocating a bit more of 4 billion level numbers might be more sensible in the long run.

The advantages, mainly helps people writing, training, and documentation, especially now, because as we are into this whole transition phase or coexistence phase between 2-byte and 4-byte, it becomes important to write 70,000 something instead of saying they are to pick something up randomly. It helps people like us and the training, and all the people who are involved in the training and not having to use their own company's AS number in training and documentation, we have seen a lot of people use it on their own routers. It should be avoided. Also, not use a random IP, random AS numbers allocated to other people.

The disadvantages of the proposal mean that at least 4, as I had, maybe more than 4, 4-byte ASNs will be not available for APNIC members and probably will be gradually added to non-routable AS numbers for different organizations. It might make some people believe the ASN block is effectively private space as it is not routable. But with the document address space in IPv4, it is not used as much as allocated space so that disadvantage is slow. Other considerations, if you download the slides from the APNIC website you will find the changes I made during the break. The rejection of the proposal means we continue to use random ad hoc 4-byte ASN for training and documentation and things like that. Also, given this is a time for trying to train more people on 4-byte ASNs, probably run into problems with APNIC documentation and training programs.

I'm not sure what they are currently using but I see it's an APNIC member, we should let the APNIC training team have it. Even with - there has been a bit of discussion previously, and even with the proposal 64 and 65, we still think we need the 4-byte document as an AS, we had the discussion earlier in the week with quite a few people, if you start uses ASPLAIN, the whole idea of needing something with a 4-byte is not necessary. But there has been more feedback, or at least considerations, saying it is more important now as we actually need to show people the differences between the two sites. So that is why we're still continuing with the proposal. This proposal has no impact on APNIC members or NIRs. Questions?

RANDY BUSH:

Are there any precedents for this history?

GAURAB RAJ UPADHAYA:

Yes, those things are on the mailing list, I should add a bit of it. In the APNIC region we have a precedent on this, coming to IPv6 address space, the 201 TVA address space is assigned as documentation IPv6 comes from the APNIC address block and it went to this exact policy process, for that to be assigned and IANA cooperated later with global IPv6 document prefixes. There is a precedent in this, from the past. Does it clarify your question?

RANDY BUSH:

My, the way I would put it is we have experience with IPv6 addresses, for documentation purposes, APNIC just allocated and said here is some, ITF, and IANA therefore didn't have to argue where it came from, and excuse the Americanism, rubber-stamped it and said that is what is going to be used.

GAURAB RAJ UPADHAYA:

How long IETF takes to do things, more months?

RANDY BUSH:

Considering the quality of what they do it may not be a problem.

JAMES SPENCELEY:

I was originally against this proposal, considering the IETF would get a spot first, however, having written a lot of 4-byte documentation both internally and externally for presentations I have struggled to come up with to what to use, I used my own and Phil Smith's. I think it is relevant now and useful, it is 4 out of 4 billion. Let's approve it and give ourselves some AS documentations.

BILL MANNING:

If you assume ASPLAIN and you can represent all ASes as 4-byte then you have your documentation and it already exists in private AS space, you just have to stick a bunch of zeros on the front. We think we need 4, historically, there was documentation address for IPv4, 0.0.0/24, at the time people said we needed one address, turns out they were wrong. It is not clear to me your submission of 4 is going to be good enough for going into the future. So I am actually kind of persuaded I would like to see us reuse the existing private AS space and just treat them as 4-byte if we can do that.

RANDY BUSH:

Can I ask a question, Bill?

BILL MANNING:

Sure.

RANDY BUSH:

When you do this, use your AS number, for example, 1234, make sure you don't use AS numbers out of the private range 65.

BILL MANNING:

Do you reference?

RANDY BUSH:

Try to use the private range as examples, you will see something that is real.

BILL MANNING:

Of course it is real, private ones should be private and they are wall gardens and it is a really good way to document to people who have to set things up where it won't break other people. So I was thinking dereferencing your - you are welcome to use mine. Not really.

IZUMI OKUTANI:

We support this proposal and, as mentioned in the proposal text, the downside of using private ASN or your own ASN and just for ASN, I don't think the impact is there, so we think this is good and regarding the, you know, appropriate process, whether it is going to be RIR or IETF, we don't have a strong opinion so just leave it up to the opinions of the community, thank you.

ANDY LINTON:

I was concerned about documentation described in the tunnelling of 4-byte going through 2-byte, you need a real ASN out of the private space, need a large one to say this is how the process works so it is an example of where you would want one that is of 4-byte range.

DAVID WOODGATE:

I opposed this proposal on the mailing list, I believe there should be a documentation standard, I lodged it in a practical sense, 4 ASes out of 4 billion number space is negligible. However, I am extremely concerned by the consistency of APNIC's policies that we are applying. In Taiwan, I was told fairly strongly by several people that it is not APNIC's responsibility to reserve public resources or resources that have been allocated to it by IANA for the purposes of, for ongoing allocation to the end-users. Now, in that particular context, it was a far more significant issue, a far bigger issue, but I would like some consistency of responsibilities identified and followed in these sorts of principles. If that is the case, then I believe that this proposal contradicts that principle. And that is the basis of my opposition to it.

JASON SCHILLER:

I just wanted to echo Randy's comments about the use of the private ASNs, we use the ASN spaces at RIPE for subASNs so we were to use those for documentation purposes, it would lead people mistakenly to the conclusion we are talking about confederate BGP. So the 65,000 range does have a meaning attached to it and it may create some confusion.

GAURAB RAJ UPADHAYA:

To answer Bill Manning's earlier question about using something from the private ASN, as Andy pointed out if you're trying to show people the transition and use 2-Byte ASNs, and see 23456 in the path, it will go against the idea of it. So we need something from the big ASN, as Leo pointed out earlier.

DHEEPVIJAY BALARAMAN:

I would like to support the document because we need clarity in documentation and ASNs for other purposes so I support this.

JAMES SPENCELEY:

This is in response to David's comment there, is a massive difference taking a /8 out of an ever-declining pool and 4 ASNs out of a massive pool. There is a level of gradience we can accept as a group and stick to rather than creating governance types issues if we approve one, we can't approve another, personal opinion.

DAVID WOODGATE:

If I may respond to James, I agree that the scale of the concept was completely in orders of magnitude, but I disagree that there is a - currently any statement of discretionary capability involved. I'm wondering whether it would be better to arrange for IANA to have a discretionary level, that level, in terms of its allocation of resource space so that it can take upon itself to reserve resources for document purposes without having to refer to IETF.

RANDY BUSH:

Don't look behind you, David.

LEO VEGODA:

Thank you, the way IANA works we take an action on a request that is going through a process that shows that there is support for the request, and the most recent request we had was for a global policy for the allocation of AS numbers and one of the things in that global policy is the minimum we can allocate to RIR is 1,024 AS numbers which is 1,020 numbers more than Gaurab needs. We can't allocate them to documentation; we have to allocate them to an RIR. So we don't have the freedom of action here. We need formal request from someone else, that has gone through a process, blah, blah, blah, and the main reason for that is people get a bit antsy if we start taking actions off our own initiative. But thinking about this, I actually read the APNIC policy for assigning AS numbers and the policy just says that you get an AS number when you have a network with a unique routing policy that is connected to more than one other network with a unique routing policy, if you have got a training network, where you are training people, you have got three or four of these separate routing policies, separate autonomous systems, you build the network, take it down and move to another city to do the training, you built the network and take it down but there is nothing in the policy that says you can't go to APNIC and say, "Please give us 4 AS numbers for the purpose." APNIC may be nice and say we are going to wave the fee because we think it is a public benefit thing, I don't know if they would do that, but they might be really, really nice people. So, even if this policy proposal is not accepted, I'm pretty sure that APNIC could assign a bunch of AS numbers for this purpose.

RANDY BUSH:

I'm amused you are so preoccupied with the rules that constrain IANA and give 10 /24s because of dah, dah, dah, I was going to say ICANN needs a psychiatrist more than anything else. But if you turn it down, that APNIC can do it anyway, the contrast is interesting.

LEO VEGODA:

I think there is a possibility that the policy community in this region has already approved this policy. And this is a superfluous request. The policy community in this region has said IANA is not allowed to act in this instance. However much we might prefer to be able to act. So you have tied our hands, but you don't seem to have tied your own hands.

RANDY BUSH:

I'm an operator, I try to get things done, I'm not interested in the bondage stuff.

JASON SCHILLER:

The question that IANA can allocate numbers for documentation purposes that a global policy be ratified in all regions. Investigate having it is what I was thinking.

DAVID WOODGATE:

It is what I was thinking.

LEO VEGODA:

If APNIC want people to register 4 or 5 numbers for documentation purposes, it is not my call to say APNIC can't do that. I don't think they need to club up with four other RIRs and take a process that will take 18 months. It would seem simplest to just get it done.

RANDY BUSH:

We need an engineer. We know how to do this, we did it with IPv6 addresses etc, let's not get hung up on the process. I would like to close quickly, because we now are 6 minutes behind the secret schedule. Jason, if you have something to say, don't walk away, I'm not throwing people away from the mics but if you have something to say, or someone new, say it. I had to tell the Secretariat we are not going to have a free prize draw because we are behind schedule.

JASON SCHILLER:

My question was asked and answered, thank you.

TOMOYA YOSHIDA:

I support your idea but I think a little bit of change, but I think that, I mean, when I was, when I have a tutorial in Japan, I sometimes use more than five, five or six AS numbers to explain the BGB policy or BGB attributes so the proposal is, if the number is 4, but I think that I think that we have many AS numbers to extend the 4 byte. So I think it is better to have a range like 10.

RANDY BUSH:

But you think Leo's 1,024 is more than you need. I come from the US, we are one of the most rule-obsessed cultures in the world. So for a motion to be passed in ARIN, the words have to be decided and just right. Here, that is not the case. So it is very easy for us to ask for consensus today that says, "Do you support this proposal, probably slightly modified, to have 16?"

ANDY LINTON:

In the proposal it talks about a number of 32-bits ASNs for documentation purposes, but it also mentions some 16-bit ASNs, I think it would be useful for consistency to do both at this point, because if you want to write documentation that says this 32-bit interoperates with this 16/bit and these private addresses, it is useful. So I think it would be good to pass something, whatever number we agree to, but some number of both.

RANDY BUSH:

That is what you said Andy said?

ANDY LINTON:

All the slides are talking about a number of 32-bit ASNs but it talks about a mixture and I think a mixture is the way to go.

RANDY BUSH:

To clarify, what I suggest we try to gauge the consensus on is should a relatively small, 16, for example, to be worked out later, group of 4- byte ASNs and another 2-byte ASNs be reserved for the purpose of documentation? Could those who support that please raise their hands? Could those who oppose that please raise their hands? I believe there is consensus. Thank you, Gaurab.

GAURAB RAJ UPADHAYA:

Thank you, Randy; thank you, everyone.

RANDY BUSH:

Next up and we are now 10 minutes behind schedule, is prop-062, the use of the final /8. I believe Philip is going to present it and as I said, Americans are very rule obsessed. I saw this proposal being formed, I had opinions about it. Therefore, I had to, and I stated those opinions and I opposed the proposal to be modified, therefore, to be honest I had to put my name on the proposal and therefore I will step down and Jian will chair.

Back to contents

prop-062: Use of final /8

PHILIP SMITH:

Good morning, everybody, I hope you can hear me OK, because I'm a bit of a distance from the microphone here. So this is the prop-062, as introduced for the final of /8. I have been basically one of the loudmouths who has whined a bit over the last year or so about prop-055. Prop-055 was the one that was proposing a global policy for the allocation of the remaining IPv4 address space. And that policy basically gives a /8 to each of the regional RIRs. That is all it did. It didn't actually say what would happen with the final /8. One of my objections for quite a long time has been, well, you are asking the IANA and community to give a blank cheque to the registries but you are not going to say what you are going to do with the actual money you are going to get, for sake of analogy.

So, well I stopped whining and I started writing text instead. So what I have put together here with assistance from co-authors is a proposal of how the final /8 should be handled, assuming the prop-055 is approved by the community here today.

Right, so, current issue is, prop-055, if it is implemented globally, each registry will receive a /8 from the IANA, APNIC's existing v4 allocation rules would apply and that would negate the purpose and considerable effort that has been expended on prop-055 so far. Of course, the goal of prop-055 is that each RIR community can plan to use its final /8 in a way that basically suits its needs. So far, we have had no plan and it is what this proposal is trying to do. Situation in other registry regions is that this policy proposal has not been made in any region but we as authors would like other regions to consider. LACNIC, however, has approved a very similar proposal, LA-2000-04, it is not mentioning the /8, it says out of the LACNIC's pool once the remaining free pool has run out. New LIRs will receive a /22 and critical infrastructure will receive a /24.

So the details of the proposal, I have split it into three separate pieces, the three items for consideration. The first one is that new LIRs would receive one /22, which is APNIC's minimum allocation from the /8, regardless of the LIR size or intended membership tier. They will receive the address space once they fulfil the current, of course, allocation policy in force. So they will receive that address space once they fulfil the criteria. It is not a case of everybody can then just suddenly rush up and say, "I'll take my /22 now", once you fulfil the criteria, according to APNIC's allocation policy, in force at the time they request address space.

The allocation size tracks APNIC's minimum allocation in force at the time of allocation. I realize it could be what size should we use. As authors we felt the APNIC's current allocation was a reasonable number to pick, I would be interested in the community's view if anything else seems reasonable but to me, a minimum allocation of the current minimum allocation seemed to be the best choice.

Second item in the proposal is existing LIRs could also receive one /22 from the /8, again, regardless of LIR size and current membership tier and again, they will receive the address space once they fulfil the criteria to receive v4 addresses according to APNIC's allocation policy in force at the time. Again, the minimum allocation, or allocation size here tracks APNIC's minimum allocation in force at the time.

The third item is we would also like to propose reserving a /16 for future use. We don't know what the future use is, the Internet is changing, disruptive technology, as we all know, things change all the time. Something may come along where we may need some address space that address space that can't be covered in other ways so we are proposing to hold a /16 for the unforeseen future use.

In the event the /16 remains unused, but in the time that the remaining /8 is all allocated to RIRs, then the /16 will go back into the pool to be redistributed according to items 1 and 2.

The advantages? APNIC's final /8 and prop-055 will have a policy. It avoids the risk of one or few organizations consuming the entire final block with a well-crafted and fully justified application. It will allow the final allocation to receive exactly one /22 each, this is much larger than the existing APNIC membership and thus we hope it assures that no organization lacks real routable v4 address space during the transition to v6.

Disadvantages? Some organizations may believe, and can demonstrate, their requirements are larger than the /22 but our understanding is it is not intended as the solution to the growth needs of the few organizations but to allow assistance in transition. Some organizations may set up multiple RIR registrations in an effort to get more address space. APNIC will be required to be vigilant, as they do now, but authors do accept it is very hard to assure complete compliance. So much of the Internet today is based on the trust and honesty model and we have to rely on trust and honesty with this as well.

With 16384 allocations, we don't envisage it to be much of a major problem or impact on APNIC members and NIRs. The proposal allows APNIC and NIRs, existing, and new, to receive address space from the final /8 allocated to APNIC under a successful prop-055. The proposal doesn't have any direct impact on the operation of the NIRs but as I have noted before, it has direct impact on the ability of NIR members, existing, and new, to receive address space from the final /8.

There are other considerations. Prop-055 requests IANA to assign a single /8 to each RIR so that each RIR region can plan for v4 runout during transition. I'm offering this prop-062 as one such plan to handle the /8. We also believe the prop-055 is untenable without a plan for the /8 to be in place. Quite honestly, so much hard work with prop-055 will have come to nothing.

On the mailing list, there was one question that I think is important for us to consider here, as well. Should the allocations made under this proposal be linked to an IPv6 allocation? I would be interested to hear what the community's opinions or views on that particular aspect are as well. Are there any questions?

RAUL ECHEBERRIA:

One question, it is linked in some way to the approval of prop-055, what if the proposal is not adopted?

PHILIP SMITH:

If prop-055 is not adopted, this proposal doesn't, this proposal is purely aimed at prop-055.

RAUL ECHEBERRIA:

I think prop-055 will be adopted but the question is, because I think it is a good idea, anyway, so probably, even we should consider probably the possibility of getting a space. It could apply to the last /8, regardless of the source of the last /8.

BILL MANNING:

I think I concur with Raul about delinking from the prop-055; APNIC could do this regardless of prop-055 passing or not. The question I have is what is the current allocation rate inside APNIC and, I'm looking at the total of the 16,000-odd potential allocations from this policy and how long will those 16,000 really last based on the current burn rate? Has that analysis been done?

PHILIP SMITH:

With somebody from the Secretariat help with that?

RANDY BUSH:

I looked at it a very long time.

GUANGLIANG PAN:

Just ask the question of 16,000, allocations, how long it will last for? I just can give some data about 800 IPv4 allocations since this year so we can think how long it will last for.

PHILIP SMITH:

Can I ask a question, does anybody have any estimation of how many new LIRs APNIC will get and NIRs will get in the next 2 to 3 to 4 to 5 years? I don't know that.

GUANGLIANG PAN:

Yes, just the data, like the new members who join APNIC since this year, 260? All up? George? George can clarify the number.

PAUL WILSON:

The current projections which have come out of the fee structure modelling that is going on at the moment by 2013 we will have 2,000 members, I understand this proposal allows existing and new members, that is, by that time, all 2,000 will have received one allocation under the new policy, that is the answer for the time being, we haven't been projecting on the...

RANDY BUSH:

Which will consume about 12.3% of the discussed?

PAUL WILSON:

2,000 out of the 16,000.

RANDY BUSH:

About 12.3%.

PAUL WILSON:

NIR members to our knowledge, number about 1,000, but we haven't projected those forward, so add another 1,000, 1500 to the number and we could use 25% in the next five years.

RANDY BUSH:

The reason I joined this proposal is because I feel that two things. One is in the past we have kept a lid on people being able to enter and get address space in exchange for router slots. And that has been a barrier to entry and I don't think it is a good thing. It has not been successful because if it was successful, please explain why over half my routing tables are 24s. The second reason is I work a lot on IPv6 transition. And whether we move to IPv6 or we are stuck, praying to the evil gods of IPv4 NATs, all new multi-homed entrants to the market are going to need a little bit of IPv4 space to remain compatible in the IPv4 Internet so that everybody can reach the whole Internet and it is one Internet. So my feeling here is by allowing everybody to have just a little address, v4 address space for many years to come, how we get some compatibility and some ease of transition for our children and grandchildren.

Yes, I do have grandchildren.

PAUL WILSON:

Can I correct what I said before, I'm sorry, 2,000 is our estimate for the end of this year, 2013 we are projecting 4,000 members, if we take the same projected doubling of members across NIRs we will have 6,000 in total out of 16,000 allocated, I apologize.

DEAN PEMBERTON:

I think the proposal does a really good thing, in allocating the /22s to new LIRs, I'm starting to see questions around here as well, what will you do with any space left over? So this is the proposal for how to use the final /8. It certainly does a really good thing in how to use a portion of it but given there is not going to be 16,000 people coming up for /22s, doesn't the proposal go some way to what happens with anything left over as well?

PHILIP SMITH:

It is a good question, I would ask won't we all be using IPv6 by then, perhaps.

DEAN PEMBERTON:

Hopefully we should be using it before now as well.

PHILIP SMITH:

If we run out of 16,000 /8s and still use v4, woo!

IZUMI OKUTANI:

I concur with others in supporting the essence of the proposal that it would help address issues after the exhaustion. I think it is a good thing to do. Two suggestions for change for this proposal: one is regarding the size of allocations. I understand that /22 is defined to make it consistent with the current minimum allocation size, but some LIRs in Japan feel this may be too small to support, even for the starters, it only supports 4,000 customers? According to their calculations, if they apply carrier-grade NAT and supporting 200 users. It is really detailed in a lot of the functions but this particular person feels that way and he feels that maybe, there has been some discussions whether, maybe, the size that is being reserved is just a little too big so maybe we can allocate a bit more, for example, /21, /20 per LIR.

Another point is some people express concerns some LIRs try to set up another company to get hold of multiple /22s. As a way of avoiding this, maybe if an organization receives multiple /22s as a result of mergers and acquisitions or other reasons, it should be the subject of review and maybe asked to return the space, depending on the result of the review. That was a suggestion to make change to the proposal.

PHILIP SMITH:

Yes, on the second part first, thank you for your feedback, it is useful, Izumi, the question is really, how does APNIC and NIRs handle this, I suppose, duplicate organizations, for want of a better description. We rely on a lot of honesty in the whole Internet process, so far, so yes, I realize APNIC and NIRs will have to do, work as they do now to ensure people are not setting up duplicate organizations, it is going to have to carry on. I can't think of any descriptive way changing the proposal to somehow make it different or better.

IZUMI OKUTANI:

Do you think it will be too detailed to incorporate the suggestion into the policy proposal? Something that should be in the operations.

PHILIP SMITH:

It is a registry operational piece, yes, rather than policy. I don't really want to tell you how to run the JPNIC function or tell Paul how to run APNIC. I would rather leave it to you to work out how to implement.

IZUMI OKUTANI:

Sure.

PHILIP SMITH:

For the first one, the /22, as authors, we had quite a bit of discussion whether we should pick /22 or something else. Um, I mean, I chose the minimum allocation because it seemed straightforward to do that. I picked /21, well that reduces it to 8,000, /20 reduces it to 4,000, we could try /22 now, if we think it is not going to work, we can come back six months later and modify it, perhaps? I'm seeking thoughts from the floor.

IZUMI OKUTANI:

I would like to seek opinions from others on this as well, sure.

DAN ALEXANDER:

Just offering another thought, instead of existing LIRs only having one and only /22 from this remaining /8, you could place a time restriction, saying every six months, every 12 months, where it wouldn't completely shut them out and it would allow you to use more of the 16,000 but you would still gain several years out of what is left.

JONNY MARTIN:

I think there has been some good feedback this morning but the big thing I haven't heard, this is the last /8. Once this is gone, there is no more. We owe it to ourselves to be really conservative in the way we allocate this. If we decide to let it out too fast, we can't come back from it, there is no recovery. By taking it conservatively now, in 6 months or 12 months, each meeting, it is going to be pretty easy to change things if we decide we have done it wrong. On the other hand, if we don't know anything or we look at some larger allocations to start with, we might find we have big problems once we get to the point where we are using the last /8.

TONY HAIN:

On the point about the size of the allocation, from Paul's numbers earlier, it sounds like you hit the red number inadvertently. I was thinking /22 is too small originally but if the projected number of LIRs, NIRs that might step up to the plate to get one of these consumes roughly half of it within five years, that is probably the right number, independent of how you got there. Because you can't necessarily guess correctly and if you consume more than half in the first five years you probably guessed not conservatively enough. So I think you hit the number right on the head. I think it needs to be decoupled however the last /8 is acquired.

DAVID WOODGATE:

You will have gained from my postings on this that I'm concerned about proposal, quite extensively. I believe the intentions behind it are good but I must admit I think the implementation, the actual text of the proposal as it stands, doesn't actually reflect those intentions as thoroughly as it should. At the moment, it seems to be that the proposal is essentially, just someone trying to work out how let's chop up the last /8 and distribute it evenly as best we can. There are some words about easing transitions but no ideas on how it helps in the transition. So right now, the proposal reads more about managing runout rather than managing into a new Internet environment. I also raised the same issue that Dean raised about the concern about space, I have, while I certainly acknowledge that you don't want to put out the space, runout the space before you are sure you know what to do with it, I also point out that ultimately, an unused address doesn't help anybody.

If APNIC effectively hoards address space, itself, it is effectively increasing the runout problem anyway, only by a little bit, I acknowledge that but it is still a runout. And the question about, I also have questions about the existing, if the time of the plan is to really to allow new members to get address space, why not target new members in the way the LACNIC proposal has? Why leave it open for the people who have already got address space? So I still think, I wouldn't want to abandon this proposal by any means but I think there is a lot of things that need to be explored and reviewed. I think there is a lot of tidying up of both the intention and the execution that needs to be discussed.

ZHAO WEI:

I was about to ask the question about how you do, the design the /22 but you identified earlier on. I might put some information and comments on to Izumi. With LIRs, since the initial allocation goes to the /22, I barely got requirements of the /22, still got the requirement about the /21. So my information is for those regions who don't worry about the customer, they have 2,000 customers, the /22 will not help them more. So it probably goes to things, when we start allocation, of the last /8 and the ways of the policies, only a /22, it will be for them. I support Izumi, we probably won't think about that more to not cut most of the ISPs aligned to the proposal because /22 is too small.

RANDY BUSH:

Randy Bush, IIJ. I can't speak for my other co-author but I will say this, yes, /22 is too small for an LIR, but it is the last /8. You are dead. It is the end. There is nothing you are going to do about it. OK? So this is not going to solve the problems of those LIRs. There is no way to solve them, other than move to v6. Or move to massive NATing. You want to move to v6 or massive NATing, then you are going to need a little bit of v4 space to put in front of that NAT. I believe a /22 is too large, I believe we will be here at this meeting three years from now, changing that to a /28 because it is going to sit in front of the NAT, of many people, who want to be multi-homed, and they are going to need one IP for their SNTP server and one for the NAT and you know, the water is running out, boys, and girls! This is the end! Right? You have no choice, you can make this lots of small spaces or some big ISP is going to walk in at the end and justify a /9 and another will justify a /9 and you don't get anything - you have a choice.

JAMES SPENCELEY:

I guess we need to have a fundamental mind-shift on the back of David and Randy's comments, let's not be afraid to give it out. When it is turned off and you have got some left over, why not? We don't know what is coming, let's shift our mentality and use the resources and not worry about the utilization of the last /8, I agree with Randy, let's keep the resource available for use as long as possible. If it is 10 years or 20 years - fantastic in my view.

LEO VEGODA:

I have got slightly less material contribution, which is to do with which /8 is used for this purpose if the proposal is accepted.

JONNY MARTIN:

George was talking about a "Day in the life of the Internet" project, I can ask Duane Wessels to use the data collected there and see which of the unallocated /8s have already been used and how much use there is in each of the /8s. And he measured, in different ways, and the measurements he did are too complicated for me to describe now. But I will send a link to his research to the list. What he found was that there are some /8s which are significantly more used than others. And I think that if this proposal is accepted, as the proposal is intended to give a chance to new market entrants who are most likely to be going to be less influential, less able to buy stuff from people, it might be best to select the address space that is used for this proposal quite carefully, to look at the address space used, and try and find address space that has the least existing use, because trying to look at this to benefit new market entrants maybe existing market players will have more influence and be able to get that already-used space that should already be used routed to their benefit, whereas a new market entrant would find it more difficult. So if the room does decide that this is a good proposal and should go forward, I think it might be worth looking at the selection of the address space quite carefully.

PHILIP SMITH:

Do the registries have a process for saying to IANA, "I want that /8?"

LEO VEGODA:

No, I'm actually working on a process for making sure when we allocate /8s to an RIR, the process doesn't favour one RIR more than any other RIR, we will be discussing it with the RIRs, we want to make sure that we do this in a very neutral way so no RIR is benefited more or disadvantaged more than any other. So I can't tell you what the process is going to be right now, but I can tell you I don't know exactly which /8s will be the last /8s will be allocated. So just be careful when selecting the space, that's all.

RAUL ECHEBERRIA:

OK, from LACNIC, one second, the only way in which we can discuss this kind of policy is assuming that the /8s we will receive from IANA are usable. We cannot consider any other options. Let me share with you some of the things that were discussed in LACNIC when the policy that you are referring to was considered in the last meeting. I think that there were many questions, questions regarding the size of the allocations, the questions regarding if the allocations should be made only to new entrants or to any ISP. Many other things. The perception that I have and that we have in LACNIC after being adopting the policy is the policy will be revised in some way in the future. I can see with the spirit of what Randy said before, it is the feeling of most of the people in the room, when the policy was discussed.

So probably, even the more policies like this are discussed in other RIRs, probably there will be opportunity for them to converse in the future, taking the positive aspects of other policies set out in other regions. But we value very much in LACNIC is at least we have a guideline for how to, how we will work in the future if - with the last allocation. I think it will remain open for discussion for a long time but at least we have something at this point.

DAVID WOODGATE:

A couple of other extra points. Last, we have been assuming that the nature of LIR membership of APNIC would remain unchanged by this policy, effectively, by this proposal. And we have been estimating runouts based on that. Last night it was pointed out to me that I made a false assumption and I haven't had time to think about it in depth but what may happen is that if organizations run out of the ability to get address space from their ISPs they may come straight to APNIC and join, so you may find, effectively, the membership of APNIC suddenly shoots up by 16,000 overnight or within a short timeframe and that the /8 will disappear anyway, faster than the intent of the proposal, I'll leave it to others to think about the pros and cons of that. If it is feasible, I'm not sure what they would want to see the membership of APNIC change in that way, I'm not sure it would be constructive to the industry.

Other things, if we can get - in terms of people saying, "Let's make sure we are going to have address, still some address left over in the future" or whatever, I point out that this, there is probably not a really, not much point in reserving address space unless the utilization of that address space is going to improve in the future, if it is, if only getting one to one, one address per customer and you intend to have one address per customer, I suggest that the timeframe involved for the allocation is wrong. If you can see a way of turning the one-to-one ratio now to 1 to 1,000 in 10 years time, or whatever, then that can be a good thing. On that basis, I would rather see a proposal, or consider explicitly, assigning - having address assignments against intentions to use NATs or intentions to use IPv6. Something which will actually, actively improve the utilization of the remaining address space rather than just saying whoever wants it will get it.

PHILIP SMITH:

Your final comment, it is why I had the final question, should it be tied to a v6 allocation, or something else? It is an open question, really for anybody else to comment on if they would like to. As for the APNIC membership growth, that is why a /22 seemed to us to be a reasonable compromise. Really, it is like sticking your hand into one of these lottery bins and picking out a number, you have no idea what people are going to do. And yes, as you say, it is quite possible organizations could join APNIC rather than get addresses from ISPs so you could so a growth in membership so the final /8 could disappear quicker than the conventions we see now. I don't know how my coauthors feel but I have made no assumption things will remain static, the next two or three years will see a massive burst of fee people trying to grab a slice.

NURANI NIMPUNO:

I think there is a risk of the perfect being the enemy of the good here. I think we agree we need a plan, plan is not to try to extend the life of IPv4 any further, when we have a /8, it is all we have. It is a transition plan, I think a /22 is a reasonable assumption, and I think, I would rather have a plan than not a plan, we don't have that many years to play with. Actually accepting a policy we can tweak is something I'm very comfortable with. So I support the proposal.

PHILIP SMITH:

Thank you.

BILL MANNING:

I have been up one too many times, the /22 and the 16,000 made me think about an operational issue as opposed to an address conservation issue which is the growth and size of the routing table, injecting another 16,000 routes probably will be OK. But then if we try and actually approach Randy's vision of being less lonely, he being the only person who has ever gotten a /33 from an RIR, handing out /28s, the table will get larger.

PHILIP SMITH:

It is why we tied it to the minimum allocation, rather than have discussion that goes with APNIC's minimum allocation rather than try to do something separate with the proposal. So yes, the routing table is exploding, regardless.

ED LEWIS:

The unforeseen circumstances from the policy. From my experience, those clauses are not useful, it says it only counts if it matters. Drop that part of the policy to make it that much easier to deal with the cut-out section 43, the last third of the model, just that part there. I don't think we need to have it as part of the proposal, as part of the policy. If anything comes up, it will come up anyway.

PHILIP SMITH:

Sure.

TOMOYA YOSHIDA:

Just one point, I support at this stage, as Izumi said, we have discussions about which size is better but I think we can, if we discuss more and more, at the next APNIC meeting or some meetings, but at this stage I support your proposal.

GAURAB RAJ UPADHAYA:

I, in a sense I support the proposal, I think it is fair thinking, and as Philip pointed out, it ties itself to prop-055, so there is the global policy to be considered. I actually want to answer the third question you posed about v6, I think it is a good idea to actually get, make it part of the policy that the new entrants for the reserved /8 are also assigned appropriate v6 space, that brings in more complications for the current APNIC policy because as per the APNIC membership system, anyone who receives a /22 is a very small member, cannot receive IPv6 yet because they have a lack as a small member, whereas the previous policy of minimum /20, I guess? 20? To qualify themselves for v6 address space. So there might be a bit more complication there.

But we should probably make v6 part of the allocation, thank you.

JIAN ZHANG:

Sorry to interrupt, we are running out of time, so... let's finish just for the people.

JONNY MARTIN:

Just in response to Bill Manning's comment about routing table size, if I can't get address space, I don't care how big the routing table is.

PHILIP SMITH:

Good point.

ALASTAIR JOHNSON:

Just like to remind people that this is an organic process, policies can be changed. There has been a lot of concern, moving forward, I would like to say that I have some sympathy for the concerns around Australian address spacing proposal, I would like to see a comment that says it should be reevaluated if we see a significant amount going in LIRs taking up the space, in general, I support the policy.

PHILIP SMITH:

Thank you, I think several people have observed, if we approve this today, we can easily reevaluate this in Manila or Beijing, the two future meetings, if we see it not being effective or being too stingy with what we are handing out, we can try something else. We can change the minimum allocation. So I can see that we can change details of this after we get more experience.

JASON SCHILLER:

In response to the question that you have on the slide now about should it be linked to an IPv6 allocation, I just wanted to bring up and read two sentences from an ARIN proposal, the proposal for dedicated IPv4 block to facilitate IPv6 deployment, it reads, "Allocations and assignments must not be justified by immediate IPv6 deployments, examples include IPv4 for key dual stack DNS servers or NAT translators." It is important the space be used for transition purposes, you cannot only tie it to an IPv6 allocation as suggested but you can go a step beyond it and require a justification for how the v4 addresses enable or support an IPv6 only deployment such as being able to dual stack your servers.

PHILIP SMITH:

It is a fair point; I would love to hear feedback from the rest of the audience, if that is a viable thing to consider.

MARTIN LEVY:

I have no problem with that because we match it. But going back two or three points you talked about potentially getting 16,000 members for APNIC, paying a price to APNIC in order to get IP space that is unavailable anywhere else in the world and it could happen in any direction, my question is how do you define the price on eBay for address space at that point?

PHILIP SMITH:

It is already defined on eBay.

JIAN ZHANG:

OK, I think that is it. So we are going to seek consensus. How many people are in favour of this proposal, please show your hands?

DAVID WOODGATE:

Is this seeking of consensus the...

JIAN ZHANG:

The whole thing.

DAVID WOODGATE:

As it stands now or with adjustments?

JIAN ZHANG:

Without adjustment, I think we are going to seek consensus without adjustment and see how many people think we need some adjustment and then come back. OK. Sorry, let's do that again, how many people are in favour of this proposal? OK. How many people are against this proposal?

DAVID WOODGATE:

I think it needs adjustment.

JIAN ZHANG:

The third question will be how many people think it would need adjustment?

RANDY BUSH:

What kind of adjustment?

JIAN ZHANG:

OK. Actually, I have seen a lot of hands to support this proposal. Also seen a lot of hands to say we need adjustments. So Phil, actually Philip promised he is going to do adjustment during lunch. So we are going to come back after lunch, we are going to see what kind of adjustment we are going to have and we are going to seek your opinion again. Thank you. Let's take a break for lunch.

RANDY BUSH:

Could people who wanted adjustment please let one of us know what adjustment they were thinking?

PHILIP SMITH:

Yes please.

JIAN ZHANG:

Please come back at 2pm.

SRINIVAS CHENDI:

Before we go for lunch break, we have a draw. The communications manager, German will do the draw.

GERMAN VALDEZ:

It is going to be very quick. We won't keep you here for lunch. The prize is Asus AP 6. I would like to invite to the stage Stuart Fleming who will choose the winner of the raffle. While he is coming to the stage, we would like to thank the local hosts for the hospitality for this meeting. Please give a clap.

*APPLAUSE*

GERMAN VALDEZ:

Thank you, Stuart. So please push the button so we can find out who is the winner of the prize? And the winner is... Mark Foster!

*APPLAUSE*

GERMAN VALDEZ:

Thank you, Mark. So that is it.

(End of session)

.

SRINIVAS CHENDI:

Thank you, now you can go for lunch.

Thursday, 28 August 2008

Policy SIG

1400-1530

(Start of meeting)

RANDY BUSH:

Housekeeping note, just in case you didn't remember them from last night, we would like to re-thank our sponsor of the day, Auda. The Helpdesk is located upstairs in Room 7, kind of that way. And if you have any questions, go, and visit the Helpdesk. The prayer room is next door in Hall C.

Come visit Room 6 upstairs right next to Room 7 surprisingly enough for the APNIC eLearning environment during morning tea at 10:30am. I have a suspicion that this one should have been removed because 10:30am has passed.

There will be an APNIC vendor reception at the Crowne Plaza atrium where we just had lunch at 6:30, unless we run over time of course. It starts at 6:30 and a light dinner will be provided.

There will be an informal dinner tomorrow at the restaurant at the gondola. Transport will be provided; I assume the same as last night. The cost is 70 units of the local currency! Please register at the registration desk and more information is available at the registration desk - by that I assume the registration desk directly across the hall.

Now we will resume where we left off which was on prop-62 I believe, or something like that. It is numbered - I forget which is how the last /8 is to be used at the end of the last time - we essentially had most people behind it, but the consensus behind it but people wanted to discuss some options during lunch. We went and tried to listen to what some of the people wanted for options and I believe Philip will take care of some of that.

PHILIP SMITH:

Basically there, were four questions and what I would like to propose to the chairs and everybody here is if we can see what the opinion is for these four questions that were arising from the discussion this morning.

The first question is that should this proposal be tied to prop-055 which is the global final /8 policy proposal.

JIAN ZHANG:

So, we're going to seek - Philip, actually, was there a question you were going to ask?

PHILIP SMITH:

I can go for more then. OK, so I'll go over the four questions first. So, this was the first one.

The second one is, should the allocations made under this proposal be fixed at /22 or tied to APNIC's current minimum allocation?

The third question - should the allocations made under this proposal be linked to an IPv6 allocation?

And the fourth one was - should this proposal reserve a /16 for unforeseen requirements? So, those were the four talked about this morning prior to lunch.

JIAN ZHANG:

What I'm going to do is, we're going to seek consensus on each individual question with the original proposal and then, if that question gets consensus, we were' going to get back to the original proposal and which question has reached a consensus. So we're going to vote again. So that's what we're going to do next.

For the first question, should this proposal be tied to prop-055? Who is in favour of this question say yes. So, would you please raise your hands?

RANDY BUSH:

There was a question, what is prop-055. The question is, should this proposal be tied to the last /8 proposal? In other words, I think somebody over there said it well. In other words, if prop-055 does not pass. In other words, if we do not have the global policy that the last /8 s have been given each one to the global registries, then we do not get the last /8, so should we tie it to that, or say it will happen for whatever the last /8 is. And since, I have got the mic, I don't care! I think the point here is, prop-055 is not going to pass without this. This can pass with or without prop-055.

JIAN ZHANG:

Now, is everybody clear about our question?

So, I'm going to ask again, who is in favour of the proposal with this question? I didn't see any hands. OK.

Who is not in favour, who is going to say no? The question is over there, should this proposal be tied to prop-055?

PHILIP SMITH:

Prop-055 is that each RIR would receive a /8 from IANA.

NURANI NUMPUNO:

Sorry, maybe it's just me. But, the question, I don't understand, is the question whether or not we approve the proposal with it being tied to prop-055 or without it being tied to prop-055?

RANDY BUSH:

Yes.

NURANI NIMPUNO:

But which one?

RANDY BUSH:

OK, what happened at the end was, we perceived that people felt that there were points that needed to be decided that could have gone multiple ways. One of those points was, delinking this from prop-055. In other words, it would apply to the last /8 if we got it at the Crowne Plaza Hotel for lunch. Wherever we got it, it would apply. As opposed to, if prop-055 does not pass, this proposal is inoperative. So one way or another, so we're just trying to ascertain which way the people here feel that the proposal should be modified.

JIAN ZHANG:

Let me do a little bit of clarification, because in the original proposal, that Philip wrote, it is actually linked to prop-055 and Philip would like to do the modification if anybody is strongly against it. That's why we came up with this question. We're asking people if we do the change, are you going to be willing to be in favour of it? .

PAUL WILSON:

I'm a little confused as well. The question is, has the proposal in question been approved yet? It has not been approved, so what we're doing is voting on amendments to the proposal and once all the amendments are decided, the final proposal is being put to the room for a vote. Is that right? Is that the case?

I mean, either the proposal has been approved and we're...

RANDY BUSH:

Actually, the proposal when in consensus was asked for it, was given a light consensus, but some people said we have some technical issues with the details so we're trying to go back and cover those and then re-ask.

PAUL WILSON:

So in any case, the consensus has been reached on the original proposal and now we're adjusting the details?

JIAN ZHANG:

No. My understanding is that we didn't reach the consensus on the original proposal. That's why we're asking those questions.

ANDY LINTON:

I too, like Nurani was confused about which question was being asked here, and I think perhaps a more useful way to phrase this question is, should this proposal actually be the policy for the last /8, regardless of which mechanism it comes by, because if you're actually asking about linking it to prop-055, it is well yes, I think it should be linked to prop-055 but I don't think it should stand or fall over prop-055. So it is much easier to say, should this be the policy for the last /8 that APNIC allocates and then worry about prop-055 afterwards.

EDWARD LEWIS:

Ed Lewis from NeuStar. The question I have is, if we tie this to prop-055, then what is the last /8. But if it is not tied to prop-055, how do we know which is the last /8. Registration services don't always give the last /8, they have a pool of addresses. I don't know if that's true in the APNIC region or not, but sometimes, more than one /8 is being allocated at one time, so it is not necessarily going to be a final /8, regardless of whether it is from prop-055 or not. Does that question make sense?

What I'm asking is, if this is not 55, how do we know what the last /8 is? Will APNIC hold one last /8 in reserve and if there is, will it become subject to the policy. Or is APNIC going to allocate from all /8 s on hand until then?

PHILIP SMITH:

I feel that's an APNIC implementation.

RANDY BUSH:

Welcome to the IETF!

GAURAB RAJ UPADHAYA:

I think my question has been answered.

RANDY BUSH:

Randy Bush IIJ. Does anybody not understand what the question is? Should it be tied to the last /8 policy? Should the two policies be tied or should this policy be independent for whatever APNIC thinks is the last /8? Anybody have any questions on that?

YI CHI:

The previous question asked is that if you untied it with prop-55, then what's left and you could... implementing this for /10s or, how are you going to do that? I think it needs clarification.

RANDY BUSH:

No, it doesn't. If you don't think you can identify the last /8, then vote "no". If it is yes, then vote "yes". You know, we can go back to arguing if there's two dots.

I think the two dots should be at 45 degree angle. Could the Chair move this along please.

JIAN ZHANG:

So, I don't know, if people will feel better if we just say, "This proposal will be used on the last /8, whatever APNIC has?" Even though there's no prop-055.

RANDY BUSH:

That's the question.

JIAN ZHANG:

OK, let's put it this way. So, would you please show your hands if you favour just what I said. This proposal is used on the last /8 APNIC has.

OK, thank you. Who is not in favour of this question, please show your hands. OK, I guess - I think we reached consensus on this one.

PHILIP SMITH:

Right, so the next one. Should the allocations made under this proposal be fixed at /22 or tied to APNIC's minimum allocation?

Note, the latter is the proposal, in other words, the proposal is saying that the allocations will track APNIC's minimum allocation.

JIAN ZHANG:

Would you please show your hands who is in favour of this question tied to our proposal.

DAVID WOODGATE:

Sorry, it does need to be separated.

RANDY BUSH:

Should you write, "As opposed to"? OK, that will do too.

PHILIP SMITH:

Either or.

JIAN ZHANG:

So, who is going to be in favour of the question, "Should the allocation made under this proposal be fixed at /22"? Who is in favour of this question, please show your hands.

OK, I will take that as a no.

So, who is going to be in favour of - "Should the allocations be tied to APNIC's minimum allocation"? Whatever the minimum is.

I will take that as a yes, so we reached consensus on the second option.

PHILIP SMITH:

So the third question that was discussed during the Q and A before lunch was, "Should the allocations made under this proposal be linked to an IPv6 allocation?

JIAN ZHANG:

Would you please show your hands who is in favour of this question.

Thank you. Who is not in favour of this question?

From what I can see, it is like 50/50, people saying yes and no. So, we're going to just dump this question in the proposal.

PHILIP SMITH:

OK, the fourth question was, "Should this proposal reserve a /16 for unforeseen requirements". If you remember from the text, this was item 4.3.

JIAN ZHANG:

OK, who is in favour of the answer to this question, is yes, we should keep to proposal reserved a /16 as part of this proposal? Who is saying yes? Please show your hands.

Who's answer is no? Please show your hands. The people who said yes is over the people who said no. So, you're going to keep the reserve /16 in the proposal.

DAVID WOODGATE:

Can I ask another question please, just about a previous question on the IPv6 allocations. I don't know whether it would have changed anybody's positions if it had been tied to IPv6 allocations or NAT plans? I don't know.

JIAN ZHANG:

I think we asked this question just because some people talked to Philip and said, we would like to add this expression in the proposal and he would like to see what others feel on this question.

DAVID WOODGATE:

There was also some question about NAT prior to lunch as well.

RANDY BUSH:

They don't need to have plans for IPv6 or NAT. They're going to do one or the other whether they like it or not.

DAVID PEMBERTON:

In that way, they're going to have to get it whether they like it or not anyway. I don't think just making a requirement that they get some adds or removes anything from the plan. I think, you know requiring them to get the last 22, people have a plan to deploy some, might make a bit of a difference, but just requiring that they come and get some, I don't think makes a difference either way.

TOMOYA YOSHIDA:

I wanted to count from the last questions.

JIAN ZHANG:

Last question, people say yes, is 15. And people say no is 10.

TOMOYA YOSHIDA:

I want to know who is in favour of this proposal, because problem is the size of the /16 or the idea to reserve some of the prefix. I want to ask who doesn't favour of this proposal?

JIAN ZHANG:

I don't know if anybody would like to answer this question.

TOMOYA YOSHIDA:

I think the size is a problem, so we should discuss this?

DAVID WOODGATE:

I suppose I have a lot problem with the way the questions are being asked, but asking people to make up their minds on some of these things in a snap way is asking a lot rather than discussing this on the mailing list. Like wise, you were saying before that you've been taking the majority or 50/50 sort of things as indications about whether things should be taken or dropped. My understanding of general consensus procedures to date has been that consensus has been looking for a clear indication. There hasn't been a clear indication... it's not so much, that's usually an indication further discussion required rather than just saying matters dropped entirely. So, I'm concerned that the process may not actually be working in a consensus way at the moment.

JIAN ZHANG:

I understand your concern. Actually, the reason, the only reason we ask for those questions is because Philip and Randy feels that they would like to make the change if people feel strongly, if they are strongly against something, against all the questions or in favour of on the other way, you know. So that's the only reason we ask those questions. Actually from the result we just show, there is no change - there isn't going to be any change in the original proposal. We're going to seek consensus.

RANDY BUSH:

David, as one of the authors of the current policy development process, let me assure you that we specifically stuck in that there will be time on the mailing list after this. So, people will have the chance to have their voice, and I suspect you'll take advantage of it.

Two is, you either can have it green or red, you know. You can't have the proposal blank in that space.

But number three, to the actual substance of how to choose the size of a /16 or not, it was arbitrarily chosen, and I will accept the blame, and I think we should leave it up to the IETF to decide how much space is going to be needed for something we don't know anything about. This is for the surprise. We don't know what the surprise is going to be, how the hell do we judge how much space we're going to need for it? So, /16! I'm old enough that it was a Class B - I'll admit it!

JIAN ZHANG:

So, any more comments from the floor? Philip, would you please kindly explain a little bit of a summary on this proposal. There's not going to be any change in the original proposal.

PHILIP SMITH:

So, the original proposal is that well, prop-062 is basically, the policy proposal to handle the final /8 under prop-055 whereby, if agreed, the registries would receive one /8 each. That's what this proposal is all about. And it indicates that a new LIR and existing LIRs would receive APNIC's minimum allocation. Well, according to all the usual APNIC criteria for receiving address space, and it would also reserve a /16 for unforeseen requirements. So that's basically what the proposal is about.

JIAN ZHANG:

So, I'm going to ask again, would you please show your hands who is in favour of this proposal.

OK, who is against this proposal, please show your hands?

At this point, we didn't reach consensus on this proposal.

RANDY BUSH:

That was clear consensus.

JIAN ZHANG:

25-7. I wouldn't think that that's consensus.

MATT ROBBMARKHAM:

You said, a few minutes ago on one of the questions, a consensus was reached by 15 over 10; how is the vote now, not a consensus?

JIAN ZHANG:

Actually, I think that's a mistake, because actually we're not seeking consensus when we're asking the question. Because the answer has got to be yes or no, right. And what we're going to do is, if most of the people say yes, we're going to add that modification in the proposal. If no, we're just to leave it there. So that's the reason why. But on this consensus, on the proposal consensus saying we've got to reach consensus if we want to pass it. This is not like - if some people are strongly against it, we wouldn't say we reached a consensus on this question.

NURANI NIMPUNO:

I know throughout the years, we've had many discussions in all five regions now about what consensus actually means, but I think it's generally agreed that consensus means rough agreement, general agreement. It doesn't mean that 100% agrees, it means that most people can live with it. So, if most people think that this is OK and then you'll always have a few unhappy people. If you want everyone to agree, you'll never reach a decision. So, I think bearing in mind that consensus means general agreement, rough agreement.

JIAN ZHANG:

I understand your concern. Actually, we had a lot of discussion about what is consensus but from my understanding, it is for a situation like this, some people are very strongly against this proposal, also for a certain amount of people who are against this proposal, we wouldn't seek consensus.

RANDY BUSH:

I just want to recount the people raising their hands.

GAURAB RAJ UPADHAYA:

I just noticed that when the 10 versus 15 or 25, that it was 10 versus 15 rather than seven, so if that made a different measure of consensus, then, if you remove that earlier question about the last /16, I would say that the room has reached consensus. I can see the hand counts standing in the corner, so exactly what Matt said earlier. Those two things don't seem to match.

OK, let me repeat myself, the people who oppose in the final consensus bid were also against the /16 count.

RANDY BUSH:

How many people who were opposed were opposed only because of the /16? Was my question clear? How many people who voted "no" to the proposal voted "no" because of the last /16? OK, so I don't think that was a major problem. Two out of seven.

OK, could we get a clear show of hands, raise your hands high and we will actually count how many people are for this proposal. I would like multiple counts please. Sam, could you count?

GEORGE MICHAELSON:

Plus one from the Jabber chatroom too.

RANDY BUSH:

OK, could we have separate counts from the Secretariat please.

Did you count the Jabber room one?

SRINIVAS CHENDI:

44 is what we've got.

RANDY BUSH:

Those people against the proposal please.

Shall we move along!

JAMES SPENCELEY:

A quick observation, in the case where a vote is close but a lot of people abstained; it might be valuable based on that that we recount and do that often, that seemed to stimulate enough people to change their vote.

DAVID PEMBERTON:

You would just have to be careful that it is not a case of - I like not this result, bring me a new result!

JIAN ZHANG:

Yeah, I actually got that feeling too. Because, obviously it is different from the last count. People vote differently this time. Only two people against it!

RANDY BUSH:

So, whoever the goddess of the agenda is for tomorrow, a discussion of consensus, thank you.

Moving right along, prop-055, this is the one to which we're tying this. This is the one that's on the laptop. This is the one to which we did or did not tie the previous proposal. To be honest, I don't remember.

And this says - this has to be a global policy because this says how IANA does things so this must be agreed between all regions.

Do you have the status between the regions or should I do that now? Thank you.

Back to contents

prop-055: Global policy for the allocation of the remaining IPv4 address space

IZUMI OKUTANI:

Izumi Okutani from JPNIC. Since we've been making this proposal for the past few APNIC meetings, I would just make the introduction of this proposal really, really brief. And the earlier proposal that we just confirmed the consensus, that discussed the distribution of the last piece of IPv4 address space that APNIC has to its LIRs. This proposal is about how IANA, would distribute the last piece of IPv4 address space to RIRs, including APNIC. So, that's what this is about.

And well, I've written all of this in three steps, but the proposal itself is very simple. What it says is that IANA will reserve five /8 s out of its unallocated pool to RIRs from the standard allocation pool, and when the standard allocation pool to RIRs runs out, then IANA will simply distribute a single /8 to each RIRs to completely use it's v4 allocations stock. So, what it does, I've just displayed on the side here, the difference between applying this policy and not applying this policy.

First, the diagram above shows what happens if we don't apply this policy. So, from APNIC's perspective, at the time when IANA's remaining pool is very limited and you make a subsequent allocation of, for example, two /8 s, depending on the timing of your request and you know the situation in other RIRs, if there are no stocks available in IANA whatsoever, there's a chance of getting zero /8 s, but if there's just, you know even though what you want is two /8 s, there's a single /8 available, and you happen to be the next RIR to make the request, then you will be able to get a part of the address space that you requested and if you're very lucky and there are still stocks available in the IANA pool and no RIRs have requested for that space, then you might also have a chance to get fully what you wanted.

However, it really depends on the timing of your request and the situation in other RIRs. So, by applying this policy, it ensures that you will get, each RIR will get at least a single /8 each and it reduces the chance of uncertainty, whether you will get no /8s whatsoever, a single /8 or, you know totally able to receive what you wanted. So that's the basic idea behind the proposal.

Its advantages - I think I've pretty much explained as a part of the proposal. Each RIR will know in advance that they will get a single slash eight for sure as the last piece of allocation from IANA. And then, this will help in RIRs on planning how they will distribute their IPv4 address space within their region to its LIRs, like what we discussed in the last previous proposal - I can't remember the exact number. Yeah, 62 or what Philip has proposed before me.

And the possible disadvantage would be that some people have expressed concerns that since the rate of consumption of v4 address space depends on the region, some regions you know use up the space really quickly, others very slowly. So, if we just affix a size, a /8 flat to everybody, then you would not be consistent with the actual consumption in each RIR region. However, there's - well, let me counter argue against this point, that the impact of a single /8 in RIRs with high consumption rates such as APNIC, ARIN, and RIPE, it's not very big. It's an equivilent of one, two, three months of allocations. So, if we think about this negative impact, it is quite small. And if we balance out with ensuring that we will get at least a single /8, well, as my personal opinion, I think the benefit is larger than this disadvantage. And that's basically the introduction of the proposal and just to briefly introduce the current status. Consensus has been reached in three RIRs. I don't know exactly the date for each one, but ARIN, I think it was in April; LACNIC maybe the following month and AfriNIC pretty much around that time as well; and there has been a last call for consensus - I don't know if you would call it consensus in RIPE, but last call made in the RIPE region for this proposal as well. So I would and we are still waiting for the chair to make this decision at this stage in the RIPE region. And there has been some discussions at APNIC, and in the last APNIC meeting, we found that there was support in general from the participants. However, a concern has been expressed that we haven't really defined how we will use the final /8 within the APNIC region and unless this is defined, the benefit of this proposal isn't clear.

And well, as you can see, we have reached consensus in the proposal before this, so I believe this concern has been solved.

Lastly, this is not directly related to the distribution of the last /8 among the RIRs, but other regions have also started discussing on what they're going to do about the last v4 space within their region. For example, LACNIC have started discussions on how they're going to use and reserve a part of /12 to newcomers and ARIN has started discussions on how to use the last /8 and they are encouraging the deployment of IPv6, so I think all of the regions have started considering what they're going to do about the /8, based the on the assumption that they will be able to receive at least a single /8 from IANA as the last allocation. So, that's all from me.

RANDY BUSH:

I remember the ARIN meeting; by the way it was October last year I think. Some people here from ARIN can correct me. And I thought that this proposal would be very contentious in ARIN and in fact it passed by a ratio of 9-1. Discussion, David?

DAVID WOODGATE:

I just want to emphasize for the APNIC community, we do need to appreciate that the implementation of this proposal in combination with prop-062 will mean a couple of things. Depending on timing and when prop-055 kicks in, as distinct from where APNIC is in its allocations cycle. Effectively, it will mean that the run out of - for anybody who needs larger than a /22 in their allocations, the run out of IANA will effectively mark the run out date of APNIC for larger allocations. That means that I think you'll find that I mean that that would mean that the run out, the effective run out of APNIC would be moved towards the first quarter of 2011 at a guess. But, I'm quite happy for anybody to dispute that comment.

I agree certainly that the actual temporal impact is a matter of months, not years. But, you know, if anybody is keeping in mind the requirements and they're planning over the next few years, they do need to keep that in mind. Thank you.

IZUMI OKUTANI:

OK, thank you for the note.

RANDY BUSH:

Actually, David, given prop-062 passing, the impact is used. Right? Having that /8 allocated under /22 extends the utility of that /8 for five to ten years at opposed to Optus getting it all on day one.

DAVID WOODGATE:

But as I was saying to anyone who is going to realistically need more than a /22 for their own planning purposes, naturally they won't be able to use it.

RANDY BUSH:

Do Manila and Hanoi have a chance to ask questions or state opinions?

SRINIVAS CHENDI:

They were given a chance, but no questions.

RANDY BUSH:

This is a fairly important proposal, so admittedly we have discussed it a couple of times before, so anybody have...

PAUL WILSON:

Wondering if you can show us Manila or Hanoi, rather than the question mark that you're now on the presentations.

RANDY BUSH:

Does Hanoi have any comments or questions? I want you all to be able to see Hanoi. There you go. Hello Hanoi.

SPEAKER FROM HANOI:

Hello.

(INAUDIBLE)

RANDY BUSH:

No, we have not understood any questions from you, Hanoi.

SPEAKER FROM HANOI:

We support prop-055.

RANDY BUSH:

OK, thank you. OK, here's Manila. Our friends in Manila - do you have comments, questions, anything we can do to help you understand or come to feeling about this proposal?

SPEAKER FROM MANILA:

Hello, we have no questions or comments on the policy at the moment.

RANDY BUSH:

We will see you in six months.

Moving right along, do people, you know, we're seven minutes from break. We can start break early so people can come back and start the consensus or we can do it right now.

We specifically time these things so there can be a break for people who are not - English is not their mother language to be able to discuss among themselves.

This place is very quiet.

IZUMI OKUTANI:

So, does everyone understand this proposal and any questions?

GAURAB RAJ UPADHAYA:

We do it once before the break and again after the break!

RANDY BUSH:

Gaurab, how do you feel about the proposal?

GAURAB RAJ UPADHAYAl: I support it.

RANDY BUSH:

OK, what the heck, how many people support prop-055 as stated?

Thank you, I'm not going to count. How many people oppose prop-055? I think we should go and have some coffee or tea.

IZUMI OKUTANI:

Thank you.

(end of session)

Policy SIG

Thursday, 28 August, 2008

1530-1800

RANDY BUSH:

Brenda, are you around? There you are. You are right, it is Jonny. Let's get started again. Despite Gaurab's suggestion that we do it twice just for the fun of it, I think things were pretty decisive last time, it was clear with consensus in favour of prop-055 and for the benefit of the schedule we will move along to... it says the same thing, right? Reducing the timeframe of IPv4 allocations from 12 to 6 months. Woops?

DAVID MILES:

Do you have a moment to have a couple of comments? David Miles, Alcatel-Lucent. David made the point regarding the proposal discussed prior to the break, acknowledging that APNIC's current consumption of IPv4 addresses means that policy is going to be felt most - most impact is going to occur right here. You are really saying when we are come down to the final five /8s. We are going to be really good citizens and allow every other RIR to get, potentially, more than their fair share. And as David said, this is going to mean, within this region, those service providers who use most IPv4 addresses are going to effectively exhaust their pool earlier than had been previously envisaged. I just want to be sure everybody is aware and prepared for that, admitting it is an inevitability, but bringing it forward by even a few months, could have some impact. So I just wanted to - I guess discussion and mailing lists are probably the most appropriate place for this to continue.

RANDY BUSH:

Indeed.

GEORGE MICHAELSON:

Sorry, I have a comment from the people in Manila I would like to add to go into the record. This is from Bani Lara and it is an observation that have a group there of five network providers, their initial consensus feeling around prop-055, the previous proposition, they agree with equal allocation of the remaining /8 to the RIR.

RANDY BUSH:

Thank you.

DEAN PEMBERTON:

Move on, just get on with it. Given that as Randy was saying before this is actually the last /8, do you want to be spending it, selling more dial-up customers or using it as transition to the next thing?

RANDY BUSH:

Maybe we should be taking this to the mailing list.

DEAN PEMBERTON:

Thanks.

RANDY BUSH:

Mr Martin, moving along.

Back to contents

prop-063: Reducing timeframe of IPv4 allocations from twelve to six months

JONNY MARTIN:

Prop-063, reducing the timeframe of IPv4 from 12 to 6 months. That is the proposal, there is not a lot more to it. The current problem we have got is the allocation window is 12 months. As we are running out of v4 addresses, that means we are getting closer and closer to the point where a small number of organizations, potentially, even one can suddenly snap up, you know, almost all the available address space. So by attempting to, by wanting to reduce this to six months, it is an attempt to smooth out the allocations, that everyone gets a chance of addresses when they come up, when they require them. So at this stage, 12 months, it is, we can consider it is a little bit too long. Other RIRs, it hasn't been submitted yet but AfriNIC, ARIN, LACNIC, and RIPE do the same, they estimate the same.

For APNIC, it is up to 12 months, not 12 months itself. So we propose that we change the timeframe of these allocations to meet the LIR's need from 12 months down to six months, it means when you are applying, you are only looking at the six-month window and obviously, at the end of the six months, if you require additional addresses you are happy to head back to APNIC to put in another application. The advantages of this, it gives us much more even distribution of these remaining addresses from now on and ensures that all LIRs and NIRs have a greater opportunity to participate in the remaining v4 address runout phase, which is pretty much from this moment onwards.

Disadvantages, of course, are the LIRs themselves only receiving six months' worth of addresses, rather than 12 and that, in turn, could mean a doubling of the amount of work required both on the LIR's part and the APNIC Secretariat. So, a potential doubling of the workload. Impact on other members and NIRs, it impacts all APNIC members, it has no impact on NIRs but impacts their members in the exact same way it impacts APNIC members.

Just got some additional data here, which is from the Secretariat here. This is looking at APNIC members, LIRs, it excludes NIRs and their members. It is a count, for a given LIR, how many months until they are back to APNIC for additional addresses. Note with these stats here, they don't necessarily tell us the window of an application from an individual LIR, simply, how soon they came back to get more.

So the two things combined and these stats are obviously, if an LIR applied for addresses and burned them through a lot faster than they were expecting, we can't confirm it from someone who went through it slowly to come back in 12 months or more.

So we can see that 44% of people are working within six months anyway, so it is not going to really going to impact them. But from informal chats with the APNIC Secretariat, they seem to feel it could be looking at an additional 25% workload, that is a very informal number. So the Secretariat may be able to comment further if they wish. Based on that, we could look at an additional hostmaster to handle the workload. Does anyone from the NIRs here have a feel for what these numbers are like? For your members? Izumi?

BILL WOODCOCK:

I can't give you an exact figure. Probably 30% or 40%, especially in the last ones, they tend to go for more. So probably not so finite with our data.

JONNY MARTIN:

It is fair to say that dropping down to six-month window is not going to have a huge impact on most members.

GUANGLIANG PAN:

Just for the hostmaster, actually it is not the numbers there, a subsequence, the IPv4 allocation is 40%. Some come back in less than a year and some come back in a few years' time. Based on the host-master feedback data this year, we think about 25% of the hostmaster will be added.

RANDY BUSH:

Excuse me for not walking to the floor, Randy Bush, IIJ, I asked a hostmaster in another region whom I have known for many years what they thought of this approach. Their opinion was that as v4 ran out they thought that making the windows smaller, like six months and maybe less in the future, would be a natural way to see that as v4 ran out, it got most efficiently spread and they were more interested in that than were worried about, you know, than others. They weren't paying the money. But they saw it as one of the pieces of physics of runout.

DAVID WOODGATE:

I actually support this proposal in principle. You wouldn't believe how glad I am to say that today.

APPLAUSE

DAVID WOODGATE:

I do need to point out that doesn't it have an implication of effectively requiring the smallest members of APNIC to double their size? In the sense that previously, if you have justify a /22 over a period of a year, your request is now only for six months, then effectively, you have now doubled the size, you are asking somebody who is likely to consume a /21 within 12 months sort of thing.

JONNY MARTIN:

I guess it may have to be an update for the minimum allocation size at the moment. I guess, the criteria for getting address space in the first place is presumably still for that year period. We are only talking about the smallest members here, presumably they won't become members unless they can justify the address space over a year. So, I guess, it kind of excludes the smaller members in that sense.

IZUMI OKUTANI:

Let me separate my personal opinion and opinions from our community for this proposal. I can understand the motivation and a personal opinion, I would think the impact to the members is not as large as some of our community members are concerned, as I mentioned earlier. Quite a number of members request 3-, 4-month period but when we discussed it in our community, people weren't necessarily opposed to it but they weren't really sure how, how far, positive effect it would have in reality. They understand the concept, it would give LIRs a chance to make subsequent allocations but it would increase the numbers from 4 to, say, 50, and then 60 and they have to make allocations twice a year. Then they feel the balance of, you know, the efforts they have to make and the benefit doesn't really like work out. So they are interested to know what would be the likely effect of this proposal? And so at this stage, they are not supporting the proposal.

JONNY MARTIN:

I guess, on average, it is not going to impact anyone. But when you get down to the final allocations, somebody is going to take the last allocation and there is going to be a queue of people waiting behind them. If the last allocation is a large one, they will be happy, obviously, they got the last allocation they required. The people behind them are not going to be so happy.

IZUMI OKUTANI:

We are clear about that part.

JONNY MARTIN:

Whether, I guess, people are going to be happy with this, it is going to depend on where they fit in the timeline. So, yes, it is.

IZUMI OKUTANI:

I guess, it is a bit of a difficult question to answer, more specific data, but sharing the feedback.

JONNY MARTIN:

Yes, it could be interesting to see a graph, much along the lines of Geoff Huston's existing analysis of v4 depletion, that sort of thing, breakdown of individual LIR level, so continuing that step and that graph downwards, it will give us a bit of an idea of what it is going to look like. I think at this stage, we can only really look at the aggregate level, high level, just see that a small window is going to smooth it out.

IZUMI OKUTANI:

OK.

NURANI NIMPUNO:

I don't feel that strongly about this proposal, but I think what is kind of interesting about is that maybe what it does is send a signal to all the LIRs out there that, you know, things are changing and you really only have a few years to go and you can't keep count on getting large allocations for 10 years to come, so it is kind of interesting, I think. I don't know.

DAVID WOODGATE:

One of the things, reasons I'm supporting this, I think it is a reasonable compromise between the sort of factors that Randy was talking about and the contrary factors that Izumi was talking about, in terms of as we approach runout, some closer scrutiny is appropriate. I'm not sure I'll ever support going smaller, shorter than six months because it starts smacking of just page-thrashing and administrative overhead for the sake of it. And I don't think that will actually achieve much but I think six months is a useful compromise. But I support this proposal but, to some extent, I would like that to be on the basis of saying they are in a position to take on the extra work load.

JONNY MARTIN:

Comment from the Secretariat on that?

JONNY MARTIN:

OK. Um, any further questions?

RANDY BUSH:

Any comment from Hanoi?

SPEAKER FROM HANOI:

No comment from Hanoi. We have some comment here. There is no comment at the moment.

RANDY BUSH:

Thank you very. And our friends in Manila?

SPEAKER FROM MANILA:

There is one comment from Manila. They just want to mention about the, concerning terms of the workload, because they have to come back every six months if the policy will be changed.

RANDY BUSH:

Could you do us a favour and repeat that? The sound is not excellent.

SPEAKER FROM MANILA:

There is one comment from the member, every 6 months they have to prepare the request if the policy will be changed to every six months a requirement for the allocation.

RANDY BUSH:

So this is a LIR saying that this means they will have to apply for space more often? Is that, I am hearing you correctly.

SPEAKER FROM MANILA:

Yes, it is.

RANDY BUSH:

Thank you.

JONNY MARTIN:

On the increased workload for LIRs, I think it is a given that as we get closer and closer to complete the completion, the workload will increase irrespective of the allocation window, as LIRs are obviously scrutinizing closer what they are doing as well as looking into it NATs and v6 and that sort of thing. I don't think it is fair to blame the complete increased workload on what the allocation window is, because it is going to happen anyway.

JASON SCHILLER:

I just wanted to point out that the LIRs that regularly come back for space because they continue to go, by shortening the window to half of what it currently is, you are also increasing the fragmentation of their routing table and the Internet routing table, internally working on how they do internal aggregation. There is the risk of increasing the number of routes internally and on the Internet table.

DAN ALEXANDER:

Having been the author of the proposal that actually just recently changed ARIN's window to 12 months from 6, some of the thinking along those lines was I agree with you. The point is to avoid the last-minute gotchas of any particular provider, with the last piece of address space. But in certain cases it can actually have the opposite effect in that if you have large providers as you are getting to the end of the pool and you know they have all been accounted for and they shouldn't need space for another 10 to 12 months, you know that they are not going to sneak up on you, because they have been properly allocated. The other point I would make is whether this is really where you want to put that throttle. Because there are other policies, like the distribution of the last /8s to the RIRs and the other policy, what do we do with the last /8? If those are really the throttle points to prevent the gotchas as opposed to the allocation time length.

JONNY MARTIN:

I guess we are looking at a gradual tightening of the belt here, which is what we seen in the related proposals.

PAUL WILSON:

Just to answer a couple of concerns, I think we have heard already that the estimated staff time maximum that might be required to fulfil what our best guess of an increased workload is around one and a half host-master staff at the worse worst, maximum of 30% but well under 5% of APNIC staff, maximally, it is across the entire APNIC cost base it is of the order of, as I say, under 5%. Thinking about this, an analogy just occurred to me, talking back to some of the early ICANN meetings where there was always a long queue of people behind every microphone and normally a very limited amount of time to speak, so there was often the case of someone who would get up to the mic and spend much, much more than the average and prevent a lot of people from reaching the mic and so what they did, of course, was stuck a camera on the screen and gave you two minutes and anyone who spoke for two minutes, welcome to go back to the back of the queue and join again and join again two minutes later but at least you had enough people having a bite of the cherry, that you got to hear the viewpoints, almost any analogy is flawed but it is what occurred to me, thanks.

MAO WEI:

I have a question, I want to know, other RIRs already have this proposal? For the policy.

RANDY BUSH:

RIRs who are here, please correct me, I believe the current status is ARIN has just recently moved from 12 to 6. Whoops! 6 to 12, I mean. Thank you for correcting me. And everybody else is at 12. Am I correct?

MAO WEI:

Any plan to review the policy or submit your proposal today?

RANDY BUSH:

In this case, it doesn't have to be a global policy to work. Would somebody from RIPE like - Filiz, care to speak?

FILIZ YILMAZ:

No, we do not have such a proposal to have our allocation periods to be out to six months. The other question is yes, no, it doesn't have to be a global one, this is a regional proposal but I guess the comment was for a common proposal rather than global?

RANDY BUSH:

What would RIPE think of, you know, how do you feel about six or 12?

FILIZ YILMAZ:

As RIR staff, I'm not here to present my idea but having - we used to have our allocation period set to 24 months, you must remember that.

RANDY BUSH:

24?

FILIZ YILMAZ:

Two years we used to use and it has been changed for a year. We consider it a discussion point. However, it has just changed.

RANDY BUSH:

And how was that change?

FILIZ YILMAZ:

You mean, well, actually the idea, it is interesting you are raising this now because at the time we were the RIR who was allocating on the longest allocation periods as 24 months and we wanted to sync it with the other RIRs, thank you.

IZUMI OKUTANI:

Regarding the point that Mao Wei raised, I understand it doesn't have to be a global proposal but then we have to maybe think about the consistency with other regions as well. Because maybe, you know, LIRs in our region feel disadvantaged that we will get, they will get actually yes, LIRs in other regions, so - get less than LIRs in other regions. Taking that into consideration, we will just shorten our own period, that is OK, but I think it is a point we should consider as well.

RAUL ECHEBERRIA:

Thank you, Raul Echeberria, from LACNIC, as Filiz said, we synchronize the, this point in the past, it took some time to coordinate among all the RIRs to ratify the issues that were applied in a different way, in different regions, so we took some actions for using the same practices. The last year, it was the final changes in some of LIRs to adopt the same criteria. Currently, there are not any do's for approving the policies in every region. When the NRO signed the agreement, the memorandum of understanding with ICANN, there were two policies included, original, and global policies, global policies need in some way the participation of ICANN. There have been some proposals for amendment to include the existence of coordinated policies because we can approve all the RIRs, can adapt the same policy today, there is no warrant that one of the RIRs or more will not change the policy in the future. So this is an issue that is on the table for being discussed by the board of the RIRs, if their willingness or not to change the memorandum of understanding but by now, there is no tool for assuring the same policy could be adopted in every region it will remain as it has been adopted.

RANDY BUSH:

Okie doke. So this is prop-063. I think since it is a proposal, let's try to see what consensus is on it. So those people who support Jonny's proposal to reduce the timeframe of allocation, justification from 12 to six months for IPv4 allocations, please show so by raising their hands. Could the Secretariat count? Because I think we will have an interesting one here. Raise them up, come on, get them up here. I only count when it looks like it might not be obvious.

SAMANTHA DICKINSON:

I have 22.

RANDY BUSH:

Those opposed? I think I would like to hear a count, wait a second. Let me complicate things those strongly opposed? And I am going to ask for strongly in favour also. Those strongly opposed? Get them up. And those strongly in favour? OK. I think I could declare consensus but I would rather not. I think I recommend that we continue to discuss this and it will give us something to carry forward to Manila, is that OK with everybody? Is anybody strongly opposed? Thank you, Jonny. Okie doke. Whoops!

HEATHER SCHILLER:

Could we have a count?

SAMANTHA DICKINSON:

There was one half up.

RANDY BUSH:

Approximately.

SAMANTHA DICKINSON:

16 against, one half a hand for strongly opposed. Is that strongly opposed?

RANDY BUSH:

Yes, whatever!

SAMANTHA DICKINSON:

And I think there were 4 or 5 hands for strongly 4.

RANDY BUSH:

What about the first count? I saw that at about 2 to 1.

SAMANTHA DICKINSON:

There was 21 to begin with. 16, half for.

RANDY BUSH:

Right. Heather, I normally wouldn't ask for a count, I just suspected it might be confusing enough that I actually need the numbers. Normally, I should be able to see consensus. Right? Go for the mic.

HEATHER SCHILLER:

I guess I'm going to start by saying that my company does actually hold resources in this region and so for that reason I'm also interested but also interested as an observer of other region's policy development process. I find it extremely useful if you actually take a count and we can have that data to go back and look at later. When you are look, when we were looking at an earlier policy, it was 6 to 0. And in the discussions about how to gauge consensus, I understand every region does it differently, but having that information is helpful for people on the mailing list or who weren't at the meeting what the room felt, rather than just saying there was consensus.

RANDY BUSH:

I have managed to get this on the agenda for tomorrow.

HEATHER SCHILLER:

Yeah!

RANDY BUSH:

Brenda? You should know that I'll repeat, prop-059 has been taken off the agenda so after Brenda we have Geoff with prop-050. This is a new proposal we have not vetted before, it is trying to deal with historic address space, counting it when trying to justify the application for new address space. I have, I believe we see an attack of coauthors.

Back to contents

prop-066: Ensuring efficient use of historical IPv4 resources

BRENDA TARIMEL:

Thank you! Good afternoon, everyone. I guess IPv4 is a scarce resource and this proposal prop-066, ensuring efficient use of historical IPv4 resources. A couple of problems with this one. This will, the current problem are LIRs applying for new IP allocations from APNIC only have to include the past allocations received from APNIC, they are not required to declare any historical addresses they may have received prior to their receiving their space from APNIC. Can I go back?

And another couple of more problems with this one, the use of the historical IPv4 addresses is not known or not documented at the present time. LIRs can receive IPv4 addresses from APNIC while holding unused historical addresses and this uses up the remaining IPv4 pool rather rapidly than necessarily. Here are some historical references to the definition, one for registration transfer to APNIC as part of the AUNIC to APNIC migration. The other is a registration transfer as part of the ERX and the other one, as historical APNIC resources which were delegated to organizations by APNIC prior to the introduction of the membership structure.

Situations with the other RIR regions, ARIN and LACNIC, do consider historical addresses, AfriNIC and RIPE do not. Unless somebody can refine that here from other regions? The proposal is essentially to make that criteria for receiving IPv4 addresses, to modify that to include historical IPv4 holdings. And this applies to IPv4 resources registered in the APNIC Whois Database and it will have no historical fee implications. The advantages is to ensure efficient use of scarce IPv4 addresses to the fullest extent and use of historical IPv4 address will follow the current best practice for address management and the remaining IPv4 free pool will be allocated to LIRs that have a genuine need for IPv4 addresses.

Of course, there are disadvantages. The organization will be unable to hold any historical IPv4 addresses while at the same time holding more IPv4 space from APNIC pool. Organizations with historical addresses may find it hard to change their network architecture if it uses historical IPv4 address in an inefficient manner. However, the difficulties are outweighed by greater benefits and use of the scarce IPv4 addresses.

Any impact on APNIC members and NIRs, APNIC members who have applied best practices for address space management will not be affected. APNIC members who have not applied best practice will be affected. NIRs will not be affected but their members will be affected in some ways as it has impacted the APNIC members. That is it. Any questions?

GEORGE MICHAELSON:

I have some late feedback to get on record from the previous proposition from VNNIC, the members are concerned six months is short in preparing network plan and they are concerned about more workload for an ISP staff.

RANDY BUSH:

I owe both the Vietnamese and Philippine friends an apology for forgetting to poll them last time.

GEORGE MICHAELSON:

There is one more vote to be noted in favour of the proposition. It is my fault.

RANDY BUSH:

No, my fault, staring me in the face on monitors and I forget.

DAVID WOODGATE:

I am basically in support of this proposal, over the past couple of days, you may have noticed on the mailing list a couple of questions about whether I thought this proposal would be actually applied, given the way that APNIC recognizes "ownership" of historical resources. If, I believe, historical resources can only be transferred into APNIC member accounts through proof of declarations with those historical resources, therefore, this proposal, I think can only really be applied to historical resources that already have been transferred into an APNIC member's account. Having said that, I thought previously, that any historical resources that were in APNIC's member's account were being assessed for due usage.

I gather that is not the general case, there is just a peculiar circumstance and there has been an assessment of appropriate historical resources in the past for our networks. So my appreciation is that this proposal can be applied to historical resources that have been transferred into the account, the APNIC's accounts of members. I do not believe it can be applied to resources which have not been cleared, declared by members, I suspect members will still be able to effectively by-pass the policy by just failing to declare their association with historical resources which are not appearing in their member's accounts, I still think that it is still worthwhile going through this particular policy though. A couple of other very quick things, just about semantics of the proposal, if you could go back it the proposal slide, that would be great. Thank you.

Just hate to be pedantic, but given it is a policy document it should reflect accurately what the proposal is, I do feel the first sentence doesn't state how the criteria are being changed or in what sense. I think from, anyone who is dealing with it on a day-to-day basis, we interpret what is assumed here but it doesn't say the criteria is being modified, that the assessment of address space is being considered to include historical address holdings. It is not clear what the - from that top sentence alone, that how the historical IPv4 addresses are being included, which criteria they are being included in. It is just a minor point of semantics but I think it should be cleared up in the proposal.

IZUMI OKUTANI:

Well, we support the concept of the proposal to take historical address space into account in making sure that LIRs who request subsequent allocations should efficiently use this space. I don't know, it might sound like picking into details but we are concerned how it would be applied in operations, as David has pointed out. Because unless we know, you know, how LIRs with historical address space should request and how it will be assessed, it is very difficult to assess its impact and we want to ensure we wouldn't have extra disadvantages for, I mean, I'm sure they will not feel comfortable if they are not efficiently using it, that is fine, that is perfectly OK but we shouldn't put them into extra disadvantages by adding this proposal. One of the concerns that was expressed was they wanted to find out if they will be able to make customer assignments from this historical address space. The reason for this is that if they can only use it, sorry for being into a bit of detail here, the reason for this is that if they can only use historical address space for their own infrastructure, maybe they can't fully meet their needs and it is the conditions are not as equal as the standard PA allocations. So that would put them into disadvantage if making assignments from the historical address space is not allowed. Am I making myself clear?

RANDY BUSH:

I believe I understand what you were saying but what I don't understand is what would cause them to think that the way they use that historical space has any restrictions that, the way they use any other space has?

IZUMI OKUTANI:

Because it is registered as an assignment and usually assignments are not allowed to make further assignments to other organizations.

RANDY BUSH:

Thank you. Raising your hand is insufficient, you have to walk to the mic.

IZUMI OKUTANI:

So what would be the answer to this point?

RANDY BUSH:

I'm not sure what the answers would propose, I think you need a fix.

JAMES SPENCELEY:

You have to justify your historical space on your next request for new resources, that being there is some valid - we need to actually define what the status is, I guess, of the new allocation.

RANDY BUSH:

I think Izumi's point is, now that I understand it, I think it is substantial, that you are going to have to change an allocation. So you are going to have a process to do that, so that then they can assign it. So then it is utilized.

IZUMI OKUTANI:

We generally support the concept, but unless this part is clear.

RANDY BUSH:

There are details.

IZUMI OKUTANI:

Yes, that is our position.

PHILIP SMITH:

My question then back to APNIC and NIRs is what do you do today when an LIR has assignment and allocations? How do you do an assessment? We are not proposing again to tell the registries and NIRs how to do the assessment, we are simply proposing that APNIC and NIRs include historical resources when they do assessments, however those assessments are done.

GUANGLIANG PAN:

I would just give some data about historical resource. Actually, APNIC have about 3.6 /8 historical resources. So far, that is about 2.6 /8 has been taken by members. It is about 1 /8 still, no-one claimed it, at this stage. That is how the policy will be affected, the total amount of the historical resource. It is OK, 3 /8 will be affected by the policy. Another question, like how, the host-master the IPv4 address allocation, at this stage, the historical resource is not subject to current policies we don't ask them the use rate and how they use it. That is the situation, I think this policy mentioned and tried to address.

IZUMI OKUTANI:

Same situation, we don't consider it as part of the, you know, we don't consider it when evaluating it at this stage, our suggestion would be if historical addresses are allowed to be treated, just ask portable allocations and they are changed in such a way they can make further assignments, maybe they will be, the historical address holders will feel more comfortable with this proposal?

SYLVIA SUMARLIN:

How far back do you need the data? In Indonesia itself, we just begin to ask them to put in historical data when they request new ones, which is like the past two years. So if the ISPs - let's say there is an older ISP who started in 1995, 1996, wanted more and you require that, they might not have it. So there should be a clear cut, when do you start? How far back do you need the historical data? Thank you.

PHILIP SMITH:

Yep, it is the historical data that is in the APNIC database, if it is listed there, that is what we would like to be considered. I would still like input from Secretariat or the NIRs as to what they do in the mixture of, when an LIR has allocations and assignments. What I'm trying to say, I don't want us as proposed authors to tell APNIC how to do their jobs.

SAMANTHA DICKINSON:

Just clarification about historical address space in the database if it is a /22 or larger it is registered as portable allocation, if it is smaller than a /22, we consider it an assignment, so along the lines of current address space, if it is smaller than a /22, it is an assignment, if that helps. If it is longer than a /22 it is considered an assignment.

JAMES SPENCELEY:

I guess the theory was to get people to identify the history of the address space, the main principle is that people need to justify and be subject to the same criteria.

RANDY BUSH:

Excuse me for being rude to the people in the audience but I was rude to the remote participants last time, so I would just like to give them a chance to step in, Manila, any comments or questions?

GEORGE MICHAELSON:

The Manila attendees have indicated if it goes to a show of hands they would like to agree to the proposal, the use of historical addresses should be declared.

RANDY BUSH:

I did not understand your statement. Who? What did they say.

GEORGE MICHAELSON:

The five operators in Manila say they agree on the proposal; the use of historical addresses should be declared.

RANDY BUSH:

Thank you, and our friends from Hanoi?

GEORGE MICHAELSON:

I forgot, the friends from Hanoi have said they have no historical resources, so they don't think they have relevant input to make on this.

RANDY BUSH:

Thank you, our brothers and sisters in Hanoi.

IZUMI OKUTANI:

Just sharing the situation in Japan. All historical resources are registered as assignments, so if we are simply apply the current policy for these proposals, it is going to be considered as utilized because it is registered in the assignment, so it would probably not meet the purpose of the proposal as the way we run it. That is why I earlier proposed if we can convert the historical assignments registered to be considered as portable allocations and allowed to make further assignments then that would probably meet the purpose of the proposal as well as, you know, the need of the historical address holders. Just an idea.

PAUL WILSON:

A few things to say in no particular order. As Jiang mentioned before, a member applying for address space declared whether or not they have historical address space, we are not documenting its usage, so as I understand, this proposal actually is requesting that APNIC gather the documentation about the usage of address, historical address space before allocating more address space, is that correct? OK, and I would just pick up on something James said before, he said that this was this proposal was attempting to justify the usage of historical address space and I don't think it, the intention is and I don't think it is possible for APNIC to examine historical address space for the purpose of justifying that address space, for instance, if it is not found to be justified it should be taken away, because we actually don't have that kind of authority at all. What we do have, I would suggest, is the ability to say if you are asking for more address space, you need to demonstrate your need for more address space and it involves the documentation of current and historical address space.

RANDY BUSH:

The proposal is exactly what it says.

PAUL WILSON:

OK, just clarifying the idea of justifying historical, as if it might be subject to reclamation.

JAMES SPENCELEY:

No intent to impose that on historical.

PAUL WILSON:

Sam mentioned we are treating the historical delegations of address space larger than /22 as allocations and I think it is not strictly a policy distinction. It would imply, and I don't see a policy reason why it should not imply the ability to sub-delegate as Izumi has asked, but I think it is a grey area. As I have tried to mention here, the authority to assert policy over historical address space, I think is quite unclear and in fact, because it is unclear we don't attempt to assert rules, guidelines or authority over how historical address space is utilized. I would say there is not anywhere a written prohibition on sub-assignment or sub-delegation of historical address space in my opinion, as I understand things. But if the sake of documentation, as Sam has said, by a sort of an operational administrative convention, we have documented delegations of larger than /22, as being allocations and delegations smaller as being assignments.

I think that in the case of historical, the distinction there is not a particularly important. But in either case, I would say sub-delegations would be possible. Just one other point I would make, I think the point was raised before that just requiring the documentation of address space doesn't somehow allow us to know how the address space is really being used. The same thing goes for the entire request process. We allocate on the basis of declared documentation and forms, which, to be quite honest, could be entirely false. It would be a work of fiction. The work of hostmasters at APNIC is to examine, make appropriate questions, and make judgment about the credibility of requests and a series of requests. The same thing goes for this type of requirement, if it is approved.

I point out that under the membership agreement with APNIC, members are obliged to provide correct information. The risk a member takes by not providing correct information by the policy, the risk is more retrospective, to be discovered down the track than APNIC staff can magically work out what is true and what is not. Even though our ability to determine the truth is limited and will be limited until we have some comprehensive auditing, for instance, which is being proposed, the principles of the obligations under the membership agreement are still very real and very much a meaningful implication of this kind of policy change. Thanks.

BILL MANNING:

So I guess it is my turn, again? Bill Manning. I suspect that people who hold historical space got the space under a slightly different set of policies and procedures than currently exist. To date, as far as I can tell in the APNIC region, nothing has been done to recognize those historical conditions and terms. And that may be one of the reason why some of that space is not yet brought to the fold. And the ARIN region there is an explicit recognition that people that hold historical space got the space under different sets of assumptions about use and utilization. As we move forward, as RIRs, and particularly looking at the next policy that is going to be presented, there is a strong reason to be able to accurately identify who is the responsible party for all the address space that may show up.

Including historical space. So I'm in favour of things that accurately identify who is the responsible party. I'm not entirely convinced that forcing people who got space historically to adopt to current policies for that historical space is a workable solution. So I'm in favour of some of this policy, I'm not so sure I'm in favour of all of it. Now, regarding the missing /8 in the APNIC region, I have been dually authorized by one of my associates to proxy for whoever that is and I'll take responsibility for that /8, thank you very much, please update the records appropriately.

RANDY BUSH:

I think you misunderstand what we mean by that /8 is not recognized. What they mean is that they have whois data, it is there, we know who owns it, it is like a large amount of data in ARIN space that it is hard to get a response from them. The situation is now, secondly, I believe this proposal is not saying that you have to, as Paul said before, I don't need to say it again.

BILL MANNING:

So in response to that first point and the half of the second point, Paul actually pointed out that comprehensive audits have not been done and perhaps we need those? Paul? Paul? Yo! Bud! Would you object if I was to propose APNIC do a comprehensive audit?

PAUL WILSON:

It is not up to me, Bill.

BILL MANNING:

Would you object?

PAUL WILSON:

I cannot object. Whatever it occurs to you to propose, go ahead. To clarify what Liang mentioned earlier, the missing total of something over a /8 is as a result of a decision of a meeting some time ago. APNIC went ahead, APNIC staff went ahead with an historical recovery process wherein we made elaborate efforts to contact the holders of the space under our administration and we were able to track down, in rough terms, around 75% of the address space we have registered, the historical address space registered and there is still a /8 and a bit more of the records of which we have not been able to contact. The decision of the prime meeting was that we should be recovering that address space and holding it in our database, so to speak, without reallocating it. After having gone through the process of trying to contact, so that is what the missing, that is what the reference to missing address space was. But I have to say we have not been reallocating that address space, it is being held by us in that missing state. As I, if I understand what you just said?

GUANGLIANG PAN:

Just to clarify, it is not a missing /8, actually we got this 3.6 historical resource recording from IAX and also like a period, of reallocated space our, 3, and a half /8 total space and our members actually contacted us to get 2 and a half into their account. It is an underpaying member they are holding 2 and a half, the space and it is about the total of 1 /8 is, they haven't contacted APNIC to update the data base. They are using, some of them, most of them, are actually, and they don't want to change the database, they don't want to contact APNIC or they don't, like, need to contact us. So in the database, there is one /8 in total. It is what I'm meaning.

PAUL WILSON:

I misunderstood.

GUANGLIANG PAN:

Clear now?

DAN ALEXANDER:

Understand the details correctly, in the reporting of the historical records, you are not actually looking to apply policy to those allocations in order to reclaim them, you are only looking to show that they are properly allocated before you give them RIR allocated IT space, so you are not looking to go after them.

RANDY BUSH:

Paul, I think made that, tried to make that extremely clear, the point of this exercise is when I come and ask for new allocation from APNIC to decide if I can justify that allocation my previous APNIC issued holdings will be assessed for utilization and my previous historical allocations will be assessed. That is all.

SAMANTHA DICKINSON:

Just to address a bit further, sorry, the question about making assignments to historical address space, under the historical maintenance guide, we do say historical resources can have can make sub-allocations or assignments, that document dates back a couple of years since the policy came in.

JAMES SPENCELEY:

That has clarified it for you, Izumi?

IZUMI OKUTANI:

Yes, it pretty much clarified the major concern we have, as I said, we support the concept itself, so we got a bit into details of how to find this but generally we are in favour of this proposal.

NARESH ADJWANI:

The scenario has now expanded, not only from best practices being shared by ISPs having a challenge, it has gone to even where countries like Indonesia, they have not even communicated to the ISPs to go for the similar kind of a historical information. I think the horizon has widened. We shall give it thought again, shall it be mandatory to provide historical information or not? Thank you.

JAMES SPENCELEY:

I'm a little confused. The proposal is saying if you have resources that are registered with APNIC, the next time you request address space, you will be requested to justify, or new address space from APNIC, you will be required to also... yes, document the usage of your historical assignment. I don't see how we can widen that any further.

RANDY BUSH:

OK. Uh-huh! Please.

ZHAO WEI:

I do have a question for the Secretariat, I wondered, any data or number that shows how many historical resources holders come back to APNIC before as more resources, either IP four, IPv6, any data on that?

RANDY BUSH:

I suspect the answer is...

SANJAYA:

We don't have the figure handy but we could investigate and send it to the mailing list.

RANDY BUSH:

That would be appreciated, thank you very much. I'm going to make trouble. Well, do a lot of people understand, yes, I always make trouble, Andy, do a lot of people understand the American idiom "black helicopters"? Fear of things we haven't seen yet but, "Oh, my God! The black helicopters could come any day!" One of the black helicopters that hasn't been raised here: what about if they have address space from another RIR that is underutilized? I thought about that and I said to myself, "I think that is going to be a separate proposal". It could be easily separated.

DAVID WOODGATE:

Just addressing that point, as I said before, I think this proposal can realistically only be applied to historical resources that are transferred into member's accounts, therefore, no, you couldn't apply it.

RANDY BUSH:

It is a joke, a little humour!

AKINORI MAEMURA:

I think it is a comment some part of the influence from the JPNIC community, one big concern was raised at our meeting which was this is a quite good proposal to include historical resources to the current policy scheme, that is OK, but I think that is what we, there is a point we are supporting, the concept, but some historical resource holders, LIRs, concerned about, this is more or less the proposal which reclaiming the historical resources, so this proposal should be considered from that point of view. Because if the historical resources should be reclaimed to the registry or not, then after that, the point of the concern is that this proposal consists of that concept in the basis of the proposal. So that is additional input from the Japanese community.

RANDY BUSH:

We are running a little behind schedule so I would like to ask if anybody has a new or strong point, otherwise I would like to call for consensus on the proposal and get to Geoff's transfer proposal, which should be exciting, wake us up. How many people are in favour of this proposal? How many people are opposed to the proposal, I don't think we need a count. Thank you, the proposal has very clear consensus. Okie doke. Thank you, Brenda. Geoff?

SAM DICKINSON:

This has been submitted as a policy proposal, whether or not it is discussed for consensus is up to the proposal author at this meeting.

RANDY BUSH:

Thank you, mam. You can even decide it here.

GEOFF HUSTON:

Doesn't matter to me.

RANDY BUSH:

Thank you, Geoff.

Back to contents

prop-050: IPv4 address transfers

GEOFF HUSTON:

You've seen all this before. The idea was that the reform was going to last all the way through so that the take up of v6. It won't, that's a problem. Realistically, it appears that this industry needs more addresses in v4 than we have addresses in the unallocated pools to last, so you can either look at this option now or wait until it is time to really panic - your call.

This proposal actually simply calls for a very simple mechanism and says that APNIC recognizes the transfer of v4 addresses between current APNIC account holders. You can read that as well as I can, and the idea is that those transactions are recorded in the registry.

The proposal describes what the constraints are and the constraints are that the address block is a /24 and when I said larger, I mean larger in the number of addresses like /23 and /21. And it says that the status on the address is "current" and the subject is current for all APNIC policies. The proposal also describes the constraints placed on this for access to the registry on the source of the transfer and on the recipient. And the details are in effect that both parties have to notify APNIC that it gets published in the log and APNIC may levy a transfer registration, and fee setting is the responsibility of the APNIC EC.

We were asked of course in the policy proposals to list advantages and disadvantages and this is simply a transcript of what's in the proposal itself in terms of the advantages that I perceived. You may see your own and advantages and disadvantages that I have understood from the mailing list and the point of the discussion, since this has come here about three times, I have really spent an awful lot of time describing it and I assume that most of you are familiar. If you want prompts, here are prompts. But mostly, it is up to you. Thank you. For what's changed, the only thing that's changed for the policy proposal is that I've included my understanding of the summary of what is included in the mailing lists on both APNIC and on mailing lists in the ARIN and RIPE comparable mailing lists when they have been discussing similar proposals in terms of recognizing transfer, but dissimilar in terms of details in their respective regions. So the transfer is an inclusion inside the policy proposal of what I understand to have happened in other regions.

I was asked by Randy here who hasn't got a microphone - what were the changes? I have not changed the policy proposal at all between the last time we talked about this in Taipei and now and I have inserted a section on what I have observed in other regions to make, I suppose the consideration of this one that at least you understand the context of APNIC's consideration with respect to other considerations.

PAUL WILSON:

I would just like, I feel like I should make one clarification here Geoff for you, because I was asked this question earlier. The proposal does not apply to address space which is tagged as historical in our database. Specifically, the - well, you said it yourself, it says the address space is tagged as "current". The historical address space is then not included in this proposal as I understand it. And that is even if we have signed for historical maintenance agreement on the address space, then at this stage, it is not included. So that would be current address space, that is the address space under APNIC's authority as indicated by the IANA to APNIC and not historical, not historical results.

GEOFF HUSTON:

This afternoon, I've seen three different definitions of historical and I wasn't paying all that much attention. It really does seem to be a major issue of precisely what we mean when we use that term. I've used blocks called historic when it comes out of 203 /8, which you would say was one out of the administration pool. So I'm not sure that we commonly understand what we mean when we use that particular adjective.

What I meant when I authored this proposal and I was specifically asked by Izumi on the mailing list was that I intended this proposal to encompass all resources that were accounted for and considered as part of the holdings of members whose status in APNIC is current. Now, as a proposer, that's what I thought I had said. The words however seem, as I said, to have some difficulty. I actually think that the word "historic" has some real problems in precise interpretation, but that's my personal opinion.

RANDY BUSH:

This is a conversation we held last meeting. That's why I'm a little surprised when your response to what has actually changed in the proposal was effectively nothing. Because, is there hope that you will clarify this so that we don't have this confusion? I realize you're trying to state it so that we didn't, but clearly despite best intentions, you didn't succeed.

GEOFF HUSTON:

Despite my best intentions, I didn't succeed.

RANDY BUSH:

So can we have another go. Let me propose this - we understand what your intent was. I think your last words were pretty clear - you meant it to be any APNIC account holder whose account is current, all their holdings, whether they got them in an egg muffin or from APNIC.

GEOFF HUSTON:

That's correct.

RANDY BUSH:

So the words are a little confusing, so if we call for consensus, and it gains consensus, you'll then fix that.

GEOFF HUSTON:

That's correct.

RANDY BUSH:

Thank you. Does that make you happy, Paul? Well, do you understand it?

PAUL WILSON:

I am simply wanting to clarify for the sake of the audience and the people who have asked me about it, Geoff, the definition and for everyone to benefit, the benefit of "historical" is actually set in the historical resources transfer policy. The historical resources maintenance management policy which Sam pointed out to me, so it is online, but Geoff, the term "historical" hasn't appeared here. The sat status being set and defined as current is well established in the APNIC procedures and it means resources which are not historical, so that actually is unambiguous if look into what this means. The reason why I raise this particular point is that at the moment, there is a discussion that is under way between the APNIC EC and the EC of other - the Boards of other RIRs about the management of historical address space, in particular the authority for historical address space, and it has become quite important in the course of that discussion to clarify the difference between administrative responsibility for administering historical address space and the policy authority for determining what happens to a historical address space under APNIC or RIR policies.

And the general principle which I think we have followed quite consistently in this region is not to apply APNIC policies to the historical address space, but rather to provide services in connection with historical address space. That is to provide both DNS and registration services but not to historical policies and that's what I said earlier about APNIC not having the authority to control and dictate the utilization of the historical resources and for instance, to reclaim it, reclaim the resources.

So, it is actually becoming an important consideration and I would say to my experience to date, a lot more emphasis is being placed on historical resources and where and how they're being used around the world as we run out of the current IANA pools and I think it is quite important to be quite specific and deliberate about what resources we are talking about in the policy discussion like this one.

DAVID WOODGATE:

Paul, can I ask you a quick question. I think that the last proposal, the acceptance of the last proposal set the precedent on the historical records now.

PAUL WILSON:

It was the point I was trying to make is that we were not asserting policy over those, over the historical resources. We were saying that we're trying to see the current resources and to demonstrate a need for them which also involves a need for demonstrating that you have a network for instance and we're not asserting authority over your network just by asking you to describe your network.

RAUL ECHEBERRIA:

OK, Paul has explained the position and what's happened with the RIRs that moment, but I would like to say that no policy has been submitted in the LACNIC region about transfers. So as an organization has no position about that and we are open to implement what the community could approve in this sense. We have a conscious position about what the APNIC community should do. In this regard, we have the same thing I have stated in our RIRs and LACNIC and the concerns about legacy space in the policy. With the transfer of the legacy space requirement, APNIC the legacy space is not under the authority of a single RIR and so it deserves a special treatment. There are some conversations going on on this issue, but if the policy would be adopted, as it is now, it could be affecting the interests of other communities and so, we recommend to limit, well, we don't recommend anything, we only express our concerns and say what we think about this point.

IZUMI OKUTANI:

I'm not sure how far we should dig into this particular topic on historical address space, but I have one clarification question. My understanding according to Geoff's explanation on the mailing list is that even though resource is considered to be part of ERX resource, if a contract has been signed between the organization and APNIC, then it will be the target of the transfer proposal. Is my understanding correct?

GEOFF HUSTON:

I had no intention of locking out any address space held by a current APNIC account holder from consideration under this policy. So that was my intent as the author.

RANDY BUSH:

Some clarification, Geoff, which is in fact that part of your hope in this proposal was specifically to flush out under-utilized space that very well might be biased towards historic data.

GEOFF HUSTON:

I can not talk about what bias might be, but my intent was to allow any APNIC current account holder to be able to transfer all or part of their holdings. That was my intent as the policy author. I have heard concerns expressed this afternoon from Raul. Obviously, I've also heard concerns from Paul on this, but I still say as the author of the policy, that was my intent and that is the wording as I understand it in the policy. If you ask me to clarify the wording, it would be that the intent was "all address held by a current account holder, a member of APNIC".

IZUMI OKUTANI:

OK, thank you.

GEOFF HUSTON:

Is that clear?

IZUMI OKUTANI:

Yes, it is clear to me.

ANDY LINTON:

I'd like to say, I support this policy because it actually reflects in actuality what is happening. There are people out there who are transferring space and the records aren't kept up-to-date so you've got no idea who is using the space. And I'm personally aware of a number of these things happening where people are using the address space of other people and it is not documented, so I think it is a pragmatic policy and I think you should accept it.

DAVID WOODGATE:

To my mind, there are only two things that are going to happen once IPv4 runs out. You can either rely that under the current system, people might sent the address space to APNIC to continue with the allocations along the current way. That seems extremely unlikely, or you can approve this proposal which would allow members to transfer in a way that they see best fit between themselves.

I don't think any of us hold that much hope for resources being voluntarily returned by members in the first instance. There are some good Samaritans out there that take that approach. I think that there is some degree of address transfer which is realistic. I think whether that's associated with training or not, whether or not, I'm not clear to comment on that. There may be agreements between particular parties for a variety of reasons. I think it is very sensible and Andy said very pragmatic and I very much support the proposal. One comment on the historical space, I make the observation that if APNIC has no jurisdiction over the use of historical records, then obviously that means that the historical transfers maybe are happening already. The only thing that wouldn't be happening is registration with APNIC and that's what we particularly would like to see happening.

JAMES SPENCELEY:

Just wondering, if we're not opening Pandora's Box too early. Is there any reason that you see the need to propose this policy, two and a half or three years out from v4 exhaustion. Is it not potentially a better idea to do this closer to the date that we see stronger demand for transfers and closer towards the end of v4?

GEOFF HUSTON:

In response, I would like to say thank you, James, for your amazing faith in my abilities to protect the exhaustion of v4. It's a faith that I don't share. I think that the predictions that I've done are remarkably inaccurate and are out by as much as 20 months.

That doesn't mean that it will likely exhaust in 2013 rather than 2011. It means quite the opposite. So, if you honestly believe that you would like to wait until after this problem starts and then somehow create policy, then obviously that's your view. I am proposing this and have done so for the last three APNIC meetings because I happen to have a different view on this and actually think that we should create the necessary policy framework to be able to be in a position to do what is necessary to keep the integrity of the registry intact well before you get into the last microsecond of the problem here. So, the reason why I do this is that this timing is - I don't think this is well in advance, I don't personally believe that you have two and a half to three years in the industry, and I think that probably, you have a lot, lot less. But, it's your policies that you're ultimately going to achieve consensus on or not, but that's why it's here now.

IZUMI OKUTANI:

Izumi Okutani from JPNIC. I agree with James' point in the way that it is important that we discuss it now and seek what we want to do about it, but I think implementing it at this stage would be too early because I understand the intention of the policy is strictly just limiting APNIC's ability to allow database transfers, nothing more and APNIC is not involved in any other roles on how the transfer is made, the restrictions on how, you know prices or market, etc, etc. Understanding that, we understand that. But we feel that impact on those areas and studying and reviewing, it is important before implementing this policy, because obviously it would impact LIRs in terms of the way they manage the address space. Not just in terms of the address management and operation, but in terms of taxation, because address space could be considered as a property and another point would be - well, a number of concerns have been expressed that yes, being able to receive address space, but it would fundamentally change the way we have been imagining address space, and after considerations, maybe this is the way we should go, but not enough discussions are made on you know the impact on this, which is unlike how we have been managing address space in the past.

Those people who may not necessarily need address space will be able to obtain it from purchasing and those who really, really need it will no longer be able to obtain it if they don't have money, so these implications must be looked into and studied carefully before implementing this policy.

GEOFF HUSTON:

In response, I would actually I suppose give the same response I would give to James. Perhaps the worst possible scenario. Let me give you a little bit of reasoning why I believe that that prediction is so astonishingly inaccurate. It actually relies on the laws of very large numbers and it says that as long as your sample space is big enough and you understand why today happened, you can predict tomorrow easily. Though each individual action is entirely unpredictable. So you look at this and you go, over the last 18 months, the RIR system across the entire globe did, if you believe the daily files, around 11,200 allocations and you think that's a large number. But if you look at the closer, one half of the address space in v4 out of those allocated in the transactions was performed a little over 200. So of the remaining space, the similar distribution was going to happen and now you're looking at the actions of a mere 200 people. They could happen tomorrow. It's not unusual. Panic when the resource is invisible and short supply is normal human reaction. So, you know, if one really does have 120 days or less, on which particular day of the week do you want to do the study and how long do you want to spend to do it? In some ways, I appreciate that it would be really good if exhaustion took another ten years and you could study it in full details, however, it's an event that we have no particular control over in terms of its timing and that creates this issue.

In some ways, this policy is being put here, not in terms to understand what happens in markets and transfers and trading, because quite frankly, address scarcity and the cessation of the current address distribution framework is its own problem. Scarcity naturally breeds price. That naturally has property implications irrespective of what this community decides. We can't even alter it much. We have a registry that we think is relatively accurate. Unless you allow it to understand what's going to happen in terms of the redistribution of addresses following the cessation of the current distribution framework. This policy proposal is very much registry-centric. We are after all, running a registry in this community of APNIC. It doesn't try to save the Internet. More parties than us need to help to do that. But, it does try to say, this particular piece of function, given the appropriate changes in policy can continue to play its role, rather than also being subdued in a massive tidal change of the way in which addresses are transacted. So it would be nice to understand at all, I don't believe we really have the time to delay this because of that.

IZUMI OKUTANI:

Let me clarify, sorry for people in the queue. Let me clarify, I'm not suggesting to stop considering this proposal and it is good that we discuss it and try to implement this proposal. All I'm saying is that we should study other aspects of the proposal because it would have a large impact. You say that you know, these things, it shouldn't really involve APNIC and you know, it's not the role of APNIC to consider these issues, but if you think about the impact to the whole industry or the community, I think we should review it and if there's anything that APNIC can do to prevent any negative impact or minimise confusion, then I think it is something that we should consider rather than just restricting APNIC's role into the database update, and as a result of consideration in studies, we might reach the same conclusion at the end of the day, but I think we should review it more into details first. That's my point.

GEOFF HUSTON:

This policy proposal was first brought forward to the community I'm trying to remember if it was 12 or 18 months ago, so certainly, your community, my community, our community, the communities have an enormous amount of time to consider this already. It's not the - you know, who does this review? How do you reach your own views about policy proposals?

IZUMI OKUTANI:

So, I'd like to... well, I understand your point that we've been discussing it and no substantial progress. So rather than just discussing it in the meeting and in between and with the community as a whole, maybe we should set up a working group with experts on the economy or go more into details on a special task force and look at it more intensely. Then maybe we could have more progress than we have at the moment?

JASON SCHILLER:

Jason Schiller from Verizon Business. I wanted to follow up with beating this to. Following up on James and Izumi's comment on, is this too soon and Geoff's response of, "We don't really know when depletion will occur". One of the things discussed in the ARIN region was possibly having policy that the community would agree to and adopt but not implement immediately, and instead implement some sort of triggering event such as the IANA pool is depleted or there's less than three /8s in the IANA pool, and I wonder what this community thinks of an approach where the policy would be adopted but not implemented until there's some triggering event.

DAVID PEMBERTON:

I was going to say...

JAMES SPENCELEY:

One of the things that mulled over in my head was that, Geoff, you worry about the database. I think there's a potential for, not to rush into this but to open up a - 'no questions asked' policy. Once this policy is open so that people can correct information in the database. I think that's a potential option, you know that might solve your issues with the database corruption or misinformation in the database. Having said that, I really do like Jason's proposal.

RANDY BUSH:

Randy Bush IIJ. First, I'm going to speak for the proposal. I believe there's a number of reasons that we need this. The database is important, it's not the only thing we're doing, but having it as accurate as possible is important, there is black market trading, let's face it. How soon we will exhaust etc. Geoff has put a lot of work into that and come up with a lot of numbers, none of which I believe and none of them which he believes. It's a best effort, you're shooting in the dark.

To Izumi's point of economic studies, I have already been forced to go to a number of meetings where economists and IP addressing people and lawyers etc. - well, the rest of the sentence would be very negative I assure you! Let's not add more. You can go to the existing ones, this has already been heavily discussed from that point. By the way, if you're looking for a recommendation, one of the saner places it's been discussed is the OECD.

The purpose here is underneath, there is a belief that having an open market will put the under-utilized address space to what the economists seem to call best use. I come from a capitalist society and I believe this is heavily embedded in capitalist theorem. I.e., those who pay for it the most get it the most. I was raised by socialists so half of my mind raises alarms at this point, but that's neither here nor there. The idea of having a marketplace which is open and honest and where the registry accurately reflects what is happening is, I believe something we're going to be doing. Whether we do it now or later because it is what is happening in reality and underneath. I think what Geoff is proposing is how to move forward on it in a fairly simple way. If you look at what is discussed in the other regions, despite Geoff's reputation for complex talk, his proposal is by far the simplest and the most understandable. So, whether we pass it now or pass it the next time, it is time to take it seriously, so I advocate supporting it or supporting it next time if not this time. But I think Geoff is trying to do - trying to face the inevitable for the IPv4 depletion, it's not going to be pretty.

YI CHU:

It's looks like the space is the only hang up here. So would it be better to separate your proposal into two, one covering APNIC space and the other into legacy space? That way, you know people with problems with legacy, they can vote for the second.

DAVID WOODGATE:

I don't think, as Randy says, I don't think that anybody is thinking that this IPv4 runout is going to be pretty. I think it is - I don't think anybody necessarily believes that opening up this proposal is not going to reveal all sorts of interesting side issues along the way. But, we have been considering it for a year. I very much think it is time to get down and actually put it to a consensus, to asking for consensus on it and getting ahead with it because as I said before, there's not many other options. Thank you.

IZUMI OKUTANI:

Izumi Okutani from JPNIC. I actually share concerns on how the discussions of this proposal is progressing, it is really slow and it is always continue discussions, continue discussions but no further progress on the issues. So as I mentioned earlier, I would like to suggest setting up a working group or task force with experts and have more intense considerations so that we could have more progress about this proposal and address any concerns that have been raised.

GEOFF HUSTON:

OK, my concern here is that the reason that this has taken so long is that it really is confronting something that is incredibly difficult. Because, right up until now, we've been dealing with a good that you treated as abundant. Treated as abundant. You kept the economic price close to zero. The largest companies in the world pay a few thousand bucks for the space a year. Compared to the economic value, that's a joke. So you've actually created a system that is incredibly artificial. And while the resource was incredibly abundant, it wasn't a problem. It is now a massive problem. We're now giving out more address space through the system than we've ever done before in the past. The upheaval that you're about to be presented with as an industry is certainly unprecedented in this industry. It's hard.

So OK, you have the option almost right now. Do you want to make a hard decision now or do you want to make a hard decision when it is too late? That's really what you're confronted with. Because quite frankly, it is going to be easier to study this to exhaustion and there's an industry of folk getting paid by the hour to do that, and we can and we will. No matter what, it's a fascinating issue of breakdown.

So, to my mind, I really don't see any particular value in making a hard decision too late. I would rather we actually understood whether we're ready or not to confront the issue that this distribution system that we've used for v4 is now basically running it to an end. And we need to understand - do you value a registry that actually tells you who has what addresses, or do you believe that you want a taste of what address chaos really means to a pseudo non-functioning, non-Internet. Because if you believe this too late, no-one is going to wait for this system to correct the consequent issues.

So, I understand what you're saying, but as the proposer of this policy, I believe I'm now not in a position in all consciousness with respect to the registry and its integrity and my view of what is required to help and assist and mitigate to some small extent the phenomenal problems we're about to face.

I'm not prepared to risk the integrity of the registry function. I believe that we should indeed put this there now and understand where you stand on this. Because, to me, like I said, you could keep on saying, I want another hour to study it, I want another minute to study it until it is too late. So, I understand what you're asking for, but after a good 18 months, quite frankly, the ideas and concepts that have come out have come out. It's a hard problem and we do not understand what's going to happen.

We however do understand our addiction to v4 will not get turned off when the last address is allocated from the current address allocation system. There are folk out there who still need addresses, and that need will get met. Whether the registry function helps and assists in recording the disposition of addresses or whether the registry function deliberately turns a blind thereby creates the elements of address chaos is really the decision you're looking at and it is not an easy decision because of the other implications but I value it. And that's why I indeed am saying that I am happy to do the consensus call this afternoon.

IZUMI OKUTANI:

I understand your point and it is probably going to be parallel so it's going to be my last comment on my position. I'm not saying that we should delay or shouldn't face the problem, we should look at it. But by just doing it right now, and not looking at implications, it might help create more negative effect by not considering it fully. That's the concern that we have. And as a result of looking at it and into it, and feeling that the proposal itself is fine, then you know, we can certainly go for it.

GEOFF HUSTON:

So let me understand this. Last September, you asked for more time and you were going to study this at the end of 2007 and understand that in all its implications because it is hard. To some extent, I kind of feel I don't understand what's going on here. Nothing seems to be pragmatically there because this is what I said a year ago. You must forgive me, I am confused.

IZUMI OKUTANI:

That's why I'm proposing setting up a working group or task force to look at it in more detail. We discussed some of the issues in a little bit more detail such as the ones I've listed on the mailing list, so, well, I think I've spoken enough, but I think these issues I've listed should be looked into in more details before implementing this policy. That's my basic position.

PHILIP SMITH:

Philip Smith Cisco. As in previous situations at this presentation, I would like to indicate my general support for the proposal. We have to recognize the transfers are happening already and I agree with what you say, Geoff, that the registry has to be up-to-date with who has what, otherwise we have absolutely no idea what's in the routing system, if there's enough evidence today of, what we say, stuff in the routing system that probably shouldn't be there unless people find it hard to do. So I would actually agree with the calls for calling for a consensus at this meeting here now, because we've been discussing and discussing and folks want to set up working groups which were started about 18 months ago, 12 months ago, 6 months ago actually say I agree with your position. So let's get something done and done now if it means fine tuning, while the blokes who want to do fine tuning.

RANDY BUSH:

Excuse me, can we just check whether our brothers and sisters in Manila have any comment.

GEORGE MICHAELSON:

People in Manila are off line for their lunch break! They're not moving and Vietnam Hanoi suffered a network outage and are also down.

RANDY BUSH:

Well, no, they actually had another meeting I'm told.

GEORGE MICHAELSON:

I'm sorry, I misunderstood.

RANDY BUSH:

Oh, they all went for a lunch break.

GEORGE MICHAELSON:

Randy, could I also read a comment from the Jabber record. Tom Vest asked if I read this - "Please consider that the address transfer policy will be irreversible in a way that nothing has been since the RIR system has been established. It will effectively separate resources from the policy process and jurisdiction or at best, make their status as ambiguous as policy resources. Given this irreversibility, the impact of alternatives of this policy merit further careful consideration". Tom has noted separately that there is an idiosyncrasy challenge.

DAVID WOODGATE:

We have had a proposal where the membership wanted to pass the principle of the proposal without necessarily being happy about all the details. Given the length of time we've had on this proposal, I think that there will definitely be some modifications along the way going forward, but I think we should definitely put it to a consensus this afternoon and at least see where people stand on the principle now.

RANDY BUSH:

I will admit that we are now one minute over the official schedule. I don't care, I think it is an important proposal and a complex one, so I'm not going to cut people off at the line. Sam or Secretariat, if I'm causing serious trouble by this, please tell me. Sam signals - no problem! Sir.

DAN ALEXANDER:

Comcast and ARIN AC. I'm curious because I heard the phrase a number of times in this conversation, I would just like to get your definition or what your impression is of "too late". What do you think of as too late?

GEOFF HUSTON:

There are a number of basic issues flying around that we actually played out and experimented with back in 1998. When folk thought that the registration policies of the route DNS didn't accommodate what they thought was appropriate to do. And rather than creating one alternative, they started to create many, many, many alternates because the opposite of one is infinity. The resulting chaos in the DNS system was unsupporting. The DNS was headed for a fatal disease. You saw the solution, you saw why it was absolutely necessary to go there if you wanted a coherent name system. The issues that we face here is that given that without a registry, they're just numbers. Then the temptation for other parties to support various other forms of transfer using their own Internet transfer registries looks a lot like Internet routing registries in some ways, they're popping up everywhere.

But you're looking for a single definition and what you'll find it 30 answers that are all different. Where do you find the packer? What this? Too late happens as soon as the third or the fourth registry happens. In fact, I would say that the too late happens when you have two because three happens there after that have the same address information but different parties being registered. So, "too late" is very early on in this because once you've gone there, it is extremely difficult to understand why and how this particular framework which from some sense is a monopoly, is necessary and why uniqueness is the one thing we really, really, really have to have in addressing or else we might as well all go home. So I would say that too late is when you have two with different information. After that, it's all over.

RANDY BUSH:

They're going to make me throw this darn switch every time. Dan, let me give you another take on it. For some reason, what is commonly known as the YouTube incident has managed to get the attention of people who influence routing and routing security like nothing else has. And I'm not interested in why, but you may know that a number of us have been working on the resource certification for X.509 certificates are issues for address space. But let me put it this way - those will be attempted to be used to validate routing. Fairly simple. Much sooner than we expected because the silly YouTube incident and I think that that is actually good and we're about to increase the badness of the data. The transfers are happening and they're going to increase and unless we find a way to record them properly and legitimise them, routing suffers.

DAN ALEXANDER:

I don't disagree with you one bit, but I guess the one point I'm making is that, those things are going on even currently when addresses are still relatively available. And I'm not at all trying to dismiss the urgency behind this situation, because this question has to be answered, and it has to be answered quick and fast. I'm also not an advocate that we need to study it forever. I'm curious that it has been raised several times and I've heard it in other registries as to when the trigger for this should actually be pulled, and it was suggested on the floor here today that the IANA depletion is a potential trigger point because when this happens, it does have implications both good and bad. So, the fact that this stuff, these issues are going on today doesn't mean that implementing this today is necessarily going to fix those problems either.

ERIK KLINE:

Erik Kline, an innocent bystander. Collateral damage, yes! I'm not exactly familiar with anything and perhaps I'm a bit of an anarchist because I'm curious to see what happens if it is approved and see what happens with the experiment, but I'm curious to know are there any stop gap measures to pull the plug if something goes unpredictably awry. Is it reversible or unstoppable?

GEOFF HUSTON:

I'm not sure that a simple title office whose job is to maintain integrity of association, parties with resources has the power to restrict the actions of parties. The land title office doesn't really have that power and I'm not sure that we do in this industry, so for saying, "What do you do when what?"

The whole idea of the proposal is that the registry remains accurate. So what are you saying that the registry itself has to change to fix?

ERIK KLINE:

I guess I'm wondering...

RANDY BUSH:

I think I can answer the question. If it's a mistake, can we take it back? Simple answer, we have an entire process in all the RIRs who love to create, destroy, change etc. policy. It's become a minor industry and it takes people around the world for many fine lunches and dinners so I assure you that we continually modify this policy on a quarterly basis, yes.

ERIK KLINE:

So it is worth trying an experiment in some circumstances then?

DAVID ROBB:

From Telstra clear. I'm in favour of this proposal because I believe that we are inevitably going to end up in a market environment. However, just a couple of small points that may be curious. In this proposal, you are saying that you would allow the transfer of /24s between entities. Yet, APNIC has a current minimum allocation size of a /22, which I believe is there in order to try to reduce the explosion of the routing table, as well as generally keeping things tidy and less fragmented. Would it not seem sensible to lengthen the minimum transfer size to whatever the minimum APNIC allocation was at the time. While the move may certainly be smaller chunks traded around, the question is how small do we go in allowing transfers to the registered? Do we want to allow /22s? Probably not?

GEOFF HUSTON:

OK wait, is that a question? Do you want to stop and pause for a breath and let me answer.

The answer to that is that irrespective of the allocation policies, this RIR and other RIR communities adopt, irrespective of that, the routing table has its own dynamic and /24s absolutely proliferate. Now, it is one thing to enact a policy knowing that it is going to be wrong, and to my mind, that just seems like perpetuation of a myth and a very not useful one at that. Recognize the reality that out there right now, 24 is a universal minimum of what carries in the routing system and everyone who gets an allocation, even yesterday, slices into a /24. And I can show you the evidence or you can go and look for yourself, it is just there. So /24s is what's in the routing system and the policy because it is trying to match reality to the policy for once.

DAVID ROBB:

You speak of reality but I find it interesting that APNIC has a policy of 22 when obviously there is a desire by parties to use /24.

GEOFF HUSTON:

I am a proposer. If you make that judgment, look around the room.

DAVID ROBB:

Consider this to be a general observation. I will be in favour of the proposal anyhow. I merely wish the points to be brought up so that people may consider them.

The second point that I would like to raise is that I believe there's a clause in your proposal suggesting that when somebody donates address space to another party, that they are restricted from seeking further space from APNIC for a period of two years from that time. Is that correct?

GEOFF HUSTON:

It is not donate, but transfer. When two parties agree - if you will, the party that's disposing the address space is restricted from going back under the existing allocations and procedures of APNIC to go for more IPv4 space. In other words, you can't dispose of it and then go and ask for its replacement. The 24 months was quite deliberate then. The 24 months said, by the time 24 months expires, you can go and ask all you want.

DAVID ROBB:

And I believe that is an excellent idea. I believe it should be considered to actually extend this clause so that not just, is the party who is disposing of the address space restricted from receiving any more from APNIC, I believe they should also be restricted from receiving any more from any other party.

GEOFF HUSTON:

What do you mean by that. No, "any other party". Any other RIR?

DAVID ROBB:

Moving there.

GEOFF HUSTON:

So you're saying any recipient.

DAVID ROBB:

Any disposer of address space as you suggested is restricted from receiving more and selling it off and making a nice profit along the way, that this could be extended to at least with - you know discouraged from a registry point of view because obviously as you say it can happen anyway, from going and buying up more address space from other parties and selling it on.

GEOFF HUSTON:

Let me respond to this by getting right back down to fundamentals. To what extent does a title office become a market regulator and to what extent are market regulators there as distinct from a market regulator. You're saying that market facilitators should not occur and that the title office function should preclude that? Now... in normal market practice, you don't do that, you actually independently regulate the market and there is no doubt that any market that might emerge in addresses would be regulated inside normal regulated frameworks we have today. Obviously, to what extent do behaviours get modified by that is another route problem with a rich history in this space. Whether you believe it is appropriate for a title office to carry that burden, I as a proposer would say, it is not there because I disagree that that function should also be formed by the title office. I think you're over-burdening the neutrality of title with an additional function of market regulation. I don't disagree that that function of regulation has value, but equally, I would say that market facilitators and brokers exist in every other market and probably would exist in this one as well. And generally, they are beneficial to the operation of the market rather than detrimental.

So, to that extent, as I said, it is not in this proposal as it stands for a philosophical reason that title offices should be neutral and I think I would stand by that as saying, regulation happens through other mechanisms.

DAVID ROBB:

Seeing as I've taken up more than enough time, but we have already pointed out several times that proposals and policies can be adjusted even on a quarterly basis as people wish to do so, and I believe that in the start up of the market, some form of regulation is appropriate to have in place and if the title office is not the right person to do it or the right entity, then who else is going to?

GEOFF HUSTON:

If that's a question, the normally answer is that every single national regime seems to be stuffed to the gunnels?

BILL MANNING:

A couple of number observations. The IGF has been very clear in pointing out that we have approximately a billion people on the net these days. If you take off your glasses and squint, you would say, we've effectively used all the IPv4 space which is about four billion addresses, so it takes approximately - squinting - four addresses to bring a person online. The 2007 world census said that there is approximately 6.5 billion people on the planet, which means that even if we got it down to a ratio of one address per person, there wouldn't be enough IPv4 space.

So, I am looking at this proposal in some sense as a - as Randy pointed out earlier, rearranging the deck chairs on the 'Titanic' and not ordering dessert. This isn't going to do fundamentally what we want to do.

The other has to do with - I'm not sure if you're using this as an analogy or making this and I an assertion of the RIR but using the addresses as things that have title of things that have property and the registries become title offices, simply recording who the registered party is for that particular piece of property. Do you actually - is that an analogy or what you want to assert.

GEOFF HUSTON:

It is an analogy.

BILL MANNING:

If we talk about markets and transferring these assets or resources and we act as a title office, when the regulatory people are going to jump and they're going to say, oh, we need to regulate this and isn't this really property and who says the taxes?

GEOFF HUSTON:

Bill, as I said in the e-mail, I will take the time of responding from the mailing list.

BILL MANNING:

I'll go and read the mailing list. We have other people.

GEOFF HUSTON:

Go and read it, the response answers that.

JAMES SPENCELEY:

I have a question, why are people transferring address space today? Why are they selling it on the black market? This interests me. The black market transfers are happening and why?

GEOFF HUSTON:

Having never bought or sold an address on the black market, James, I don't think I'm the appropriate person to answer that.

JAMES SPENCELEY:

The theory is that because it is not subject to any form of justification, you can hold on to that space and not justify it to APNIC. So I put it that your policy, which I support, doesn't solve the fundamental problem, is that the value created on the black market is that it doesn't need to be justified. I can go and get address space from APNIC and pay $10 to $15 or buy it on the black market because APNIC doesn't have the address space and that's a lack of justification.

GEOFF HUSTON:

As you're hopefully aware, the true intent of this policy extends well beyond the extremely limited time for which APNIC and any of the other registries have time to point out through that mechanism. So if your observation is that that holds for the next few weeks or months, then that may be true. But thereafter, it is not true, you're not pricing an alternative because there is no existing allocation mechanism that you're pricing against, is there?

JAMES SPENCELEY:

I suspect that there will be black market transfers even with this policy because people want address space that doesn't require justification.

GEOFF HUSTON:

I'm sorry, in the structure of this policy, there is no justification for allocation. It is a transfer policy.

JAMES SPENCELEY:

My understanding is that the recipient must obviously utilize that space.

GEOFF HUSTON:

No. No, I'm sorry. Perhaps you might like to read the text of the policy, James.

JAMES SPENCELEY:

But if they remember...

GEOFF HUSTON:

Perhaps you might like to read the text of the policy, thank you.

JONNY MARTIN:

From New Zealand. This is mainly in respond to David Robb's earlier suggestion that if people are selling or disposing of addresses in this way, they shouldn't be allowed to obtain more from any party. I think the problem with putting any sort of restrictions on the transfers are, there's a restriction, you just invite the black market to flourish again. So we need to make sure that we stay away from any sort of restriction or any sort of regulation in this part of the market because if we do, we're back to square one, but we also have the disadvantage of, you know trying to legitimize it. I'm a proponent of this and I think as the proposal is written, it is about the best we could hope for.

GEOFF HUSTON:

Let me I suppose make it abundantly clear. This is a policy deliberately restricted to the transfer of registration details.

JONNY MARTIN:

A very good feature.

GEOFF HUSTON:

Most of us live in territorial regimes that actually have various regulatory structures and that by and large, everything you do in this industry is subject to various rules, regulations, and legislation in the countries in which we operate. Nothing you can do and I can do stops that.

So, when parties reach agreements to transfer addresses, they will be subject to all of the constraints, conditions, and compliance that exists within this industry and every other industry yesterday, today, and tomorrow.

What I'm saying is that we should not invent more. By inventing more, we have an authority problem. We actually have a role problem. We have a competence problem. We are a community that seems very adept in creating policies for allocation. This is great, but it is not about to be a skill that in v4 has much in the future. We are also a community that understands registration and the registry function. This is good, that function endures. But by and large as a community here, we're not exactly into the cut and thrust of the operations of markets.

And to impose upon ourselves that load, the risks of doing it badly, without authority and incredibly poorly and thereby making the Internet suffer are bloody high. So yes, other folk do regulation well. It is their job. I believe that we do registries and registration functions amazingly Well for the Internet. That's our job.

JONNY MARTIN:

Thank you. I agree.

GEOFF HUSTON:

It's in your hands, Mr Bush. I know I'm in trouble but here we go.

RANDY BUSH:

Any final comments. Sam, are you rushing to the microphone? Okie doke.

So, it is the proposal as Geoff has stated, there was confusion over some wording and he has attempted to clarify that. Is anybody at all confused over what Geoff is proposing? You're more than welcome to disagree with it. Could we put it on the screen? I don't know.

GEOFF HUSTON:

I don't know, it is actually a number of slides. Do you want me to go boom, boom, boom for you.

RANDY BUSH:

Let's review it for a giggle.

GEOFF HUSTON:

What the hey! The first thing is that APNIC recognizes the transfer between current account holders. This does not apply if you are a member of another RIR and not a member of APNIC. This does not apply if you are a member of an NIR per se. It applies if APNIC sees you in its membership books as a current account holder. It will record the transfers according to three constraints - constraints apply to the address block itself.

What is being recorded is a transfer of the /24 or bigger, what I mean bigger is /23 or /22. It is recorded if that block is administered by APNIC and the status is current. By that, I mean clarified, irrespective of the providence and part of the account system of a current holder of membership, it is there. And it is subject to all current APNIC policies.

The disposer is an APNIC account holder. Is the party that we understand is the current registered holder of that right of use. Is going to be eligible for any further APNIC address allocations in IPv4 for a period of 24 months. And if they come back after 24 months to APNIC to receive the space in a normal allocation, they must document the reasons why they're coming back.

The recipient of the address space is already known to APNIC and is a current holder is subject the address space to all APNIC policies and is liable for any fees associated with the current holdings before and after the transfer is effective. And the details. Notification by both parties published in the log. Nothing is secret here, it is open. And APNIC may levy a fee, that's the business of the APNIC EC. I believe that's the full intent, so it is simple.

Does that help you Mr Linton. Mr Linton and everyone else then.

RANDY BUSH:

Moving right along. No further questions? Everybody pretends they understand Geoff's intent! We just don't want it explained any more.

Who support this proposal, would they please raise their hands.

We'll re-count if there's - if we feel we need to.

Would those who oppose this proposal please raise their hands.

OK, could somebody count because I think I would probably call consensus because it looks like 3-1, but I'd like to know that it feels like 3-1. You folk back there, get those hands up if you mean them. People have to count.

GEOFF HUSTON:

Hands right up everyone please.

RANDY BUSH:

Right up doesn't translate - could you raise your hands high. It's hard to see.

OK, could those in favour please raise their hands high. Could you tem us the count please.

SAM DICKINSON:

Second count was 38 but I can't remember the first one, do you remember.

GEOFF HUSTON:

I thought I heard you mumble it was that those opposed were 19 hands raised in favour and those in favour were 38 hands raised in favour.

GEORGE MICHAELSON:

Asked that someone on Jabber added one, Tom Vest to which particular?

SAM DICKINSON:

20 and 37.

GEOFF HUSTON:

20 and 37. Thank you very much. 37 in favour and 20 opposed.

RANDY BUSH:

So, I am responsible under the rules and regulations to actually judge the consensus. I do not believe that consensus was reached. Oops, sorry?

JAMES SPENCELEY:

I have a question, would you be opposed to including Jason's comments that this be put for a consensus, but for a future date to be implemented?

RANDY BUSH:

I think the easiest way for us to deal with that is, I believe we have a larger body ratio for than we did last time. My guess is that by next we will have consensus, especially if Geoff refines things and therefore you have the delay and hopefully Izumi will have finished her studies by then!

DAVID PEMBERTON:

Is there any interest in a non-binding show of hands, given that we've already done the strongly agree and strongly disagree from earlier on.

RANDY BUSH:

Show of hands for what? Please clarify.

DAVID PEMBERTON:

For accepting the proposal, but for some future date.

RANDY BUSH:

Let me ask the question this way. How many people who voted against would change their votes to yes if the proposal were timed for some future date? Thank you.

I believe this will go forward on the list, we will carry it forward and continue discussing. Geoff, I'll, I personally volunteer to help you work this for next time if it is of any use to you. And any last and unfinished business?

I believe we still have a 6:30 vendor reception at the Crowne Plaza which we have plenty of time to comfortably get over there. I want to thank everybody for your for their participation. This is democracy and sausage being made in action. See you in Manila.

APPLAUSE

(End of session)

RANDY BUSH:

I have to remind you about the social tomorrow night and the transport is located at an unspecified time and the cost will be $70 in local currency.