Session 1 Begins

Sunny Chendi: Good morning for those who are in the room here.

We had a big party last night. I hope you joined the party at the F bar, so we expect more people to join us today, this morning here in the room.

We just decided that we'll start the session around 9.20 am. I hope we'll get more crowd into the room by then.

Otherwise, just sit and relax and catch up with your emails. Once we have more people in the room, I'll come up and begin the session.

Thank you.

Andy Linton: Good morning, everybody. I think we'll make a start. I think looking around the room, almost everybody here is either APNIC staff or staff of other RIRs or related organizations. We don't really have very many of the community. But our first part of the meeting is sort of administrative stuff, so we're not actually making any decisions and I'm going to look when we get back into the session after the break, to make sure that we actually have enough people here who are able to help us reach consensus actually here. I don't think that a very small group of people should be doing that.

So let's see how that goes. But I'm going to start first thing up we've got like a reminder of what the policy development process is for people. Most of you are -- I'm guessing, looking around the room -- very familiar with this, but I don't think it hurts to go through that, to make sure we're all working from the same set of rules and conventions.

Then our next thing on the agenda is our review of action items, so that's really just talking about what we're planning to do today, an overview of the proposals.

We have four proposals, one of them is going to be presented not by the author, but by someone who is going to help there. One is going to be presented remotely, and then we have two others.

Let's start that part of the session off and I'll get the slides for the first part of this up and then we'll go on with that. There may with some questions and things in this first part.

Can I remind you that when you come to the microphone, there's a little note on them all saying please identify yourself and please speak slowly, so our excellent transcription people down the front here can get hold of it. If you find that I'm speaking too quickly, please signal as well. I can't do much about the accent, but you can certainly slow me down if you need to.

It looks like we need Bluetooth too on this keyboard, because we haven't got enough range on Bluetooth to do that.

So I'll just get through the agenda itself and then we can see what's going on from there.

In this first session, we have some slides on the policy development process, a review of our action items, as I said, a proposal as overview and some slides and discussion, hopefully, on what we're calling community remote hubs.

Then in session 2 we're going to have a report from the Chairs. I think we should probably move that apostrophe, it's the Chairs plural, but I will be delivering that. Then we'll have prop-101, which is removing multihoming requirement for IPv6 portable assignments and then prop-098, optimizing IPv6 allocation strategies simplified.

In session 3, I think we're also going to have the APNIC resource policy documentation, so there's going to be some discussion on work that the Secretariat planned to do on trying to tighten up the documentation and basically do an edit and get it into probably, hopefully a more readable and more accessible form for people, but we'll talk about that then.

We'll have a global policy update on prop-097, which has been through our region and the other regions and we're now at the point where that's been agreed by everyone and it now needs to go to the next stages.

Then we'll have prop-099, which is IPv6 reservation for large networks. This was a proposal that was at our last meeting in Busan and went back to the list for some further discussion and it and proposal prop-098 have both done that and we'll see that again today and then another new proposal, prop-102, about sparse allocation guidelines for v6 resource allocations.

Just to remind you all about how our policy development process works, or to give some insight to people who are new to this: our Special Interest Group, the Policy SIG has a charter which is to develop policies and procedures which relate to the management and use of Internet address resources by APNIC, NIRs and ISPs within the Asia Pacific region. It's quite a concise charter. It's our job to look at those things and not other issues.

We have two mailing lists, one which is the open mailing list for discussion, the sigpolicy@apnic.net and we have a further list, SIG Policy Chair, which is for discussion between the three Chairs and the Secretariat, so that we can do the management of the work that we have to do.

When a policy proposal is -- someone thinks they have a good idea, there's a number of steps that have to be gone through for this to become part of our policy.

There's a proposal submission. That submission has a deadline of four weeks before this meeting. I note that, almost inevitably, all those proposals come in at five minutes to midnight on the day, the last day, or metaphorically anyway, very close to the deadline. There is no requirement for you to wait to the last minute to put a proposal in. Those can go in, you could leave this meeting and in a week's time, put a new proposal in for discussion next time around. That may or may not be a good idea, but waiting to the very last minute isn't a prerequisite. You can do this earlier.

We have discussion before the meeting. So typically what happens in the four weeks between the proposal being submitted and the meeting starting, there's some discussion about proposals, and that's an important part of this process. It's a period when some ideas come together; people say, "Yes, I like this," or "No, I don't like this," or "I'd like it better if it went this way," and so on. It's important as well because it allows people who can't get to this meeting to take part in the process.

This meeting is only part of the process. What goes on in the mailing list is significant as well. There are plenty of people in the Asia Pacific region who either can't afford or don't have the time or for whatever reasons don't get to these meetings, so it's important that people take part in that discussion, I think.

Then we get to our meeting, as we are today, and we discuss the proposals and we hear pros and cons and we debate the issue and then one of the tasks of the Chair is to decide whether at some point, we are going to reach consensus on a proposal. We'll talk a little bit more about consensus in a moment, but it's not the only place where the decision is made. Part of the decision is made relating to the discussion on the mailing lists, so if there are plenty of people on the mailing list who are very strongly for or against something, those views will be taken into consideration in the consensus process.

Again, that's important to understand. It's not just the people here in the room, you know, we're a very special select few out of our community. Yes, we have made the effort to come here, but it's important to understand that that other part is important, too.

If we reach consensus at this meeting, we go tomorrow to the members' meeting and we report to them what we've agreed. When we report that to them, then the meeting has a chance to consider our recommendation from this meeting and they then can decide whether consensus is reached again.

That's an important check. It means that, you know, if something has gone wrong with the process in this meeting, those members are in a position to say, "Wait a minute, you know, think again."

We then go back to the mailing list and we have a further comment period which lasts eight weeks. Again, that period is a time for people to raise serious objections to any consensus we would reach in this meeting and it is a period when if there are serious objections and the Chairs believe that they would overturn the consensus decision, it can be done.

All these checks are there to make this robust. This is to make this so that we can't make a strange decision by some strange aberration in this room.

When that eight-week period is up, it's the task of the Chairs to decide whether there have been any barriers to proceed, and at that point the recommendation proceeds to the EC. The EC, the Executive Council, then look at this again and say, "Yes, this is good", and it moves on.

There is then a period where the Secretariat will prepare a formal text for what the policy represents and that's to keep the style and so on on the documents sort of consistent and just to dot the Is and cross the Ts in there.

It means then that one of the tasks that we have as the mount is to look at those documents and make sure that the editorial work that the Secretariat has done actually reflects the view of this group.

If that all proceeds, then we go to implementation. It's important to remember that implementation, in some cases, actually takes some time, systems have to be changed, processes have to be worked through, training for the staff and so on.

All the work we do has some implication for the Secretariat, and things may take a very short period of time if it's simple and they may take longer and it's important that that work is done properly, so that the policy gets implemented correctly for us.

Consensus decision-making, I suspect we all think we know what it means. I think I know what it means, but probably my view is slightly different from yours and so on. But it's important that we have consensus on consensus.

It's sort of a bit of a circular argument. It's general agreement. It doesn't mean that if 51 people support something and 49 people don't -- it's not a vote. It's not a simple majority. You know, we all agree or we all even get to the point, "Well, I don't quite agree, but I'm content to let this go ahead."

The Chair takes into consideration comments on the mailing list and at the meeting, as I say. We use a show of hands to broadly gauge opinion. But it's not a matter of counting the hands that are up. It's a way of saying, OK, let's understand what the feeling is here. What do people want?

Voting would disadvantage those who are not present. You know, there's barely 100 people in the room here and it would be wrong for us to be saying we can actually vote on behalf of the whole community.

It might be useful to think about -- there's a couple of definitions up on the screen here which come from the Tao of the IETF document, which also uses a consensus process. I'm not suggesting that these are our definitions, but they may be ways of focusing your idea here. You may consider a very large majority of those who care must agree and you can say that that's one way to look at it, or another coining of the phrase "strongly held objections must be debated until most people are satisfied that these objections are wrong."

We can be in the position where someone is strongly against or strongly for something and their opinion is of course a valuable opinion, but, you know, they may be wrong. If most of us think it's that, then we're at the point where we have got consensus.

We use consensus in the policy development process because, I think, we're an open multi-stakeholder environment and this is the way we do things here.

Anyone can make a proposal. We can discuss policies and participate in the decision making.

It's important to remember that. It's anyone. We're transparent. It's public and it's documented. APNIC publicly documents all the discussions and decisions, and this stream, as well as being heard in the room, the transcript is being typed as we do this, there are also some remote connections, we have two remote hubs currently listening to us and a number of people joined in on things like Jabber and so on.

So those people are also part of this process and that open scrutiny is part of our -- it gives us our legitimacy. So it's bottom up. It's driven by the community. This community drives the policy development.

The Chair responsibility at the SIG meeting is to provide a neutral view of all proposals. It's not our job to decide about whether the proposal is a good proposal or not. Our job is is to decide whether you think this proposal is a good proposal or not. We're not the arbiters of whether a proposal is a good idea, we are here to make sure that your decision is recorded and documented.

If there's some proposals which are closely related, then our job would be to provide some contextual presentation on that and control the time and order of speakers on the floor.

So we will do our best to make sure that everyone gets a chance to get a fair hearing. We'll try and prevent people hogging the mic, but at the same time, if people have important things to say, we'll do that.

We do have time constraints. We have three sessions, but we have been at the point before where those sessions have been barely long enough to get to the decision point and so on.

When you come up to the microphone to speak or you type in on Jabber or by whatever means you try and communicate your ideas, it's really useful to the Chairs for us to hear what your intervention is. Do you support? Do you oppose? Have you conditional support or opposition? Are you strongly in favour or strongly against? Or you don't have enough information? You know, I'd like to understand this.

So please when you get up to the mic, tell us who you are and say, "I strongly support" or "I strongly oppose" or "I'm fairly neutral about this propose, but", and so on. We do that because it helps us gauge the consensus.

Just some sort of good housekeeping and just to remind you -- Sunny talked about this the other day, but it's useful to remember -- there's nobody putting a proposal in here in any sort of malicious way. People have good intentions. They submit a proposal because they think they have a problem or they perceive a general problem for the community. We have different opinions, but we all are here for the same reason, to try and promote a good and healthy Internet and so on.

So normal rules of behaviour, polite, professional, respect each other's opinion, even if you disagree, state your affiliation and whether you support and ^.

If you are in the room and are nervous or reluctant to get up to the microphone, remember that you can join the Jabber room and submit your comments that way. At the moment, I think one of the staff is monitoring that. If you're nervous about saying, you know, I don't particularly want to identify myself because I'm sitting next to my boss who would probably disagree with me, you know, say that on your post into the Jabber room or whatever and we don't have to read your name out.

Some references about the whole process. I'm not going to sort of delve into all those. You can go and look those up if you want.

Just one final thing here. Just working definitions for minor objections. Some problems may occur for some members of the group. So if you're coming up to say, "I'm not sure about this, I think it may cause some problem for some people," that's a minor objection.

If you have a major objection, "This will break the Internet in this way", I encourage you to work together to resolve things.

Any questions on that?

I'm taking that as "no".

OK. So our Policy SIG action items. The first one we have is pol-32-01, prop-098 optimizing IPv6 allocation strategies (simplified). It failed to reach consensus at APNIC 32 and was returned to the mailing list for further discussion. There's been a little bit of discussion on the list prior to the meeting and we'll have a presentation on that shortly.

Prop-099, IPv6 reservation for large networks, again didn't reach consensus at the last meeting, but by the same token, there wasn't outright objection to it either, so it was in the balance, so we will look at that one again this time.

Prop-100, which was presented in Busan, was a proposal from Mr Agarwal here in India, which was looking at allocation of large address blocks on a countrywide basis. He and his co-author have decided not to present that here, so what we've actually done is close that item off. If they decide that they want to produce a revised version of that, then that would be presented at a future meeting. They have decided that they don't want to proceed with that at the moment.

Further, we are going to have a report on this, but pending approval of each stage of the policy process, the Secretariat will implement prop-097. This is the global policy that talks about movement of IP addresses between IANA and the different RIRs and how all that would work. It has been on our books for a couple of meetings now. We're in the process of waiting for that to be implemented. The process is coming to an end and Tomohiro-san will present a piece on that to us shortly.

This action item was about prop-096 which was about maintaining demonstrated needs and transfer policy. This was passed at the last meeting and was implemented before Christmas last year.

We also had another attempt at a global policy document policy, which was prop-69 at the last meeting. We recognised that that proposal couldn't proceed to finish because there wasn't agreement in all the regions, so we took steps to recommend to the Executive Council that they would can that proposal and get rid of it. That has been done and it's closed. Just following up on the work we did last time.

Those are the action items.

So any questions on those?

Good. Thank you.

So we'll go through this overview of the proposals.

The first proposal we're going to look at, these aren't in any particular -- I don't think these are any particular order. They're not the order we have them in the agenda, they just happen to be how they have come up.

They are it in agenda, they are it there order they're going to come up in the agenda, that's right.

So we have scheme brief summaries here, these are summaries that the Chairs have put together to summarise what the proposals are about.

The authors have seen these and agreed that these are a fair summary of their proposal, so these are documents that we have done so it's a brief summary of what's going to happen.

So prop-0101 aims to address these issues.

The portable IPv6 assignments -- that doesn't read quite right.

Portable IPv6 assignments are available only if the met work is currently or plans to be multihomed in the next three months. If you come along wanting a v6 assignment and it's going to be multihomed, then you haven't met the criteria.

There are technical and commercial reasons why some will not be multihomed and if IPv6 assigned -- a provider assigned IPv6 addresses are used, then if you change their ISP, you would have to re-number.

So the author believes that's an issue.

This is the proposed solution.

The.

If they have previously justified an IPv4 portable assignment from APNIC. That's in line with the policy we already have

Basically say the one click process would probably take you.

But if the organization doesn't have a portable assignment, then it would need to be accompanied by a reasonable technical justification, indicating why an IPv6 address from an ISP or other LIR isn't suitable.

So it's just seeking to broaden the scope here a little bit and only one IPv6 address block is to be given to an organization.

Subnets may be the the different site.

The APNIC sparse allocation so that subsequent requests could be accommodated by a change of prefix mask.

Just as some background for you there on the sparse allocation, Sanjaya presented something yesterday afternoon about sparse allocation.

