Transcript

Thursday, August 27 1100�12 30

RANDY BUSH: OK I'm Randy Bush from IIJ in Tokyo. You've already heard from me but now you'll hear from me too much.

Welcome to the Policy SIG, we will be going today over the seven policy proposals we mentioned yesterday and we viewed slightly. And now we can look at the details. We have some procedural matters first. I'm going to try, because we have many cultures and many languages, I'm going to try to put things on that screen that are helpful, because some people appreciate being able to read, and I will particularly put on that screen � when we call for the feeling in the room, the consensus. I will type the question specifically on the screen so we know what we're talking about, or we have a little better help.

You should know that we have two countries who have people in separate rooms who are participating remotely. They will come in come in over video on that screen and we have people from Dhaka and people from Kuala Lumpur. I would like if somebody would volunteer to monitor the chatroom, and if you don't know what the chatroom is, then don't answer, because it is going to be too difficult. So, if somebody is in the chatroom right now, and I can see a list of you, would somebody please volunteer to... if people in the chatroom ask questions, to please take their question and go to the mic and raise your hand to catch my attention. I know it's hard to participate remotely, so, therefore, we try to give priority to those people who will be into Dhaka and Kuala Lumpur and the people in the chatroom who are participating remotely.

So, could I get a volunteer to represent the chatroom? Thank you. Who do we have. You may want to sit near a mic.

WENDY ZHAO: I would volunteer to the chatroom, but I'm going to have a presentation probably in the second one, so during presentation, I probably need somebody to replace that.

RANDY BUSH: During your presentation, I volunteer to watch it.

WENDY ZHAO: Thank you.

RANDY BUSH: You might want to move your computer nearer the microphone so you don't have to do the long walk all the time. But thank you, Wendy. So, we do have an agenda. We have reordered things. Yesterday, we discussed these in number order. We're proposing that today we do them, we kind of group them in those that fit together, the transfer proposals, the v6 proposals, the AS number proposals separately. Is that OK with everybody? Is there anybody who has some comment on the agenda? Is

OK, I am hoping to chair less and less of these things, so, we're going to try to get our co�chairs here to handle a bunch of these sessions, so, to start off with, oh... we should introduce the co�chairs. That would be nice. So, we have... let's be correct. Has this been fixed? The webpage is fixed. There we go. So, Ching Heng is from TWNIC. And Terence is from CNNIC, so the NIRs, you're well respected here as they are throughout APNIC. And Ching Heng is going to chair the first bit, which is transfer proposals and the first one is prop�050. For IP address transfers.

CHING�HENG KU: Good morning everyone, I'm from TWNIC. My mission is to chair the IPv4 address transfer proposal and the proposal has been discussed for many times. So, we hope that we can make the general content this time. So, we welcome Geoff Huston on the stage to give his presentation. Geoff? Let's give a round of applause to Geoff.

APPLAUSE

GEOFF HUSTON: Good morning all, I've got my computer here in case you want to refer to the text, because I've completely forgotten what the text of the proposal is. My name is Geoff Huston and I'd like to talk a little bit about the history of what's been happening here and why I'm back up here again presenting this particular policy proposal. The previous version of this was version 4, which you had so much fun discussing at Manila, that you took the entire day, and finally at the end of the day, ground out what you believed was a consensus and then took it to the mailing list. At the end of the mailing list period, it was then passed across to the Executive Council of the EC and they considered this in May and I noticed that in looking through the mailing list archives of the Policy SIG, the EC then communicated back with the message that they did not see a clear consensus in favour of the policy.

So, they disagreed that there was consensus here, and they also had noted that there were concerns relating to adequate safeguards against potential abuse. And according to the policy development process, it was then referred back to this group for further consideration. And you did a very good job, well done!

The level of participation in the Policy SIG mailing list varies a lot, and 59 posts on this proposal within a period of a couple of months is truly outstanding. Congratulations!

What we did do, though, is that I worked with Philip Smith, who is now the co�author of the policy proposal and we're actually very careful in trying to make sure that the words in the current version, Version 5, are not our invention, they're actually a reflection of what we saw on the mailing list. So, we were going through a process which we'd seen in amongst all of the 59 wonderful posts about proposing where we'd got to, and then seeing if they were happy. Version 5, as far as we can see, certainly represents what we'd regard as being � I wouldn't quite say closure, but there are no outstanding objections left from the people who are participating on the mailing list, so that what you see before you is largely as a result of a relatively extensive process of consultation.

So, what do we do? Compared to Version 4, we did put in a lot of text, and if you'd been following versions 1, 2 and 3, you might have seen that some of the text was certainly familiar, and if you're aware of prop�078, if I recall rightly from Philip Smith and Randy Bush, you'll see that. Detail was added in, and quite a bit of it, to specifically address the comments from the EC regarding the level of additional safeguards against potential abuse of transfers. So, in other words, the process that we used was intended to directly address the reasons why the EC felt uncomfortable at the time. So, the things that are there inside the text is to record all transfers in a public record. And prior to unallocated pool exhaustion, and precisely what that means is in the full text.

Prior to that point, there is an eligibility criteria for transfers and the issue that once a party disposes of an address via transfer, they can only receive a conventional allocation or assignment under what's called exceptional circumstances with the reporting of that activity.

So, Philip and I are confident in saying that it certainly represents the general consensus in some form or fashion of the participants in the mailing list. And it's up to you today to see if the mailing list and your own feelings coincide, and we believe that we have added safeguards in there, particularly the concerns noted on the EC response. So, before I hand it back to the Policy SIG co�chair here, Philip and I, as co�authors would certainly like to thank all of those who have contributed their views and suggestions over the last few weeks to address the concerns noted from the EC, and we're certainly hopeful that what you have before you now does reflect a general intent of the community. So, with that, thank you, and I'll hand it back to the co�chair.

Thank you very much.

CHING�HENG KU: Thank you, Geoff. So, the microphone will open on the floor so if you have any comments? If I have any comments or questions.

RANDY BUSH: Randy Bush IIJ. Geoff, what's the proposal?

GEOFF HUSTON: The URL is there.

RANDY BUSH: That's kind, but it would be very nice since we have the membership meeting if you could just review the items in the proposal. Just a couple of bullet points. What is the proposal?

GEOFF HUSTON: Is there a URL up there. It is certainly on the meeting presentation, yes?

The text you see before you here on the text is probably in front of the laptop. Anyone who doesn't have a laptop? One! Well, this is for you! Please look up! Yeah, section one, introduction, nothing has changed. The summary of the problem has pretty much been constant throughout all of the versions. But the situation in the other RIRs does note that RIPE has implemented this. That's in reference. ARIN has implemented a transfer policy and there's a reference there. LACNIC is currently discussing one, and AfriNIC at this point is the one RIR with no similar policy proposal and as usual, this text would be familiar to those who have seen a long history of edits. This goes through, if you will, looking at criteria here. What can be transferred and so, as you see in very small print, is that large enough for you, Cathy?

Good, thank you. The minimum transfer size is a /24. It actually is part of the portfolio of address space that's been assigned to a current account holder and of course it is subject to all current policies. There's a number of additional criteria. Obviously, they need to be current and known to us, and they also need to have that address, the currently listed holder. This is the first of the safe and they're ineligible to receive or until the final /8 policy comes into effect. So, up until the point where we're actually completed doing conventional applications and assignments, you will be ineligible to receive further allocations, except that the screen is gone funny. But it doesn't matter, because I believe the only person without a laptop has probably got one.

And the exceptional circumstances are that you can submit an application within that period, and the Secretariat will monitor these and without breaking any of the conventional non�disclosure provisions that relate to allocations and assignments, those statistics will record the number of requests and their outcome. The economy they came from, and similar. So, what this is is basically a reporting that if you do need to come back earlier than 12 months for some exceptional criteria, then the Secretariat would evaluate that and that they'd be reporting in a general sense of that event.

The recipient of the transfer � again, must be a current APNIC account holder. It would be good to know who you are. Again, the address doesn't leave the policy frame work. It still stays in there, and while there are still IPv4 address spaces to allocate or assign, the recipient will be required to go through the official utilization of that address space that form part of the portfolio. And again, in another safeguard there, prior to the exhaustion of the v4 space, and again, that criteria is spelled out prior to the use of the final /8, transfer recipients will be required to justify their need for the space under the normal criteria. After that time, there's no requirement. So, once the address space is down to the final /8 and beyond, exhaustion has taken effect, there is no further requirement to justify your space in order to be a recipient.

APNIC address policies normally apply to NIRs. This is no exception. However, the NIRs do have the choices to when to adopt the policy for their members. The Secretariat as normal is requested to implement this in the usual process of the policy development. And for those of you who love reading, there's a huge amount of text in advantages and disadvantage which will take you the rest of the day if you're feeling so inclined. It is discussed at length and I'm sure it is not exhaustive. The effect on the members � they have the ability to transfer the address space, and similarly for NIRs then they choose to adopt this policy for their members, the NIRs would have a similar capability. So, that is pretty much the rundown of the text.

But, as usual, I could be wrong. The text is right.

CHING�HENG KU: Thank you, Geoff. So we were briefed yesterday.

CATHY ARONSON: I just want to make a comment. There's another policy that's going to be discussed, it's a global policy about handing recovered blocks back to the IANA for redistribution to other RIRs and one of the problems in our region with getting the policy past. There are several problems, but one of the main problems is that our region doesn't want to give blocks back to a region who doesn't have a needs�based policy to hand them back out. And I wondered if you could comment about that?

GEOFF HUSTON: I'm afraid I can't comment on that, Cathy. I really am restricting what I'm saying here, too.

YI CHU: I noticed in the recipient, you have a requirement for the recipient to justify, but you will require that before the final /8. After that, there's no need for the recipient to justify.

GEOFF HUSTON: That is correct.

YI CHU: So I think that the transfer activity is going to be more once we reach the final 8. That's where it will stop. So, I wonder why we go through all through this but then you actually relax the requirement? What is the rational behind that?

GEOFF HUSTON: It's good of you to ask me, but in this particular case, what you see here is the outcome of discussions of the people around you in this room. So that requirement is what the mailing list, the group of folk who discussed this feel comfortable with, so, it's there, because folk wanted it there. Why each of them individually felt that that was appropriate, it's for them to say. I have recorded that view here.

YI CHU: Thank you.

IZUMI OKUTANI: I might be able to answer the yes. Sorry, Izumi Okutani from JPNIC. I might be able to answer the question from Yi Chu from our ISPs. They feel that justification is not required after exhaustion because APNIC's role as registry on checking efficient utilization is actually linked to allocations, so no justification is required. Once APNIC no longer makes allocations, it should be just restricted to recording the record of the transfer rather than doing the actual check, and another concern about doing the justification check would be that by adding too much restrictions, people might not bother to register information. And think, if we try to update APNIC about the transfer, APNIC will request for justification.

So, it would reduce the motivation to update the record of the transfer, which will not meet the initial motivation of the transfer proposal. At least that's the case, the reason that ISPs in Japan support removing justification after the exhaustion. And actually, there was another point that I actually wanted to mention besides replying to Yi Chu's question.

I would like to give an update on considerations in Japan, because we did express quite a bit of concern about implementation in Japan about JPNIC's perspective, and we feel that we still have these issues that it is important to consider about implications outside of address management, which are, you know, what would be the legal implications, implications and taxation. But, rather than saying that we have these concerns, we feel that it is more constructive to actually go ahead and review it before implementing within JPNIC. That's what we've been doing since the last meeting and the status of our review is actually � I made a presentation in NIR SIG, so if you're interested in what concerns we have and how we plan to address them, you can see them, and the NIR SIG page and in Japan, we are planning to discuss it within our OPM and that's the update of the status.

GEOFF HUSTON: Thank you very much.

CHING�HENG KU: Thank you. Is there any comment or suggestion? OK. Please speak your name first.

REN HUNG HWANG: We have discussed this in the IP committee. Just to report our conclusion. We propose to remove the session or circumstances from the proposal. The rationale is that short period of time we need to look at the processes and looking at the justification for exceptional circumstances. In addition, prior to the final /8, most people do not think there will be many transfers. So, it is better to keep the policy there.

GEOFF HUSTON: Thank you for that, you are proposing to remove the exceptional circumstances condition. That text was placed in there in response to promotion, or at least in response to add vocation from, I think it was the Japanese community who were particularly worried that there was a period where APNIC would deny service for a period. And they didn't like it that the denial would be absolute, and they wanted some degree of flexibility in the policy frame which they called "exceptional", so the door was not completely slammed shut. Now, I trust I've done justice to the folk who have requested that to go in. But, there are folk from the Japanese community here. If there are any who advocated that text, feel free to respond. But that's the reason why it is there.

I'm completely neutral as to whether it should be there or not. Thank you.

CHING�HENG KU: Thank you, Geoff. And also thank you to Professor Hwang. Any more comments.

SEIICHI KAWAMURA: I'm one of those people that did want this exceptional circumstances put in. Is that was what I thought when the period of non�allocation was 24 months. And it turned into 12 months, recently, and I really haven't given it much thought after it became 12 months, but when it was 24 months, I felt that it was a very long time for business. And over a period of two years, a lot of things can happen to your business, and I felt a second chance would be very nice to have. Of course, you know, you really have to think before you transfer addresses, but in these days, sometimes action can be taken before you actually think over the consequences, because consequences are usually hard to predict, in these times of exhaustion, and so that was my point of view and this 12 months, I don't know.

That's what I think right now, I don't know but I don't think it will do much harm to have it. Did that answer the question?

GEOFF HUSTON: Thank you. I too understood that when it was put in, it wasn't a case of doing harm, and it alleviated the position of saying that absolutely, under no circumstances, and modified it to be "In general, no, but if fl are exceptional circumstances, make the case." So it would seem to me to be a friendly and at least harmless change, and the 12 or 24 months seems to me to be, you know, neither one way nor the other. But the question was... does that answer your comment.

REN�HUNG HWANG: My comment is that it should be simple and straightforward for the policy, and two months is already too short and I think any company that makes the decision should be able to be seen for the next two months. So it is really not comfortable to me that we have these exceptional circumstances and we don't know how to process it and we don't know the justification for that. But, that just creates some concerns that it's not transferring to the public.

GEOFF HUSTON: Over the last 12 months, we saw a huge amount of the financial system of the world figure out that money wasn't what it used to be, and I can certainly have some sympathy with the view that says � 12 months can be an awfully long time in this business, and circumstances do change. So, I must admit, I personally have some sympathy with the view to say � don't slam the door and lock it. Allow at least some ability in the policy to say, you know, things really have changed. Our circumstances are remarkably different from where they were back then. And all of us have lived through that particular change in our business over that last 12 months. So, I certainly see some reason there.

IZUMI OKUTANI: I'm probably echoing what to say, as you mentioned earlier. We had quite a bit of discussions within our OPM as well, and the reason why our community strongly supports making sure that exceptional circumstances condition is included, is that it might put a barrier for those people who are actually willing to transfer address space, but by saying that, you can not apply to APNIC for the next 12 months. It's like a punishment for those people who are willing to give out transfer space that is actually available, so, they feel that it might be a barrier, and that is why we support adding this exceptional circumstances condition.

CHING�HENG KU: Thank you, Izumi. Any other comments?

MASATO YAMANISHI: I think that the intention of this 12 months is to prevent milking the IANA pool. Whatever hand that the intention that under exceptional circumstances is, we should not stop business motivation or business planning. So, I think it's not so simple like simple is better than complex. I think it's � how can I say? The proposed text is minimum consistency, I think.

GEOFF HUSTON: OK, thank you.

CHING�HENG KU: OK. So, I think that.

ANDY LINTON: From New Zealand. It occurred to me that if someone were to come back to the registry and say, I have some IPv4 space that I don't need and hand it back, something that doesn't happen very often, but let's say someone does that, would we have a barrier to them saying that within 12 months, "Oh, actually, you can't have any more IPv4 address space." If they change their mind and they get it back. I don't think that that would occur. We would be at the position where you get the address space back and say, there are some circumstances where I say, why I need some IPv4 space. So that's one criteria for giving the address space or reusing the address space. Under this policy, one of the things that concerns me here is that we envisage that everyone who is going to transfer address space to someone else is some sort of villain or some sort of criminal who is actually trying to work the system.

