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.