https://conference.apnic.net/40/program#sessions/policysig3 ************ >>Sylvia Sumarlin: Good afternoon. This is just a reminder. It is almost 2 o'clock already. There are only two more minutes to go. Please cast your vote at the voting desk outside. If anyone has not cast their vote, please do so, as you have only another two minutes. Thank you. >>Adam Gosling: Before we get started, a couple of housekeeping things. We have a couple of reminders that the Internet operations research grants are now open. There should be a reminder on your desk. Also a reminder to cast your vote for the ISIF Asia Community Choice Award. If you could do that, that would really help the ISIF program. We have a couple of minutes before we ask the Election Chair to come and close the ballot. Masato is here, but we have to close the ballot for the NRO NC. >>Sylvia Sumarlin: Another announcement: it is now 2 o'clock. No more votes in. The election officers and tellers will move the ballot box to a private room and commence counting. The entire process is supervised by the election scrutineers and the results will be announced here at around 3 o'clock. Thank you. >>Masato Yamanishi: It's 2.00 pm so I'd like to resume the 1 Policy SIG Session. The next item is an informal presentation from Guangliang, talking about Whois update. Actually, it is community consultation, because you want to make sure of a couple of points. Right? >>Guangliang Pan: Good afternoon, everyone. My name is Guangliang Pan, registration services manager at APNIC. Today I would like to give you a Whois update. Before I go through the presentation, I want to give a bit of background information why I'm presenting this. In the past, we used to have a SIG called Whois Database SIG, Whois SIG, chaired by Xing Li from CERNET, China, and actually used to discuss the Whois policy issues and all the technical stuff. For some reason, later on we decided not to continue the Whois SIG and we moved to a single only Policy SIG. Then some of the people suggest maybe APNIC Secretariat can give a bit of update on some interesting things in Whois, what's going on there. That's why I'm presenting an update here and trying to give you some information about Whois. Also we want to hear your opinion as well. In today's update, I will talk about three items. First is about the differences between APNIC and RIPE Whois databases. Then I will talk about change mnt-by from member's maintainer to APNIC-HM for AS number object. Last, I will talk about creating route objects 2 for those foreign AS numbers, which means if your AS number is not under APNIC management and if you want to create a route object in APNIC Whois database and what we are going to do with that. First, I would like to talk about the difference between APNIC and RIPE Whois databases. APNIC shares RIPE NCC's Whois database code. Actually, we borrowed it. We took the code from RIPE NCC. They designed the code and then we just used their Whois code. APNIC also modified the code to meet our own policy requirements, like if we have a new policy or we have something we need which is only in the APNIC region, we needed to modify the Whois. For example, the latest case, we have a policy to ask for the IRT object encoded in inetnum, inet6num and aut-num. By the policy, it is mandatory. However, in RIPE NCC they are actually optional. So we need to modify the APNIC Whois to meet this policy requirement. You can look at the Whois template. In APNIC Whois, inetnum object when IRT is mandatory. So you have to have the IRT reference before you can create an inetnum object or update an inetnum object. But in RIPE NCC, they actually make it as optional. So either you have or not. With IRT object, you can 3 still update your inetnum objects. Instead of actually they introduce an abuse-c, like abuse content into the database, under their organization object. This graph shows you how abuse-c is introduced into the database and how it works. They have inetnum object and linked with an object, is an organization object and the organization object, they have abuse-c content, and then they connect it to a role object and the role object with an abuse mailbox. So it uses a little bit different way, compared to APNIC Whois. This is something like -- it's because the policy is different, so our Whois will be a bit different to RIPE NCC Whois. Also, we are planning to upgrade APNIC Whois as well. Technically, APNIC Whois is in 1.69 version and RIPE NCC Whois is on 1.81. It's a bit ahead of APNIC Whois in technical terms. So we are also planning to do an upgrade to make it a bit, like, consistent in the technical points, like coding and the language of coding. During that also we will consider some new features which are in the new version of the Whois. I won't give all the details on those features because it is quite a lot and also very detailed. We are planning to send it into the mailing list with the details and then ask 4 the community to think about it and you can tell us, "Okay, that's good, that's bad", and you can actually give opinions. It's not that urgent. You can actually take your time to wait and maybe come back to us in the next meeting or during the mailing list. We are planning to send those features to the mailing list. I just quickly scan them and give you a bit of information, what kind of new features for consideration. They have something quite interesting. It's called like a dry-run update. What that means is we want to do some update in testing and we normally use a test Whois. But if a test Whois, you don't have all the objects related, you need to build objects into the test Whois. It's a bit different to the real Whois. The dry-run is you can actually test the production Whois. Actually running, it looks like you are running and update the production Whois and the software will be strong, the same as the production Whois. But, in fact, you don't update it. That is a very good, interesting feature. Also they have some pending route, like how to create a route object. Because you need to have a password for main route, for both your IP address and AS number, to be able to create a route object. In this 5 feature, they will send those requests to the AS number and the IP address block for maintenance. It is also interesting. They have some new query flags to filter out the syntax, like valid syntax or non-valid syntax. They also have some new attributes. For example, we used to change the field. Like to mark the day, you update the Whois. Now they introduce two new fields called "created", which is the day you actually create the object and "last-modified", which is generated by the system to record exactly what is the last modified date. They also have some new role syntax. A role normally in the past you can consider like a person, and because a role actually is an organization, so they change a bit to allow more tests into the role object. They also allow to change the name of a person or role object. In the past, if you create your personal object, you want to modify your name, it's impossible; you need to delete it and then create a new one. But now it allows you to modify the name of the person and the role object. This is some interesting features we can consider and we will send that to the mailing list with details, but we are not going to discuss it here today because it's the Policy SIG and the time is also limited. 6 I'll move on to the second item I want to talk about, which is about change the aut-num maintainer. Currently the aut-num is an AS number object, it's mnt-by our member's maintainer, which actually allows people to easily modify the routing policy. In the past, the update Whois is not that easy. You can have like an email sent to auto-dbm, such things. To allow people to update the aut-num easily, we put member's maintainer into the aut-num. So if you change your upstream and you want to change your routing policy, you can actually update your aut-num object easily. From time to time, we very often found members accidentally deleted their aut-num object. After you delete it, you can't put it back into Whois. Then they will straight away call the Hostmaster, "Hey, sorry, I deleted my aut-num. Can you help me to put it back?" Last week, I got one case, before I fly to Jakarta. That is some case like, it's a bit funny, people accidentally delete it and they couldn't put it back and then it caused them dramas. To avoid that situation, we suggest to change the mnt-by member's maintainer to APNIC-HM. In that case, only APNIC Hostmaster can delete the object, members couldn't delete it. However, they can very easily 7 update the object via MyAPNIC. We have improved a lot for the tools, how to update Whois, especially in MyAPNIC. You can just log in and get all your objects related to the member, so you can easily get an update. We improve the function for you to update the objects in MyAPNIC. You can easily make a change, but you couldn't delete the object. The last item I want to talk about is creating route objects for foreign AS numbers. Based on the Whois role, APNIC members can only create a route object when their inetnum and AS number, aut-num, are both in APNIC Whois. Also, the main route setting into those objects, then you can use that main route to create a route object. That is the Whois role. However, in some of the cases, your IP address may be routed by someone else and their ASN is not in the APNIC Whois. In such case, you can actually contact APNIC help desk and we will evaluate your request case by case. If okay, we will create that object for you, because we need to contact that AS number and verify this is true. But we don't want to create something dummy and not true into our database. For IP address ranges not under APNIC management, we don't create a route object. We actually suggest you 8 contact the relevant RIR to get your route object created. That means where you get your IP address and then you go to that RIR to create your route object. If that IP address is from ARIN, then you go to ARIN. If it's from RIPE NCC, you go to RIPE NCC to create your route object and not in APNIC Whois. Okay. I think I finished my update. Are there any questions? >>Gaurab Raj Upadhaya (Limelight Networks): Actually, the previous slide, the last point, this is a real problem for us who operate networks in all RIR regions and use a single AS number. I would suggest that if you set up a process whereby you validate the AS number belongs to an account, maybe in another RIR region, only one time. For example, we have the same AS number that we use globally for everything. If you validate that AS number one time, then I don't have to send you a request every time I need to do an operational change, add an aut-num or add something into Whois for addresses that are assigned by APNIC. >>Guangliang Pan: That is a very good point. >>Gaurab Raj Upadhaya (Limelight Networks): Otherwise, I might need to urgently announce something, then there will be no time to go to the help desk or anything like 9 that. In the end, we end up using RADB because we can change things as we want. That is one reason why we don't use the APNIC Whois as much as we would like to, because the process is not easy. So please take that as feedback. I'm happy to validate it one time, then after that, let us add those routes under that AS number as much as you like. >>Guangliang Pan: Maybe you can see this is one of the new features, the second one, pending route authorizations. That probably update the Whois, maybe we solve that problem. When they create a route object, they will send you an email asking you to verify and then you confirm. Probably that function will actually work. >>Gaurab Raj Upadhaya (Limelight Networks): Yes, but if it goes to the help desk queue and it takes a while, that does not solve the problem. >>Guangliang Pan: That will be automatic. That is the function we are planning to consider. When we send it to the mailing list, maybe you can comment that you really support or need the function, then we can implement it. That is the point we are trying to consult the community. Thanks, Gaurab. >>Elvis Velea (v4Escrow): There was a long discussion about routes and RADB and everything and I'm not going to go 10 back to that, but the pending route authorization only works if both the inetnum and the aut-num objects are in the APNIC database; right? >>Guangliang Pan: Okay. >>Elvis Velea (v4Escrow): I think that is how it is right now in the RIPE database. It only allows a route authorization. You can initiate the creation of the route object and an email will be sent to the second party, but only if the two parties are in the same database. >>Guangliang Pan: Yes. >>Elvis Velea (v4Escrow): I would say, because you guys are planning to use the latest version of the RIPE database and the RIPE -- so it's basically the same database software. I would actually give you -- again, just as feedback, it would be a very good idea if this could be expanded, both in the RIPE region and AFRINIC -- they are using the same database as well -- and APNIC, to basically, when you want to create a route object and you are the holder of either the IP addresses or the AS number, you initiate the creation in the database and the databases could talk to each other and notify the holder of the corresponding object maybe in the other region, with an email to confirm the authorization. So it doesn't have to go through the Hostmaster. 11 >>Guangliang Pan: Yes, exactly. That is a very good idea. I'm thinking we need some software to automate the system. >>Elvis Velea (v4Escrow): Yes. If someone wants to create a route object with an AS number from APNIC and IP addresses from RIPE, it would very simply go to the database, initiate the creation of the object, the object has a holding time of one week, I think. The databases talk to each other and the APNIC database tells the RIPE database, "Hey, who is the holder of this IP? Who is the notifier of this IP range?" The RIPE database gives back the email address that should be notified and that email address gets notified and that's it. >>Guangliang Pan: Yes, exactly. I think that's a very good idea. >>Elvis Velea (v4Escrow): Then both parties, the holder of the AS number and the holder of the inetnum object, have accepted the creation of that route object. >>Guangliang Pan: Okay. Thank you for your comment. >>Masato Yamanishi: I have one question on the second-last slide, about the aut-num maintainer. I think that some members update this object by script or tool. In such case, doesn't it cause some problems if you will change so it can be updated only 12 through MyAPNIC? >>Guangliang Pan: Yes. If they want to use the email update, yes, it may be you can't update it because that mnt-by APNIC-HM and they can only use MyAPNIC to update. >>Masato Yamanishi: Don't you have any plan to provide web API in such case? >>Guangliang Pan: Yes, maybe we can consider another easier function before we implement it. We just suggest to do this. That's why we see if there is any opinion from the community. Thank you. >>Masato Yamanishi: Are there any further comments or questions? Thank you very much, Guangliang. >>Guangliang Pan: Thank you. APPLAUSE >>Masato Yamanishi: The next one is another informational presentation from Tomohiro. The title is "Which IP address should be used to implement IoT/M2M services?" >>Tomohiro Fujisaki: Good afternoon, everybody. I'm Tomohiro Fujisaki. This time I would like to discuss about the necessity of policy change for the creation of the new policy for the IoT purpose. As many of you know, Internet of Things, IoT, has become so popular a topic in the Internet, and many IoT device services have been started and many IoT-related consortiums have been established and started to discuss 13 many aspects of IoT, such as business issues, platform creation, security issues and so on. But I partly think to implement the IoT service, addressing could be one important consideration point. But I never heard these consortiums or groups discuss about the addressing issue. Here, addressing the IoT, I would like to discuss that, but one assumption is that this here, I want to discuss only the IPv6 addressing issue, because in IPv4 case we can use only the private address and no other address blocks for this purpose, so I would like to discuss about IPv6 policy. To open the discussion, addressing highly depends on the network structure. So I show you some IoT service network examples. Here, I show you four types of networks. The first one is non-IoT dedicated network, second type is dedicated network connected to the Internet, and third is IoT dedicated closed network and fourth is the non-IP network with IP gateway. There may be other types of IoT network, so if you know or if you have such kind of networks, please let me know. This is the first example of a non-dedicated network. In this case, the IoT device is connected to the current Internet. The second type is dedicated network connected to the Internet. 14 This here shows only the Internet network, but there are many, many other wide area networks, such as current network or the IPv6 capable IoT device or maybe such network will be a nationwide network. Third type is IoT dedicated closed network. This is for factory automation or something like that. There are many types of these networks. The fourth step is the non-IP network, but there are some IP gateways assign the proxy IP address to each IoT device. Then next I show you the current IPv6 address policy. We have currently two types of address policy, one is the IPv6 allocation policy and the other is the IPv6 assignment policy. This slide shows the IPv6 allocation policy. This shows how it is linked up to the IoT addressing. For the allocation criteria, for an organization to get an IP address, it should not be an end site and also should have some criteria, number assignment criteria and so on. Maybe this type of program is if some organization has an IPv6 address with this allocation policy. For the assignment policy, the current APNIC assignment policy, some organizations want to get IPv6 address with this policy, maybe they use their provider 15 independent policy. In this category, the criteria is here and also the deadline is here, requests if they are able to demonstrate the reasons why they cannot get IP addresses from their other ISP or LIR, it might have impact to their IoT service. Then for the IPv6 policy, in the next slide I show you the impact of the policy that is proposed for the non-dedicated network structure, so the first type is non-dedicated network, maybe this is no problem with the current policy, because the IoT devices are connected to the current Internet and maybe the IoT have their ISP addresses. The second type is dedicated network connected to the Internet. In this case, if using the ISP's address, these addresses are provided by the connectivity provider, the connectivity provider is okay, but if the IoT devices, the device service is provided by the IoT service provider maybe has a problem with -- I'm not sure if they can get IPv6 address or not. Of course, this is a closed network and I'm not sure which address should be used in this closed network. As you know, IPv6 has the private address, ULA address, but I'm sure it is suitable for this kind of network. Of course, we can use the PI address for that purpose, but 16 this is also not sure this network can get the PI address. Also we have the fourth type of network, the IP gateway and there are non-IP devices under this gateway. In this case, which address should be used? We have the IP gateway and also how much address size should be assigned? This too is a problem. This is a summary slide, and addressing depends on the network structure. Like I said, the four types of networks can get IPv6 address or not, it's a big problem. I would like to hear your opinion. Are there any cases where current IPv6 address policy cannot cover? For example, maybe there are other types of IoT networks, and I think we have to discuss the necessity of the policy change. Also, if you have any opinion or you have any example, I would like to hear about which address should be used in the closed IoT network. Is it possible to use the global PI address or should we use the ULA central or are there others? This is the end of my presentation. Please, does anyone have any questions or comments? >>Masato Yamanishi: Is there a comment or question? >>Adeel Sadiq (NUST): "Other type of IoT network", could 17 you explain this term? It is pretty ambiguous to me. The first point, "other type of IoT network", what kind of IoT network are you talking about here that you cannot use with the current IPv6 address policy? Can you please shed some light on that? >>Tomohiro Fujisaki: I showed you four types of example of network and other type, and the other is separate from these four types of network. >>Masato Yamanishi: He wants to make sure, is there any other types of use case or not? >>Tomohiro Fujisaki: Yes. >>David Huberman (Microsoft): Fujisaki-san, thank you very much. This is very good. As a community, when we think about IP addressing policy, I think, as an engineer, it's very important that we say if I'm building a network and I have devices which speak IP that I should have the ability to decide for myself if I need to give it a PI address or ULA or something. Okay? When we consider IPv6 policy as we move into this Internet of Things, I strongly hope and encourage my fellow operators in APNIC to be very liberal with our policies, allowing engineers to make the decisions they feel are best, because this is all so new for all of us. How do we decide what should and should not happen? 18 >>Tomohiro Fujisaki: Thank you. >>Masato Yamanishi: I have one comment about the use case. I think we also have another use case which is a combination of the second and fourth ones. It is a dedicated IP network, but it has a gateway for Internet, so that is a variation. >>Tomohiro Fujisaki: Yes. Okay. >>Masato Yamanishi: Are there any other comments? I would also like to discuss about the next step, because it's a pretty new topic for us, so I think we cannot reach any conclusion in this meeting, but we need to continue the discussion about this topic. Is there any suggestion about the next step? Tomohiro, do you have any idea? >>Tomohiro Fujisaki: Yes, I would like to continue to discuss about this topic, so I post to the mailing list to kick off the discussion. So, yes, let us continue to discuss on the mailing list and possibly, if there are many people who have an interest in this topic, we can have another session at the next policy meeting. >>Masato Yamanishi: I think people in here are not directly responsible for your company's IoT or M2M services. So if possible, please bring back the use case to your organizations and ask appropriate divisions whether these use cases are covered, what they are thinking 19 right now or not, then feed it back to this community. I think it is very helpful for the discussion. Is that okay? Thank you for a good presentation, Tomohiro. >>Tomohiro Fujisaki: Thank you. >>Masato Yamanishi: You are the next speaker also. Thank you very much. APPLAUSE We have very good progress, so let's go to the last item, which is prop-115. It is a registration of detailed assignment information in Whois database. Please present. >>Tomohiro Fujisaki: Good afternoon again. I'm Tomohiro Fujisaki. At the previous meeting in Fukuoka, this topic was presented by Hiromi-san, but unfortunately she cannot join this meeting, so this time I present prop-115. This is the problem statement. To specify the individual user or organization in the current Internet, additional information is necessary. Without this additional information, operators cannot filter out specific abuse address. So it might lead to over-filter in some cases. I show you two examples. One example is the network using IPv4 address sharing technology case. This example shows you have one IP address that is 20 shared by several Internet users. In this case, if there is one bad guy in this group, the network operator would like to filter out this one user, but if the network operator does not have the appropriate information of the port range for the bad user, the outside network operator can filter out the whole address space of this. This is one problem with the IPv4 address sharing technology case. The second case is the address assignment size information in IPv6. As you know, the IPv6 address assignment size to users may be different among ISPs. Currently, no information about the assignment size. This is assignment size in a specific case, but if we don't have the assignment size information, we cannot filter the individual users. So in some cases, the network operator filters out the whole address range. This is the problem statement. This is the objective of the policy change: to provide more detailed assignment information to network operators and to identify the individual organization or user. If such kind of information is available, lots of operators can filter out properly their bad users and the operators can check the Whois database records when 21 harmful traffic is coming into the network, and the operator can decide to filter out with that information. Our goal is to provide more specific information to support these operations. This is one point: we have no intention to expose each user's private information, only the assignment information, to filter. This is the situation in other regions and countries. As far as I know, no same regulation or discussion can be seen in other regions. This is the proposed solution. Add following the information to the Whois database for the IPv4 case, the port range information to assigned IP for the IPv4 address sharing technology, and for IPv6 assigned prefix size information to the assignment information. This is just an example, not the concrete proposal, but the IPv6 case, such kind of field, it is good to add such kind of field. In this case, I show you the additional fields, but it is possible to use the "Remarks" field here and in such case maybe we need no change to the Whois system. Also this is the IPv4 case, but we also have an example, but I'm not sure if this is good, but such kind of information should be in the Whois database. Again, this is the advantages and disadvantages. 22 The advantages is that operators can configure access filters by using correct assignment information. Also, users who share the same address or the neighbour address space can avoid damage of over-filtering. There are some disadvantages: the operator need to check the registered database records frequently, because maybe this kind of information is changed. In that case, some fields, the additional record or option should be considered for the Whois database. For the address holders, additional registration workload would be needed. These are the disadvantages. The impact on APNIC and APNIC members. For APNIC, if we have to modify the Whois database, there is some cost to modify the system. For APNIC members, members need to update their records if this field is created. This is the discussion on SIG Policy ML. We have got only one supportive message. The message says these three points, first that it helps law enforcement, as well as those who wish to report network abuse. That is one point. The second point is it allows for more targeted spam filtering. But at the same time, the person says this should not be mandatory but be an option for the address holder. This is the summary. We propose to add some 23 assignment information to the Whois database and we add the information so the operators can set the filters with this detailed information. This is the end of my presentation. Any questions or comments? >>Masato Yamanishi: Thank you. Are there any comments or questions? >>Matsuzaki Yoshinobu (IIJ): Hi, this is Yoshinobu Matsuzaki from IIJ. I'm opposed to this proposal because it brings too much complexity to the Whois database. It is interesting to have such information somewhere else, but not in the Whois database. Thank you. >>Tomohiro Fujisaki: Matsuzaki-san, do you have any opinion where we should put such information in the database? >>Matsuzaki Yoshinobu (IIJ): In the Internet we have Internet Routing Registry and to register information we use RPSL, routing policy specification language. This is an assignment policy, so you need to develop new language, like assignment policy specification language, to describe RIRs' assignment policy. >>Tomohiro Fujisaki: Yes. >>Matsuzaki Yoshinobu (IIJ): I don't know where we can have it, but probably not in Whois. >>Masato Yamanishi: Also, why do you think it is too much 24 for the Whois database? >>Matsuzaki Yoshinobu (IIJ): Because to put the port numbers in Whois database, I don't know how much records we need in the database that explore -- I don't know how much, not like double, but much more than that. >>Tomohiro Fujisaki: How do you think about the IPv6 case? >>Matsuzaki Yoshinobu (IIJ): Again, it's assignment policy. Probably the RIR can say, okay, in this range we assign the /56 or /64 for the end user. Still with the policy statement, so we can have a database to provide such kind of policy statement. >>Masato Yamanishi: Thank you. >>Billy Cheon (KISA): We had a survey on this proposal, to get some opinions from our member ISPs. >>Tomohiro Fujisaki: Thank you. >>Billy Cheon (KISA): They reject. We oppose this proposal, because the main opinions from our member ISPs is that detailed information on the Whois network probably is being used as basic information for the network implement, for hacking and spamming. The other reason is workload that this thing created. I think those are the main reasons. I just wanted to deliver from the Korean ISP community. Thank you. >>Tomohiro Fujisaki: Thank you. 25 >>Masato Yamanishi: We have a comment from Aftab. >>Sumon Sabir: Aftab made the comment that Whois database, as it stands today, already has so much in it, because people do not update it properly. So it might be a challenge if we had more records here, and the wrong record is not always good at all. >>Bertrand Cherrier: I am going to be a gentleman and let Ingrid go ahead. >>Ingrid Wijte (RIPE NCC): Ingrid from RIPE NCC. I have a comment on what is done in the RIPE database. With objects that are aggregated by LIR, we have an assignment size attribute where the LIR has to indicate which size they will use to assign from that prefix. Whether they do /56 or /64, they need to indicate that in that attribute, but no further details. >>Masato Yamanishi: Thank you. Bertrand. >>Bertrand Cherrier (Micro Logic Systems): Bertrand Cherrier from Micro Logic Systems. You have two cases in your proposal. The first one I strongly oppose it, the same as last time in Fukuoka, because to me it's encouraging people to use CGN instead of deploying IPv6 on the one hand, but your case No. 2 might be very interesting, just to get the information on who is using IPv6 addresses. Thank you. >>Masato Yamanishi: Thank you. Actually, I think Billy's 26 comment is also related on the first point, which is port range. >>Bertrand Cherrier (Micro Logic Systems): Yes. >>Gaurab Raj Upadhaya (Limelight Networks): Why Whois? Why not DNS or BGP or something else? >>Tomohiro Fujisaki: Actually, I think it's one option. Just the operator wants to know the size, just so the Whois is one proposal, so if we can get such kind of information from another system, maybe a community one is a possible option, I think okay. >>Gaurab Raj Upadhaya (Limelight Networks): CGN and BGP are more robust than Whois. Whois has a lot of useless data in it, to use a very polite language, so I would really -- I don't think this is a good proposal, but you could do some work on putting it into the DNS or BGP, it might be more interesting. Thank you. >>Masato Yamanishi: Thank you. Are there any comments or questions? I think right now we have two major discussion points. The first one is which kind of information should be added. Then we have some concerns about publishing the port range, from a security perspective, but many of you are pretty supportive of announcing assignment size, and also another discussion point is whether we will use the Whois database or not. 27 I think these are two major discussion points. Are there any other discussion points? Tomohiro, I think you also suggested to have some kind of research project. >>Tomohiro Fujisaki: Yes. >>Masato Yamanishi: Which kind of information is needed and what is the purpose of that? Could you explain that? >>Tomohiro Fujisaki: Actually, there are some people have the opinion, we had to consider about which system we should use or which kind of information we should collect. Maybe -- I personally think this is not for the APNIC community program but also more for the global program, so just now I'm not sure of the exact next step. I cannot imagine the next step, but we have to consider and discuss about such kind of point. >>Masato Yamanishi: KRNIC already did some surveys to your members; right? >>Billy Cheon (KISA): Not officially. But anyway we invited major ISPs, like top 10 probably. So we ask the network operators if this policy is implemented in here, then what kind of impacts on your operation, and we got the opinions, those two opinions were my observation. >>Masato Yamanishi: Thank you. If there are no further comment, I would like to ask consensus about this proposal, I would like to ask your opinion about this 28 consensus. If you were here this morning, you have five options: strongly support, support, neutral, oppose or strongly oppose. Can we switch to CONFER? If you strongly support this proposal, please raise your hand now. I mean strongly support this proposal as it is, please raise your hand. If you support this proposal as it is, please raise your hand. Okay. If you are neutral or still wondering about this proposal as it is, please raise your hand now. Okay. If you are opposed to this proposal as it is, please raise your hand now. Okay. If you are strongly opposed to this proposal as it is, please raise your hand now. Okay. We saw some strongly oppose and also several oppose for this proposal. Let's forget about the discussion point, whether we will use the Whois database or not, but let me ask which kind of information should be published. First, let me ask about: this time you only have two options, you support or oppose. If you basically support to publish the port range information in some way, please raise your hand now. If you are opposed to publish the port range 29 information, please raise your hand. Can I assume these opposed opposition comes for security reasons? Okay. Let me ask about assignment size. If you basically support to publish or share assignment size information in some way, please raise your hand now. Okay. If you are opposed to share assignment size in some way, please raise your hand now. Okay. Regarding assignment size, there is some support, no opposition for that. I think for the next step it will be -- let me ask the community. I think a suggestion about the next step is to have more survey which kind of information should be published and which kind of information should not be published and also which solution is feasible to share such information, like Whois database or BGP or DNS. Let me ask your opinion whether we will have such survey in APNIC region or not. If you think we need to have such survey, please raise your hand now. okay. If you think we don't need to do survey, and it is a waste of resource, please raise your hand now. Okay. It seems there is no objection to have such survey. So I need to decide how to proceed with this proposal 30 itself. Let me push back this proposal to the mailing list and also ask to have such survey to the AMM this evening. Is it okay? Okay. Thank you very much, Tomohiro. >>Tomohiro Fujisaki: Thank you very much. APPLAUSE >>Masato Yamanishi: This one was the last item of Policy SIG. I see the Election Chair there. It should be done. >>Sylvia Sumarlin: Now it's the announcement of election results. I'm happy to say the results are here with me right now and also that no disputes have been brought up. I would like to call one of the scrutineers to make a comment on the vote count process before I announce the results. >>Rumy Spratley-Kanis (RIPE NCC): Hi, this is Rumy from RIPE NCC. Agustin from LACNIC and myself have observed the voting and we did not observe any abnormality, everything went according to plan. So we look forward to hearing the results. >>Sylvia Sumarlin: Thank you, Rumy. Thank you, Agustin. I have the envelope with me now, it is still sealed, and I will open it in front of you right now. 31 Okay, the result, 2015 NRO Number Council election, today, 10 September 2015, result announcement: Total paper ballots counted, there are 46. Total valid paper ballots counted, 46 also. Total invalid paper ballots counted, zero. Total aggregate counts for online votes, 42. Total aggregate counts for on-site votes, 46. Candidate name: Tomohiro Fujisaki, total vote count for each candidate 59. Candidate name: Kong Diep, total vote count for each candidate 11. Mohammad Nadir bin Ali: total vote count for each candidate 5. Candidate name: Sandeep Goel, total vote count 5. Sardjono Insani: total vote count 5. Raja Muhammad Azeem: total vote count 2. Dhruba Adhikary: total vote count 1. Elias Mandawali: total vote count 0. Therefore, the successful candidate is Tomohiro Fujisaki. APPLAUSE Thank you for the tellers, Connie Chan, Zen Chuan Ng, Wita Laksono and George Kuo. Thank you. >>Masato Yamanishi: Regarding the last proposal, I got some complaint over the chat. But I would like to make it 32 clear, I said I will ask to have survey, which kind of information should be shared in some way, which kind of additional information should be shared by some way, or which kind of information should not be shared by some way. We have discussed about port range, but it's not the decision in here, because we can ask consensus on each proposal, and this proposal itself is pushed back to the mailing list. Also, some remote participants asked why it is not rejected. Because I think it's still a pretty new concept, so I think it is not fair to reject it at this stage, before asking the result of such survey. It's some kind of pending status. That's the background of my decision. Okay? Then I got a message from Adam -- what do you mean? >>Adam Gosling: The new proposal. >>Masato Yamanishi: Last week, you mean? >>Adam Gosling: Yes. >>Masato Yamanishi: Since we have some time, let me explain about our pretty newest proposal. Actually, it has not yet been accepted, but last week we received new -- how can I say? -- new draft proposal, but it was after the deadline and also it was not yet so mature. So I decided not to present it in here, but basically it is 33 related with Geoff's presentation this morning, because right now we have two different address pools, one is last /8 and another one is IANA returned pool. Basically, if applicants show enough need, they will receive /22 from last /8 pool and also another /22 from IANA returned pool. That is the current operation. This new proposal asks the request to combine these two pools, so actually it means applicants can receive a single /21 instead of two /22s. I said to the author that since these two pools have different policies and have different supply and have -- these two pools have different history, so please consider these points and update his proposal. He is now improving his proposal. So it may be presented at the next meeting. But I just want to let you know that we have another new one right now. But it was received after the deadline, so it was not discussed in this meeting. That's the situation. If there is nothing, I would like to close this meeting. Thank you very much for each presenter and also each author of the proposals, and thank you very much to everybody. APPLAUSE 34