We have another proposal talking about sparse allocation later in the program.

Any subsequent request must be accompanied by information demonstrating why additional space is needed, why an assignment from an ISP won't work. The use of a prove assignment generated the minimum number of prefixes in the global how that additional assignment would be managed to minimise the.

These are all criteria that are very similar -- OK, we have a problem with the transcript here, so we'll?

... eliminate these.

The HD-ratio leaves much to be desired as an address administration tool.

So there's a number of issues there.

The solution -- proposed solution is that utilization can be measured in provider allocation units. The smallest reassignment unit.

The measure of that is 75 per cent or more overall utilisation or one or more facilities has reached a 90 per cent utilisation and no blocks are available to expand.

So this is to replace the HD.

The other part of the solution, it's a proposal to allow LIRs to request nibble aligned blocks of any size greater than or equal to a /36.

So that means there would be 36 or 32 or/28, /24. A maximum to accommodate five years.

So the idea is that you would be looking for documentation out to five year window.

Subordinate LIR blocks account is fully utilised.

Any subsequent allocations can be expanded to the next nibble, so existing allocation really can be resized. The idea is you change the mask. This is optional at the provider's discretion.

It's important, I think, to note that that extra clause, the optional, is a change from the last version of this proposal.

Allocation won't exceed a /16, but a provider may receive multiple /16s to meet their justified needs.

LIRs are encouraged to vacate their old allocations.

Prop-099 aims to address these three points. Slow start policy allocates a /32 and then reduces the bit mask one bit at a time.

This causes fragtation and complexity in large networks with POPs growing at different rates.

IPv6 policy doesn't take into account long-term, up to five years, future growth.

The proposed solution is to do multiple prefix requests and that's something that's separately justified as per prop-083. Subsequent allocations are made within a reserved space as extensions to existing prefixes and/or new prefixes.

A reservation request for projected network growth up to five years is part of the proposal and that would allow long-term network planning and would allow for environmental factors. We'll hear more detail about all these proposals later. This is a brief overview of where we're going.

Any reservations that requested with this projected five year horizon would expire after two years, unless rejustified. Allocated prefixes would be registered in Whois. Reservations would be documented separately.

Prop-0102 aims to address ^ IPv6 allocations are currently based on a one to two year timeline, while beemployment plans are often based on a five to ten year time frag. Contiguous allocations aren't guaranteed. Sparse allocation is used operationally, but it's not mandated by policy and the exact Al gosm and parameters are not visible to members.

The slide I have here talks about this mandating the use of the sparse allocation when allocating IPv6 resources from APNIC address pools and so did the version 2 of this proposal. There has been a new version of this proposal sent to the mailing list and when the author presents in this afternoon, I'm looking at him to see if I'm getting this correct, this clause will be gone.

Dean?

Yep?

Dean Pemberton: Yep.

Andy Linton: The clause that you need to think about, the slide is shriek Li out of back here. ^ framework on the APNIC website as a numbered document and changes will be handled by the normal process, which is APNIC 112.

We also had one proposal which wasn't accepted for discussion. The author was Imtiaz Ahmed and he had a proposal a about a member state of APNIC could be a member of adjacent RIRs. So the two RIRs in question were RIPE and APNIC. His proposal was that a country should be able to choose their preferred RIR.

We discussed this and went back to the author and said, no, we judge this to be outside the Policy SIG charter. It's not to do with number resource allocation and we referred the proposal to the APNIC Secretariat who contacted the author.

So it is an illustration that our charter binds us to consider certain things and not others.

Just for your information, that proposal did come in.

Any questions on any of those?

OK. We're going to move to our last item, which is on community hubs.

Right now, we have some remote participants taking part in this in two remote hubs which are run by the APNIC Secretariat. These hubs are run in -- my mind has gone blank as to where they are, but where are the two, Thampika?

Sorry to those people, it's in Brunei and Vietnam. What happens often at this time, at the time of the meeting, there are some remote training sessions organised by APNIC in those locations, similar to the training sessions that go on here.

As part of that training session, a videolink is made available so that people who are at the training session can participate in the meeting.

Those are staffed by someone from APNIC and are organised by APNIC.

There was an approach at the last meeting from the Japanese community JPNIC members were seeking a a way to get more directly involved in the forum and there was a proposal to run a community driven hub in Japan, where people could get together, rather than sit at their desks looking at this one on one remotely, they could get together and perhaps discuss ideas during the sessions and so on.

There was some interest in other communities, interest from Australia, New Zealand and I suspect some others. But the idea was that people could take part in the process, in a hub that they had organised.

The hubs that the Secretariat run are well defined and we know what's going on there. Normally they're full to way video. Today they're not. They're one way and they accompany these training sessions.

The idea was that the questions, I suppose, that this raises is how would we manage that? How would we manage as (a) the Chairs and (b) the Secretariat, how would they manage having many remote hubs where we were trying to see what was going on, understand the feelings of those people and so on?

The Secretariat, if we did this, would provide a webcast feed, it would be browser based, broadcast video, audio and transcript and Jabber chat support were the initial ideas.

There's some questions there. Are we talking about the whole Conference? Are we talking about the Policy SIG sessions here? Are we talking about the member meeting?

I think it's in our scope to think about the Policy SIG sessions, but this may be something that gets expanded later.

We have some issues. The Chairs have quite an important, serious, difficult, whatever you want, task in trying to judge consensus. It can be quite a difficult thing to judge. Having people connected remotely might actually make this much harder.

Who would be entitled to take part in one of those remote hubs and would they be able to take part in the consensus decision? We are a large community spread over a large area, expensive travel and so on. Would that be a good thing to do?

Is there any danger that someone would run a remote hub, get 100 people into it and then try to sway decisions in a way that is less easy to do in a room like this, because we can actually see who's here.

Should we do a test trial of this?

What would be the requirements to host? Can anybody do this? Does it have to be -- what would be the criteria? What facilities would need to be provided? What support from the Secretariat?

The questions really for this room are: is this something that we feel would be a useful addition to the things we do? Would it complicate life so much that we'd never make any decisions, we would make bad decisions? This is really a question -- is it a community or a Secretariat decision? Would we like to see this happen and on what basis?

I haven't got answers for all those questions. Really I want to put those questions in front of you. I think it's something that we need to think about, discuss and so on.

The break for morning tea is at 10.30. So we've got a few minutes to think about this and talk about it, if there are any questions or concerns.

As I say, this is a proposal from some members of the community and I would be interested in any views or opinions on that or do people say, "That's OK. I don't care." Or what? Any questions or views on this?