And I don't think that that is the case. I don't think we're saying that. The people who are going to do this have some space and they want to move it on and we shouldn't be looking at this saying � they're trying to scam the IANA pool and those sorts of things. So I support the idea of the exceptional circumstances. I think if someone hands space over, we should work in good faith and say, they've done this because they think it was a reasonable thing to do, and then after that, if there are some why they need some space, they should be able to come back and say, here are the reasons and yet our hostmasters do a good job by saying, you need the criteria by that and hand them some more space if they need it. But it should be something that happens if they need it. And it should be available.

So I support the idea of it being in here.

GEOFF HUSTON: Thank you, Andy. If I could simply make the comment here that a fair deal of the discussion around these particular issues was in response to the Executive Council's comments that they were worried about the safeguards of potential abuse.

ANDY LINTON: Yeah.

GEOFF HUSTON: And the specific inclusion of text here was both meant to create a safeguard, but allow just enough that if circumstances change, there are appropriate ways through. So yes, your comments are entirely ones that I find appropriate here.

ANDY LINTON: Yeah.

RANDY BUSH: I agree, don't let me confuse things. There's just something happening between New Zealand English and American English that I want to clarify. Irish English! OK, Irish wouldn't call it English, would you!

But anyway, when you used the word "hand over" and "hand back", what I hear is "give back to APNIC for redistribution." And I don't believe this proposal at all intends to say that if you give space back to APNIC, you can not get some back 30 minutes later. It is specifically only transferred between non�APNIC parties and I can understand wanting to safeguard that and I can understand saying that just in case there's something strange and new and different going on, we have this exception clause and we rely on the good judgment of APNIC to apply it only when necessary.

ANDY LINTON: Yeah, I think it's probably a question of a phrase, Randy. I agree with you, this proposal does not have anything to do with handing the space back, but I'm thinking about the mechanisms of someone relinquishing address space, where there are two things you can do. Give it back to APNIC and hand it back, or do it indirectly which is what the policy deals with, and I think that if you were to do the former, which the policy doesn't cover, there wouldn't be a barrier to you getting more space if you needed it, and neither should be there under the policy. You asked the host master to look at the requirements and the exceptional circumstances and be quite diligent in their view of that, but having done that, if someone has a genuine need, then there shouldn't be a barrier, and I think we're in agreement here.

GEOFF HUSTON: Yes, I think we are, and I think the wording in the policy that talks about "exceptional circumstances" and "monitor these requests carefully" is sufficient guidance to the Secretariat that under the circumstances, they do the community expectations with the diligence to make sure that the safeguards are there, but the ability of changing circumstances to have their needs addressed is also there. Thank you.

CHING�HENG KU: OK, thank you.

IZUMI OKUTANI: I just want to make one minor clarification from another point. I did confirm on the mailing list that inter�registry transfer is also within the scope of the policy, as long as the other registry agreed to do the inter�registry transfer. That was the response I believe I got from Philip. Is my understanding correct? So, if the NIR or other RIRs wish to have inter�registry transfer with APNIC, then...

GEOFF HUSTON: Let me qualify what Philip and I believed you asked to then answer the question that Philip and I colluded in answering. The question that I believe you asked was � can transfers between members of NIRs and members of APNIC take place under this policy? And we said yes.

IZUMI OKUTANI: OK.

GEOFF HUSTON: And it is up to the NIR and the relevant text that I think was quoted at some point is that NIRs have the choice as to when to adopt the policy. Just a few seconds ago, you also said "and other RIRs", and I notice that the back of the room, Philip's eyebrows headed to the ceiling and if you were looking at mine very carefully, you would have seen one or two hairs flick up at the same altitude! This policy does not talk about other RIRs. RIRs. And if this community wish today do so, it would be a subsequent policy initiative inside this. So, this policy does not have any text that recognizes a transfer to members of other RIRs. It does allow transfer to members of NIRs when the NIR is ready to do so. Does that answer your question?

IZUMI OKUTANI: Yes.

GEOFF HUSTON: And clarify what happened?

IZUMI OKUTANI: OK, thanks. So, if people want to have inter�RIR, then that should be separate, maybe a follow�up policy proposal.

GEOFF HUSTON: That's correct.

IZUMI OKUTANI: Thank you for the clarification. I don't have a problem with this.

CHING�HENG KU: Does anyone want to go to the mic to present your comment. There's one discussion topic of "exceptional circumstances". But, we also make the general consensus for prop�050. So, we should ask, if you support the prop�050�v5 as described in the formal text, please raise your hand. Is it agreed? If you support the proposal 50, please raise your hand.

OK, thanks. If you oppose this prop�050 v 5 describing the formal text, please raise your hand.

OK. So, I think that we have made the general consensus in prop�050. Excuse me... no, no, no. We still need to speak to Dhaka and Kuala Lumpur and we still need to reach consensus. So the attendees In Dhaka and Kuala Lumpur, do you have any comment or suggestion for prop�050? If you have any comment to make?

So, may I ask the attendees In Kuala Lumpur. The question if the proposal can also include AS transfer number?

GEOFF HUSTON: The question was raised whether this would also include AS number transfer. The proposal does not include AS number transfer. If members of the community feel that such a proposal for AS number transfer should take place, then they should, of course, put a proposal into the policy development process and consider it, but this proposal is explicitly talking about IPv4 addresses and only that.

CHING�HENG KU: So for the IPv4 address transfer. So for the Kuala Lumpur attendees, From Dhaka, is there any comment or suggestion for the prop�050? Please go to the mic to speak up?

OK, they have no comments. We have made the consensus in prop�050, so, thank you, Geoff.

GEOFF HUSTON: On behalf of Philip Smith and myself, thank you indeed for your support on this. Thank you.

APPLAUSE

CHING�HENG KU: Next item is the prop�077, a proposal to supplement transfer policy of historical IPv4 addresses. It's presented Wendy Zhao.

WENDY ZHAO: But good luck. I will propose a transfer policy of historical IPv4 addresses. We do realize that in Geoff Huston's policy, the historical IP addresses have been moved away from his proposal because the current policy for the transfer, has been existing. But it is different. We find out the possibility necessary to support this existing proposal.

So, introduction. The policy proposal seeks to supplement current policy for the transfer of historical Internet resources in the AP region.

OK. The current status in the policy for historical resources APNIC does all transfer to current APNIC account holders made under this policy are recognized and registered by APNIC but APNIC does not require any technical review or approval of the resources currently used to approve the transfer. Position in other RIR regions.

First of all, in AfriNIC, there is no requirement

The detail of the proposal is that until the final /8, until we start to allocate the final /8, these transfer proposals need to be justified according to the same transfer criteria which was the same policy that we had in the past in Geoff Huston's proposal. I would say, that if such a policy exists, but it has exists, just five minutes ago. OK, if the transfer for current IPv4 transfers does not exist, which is not there, then I will accept this. So, after the allocation proposal, principle for the final /8, the justification will not take place. The advantages there where we have the consistency of this which specify IP address transfer. At the moment, we didn't find any disadvantages. So, that's really the whole proposal. Should I hand over back to the chair for the questions and comments?

PAUL WILSON: Hi, Paul Wilson from APNIC. I thought I might make a couple of comments about the policy and I think the first comment is that historical resources are currently not considered to be with APNIC address policies, and that by transferring them into current status, they become current... they become subject to current address management policies. And I think, recalling the discussion at the time, it was considered to be preferable to have resources brought into current address management policies rather than having resources remaining in an ongoing way, not subject to any policies at all. So, there was definitely an element of compromise in allowing the transfers to happen without justification, because at least from the point of transfer, the addresses would be subject to current policies and I would also like to point out for the information of the audience that there is an increasing number of mergers and acquisitions and transfer address space through that, which, as you said, is not subject to any justification either.

But that in recent years has increased quite dramatically, so, for instance, in the month of July, we had a very active month, relatively, in APNIC membership with 51 new members and 11 members cancelling. So, we have... and that's not atypical to have ten or so members cancelling in a month, and the majority of those would be cancellations due to mergers and acquisitions and they will always be related to address space transfer, which as I said, is not subject to any justification either.

WENDY ZHAO: OK, thank you, Paul.

CHING�HENG KU: Are there any comments or suggestions for this proposal?

MASATO YAMANISHI: I think if we will deploy this policy, I think historical leases can not be transferred to the smaller ones. So, we can not assume that it's a clear justification, so, there is a possibility that just less than 50% of historical resource is used. So, let me explain about /16 as a historical resource, but historical resource, only /24 is just used in such case, these historical resources can transfer to small there can't be clear historical justification. I think.

WENDY ZHAO: Yeah, I get you, OK. In your question, it is the case that there's a big block of historical addresses going to transfer to another one which is the small ISPs, which they don't really need that much. But, in the AP region, we have a goal that when we allocate or distribute the IP addresses, they're there. So, if the policy, if the transfer only needs half or 30% of the addresses, then they would only take half of them if that's enough of their business. They can get it either if they are really generous, give back to APNIC, or transfer to another one. They need to look at the assistance with the current but we don't really want to see it making a problem for later on. It will be a problem only if the historical resource, like one block of historical transfer is, sorry, historical addresses were given to two parties or three parties, but so far, we look at the same criteria with the policy which is passed with the /24, which that means that we will distribute our IP addresses based on the needs.

But, after the final /8, I don't have any problem if someone says hey, I have a relation with something here, will you give me the addresses which I might not use for one future year, but I'm going to use them for two or three years. If you do have that relation with the big guy, and you can get there, and the final /8, you couldn't get any from APNIC, I don't have any problem on that. But before that time, if you do and can receive allocations from APNIC based on the requirement or needs, you can choose either to go to the historical or go to APNIC. But it should be based on the evaluation of the business needs.

CHING�HENG KU: Thank you. Randy?

RANDY BUSH: Randy Bush IIJ. Does this apply to acquisitions and transfers? Mergers and acquisitions?

WENDY ZHAO: Um.

RANDY BUSH: Somebody holds historical address space and it's acquired?

WENDY ZHAO: Yeah, sorry, I forgot to make a clarification of that some people look at that. I do think that APNIC has a procedure to deal with... sorry, is not your questions.

RANDY BUSH: I get confused because you're clarifying. I want to understand. Because we are going to ask for consensus on the policy proposal as written, what did you write? Does it apply to transfers? To acquisitions and mergers or not?

WENDY ZHAO: I suppose it does.

RANDY BUSH: OK, then we have a serious problem.

WENDY ZHAO: OK.

RANDY BUSH: Just to understand, I'm an actual operator and I have experience in mergers and acquisitions, having been in a company that merged 66 ISPs in three years. Having to take an organization that the business people and legal people etc. have absorbed legally and business wise, and immediately have to go through the administrative process of actually analysing their use and being able to justify it to APNIC before I can keep the network running is just not reasonable.

WENDY ZHAO: OK, sorry, there's a little bit confusion on this. I might just check with Geoff Huston about the policy that's been passed. That policy included the merging and acquisitions, because we have the current policy of the acquisitions for the policy, which already passed on prop�050. Does that include the proposal that's just been just passed?

GEOFF HUSTON: Geoff Huston in a state of confusion! I actually don't understand the question.

RANDY BUSH: Does prop�050 cover mergers and acquisitions.

GEOFF HUSTON: Of course not.

RANDY BUSH: Thank you.

WENDY ZHAO: Thank you, that would also mean no. I mean, in historical policy, it is that if the policy for the where they don't include the merger and acquisitions, then the historical transfer...

GEOFF HUSTON: Let me clarify a few things. This is Geoff Huston APNIC. There are members of APNIC and they have holdings. Some of them have signed member agreements. Others have and others have looked at that. They are entities which are alive and have a relationship are with APNIC and they have a portfolio of resources. How they attained the portfolio of resources is for the transfer policy. They are current members with resource holdings. Prop�050 refers to those folk and their complete portfolio of holdings and says, of the v4 bit, if you transfer APNIC will register them and treat them. How those resources got into the portfolio of that member is not the subject of transfer policies. The rest of the policy structure.

RANDY BUSH: That was not my question.

GEOFF HUSTON: So, my state of confusion is accurate. I'm totally confused.

RANDY BUSH: That's OK, you answered the question I asked.

GEOFF HUSTON: OK, I'll go and sit down.

RANDY BUSH: So, again, your policy proposal applies to mergers and acquisitions and makes mergers and acquisitions in an operational sense. Those who have to move packets and not paper � very, very difficult.

TERENCE ZHANG: If we need clarification. Actually, I think that the proposal Wendy is presenting, the transfer policy of the current address. Is this then the justification criteria of the historical address will be compliant with the justification criteria of the current... so, if the current address policy does not apply to mergers and acquisitions, then I think the historical transfer does not apply to merge and acquisitions.

RANDY BUSH: So, you disagree with Wendy? You say, when you and I asked, it does apply to mergers and acquisitions. You say it does not. Could you and Wendy please decide?

WENDY ZHAO: Sorry, Randy. I think my second answer to that is... because first of all, I was getting confused by myself because I haven't thought about that part. But after clarifying with Geoff, which means I don't really think that the merging and requirement of acquisitions be with the proposal.

RANDY BUSH: It is.

WENDY ZHAO: It's not.

RANDY BUSH: You're asking us to vote on a specific proposal.

TERENCE ZHANG: Currently, the proposal includes that proposal.

RANDY BUSH: Prop�050 has not passed as we learned six months ago.

TERENCE ZHANG: So let me clarify. The proposal is just like, if we have a current policy for address, for the transfer of current addresses, then the justification here will be the same as current address transfer? If it does not exist, then we will, what we propose is justification is really according to current address management policy.

RANDY BUSH: And since prop�050 does not...

TERENCE ZHANG: Yeah, so...

RANDY BUSH: Since prop�050 does not propose to change justification criteria, it just says justification criteria will apply. It's not changing anything. So therefore, whether prop�050 passes or not does not change justification criteria. So, again, does this proposal apply to mergers and acquisitions or not?

WENDY ZHAO: Sorry, it's a firm...

RANDY BUSH: Prop�050 does not apply to mergers and acquisitions.

WENDY ZHAO: It's a firm no.

RANDY BUSH: Thank you.

GUANGLIANG PAN: From APNIC. Based on my understanding, on this changeable policy, it's locked in code for the... basically at the moment, members can still transfer resources if they are patched to another company or matched with another company. But, we need to have justification like arguments, like legal documents. And also the name change for the register in that country, so, that is already happening. So, that is not encoding into this policy.

RANDY BUSH: But the word you used, justification, it is not justification, it is "proof of transfer."

GUANGLIANG PAN: Yes, proof of transfer from the legal document.

WENDY ZHAO: Thank you.

CHING�HENG KU: Izumi�San.

IZUMI OKUTANI: Izumi Okutani from JPNIC. I think I understand what you're doing, all you're trying to do is make the criteria consistent on what prop�050 is trying to do with historical transfer that is not covered in prop�050. Is that correct.

WENDY ZHAO: Yes, definitely.

IZUMI OKUTANI: Actually, as JPNIC, we don't really have a strong opinion about this, because the concept itself seems like a good idea. But at the same time, I do hear some people saying that actually, the nature of historical resources without any transactions with APNIC, which is like historical resources without APNIC is actually different in nature from historical resources or other resources with APNIC account. So, maybe, we should consider it as a separate issue rather than making it the same. But having said that, we don't, I don't really have a strong opinion about supporting or against it. And with our situation, we don't really have such caches or historical resources. We have contracts with JPNIC, so I'm happy to leave it up to what the committee think about that.

WENDY ZHAO: OK, thank you. I think comment on that as well. With this transfer policy, we have existing historical transfer policy because APNIC would look at how the historical addresses being transferred to the current one to make the registration management and looking at what we know who is holding the historical and looking at leaving some information to the people who really need to find out the information from the historical. But, what I heard from Geoff is that currently the transfer of historical resources is most likely emerging acquisitions, which is much more reasonable, because those are historicals. There's 20 or 15 years old, addresses. You know, the organization changes, the firm changes and I barely find a firm in China who would leave it for more than five or ten years.

And just to clarify Randy, the merger and acquisition is not included in the policy proposal. But the reason weapon wanted to include it with the current address transfer is that we're talking about justification. We don't really want the loophole, we don't want somebody, which we don't want to do with the selling addresses which it seems like more and more people are getting interest on that. So, if we close the door on the current address transfer, and then we still open the door for the historical one, what are people going to do? They're going to stop having addresses from historical which is looking around outside the frame. So, just to make, it's fair enough to everyone who either has historical addresses or current addresses have the same criteria, so we couldn't say, OK, historical addresses is much better because you don't need justification.

