Transcript: Policy SIG

Disclaimer

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

Policy SIG.
14:00 to 15:30.
Wednesday, 23 February 2011.
Hall B&C.

[Jump to session 2 | Jump to session 3 | Jump to session 4]

Srinivas Chendi: Welcome back to the APNIC sessions. This is the Policy SIG number 1. As I said in the earlier session, we have five Policy SIGs and this Policy SIG is sponsored by CNNIC. We would like to thank CNNIC this time for sponsoring the Policy SIG, all five sessions, two today and three tomorrow.

Can I ask you all please to give them a round of applause, in support.

APPLAUSE

Thank you, while we are trying to get into the Jabber system, I got some announcements to make regarding the social event tonight.

I was told that every delegate received either a green or a red tag, along with your registrations.

Do you have them? Either green or red. It should be in your name tag or it was given to you when you went to register.

OK. We're using this system, because the place we are going is very limited in capacity and we have a lot of attendees here and we do really apologize for not accommodating everyone in the social event tonight, but whoever got the sticker, these tags, we have two groups going to the social event. The first one will be red tag, the bus leaves at 5.30 pm, to Happy Valley. It's a race club. If you carry your money, you can bet on the horses.

It's exclusively booked for us.

But the first group, whoever got the red tag, will go on the first group. The bus leaves at 5.30 pm, sharp, from the Harbour Road, same place where you took the bus to the last evening's -- Monday night's opening ceremony.

Then the second group, with the green tag, the bus will leave at 7.30 pm. That's the first bus, which leaves at 7.30 pm. It's very important that you follow your tags, whichever tag you have, you go and take that bus, because we're going to take the first group to the social event and then we'll send the first group back to the venue and then we take the second group.

So everyone can enjoy the social event, everyone can bet on the horses. We do really apologize. We didn't expect that this many attendees will actually would like to go for the social event and the ve true is very limited in capacity. They can't expand it for us.

OK, we are also doing some lucky door prizes at the social event, so I recommend to bring your business cards, so we can do some lucky door prizes.

Social event is sponsored by Hurricane Electric.

I'll talk more about Hurricane Electric later, when we get a the social event.

OK, Gaurab Raj Upadhaya is the chair of the Policy SIG and Terence Zhang is the Co-Chair and Ching-Heng Ku is also Co-Chair. His term expired by this meeting, so we're going to have co-chair elections, once whoever is get elected, they are now requested person to come and take the seat, up on the stage here.

So I hand over to you, Gaurab.

Gaurab Raj Upadhaya: Thank you, Sunny. Welcome back to the Policy SIG at APNIC. We are at APNIC 31. Thanks to the hosts. It has been a wonderful meeting so far and hopefully we'll have a good meeting.

We have a long agenda. We have almost a day and a half, six 90 minutes sessions, it's probably the longest we have had for policy discussions at APNIC in a while.

So I'm going to start with a very short description of how the policy development process at APNIC works and then we'll have the co-chair elections and then we'll continue with the policies after that.

The Policy SIG charter basically says we develop policies and procedures which relate to the management and use of Internet address resources by APNIC and in the APNIC region. We have two mailing lists, one is public mailing lists, where all the discussions with regards to policies happen and the SIG chairs and policy manager at APNIC, we also participate for internal discussion on SIG policy chair mailing list.

The PDP is it has to be open, transparent and it follows the bottom up policy process. Anyone can propose a policy. You don't have to be an APNIC Member. Anyone from any part of the world can propose and you'll see we have proposers from almost everywhere around the world. All the discussions and deliberations are documented. All the policy discussions are archived and we also have transcripts and video recordings of these sessions.

So you'll notice that even today and tomorrow during the policy discussions, we'll have a live transcript of discussions on the screen, on the right side of the room.

So basically, when it comes to how new policies are formulated in the APNIC region, there's a four-week period before the APNIC Meeting, anyone can submit a proposal, or if they have an amendment to the previous proposal, it is submitted to the SIG chairs or to the Secretariat and then we, one of us, the SIG chairs, mail it to the Policy SIG mailing list and then it is community discussion on the mailing list and then it is presented at this meeting.

Presently at this meeting, his is where we are. We have gone through a bunch of policies, we have almost 16 policies being discussed in the last month or so. If there is consensus on policy, then it passes and then it is forwarded to the Secretariat and the EC for implementation.

If it can't reach consensus, then, you know, based on the discussions, it can be either withdrawn or stopped or sent back to the mailing list for further discussion.

As a further step in this process, once the policy reaches consensus in the policy meeting, it is further presented at the APNIC Members Meeting, which is generally on the Friday, the last day of the Meeting, for approval by the Members and further consensus.

After that, the consensus stays or the summary of the discussion is posted to the mailing list. There is an eight week long period where people can further discuss it or work on it and the discussion is posted on the mailing list, the last call is done and if there is no objections, it becomes a passed policy.

If not, we go through the whole process again of being discussed in the mailing list, being presented in face-to-face meeting and then discussion, consensus at the meeting, followed by consensus at the AMM and then back to the mailing list.

If the policy passes with consensus, then it goes into the implementation phase.

So it's basically a cycle. I mean, the before Meeting period, when we receive policies, then the Secretariat will work with the author to edit it, make it compliant with the syntax and procedures of APNIC, it's presented to the APNIC community, to the Policy SIG mailing list, it's discussed, it is then brought to the Meeting, during the Meeting, further discussion, I hope, in the Policy SIG as well as in the hallways and doorways and, you know, social events and everything, and then community feedback is taken, it goes back to the community on the mailing list and there is a chance for people, but not at the face-to-face meeting, to still comment on it during the eight-week period.

Then when everything is OK, the policy will be implemented.

So what is our role in the policy meetings or the policy process? Basically, the chairs, me and my co-chairs, Terence and Ching-Heng, who is not here, will try to manage the discussion. If the authors can't be here, then we also give a short overview of the policy. We generally try to manage the time.

And given the large number of proposals at this meeting, we will be pretty strict with time. I'm warning you in advance. So be prepared on what you want to say.

We do want, when you come up to the mic, to make your position known, for you to explicitly state whether you support or don't support or support with conditions, so that we have a definite view of the policies.

Sunny just told me that this session is being transcripted and broadcast live, it's webcasted, so whenever you go to the mic, please state your name and affiliation. If you don't want to state your affiliation, that is fine.

Before we go onto the next, we believe that all the policies that have been submitted have been submitted with good intentions. People think and people follow the bottom-up policy process, they are trying to use the policy process to address their concern about how we are, you know, administer the resource policy and how it is used on the Internet. We might agree or we might disagree, but, you know, our job here is to make sure that all the views are heard and we can come to agreement.

So please respect all opinions.

This is the formal thing. Informally, I was talking with someone yesterday and the World Cup cricket is currently ongoing on the subcontinent and for those of you who don't follow cricket, in cricket we can play for five days and still not win or lose. I don't think the policy process should be a reflection of that. We do want conclusion on certain policies, otherwise it gets too late. Having kept that in mind, I think we'll move onto the next stage.

So next, my list here says we'll have to run the co-chair elections.

So any questions about the PDP process? OK. Thank

Next up, we'll have the Policy SIG co-chair elections. The call for volunteers were sent out six weeks ago and we have two volunteers: Andy Linton and Ren-Hung Hwang. The biographies are on the Meeting web site. The candidates will have up to 2 minutes to speak to participants, the election will be decided by a count of hands. The election is done by those who are present in this room. There's no online or Jabber voting. The count is taken by representatives from other RIRs.

I hope there are enough in the room. The candidates with the largest number of votes wins.

OK. So, actually, next, I'll ask Andy Linton to come up.

Andy Linton: OK. My name is Andy Linton. I know quite a number of you and some of you I don't know personally, but I look forward to, if I am successful in this, getting to know you better.

I have been involved in networking for over 25 years, early days, and I have worked at universities in England, New Zealand, and Australia. These notes are basically based on my biography that's on the website.

I have also worked operationally with a number of ISPs. I worked at AARNet in Australia, and I've also for Telecom New Zealand and Telstra and connect.com.au in Australia and I have worked for a metro fibre provider in New Zealand.

I have gone back recently to teaching network engineering at university, and I have a set of experience that goes across both the academic and the technical arena and operational arena.

I have a strong understanding of the issues that face this industry. I have been involved with this whole policy thing for a very long time, long before there was an APNIC, we were having to deal with some of these issues in terms of names and numbers and so on, and I have served on the board of the public interest registry, which manages .org and I currently am on the policy board that sets policy for .NZ and I'm a trustee of the NZNOG network operators trust. The other things that I sort of -- I'm also one of the 14 trusted community representatives that work with ICANN to oversee the DNSSEC process and I have been involved with APNIC since its formation, before there was an APNIC, David Conrad was based in Tokyo and one of the group of people who used as a sounding board for some of his ideas in the early days, I was one of those people when I was based at AARnet in Australia.

So I have this long engagement, on and off at these meetings, but certainly in my home environment and around the world in this sort of thing.

I'm also heavily involved with work in the Pacific, where I travel and do training courses and so on, and I think that I've gained from that an experience that sort of lets me meet and talk with people from all sorts of walks of life, all sorts of parts of our community. I appreciate that we have different ways of dealing with things, different ways of doing things. I would like to think that I'm a person listening to those concerns and I just believe that I can help facilitate good discussion on this, this important point in our policy setting and so on, as we move from the v4 to work with dual stack and have v6 implementation.

I would appreciate your support and I look forward to being of service to the community and to the people here. Thank you.

APPLAUSE

Gaurab Raj Upadhaya: Now we have the second candidate, Ren-Hung Hwang.

Ren-Hung Hwang: Hi, my name is Ren-Hung Hwang.

I was a professor in National Chung Cheng University, Taiwan. I have been Chairman for a couple of departments and then director for learning center. My experience on this policy making is in Taiwan, I was responsible to help TWNIC to make policies for Taiwan and also deliver those policies to the community, and I was involved in a number of projects for TWNIC, especially on the IPv6 deployment and the IPv4 exhaustion problems.

In the past few years, I have been involved in these meetings and also participated in the discussion of this community.

I think I would like to express to be co-chair and helping the community to make good policies.

So I appreciate your support and I think I'm very willing to service this community.

Thank you.

APPLAUSE

Gaurab Raj Upadhaya: Thank you, to both the candidates, for volunteering to be part of APNIC policy process.

Now move to voting with a show of hands.

I would like to request representatives from other RIRs. So John Sweeting from ARIN and Nate Davies from ARIN as well. Anyone wants to volunteer counting. Arturo? Yes. Please. This is a large room, so it's better to have more eyes.

I would like to request all of those who support Andy Linton to be elected as the Co-Chair of the APNIC Policy SIG, please raise your hands nice and high and for a while. Candidates can vote for themselves.

OK. So now you can put your hands down.

Now I would like to request those voting for Mr Ren-Hung Hwang to be elected as the Co-Chair of the APNIC Policy SIG, please raise your hands, long and clear.

OK. Tally your numbers and add or you can give it back to me and then I can add it up.

Thank you to all the representatives from other RIRs who helped in counting the votes.

As for the counting, we would now like to declare Mr Andy Linton as elected to as the Co-Chair of the APNIC Policy SIG APPLAUSE

Gaurab Raj Upadhaya: I would like to thank Ching-Heng Ku, who served two years as the Policy SIG Co-Chair. I would also like to thank Mr Ren-Hung Hwang who volunteered for the position of co-chair as well.

I would now like to ask Andy to come and join us up here on the stage. Thank you very much.

Next, we'll start with the open action items in the Policy SIG. We have a few action items, policy 29-06, or otherwise known as prop-083, "Alternative criteria for subsequent IPv6 allocation" was returned to the mailing list for further discussion and also working on a rewrite and we'll present it at this meeting.

Then we also have prop-085, "Eligibility for critical infrastructure assignment from the final /8". It was returned to the mailing list after the last meeting. The proposal has been withdrawn by the authors and key components merged into another proposal. So this action item is now closed.

Prop-087, "IPv6 address allocation for deployment purposes". It was returned to the mailing list for further discussion after the last meeting. The author has informed us that he's expecting more feedback on the mailing list and is waiting for more personal experience with protocols like 6RD before he presents this again to the Policy SIG. So this will stay open until the next meeting.

Prop-084, "Frequent Whois information update request". It was returned to the mailing list for further discussion. The author is now waiting for the similar policy to go through the RIPE policy process or it's actually working through the RIPE database working group and it will be present this again in feature, when those issues are clarified in the RIPE database working group.

Any questions on this?

OK. To facilitate the discussion on the different policies, what we have done is we have divided the policies into different groups and tried to organize these policies under a theme, so for this meeting, we have categorized all the policies into four different categories. First are the IPv6 policy amendments, or policies related to IPv6, a change in APNIC does IPv6 address delegation. The second group is our policies that are all related with, you know, tweaking how we deal with the allocations in the last /8. I think we need a new name for that, but that's the second group of policies.

The third one is the inter-RIR transfer policy.

Then the fourth group is basically two policy proposals about -- proposed global policy proposals about recovery and reallocation of address space by IANA.

We'll try to discuss these proposals together in a theme.

The first theme is the Policy SIG will do is go through two item v6 policy proposals and try to build consensus on those proposals.

So we have these two, that is prop-090, which is "Optimizing v6 allocation strategies", alters justification for larger/subsequent blocks, it suggests alternative for HD-ratio and call for allocation on nibble boundaries, so that the authors will expand on that further.

Then we also have prop-083, which was discussed a year ago and authors have gone back, got more feedback and are presenting it again for the Policy SIG discussion. "Alternative criteria for subsequent IPv6 allocation".

The authors actually informed me just before this session, during lunch, that based on some community feedback, they have altered some text. So we might try to get that presented as well.

But prop-083 mainly permits multiple locations, you know, multiple disparate networks to receive multiple allocations from APNIC.

So we'll start with this. First will be prop-090.

Owen DeLong is the author of prop-090 and Skeeve is going to help him present it. Owen is going to present it over Skype and then we'll have discussion following that. So when we go into the Q&A phase, please allow for a second of delay, if you are especially talking to Owen or asking him questions.

Owen, are you ready?

Owen DeLong: I can see all of you.

Gaurab Raj Upadhaya: So you are on the system now.

You can see the streaming and ask Skeeve to ...

Owen, you can get started and you can just ask for the next slide and Skeeve will turn it over. You can start now. Thanks.

Owen DeLong: Let me see if I can pull the slide up.

OK. Welcome to prop-090, IPv6 thinking for an IPv6 world.

Next slide, please.

So why do we need this? Well, at some previous events that I've attended in the APNIC region and other parts of the world, there's a common misconception that ISPs are supposed to fit inside the /32 and this is causing a lot of ISPs to think that they need to figure out how many customers they've got and squeeze their assignments down to sizes that will fit all their customers inside a /32 and that really isn't the intent. The intent was that a /32 was kind of the minimum size for an ISP and we have some options here to make things a little bit better. It turns out people are historically bad at bit-math and a very large percentage of Internet outages in the past have been caused by people making bit-math errors.

So how does this proposal help solve those problems? First of all, it makes all the allocations nibble-aligned, which means that instead of having to worry about breaking things in the middle of various bits, we just chop them off at digits. So no more bit-math in people's heads and hopefully we can reduce some outtages that way.

It also allows for at least of one level of hierarchy within the provider to also be nibble-aligned and rounded up to nibble boundaries, further reducing the probability of bit-math in the field.

It provides a clear ability to delegate up to at least a 48 per end site as the basic minimum.

Providers can still choose smaller minimums if they want to. That was an issue raised on the mailing list. This proposal doesn't prohibit that, it merely recommends that /48 be sort of the de facto standard.

It provides an ability to assign more than a /48 in the case of an end site that can show sufficient justification if there ever is such a thing.

Next slide, please.

It allows for a five-year planning horizon, so we can hopefully achieve better aggregation and smaller routing tables. It provides consistent size divisions. You can make every point of presence, or every serving site that you're certaining customers out of the same size as your largest site and in that way, it simplifies your subdivisions, it reduces the probability of fragmenttation and it creates the ability to have your engineers share consistent expectations across all parts of your network, which should hopefully reduce errors and outtages.

Next slide, please.

It provides for simpler expansion. No more complicated post-density ratio. You either need to achieve a 75 per cent utilization of your overall space or 90 per cent utilization at any one of these like-sized sites. So obviously your most populated site would need to achieve a 90 per cent utilization. If you don't have 75 per cent overall.

This allows you to expand fairly early before you get anywhere near the wall, while still providing pretty reasonable set of allocation guidelines that will prevent you from consuming vast quantities of space without making good use of them.

It does provide for some oversized subsequent allocations, enough to contain both your existing use and your projected future use, that will allow you to vacate the original allocation through attrition and optionally return that, so that you can keep your stuff in one to two prefixes, if at all possible.

Again, further improving aggregation.

Next slide, please.

So what are the down sides? The biggest downside is that this will actually increase the consumption of IPv6. Without this policy, the best estimates I'm aware of say that in 50 years, the IPv6 free pool will dwindle to a petty 99.9975 per cent free.

The results with this policy dramatically reduce that to approximately 99.54 per cent still free in 50 years. I think these are numbers we can live with and I think that the gains of this policy definitely outweigh the downside.

Next slide, please.

So in summary, we get better aggregation, better network structure, fewer outages hopefully through to no bit-math required and consistent expectations across the network, bigger prefixes for end users, and still plenty of free space for way more than 50 years of Internet growth.

Next slide, please.

At this point, I would like to open it up for questions, discussions, et cetera. Please approve this policy.

Thanks for your time.

Gaurab Raj Upadhaya: OK, I think I saw Randy walking before MMC. Randy, it's you.

Matthew Moyle-Croft: As we have been looking at our IPv6 allocation strategy for our broadband customers, which we're about to put into production, we have run into exactly the problems that Owen has talked about, which is it is actually quite hard to make customers fit into a /32.

In a world where everyone is encouraging us to give away IPv6 because there's lots of it, it does seem a bit bizarre to me that we put so much effort into making ISPs cram themselves into /32s.

The current policy, we probably don't quite have the customer numbers to get a larger allocation, and this would allow us to build a network that actually is much more future proof, much easier to run. And, yeah, I absolutely support this proposal.

Gaurab Raj Upadhaya: Thank you. Randy.

Randy Bush: This proposal seems to mix a number of things. Aside from the fantasy number math towards the end, it seems to be allowing an ISP to break address space and qualify across multiple POPs.

This has been done for a while in the ARIN region.

My impression is that it would be interesting to have somebody from ARIN itself speak. My memory is it's not heavily used and has been somewhat effective. John, if you care to wander towards a mic, but some of this proposal, which seems to say how I should allocate address space as an ISP and that I can't do bit-math is a bunch of crap and I am tired of people telling me how to run my network.

I have been doing it for something like 30 years and I can probably figure it out.

David Woodgate: I'm neither supporting nor opposing this proposal this stage, I just want to make a few observations.

I'm conscious that whilst I recognize that some of the limitations about the /32, I believe that TR187, as a broadband forum standard, actually recommends /56s as the standard for DSLs or broadband services -- somebody can correct me if I'm wrong on that.

So I'm wondering whether the assumption about the /48 being the absolute standard for all sites is actually likely to be valid and certainly when it comes to things like mobile allocations and things, that's going to be an issue.

Of course, there are 4 billion /64s in a /32 and I believe the IETF IESG has just approved the use of/127s for point-to-point links. So some of that is going to reduce some of the pressure in the other direction.

Like Randy, I must admit that I would have thought that, actually, in terms of the bit-math aspects, life would be even easier to determine whether you were just dealing with 2, 4, or 8 as your bit-math points anyway. So I'm not sure that's a great concern, but I stress that I'm not opposing this policy.

Gaurab Raj Upadhaya: Owen, et's go to the Q and A and then you can answer.

Owen DeLong: Sure.

