Transcript: Policy SIG
Disclaimer
Due to the difficulties capturing a live speaker's words, it is possible this transcript may contain errors and mistranslations. APNIC accepts no liability for any event or action resulting from the transcripts.
Thursday, 26 August 2010, 11:00-12:30 (UTC +10)
SUNNY: Thank you for coming back for Policy 6 session. We have two locations, two remote hubs participating in this one. I will show you. We have a location coming from Hong Kong and one coming from Bangkok. It is too early for them. Hong Kong is three hours and - sorry, Bangkok is three hours and Hong Kong is two hours' difference.
I would like to remind you again when you are approaching the microphone please state your name clearly. And speak slowly. There is a time difference. There is a transmission lag between us and the remote hubs. So speak slowly so that they can understand and they can share their views, comment, through the remote hubs. Whenever they have questions or comments, I will flip them on to the main screen. So I will be sitting here assisting the chairs for this session. And if you have any questions, I would like you to approach the microphone, please. Don't start commenting where you are sitting there. No, please approach the microphone and then start commenting or start your questions.
That really helps the remote hubs to be with you, to take part in this Policy SIG.
Randy Bush, the chair of the Policy SIG, term completed this meeting and the first title is the Chair Election. I would like to invite the co-chair Terence Zhang, to proceed with the chair election first.
TERENCE ZHANG: Thank you to everyone, for participating in the Policy SIG session. As Sunny mentions, the chair is not here. Ching-Heng and I will chair the first session. First on the agenda will be the chair's election, and then I will do the open action items and Ching-Heng will do the overview of the policy environment process and the summary of the proposal as well. And then we will move into the policy discussion. There are four policy proposals. Hopefully we can finish the first one before lunch time, and the rest of three in the afternoon.
So is everyone clear with the agenda? Any questions?
OK. We will move on.
We move on to the election process: The chair Randy Bush, his turn is up, we call for a volunteer for Policy SIG chair. There were two nominees, Brajesh C Jain and Gaurab Raj Upadhaya. Their biographies can be found in the website. Here is the election procedure. Each candidate will have two minutes to make a speech. It may not be a full introduction. Just the important point, especially their experience with APNIC, and the policy development, it will be very helpful.
After the speech, I will call for a show of hands, and the election is decided by the count of hands. The election will be decided by those who is onsite in this room. The count will be taken by representatives from other RIRs.
The candidate with the larger number of hands is the chair. So anyone has any questions about the election procedure, any questions? Is that clear to everyone?
OK, I think that's the question. OK.
PAVAN DUGGAL: I'm President of Cyber Asia, practicing attorney in the Indian Supreme Court. My question to you is - the election process is going to be by show of hands. Is there any consideration of people who would not be raising their hands? Any clarification in that regard and whether they'll be counted as votes or not?
TERENCE ZHANG: It's just a simple count of hands inside this room. It's a documented procedure. It's a count of hands taken by the representative from the other RIRs. So I think that I'm not quite sure what your question is?
PAVAN DUGGAL: Mr Chair. Apologies that I have not been able to get my question understood. My question is - does the rules and regulations stipulate anything on people who do not raise their hands? And what is the status of those number of people?
TERENCE ZHANG: OK. We do this by the guidelines. So we just follow the guidelines. Because the guidelines are followed by the previous... I think 20 meetings. We are doing the same, so no change this time. Just explaining the procedure. It is not a new procedure. It is what we're doing in the past ten years. So, any questions?
OK, now, we will call the first gentleman, Brajesh C Jain to make a speech. Welcome.
APPLAUSE
BRAJESH JAIN: Namaste. Thank you for this opportunity, Mr Chairman. I will start with (says hello in multiple languages) - good morning to all of you. First of all, I see lots of energy in this community. As was said in the BoF session, there was a majority willingness to work together and very responsive to accept new ideas. I stand here, very keen to be a key member and to contribute to this active and vibrant community. I recognize that Policy SIG task is very important. As policy moves forward to grow the Internet, there is IPv6, security issues, needing your immediate attention. The Internet needs to play a very key role in all-round development of society. With your permission, while my biography is posted, I would just like to say in academics, I got a chance to get an admission in one of the top colleges in India. And received the highest rank in the class by achieving, by graduating with a gold medal.
While in my job, I have reached a good position. And very worked actively in Internet policy, driving Internet business and since the Internet in India in the year 1999. I got an opportunity to work in the development and participating of Internet policies in India whether it is IPv4 Internet telephoning, Internet applications, and converged the play of cable TV and Internet. I have international experience, which I acquired working with NTT of Japan and Telecom Networks in Philippines, Hong Kong, and Japan. I would like to very clearly state that I am new to APNIC and do not have the benefit of interaction with all community members. I have been attending some APNIC and ICANN sessions in the past. I see this as a strength, helping me in aggregating with the APNIC community in an unbiased and neutral manner.
I promise to facilitate an encouraging constructive discussion to build consensus and work towards active participation of community to develop and anchorage new ideas and very effective policies for the APNIC region and for the global community as well.
Thank you for your patience. I will say (Goodbye in multiple languages)
TERENCE ZHANG: Thank you Brajesh. You can step down and then I will ask Gaurab Upadhaya to make his speech. Let's welcome Gaurab.
APPLAUSE
GAURAB RAJ UPADHAYA: Thank you, Terence. Good morning once again. You saw me this morning. I'm Gaurab Raj Upadhaya. I started to work for Lime Light Networks as of this week. I worked in the industry for many years. I see a lot of familiar faces here and I've been a part of the APNIC policy process and other things since around 2002 and actually, I've been to all the APNIC meetings since then. And participated in different policy-related issues and policy discussions. In fact, I remember I was part of the discussion when this policy process, or the PDP, was accepted in the 2002 meeting, when we were discussing that at that time. So that's what makes me interested in the volunteering for the position of the SIG chair policy, mainly because I think I can contribute back to the community.
And to have a good understanding of the policy process here in the APNIC region, as well as having participated in multiple NANOG meetings and ARIN and RIPE and AfriNIC meetings and a bunch of NOG - I've been a speaker at AusNOG, and SANOG, NZ NOG. I don't know, lots of them in the last eight years. So I think that I can bring a good idea from the community both Ops and policy And that's why I'm volunteering for this role here. I hope you vote for me, thanks.
APPLAUSE
TERENCE ZHANG: Thank you, Gaurab. I would like to thank both candidates for their volunteering. I want to clarify the previous question that the gentleman raised. People in the room have the right to choose to vote and not to vote. And they can vote for the people they support. But the result will come by the show of hands. Is that clear? OK.
So, now I'm going to ask for a show of hands for support. Does anybody need more time to consider who you will support? I guess everyone is ready.
Those people who support the first candidate, Brajesh C Jain, please raise your hand clearly.
OK, please put your hands up very clearly and hold them up. Because the ladies have to count. And make sure that the count is correct.
It would be nice if someone can double check that.
OK, OK, thank you. Thank you, then we are going to show hands for the next candidate. Those people who support Gaurab Raj Upadhaya. Please raise your hands clearly. OK, please raise your hands high and clearly so that people can see easily. Keep your hands up so that people can double check.
So, do you agree on the count. Yeah, thank you. Thank you for that for doing that count.
Now, OK. The first candidate, Brajesh gets 17 votes. And the second candidate, Gaurab gets 75 votes.
APPLAUSE
OK. Is there something to add?
BRAJESH JAIN: I wish Gaurab the very best for the success of the policy. Thank you.
APPLAUSE
TERENCE ZHANG: Again, my congratulations to Gaurab, and also my thanks to Brajesh for volunteering. Also, by the way, we would thank Randy Bush for his service.
Now we'll move to the next agenda. And before that, we welcome Gaurab to the stage.
APPLAUSE
Next, we move to the open action items. Those items from the last meeting. Action item one, pol-29.01, prop-078. IPv6 deployment criteria for IPv4 final /8 delegations. It is returned to the mailing list for further discussions and the current update is that the proposal is withdrawn by the authors.
Second item, pol-29-02 pending approval at each remaining stage of the policy proposal process. APNIC Secretariat to implement prop-079, "Abuse contact information." And the current update, the policy will be implemented on November 2010.
Pol-29-03. Pending approval at each remaining stage of the policy proposal process. APNIC Secretariat to implement prop-080, "Removal of the IPv4 prefix exchange policy." The current update is that it is complete.
Pol-29-04 is about prop-081 and the eligibility for the assignments from the final /8. It is returned to the mailing list for further discussion. The current update is withdrawn by the authors.
Pol-29-05, pending approval at each remaining stage of the policy proposal process. APNIC Secretariat to implement prop-082, "Removing aggregation criteria for IPv6 initial allocations." The current update is that it is implemented.
Pol-29-06 is about prop-083. "Alternative criteria for subsequent IPv6 allocations". It is returned to the mailing list for further discussion and the current update is that the author will work on a rewrite and will present it at the next meeting. Probably, we can get the author, Skeeve to give an update. Yeah, maybe you can give just a little bit of an update about how you want to go with this proposal.
SKEEVE STEVENS: I don't need to say much! Sorry about the microphones. Pol-83 will be rewritten and rediscussed and presented at Hong Kong.
TERENCE ZHANG: OK, thank you. So we'll move on to the policy development process. So Ching-heng will be presenting.
GAURAB RAJ UPADHAYA: Thank you to everyone. Thank you for voting me in. I hope that I won't disappoint you. I'll be stepping into Randy Bush's shoes so I probably won't be as effective, I guess! Anyway, what we have decided is that I'm not familiar with everything, so Ching will chair this session up to lunch and then I'll see what I can do. Thanks once again to everyone.
CHING-HENG KU: Good morning everyone. I present the policy development process. And to develop policies and procedures which relate to the management and use of the Internet address resource by APNIC, NIRs, and the ISPs within the Asia Pacific region. It is the Policy SIG charter.
And then the policy development process is open. Anyone can propose policies. Anyone can discuss policy proposals. It's transparent. APNIC publicly documents all policies and discussions and decisions. It is also bottom-up. The community drives policy development.
In the policy process, four weeks, before the APNIC meeting, you can submit your proposed policy or amendment which is five weeks before the meeting. At which the proposal will be discussed. And the SIG chair will post the finalized proposal to the mailing list so that the community can discuss it. And at the APNIC meeting the proposed policies are presented using the Policy SIG session. This is the opportunity to present the proposal in person and then the community will use this opportunity to discuss the proposal. After the meeting, there's a week of proposal consensus at the APNIC meeting. The proposal is sent back to the mailing list for the eight week comment period. If any changes are made to the proposal during the APNIC meeting, it will give time to comment on the modified proposal.
So if the proposal has no substantial objections during the eight-week period, the SIG chair will ask the APNIC EC to endorse the proposal.
And then the implementation phase when APNIC endorses the policy proposal. The APNIC Secretariat implements the policy. This usually occurs a minimum of three months after the EC endorsement.
So the policy circle is shown on the slide. The community identified a policy issue which needs addressing. And the solution is proposed and discussed by the community and agreed solutions are then implemented. And then after that, if the implemented solution has no address, it can create a policy or complication that could be defined. The community can propose a new solution for the issue. So the policy cycle begins again.
So finally, all proposals has been submitted with good intentions, so maybe there could be opinions of difference to see this. So please respect all opinions. It is a brief presentation of the PDP. So, any comments or suggestions?
No, OK. Maybe I will go next to the agenda. The brief summaries of the proposal in this meeting.
OK, so let me give the presentation for the overview of the policy proposal in this Policy SIG.
There are four policy proposals in this session, in this SIG. Prop-084 is frequent Whois information update request.
Prop-085 is eligibility for critical infrastructure assignments from the final /8.
Prop-086 is the global policy for IPv4 allocations by the IANA post exhaustion.
Prop-087 is the IPv6 address allocation for deployment purposes.
Now, the proposals 84 is problems in this proposal aims to address the inability to contact networks when needed due to out of date contact data in Whois and the deliberately wrong contact data in Whois.
So the proposal solution is the Secretariat to send an update notification for all existing objects to the corresponding responsible APNIC account holder once every X months.
And the Secretariat to send update notifications to responsible organizations at times shorter than X if made aware that the organization's objects contain invalid information.
And via the MyAPNIC network managers must verify all objects by actively clicking and acknowledging the correctness of the objects. And they should publish two lists of resources associated with invalid contacts with non-responsive content.
And it will include a link of all Whois output to APNIC for reporting invalid contact information.
The proposal statistics is Version 1 sent to the mailing list on July 2 2010.
And version 2 sent to the mailing list on August 9, 2010. So the discussion the mailing list has nine posts from five people.
It is prop-084. And other RIRs, ARIN conducts an annual POC, point of contact, validation process. There's no similar process at AfriNIC, LACNIC, or RIPE NCC.
And the following is prop-085. The problems, in this problem to address the critical Internet infrastructure will not be able to request assignments when the last /8 is reached. Critical infrastructure may not be able to meet the criteria for an allocation during the last /8 phase.
So they propose the solution is to permit critical infrastructure to receive a single assignment during a final /8 phase.
Use existing criteria for critical infrastructure assignments. And then organizations who can receive one assignment or one allocation, not both, from the final /8.
And this proposal statistics is sent to the mailing list on July 22. And the discussion on the mailing list is there. 43 posts from 12 people.
And other RIRs, the situations. AfriNIC, they have policy proposals under discussion and that permits assignments as well as allocations to be made from AfriNIC's last /8 from IANA.
ARIN, they have policies that permit both assignments and allocations from a reserved /10 block, as long as the requestor can demonstrate immediate IPv6 deployment requirements.
LACNIC also has policies that permit critical infrastructure assignments to new members from LACNIC final /12.
RIPE also have a similar policy. They have a policy proposal under discussion that permits allocations to be made from RIPE's last /8 worth of space, but not assignments.
Following is prop-086. The problem in this proposal aims to address that there is no policy for how IPv4 address space reclaimed by the RIRs can be returned to IANA and then redistributed amongst the RIRs once IANA's free pool is exhausted. And the authors fear that the previous proposal that dealt with the issue, prop-069, will not gain global consensus.
So the proposal, the proposed solution. The return of address space to IANA by the RIRs to be voluntary. And IANA to reserve the reclaimed address until the first RIR exhausts its entire IPv4 pool.
Now, the reclaimed pool to be distributed by IANA equally to requesting RIRs and addresses distributed to RIRs can not be subsequently be transferred amongst the RIR members unless there is a global policy to allow this.
So the statistic of this proposal is to sent to the mailing list on July 23 in a discussion on the mailing list. There are six posts from four people.
Other RIRs, the situation is still to be submitted to all RIRs.
To the final proposal is the prop-087. So the problem in this proposal to address the current IPv6 address allocation policy is basically based on the number of subscribers the applicant will have. But this does not allow sufficient allocation size to adequately deploy some IPv6 protocols. For example, 6rd.
So the proposed solution is to permit LIRs using an IPv6 deployment protocol in an RFC to be eligible for more /32. They hope that this policy can be applicable until 2013. After 2013, the LIRs will need to return the extra space if they can not justify its use via the HD ratio.
And the statistics of this proposal. This proposal is sent to the mailing list on July 26, and there are 25 posts from 11 people discussing it on the mailing list.
So, let's briefly summarize the proposal to be discussed in this meeting. So is there any comment or suggestion? If there is no comment or suggestion, maybe we can follow up the agenda to the next action item to discuss the prop-085. Eligibility for critical infrastructure assignments from the final /8. So the presenter is Terence. So welcome Terence to give and introduce it and make the introduction of the prop-085.
TERENCE ZHANG: Good morning, everyone. This is Terence Zhang from CNNIC again.
This is prop-085, the eligibility for critical infrastructure assignments from the final /8.
This policy proposal seeks to make it possible for critical infrastructure account holders to receive portable IPv4 assignments from the final /8 space.
In the spirit of the current final /8 policy, this proposal ensures each account holder is only eligible to receive one single allocation or assignment from the final /8 space.
Currently, critical infrastructure networks such as top level domains are eligible to receive portable IPv4 assignments under the critical infrastructure policy.
Currently, 203.119.0.0/16 is used to make /24 assignment s to critical infrastructure.
The current final /8 policy only permits allocations. This means during the final /8 phase, it will be impossible to make IPv4 addresses assignments to end-users under critical infrastructure policy.
During the mailing list discussion, I feel that there might be some confusion about whether the assignment is still possible. So I will make a bit of a clarification. Let's take a look at the allocation and assignment criteria. This is a tax copy from the policy. I highlight those important points in blue. So the criteria for allocation, you have to demonstrate immediate need for /23, /24, something like that, and for critical infrastructure assignment policy, the following critical infrastructure networks are eligible to receive a portable assignment. Root DNS server, gTLD Nameserver, et cetera, so people can see the criteria for allocation and assignments are quite different. For allocation, they have to show the lead of useage, which is led by the number of users they serve.
For assignment, which can be justified by the function. If they are a gTLD operator, they can justify the minimum assignment.
So it is distinctive in the allocation and the assignment criteria.
When we come into the final /8 phase, the final /8 policy, we it will supersede all allocation and assignment policies. So that is the copy of the text of the final /8 policy. Also, I highlight the important points.
Number 10 is the definition of the final /8 phase. It means when the remaining space in the an allocated APNIC address pool which is addresses a total of 1 /8, technically, that is a definition, but in the previous session, we discussed - Guangliang gave an update of what APNIC is going to do. It is likely to be a single /8 block.
But the policy is - technically, the policy is a total amount of address space, which is equal to 1 /8.
Numb 10.1 is the allocations criteria. Each account holder will be eligible to request and receive a single allocation from the final /8 space, with the following condition.
The account holder must meet the criteria for receiving an IPv4 allocation. Either the initial allocation or the subsequent allocation. So based on this criteria, people can no longer use the critical infrastructure assignment policy to justify their need.
Because some of the top level domain operators, they might have difficulty to show a need of /22 or /23, something like that. So it may be difficult for them to justify a /22 allocation from the final /8.
That is the current status.
Situation in other RIR?
AfriNIC has a policy proposal under discussion that permits assignments as well as allocations.
ARIN has adopted a policy that permits both assignments and allocations to be made from the final /10.
And RIPE has a policy proposal under discussion that permits allocation, but no assignments.
LACNIC has adopted a policy that permits critical infrastructure assignments to new members from the final /12.
Details of the proposal. It is proposed that each APNIC account holder will be eligible to request and receive a single assignment from the remaining /8 worth of space, with the following conditions.
The account holder must meet the criteria for receiving an IPv4 portable assignment specified in selection 11.3 "Critical Infrastructure" in Policies for IPv4 address space management in the Asia-Pacific regions .
Each assignment will consist of the minimum IPv4 assignment size for critical infrastructure, or the minimum IPv4 allocation size, whichever is smaller.
All APNIC account holders are eligible to receive only one allocation or assignment from the final /8 space.
So, basically, we just propose to continue to use the critical infrastructure policy to justify assignment during the final /8 phase.
The advantage. This proposal makes it possible for critical infrastructure account holders to receive portable assignments from the final /8 space.
The disadvantages? I don't actually see a disadvantage over that.
The effect on APNIC Members. APNIC Members with critical infrastructures may receive IPv4 address assignments from the final /8.
If they are NIR members, the same as the effect on APNIC Members.
Summary of the mailing list discussion.
There were questions about whether it would still be possible to request critical infrastructure assignments from the designated 203.119.0.0/16 block after the current final /8 policy is activated.
The reservation of the 203.119.0.0/16 was just an operational decision.
All previous allocations and assignment policies will be replaced by the final /8 policy when it is activated.
There was a suggestion that any critical infrastructure assignments made after the final /8 policy was activated should be contined to be made from the 203.119.0.0/16 block.
There was a discussion about the definition of the critical infrastructure. And it is clearly stated in the policy, 11.3, "Critical Infrastructure". And the need for IPv4 address in the final /8 space. I think, the objective of this proposal is to give people options. Technically, it is possible to operate a top level domain using the upstring address or even using, renting the whole facility from a provider. The objective of this proposal is continuing to give people options like what they have today where they can justify their lead using the critical infrastructure policy. Any questions? Or comments?
CHING-HENG KU: Thank you, Terence. If you have any comments or suggestions, please go to the floor.
GREG SOFFE: Telecom New Zealand. I just wanted to clarify or get clarified on this policy around gTLDs. With the event of vanity gTLDs can the.Coms so we don't have critical infrastructure requests for things like dot triple X.
TERENCE ZHANG: I have no comment.
BRAJESH JAIN: From Spectranet India. Can you please see that when is the /8 final policy likely to come into play? Is there an estimate? Number one, and number two, when you say Members, what would be the policy for the NIRs in this respect? Will they be treated as Members? Or will they be treated as separate policies outside of this scope? Thank you.
TERENCE ZHANG: Sorry, I cannot follow you. No, it is not just for NIRs. It is not just for NIR. I think that the proposal is a general policy, that the proposal is a general proposal. It is not just for NIRs.
BRAJESH JAIN: OK, you have an estimate that when this final /8 is likely to come into play? The final /8? When will it come into play? By which time?
CHING-HENG KU: Maybe Guangliang Pan can talk.
GUANGLIANG PAN: From APNIC. I just want to answer the question. It's when the final /8 policy will take place, in my presentation this morning, it's likely that the IANA pool run out earlier next year. And the APNIC pool have a few months address in our pool. And probably, it can be run into late 2011 or likely will be 2012, earlier. But I can't tell you exactly the date. But approximately late next year.
BRAJESH JAIN: I understand, thank you.
CHING-HENG KU: OK.
TERRY MANDERSON: Terry Manderson speaking for myself. -- speaking for myself. I still find it difficult to comprehend that critical infrastructure can live in a world of the last little glob of IPv4 and how you could in fact justify that. I just can't get past that point right now. Additionally, I've not seen any analysis, pragmatic analysis to suggest that this policy will actually be used, irrespective of the math that is used to decide what is the last /8? Further, given Randy's suggestion of making the minimum allocation in the last /8 a /24, that would completely suggest to me that this policy wouldn't see use. Thank you.
TERENCE ZHANG: OK, yeah, I have no comment for this.
CHING-HENG KU: OK, Philip, please.
PHILIP SMITH: Philip Smith, Cisco. I didn't really want to recycle comments from the mailing list, but I just want to point out that critical infrastructure is just the root name servers as far as the operators are concerned. Everything else is discoverable by the DNS. So this definition of critical infrastructure is here is not an operations one. It's a kind of a political business, self-appointed type of thing. They don't need any special address space compared with any other organization does. I mean, I could say that my company could also declare itself critical infrastructure and come along and get 24 out of this kind of piece. So the second comment on the mailing list, I don't understand why the /22 allocation from the final /8 is not sufficient. When you've said that it is probably hard to justify, but it doesn't take much to even justify a /22 today, so I can't imagine what kind of network couldn't even well, can't use a /22 right as it is. I simply don't see the point of the policy at all. There is nothing that I can understand or has been explained on the mailing list so far.
TERENCE ZHANG: Hmm.
SRINIVAS CHENDI: I would like to request the speaker s to stick close to the mics because the remote hubs can not hear your comments.
IZUMI OKUTANI: My understanding of critical infrastructure definition is that maybe they can run without portable address space as well. But it is considered to, they're considered to be important networks in order to run the Internet smoothly. Which is what is defined in the v4 and the IPv6 policy at the same time. So I think that it is important to ensure that the new entrants to, that belongs to this category will be given address space as much as new entrants that can receive allocations. And that's why, because, they can't meet the allocation criteria, which is why we have the different criteria today. That's my understanding and I can see the needs of this policy.
JUDITH DUAVIT VASQUEZ: From PHLOCO. There is a looming crisis on the domain name side of the Internet. And I know this because I was at the ICANN meeting recently in Korea and ICANN really interests itself in the domain name, while we're in the numbers space. Very soon, domain names will be non-Latin, meaning non-English, non-alphabet. In languages many of you don't even know exist. And so, the critical infrastructure that is referred to here, like in the case of domain names, can be a domain name even I can not pronounce, because it is in a dialect in India, the Middle East. Countries you done even know exists. And that is the big additional load to the Internet outside actually of what is IPv6. So when we talk about gTLD or even ccTLDs. There will be country codes that are written in the local language, no longer CH.
But for example, what is CH for Chinese. So I just wish that this is brought to the realization of the NOGs that one day we will be hosting sites with keyboards that are not in the English alphabet.
CHING-HENG KU: OK, thank you, Judith.
JONNY MARTIN: Yeah, so, I think that Philip and others have kind of covered it. I think that this is an unnecessary proposal. And the comment has been made several times before. This is down to the last /8. There is no more. The actual critical Internet infrastructure that actually needs specific IP addresses set aside for them and the root name servers, they've already got them. If you have new entrants coming along which are critical infrastructure providers. If it is really critical to them to get address space, they'll be able to get it through a transfer or some other means. It's just as critical that all of the other ISPs have a need for them as well, so this is not really helping.
CHING-HENG KU: OK. We have Hong Kong and Bangkok attending so if you can speak louder.
WENDY ZHAO: OK, from CNNIC again. Just want to clarify something. At .CN, we do agree with the lady before me saying that the domain name coming up from the new gTLD and the ccTLD and also, the purpose of this proposals I suppose, and we don't really want to set up the special right for the critical infrastructure because that's the only use or the application for the Internet. But we do like the critical infrastructure to have its chance, especially for the newcomer. We'll get their block from the final /8, equally aligned with other newcomers ISPs. As we know the critical infrastructure, they cannot identify themselves to a /22 and only to identify themselves on a /24. And there's no point wasting addresses to ask the /22 as well.
So that's why we want to include the critical infrastructure application in the final /8. It doesn't need to be specific blocks. It just needs equal rights. Thank you.
CHING-HENG KU: Thank you. Kenny.
KENNY HUANG: Address council member and and also Board of TWNNIC. According to the APNIC allocation policy, a critical infrastructure in this has a right to be allocated, but for a reason, the last /8 did not allow critical infrastructure to do so. And probably people think that when we discussed in the last /8, it doesn't matter. But the most valuable asset for us is our last brace. So the stakeholder has the equal opportunity to hold their brace.
CHING-HENG KU: Thank you.
JONNY MARTIN: The last /8 policy deliberately didn't include this stuff because it is the last /8. If we start including the critical infrastructure policy and other policies that are going to come along if we let the first one in, then we don't have a final /8 policy, we just have a really big brick wall.
CHING-HENG KU: So, the explanation for the final /8, it does include the critical infrastructure assignment or not. Is there any explanation from APNIC?
PAUL WILSON: Paul from APNIC. I think it's pretty clear that the policy on the final /8 does not include critical infrastructure assignments, and that's what this policy amendment is all about. The thing that concerns me a little about the discussion from the Secretariat point of view is that we have to deal regularly with enquiries and with explanations about our policy process and the consistency of our policy processes is a pretty common question, it's an inquiry as to why we can do this, but not this, for instance. And I think that we will receive a lot of questions, possibly complaints, about consistency in that it is apparent that the community has recognized and critical infrastructure exists. There may be those who disagree with it, but there is a definition that exists and it has been agreed.
And for some reason, that agreed definition disappears at the end of the slab, the current pool of addresses when the last /8 comes into play. So we will have to deal with that, and it always concerns me a little bit because dealing with these sorts of enquiries and trying to explain from the Secretariat point of view on behalf of the community what's going on can be rather a brick wall to people who see themselves as having a case or rely on having a case. From a personal point of view, I remember a discussion about the last /8 policy that there are thousands of minimum allocations within that last /8 policy sufficient to last for many, many years, even at increasing allocation rates. So I think we've also, in terms of consistency, done a very good job there in making sure that the pool is available and will last for a long time.
And yet, at the same time, without diminishing the truth of the case, it does seem that the need for ongoing, the ideal of ongoing conservation and restricting use is maybe overriding the previous decisions that we've made, both on critical infrastructure and on the size and the appropriate conservative approach to the use of that last /8. So they're my personal comments on this. But yes, it is certainly true, back to the original question, that we would stop making any critical infrastructure assignments at the point that phase 3, as Guangliang defined it, comes into play.
CHING-HENG KU: Thank you, Paul. And any comments or suggestions from Hong Kong or from Bangkok? No.
OK, so any other comments or suggestions from the floor? Is there any explanation?
TERENCE ZHANG: No more. There's a lot of discussion.
CHING-HENG KU: A lot of discussion on the mailing list and in this room. And so maybe we still need to make our process to make conclusion of this. We hope to reach consensus or not. So maybe, Hong Kong and Bangkok can make the preparations so we will make some consensus or not. Because there's some delay from here to Hong Kong and Bangkok Four minutes! So OK.
Anyone who supports this proposal, prop-085, please raise your hands. Hong Kong and Bangkok? No, OK. Thank you. So next question is, if you're against this proposal, prop-085, please raise your hand straight up?
And Hong Kong and Bangkok, if you do not support, if you're against this prop-085, please raise your hand. OK, Hong Kong, Bangkok, are you against prop-085 please raise your hand. Ok Hong Kong, one.
OK, so thank you. So, this does not make the consensus, so we hope that this proposal can have more discussion on the mailing list. So thank you, Terence.
TERENCE ZHANG: Thank you, everyone.
CHING-HENG KU: So the next proposal is prop-087. But we... I think that we don't have enough time to present another proposal and if it can be discussed in the afternoon. So I think that it is a good idea that we can go to have a lunch earlier or check your mailing list, check your mail. So thank you very much for joining this session. So we will begin at 2:00 in the afternoon. So we have another three proposals that we will be discussing in the afternoon. Thank you very much.
APPLAUSE
Thursday, 26 August 2010, 14:00-15:30 (UTC +10)
SRINIVAS CHENDI: I'd like to request Paul Wilson to give a trophy to Google for their generous support to APNIC 30.
PAUL WILSON: Yes, just briefly. Thank you very much to Google. They've been a great supporter of APNIC and a great supporter of the RIRs in the other parts of the world. So thank you to Jake for coming all the way from the Google-plex and standing and going through the draw with us. But thanks a lot. Thank you.
JAMES SPENCELEY: OK, so I'll hand over --
SRINIVAS CHENDI: So I'll hand over to the newly elected chair, Gaurab Raj Upadhaya, to go on with the proposals.
GAURAB RAJ UPADHAYA: Thank you, Sunny. We'll go by the website. The first... well, we have three more proposals. Four more proposals to discuss today. But one of the proposals had been withdrawn by the author, so we'll have prop-085, prop-087 and prop-086. Right. We've already done prop-085, so we'll do prop-087. The IPv6 address allocation for deployment purpose by Tomohiro Fujisaki. I would like to request the author to do the presentation and then we can go on.
TOMOHIRO FUJISAKI: Good evening. Thank you, chairman. I'm Tomohiro Fujisaki and today I propose IPv6 address allocation for deployment purposes.
OK, this is the introduction and I proto add alternative IPv6 allocation criteria for receiving larger than /32 initial IPv6 allocation. My aim is to see the allocation for the purpose to use IPv6 deployment protocol described by the RFC.
And this is the current problem. And the current IPv6 address allocation policy. The criteria is basically based on the number of subscribers, the number of users, the ISP hub and the user assignment size. How many subnet the ISP allocate to the users. But in some cases, the ISP needs other criteria. For example, the 6rd case. The criteria for the parameter of the prefix size is not the number of users, but user assignment size and the number of IPv4 address bits to encode in IPv6 address.
I'll explain in more detail. And 6rd is just a protocol to create an automatic tunnel between the user site and the ISP. Like the 6to4. Actually, 6rd is modified version of 6to4 the internal use. And this is the other thing of 6rd and ISPs can choose it the number of bits to encode in the IPv6 headers and that number of subnet in this field.
And this is my... I think this is a... this addressing is the best, most suitable address for 6rd. This is my opinion and the ISPs are there with the 32 address and the subnet ID for end users. In this case, the ISP needs just /28 IPv6 prefix. And this is my understanding and please correct me if I'm wrong, but under the current policy, if an ISP wants to have the /28, the ISP has to justify this number, 43 million users. Even if the ISP allocates /48 for a technical reason, the ISP has to justify about 200,000 users. And I think this number has to justify is it small or medium sized ISPs. Especially in the IPv6 deployment phase. So this is my proposal.
In my proposal, I define two phases and one is IPv6 deployment and after the deployment phase. And I propose in IPv6 deployment phase. I propose networks using an IPv6 deployment protocol specified in the RFC can get more than /32 in this block. And after the deployment phase, I think this is after 2013, if the ISP still wants to use the address blocks, they have to justify the base with the policy, and if they cannot... if they have extra addresses, they have to return the unused block to APNIC. This is my proposal. And other RIRs. In ARIN, they have two proposals. One is the assignment for 6rd. And one more is IPv6 subsequent allocation policy.
And RIPE has discussed the assignment, but currently they don't have the formal proposal. As far as I know. And this is the advantages and disadvantages. It's very simple. The advantage is, with this proposal, it makes it easy to have the IPv6 implementer to deploy the IPv6 network with the development proposal such as the 6rd and of course, the disadvantage is that in some deployment protocols, maybe the larger IPv6 address blocks are there.
And this is the implementation and I add this - I want to add this criteria to the current IPv6 address policy and impact to the NIRs and the NIRs can select to implement this proposal or not.
And I received several comments and questions in the Policy SIG mailing list. And they were mainly suggestions about the 6rd addressing. So, as I said, it's possible to encode less than 32 bits in the IPv4 in the 6rd address field and also, it's possible to assign another address, such as a netting address to the user and they're using 6rd. And another comment about returning address issues, some comment, it's not good to assign, to make a policy to the RFC.
And about 6rd, the other thing, this is the other thing I think that is best. As I said, it's possible to assign the 32 address here, but I think that it complexifies the operation and looks at the site to site function in the 6rd. This figure shows that if the ISP have three other blocks, three IPv4 address blocks which are not a continuous block, in that case, it's possible to use the 6rd with creating each domains for each address block. And in this case, the ISP can see the ISP with the address block. But the ISP has to manage the multigroup. For the domains. And if the 6rd router did not have the function to process the multiple domain, it has to operate that. And as I said in the previous slide, the 6rd has a function to communicate, to enable communication between end sites, but it is only in the same domains. So the communication between the 6rd domains are disabled.
And I ask the APNIC Secretariat about the allocations statistics of IPv6 and I got this. Currently, about 2,000 APNIC Members have IPv4 address block more than one. And in that 2,000, about 1,300 organizations have the multiple IPv4 address under a different IPv4 address block. So, if they want to use the 6rd, they have to manage to two or more 6rd domains. And I also propose this proposal in the open policy meeting in Japan, and at that time, I proposed just as a 6rd policy. But that policy did not reach consensus. The main objections at that time were that creating a policy for a specific protocol is not good, and should not create a policy if it is possible to implement with some operational effort. And the point is, the points I mentioned at /28 for 6rd is quite a waste of address space.
these comments were made in Japan.
OK, and this is the summary. I propose the 6rd, sorry, I propose an alternative criteria for IPv6 address allocation during the IPv6 deployment protocol with the RFC. Thank you, this is my presentation and I appreciate you giving me any comments or questions.
GAURAB RAJ UPADHAYA: Any comments on this from the floor.
SPEAKER FROM THE FLOOR: I support this proposal because this proposal encourages IPv6 deployment. Thank you.
GAURAB RAJ UPADHAYA: Can the audio. We're getting feedback here in this part of the room.
MATT LEPINSKI: BBN. So in general, I support this proposal. I think that removing perceived impediments to IPv6 deployment is a good thing. However, I wanted a clarification. You said that this applies only to mechanisms described in the standards track RFC. So 5569, which is, I believe, the RFC number for 6rd is an informational RFC.
TOMOHIRO FUJISAKI: Yes, about that. The 6rd, the issues as a proposed standard.
MATT LEPINSKI: Wonderful.
TOMOHIRO FUJISAKI: And the number is 5969.
DAVID WOODGATE: David Woodgate from Telstra. I have some sympathy for the intent of this proposal, but I'm cautious about the idea that it basically makes APNIC a lender of addresses. In a way that perhaps I'm not aware that there's a general precedent for outside of this. So, my feeling is that rather than the issue that was raised at the OPM meeting, you identified about not tying it to any particular protocol, or any specific protocol, I think you actually do need to be extremely specific about identifying this against a protocol. Because otherwise, it has too much capability for scope. I notice that the ARIN proposal is specifically about 6rd. Whereas, and I think that that is the way that your proposal should go as well if you want to go ahead in that direction.
I think that if you don't, if you aren't specific about it, then it will... some of the way you've worded things may have too much leeway of interpretation far beyond what you intended in your draft of the proposal. And likewise, if similar protocols came up, there would be nothing to stop individual proposals being raised to address those as well. I don't see that this is something that needs to try to cover a wide generality of proposals at this point. I think that it would be much more valuable to be specific about 6rd.
YI CHU: From Sprint. There's an echo in the back. Yeah, I speak against this proposal. Especially, you mentioned the general RFCs. You said "A RFC" and I go with David's concern, because you leave it all for future unintended consequences. And I believe that APNIC and the RIR should maintain independence because we are the ultimate IP address resource gate keeper and it should be independent from the IETF RFCs.
My second objection is actually to specifically, the 6rd and you actually, the 6rd leaves room for different implementations and your intention is to implement it temporarily during the deployment phase. And for that, you know, you shouldn't be able to make some compromise, use a different domains, although, you know, you pointed to some shortcomings, but these are not show-stoppers. You can still deploy it with some shoe strings attached without having to go. You can still do it within the current frame work of the address aggregation policy. Thank you.
JONNY MARTIN: Yeah, I think this sets a dangerous precedent for allocating resources based on the technology that an LIR is using. So while I understand that it may make things useful for those using 6rd, the precedent, I think, really overrules me providing any sort of support for this.
DAVID FARMER: From ARIN AC. I would like to clarify the two ARIN proposals. ARIN has one proposal which is specific to 6rd. The other proposal is not specific to 6rd. This was a specific issue of contention, should we be specific? Should we not be specific? We provided two different proposals, two different ways to do it. And when we have the meeting, we'll hash that out.
GAURAB RAJ UPADHAYA: Thank you.
OWEN DELONG: From Hurricane Electric. I can't support the proposal as it is currently written, but I do support the idea behind the proposal. I think giving providers space to deploy 6rd is a very good thing. I think that, you know, rather than worry about getting the best use of exactly every finite address in v6, because there's only 340 zillion, we really need to worry about getting it deployed instead. I don't think that we should be looking at it as a lending process. I think that we should go ahead and let providers deploy 6rd, and when they're no longer dependant on v4 addresses being embedded, they can go back and fill in the holes in their 6rd assignment - or allocation to use that for their own non-v4 based customers and that should work out just fine.
It should even fall on reasonable hierarchical boundaries if they deploy their 6rd correctly. I don't think that that will be a big issue. I think that giving providers more than a /32 is probably a very good thing. In the first /12 in each RIR, there's more than enough room for every currently active autonomous system to get two /28s per region and not even begin burning the first /12. OK, so let's move on.
PHILIP SMITH: From Cisco. I pointed out on the email list, some of the reasons why I'm against this proposal. An ISP does not need to encode the 32 bits of address for 6rd. And yes, I can understand operational simplicity. We can also have operational simplicity by giving every ISP on the planet a /10 out of IPv6, and then we don't need to worry about custodianship of address space. Same, we could have had it in IPv4 by handing out the /8s in 1988 or something. So I don't think that operational responsibility is an argument. I've explained the reason on the mailing list how you can do it. If you use up your entire v4 address space that you would have had as an ISP, you justify more than a /32 of IPv6 anyway.
So I don't see what problem we're trying to solve.
GAURAB RAJ UPADHAYA: Jordi.
JORDI: Well, I am divided myself, because I believe that 6rd is not necessary. I believe that we can achieve 6to4 with onsite 6to4 relays, but as many people don't like 6to4 or like the way that 6to4 works, I believe that we should move ahead with the IPv6 deployment, I think that it will be good to open the pack for using 6rd. And if people prefer to encode the 32 bits, I'm fine with that, because if we count the number of /16s that we need for all the ISPs in the world, we still have many, many years to go with IPv6. So I don't see the problem of going forward with this proposal. Maybe we need to clean up some thing, but I think it is perfectly feasible for maybe, I don't know, 200 years from now on to live with one /16 for every ISP.
Do we really believe that we will be using IP at all in let's say, 100 years? I don't think so. So yeah, I understand that we need to conserve addresses, but up to a certain point. And if this is delaying IPv6 deployment, and this can help us in one way.
The other question I have is, right now, I believe 6rd is implemented by Cisco, so people need to see if going to 6rd is necessary because they may need to replace the CPEs. It costs the same as actually going to dual-stack.
GAURAB RAJ UPADHAYA: Thank you. Any more comments here? I have a few questions for the floor. How many in the audience are actually looking at deploying 6rd or are fairly familiar with the protocol? OK, that's not a lot. I think we have a fair number of comments, both for the proposal and against the proposal. So we'll just do a show of hands to determine whether it can reach consensus or it needs to be sent back to the mailing list for reconsideration. OK?
TOMOHIRO FUJISAKI: Yes.
GAURAB RAJ UPADHAYA: Can you show your hands if you accept it as it is?
Those of you who want it sent back to the mailing list for further discussion and clarification, please raise your hands? OK, I think there is consensus that we send it back to the mailing list.
Any comments from Hong Kong or Bangkok? Or in the jabber chat room? No, nothing from Hong Kong and Bangkok. And not really anything on the jabber chatroom as well. So yes, we'll leave that for you to submit back to the mailing list.
TOMOHIRO FUJISAKI: Thank you.
APPLAUSE
GAURAB RAJ UPADHAYA: OK, next we have prop-086. Global policy for IPv4 allocations by the IANA post exhaustion, version 1. Louie Lee, who was going to present this here, unfortunately could not be here, so Dr Kenny Huang will present this proposal on behalf of the authors. Louie is available on Skype on the screen to answer questions or reply to anything later on.
KENNY HUANG: Thank you, chair. Good afternoon. My name is Kenny Huang, Address Council member and also Board of TWNIC. I'll present the global policy for IPv4 allocations by the IANA post exhaustion. And basically, the draft that was contributed by a group of people unfortunately could not come here on site, so I'm helping them to make the presentation and we have Louie Lee online, so he should be able to answer the questions in detail.
So, the policy proposal define the process for the allocation of IPv4 address policy post exhaustion phase, last defined in the draft. In order to fulfil the requirements of this policy, the IANA must set up a reclamation pool to hold addresses in and distribute from in compliance with this policy. This policy establishes the process by which IPv4 addresses can be returned and re-issued from the IANA post exhaustion phase. Basically, they try to describe the intent of the policy including the exhaustion phase of the IPv4 address space returned to the IANA and also allows allocation by the IANA from the reclamation pool once the exhaustion phase has been completed. Defines need as the basis for further IPv4 allocation by the IANA and does not differentiate any class of IPv4 address unless otherwise defined by an RFC.
Also, encourage a return of IPv4 address space by making this allocation process available. Disallow transfers of address sources from the reclamation pool in the absence of an IPv4 global transfer policy to neutralize transfer process in equity across the RIR. And applies a legacy of IPv4 address space to RIRs, includes any length of fragments currently held by IANA now and in the future.
So, what are the current problems they're trying to address? With the depletion of the IANA free pool of IPv4 address space, the current policy regarding the allocation of IPv4 address space to the IANA will become moot. This policy provides a mechanism from the RIRs to recover IPv4 address space to IANA and provide IANA the policy by which it can allocate it back to the RIR on a needs basis. This policy creates a new global pool of IPv4 addresses space that can be allocated where it is needed on a global basis without a transfer of address space between the RIRs.
So, first of all, we try to define the reclamation pool. Upon the adoption of this IPv4 address policy by the IANA Board of Directors, the IANA establish a reclamation pool to be utilized post RIR IPv4 exhaustion as defined in Section 4. As soon as the first RIR exhausts its inventory of IP address space, the reclamation pool will be declared active.
So, talking about return address space to the IANA. The IANA will accept the reclamation pool all eligible IPv4 address space that are offered for return. Eligible address space includes addresses that are not designated as special use by an IETF RFC or addresses allocated to IANA unless they're being returned by the RIR that they are originally allocated to. Legacy address holders may return address space directly to the IANA if they so choose.
The address allocations from the reclamation pool by the IANA basically, we have the allocations from the reclamation pool may begin once the pool is declared active. Aggregates in the reclamation pool may be divide on the CIDR boundary to the longest minimum allocation or assignment of any other RIR in order to complete these allocations. The reclamation pool will be divided on the CIDR boundaries and distributed evenly into all eligible RIRs. Any remainder not evenly divisible by the number of eligible RIRs based on CIDR boundary equal to or shorter than the longest minimum allocation of all RIR will remain in the reclamation pool. The addresses that are left over will be held in the reclamation pool until the additional IP addresses are returned.
Or a minimum allocation unit is achieved that allows continued allocations from the pool.
The most important thing we're trying to understand is the RIR eligibility for receiving allocations from the reclamation pool. Upon the exhaustion of the RIR's free pool space and after receiving their final /8 from IANA, an RIR will become eligible to request address space from the IANA reclamation pool when it publicly announces via its respective global announcements email list and by posting a notice on its website that it has exhausted its supply of IPv4 address space. Exhaustion is defined as an inventory of less than the equivalent of a single /8 and the inability to further assign address space to its customers in units equal to or short than the longest of the RIR policy defined minimum allocation unit. Any RIR that is formed after this policy has been adopted by the ICANN Board of Directors is not eligible to utilize this policy to obtain IPv4 address space from the IANA.
There's the reporting requirements. The IANA shall publish on at least a weekly basis, a report that is publicly available which at a minimum details all address space that has been received and has been allocated. The IANA shall publish the returned address space report, which indicates the resources were returned, by whom and when. The IANA shall publish an allocations report on at least a weekly basis, which at a minimum, indicates that IPv4 address spaces has been allocated. Which RIR received the allocation and when. The IANA should publish a public report from the RIR eligibility subsquent to Section 5.4.
GAURAB RAJ UPADHAYA: Can you go a little bit slowly.
KENNY HUANG: Finally, we identified no transfer rights. Address space assigned from the reclamation pool not subject to the transfer outside the ICANN Board-adopted globally adopted transfer policy. The definition of the global transfer policy of the purpose of this policy is the global policy that has been processed and adopted by ICANN in complying with the MoU and attachments as agreed in the October 2004 between the ICANN and the RIRs. Finally, I tried to cover some discussion which has been done in the mailing list, and it is not all of the discussion. Of course, if you have any questions on the floor, you can go to -- I believe that Louie is happy to answer the question.
The questions raised from Izumi from JPNIC is, "Is the policy intended to create a frame work to allow re-allocation mechanism to IANA and RIRs." And the answer was, "Yes, the policy is primarily intended to create a framework." A question also from Izumi, "Once an RIR makes a public announcement about the exhaustion of its free pool, that RIR can constantly receive address space from IANA every time the reclamation pool is filled up." An RIR would become eligible from the -- when it has exhausted its address space. And question from Philip, "Why are we trying to prolong the use from IPv4 even past the end." The answer from Louie, "It is our belief that it would be used to help to facilitate transition and be a small help in avoiding participating in costly address markets. " Also, a question from Philip, "What is the incentive for the RIRs to return the IPv4 address space to IANA." And the response, also from Louie. "We believe, we see address space returned to IANA for redistribution, so we assume that this may happen again in the future."
Question also from Philip. "New address pool can be allocated where it is needed on a global basis, but the proposal in 5.3 says that the reclamation pool is divided equally amongst RIRs which contradicts the above para." The answer, "If an RIR is eligible in the space, they will go there where it is needed." And also, Philip's question. "Longest minimum allocation doesn't parse very well. It would be clearer to say, smallest minimum allocation." And basically, the answer was "We will consider your alternate wording for clarity." There was some discussion running right now. So I will leave the discussion on the floor and that's the present of the presentation. You are happy to go with the questions. I believe that we can try our best to answer.
GAURAB RAJ UPADHAYA: Thank you, Kenny. I'm going to put Louie on the screen here. There's been ongoing discussions on the mailing list as Kenny was proposing this here. So I would actually ask Philip who was an active part of that discussion to summarise what the latest discussion on the mailing list is as Kenny was presenting. And then I'll let Louie answer some of the questions. I'll just put Louie on the screen here. Questions? Comments?
Wow, this is very surprising!
MIKE JAGER: This seems very much to me like policy looking for a problem. I really can't see that, as Philip stated, that people... once the v4 is gone, to quote our friend, Mr Bush, "It's gone, it's finished." People are not going to be giving it back in a hurry. I can see that happening and the RIRs are going to accumulate enough space that's worth handing back to IANA for further distribution? Thanks.
GAURAB RAJ UPADHAYA: Philip?
PHILIP SMITH: Philip Smith, Cisco. Yeah, you called my name, so I thought that I better be here. Just to do the last bit and what was being talked about on the mailing list. Given that Louie on the screen there, was pretty late answering. It's all the interesting discussions happening now when it might have been more helpful weeks ago. The issue here is that I'm co-author of the final /8 policy at APNIC, as I think I mentioned. And the design of that was that we were to have a sufficient amount of small bits of address space to last us many, many years. So we've got at moment, 16,000 or more /22s, which are the current allocation rate. I don't know how many years that lasts. It's a long time. So nobody is going to be giving address space back to APNIC, and so they don't actually need it.
V4 is going to be hanging around for quite some time yet. We don't know really how long. Two years, five years, ten years or it could be longer. I reckon the 16,000 /22s will probably last for that length of time, and it is only after that that we will actually be giving address space back as an APNIC members will be giving address space back to APNIC. So that would be the first instance I would see that APNIC would be in a position to give anything back to the IANA. Now, the only reason that people give address space back to APNIC is when they don't need it. And so, when they don't need v4 address space, it means that nobody is using it. So, why do we have this policy here? It doesn't make any sense to me whatsoever. Waste of our time, quite frankly. Sorry to be brutal like that.
But I honestly don't see what problem it is solving.
OWEN DELONG: Hurricane Electric. I have mixed emotions about this policy. I think that we do need some policy by which units of addresses that are returned to IANA, if that happens, and that's admittedly, a big if, can be distributed to the RIRs such that they can be utilized. I have grave misgivings About certain aspects of this policy. This policy would be palatable if it would exempt space reserved under the various - whether you call them soft landing or set aside or whatever policies that reserve space for transitional technologies. I think that that would be a necessary improvement. I do think that the blockade on transfers until there is a globally coordinated policy regarding transfers is an absolutely necessary part of this policy, because otherwise, a region with a liberal transfer policy can provide space that they receive under this policy to an organization which can then provide it to a third party under the transfer policy and go back and say, "Yes, I still have need because I sold that address space. " And get more space under the policy and then just drain the whole pool and go and make lots of money on it. Without actually having had more than a small amount of actual address need satisfied. So, I think that that is actually an important part of this policy. I think that there are some other problems with it. I've expressed those on the mailing list.
GAURAB RAJ UPADHAYA: It seems that there are some questions on jabber. Sam?
CHAMPIKA: There's a question on jabber. From Martin Hannigan. How long will any region set aside pool last?
GAURAB RAJ UPADHAYA: I think that that is probably for Philip.
PHILIP SMITH: Well, Philip Smith here. I don't know how long. APNIC has 16,000 /22s. I think that the Secretariat generally do projections about how long this may last, but at current rate, it is quite a long time. But maybe, I don't know, Guangliang Pan or Sanjaya can give guidance, guesses, estimates.
SANJAYA: Since people are not allowed to double dip on this range, and the fact that we only have about 3,000 Members and the growth rate of APNIC is approximately 300 Members a year... but you never know. Because maybe people start to become APNIC Members and before long, we've got 15,000. Yeah!
LAUGHTER
I've got no figures in my mind!
GAURAB RAJ UPADHAYA: That will last for 50 years.
SANJAYA: It will be a while. The key is that we don't allow double dipping here. So it's a bit different from other regions. Thanks.
GAURAB RAJ UPADHAYA: Yes, Philip in the back there.
PHILIP SMITH: I was going to say, I don't mean to be cruel, but maybe come back nearer to the time that we have a problem. Like 30 years from now or something. OK, that's assuming linear growth. I don't believe linear growth, I expect exponential growth as the Internet has been doing pretty much in the last decade or so anyway. So it won't be 40 years, but I still think that we're looking like a problem 15 or 20 years from now, probably.
GAURAB RAJ UPADHAYA: Louie, do you want to say something?
LOUIE LEE:: I think waiting 15 or 20 years, we shouldn't be waiting 15 or 20 months, given that IANA will be exhausted of their space much sooner.
GAURAB RAJ UPADHAYA: OK. To add to the discussion, there's been back and forth and I know that this policy tries to address the case where IANA has less than /8 of holdings, and give it to other RIRs. But from what they posted from IANA, they don't really have any space like that and APNIC doesn't have a policy of giving address space back to IANA. If something is returned to the APNIC address pool, it goes to the Resource Quality Assurance process, and then goes back to the unallocated address pool. So, how do you think that this policy will change that? That is pretty significant for the APNIC Members?
LOUIS LEE: If I may. As posted by John Curran for ARIN. ARIN is presently working with parties who have use of address space and plan to return it in the next three to six months. And yes, they are aware of the potential monetary value, but want to do the right thing for the Internet community.
OWEN DELONG: Hurricane Electric. I think, this policy isn't about controlling how or what space is given back to IANA. That was decided to be up to each region to determine for themselves. But once space does go back to IANA, there needs to be some way to get that space back to the RIRs, or we look pretty dumb having that sitting there in southern California in the record as yeah, it's here and we don't really know what to do with it. So I think that it is important to have some sort of policy by which any space that does flow in there can flow back out of there to the RIRs so that it can get used by the community. You know, so I think that this does try to solve a real problem. I think that it would be wise of APNIC or useful of APNIC to come up with some consensus among the membership here as to what they want to do, but that would be a separate policy proposal in terms of how they want to return addresses to IANA, if at all.
I don't have a problem if they want to do that. I think that ARIN will eventually come up with a policy to specify how and when and what happens there in that regard. I don't know what other regions will do. I think that ARIN has already been returning space to IANA and I think that ARIN will continue to do so, even without additional policy. But that's really what this is about, having a framework where if space goes back to IANA, not necessarily from the APNIC region, but from any region, it has a way to go back out to the community.
GAURAB RAJ UPADHAYA: Thank you.
JOHN CURRAN: President, CEO, ARIN I'll help Owen out on that last statement where he speculated what ARIN would do and make it clear. ARIN's policy is that we will take address space returned to us and return it to IANA, if that can be done. We'll continue to do that unless the community or the board determines otherwise, and the guidance I've been given is that that is something that needs to be looked at to the extent that any region as a non-needs-based allocation policy.
GAURAB RAJ UPADHAYA: Actually, a question for John. The address space you give back to IANA. Is this based on some ARIN policy, or are you doing that out of good heart for the Internet?
JOHN CURRAN: RFC 2050 has some coverage of that and is like a governing document for all of us. So if the RIR doesn't have the need for the address space, then the theory is an organization that does have the need for an address space, like another RIR, should end up with the opportunity to get that address space. So we return it to the IANA and they give it to an RIR that has need. Well, if RIRs are getting address space based on arbitrary division rules or issuing them to organizations bayed on arbitrary policies, and that includes transfers that are not needs-based, there's no need to move to move the address space to another place. It doesn't necessarily improve utilization because the person receiving it doesn't necessarily need it. So the only reason that we all return address space up is because we don't need it.
The moment the party is using a non-needs-based allocation, there's no need to return anything. It's just going to be given out based on something other than actual need.
GAURAB RAJ UPADHAYA: But when you start running low on IPv4 addresses and there's not enough to be had from IANA, will you still be going to IANA or re-allocating to your own members?
JOHN CURRAN: If would be great if all the RIRs could come to a policy to do that. The last policy that we attempt today do a policy on that failed, and it failed because several of the regions have - for example APNIC, has a policy that says, at address depletion, transfer can proceed without any need requirement. So if that could be triggered, there's no way that ARIN can agree to a policy that always returns address space.
GAURAB RAJ UPADHAYA: OK, that explains it. Any more comments on this? Well, it seems to me from the discussion here that there are pretty strong arguments against the policy. And some pretty strong arguments against some parts of the policy. Yes, John?
JOHN CURRAN: I'll try to make it simpler. Just to be really clear. And this is, all the RIRs have to come to agreement on this sooner or later. To the extent that there's a transfer policy that allows people to transfer addresses with no need, that allows speculators to participate. Well, that's not a problem. You know, speculators don't need addresses but they can do it. The other thing that it does is that it removes the even allocation process. Right now, 3, 6, or 12 months worth of address space is what you're getting. If the RIRs are not involved in doing that assessment to address transfers, then 72 hours after we run out of the free pool and there's no requirement, it's quite possible all of the available address space, materially, will go to all of the people who have the funding to do such.
And those parties, instead of getting a year's worth and having to worry about v6 with the rest of us, might get five years' worth. If the top several dozen ISPs all got a few years, four or five years worth of address space, then they're not going to do IPv6 and it is left to everyone else who can afford address space to have to do v6 migration without the core of the Internet who will have bought their way out. So I guess what I'm saying is that ARIN members basically said, a needs-based transfer policy is essential to maintaining stewardship, even post depletion. When you look at the impact of what this would do for v6, it is pretty dramatic if a group of ISPs all decide that they can get multiple years' worth of addresses and that's what we're enabling.
So this is an ultimate kind of issue which needs to be resolved. The only reason we're talking about it in the return is that ARIN is not going to return address space if at the other side, it's going to enable that practice.
GAURAB RAJ UPADHAYA: Thank you, John, for your views on this. Do I see Paul going up?
PAUL WILSON: Paul Wilson from APNIC. I agree with John that the, that this is by no means decided. There are many things to still be discussed, but I'll just recall from some of the discussions that we've had about the transfer policy over some years. So this is, this recollection may not be entirely accurate and I think we would have to go back, if we were that keen on the exact details, we have to go back to web casts and so on. My understanding of where the community has gone, or how far we've come so far with transfers is that so far, transfers are available and recognized at APNIC under the same criteria as normal allocations, so you can receive a transfer if you can satisfy the criteria for receiving the address space as an allocation. The policy also says that that requirement will disappear when APNIC has no more address space to allocate.
It says nothing about changing any of the criteria by which APNIC would allocate addresses if it subsequently receives addresses. So any allocations by APNIC, unless the policy is changed, of address space which is received by APNIC after depletion, would still be subject to the normal allocation policy. So in that sense, we would still have a needs-based allocation system. There's also a discussion which happened in the context of the transfer policy, which is that if someone has transferred address space to someone else, will they then be a candidate for receiving an allocation from APNIC? And the answer is pretty clearly no, that they wouldn't. So, you couldn't say that someone would receive address space, sell it off and then receive more and repeat that process.
So I'm just... I think that given what John has told us here, we need to be quite clear. And I think that we need to be quite clear in any case about the status of our - the basis of our allocation system. Is it or isn't it needs-based? Because I'm claiming that the allocation system is needs-based. And I think that unless we change policies, then it's going to remain that way. But it's been suggested, somehow perhaps by confusion of the issues, that the existence of a transfer policy is contradictory with the needs-based allocation system. That may or may not be true. I don't see them as contradictory confusing myself, but I think that we need to be clear about this in the future. Thank you.
GAURAB RAJ UPADHAYA: Thank you.
MIKE JAGER: Whether you decide that your transfer policy is needs-based or not, if your transfer policy requires justification of need and need is not deemed to be there, and so the transfer is denied, the transfer is still going to happen. I don't want to rehash the arguments that happen with the transfer policy discussion, but it will happen, make no mistake. People will transfer address space and it will move around. So even if you have your transfer policy saying that even after APNIC has no more v4 to hand out, transfer must still be done based on need. They're going to happen, regardless.
CHAMPIKA: Comment from jabber. Martin Hannigan. The comment is, "I think it's clear that there is a need for IANA to allocate addresses which are returned. That was also demonstrated by the last attempt to pass a similar policy which was not successful. Perhaps we ought to consider if we all green on that point and then try to address the issue raised in an additional version of the proposal."
GAURAB RAJ UPADHAYA: Thank you, Martin. I think what we...yes, Nigel.
NIGEL TITLEY: I'm one of the authors of the policy that failed. The policy failed not on...
GAURAB RAJ UPADHAYA: The policy that is being referred to is prop-069.
NIGEL TITLEY: Yes.
GAURAB RAJ UPADHAYA: So if you are trying to find the old policy, just look for prop-069 on the APNIC website.
NIGEL TITLEY: The policy failed, not on the reallocation criteria, but on the return criteria. That was the only difference between the regions. I would just like to point that out.
GAURAB RAJ UPADHAYA: Thank you. I think what we are getting to, both from Martin and from Nigel, and I personally think as well, is the crux of the problem is if and when IANA receives some return address space from ARIN or from some other RIR or from direct allocations that were made a long time ago, which should enable IANA to make allocations smaller than a /8 to a needs-based. Do we agree to that as an assessment of the problem?
Let me rephrase it. Should we enable IANA to make needs-based allocations to RIRs smaller than a /8?
I think is that the problem that this policy is trying to answer?
KENNY HUANG: Part of it. Any comments on that?
MIKE JAGER: Allocations of what smaller than a /8? It's not going to be there.
GAURAB RAJ UPADHAYA: Yeah, that's what I'm coming to. The policy is saying that if there is return address space from some source to IANA, they should be able to give that space back to the RIR that is in need of it. And as Nigel pointed out, the last time this policy was being discussed, what people did agree to was that the allocation from IANA is fine. But nobody agreed that the address space should be returned to IANA. So if you take the two apart, and this policy here is trying to tell us that when and if IANA receives any address space back from someone. Let's not claim whom, they should be able to assign that to which ever RIR is in need of more address space. So maybe the solution would be to just make a simple proposal which let's IANA make the address allocation on a needs-based basis and that does not have to be a /8.
Right?
GUANGLIANG PAN: Guangliang Pan from APNIC. I think this policy is a bit complicated. I guess most of the people may be not very clear what is actually it is talking about, because they're not really dealing with IANA and other RIRs. Only the request from IANA, our Members don't request just from IANA, so they may not be sure what is the procedure in how to get address and about this policy. So I would like to give a bit of an explanation of what this policy, what I understand.
Actually, this policy is to address those historical addresses. Like this morning, I talked about the 92 /8. That is between the RIR. Before the RIR was set up and IANA has directly allocated those ranges to companies or organizations. Those that are considered at class A, class B and class C addresses and those were the legacy or historical address. And this policy is trying to address those legacy space. If those people return that space to IANA, so IANA will have more space to allocate it to other RIRs. I think that this is a good intention of the policy.
The problem I can see in this proposal is the criteria to receive this address from IANA based on the criteria. Can you put that up?
KENNY HUANG: Yeah, sure.
BILL MANNING: Sure.
KENNY HUANG: Eligibility for receiving information from the allocation pool.
GUANGLIANG PAN: One of the criteria is very long.
No address to give to the minimum size. Means APNIC have a final /8 policy. The level one now in our space. This means APNIC will probably never get back to IANA and qualify for more. I think that this is probably the issue of the policy at the moment where I can see it. So I just want to expand what I understand of this policy proposal at the moment.
GAURAB RAJ UPADHAYA: Thank you Guangliang. I think that we should probably send this back to the mailing list, because there are some very valid points raised about this proposal here and there seems to be a fair amount of pros and cons raised with it. So raise your hands if you think that you should send it back to the mailing list?
Raise your hands if you think that we should completely drop this now.
OK, I think we'll advise the proposal authors To take it back to the mailing list and incorporate the feed back from the discussion here.
KENNY HUANG: OK, thank you.
GAURAB RAJ UPADHAYA: Thank you, Louie.
So I think that we are fairly close to the break time.
So the next proposal is a remote presentation from Germany. I think that we are going to take a break now. 30 minutes break and we'll be back here. Is that right, Sam? 45 minutes?
OK, no, we come back at 3:45. And then one more policy to discuss and then we can go and have the beers!
Thursday, 26 August 2010, 15:45-16:15 (UTC +10)
GAURAB RAJ UPADHAYA: Good afternoon, welcome back.
I will ask my co-chair Terence to chair this session.
The next proposal is prop-084, Frequent whois information update request.
The author is Tobias, he is in Germany.
Nigel will volunteer to present the proposal, and then Tobias will be on the Jabber, and he may answer questions on the Jabber.
Welcome to Nigel.
NIGEL TITLEY: Tobias is not able to be here. He has asked me to present this.
The substance of this proposal is that is to ask APNIC to introduce a service that contacts all current APNIC with resources in the Whois Database and to get them to check that the details in the Whois database are up to date.
There's a couple of problems with the current data. And all RIRs have this problem. But, basically, in some cases, data is wrongly published to camouflage illegal actions, although this is not a major problem, I suspect. I think far more important is that wrong data is published because we forget to update our Whois data. I've certainly done this in the past. Once the data is in the database, it tends to stay.
And the secondary problem is that the data is incomplete. One of the reasons that the data is incomplete is that optional attributes become mandatory. Additional attributes are added and so forth to objects in the database, and to be fair, we're all busy, we don't tend to go back and actually update things.
Now, how do other RIRs cope with this? ARIN has a regular annual point of contact validation process, where they contact all their members and check the data. Other RIRs don't have any similar process so far. This proposal, obviously is to try to introduce such a process in the APNIC region. If this proposal succeed, then it will be presented to the other RIRs for submission there.
OK, details of the proposal.
APNIC will send out a yearly update notification to the current responsible organisation for the following six types of objects. Inet(6)num, autnum, person, roles, irts.
On receipt of that update notification, the object owner, as recorded, must actively acknowledge the correctness of the object. In the case of an object that is incomplete, they have to add all the mandatory information.
And the changed attribute will be updated.
And a further aspect of the policy is that if APNIC is made aware of objects that are invalid, so if somebody has tried to contact the owner of a particular object and has ended up with a telephone number that doesn't work or an email number that does not respond or something of that nature, they can report that to APNIC for further action.
To do that, there will be a URL pointing to a form that will make it easy for Whois users.
It will come out in the Whois output when you query for an object.
How does it work? The initial message goes out and the owner has 60 days to confirm the accuracy of the object. And reminders will go out after 10, 13, 15 days, or as appropriate. If no confirmation comes back, or if no confirmation is recorded in the My APNIC portal, APNIC will add that range to a list which will be marked - that this particular object, the owner of this particular object, has not responded. So it is not a non-responsive object, and it will be a publicly available list.
The other list that they will maintain is the known invalid contact details list. This is a list of objects whose owners' object details are known to be invalid. Object owners will stay on that list until the information is updated.
And it's up to the APNIC Secretariat to include a remark on these lists to show why the information is invalid. That is in the case of invalid contact details.
So what does this solve?
Well, it presumably solves the problem of forgetting to update objects, because you will be prodded every year to do this. And it will also make sure that mandatory attributes are actually added and updated again on a yearly basis.
And more people use the My APNIC portal, which must be a good thing!
Disadvantages? Tobias says no disadvantages are foreseen. But I can see one disadvantage that this will be extra load for APNIC. However, I understand that APNIC have done an impact assessment on this, and they think that the extra work load would be supportable.
And, of course, the effect on you guys - oh, and me as well, because I'm an APNIC Member - is that you will have to update or verify your objects once every year.
NIRs - those of you who are NIRs, obviously, it would be nice if you were to implement a similar service, but that is a different proposal and not covered by this one.
In conclusion, this should improve data accuracy. As a result, it should clean up the APNIC database and it should make sure that all the objects are running at the latest version and with all the necessary attributes filled in.
Questions? Discussion? And thank you.
Tobias, I believe, is online. He will answer questions. I saw this proposal for the first time yesterday. So I'm probably not the best person to answer questions on it.
YI CHU:Sprint. I have a request for clarification. As RIR will receive allocations from APNIC for example /19s, we also sub-allocate to our downstream customers, /25, /26. We do update records both of those allocations. So does your proposal cover both types, and if so, am I responsible for both types of whois records?
YI CHU: It looks like it would be both, but I do want to clarify.
NIGEL TITLEY: I would think it would be both.
YI CHU: The second question is, like I can make a person object for anybody in the room. But my question is, for example, to make a person object for Philip Smith. Would Philip Smith be the responsible party for updating the record or is it me who is putting that record responsible?
NIGEL TITLEY: That's a good point. I'm not sure how personal objects in the APNIC database are protected? But presumably, it is to maintain the person's... the maintainer for that person.
YI CHU: So there is a changed view of whoever is there to be responsible.
NIGEL TITLEY:
YI CHU: For that, I think I agree with the intention of the proposal and I think that there are feasibility problems for the big ISPs and there's thousands of records to be put in the database, and knowing my company, I don't think that we're set up to do that annually. Thank you. DAVID WOODGATE: I support that comment from my colleague in Sprint. I think that this will have feasibility issues for larger ISPs. But the thing that I did want to comment on. I have a couple of questions and the first thing that I want to comment on. This is a very prescriptive policy. This is not just a broad-brush policy of proposed... you know, an annual process for keeping things up-to-date. This is talking about the 10, 15 and 30 and 50 days and such. Things that I would normally have assumed to have been left up to the Secretariat. I'd certainly like to understand from the APNIC Secretariat a bit more detail about what they consider to be supportable. What are the terms of supportability? Does it require additional head count or anything? To support this? NIGEL TITLEY: Is that the question you were going address, Sanjaya? TERENCE ZHANG: There is some feedback to the previous question. Feed back from Tobias. No? Is that feed back from Tobias from the previous question? CHAMPIKA: Yes. "The intention of this proposal is to keep all the data updated. That means all should be updated." Yes, that's the feed back. TERENCE ZHANG: OK, thank you. SANJAYA: OK, we've made an assessment on the feasibility of implementing this. So there's some issues I'd like to clarify here. I've sent that to be mailing list basically to question, what about the historical account holder who doesn't have an account relationship... I'll swallow this microphone. Who doesn't have an account relationship with APNIC. Therefore, they have no access to MyAPNIC. And with the historical account holder, there's no... we can't force them to become an APNIC Member, so that's one. If we can make an exception to those sets of people, then we're all good. Because the rest, you can cover the one who is within MyAPNIC. And then again, echoes Yi Chu's point. From the people who are using MyAPNIC, these are the ISPs. Some of them small and some of them large. The larger ones have thousands of objects underneath. And we were playing with the idea of how to present this. We probably just show them the list of all the objects they have. They can tick all and they say - yeah, they're all good. But wouldn't that defeat the original intention of making sure that every object is correct. So yeah, that's the... we're struggling with that part of the implementation. CHAMPIKA: One little addition to the previous part from Tobias. "Change field is responsible." YI CHU: Just again to follow up on the issues that I see, especially for the person object. When we make that Whois record for the person, we make every effort to ensure that's correct. But those are our downstream customers and people move around. And so, with the turn around these days and basically, every year we have to validate and make changes for every personal record that we put in. I just don't think that it is possible. TERENCE ZHANG: OK, does anybody have any more comments or questions? OK, then let's call for the consensus. Anyone who... David? DAVID WOODGATE: No. TERENCE ZHANG: Anyone who supports this proposal, prop-084? Is it? Prop-084, yeah. Anyone who supports the proposal prop-084, please raise your hand. OK, anyone who opposes the proposal 84, please raise your hand. OK, so I don't think that there was enough support. Let me see if the remote rooms if they have any input? No. Then, I done think that there was enough support for this proposal as it is written. So this proposal will be returned to the mailing list for further discussion. Thank you. APPLAUSE We finished all of the policy proposal discussions. Thank you for participating. There's no more topics in this session. SRINIVAS CHENDI: Thank you for chairing the Policy SIG and also thank you for participating. Just an announcement for tonight's closing dinner. Since you all enjoyed the dolphin show last night and you didn't eat any dolphins last night, so tonight, we're going to take you to Paradise Country to show you the outback Australia! There will be Kangaroos, koalas. You can't eat the koalas! But maybe you can eat the Kangaroos, if they serve it for dinner! OK, so the buses will start at 5:30 pm from the lobby level. There's three buses going to leave at 5:30 pm, and then we're reserving one bus at 7:30 for those who are attending the AP IPv6 task force. So the seats are limited in that bus. It's only a 56-seater bus. So I suggest if you're not attending that session, to take the bus at 5:30 pm. And all of the buses will return from Paradise Country at 9:30 pm. So have a little break and we'll see you at 5:30 in the lobby. Thank you. (End of session) GAURAB RAJ UPADHAYA: I would also like to thank the remote participants in Bangkok and Hong Kong for participating remotely. I think we're done for the day and hopefully you can join us tomorrow for the member's meeting? OK, no, they're not. Thank you very much.