And the current is less because you have to justify and can't just have such things. Just try to make it in fairness.

RANDY BUSH: Randy Bush again. Start walking to the mic, Geoff.

GEOFF HUSTON: Start or stop. OK, sorry, start!

RANDY BUSH: What I just heard says that current addresses, current address holders will take over so she's just proposing that the same criteria applies. But what I heard you say a few minutes ago and what I believe you understand from prop�050, is that it must be current account holders. So, those addresses are by current account holders and the recipient must justify the space under prop�050. Is that not correct? Could you answer simply. Like yes or no.

GEOFF HUSTON: This is Geoff Huston at APNIC.

RANDY BUSH: So, Geoff is saying that this problem is solved by prop�050. Am I correct? Are you hearing the same thing that I am? Geoff Huston if I'm going to say to this. Yes or no.

GEOFF HUSTON: OK, I would remind everyone of the current fee schedule that takes place in January 2010. And the full sentence, it says that the fees are based on total address holdings of the member or the service. But there is no distinction as to how those addresses have been associated and registered for that. There is no such concept inside the APNIC serviced community. Members and non�members. There is no longer any distinction between historical and current. If you are a current account holder, you have a portfolio of addresses. And prop�050 refers to those and says "the transfer policies apply with all the criteria, including justification." If I might add just one minor comment here, and I am a member of the Secretariat, so I may be going beyond my normal remit.

You may find it helpful, perhaps, to reconsider this policy proposal after reviewing the fee structure membership agreement of prop�050 and see if there's still a need for additional tweaking. You might come to the conclusion that our existing policy framework, if one assumes prop�050 is endorsed, actually encompasses what you're trying to achieve here already. That would be my advice. You may wish to consider it or not.

WENDY ZHAO: OK, thanks. From the further comments from Randy, yes. I do get your point but in prop�050 it does say that this proposal is actually... sorry, this proposal is actually only covering the current APNIC member, but it doesn't stop us using the same justification criteria because it clearly said... this transfer proposal doesn't include historical holder. So, our proposal is just to say, OK, you can be the historical holder. You can transfer your addresses, but based on the same justification criteria.

RANDY BUSH: Randy Bush again. You're talking about the source. The justification lies on the receiver. Not the source.

WENDY ZHAO: Yes. Receiver.

RANDY BUSH: OK and prop�050 says � the receiver must be a current account holder and must justify.

TERENCE ZHANG: I think that the proposal we proposed is to justify the receiver of the historical address. For the transfer of the historical address. I think that's what it says from the proposal.

RANDY BUSH: Then I think, what Izumi said, subtly, is what you're trying to do is two things. One is talk about justification. And two is saying, all recipients must be members. OK, and prop�050 seems to cover both of those. And what you just spoke to was the second, which also prop�0seems to cover, now Izumi�San, wherever you're sitting, I apologize for putting words in your mouth.

TERENCE ZHANG: Because, as I follow up the mailing list discussion of prop�050, I remember it's basically, it just covers the transfer of current address. It is not historical. That's what I understand. But, if I'm mistaken.

RANDY BUSH: I do not believe that is correct. I have a feeling that Andy is walking towards the microphone with a copy of prop�050 on his laptop.

ANDY LINTON: Just to refresh our memories. The wording in prop�050 doesn't talk about the people who are either have the source or the recipient being members. It talks about being current APNIC account holders. Now, people who have historical allocations do have accounts with APNIC because they pay the $128 a year, and so, this prop�050 does apply to them. Because they are account holders with APNIC. It doesn't talk about members. It says account holders. So I think prop�050 covers this. I understand why you're trying to do this and I think it is good that we cover all of the bases, but I think prop�050 covers it.

WENDY ZHAO: The transfer says, if my memory didn't train me, but if I'm wrong, please correct me. With the historical transfer, if someone wants to transfer a historical resources to others, those resources become, applying to the current resources, going to manage in thee criteria with the current addresses. But does that, according to if you managed the same... sorry, the resources being managed had the same criteria. Does that make the holder become a current APNIC holder? Because you have paid the normal fee?

RANDY BUSH: I think what people are saying, Wendy, is that we think we understand what you are trying to do. We agree with what you're trying to accomplish, but we think it is already accomplished by other means and therefore this policy is unnecessary and just more complication.

CHING�HENG KU: So Andy, do you not have any comment. So, I see we are spending a lot of time to discuss this proposal, to clarify the points. Oh, one more.

AFAB AHMED SIDDIQUI: What India are trying to say is that what prop�050 covers, historical recovery as well, but my point is that you have to be, you know, an expert in getting that point out of it. What Andy just read out, it's like to be the account holder and what Randy is saying to be the member. This is the only difference like prop�077 and prop�050 to make the difference out of it. Is that right, Wendy.

WENDY ZHAO: Yes.

AFAB AHMED SIDDIQUI: So, is it possible to add the word "historical recovery" in prop�050.

WENDY ZHAO: Could be. With the current situation, there's some is that it is really not suitable with the historical transfer, but if I revise the proposal to say that to put the clarification there with the recipient of the current APNIC account holder, sorry, just matching up the current account holder or current APNIC address together to find a way to incorporate them together. Would the audience take this further or not?

CHING�HENG KU: OK, thank you, Wendy. So, any comment from Colombo? No. Are there any comments from Dhaka.

SRINIVAS CHENDI: We don't have Colombo here, it is Kuala Lumpur.

CHING�HENG KU: OK, so there are many discussions about the proposal concept and looking at the justification and clarification. One more comment.

TERENCE ZHANG: We have to look at prop�050. With prop�050 specifically states "the source entity must be current APNIC account holder, so based on this statement, I believe some historical addresses belong to current APNIC account holders." So I think this proposal is trying to address this. That's what I tried to clarify.

CHING�HENG KU: OK, thank you, Terence.

RANDY BUSH: I hear the problem with the terminology. We have a problem in this culture that we use complex terminology, and there are magic words. OK, like, how many people in this room really know the difference between allocation and assignment? Right, very few. But they are critical and we keep using them and we will. And these essentially are kind are formal documents and we have to use the formal terms. The documents could, of course, in the description section provide some help, and maybe that's a good criticism. But the difference between current account holders and members, etc etc, indeed, are useful differentiations.

CHING�HENG KU: OK. Gait

DAVID WOODGATE: Just commenting on the last comment. If the aim of the proposal is to try to deal with non�APNIC members, I'm not sure that that is not outside of the scope of APNIC's capabilities.

CHING�HENG KU: Do you want to answer? I think the proposal looks at the APNIC holders?

WENDY ZHAO: This is really... sorry, this is really getting much more complicated. I do believe... I might need a little bit of help of how many non�members are holding historical addresses?

CHING�HENG KU: Is there something there.

GAURAB RAJ UPADHAYAl Actually, to supplement this question, the real problem is that in APNIC, if you have some historical address space, you can have a non�member account, right, and pay $100 maintenance fee, and now, the question is whether that is address space and administered by APNIC or maintained by APNIC? And until that question is answered, you would either say yes or no to the question.

WENDY ZHAO: I do understand that, but that's a criteria with APNIC with how to manage the historical resources. But according to that policy, there's how many historical addresses have been moved. Because, I know quite large historical resources are out of frame. Not all of them in the frame, so just trying to see if the non�members are there. Have I made myself clear.

SANJAYA: I don't remember off the top of my head how many non�members are holding historical... you know the $100 account that Andy mentioned. But, it's quite a lot. It's more than a few hundred, basically. Now, how many historical addresses in the Asia�Pacific region outside of that haven't been claimed by anyone? And also, there's quite a few there, and yet, we can yet to identify and bring to the system. So, if you ask my gut feeling, probably still, you know, about half�half maybe.

WENDY ZHAO: OK, to give you an idea, purpose of this proposal actually dealing with historical resources, and so, in that case, anyone trying to transfer historical resources, either they're a non�member or member... sorry, the current member who has a current APNIC account who has historical addresses, will need to transfer out, give them historical resources to anyone except the merging authorization will be included in this proposal. Does that answer the question?

ANDY LINTON: I work for a university in New Zealand and up to six months ago, we were a historical address account holder. We had a /16 which was issued over 20 years ago and we paid $128 a year. We applied for v6 address space and we have folded our v4 space. So, we are now a member paying the full fees. So, we've moved from that. When we got the v6 address space, we signed no contract when we originally got it, we signed no contract with APNIC. APNIC didn't exist when the university got that space. And all of those people that Sanjaya talks about who have historical space and who have never taken out an account for historical address management with APNIC, have no contract with APNIC. Is they've never signed a contract with APNIC. You can't propose and say "This policy applies to you." Because they have no contract with you. The only thing that you can do at that point is when they want to transfer it, is that the APNIC member is subject to the policies but the person who has the original block, if they've never been an account holder with APNIC, are not subject to any of the policies. You can't retro fit this on to them. So the thing that's important is getting the resource into the APNIC management structure so that it gets managed, and the prop�050 deals with those people who are account holders. Not members or non�members. People who have an account, who get a bill from APNIC and pay it, and therefore have an contract with APNIC. They have agreed to have a contract with APNIC. Now, if APNIC's terms and conditions, service levels and fees and policies all begin to apply to them, and the new policy that we've just agreed, or subject to ratification, will cover the transfers, because those people who are account holders, who transfer to another account holder will be subject to the policy.

Not members or non�members and the non�member, the people who have the historic space will stop paying because they transfer it away and they'll no longer be account holders with APNIC, because they possibly will have lost that resource, or that resource has moved away from. So, I think that we don't need to have this because current policy, currently, the current policy is about to ratified. And I think we need to have that.

CHING�HENG KU: Thank you. I think that we have a very clear concept in this proposal. So, I think because of the time issue, we should make the consensus at this moment. And if you support this prop�077, I think as described in the formal text, please raise your hand.

OK, thank you. If you oppose prop�077 as scribed in the formal text. Please raise your hand.

OK, thank you. Kuala Lumpur and Dhaka? Do you have any... do you have any comment? For this proposal?

RANDY BUSH: From the chatroom, one oppose.

CHING�HENG KU: One oppose. OK. No comment from Dhaka.

OK, so I think that we can not make the consensus in this proposal 77.

CHING�HENG KU: OK, two opposed in the chatroom. OK, thank you. OK, it's lunchtime, we will continue our Policy SIG at 2:00. So, you're welcome to come back to the Policy SIG at 2:00. Thank you, everyone.

Thursday, August 27 � 1400�1530.

RANDY BUSH: It's 14:01, let's find our chairs and prepare to begin. A 2�minute warning.

Welcome back to the Policy SIG. One procedural matter. We failed to get consensus on the last proposal, number 77. And I have not spoken to the proposal authors, etc. But my suggestion � it's a question of where do we go with it? Is the proposal withdrawn? Is it sent back to the authors? Is it still for discussion on the list? If prop�050 makes it through the process, then the feeling of the room was this was not necessary. So I would suggest, maybe, that we ask the authors to continue to work on the proposal, and we plan on discussing it in Kuala Lumpur. If prop�050 has not passed, then it will be a very serious proposal in Kuala Lumpur, otherwise the authors will have to reconsider it again.

Will that be OK with you, Wendy

WENDY ZHAO: Actually, the intention is this cannot be covered. If in Geoff Huston's � we got the intention that it is being covered. So I don't really think we need to revise and talk until we find out how it's going on with Geoff Huston's proposal.

RANDY BUSH: I think we're in agreement. But Sam, our policy queen, wants us to give her one of three answers. The proposal's withdrawn. The proposal's being worked on by the authors, reworked, which is I think what you're saying. Or, three, the proposal will continue discussion on the mailing list? Am I correct, Sam? Right. May I suggest we agree on option two � the authors will hold on to it and do as they want and it's still an open proposal until we know what happens with prop�050, and then you can decide the procedural withdrawal?

WENDY ZHAO: That's totally fine with me. Thank you.

RANDY BUSH: Thank you. Sorry, we just have three buckets and we have to know which to put it in. So Terence is going to chair for a while. And you can see the agenda there, we're going to take 73 next.

TERENCE ZHANG: Hello, everyone. I hope you enjoyed your lunch. Because we have a very big schedule. We are discussing prop�073. Terry is there to speak.

TERRY MANDERSON: Thank you, chairs. Is this on? This is discussion on prop�073 � version three. Automatic allocation assignment of IPv6, authored by myself and Andy Linton. Before I get in to the depths of the introduction, I'd really like to say thanks to the participants on the mailing list. Having some over 80 posts from 24 people is pretty exceptional. And really goes to show that there is definite involvement in the policy process.

So, the crux of this proposal, and what we're trying to do is to simplify the criteria for a member requesting an initial block of IPv6 addresses where the member already has an IPv4 assignment or allocation. That's the meat of it and that's what we're trying to achieve. We're trying to simplify that first step in the policy space for someone who does not have v6 address space. So APNIC, we would like APNIC to reserve � this is one of these magic words we've been floating around � but there's a slight difference in definition for reserve here and I'll come back to it later. APNIC would reserve an appropriately sized IPv6 block for each member that has IPv4 addresses but not have v6 address space. So this does not apply to you if you already have v6 address space. This does not apply to you if you do not have v4 space but are applying for v6 space.

Members holding those v4 addresses would be able to request IPv6 space pre�approved based on what they have already done or proven to the APNIC Secretariat through a simple online process.

So, the summary of the current problem is that we've observed, through our various interactions with people out there in the world, that it's something they're not entitled to IPv6, some can't see doing the justification. Whether it's hard through time or money. Some actually can't even get organizational approval to research the process to then do the justification.

And we do know that IPv4 space is heading towards exhaustion. The IPv6 uptake is certainly slower than what we'd like. We have tried, all of us together have tried to encourage more IPv6 deployment and that's going swimmingly, apparently, and there are many barriers to IPv6. Not just policy ones, many, many barriers to IPv6. Cost, organizational readiness, training, so on and so forth. This policy is to further simplify the process of applying for IPv6 resources.

So the situation of RIRs? There was a proposal put up in 2008 in the RIPE community. This was about an automatic allocation to every LIR, whether they ask for it or not. This is not the same as this proposal. A member must request for the v6 space. So if no�one wants the v6 space, we're not going to shove it down their throat, to use some fairly glib language. And we've observed no similar formal proposals in other times.

My apologies if you have read the proposal but I'm going to quickly go through the important points here to make sure that everyone in the room is with it. The alternative criteria to be added to the IPv6 allocation, assignment policies, to allow APNIC members that have IPv4 but no IPv6 space to qualify for an appropriately sized IPv6 block under the matching IPv6 policy. APNIC would pre�approve an appropriately sized v6 delegation for any APNIC member that holds APNIC�managed v4 address but does not yet have APNIC matched v6 address. Any APNIC member in the future that applies a v4 address and has not yet received a v6 address. The size of the IPv6 block will be based on the following. A member that has an IPv4 allocation would get a v6 /32. A member that has an IPv4 assignment under the multihoming policy would get a IPv6 /48.

A member that has received an IPv4 assignment under the IXP or critical infrastructure policy would get an /48.

I said I'd come back to this magic word about reserve. I don't believe reserve means forever and fixed. So, it's really a tool for the Secretariat to use in making sure the allocation is seamless as it possibly can be for the member.

So the Secretariat may reserve prefixes for any or qualifying members to allow for a seamless allocation process. It's the responsibility of the Secretariat to select an appropriate reservation schedule, whether that's five minutes or a couple of months � that's up to the Secretariat � and as such the reservation of of that prefix is not fixed in size, scope nor time. A member may come back, they may get more v4 address space. They may hand back address space. I'd like to see that. But they may hand back address space. So it would change the dynamic.

So one of the things here that with that assumption that we have, that this is going to substantially change the current initial allocation practice, we're recommending the APNIC Secretariat community to members and others that satisfy this criteria. That the criteria is simple, the process is simple and they can obviously very easily get their v6 address space and start using it. And it's really great for the Secretariat to be able to do this and show the members there's no barrier here to obtaining v6 address space. That's a recommendation from the authors, not actually the crux of the policy.

So this policy is added to the existing v6 policy. So current policies are still available for those members who apply for v6 addresses without existing v6 sorry, v4 addresses, or decide their v6 allocation is not sufficient and coming back to the Secretariat to get more v6 resources. They still have to go through the HD�Ratio, they have to go through the full regiment of process.