Miwa Fujii: There is a comment on Jabber chat, Yi Chu from Sprint.

I would like prop-090 to remove the statement that /48 is recommended assignment unit.

Gaurab Raj Upadhaya: Thank you, Miwa.

John Curran: I'm up here because someone asked for some feedback on whether something was comparable in the ARIN region.

I'm actually going to answer. Randy, I think you alluded to the Multiple discrete network policy in the ARIN region. But I actually don't think that's the comparable here. I believe there's a policy proposal in the ARIN region to introduce similar v6 allocations for ISPs who have ISPs, that's actually in front of the ARIN region right now.

So we do have a multiple discrete network policy.

It's not heavily used. We've had maybe half a dozen people use it, but the most comparable thing to this is one of the policy proposals in the ARIN region that's up for discussion in San Juan in a couple of months.

Randy Bush: (Unclear -- not standing near a microphone ...) John Curran: Well, I would actually give that one back to Owen, if that was possible, if Owen would like to comment on that, because the multiple discrete network policy serves a very particular purpose, as opposed to a general policy that lets ISPs qualify for allocations of much larger blocks, recognizing the aggregation of ISPs below them.

Philip Smith: Something in the presentation that I didn't quite follow that got an implication that somehow ISPs couldn't get more than a /32 from APNIC and I'm wondering if we're actually in the right region. In the APNIC region, ISPs can apply for whatever v6 space they require. And so I don't actually understand what problem we're trying to solve here.

I mean, I agree with Randy. Why are we trying to tell ISPs how to dish out address space to their customers? It's their business. They get the 32 or greater and if an ISP wants to do 69s and 125s and 3000s for the sub-prefixes, that's their business.

Maybe I have misunderstood something in the whole write-up of the proposal or the documentation, but I can't support it as it stands, right at the moment.

Gaurab Raj Upadhaya: Thank you. I think I need to add two things.

The proposal also sort of implies that when APNIC does allocation to Members, they do it on nibble boundaries. So once they get a /32, the next allocation is going to be a /28 and not another /32. We have someone there, so -

Masato Yamanishi: I'm basically opposed to this proposal, because, first of all, if they start from misconception, I think it's not enough as a background statement of this proposal. Then also, in particular, I have a strong concern about nibble bit boundary, because if prefix length will become short, like /24 or /20, difference means very huge number of address. I think it has big negative impact.

Gaurab Raj Upadhaya: Thank you. Before I ask Owen to reply -- Sanjaya, is he around?

Can you tell us how this impacts the resource allocation from the Secretariat perspective.

Sanjaya: Thanks. As APNIC Secretariat, as usual, we are neither against nor for any proposal.

The implementation consideration for this particular proposal is it's slightly more complex.

We probably are able to -- if this gets approved, we probably need a two stage approach to implement this.

Three months and then take another three months to set up our system to support the non-HD-ratio calculation utilization. So it can be deployed. It will need six months in two stages for us to implement this.

Gaurab Raj Upadhaya: Additional question - how many allocations of /32 -- v6 we have -- Sanjaya: Larger than 32?

Gaurab Raj Upadhaya: Yes.

Sanjaya: Probably 10 per cent.

Gaurab Raj Upadhaya: OK.

Sanjaya: Most of the large ISPs, the really big ISP ask for more than /32. Most middle size and small ISPs are happy with a 32.

Gaurab Raj Upadhaya: OK. Thank you. Owen, you have now time to respond.

Owen DeLong: OK. First, I'm not presuming to tell Randy how to run his network or anyone else. That is a misunderstanding of the proposal and I'm sorry Randy chose to take it personally.

The proposal is to allow up to these maximums.

ISPs that want to do something smaller are welcome to squeeze their network into whatever lesser space they would like. This is setting a mechanism by which APNIC can calculate the maximum allowable size for an ISP on a reasonable basis.

It is not a misconception that APNIC is creating at least the perception on the part of people applying to APNIC that unless you are extremely large, you get a /32 and you have to squeeze your customers into it.

I discussed this with APNIC registration Helpdesk people and with various APNIC applicants before I submitted the policy proposal and it's not a misconception; it's reality. That is at least the perceptions that is being created by the current policy and what people are doing.

Gaurab Raj Upadhaya: Thanks, Owen.

I think at this point, we would like to see whether the room here supports or doesn't support the proposal.

Mind you, this is not a vote, it's just a way for us to gauge the level of consensus, because we can't have everyone going to the mic and, you know, telling us what they feel like.

So if you think this proposal is a good one, it helps you, please raise your hands now.

Thank you.

If you think that this proposal doesn't make sense and we should drop it, then please raise your hands.

OK. Thank you very much.

I think there's no consensus on this proposal, so what we'll do is we'll send that there's no consensus to accept this proposal to the mailing list and then see what happens. It's not sending it back to the mailing list, we'll just inform the community that there is no consensus and maybe Owen can revisit it at another stage.

Thanks. Sunny is clarifying some procedural information for me - as I said, there is no consensus to agree on this proposal, so we'll drop this proposal as of now.

I'm sure this proposal will come up again in other forms, but thank you for your participation.

Thank you, Owen.

Owen DeLong: You're welcome.

Gaurab Raj Upadhaya: Thank you very much.

Next policy we have under discussion is prop-083, also to do with v6 delegation policies. This was last presented in Kuala Lumpur and was sent back to the author for reconsideration and discussion with community, so it's back here again.

This is version 3.

Skeeve, up to you now.

Skeeve Stevens: Thank you, Gaurab. As Gaurab pointed out earlier, I did send a version 3 to him during the lunch break, based on some community feedback and I have confirmed with APNIC was this OK and it was basically the spirit of the policy is still the same. What I have done is basically de-focused it on the disparate networks and to make that an example and option and I believe Gaurab will be sending it to the SIG policy list afterwards.

Gaurab Raj Upadhaya: What Skeeve said was based on his discussion here at the meaning, he sent a slightly revised text, but that is too late to be formally considered here. He's going to present this at the meeting, his revised version of the policy, and we'll just consensus or no consensus and it has to go back to the mailing list for it to complete the process.

Go ahead.

Skeeve Stevens: OK. So this is a proposal and it was presented in KL a year ago. It did not reach consensus and went back to the list.

There has been probably only support in the only brief discussion, there's only been a small discussion about it, which was detailed in the Chair's summaries.

Over the last year, there has been about a couple of dozen instances that have been referred to me relating to this policy of people having similar issues, where they've approached APNIC for subsequent allocations yet have not fulfilled the utilization on their initial allocation. This has been for a variety of reasons, disparate networks seems to be the number one major part. Just for clarification, disparate networks is where you have a network that is not connected to your -- the network that you announce your original allocation from that would be announced by a different AS and because of the bogon filterings and other issues, you can't slice up your /32 and announce it in smaller chunks due to these issues.

So what I have done is I have slightly altered the policy that basically opens a series of options that can either be given to APNIC and the community to make available a variety of choices and I'm only presenting two at the moment, that allow people to get additional allocations of IPv6.

So the initial introduction of the text is this is a proposal to enable APNIC current account holders, with existing IPv6 allocations, to receive subsequent IPv6 allocations from APNIC to facilitate network deployments.

At the moment, the current policy, in certain circumstances, put handcuffs around your ability to design your networks and I agree with Randy and others, where we should not be constrained and we should be able to build the networks that we need to, in the way we need to do it. We have been doing it long enough that for the lower end of town, the smaller ISPs that do not have international capacity and so forth, this is causing a problem.

This is a summary. An LIR with an existing 32 unable to de-aggregate 32 due to community practice of filter blocking or bogon lists. The LIR may want to build a network in a separate location and provide IPv6 connectivity and so forth.

Due to routability problems and de-aggregation, the LIR cannot use the subset of the initial allocation.

An example would be I, for example, have a /32, I'll use myself as the initial example. We have networks in Australia, in Sydney specifically, where we announce our /32. We now have a new office in the Cambodian region and we now have IPv6 capabilities to that office, but I can't de-aggregate by /32 in Sydney to be able to announce that over there, otherwise it will be filtered, even though we use a a different AS and so forth.

So the request is that -- and this is only on a very small scale. Other similar ones that were brought up on the SIG policy list was Monash University in Australia that has multiple overseas campuses that are separate networks that is actually unable to obtain extra v6 allocations for to feed those locations. I do not believe the policy environment is to go through the couple of dozen examples that have collected over the previous 12 months, but suffice it to say it's becoming, as deployment happens more and more, where there are separate networks, this is becoming a serious issue.

This other examples of subsequent allocations may also be to facilitate transitional technologies such as 6RD, which was dealt with in another policy, but could be handled by this policy, should this policy be approved.

This is just a brief summary. It's similar to what -- it's the same as what was announced in KL and the key problem with bogon filtering. I don't think we need to go into the details about the bogon filtering.

As far as I know, there has been no changes in the status of the other RIRs. But feel free if you're here to correct me on that. I don't think AfriNIC and LACNIC have any policies. ARIN still has the same policy they referred to 2009-5. It has been adopted and integrated, yes. There's not that many -- John, is that the same policy that you're to referring, that there hasn't been that many allocations under it?

John Curran: Yeah.

Skeeve Stevens: RIPE, there was a similar policy and it was rejected in favor of 2006, which basically recommended the routing requirements be relaxed. But as far as I know, they have not been, so far.

So this is the basic details of the policy are the same as the wording that I have already given, with the two examples being disparate networks and transitional technologies. The list of valid reasons in this policy can either stand with the two examples and personally, I believe that APNIC is capable enough to judge with some guidelines from the community, of subsequent allocations and whether they're applicable, but at the moment, they're restricted by the utilization and consumption rules, so they're not actually able to make that decision.

To the point that APNIC has actually had to say no, but there is a policy out there, if you are able to look into it, which seems to fit against what you're actually doing.

So APNIC is actually in a position where it isn't able to do that at the moment and I would like to see this policy be able to free APNIC or the community or just leave it in APNIC's -- the Secretariat's hands, to be able to make those decisions.

Just some details about the qualify, same as before, be a current APNIC account holder, be announcing an existing allocation, have a compelling reason required for the subsequent allocation.

I have removed the wording relating to -- in that slide and moved it just to a valid example, so a compelling reason for establishing a separate network or transitional technology such as 6RD with an implementation plan and so forth. In other words, APNIC should be free for you to convince them that there is a valid reason, for you to be able to go I have networks this these locations, I do not have interconnecting communications because of (a), (b), or (c), I'm rolling out 6RD or other technologies that might require transitional address space and so forth.

Advantages. The proposal enables current account holders to deal with the problematic operational issues. We'll be able to acquire resources and announce them separately to transit provider this is disparate locations and be able to innovate with transitional technologies not constrained by present consumption policies.

The disadvantage that I have to list, although I agree with some of Owen's numbers, is that this proposal could lead to faster consumption of the IPv6 address space. I will use some different numbers, in that the only one I really want to refer to is the standard /12 that APNIC has in v6, which is 1 million /32s.

Given the number of Members in the APNIC region, even if every Member was to take another ten /32s, this would impact that /12 in no significant way whatsoever.

I realize there are some people that have the views of economies and consumption and I do agree that, especially in point-to-point links and a few other areas, but I believe that we are being constrained by -- not by current policy, but by lack of freedom of policy in how we operate our networks and going forward.

APNIC Members, the same as the previous slide.

NIRs, no particular effect on those and standard references.

Gaurab Raj Upadhaya: Thanks, Skeeve.

Joao Damas: I was surprised that you mentioned that the bogon list was not the issue.

Skeeve Stevens: They are one of the big issues.

Joao Damas: They are essentially the reason for this. When we have this discussion at RIPE, everyone reached the conclusion that in fact that the problem relate not with the size of the allocations, but the rigidity or stubbornness of how the bogons were being set up and there's work going on on a set of representations to make people realize that some time in the past, perhaps blanketing everything on /32 was the thing to do, but that's not the case any more.

You are correct that the recommendation is not finalized yet. I also like to report that one hour ago, we just issued a new revision of the recommendation, so feel free to comment on it.

Skeeve Stevens: Is that 2009-6?

Joao Damas: It's not the policy. We try not to mix address policy and routing policy, because they are two independent things. So the policy -- the address policy says one thing and refers to a future routing recommendation for filtering and routing work group at RIPE is the one working on the routing recommendation. That's the version of the texts that being revised one hour ago and that you are welcome to comment on.

Skeeve Stevens: OK. Is that working group from 2009-6? It resulted? Because that was issued nearly a year and a half ago.

Joao Damas: I'll lead the next person explain.

Skeeve Stevens: OK.

Emilio Madaio: I'm the Policy Development Officer at RIPE NCC. The proposal you mention here, policy proposal 2009-6, was approved in September 2009, yes, and updated the document, the policy document RIPE-512. Joao Damas is mentioning a routing document that will cover the strategy for IPv6 routing, but as he said, we in the RIPE NCC service region, we do separate the policy discussion and the routing implementation recommendation. So in this sense, this happened, we relax it, as you said here, the routing restriction, so policy-wise, we don't say how much it has to be the prefix announce on the routing side, there is this new document that Joao Damas mentioned. OK?

Skeeve Stevens: Has that has an effect yet?

Gaurab Raj Upadhaya: Steve, can we go back to the floor and then go back to it at the end. Thanks.

Randy Bush: I have some sympath for this by the way. I do not filtering argument, I currently announce a 48 in three locations, I have no reachability issues - about Rob Evans' instigation actually do a reasonable measurement study on this using techniques similar to the stuff we did at the bogon filter detection a couple of years ago. So I think it's wonderful that we all base our theory on layer nine things and far I know, there is no serious filtering on things longer than /32, but I have sympathy for wanting to be able to get segments to announce in multiple locations and I think John will hopefully speak to that from the ARIN experience. I'm trying to understand the difference between what I see in writing and evidently this is a modified proposal. I think if I understood your presentation, I just want to be clear, so I know when I raise my hand in stupidity I"m a little less stupid, that you've taken and moved the criteria for being a little explicit and formal, to being dump it on the hostmasters. I'm not saying that's good or bad. Is that essentially the difference in this proposal, Skeeve?

Skeeve Stevens: Yes, it's essentially the difference in the version 3.

Randy Bush: Thank you.

John Curran: I have no view on the policy proposal. I'm going to try to just try to seek some clarity in the situation at ARIN compared to this. I ask apologies in advance, because comparing policies between the regions is sometimes like comparing curry between the regions or cuisines, same words are used differently.

Depending on how this is used, this actual might be most similar to, if it's used for transitional technologies, for example, to the policy proposal in the ARIN region 2010-12, which allows you to get a block allocation for that particular purpose of transitional technologies. That's just been adopted. We have a /16 allocated for that purpose to do special allocations out of.

So depending on how you're going to use this additional block, it may match the ARIN policy that was just adopted or it may be a discrete network, so I'm trying to describe something this general and how it compares in the ARIN region, says how someone goes to the hostmasters and says how they are going to use the additional block.

Philip Smith: Many of the folks have said what I was going to say, but I was just interested in one thing, Skeeve. In the two dozen issues that you had, could you narrow it down to any particular provider or providers that were actually blocking your reachability? A bit of history. I have been announcing Cisco's /35, out of a /32 block for, I don't know, close on seven, eight years, pretty much anywhere I have gone on the planet, I have just seen that /35.

I would just be curious, this is just personal information, to know where the blockage actually is. I'm really looking forward to Randy and his teach's research, to find out what the issues are. I'm worried that we spend a lot of time at the policy level with something that might be a technical problem. Doing the research will be very interesting.

Miwa Fujii: There is a comment on Jabber chat, Owen DeLong, Hurricane Electric: "I support this proposal. It's just good sense."

Gaurab Raj Upadhaya: Thank you, Miwa.

Izumi Okutani: Just to share what we do in JPNIC, is one of the issues that you have raised.

In our case, if they've deployed a separate global ASN within the same organization, we consider them as a separate account and we give separate initial allocation. So, for example, like ISPA runs two separate networks, one in Tokyo, one in Osaka, each individually with separate global ASNs. We create two separate accounts and then they get two /32s as initial allocations instead of subsequent allocations.

So just to share. It might help some of the issues that you're trying to resolve.

Gaurab Raj Upadhaya: In this case, do people pay more when they get more address space in.

Izumi Okutani: Yes. They are charged, as like a totally independent account holder.

Gaurab Raj Upadhaya: They pay for a total of /32 address space.

Izumi Okutani: They charge for the total of two separate, individual /32s.

Gaurab Raj Upadhaya: In effect they are getting to memberships?

Izumi Okutani: Yes, something like that, two accounts, two membership accounts.

Gaurab Raj Upadhaya: Thank you.

Any other comments?

Skeeve Stevens: Just some brief comments there. We've had several -- I don't have the details of which providers, but we have come across a lot of rogue routers which have old v4 bogon lists and v6 bogon lists. There isn't too many of the v6 ones. I would have liked to have had enough time to fully go through, but the bogon list is just one issue. Accounting and doing separate different networks in different locations is also, from an administrative perspective, a lot easier.

Referring to what Izumi said, I have no problem. In the APNIC perspective, if you have two /32s, you're going to be paying more to APNIC anyway, whether it is two separate accounts or I think it would probably pay a lot more if it was two separate APNIC accounts, but if it was under a similar account, then you would be paying more anyway.

So the resources there would be paid for.

I'm also very interested, I would be very interested as soon as possible to see the bogon project analysis and where the different blocks are.

Gaurab Raj Upadhaya: Thanks Skeeve. I think we sort of get the point here, that bogon or routing announcements might be an issue, but not really a big issue.

Skeeve Stevens: It's only one, yeah.

Gaurab Raj Upadhaya: So I think it calls for the community to go and, you know, announce their /35s and see reachability, because we have done that before.

Skeeve Stevens: My only last statement is that I have been listening a lot over the last couple of years and I believe that policy shouldn't manipulate or control how we operate our networks and I believe at the moment policy is limiting our abilities to do what we need to do to easily expand our networks and it particularly affects the smaller ISPs that are setting up in different locations. When I start to put some servers in a variety of infrastructure in Cambodia or Thailand or New Zealand, these are going to cause significant issues to me.

Gaurab Raj Upadhaya: Thanks, Skeeve.

Before we put this for consensus, can I ask Sanjaya again to give an implementation report?

Sanjaya: Again, we are not for or against any proposal, this can be easily if approved, we can support this implementation within a few months. We do need some guideline on approving the additional request, like we either create a separate -- in IPv4, we have a separate, we have a main policy document and we have a separate guideline that gives the APNIC Hostmaster a bit of a checklist on how to evaluate this additional criteria. We probably need that additional guideline for IPv6, if this proposal gets consensus.

Gaurab Raj Upadhaya: Actually, I have a question for the community here. Is if you have reviewed APNIC IPv6 policy, it was written quite a few years ago.

As we have seen, we keep on getting new proposals to tweak bits and pieces of it. I actually invite the community to go and discuss this on the IPv6 Technical SIG and if it's to be reviewed, you know, probably a good place to do that. That's just an aside.

Randy Bush: I submit that the rate of arrival of proposals has nothing to do with anything in reality.

Gaurab Raj Upadhaya: I agree.

Thanks. We'll put this for a consensus to the community.

So those of you who think this is a good proposal and should proceed forward, the condition here is that there is a special condition that the text that was presented in the PDP before the meeting and the text that Skeeve just presented are slightly different. We'll go and try to get consensus on the new text and then this has to go back to the mailing list and through the policy process again.

I'll request those who are support the proposal, please raise your hands.

Thank you.

Those of you who oppose the policy, please raise your hands.

Thank you. Miwa, yes.

Miwa Fujii: One more supporting from remote participation.

Gaurab Raj Upadhaya: Thank you.

I think there's no strong objection to the proposal, so we think that the proposal has reached consensus.

Thank you very much, Skeeve. This proposal will go back to the mailing list for the eight weeks' comment period. So there are, you know, issues there, we can still discuss this.