James Spenceley: Just personal opinion, if somebody wants to host a remote hub, let them host a remote hub. I don't think it's something we need to have a policy or major discussion about (APNIC EC ^.

Andy Linton: James, I would have a question for you, then. The Chairs -- at a remote hub, it just happened to be a remote of people watching this together or are they part of the decision process? This is the question really that this comes into. Can we make it part of?

James Spenceley: I don't see why not. Somebody can email the mailing list and that's considered part of the discussion or somebody can talk on a Jabber room as part of the discussion, so if people want to get together, you know, I just don't see why this would be a problem. I support it and more participation is good.

Andy Linton: Any other views on that?

Skeeve Stevens: Andy?

Andy Linton: Sorry, Skeeve.

Skeeve Stevens: Just responding to James' comment, one of the important things to us is accountability and with remote hubs, what does a hub mean? Is it indeed just a group of people? How do we measure consensus? Resourcing, finances from APNIC is is there going to be an APNIC staff member at each one, like at the moment there is an APNIC staff member in Brunei and Vietnam. If we have 27 hubs, how do we do that? How do we make sure that the consensus is fair in the room if we are calling for it? We need to be able to some time measure that and obviously if you've got 27 different video feeds or Jabber chat participation, we've got to know how to do that. So that's where some of the difficulties come into us. We want the absolute maximum participation to be able to gauge consensus. The numbers are pretty low here today and I would be happy if there were hundreds out there that were actively participating, but the technical solutions on that and the costs involved are something we need -- we really need the community, whether you guys have people at home in your own countries, to know whether they would be loving to participate, so we know that it's worth putting the money into it.

Andy Linton: Yep. And the effort, I think.

Dean Pemberton: InternetNZ. I think it is a really good idea and will mean that a lot more people from throughout the community get a sense of involvement. Andy mentioned before the chance of maybe doing a trial, so I think if there are economies out there that are willing to do their end, that we look at maybe having a little bit of a trial for the next meeting and see how it goes, without committing to all of the stuff that Skeeve has mentioned.

Izumi Okutani: JPNIC. I just thought I would share what kind of consideration is made in Japan. Actually, this is an idea that we've been discussing with our policy working group. We also have our own forum and our working group Chairs have been considering this too so that people in Japan, who we usually discuss in JPNIC open policy forum, can also directly participate in APNIC forum as well.

The issue that we are facing at the moment is how we can have a local moderator while, like, myself and most of those people who are directly involved in policy would come to APNIC meeting and then at the same time, have somebody who can do good moderation between the remote hub and the APNIC venue itself. That's the kind of issue that we think is a big topic and I can also certainly understand some of the issues that Skeeve has raised, but still there's an interest, so we hope we can find a way to make this happen.

Andy Linton: Anyone else?

There have been three or four people who have made useful comments here and thank you for that.

Can I get some sort of feeling from those in the room who would like to express an opinion, what they think of this? If we were to go ahead with, let's say, some initial limited test with this, you know, one or two community remote hubs, to see how this worked, would that be acceptable to the community?

Go on, put your hand up. Don't be shy, you know.

By the time we sift out all the staff and so on, who would be against this?

Thampika is relaying a question --

Champika: It's not a question, it's a comment ^ it's from David Woodgate ^ in discussions as long as (a) it is is clear that they are anticipating in discussions as individuals and not Chairs (b) it is made clear that their opinion has no more weight than any other individuals.

Andy Linton: Could you just give me those again? Just so I can relay them back.

Champika: Yes, that's for the previous --

Andy Linton: The two.

Champika: Yes, (a) it is clear that they're participating in discussions as individuals and not Chairs and (b) it is made clear that their opinion has no more weight than any other individuals.

Andy Linton: OK. Can we ask, is that related to the comments that Skeeve made or any comments that I made? Just curious.

Champika: It is for the comment that Andy made, as far as I can make out.

Andy Linton: OK, all right. Sometimes it's difficult to split those two things. I mean, my personal opinion on this is -- and I make that very clear, my personal opinion on this is that along with James and along with Dean, that widening the scope of our discussions seems a perfectly reasonable thing to do. The question that I have as the Chair is to what degree do we include any comments or any participation by remote hubs and how do we count it?

We take it into account when we go for calls for consensus. If we allow people to.

Including their participation and consensus process. So there's two parts to that. There's my opinion as the Chair and there's my opinion as an individual. I hope that doesn't confuse people too much.

We have been asked to look at this by others, by JPNIC, by two other groups have suggested -- three other groups have suggested they would like to do this and so I'm asking the community, do they approve of us doing this? I have not seeing strong objection to us doing this. To some degree, we can't stop someone doing this because they can take the feed and sit in a room and look at it.

Martin Levy: Hurricane Electric. Could I just say that there is maybe a two-step process here. One is that it should be easy to write a document within APNIC that would say this is best practices for any form of remote participation, somebody could do this in their living room, there is no need for it to be official and then the second part then would be to take it to the next level of saying if you want to have it -- I hate to use the word sanctioned, but to make it more official, then to have the next step, which is what APNIC would like to see, in order to promote it even further. But it doesn't stop anybody doing this remotely, whether they are inside a company in a Conference room or just a bunch of buddies at home. But best practices document, a very simple one page, you should have a Jabber, you should have the video, you should have the text. Something like that. You should say who's there. Something like that would be an easy document to write.

Andy Linton: Are you suggesting that we should have a document like that prepared for the next meeting in Phnom Penh and perhaps run a trial at Phnom Penh as well or are the two steps --

Martin Levy: I think the subtle message I'm trying to make is don't make this too complicated and step 1 would simply be how would you like people to run a remote hub, that isn't different from how you run it with an official remote hub, with maybe somebody from APNIC there. There's a two-step process there. But getting that first document would at least get people to understand what is necessary, minimum would be what is necessary.

Andy Linton: That's a good idea, yes. Would people in the room support that idea of Martin's of producing a document to describe this?

James Spenceley: Just not sure what we've trying to achieve here. I support Martin's idea of writing a little brief summary, but in reality, if 10 people from a company want to get together in a room and watch the feed and contribute, I don't know that we immediately need a formal process for that. We have already suggested that we can have anonymous comments from Jabber, so in reality, we've opened that up completely to anyone commenting without any accountability, so why now are we placing so much structure around a group of people getting together to comment? I think we should encourage this.

If anyone wants to host one for their work or for their community or their region, absolutely do it. They can each log-in to Jabber or arrange for a webcast or something to be set up in the room. I just think maybe we're taking this a step too far in terms of structure. But I'm happy to see if a document is produced.

Andy Linton: Any other comments on that?

What I'm hearing here is that this is something we can do anyway and people can do anyway and it may be useful to have some recipe here for people or some document that describes some ideas of how they might do this well and document what we offer and what we can do and where we can help.

I bring it up because, you know, members of the community asked us about doing this and there were some questions about how it would be done. So mostly for information, really, but I was keen to understand I think we all were, to see how useful this would be and I'm hearing some indications that it broaders the scope of our reach, that's good.

OK. I think that takes us to the end of our morning session. I believe there's tea outside, so see you back here -- if we can get back on track, we had a late start, but this session has sort of caught us up, so we can get back here on time for session 2.

Thank you.

APPLAUSE

Session 2 Begins

Andy Linton: In this session, we will be moving on to two of the proposals. Before we do that, I have a Policy SIG Chair report. It is not a formal report about what we have been doing and so on, but let me go through.

The three of us were elected at the last meeting in Busan, and during that process and since then, there are a couple of issues we have noticed make life perhaps difficult for the Chairs or things that we think there are some potential improvements. We want to share those with you, to see if those are things that you can help us with or take some of the proposals or ideas that we have here to try to help the process.

We want to make some comments on these three issues -- the election of Chairs and Co-chairs, measuring consensus and implementation considerations from proposals. I will go into more detail.

At the last meeting in Busan, I had been acting Chair for about three months, I had become a Co-chair six months before the Busan meeting, so I was still, to some degree, feeling my way through the process. I stood and was returned unopposed, but we could have had an election there quite easily.

My two Co-chairs were elected into the role and took on the task immediately. So it would have been relatively straightforward for us to have been in the position where the three Chairs would be on the stage here, having just been elected one minute beforehand, and that causes some problems.

My two Co-chairs -- I had met them before and we had had a little bit of discussion before, given that they were candidates, but we had not had a chance to sit down and talk to each other and work out our dynamics and who was going to do what and that sort of thing.

We get driven to that because of a line in the SIG guidelines that the election must be held at the upcoming SIG session as the first item on the agenda. The natural progression from that -- it does not say so -- is that you have the Policy SIG election and those people are elected and they take over.

The question we have is what if we were to have the Policy SIG Chairs, the new ones, take up their role at the end of a session? The reasons we think that may be useful, the incoming Chairs would have a chance to study the meeting. You would assume that they had been at the meetings before and had been participants, but being a participant at the meeting is not the same as chairing it. They would get a chance to study that, talk to the outgoing Chairs and so on.

One of the issues that we saw, and we see still, incoming Chairs have to take on the consensus process halfway through. So the consensus process deals with the comments on the mailing list, then you go to the meeting and so on. We generally feel that it might be better if the Chairs took up their position at the end of the meeting.

You might be cynical and say, these guys just want the Chair for another meeting. That would be a boundary case, a cutover case. I can assure you, by the time I get two years into this, I would probably have had enough chairing these, but that's OK, I don't mind. It's not for that reason. We think this would be a better result.

We could just agree that at a particular meeting or we could go out and talk to the community or so on. We could leave the election being the first item on the agenda, but with the clear understanding that it is for the Chairs to take up their role at the end, or we might move it to the end of the session and say, let's do it then.

If we had tried to do this this morning as the first item on the agenda, there would have been no one here to make the decision.

Our other question for you was: how should Chairs be elected? The Policy SIG Chairs and the Co-chairs have a responsibility to the whole community. We have a responsibility to the meeting, to the remote hubs, to people on the mailing list, people taking part on Jabber and on streaming stuff and the whole wider community.

Our feeling is that this role -- we are not trying to talk ourselves up and make ourselves more important -- but this role can have a major impact on the direction of things at APNIC. Is it appropriate for it to be a show of hands in a room which is relatively sparsely populated by the population?

We have a different process to put people on to the NRO and, say, the ASO, where we have a vote beforehand by members, then there is stuff that happens in the meeting as well, you need to be registered for the meeting. There is a potential for someone to wheel in 20 or 30 of their friends into a meeting and say, "I am voting for him because he's my boss" or, "He's my friend" or, "He comes from my country", or whatever. There is a potential for that and I would hate to see us be in a position where that was the way we elected our Chairs here.

One of the questions is, maybe we should think about that. We raise these issues with you because these are things that we see as potential -- "problems" might be too strong, but things that could be better.

Measuring consensus. We have spent a chunk of time over the last two days talking about what we mean by measuring consensus. I know that other Chairs and other people have had long discussions about this.

I noticed in Busan, when I asked for consensus, we had actually a much bigger spread of people in the room than this one. At times, we had only a few dozen hands up. Who strongly supports this? A few hands. Who strongly opposes this? A few hands. Who doesn't mind? Nobody.

Again, this is a difficult one for the Chairs to look at. There are a number of people here who work for the RIR, for APNIC and the other RIRs, or work for IANA or whatever, and it's not appropriate for them to express an opinion. I am not picking you out, Elise, honestly. But it is not appropriate for them to express an opinion.

Does a room with no hands up mean that nobody supports this? Does it mean that nobody cares? Does it mean you are too busy reading your emails? What does it mean? That's kind of hard.

That gets interesting as well when we look at the remote hubs or people connected at their workplace or at home in the evening or whatever.

We touched on this when we had the brief discussion before the break about the remote hubs, how would we judge the opinions in there? It's a question that we have.

We might consider using something like this URL, http://meetings.apnic.net/33/policy/consensus-test.

We have mucked this up, but you can see that when we came to the point where we asked for consensus, we could say, "Prop-099," title of the proposal, maybe a link to the proposal and so on. We could then ask people to click on the links and express their support.

If we can click the link at the bottom, as you see, some people have dived in -- I am guessing two at this point. But this is not a count, it is a tool to help us gauge this.

We think it may be useful for us to look at something like this. It would not necessarily be exactly this tool, but something along these lines. It would help the Chairs to look at things and say, "OK, those people who were too shy to put up their hands or come to the mic or for reasons, can express an opinion here without exposing themselves to whatever issues they think are a problem."

The question for the group here: is this something that is so far out of left field that you think it is shocking and you strongly oppose?

I will go through the other things, then we can have some feedback on these ideas.

That link will be there after we have finished the discussion. One way to do this is to go there and say, I think this is a reasonable idea or not.

One of the other things that we have talked about is that in some of the other RIRs, in RIPE and ARIN, as far as we can work out, when a proposal comes forward, our documents have a pros and cons section, for and against -- these are the benefits and these are the disadvantages.

The other RIRs, those other two, at least have something in there that says, "These are some of the implications for implementation."

During the open policy meeting, when we have a proposal, one thing we do is ask one of the members of the Secretariat -- it is usually Sanjaya -- to say are there any roadblocks or major issues or things like that? This is just a verbal report that appears here. It does go into the transcript, so it is a matter of record and so on, but we wondered whether this would be something that would be useful to those people participating on the mailing list or who were not here in the meeting.

We had some discussions with -- the font on this is small. Internally, the Secretariat prepare a report on each proposal, and there are some questions like, "What sectors of the community does this affect?" "How does this affect MyAPNIC?" "How does this affect the Whois Database?" And so on.

I have seen the ones for the current proposals. I won't put them up here now, because we have not discussed them, but often the results are "yes" or "no" or whatever, so they may not be particularly useful.

It would be fairly difficult for us, if we came up with some policy proposal which was going to cost a major amount of either dollars or work or whatever, we might get -- it might be useful for us to know this stuff. Again, we ask the question: does the community think this would be useful?

What we would anticipate here would be that a proposal comes in, it is posted to the mailing list and there is a response from the Secretariat, probably via the Chairs or possibly not, shortly after that they say, "Here are the implications." Then people will be working from a position of knowledge.

Again, this is a question: do you think that is a useful thing? Do you think it takes us into a place we don't want to go? Really, I am just seeking your views on that.

Again, one of the things we think is our responsibility as the Chairs is that if you have other concerns or improvements, things that really bug you about the process, raise it with us, either talk about it here or talk about it on the mailing list and so on. So there may be some things that you think about our process that could be improved.

I mentioned this morning that I was reluctant, if we only had a very small number of people here, to go for decisions on consensus on our proposals. For us, trying to find ways of improving our consensus process and our engagement and so on is highly, highly important.

If we go down that track, the sort of thing we envisage would happen is at this meeting we present our view, ask for the community views on any other issues. We have briefly shown you this tool for consensus. If there are any issues raised here, I think it would be appropriate for us to report those to the AMM tomorrow, and also further discuss it on the list.

If we were to go further for this, and again I am seeking guidance, we would need community feedback and possibly something from the EC. If there are changes needed, there are two parts of this that might need some tweaking. There is a policy development process which is a very formal process, because it is a current policy document, so we would have to go through that normal process.

If we wanted to make any changes, amendments or additions to the SIG guidelines, we have a couple of issues there. The SIG guidelines are written for all the SIGs, not just for the Policy SIG, so it may be appropriate for us to fork word that and have a policy guidelines SIG document, and the question of which one overrides which and so on.

It is not clear whether the document should become more formal. One of the things in the guidelines, there is no direction as to how to make any changes to it. The document is eight years old, we are not saying it is massively broken, but there are some details that might bear some scrutiny.

At the next meeting, we have talked about the remote hubs. We might look at demonstrating that extended remote participation, if we could. Again, if we look at the issues we have talked about, if changes are needed to the PDP, that is where we would bring them up, and similarly with the SIG guidelines.

After the next meeting, if there were some issues there then we would -- if people agreed with they will, we would proceed to implement them if we got endorsement.

I would like to ask people, are there any thoughts on those. This is the first summary slide.

Masato Yamanishi: Andy, one thing about the staff analysis. Regarding the staff analysis by RIR staff, I think ARIN and RIPE already have similar mechanism. I do not know about the details of RIPE, but in ARIN's case it is presented in the policy meeting as part of the introduction slide of each proposal, but it is not shared on the mailing list before the meeting.

Andy Linton: If there is any information from the other RIRs about what they do here, that might be useful to us. I see Emilio.

Emilio Madaio: Emilio Madaio, policy development officer. There is a main difference of the PDP of the RIPE community and all the others. We make all the decisions in the mailing list. So in the mailing list, most of the input that is received on the mailing list, we announce that we performed the impact analysis that we publish, together with a proposal online.

There is a presentation during the RIPE presentation made by the proposer, and there can be mentioned to the impact analysis too. Although the impact analysis is already published online and it is supposed to be already in the community's knowledge.

What I wanted to add is that the value of the RIPE meetings is just the face-to-face discussions, and some more conclusions can be reached. But again, most of that input is then taken into the mailing list.

Andy Linton: Thank you for that. That's useful clarification. Is there anybody from ARIN who can comment on what happens there?

Einar Bohlin (ARIN): Einar Bohlin, a policy officer for ARIN. We do post it on the mailing list. The assessment is comprised of staff understanding, staff comment, legal comments and a resource impact statement -- essentially is anyone going to need extra personnel, hardware, code, et cetera, to implement the policy. That goes to a list, it is on our website, and it is also in a document we produce for our meetings, called the discussion guide.

Andy Linton: Thank you. I would like to understand -- is there anyone here in the community, in our community -- I am not saying our friends from ARIN and RIPE are not part of our community, in a sense -- but is this something we should look at, would this help on or hinder our deliberations, or would it not do any harm?

Izumi.

Izumi Okutani (Jpnic) (JPNIC): Izumi, speaking as an individual. I think it would be helpful to have some kind of analysis on the impact of resource management within APNIC or other factors, like additional cost or any legal impact on APNIC. It does not have to be detailed, as in having all these items, but it would be helpful to have some overview of analysis from APNIC staff. That's my opinion.

Andy Linton: Izumi, I have posted this to show that this is what APNIC -- this is their template. When we saw the results from this, many of the sections here had "No" or "No effect" or whatever in them. If the Chair had a report from this, we could summarize that report. This is the sort of information that is available, but we would not necessarily have to show all of it. A simplified report, absolutely.

Any other thoughts on that?

Desi Vali (Net4): When you say measuring consensus, what is the difference between that and voting processes, as far as your interpretation is concerned?

Andy Linton: We talk extensively in this community about reaching consensus, rather than voting for something.

They are both ways of measuring support, of course. But a voting process would say, if there were 100 people in this room and 51 people said yes and 49 people said no, we would have a vote and the majority would decide. But if you have 49 per cent of your population who are very unhappy about it and believe it is a significant problem, it does not bode well for taking the thing further.

The use of a consensus process is absolutely an historic thing, it is what we have always done, but the idea is it that we are looking for a very large majority of people to believe that this is the right thing to do, or not. So you may have some people who don't agree with the decision but they have had a good hearing and the majority here -- it is a very woolly term in a lot of ways -- a very large majority believe that any objections are either wrong or they are not material or whatever. I think that is the big difference between these.

It is a very difficult area. It is a very difficult area for us to look around this room and say who agrees and who does not.

Perhaps one of the questions the Chairs have to ask of the community is, at some point -- how do we measure consensus? We need to keep at this and work it out, because it is a continual question of what we mean by consensus. Your view of it and my view of it may be different, and the view of other Chairs.

I do not profess to have a 100 per cent answer on this. The process is one of engaging the opinions on the list. The people in the room, the remote hubs, Jabber or whatever, and deciding that the will of the community is to go this way.

The job is available -- it is not available at the moment -- but it is not an easy task. Does that help explain? So it is a very large majority, I suppose is really the question, and we leave it vague.

Let me go back to these individual questions, and ask people to express an opinion here.

Would there be a downside if the Chairs took up their role at the end of the policy session rather than the start? How many people believe the Chairs taking up their role at the end of the session would be a better thing to do? Can you put your hands up?

I'm seeing a few hands on that.

Do many people think things are perfectly OK the way things are, the Chairs should be voted in, then take their seat? And do many people don't care?

Maemura Akinori: Sorry, I did not recognise your question. I think you should ask the question again.

Andy Linton: The question is: if the Chairs were to take up their role at the end of the Policy SIG session, would that be a good thing? Would that be an improvement on where we are now? Could you support that, or not?

Maemura Akinori: Let me clarify. That means that the election is held in the beginning of the Policy SIG but the existing Chair, the outgoing Chair, would be chairing that SIG until the end?

Andy Linton: Yes.

Maemura Akinori: And the role is until the role is handed over to the new Chair?

Andy Linton: Yes, and the Co-chairs as well.

The question for us is to publicize this on the mailing list as well, so people who are not here can know about that.

When we come to a future election, which there will be one in Phnom Penh in Cambodia at the next APNIC Meeting, we would look to do something on that basis. Is that something everybody is comfortable with? Is anybody not comfortable with that? If you really do not like that idea, let me know.

Skeeve Stevens: We should probably state the actual effect of that, when we are doing it.

Whenever we choose to implement it, the actual Chairs, those that would be expiring that term -- no, sorry, it doesn't matter when it happens, all Chairs will be receiving one meeting extension.

Andy Linton: Those people will be at the meeting anyway, to some degree, but the question will be that they will Chair the session and then finish.

Che-Hoo Cheng: I just want to clarify what you are talking about. You are talking about, let's say, for example, there is an election but the existing Chairs will chair the same meeting until the end, then the newly elected Chair will take up. But there will be follow-up work after each meeting, and who will be in charge of the follow-up work?

Andy Linton: Yes, because effectively there is work that goes to meet with the EC after the meeting, and there is also the monitoring of the mailing list until the end of the comments period. Is that your question?

Che-Hoo Cheng: Yes, that is my question. There would be follow-up work on the mailing list or further discussion or whoever. I think we need to have a very clear proposal before we can answer your question.

Andy Linton: Really what I'm looking for is the principle of this, is this in principle a reasonable thing to do? Given those caveats, I am not seeing major dissent on this, but this is perhaps one we can look at.

This business about the election process is a much bigger question, and one that requires more consultation with not just this group but the rest of the community.

I raise it because there is a risk here to the position of the Chair, and the community should be aware of it. So that is really what I want to do there.

What we will do is go out and publicize this link, http://meetings.apnic.net/33/policy/consensus-test, and we will look to see what results we get from this and see if we take it further on the mailing list.

Any major problems with doing something like this, using the web page with the radio buttons?

Skeeve Stevens: Just a clarification from Jabber earlier on, there was a question whether we consider doing this today?

Andy Linton: No, we have no intention of doing this at this meeting. This is flag raising, to ask whether this would help us with our deliberations. There is no intention to do that.

Again, we will investigate this, because I am not hearing any major dissent about the idea of producing something that talks about the possible impact on operations and the Secretariat.

We will move on to our first actual policy item. I will let the staff get the slides for that.

From memory, this is prop-101.

This has been proposed by David Woodgate. It has been on the mail list and there have been a number of comments on there. Dean will come up and be the magic finger to move the slides on. David will present this remotely over Skype. We will see how that works. I hope we have David online. I am seeing a sign saying, yes, we have.

David, can you hear us? Can we hear you?

David Woodgate: I can hear you. Can you hear me?

Andy Linton: We have you on screen. Dean is here to do the next slide part. Let's hear David's proposal.

David Woodgate: Thank you. I hope everybody is having a great time in New Delhi. I am sorry I can't be there myself.

I cannot see the slides on the screen at the moment. I will refer to my own computer.

The idea of the proposal is that we remove the multihoming requirement from the existing IPv6 portable assignments policy.

Dean, if you could bring up the first slide, that would be great.

The current problem is that section 5.9.1 of the IPv6 address allocation and assignment policy document currently requires that an organization is multihomed to multiple providers or AS numbers before being eligible for IPv6 portable assignments.

There are certainly cases where not all organizations are multihomed and, unlike IPv4, IPv6 addressing models tend to assume a much deeper penetration of public addresses into a network than IPv4. So we are not talking about just numbering around the edges at NATs or DMZs as we have been used to with IPv4.

Not all organizations who would like to be able to use dynamic IPv6 addressing, we hope that a lot of small companies probably will be able to use prefix allocation, but it is unlikely that all of them will be able to.

Some organizations are unlikely to have statically addressed networks that are just too large or complex to manually renumber with a change of provider.

That basically means if you are in a situation where you have a complex network or a statically addressed network, that is in the habit of receiving its Internet connection from one ISP, then the basic options are either receiving the LIR addresses, in other words the addresses from the ISP and numbering your network from those addresses, which if you then can't renumber later, effectively commits you to that ISP for a long, long time, and possibly permanently. Or else you have got to request multihoming when you previously haven't had any requirement to -- that is obviously extra cost, both in terms of the actual second server that is concerned and also in the technical complexity of your own network.

Next slide, please. The situation in the other RIRs is that APNIC is the only remaining RIR that insists on multihoming for portable assignments.

If I consider what AfriNIC has, in their policy for IPv6 provider independent assignments, for end sites, all they basically say is that either a holder of IPv4 PI space will qualify for IPv4 PI assignment, and as far as I can tell from their policy for end user assignment also in the AfriNIC service region, they do not generally require a demonstration of multihoming, except if you are trying to be a critical infrastructure or specialty exchange points.

ARIN has quite detailed requirements for IPv6 provider or criteria for IPv6 provider independent assignments. Basically, if you are either an IPv4 -- have previously received an IPv4 end user assignment or you are multihomed or you meet criteria of either 2,000 IPv6 addresses plan to be used or 200 /64 subnets to be used within the 12 months timeframe from assignment or, failing that, providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. In terms of those technical justifications, they provide examples within the document but they are still examples, obviously.

In LACNIC, the options are you have either previously received IPv4 space, or else you are not an LIR or an ISP, and basically provide detailed information showing how the requested block will be used within the following three, six and twelve months. Again, no multihoming requirement.

In terms of RIPE, RIPE has just removed the multihoming requirement as of January. In RIPE-545, and basically as part of that they just don't require -- there is a fairly minimal requirement placed upon that. They talk about limiting the size of the at the same time to /48 and needing to meet contractual requirements for provider independent addresses, but it is in the broad statement of a request properly submitted, either directly or through a sponsoring LIR. They say that PI assignments cannot be further assigned to other organizations.

The proposal is to remove that absolute requirement for multihoming for the assignment of portable addresses and replace it with the following criteria: that you must be APNIC members or have signed non-member agreements; that you would be automatically eligible if you had previously received IPv4 portable assignments; or a reasonable technical justification is required to demonstrate why ISP/LIR assignments are not suitable; minimum /48 to be assigned, more if needed to have a plan which stays below the applied HD-ratio threshold specified in the APNIC document; and in order to minimise routing impacts, to assign only one prefix on an organization initially, where subsequent allocations are dependent on demonstrates of good aggregation practices; and to have APNIC recommended to use sparse allocations to simply change the prefix lengths, rather than requiring additional prefixes for any subsequent assignments, where possible, of course, that may not always be possible.

The clear benefit is removal of a potential complexity of IPv6 addressing for some classes of organizations, which may discourage them from using IPv6, and also consistency with other RIRs; and making sure we have a consistent global approach to this. Insofar as you are seeing that there is no general consistency about the criteria, but removing multihoming as an absolute one would at least put one point of consistency across the globe.

The risks are the potential explosion of IPv6 routing tables if removing that requirement resulted in the excessive applications for portable IPv6 assignments, and that would have a flow-on implication that the potential workload would increase in the APNIC Secretariat and an explosion of APNIC membership numbers as well, of course.

In reality, I at least strongly suspect that the costs of APNIC membership, both the initial upfront costs and the ongoing costs, are going to discourage casual or frivolous requests; that only people who really currently comply with the requirements or cannot use LIR assignments will be coming to APNIC for such blocks.

I am assuming the implementation timeframe of three months from consensus as usual and also assuming that the changes are just to section 5.9.1 and for any forms used for application of portable assignments, this is an APNIC-specific policy and it would be the choice of each NIR whether a similar policy would be adopted.

Are there any questions about that?

Andy Linton: Does anyone here have any questions or comments on this?

Martin Levy (Hurricane Electric): As no one else came to the microphone, we support this. Thank you.

Izumi Okutani (JPNIC): In conclusion, we support the proposal with the condition that the Secretariat gives like a constant update, maybe once a year, or every APNIC Meeting, on the impact of this proposal; whether the number of applications have really increased. The reason behind it is that I have talked to a few operators in Japan and they feel a little bit still concerned about the impact on routing table, but it is not a real concern at this stage. So it would be a good idea to be able to monitor the impact and if there is anything we are concerned about, we can always review the criteria, but it is fine to go ahead with it at this stage.

Valence (IDNIC): We agree with this proposal about the fee of the registration, I think APNIC will not charge the membership registration if the company only applies for IPv6, maybe we need clarification on that from APNIC.

Andy Linton: Can I clarify, are you asking for a change in the fee structure here for these blocks?

Valence (IDNIC): I heard, when the proposal was explained, one thing that will -- the registration fee for membership for APNIC will decrease the company that will apply for IPv6 initially, but I think APNIC has a special policy for the registration fee?

Andy Linton: I think -- I hear your comments, and I am sure the people in your room hear comments, but it is not our job to set fees in this group here. Our job is to look at the policy. So the fee setting would be different. Sanjaya, perhaps you can clarify this.

Sanjaya: He is probably referring to the one-click IPv6 promotion that the APNIC Secretariat currently has. It is operational; I agree it is not a policy.

Andy Linton: Can I ask the previous speaker, do you support this anyway, and the fee thing would be something else you would seek to look at in a different forum?

Valence (IDNIC): Yes, we support this.

Terence Zhang (CNNIC): First I have some questions, the details of the proposal, they have a few convictions, I think, from condition A to condition D, and some of the conditions are like either/or conditions. I am not sure if other people can understand it very well, because when I asked this in the mailing list, I understand that B and C are like either/or, and then others, they have to meet A and D, something like that. So if you list this way, I am not sure if it is quite clear in a policy. That is the question first.

Andy Linton: Terence, the conditions that are on the screen at the moment in the proposal, these are the ones you are talking about?

Terence Zhang (CNNIC): Yes, condition A. I understand that the intent here is like if the organization can be condition A, the organization must meet the condition A, B or C, and then D or E, so it is like a little bit confusing just to myself. I am not sure if that is it is clear to everyone else.

Andy Linton: You can perhaps tell me, because on the mailing list you said the conditions that are on the screen, the automatically eligible if previously upheld, and a reasonable technical justification, you asked for clarification whether that was either/or. I think David on the list agreed that was either this or the other one.

Terence Zhang (CNNIC): Yes. I understand it. I am just asking that the format of this -- I am not sure if it is clear to everyone. It is just a question.

Andy Linton: At some stage, if this were to proceed, the Secretariat would draft an editorial. Would that satisfy your requirements? If this block was written more clearly, this text up here, had the "or" in the right place, if that was fixed, do you support this?

Terence Zhang (CNNIC): Yes, it doesn't affect it I support or not support, yes. Then I would talk about my comments.

Andy Linton: Sure.

Terence Zhang (CNNIC): Currently I support the intent of the proposal and I do not think the multihoming requirement is absolutely necessary, but I do not support the whole proposal as currently written, because I think the current criteria is just like a reasonable technical justification, or something like that.

I think the criteria should be clearly defined and variable. Reasonable justification is hard to evaluate the impact. That is my general idea about the proposal.

Also, I want to talk about some concerns CNNIC has, and we talked to some providers in China and they have concern about the impact.

What we can see, the impact and the benefit of this proposal, we think the proposal is like -- when we try to figure out a position, we try to see what benefit can be achieved by this proposal and what is the potential impact. So I am going to talk about the benefit, what we can expect, and then what impact we expect.

The benefit here, I understand, is easy to renumber, I think that is the benefit. I understand the requirement to renumber, but currently I do not think this benefit is very significant because, first, technically in IPv6 we have some features, other than different from the IPv4, so you can support something like multiple prefixes in the same interface, and also the address has a lifetime, so these kinds of things can be renumbered easier than IPv4.

I think in IPv6, if the level of planning, address planning, has to keep in mind about the future requirement of numbering, the number itself would not be that difficult.

So I do not think the benefit is significant, and also practically, in APNIC regions, the IPv4 assignment policy is different than other RIRs. In the APNIC Region, an organization can only receive a portable IPv4 assignment under the assignment policy, which is multihome and ISP and critical infrastructure. Therefore, in the APNIC Region we do not have too many people who have portable IPv4 assignments before. This is different than other RIRs.

In other RIRs, the IPv4 assignment policy is different. Maybe for some people they are entitled to get an IPv4 assignment, but if they are not entitled to get a portable IPv6 assignment, that might have some impact to their acceptance of IPv6.

But in the APNIC Region, I do not think it is easy, because all people, if they have a portable IPv4 assignment before, they are entitled to IPv6 assignment, because the current eligibility criteria is the same.

So if they are not entitled to receive a portable IPv4 assignment, I do not think they are looking for a portable IPv6 assignment. So that is why I think the value, the benefit, of this change is not that significant.

Also, I will talk about the impact, what we see, and also we have talked to some providers in China, and they have the same concern about the impact, versus the popular use of the portable /48 assignment will make a route application less likely.

Then the other thing is the difference between the IPv4 assignment and the IPv4 allocation is not that significant, because the minimum IPv4 allocation, the minimum is /22, the minimum assignment size is /24. So even if those people get /24 assignment, that won't have a significant impact on the routing table in IPv4.

But in IPv6, the minimum allocation size is /32 but the minimum assignment size is /48, so the potential impact to the routing table is significant. We can just predict the impact on the routing table using the model of the IPv4 assignment currently.

I think the potential impact of the routing table -- I am not saying it is certain to happen, but it is very likely to be a problem.

Andy Linton: Terence, I am conscious of other speakers in the queue and I would like David to have a chance to respond to you. Do you have a lot more you can cover?

Terence Zhang (CNNIC): I have two more points.

Andy Linton: I am absolutely hearing your concerns about the routing table growth, and I am sure the rest of the room is. Can we keep it tight?

Terence Zhang (CNNIC): Another concern is we use the /48 more popular, some organizations, they think about the slicing of their /32 allocation into pieces, just like we have in IPv4 currently. So that is another impact we have to consider.

That is why I think the benefit is to a small number of organizations who are trying to renumber, and the burden of the increase of the routing table having to replace on every served provider who is running a network. That is why I don't think it is worth to take the risk of the impact to achieve the not that significant benefit.

That is my comments.

Andy Linton: Thank you for that detailed explanation of your stance on this. David, do you want to respond to that?

David Woodgate: As far as I can remember the points.

Just addressing a few things, I agree with Terence that there is a potential in the industry for several models to away rise with IPv6 addressing, however we have not yet seen them and we are trying to encourage new businesses to take up IPv6 at this point. So the problem we are faced with is that, although capabilities like multiple addressing and, who knows what will come into the future, maybe even address translation with a unique local addressing will come into vogue at some stage.

The reality is, whatever may come in the future, we do not have that now. So when we are trying as an industry to approach businesses and say, "Isn't it time you thought about adopting IPv6?" And you have to answer the question, "Well, what's the addressing look like?" You will say, "Well, you are going to address most of your network, rather than just the edge, as you have been, and that's likely to have a long-term impact upon what you want to do with the choice of provider."

Now, the other RIRs have removed multihoming to remove that particular restriction, so that at least you can -- at least businesses are likely to be able to get an addressing block of their own, if they really think they need it.

I agree with Terence that we are expecting this to impact a relatively small proportion of businesses. Now, of course, when you speak globally, it is hard to put a number on what a relatively small proportion meanings. But because it is a small proportion, I expect that it will not have the burden that Terence seems to be expecting. It is one of those things that, as Izumi said, time will tell, and we have to monitor route table growth generally.

Frankly, I think we need to monitor route table growth, whether we have this proposal in or not; we need to keep careful attention to it.

Andy Linton: David, I think we are going over stuff that you have already covered in your presentation. So I am going to stop you here, because we are starting to run tight on time and I have other people who want to comment. I will give you a chance to summarize a little bit at the end.

Let's have the next person at the mic.

Randy Whitney, Verizon.

Randy Whitney (Verizon): If you can put up the summary slide, the one with the list of five or six conditions --

Andy Linton: This is the same slide Terence was talking about.

Randy Whitney (Verizon): In one case, I agree with Terence, and I think points 2 and 3 should be combined. Otherwise, I agree with the proposal.

Andy Linton: I believe this was discussed on the list and agreed to, but it has not made it on to the presentation.

Randy Whitney (Verizon): Yes. Thanks.

David Woodgate: I definitely meant either/or.

Andy Linton: David has confirmed it was an either/or.

Matsusaki Yobinisho (IIJ): One clarification: this proposal recommends a staff allocation, chk and I think this should be consistent with proposal 1 or 2. Is this the correct understanding?

David Woodgate: I was not being specific about any particular proposal or methodology. But obviously just trying to recommend that APNIC allocate /48s directly adjacent to each other, to different organizations, so that there is scope to grow and reduce the routing, therefore impacts on subsequent allocations.

Izumi Okutani (JPNIC): I can sort of relate to Terence's concern about routing table, and it is certainly something that was pointed out by our operator, but it is not specific at this stage.

My suggestion, as I commented earlier, is for the Secretariat to do a regular update, then maybe the community can see if there is any notable impact on that and review the criteria, if we have any concerns about it.

Terence, would you feel that you would be able to agree with this proposal if we add this condition?

Terence Zhang (CNNIC): Yes.

Izumi Okutani (JPNIC): Of course, I would like to ask David if you feel comfortable to add this as a condition in your proposal as well.

Andy Linton: We have lost David on the remote connection. But let's go ahead anyway. We can always ask him the question later.

Terence Zhang (CNNIC): I think, currently, the position is we do not have any historic data to predict, so I agree with you and David that the impact, we are not sure at this point. I think a solution might be, I think we can try it, have a try on this policy, and maybe might put a condition that this policy will lapse effectively at some point and then at that point we can have a review and put it to consensus, something like that. Because if we formalize the policy and after two years we say the number is higher, and we try to rely on a policy proposal to restore the requirement, then I think it is very difficult to reach consensus, if this has passed.

So this kind of, if you agree on -- if you try to oppose the policy, it is generally easier to -- easier if you support the policy. If we put a condition that the policy will lapse in two years, then at that point we have the impact analysis and then put it to consensus again, I can agree.

Andy Linton: Can I ask the Secretariat, effectively Sanjaya, to comment on what that reporting would require and how difficult it would be.

Sanjaya: I think it is pretty easy for us to have the reporting, the way we report, say, the transfer log, the IPv4 transfer log, we publish it daily, so if you want we could publish daily the portable assignment. It is easy, we can do it.

Andy Linton: Can I get some indication from the people, from Izumi and Terence, who were keen to have a log, would something of that nature be satisfactory, a daily log in similar form to the one we have for transfers? Would that be the sort of reporting you would be looking for?

If it was every day, we would rapidly see a picture.

Terence Zhang (CNNIC): This is part of it, not necessarily every day, but maybe one year or half year.

I think another part of it, I think if -- for example, two years later, some people feel the number is too high but other people feel it is OK for me, then it is hard for you to write a proposal to say, OK, I want to have more restrictions, it is hard for the policy to get consensus, because generally people oppose the policies easier than to support the policies.

What I like is to have a condition in this policy that this policy will lapse effectively in two years, like two years later, then we have discussed it again, we try to make consensus again. This is what I mean.

Andy Linton: I want to make sure I understand and the rest of the room understands. You would support this policy if it had a time clause to say it would be effective for two years and that we should re-examine it at that point? We should look again in two years time?

Terence Zhang (CNNIC): Yes. Just like two years or one year, some time constraint, and then at that point we discuss it again as a new policy proposal. It is just like you don't have -- you don't have the position of the people against the proposal -- the people against the proposal have more favourable position than the people who support the policy. This is what I try to raise.

Andy Linton: David, I know you have been dropping in and out of the conversation here, but is that time constraint on this something you would be comfortable with or willing to accept or whatever?

David Woodgate: In principle I have no objection to it but I think the issue is that anybody can raise a proposal when they want, if they feel that there is a problem emerging. So I am not sure whether it needs to be represented by a sunset clause in the proposal itself or whether it is really a case of that if things are being seen to be going astray, then someone raises a proposal to revoke that. That we institute multihoming.

Andy Linton: Another comment from Izumi, then we will come back to Terence.

Izumi Okutani (JPNIC): My point is basically the same as David's. I wouldn't be opposed to having a time limit but we still support the proposal even without it, and I think people can basically propose it whenever they feel the need.

I am also OK with the idea of setting a time limit, if that makes everyone more comfortable.

Andy Linton: Are there any comments from anyone else? Let's leave on the table the idea of a time limit and come back to it shortly.

Does anyone else have any comments, concerns or questions?

I am not hearing any -- apart from Terence's concern with the possible impact on routing tables, which is a genuine concern of course -- and his desire to perhaps have a time limit on this -- I am not hearing any other negative feedback on this from the room. Is there anyone else who has negative feedback on this, anyone in the remote hubs or on the Jabber conversations who wants to express an opinion?

I am not hearing anything.

George? No, nothing coming back.

The one major concern about this proposal, from what I am hearing, is the potential time constraint on it, or a re-examining of this in the future and saying -- I am getting a prompt.

We need some -- the proposal is we need some more time before we discuss this for consensus. We have some time constraints because our day is limited to a certain length.

I do not want us to go around in circles about whether we want a time constraint or not.

How many people here -- I am not looking for consensus, I am just trying to gauge the feeling in the room -- how many people here are comfortable with the proposal more or less as it stands, how many are generally in favour of this?

I am seeing a reasonable show of hands, given the number of people here.

How many people here are strongly opposed to this? Terence, I take your concerns here.

Are there some other people here who are neutral on this, who do not mind either way?

We have a lot of people in favour of this and one person who is opposed, because of the potential problems.

There are a couple of messages on Jabber supporting it without any amendments.

What I am going to do is get the Secretariat to put the slides that we have for consensus on this and I am going to ask for a call, to see. I am also hearing there is a strong report for the idea of reporting on this, and I think that is a good notion to have. I believe the Secretariat will probably end up doing that anyway, because it is important that we have those figures. But let's have the consensus call.

I am going to go to a call for consensus here. I want to make sure the remote hubs understand that they are involved in this. I do not believe I have seen any comments here, but I would certainly expect them to be part of the process, and anybody who is participating over Jabber and so on can express an opinion here. Thank you, Dean.

Let me remind you what the proposal seeks to address: this idea that portable assignment is only available if the network is currently or plans to be to be multihomed within three months, and there are some technical or commercial reasons why someone will not be multihomed. If provider assigned IPv6 addresses are used, then any change in ISP would require renumbering.

These are the bullet points we had up. Basically it allows anybody who meets certain criteria to apply for a block.

The fundamental question I want you to think about is what is your view on this proposal? I would like you to think about what you mean by strongly support and strongly oppose. I am going to ask those people in the room and on the other media, to answer the first question: if you strongly support this, would you put your hand up?

If you strongly support this proposal, would you please put your hand up, so we can get some feeling. This is where you can really help the Chairs make a good decision.

If you support this, but you have some doubts or have some extra criteria, please put your hand up.

Would those extra criteria be met if we had decent reporting? Yes.

How many people are neutral about this? That's always useful to know.

And oppose?

And strongly oppose?

For those people who are opposing here, Terence has voiced an opinion here that if we had a sunset clause on this and if we had a report in a year's time, or something along those lines, would that meet those concerns? Can I ask you that?

Would you be happier to support this if it was something we examined or re-examined in a year or two years' time?

Terence Zhang (CNNIC): I am not sure I understand what you mean by examine. If you just chart it and then -- because we do not have the mechanism here, just like if you say -- if I say, OK, if the number is higher, and other people say, that's OK, I am not sure how the examination is going to help.

Andy Linton: Would you like a clause in this that said we will look at it in one year's time and re-endorse the proposal?

Terence Zhang (CNNIC): Re-endorse, yes, something like that.

Andy Linton: I do not know how that would be reworded. I see this as a reasonably -- there are a few people in here who have this problem, and the other people who were opposed, the three or four people who had a concern about this? Is this the concern you had?

Similar concern, OK.

Skeeve Stevens: Andy, there is some support from Vietnam strongly supporting and from Brunei there is support with added criteria.

Andy Linton: David has agreed the criteria of reporting on this is something he is happy with. Am I correct, David?

David Woodgate: Yes, certainly.

Andy Linton: And you were less -- what is your opinion on the idea of -- on Terence's idea of this having a time limit on it of some sort?

David Woodgate: As I said before, I wouldn't -- if it was essential to get it through, I wouldn't oppose it, but I do question whether that just could not be a -- whether a subsequent proposal could not be raised anyway at any time, without a sunset clause. So I personally do not believe the sunset clause is necessary but I am not going to oppose it, if that is what is required.

Andy Linton: OK. I think we have enough objection from a group here to say that we are not quite there with this.

I think the further discussion is not necessarily something we can usefully do here, but we may have some discussion on this between -- can we talk to you -- can we have some conversations on this perhaps offline and bring this back briefly to the session this afternoon and talk about this sunset clause?

How many people would be content with this or would support this if it had the sunset clause in it? Can I ask that question. How many would support this with the time period? Those people who were happy to support it earlier, would you support this if the time clause was added? Can I see a show of hands for that?

So people don't want to put that clause in there.

I am going to discuss this with my Co-chairs briefly.

Izumi Okutani (JPNIC): I just want to clarify that it is not that I am against it, I am just neutral to adding the sunset clause, so I am OK either way.

Andy Linton: Our view on this, looking at this, we don't believe we have got full consensus on it; we are close to it.

The reporting condition is one that David is quite happy to agree to. David has said he is willing to put a clause in this with a time constraint or a sunset clause, and I think if we have that in there, my feeling is that the room agrees to this. But we have a dilemma here, that a group in the room, a number of people in the room -- I don't mean a group, I just mean a number of people in the room -- have some concerns about this without that clause.

So I am going to ask David, is that something you are willing to put into this and is that something the room is willing to accept at this stage? David, first of all, are you willing to put something in that says this, and what time limit would you be happy with?

David Woodgate: I am willing to, and I suggest two years.

Andy Linton: Terence, do you feel that would satisfy your requirements?

Yes.

Does the rest of the room agree that that would satisfy the requirements? Can I have a show of hands, that if we have this in with a reporting clause and a review in two years, to confirm that this should continue?

I am seeing no support for that.

Those people who support the idea of this motion with the clause that limits it to two years and a regular report from the Secretariat, please put your hands up.

David Woodgate: Andy, may I suggest that the ask for the people who previously put their hands up as opposing the requirement, to indicate now whether they support it with the change?

Andy Linton: So that you are aware of what's going on, David, the people who had a problem with this before, I saw their hands up with this new condition in place.

David Woodgate: OK, thank you.

Andy Linton: I think we need to do a little bit of work on the wording here, and we will present a -- I will get you to present a revised clause on this, a couple of extra clauses in your proposal, and we will look at this again after lunch. If we can do that, we will take a final view of this, and my feeling is that this can proceed.

Any dissent on that?

No, I am not seeing anybody rushing on the mic.

Good, OK.

Thank you, David. If you would work on that, a clause that puts a limit and the reporting, we can quickly review that after lunch. A.

David Woodgate: I will do that right now. Thank you very much.

Andy Linton: Thank you.

Our next item is one that is --

Skeeve Stevens: Owen is happy to wait until after lunch.

Andy Linton: Our next one is Owen DeLong, prop-098.

We are scheduled to go for lunch at this point, 12.30. So it being 12.33 or thereabouts, I propose that we do that. Owen has indicated he is happy to wait to do this until after lunch. Thank you for your attention. We will do a little bit of work on that last proposal and get something to show you.

Thank you.

Because we are a running a little bit late, can we get back

really sharp to start the afternoon session.

Thank you.

Session 3 Begins

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

Andy Linton: David Woodgate has sent us an amended version of his proposal, which he's added two extra clauses to. I'm just waiting to get a couple of slides which actually detail those two clauses and so let's have a look at those and treat them on what David has put there and see if that sort of satisfies requirements.

I have heard some concerns that adding the time clause would make people unhappy and obviously I'm hearing some people who say they're unhappy if they don't have it. But let's look at the proposal as is and see what David has suggested and see if it makes something we can all agree on.

I'm really reluctant today, given the small numbers of people here, to reach a decision based on the 20 or so people here.

I know there's more than that in the room, but there's really not that many people here who are either empowered to make a decision or feel they're empowered to help us make a decision, and call this consensus.

If we have a lot more people here, I will be happier, but, you know, I really am reluctant, if he this gets very small with the number of people here, to say that we represent the community. I'll just flag that.

Here is the text of the first paragraph that David has added. Let's have a look at this. I can read this out to you, but I think the brief summary of this you can look at it and read it yourselves. It is that this clause talks about a set of reporting requirements that would be useful for this. It's quite a comprehensive set, maybe more than is normal, but this is what David has proposed.

I think Izumi will be particularly interested in this clause that's on the screen. This is David's proposal for reporting on prop-101.

Can I ask, is there anyone here who has a problem with that set of reporting? I'm looking at Sanjaya. Does that give you cause for concern, if could you comment on it for us?

While Sanjaya is having a quick study of that, sorry to put you on the spot, is there anyone in the remote hubs or in the Jabber who has concerns about this? We have a very good turn-out in Brunei, something like 25 people. Vietnam is somewhat, you know, eight or ten, that sort of number.

Sanjaya: Yes, we can do this. No concern.

Andy Linton: No concern.

Sanjaya: Yeah.

Andy Linton: OK. Terence? There's another clause coming.

Terence Zhang (CNNIC): Yeah, I understand. Just at this point, I have a suggestion --

Andy Linton: Can you come right up to the mic, please, it's hard to hear.

Terence Zhang (CNNIC): OK. I have one more suggestion, because I think the increase of the global route table first is because of the portable assignment and the second, I think there's possibly people might -- because the popular use of /48, people might slice their /32 into /48, so I'm not sure if it's possible like statistics of all those /48 routes, something like that. No matter, is portable assignment or is --

Andy Linton: OK. I understand. But is this sufficient? Is this clause sufficient, as a reporting mechanism?

Terence Zhang (CNNIC): I think, yeah, if it include all those /48 routes.

Andy Linton: I have Matthew over there.

Matthew Moyle-Croft: I think the worry about the global routing table is really a bit pointless. People are going to deaggregate their space anyway and they do quite happily in IPv4 right now. I mean, if you look at the weekly reports on deaggregation that people are doing, we're definitely seeing a large amount of deaggregation.

What are we worried about? I mean, the number of people who are likely to take this up is small. All the other RIRs have agreed that this is a perfectly fine idea. Why are we so special? Why are we worried about it?

Andy Linton: Thank you.

Sanjaya: Just to clarify, I think what the APNIC Secretariat might do is to have a report on both the count of the assignment as well as the size, if you prefer.

Andy Linton: Yep. OK.

Can I just ask for an indication from those people who put up their hands before and anybody else, of course, would this clause be sufficient or would it meet the requirements for reporting? Can you please put up your hand if you think this meets the reporting requirement?

Has anybody got any strong opposition to having this reporting clause?

OK. So can we see the next slide?

This is the second clause and this is the area where I'm going to let you have a look at this briefly, but David has proposed that in the first meeting of 2014, so that's two years from now, we would have a question asked along these lines: Should the IPv6 portable assignment criteria revert to requiring multihoming?

Can I hear Sanjaya?

Sanjaya: If I read this correctly, the APNIC Secretariat is asked to extrapolate 10 years based on a two year's data?

Andy Linton: You would have to ask David that question, but, yes.

Sanjaya: I just need to clarify that. Because if we do that, then it would not be too precise, but we have people who might be able to do that.

David Woodgate: I have a strong feeling that APNIC has at least one person who is used to doing extrapolations of that type.

Sanjaya: You are thinking of the same person I have in mind maybe. All right, that's fine.

Andy Linton: Dean.

Dean Pemberton: InternetNZ. With this clause here, I'm just trying to understand what it's exactly saying. In the first meeting in 2014, the APNIC Secretariat will extrapolate this data and there will be an agenda item to consider a question? Is that part of the Policy SIG? Is that a policy? What would that lead to? Because sitting down and considering a question is fine, but what would that actually do with the answer?

Andy Linton: I think, yes, of course we'd have to look at the mechanism for putting this through under our current PDP. It might require David and Terence to put a proposal forward or someone to put a proposal forward which says we should go back to where we were.

Dean Pemberton: I have no problem with this clause insofar as the part where it gets the APNIC Secretariat to produce some data. I don't know that it needs us asking the question, because I think that can already be handled by the current policy development framework. So maybe before that meeting, the data can come out and then anyone can decide whether they'd like to raise a proposal at that meeting to act upon that data. So maybe we say, you know, within the timeframe to put forward a proposal, that data comes out and then a proposal can go in or not, based on the data.

Andy Linton: Yes.

David Woodgate: Dean, may I suggest that Terence comments, if possible, on this, because he obviously put it in because of Terence's concerns.

Dean Pemberton: Absolutely.

Terence Zhang (CNNIC): Any people can put up a proposal. It's just like when this become actual policy, some people want to change it, it's not that -- it's like in a disadvantaged position and the people support it. But currently, like, yeah, we don't know the future impact, so we just put a condition, then we just see what happens in the next two years and then the next two years, we consider this policy proposal again. But if you put it like a formal policy, then at that time, if I want to change it, I put a proposal -- yeah, like, it's very difficult for the proposal to get consensus. Just you understand what I mean?

Dean Pemberton: Yes, I understand. I don't necessarily agree with it, though.

I think the proposal development framework is what we have and I don't think it's any harder to put forward a proposal to change something, whether it's in or not, and it worries me that we would go down the track of adding these sunset clauses to policies, because I think it adds a very bad precedent.

So before the break, as the policy stood, I was in strong support of this policy. I don't mind the previous slide you had, that's fine, and I don't even mind the data getting produced, but I think if we have a sunset clause where prop-101 only lasts for two years and then ^ onlies out, then I would strongly change to strongly disagree with this policy.

Andy Linton: OK, Dean. Thank you for that.

Can I ask the Secretariat -- we are saying this will create a precedent. Would this be the first time that we've ever had a clause which limits something like this?

I see Geoff nodding, Sanjaya is going to come to the mic and give us ...

Sanjaya: We're never had this before. But instruction to publish something has precedent, so, yes.

Andy Linton: No, I mean, the publishing, but more --

Sanjaya: Putting a lifetime on a policy, I don't think we have ever had that.

Andy Linton: This would be new?

Sanjaya: Yeah.

David Woodgate: Andy, can I just comment that I have, for example, at APNIC 31, I did raise a policy which essentially was looking to revert or repeal some aspects or at least clarify previous policy and of course, there's nothing to stop it and that was clearly rejected by the Policy SIG at the time.

As Dean says, there certainly is mechanisms to just keep raising policy proposals about previously agreed policies. There's no reason that they can't be reviewed by people raising policy proposals.

Terence, I heard your comment that it becomes harder to raise a policy proposal and get acceptance on it, but I would suggest that equally -- it is the process that we have, as Dean said, and trying to, you know, prevent that sort of future possibility or limit the future possibility now may be counter to the APNIC policy development process, as people are just saying.

Andy Linton: OK. Time-wise, this is causing some concern here, we have time ticking away here.

We asked for a view on consensus on this before lunch, without these clauses. So can I ask the same question, with these clauses in.

I'm not going to ask about the first clause, because I don't see any dissent on that, so I'm only going to concentrate on this second clause, the one that was up on the screen here previously, if we can get it back up, that would be good. The one about in 2014, we would look at it, can we get that back up on the screen?

Again, there doesn't seem to be any contention about the idea of the reports and stuff in here. Are people happy with the idea that we get reports?

The key to this is here. Who supports that in 2014 we would have this review question put to the Policy SIG which would ask this question?

How many people are strongly in favour of having this process take place in 2014? If you strongly support this, let me see your hands.

Terence, go.

Terence Zhang (CNNIC): I'm not quite sure about what you're asking.

Andy Linton: I'm asking you, do you strongly support this clause being added to the policy and, in your case, would it meet the requirements you had this morning; and others, of course?

Terence Zhang (CNNIC): My intention is not to discuss -- I think the question here is just like should it revert to the multihome -- I don't think it's appropriate, because I think it's just like currently, we have the multihome requirement and then two years later, just like we restore to the current ... at that time, we should have the multihome requirement. But if people got consensus, we can remove at that time, then we remove it. So it's not on the reverse side.

Andy Linton: OK.

Masato Yamanishi: We still have three proposals ^. If we cannot reach the consensus by this text, we can push back to the mailing list.

Andy Linton: I think so. I think you're right. Given the relatively small numbers, there are some objections in either directions. If we have this in, there's some objections. There's objections.

What I'm going to do with this is we'll push this back to the mailing list, we'll have a further discussion on it and we'll bring this back up. If the author wants to bring this back up again in a revised form in Cambodia.

Let's move on with the next one. The next one is going to be prop-098, Owen DeLong's proposal -- I can't remember the full title of it.

Skeeve Stevens: The full title is is a proposal for improved IPv6 allocations by Owen DeLong.

Sunny, have you got connection with Owen doing the presentation?

Andy Linton: Skeeve is going to handle this one, so I'm going to take a seat over there.

Skeeve Stevens: Owen, are you there?

Owen DeLong: I am.

Skeeve Stevens: So we have Owen DeLong on remote. We don't have a visual at the moment. Adam from APNIC is just going to be doing the button pushes to move the slide forward.

This is a proposal for improved IPv6 allocation, known as prop-098. Owen, do you want to go ahead.

Owen DeLong: Sure. So you guys have seen something very similar to this at the last meeting, for those of you that were with us in Busan. I'm sorry I can't be there in New Delhi this time.

Slide 2, please.

This is very similar to policy 2011-3 which was adopted 10 June in the ARIN region and, contrary to some of the discussion on the mailing list, it's about allowing providers to easily seek more liberal IPv6 allocations in order to facilitate better network administration and better aggregation. It doesn't actually try to tell you how to run your network, it just tries to let you do it more easily.

The current problem, as I see it, is that a lot of -- slide 3, please -- ISPs are trying to squeeze whatever size network they have into a /32, based on an often erroneous belief that that's the size assignment that providers can get.

Historically, I have seen a lot of times where a network engineer trying to do math in their head has caused outages, so if we can move things to nibble boundaries, I think that simplifies administration, and that is an option enabled in this policy.

But one of the differences between this version and the Busan version is that the Busan version required nibble boundaries, this version makes them at the service provider or LIR's discretion.

Further, when LIRs outgrow the /32 and realise that they do have to go back and get more space, we're going to get some additional disaggregation and that's going to end up helping the routing tail look like it currently does in v4.

Undersized assignments by the LIRs to their end users are another fall-out of the current policies, because LIRs are trying to squeeze all of their customers into that /32. They think it is all they can get, so they're making their customer assignments smaller and that's going to be harmful in the long run as well.

In terms of other RIRs, this was adopted in ARIN and is actually fully implemented now. It's not yet proposed in LACNIC or AfriNIC, and RIPE is mostly doing this, although they don't have the nibble boundary policy, their allocation policy is liberal enough that you can generally do the nibble boundary thing if you want to.

The proposal, as written -- slide 5, please -- makes it clear that the ISP can get any justified prefix larger or shorter than a /36 while leaving the default at /32. It reduces the probability of ISPs choosing undersized blocks and encourages resizing downstream allocations to end users, whereas the current policy encourages undersizing.

Slide 6, please.

The proposal significantly eases the qualifications for larger prefixes, which will streamline the request process and simplify the ability for an LIR to justify a relatively large block, while still preserving a needs basis criteria and appropriate safeguards.

Next slide, please.

It does not require an ISP to take a larger prefix than they want to. This proposal sets guidelines for a liberal maximum allocation, but the LIR can ask APNIC for whatever size they want, underneath that maximum. ISPs that want to keep things small and inexpensive are actually allowed to get a smaller block under this proposal than under current policy, a /36. It does not tell you how to run your network, it gives you greater flexibility in how much address space you can get to do so.

Next slide, please.

It recommends but does not require nibble boundary round-ups. In Busan, one of the major objections was the people felt there were some pretty serious fee implications under the current fee structure to the nibble boundary round-up provision. Recognising that, this version makes nibble boundary round-ups voluntary, so LIRs can control the fee implications and plans balance? the trade-offs as they see fit.

Slide 9, please.

The benefits to this proposal are a simplified streamlined justification process, larger maximum allocations at the discretion of the LIR. Greater flexibility in managing your network, better aggregation, and more liberal end user assignments are encouraged.

Disadvantages are that it will create a slight increase in IPv6 consumption, but not large enough to matter.

Slide 10, please.

In terms of implementation, APNIC will probably have to do some development work to facilitate implementation. I'll leave it to them to determine how long that will take. In ARIN, it took about six months, I think.

There will probably be some changes needed to the LIR, initial allocation and subsequent IPv6 request forms, updates to the IPv6 allocation policy documents.

In terms of NIR impact, NIRs will need to adapt to the improved allocation practices, but that impact should be relatively minimal.

Last slide, please.

In summary, this proposal does not tell you how to run your network, it allows you to get more space, if you want it. It allows you to get nibble aligned allocations if you want them. It replaces a rather confusing HD-ratio with simple percentages. It simplifies and streamlines the justification process.

That's the end of my proposal. I'm willing to take questions if the Chair will permit it or address concerns, however the Chair wants to deal with that.

Skeeve Stevens: OK. Thank you very much, Owen.

This is quite a technical proposal. I just wanted to get an indication from the room, how many people actually understand this proposal with nibble boundaries and things like that?

OK. That's great.

Does anyone here have any specific questions or comments on this proposal for the author?

Judith Duavit Vazquez: Owen, I love it. Thank you.

Skeeve Stevens: Any other commentary? Izumi?

Izumi Okutani: It's basically what I expressed on the mailing list as well. I asked a couple of operators in Japan and they don't feel the need for this policy, including removing of HD-ratio and the nibble boundary. So I don't support this proposal, because I don't know what problem it will solve.

And I have a suggestion. First, regarding the concern that some ISPs feel they can only receive a /32, where they actually need more, I think this is already allowed in the current policy. So if the current policy is not clear that it can be allowed, maybe we can improve in explaining that it is already possible in the current policy rather than changing the criteria itself.

The second point about the nibble boundary was that our ISPs in Japan felt they configure reverse zone based on the assignment size, not allocation size, and ISPs can choose assignment size. So there's no need to base allocation based on nibble boundary.

Owen DeLong: Nibble boundary is optional at the ISP's discretion, so it's intended to be flexible and let the ISP do what they feel is necessary for their network.

Skeeve Stevens: Just a quick question for Izumi. You said that the operators don't understand what this proposal brings. Are they opposed to it because they don't see the impact or does that proposal coming in -- are they opposed to that or they just don't see the impact of the proposal?

Izumi Okutani: I think the operators are mildly opposed to it because they don't see the need. From JPNIC's perspective, we don't really see the need in changing the policy when there are no needs. Plus we think it makes the criteria more complicated than simplified, because in HD-ratio, we simply have to see the chart to be able to see what size you are able to get, but with this one, you have to calculate based on how many percentage each ISP allocation unit is able to fulfil and then multiply it by the number of allocation units and things like that.

We actually feel that it makes --

Owen DeLong: I think you're misunderstanding how the allocation units work. The calculation here is very, very simple. To determine your fullest POP, if you're assigning /48s to your end users, for example, you take the number of 48s that are present in the allocation to the most crowded POP and if you have assigned 90 per cent of them, you're eligible to get more space. If you have assigned 75 per cent of your overall prefixes, then you're eligible to get more space. It's that simple.

Izumi Okutani: For the subsequent allocation, yes, and for the initial, we have to calculate how much ISP allocation units we have and then --

Skeeve Stevens: Just please give us a few moments.

(Power outage)

Sunny, do we have Owen back?

Sunny Chendi: No, I don't.

Skeeve Stevens: We are just going to give it a few moments to attempt for Owen to reconnect.

We are just waiting for the Internet to actually come back up.

What I'm going to do is I'm going to continue a bit. I would like to know if there are any other comments relating to this proposal from the floor, in the positive or negative. If we have a specific question for the proposer, we'll have to wait for him. Are there actually any other comments?

OK. So I'm going to declare that there's no more comments.

Now, I agree with Andy and the number of people present and also, more specifically, the number of people that this proposal affects and understands and uses is rather low, which causes us difficulty in achieving consensus. But, as procedure, I will actually call for consensus.

Do we have the slides up for the consensus, Sunny?

Sunny Chendi: It will take some time for the network to come up.

Skeeve Stevens: OK. I'll go back to my own notes.

I'm going to firstly call for those in the room and in the remote hubs, which we actually don't have access to, so we'll have to consider that. For those that strongly support this proposal, can you please put your hand up.

I'd like to also find an indication of those who support this proposal.

I'd like to know, if I am neutral, don't really ...

OK. Now, I'd like to know if there's opposition, basic level opposition.

Finally, I would like to establish a strong opposition, if there's any strong opposition by raising your hands.

OK. Just a moment.

The Chair and both us Co-chairs have talked. The decision we have come to is, given this is the second time the version of this policy has been raised and that, even with some minor changes, there is minimal support or strong support for this proposal, there is rather chk areas in the neutral and also tending into the opposition areas.

So, given this is the second time it's come up, we're not going to send this back to the list.

Basically, we are declaring this proposal not successful, and we'll inform Owen that if he wishes to resubmit, then that is up to him, but that's the end of prop-098.

Next on the agenda.

Andy Linton: Next on the agenda, as we talked about this morning, was going to be the report on the global policy initiative from Tomohiro-san and Adam's report on some changes to the actual documentation at APNIC.

In view of the fact that we're being told that we have to get out of this room pretty tight on 3.30, so they can reorganize it for the plenary closing session, I'm just going to keep going with the policy proposals. I think it's more important that we get those done. The other reports we can submit to the mailing list and, if we do have a little bit of time at the end, then we'll go to them.

The next thing that is on the agenda is is we actually have two proposals that sort of fit in and around the same area, but prop-099 is from Xing Li and we'll hear that one first and then Dean's proposal has got smaller and smaller as the meeting has gone on. I think it's extremely simple, so we'll hear that one immediately afterwards.

But we'll go with Xing Li's proposal right now and then we'll hear the other proposal and then we'll have some discussion on the two things together and then we'll look to see how we get on with consensus.

So if we can have those -- the slides are already up. Masato-san is going to handle the discussion period after this.

Xing Li: Good afternoon. This is the second time I present this proposal.

The introduction: this proposal extends the IPv6 request process to allow large ISPs to request multiple prefixes within a single, contiguous, reserved space. Actually, this is only focused on the very large ISPs and there are two things in this proposal. The first is the big, giant ISPs require a large block, for example, /18.

The second issue is aggregation in each POP. Actually, when I talked to Izumi before this meeting, she's thinking POP is not really the right word, maybe the region is a better word.

The current problem: apnic-089-v010, the organization provides comprehensive documentation of planned IPv6 infrastructure and equivalent IPv4, those kind of things.

Based on these two conditions, I mean, that's the old condition, large networks are facing challenges deploying IPv6 network. The current slow start policy is to allocate, for example, /32, then reduce the bit mask. So that's the problem.

Based on guideline, there is no similar policy or policy proposal in other RIRs.

So the proposal. Actually, it is not try to change anything in the current IPv6 assignment allocation policy in the current document, but we like to suggest add a bullet 'c' in the current policy. So there are some key words I marked in red.

The organization provides comprehensive documentation of long term, up to five years, IPv6 infrastructure, which would require a large allocation. So the first key word is five years. In the Korean meeting, actually we proposed 10 years and, after discussion, we think probably five years is the right time period.

Then larger initial allocation will be via multiple prefix request. Conventional allocation policies will be applied in assessment of each prefix requested. Subsequent allocation requests can include extensions to previously allocated prefixes and/or new prefixes as needed.

So that means the ISP will request for multiple prefix in that large block, not a single one. Each IPv6 request will be able to specify a proposed reservation for the entire network, to contain all allocated prefix and room for future growth. In the case of multiple prefix allocation, only the individual allocated prefixes will be registered in Whois Database or included in resource certificates. The reservation itself will not be registered. However, it may be separately documented. So that means that the multiple prefixes will be individually announced and certified.

So this can give you example, like the left one is is the standard allocation, as the slow start policy, the blue represents the first allocation and because that's a big, big network, so each region will get the first allocation part of that.

When we reach the second application of the allocation, that's the red one. Then each region will also have their own growth. And the third one. So you can see, finally, as a whole, the ISP as a whole, actually is aggregated and announced the whole /27, for example. However, inside ISP infrastructure, each region's prefixes are scattered and cannot be aggregated. That creates some operation policyproblem ? , what I learned in big networks.

The proposed allocation method in this proposal actually is on the right.

Based on five years plan, actually we can, for example, that's the reserved block is /27. However, that's why the multiple request. Even in the first allocation, the summary of the total allocation for each region will be still /29. However, that's the multiple request and the multiple prefix and later for the second request, that grows. Again, that's /29. This grows in each region.

Eventually, if everything goes well, as predicted by the five-year plan, everything will be aggregated. In each region that is aggregated, as well as the whole also aggregated, so that's the proposed method of modification, add-ons. Again, it's not modification, but add-ons. So the standard allocation method is still there, but for some super-ISPs, that's the alternative.

For first, second and third allocation, actually the summation of the prefix size keep the same, but through the multiple prefix.

Benefits and disadvantages: advantages are this proposal enables large network to make long-term network plans and reduce internal routing complexities. The reserved space is aggregated and can be globally routed as a single prefix once the space is fully allocated.

The disadvantages: initial allocation from the reserved space could be made in multiple disaggregated prefixes that have to be announced separately on the global routing tail. However, for the long term, that will be aggregated.

I would like to point out, like this is only for very big ISPs. So even at its multiple announcement, my feeling tells me should be larger than /32. So that should not really create problems for adding the -- I mean, create dramatic increase in the IPv6 global routing tail.

Another disadvantage is additional work for APNIC Secretariat to manage the request process.

Implementation: if this is reach consensus because there's some additional things, so I believe, and it is not too difficult work.

Update, apnic-089-v010. The only thing change is add bullet 'c' as I present in the earlier slides.

Identify any impact to NIRs. The proposal allows NIRs to choose when to adopt this policy for their members.

Summary. Again, similar thing. This proposal extends the IPv6 request process to allow large ISPs to request multiple prefixes within a single, contiguous, reserved space, the large block, and try to do aggregation in each region.

The last word, actually, this model is quite similar to the configuration IPv4 address allocation. This is the unique thing in APNIC.

So I have finished. Thank you very much. Any questions?

Masato Yamanishi: Thank you. Since prop-102 is also trying to resolve similar problems, so before having discussion, let me ask Dean to present his proposal also.

Dean Pemberton: Good afternoon. While we get the slides up, my proposal is all about documenting the sparse allocation guidelines for IPv6 resource allocations.

The current problem is that over the last few meetings we have had a lot of proposals wanting to address the fact that IPv6 allocations are currently based on a one to two year timeline, but their deployment plans for large networks sometimes have to look at a five to 10-year timeframe, as we have just heard in the previous proposal.

Sparse allocation is currently used by the APNIC Hostmasters as a way of addressing members coming back and wanting to expand out an existing allocation. But the actual algorithm and parameters used aren't published. So it's not very easy for the members to see how large a reservation they could have or to come back and give feedback to the Secretariat on whether they think the sparse allocation algorithm and parameters are actually appropriate.

Other RIRs make use of sparse allocation as well, but it doesn't appear that all of them publicly document the parameters around this either.

My proposal purely seeks to have the APNIC Secretariat publish the details of any sparse allocation framework used to allocate IPv6 resources. It should be published on the APNIC website as a numbered document, and changes to that document should be handled just within the existing framework in APNIC-112.

The benefits would be that APNIC members would have visibility of the details of the sparse allocation algorithm and they would be able to see what effect that would have on being able to do future planning on their network.

The disadvantage would be that there may be an increased workload for the Secretariat to document and publish those sparse allocation details.

Implementation: This wouldn't actually require any change to the way that IP addresses are allocated. That's not looking to change any operational things that the Hostmasters currently perform. All it requires is just that their current operational procedures are documented and published. So it's purely a documentation requirement.

The policy would apply when NIRs request address space and the proposal would allow NIRs to choose whether they would like to adopt the policy for their members.

In summary, it mandates use of the existing process, it gives members the surety that they can plan into the future by being able to see into the sparse allocation framework and seeing what that reservation is. It doesn't require any operational changes and is purely around documentation, and it allows APNIC to publish procedures and consult on changes that are required.

That's it.

Masato Yamanishi: Thank you, Dean. Can you come here and sit next to Dr Li.

First question, I would like to ask Sanjaya whether we will be able to implement both proposals, because these two proposals are trying to resolve similar problems.

Also, since the author will remain here, so they cannot comment freely, as the other members, so I would like to ask their view for other proposal, as second question.

Anyway, Sanjaya, go ahead.

Sanjaya: Thanks, Masato-san.

We have analysed both proposals and basically come to the conclusion that we can implement both. There's some overlap, but it's not an issue. They both touch on reservation, they both touch on sparse allocations. The only difference being with prop-099, the APNIC Hostmasters aren't given authority to allocate this aggregated prefix within the reservation space, which is doable.

Masato Yamanishi: So it means we can ask consensus for each proposal separately at the end of this discussion, right?

OK. Thanks.

Dr Xing Li, can I ask your view, your comment for prop-102, which is Dean's proposal.

Xing Li: For large block, actually, the same goes, so for that part, I think it's fine, like prop-099 and prop-102, the same.

Actually, prop-099 is addition, like gave the right for Hostmaster to allocate discontinued prefix or multiple prefix in that large block. That can help to make region also aggregated inside ISP's block.

Masato Yamanishi: Is there any problem which your proposal can resolve but Dean's proposal cannot resolve?

Xing Li: If the first time for large block, the ISP, for example, can get a /18, then actually no reason to have that, because ISP have the larger block. So they can do planning and that will be also aggregated inside region.

However, if that large block is reserved, I believe big ISP need my proposal, so they cannot only make the larger block, to get larger block, but also continued aggregation in each region.

Masato Yamanishi: Thank you.

Dean, can I ask your comment for Xing Li's proposal.

Dean Pemberton: Yes. I think actually the proposals are trying to do subtly different things. Proposal 102 is just about documenting the current situation. Obviously, prop-099 is suggesting that the current situation doesn't always fit the needs of large providers.

So if the members feel that prop-099 does fit the needs of large providers, then I'm certain it will be helpful. My proposal doesn't actually suggest to change anything from current practice, it is just around documenting current practice. Thank you.

Masato Yamanishi: Thank you, Dean.

Since we are discussing two proposals simultaneously, please clearly mention your comment is for which proposal you're talking about.

Is there any comment?

Kenny Huang (EC APNIC): I just consider both discussion regarding to prop-099 and prop-102 and since there are too many similarities, especially for the initial large allocation, is there any other way for these authors to have a harmonised proposal? I don't know.

Dean Pemberton (NZNOG): Yeah, if prop-099 had a line that said "and the Secretariat will publish the sparse allocation mechanism", and it passed, then there wouldn't be a need for prop-102. So that would certainly be one way that we could harmonise.

Masato Yamanishi: Xing Li, do you have any comment?

Xing Li: No, I believe I really like ...

Judith Duavit Vazquez: Mine is simply a question on the reservation fee that should apply, and I say "should" apply, given the additional work for the APNIC Secretariat. And, of course, moving forward, and being a member of the board of directors of ICANN, the pressure of law enforcement for us to have more accurate data, whether it be from the domain space or the IP address space, we will have to support financially the Secretariat requirements of our RIRs.

So this is neither -- because no mention was made of the fee involved around the reservation of very large blocks. Thank you.

Andy Linton: I think the reason that we don't mention fees is because we're not empowered to talk about them in this region. I appreciate there are --

Judith Duavit Vazquez: My suggestion is shouldn't there be one is my question.

Andy Linton: It's not in our remit to discuss that. That's done elsewhere. So we pass this on and, if it's a real barrier, then that would be picked up elsewhere, but it's not our remit.

Can I suggest that if we're having problems with the power loading, we on the stage would be quite happy not to have the full spotlight on us and if that would help with the amount of electricity we're consuming, we could either dim those lights and I'm sure everybody in the room could see us anyway -- not that they don't want to see us. But the big spots, we could do without those, thank you.

Masato Yamanishi: Izumi, go ahead.

Izumi Okutani: I guess my position is pretty clear regarding prop-102 and I support proposal after the revision that it basically documents the --

Masato Yamanishi: Which proposal?

Izumi Okutani: Sorry, 102, Dean's proposal. I support this, that documents the current practice and it helps in transparency, so I think it's a good idea.

Regarding Professor Li's proposal, start from the part that I can sort of understand and support. Regarding reservation, actually, there's no need in Japan at this stage for that kind of thing, and JPNIC don't really support the idea of reservation in principle.

However, given the details of the proposal, the reservation is fixed within two years and is not a guarantee. We think that there is no actual impact on resource management for APNIC. If APNIC Secretariat can clarify that there's no concerning impact on our reservations and there are actually needs in China, then I feel I can support this part of the proposal. So it would be great if Sanjaya or somebody from the Secretariat could clarify.

Sanjaya: Can you ask the question again, Izumi?

Izumi Okutani: Does the reservation policy, as defined in prop-099, cause any concerns to APNIC Secretariat in terms of resource management, it has negative impact or anything that you feel concerned about? Interpretation is there isn't and to understand if it's consistent with yours as well.

Sanjaya: The answer is no, we don't have any concern.

Izumi Okutani: The second point about prefix per POP, I talked to a couple of ISPs in Japan and they can relate to the issue that's being raised. But at the same time, if we simply apply this, then I think a single ISP will end up receiving, like, maybe 30 or 40 prefixes in case of Japan, so we are a little bit concerned about the impact on routing. And you say that in five year's time, it's going to be a single prefix, but we're not sure if our estimate is exactly matches with the reality, so if it doesn't, we will end up with, you know, 30 or 40 different prefixes per ISP and that will really have some impact on routing.

So we can relate to the issue, but we are against passing it at this stage. We want to discuss more about a possible better solution to your problem.

Masato Yamanishi: Thank you, Izumi. Is there any other comment?

Terence is coming.

Terence Zhang (CNNIC): First, I support prop-102, yes. It's good to have transparent documentation about the sparse allocation.

Then I also support prop-099. I kind of think the sparse allocation is good technique, but it doesn't solve the problem that Professor Li is mentioning because I think the sparse allocation try to keep those allocations to an organization as far away from the allocation to other organizations as possible. There is not a guaranteed space between them. That's the first -- that's the point Professor Li is trying to solve, is by the reservation.

The second point is the sparse allocation. The allocation to the organization is still a single prefix, but prop-099 is looking for the multiple prefix to different regions. Prop-099 is trying to net those very large ISPs to have the advantage of have multiple prefix to the large region, so they will have less problem in the internal routing aggregation.

What I'm trying to say -- yes, that's the possibility, what JPNIC mentioned, yes, I understand their concern. Maybe at some time, the plan is not perfect and then those prefixes cannot aggregate in the future.

I think what prop-099 is saying is those very large ISPs, just like take China Telecom, for example, in IPv4 they have totally about 130 million IPv4 address and they have 30 provinces, 30 regions, just like prop-099 mention, a region, it's actually a provincial network. So there are 30 regions. Eventually, each region has about 4 million IPv4 address and also consider they might use ... at least more than 4,000 users.

So even if those in the future cannot aggregate into a single block, one province is still larger than a normal ISP, small or medium ISP in China. That's my comment. I support both proposals.

Masato Yamanishi: Thank you.

Terence Zhang (CNNIC): Yes, the proposals serve different functions.

Masato Yamanishi: Thank you.

Kenny Huang (EC APNIC): Just one question to prop-099. I want to clarify in prop-099 if the large ISP has a right to request for large allocation who is detailed plan is not to all the ISP in general? All the ISP still can base on their existing allocation policy to request for simple allocation process. Is that true?

Xing Li: Actually, in this proposal, whatever is single request or multiple request should follow the current IP APNIC policy, so there is no difference. The same policy.

Masato Yamanishi: I just want to mention about that one point. In Japan, broadband is already very popular, so Japanese ISP can say, "OK, we already have 1 million subscribers, so we will need same size of basic address." But I guess Chinese ISP or Indian ISP cannot say same logic, because they are still growing, right. So current levels subscriber is not enough to justify the size of v6 address they are requesting. I think that's the point, right?

Xing Li: Yes, right.

Masato Yamanishi: Sorry.

Tomohiro Fujisaki (NTT): I'm sorry, I missed, but I just want to confirm one point. I'm neutral on first proposal and I want to know the ... block is used in IANA, so what I want to know is APNIC can get additional address block from IANA or not?

The discussion is not to do that possibly.

Sanjaya: If the question is do we need to ask for more block to implement this policy, then the answer is no, we can implement this policy with the existing block. We don't need to get more from IANA.

Tomohiro Fujisaki (NTT): Thank you.

Andy Linton: Just before we take your comment, Izumi, the folks in Brunei are just about to leave us. We had a good number of people there today, so we would like to thank them for their participation. But they have missed the end of this, because they have something better to do, perhaps, I'm not sure. But anyway, they're going to drop off the call now and thank you for taking part.

Izumi.

Izumi Okutani: May I suggest the Chair to split this prop-099 in two parts. One is allowing when you seek for consensus, so one part is whether to allow reservation up to five years and then the other part is whether we should allow prefix allocation per -- I don't know what you define it, per POP or region or whatever. Because I still -- I can understand the situation, you know, better, especially after Terence's explanation, but I'm still not really sure about the implication of applying this policy to the whole of Asia Pacific, not just China.

So I want to be a little bit more careful about the later part, about you know, prefix allocation and I think I can support about the part about the reservation.

So it would be nice if you could, you know, call for consensus in two parts.

Masato Yamanishi: I got your intention, but I want to make sure. Adam, can you show the slide of prop-099? Then I would like to have proposal slide.

We will move on.

Yes, this slide. OK.

Izumi, can you make sure which part is the first part and which part is the second part you suggested?

Izumi Okutani: I think the first part would be the organization provides comprehensive documentation of up to five years, which could require large allocation and they can receive reservation based on that. But I'm not sure if there's a separate part for reservation and the rest.

Consensus on each -- the second sentence that starts with "Each IPv6 request will be able to specify a proposed reservation for the entire network," I think that will be one part.

And the other part -- sorry, I have to read the whole proposal again and if there's a part that mentions about being able to apply multiple prefixes, maybe it's the first part that starts with, "Larger initial allocation will be via a multiple prefix request." I think that's another element of the proposal.

Masato Yamanishi: How do you think, Xing Li?

Xing Li: I believe larger allocation is common in prop-102 and prop-099. However, I believe the multiple prefix is also tightly connected with this.

Masato Yamanishi: So you don't want to split your proposal into two? OK.

Is there any comment? If not, I would like to ask consensus for prop-099 and also prop-102.

Dean Pemberton: Are we asking for them one at a time?

Masato Yamanishi: No, as first question, I would like to ask consensus for prop-102, Dean's one, and next is prop-099, which is Xing Li's proposal.

We are preparing the slide.

OK. This is prop-102.

Andy Linton: This slide was prepared earlier, so you can leave out the first paragraph here. So the "mandate use of sparse allocation" is not part of this. It's just the second paragraph.

Dean Pemberton: Correct. It's just the second part.

Masato Yamanishi: If you strongly support prop-102, please raise your hand.

OK. Thank you.

If you support so-so prop-102, please raise your hand.

OK. Thank you.

If you're neutral for prop-102, please raise your hand.

OK. Thank you.

If you oppose to prop-102, please raise your hand now.

OK.

If you strongly oppose prop-102, please raise your hand now.

OK. Thank you.

So prop-102 is reached to consensus.

APPLAUSE

Dean Pemberton: Thank you very much.

Masato Yamanishi: Now we are switching slides to prop-099.

Proposed solution of prop-099 is multiple prefix request at the same time and also subsequent allocations made within a reserved space.

So let me ask your opinion for prop-099.

If you strongly support prop-099, please raise your hand now.

OK. Thank you.

If you support prop-099, please raise your hand now.

OK. Thank you.

If you are neutral for prop-099, please raise your hand now.

OK. Can you raise it a little bit more higher? I don't have good eye.

OK. Thank you.

If you oppose but not strongly to prop-099, please raise your hand now.

OK. Thank you.

If you strongly oppose prop-099, please raise your hand now.

OK. Thank you.

Wait one moment.

OK. I think we have one strong opposition for prop-099, so can I ask the reason?

Thank you.

Matthew Moyle-Croft: I think it's an over-complex way of not really achieving anything. You ultimately spend a lot of time documenting trying to stop the routing tail grow by a couple of routes for a few large ISPs who are going to be generating large numbers of routes anyway. Why?

We keep doing this to ourselves. We keep carrying on about the size of the routing table, yet, the routing table continues to grow because people continue to deaggregate.

So what are we solving? We're not really solving a problem here, we're just creating more policy and I oppose it.

Masato Yamanishi: Thank you.

Do you have any comment for that comment? Xing Li.

Xing Li: OK. As I mentioned earlier, this is only dealing with very big ISPs, so that will not really increase the number of that. Also, like one of the suggestions when I discuss this proposal, somebody said why not you ask those ISPs split into different members so they can all get continuous block, however the whole thing is not aggregated.

So in that method, if the big ISP want infrastructure continuous aggregated then, one way is they become individual APNIC members, then actually for the long-term still they are different amongst the blocks. However, the method in prop-099, eventually that will be aggregated.

Matthew Moyle-Croft: The point is they won't eventually aggregate because you will still find in five years time when they have the whole block, they announce the routes individually because they will need to continue to do that to get lowest latency routing within China, for example, just between China UniCom and China Telecom and other units in the various regions, I just don't buy that this is going to do anything for the size of the routing tail.

All this stuff we have been rabbiting on about for years about the size of the routing tail, has not stopped the routing table growing. This won't stop it. I mean, it doesn't really matter if China Telecom announces an extra 30 or 60 routes, whatever.

Masato Yamanishi: Thank you for your comment, but we cannot continue discussion more.

Andy Linton: We have a very tight deadline here. The next session starts at 3.45. I don't want to be here when that's happening and they have some changes to do here.

Looking at the call, the hands that went up here, there was some dissent on this and Matthew had strong opposition to it, but I think my take is that it's fair to say Matthew thinks this won't do any good. Do you think it will do any particular harm? Because whichever way you go, you'll have the routing table explode.

Matthew Moyle-Croft: It won't explode. We just buy bigger routers like we always do.

Ultimately, I think part of the problem is we keep chopping the IPv6 allocation strategy up into smaller and smaller parts, to please more and more different people with more and more edge caseschk . I think what actually needs to happen is sit down and work out what is reasonable for IPv6 allocation in total. Because we've rejected Owen's proposal, even though it was a reasonably good one, which allowed much sort of freer allocation of space and we've sort of got these extra concepts of reservation and allocation and everything. We need to sit down and work out what is it that we want for IPv6 allocation and stop doing it piecemeal. Because the whole problem is that there are all these edge cases, we are trying to solve all these edge cases.

What we need to do is sit down and go, what is reasonable, and just sort of stop messing around with it. I mean, you know, there's proposals that we just said earlier that we didn't want to get rid of the multihoming thing. Well, everyone else has. Why are we special? You know, why can't we just all agree that it doesn't really matter. We want IPv6 take-up. Why don't we just give people surety about allocations and stop mucking around with it?

Andy Linton: Perhaps the answer, Matthew, is for you to put a proposal to the next meeting to drastically simplify the thing and throw all the other stuff out. Maybe that's it.

If we were to do that clean-up work, having this proposal already in place would stop that and slow that process down?

Matthew Moyle-Croft: I just don't see a point in having this, if we're rejecting small ones, because they might make the space too big, this one is not going to shrink it, it's going to make it grow anyway. We need to just sit down and work out what it is we're trying to do.

We want IPv6 to be taken up. We don't want people confused about what their rights are. I mean, what is a big ISP? Does it only apply to China and India and nowhere else in the world? In which case, you know, I don't see the point. I strongly oppose this, because I think that we have just got to stop it and sit down and work out what it is the heck we want to do.

Andy Linton: Thank you for that. What I'm going to do is ask the room. I'm sorry, Matthew, if this turns into -- is Matthew's strongly held objection something you're concerned about or can we -- our notion for consensus is that the majority of people believe that this is a reasonable thing to do. Matthew doesn't believe that, he has some strongly held views on that, but because he doesn't believe this will help, I think is the real question.

But I don't think that should necessarily be a barrier to us proceeding with this. So I'm going to ask the question again or get Masato to ask the question again, so we can actually see this.

Having heard this strongly held objection -- Masato, will you do it?

Masato Yamanishi: If you strongly support this proposal -- go ahead.

Byron Ellacott: I totally agree with MMC's view, from Aftab on Jabber.

Masato Yamanishi: If you strongly support this proposal, please raise your hand now.

Masato Yamanishi: The question is still the same. You support or oppose to prop-099, without any change. OK.

If you support this proposal so-so, please raise your hand now.

OK, thank you.

Let me skip neutral.

If you oppose to this proposal, but not strongly, please raise your hand now.

OK.

If you strongly oppose to this proposal, please raise your hand now.

Andy Linton: And one strongly opposed on the Jabber, I think is fair to say as well.

Masato Yamanishi: OK. Thank you.

OK. Chairs think we cannot reach consensus on this proposal, but still we also have quite a number of support for this proposal. So we would like to push back this proposal to the mailing list and continue discussion.

Thank you.

Andy Linton: I think we're at our deadline. We're not going to hear the report from Tomohiro-san, which is the progress of the global policy. I will briefly say the proposal has gone through the five RIRs, it has been accepted at the five RIRs, it has gone through the NRO EC who have recommended to the ASO Address Council that they should recommend it to ICANN. I think that's probably the position we're at. So it's currently with the ASO AC and we have a meeting next Thursday where this is on the agenda. So we understand that we have something to do on this next Thursday. I'm not going to prejudge the issue, but it's on the agenda and I don't believe it's controversial, but we shall see what happens on Thursday.

The process after that is that there is -- ICANN can reject it, they can accept it. If it runs for 60 days, it will automatically be accepted. If they do nothing, after 60 days it will proceed, or they can reject it or send it back for further consultation.

Tomohiro, very quickly.

Tomohiro Fujisaki (NTT): Thank you so much for summarising my presentation, thank you.

Andy Linton: Thank you.

The other piece that we had on our agenda was Adam's potential report, which is to look at a study to take the documentation for the various pieces we have on the website for all the bits of policy and do a piece of consolidation work on those, to actually make them all one document, which is a little bit more readable and so on.

The report was really to say this is work that needs to be done, and I'm looking to Adam, even though I can't really see him, but I don't think we have time to present that, but I think we'll do something to send something to the mailing list about that.

Adam Gosling: Yeah, we could do that.

Andy Linton: We'll send something to the mailing list saying, here is what is proposed. The idea is not to change the policies, the idea is to put them into a more coherent and better form; and before those would be adopted, it would come back to a policy meeting, so that we agreed it captured the spirit of what our policies are.

I'm going to jump over those two, we need to go. Thank you all for your attention and thank you. It would be a great help to the staff, as they're going to do some preparation here, if we could tear ourselves away, leave the room and for those that are coming back, just come back again.

So thank you.

The plenary session will begin at 3.45, not 4 o'clock, or as soon as possible thereafter. Please don't forget, those members who are here and all of you who were part of this process, our next part of the process is to go to the AMM tomorrow to seek endorsement and consensus on the proposals that passed. So it would be good if you would be there, because you're the people who witnessed what happened today.

Thank you.