So the advantages? It does allow APNIC to engage with all IPv4 resource holders, allowing them to start working on deploying addresses. We've been saying it in the community for many, many, many, many, many years. It pre�approves prefix resourced allocations. Really making it a simple process. Really cutting down on the work that a member has to do to get v6 space.

So really reduces that duplication of effort, when we believe they've already shown to the Secretariat and to the community that their network has the need for v6. It certainly does remove another barrier, although slight some might argue, to v6 adoption by providing all eligible organizations with a v6 assignment or allocation through a simple request.

The disadvantages here is that this does not deal with historic Internet resources. And I really don't think it should. Effect on the APNIC members � we've been very careful to word this proposal so that it won't change an APNIC member's tier or fee schedule. So it sits within the current EC fee schedule for 2010. It does add a responsibility to the member that they will then have this responsibility for IPv6 resources in their APNIC framework. I think you'd agree that's fairly standard for someone who requires or requests in the policy framework. There are currently about 1300 APNIC members with no v6 resources that have v4 resources. This would approximately � and I'm using fuzzy maths here � it would approximately use up to a /21 of IPv6.

The effect on NIRs � it depends on whether the NIRs wish to adopt this within their own constituency.

So, we're kind of thinking that every member will need an IPv6 allocation eventually. I'm pretty sure all of the exports this morning and yesterday have reiterated this. And this process makes the process of getting that first v6 address block far simpler. And I'll hand back to the chairs for any questions or comments? Sorry, I did have one point. There was some issues raised very late on the mailing list regarding � I think Izumi Okutani, if you're here, you could clarify one of the questions you raised? But, essentially, it was about the � sorry, I think you best word it.

IZUMI OKUTANI: I just wanted to understand if this proposal wishes to simplify the step of application or your intent to change the criteria as well as the kind of checks APNIC host masters make when applicants apply for IPv6 space. My understanding was that the intention simply to simplify the procedure itself and not to change the criteria. In other words, the current two years � the route of v6 allocation within two years. And also, all the checks that host masters currently do to ensure the space will be utilized, they will do that. It's just that the steps will be sent simplified and they will think of ways, host masters will think of ways to do it in a one step way.

TERRY MANDERSON: This comes back to the implementation mechanism used by the Secretariat. I agree with you.

IZUMI OKUTANI: I really support the concept of this proposal and I think it's a good idea to move ahead with this.

TERRY MANDERSON: Thank you.

JONNY MARTIN: I hate to drag out this any further because it seems it's quite a small issue, amongst all the ones we do face at the moment. The stat that 1300 LIRs have IPv4 at the moment but no IPv6 I think is not an interesting one. What is, out of those 1300, how many have applied for IPv6 and are being denied?

Is there an actual problem we're trying to solve here?

TERRY MANDERSON: I don't believe any have been denied. That's not to say that some may have seen the application process as the barrier to applying.

REN HUNG HWANG: The title is automatic allocation assignment. But I think the concept has been changed to not automatically, but still under some requests.

TERRY MANDERSON: It's procedural, I think. I don't think the title will adversely affect the actual implementation of the policy.

ANDY LINTON: I agree. I think we would be perfectly happy if it said simplified rather than automatic, you know. No problem. Jonny asked a question about has any applied and been rejected? Last Wednesday, Thursday and Friday, we ran a series of v6 meetings for industry to persuade them v6 deployment was a good thing to do. At least two of the case studies who stood up and said they have done v6 deployments, one of them was one of the universities in New Zealand, and another one was � I can't remember. But the university one was absolutely clear getting IPv6 space from APNIC, as far as he was concerned, was like getting blood out of the stone. He said it was really hard. He acknowledged he had done this about a year and a half ago but the problem was the information he was giving people was that this was hard.

I would like to read some stuff for you. This was from a document given out at this and by the New Zealand Registry. So you'd think these people would know reasonably well. It says, "Your IPv6 implementation should contain the following stages. IPv6 addresses are not available to enterprise, to own in the some way that some owner IPv4 addresses independently of any ISP. They're only provided to enterprises that are planning to supply to organizations." If you can't have v6, that says. "If you're an enterprise that has your own independent allocation, you may not be able to establish the same IPv6 infrastructure. You may need to consider having a subsidiary operating entity apply for addresses to then supply them to the rest of the enterprise." That's the sort of message that's going out to people.

You can argue that's a communications problem from APNIC or whatever to the rest of the world but those sorts of documents � I've read a number of these � this is deemed to be hard. It doesn't matter if it is hard, people think it's hard. And that's one of the things we're trying to address here. So, that answers Jonny's question.

TERRY MANDERSON: I think we should probably clarify and make sure the communication, part of this proposal is simply a recommendation to the Secretariat. The crux of the proposal is to simplify the application policy, the � I think it should be pretty clear. And there are other advantages gained.

IZUMI OKUTANI: Just a final point, just to confirm, in the current proposal text it says /32 will be allocated to those with IPv4 allocations. But could I confirm this will be /32 will be allocated to those with IPv4 allocations and not end sites. And /48 will be assigned to those with IPv4 assignments from APNIC or those with IPv4 allocations and end sites. I think I'm confusing everyone here.

What I basically want to say is that if you're an endsite with IPv4 assignment, you will receive /48, not /32?

TERRY MANDERSON: That sounds like it comes down to an implementation issue for the Secretariat.

IZUMI OKUTANI: It says no allocations to endsite. As long as we have clear understanding about this and the Secretariat will implement it in such a way to reflect this intention, then I'm happy with it.

TERRY MANDERSON: Sure.

RANDY BUSH: Randy Bush. It would be nice if the text of the proposal reflected the intention. There are two things happening here. One is that you're trying to clean up stated policy to make it very clear you've got v4, here is what you can get in v6. The other is we clearly have a problem getting the message out. I think the Secretariat and particularly the marketing department and the presentation people now have that message and will go home and try to solve that problem. There's a second way to solve it. That is, we have to go home and tell our friends and make it clear on the operational mailing lists. When somebody says it's hard, we have to say, "No, go look URL." So I think the responsibility is, A, for APNIC, but, B, on all of us to go home and make clear that it is there are no barriers to getting IPv6 space if you're an existing IPv4 holder.

And, by the way, if you are not an existing IPv4 holder, it's pretty easy too.

TERRY MANDERSON: Thank you.

AFAB AHMED SIDDIQUI: It is clearly mentioned that /32 will be assigned to every IPv4 holder. Allocated. Yeah. So would that be possible to leave it to the Secretariat to decide, like, if it will be assigned a /32 or a /48?

TERRY MANDERSON: The Secretariat has information about what assignments and allocations they have already given in IPv4 space. It's a pretty close one to one mapping.

AFAB AHMED SIDDIQUE: It says no assignment for endsites.

TERRY MANDERSON: If they have an assignment, they are eligible for a multihoming assignment allocation. Sorry, a /48 multihoming assignment.

So it's based on assignments and allocations, not necessarily endsites.

AFAB AHMED SIDDIQUE: If we stuck with the allocation, what you are proposing is a /32 for an endsite as well?

TERRY MANDERSON: If it's a matching IPv4 allocation.

MASATO YAMINISHI: Is this temporary solution until IPv6 will become more popular or is it a permanent solution. I know there is such description in this proposed text.

TERRY MANDERSON: I think it's a timeline based issue. Initially, this will be used. Over a period of time, people will do their deployment. They will get dual stacked. They will have IPv6 and then in the world that we see an IPv6�only network, this won't apply. So it's an issue for today that's addressing issues today.

DAVID WOODGATE: Telstra. I certainly think it makes sense that if you have an IPv4 allocation, you want to encourage people to be eligible for an IPv6 allocation, which I think is what this proposal is aiming for. I would have major problems if the allocation were mandated to happen or reservations of specific addresses or blocks per member were going to happen but I believe that's not what the proposal says anymore.

TERRY MANDERSON: That's correct.

DAVID WOODGATE: So I can certainly support the proposal from that perspective. I also appreciate that the proposal now leaves it up to the Secretariat to decide the best method to deal with this issue, which I think is the correct way of going about it once we've stated the general aspect of policy. I would like to make caution to any speakers who will say allocations of /32s to people I think. I think it's more a question about saying eligible for allocations, just to be slightly pedantic here. And, also, those allocation sizes are eligible for minimum allocations is the affect of the proposal if somebody has a justifiable need to apply for additional, you know, larger spaces than those minimums, then the existing processes can, of course, be used to apply for those addresses.

So, within all those considerations, I support the proposal.

TERRY MANDERSON: Thank you, David.

IZUMI OKUTANI: Sorry to keep coming back on the same point again. It seems that my concern wasn't properly addressed. Let me confirm once again.

I want to make sure that no allocation, no /32 allocations will be made to end sites. And, according to what you said, those people with IPv4 allocations will receive /32. This might include endsites. So I want to make sure the Secretariat wouldn't make this automatic. Maybe add � this is a bit into details � but I want to make sure. If there are endsites and receive IPv4 allocations, then instead of /32, they should receive /48 assignments. Are we clear about that?

TERRY MANDERSON: This is an implementation issue for the Secretariat in a way a member is coming back and asking for. Is that what you're suggesting?

RANDY BUSH: If you don't mind. I think I understand and I want to ask, OK. Ozumi�san, you were saying the proposal as written might better be the following four points. A member that has a v4 allocation and an endsite is not eligible for 32. A member that has a v4 allocation and is an endsite, is eligible for a 48? A member that is an assignment in the multihoming policy would get a 48. A member that has received an IPv4 assignment in to the IXP or critical infrastructure policies would get a 48? Is that what we understand you're asking for? And that would be a textural change to the proposal?

IZUMI OKUTANI: Yes, thankyou very much for clear clarification.

RANDY BUSH: You can thank Queen Policy over there who sent it to me on Jabber. Thanks, Sam.

IZUMI OKUTANI: I support this proposal.

RANDY BUSH: That's not what the proposal says, though. So you're asking for a modification to the proposal?

IZUMI OKUTANI: Yes.

RANDY BUSH: Thank you.

TERRY MANDERSON: Sorry, Jonny. I'm perfectly comfortable to have the policy modified as such. I don't see that it drastically alters the intent of the proposal. And I'll quickly check with my co�author, he's nodding his head.

RANDY BUSH: Could you make very clear how it differs from the current proposal?

TERRY MANDERSON: Is that a question to me?

ANDY LINTON: I think if we take it, I can't remember exactly what you said, the text. But the key difference here is that where someone who has an allocation, a test, if an endsite /48, if not endsite /32 � is that effectively what we're saying?

RANDY BUSH: Yes.

ANDY LINTON: I'm happy to accept an amendment to the proposal as it is. If we can draft that up and put it on the screen and let people have a look at it, then that would be just fine with me.

RANDY BUSH: We'll have it on the screen in a moment.

JONNY MARTIN: Who has not applied for IPv6 because they think it's too difficult? Hands up. Did everyone understand the question? Some food for thought. Hopefully though that won't take up 150 people's time for too much longer.

ANDY LINTON: It's not about the people in this room. People in this room are here because they understand the process to a very large degree. It's about people who are not in this room who don't know how it works.

JAMES SPENCELEY: I think it could be easier. I think our customers find it daunting and difficult to understand. And the easier you make it, the better.

TERRY MANDERSON: Thank you. Can we have those altered words up on the screen, please. Thank you.

RANDY BUSH: Sorry, this is new technology. We're all learning how to operate our laptops. Let's take the next question while we're doing this.

JAMES SPENCELEY: My question is for endsites which wish to deaggregate for discontinuous routing that would limit them significantly by giving them a /48, no?

TERRY MANDERSON: Yes but I don't want to dive in to routing in this policy.

RANDY BUSH: Are you saying, you're suggesting that you would like it to speak about routing or you're saying you should give them something bigger than a /48?

JAMES SPENCELEY: It would be difficult for them to deaggregate that space. Let's give them something bigger by default, a /32 by default. We're not trying to conserve address space here to the point where it makes a difference and will solve a lot of issues for endsite that do need to deaggregate their allocation.

RANDY BUSH: You're saying endsites would be a 32 and to heck with it?

JAMES SPENCELEY: I believe it's the easiest solution. I'm not fussed. I think it's the simplest solution, possibly.

DAVID WOODGATE: I feel that would be not necessarily in the best interests and if we take the representation in this proposal as minimal allocations, then and I think most endsites would probably be able to cope with a /48 in the first instance and they could apply through the standard procedures if they want something further, without relying on this particular process to do that. I prefer it see it remain as a /48.

TERRY MANDERSON: So the new text that would, for section 4.3 would become a member has an IPv4 allocation is not an endsite would be eligible for an IPv6 /32. A member that has an IPv4 allocation and is an end site would be eligible for an IPv6 /48. A member that has received an IPv4 assignment under the multihoming policy would be eligible for an IPv6 /48. A member that has received an IPv4 assignment under the IXP or critical infrastructure policies would be eligible for an IPv6 /48. I don't have a problem with this for the proposal.

CATHY ARONSON: I have a question. I know in the ARIN region, I know what an allocation and assignment are. How is it maybe of a different definition for an allocation but how is it that an endsite would have an allocation? Isn't that someone, an organization that actually has customers and assign blocks to those customers? I can't reconcile the definition?

TERRY MANDERSON: I'm probably have to defer to the Secretariat for their official definition of allocation and assignment.

SANJAYA: APNIC Secretariat. I had the same problem as you are when I heard Izumi Okutani mentioning there is a possibility that an endsite get an allocation. I'm pretty sure we never give endsites allocations but she's from NIR, so I don't know. I mean, it would be, if there is, it would be that an organization that used to be an ISP suddenly decided not to do ISP again any more and still keep the addresses, but I'm not sure myself.

RANDY BUSH: Would it be appropriate to modify this text to say "It has an IPv4 allocation or assignment in both of the first two bullets." A member that has an IPv4 allocation or assignment, a member that has an IPv4 allocation or assignment and is an endsite. We don't care which it is? Do you care which it is?

IZUMI OKUTANI: No.

RANDY BUSH: Does anybody?

ANDY LINTON: I'd like to clarify. Are we saying we would move to two closes here. One is a member with an IPv4 allocation without an endsite would be eligible for /32 and everybody else would be eligible for a /48? Because that's what we're saying?

RANDY BUSH: They're just special cases.

ANDY LINTON: The second close would be a member with an IPv4 allocation or assignment. But doesn't make the first one. It would make it much simpler. No, I think the /assignment goes in the second close. Yeah.

RANDY BUSH: Sanjaya was trying to say he doesn't know if there's an allocation or assignment. Maybe it really makes no difference whether it's an allocation or assignment. They're an endsite. That's what counts.

ANDY LINTON: If we just said has IPv4 addresses and not an endsite?

RANDY BUSH: Oh, policy queen made the same suggestion at the same time.

GUANGLIANG PAN: Just from implementation point of view, trying to just clarify something. From here first, it would make it easier if a member had an IPv4 allocation and then by default they give them a /32. If they have assignment and then we give them a /48, how we make it a bit easier to understanding it?

TERRY MANDERSON: That was the original text of the policy. What we're really clarifying here is whether that person � that member that has these IPv4 addresses is, or is not, an endsite. And that's something that is a timeline factor in the business space.

RANDY BUSH: What's happening here?

GUANGLIANG PAN: Define endsite. Sometimes it's a bit difficult. In one organization. Inside an organization, they have different departments, they have assignments. So it is sometimes a bit confusing for the host master.

TERRY MANDERSON: Are you muting an endsite doesn't exist? There is no such thing as an endsite because an organization assigns internally? Is that what you're saying? Can you clarify?

GUANGLIANG PAN: For example, a university. Before the people consider them as an endsite for a /32. Just from implementation point of view, if this policy come to � how we can implement it, then we still need to clarify or check with the member. Are you an endsite or not?

TERRY MANDERSON: That's part of your host master role. Sure.

GUANGLIANG PAN: That's not that straightforward to make it easy for people to get IPv6. OK, another point I'd like to clarify is that means whenever a member come, we can have IPv6 available? It doesn't necessary to let them know this is the arrangement?

TERRY MANDERSON: It does not specify to the member this is your range but they are, I guess, pre�approved/eligible for an appropriate�sized v6 block.

GUANGLIANG PAN: What I understand is your proposal is when a member have IPv4 address, you're below criteria for getting IPv6 address space, right? If they already have IPv4, and then they come to APNIC, "I want IPv6." And then if you have IPv4 assignment by default, we can give them a /48? And if you have an IPv4 allocation by default, we can give them a /32? That both is the minimum allocation or assignment size, according to the policy.