We are right on time. That is nice. So thank very much. We'll come back in half an hour after the coffee break and we'll start discussing the more interesting, the so-called last /8 policy in the next session.

Thank you very much.

Policy SIG.
16:00 to 17:30.
Wednesday, 23 February 2011.
Hall B&C.

Gaurab Raj Upadhaya: Welcome back. Thank you once again.

Before we start, I have a small procedure, so I would like to request Paul Wilson to come over to the stage.

Randy Bush, as the chair of the Policy SIG for many years, and so the Secretariat is giving a gift on behalf of the community, for his hard work with Policy SIG. So, Randy.

APPLAUSE.

Gift presentation.

Gaurab Raj Upadhaya: Thank you, Paul. Randy should not take that as a gift to keep silent, though.

The next session, we have quite a few policies detailing how and what we should do with the final /8. We probably need a new name for it, but for now, we'll use the term IPv4 Final /8.

As I said earlier, we have grouped a bunch of proposals under this category and we'll go through them.

First up will be prop-088 and prop-092. These are basically competing proposals. Basically, prop-088 also looks at distribution of v4 addresses once the final /8 period starts.

Prop-092 looks at the distribution of additional APNIC IPv4 address ranges after IANA exhaustion.

Basically, these provide two alternative views on what to do with new resources that are added to the pool after the final /8 threshold is reached.

Should they be reserved under a single /8 policy or be made available for allocation under pre-exhaustion policies? This is basically, you know, only one of these policies can pass or should pass, otherwise the implement is, you know, you can't do it.

Then after that, we'll go and discuss prop-091, which is "Limiting of final /8 policy to the specific /9". This is what we intend and then if we still have time after discussions, then we'll also do prop-093, which is reducing the minimum delegation size for the final /8 policy. I think we might not be able to go beyond that.

Thank you, first, I would like to request the author of prop-088, followed by the author of prop-092, to come up. We'll put on prop-088 first and then prop-092 and then discuss the two together.

Philip Smith: Good afternoon, everybody. I'm Philip Smith, I'm one of the co-authors for policy proposal number 88.

This policy proposal really comes about as trying to fill in some of the little holes in the final /8 policy that was passed previously.

I suppose in our rush to get the final /8 policy in place a couple of years back, we overlooked some of the tiny little corners that I think became quite clear in the previous APNIC Meeting on the Gold Coast.

This one really deals with what do we do with IPv4 addresses that are received by APNIC once the final /8 policy is in place?

The current problem is that once the final /8 policy is in place, it is quite possible that APNIC will receive further IPv4 address resources. They could come back from Asia Pacific region networks that no longer need them or they could come from the IANA if the Global Policy for Redistributing v4 Resources from IANA succeeds.

The original intent of the final /8 policy, at least as far as us as authors goes, was that it would replace all other v4 assignment and allocation policies.

We didn't actually write that explicit text in the policy proposal, so the current language in use doesn't repeal it, so it leads to potential for confusion there.

As far as Randy and I are aware, there is no other similar policy or proposal in the other registry regions.

The details of the proposal, quite simply, are this. When the final /8 policy is activated, any v4 resources received will be placed in the final /8 pool, even if it makes this pool larger than a /8.

That's applicable to addresses returned from holders of addresses in APNIC database and any addresses that may be received from IANA.

These resources will be distributed according to the final /8 policy.

Advantages, it reduces the confusion possible if v4 resources are received outside the final /8, but during the period when the final /8 policy is active, because it explicitly states how these v4 resources are to be handled.

Disadvantages, we aren't aware of any, none are foreseen. Impact on APMIC Members and NIRs: This proposal will impact all APNIC Members. Members can only request and receive a single distribution from the final /8, so this would also apply to any other v4 addresses placed in the final /8 pool by this policy.

There's no direct impact on the NIRs themselves, but it impacts members of NIRs in the same way it impacts APNIC Members.

And that is it.

Are there any questions, comments?

Gaurab Raj Upadhaya: Thank you, Philip. We'll have questions later on.

David Woodgate: Thank you, everyone. I have prepared the slide pack on the basis of dealing with prop-091 and -092 at the same time, but I'll just pick out the bits which are relevant to prop-092 right now.

For both prop-091 and -092, I do strongly believe that it is the duty of APNIC to distribute resources, not to withhold them without a very clear and good purpose.

If there is a clear and good purpose to withhold addresses from the community, when there is a clear demand for them, then obviously I think that should be reviewed on a regular basis, just as a process of good governance, to make sure that it is still appropriate to continue withholding those addresses and make sure that a need in the community which could be fulfilled, is not being overlooked accidentally.

We do want to encourage a speedy transition to IPv6. I believe everybody who's here really, really wants to see IPv6 happening in the networks now as quickly as quickly as we can all manage.

But the fact of the matter is that IPv4 addresses are the most used now. The subpoint there about releasing more v4 addresses in five years might have been written with prop-091 in mind, it was certainly applicable to prop-092 too.

The comment was made by Lorenzo yesterday in the IPv6 working group, that there's sort of going to be a degradation of the use of IPv4 addresses over time and this is on the whole, this is a good thing, I believe.

I think we're trying to get to a point where everybody is automatically assuming IPv6.

That means the point of most use of IPv4 addresses right now, where before all the IPv6 infrastructure is in place.

So if we withhold them now and then get them out later when they're not as useful, then have we actually served the community as we should?

I certainly support reserving addresses.

I support the basic premise of the final /8 policy, in terms of reserving addresses for dual stack introduction and making sure that there's a suitable period of time for keeping addresses. But for prop-091, is a /8 the right size. For prop-092, do we really need more than a /8 for that purpose?

So prop-092 is that we should only apply the final /8 to the final /8. In other words, the last /8 that was allocated by IANA.

Any other addresses recovered by APNIC should be distributed according to the current allocation policies and the pre-final /8 policies.

I specifically excluded in the document considerations about if we wanted to return addresses to IANA, there might be, this is in the situation where APNIC has decided that they want to hold addresses for distribution and not return to IANA.

The APNIC Secretariat would need to determine appropriate processes for the distribution of what would be an intermittent pool. I'll make some further comments about that very shortly.

Why should we do this policy? Again, APNIC should be distributing addresses and the final /8 policy would seem to leave enough addresses for otherwise special purposes.

Just commenting on that logistics issue I commented on, obviously, the introduction of an intermittent address pool has several challenges in terms of trying to judge how to distribute addresses which may come in in various sizes and whether high or low watermark processes are required, et cetera.

But I do believe that the APNIC Secretariat are up to the task of being able to decide on appropriate processes.

By the way, I point out that there is an alternative, of course between, to approving either prop-088 or prop-092 and that's to not approve either at this stage, of course.

In terms of disadvantages and advantages, to be honest, it's pretty much the same as prop-088, so I won't go into the details.

That's all I have on that front.

So should we have Philip up here as well to jointly take the questions and things?

Gaurab Raj Upadhaya: Well, yes. I think we'll invite comments from the floor.

Gaurab Raj Upadhaya: When we are discussing these please state clearly which proposal you're talking about and state clearly which one you support.

Masato Yamanishi: I support -088 and oppose -092, because in my understanding, the final /8 pool has first meaning. The first one is suddenly assistant or helping implementation of transition solution, but secondly it is a reserved pool for newcomers.

Currently we are not sure how long we will need to assign IPv4 address to newcomers. So in that meaning, I think if we can add something to this pool, I mean, final /8 pool, we should do.

Randy Bush: I'd like to remind you of a number of talks given previously today and yesterday. For instance, Geoff's, et cetera, et cetera.

The fact is that -- well, there's first of all, just one thing we have to get over. There ain't enough. We're out. Done. OK?

So the question of, is X enough, the answer is universally no, for all values of X. OK.

As was alluded to by the previous speaker and as I said, Geoff, et cetera. Over the next transition time, until there is no more IPv4 out there, which unfortunately is going to be a decade or two, for a new entrant -- not an ISP, but just a multihomed site, a new small ISP, whatever it is, an enterprise, to get into the game and use the Internet, they are going to need a small bit of IPv4 space to front some sort of address translation device, whether that's NAT64, whether that's, you know, A+P, whatever. They are going to need a little bit of v4. OK? So the /8 proposal was specifically to do that.

You do not know how many you're going to need. You're not going to need how many are going to need it. You're talking about 10 years. You're talking about millions of new sites entering the Internet.

You're not talking about APNIC Members. You're talking about a lot of people.

So trying to restrict that and trying to guess what it is, because, oh my god, I can get a little bit more IPv4 space, give up. Our grandchildren are going to need it and I do have grandchildren.

Mark Newton: Neither support or disapprove either of the policies, but just a comment on prop-092.

It's predicated on the notion that in a world where we're moving towards IPv6 while IPv4 is exhausted, that there will actually be recovered IPv4 space.

That sounds a little bit unlikely to me, which makes prop-092 a bit academic, as far as I can tell.

Izumi Okutani: I basically agree with earlier comments made by [] and Randy that it should be used by newcomers and for the purpose of helping out with the transition to v6 and I think for the basis of the proposal, it mentioned that we only have roughly 3,000 Members in APNIC region and then the growth is about, well, like, 300 Members per year or something like that.

But it's really easy to meet this criteria, initial allocation criteria, because you just have to use /24 immediately and then /23 in one year, so once we get to the runout phase, if ISPs, LIR's customers need more additional space, I think they will suggest their secondary ISPs to become LIRs themselves, so I don't think it's reliable to base our, like, thinking that the current pace of membership growth will still continue after the v4 run out, so we should be quite careful in how we use this last /8 space and I don't think it's wise to shrink that space.

David Farmer: I have some questions for -088. Let's assume for a moment, by some magic, addresses appear in IANA.

Would you anticipate APNIC requesting resources from IANA to put into the pool if they were available or not? Because if you have a 10 year pool, let's say or whatever number you think it is, it's probably more than two years by its intent. If these addresses are returned to IANA, they were probably returned under the premise that someone would put them to active use and not sit in a pool for a decade.

Philip Smith: So prop-088 doesn't have anything about APNIC requesting any addresses. If APNIC happens to receive addresses by whichever function, whether they come from IANA or whether they come from the membership, then they will go into the pool.

David Farmer: I guess it might be worth clarifying that, because certain of the global proposals still call for a request and so under this, would you expect the Secretariat to make a request, be they were available or not?

Philip Smith: Dave, can I just repeat what Randy says. It's intentionally not stated.

David Farmer: OK. It would be helpful for evaluating, you know, implications for it to say that.

Randy Bush: No it wouldn't - when I say intentionally not stated, it's because we're not going to recapitulate all of policy, right. If you want to affect the policy of how things get re-given to RIRS if space magically falls from the sky, and all those things, do it in those policies. We're not trying to put everything in the world in this policy. We're just trying to say: if there is whatever space there is, gets treated the same. No matter where it comes from, how it gets there, whether it's green, pink, or blue.

David Farmer: Ok, thank you. Then I have another question for prop-092 and that is, so by saying that they would be distributed under the current policies in effect now, that would still mean that they would be distributed still on a needs basis, as it is in current policy.

David Woodgate: Correct.

Jonny Martin: I'm not sure why we're so scared of potentially having -- well, likely having addresses in the last /8 that remain unused. That to me is not a bad thing. That's basically our fallback position and by our fallback position, I mean, you know, Members, users, everyone.

Once they're gone, they're gone, we can't change our minds. So, you know, I think it's the reason that the original last /8 proposal was written that way, is to keep it very simple and make sure that that space doesn't get fully utilized, because if it does, we have nothing to come back to.

Paul Vixie: I'm a member of the ARIN Board of Trustees, but I'm speaking at this microphone as the Chief Scientist of ISC. We are an APNIC Member.

As I contemplate these alternatives to what's to be done if space comes back over and back above and above this last /8, in my mind, I'm characterizing it as a scarcity allocation regime, versus the previous non-scarcity allocation regime.

The time at which IPv6 will begin to be safe to deploy as a v6-only network really depends on other people not being able to get v4. In other words, the sooner the community entered the scarcity allocation regime, the sooner we would then, some day, reach the point where a v6-only network would be safe.

I would not like to see a return to a non-scarcity regime, based on addition of new space into that pool. I think that the scarcity regime is the healthiest thing for all of us going forward.

Thank you.

Gaurab Raj Upadhaya: Thank you. Randy.

Randy Bush: Paul, two things. Number one is, possibly what you don't know about the final /8, whether more things fall into it or not, is one per customer forever. So you can get a 22 or a 24 once.

So that's scarcity.

Paul Vixie: Thank you for clarifying. I was aware of that when I made my comments.

Randy Bush: As to the -- one argument that has not been raised or discussed is the fragmentation of the IP space and routing tables.

I anticipate, 10 years from now, because of the problem of all the people needing a little bit of IPv4 to be able to translate out to the remaining v4 services and the remaining v4-only things, that I'm going to be routing something like /27s.

I don't like it, but my job is to deliver packets.

Ah, David, we all hope not. By the way, I did have an alternate proposal that my friends advised me not to make, which is, first of all, to make another IPv4 policy proposal, you had to donate $10,000 to Greenpeace and the last /8 would go to David.

LAUGHTER Gaurab Raj Upadhaya: David, you would like to add something to the discussion?

David Woodgate: Thank you, just very quickly.

Fortunately, some of those points which were raised, I actually wrote down for prop-091 anyway, so I may as well discuss them now and save doing it during prop-091.

IPv4 has run out and we should just accept that. Well, it either has or it hasn't. We have some IP addresses, particularly with respect to prop-091, the question is -- it's that big question mark about just how many addresses, how many account holders are likely to crop up to take those addresses in the /8 anyway.

The reality is that, again, I'll anticipate prop-091 by just saying, kind in mind that a /9 could provide services for a body of people the size of Hong Kong. So the question is if you don't think that's going to be used in 20 years time or something and we have sat on it all that time and we could have done something with it useful now, then have we actually served the community correctly?

We should preserve some IPv4 for our children. I truly believe, on the basis of that my one year old will only see IPv4 in the history books by the time he's studying networking, if he's that silly.

I would really believe that if we haven't got IPv6 in place in the next 10 years, then we have failed, categorically, completely and utterly.

If we still find that we're trying to corner cases for a lot of people here, for IPv4, then something has gone really wrong.

In terms of the behaviour after APNIC exhaustion will be unpredictable, so we should wait to observe those before changing the final /8 policy and apply that to prop-092 as well, I certainly agree that's a valid argument. We all know you can't predict non differential functions, but what I'm scared about, I am scared about that some of the changed behaviours might not be good behaviours for the industry, that we might be creating industries in their own right, in terms of extra administrative work that otherwise wouldn't be needed, do have to question just how many additional Members do we want in APNIC who aren't perhaps really fully knowledgeable about the networking community, but really just trying to get that last /22 or /24.

As I said before, IPv4 addresses are most used now, so waiting one year for these may be OK, but in five years or 10 years, it is too long.

I completely agree that this is all a guessing game and placing some of your bets about where you think capabilities are going to lie. I agree that we may be for some of these things, you need to -- maybe we do need to wait a bit longer.

But I do believe that we should be continually reviewing how we are treating these addresses and if we do sit on them ad infinitum and it becomes clear that there's no value in doing so, then I believe we're not doing the right thing by the community.

Gaurab Raj Upadhaya: Thanks. David.

Miwa Fujii: There is a question from Yi Chu, Sprint, by Jabber chat. prop-088 under the scarcity regime, put APNIC community in disadvantage in getting IP from IANA compared to other RIR. What if other RIR adopt something similar to prop-092?

Philip Smith: As I mentioned earlier, prop-088 doesn't say anything about requesting address space from the IANA. It just simply deals with the situation if APNIC gets address space from IANA or from other members of the region. We deliberately kept that piece out.

Randy Bush: David, you're talking to somebody whose company deployed IPv6 over a decade ago and I look around and I see the state of IPv6 deployment and I'm not too sure that IPv4 is going to go away real soon.

This group seems to have plenty of capability for going around and redeciding what policy should be. So if in one year, or five years, or 10 years, we say: oh, you know, IPv6 is out there, there's this last v4, we don't need it, give that to Greenpeace instead of the $10,000. Fine. We know how to do that.

What we don't know how to do is eat that v4 space up now and when we find we're five years out and we need it, pull it out of our hats.

Tom Vest: Actually, just a couple of questions for clarification, David. You made a couple of points which seem persuasive. You talked a bit earlier about the presumptive declining utility of IPv4 at some point in the indeterminate future. So that they would be of diminishing value, because they would provide less connectivity and then of course, if the -- I mean, the utility of the addresses itself, the inherent thing, is not so important, I would say, as the utility for whom.

If you are looking to maximize relief from problematic address resources, it seems to me that IPv6 users who would be lacking v4, would be the parties who would be suffering most from addressing this utility, so that you would want to consider the effect on them as well.

Also, just now you mentioned that you were concerned about the possibility that the reservation policy would incentivize some less-than-productive business models. Have you considered the possibility that reducing the reservation and therefore, perhaps incrementally, creating greater uncertainty about the transition, could also easily have the same effect as well? Have you considered balancing those alternate scenarios?

David Woodgate: Yes. My thoughts on that are that I suppose that the scarcer that the addresses become, the more that the industry may be focused on the IPv6 deployment earlier. Whereas if you leave --

Tom Vest: I don't think there's a whole lot of empirical evidence for that, but maybe.

David Woodgate: We haven't run out yet. We haven't hit the final /8 policy yet.

One of my fears is that if you leave too much space around, then you start making people assume that will have at least dual stack capability, if not IPv4 capability, for a long, long time to come, as it is, rather than trying to bring home the point that, oh, yes, we have enough to get you dual stacked and NAT-ed, but, you know, you aren't going to be able to feed everybody forever. So people should be thinking about how to get beyond the dual stack phase of IPv6.

Gaurab Raj Upadhaya: Thanks, David.

Miwa Fujii: There is a comment reply from Yi Chu, Sprint, via Jabber chat, as a comment to Philip's reply to his comment: "Yes, but he does not answer the question. Prop-088 limits and slows down the run rate significantly compared to prop-092. I just want to point this out to the community, that what they get into with prop-088."

Jonny Martin: I just wanted to read out a small part from RFC 2050. That's the Internet Registry IP Allocation Guidelines. It states: "A registry's job is not to distribute but conserve," and under conservation, its says "fair description of globally unique Internet address space according to the operational needs of the end users and Internet service providers operating networks using this address space, prevention of stockpiling in order to maximise the lifetime of the Internet address space." I'll leave it at that.

Gaurab Raj Upadhaya: I think we'll call for consensus now, unless --

Masato Yamanishi: I had a comment for Jabber's comment. In my understanding, when final /8 policy is enabled, it's already run out.

Gaurab Raj Upadhaya: Thank you very much. We'll do a call for consensus now, to see, you know, we've had discussions and fairly distributed comments.

We'll have to do this in two stages.

As I said, both the policies can't pass, so that is the bottom line here, but we'll have to gain consensus on -- as I said earlier, both the policies can't pass, but both of them can fail. So making it clear to you.

So we'll go through this. Those of you who support prop-088, please show your support by raising your hand.

Thank you very much.

Those of you who do not support prop-088. Jabber. Do not support prop-088. Thank you very much.

Those of you who support prop-092.

Those of you who oppose prop-092.

Thank you. So we sort of gauge that there's not enough support for prop-092, so we are going to drop the proposal. I hope that it's OK.

But at the same time, we didn't see a very clear consensus on prop-088. So now that prop-092 is dropped, can we do a, you know, show of consensus for and against prop-088?

I'm following procedures here. So those of you who support prop-088, now that there is no longer a contention with prop-092, please raise your hands.

Thank you.

Those of you who still oppose prop-088, while prop-092 is no longer in contention, please raise their hands.

Thank you. I think we do have consensus here, that prop-088 should pass. Thank you very much.

