Address Policy SIG, Wednesday Aug 20, 2:05-6:45 pm TAKASHI ARANO: Welcome to the address policy SIG and thank you for joining. My name is Takashi Arano and I'm chair of the address policy SIG. First of all, some housekeeping things. JPNIC is a sponsor of today's meeting. Please give a big hand for the sponsors. APPLAUSE Social events - the river cruise is on the Han River in Seoul. Please gather in the lobby by seven o'clock sharp. Otherwise, please check the onsite notice board. Today's session - we will have three sessions of more than 10 items like this. We've slightly changed the order of the presentation to the previous web page. The first sessions will end at 3:30 and I hope that this presentation will be the final presentation in the first something. The second session will start with Ray's proposal and will end in Paul's HD radio presentation. And the next day, the next morning actually, Paul starts the - I'm sorry - today's final presentation should be 'Historical resource transfer'. Tomorrow morning, Paul again will start with the HD ratio discussion and finally, it will end in IPv4 lifetime expectancy by Geoff Huston. OK? If there's anything you'd like raised, any topic can be raised any time, maybe after the meeting or something. Please tell me so. Let me start with the first item. The first item is a draft charter. We would like to agree on this draft charter. I will read this. "The charter of the policy SIG is to develop policies and procedures which relate to the management and the use of Internet address resources by APNIC, NIRs and ISPs within the Asia Pacific region." Do we have any questions about that or any opinion or any other proposals to modify this proposal to this draft charter? If not, we would like to go this way. The next item is dealing with open items. There are two items remaining. One is action add-15-001 - "Secretariat to draft a proposal summarising the suggested formal process for receiving and discussing proposals." What is the current status with this action? ANNE LORD: This action is actually closed and completed and the subject of my next presentation. TAKASHI ARANO: OK. The next one is action add-15-002. "Secretariat to refer discussion of signing the DNS root to the DNS Operational SIG." This actual proposal was made previously. ANNE LORD: This is still open. We tried to contact the author of the proposal and I didn't receive a response from him. I guess the action's still open on us to continue this unless there's any other input from the address policy SIG. TAKASHI ARANO: OK, yes. Let's keep open. Question about these open items? ANNE LORD: It might be worth circulating the charter on the mailing list to see if there's any input. TAKASHI ARANO: That's a good idea. Let's move on to agenda three. Anne Lord, ‘Policy process modification’. ANNE LORD: This is a nice cosy room we've got here for this presentation. Good afternoon everybody and welcome back from your lunch. My name is Anne Lord. I'm from the APNIC Secretariat and I'm going to present to you today a proposal for a revised policy development process in the Asia Pacific region. You will note that there's a number underneath my title. As of this meeting, we've actually introduced policy proposal numbers and that should hopefully make it easier for you to track the status of the policy proposals and access all the related documentation. If you click on that on the website, you should get a full set of information relating to the policy proposal. OK, so this proposal is actually based upon feedback received at the last meeting, where we conducted a review of the existing policy process to see whether it was still appropriate for this region because, in the last five years or so, since the inception of the special interest groups, we've actually been evolving the policy-making process. So it was timely, I think, to actually conduct a review and it's also interesting to note that, more or less at the same time, all of the other RIRs are going through the same process, seeing if policy processes can be improved. At that meeting, we received major output on the mailing list and at the meeting from Randy Bush and he proposed a number of points which basically would improve the process and there was at the meeting consensus on the main point of the change that we discussed. So the Secretariat was tasked to write up a revised policy process which myself and Randy did, actually and, one month before the meeting, we circulated the proposal to the mailing list. We actually took some time to nut out the differences and come up with a proposal but it was circulated on the mailing list at that URL below. It's fair to go over the current policy development process for the people that are new to the meeting and not that familiar with the way things work. I'll try and keep it brief. At the heart of the policy-making process is a process whereby we agree policies in a consensual framework so there has to be consensus in the room for policies to go ahead to the next step. We define consensus - this is from the Oxford English Dictionary - as 'general agreement in opinion'. It doesn't mean that everybody 100% has to be in agreement, but just that most of the people have to be in agreement with what's being discussed. We take a show of hands as a judge of general agreement and we often do a count to work out who is in favour and who is against and who is abstaining and doesn't want to vote. And it's important to note that if there's - it's not a numerical majority, so if there's 51 in favour and 50 against, for example, that actually does not represent consensus. In any event, if it's difficult to judge what consensus is, it's probably unlikely to be a consensus. It’s too borderline. And ultimately, the chair of the SIG will have the responsibility for determining if it is consensus or not. So what are the principles of the process? That it's open - by that, we mean that anyone can participate. It's transparent. That means that all the decisions are actually documented and freely available for anyone to review. It's a 'bottom up' process, which means it's the community that's proposing and approving the policy. And it's all consensus-based. The elements of the process are very much the special interest groups. They are the formal groups which discuss broad areas of policy that's relevant to the APNIC Internet community and they're all formed around a resource management principle. There's the member meeting, which is a formal forum that's specific to APNIC business. The member meeting itself is open but there are issues that pertain to the members only like the fee structure. But, importantly, the members or the attendees at the member meeting actually endorse the policy decisions that arise out of the SIGs. So the SIGs make recommendations for the APNIC Secretariat to implement and the member meeting endorses those decisions. Because we're a membership organisation and the membership needs the opportunity to review what's come out of the SIG. So they're two core elements of the process. There are other elements like the working groups and they are semi- formal groups and they actually come out of the SIGs and they are tasked to work on a specific project until that project is completed and then they're disbanded. So we had, I think last year, we had a broad band working group that produced some guidelines for broadband policies. Birds of a feather lastly - that's an informal group where people get to exchange ideas. That might lead to the birth of a new special interest group. I think out of that the IX SIG came out of a BOF. So that's all pulled together through the open policy meeting and through the mailing lists. That all comes alive through these elements. The APNIC Executive Council has a role. In the bylaws, it currently states that the EC acts on behalf of the members in the interval between the member meetings. So, in so doing, they are the guardian of the APNIC membership and they may act on policy matters. For example, any issues that are time-critical, any issues that may be in response to legal judgments and any open policy meeting, the members actually review the EC decisions if the EC make a report to the members. So that's a normal part of the current process. So how does it work today? We have a new policy or an amendment that's proposed. That's posted to the SIG mailing list for discussion. There are face-to-face discussions in the SIGs and the open policy meeting. There's then a test of consensus as to whether something has been agreed. If there's isn't, it will go back to the SIG for further discussion or further amendment to the proposal. If there is, there'll be a report of that consensus item as a recommendation made by the SIG chair to the member meeting. The APNIC members and attendees at the member meeting are then asked to endorse the decisions and the recommendations by the SIG. If they don't, it goes back to the beginning of the process and we continue working and discussing. If it does, then implementation will take place in approximately three months' time. That's sort of the minimum amount of time that it takes for APNIC and the NIRs to get themselves organised. Implementation could be shorter or longer. RANDY BUSH: How long does the process take, minimal from the top? In other words, policies could be endorsed by the MM in three weeks from the start. ANNE LORD: Randy asked how long the whole process would take. Well, that's a good question. I would say, it depends basically when the proposal is posted to the mailing list. If it's not posted until one week before the meeting, you've got the week of the meeting and then you've got three months for implementation. Q. It could be proposed and then passed in a week or two? ANNE LORD: Yes, but it wouldn't be passed for another three months. That's the absolute minimum. This is the main feedback we receive. Some key stakeholders are missing at the face-to- face meeting. I think that's true of any member meeting. But it's a valid comment. We have to find a way to reach these stakeholders. The timing and availability of proposals were not sufficient. It was a case that they were posted to the mailing list just before the meeting or weren't posted to the mailing list and were posted to the website. There was scope for improvement there. All of this is important really when you've got such a culturally diverse region as this region where, for a majority of people, English is not the native language. So the objectives of this revised proposal are really to try and increase the understanding for participants of the various SIGs of the proposals by allowing them more time to actually read and digest what is actually being proposed, both before and after the meeting and, in so doing, to increase participation of the stakeholders in the community. You've got more time. People can look at the website both before and after. They can comment and have time to comment on proposals. And, in so doing, you can promote more discussion on the mailing lists. OK, so these are the proposed changes to the policy development process which basically incorporate all of that feedback. So this part of the diagram is actually very similar up until the point where we get consensus to proceed to the members' meeting. There's only [one] change and that's here. A proposal must now be posted to the SIG mailing list for discussion in text format one month before the meeting. So that gives people time to comment, time to read, time to translate and so forth. And we've actually, for this meeting, we tried to actually implement this part. It seemed a very simple change and actually we had consensus on this previously. So you'll find that all of the proposals that have been discussed today have been posted to the mail list one month beforehand. There was a clause that said, if you are unable to make this deadline, you could still present your proposal but it would be classed as informal and no decisions could flow from your proposal. You have to go another meeting cycle and propose it within the one-month boundary in order to get a decision out of your proposal. Nothing else has changed on the before. It's afterwards where things change. If you get consensus to proceed from the members' meeting, we then have suggested that we have a comment period where the proposal or the amended proposal is actually sent to the mailing list for a period which allows time for comments. Now Randy and I have different versions of how long that period should be. We put in two options. One is for eight weeks, two months on the mailing list. The other is until one month before the next meeting. I've tried to quantify that as 26 weeks but it depends on when we have the second meeting. It's roughly six months. I'll come back to that because I've got more slides on that. After that period has expired, we then look to see whether consensus has been confirmed on the mailing list - has there been any substantial objections to this policy? There can be clarifying questions. People might not understand things. Basically, we're looking to see whether or not consensus has been confirmed. The ultimate call of that, the responsibility, is with the chair to determine whether that is indeed the case and the co-chairs, obviously. So, if there isn't, if there have been objections, substantial objections, then the process will go back to the beginning and the discussion will continue. If it is, it moves to the next step, which is endorsement by the EC as representatives of the membership. So the final sign-off goes with the EC, who actually act in their capacity between the meetings as representatives of the membership to sign off on the proposal. And that would take place at the next regularly scheduled EC tele-conference. They're held every month. OK, so, if they don't endorse it, the discussion will continue. If they do, we then get back to the implementation time frame of three months. Basically, we've got this text proposal sent to the SIG mailing list which should be done one month before the meeting. That gives everybody no excuse - I hope - for not reading the proposals before the meeting and being able to ask questions on the mailing list. There's this comment period after the meeting and after the whole open policy meeting whereby the proposal and the outcome and the decisions that have flown from the open policy meeting are actually posted on to the appropriate mailing list for after the meeting. And there's the final endorsement from the EC that takes place at the very end in their capacity as representatives of the membership. So now, there's some work for you to do. You have to basically look at these two proposals and figure out which one you think is most appropriate for this region in terms of how long you need to actually take in and absorb information on the mailing list that's happened after the meeting. How long do you need for comments during this comment period? So one option says eight weeks - two months. And the other option says, basically, until one month before the next meeting. That's roughly 26 weeks. In total, this is just a breakdown really, of how long it would take from the beginning of the process, to run through to the very end, assuming that it ran through smoothly and there were no iterations of the policy proposals. So, under option A, it would take you 28 weeks to complete the process in total. That includes the four weeks before the meeting, one week of the meeting, eight weeks on the mailing list after the meeting, three weeks until the next EC meeting, the tele- conference, and then 12 weeks for implementation. That comes to 28 weeks. And, under option B, it would take 46 weeks and the only difference being the amount of time on the mailing list after the meeting. So that's the total time from start to finish. So option A is roughly 28 weeks - roughly six months and option B is 46 weeks so, it's longer. So I want you to think about which of these options you think would be most appropriate for this region. I went recently to the South Asia Network Operators Group which was a meeting held in Sri Lanka and made the same presentation there and just gathered a bit of input from people that were at that meeting. They asked some questions and I just thought it's worth probably repeating those questions here just for the sake of clarity. They asked whether or not the mailing list, in terms of after the meeting, can actually override the decisions of the members and what's happened at the open policy meeting. And, indeed, consensus can be overturned. That's the whole point of having the comment period after the meeting. If people have been unable to make the meeting and have different opinions as to what's being discussed, then, yes, they can voice those opinions on the mailing list after the meeting and, if they make substantial objections, then, yes, the consensus can be overturned. Somebody asked how do you judge consensus on a mailing list that's dormant. I said, well, there are well-known ways for dealing with this and, in practice, I think the only practical way forward is to say consensus is maintained unless substantial objections are raised. Consensus is maintained unless something is said. Ultimately, it's the responsibility of the Chair and the Co-chairs to make the call as to whether consensus has been confirmed. They also said four weeks for the comment period on the mailing list after the meeting is enough. That's the end of the presentation. I'll be happy to take any questions that anyone has about the process. We will be asking you later to think about option A or option B being preferable for you. TAKASHI ARANO: First of all, do you understand the proposal? First, I'd like to raise you to raise a question, just to make sure you understand the proposal. OK. Q. My question is, is there anything wrong with the suggestion from SANOG that four weeks rather than eight or whatever the huge number was? ANNE LORD: Just in case anyone didn't hear the question, the question was, was there anything wrong with the four weeks as suggested by SANOG. I think, basically, it could be taken as another option. I'd prefer to think that perhaps eight weeks is no so different to four weeks. If you were after a smaller time frame, perhaps you could consider the eight weeks. Randy, did you want to comment? RANDY BUSH: The goal here is two pieces - that some of the decisions that are being made affect a very wide community, that some of these are engineering decisions that affect not just the addressing policy for LIR s and NIRs in the APNIC region, but affect routing policy throughout the world, engineering that affects everybody on the Internet, etc. The other consideration is that, as Anne said in her presentation, that this is a very non-homogenous region. In other words, there are many languages, many cultures, information moves slowly through the community and, therefore, giving enough time for that to happen and for people to understand the conversations, the decision, the communications, can often be important. I believe there is an escape clause, is there not, in that the EC can act when something is very time- critical and then it can be reviewed by the process later, so this is not to stop any time conditions. TAKASHI ARANO: Thank you, Randy. I believe everyone understands the proposal. Now, I will ask for comments. Any comments or opinions? Actually I think Anne's proposal can be split into three. The text proposal on the mailing list should be done one month before the meeting. How about this part? Do you agree? ANNE LORD: I would also add that this part was agreed at the last meeting also. TAKASHI ARANO: This was the consensus at the last meeting. This is OK? Q. I have a question about this. I am Izumi from JPNIC. If you submit the proposal two weeks before the meeting and it's quite important that you want to pass the proposal for this particular meeting. Would it be possible to extend the discussion period afterwards to whatever the period that's not sufficient from one month. So, for example, if you submit a proposal 20 days before the meeting and then it's a proposal, would it be possible to add 10 extra days to the discussion afterwards to make it into a proposal or, if it doesn't meet the deadline, then it's never going to be possible to be a proposal in the first place. ANNE LORD: I think, Izumi, I think that's not with me but with the community. That would be an amendment to the basic proposal. What we've said before is that there is some leeway in the one month but, if you're talking two weeks before, that would then form an amendment to the basic proposal as it stands. The current situation is that, if you miss the deadline, you have to go through the next meeting cycle but you can gather input and feedback on the mailing list. It's to give people at the meeting [time] to get the feedback before they have the discussion at the face-to-face meeting. If you want us to consider that as an amendment as the proposal, you need to ask the rest of the people in the room. TAKASHI ARANO: The second part is the comment period. Anne proposed two options. Option A is eight weeks. Option B is 26 weeks. And SANOG's proposal is four weeks but it's a bit different from the previous consensus. In the previous consensus it was three months minimum so we're sticking to eight weeks, your proposal. Any opinion about eight weeks or 26 weeks or six weeks or any other? Do we have any opinion or comments? It's very quiet. RANDY BUSH: That's just what we've done with the one month of notice just now. It was proposed before the Taipei meeting. It was discussed at the Taipei meeting. It was discussed on the mailing lists and it was agreed today. It seemed to work. TAKASHI ARANO: Any other? PHILIP SMITH: Again, I just want to agree - sorry, I'm Philip Smith - I want to agree that having a one-month period before it comes to the proposal is a good idea. That's working fine. I must admit a preference for option A over option B. I don't see any advantage of sitting around for 18 weeks of complete silence. We've got a silent mailing list. If there are major issues on the net that people are worried about, they'll get up and scream pretty loudly if APNIC or the membership does something that has a wide impact on the community. IZUMI OKTANI: I get the impression that 26 weeks is quite long as a comment period and I'm wondering what would be the benefit of having such a long period. What I personally feel is, perhaps, have the minimum period of eight weeks or four weeks and then extend the comment period if necessary based on the judgment of the chair. GERMÁN VALDEZ: I work for LACNIC. I want to share with you that, in LACNIC region, we are working right now on the same process. We think it's a very important document because, through this document, the proposals are going to be made. The discussion of this kind of document of how we develop policy in the regions is quite important and it's difficult to discuss. We discussed this in our last meeting in Santiago in Chile. It's similar to the document you have here. Even though we prepared it from our own site and our perspective, we never shared any comments between APNIC and LACNIC. I realise it's a very similar document. The proposal we discussed in Chile was very close to the Chile meeting. We decide that we wanted to have discussions at the next meeting in November. But it seems it can work and we think it can work in our own region and, thinking about this and personal opinions of option A and option B, we prefer option A because there's often more dynamic to the process but taking account also that Latin region is a more homogenous region. That's all, thank you. TAKASHI ARANO: OK. Any other opinion? Q. I just wanted to make a statement that also in the ARIN region, the policy process is also under review. We have had a resource policy by which the process in place for several years now and we've had much time to practise with that and see how it works and, in the last year, we found that, with the current process, there are some improvements that can be made. There was a discussion at the ARIN meeting in April about this and there's been a lot of work done on it since and it's expected at the next ARIN meeting in October that there will be a new process for document writing in place. Some of the things that we have in our current process that are similar to this, that seem to work in our meeting is the 30 days or four weeks prior to the meeting, having the proposal on the mailing list. That seems to work very well. One of the other things about our current process is that the way that it's described and the way that it's laid out is kind of a mix between option A and option B. Either of them can happen. It's possible that, following the meeting, there can be a final call on the mailing list describing the discussion that had taken place on the mailing list leading up to the meeting, the discussion that had taken place at the meeting and stating what the time proposal is and the final call to see if everyone agrees with that. It's possible that there be a fast-track on it following the meeting. However, it's also possible that, either through discussion at the meeting or based on what happens during the final call on the mailing list, that it would necessary to hold a discussion on the mailing list for extended period of time and [make] time on the agenda for the next public policy meeting. So kind of both of those things are happening with our current process. That's it. TAKASHI ARANO: OK, I'd like to propose an amendment to option A. Izumi says that, if needed, we can extend the comment period to eight weeks or something and I think that's natural because, if it's the case that discussion is very hot, the Chair may have a choice to extend the period so it's not contradictory of this option A but I would add that, if necessary, the comment period will be extended. It seems that eight weeks is a preferable than 26 weeks to make sure that there is consensus - I'd like to ask you to raise your hands. OK, option A with amendment of possibility to extend the period or option B. OK, how many people agree option A? Raise your hands. Option A. OK, how many people for option B? OK, that's a consensus. We'll take option A. Something we mentioned earlier on is about the final endorsement from EC. Because it's between the meeting and meeting so the only one organisation who can endorse is EC. But the membership can review the decision in the next meeting. As Anne said, this cannot be overused. Any opinion about this? No? OK. Let me summarise the consensus. First of all, that the text proposal should be submitted to the SIG mailing list one month before the meeting. And, if the meeting and the ML agree to proceed the proposal, the comment period will be raised on the mailing list after the meeting. The comment period is regularly eight weeks but that can be extended if necessary. That is up to the chair. The final endorsement will be done by the EC. Is this OK? OK. Yes. thank you very much. ANNE LORD: Just one thing I would suggest - the APNIC Secretariat takes an amendment to write up the proposal and submit it to the mailing list. GEOFF HUSTON I'm trying to understand the comment you made that it may be extended if necessary. I'm trying to understand precisely why and how given that, if there's a lack of obvious consensus going on, why wouldn't you stop and go back up. There's a flow chart option - why wouldn't you take it back up. I'm kind of wondering that, after eight weeks, if it's not obvious, you go back and discussion continues. I am not sure and can't understand under what circumstances more time in the opinion of the chair of the SIG, would do anything if all you're trying to do is confirm a consensus. RANDY BUSH: Because there may not have been serious dissent but the comment on the mailing list might have been the following communities should be very concerned about it but we've not managed to contact them to get their opinion. As I said, many of the decisions, especially in the address allocation area have impacted on a global scale through operators that are in all regions of the world to the IETF etc. This is not a simple little universe any more. IZUMI OKTANI: I don't have a specific case in mind at the moment. I was thinking that maybe, depending on the nature of the proposal, it needs some careful consideration, but it would be too cumbersome to go back and start the process from scratch. It would be more like an exceptional case where the nature of the proposal needs more discussions or considerations. Sorry, I can't give you a specific example in mind. But that was the intention of my suggestion. TAKASHI ARANO: Let me explain one case. If there is a discussion going on and I guess the discussion can be going to the one place, but there is one more week. If the discussion can be combined into one more week, this will be that I would like to extend the period. However, because of the one proposal, there are so many controversial issues and there is no expectation to agree on the one opinion or consensus that should be in the regular process. Do you understand? GEOFF HUSTON: I suppose in my head there is the issue that I would regard the presentation to the members meeting to actually be a substantive review rather than simply going, "Oh, yeah, sounds OK, go figure." Realistically, I suppose I'm taking the comment that what you're doing in that stage after the meeting, assuming that you've actually managed to get consensus not just to proceed but consensus that it's the right thing. Now you're going back to try and confirm that and I'm assuming that, if that confirmation isn't pretty obvious, then there's a deeper problem that a couple of weeks won't sort through and you might want to go back through the process to make sure that you're actually on the right track and that all SIG parties that had an interest are actually folded in. I'm putting more emphasis at the top of the process rather than at the back and I would see that as being appropriate to say that, if you're not there in eight weeks, you're never going to get there this way. Come back and understand the true breadth comments rather than trying to patch it up in a week. I will say, all up, that we are talking a corner case and that I'm sort of saying, "you've just inserted some words on the fly from the original document and my reaction, I suppose is that it's pretty hard in a meeting to start inserting words on the fly and thinking it's the right thing." In the same spirit as what you're saying on the board is to say, "It would be better to have more time to think about that." The original proposal didn't have it in and maybe we should have thought about it then. TAKASHI ARANO: In the special case. If you put in this comment in the last day of the eight weeks, I would extend just the one more week. This is a typical case, right? You are not disagreeing with the whole thing but, if after eight weeks, it's fix that we must go back to the earlier process, we will explain the one more week, it's not reasonable. GEOFF HUSTON: A lot of care needs to be taken here because, if you allow that consensus process to be open-ended, you might get the issue that things go through the members meeting without being fully baked, hoping that you could rope it all together in this final period because you've got more time if necessary. And it's trying to weigh those two issues about getting policy through in a reasonable time frame against actually trying to make sure that you've actually managed to fold in all SIG interested parties. That's why I'm looking at this open-endedness going, "I'm not entirely comfortable", but I appear to be the only one in the room that's not entirely comfortable, in which case, we've had the discussion and that's fine. TAKASHI ARANO: Any opinion from the other people? The chair must not misuse this. That's OK. Thank you. Can I move on to the next agenda? Thank you. Next agenda should be Gerard. He will explain the APNIC document editorial policy. GERARD ROSS: Hi. My name's Gerard Ross. I'm the document manager at APNIC. This proposal is a relatively simple one, I hope, which is intended to compliment the discussion that we've just had. It's a proposal which will work with policy document process here. It's important for me to explain that what I'm proposing here is only to do with the editorial process that comes after consensus decisions. So, it's not about a way of making new decisions but the way in which the decisions which come through the process we've just agreed upon are then implemented. So, what I'm trying to suggest, is a simpler procedure for writing, amending published documents. And this will take full account of the consensus decisions that have already been reached. Currently, APNIC has a document policy in the document APNIC-083. It sets forth a document for policies and procedures. it's how significant our documents are to be reviewed. And the categorization of those points determines how many calls for comment we have and if that sounds complex it's because it probably is. The reason it is like that is because it was originally put together when this policy development process was a lot less clear than it is and it also fairly obviously doesn't recognise decisions that have already been made as effectively as it should. And it's complex and can take a very long time to go through those ultimate calls for comments. The other point I need to make is that since we've now decided on another more general policy development process, it's no longer necessary to categorize the actual document. In the other RIRs, the process of drafting up the documents is really contained within the policy development processes. And I don't really want to go through the full details of that here, it's not that relevant to us. Why in APNIC would we want to separate that editorial process from development process. We have a large range of languages in this region and to separate the editorial process should help to ensure that, because the draft is being done within the APNIC Secretariat, implementing the decisions the community has already made, and we can help to ensure more consistent documentation, which hopefully will be easier for everybody to understand. So in detail, what we're proposing is a new document to replace the current document. This document would recognise the document that's being discussed. It would not have categories of review, it's no longer relevant. It would have a fairly simple process which would involve after consensus decision has been confirmed, the Secretariat would put together a draft which would reflect the consensus decision. A draft would go out for a single call for public review. That review will not be about the merits of the policy itself; that's already been discussed. It's to ensure what is published properly reflects what has been decided. We proposed that that period should be one month. I should also point out that perhaps this can be discussed we would propose that decisions that are made can be acted upon at the implementation time that has been proposed. We should be able to get the documents through in that three- month implementation period. As I say, I would expect the documents should always be prepared in time for the expiration of the implementation. Within that review period, that one-month review period, the community could request an additional review of the draft to make sure that it truly reflects what has already been decided. In terms of the implementation of this proposal, we would hope if it's accepted, it would be fine to implement this as soon as possible, so that it can be used to implement any other decisions that flow from this policy meeting. That's all from the proposal. We also have some references here that link you to the current review policy. Anybody have any questions? TAKASHI ARANO: Question or comments? This is a proposal. I will ask for a consensus. How many of you agreed with this proposal? Raise your hand. OK. How many of you disagree, raise your hand? OK, that's the consensus. GERARD ROSS: Shall the Secretariat implement this? ARANO: Let's move on. IZUMI OKTANI: Hello, I'm from JPNIC and we're one of the RIRs in this region. Sorry about this. I would like to introduce the current issues in IPv6 policy. This is not a proposal. I simply want to... can everybody hear me? OK. Please note that this is not a secret consensus. I want to introduce some things and have the chance to discuss issues in the community. A brief background just so that to familiarize with people. The current IPv6 policy was implemented in July last year as the common global policy and since then there has been discussions going on in the global community on the IPv6 mailing list. In Japan we had discussions in LIR meetings, JPNIC open policy meetings, just like this but the Japanese version and we've also conducted a questionnaire to LIRs to Japan. We summarised all these comments and firstly we selected a number of issues to the global IPv6 policy editorial team, which is for editing the current policy. This was just intended for them to share information and keep them updated of what the issues are. Out of these issues we've categorized them. Firstly, those issues regarding allocation criteria. Secondly, those regarding resource services in general, except for allocation criteria. Thirdly, about the special cases that can't be accommodated in the standard policy, but need to be recognised. And lastly, just simple wording problems. And out of these four, number one and three are the cases where there has been some specific cases and comments. So, first - explain about issues regarding allocation criteria. There have been two types of comments made with this issue and firstly there are concerns made on the criteria set in the policy themselves. So, for example, the criteria is set - one of the criteria in the initial allocation is set as you have to meet 200 /48 assignments within two years in order to receive an initial allocation. and some people feel that this criteria might not be appropriate. And in other cases, for subsequent allocation, utilisation is calculated using the HD Ratio and people feel this is really an appropriate way to calculate utilisation. The second comments are regarding concerns on the figures that are stated in the criteria. For example, the figures 200 or two years or the value of 0.8 in the subsequent allocation. When you look into the comments, there are no specific comments made related to subsequent allocations. Regarding the issue allocation criteria, and those can be identified into two. First it's psychological barrier. Set by the initial allocation criteria. This has been expressed both in the global community as well as within the Japanese community. The second was a comment made by an LIR in JPNIC Open Policy Meeting, suggesting that perhaps there should be a criteria based on the number of customers instead to supplement the existing 200 /48 assignment criteria. And before I'm moving on to what the issues are, let me just explain what I understand as the intention of the IPv6 policy. According to my understanding, the initial allocation criteria was developed to accommodate allocations for ISPs that are substantial in size. So, you don't want to allow allocations to any networks. So to make sure that the size of the routing table would not be too big. And 200 /48 assignment criteria was believed to reflect this contention, allowing allocations that are substantial in size. And the second point I noted - you might have some arguments against this - but I assume that if an organisation is an LIR and operating networks in the existing IPv4, trying to change from an existing IPv4 networks into IPv6, then those LIRs are most likely to be eligible to receive IPv6 allocations. In reality, some people point out that networks that actually acknowledge that they are qualified for the allocation are much smaller than those who are actually qualified according to the intention of the policy. So if you look at the diagram, the white part is the number of networks that acknowledge that they're qualified, and the red part, which is much larger than the white part, have qualified for allocations. And specific examples were given for the types of networks that refrain from making allocation requests. First, I think it was introduced in Taipei that the mobile phone networks, since they don't make customer assignments, it's very difficult for them to reach 200 /48 assignments criteria, even though they're substantial in size. This idea also applies to cable TV or xDSL networks in Japan. Those providers were showing concerns that even though they're substantial in size, they don't make customer assignments. Most of the assignments they make are for their infrastructure. It's extremely difficult for them to meet this 200 /48 criteria. Another point was that some people interpret the policy too rigidly. Even if they're likely to be able to reach this criteria, they fear that for some unexpected reasons, they might not be. So they think, "OK, we don't meet the criteria," and won't submit the request. What I believe the reasons for this barrier is simply misunderstanding the intention of the policy. So to address this problem, it can largely be addressed by providing supplementary information providing what the information is. I'll explain in more details in my next presentation on how to provide this kind of information. And even after providing this supplementary information, if the problem still exists, then it could be because the criteria itself is not appropriate and you might need to review the criteria. However, before moving on to this conclusion, I think careful consideration and further discussions will be necessary. And it's something that should be tackled. It's a long-term solution to this issue. Another issue regarding the initial allocation was a suggestion from cable TV service provider in Japan, suggesting that there are ISPs that don't make customer assignments which should be evaluated based on the number of customers they have, not based on the number of /48 assignments they make. For example, if an LIR has the equal number of customers as the minimum allocation size, which is 4,096, then they should be eligible to receive allocations. And this only applies to those ISPs that don't make customer assignments, so it doesn’t apply to everybody. This was just a comment made at JPNIC over a policy meeting. To summarise the issues regarding the allocation criteria, there are issues on the psychological barrier created by the issue allocation and also a suggestion that allocation criteria based on the number of customers should be set for ISPs. There are no other issues that are specific enough to be discussed regarding allocation criteria. For other resources, there aren't comments specific enough for us to move in to further discussions. but let me introduce what they are. Regarding the second opinion request was a comment stating that there's not enough information on what kind of documentation is required for the second opinion. For reverse DNS delegations, concerns were shared that there would be too much burden on ISPs to make it compulsory to delegate the reverse DNS zones. Neither of them have specific cases. And the demand is not very urgent. So maybe the documentation for the second opinion request needs to be made clear in the long-term basis but no urgent need at the moment. And third, are special cases that cannot be accommodated in the standard policy but something that maybe should be recognised, and these are portable assignments which are not accommodated in the current IPv6 policy except for critical infrastructures. And another thing expressed in the global mailing list was the requirements for allocations for transit providers. And last week, addresses for close networks. So portable assignments are self-explained. The policy, the current policy does not require assignments. These were expressed in the last JPNIC open policy meeting. Portable assignments weren't necessary. And these come not from the technical needs but business aspects for critical networks such as the online gaming and banking and etc. There was also a suggestion to allow portable addresses for networks with ASNs. This is somehow related to the idea of allowing portable assignments for networks. The second case that requires portable assignments is for a large multi-national enterprises. No specific needs were expressed in Japan but I think there were some discussions on the global IP mailing lists. These enterprises have networks across different regions but operate under a single routing policy. It's difficult for them to receive assignments from LIRs under each regions. It won't enable them to aggregate their routing policy. But at the same time, if they happen to meet 200 /48 assignment criteria, since they're not LIRs, they are not eligible to receive allocations. In considering this policy for portable assignments, I think we need to consider the balance between these needs and the size of the routing table. It's important to accommodate these needs but at the same time we don't want to allow portable assignments to everybody, and make the size of their routing table too big. And the second thing about the portable assignments to large scale enterprises. This could be an issue to review on allocation criteria, not within the portable assignments to allow allocations to organisations that cannot LIRs, as long as they meet other criteria. We probably need to make further discussions about this. For allocations for transit providers, there are no strong needs expressed within Japan but I believe there were a few comments in the global mailing lists for such providers. Since their customers are ISPs, it's difficult for them to meet this 200 /48 assignment criteria but they can't receive assignments from LIRs because they are upstream in terms of routing. And I think we need to have further discussions for this. Addresses for closed networks. There were quite a few comments in Japan regarding this. And there are two types of needs. First is the case where many networks in Japan would like to test their IPv6 before connecting to the global Internet. After the test, they might conclude that they won't need IPv6 network after all, or they'll think we might want to connect to the global IPv6 network. So there was a period when this wasn't fixed. So it's difficult to say if they need the criteria to receive assignments for allocations in such case. So there was an idea that we may need to accommodate addresses for these types of networks. Maybe this is just a simple case of determining the policy more flexibly. The second case is for large-scale intranetworks that are not connected to the global Internet. So each networks are managed by totally different entities but they are inter- connected within the intranetwork. For such case, they need to avoid duplicate addresses. They're requesting for a globally unique address. There is actually a specific need in Japan at the moment. Again I think we still need to make further discussions on this. So to summarise these special cases, specific demands actually exist in Japan to accommodate portable networks and addresses for closed networks. No strong needs were expressed for allocations for transit networks. And I'm interested to know what the situation is like in other countries. And the last - it's quite a minor issue - but wording problems. The current v6 policy doesn't mention address returns. Unless it was intentionally removed from the policy, maybe it would be helpful to describe them in the document. There was also a minor typo in the policy and this has been reported to the editorial team. Since there are quite a few issues that I've introduced, I've categorized them in terms of time frame that these issues can be addressed and the priorities. I still haven't submitted this to APNIC yet, but I will submit this after the meeting so everyone can see this on the website. So a summary of what I've just introduced. The issues that are substantially specific are those relating to issue allocation criteria and also special cases, such as portable assignments and closed networks. These issues still need further discussions on what we should do about these policies. And other issues are not specific enough, even to start further discussions. So I think we can leave them until there are some specific problems. And wording problems can probably be addressed by the editorial team unless there are strong comments within this community to be against this idea. That's it for me and I'm interested to hear what you feel about these current issues I've introduced. Thank you. TAKASHI ARANO: Any questions, comments? Q. In January of this year, a discussion started on an [ARIN] mailing list, a policy mailing list about IPv6 policies and one of the points that was brought up there was the 200 customers, working two years criteria and there seems to be a lot of interest in your region for that to be modified or removed. That did turn into a policy proposal and there was a policy discussion at the meeting in April about this and included the point of the 200 customers, two years as well as a few other items. But the decision at the end of that meeting was for further discussion to take place on the mailing list and it was asked that those members who were interested inside the community on changing the v6 policies and the advisory council, worked together with members of other regional registered communities to work towards another common policy document. And I understand there are some steps moving forward with that now and it's interesting to hear one of the issues coming up, I hear at the APNIC meeting and others that the 200 customers and two years issue. I wanted to make sure that was coming up as well. PAUL WILSON: Regarding the consideration of IPv4 and infrastructure which is addressed in section 4.4 of the document. I'll read what that section says. "Where an existing IPv4 service provider of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request that would be justified if based solely on IPv6." Thinking back to the discussions that created that wording, there was a clear intention in my recollection that IPv6 and IPv4 service providers requiring as it says, address space for eventual transition would be able to receive an allocation corresponding to what was sufficient for the number of customers. And I think perhaps during the drafting process, the wording process, perhaps that original intention was lost and that original intention, what I believe, but I would like to point out that that clause, as least, at one point during the discussion of this policy, was intended precisely to make it very straightforward for existing providers to receive a substantial IPv6 allocation, at least substantial enough to allow them to a fairly easy transition. Not a slow start basic transition but a transition based on their existing establishment instruction. And correspondingly, the 200 customers provision was really a version of slow start and was intended to apply to a provider without that infrastructure. So I think those two facts, which I believe were behind the original policy, really need to be clarified. And if they can be clarified in this way, it would resolve and address many of the issues that have come up in this review of the discussion process. Thank you. Q. In regards to the document, one of the problems with having a very large and long document, claiming it's a policy and it's really a mixture of many things and perhaps to go on with what Paul was saying, what should be done is to take the existing document and create an executive summary of it to clarify those points and lay them out closely as opposed to forcing a subscriber to weed through the document and try and determine what the intentions of the drafts were. Maybe that would be the job that the v6 edit team would take on? IZUMI OKTANI: I think that's a very good idea and I think what you've proposed is kind of related what I'm going to present in my next presentation. And thank you Paul for making the intentions of the policy clear. There was a lot of concerns in Japan about this and we received a lot of questions from LIRs that are medium in size saying, "I know large LIRs can receive allocations but how about us?" And we were not very sure, so we just said, "Just try to make a request and see if you pass." that was the only answer we could give at the time. So the explanation from Paul is very reassuring and it clarified many things for us. TAKASHI ARANO: OK, anything else? OK. Q. I just wanted to comment that in our region that policy was interpreted as the intention from the request of LIR to come up with production services within a certain period of time. So it was the intention that was asked. If you reading the wording, 'did they plan to make 200 /48 within two years' the idea that they don't want to do this for special purposes or whatever but they actually want to come up with a production plan. So the 200 plus customers is not a barrier to entry as such, it's the intention of the planned production services and that number was then taken, just arbitrarily. So I just thought I'd clarify that. And perhaps the facts that should be clarified in that regard as well. It does state that it's a plan. That they have a plan to do it and in two years, whether they do or not, that's a different case. TAKASHI ARANO: OK, thank you for your comments. We already passed the time. So if anything special. Nothing special I'd like to end this session. It is OK? Yeah. Philip wants to make a quick announcement. PHILIP SMITH: This is an update of the worm. Six of you are infected. You are 221.143.6.68., 221.143.6.141.133 and .299 and .120 and .197. TAKASHI ARANO: Thank you very much. [Break 3:45 - 4:04 pm] TAKASHI ARANO: OK, let's restart the session. We are already behind schedule. We'd like to speed up. Our next speaker is Izumi again. She's talking about developing an IPv6 guideline document. IZUMI OKTANI: This presentation is related to the presentation that I have made previously just now. And this presentation suggests developing what's called an IPv6 guideline document which is a document that provides operational information just as a reference if making requests. So it's much more practical than the policy document. And this next slide is just the same as what I've explained in my last presentation, explaining that we've been discussing what the issues are in the IPv6 policy and that we've summariseed the issue, so I won't go too much into details of this. And here, out of the issues that I have explained in my previous presentation, I have categorised them into three types. The first are the issues that are related to the policy and the second are the issues that are related only to operational things. And the third type of issues that I've raised are the issues that are related to both the policy and the operations. You may have some comments against the categories I have put in, but that's not my main point. And what I want to say is that those policies that are categorised are related to the policy, then the policy itself should be reviewed under the formally defined policy process and these include the issues that I have categorised as being related to both. If it's related to the policy, then the policy review should be undertaken. However, for the issues that are categorised as operational, I think I would like to suggest we should develop a document that's separate from the policy called the "Guidelines document" to address these issues. And what are these operational issues? I've introduced them but I've re-categorised them. First, there have been discussions about the interpretation of the initial allocation criteria - how it can interpret 200 /48 criteria. There has been some misunderstanding of the intention and people interpreting the policy too rigidly as a result of this. The second problem is that it does not accommodate special cases that cannot be defined in the standard policy, such as portable assignments or special allocations. Third, there is not sufficient information that helps requesters or highlights the policy and helps them make requests. For example, what kind of documentation would be necessary in making a second-opinion request or requesting for allocations more than /32, things like that. So these are the three issues that are related to operations. If we try to include all these operational policies into the policy document, then it's going to create some confusion. OK - what's defined in the policy, what's the idea of address management? And, together with too many operational details, it's going to be too cumbersome and long to read. You defined the operations in the policy, then it's going to make the operations too rigid. The nature of these issues are different, so I believe that it should be addressed separately. So, even for the issues that are categorised here, for example, psychological barrier in initial allocation, it has some operational aspects to this as well as the need to review the policy itself. These should be addressed separately. I will explain the details later, what the differences are. So, what's the guidelines document that I'm suggesting to develop? This is very similar to APNIC guidelines document in IPv4. It's like a reference or FAQ which happens to be in a document format. But it can include information that can just be on the web. But it's so much easier to see it in a document format, rather than just having it everywhere on the web. That's the basic concept of the guidelines document and it would help requesters in making requests and giving them idea in how they can make requests or give them ideas if they qualify for an allocation. And looking at other RIRs, I believe there are no such documents except in APNIC - well, there is not one in APNIC for IPv6 - but for IPv4, there are no other RIRs that provide what's called a guidelines document. I think RIPE NCC has FAQs for IPv6 but it's not in a guidelines document format. I think Richard wants to make a comment. RICHARD JIMMERSON: ARIN has a full guideline document for IPv6 on our website. If you go to our website, there are two separate sections you can go to. One is policy. If you go to policy, there is something saying, "This is the policy." Just read that. If you go to registration and you go to the v6 area, you'll find a long v6 guidelines document which show people procedures by which they can request space from ARIN as well as some other background information. It is there. It's been there for a couple of years. It might be hard to find. Maybe we'll have to put it in a different location. IZUMI OKTANI: OK. Thanks for this supplementary information. OK, so let me modify that ARIN has a guidelines document already in IPv6. If we develop this guidelines document, other RIRs are also welcome to share the guidelines if they wish, but the basic idea is that it's for this - for the AP region to start with. The short-term effect of developing such a document would be it would largely address the misunderstanding [of] the intention of the policy by, for example, highlighting the important parts of the policy, explaining about, for example, 200 /48 assignments which seemed to be quite a big issue in other regions as well. It will provide examples of networks that are eligible to make allocation requests, things like this. So it's expected to reduce a psychological barrier in initial allocation as a short-term effect. Other anticipated effects would be reduced misunderstanding of the policy, not just restricted to the initial allocations but there may be other parts of the policy that have been misunderstood by the requesters. We can also reduce those problems by providing such a document. Another thing it can do is introduce special cases, providing samples of cases where portable assignments or special allocations can be accommodated. And, thirdly, provide practical information, the type of documentation that would be required for making requests, or highlight important parts of the policy so that it's easier for people to see what are the paths that they have to take and pay attention to. The scope of the guidelines - I want to make it very clear that the guidelines document won't define any criteria set in the policy. It won't change anything that's set in the policy: If any changes in the policy are necessary, then the policy itself should be reviewed, not overwritten in the guidelines. So what you will do is highlight important parts of the policy, supplement intentions of the policy with specific examples and explain the documentation procedure for each request. How can this be updated? The important thing about this procedure would be that, since it provides information on the operations, it should be very practical - it should be very flexible to changes, because operations tend to change more quickly than the policy and it should, at the same time, incorporate comments from the community. So what I have in mind is to allow flexibility in the development or updated procedures, it should not involve a formally defined policy process and also to allow comments from the community, it should be drafted and updated by volunteers from the community. So it would first be developed and drafted by a drafting team which we will - we can ask for volunteers and also outside the community if any other people are interested. Then the APNIC Secretariat will edit the document. It's just very similar for what we did for the IPv4 guidelines document. So what's the difference between the policy and the guidelines document? Well, it's quite obvious from the name - that the policy issues should be addressed by the policy. So the policy will provide concepts and it will define criteria whereas the guidelines simply supplements the policy. It does not change nor define the policy itself. And the guidelines will provide operational details with specific examples but the policy doesn't. And another thing to note is that it's important for the policy to accommodate changes but, at the same time, we need to consider this carefully and take some time for discussions rather than just jumping into conclusion. Whereas, with the guidelines, we need them to be very flexible and, if it takes too much time to fix it, then it will no longer reflect the best current practice. So it needs to be updated more easily than the policy. The example - let me just show you some examples of how this can be different. For the psychological barrier, the guideline - to address this issue, the guidelines will address the issue of what the initial allocation criteria is and state that, if you are already operating networks then you are most likely eligible, things like that, and also provide information on the documentation that's required or provide examples on the kind of networks that qualify for allocation. If the psychological barrier still exists even after this providing this supplementary information, then it may be that the criteria itself is not appropriate for reflecting the original intention of the policy. So we need to review the criteria itself in the long term. This should be addressed as the policy issue, not the guidelines. Another case is how we can accommodate special cases, such as portable assignments or special allocations for transit providers. It should be first defined in the policy if such cases should be accommodated or not. And, if it is defined in the policy that we should accommodate, for example, portable assignments then, in the guidelines document, we should provide examples of cases where portable assignments can be accepted. So, maybe, state that, if you are multihomed, then you are eligible to receive portable assignments. However, guidelines won't provide solutions for all the problems. If, as explained in the case for the psychological barrier, any criteria set in the policy itself is not appropriate, then the guidelines won't solve the problem. We should review the criteria in the policy itself. Another thing is, if there's anything that's not defined in the policy, for example, whether to allow special allocations for transit providers, then we can't state anything in the guidelines, because it's not fixed in the policy. Then, why a guidelines document? It's just, again, summarising what I have been explaining. It's a document that helps requesters with practical information, supplementing the policy from operational aspects, providing examples of special cases. It is - another feature is that it is capable of making very easy updates and flexible and it would also help other RIRs to acknowledge practice in the AP region. If we try to incorporate all this in the policy document, it's going to be too inflexible and too cumbersome to read. Can we stop this? There are quite a few issues as I explained previously. We need to discuss things before jumping to conclusions. We don't need to try to address everything at once. We can start with what we can. For example, explaining the intention of the policy in the initial allocation for providing information for requesters such as the kind of documentation that's required for making requests, things like that. And then, in the long term, it's desirable to address each issue and include them in the guidelines document after we have reached a conclusion. Lastly, let me summarise the features of the guidelines document. It's going to provide practical information for requesters, flexible to changes and, to start with, we can just start with what we can and then add more information as we go on. The document should be developed and updated by a drafting team which consists of volunteers from the community and it will then be edited by the APNIC Secretariat. That's all from me and I'm interested to know if there are any comments for this presentation. Thank you. Q. I'm from RIPE NCC. In our region, we don't have a separate supporting notes general document on the procedures and so on, but each request form itself has a supporting notes document and those can be found in our document store. Just one other point is this issue has come up again with the policy document. One of the ideas that's bouncing around in our region is that, rather than come up with a document that explains a different unclear document, the policy document, perhaps a more efficient solution would be to edit the policy document itself so that it is, in fact, more understandable and clear. TAKASHI ARANO: Any other comments or opinions? ANNE LORD: I just wanted to add that, you know, I think it makes a lot of sense actually to develop a guidelines document because the way that we interpret information in this region can be very different across the region and there are quite a lot of demands for quite a lot of detail. Currently, as Timothy from RIPE NCC said, the policy document actually contains some of that information which perhaps isn't spelled out in a way that is necessarily clear for this region. I would strongly endorse having a guidelines document for this region but it does leave open the implication that we should edit the policy document to strip it back to perhaps the bare bones of what the actual policy statement is. And then, as there are guidelines documents and FAQs in each of the regions and they already have those partly in document form, like ARIN has, you can leave explanations as to what is required regionally for them. IZUMI OKTANI: Thank you for your comments. Let me just add that I'm not saying that the policy shouldn't be reviewed at all and I just want to make it clear that it's also important as probably comments made in the RIPE region to review the wordings or the criteria in the policy itself and, at the same time, I think there will always be people who are not sure or, you know, are interpreting the policy differently or need some specific examples so the guidelines is intended to serve those kinds of needs. I hope I have made my intention clear. TAKASHI ARANO: I remember with IPv4, we developed guidelines for cable and DSL allocation assignments. That was very helpful and successful. Maybe this idea will be one where I believe it will help. Any other opinions? It's not a policy proposal, it's just information but I would suggest APNIC to have room to discuss the drafts and guidelines. What do you think? If OK, APNIC Secretariat announce the call from the front here. Maybe the charter for the working group should draft guidelines, draft a guideline. Any objections? Yeah, OK, I think that's a consensus. You can proceed as such. OK, thank you very much. I'd like to introduce Yong Wan Ju, co- chair of address policy SIG and I'd like to hand over to him to handle the rest of the session. YONG WAN JU: My name is Yong Wan Ju. I'm one of the co-chairs of the address policy SIG. We are behind by 30 minutes or so. In this session, we have four sessions. The first is the IANA IPv4 resource request procedures. And then the IPv6 address space management and then IXP assignments and that will be Bill Woodcock from PCH. The last will be Paul Wilson, who will explain supporting historical resource transfers. First of all, we have the IANA IPv4 resource request procedures. RAY PLZAK: Good afternoon. I'm Ray Plzak from ARIN. What I'm about to present is not - I'll say that one more time, it is not - an ARIN proposal. It's being presented on behalf of all of the NIRs and it's a global policy. Once [all] of the RIRs agree to this policy, it will then be transmitted to the Address Council of the ASO and for them to then transmit it to the ICANN board for their consideration. There does not exist today a policy in regards to how the IANA allocates IPv4 addresses to the RIRs and, because of that lack, there has been a large amount of problems that have existed in the RIRs, particularly to get address space from the IANA so that they can fulfil your needs in a timely manner. I will be discussing what the allocation policy looks like. It has elements and factors; I'll further define the allocation factors. We're introducing some new terms here, one of which is 'necessary space'. There'll be a description of what the policy itself is and then summarised by talking about the notifications and announcements that can be made with regards to an allocation. To start with, allocation policy is composed of elements and factors. The elements are the minimum in terms of the size of the minimum allocation and also in the size of the unit of the minimum allocation. In addition, there are criteria. The criteria are for the initial space allocation and then for the additional space allocation. In regards to this policy, there are also factors. I will define these shortly - that of available space i.e. the space the IRR has at its disposal and necessary space, space that it needs to perform its mission. Necessary space has got a normal aspect to it and also a special need. Looking at factors, looking at available space. Available space is the amount of free space that the IRR still has that it can allocate from, plus any reservations that it may be holding for its subscribers that will expire within the next three months, less the fragmented space. Fragmented space is those available blocks that are less than the minimum allocation size. So, for example, if the minimum allocation size would be for an RIR as a /20 and they have blocks of /22s, that is fragmented space and would not be counted as available space for allocation. Necessary space, on the other hand, is the space that is required based upon its six-month allocation rate times nine for the next nine months of doing business. Now, I mentioned earlier that necessary space could have a special need. How is that determined? If the nine-month allocation projection rate is equal to the previous six- month allocation rate times nine, then there is no special need. If, on the other hand, that is not the case, then you have a special need and, in order to qualify for a special need, an IRR will have to provide justification to the IANA. If you're projecting to allocate in a faster rate than in the last six month, they must provide trend data and analysis. If it is affected by one or more new RIR allocation policies, then the RIR must provide an impact analysis to the IANA. If the basis is based upon external factors, such as new services within the region, a new infrastructure, technology advances or legal issues, then the RIR must provide analysis and reference to source documentation so that the IANA may verify this. So in regards to the IANA to RIR allocation policy, the minimum size is the amount of space required for the RIR to do business for the next 18 months. That's necessary space and the unit of issue is /8. What that means is that, if the 18-month necessary space for an RIR is 1.5 /8s, the RIR will receive two /8s. In regards to new RIR criteria, this is the only time that an initial allocation would be made with an emergent RIR. That RIR will be given one /8 as soon as it is recognised and this will be regardless of any other utilisation that it may have. This is also regardless of the amount of space that was transferred to it from the existing RIRs. An RIR qualifies for additional space if its available space is less than 50% of one /8 block or the available space is less than the necessary space. Once the allocation has been done, there will be a series of notifications and announcements. In terms of notifications, the IANA will provide to the receiving RIR a detailed notification. The IANA will also notify the other RIRs that this allocation has been made. In terms of announcements, IANA will announce only to those lists that is it is concerned with. It will not announce to any regional lists. The RIR s will do that. So, for example, in the ARIN region, or the APNIC region, the IANA would not announce to the SANOG list, APNIC would. In the ARIN region, ARIN would announce to NANOG, not the IANA. So I'll say thank you. I guess it's open for questions. YONG WAN JU: Do you have any questions. RANDY BUSH: Could you flip back to the requests. Thank you. Additional space criteria - if a registry is down to less than 80% of a /8, they get another /8. What if their utilisation rate is a /8 every three years. A. I guess the answer to that question is, if it's stated in the policy is correct. Q. It seems to be correct but I request question it's desirable. A. I would say that, probably, if you go back and look at the special needs criteria, you could apply it here as well. If my allocation rate is going to be less than what it was previously, the I necessarily wouldn’t qualify. Q. It’s not less. That just merely says, five years ago I got a /8. It’s taken me five years to get under 50%. I’ve got another /8 now, even though it's going to take me another four years to use up what I've got. A. That's the way I would interpret that as well. Q. Do you think that's a good idea? A. From the stand point you're taking, it probably isn't. PAUL WILSON: Just a comment on that question. The justification was that the only way the registry would qualify under that criteria and not the other criteria would be if they were very small. And the justification was that a small registry with that small amount of address space would still have a small number of ISP space and, with that little room to move, they would have a lot of fragmentation. Even if it took a lot of time to consume the space, the fragmentation would be greater. I'm answering in terms of what the justification was as I understand it. YONG WAN JU: Do you have any comments or questions. TAKASHI ARANO: Yeah, actually, I agree to this proposal. I don't know why IANA strictly allocates the address to the RIR because RIR will eventually use address. It’s different from the RIR so this kind of criteria should be looser. That's my comment. And possibly the NIR could do it. The NIR will use the address space quicker than the RIR. RANDY BUSH: Ray, could you tell us the difference between this and the current policy. RAY PLZAK: Very simple. There is none. What's happening is, every time an IR goes to the IANA and requests space, it asks a different set of questions, a different set of justifications. Approximately somewhere in the first two years or so of the ICANN life, they developed this algorithm that we only became aware of within the last six months that that's how they were dealing with us and it was a very convoluted thing. The RIRs did not have confidence going to the IANA. I know of several instances where it took literally months to get address space from the IANA and there was no guarantee that, when you got address space from the IANA, the next time you requested space and you provided the same type of justification you did last time, in other words, the same answers to the questions which you were asked before, that you wouldn't get another set of questions. There was no criteria that you could apply to. Does that answer your question? RANDY BUSH: What is the convoluted algorithm? RAY PLZAK: I would have to go and dig it up. It was a very long formula and it was provided when we started this process about finding justification. It was a long formula. YONG WAN JU: I think this proposal is finding the allocation transfer between the IANA and the RIRs. In here, I think we should have acceptance or not about the general concept of this paper. Do you agree what I mean? OK, and then, if you agree, can you please show me your hands about this proposal. And then, reversely, if you don't agree, can you please show me your hands. OK, that's OK. Possibly, we will just be decided to accept this proposal here, OK. Thank you. Let's move on to the next proposal, from APNIC about IPv6 address space management. ANNE LORD: This is actually in some ways a follow-up to what Ray has just presented because it actually describes the relationship between IANA and the RIRs. This is a follow-up to a proposal of a document called RIPE-261. It is actually a proposal for managing IPv6 address space. We've given it a new document number: 005 version one. A little bit about the history of RIPE-261. I'll go on to describe what the follow on is all about. The document itself was released in October last year and was presented at the RIR meetings. And there was a follow-up, this proposal which was posted in July which basically takes the elements for which there was support for RIPE-261. Basically they tried to condense into a follow-up proposal and we called it "Requesting larger IPv6 allocations from IANA". The current system of allocations that the RIRs receive from IANA, we get blocks of /23. The minimum allocation is /32 and we reserve to /29. So in any /23 block there are 64 /29s and there's no contiguous allocation for any one ISP beyond that /29 because we made sequential allocations. So the 32 is allocated and the 29 is reserved. And RIPE-261 observes that in the long-term, under the effects of an IPv4, we observe fragmentation of a result of this rather piece-meal approach. Just a quick snapshot of the current allocations that have been made by the IANA to the RIRs. Some of the /23 blocks are adjacent to each other to the respective RIRs. As I say, each of those blocks are made sequentially. Once a block is filled up, the RIR will then apply to IANA for a new block and a new /23 is issued. The objective is to minimise the fragmentation of IPv6 address space and it's taking a very long time. The method that they proposed to do this was basically through managing, not regional pool of address space, but each of the RIR dipped in to receive allocations for individual ISPs. And we practised something known as sparse allocations, which is a method of maximising the distance between the allocations from the individual LIRs. So the sparse allocation maximises the distance between ISPs, and it's to maximise chance of aggregation of subsequent allocations. They receive a block and then the block is divided into two and ISP will receive an address allocation which is as far away as possible. The third ISP will come along and allow people to receive allocations from as far away from A as long as possible. So this principle is repeated for the remaining address space. It attempts to maximise the aggregation to any single individual item. So when RIPE-261 was presented in the various regions, there was general support for the idea in terms of maximising aggregation, as seen as a good long-term thing. But there wasn't really any consensus on the idea of a common allocation pool. People suggested if this was done, there would be no longer the possibility of allowing filtering on the prefix boundaries of allocation to the RIRs and that was received at the APNIC meeting in Taipei, the last APNIC meeting. There was also support for IANA to actually allocate larger blocks than these /23s and a /12 and /8 has been suggested. So in terms of making a follow-up proposal, basically to include the elements which seem to be generally supported by the community. So, we'd like to propose that the IANA makes allocations to the RIRs in units of /8s and no less and that larger pool basically supports the possibility and potential for greater aggregation. But if these allocations are made to individual RIRs that still preserves the regional integrity. It appeases the concerns people have for not being able to filter them. And the sparse allocations may be practised by the RIRs within the allocated blocks. We certainly want to propose that it happens in this region. If we practice sparse allocations it means that you can discontinue this with a /29. Some may require less and some may require more. So this is closer to the mailing list and the feedback received was actually endorsement from the RIPE policy working group chair. He said he would be in favour of it and bring it up at the RIPE meeting. There were several other comments that were strongly in favour of the mailing list. A couple of comments suggested questions and one suggested that sparse allocations must be used rather than maybe used. So what could the next steps be? If we agree on the basic principles which are these larger allocations, we could develop a companion document to the IPv4 document that Ray has proposed and discuss that in the RIR communities and get feedback on that document. That duplicate would be slightly more cumbersome than I have just written but would describe similar procedures. As Ray mentioned, that document would also require documents. So basically I'm looking for feedback as to whether you agree with these general principles and I'm happy to take any questions or comments. RAY PLZAK: The one comment I have was made to the proposal about the RIRs which had to use sparse allocation. How the RIRs’ allocation should come out of this document and just with the individual RIRs. If you notice I did not put that into any questions or comments? We have two main issues from this presentation. First one is the allocation side from the IANA. Originally this proposal is /8. And another main issue is to sparse allocation. Any questions? RANDY BUSH: It wasn't clear to me whether this proposal was a /8 being allocated to an RIR or to all the RIRs to use in the community. ANNE LORD: It was a proposal for the RIR for a /8. Q. RIRs get /8s but just a bit bigger? Thank you. It's the same as IPv4. Q. How many /8s are there all in all? In the currently defined IPv6 unicast address space. 32 is the answer? RAY PLZAK: Isn't it used for other things? Q. I'm trying to say those are big spaces. I'm talking about 130 second of the current entire plan unicast address space of v6 RIR per allocation. Do you want to allocate this as /8 according to the meeting, just as they suggested the two options with /8? ANNE LORD: /8 or a /12 both would be acceptable. If you want you can ask. The larger the better. In terms of supporting aggregation, it's quite clear what the effects are with IPv4 and the incremental allocations we received today. Concerns over conservation, is that the issue, Randy? YONG WAN JU: OK. Let's think about aggregation. How many persons agree with /8? How many have we decided for /12? will you please show your hand clearly. OK. Let me discuss. OK, we've got the consensus about the enlargement. OK. OK, as I mentioned before, in here, we will just accept the IANA allocation size. From now on, just /23 to the /8 or /12. We need more discussion about the objective size, according to the mailing list or something. OK. After that, the other issue was sparse allocation. Do you have any question about the sparse allocations? According to my understanding, we only discuss about each issue in the entire meeting already as Anne Lord described in here. We will have to check the registry. How many persons agreed to the idea. How many people agree with the practise of sparse allocation? Could they please show me their hand. OK, how many persons disagree with the proposal? OK, we will just accept the sparse allocation. Do you have any other comments or questions? OK, let's move on to another presentation. ANNE LORD: I have one comment about size again. As I understand it, we're wanting it to be shorter than a /23, with no specific agreement over the size. I observed a fair amount of support for a /8 and that should be noted. In any event, this should be globally coordinated. There should be agreement between the other RIRs. There should be further discussion. YONG WAN JU: OK. Let's move on to another presentation. OK, next presentation is the IXP assignment. This is Bill Woodcock from PCH. BILL WOODCOCK: The policy proposal that we're going to discuss is something that Anne, Philip and I have been working on as an update to the existing Internet Exchange allocation policy. This is the policy under which a /24 of address space is available for Internet exchanges in the AP region. This is complex, because this is a bunch of small changes and updates to an existing policy so we'll run through them. First, there is a change to the definition. The old definition started out with, "An Internet Exchange point, IXP, is a physical network infrastructure operated to facilitate the exchange of Internet traffic between independent ISPs" That’s an OK definition. It's not terribly clear and it's not terribly precise. But then the definition goes on to include several other clauses which are not properly parts of a definition. We propose to move those out of the definition and leave the definition simply, "An Internet Exchange point, IX or IXP is a layer 1 and layer 2 network interstitial between and interconnecting three or more Autonomous Systems in contiguous IPv4 and IPv6 subnets for the purpose of exchange of Internet traffic." OK, then we go on to move some of the portions of the previous definition which didn't seem like a definition but rather restrictions into a different clause. In order to be able to apply for address space under this policy, remember that this is one policy and that exchanges will always apply under regular policies, such as ISPs would. So this is just one way of getting space. So, in order to qualify for this policy, IXs would need to offer membership on a non-discriminatory basis in accordance with a published process. That means that, in order to be able to apply under this policy, an IX would need to allow anyone to join and they would need to have a published policy that explained how to join. The next criteria is that they must not provide nor be provided by an operator of any layer 3 transit or transport services. This is saying that, if you are an Internet service provider or a phone company which is operating something that you choose to call an exchange, you're not eligible under this policy just because you call it an exchange. Third criterion - you must be an end-user of address space. This is not a change to a prior policy. This is just moving this criterion from the definition into something that's purely a criterion. This simply means that you cannot take the space that you get and suballocate it for other purposes. OK. Two more criterion - the address space must be used exclusively as the switch-fabric subnet interconnecting the Internet Protocol devices of the IXP participants. That is, if you receive space under this policy, you must use the space for the Internet Exchange, not for other purposes. At the time of application, you must document three or more initial IXP participants with AS numbers. When you apply, you have to submit the AS numbers of your first three participants to show that you're going to be an Internet Exchange. OK. So, now we get to controversial thing number one - in accordance with established best practice, both IPv4 and IPv6 blocks shall be assigned simultaneously and the last two bytes of the network portion of the assigned IPv4 and IPv6 blocks shall be matching values. So this is saying two things. The first thing it's saying is that, when an IX applies for address space, it will get not only IPv4 space but also IPv6 space simultaneously. This removes the requirement for IXs to make two separate applications. Now they make one application, they get both the blocks of space that they'll need simultaneously. The second portion of this is saying that, since the address space is being allocated from a reserve range in both cases, that the two blocks share the last two bytes values so that you can tell that they're paired with each other. This is not really a hard requirement and this is not a technical policy so much as it is a convenience. In the old policy, there was a requirement that the exchange subnet block never be advertised as a BGP. This is a technical imposition policy by the RIR upon the exchange and is probably inappropriate, so we are removing that restriction and leaving it up to the exchange members to make that technical decision themselves. OK. Now we get to controversial thing number two - fees. Part of what we are trying to do here is address the widespread problem of Internet exchanges in small countries that don't have any money trying to get up and running. There is a boot strapping problem in that, in many countries, a huge amount of money is being exported from the country to buy transit to get back into the country. And as long as they're spending that money, they can't improve their infrastructure to solve that problem. So we need a mechanism whereby Internet exchanges can get themselves started very cheaply. So one of the goals of this policy was to try and find a definition of Internet Exchange under which those which really needed to get the address space at no cost or at substantially reduced cost could do so. So my attempt at defining that is as follows - qualifying not-for-profit IXP organisations, whether incorporated or not, which do not charge fees to their IXP participants, shall have their fees waived. This is saying that, if an Internet Exchange is started as not-for-profit and doesn't charge money to its participants, then APNIC will not charge it any money. If at any time an IXP is operated by a for-profit corporation or fees of any sort are charged to the IXP participants, normal fees will apply. That is if, subsequent to applying under this policy, an IXP begins charging fees to its participants or hands over operation to a for-profit or becomes for-profit itself, then it has to pay fees to APNIC exactly like any other APNIC member or non-member would. So please think carefully about this and about whether you're willing to make an exception to the fee structure in order to assist small countries in becoming more self-supporting. Lastly, implementation - we have to have the implementation clause at the end of the policy and so we just said three months after acceptance by the community. So discussion next. YONG WAN JU: Do you have any comments or questions? RANDY BUSH: Is there an expectation that this will become a global policy? BILL WOODCOCK: I believe that - I know that AfriNIC folks are looking at very similar things to this. RANDY BUSH: Global? BILL WOODCOCK: I doubt this will become global policy. RAY PLZAK: It could easily become a global policy like with IPv6. The reason you don't want it to be I’d guess is that you have to get it adopted then. BILL WOODCOCK: There is no pressing need for this that I have observed in the United States and Canada. In Europe, I can see that there would be a need in Eastern Europe but there has been no pressing demand for it. There has been a clear, pressing need for this in Africa and parts of south and south-east Asia. RANDY BUSH: The similar exchange point policy in the RIPE region. I just - the issue of - I agree with most of your sentiments and most of your motivation. The issue of it not applying to a commercial exchange points which are run by people who also sell layer three would restrict a significant number of players in the more developed countries. For instance, in the APNIC region, I am aware of at least one major exchange point that is owned by a layer three transport provider. BILL WOODCOCK: Do you believe they are incapable of paying $2500 a year? RANDY BUSH: No, no, no. That's not what your policy said. Back it up. You said… BILL WOODCOCK: This is for this policy. RANDY BUSH: No, no, that's fees. Back it up. The second point there. That says that one of the large Japanese exchange points does not qualify. BILL WOODCOCK: Exactly. They're already a member or they can afford the member fees. RANDY BUSH: This isn't describing how they get their fees waived. This says this change will mean they could not get such an allocation. BILL WOODCOCK: That's certainly not the intent. RANDY BUSH: I didn't think it was your intent. But this was in your criteria for allocation under this policy. And certainly it would prevent a significant number of exchange points that meet this kind of allocation in Europe and in North America. BILL WOODCOCK: The intention and the understanding of the Secretariat is that these criteria apply to people who wish to have fees waived under this policy. These are not criterion which are applied to anyone applying for address space who happens to be or call themselves an exchange. If you want the space for free… RANDY BUSH: I hear what you're saying. GEOFF HUSTON: In this case, from the EC opinion, as I understand it, as has certainly been the case historically and continues to be the case, you don't need a policy if all you're trying to do is to look at the payment structure unless you're trying to institutionalise something. It's always been the case that an applicant can apply to the EC regarding the fees paid to APNIC. We have been sensitive all the way through the history of APNIC to the relatively high diversity of economic conditions in this region and that, if someone from the region feels that they're disadvantaged and the fees are way too onerous, they've always been able to go to the EC and say, "This is a special case here," and plead their case. In the knowledge of that, do you feel that you need to place a policy here or did you feel you were doing this because there was no other way? BILL WOODCOCK: First of all, there are 350 exchanges in the world right now. I don't think the EC probably wants to be bothered each time a new exchange is formed in the region. Secondly, people read the written policy and they believe it. They do not, especially in this region, people do not read policy with an eye to finding loopholes. They read the policy and take it as a specific course of action that they must follow. If the policy says that they have to pay more money than the net aggregate income of all of their participants for the year to get the address space, they are going to determine, as they have historically, that it is not possible for them to deal with APNIC and that they have to use space from upstream providers and then move it over horizontally which should never happen. This is addressing an existing problem. This is not hypothetical. GEOFF HUSTON: I'm kind of wondering if the problem is in the documentation or in the policy. All I'm saying is that this is not breaking new ground in terms of the ability of APNIC to provide addresses. BILL WOODCOCK: The policy says that everybody has to pay $2500 a year. GEOFF HUSTON: I'm not the EC. I don't understand what you're saying. BILL WOODCOCK: This is a common case. It has to be documented if it's going to be clear to people and going to be used. We can't leave it passive because we have an existing problem. You're saying that there is a mechanism right now. GEOFF HUSTON: I'm asserting there is a mechanism. I was trying to understand whether the problem you're trying to address is the way in which it's been described and published or whether the problem you're trying to address is whether truly there needs to be a policy as distinct from the mechanism. BILL WOODCOCK: I don't think you want the documentation to say that every case is an exceptional case. RANDY BUSH: May I suggest that that's close to an answer to Geoff's question. Make it public and make it clear. Secondarily, I think you need to clean up the language so that it's clear that you're only changing these criteria for when it is free and actually I think you're mixing two sets of criteria in the changes to the document and all you have to do is say, thank you, understand the problem, we'll clarify it. BILL WOODCOCK: Sure. Happy to. YONG WAN JU: We have one additional idea about not deciding to make any policy about IXP and also you like to make the document to the policy. OK. About the two ideas - are there other opinions and comments here from the other persons? TAKASHI ARANO: In one IXP's case, it's WIDE, just a not-for-profit organisation, of course. The membership shares the burden on a parallel port basis. It's not-for-profit but each member pays money for the connection to the switch-fabric. Maybe that kind of case should be removed in your criteria. BILL WOODCOCK: Actually, I would say not, because there are some exchanges which do charge fees for their services and some which don't. The ones which do charge fees to the members include in those fees staff, offices, membership of the organisations like APNIC and they include a mechanism for the passing on of charges from the membership or charges that they receive through to their membership, to their constituency, their users. This policy was aimed principally at accommodating the IXs which do not have that mechanism, which do not have a bank account or a corporation or a way of passing charges through. So, if there's already a mechanism for getting money from IX participants and passing it on to those who pay fees, we feel they should be treated as they would with today's policy. This is a mechanism for helping companies not in countries like Japan but in countries like Bangladesh or Vietnam or places where there isn't a mechanism for moving money from participants. TAKASHI ARANO: Actually, I'd like to talk about just this example. Probably, actually, my feeling is that these kind of things are very case-by-case basis. So it might be very difficult to formulate the criteria in one document. My feeling is that you need something better than the document. That's just my point. YONG WAN JU: Thank you, Arano-San. For this case, we want to get the consensus about which one is better, make the document or just to treat it as a case-by-case basis. Can I get the consensus from the floor regarding that. OK, how many persons - PHILIP SMITH: Which one and what? What are you talking about? YONG WAN JU: I'm talking about trying to get consensus. They suggested one idea about this proposal so I'd like to have a vote about that. How many persons agree with the document, the paper for IXP-related matters, like the proposal of Bill Woodcock? How many persons agree? And then how many persons agree just the idea from Geoff Huston of a case-by-case basis. It's very difficult. TAKASHI ARANO: They need consensus for the rest of the proposal. How about this? I will say, actually withdrawing the part about the fees, and stick to the consensus for this. This means the definition and the eligibility and the assignment details. BILL WOODCOCK: So remembering that the principle purpose of this proposal is to update existing policy, cleaning up the definition and so forth. If we do not include a change to the fee structure, is there consensus on incorporating the rest of the changes. RANDY BUSH: No. What do you mean? BILL WOODCOCK: A change to the definition. Not too much, you're right. Let's see, moving portions out of the old definition into the criterion. If you receive space as an exchange point, you're not allowed to subdivide it, give it away to other people, use it for other purposes. And the IPv6 and IPv4 simultaneous allocation and the restriction on routing. So it's basically only the fee part that would go away out of this proposal. YONG WAN JU: We have some things about this presentation. First of all, is the definition and the characteristics about this presentation and the next one is the review of eligibility and the assignment details and the third one is routing and the fourth one is fees and the last one is the implementation. So, OK, let me check the first one, definition and characteristics. How many persons agree with this definition and characteristics? Could you please show me hands. OK, how many persons disagree with the definition and characteristics. OK, next one is the issue of eligibility and assignment details. About these issues, how many persons agree with this description about the eligibility and assignment details. Show me hands. How many persons disagree with this matter, regarding the PA eligibility and assignment details, show me hands, raise your hands. OK, third one is routing methods. How many persons agree with this description about the routing? Same question, how many persons disagree? OK, also acceptable. OK, last one is the fee method. OK, as I mentioned before, the fee matter is the two ideas, just the case-by-case, and the documentation. Which one is better. Need to gain consensus about which is better, OK? First one is the document, about the pay matters. Which ones agree documenting in paper about the fees? How many persons? Show me hands. OK. Let me just summarise the consensus thing. According to the consensus, we accept the definition and characteristics and PA eligibility and assignment details. We like this proposal. But just the fee manner is what we will withdraw. OK. That's OK? OK. BILL WOODCOCK: There is a suggestion that we discuss the fees further and see if consensus can be developed on some compromise in the future. YONG WAN JU: After this meeting we will discuss about the fee matters in detail. OK. Let's move on to... TAKASHI ARANO: Let's have the discussion on the mailing list. Is this OK, about Bill's proposal? OK. YONG WAN JU: Let's move on to the final presentation of this session. This is from Paul Wilson. PAUL WILSON: Good afternoon and I'm very happy to be bringing you the final presentation of the day and I suppose you might be very happy to be hearing the final presentation of the day! It's been quite a long day and I very much appreciate the fact that we've had such good participation during some quite lengthy and complex presentations. This presentation is not so lengthy and it's hopefully not so complex either but what I'm addressing is the question of historical resources which are being managed by APNIC and the proposal is one which will support the transfer of those resources from one party to another in very specific situations. Now I'll just start with some definitions. I'm going to be talking about historical resources during this presentation. What I mean by historical resource is address space which has been registered under early registry policies and/or without formal agreements. These might include what we all ERX - or early registration transfer resources. These are the address blocks mostly that were assigned by registries prior to the RIR system so by the IANA, DDN-NIC, InterNIC, etc. These resources are being classed as historical. They are currently, as you probably know, the subject of the ERX process, which is transferring resources from the ARIN registry where they've been held into the respective regions, where the resource holders are located. So APNIC is receiving ERX historical resources from ARIN at the moment and that process will continue for some time. Other resources were allocated prior to 1996 before formal structures and agreements and policies to go with them. We also have some historical resources which were inherited from the ex-Australian national registry, AUNIC. All of these are historical resources and the thing about all of them is that none of them are governed by specific agreements or clear policies and that is one of the issues that we're trying to address with this presentation. There are, on the other hand, current resources. The current resources are registered and allocated under formal agreements and subject to the current policies which are in operation today. Any recent APNIC allocations and assignments, that is through the normal process of allocation and assignment to APNIC members and so forth, these are known as current resources. This proposal is attempting to address some particular problems with historical resources. The first of those problems is that, with early registrations and historical resources, we have inaccurate registration data. There's no relationship between the holder of the resource and the regional Internet registry. So there is, in general, low incentive to maintain accurate data and we find that many historical resources have out-of-date data. E-mail addresses don't function, contact addresses don't function. APNIC receives a huge number of complaints about security breaches that relate to historical resources we hold where the resource-holder can't be contacted. Historical resources have had, historically, a lack of protection mechanisms. They have been at risk of 'hijacking', as we call it, where the resources may be resources which are not being used and may be hijacked by another party simply by forging a protection or they were not protected in the first place again, the contact data is out-of-date or deliberately missing and, again, APNIC suffers a number of complaints and so forth about that. APNIC members incur unfair costs for carrying and maintaining registrations. This creates also a liability or risk for APNIC; there are certain interpretations where the data that we carry in relation to certain resources may be trusted and where resources are used for illegal or damaging purposes, [and] there is conceivably a risk of liability for the registry. These problems exist in some respect due to the ongoing early registration transfer project. Because that project is ongoing, that is the reason why the presentation is being made today. So the proposal is to allow voluntary transfers of historical resources from the historical resource holder to APNIC members and I stress the word 'voluntary'. The idea is to allow historical resources, in a sense, to become current. resources, [and] by becoming current, they would become subject to appropriate current policies as well and, by being subject to current policies, they would - we would be able to more directly address issues of accuracy, of registration, lack of utilisation of resources, allocation of additional resources to resource-holders who have historical resources to their name and, perhaps, that should not be receiving additional resources without justification. There are some conditions which would be placed and would not be placed on this type of transfer. Specifically, we're suggesting that there should be a technical review or approval for this kind of transfer. There'd be no review of agreements between the transferring parties. That might sound like an exception to current RIR practices and, in a sense, it is. But what we have a, let's say, a balance here between the desirability of bringing historical resources into current status and what some people might see as an exception to policies in that we're registering resources without subjecting to the normal reviews that would apply to new resource allocations. But, in terms of positive conditions on such transfers, we would need to, of course, verify the holder of the historical resource. That's something we've had quite a bit of experience with in recent years through the ERX process and some of the other historical registration processes that I've mentioned. The transferor would be a member of an NIC, the resources would be coming in under a current membership agreement. There would be no fee for the transfer. Some of you who have been familiar with APNIC policies over the years might see a parallel between this policy and what we call the 'no questions asked' policy which allows the holder of historical resources which are unaggregated to return them and have a replacement given to them. That is a process in which there are no technical criteria, no technical review and no fee imposed. I'll just mention - this is one specific measure which is designed to reduce the historical address space problems that I mentioned. It won't solve all the problems and it's not intended to. Specifically, it is a voluntary process. There is no proposal that historical resources should be taken and transferred. It is purely on agreement of the historical resource holder and the proposed recipient of resources. So the transfer process involves, well, the transfer request, which would be represented on what we might call a historical resource transfer form, which would have to be developed. And this would be submitted by the holder of the historical resource. The APNIC Secretariat has to go through a validation process relating to the historical registration. With these processes, there can be quite a complex trail of transactions involved, where a company may have been transferred to another company. There may have been, in many cases, mergers and acquisitions which haven't been reported. In validating the holder of a historical resource, there are documentation requirements and then statutory declaration requirements which have already been developed and may be brought into place in these situations. This is all designed, as I say, to validate historical resources, validate registrations and overcome the problems that we've had. The other part of the transfer process is, of course, to validate the recipient for consent to receive a transfer. That recipient should be an APNIC member before the transfer is approved. If the organisation was becoming an APNIC member in order to receive a transfer, then the resource application fee which is imposed to enter into the hostmaster request process would not be imposed at the beginning of that membership in order to receive the transfer. That application fee is intended to cover the hostmaster efforts required to understand the initial case, the development plans, etc, of the ISP in order to make the allocations in the conventional way. And timely the resource transfer would be registered through database registration, update systems through APNIC, etc. It's worth remembering that the transferred resources would then become part of the pool of resources held by a particular member, subject to current policies. They would be counted as part of the address space of the member when it came to membership renewal. So implementation - I've really been through it already - updating internal Secretariat systems, documentation and the actual transfer. And that's the end of the presentation. I hope the intent of the proposal is clear. It is intended it address to the problem with historical resources which are currently a cost and a threat in a sense to some of the goals of APNIC as a registry, to bring those resources voluntarily on request into current policies and usage and so forth. So I'd be happy to take any questions. Thank you. YONG WAN JU: Any questions. Randy? RANDY BUSH: Today, without this policy, I have a /16 and I am selling my company. This data will need to be changed. Do you do that? Today, I have a /16. I'm selling my company to another company. Along with it goes the Internet /16. The Whois data needs to be changed. Do you change that today? PAUL WILSON: In the case of historical resources that has happened without the update of the information. RANDY BUSH: If I ask you to change it, will you change it? PAUL WILSON: Yes. RANDY BUSH: OK. With this new policy, are you going to demand or ask that the recipient be or become a member of APNIC? PAUL WILSON: They would need to become a member of APNIC in order to have the transfer registered within the APNIC database. RANDY BUSH: That's essentially the change - you're demanding that they become a member to receive the transfer. IZUMI OKTANI: I have some questions regarding the answer to Randy's question. We've mentioned that if company A has been transferred to company B, then this company B will need to be an LIR under APNIC's policy. Is this correct? PAUL WILSON: In many cases, where historical resources are being properly maintained, where they're being actively used, the records will be up to date and a transfer of this type might happen without the knowledge of APNIC at all. That will continue to happen. But we have many other cases where historical resources are, for instance, in disuse and the statistics which have been published by Philip Smith and Geoff Huston show that, out of all the Internet address space held, approximately 50% is not used at all. We have resources which are perhaps not used, where the holder of a class B block may need a /22 for instance from that address space and they may wish to or they may be prepared to put that address space - the unutilised blocks that they hold back - into circulation so that someone will have to take over responsibility for the address space. It's purely voluntary, as I say, and it's something that is not designed to address the entire problem of address space but it's hoped it would improve the situation without requiring the acquisition of compulsory policies or charges etc., which, because of the nature of historical addresses, since they're not subject to agreements, it would be quite difficult for any of the RIRs to try to propose new policies and specific policies on those historical resources, so, by offering a voluntary mechanism, the resources will be transferred under current policy systems. We hope to improve the situation somewhat. IZUMI OKTANI: I understand the idea and I am for the idea as well. What I wanted to confirm was the transfer of the IP address and the transfer of a company are different issues and I wanted to know, if a company has been a company with a historical address that's been transfered, in that case would that company need to be an LIR to make this transfer of the company happen to receive it, instead of transferring an IP address to another organisation? So the idea is the network itself is the same and just the company name would change. In that case, would this company need to be an LIR? PAUL WILSON: In order to maintain historical allocations? It happens all the time. The proposal is not to suddenly impose a requirement on all transfers, on all such transfers that they become LIRs because, as I've said, that would be to impose, top-down, a requirement which we have no agreement that allows us to impose. RANDY BUSH: But that's the opposite of what you just told me. I asked the same question - the company is sold from A to B and today, when B says, "Please change the Whois data," you do so. I asked that the essential change of the policy is to mandate that the recipient be a member and you said yes. PAUL WILSON: No, I misunderstood your question, sorry. RANDY BUSH: So, Izumi-San, your understanding is mine. If I have a company that has a network and I sell that company to Izumi-san, she does not have to be a member. PAUL WILSON: If you have control of your historical resources, while the people are maintaining resources and updating records and they're doing it without the registry, that's fine. RANDY BUSH: Of course it's with the knowledge of the registry because you have the Whois. BILL WOODCOCK: How can they update records in your database without your knowledge? PAUL WILSON: If the maintainer is up to date, it can be maintained by the holder. With current resources, the maintainer is APNIC. BILL WOODCOCK: You're saying if the maintainer is out of date, in order to update the maintainer, they have to become an LIR. RANDY BUSH: Let's not go into the detail. Is your intent that a historic holder whose data is approximately correct, however it was maintained, is selling to another party the whole thing, that you're going to still update the data and you're going to politely ask them to, to use your word, voluntarily, the recipient should become a member of APNIC or will you demand it? PAUL WILSON: The former. RANDY BUSH: Thank you. YONG WAN JU: Any other comments or questions? IZUMI OKTANI: This is just a confirmation. Let me say that I am for the idea. I want to confirm if my understanding is correct. Once it's been transferred to an LIR, this LIR can reassign to end-user’s network or reassign to its own network just like regular allocations that it received from APNIC. Is this correct? PAUL WILSON: That's correct, yes. IZUMI OKTANI: One more, I'm sorry. I'm interested to know the implications for NIRs. I'm not sure if it's appropriate to discuss it here or in an NIR SIG. PAUL WILSON: I would suggest that every policy, every general address management policy is discussed in this forum as an APNIC policy will apply the appropriate way to regional management through NIRs. That's one of the principles I guess we've arrived at through the NIR process is that the APNIC policies and NIR policies should be the same. And so, in translating this from an APNIC policy, let's say, into an NIR situation, then I would suggest that it is a case of a member of an NIR that is an ISP that may be an executive member for instance, receiving a transfer, having that transfer registered as current address space in accordance with JPNIC's situation. That address space then becoming part of JPNIC's direct pool for the purposes of future management. IZUMI OKTANI: In this there are two cases. The first is an NIR itself will receive such a transfer, so JPNIC will receive such historical transfers from an end user network. I don't know if this will apply to NIRs. The second case is, I think that's what you have explained, LIRs that are under JPNIC's management will receive such resources from an end user's network and, if this policy passes, the latter will be implemented and not the former. Is this correct? PAUL WILSON: Yes, the current practices which are different from former practices involve allocation of address space from an APNIC address pool to a member on the approval of the NIR itself. This is a transitional situation that we're transitioning, as you know, to a direct allocation model rather than the NIR allocation of the old model. What I've described is an interpretation of this policy, this proposed policy according to the new direct application model. You might want to make a counterproposal to that, but I'll leave that to you. IZUMI OKTANI: I think it's OK but would this be compulsory to implement? This would be compulsory to implement within Japan as well? Or do we have a choice to discuss it in our JPNIC open policy meeting and seek for consensus there and decide to implement within Japan? PAUL WILSON: I think that it’s important that you have that opportunity, that this policy, if approved at the APNIC level, doesn't represent a problem for JPNIC in terms of timing - or any other NIR for that matter - in terms of timing of your own consideration of the policy. IZUMI OKTANI: OK, thank you, and sorry to others for taking so much time about NIRs. BILL WOODCOCK: Can I quickly ask for a little bit more clarification. I want to pose a case and see how the new policy applies to it. Let's say that I'm a university and I have an allocation which predates the existence of APNIC and, through no fault of my own, the maintainer has nothing to do with the real person who's actually responsible for this because, maybe they died long ago. Now I need to move a nameserver and I need to change the IP address on one of my nameservers. I've never asked APNIC for anything before, never asked for services, never asked to become a member. How does this policy affect me? PAUL WILSON: It does not affect you. You’re currently receiving service for free from APNIC in terms of your maintainers and your addresses. If you require help with regard to the maintainers because they have moved on or passed on, then you come to APNIC and that is updated. BILL WOODCOCK: OK, and what is the effect of the policy? PAUL WILSON: If you are a university, for instance, that is an APNIC member and receiving APNIC services including coming along to meetings, voting, using MyAPNIC, etc., then you are in a position to receive transfer from an historical address space holder in a facilitated and easy manner. RANDY BUSH: I think I can help. It means that, if I'm an ISP that's on APNIC or JPNIC or whatever member, and I purchase another ISP that has address space, they will not look at the justification for that address space on the transfer. They will not question if I publicly purchase that address space from you via the social agreement we have. They are saying they will be blind to it and accept the transfer if I am an APNIC member. That's all. Am I correct, Paul? PAUL WILSON: Yeah. TAKASHI ARANO: I agree with the goal of maintaining the information in an updated way. My proposal is that, if some program will solve that, that's the next step. That's my proposal. YONG WAN JU: JPNIC also have a lot of historical address space and also other NIRs such as in China and Taiwan, also in Korea. There's a lot of historical space. We needed to discuss within Korea. Let me check how many persons agree with the general goal of this presentation? Could you please show me the hands. OK. How many persons disagree with the general goal of this proposal? OK, this is accepted here. After this meeting, we will discuss this through e-mail and any other methods. OK, and then, finally, could you please give a big hand to all the presenters together. APPLAUSE OK, I'm just going to announce some important things. As you already know, the river cruise on the Han River in Seoul - a public bus will be prepared in front of the lobby at seven o'clock. So that's the only notice that, after this meeting, we have some meetings. No, both meetings are cancelled. Thank you. PHILIP SMITH: Before you run away, there's still one worm running around the network. Your address is .197. You've had no Internet access for three hours. If you want it back before you go home, I suggest you get your laptop back up. That's 221.143.6.197. 1