TERRY MANDERSON: Correct.

GUANGLIANG PAN: If a member says, "I want larger," that's still possible?

TERRY MANDERSON: This policy is additive. It does not replace the existing HD�Ratio review that you have to do when a member comes back to the APNIC Secretariat and says the /32 or a /48 that I was given under this policy is not adequate. I want more. So you would then have to adjudicate them based on your existing subsequent allocation framework.

GUANGLIANG PAN: Yeah. If that the case, I think this policy may be easier for a member to getting IPv6 address space. They don't need to fill in the form. It's easy for APNIC host master to reduce the workload because we don't need to do it. They have IPv4 address and then we can approve it straight away. Is that what your intentions are?

TERRY MANDERSON: Yes. Thank you. Should we go back to the further adjusted text for section 4.3 which is a member has IPv4 addresses and is not an endsite would be eligible for a /32. A member that has IPv4 addresses and is an endsite would be eligible for a /48?

RANDY BUSH: That's what it says up there. He was suggesting to change the word from not an endsite to assignment.

TERRY MANDERSON: Can you clarify?

RANDY BUSH: Am I correct in saying, what you are saying is it's hard to judge endsite or not to use the allocation or assignment instead? That's what's in the database and the host masters at APNIC can easily tell?

GUANGLIANG PAN: I think based on allocation and assignment, that's the APNIC policy already. But if you're trying to ask and clarify with the member, "Are you an endsite?"

TERRY MANDERSON: We're adding steps. In the glib words of trying to simplify in terms of actual impact, we're adding steps by saying endsite.

GUANGLIANG PAN: I'm trying to make it as simple as possible. The policy proposal is to try to simplify the steps for members to get IPv6, right? I'm trying to clarify.

RANDY BUSH: We understand. Would anybody else like to speak to the specific question of whether it should say endsite, not endsite, as opposed to allocation assignment?

GAURAB RAJ UPADHAYAI: Actually, initially when I read the proposal, this proposal was making it easier for members to get IPv6 addresses. And I think suddenly we've gone into the details of minimum allocation criteria for v6 which this policy probably is not about.

I propose not to fine tune the language but to remove section 4.2, I believe, completely. And use existing policies to determine what either endsite or a member or a non�member qualifies under existing policies. And that probably makes more sense, given in future, if we have to revisit the issue of minimum allocations, we don't have to deal with two different policies at the same time.

So I would prefer to remove all the details and just have a policy or actually a direction to the Secretariat that the IPv6 application process be made a lot simpler is probably three steps now. It probably needs to go to 1.37 steps in the future. And make it easier. And let other existing policies and other existing host master rules to determine whether a site is an endsite or an enduser or an existing ISP. I mean, saying that it is a minimum of /32, say if someone needs a bigger allocation, they still have to go back and deal with the host master on a one�to�one basis. Making it easier has my support. But trying to define the issues of /32s and /48s and allocations and assignments on this policy, I'd probably not be for it. Thank you.

TERRY MANDERSON: The reason why we decided to link the allocation assignment size was to ensure it has no adverse effects on the fees that members were paying. But it could

GAURAB RAJ UPADHAYAI: It could be detrimental sometimes.

TERRY MANDERSON: They're probably quite capable of paying more fees and that would be perfectly fine. In terms of simplifying getting access to two IPv6 form members without impacting their fees I think is extremely important because when it comes down to it, the cost issue is always going to be on the forefront of people's minds when they start looking at IPv6 � how much is it going to cost me?

GAURAB RAJ UPADHAYAI: The policy process never has control over the fee process.

TERRY MANDERSON: The fees are an EC issue. Certainly.

GAURAB RAJ UPADHAYAI: Thank you.

RANDY BUSH: Did you want those words to say, "Endsite and not endsite with allocation assignment, A or B?"

GAURAB RAJ UPADHAYAI: Probably got whatever they qualify under existing process.

RANDY BUSH: The purpose of this proposal is not qualifying. You don't qualify. You have, you get. So if you have v4 space, what do you get? What are you saying they get?

GAURAB RAJ UPADHAYAI: You probably have v4 space under some existing criteria from APNIC. Based on whatever your v4 space was on, you would get the equal in v6. That would be my understanding of it.

RANDY BUSH: I give up. Next. Are you speaking to the current question?

DAVID WOODGATE: Yes. I would like to support Gaurab. I couldn't see any difference that was specified in 4.2, the proposal and the existing initial allocation criteria specified in section five of the IPv6 allocations policy. So I'm wondering why we don't just reference that policy? And say, make an initial allocation consistent with that policy anyway?

TERRY MANDERSON: Sorry, I don't have section five in front of me.

DAVID WOODGATE: I think it's section 5.1 and 5.8 dealing with � what I'm saying is these issues have already been considered, including the specification of the range at which I believe are completely consistent what you had in 4.2. We may be able to avoid this discussion altogether by just saying allocations would be made in accordance with the existing policy.

TERRY MANDERSON: Sure.

RANDY BUSH: We have response for people in Dhaka saying that the majority do not support Gaurab's proposal?

IZUMI OKUTANI: I am for Gaurab and David's idea. If you don't intend to change the current criteria and simplify the steps, then I don't really see the need to go through the detailed discussions on what the endsite should be or how we should word the proposal, as long as the current criteria remains the same. I think there seems to be a bit of confusion on making criteria and documentation, remove the current documentation, or we simply want to make the steps simple. If it's the latter case, then I think we don't need to clearly define the wording. But if you want to change the criteria to make it easier or remove the documentation that APNIC currently requests for, then I think we should clearly document what we want to do. Which one is your intention as a proposal?

ANDY LINTON: Can I have a go at this? As far as I understand, if you go to APNIC and say, "I have v4 space and I would like IPv6 space." The process is relatively straightforward and what we're looking to do is clarify that and make it absolutely more straightforward. When the hostmasters look in the database at your v4 holdings, there are two key words that pop up, it's 'allocation' or 'assignment'. It didn't say endsite, LIR or any of these things. The key for the hostmasters to make it easy for them will be, "We'll look and see if someone has an allocation or assignment." And the question of are you an endsite or not is really quite mute. "

So it doesn't actually matter whether your an endsite or not. It's what are the key words in the database now � allocation and assignment. That's the switch we have to make the decision on. There seems to be no point if we have � we're trying to develop a change in policy here. If we keep looking back at the policy and say, "What does the old policy say?" We can never change it unless we're prepared to say that there was a change here or there is a variation or we made it simpler. The policy that's there is not necessarily cast in stone. This process is about evolving the policy and so perhaps we have to give away the idea an endsite is a critical piece of this?

RANDY BUSH: Let me try to clarify. Izumi asked are you changing the old policy which says you can have the space if you meet these criteria? And you're proposing to change the policy to specifically say the criteria instead of justification is what do you already have? Which we can look up in the database. You don't have to provide justification.

ANDY LINTON: What's already in the database is the justification. You've already justified.

RANDY BUSH: The problem is justification. We have a cultural meaning that says you have to explain what you're going to do with it. And in this case, you qualify � let me use the word qualify � because what you already have, not because of what you say you're going to do. We can look in the database. It says you have an allocation or an assignment. If you have an allocation, you get a /48. If you have an assignment � an allocation you get a /32. If you have an assignment you get a /48. We don't care what you're going to do with them. You can put chocolate sauce on them and eat them for desert.

ANDY LINTON: I'm not suggesting we say that we don't care what you're going to do with them. Again, an implementation issue, I would envisage when you go through the process of going on a website, you'd be saying, "I understand I'm getting these addresses to work towards routing these on the Internet and I'll be pulling them through my organization and all the normal criteria that you get address space under, which is to use it." So we're not saying to people, "This is something you can take away, put it in your back pocket." The intention is you ask for this because you intend to use it and get it routed. It may not be tomorrow, not next week, but you intend to get it out there.

RANDY BUSH: You don't say you plan to have 200 customers. You don't say what your allocation plan is. You don't say what your engineering plan is. You say, "I'm going to use this place to deploy IPv6 in my network." End.

IZUMI OKUTANI: Just before making any comment, let me try to understand what's being proposed and summarize. My understanding from explanations so far is currently you only make allocations to endsites and you make sure that the applicant will route allocation within two years. What you're proposing is you don't really care if the applicant is endsite or not as long as they receive IPv4 allocation. So this part will be changed as a result of this proposal. Is that correct?

ANDY LINTON: Talking about the formal long document that describes the v6 policy? I think this is in addition to that because we're not suggesting that the existing policy disappears for subsequent requests. So if I get this initial � let's say it's a /32.

RANDY BUSH: Or newcomers.

ANDY LINTON: If a newcomer comes along and says, "I'd like to apply for an application of v4." At that point, the hostmaster would say, "By the way, you are eligible for v6." There's a tick box then to ask if they want v6 at the same time. You're right that we're asking to see the two criteria match up. What it means to have an allocation in v4 and an allocation in v6 for your first one are essentially the same.

It strikes me as ironic that there is a policy for a very scarce resource and a more difficult policy for a resource that we certainly, if not have unlimited supplies of, have more of. In some ways we should be turning this the other way around. But I don't want to see that. Let's match the two up and say, "If you've got this one." I can envisage we'll get to the point where someone rocked up and said, "I want v6 space." You'd say, "Do you want v4 as well", if they haven't got some?

IZUMI OKUTANI: OK, that's how it will be changed?

RANDY BUSH: I'm asking is this something you agree with? We have one author who said this, Izumi?

GUANGLIANG PAN: Just from implementation point of view, I just want to clarify that this is the minimum and also it doesn't mean a member have IPv4 assignment that they couldn't get IPv6 allocation. If they can still, they want to have IPv6 allocation, they can still get IPv6 allocation. Even they get IPv4 assignment.

TERRY MANDERSON: Correct.

GUANGLIANG PAN: Right. I just wanted to clarify that point. Also, if a member has IPv4 allocation, maybe they can consider the membership size or the fee. They may choose they want to have IPv6 assignment, they can still do that choice.

TERRY MANDERSON: Correct.

GUANGLIANG PAN: Thank you.

TERRY MANDERSON: This is OK to me. Minus the section about IXP and multihoming. So I'm fine with this.

JANOS ZSAKO: I'm from RIPE. I'm wondering whether you would like �

RANDY BUSH: The audio visual people can not turn up the microphone volume any higher. Could you swallow the microphone.

JANOS ZSAKO: I'm wondering whether you'd add one more word to the second bullet, actually, whether the member has only an assignment because I suppose there are members who have allocation and self�assignments as well. So this would make it probably just a bit more clear?

TERRY MANDERSON: Yeah, I think that's perfectly fine to say if a member only has an IPv4 assignment they'd be eligible for an IPv6 /48 � is that what you're saying? Yes. I think Randy's question off mic was 'is it necessary?' If they qualify for the first one �

RANDY BUSH: If they have both an assignment and an allocation, then if they want a /32, they say, "Allocation, give me a /32." The result's the same. Less words.

TERRY MANDERSON: Yep. I'd agree to that. Yeah. Since there are no more people at the microphone, and we seem to be reaching a point here that we're happy with this � I'll pass back to the chairs.

CHING�HENG KU: We are going to ask for consensus so the question is, do you support the proposal there

RANDY BUSH: So, or not as described in the formal text of the document. But here. Those who support prop�073 as modified.

Thank you, and do you have anything from Dhaka or KL. KL is neutral. Those who want it modified, please raise your hands.

NEW SPEAKER: What about Jabber

RANDY BUSH: Have support from the Jabber chatroom. It is pretty clear that we have consensus.

Terence is going to present prop�078.

TERENCE ZHANG: Is that OK, OK. Good afternoon, ladies and gentlemen. This is prop�078. Reserving /10 IPv4 address space to facilitate IPv6 deployment.

Actually, just a brief introduction. The intent of this proposal is to stimulate native IPv6 deployment as much as possible, while supporting the need for IPv6 networks to communicate with the IPv4 world. It is proposed that when APNIC receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment.

The current status � we are reaching exhaustion and we also know that IPv6, IPv4 will still be used for many years during the adoption of IPv6. So we ask to correct to the Internet using the IPv6 Internet so that the move to the IPv6 from IPv4 will be sustained for many years. Currently, the final /8 policy provides one single /22 allocation to each LIR and does not require LIRs to deploy IPv6.

During the discussion of the final /8 policy, of course, it reached consensus, but I remember there was some comment about shortening this to IPv6 somehow, or to the /22, it is probably too small and there might be too many space left unused in the final /8, something like that. So but the terms of this proposal is to try to supplement, to try to address those kinds of concerns.

So, reserve one slash 10 from the final /8 and we try to dedicate this /10 to IPv6 deployment.

The situation in other RIR regions. ARIN has adopted a similar policy with IPv6 deployment. RIPE has a similar policy proposal under discussion. And AfriNIC and LACNIC currently have no similar policies or proposals, but it might be worth mentioning some policies, you know, just to look at the /22 or /24 and only give to newcomers. Or soft landing but pretty much the same, just that you see the allocation size, which is on the approach and something to link this to the automatic IPv6 allocation, something like that.

I consider this as kind of relevant, but it certainly is not similar because it is especially with the v6 deployment.

And because of the proposal, we separate the details of the proposal into four... I believe it was four. To the four items. The first item when APNIC receives its last /8, IPv4 allocation contiguous slash 10 IPv4 block from the /8 will be set aside and dedicated to facilitate IPv6 deployment.

Allocations and assignments from the dedicated /10 block must be justified by immediate IPv6 deployment. But the key dual stack, NAT�PT or NAT 464 translator, DNS servers, something like that. The key points by IPv4 users, devices facilities is justified by the needs of IPv6 to IPv4 working devices, the Internet working.

Item three, the size of each allocation from the /10 block is /24, or APNIC's minimum allocation size. Whichever is smaller.

Number 4 � allocations under this policy do not affect an LIR's eligibility to apply for IPv4 addresses under the final /8 policy, and vice versa.

So, in order to get the first allocation or assignment, the applicant must demonstrate immediate IPv6 deployment needs, especially the need for IPv6 to IPv4 Internet.

The applicant must have either existing IPv6 addresses or valid applications for IPv6 addresses. The applicant must be an APNIC account holder or a member of an NIR.

And we do allow for subsequent allocation or assignment. However, the current propose add /24 size, there would be a lot of subsequent allocations going on, but we have to still look at this kind of possibility. But we made the requirement more strict in subsequent allocations, so, in order to receive a subsequent allocation, the applicant must demonstrate immediate IPv6 needs, especially for IPv6 to IPv4 Internet working. The applicant must not receive resources under the policy in the preceding 12 months. And previous allocations and assignments under this policy must be strictly used to facilitate IPv6 deployment and the utilization rate is higher than 75%. The utilization rate of assignments for other IPv4 addresses and allocated from APNIC must reach 80%.

And the applicant must be a current APNIC account holder or a member of an NIR.

Advantage � I believe this will stimulate IPv6 deployment as it ensures that LIRs can receive dedicated IPv4 address space from APNIC if they have an immediate need to deploy IPv6. They don't need to worry about the IPv6 network. They will have difficulty to communicate with the existing IPv4 Internet.

And another advantage, support the need for native IPv6 networks to communicate with the IPv4 network.

Disadvantages � there is a remote possibility that after setting aside one /10 that the remainder of the /8 may be used up. If that were to happen, the LIR would need to have immediate IPv6 deployment needs to qualify for IPv4 addresses from APNIC.

However, with the current policy for the final /8, provides 16,384 allocations and currently, APNIC has 12,288 members and that was like for the members of APNIC, the estimate will be about 4,000 members in 2013. And together, with about 2,000 NIR members, so the estimate total members in APNIC is less than 6,000 in the year of 2013.

So, it's not likely for 12,000 allocations to be used up.

The reason for reserving a contiguous /10. First, IPv4 and IPv6 may co�exist for many years and the demand for IPv6 to IPv4 Internet working will be sustained for many years.

Second, the final /8 provides 16,384 allocations, setting aside a slash 10 to reduce the allocations to 12,288. Currently, APNIC has about 2,000 members, so it is feasible to set aside a slash 10 in the final /8. And the dedicated slash 10 block can provide 16,384 allocations with the /24 allocation size.

And then, setting aside a contiguous slash 10 for IPv6 deployment, the last possibility of future special technical handling such as filters or QoS or whatever it is. In the future for this specific block.