Now I would like to invite David again to present prop-091.

David Woodgate: Now the obvious question is that given prop-088 has passed, does that sort of effectively supersede prop-091 anyway? I think I should probably potentially withdraw prop-091 on that basis.

Gaurab Raj Upadhaya: That's up to you, if you feel so, then that's OK.

David Woodgate: Thank you.

Gaurab Raj Upadhaya: You can make a statement.

David Woodgate: Just very briefly, then, so the principle behind prop-091 was that the current rate of growth of APNIC account holders seems to be such that a final /8 won't be consumed for 20 years or more, at least 20 years, and even a /9 won't be consumed for 10 years, so why not cut back to the /9?

Given the impressions I have just received from the room and given the passage of prop-088 which could, in theory, negate prop-091, I think I'll withdraw prop-091.

Thank you very much.

Gaurab Raj Upadhaya: Thank you, David. Thank you for your proposals and thank you for your participation.

APPLAUSE

Gaurab Raj Upadhaya: Next, I will go into discussion on prop-093, "Reducing the minimum delegation size for the final /8 policy".

Procedure-wise, both my co-chairs happen to be co-authors of the proposal, so they are stepping down. I'm not telling them to go away.

Philip Smith: Thanks, Gaurab. So prop-093 is another proposal really just to tidy up the final details of the final /8 policy that we missed out the first time around a couple of years back.

As you see, co-authors there, Randy, Andy and Terence, I will do the speaking on all our behalfs.

The proposal here is really to change the minimum size of v4 delegations to a /24 when the /8 policy is activated.

If we look at the current problems, current final /8 policy requires that networks have to meet the minimum requirement -- meet requirements for minimum allocation size currently in place.

In other words, to justify a /22, you have to demonstrate a need, an immediate need for a /24 and you have to provide a detailed plan for use of /23 within a year.

The problem is this prevents small networks that are multihomed or operating critical infrastructure or connecting to exchange points or running v6 transition tools such as NAT64 from actually justifying a need for v4 addresses from the final /8.

That was a bit of an oversight from the first time around.

Situation in other RIRs, we don't know of any similar policy or proposal in other regions.

The details are that we would propose to set the minimum delegation size to be a /24, so the smallest amount of address space an organization could get would be a /24. The maximum delegation size remains at a /22. The most that any organization could get under this policy proposal is still a /22.

Delegations under the final /8 policy are being extended to include small multihoming assignments, Internet Exchange Points, critical infrastructure and any other entity that could not justify a /22.

Advantages, proposal allows a greater range of networks to access resources in the final /8. And it extends the maximum possible number of networks benefitting from the final /8 from around 16,000 to 65,000.

That widens the assistance available to networks making the transition from v4 to v6 over the coming years.

Disadvantages, we don't foresee any disadvantage of this proposal.

Impact on APNIC Members and on NIRs, it does impact all APNIC Members, it does no direct impact on NIRs themselves, but it impacts the members of NIRs in the same way as it impacts APNIC Members.

That's the proposal.

Gaurab Raj Upadhaya: Thank you, Philip. Discussions on this?

Actually, given that we have time, I'll request, this is a note on procedure, author of prop-094 to be ready for discussion.

Yes, I don't know who got there first.

Paul Vixie: Speaking as Chairman and Chief Scientist ISC, APNIC Member.

I have a question about the proposal. Randy pointed out that the last /8 allocation regime that is currently in force is a once in a lifetime.

Speaking now as the operator of F root, where we actually consume critical infrastructure /24s for our F root nodes, I would like to ask, is there a provision in this proposal for allowing critical infrastructure applicants to be more than once in a lifetime for that /24?

Philip Smith: It permits up to a total of a /22 for one organization.

David Woodgate: Question, Philip. Does the proposal assume the current utilization requirements continue to be met for the /24s? That there needs to be demonstrated an 80 per cent utilization of the /24?

Philip Smith: That's the intention. What would that be?

David Woodgate: Sorry?

Philip Smith: Yes, the utilization of a /24, indeed.

Izumi Okutani: OK we generally support this proposal, we think it allows more flexibility in distributing the last /8 space and just as a clarification question, if there is an ISP that can immediately justify for the needs for a /22, then can they get a contiguous /22 at once or do they have to receive a /24 first and then come up for subsequent allocation?

Philip Smith: I would venture that that might be a Secretariat operational thing and if they have a /22 that's contiguous, I'm sure they would be able to hand it out, but if they don't have anything remaining in the final /8 pool, it is contiguous /22, then it would have to be pieces.

Izumi Okutani: Sure, but there is a possibility and that's left up to the Secretariat?

Philip Smith: Absolutely.

Izumi Okutani: OK. Thank you.

David Woodgate: One disadvantage you didn't list was the potential for fragmentation of the global routing tables, with respect to increased numbers of /24s appearing in different paths.

That's probably the aspect which most concerns me about this policy, I certainly support the other two principles of critical infrastructure and Internet exchanges. It's only the multihoming that makes me stop and think a bit.

Philip Smith: I think that's a fair comment. I mean, those of you who know me, know I'm quite a strong advocate of as much aggregation as possible, but the routing system today, even before we have run into the final /8, is sitting at 180,000-plus /24s. Not using that as a justification for /24 here, but just pointing out that if the industry really is worried about /24s, we should have done something about it well before now.

Randy Bush: As I said earlier, I'm resigned to it. I'd buy Cisco stock if it wasn't doing so badly.

There were words sprinkled in here like allocation and delegation, et cetera, and I'm just a poor old hippy and all these, you know, allocation versus whatever it is, versus whatever it is, that's gone, you get a /24 it's pink, you like pink, that's it.

Philip Smith: Exactly. No discussion, arguments, disagreements, interpretation, but whether it is an allocation or assignment, it is delegation, you get that, done.

Randy Bush: Give it to your grandmother, eat it for lunch.

Gaurab Raj Upadhaya: Thank you for this. I think we'll put it for consensus vote now.

So I'm calling for consensus vote for prop-093, "Reducing the minimum delegation size for the final /8 policy".

Those of you who support this policy, please raise your hands.

Thank you.

Those of you who oppose this policy.

Thank you.

This policy has reached consensus. Thank you to the authors.

Now I would like to ask author of prop-094, Izumi and one of my co-chairs, Terence, is still a co-author of the proposal.

Izumi Okutani: Good afternoon. My name is Izumi Okutani. I'm from JPNIC and I'm making this proposal on behalf of my co-author, Terence Zhang, from CNNIC, so this is a joint proposal from JPNIC and CNNIC.

As a brief introduction, I have realized that we're not getting a lot of support for this proposal on the mailing list at the moment and, I mean, if that's what the community feels, that's certainly fair enough.

But we would like to share the implication of keeping the re-numbering requirement in the initial allocation criteria after the final /8 and after understanding this implications and the community still feels that we don't need to make this change, that's certainly fair enough, but we would like to make sure that we make a conscious and explicit decision that we would like to keep the re-numbering criteria.

Just to share our understanding of the last /8 block, we understand that this should be, in principle, used to enable IPv4 and IPv6 dual stack environment to help with the transition to IPv6 or any other interim measures to face v4 address pool run out.

So it's not intended to expand, to be used to expand the existing IPv4 service. Based on this intention of this block to be used, this is again a revision of the current policy and who are eligible now and what would be the criteria? So new LIRs are eligible to receive a single IPv4 block of minimum size if they immediate the initial allocation criteria.

Also, existing LIRs are able to receive the the v4 block of the same size if they meet subsequent allocation criteria.

The issue we feel is the initial allocation criteria. Just to introduce what we have at the moment, to receive the initial allocation, the criteria (a) to (c) is basically justifying and demonstrating the need for this address block, so they have to demonstrate that they actually use the /24 immediately and use /23 within a year.

We don't have an issue about that.

What we would like to share is criteria (d). It says that once LIR receive initial allocation, then the new LIR must commit to re-numbering into the allocated block within one year.

Our understanding of this criteria is the purpose is aggregation, so instead of having this new LIR having assignments, with assigned IPv4 address block from upstream and also allocation directly from APNIC, it doesn't really help with the aggregation.

So that's why the criteria is here to make sure the only block that the new LIR holds will be the allocated block from APNIC and it will not have any assignment from its previous upstream.

So the purpose is aggregation and not reclamation of existing LIRs' holding, why we have the re-numbering criteria.

Let's look at how this will change before and after the final /8 phase.

Before the final /8 phase, APNIC is able to compensate for the v4 assignment that the existing LIR is receiving from its upstream, in addition to their additional needs. For example, if a new LIR applies for -- currently holds, for example, /21 from its upstream, and then requesting for initial allocation, then APNIC is able to supplement for the existing v4 assignment when APNIC makes allocation to this new LIR.

But after the final /8 phase, the allocation size from APNIC will be fixed to /22 at the maximum, so APNIC can no longer compensate for v4 assignment that the existing LIR used to receive from the upstream.

So if we keep this re-numbering practice, it will actually mean that reclamation of a new LIR's v4 address holding used for its existing network and this will actually affect over 95 per cent of new LIRs, because there aren't hardly any LIRs that has no IPv4 space at all when they apply for allocation, well at least to JPNIC.

I show this diagram to maybe help people understand the situation a little bit better.

Suppose that for existing v4 network, this new LIR has been receiving IPv4 assignments from its upstream and now they would like to build this additional part of their network for translation purpose, for connection with IPv6. They would require additional IPv4 space for this purpose.

So they apply for the final /8 allocation to APNIC and then once they receive the final /8 allocation from APNIC, they must return this address space that they have been receiving, to its upstream LIR, so they will no longer have v4 space that they can use for the existing v4 network.

So this is the issue that we would like to share.

This is a summary of what happens to each case.

There are three types of targets. One is new LIR with no IPv4 at the moment. For such LIRs, they can build new network based on IPv6 and then for the translation purpose, they can receive the v4 block from the last /8 and they don't need to re-number what they use for the new network, because there's no re-numbering requirement for v6 allocations, in order to receive the last /8.

Now, for the new LIR that that received IPv4 from the upstream, as I mentioned, this applies to over 95 per cent of new LIRs.

They must return the existing v4 assignment that they have receiving from its upstream in order to receive v4, from the last /8, to use it for the translation to build the translation network and for the existing LIRs, they can receive additional IPv4 block from the last /8 for the translation purpose and they can keep the existing v4 allocation, because no re-numbering criteria is there to receive subsequent allocations.

So that's the overview of the situation, in general.

To summarize what the issues we might have, is if we keep the re-numbering requirement initial allocation after the final /8, it will, in practice, mean a reclamation of a new LIR's IPv4 address holdings for existing network to receive necessary v4 block for v6/v4 translation, so that's the issue that we're concerned about.

It will also affect over 95 per cent of new LIRs.

The third point is it would be difficult to provide a rational reason why existing LIRs are allowed to keep their past allocations, but not the new LIRs.

In order to address the issues that we have listed, the proposed change in prop-094 is to keep the justification requirement as it is in the current allocation criteria, but not make the re-numbering criteria a must. So provide an alternative option to the re-numbering criteria, that they if they can demonstrate 80 per cent usage of the past allocation, then re-numbering is not required.

The reason for this 80 per cent is that it's consistent with the percentage utilization required in subsequent allocations.

So this is just to give you an idea of what the policy might look like when we implement this policy. So the justification part in criteria (a) to (b) remains the same. So a new LIR must still justify their need to receive the last /8 block.

But in addition to the current re-numbering requirement, there's an alternative option that if they can demonstrate the need that 80 per cent of their past v4 space has been used, then they don't necessarily have to re-number the existing assignment.

And that's basically the idea mind our proposal and as an additional note, supposing that there's no strong community support for this idea, if that's the case, it's fair enough. I but we feel that it's important we share the consequences of receiving the last /8 block as a new LIR when applying for initial allocation.

So it's important that APNIC notifies the applicant that when they apply for the last /8 block, they must return the existing v4 space holdings to its upstream LIR and they know they agree with this condition when receiving the last /8 block.

That's just an overview of our presentation.

Gaurab Raj Upadhaya: Thank you. Now we'll open the floor for discussion.

Pindar Wong: Sorry for not knowing the full background and thank you for the brief.

Can you bring up your proposed text of how you might understand that? Two clarifying questions.

In fact, maybe only one clarifying question. Is the reason or the motivation behind this proposal basically to introduce an element of flexibility, given that flexibility doesn't quite exist as you've indicated in the old text? Is that the primary reason?

Izumi Okutani: No, not quite. We are concerned that under the current policy, before the last /8 phase, the existing -- when LIR receives more v4 allocation, they get to -- well, they must re-number, but they don't have to have the v4 address space that they have been using for existing network reclaimed, because it will be substituted by additional allocation from APNIC. So they can still keep the v4 space they need for the existing network.

But once we get to the final /8 phase, because of the re-numbering requirement remains, so they must return this v4 space they're using for this existing network. We think that this would be a concern and cause problems for a new LIR to apply for the final /8 block.

Pindar Wong: so you think it's going to generate more problems for the new LIR.

Izumi Okutani: Yes.

Pindar Wong:: Equally, you are raising this to the community's attention and you want whatever decision the decision to be a conscious one. Do I understand that clearly?

Izumi Okutani: Yes. Thank you for stating it more clearly.

Randy Bush: First, I think possibly for some people, a clarification would be helpful.

I think -- and correct me -- what you mean by a new LIR is an entity who already exists and has a running network, they just have IP space from an upstream provider and they are now going to go get directly from. It's not that they're new, it's that their LIR-ness is new. OK.

Izumi Okutani: That's right.

Randy Bush: I'm having a problem in that asking them to return it all I think has built into it the assumption that the space they are -- it has an assumption brought from traditional more open allocation, that what they are going to get is the same size or bigger than what they have today.

Izumi Okutani: Exactly.

Randy Bush: And it's not going to be.

Izumi Okutani: Exactly.

Randy Bush: It's going to be significantly smaller.

So why not just remove the re-numbering entirely?

Izumi Okutani: So not even add any alternative criteria at all?

Randy Bush: You know, I'm getting a 24, I had a 20 or a 21, I'm going to re-number what?

Izumi Okutani: OK. I mean, if Terence is happy with this change --

Randy Bush: I mean, I don't understand what segment of the market is really going to be addressed here? Because you're going to get a little and you probably had more than that. You can't re-number.

Izumi Okutani: Exactly.

Mark Newton: Randy actually approached the same issue that I was going to approach. You touched on it very briefly when you said that some of these new LIRs might already have a /21 and I'm thinking, well, at most, they can get a /22 out of the final /8.

Do you have any data on how many new LIRs are in a situation where the amount of address space they already have from their upstream is larger than the amount of address space they can conceivably get out of the final /8, how many impossible re-numberings there are under the current policy?

Izumi Okutani: I haven't done any analysis, we just know that it would affect over 90 per cent of the new applicants, but I haven't done the case where the address space they will be receiving from APNIC will be smaller than the address space they have returned. I haven't done any analysis on that.

Mark Newton: Ok, we'll support the proposal and just make the note that things have already stacked up against new entrants badly enough in a post exhaustion world. I don't think we need this additional obstacle as well. Thank you.

Izumi Okutani: Thank you.

Sheng-Wei Kuo: Izumi, I have a question. When LIR requests IPv4 addresses for this critical, does the LIR need to provide evidence of IPv6 deployment?

Izumi Okutani: That's not included as a part of this proposal, no, because that's not a part of the criteria for the current /8 block.

Randy Bush: My apologies. Randy Bush, yet again.

Is there anybody here who would support this proposal that would object to liberalizing this proposal further to remove the re-numbering requirement entirely?

Gaurab Raj Upadhaya: We can do that. Thanks for the suggestion.

Randy Bush: To repeat, I'm saying if you like this idea at all, you know, this says remove the re-numbering requirement for some people. I'm saying do you mind removing it for all people getting from the /8, because they're going to be getting a 24 and they had a 21, they can't fracking re-number. I'm saying does anybody really care about further relaxing this proposal?

Randy Whitney: I think I support that, but I would like to see it written up.

Randy Bush: Well, this is APNIC. We do it a little differently.

Gaurab Raj Upadhaya: I think this is a good discussion. I would suggest to the authors that if they can rewrite or present the text again tomorrow, you have time today, tomorrow morning, then we can revisit this for consensus. I think that's what we should do.

What we have just discussed with Izumi is the authors are open to re-submit text that we can, you know, view tomorrow morning when we are back at the Policy SIG. Is there general agreement on this topic, that we'll call the final call for consensus after we see revised text? Can I get a show of hands for that?

We are proposing -- let me rephrase this -- we are proposing that, you know, we remove all requirements from receiving the /22, from the final /8. The current proposal just removes the requirement to re-number, but the proposal has been that we remove all requirements all together.

Liberalize the policy. So we wait --

Randy Bush: I just merely suggested we remove all the re-numbering.

Izumi Okutani: Criteria (d), right?

Gaurab Raj Upadhaya: Yes. All re-numbering requirements, so we'll revisit the text tomorrow morning.

Can I get a show of hands, that we agree to that?

Thank you.

Anyone opposed to this idea?

Thank you very much. I think we'll end for the day. We'll revisit this proposal, as well as other proposals in the morning, tomorrow morning.

You can still make it to the 5.30 bus, to go to the social event.

Thank you very much.

Policy SIG.
09:00 am.
Thursday, 24 February 2011.
Hall B&C.

Gaurab Raj Upadhaya: Good morning, ladies and gentlemen. We'll begin in about 10 minutes more, because we have remote participants today and we are trying to test that set up.

So still another 10 minutes for you to go and get your coffee, wherever it is.

Good morning, ladies and gentlemen. I think we'll start now, so you can take your seats.

Welcome back. We'll start from yesterday's proposal. We asked the authors to come up with alternative text on the proposal and so it's here.

I'm talking about these two proposals here, prop-094. So I would like to ask Izumi to come and present her alternative text for prop-094.

Izumi Okutani: Good morning, this is Izumi from JPNIC. Yesterday, for prop-094, we discussed that from the initial out -- the current initial allocation criteria, we should remove the part that mentions about re-numbering, so I'd like to first show what it actually says in the current policy.

So there are criteria (a) to (d) under the current criteria and criteria (d) mentions: "Commit to re-number from previously deployed space into the new address space within one year." This is the part that we discussed that we should remove and our suggested change would be we do keep the criteria (d) as it is, but it simply adds the clause that criteria (d) is removed for initial allocation once we move into the last /8 phase, which actually specifically says, under 9.10, "Distribution of the final /8 worth of space in the unallocated APNIC IPv4 address pool." So if it makes sense to everyone.

Gaurab Raj Upadhaya: Yes. Thank you, Izumi.

We'll do a call for consensus now on this, because we had the discussions yesterday and we asked Izumi to come up with a slightly better text.

I'm going to ask those of you who support that we adopt this policy, please raise your hands now.

Thank you.

Those of you who think there is no consensus and do not support this proposal, raise your hands now.

Thank you very much.

There is consensus on accepting prop-094, as a policy proposal. Thank you to the authors. Thank you very much.

Izumi Okutani: Thank you.

Gaurab Raj Upadhaya: We still have one policy proposal under the last final /8 amendments, prop-089, but we are not able to track the author down, for remote presentation or otherwise.

So if anyone has seen David Woodhouse, not Woodgate, here in the conference hall or knows how to get to him on the phone or email or otherwise, let Sunny know and we'll try to touch this proposal again later in the day, if we can get in touch with the proposer. So we'll leave this pending.

Next, Terence can come back.

If you are following the website, then the next proposals in the queue are the global policy proposal -086 and -097, but we have remote presentations for at least one of them and they're on a fixed schedule, so we can't move it ahead. So instead, I have put the two IPv4 transfer policy amendments for this morning's session and the two policies we have here are prop-095, Inter-RIR IPv4 transfer proposal. Basically, it adds an amendment to the existing APNIC transfer policy.

Then there is prop-096, which insists that there must be a demonstrated need requirement in transfer policy after the final /8 phase.

So I would like to request the author, Tomohiro-san, to come and present prop-095 first and then we'll go to prop-096 after that.

Tomohiro Fujisaki: Thank you. Good morning, everyone. I'm Tomohiro Fujisaki and today I propose two things. One is inter-RIR IPv4 address policy and the other is keeping the demonstration needs for the transfer policy.

Actually, I think these two policies pair and if we will have the inter-RIR transfer policy, we should have maintain the demonstration needs requirement in current IPv4 policy and if we need not inter-RIR transfer policy, I think we need not demonstration needs for transfer policy.

Anyway, let's start from the prop-095. This is introduction and I propose to define mechanism for inter-RIR transfer policy. That is, between APNIC account holder and the organizations in other regions.

This is current problem and I think the current APNIC transfer policy is allow to transfer only in the APNIC region and I think to achieve one goal of transfer policy, that is efficient use of IPv4 address space and inter-RIR transfer policy should allowed.

So I propose the inter-RIR transfer policy. This is premise of our policy and of course, in this policy, both APNIC and the counterpart RIR should have the transfer policy and allow the transfer each other.

This is the proposed policy. The basic idea is the transfer should satisfy the source RIR's transfer policy. For example, if APNIC account holder want to receive address space from other RIRs, the APNIC account holder should satisfy the source RIR's transfer policy.

If APNIC account holder want to give their address to other RIR, the recipient has to satisfy the transfer policy of APNIC. This is the idea of our transfer policy.

This is the situation in other RIRs. And currently, as far as I know, only ARIN is discussing the inter-RIR transfer policy. They have draft policy like this and stated in this policy, two RIRs agree to transfer it and from a point that RIRs should have the policy based on the RFC 2050. This is ARIN's current draft policy.

This is benefit and disadvantages. Of course, I think the advantage is this policy make the use of IPv4 address space more efficiently.

Disadvantage is the current policy I propose is sometimes confusion, because the APNIC account holder should satisfy the counterpart RIR's policy.

So I think this is a real bit of confusion point.

And about the implementation, we change, if this policy accepted, we should change the APNIC transfer policy and we need to negotiate with other RIRs.

For NIRs, NIRs can select to implement this policy or not.

OK. We got several comments on the mailing list and this is concern that suggested on the mailing list by Owen and maybe Randy advised us is the same condition. In this condition, the participant of the transfer has to satisfy the condition of their region.

Actually, we define the condition in the source RIR have to be satisfied, but this suggest that conditions of each RIR should be satisfied. Yes, that is the difference.

OK. This is summary and I propose inter-RIR transfer policy and I think we should allow inter-RIR transfer policy to utilize IPv4 address space.

This is the end of my presentation.

Gaurab Raj Upadhaya: Thank you Fujisaki-san. The floor is open for support, not support, questions and comments.

Randy Bush: Fujisaki-san, which are you suggesting? What is the proposal?

Tomohiro Fujisaki: Actually, kind of proposal we say is this condition, the counterpart, source of the RIRs, yeah.

Randy Bush: So this is the original proposal?

Tomohiro Fujisaki: Yes. Actually we want to satisfy this condition of the counterpart RIRs.

Randy Bush: I don't support it.

To be clear, I don't see why I would apply the source's policy on who can receive to the recipient.

It's the reverse that makes sense to me. In other words, the sender has a sending policy and the receiver has a receiving policy.

Tomohiro Fujisaki: Yes.

Randy Bush: But I already said that on the mailing list.

Tomohiro Fujisaki: Yes, I know that.

David Woodgate: Do I understand correctly that you're proposing actually transferring the inetnum objects from one registry to another as part of this?

Tomohiro Fujisaki: Yes, exactly.

David Woodgate: I would have concerns about the complications in the management of the registries in doing so.

John Curran: I have no view on the policy proposal. I have a question just to make sure I understand it.

This diagram says conditions defined by the policy of the counterpart RIR will apply when the source is in another RIR.

Tomohiro Fujisaki: Yes.

John Curran: It's conditions that are going to be applied from the other RIR policy, both on the source and the recipient. So because the source is another RIR, you want to apply their policy on the recipient in the APNIC region? That's what this diagram says.

Tomohiro Fujisaki: Yeah.

John Curran: OK. That's what I just want to understand. And the counterpart would be when the source is in the APNIC region, your policies would apply and would apply to the recipient in another region.

Tomohiro Fujisaki: Yep.

John Curran: But in theory, there could be other requirements on that recipient by their RIR as well.

Tomohiro Fujisaki: Yes, yes.

John Curran: So to some extent, this says both policies apply.

No? OK, I missed that.

Randy Bush: That's the problem.

John Curran: That's my question. So in the case below, if the source is in APNIC, you're going to apply APNIC's policy for both source and recipient?

Tomohiro Fujisaki: Yes, I accept that.

Randy Bush: And the receiver could be trying to receive something under conditions from the source RIR that violate the policies.

John Curran: Right, I understand.

Randy Bush: Under which the receiver must operate.

John Curran: So that's what I said, yes.

Randy Bush: So that's why I can't support it, because it's going to say that if APNIC says that I cannot receive something unless it's blue and he sends orange ...

John Curran: So my interpretation is that it's possible that a recipient would have to meet the policies of his RIR and APNIC's policies, both.

Tomohiro Fujisaki: Sorry? Pardon?

John Curran: A recipient in another region would have to meet APNIC's policies, because that's the source, and would have to meet his own RIR policies, obviously, because that RIR has to concur.

Tomohiro Fujisaki: Yeah.

John Curran: That's all. I was checking for clarity. I have no view on the policy either way, but I just wanted to make sure I know, because we might be on the other side of one of them.

Izumi Okutani: Again, I'm also neutral about this proposal itself, but I have a question to ARIN.

I think there was a concern raised in ARIN region about having inter-RIR transfer policy within APNIC region, because we don't have criteria in place that requests for justification.

If this proposal is passed under the criteria that's being proposed as it is, would this meet the concerns of the ARIN region or do you still feel that it still remains some concerns? I'm interested to know if transfer with ARIN would be possible under the criteria that's been proposed.

John Curran: As I read this, if the ARIN was the source, if I read this policy as I see it, then APNIC would be applying ARIN's criteria to the recipient in the APNIC region. If that's the case, I can't imagine any RIR that would object to its policy being applied in another region, so it would have to, unless ARIN passed a policy that it wouldn't recognize another RIR using.

So the answer would be, this has effectively both RIR policies applying on a transfer. It may say the source, but the recipient is subject to their RIR and the source's RIR. This would certainly be compatible. There's another policy proposal that would also address it.

Seichi Kawamura: I'm kind of reading in between the lines. I have talked to Tomohiro Fujisaki in Japanese, in our local language.

What I think you wanted to write was what the source can transfer, like the size or, you know, the eligibility of the transfer should be determined by the source and what the receiving side can receive should be determined by the source and maybe you wanted APNIC to be able to receive anything that comes into the region.

Is that what you wanted to write? Because it's not written that way, but, you know.

Tomohiro Fujisaki: Yes. Maybe that's a point I want to propose, yeah.

Seichi Kawamura: But it's not written that way.

David Woodgate: I do support the concept of at some stage being able to extend transfers into an inter-RIR context, but I must admit that judging by the kind of discussions we have heard here this morning plus my concerns about inter-registry transfers of address objects, I probably can't support this policy as it stands.

Randy Bush: Transferring a bunch of little textual objects is something we leave for programmers in the RIRs. Don't give it to them. It's the address base that's the issue, not some -- some RIRs don't even have inetnums, like ARIN, for instance.

Fujisaki-san, what I said on the mailing list and what this proposal proposes seems to be the reverse, right? So we're close to it. Actually, what I think this says is that the source RIR, those rules for sending and for receiving must be met, right? All at the source.

Izumi Okutani: Can I interrupt?

Randy Bush: Please, please.

Izumi Okutani: I think Fujisaki-san's intention, according to what I spoke to him, is a little bit different. So please correct me, Fujisaki-san, if I'm wrong.

I think your intention is that the receiving RIR should have two standards, because the conditions of the source RIR would apply in case of inter-RIR policy. For example, in case of transfer between APNIC and ARIN, and APNIC keeps current criteria, in case transfer happens from APNIC region to ARIN region, then ARIN region recipient doesn't need to have justification to receive address space from APNIC.

Is that what you're proposing?

Tomohiro Fujisaki: Yes, yes, yes.

Gaurab Raj Upadhaya: I think I have some feedback that the text on the screen didn't match the picture, so you can read the actual text on the screen now.

Randy Bush: Right, but unfortunately, I don't understand the meaning of counterpart. I understand the English meaning of it, but since this neither says who the source or the destination is, the word "counterpart" is not associated with any RIR. Does counterpart mean the source or the destination?

Izumi Okutani: I think this means whoever APNIC is doing the transfer with. So if APNIC is being the source, then the counterpart would be the recipient and vice versa.

Gaurab Raj Upadhaya: Is that your meaning, Fujisaki-san, what Izumi just says?

Tomohiro Fujisaki: Yes, yes.

Gaurab Raj Upadhaya: I hope that clears that up, that counterpart means whoever is on the other side of the transfer.

Randy Bush: As I said, I understood the meaning of the word "counterpart". Right? But if I'm the source, the counterpart is the destination. If I'm the destination, the counterpart is the source. So when it says the conditions defined by the active policy of the counterpart, I do not know whether that's referring to the source or the destination.

John points out that the first line of 5.2 says this is transferred to APNIC, so "counterpart" therefore means the source.

Thank you.

George Michaelson: I have a comment from the Jabber chatroom. This is Yu Chi saying: "I oppose the proposal, because we do not understand policies from other RIRs. It is premature to establish inter-RIR when no transfer policies have been defined yet."

Dean Pemberton: I think we're getting some good clarification on this from the floor and the podium, but it sounds to me like the clarification we've got needs to go back and be a rewrite and come back with a little bit of that clarity actually in the proposal. Thank you.

Pavan Duggal: Quick question. I see a lot of legal and policy issues. Are you talking about the authentic holder of the source must match with the source without any disputes? How is disputes defines as? Who will adjudicate the disputes? How do you determine the jurisdiction of each RIR? How will the jurisdiction of each RIR be implemented?

Who will be the arbitral body or authority that will help adjudicate these disputes, given the fact that, to date, at the time we are talking, there is no one compendium of policies specifically related to this which have been complied with in all its letter and spirit by all the RIRs. I wanted a clarification.

Thank you.

Gaurab Raj Upadhaya: I can clarify that. I think I can clarify that.

There are relevant RFCs that cover all the aspects of things that you have just asked. You know, the working regions for each of the RIRs, plus how to, you know, educate who is the resource holder. There is a registry that maintains who is the current user and, as Fujisaki-san's proposal says, the authentic holder. So I think those things are not, you know, questionable, as far as I can see.

If you need references to the relevant RFCs that define the procedures, then I will need to dig it up.

Randy Bush: We have been doing business for a number of decades. This all does work. If you want to throw it all up in the air or re-understand it, this is not the forum.

Gaurab Raj Upadhaya: Thank you, Randy.

Any other comments or questions or if I understand correctly, what Dean said was that proposer rewrite of the text to make it a bit clearer. Is there any opinions on whether we should discuss what the rewrite should be or we let it -- send it back to the mailing list and expect that we'll get more feedback on the mailing list on the text itself?

Tomohiro Fujisaki: Actually, currently we propose this type of condition, but --

Geoff Huston: Can I just offer you a friendly suggestion here, since I was involved in these transfer policies some years ago. You might drop the word "counterpart" and use the words "source" and "recipient" when you try and describe each of the parties, so that it's very clear to whom you are referring.

Tomohiro Fujisaki: Thank you.

Pavan Duggal: Quick question which is if you are going for a rewrite, which is good because one can give more suggestions to this, because I distinctly see that while this is technical, the fact still remains that there are going to be issues, considering that there are RFCs, at best, defined standards. However, when we talk of implementation of policies, we are talking of real life mechanisms, which currently do not exist.

In the absence of such mechanisms, how will this kind of a policy pan out in implementation is an issue that will have to be discussed. Thank you.

Randy Bush: Can I steal it? We already do inter-RIR transfers.

Get over it. We actually know how to do our business. Get over it.

Izumi Okutani: My comment is not about the content, but how we should proceed. So if you have comments about the contents of the proposal, please go ahead.

John Curran: My issue is not about the policy proposal, but about the questions raised about the lack of mechanisms for inter-RIR cooperation.

Gaurab Raj Upadhaya: John will be the last one to comment on this and then we'll take it offline.

John Curran: With regards to the prior comments, regarding the cooperation of the RIRs, the RIRs actually cooperate through the Number Resource Organization, the Number Resource Organization includes an MoU, the MoU specifically defines a dispute process for when RIRs have a problem managing something like this. We have worked successfully for so many years we have never had to use it, but the mechanisms do exist and all of them have been signed off and countersigned by ICANN, so we actually have a very nice robust structure that we don't have to use because we work together so well.

Gaurab Raj Upadhaya: If what you said is correct, then I think the NRO has not done enough to spread the word out, despite having booths at different places. Maybe a bit more PR on the NRO side might be useful there.

Izumi Okutani: May I suggest the chair to ask the feeling on the floor if people support the concept of inter-RIR transfer itself, but have issues with the particular criteria that's been suggested? If that's the case, how can we proceed in the future about the modifications for the criteria?

Tomohiro Fujisaki: Thank you, Izumi-san. I really want to know which concern with -- actually, inter-RIR transfer policy, everyone needs inter-RIR transfer policy and the condition, which condition should be applied. I want to know.

Gaurab Raj Upadhaya: I think I agree with Izumi and the chairs also thought maybe we need to get the feedback from the audience here, whether in concept, the concept of inter-RIR transfer is supportable, as a policy. Then I think we need to send the policy back to the mailing list, to get the specifics of it correct.

Tomohiro Fujisaki: Yeah.

Gaurab Raj Upadhaya: Randy, you have something to say?

Randy Bush: Or possibly even faster is if people agree that we need a policy now, just a quick hands.

These two policies that you see of the two diagrams are really the two basic possibilities and I think you could come back later today with a re-word, if you need it.

Gaurab Raj Upadhaya: We can talk about that. So let's do a show of hands -

Masato Yamanishi: Actually, I have not thought yet about what is the solution which is proposed by Fujisaki-san. Thanks.

Gaurab Raj Upadhaya: Maybe what we can ask others is, if you think there needs to be an inter-RIR transfer policy and you agree in concept with this, and think that it needs some more re-word, please raise your hands. I'm just trying to gauge whether this is worth discussing.

Thank you.

Those of you who are strongly against this concept.

OK. Thank you very much.

That at least solves one issue.

Next question to help Fujisaki-san re-write the proposal is whom of you think that when there is a transfer, the policies of both the RIRs should apply? I'm just trying to help Fujisaki-san.

Yes, Randy.

Randy Bush: Might I suggest that that's not the exact productive path you could follow. Because the likelihood of satisfying, in the current political environment, the rules of both RIRs is very small.

Gaurab Raj Upadhaya: Yes, that's what I was trying to gauge from the audience.

Randy Bush: And that's why the mailing list suggestion separated the source from the destination.

Gaurab Raj Upadhaya: Is that your reading, Fujisaki-san? Is that what Randy just commented, is that your reading?

Randy Bush:His diagram, what he is showing, is exactly correct.

Gaurab Raj Upadhaya: This one here.

Randy Bush: Source meets source criteria.

Destination meets destination criteria. Right?

What that eliminates is the destination having to meet the destination criteria of the source.

Gaurab Raj Upadhaya: Yes, I agree.

John Curran: I have no view on this particular policy proposal, but two comments that might be worth thinking about on how to make progress.

The first one is the question you asked regarding applying the policies of effectively both RIRs, operationally, I think about the role that ARIN would have to do in doing that and it could be interesting, because there may not be counterparts to our terms and policies in the organization in another region.

An example, a national registry structure exists in APNIC and doesn't exist in the ARIN region. So applying policies of both regions will probably be more difficult. I'm not saying that -- ARIN will do whatever the community says to do. OK, we'll do it.

But it will require more interpretation if you have both policies and that's worth people thinking about, because in some cases, we have very different structures.

The second item I would like to point out is there is another policy proposal regarding transfers that doesn't been discussed and the answers to these questions on how the floor feels may change at the end of the next discussion. That's just something worth thinking about.

Gaurab Raj Upadhaya: I just conferred with the author and I think he feels that if the comments and feedbacks are sent to the mailing list, because the policy will go back to the mailing list for discussion. He would appreciate that better, because that gives him time to, you know, work on it properly.

You're already at the mic so you can say, but I think that will be the last one.

Dean Pemberton: Yeah, I have nothing to add.

Gaurab Raj Upadhaya: As conferred with the author, we'll send this back to the mailing list and please send your feedback and comments on the mailing list for further discussion.

Tomohiro Fujisaki: Thank you.

Gaurab Raj Upadhaya: Thank you very much.

Next we'll go to prop-096.

The two policy proposals are slightly -- well, quite related, but I still ask Fujisaki-san to do it.

Tomohiro Fujisaki: OK. Good morning again. Next, I propose "Maintaining demonstration needs in the transfer policy".

In this proposal, I propose to maintain the requirement needs in the APNIC transfer policy after the final /8 phase begins.

This is the problem I think that current APNIC transfer policy removes the requirement to demonstrate need for the transfer of IPv4 address space in the APNIC region after the final /8. I think this has a problem, that the removal of justification of need will make APNIC only RIR that has no criteria for demonstration need.

The next point is the inter-RIR transfer policy sometimes requires such kind of need. For example, in any case, we should have the demonstration need.

So I propose to maintain the demonstration needs after the APNIC reaches the final /8 block.

Actually, this is my proposal and current policy removes the requirement needs after APNIC reaches the final /8. But I propose to maintain these needs after the period.

These slides show the situation in other RIRs.

I don't introduce these in detail, but all RIRs have demonstration needs for address transfer.

This is the benefits of my proposal. It is -- actually, inter-RIR, we permit inter-RIR address transfer, we should have the demonstration needs requirement and this policy make the APNIC transfer policy equivalent to the other RIRs policy and this policy will remove the impact to change the policy in the future.

This is the disadvantages, I think, that actually, we got some comment on the mailing list, that this justification is not necessary and it might be a barrier to accurate database update.

This is implementation, just remove the requirement for -- just remove the conditions for after /8 allocation measures.

This is summary, just the same, and I propose maintain the requirement for the demonstration needs after IPv4 address, in inter-RIR IPv4 transfer policy after APNIC reaches the final /8.

OK. This is end of presentation.

Is there any questions or comments?

This is all I want to say.

John Curran: I have no view on this proposal one way or the other.

But I have to answer the same question Izumi asked earlier. If this policy proposal passes, and the counterpart currently in the ARIN region passes, then to the extent that there's a need-based transfer policy in this region, then inter-RIR transfers would be allowed, which means on the earlier policy proposal, the policy that applied to the source of the addresses could be applied by the source RIR and the policies to the recipient could be applied to the recipient RIR and you wouldn't have to apply both RIRs' policies to the recipient.

So if this passes, it may allow simplification of the earlier policy proposal and still have effective inter-RIR transfers.

I don't know if that's desirable or not, but this solves something that I think the earlier policy proposal is also trying to solve by applying both regions' policies to the recipient.

David Woodgate: So, John, you're basically trying to say that a global standard might make life easier for things?

That's not what I was going to say.

My memory of the discussions around prop-050, which introduced the transfer concepts, was that this point about not requiring the demonstrated needs for transfer purposes after exhaustion was to avoid a situation whereby a black market would arise and therefore, the point was to try to make sure that registration of transfers was simple and unencumbered.

The fear would therefore be that if we reimposed those requirements going forward, then that will just force people to do transfers without registration and there would be no way of APNIC to keep track of such activities.