And also, according to some research that going from IPv6 to IPv4 Internet working will be stable at a certain level. IPv6 looks at growth and with IPv6 it will grow exponentially. It also grows at a certain stage and the Internet working traffic will be slowed down. And then just a huge amount of IPv6 user. The content provider will start to consider the content from the IPv4 network into the IPv6 network. And so, many users may or may not need to use the IPv6 network to visit IPv4 directly. So, it would be at a certain stage that growth will be slowed down for the need of Internet working traffic.

The reason for the /24 allocation size. First, the specific block is used for IPv6 to IPv4 Internet working purpose, so the amount of address we need is not that many. A /24 or even a /27 can perfectly satisfy the needs for one organization. Currently, we all understand the longest prefix in the Internet routing is mostly a /24. We all understand when we are facing exhaustion, the routing may change, and so, in the future, if longer the block is accepted. Relatively larger allocation size and more are possible. But right now, because we don't know when this change is going to be, and how it is going to change, so, we still specify /24 or APNIC's minimum allocation size.

Another reason, a relatively large area is allocation size to minimize the possibility of an organization getting multiple and contiguous small block, which will encourage the aggregation.

Any questions or comments?

DAVID WOODGATE: I'm very much in favour of the principles that you're trying to achieve. I've greatly encouraged the idea that the remaining IPv4 space should be used to encourage the deployment of IPv6. And in that, I believe I very much, I support the intent of the proposal. I think the battery is going.

However, I do, I'm finding it very difficult to understand how much can be achieved with the /24. You make the claim that a /24 or even a /27 would be perfectly satisfactory for one organization. I'm sort of thinking if you're trying to deploy, if you're trying to connect 50,000 or 100,000 or 200,000 IPv6 users, what technique are you using that could scale to or let 256 addresses usefully interface and name that IPv6 deployment of that level of customers. Could you perhaps explain why you think a /24 or a /27 is adequate?

TERENCE ZHANG: Since the IPv4 address is mostly for the Internet working progress and what we currently have is NAT, so when we have massive NAT /24 with 256 addresses can support. You can do 10 0�1 or 200�1 or things like that.

It is only for heavy users or heavy servers. I mean just this plot is just for the Internet working purpose. But, if you have it, it is free to use that for other kinds of things and servers but the intent is for Internet working purpose. So, when they have the NATs, it can be very much.

DAVID WOODGATE: I must admit whether I'm wondering whether a more appropriate approach with would be something of specifying a ratio of users to address size, perhaps to say the maximum of a APNIC minimum allocation size, so something between a /24 and a /22. And depending on the number, the proposed number of IPv6 users you were going to connect. So, that you might...

TERENCE ZHANG: Cause first when you're using NAT, only the concurrent communication needs to be supported. So, if you have a huge amount of users, only the ongoing communication is there, you know, using IPv4, we are using NATs, and then one address can support 100 users. It's just that kind of concept.

DAVID WOODGATE: I understand that, but for the medium to larger providers, it would be quite conceivable that IPv4 address ratio is in the order of about 50,000 users for a /24, for example. It would be, and there would certainly be many providers who would be looking at 200,000 or a million sort of users and if you could, if there was a scaling possibility to take it from a /24 up to say a /22 for the right sort of proposals, then I would find it easier to support what you're recommending. As it is, I think that the /24 will be too much of a limitation to be of much practical use for many providers. And therefore, I'm finding it difficult to support this proposal, which, as I said before, I would actually very much like to support.

In fact, I would like to use the entire /8 for this purpose. But, would you ever consider...

TERENCE ZHANG: Let me clarify. The intent of the block specifically to help with the IPv6 deployment. But the provider can still use other sources of IPv4 addresses. So, we try to just give an organization just a certain amount of IPv4 addresses, but, I mean, if they are a large service provider, they may already have another source of IPv4 address. So, it is not just... it is not just to use the allocation from this block. This is one of the arguments. And then, they are allowed to get subsequent allocations from this policy. And also, sorry, just to finish. And also, to give you a reference in other RIR regions. The minimum allocation size is /20.

DAVID WOODGATE: Minimum or maximum?

TERENCE ZHANG: Minimum. And also,...

CHING�HENG KU: Terence, sorry. Because of the time issue, may I clarify your point, David's point is that you're in favour of the principle, but you have some argument about a /24? Is that your point?

DAVID WOODGATE: Yes.

CHING�HENG KU: OK.

RANDY BUSH: Just want to quickly respond to that point. One is... I work heavily with large NATs. You're not going to get 50,000 into 24. Two, is that there is not going to be more IPv4 space. You are not going to satisfy Canadian users behind NATs. Get over it. Canadian users! Canadians... Canada has a sparse population. You probably can � we're in China. I'm sorry to abuse the stenos.

One is that you're trying to say that the prop�060 on the last /8 should go down to /24 instead of it being /22. It says minimum allocation. You'd like it to be a /24. And secondly, you're saying that you can come back and get multiple of these. OK, these are essentially the two changes to the proposal?

TERENCE ZHANG: You mean the final /8?

RANDY BUSH: Yes. So really, if you just said the final slash eight changed from the current to minimum to /24 or less, if the minimum is less, you would be happy and I think the original proposals of that, even thought of that and didn't think it would pass. The second thing is that coming back, I have problems with. If the purpose is that you've got NAT in front to get to v4 space, you don't need multiple allocations. And looking at that, was that we're going to be converting for the next 10�15 years � if we're lucky and v6 succeeds.

We need to be able to give this to our grandchildren so they can NAT, and we will actually need those thousands of /24s that are in prop�060. So, I don't think this adds enough value to warrant the complexity and especially the return to get more. And I would personally support making the proposition policy that augments prop�060 to say, make it a /24 or longer. I don't think that making it shorter is a win, because making it shorter is just trying to make believe there's enough v4 space to NAT everything. There isn't. We're out of v4 space.

WENDY ZHAO: Sorry, can I get that question first. You were here before me.

OK, about the question raised by Randy, was actually raised by several people. The actual intention of this proposal, I do believe, is not to duplicate or overwrite something. It is just for a supplement. Think about the last time we're talking about this /8 and how we're going to allocate it. So look at the whole /8, that's why we come up with the idea of the NAT. But as each ISP member only has one /22. But now, that's not the only intention we're going to do. We're going to let the people know that that is the last portion of the IP addresses. So you really should use this block to do some deployment of IPv6. But that's just a signal. We didn't really say that, so, the intention of this proposal actually is not to let... not only to make the intention. Let's make the policy, and another question actually from Randy is � why do we just say that we're going to say we reserve the final /8 and using them as IPv6 and each one got a /22.

Actually, that doesn't really relate to the IPv6. Remember last time when it was asked, do we want to relate this policy to IPv6? And there's really no consensus on this, because people really don't know or don't have an actual idea about what we're going to do, but right now we have a sample from ARIN and we have a clear idea of what we want to do. We want people to clearly understand that this portion that are going to be used for the deployment of IPv6, and there's someone working on that. If I'm supposed to do something, which is not good enough, I would have a policy or a regulation or a responsibility to say � you have to do this, and then we have a valuation on this. That's the intention of this proposal. And the other one is... if... whether if we want to take the whole /8, actually, we're trying to balance of not being too much or reserve too much of the last portion we can have for the IPv4.

Think about it, /22, ISPs can do a lot of things. I know ISPs who live in Australia, they can live perfectly with /22. As with India it's the same. They didn't tell you you're supposed to use this /22, but deploying IPv6. They might use that for the current business. They use them up, and they eventually find out, OK, I have no actual small portion to talk with IPv6. Actually, that's not good, and we're not going to punish them by not giving them that. We have a saying that you use the /22 for your current business and if you find out you need another portion of IPv4 addresses to deploy IPv6, and you still can come back to APNIC and get that portion.

CHING�HENG KU: OK. Just because time is short, maybe when you speak, could you clarify to your point, your comment about the /10 or if you have a comment related to the /24. OK.

GEORGE MICHAELSON: I have two comments on behalf of people in the jabber room. One from Barry Hall in Telstra. Who says "He agrees with the two speakers at this time. A /24 NAT pool is too small to be of real use, and an ISP called Mike who says "As a NOC for a small ISP, a /24 would be too small." So that was two comments from the Jabber room. "

SHENG�WEI KUO: How do we justify the request for the IPv4 address to use in the deployment and if they don't use in the deployment. How do we do that?

TERENCE ZHANG: The first allocation, we need to have a plan and then if they don't follow the plan, they use it for another purpose that we can come to the point that the next time they apply for an address. So, we just control on the subsequent allocation, because that's the only control you have after you give the other addresses. So that the subsequent allocation will specify they have to... the previous allocations under this policy must be strictly used to facilitate IPv6 deployment.

ANDY LINTON: I recall when we discussed the proposal for the final /8. One of the things, one of the key things that we said was that this would make clear to people that this was the last /22 that we would get. We would get a /22 and this would be the final allocation of v4 that people would get, and that the message was to people that they should use that /22 very wisely. Now, it seems to me that the proposal you've got and the recommendations on how you would use this to facilitate the deployment of IPv6. For the message we're conveying to people when they get the final /22 is � you would be very wise to use it for this purpose and not for any other. Then, all you're doing with this is saying � the final allocations are a /22 for everybody. Plus, the /24 for almost everybody, because people who will walk up and say we'll have this /24, and then checking to see after this whether they did good work with the /24 you were talking about allocating to them under this policy.

I think people should understand when they get the last /22, it is the last one. And fortunately for them, because the policy �� prop�073 which has gone through, if they knew, or that it was likely to go to the next stage, they would also get a IPv6 allocation at this time as well. If this was the first /22 and you make the message really clear, you get the /22 and you're going to have an IPv6 allocation at the same time, because it will be their first one. Or they'll already have v6 and we should make it very clear that the sort of ideas that you have in your proposal by the recommendations of what they use this for. I don't see a need to have these two things separate. I support the idea of using the last /8 to do v6 deployment and make that process as smooth a transition, but I don't think that we should have a separate block here for this.

That's my call. Or else go down the track that Randy is suggesting and make the final block have a /24 allocation. But not to mix the two things together.

TERENCE ZHANG: My comment would be yeah, that would be different between you would just give an automatic allocation, and they have a sophisticated deployment plan. Because, I think 73 made the application seem easier. And they may not require to have an immediate deployment plan.

And second, because this kind of space block isn't served for that purpose. I think the current /8 policy, they will allocate a /22, but have not specified that they have to use this for whatever reason, so they might use it for NAT, for IPv4, or something like that. So the purpose of this proposal is to further strengthen the requirement that they have to use the space to facilitate the IPv6 deployment, and they've got to have an immediate deployment plan.

ANDY LINTON: Yes.

RANDY BUSH: Excuse me, can we interrupt. We really have more proposals. No, no, I'm not telling you not to, but one or two sentences and something new that hasn't been said already.

ANDY LINTON: Just to hit on the business about using the last /22 wisely � you know, if we haven't got the message to people when they come for the last /22 that there will be no more, then that poll sip doesn't actually work. There's no point in having a policy that says "This is your last allocation." But if you then say "but", if you fill in the forms and say, if you meet this criteria, you can have some more. It doesn't actually work. The /22 is the last allocation. It's finished, it's over. Use this to get to IPv6 and you could do some else and you could find a way to get some more v4 space. At that point, I think that's enough.

RANDY BUSH: Wendy, short and new.

WENDY ZHAO: Yeah, I know that the audience in this room are wise enough and they know what's happening in the future and they know that we need the future of IPv6. But are the old ISPs really aware of that. You can't really get them to see through the last final /8 and say, use it wisely, unless you give them guidance.

JONNY MARTIN: Jonny Martin.

RANDY BUSH: Who are you?

JONNY MARTIN: It is up to ISPs and other users to work out what to do it themselves. It is their job to look at what is happening in the Internet. I don't think that we need the last slash 10 or second to last or post last.

MASATO YAMANISHI: I agree with Andy's last comment. If we were prepared and as a possibility to get address. I think somebody maybe misunderstood the message of the final /8.

RANDY BUSH: Any comments from Dhaka or Kuala Lumpur? Or the Jabber room? No comments. OK. So, we're going to call for consensus on prop�078 as written. In other words, there have been no proposed modifications here that have been agreed. So, it's prop�078 as written. You can find it on the APNIC website. Would you please put that up there. This is what we are calling to question. Just a sec, Miwa�San.

OK, those people who support prop�078 as written, please raise their hands. What about Kuala Lumpur and Dhaka?

OK, KL. Thank you.

Those people who oppose prop�078 as written. Please raise your hands. �� please raise your hands.

OK, Dhaka.

Kuala Lumpur

OK, thank you. We do not have consensus. Would the authors like to work on it some more?

TERENCE ZHANG: Of course.

RANDY BUSH: The authors will work. Oops, is that a co�author?

WENDY ZHAO: Yes, I would really just like to get an idea of how people really want this policy to go.

RANDY BUSH: That's why we have the mailing list. We really need to move along.

WENDY ZHAO: OK.

RANDY BUSH: Sorry, I understand, but it's not fair to the other proposals. Agenda, please.

We're going to have a working break. Go get your coffee and come back. This is American style. Also Japanese style.

(BREAK)

Thursday, August 27 � 1600�1730

RANDY BUSH: 1 minute. Tick, tick, tick, tick, tick, tick, tick, tick.

Could somebody start chasing people into the room? Thank you, Lou.

Our friends and brothers and sisters in Dhaka had to go to prayers. And in Kuala Lumpur, so, at least Dhaka is off net. I don't know if KL is still here with it. If KL is off net, is Dhaka still working? Oh, we have some friends there. Hi! OK. Glad to have you with us. Let's restart.

The next presentation is Fujisaki�San talking about subsequent allocations.

TOMOHIRO FUJISAKI: Thank you, Randy. I'm Tomohiro Fujisaki and I have a proposal to add in the clarification.

This is the introduction and current IPv6 address policy defines two kinds of criteria. With the initial allocation and the subsequent allocation.

And this is the current criteria and the organizations who look at the subsequent allocation and the organization who need more IPv6 address. And I'm sorry this is very small, but this is the criteria itself to be an LIR, not be an endsite and so on. So, the current problem is that the initial address requirement. This is looking at criteria C. It can aggregate and there's no mention about the allocation criteria. So, looking at the services allocation. And this is for the other RIRs and LACNIC and RIPE have the opposite proposals that deal with the aggregation with the initial criteria. And I had yesterday, this policy meeting in the evening for the proposal to develop the allocation. And the benefits and disadvantages.

The disadvantages is by describing in the document, policy document queen, the future of IPv6 and the disadvantage is that with the current allocation, that this proposal may be non�binding. So there's a requirement, and as I said, some RIRs look at the application from the current criteria and so APNIC has more strict criteria in the IPv6 service subsequent allocation.

This is the implementation and my proposal is to add an aggregation requirement criteria to section 5.2 of the IPv6 policy. And I got the comment on the mailing list that that is the case that aggregation... sorry, deaggregation is required and I modified my proposal to add that there is a technical reason, there is no technical reason that the organization should aggregate the others. And so, in summary, I propose to add the application requirement. And that's all, thank you. Any questions or comments?

Thank you.

DAVID WOODGATE: David Woodgate, Telstra. I think while all of us would agree that while trying to limit the growth of the IPv6 routing table is going to be essential, I fear that it would be impractical to try to impose an aggregated, an aggregate for subsequent allocations for a variety of reasons, both at the level of the requester and also the level of the APNIC Secretariat in ensuring these things. There's also an open question about the relationship between APNIC requiring a routing solution against an allocation solution. In other words, to what extent can APNIC truly influence the routing tables? Thank you.

ANDY LINTON: Could you put your proposed amended text back up?

I agree with David, and I would be much happier if this text said something along the lines of "recipients of further allocations should be encouraged to minimize, rather than must attempt to." This is a reminder to people that it is a good idea to do this, but if there are reasons not to do this, then it shouldn't be a prescription, it shouldn't be a requirement for people. And so, an encouragement here, but not a must.

PHILIP SMITH: Philip Smith, Cisco. Can you hear me? I just wanted to echo again what Andy that I would rather see the encouragement and what's happening in the RIPE NCC, in the RIPE region about moving particular requirements about announcements and so forth. But the one at the bottom there. So, what's going to come real soon in the next few days is something along the lines of the RIPE 399 document which encourages aggregation without making it mandatory for ISPs to do that. So, I would rather see something along those lines, than trying to dictate what we have to do.