Randy Bush: John, I think it's the reverse.

I think if you take the previous proposal and you take the mailing list suggestion, which is that the rules of the source RIR apply to the source and the rules of the destination RIR apply to the destination, then this doesn't cause -- you know, you can choose independently what policy we wish here in APNIC and we don't have to worry about a recipient has to justify 80 per cent in ARIN and 82 per cent in APNIC and, oh, they're only 81 per cent. What do we do?

So I am -- when I look at this proposal, I am assuming that that problem is removed. So I'm merely looking at should we apply needs criteria to people in the APNIC region receiving transfers, whether they receive it from other regions or from within the region.

I kind of like -- I can see maintaining needs justification. I'm not strongly for it, but, yeah, I can see maintaining needs requirements. I think that's perfectly reasonable.

So what I'm saying is, I guess, I kind of support this proposal, but not for all those reasons.

Right?

Tomohiro Fujisaki: I see.

Randy Bush: I'm not worried about ARIN telling us what to do. There are plenty of proposals here with ARIN telling us what to do. I'm just -- do we want justification or not? I can kind of see we want justification.

Izumi Okutani: It's fair enough that, you know, we want to discuss whether we need this criteria as APNIC region is on its own, regardless of inter-RIR policy. That's one point of view. I understand that.

But I still would like to understand the implication of not having this -- having this criteria in relation to the inter-RIR policy.

Suppose that the suggested change would apply, so for inter-RIR policy, in other words, the criteria of the source will apply to the source and the criteria of the recipient will apply to the recipient. In that case, if the address space with source ARIN will be transferred to APNIC, then is my understanding correct that APNIC region is able to receive address space from ARIN without any justification, without this proposal?

Tomohiro Fujisaki: Yes, I think, yes.

Izumi Okutani: So in that case, does that answer the concern of ARIN region, without this proposal?

John Curran: Specifically, there's a policy proposal for inter-RIR transfer being discussed in the ARIN region and I mean actively being discussed.

It's on that mailing list called PPML that if you need more mail, you should subscribe.

And there has been suggestions that that inter-RIR transfer only be done to RIRs that have need-based policy. If that's how the inter-RIR policy is adopted in the ARIN region, then this would need to be adopted in APNIC. If that isn't part of the inter-RIR transfer policy in the ARIN region, then this wouldn't have to be part in APNIC.

It's an active discussion in the ARIN region.

I expect it to be resolved around about the San Juan ARIN meeting in the middle of April.

Gaurab Raj Upadhaya: Thank you.

David Woodgate: Just commenting on what I just heard, I think I had come up to the mic to basically say that I assume that regions -- different regions would always be able to come to some arrangement on trade of addresses in the same way that countries tend to come to arrangements on trade in general.

It would be unfortunate, in my view, if ARIN did take that particular line that John just mentioned, just in terms of potentially blocking that sort of transfer just because the policies are not completely aligned.

Randy Bush: What process do I have to go through to put a proposal that recipients of transfers from APNIC where the destination is in not America, can only be blonds, males, over 40, who supply over 2 kilograms of dark chocolate?

Gaurab Raj Upadhaya: I explained the policy development process yesterday and as ex-chair, you might be very well aware of it. I'm pretty sure that proposal would pass. I, for one, would support it. Thanks, Randy.

Any more questions or suggestions or prop-096?

I think what Fujisaki-san told me earlier was, this proposal is quite dependent on prop-095 being passed and so on.

David Woodgate: Why?

Gaurab Raj Upadhaya: We were discussing that this is more -- well, that's his feeling was maybe he should not talk about it now, because there needs to be an inter-RIR transfer policy before this one goes in. But we can still go for consensus on this proposal itself. That's what I think. Is that OK with you?

Tomohiro Fujisaki: Yeah.

Gaurab Raj Upadhaya: OK. Just clarifying with the author that that is what he intended.

Dean Pemberton: I think, you know, this is more important if there's an inter-RIR policy, but I think it kind of stands by itself, so if we want to talk about this one and get consensus on this, then I think that can stand.

Gaurab Raj Upadhaya: I agree with that. That was my thinking, but just clarifying what the author thought about it.

So we'll put prop-096 as discussed just now to consensus call. Those of you who support the proposal, please indicate your support by raising your hands.

This is prop-096: "Maintaining demonstrated needs requirement in transfer policy after the final /8 phase".

Coffee break is in 30 minutes, but I think you can still raise your hands a bit higher.

Thank you.

Those of you who do not support this proposal, please raise your hands.

Thank you so much.

We have conferred and we think the proposal might need some more work. There is support, but there is also some opposition to it. It's quite difficult for us to judge whether the audience really wants to support this or not, so what we'll suggest, Fujisaki-san, is to, you know, rewrite the prop-095 and then present this again in conjunction. Since it looks like we'll have time in the afternoon, we'll probably request you to do this in the afternoon again and then come back to the Policy SIG and present it again. Is that OK?

Tomohiro Fujisaki: Yeah. It's okay, yeah.

Randy Bush: If you wish, Fujisaki-san, I will help.

Tomohiro Fujisaki: Thank you so much.

Gaurab Raj Upadhaya: Please, if you have feedback, because we do have time in the afternoon. Thanks for the very proactive audience. So we'll probably revisit both the proposals again, some time after lunch.

Anyone found any news from David Woodhouse?

No. We are ready to go for coffee break, but before we go out, I'll just give you a preview of what's waiting for us in the next session.

When we come back after coffee break, we'll have two global-- proposed global policies to consider. Both of the proposals are related to the IANA redistribution of address space now, after they have assigned everything away and then if they receive something back.

So we have prop-086, which is Global Policy for v4 Allocations after the IANA -- which the IANA Post-Exhaustion and prop-097, again, Global Policy for Post-Exhaustion IPv4 Allocation mMchanisms by the IANA. So the title is a play on words. Both of them are of similar nature.

Prop-086 is a redraft of prop-069, which was passed in the APNIC, RIPE, LACNIC, and AfriNIC regions, but failed to gain consensus in the ARIN region.

We'll have a presentation on this after the coffee break, a remote presentation. So please be here on

We have gained 20 minutes this morning. Somebody needs to tell me whether coffee break is ready or we need to do some song and dance here.

LAUGHTER.

Gaurab Raj Upadhaya: There's no coffee, but the coffee break can happen.

We'll come back at 11:00 sharp. Thank you very much.

You can take some time to visit the sponsors booth, if you have not done so yet. Freebies, T-shirts, if you need some more.

Policy SIG.
11:00 am.
Thursday, 24 February 2011.
Hall B&C.

Gaurab Raj Upadhaya: Welcome back, ladies and gentlemen.

Andy will do his co-chair role now.

Andy Linton: OK. Now you see what you voted for yesterday, see what you get.

We're going to look at these two proposals, the ones for the global policy for allocation and the first one is prop-086 and we are going to do this one over the net with WebEx and just see if we are ready to do that.

Our presenter is going to be Chris Grundemann.

Are you with us, Chris?

Chris Grundemann: Yes, I'm here. Thank you.

Andy Linton: OK. So over to you.

Chris Grundemann: Great. Thanks. I will be presenting prop-086, the Global Policy for IPv4 Allocations by the IANA Post-Exhaustion. This was a collaborative effort by a number of people and obviously through at least one meeting in all of the regions so far. Hopefully this is good information for everyone. I want to apologize for not being there in person. Thank you for letting me present remotely.

To start, I guess, what are we talking about here?

This is a global policy to allow the IANA to accept and reallocate IPv4 space, especially in blocks smaller than /8. It provides to the IANA to allocate v4 addresses post-depletion, in other words today, open and transparently.

It defines RIR eligibility criteria, and it publishes the distribution method, which is transparent and provides for public reporting, which is the openness aspect.

Also, it maintains values of RFC 2050 in present day form and the bottom line is that it removes roadblocks to return space from the RIRs to IANA.

Why did we do this? Without this policy, any space returned to the IANA would be stranded, because we have triggered the allocation of the last /8s from IANA, it's questionable as to what would happen to returned space, because there's no current mechanism for IANA to distribute space to the RIRs, especially space that's smaller than a /8.

Obviously, this is a massive problem, if we expect any IPv4 resource returns at all.

How does prop-086 do this? It creates a reclamation pool at the IANA and allows all IPv4 space returned to the IANA to enter that pool.

Subsequently, the IANA will allocate space from the reclamation pool evenly to all eligible RIRs.

The allocation happens once per three months, once every quarter. It happens on CIDR boundaries.

There's a maximum of one /8 per RIR and the minimum is equal to the minimum allocation unit of all RIRs.

So the RIR local policy basically determines the minimum allocation.

So what does this mean for eligible RIRs?

Basically, all eligible RIRs have need. They are unable to assign space to customers, LIRs or ISPs and users within their region. And one /10 can be held in reserve for any special purposes.

Additionally, prop-086 gives no transfer rights to the space reallocated by IANA. So transfers are allowed only under a future global or globally-coordinated policy.

Comparing the like proposals, obviously, prop-086 was born from prop-069 and so they're very similar.

Prop-069 had two very distinct provisions. The first provision was to allow the IANA to accept and reallocate space post-exhaustion and the second provision was describing how IPv4 space returned to the RIRs would be returned to IANA.

Basically, it mandated the return of all space.

Prop-086 only addresses the former provision. It allows IANA to accept and reallocate IPv4 space, but it completely ignores the second provision of how RIRs return space to IANA.

However, it in no way precludes another proposal to address the latter provision, the returning of space. In fact, we believe that it facilitates it.

We see a strong need for IANA to be able to accept and distribute returned IPv4 space and we see that prop-069 appears to be stalled. Basically, the past is behind us and the time for action is now.

So speaking of the past, we examine the reasons why prop-069 failed, and it's very succinct. The ability to transfer IPv4 addresses to other regions with dissimilar standard is a roadblock to global consensus. Because of that, mandatory return is a roadblock for global consensus.

So why are those two things roadblocks? Mandatory return is a problem because any RIR could abandon needs-based allocations at any time without a codified agreement. Unforeseen circumstances could evolve in any region, and global policy is obviously quite slow to react. And it cannot reach consensus in all RIR regions.

And that's mainly because of the transfer of space. Why that fails is due to the fact that a needs-based system is fair until it's broken.

Distributing IPv4 space to any RIR that has significantly dissimilar standards is inequitable.

Any RIR could abandon needs-based allocations at any time without a codified agreement. Leaving this to chance is simply too large a risk.

Redistribution of address space should not result in less stewardship and this causes the roadblock.

So in prop-086, we introduced a transfer hook. It basically allows for the RIR communities to develop a proposal, whether it's global or globally-coordinated, two sentences or two hundred, to the RIR communities retaining the power to decide. This allows the transfer issue to be separated from within the policy, it separates the proposal from the politics. Basically, it's a compromise.

The entire idea of prop-086 is to remove roadblocks. We extracted the hot button issues.

We're paving the way for legacy returns direct to the IANA, bypassing RIRs. In addition, RIRs have returned address space to the IANA previously, and there's absolutely no reason to believe that it won't happen again if these roadblocks are removed.

There's concerns about the inability of IANA to make allocations and that if they do, they could be unpredictable.

Again, the bottom line is the lack of policy in this area is preventing returns.

As evidence to that, Interop returned almost a full /8 and their press release is quite clear, I'll read it from it here: "After the hold period, ARIN will follow global policy at that time and return it to the global free pool or distribute the space to those organizations in the ARIN region with documented need." So, I think it's very clear that if there is a global policy in place that allows ARIN to return this space to IANA, they will do that, if they think that's the right thing to do.

Again, this is a proposal that conceptually the same to prop-069, with a compromise on the transfer issue, and it removes the mandatory returns, which are two things which caused prop-069 to stall globally.

It allows two control mechanisms for RIR communities to address both allocation size and the transferability of address space.

Mainly it ensures that if there is need and if there are v4 addresses at the IANA, that they will be distributed in a predictable manner and it does all this by removing roadblocks for returning IPv4 space to the IANA.

This slide shows the status in the other RIRs.

Basically, it's been adopted in the ARIN region and is under discussion here and in the others three regions.

Version 2 included changes that ARIN Advisory Council made when they recommended this proposal to their Board. The main change being the change from "longest of any RIR's policy defined minimum allocation unit" to "the longest of that RIR's policy defined minimum allocation unit." The eligibility is directed to local policy, as opposed to everyone else's policy.

Obviously, there's some procedural bits in this.

There has been some issues in the APNIC region regarding the longer and shorter prefix language.

There was some questions about the various registries. I think those have been cleared up and then also that any RIR minimum versus particular RIR minimum, which was changed by the ARIN AC.

Our understanding is the policy language can differ between regions and as long as the intent is clear, the NRO can convene RIR staff to review and edit through a simply and efficient process, which gives all the regions a voice in clarity discussions.

So there's a little bit that's different in what's passed between the regions, we can overcome that.

This slide obviously is a pie chart, but it contains the details of the proposal. It's here for reference.

These are the references from the proposal as well, which we feel are important to have.

Obviously, I would like to note the contributors.

While all of these contributors are from North American area, from the ARIN region, our discussions were mainly around why prop-069 failed in the ARIN region and how to get around that and how to get a policy passed globally that would allow the return and redistribution of space.

With that, I would like to thank you and open it up to discussion and hand it back over to my friends there in Hong Kong.

Andy Linton: OK. Thanks, Chris, for that.

What I would like to do now is get Philip Smith to come and propose -- to talk about prop-097. But can you stay on the line with us and then we'll take some discussion points based on the two documents?

Chris Grundemann: Absolutely. Thank you.

Andy Linton: Thank you.

Philip Smith: Good morning, everybody.

As they say: me again.

I think I have drawn the short straw for this particular presentation, given we have quite a list of co-authors of it.

This is about prop-097, a Global Policy for Post-Exhaustion IPv4 Allocation Mechanisms by the IANA.

The proposal is describing the process that IANA will follow to allocate IPv4 resources to Regional Internet Registries after the central pool of addresses is exhausted.

So in other words, from now onwards.

Current problem is, IANA has now exhausted its pool of /8 blocks. However, there is a possibility that IPv4 addresses will be returned to the IANA post-exhaustion. There's currently no policy for what IANA does with these addresses.

Previously, prop-069 passed in four Regional Internet Registry regions. Prop-069 failed in one RIR region and that region proposed prop-086 as an alternative.

There are problems with prop-086, in that the reclamation pool could be exhausted by RIR or RIRs with high allocation rates after the first -- or first few -- allocation periods.

The reasons can include the rate of growth of Internet in the region, policies on how to manage the last part of their v4 address space. Registries with v4 soft landing policies in place are put at a disadvantage when compared with registries with no such policy.

The problems with prop-069 and prop-086, prop-069 mandated the return of IPv4 addresses to IANA.

Prop-086 doesn't mandate the return, but a registry which does not return addresses could claim the entire returned pool.

Both proposals attempt to define eligibility and exhaustion in ways to meet the needs of all five RIRs.

Situation in other registries, this proposal will be submitted to all registry policy development meetings, with a view to becoming global policy.

So to the details of the proposal. We have tried to keep this very simple, simple things in life tend to work a lot better than complexity.

IANA will establish a recovered IPv4 pool. It will contain any fragments of IPv4 remaining in the IANA pool and any IPv4 addresses returned to IANA by any means.

So the pool will exclude the special use IPv4 addresses, the details of those addresses are in the text version of the policy.

The recovered v4 pool stays inactive until the first registry has a less than a total of a /9 in its inventory. Once the pool is active, each registry will receive one-fifth of the recovered IPv4 pool rounded down to the nearest CIDR boundary.

This distribution will be done every six months.

The smallest allocation that any registry will get is a /24.

Obviously, if the pool is empty, then no distribution will take place.

Reporting. IANA will make public announcements of IPv4 address transactions that occur under this policy.

IANA will make appropriate modifications to the Internet Protocol v4 address space page of the IANA website and may make announcements to its own appropriate announcements lists.

IANA announcements will be limited to which address ranges, the time of allocation and to which registry they have been allocated.

So this reporting mirrors exactly what IANA has been doing up to now for the v4 pool that has just run out.

Advantages. We hope that we've removed the problem areas of prop-069 and prop-086. Regional variation of v4 runout policy is permitted.

Prevents the possibility of one RIR claiming the entire recovered v4 pool and it removes two areas of policy that failed to reach consensus in previous attempts. Those were how to return addresses to the recovered v4 pool and references to transfers and how they should or should not take place.

Disadvantages. The proposal does not provide details of how address space may be returned to the IANA v4 recovered pool.

We have chosen to exclude this from this policy proposal. There can be another policy proposal that addresses that issue, if the community wishes.

Impact on APNIC Members and the NIRs. The proposal affects the allocation relationship between the IANA and the RIRs. It does not imply any change in allocation relationships between APNIC and its Members or the NIRs and their members.

And that's all I have. Thank you.

I suspect that we'll have a number of people who want to comment on this and that will be good. Can I ask you, please, when you come to the microphone, the usual rules of who you are and, you know, whether you're for or against which of the two proposals and can you make sure that you do talk clearly to the microphone, because Chris is at a big disadvantage in that he's remote and he'll not pick up all the signals of how the questions are being formulated.

Mark Newton: Just speaking to the second proposal here. It sounds like you're envisaging sort of an alternate universe where resource records will be returned to the free pool. I'm just wondering if that alternative universe has its own RIR and can we join it? Sounds like they have lots of IPv4 addresses.

Philip Smith: Thank you, mark. Yeah, I know exactly where you've coming from. I mean, it was pointed out at the APNIC Meeting in the Gold Coast and previous APNIC Meetings, that IANA, if in the highly unlikely event IANA should get addresses, what should they do with them? So this policy proposal is simply trying to -- well, I suppose, plug that little gap. Should the situation ever happen.

John Curran: I have no view on policy.

LAUGHTER.

John Curran: But I have a view on that alternative RIR, that strange world you describe.

So 254 out of 256 of the Interop /8 did come back.

There's potentially a /8, /9 or /10 -- not 8, let's say 9 or 10, if I'm being practical, depending on how the party I'm talking to wants to squeeze into the remainder, that could be coming back.

When we did, on February 3, the announcement that said the free pool is depleted, I received three emails from organizations saying, oh, I haven't used my block. Here, take it back. So there's some small stuff, 16s and 24s that come back.

So there's an amazing number of people who actually read RFC 2050 and think if they're not using the address space, they should return it, but we have to be practical. It's always going to be a small amount. Realistically, when you pile it all together, for the next five years, it is unlikely to be much more than just over a /8. So that's just a practical thing for people to think about, but there is going to be space that needs to be dealt with.

I know people from the IANA are here and they've indicated that they are willing to steward addresses that are returned until such time as there is a policy get them back out. That was something that ARIN asked specifically, because a lot of these are ending up at ARIN.

So it would be useful for the IANA to have a policy to re-issue, but that won't preclude us necessarily from returning them to the IANA, it's just they may not come back out the other side, without a policy to get them out, since they are smaller than a /8.

I just wanted people to have a characterization of how much space we are talking about, at least for the next five years. Beyond that, there will be a v6 thing and there will be people deploying it and maybe that will bring stuff back, but that's kind of - when you are on the other side of the hill, I'm not sure it matters, at that point.

Mark Newton: Can I just address John. I submit that the free offers of unused IPv4 address space will probably stop dead as soon as people who hold that IPv4 address space works out how much it's worth.

John Curran: Imagine the conversation where you have to say, "You're doing the right thing. But I want to inform you, fully, this thing has value and will have more value. You know that, right?" "Yes. OK." "And you're doing the right thing by returning it, but you could also hold it. There's no grudge either way." "Yes, I know that." "You're sure you want to return it?" "Yes." "You don't mind putting that in writing, do you? Good." LAUGHTER

David Woodgate: My head is spinning a bit at the moment, in terms of a lot of the cross-implications between some of these proposals that are put up.

I'll address prop-097 first or a couple of concerns there.

Not /24s as a minimum allocation from IANA, please. May I suggest /16s as a minimum? I mean, you have come down from /8s to /24s as the allocation that IANA would do as a general thing.

I think that /24s is just getting too small from IANA to the RIRs.

Leo, do you want to comment on that point?

Leo Vegoda: We actually appear to have about a /20 in bits and pieces of /24, which I think would be the seed for any reclamation pool were such a policy to be passed.

Of course, if people don't want us to allocate those eight, I think it is, /24s, then we can probably just pass them out to staff and, you know, sort it out that way. In any case, we do have very small bits currently waiting for a policy. It's not really very much, so you probably don't want to go through a lot of effort just to get that /20. In any case, there is some space in /24s and no one is using it at the moment.

David Woodgate: I would still personally argue that if we see a regular thing of IANA allocating /24s around and let's live in the fantasy land for a moment where there is a lot of address returns in bits and pieces. What that's going to do to the routing tables is a fascinating concept.

The other thing I wanted to comment on is I understand what you're trying to do, in terms of equitability or perceived equitability about uniform distribution of addresses between five RIR regions, but the reality is I don't believe that demand is likely to be equivalent between five RIR regions, just on the basis of population alone, I suspect.

Somebody correct me if I'm wrong, but I don't believe the individual RIRs represent the same levels of population per region, do they? I'm happy to be corrected on that.

Philip Smith: I don't know the numbers, but if we follow it by population, I think APNIC would get a good third, given the population in India and China.

David Woodgate: Has any consideration been given to such splits on proportion of population represented which might have more relevance?

Philip Smith: The authors of prop-097 used the precedents of last final five /8s, the last five /8s, the registry regions managed to agree that the final five /8s would be distributed evenly and we feel, in the unlikely event, that v4 address space comes back to the IANA, that whatever remains should be distributed evenly as well. It stops the whole means-based, trying to figure out if it's done by population or number of LIR members, or the size of LIR members, or how many votes they have, or votes they don't have or any other gymnastics that we want to get involved in. The authors strongly believe in simplicity, dividing by five is easy.

David Woodgate: I sometimes wonder. That's getting overly simplistic, but we'll let the policy go on that basis.

A reference to prop-086. Am I correct that proposal is that no -- for prop-086 is that no inter-RIR transfers would be considered permissible under that proposal until there was a global policy in place by ICANN?

Andy Linton: Chris, could you perhaps address that one?

Chris, we're not hearing anything from you. I'm not sure if you're hearing us.

Chris Grundemann: I am. Can you hear me now?

Andy Linton: Yes.

David, would you like to ask the question again, perhaps.

Chris Grundemann: I heard the question.

Andy Linton: You got it?

Chris Grundemann: Yeah.

We tried not to preclude what we call a globally-coordinated policy. So rather than mandating a global policy, you know, ratified or endorsed, the idea is that all RIRs are coming to some agreement, a little bit less officially, on transfers between RIRs and meet the requirements in the proposal.

Andy Linton: David, does that answer -- David Woodgate: I'm not sure, but Randy is going to -- Randy Bush: Let's get the cards on the table here.

The reason that ARIN stuffed the proposal that everybody else in the world agreed to was they wanted to tell everybody else what the rules should be on transfer and what the rules should be on needs-based. Now they come out with a proposal that says, oh, everything is wonderful. That other proposal just really didn't work. We're not going to say why, but there has to be globally agreed transfer and everybody has to be needs-based and by the way, we don't think you should hold a soft landing any bigger than a /10 and only people with brown hair should be able to get this.

That's what we have in front of us today in the ARIN proposal. OK?

And I think Philip, your proposal is very simple.

To David, I think what it says is if the policy was good enough to allocate the final five /8s, it should probably be good enough to allocate the final five /24s.

John Curran: I have no view on the two policies presented.

But I actually was going to try to answer your question regarding -086. ARIN staff read on coordinated global policy is that if we adopted it in the ARIN region, and another RIR adopted it, then inter-RIR transfers between those two would be allowable, to the extent that each of us met the criteria.

So that's just how ARIN staff views the implementation of the inter-RIR transfer policy, is that it could be done pair-wise, if that makes any sense. Does that answer your question?

Andy Linton: I'm sort of surprised that -- well, I think we have covered a number of the issues here.

Does anybody else have any other thoughts on this?

The position with the two of these, you know, we don't -- if we try and seek consensus on one, we preclude the other one. Do people want to have any more thoughts on this? Because it's a fairly important issue, this.

Nobody else?

Maybe I shouldn't give you the option.

David Woodgate: Look, I admit that the thoughts going through my mind is that a lot of this is academic. Given, as you know, my perceptions on whether the final /8 policy is going to last and how it is going to affect the APNIC region, I think it's a fairly academic argument anyway, because imagine if everywhere were using the same final /8 policy, then you would probably actually never apply prop-097 much anyway. I just can't see these things happening in any major way.

Andy Linton: What I'm hearing from the information that John Curran gave us was that we're likely to see or possibly to see perhaps a /11 or a /10 thereabouts, is what's at stake here.

If we go with prop-097, that's what would happen to each region. And if we go with prop-088, it's not completely clear who would get what.

I think that for me is the nub of the problems.

If anybody sees that differently, I would like to hear them say so. Sorry.

Masato Yamanishi: I think major difference between these two proposals is the criteria which RIR is eligible for this policy. And I think prop-086 says eligible RIRs have been unable to assign space to customers, that actually the author of prop-097 has big concerns for this criteria, because it seems RIR which consumes current existing pool very rapidly can get more space. I think it's not intention of the prop-086, but it can be read, so that is the reason why we propose prop-097. Thanks.

Andy Linton: OK. So in the absence of -- I'm not seeing any compromise on these two coming out from the discussions. There's one position, and one other. What I'm going to do is try and get a sense of the feeling of this meeting about the two proposals and then let's see where we go with that.

If you think about proposal -- Chris, is there anything else you want to say before we go there?

Chris Grundemann: No. Thank you.

Andy Linton: Philip?

Philip Smith: I have nothing to add.

Andy Linton: OK. So on prop-086, I just like to get a feeling of how the meeting feels about that, how many people would be this favor of that one.

So the first one.

For your benefit, Chris, there's an underwhelming show of hands here. There's not a single hand.

So let me try and put that as clearly as I can.

So the first proposal that we heard, the one from Chris, is there anyone here who would be in favor of going to adopt that proposal? Prop-086, in favor.

OK. And those who are against seeing that one adopted.

And again, for your benefit, Chris, there are a few people here who are against that.

Let's talk about the other one, prop-097, how many people are in favor of prop-097?

OK. And we're now seeing more people in support of that than we're seeing who were against prop-086.

Who is against prop-097?

I think the mood of the meeting here is that prop-097 is the one that has the most -- you know, has the support.

I think we can -- support isn't overwhelming, but I think there are no objections or no strong objections to prop-097, so I think we have consensus on that. Yes? And we'll go back to the mailing list with that and see if there are any other comments.

I would encourage the authors of both of them to see if we can work together on this further. You know, it may be that the proposers of -086 can work with the people who worked on -097 and see if we can come to a suitable compromise on this, because it is important that we get an agreed policy or a set of policies that can be acceptable to each other.

OK?

Thank you, Philip. Chris, thank you for contributing and being with us this morning.

Chris Grundemann: Thank you.

Jonny Martin: Just one last question about this. What's the time frame for this?

Andy Linton: Do you mean the timeframe in terms of getting this policy --

Jonny Martin: Yeah, getting a policy proposal accepted, bearing in mind, you know, the free pool is out at the moment, the next meeting is in six months' time, plus then there is, you know, a period after that, if something does get accepted and is it going to help at this point?

Andy Linton: Well, I mean, we have reached consensus on this, we go to the mailing list for final comments and so on. Is that what you're asking?

Jonny Martin: Yes, and more specifically, the global part.

Andy Linton: John, do you want to comment on that?

John Curran: I have no opinion on this proposal or the other one.

On the timing of it, I don't know how long it will take a global policy, but it is definitely the case that a policy to redistribute things from the IANA that is smaller than a /8 is going to be a global policy and takes time.

I think I said this before, but I want to be clear. ARIN presently has a large percentage of a /8 that was returned from Interop on or about May 22 of this year that will come out of the hold down to get it out of the routing tables and the ARIN Board will decide whether it is to be re-issued in the region, or be returned to the IANA.

In preparation for this, I took the time to double-check with the IANA and they will receive it, even if there is no global policy that allows it to be re-issued.

So the good news, as the absence of a global policy does not automatically decide this matter one way or the other. And as address space comes back, there's presently proposals in the ARIN region to help guide the Board as to what to do regarding return it to the IANA or re-issue it in the region.

Andy Linton: Can I ask, just to clarify for the rest of the group here, does that mean that the stuff that goes back to IANA will sit effectively in limbo until we get a new set a policies in place here?

John Curran: I confirmed with Elise Gerich of the IANA that they would receive address space and hold it in stewardship as long as they didn't have a policy that allowed re-issue answer. I can't speak for the IANA, but I will say we'll certainly -- we're not forbidden from returning a space to them. They will hold it. That's what they do. They're the IANA.

I don't think it will be re-issued, because none of it is a /8 or greater, so it doesn't apply.

I see Leo here.

Leo Vegoda: I can confirm what John said. If space is returned to us and there isn't a policy for giving us instruction on how to allocate it onwards, then we will put it at the back of a dusty cupboard and make sure that it stays there.

Andy Linton: Johnny, does that answer your question?

Jonny Martin: Unfortunately, it does.

Andy Linton: OK.

So as a result of this discussion, what we're going to do is we're going to drop -086, because there was no clear consensus and support for it. We're going to take -097 back to the mailing list for final discussion and that sort of settles those two for now anyway. I don't think this is finished, but I think we need some more -- well, we'll go to the final discussion and see where we go.

Before coffee break, we were looking at proposals -095 and -096 and we asked the proposers of that to have a bit of a rethink and perhaps come back and look at that with us.

We have some time before lunch, so I'm going to ask them to do that now.

So just to summarize where we were before coffee, prop-095 was the one about the policy for inter-RIR transfer and I think we have alternative wording for that.

So we're going to have a look at that now.

Apparently, the draft is in transit.

Tomohiro Fujisaki: Actually, we revised the text of prop-095 under this condition, to respect each RIR's policy. Is it possible to show the policy text?

Actually, we write down the concept of the previous slide.

Andy Linton: Can the people at the back make some sense of that? Perhaps next time, instead of a torch, we'll have binoculars.

Randy Bush: Let me see if I understand.

Essentially, two things have changed. One is for stupid old hippies like me, you made source and so on explicit in the text. Right?

Andy Linton: Yes.

Randy Bush: So I don't have to try to think, which is very good.

The second is, that you have used the mailing list suggestion of the source of the transfer must obey their rules, the destination of the transfer must obey the destination rules, and those were essentially the two changes. Anything else?

Tomohiro Fujisaki: Yes, yes, exactly, yes.

Izumi Okutani: That's it.

Andy Linton: What I'm going to suggest -- Randy Bush: I support this proposal.

Andy Linton: This is kind of hard to read, but if we go back to the slide that had the diagrams, I think this summarizes the intent of the text.

Tomohiro Fujisaki: Yes.

Andy Linton: So this is the thing that we're actually going to -- I'm going to ask you to consider and see if we can reach a decision on. Is there anybody who wants to make any further points on this, given our discussions earlier? I think this is a clearly different from the thing we talked about before morning tea. How many people in the room will support prop-095 if this is the thrust of the problem? John, do you want to ...?

John Curran: (Tape played): "Hello, I'm John Curran, President and CEO of ARIN. I have no view on the policy proposal." LAUGHTER

John Curran: Regarding the revised one as revised, if I think about the inter-RIR globally-coordinated transfer policy in the ARIN region, to the extent that we're talking about a source being ARIN and a recipient being an APNIC account holder, whether this would be compatible with that would be based on whether or not the APNIC account holder meeting APNIC criteria for receiving space, its would be whether or not those policies in the APNIC region match the inter-RIR policies that ARIN can't do an inter-RIR transfer unless that RIR has policies that polices that comply with 2050 and are need-based. But to the extent that there are such policies in this region, OK, then it would be compatible. APNIC would be the one doing the applying, not ARIN.

Andy Linton: John, we're going to go and look at the second proposal immediately after this, which I think addressed that notion of the needs-based stuff.

So if we do the two, will that meet your requirements?

Randy Bush: I don't think it's relevant whether it meets the requirements. We all know that ARIN's rules will put burdens on everybody else and how we all should run our regions. OK? So any transfer to and from ARIN, if it is polite and trying to be cooperative and says that ARIN's rules will be considered, that will place ARIN's burdens on everybody else. That's life, living with ARIN.

John Curran: I actually have another one here.

Just to be clear, what Randy said is, ARIN's rules will be considered and will place ARIN's burdens on everyone else. I just want to be clear. That's accurate, to the extent that you read the rules as RFC 2050, the RIR policy framework. It's inaccurate if you read rules to mean ARIN's policies. The prior version of this actually had RIRs applying each other's policies to processing requests, which, obviously, has some excitement potential.

All this says is if APNIC's policies match the need basis in 2050, then it's a compatible framework with ARIN for inter-RIR transfer.

Randy Bush: No - what this says is, for instance, if I, as an APNIC account holder, want to do a transfer from you, John, who's an ARIN holder, OK, APNIC's rules will say that your outbound must meet your criteria and one of those criteria could be that the recipient must be blond and give chocolate, in which case this would let ARIN impose its rules on me.

But my point is, that's a bug in any system that acknowledges the rights of other RIRs. ARIN just happens to be a bit abusive of those rights.

John Curran: I want to be really clear, because both Randy and I, I think, misspoke.

This doesn't allow an RIR to put criteria on the recipient. It says APNIC. Let's talk about this, APNIC policy. It says APNIC is going to apply the recipient criteria for the APNIC region and the source should be applying the source criteria.

So this is your policy and it is what it is. All I'm saying is that in the ARIN region, the inter-RIR policy has a big macro evaluation, a meta question, which is ARIN has to maintain a list of those RIRs with compatible transfer policies. This would be compatible if the rules that you're applying to your recipients are need-based rules.

OK? If so, we would list APNIC as having compatible transfer policy. If this passes but for some reason you're not having need-based on the recipient, we wouldn't list APNIC as having a compatible transfer policy. That's all I'm trying to say. In either way, we wouldn't be looking at the are you acceptient or asking questions about the recipient. It's always your recipient, your rules.

I hope that helps clarify.

David Woodgate: A question of practicality. It sounds like this proposal is requiring the RIRs themselves to be the ultimate approvers of the transfers between them, in other words, there needs to be a logistical process of agreement between the RIRs before a transfer is deemed to be completed.

Is that seen to be a practical thing by the RIRs concerned? Now, the way that we have the policy drafted, the onus of responsibility for transfer is not -- doesn't appear to be on the actual transferee, the person trying to transfer their assets across -- sorry, addresses, apologies, from one RIR to the other. It appears to be that you would have to put the request in to say, an APNIC Member would have to put the request in to APNIC, they would have to arrange the transfer with the other RIR and that transfer would need to be agreed.

Is that what is the intention of the policy?

Tomohiro Fujisaki: Yeah. Actually, in that point, I think it's some kind of the implementation of the policy, so ...

John Curran: I have no recommendation on this either way. Way back in his question, there was the statement do the RIRs see a difficulty from a practical implementation case? In the case of ARIN, we don't see any difficulty with an inter-RIR transfer policy or the implementation of it. We recognize it's going to require more coordination than something that takes place in one region, but the RIRs are pretty good at coordinating, so we don't see a problem implementing our particular inter-RIR policy. I don't know about any other region.

Andy Linton: I think it would be useful if Sanjaya, you could give us a similar view from APNIC.

Sanjaya: Yeah, I'm echoing John here. We have transferred before on different condition. We know how to coordinate and I think we can handle this.

Andy Linton: David, does that answer you?

David Woodgate: Sort of. I'm wondering to the extent that this sort of implies a global policy rather than a unilateral APNIC policy, is the question. I suppose the answer is it's a unilateral APNIC policy to the extent that it is capable for APNIC to communicate with the other RIRs. Is that a fair statement?

Andy Linton: I'm not sure I can make the pronouncement on that. I think that's for people to decide.

OK. I think we've covered -- there's no one else who has any further points on this?

OK. Let's ask the question, because this morning there was certainly some support for a motion like this. Let's see if these changes have made this more acceptable to the group here.

If we now consider prop-095 based on the mechanism that's on the screen at the moment, and you haven't had a chance to read the text in detail, but I believe the text actually reflects this accurately.

So for prop-095, who is happy to support this?

This morning, there were, I think, more people who supported the -- whose hands went up in the original or who supported it. Are people still confused? Is there more clarification needed on what we're actually asking about?

I'm seeing one or two heads nodding. So let me try and summarize what this means. If you're transferring inter-RIR, you have an APNIC account holder is transferring something to someone in another RIR. Then the rules that apply on the source of the resource are the APNIC rules and when it gets to the other side, to the other RIR, their rules apply and the same applies in the other direction. So if we have resources coming into this region, the rules that apply in the other region apply there and the rules that apply in this region apply to the recipient.

So we have policy that is set in this region which is appropriate for people in this region and policy which is set for people in the other region, which is appropriate for them. Those may be slightly different, but from what we're seeing, they're not vastly different.

Let me ask you again, how many people are happy to support this?

Those people who are opposed to this?

Are there people who have no opinion or who are too confused or don't care?

I don't know which of those three things -- OK, those people who are confused, those people who, you know, haven't got enough information to make a sensible call here.

OK. There's a small number here, smallish. But I think we have got consensus on this. I think enough people support this that we can move this to the final call on the mailing list. If there is strong objections there, then we'll have to revisit that.

We are also going to look again at prop-096 -- sorry, go to the microphone.

Pavan Duggal: Just a clarification. Given the fact there are some hands going up saying they don't agree or there is confusion, I just would be more happy to get enlightenment to you as to what would constitute a consensus here, given the fact that there have been hands on both sides. I don't see any consensus coming in, to the extent. I think we have some clarification, but I would require the clarification from the chair rather than from anybody on the floor. Thank you.

Randy Bush: We've had the consensus discussion many, many times.

Andy Linton: I think that what we're seeing up here and perhaps Gaurab can come in on this, there are people who support this, there are people who don't support it and there are people who either have no opinion or, you know -- let's call it they're abstaining from making a decision. They're not saying yes and they're not saying no. So it's not a vote and it's not, you know, about a unanimous vote either. This is about consensus. I think there's enough. So I have some other people who want to speak on this.

Masato Yamanishi: I'm one of the persons who raise their hand. I'm confused.

The reason why I raise the hand, not stopping consensus, because if I will stop the consensus, I opposed to, because I cannot understand what this proposal clearly said. So it's not opposing. I'm neutral for this proposal. So I think we can reach to consensus, even though I'm still confused.

Medel Ramirez: I'm not just confused or even against it, it's just a matter of more clarification, as to what extent, as to crossing the boundaries between RIRs, rules, policies, and procedures that came across or what's the gap between that has to be in place in order for the rule of each RIR can fit into the next RIR's rules and policies?

So what I'm saying here is what are the extent of that particular policies that will enable each inter-RIR transfer? So that's where I'm coming from. What is the gap? Or each RIR has a mutual compromise that, OK, we agree with each policy and procedure and then you get this piece of pie. OK.

Thank you.

Randy Bush: I think I can speak to that. The change between the earlier version of this and the current version was specifically to address that problem. The previous version made the two RIRs' policies very interlocking and very reacting, you know. If I wanted to do a transfer from you -- this one separates them nicely. OK? And has good manners. So this one says that, you know, you're putting money in the bank, you decide how to do that, I'm taking money out. My rules apply.