TERRY MANDERSON: I, like the other speakers, have thought that it's good to encourage good routing behaviour. I think it is good to consider routing behaviour and the policy process. I would not want to see APNIC become the routing police. So, strong words like "must" I don't really think have a position. Thank you.

RANDY BUSH: Cathy or Louis or someone from ARIN, what is the culture in ARIN along the RIR.

CATHY ARONSON: We in the ARIN region have a proposal, a draft proposal that will be presented that removes the application requirement, and I don't know about that, but there's definitely a proposal to do that.

RANDY BUSH: Very good questions � any more questions before I call for consensus? OK, does anyone from Dhaka wish to speak? Doesn't look like it. Anybody in the Jabber room alive? Don't see it. OK, the question is � do you support or oppose prop�076 as described in the text on the APNIC website?

OK, would those people who support the proposal please raise their hands. And speak in the Jabber room and in Dhaka, we'll get to you in a second. Support for the proposal. Dhaka? Could you raise your hand again? Dhaka, could you raise your hand again. OK, thank you. Those people who oppose the proposal, of which there are a number in the Jabber room. I'm there, I'm just not seeing the number, George, because we try not to vote, but I see them, thank you for calling my attention. Those who oppose the proposal, please raise your hand. Dhaka. OK, thank you. The proposal does not have consensus.

Do you wish to work on it further, withdraw it? Talk about it on the mailing list?

TOMOHIRO FUJISAKI: Yes. Actually, I want to hear the opinions. Personally when I first proposed this proposal at Japan, I proposed to be with consider the allocation and looking at the subsequent allocation. Or to remove the initial allocation criteria. To remove the aggregation. And who supports to remove the aggregation criteria?

RANDY BUSH: So, to go the other way. I believe what he's asking � let me double check. Is that the current initial aggregation criteria is there. He was making subsequent allocations. The next allocation matched, that you also must not aggregate. He's now asking � oh, if they which they should not be demanding aggregation, and demanding how an ISP routs, then maybe we should remove it from the initial allocation. Would people like to see that? People who support that idea, removing � a new proposal that would come next time. To remove the requirement for aggregation on the initial allocation? Or who would oppose such a thing? Jabber room and Dhaka, please? Opposed? Support? Thank you. Oops, we have people who wish to speak. OK, short and sweet and new.

DAVID WOODGATE: Just one request with respect to that, then is that is the current specification in the policy, and I'm trying to remember it myself, is that a mandate or is that an encouragement? I seem to remember it's simply an encouragement in the existing policy, in which case, you'd probably want to leave it as an encouragement?

RANDY BUSH: Could we leave this for the mailing list?

DAVID WOODGATE: Yes.

RANDY BUSH: And I'm sorry to be brutal, but, I'm getting evil eyes from those people who think we should be finished in one hour.

TOMOHIRO FUJISAKI: Yeah, OK.

RANDY BUSH: So take it to the mailing list and suggest making a harmonious policy that talks about current allocation, new allocation and that it's suggested strongly and documented and those sorts of things.

TOMOHIRO FUJISAKI: Yeah, OK, thank you.

RANDY BUSH: Thank you.

RANDY BUSH: The ASNs, and that's Andrew.

ANDREW DE LA HAYE: Wishes that 32�bit ASN proposal. We have seen in the RIPE region a slow uptake of 32�bit ASN numbers. In 2009, up till today, out of the 1300, 46 assignments we made, 1130 were 16�bit and only 125 were 32�bit assigned. So that's a very slow uptake as we can see.

We always request what the reason is if people ask for a certain assignment. 45% of the regions were in the area of their network devices are not working, as they should with 32�bit. Their hardware is outdated and there are no updates available. In 22% of the cases, we see one or more of the peering partners do not support 32�bit ASNs. There are several more reasons. I won't go into all of them. You can read them in the presentation. They're all more or less in the same area. Of course, the merits of these considerations on this slide might be challenged. And we always try to provide guidance to our members but still it seems they have quite some issues with the 32�bit ASNs.

There's the regional part of the proposal which is basically about what the region should do after the first of January 2010? And it wasn't totally clear what the expectations were for the RIPE region. But in the last RIPE meeting, we reached consensus that as of January 1 2010, we will continue with the current way of assigning. Basically, all assignments will be 32�bit, only assignments by default. But if people have specific request, they can get 16�bit.

Now, the global part of it. Currently, and until December 31 of this year, we have an undifferentiated pool, which means there is a pool ASN 16�bit and 32�bit. From January 1 2010, IANA will look at us and see it as an indifferentiated shade of pool. The problem that can rise, if we currently want to refill the ASN 16�bit pool, we can request 16�bit as such. If we have to request new AS numbers, as of January 1, 2010, the policy says it might happen that we have enough 32 and can't get any 16�bit ASN numbers. Although, they're still there.

Now the risk is that RIRs will not qualify for the new 16�bit ASN blocks due to the 32�bit only blocks in our regions.

This is a bit of information on how much time we have left and blocks we still have at IANA. This is the same story basically, different source. So we can see on these slides, both of them, there is still enough space in the IANA pool, 16�bit, I mean. So the summary so far. The current policy was crafted around operational incentives and an earlier run out date. Operational incentives to try to move people to 32�bit. Fact number one � operationally our members don't seem to be ready. Fact number two � more 16�bit left than previously projected.

Our proposal is to sync policy with the current effects.

There are three alternatives. I'll go through them quickly and wrap up. Do nothing. Get ready for the 30�bit. The biggest one is we will run in to operational issues and the RIRs will see angry members. Option number two is extend the global policy by 12 months. The pros is that it basically takes away the cons and there's not a substantial change to the current idea and current proposal or policy I have to say. But you might see me here next year, that's the con.

A run out of 16�bit ASN globally. It's a major change of the policy and the idea behind the policy. Our idea of Stacy and myself, is option two to extend the global policy by 12 months.

We also submitted this proposal because it's a global policy. IANA is involved in to the other regions. In LACNIC the global has been proposed. It's under discussion and we're using the expedite process. It's some kind of fast track they introduced. And we also submitted a proposal. In ARIN, it's currently discussed and in the RIPE region, we're in last call for this proposal.

So that's the story. Any questions?

GEOFF HUSTON: The unfortunate author of the policy that you wish to amend, that's me. It's certainly true that in setting deadlines and creating that original policy, we had the optimistic view that this would indeed create clear signals to both the industry and vendors, as to when equipment should be ready and fielded and deployed. You're quite right in the observation that goes, "We should be now seeing 16�bit AS numbers as historical artefacts, whereas you've allocated some 4�byte numbers which are not much in use. By changing the date in the policy, rather than saying is there any other way of doing it, I kind of wonder if you're playing ever so slightly without addressing it. "

When we look at what's going to happen in January 2011, when this policy runs out, there will still be between three and four blocks of 1,024 numbers left at IANA, just. Probably only three. If we're still addicted to 16�bit ASN numbers. Some time this whole policy process runs out of time and what strikes me as being something that I didn't hear you discuss is did you think about just carving them up between the RIRs now?

ANDREW DE LA HAYE: I think that will be the next proposal. We didn't go into that one yet of carving them up now. It might be something we can discuss. It's a totally different discussion. We wanted to make it as clean and easy as possible for our members to at least extend it for another year, because we are running out. It's like January 1, 2010 is almost tomorrow. So this will help us to at least extend the date of this implementation and of the next 6, 7, 8 months we can in length discuss dividing whatever is left of the RIRs.

GEOFF HUSTON: Speaking as a member of this community, I clearly agree with you that for this policy to � the one we have in place, not the one you're proposing � to get to the end of this year and still leave some numbers in the pool but IANA and the RIRs are unable to do the right thing by their community is not a good outcome. So we do need to do something � operationally in policy, whatever � to solve this particular issue. From that respect, I agree the time is right to consider this and do something. Thank you.

ANDREW DE LA HAYE: Thank you, Geoff.

RANDY BUSH: IIJ, Randy Bush. How many people in this room think this is very similar to another problem � IPv6? We're running out? It's not being deployed? Devices do not support it? Yes, we have a pool left but maybe we should look � and I agree that, hey, we've got a current policy that ends at the end of this year that we better fix, I have no problem and I probably support this proposal � but I think we need to take a little longer and deeper thought. Think about things like prop�062 that would reserve 32�bit ASNs in one per customer for the next years for those people who can't deploy 4�bytes or whatever. I'm not suggesting specific policies but I'm saying maybe we should learn from history and parallel problems?

MASATO YAMANISHI: I basically support this proposal because the implementation of 4�byte AS of each bit of software, are not so sure. So I'm saying that we should, we should postpone the deadline of 2�byte AS. I don't like to do so, but we should.

Also, on the other hand, we need to keep promoting 2�byte AS is almost running out. That's my comment for this proposal.

ANDREW DE LA HAYE: Thank you.

GEOFF HUSTON: Just to give you some data about if this policy went through and we continued to differentiate. So, if we were continuing to treat the 16�bit pool as we currently do and do allocations such that when each RIR gets to a low threshold, it gets a group of 1,024 blocks in the next 18 months or 9 months or whatever. Out of the pool of AS numbers, APNIC will probably get two blocks of 1,024. It's due for one immediately. Interestingly, it's due for one, the last one in February 2011. So, if we don't differentiate, APNIC misses out on one.

RIPE is going to do 3,072, three blocks of these. RIPE will actually get them inside the period between now and December 2011.

ARIN is consuming at a faster rate at this point. It's due to get 4,096. But if this policy only extends it by one year, they'll only get 2,048 and they'll miss out on 2,048 because the other two blocks will occur very, very close to that final period in February 2011.

So you might want to consider pushing it all the way to the end, and instead of talking about December 2010, talk about June 2011 and treat the remaining pool as the remaining pool. However, I do stress that Randy's note about saying, "Do you really want to use them all up or do you want to keep something just in case," might be a consideration. It might. I don't know. I really have no idea how important that might be. But you can either run them all out or you can possibly think of keeping a few. I don't know.

RANDY BUSH: That doesn't have to be global policy?

GEOFF HUSTON: That's correct. It wouldn't have to be.

RANDY BUSH: It could be what APNIC decides to do with the 119.3 AS.

GEOFF HUSTON: That's correct. You should also take into account a little bit of fact here. APNIC gets through 1.45 AS numbers a day. RIPE gets through around 5.3 AS numbers a day. ARIN gets through around 5.8 AS numbers a day. And AfriNIC and LACNIC get through remarkably few. The two RIRs have a large amount and the other three don't. That's the way the data has been running consistently for some time.

ANDREW DE LA HAYE: We can explain it. In our region, people want to be autonomous in that sense. I do also agree with you it would be nice to have an additional policy or whatever next to this one, or after this one, where we say, "OK, we have to look at the global pool and how can we divide it equally, if there's any equal kind of measurement in this world." However, the lengthy processes of our policy stuff will give us problem as of January 1. That's why I'm proposing this. And I'm very glad to discuss other proposals in the different manner.

GEOFF HUSTON: I'm not proposing anything but I hope the data has been good.

ANDREW DE LA HAYE: Very useful. Thank you.

IZUMI OKUTANI: Just trying to understand the proposal. This is basically trying to change the IANA to RIR allocation part. Not the part from APNIC to LIR. Is my understanding correct?

ANDREW DE LA HAYE: Yes.

IZUMI OKUTANI: I support this proposal because I totally understand that it's important for RIRs to ensure smooth service for the members and as long as the definition in APNIC's document on distribution on ASN remains the same. So from January 1, 2010, there will be no distinction between 4�byte ASN and 2�byte ASN. It will still remain pressure for the applicants that better be prepared. And I think in addition we can maybe try to have some promotion to transfer to 4�byte ASN. I don't know a specific plan at this stage. I think this is a good proposal. And to address the reality of the current problem.

ANDREW DE LA HAYE: Thank you.

MASATO YAMANISHI: Based on Geoff's statistics data, I believe if we will, if we will implement this proposal, it will become quiet after 1.5 years later. But just in case, because I'm trying to support 4�byte AS in my company. It's very hard. But there's a lot of problem some router cannot support 32�bit AS anymore, or we need to upgrade router's software. And also, two weeks ago, a quite severe path related to 32�bit AS number found in some router. It is also evidence which it is almost becoming quite severe case. Thanks.

GEOFF HUSTON: Let me just correct that one, in fact. People noticed that DGP tend to bring down the peer session when zero is in the AS path. Not 2�byte, not 4�byte, zero. All BGP implementations are vulnerable. There is a, if you're from Cisco, a security, whatever it is about this implementation and there may be some from other vendors. Please, it's not a 4�byte problem. If you run BGP and someone constructs an AS path with that, the peer session might just come down.

LOUIS LEE: Might I remind folk physical you're looking for justification within your company to deploy 4�byte ASN, you can still continue to look at the RIR to membership assignment policy as your justification because this proposal does not change that. It only changes the assignment practice from IANA to the RIR.

ABAB AHMED SIDDIQUI: I want to ask one thing, why does the gap of 12 months if Geoff gave some statistics like 1.2 assignments and we still have a lot of time? So why the 12�month gap for APNIC? Can we remove that gap? Not until the end, but just keeping one block with us and take it till the end?

ANDREW DE LA HAYE: That could also be an option. A year, two years, 1.5 years, this will at least help us for the next period. And one of the thing was there is still this thing where people will see 32�bit will be next year. If we make it longer, there's less pressure and we thought it would be nice to keep a bit of pressure on. Having Miwa on stage, showing people it is an issue. We don't have to discuss it but you never know. This was one of the reasons to.

MASATO YAMANISHI: Let me step back to stability. As Geoff said, if suddenly � it was 4�byte AS because it seems wrong update, who generate that wrong update? It is different company router, then � no. But, what I'm saying is the implementation of that router which generate that wrong update is bad. The data was 4�byte AS.

RANDY BUSH: Are there questions? So, any questions from Dhaka? Any questions from the Jabber room? OK. Could you speak loudly, please? We have a question for the Jabber room saying they are not following the reason for this change? The reason is purely � let me see if I can say it simply � the reason is purely administrative. We have a global policy that says that IANA will not give the RIRs more 2�byte ASNs after the first of the year. That's four months from now. And therefore RIRs will not be giving members 2�byte ASNs, starting January 2010. Equipment vendors do not universally support 4�byte ASNs. Members are having trouble deploying them, so this is in a sense emergency request to change administrative policy, so that IANA allocate to the RIRs and the RIRs to the members, 2�byte ASNs for one more year just moves the policy to the right, one more year.

And that's the end. That's the proposal. It is expected in that year that other things will be proposed and thought about to make this transition work a little better.

ANDREW DE LA HAYE: That's a fair statement, Randy.

RANDY BUSH: Jabber room says they understand now. Questions from Dhaka? OK. So how about the question is do we support prop�074 as described in the next? And for change first we're going to ask Dhaka. Dhaka, if you support prop�074 as described, would you raise your hands, please? Thank you.

Jabber room � support? So far the Jabber Room supports.

Here we are in Beijing, with those people who support the proposal as written, please raise their hands?

Thank you. Dhaka, would those people who oppose the proposal please raise their hands? Jabber room, any opposition? Beijing, those who oppose the proposal as written, please raise your hands?

The proposal has consensus, thank you very much, Andrew.

ANDREW DE LA HAYE: Thank you very much.

APPLAUSE

RANDY BUSH: OK, the last one is ensuring efficient use of historical AS numbers, prop�075.

GUANGLIANG PAN: Hello, everyone. I'm a resource service manager of APNIC. I'm here to present a policy proposal 75, ensuring efficient use of historical AS numbers.

I would like to provide you the background information of this proposal. But 16� bit ASN pool is reaching exhaustion but many networks are not prepared for 32�bit ASN numbers.

APNIC can reclaim unused AS numbers assigned under current policies.

APNIC can also reclaim unused historical IPv4 address space. However, there is no similar policy for historical AS numbers.

Please look at more details of these reasons. First, let's look at the IANA 16�bit ASN number allocations data. From this graph, you can see in the last five years IANA allocated 3,000 to 6,000 2�byte AS numbers per year. There is 9,200 2�byte AS numbers in IANA in the allocated pool at this stage. You can see the green bar there.