But we probably getting closer to lunch and I would suggest that those people who want to explore this further, we could sit at the same table for lunch and try to explore it, discuss it and try to understand it better.

Andy Linton: I think we're done with this.

I think if, you know, the opportunity is still there on the mailing list to look at this again and if people really want to get in and change the position on this, then that's where that final call is.

There may be people who are offline here who will want to look at this as well.

So I think we move onto that process. This isn't the finish of the process, because the process continues with the final call and the opportunity arises to, you know, put a final block on it.

Tomohiro Fujisaki: Sorry, I just sent the revised text to the mailing list just now, so please look --

Andy Linton: OK, so the text has been sent to the policy mailing list now, so people want to read the fine print of it. But I think we have enough sort of weight of opinion and consensus on this that we can go to that stage and take it all on the mailing list. I'm not hearing material objections to the way this works that change that.

OK. So prop-096, which was the other one, which was where we got to this morning, and I think now if we look at prop-096 in light of prop-095 being there, and this was the key description of the proposal this morning.

Tomohiro Fujisaki: Actually, prop-096 is not changed from the previous version, but as far as I understand, this might be necessary to achieve the inter-RIR transfer between ARIN, because John says that RFC 2050-based policy is necessary for the counterpart.

So I think we need this. So I want to ask the community if it is acceptable or not.

Dean Pemberton: I was having a discussion earlier on with an APNIC staff member who found their input in this might be good, so I would like Geoff Huston to come and give his opinion.

Geoff Huston: Thanks, Dean. This is Geoff Huston from APNIC, but I'm going to drop the from APNIC attribution and speak as an individual member of the community. Echoing a role I took in this same forum two year ago in Manila, when we discussed the original prop-050 and the transfer policy, which at the time as in that slide there, the current policy, it was a transfer policy where recipients did not need to demonstrate their needs for addresses after the point at which the current allocation system reached a logical conclusion.

There was a very fundamental and very important reason for that that I'm not sure we truly remember today, so I would like to state it again. We are a registry and the registry is a registry of uniqueness of addresses. If we have two registries that describe the same resource but describe it with different holders, we break the Internet. We cannot threaten the integrity of that registry and still have a working Internet. They are not compatible propositions.

So when you reach a point where you have no more allocation, what you want and what we all need is for the registry to accurately reflect the current disposition of addresses from day to day from second to second. Because if that doesn't happen, the registry is useless and APNIC is irrelevant in the scheme of things.

If you put forward artificial barriers to entry to that registry, then you are effectively stopping access to that registry and encouraging others to create their own registries. As we have already seen with route registry databases. It's not hard to make a lot of them. It's just disastrous.

What you are proposing here is, in fact, an extremely dangerous proposition to this community.

You are placing barriers to entry to the APNIC registry, artificial barriers, and in so doing, you are indeed threatening the future of a unique registry. This is a very, very dangerous concept, because at that point, you really are threatening the integrity of the entire Internet.

So I would please plead with you to think extremely carefully about what you're doing here and understand that when you place such barriers to entry to a registry, not everyone just simply goes, well, I can't do that because APNIC won't let me.

They will find another mechanism of doing it that doesn't involve this registry. As soon as that happens, I'm really not sure what happens to the Internet, but it's not a good outcome.

So that's what I wanted everyone to appreciate here, that the reason why we had this very long discussion in Manila about this and the reason why that policy was crafted in that way, was all about registry, integrity and a working Internet.

I personally thought at the time that was a difficult but well thought out outcome. I worry that we forget that so quickly. I worry that we treat the Internet so casually and treat registry with such disdain. I wish we were more respectful of our role here. We really need to make sure that registry works for everyone, it's accurate and current, and the barriers to entry are as low as we can make it, because that's the best thing this community can to for a working Internet. If we can't do that, why are we here? Thank you.

APPLAUSE

Andy Linton: Is anyone keen to have a go after that?

Tom Vest: Just a point of clarification, in the absence of a needs-based criteria for the resources, I was wondering if Geoff would help clarify the requirements that would remain for the identifiability of the aspiring resource holder.

Would it be sufficient to satisfy the requirements for maintaining registry integrity if the resources were all unique, but they were all uniquely registered to don'tcallme@yahoo.com and anonymous@gmail.com. Things like that. I think if there's some foundation for maintaining the referential utility of the registration entries, then that would be of substantial value. That I think is one of the a things that's currently functionally tied up with the needs-based testing.

I would appreciate a clarification.

Geoff Huston: It's simple. A registry records the association of a resource with a holder. That's an identity and a resource, Tom. Yes, identity is really important. That's what the registry is about. Resource and holder association. If we lose that, we lose uniqueness of the resource and we lose the ability of others to associate identity with the resource. The registry becomes useless, we all give up and go home. Identity is important. Yes.

Randy Bush: I want to roll back to Geoff's original one. Geoff and I are known for many -- too many words and too few words, so I will try to maintain.

Your point, Geoff, is, restrictions on transfer create black market which hides information. OK.

Therefore, I would expect that you would not like the previous proposal, because it, for instance, said, OK, say I'm buying from an ARIN holder, that since it allows ARIN's rules to be superimposed on the source, that restricts it and would be bad. So I don't know where to draw the line to what's good and bad and I think Fujisaki-san's intent here is just kind of to maintain, you know, minimal change and still sticking with 2050, but I hear your point, but who are you protecting? The recipient who wants to hide their identity. Are they going to announce it in the routing table?

Geoff Huston: I think that the best I can do in this community, in this region, is to advocate the best possible thing that this region and this community can do. I personally have some opinions about what ARIN is trying to do and I think they're amazingly misguided and the same principles of what I said before about trying not to impose conditions on registry apply equally forcefully to what ARIN is doing. I think the same conclusions can be drawn about what ARIN is trying to do, that is misguided and dangerous is where I sit personally. But I'm in this community, Randy, and I can only advocate here what I think is good sense for the Internet as a whole.

We really, really need registries to work every day, every second, for the Internet to work.

If we put barriers up there, I don't know what happens after that.

Skeeve Stevens: I'm not actually commenting on the proposal, I like considering some of the ongoing discussions and the enlightenment that some of this is bringing and realizing that consensus has already been called. I would request the chairs to actually reconsider calling consensus.

Andy Linton: On this proposal?

Skeeve Stevens: This proposal has already has consensus been called, hasn't it?

Andy Linton: No, we are still talking about this.

Skeeve Stevens: OK. No problem.

Andy Linton: I think. Yes.

Philip Smith: I think this slide probably says everything that's wrong with the policy proposal.

Like Geoff has said, ISPs look a the five Regional Internet Registries for who is actually the holder of the address space and they will accept at least space based on what the registries say. If there's a barrier put up, then another organization will step in. Some of us know about depository, for example. That's just the thin end of a very big wedge. Why a commercial company? Why can't a country to this, for example or a subregion and so on. You can get my point.

Somebody who is willing to register transfers and then who do you actually believe? Do you believe the registry or do you believe these other people?

Who would the ISPs believe? Maybe we pay money, you know, the ISPs pay money and so forth. It just gets silly.

Maybe countries are running one, then the country says you will believe us and we end up with anarchy that Geoff is talking about. So I think this is just so dangerous, we shouldn't even be going here.

John Curran: Regarding the policy proposal, this is a policy proposal before APNIC for what APNIC's Members think are best and I have no view. I think that Geoff has raised some profound issues that you need to think about, as have other people discussing.

I only will point out probably one conceptual difference and actually Philip Smith was the perfect straight man. I need to thank him. Because this slide fundamentally describes the differences in philosophy that are probably underlying a lot of this.

When this first came up earlier, I actually looked at the slide and I thought, wow, I would have beat someone into the ground for putting that up in the ARIN region, but it's not the ARIN region, so it's wonderful. And it's the last sentence. It says: "Could be a barrier to entry to the accurate recording of transferred IP blocks registered in the APNIC Whois." That might be the way it is in APNIC. In the ARIN region, we operate the ARIN Whois Database based on what the community wants the rules to be. They do kind of similar to this and we make policy. But at the end of the day, the transferring of a block occurs when it occurs in the ARIN Whois Database.

So there is no transfer of blocks that aren't accurately recorded because, actually, that database is run for the ARIN Members based on the rules they give us. So that's probably a different philosophy than we've heard other people talk about and might be a core question for this region to think about, because it is a very important question when you're looking at this policy proposal.

James Spenceley: Unlike my RIR colleague, I tend to believe that a transfer happens when somebody signs a piece of paper and starts announcing address space, whether or not the Whois accurately reflects that. That's the actual point that a transfer happens.

I think our responsibility as a registry is to ensure that as a transfer happens, we have accurate data of the person that is utilizing those resources. I find myself quite shocked that I'm agreeing with Geoff, but I am agreeing with Geoff, that this is the primary function of APNIC and I think that we, at our peril, will ignore what is human nature and what is commercial nature, that these transfers will be happening and that they won't be recorded accurately in the Whois.

Thank you.

Pindar Wong: So three points. The first is that I believe the disadvantage is, you know, it is the thin edge of the wedge or a slippy slope or whatever you want to call it. Yes, there are going to be a whole set of market dynamics and other concepts that will be injected into discussions, such as concept of property and other stuff.

It's going to be complex no matter which way you go. And I think the risk here, and I agree with Geoff, is that some of the more philosophical points which, I guess, were never written down, and I found that to my own experience yesterday as a single vote on a proposal, somehow seems to be gotten lost in the mix. So I think it's very important that we go back to Geoff's statement to go back to, yes, we are a membership organization and we respond to the Members, to address John, in this region, but at the same time, we have a very important and relatively simple task to do and doing that well is hard.

So please think very carefully whether or not you agree to this. Thank you.

Mark Newton: There have always been ways to get address space other than going to your local RIR, for instance, you can go to a holder of historical address space, get some agreement from them to use it and off you go.

In the pre-exhaustion world, the RIRs, if you had done something like that, would then be able to say: well, you're using these address resources, you have to justify them according to our policies or you can't get more. And that was almost an enforcement mechanism that would make everything who was a member of that RIR, play by the same rules.

That isn't a sword hanging over anyone's head any more, because if an RIR says, you know, you need to satisfy our criteria or you don't get more, it's like, well, that's all right, you're not going to give me more anyway, there isn't any more. So I think one of the conceptual problems with this proposal is that it seems to come from a belief that if an address transfer happens contrary to APNIC's proposals -- APNIC's policies, then that will be disallowed. Like in reality, that isn't actually going to happen. A transfer will occur, whether it is consistent with APNIC's policies or not. What we're actually talking about is whether that transfer gets recorded in the database.

I concur completely with Geoff, which is when transfers occur, off the books, consistent with APNIC's policies, consistent with ARIN's policies, who care, anyone, regardless of how the transfer happens, its must be able to be recorded, because if it can't, then, you know, how do we work out who's using each address block?

Andy Linton: Thank you.

We're at 12.30, which is when we're supposed to break for lunch. I think we're within sight of a solution, so what I'm going to do is keep this going for a little while to see if we can get to the point where all the discussion points are covered.

We won't go past maybe quarter to, ten to one, so I'm going to put a bound on this. If we can't reach a sensible point at that, we'll break for lunch and come back, but let's see where we can go.

I'm hearing a number of people saying they agree strongly with Geoff and this is really important.

And I'm very happy for you to come up and say that sort of thing, but I think what I would like to hear mostly is if there's anything who has got a different view from that.

I'm very happy to hear you and we all are, but if what your view is that, you know, the consistency of the registry is really important and so on, then keep it short, so we can move on with it.

Jonny Martin: Just perhaps a finer point about the registry here. The thing that makes the RIRs the registries is that enough people trust that data and trust it enough to use it. Alright? So this is getting back to reinforcing what Geoff said. Anyone can set up a registry and they probably will if our registries become of limited use. So, yeah. We need to make sure people believe us, because that's what makes us the registry.

Pavan Duggal:I was just wondering, in case if this policy is implemented as it is, then whether it is going to give a legitimate foundation to illegal trading of IPv4 addresses and will actually give a [] to the grey area market which everybody is trying to avoid. So I just wanted to have a clarification from the proposer. Thanks.

Andy Linton: I suspect, but other people who have already spoken can probably do so by nodding their heads or making some signs to the rest of us, you know, the opinion is that if we go down this track, we'll get illegal trading. I mean, is there anybody who is wildly divergent from that view? Do people agree with that view?

Randy Bush: That's what people have been saying for the last half hour.

Andy Linton: Yes, I think that's the case.

Tom Vest: I just want to expand on a couple of things that James and Johnny said. James talked about human nature and the natural tendency of market forces to have their way and compel people do things perhaps in contravention to the established rules.

Well, that's going to be true regardless of whether we have more or less rules.

It's very natural and understandable for private institutions to want to protect their information, to maintain as much confidentiality as possible and to have a self-understanding of what constitutes sensitive, you know, confidential commercial information and to define that in as broad as terms as possible.

I think we have to balance the tension here. We need to do as Jonny said, maintain the level of trust which has been vested in the registry. That's very important for lots of reasons, including and it plays an important role, I would say, in the industry's peer-based risk mitigation and discipline mechanisms. So it's very important to everybody.

But there are two dimensions to that trust. It's got to be accurate, so uniqueness has got to be preserved. But whatever is the content of the database actually must be useful for contact, you know, for actual contact and identification purposes.

Again, I think the needs-based testing has served as a kind of a passsive vehicle for supporting that function up to date. So I just think we need to be mindful of what, if anything, is going to fill that gap, if that's eliminated.

Andy Linton: OK. Now, at this stage, I'm happy with the people who are up speaking, I've got Dan, Izumi, Randy and then what I was going to do was ask Sanjaya to give us a view that if we went with this policy, what effect it would have on the Secretariat. Unless I'm getting someone who has wildly divergent opinions who feels very strongly, we'll go to a call for -- consensus and then we'll go to lunch and so on.

David Farmer: These comments are purely my own, have nothing to do with my employer or my position with ARIN.

I have a slightly different issue to raise than has been raised so far. I grant you that there are serious concerns to be considered about the long term proprietary of the registry data. However, the slides up there today, right now, is the question that I want to raise and that is when is the appropriate moment to trigger that registry change? APNIC is part of a registry system, an entire system. There's five global RIRs coordinated under IANA and ASO AC. It's not an individual registry, it's a system of registries.

And when APNIC is out, is that the right time to trigger this or when all of the other RIRs are out or all of that? Because when APNIC is out, there's still needs-based allocations being made in other parts of the world and what does that do to the worldwide system?

If you believe that, then there's a lot of questions about how the need from APNIC is going to shift to other parts of the world.

Just something for you to consider.

Andy Linton: Thank you.

Izumi Okutani: I remember there has been, like, similar discussions in RIPE NCC about this transfer proposal and the feeling of the community is that it's really important to maintain the accuracy of the database. That was the general seem to be the general agreement of the community.

Yet, RIPE NCC community has reached consensus to request for justification. So I would be interested to hear anyone from RIPE would be able to give a view on how they can maintain the accuracy of the database, while requesting for justification.

Nigel Titley: As one of the authors of the RIPE policy, we retain needs-based, because it was the only way we were going to get a transfer policy through. It was a concession. We originally -- the original form of the policy had no needs-based requirements at all.

Randy Bush: There's the old story of a man on the rope on the cliff and above is the tiger and below are the tigers and the tiger we have above is that needs-based will create more of a black market and damage the data in the registry. The tiger below here is that we're not in the spirit of 2050, we're not in the tradition which we have carried on forever. I would note that what the story ends is that he ate the strawberry that was in front of him.

I'm going to lunch.

Paul Vixie: I'm speaking as an individual, not as a member of the ARIN Board, not in my day job capacity. But you asked if anybody would speak sort of in opposition to what Geoff said.

What I want to say is: don't run scared. The idea of off books transfers that take place outside the 2050 regime, therefore not on a needs basis, runs in contravention to the whole registry system, the whole idea of an Internet.

Several people, including Geoff, have said that we respect the allocations as recorded in the Whois Databases because they are unique and because they're valuable for that reason. It is possible that network owners who use this data to guide their operations also respect these things because they were allocated on a needs basis and if the network operators, who have a choice of what route to accept, begin to suspect that some of the things recorded in the Whois Database are actually there for reasons other than what 2050 said, they could decide to stop trusting it for reasons not having anything to do with uniqueness.

So the idea that a registry would decide that they should record all transfers, no matter how they took place, what off books, side private transaction, no matter whether a needs basis was there or not, but must record everything because the value of the registry is otherwise threatened by non-uniqueness, is, I think, a mistake.

Thank you.

Andy Linton: Sanjaya, if you could just talk to us about the implications that if we go with this proposal,

Sanjaya: The impact would be minimal, whether we go with this proposal or not, because we know how to evaluate, if this gets approved, or if it's not approved, then we know how not to evaluate it. It's all good.

Andy Linton: Before you go, can I ask you another question. Just on our current implementation or proposed stuff, when we go to the last /8, our current policy talks about us, our transfer policy we won't have conditions on the transfer, under the blocks that we hold, so on our internal -- are any internal transfers within APNIC, we won't be doing any needs-based assessment and I'm seeing Geoff nodding I think that's my reading of the policy, but that this stuff will have this implication.

Does that color your answer in any way?

Sanjaya: Yes. No. It doesn't change. It's just that we will continue -- as you can see, the blue line there, change to a green line, right?

Andy Linton: Yes.

Sanjaya: We are already preparing to do the green line, which is no need to demonstrate. But if this gets approved, the blue line will continue, so we'll be just continuing work with what we're doing now.

Andy Linton: But this will be only for addresses that are transferred in from outside, the blue line, this change.

Sanjaya: That is within APNIC. Yeah.

Andy Linton: OK. Just so people -- to make people understand.

OK. I don't want to put the pressure of going to lunch on you as a way to get you to make a decision and so on, but this proposal is -- there has been a lot of discussion around this proposal, about the effects it will have and so on, which has been the main sort of discussion, it's not whether the proposal is workable. It's perfectly workable in either way. But the real issue here is whether you believe that if we go with this proposal, we end up with a barrier to having the accuracy of the registry. I think that's the sort of -- that's my reading of it and I think that's where we are.

So that's what I want you to keep in mind when you try to reach consensus on this.

So those people who are in favor of us adopting this proposal understanding that there may be some risk in keeping the registry data accurate, so I would like to see who you are. Those people who feel we should adopt this proposal.

And those people who feel that we shouldn't adopt this proposal.

OK. There's a small group of people who are the people who were, you know, the active discussers here.

I don't think we have enough people who are really happy with all this that we agree it. We'll go back to the mailing list with this, and that's it for that proposal.

So we have some administrative stuff.

Gaurab Raj Upadhaya: Thank you, Andy, for doing the four proposals.

We still have one proposal that we were to discuss, prop-089, "Additional criteria for final /8 allocations and assignments".

We cannot trace the author and we have not found him or we can't get a response from him.

I can read the proposal or I can propose that we just send it to the next Meeting.

So you want lunch or you want the proposal?

OK. So I think what we'll do is because we can't get in touch with the author, we'll just send it back to the mailing list and it will be considered at the next Meeting.

Besides that, since we have covered all the proposals, you'll have 90 minutes of shopping in Hong Kong to do after lunch. We'll not have another Policy SIG session again for this meeting.

There will be a closing plenary in this hall after the next coffee break. There's a lot of activities going on between now and the closing plenary. There is a 4K to know, there is a 10 gig demo from Prague all the way in Hong Kong, you should go and see all those stuff in the theatre opposite here and on the forth floor, so please take your time, go around, meet our sponsors and thank you for being part of the Policy SIG.

APPLAUSE

Also thanks to the sponsor of the APNIC Meeting, CNNIC, for today and also all the remote participants and all the policy proposers and active debaters on the policy.

Thank you very much.

APPLAUSE.

Follow us:

on Facebook on Twitter