Based on our conclusion of the current use, we think the IANA pool will run out in 2�3 years time, like about 2011 to 2012. However, the 4�byte AS number is not what we expected. I just look at 4�byte AS number report yesterday. There was only 77 4�byte AS number. It is interesting the 2�byte AS number is also running out as the IPv4 address at a similar time. So we need to address this issue. This is the first reason for this policy proposal.

The second reason, the current APNIC ASN policy is the return of unused ASN numbers. But this policy does not apply to those historical AS numbers. So we need a policy to cover that part.

APNIC has a policy proposal in 2004, which asked us to reclaim unused historical IPv4 address space. We actually tried to implement the policy. And reclaim some of the historical address.

Here is a statistical report. APNIC Secretary estimated the total in 2009 prefixes. And after we contacted those organizations, 3% of them actually routed it and then they used that space. And 14% of them claimed it, they said, "I want it. I want to still keep this range." And there are 37% is uncontactable, even by email, phone, fax, all this, but it's not contactable. And about 6% they returned their address to APNIC. They're happy to do the right thing. They say, "I don't want it. I don't use it. I want to return." That is very good,

This is can see the assignment to other APNIC account holders. Before I go into the proposal details, I would like to give the definitions. What is an historical AS number? Historical resource AS and reduce the early registry and policies without formal agreements.

It means that those AS numbers are not correlated by the current policies. And what is the unused AS numbers? Any AS numbers which has not a global in the routing table for a specified period of time, and they call it unused AS numbers. Some people may argue here � how about I use the AS number internally or privately, and you're probably not able to see that. So, in this policy proposal, we're not going to return those AS numbers if you tell us you want to keep it. So it doesn't matter if you're using it partly or you don't want to use it, you just say � oh, I want to keep it but we can't see it and we don't know if we're using it privately or not.

So, let's look at the details of the proposal. It is proposed that APNIC recovers historical AS numbers that have not been used for a reasonable period of time after a period of time, reclaimed AS numbers can be re�assigned.

If organization with unused AS numbers wishes to hold on to the AS number, APNIC will not reclaim.

This is the detail of the proposal. And how to implement this proposal. So step one, the APNIC Secretariat will identify unused historical AS numbers and generate a list. And then, notify the organizations responsible for unused historical AS numbers.

If the AS number in has an NIR, they would also ask the NIR to help, to contact. That organization. So, the first step is trying to identify the list and contact them and let them know that your AS number is not using. And then, the second stage, and how APNIC do with those responses, like, how they process the response. The ASN will be recounted if the AS number holder agrees to a return of the AS number. Right, if I use it, I'm happy to return it, that's fine. Then you just tell APNIC and APNIC reclaim it. And also, there would be another case where no response is received after three contacts in three months � or even more. That is the experience we had. When we reclaimed the IPv4 address space. They don't respond to you, or they even no contact.

In that case, my proposal is that we should reclaim the AS numbers. But, I received some feedback that would be put, that someone may use it, but they may not respond, or the contact information is incorrect. So, we can't contact them. So, I have another option put in here in the yellow. Now it says, if there is no response received after three contacts in three months, should we reclaim it? So, I will ask your opinion here. Of course, for those AS numbers we want to keep, that's OK. But for those AS numbers, we contact them a few times, but there's no response. So, how do you think... should APNIC reclaim them? Or we should not reclaim them? I would like to ask you, like to give me some feedback and your opinions. Then I can modify that proposal.

I would like maybe if you want to raise your hands. If you think, if we don't receive a response from those organizations to reclaim them. If you agree with that, maybe you can raise your hand and let me know. This is what you think we should do. Can I get your opinion here?

DAVID WOODGATE: David Woodgate, Telstra. Just wanted to ask, in the process of considering contact information, if you weren't getting response from the contact that you had, but you were, you knew that they had a corporate phone number or something like that, would you try to contact the corporate phone number in addition to any previous contact information?

GUANGLIANG PAN: Yes, that's the implementation procedure. We would try to use e�mail first, and then if no response, then we would try to use the phone, if we have their phone number. Yeah.

DAVID WOODGATE: I suppose, I mean in the sense of... you may have all of this information, but if, for example, I know that if a large company, individual e�mails or phone numbers may get lost, would you say this is a large company X, we'll look it up in the phone book and see whether we can contact somebody through that?

GUANGLIANG PAN: Not at this stage.

DAVID WOODGATE: OK.

GUANGLIANG PAN: I mean, if everyone would like to do that, I think it is possible. But that will be a little more human resources to do that part.

DAVID WOODGATE: I understand.

BILL WOODCOCK: I was just doing a little bit of math, and it appears to me that you're doing a special purpose policy that will give you another 71 hours of run time on 2�byte AS. And coincidentally there are about 150 people in the room and we've spent about 30 minutes discussing this, which is also about 75 hours of people time. It doesn't really seem like a good use of the policy process to me.

RANDY BUSH: I think your question was, if they could not be contacted, do people in the room support recovering the ASN?

GUANGLIANG PAN: Yes.

RANDY BUSH: That was the question, yes?

GUANGLIANG PAN: Yes.

RANDY BUSH: Well, to answer that, my feeling is, when I read your proposal, you say that you will recover it, but you will keep it to the side. First of all, you will try hard to contact them?

GUANGLIANG PAN: Yeah.

RANDY BUSH: Then if you recover it, you will keep it to the side for 12 months to see if they magically come up and say � oh, you've got my address. Give it back. Which I think is doing about as much as you can to try to be fair. So, I support that. I would suggest one further thing, which is... if three years later you have given it out to somebody else, and they come back and they say "Aargh" and I need it, that you give them a new one. Now, I notice that's a new 2�byte ASN, so this would tie into the problem of reserving a small pool of them for the future. Geoff is looking puzzled. I'm saying that right now he's proposing, Geoff, to hold on to it for 12 months. I'm saying that this is something that wasn't well maintained. If they come back three years later and say, oops, I'm sorry, that person left the organization as David said, the example was, how do you call Telstra?

There's ten million people there. So, looking it up in the phone book is not very effective. So, you know, they come back and they say, hey, I did have that, you can understand why you recovered it, but can I have some space back, and by the way, here's why I need it. I can justify it. But if you've got a pool of old 2�byte ones you're saving, I deserve it.

GEOFF HUSTON: Geoff Huston APNIC. I'll answer this quickly. I was looking puzzled because when two people try to use the same IP address.

RANDY BUSH: I didn't say the same ASN.

GEOFF HUSTON: No, I was going to say, when two people use the same AS number, it seems to happen quite a lot with the bogon list. No�one seems to notice, let alone have a problem. The bizarre thing about AS numbers is that clashes are, most of the time, harmless, as we are proving with AS 23456.

RANDY BUSH: At the lightning talks, the first lightning talk that I do because I have to run off to another meeting, and you will see that I used other people's ASNs and I will gladly give you the collection of outraged e�mail that I received for using other people's ASN.

GEOFF HUSTON: My point is that you could never get the collection of outraged packets that were delivered, because there weren't any?

RANDY BUSH: No, but if you use somebody else's in AS.

GUANGLIANG PAN: OK, Izumi, any suggestions?

IZUMI OKUTANI: Yes, I'm basically supporting the idea that if you contact the holder and what we do in JPNIC for historical resource is that after we do all sorts of things to contact the organization look at the range and the organization that's holding that space for a certain period of time. I can't remember exactly how much. And they and say that the holder of the space contacts JPNIC and we're doing the same thing for historical ASN at this point. Maybe you could at this step, that's just one snugs

GUANGLIANG PAN: Probably I'll move on to the next slide and then answer your question. Is there anything you wanted to say?

SHIN SHIRAHATA: From Tokyo 62 for project. I agree with your process on proposal, but I found a program on the definition of unused AS numbers, because we are seeing one is for IP before any prefix only. So, if AS number could not be observed in some country or some area, our AS number could not be seen in the global routing tables. So, I would suggest that to change the definition of the unused AS.

GUANGLIANG PAN: OK, first. What I would say, yeah, we can discuss that later. Yeah.

GEORGE MICHAELSON: And we have one comment from the Jabber room who says that he would like the procedure of verification for the address of information to be clear.

GUANGLIANG PAN: What does that mean?

GEORGE MICHAELSON: He would like a clear procedure for verification.

GUANGLIANG PAN: OK.

GEORGE MICHAELSON: About the address associated with the information.

GUANGLIANG PAN: OK, OK, thank you.

GAURAB RAJ UPADHAYAl: I agree with the previous comment that the visibility of the global routing table does not indicate whether an ASN is being used or not, so please pay attention to that. Maybe another definition is needed on that. Thank you.

GUANGLIANG PAN: Thank you, yes. Thank you.

GUANGLIANG PAN: OK, we'll move on to the next slide and it may answer some of the questions, actually. Yeah, all we can, the all of the steps, all of the recovered AS numbers will be removed from the public APNIC Whois Database, and kept in the APNIC unallocated pool for 12 months before redistribution to other networks. This is my original proposal. And I also received some comments, like in the yellow. And they say, like, it may be better to use those reclaimed numbers after the IANA 2�byte ASN pool runs out. And so, we can move on to discuss it later.

Here is some figures of the APNIC managing the AS numbers we have 5,780 2�byte AS numbers and advertised 3,755. Unadvertised, 1,717. And there's still 308 in the APNIC pool. We also have some historical AS numbers and I just checked. We have 51 unclaimed ERX ASNs and unclaimed for historical ASN numbers. These figures just give you an idea of how the policy will be, because what the policy implemented, what we get from this policy. This is just a target for the historical AS numbers. This is the bottom part of them, like the 51 and 34 AS numbers is possible on the target list, and most of them is not used so this may be impossible to reclaim.

And the current AS number is governed by the current AS number policy. If we can implement it at the same time, like, we try to get a program, and you can. All of the unused AS numbers. That is the data you can see.

And there's advantages for this policy proposal. This proposal will use the numbers back to the unassigned pool. There are also disadvantages. This proposal would look at the increase in the work of the APNIC host masters. There's no direct impact to normal APNIC members. NIRs are encouraged to have reclaim unused historical AS numbers within their economies. There's no similar policy existing in other regions.

So, questions?

RANDY BUSH: Further questions? Jab

REN HUNG: The same question because one of the ISPs told me that they were looking at the one AS number, but it is not, that would not appear in the global GDP table.

RANDY BUSH: But they may respond to e�mail, yes?

REN HUNG HWANG: I guess they just don't want to be bothered by this issue.

GUANGLIANG PAN: OK, but how do they know the AS number is not in use or used it privately and not being able to see. Is anyone going to answer that question from a political point of view.

RANDY BUSH: I just want to make a comment. Somebody a global resource for which we're all responsible.

AKINORI MAEMURA: I would like to have some clarification. I think there is on page nine.

GUANGLIANG PAN: Which one?

AKINORI MAEMURA: Page 9.

GUANGLIANG PAN: OK, which one?

AKINORI MAEMURA: There's an expression of the associated NIR, with the contact means.

GUANGLIANG PAN: It's here, is it?

AKINORI MAEMURA: This is the page. So the contact associated with the NIR, then I would like to direct meaning of the associate.

GUANGLIANG PAN: Actually the AS number may look or the AS number is... it's in the NIR's economy.

AKINORI MAEMURA: OK, then if the concerned AS number is under the NIR, then the reclaimer should be the NIR, not APNIC. That's my point.

GUANGLIANG PAN: Yeah, you mean like after the AS number is recovered, the AS number should be in the NIR pool?

AKINORI MAEMURA: I don't necessarily mean that, but APNIC doesn't reclaim the AS numbers which is under the itemization of the NIR? Am I correct?

GUANGLIANG PAN: No, actually, what we can do is get a program to check all the aside AS numbers compared with the routing table. And see which one is not there, and then it would see the contact information. If the AS number is in the NIR and then the contact would be the NIR.

RANDY BUSH: I think I can clarify. I believe what Maemura�San is saying is that when you find an AS number which is not in the routing table and hasn't been there for a long time, the data says it's in Japan. First of all, it doesn't mean that that was allocated by JPNIC. It may have been a direct or historical, but secondly, that APNIC should not be saying that it's going to reach inside of JPNIC and recover an AS number that was allocated by JPNIC. That is JPNIC's job if they choose to take it.

AKINORI MAEMURA: OK, that's one interpretation. Thank you, Randy, very clear interpretation. And practically, if JPNIC need to reclaim the resource from the holders, we need to sell up our own policy. That's a very important point. Right? Of course, we can help APNIC to any APNIC account holder for the AS number in Japan. We can have anything for you. But if that is under JPNIC's itemization, we need to set up the policy first to reclaim such an AS number?

GUANGLIANG PAN: I don't think it is really for JPNIC to set up the policy. I think we can JPNIC can follow APNIC policy.

AKINORI MAEMURA: No way, no way. We need to set up our own policy according to the APNIC policy.

RANDY BUSH: JPNIC might choose to! I think the point has been well made. Could we move on, because we're already one minute over our time. I don't mean to stop anybody, but please, Izumi�San?

IZUMI OKUTANI: Just to clarify the point. If APNIC says that JPNIC should do it, maybe we should introduce it in the next OPM, and actually we don't have a problem with this, we just have six ASN under our management. That's not contactable, so I think JPNIC can support this proposal as it is, even if it forces NIRs to implement it?

AKINORI MAEMURA: OK, so we have no problem under it.

IZUMI OKUTANI: What?

AKINORI MAEMURA: So we won't have any problem?

IZUMI OKUTANI: Yes, so we shouldn't have to worry about it and I think this is a good proposal.

RANDY BUSH: Thank you very much. I believe Filiz was next. Filiz Yilmaz �

FILIZ YILMAZ: Just a small clarification. Guangliang said that there is no similar policy in other RIR regions. That is correct, but I would slightly change that. There is no specific policy in the RIPE region for this, otherwise, if it comes to our attention and there's an unused Internet resource, we obviously reclaim it, and it's also the fact that historical is used for different things, and if we have a contract with the resource holder and that, you know, then that we are to reclaim that.

GUANGLIANG PAN: OK, thank you.

FILIZ YILMAZ: It's not as specific, but we do claim. Thank you for the clarification, and I think that makes more sense. Like actually doing similar things.

REN HUNG HWANG: I refresh my concern, we certainly support this proposal, we're just a little bit concerned on when you see the used ASN number and say, if you do it this month and then you notify your RIR and he answers that that this AS number is under use, usage, and then next month, would you do it again or find out that this is not in the global table and notify them again, or just keep a record for that for one year, two years? I think they just want to make sure how they are required to this, how long they need to reply to this?

GUANGLIANG PAN: Actually, in my mind, that would be forever. If you want to keep it, and we don't bother you any more. That would be put in the recall.

RANDY BUSH: Dhaka, any questions? OK, no questions from Dhaka or from the Jabber room. We're running pretty late, sorry. So, do you have the slides ready? Then I'll just say it.

For those people who support the proposal as written, would you please raise your hands.

Opposed raise hands, please.

The proposal has consensus. Thank you very much.

GUANGLIANG PAN: Thank you very much.

APPLAUSE

RANDY BUSH: We've reached the end. Thank you very much. I believe Srinivas has a couple of administrative points, probably.

Yes, one thing is that I should be polite and thank the people in the Jabber room and those people in Dhaka for participating under difficult circumstances. Thank you very much.

SRINIVAS CHENDI: Hello! And thank you Randy and Ching Heng for chairing the Policy SIG and thank you to all of those who participated remotely and onsite. I have a couple of reminders is that the lightning talks start at 6:00 in the same room. It goes from 6:00 to 7:00 pm. And then, those who would like to go for the informal dinner tomorrow, the tickets will be available from the registration desk in the morning tea break. The cost is US $70 per person, and we'll be taking you to... sorry, about my pronunciation, it's inside the Lotus Market in Beijing. Those who would like to join the formal dinner can purchase the tickets from the registration desk.

RANDY BUSH: I have a question. So, the last two socials, they were free au didn't have to get tickets. So they were formal. The informal one costs money? And we have this.

SRINIVAS CHENDI: Because we don't have a sponsor for this one.

RANDY BUSH: I think there is a sponsor for that.

SRINIVAS CHENDI: Usually we don't have a sponsor from that, but it is nice to get the last moment there. Are you OK?

And the most important one tomorrow, if you would like to attend the AMM, you must register to enter into this room so that you can collect your ballot paper for the NIR NC elections tomorrow. So, please when you come to the AMM meeting tomorrow, register yourself at the registration desk so you can collect your ballot paper. Thank you so much for today. See you tomorrow. Goodbye.

APPLAUSE