Transcript

APNIC 23
Policy SIG
Thursday 1 March 2007
14:00 - 17:30

KENNY HUANG: OK. Good afternoon, ladies and gentlemen. My name is Kenny Huang, the chair of the Policy SIG. This time is my last time to chair the Policy SIG and, anyway, thank you for coming to the Policy SIG meeting. And joining with me is the co-chair, Toshi-san, and another co-chair, Eugene Li, sitting right there.

OK, before we begin the Policy SIG, I need to quickly go through the housekeeping notes.

OK, the first housekeeping is use the microphone. People asking questions, please use the microphone. This session is broadcasted so please use microphone.

Second is afternoon tea should be outside the meeting room.

The third - APRICOT closing event, the event is at the Grand Hyatt. A shuttle bus will be available starting from 6.30 pm. Detailed information is available at the message board at the registration desk on the ground floor.

The fourth one - MyAPNIC and Policy flash demo all day at the APNIC service lounge and helpdesk.

The fifth one will be - you have the possibility to win an iPod Shuffle. Complete the meeting online survey, then have you a chance to win the big prize. Please visit the APNIC meeting website for the survey form and prize draw details.

The sixth one is the onsite notice board. Where is the onsite notice board? Okay, anyway, try to look for your website to see the onsite notice board.

And the seventh one is the APNIC closing dinner will be tomorrow after the APNIC member meeting.

OK, that's part of the housekeeping items.

The next one is, I will quickly go through today's agenda because we have so many presentations and so many policy proposals submitted to the Policy SIG. And besides, OK, here is the order of the agenda items. You can see from the Policy SIG website and for the last one, the draft of SIG guidelines, I will move to the first, before we do the rest of the items. So later I will give some brief about the SIG guidelines.

And the second one is we do have a wonderful proposal recommended by IPv6 technical SIG that was discussed yesterday and that was presented by CNNIC and Mei Wang regarding the allocation of GAP algorithm. I don't know if we have enough time or not. If we can try to squeeze, if we have three or five more minutes, probably we can allow them to share this information with the Policy SIG members.

OK, I'll go through the first one.

OK, that's the SIG guidelines.


The SIG chairs and co-chairs have discussed their roles, responsibilities and the term. So draft document published on the website. You can follow the link, go to check the SIG guidelines document. Including the roles and responsibilities of chairs and also mention about how to run in the chair election. That's what we will try to do later. And also the definition of consensus, SIG presentation guidelines, so on and so forth. So, if you are interested, you can go to the URL, just download the guideline document.

So basically the chair election, the terms of the chair will be two years. And a staggered chair/co-chair election will be something like that. So, for example, we are running the chair election in year 2007, so the newly elected chair will commence from 2007 until 2009 and co-chair will be elected from 2008 until his mission to 2010. So that is the election procedure. Before the meeting, we have been calling for nominations regarding chair and co-chair because right now we have one chair to step down and one co-chair to step down.

So far, that's the list of the nominees. The nominee for the Policy SIG chair is Toshiyuki Hosaka-san from JPNIC. Right now he's currently the co-chair of the Policy SIG and also we have one nominee for co-chair. It's Dong Yan from CNNIC. Where is Dong Yan? Okay, right. So we have at least one nominee for Policy SIG chair and co-chair. So right now we're going to do the next item, which is the chair and co-chair election.

Um, Okay, since we only have one nominee for Policy SIG chair and one nominee for Policy SIG co-chair, I still need to have your comments regarding the nominee. I would like to see everybody who is in favour to support the nominee for Policy SIG chair, Toshiyuki Hosaka-san. Please raise your hand. Okay, thank you. Sorry, have you finished? Okay. So, we have consensus to elect the newly elected chair, Toshiyuki Hosaka-san and he will carry on his mission starting from APNIC 24 meeting. Thank you.

TOSHIYUKI HOSAKA: Thank you.

KENNY HUANG: Okay, I would like to ask who is willing to support the nominee for co-chair, Dong Yan from CNNIC. Please raise your hands.

Okay. Thank you. So I see the consensus from the community. Congratulations to Dong Yan. He will be carry out his mission to be the co-chair of the Policy SIG.

APPLAUSE

Okay. Thank you, everyone.

So I need to go through the next section because we have very tight schedule.


Okay. This is the open action items. Here is some brief regarding to the Policy SIG. This charter - "To develop policies and procedures which relate to the management and use of Internet address resources by APNIC, NIRs, and ISPs within the Asia Pacific region." And so far the chair is Kenny Huang, myself, and Toshiyuki Hosaka-san will be the next chair of the policy SIG and Eugene Li the co-chair.

All the policy documents, current policies, you can check the URL apnic.net/policy. For policy proposals, you can follow the URL to download the policy proposals.

So far, actually, we have more than eight policy proposals. I haven't updated this slide - we have six policy proposals to be discussed.

Okay, facilitating the process - policy development facilitation. APNIC Secretariat is the first contact. SIG chairs check suitability and discuss it in the appropriate mailing list and there is discussion in the upcoming SIG and AMM. If you want a policy change, you can discuss with peers or submit a proposal using the form at the following link.

Okay, awareness of current policy discussion, you can go to the link. You have to subscribe to receive and post comments. Participation in APNIC meetings and access via remote participation and read minutes and meeting report.

I mentioned housekeeping before.

And that's the open action items from previous APNIC Open Policy Meetings.

Open action on proposal 21-002 - "Pending approval at each remaining stage of the policy proposal process, APNIC Secretariat to implement the proposal establishing a transition timeline for assigning 4-byte AS numbers." That's ongoing.

Action item proposal 22-001 - "Chair to refer proposal 037, deprecation of e-mail updates for APNIC registry and Whois data to mailing list for further discussion."

Proposal 22-002 - "Secretariat to call for formation of a Working Group to further discussion proposal 037 for deprecation of e-mail updates for APNIC registry and Whois data." That will be reported later.

Proposal 22-003 - "Pending approval at each remaining stage of the policy proposal process, APNIC Secretariat to implement the proposal 038, modified lame DNS proposal."

Action item 22-004 - "Pending approval at each remaining stage of the policy proposal process, APNIC Secretariat to implement the relevant parts of the proposal prop-039, a proposal to improve reachability of new IANA blocks."

Action item proposal 22-005 - "Pending approval at each remaining stage of the policy proposal process, APNIC Secretariat to implement the proposal prop-035, IPv6 portable assignment for multihoming."

Action item 22-006 - "Pending approval at each remaining stage of the policy proposal, APNIC Secretariat to implement the proposal 033, end site assignment policy for IPv6."

Action item proposal 22-007 - "Pending approval at each remaining stage of the policy proposal process, APNIC Secretariat to implement the proposal, proposal 041, IPv6 assignment size to critical infrastructure."

That's all of the action items. I would like to ask APNIC to help to respond what is the status of the open action items.

NURANI NIMPUNO: I'm Nurani Nimpuno from the APNIC Secretariat. I'll go through each action item and give you an update on every one.

I believe action 21-002, about 4-byte AS numbers - that is done. That was implemented on the 1st of January this year.

Moving on to the next action item, 22-002, to call for a working group to further discuss proposal 37, the deprecation of e-mail updates for APNIC registry and Whois data. I believe that was done. The working group was created and a new version of the proposal will be delivered later in this session.

As for action item 22-003, the Secretariat to implement proposal 38, modified lame DNS policy proposal. I believe that is done. And that was implemented the 1st of January this year.

Moving along to action 22-004, and that refers to proposal 39, a proposal to improve reachability of new IANA blocks. That one was closed. Elements of the proposal were accepted and implemented at the last meeting. There was a new version discussed but failed to reach consensus on the mailing list so the proposal was abandoned.

Action 22-005 - that was referring to proposal 35, IPv6 portable assignments for multihoming. That is done and that will be implemented 9th of March this year.

Action 22-006 - that referred to proposal 33, end site assignment policy for IPv6. That is also done and will be implemented 9th of March this year.

And the last one, action item 22-007 referred to proposal 41, IPv6 assignment size to critical infrastructure and that is done and was implemented 18th of December.

KENNY HUANG: Okay. Thank you.

So we move to the next agenda item and the next agenda item will be global policy update presented by Nurani from APNIC.


NURANI NIMPUNO: Good morning, everyone - good afternoon, everyone. It's afternoon, but my name is still Nurani Nimpuno and I will be presenting the policy update for APNIC and the other RIR regions. I'll try to be quick because I know that we have a lot of agenda items today.

So I'll give you the status of the policy implementation in this region and then look at the global view.

So proposal 41 - IPv6 assignment size to critical infrastructure. That was implemented on 18th of December last year. And the 4-byte AS number, proposal 32, was implemented on the 1st of January this year. And I think that, as I will mention later, that is a policy that has been accepted in all five regions.

Proposal 38, amending APNIC's lame DNS reverse delegation, that was really just a matter of redefining the lameness definition and that was accepted and implemented on the 1st of January 2007.

We have a few policies that have been accepted and gone through the policy development process. And will be implemented on the 9th of March. Those are proposal 31 - the amendment of IPv6 assignment and utilisation requirement policy and they refer to the HD-ratio of 0.94 and changing the measure of utilisation to /56.

The second one is proposal 33 and that's end site allocation policy for IPv6, which was a new policy - well, it was a change in that it allows LIRs to actually choose the prefix size that they wish to assign to end-users. And the last one, proposal 35 is the IPv6 portable assignment for multihoming, which is a new proposal and a new policy that was accepted allowing end sites to get an assignment to multihome.

Okay, so I'm just going to give you a very quick overview of some of the policy developments in the rest of the world. So starting with IPv4.

12-month allocation period - and this refers to the time - sorry - the allocation time for allocations to LIRs in some - in the RIPE NCC region, it refers to the subsequent allocation and in some of the other regions it actually refers to the initial allocation as well. And in AfriNIC that is under discussion. In LACNIC that has been adopted and in the RIPE region, I believe that's in its last call.

So the second one is PI assignment size, /24 minimum for multihoming networks. And that's in the RIPE region and that is currently under discussion.

In the LACNIC region there was a proposal for Whois privacy, limiting the amount of information registered in the public Whois. That was discussed at the last meeting and I believe there's been no action since then so that's still under discussion so to speak.

There was another proposal to increase the assignment window to /21 to LIRs after six months and that's in last call in the RIPE region. So that's currently being discussed and it's reaching the end of the discussion period.

So moving on to some other policy developments in the other RIR regions.

End-user assignments, in AfriNIC until recently there weren't any end-user assignments, or there was not a policy for end-user assignments, so that has now been adopted. They've also adopted the policy of temporary address assignments, so that refers to, for example, assignments to conferences or to experimental assignments. And that has also been adopted in AfriNIC.

There was a proposal for resource recovery in LACNIC and that has been adopted.

And the two other proposals that are just in the initial review state in ARIN and that is the IPv4 countdown proposal and the eGLOP multicast address assignments and those are also proposals that have been brought to the APNIC community.

So moving on to IPv6, as I mentioned, the HD-ratio changed to 0.94. That had been brought to the APNIC community, has also been brought to the other communities. ARIN and LACNIC have adopted those but it's still under discussion in the RIPE region. The related proposal there of amending the IPv6 assignments and utilisation requirements to /56, that has been adopted in ARIN and it's under discussion at LACNIC and the RIPE region. The end site definition, which I believe is being discussed here as well, is under discussion in LACNIC and the RIPE region.

The PI, or the provider-independent assignments for end-users, is something that's been discussed in all the other RIR communities but only adopted in the ARIN region. And changing the initial allocation criteria is something that's been discussed currently in ARIN and the RIPE region. And finally the critical assignment infrastructure is under discussion in the AfriNIC region.

So that's it for IPv6.

And just very briefly, finally, the Autonomous System numbers, the 4-byte AS number policy has been adopted in all five regions and has been implemented as of January this year.

And this is just a list of all the policy proposals you can find. And I believe that's it from me.

Are there any questions?

KENNY HUANG: Okay. Thank you.

APPLAUSE

TOSHIYUKI HOSAKA: Thank you, Nurani. I'm Toshiyuki Hosaka, the co-chair of this session. I will be chairing the rest of this session. The next presentation is from Jordi Palet and, actually, he has four proposals. Jordi, please.


JORDI PALET: Okay, so this is the first one of my four proposals today. The propose - summary of this proposal is intended as a solution for a number of discussions that have been carried out in different - in all the regions, basically, regarding the existing IPv6 policies and, in fact, in some regions, they already removed this requirement. Basically, the problem is that there may be some ISPs which may not have 200 customers. And asking them to say, "Yes, I will have a plan for 200 customers," somehow can be perceived as even asking them to lie if this is not going to be true just to get the IPv6 allocation.

As I said, this has been submitted or similar proposals have been submitted in other regions and in fact, some of them, I think, right now, AfriNIC and LACNIC, don't have this requirement almost since the beginning their IPv6 allocation policy.

One point here is that I think it's in the case of LACNIC - I am not really sure - they ask just for a reasonable number of assignments to get the allocation, right?

So, if we compare the existing policy it basically changes only one point which is right now plan to assign 200 /48s - I think it says exactly within two years and my modification is proposing to just say, "Plan to make a reasonable number of assignments-in-within two years." In the list, there has been a proposal from JPNIC, it was sent by Izumi, which suggested what I call here the option 2. Option 1 is the same as we had in the previous slide. JPNIC was proposing to plan to make assignments within two years. I totally agree. I also said this in the list this morning. I totally agree with this. This is simple and it's also not making some subjectivity somehow in the hands of the hostmasters to say this is reasonable or not. So I will be in favour actually to go to this, what I am calling here in the slide 'option 2'.

I think it is not really changing the objective of the policy proposal and I discuss it also with the APNIC staff and it seems that it's possible right now to say, "OK, let's go and stick to option 1, option 2, if the people agree."

And that's it. Quick.

TOSHIYUKI HOSAKA: Thank you, Jordi. Any questions or comments?

RANDY BUSH: Randy Bush, IIJ. Why were we so stupid as to put this requirement in in the first place? I mean, such idiocy that we ask the people to tell us that they're going to use it before we give it to them. This seems really silly. We should give it out with a driver's licence.

BILLY CHEON: Hi. Billy from KRNIC. I agree with the proposal, with the modified proposal by JPNIC. I think it is difficult - what is 'reasonable number'? Right, defining it, it is difficult. I think it is better. I second JPNIC's proposal

JORDI PALET: In fact, I must say I have a similar proposal in RIPE and my first version had 'reasonable' and then I took out the 'reasonable' and now the policy being discussed in RIPE is without 'reasonable'. I am starting to be confused with so many proposals.

PAUL WILSON: Paul Wilson here. I will make a comment which is personally motivated. Sympathising with Randy, I think the bar of 200 was considered to be low and to remove the bar and make it any number of assignments seems even more reckless, if you like. It's a plural. It's a minimum of two. You must make assignments, not just one.

I think it is perfectly reasonable for making the bar for entering into the IPv6 system as low as we possibly can, but I do question allocating a /32 for whether it's 200 or even a smaller number of assignments when according to an HD-ratio of 0.8, that's enough for thousands of customers, and on a 0.94 it's even considerably more than that and I would really look forward to some time when we actually are allocating, taking the future seriously into account and allocating according to the actual need for the address space that's being questioned. That's all from me.

JORDI PALET: I think I somehow will agree with you. I think anyway it's a different discussion. It's the discussion about depending on how many customers you plan, how much you get. The reason for going into a single, let's say, minimum prefix for everyone, which was a /32, was basically trying to do a balance between routing entries, because you should announce a single aggregated prefix, regardless of how much addresses may be being wasted in that sense.

I think it's a good comment but it belongs to a different discussion, probably much more complex. That's my view.

RANDY BUSH: Randy Bush, IIJ, again. Have a much greater need for v4 addresses. I think we should give them a /19 for anybody who says they need v4 space. Don't need to say how they're going to use it in anything. Is the same as you are proposing. Except it's a much - v4 space is a much more needed resource. If we just give things away without saying that people actually use them or actually measure them and give them a /32, it's just...you know...our job as the NIC was stewardship and reasonable things, not sitting there taking it and throwing it in the air.

JORDI PALET: Randy, I would agree with your comment if changing this policy creates a big number of requests in addition to the requests that we are having. I don't think that will be the case and, in fact, if you look to LACNIC and AfriNIC, has not been the case.

RANDY BUSH: It's because they don't want v6.

JORDI PALET: Well, that's your view. I don't really think that will make a substantial change in the number of requests.

RANDY BUSH: I think in this region, it will.

JORDI PALET: If we want to go a little bit beyond, I already said this in a couple of mailing lists - this barrier, which is totally artificial, I believe it can be considered against some anti-trust regulations.

RANDY BUSH: Bull! Stop playing lawyer. You are not in Spain. This is not Spain, Jordi. This is not Spain. Also, the people from Mars could come down and shoot us all! If you think it does not make a change in requests, why do you want to do it?

JORDI PALET: Because if there is a single possible allocation according to this change, I think it's fair to do it.

RANDY BUSH: And if there might be 100 bad ones?

JORDI PALET: I don't think that's going to happen.

RANDY BUSH: Well, that's what I'm worried about, Jordi.

JORDI PALET: If that happens, that is another problem. If we are allocating a space, IPv4, IPv6, whatever, and it's not being used the problem is a different one.

IZUMI OKUTANI: I basically agree that we shouldn't give it out to anybody and the reason why we proposed this was we assumed that by saying that it should not be given to an end site, and also by stating that this organisation should provide connectivity to those who assigned, so it pretty much assures that, you know, it's going to be ISPs or some organisations that provide similar kind of services, so we thought that it's not too loose. However, if people think that, you know, this is too loose and we should restrict to ISPs of a certain size, for example, an alternative idea would be that maybe we can keep the current criteria but add it as an 'or' that, if you are an LIR in IPv4, you qualify for IPv4 allocation and ISP and plan to provide the service within two years, you can choose either one, then maybe it meets your intention and also the people who are really concerned about -

JORDI PALET: But then - I think I understand what you mean, but then you will be excluding possible newcomers. I mean ISPs that want to provide IPv6-only services and maybe they are new so it will not - I don't know. We will need to draft a text to know exactly but there is a specific case, which I think is similar to what you are proposing, which is the existing policy in ARIN and I am proposing also to change it because that's excluding new ISPs to come into the IPv6 market.

IZUMI OKUTANI: OK. What I want to clarify for those who are proposing this change is whether you are against allocations to ISPs in general or you're concerned that it expands allocation criteria to any organisation. That's the thing that I want to confirm and then maybe we can discuss about the details of the criteria after we share this understanding.

BILL WOODCOCK: Bill Woodcock. I think we can observe that the people who have access to IPv6 addresses right now are not particularly interested in them, are not requesting very many and are using even fewer.

I think that we, as a community, have not really evidenced a desire, a goal, to get IPv6 addresses adopted because we don't really mostly see the immediate or pressing or economic need for it.

I think that Jordi is looking at this from a very different point of view and representing a different constituency in that, if this is something that we have proven that we don't really care about and don't need very much and Jordi says that he's representing a constituency that does care about it and that does need it and that we are preventing access to that constituency, I don't really see that there's any harm in letting Jordi try this way for a while since what we've been doing clearly hasn't really mattered one way or the other.

PHILIP SMITH: Philip Smith, Cisco. I think I've been to too many registry meetings because I don't know how many times I've seen this proposal. I don't know how many times I can stand up opposing it. I think it is complete nonsense. But it's a "plan to assign". What is a plan? It is not a promise written down, Okay? It's not a permanent guarantee that I will do this on pain of death or whatever. It's a plan. Anybody can come up with a plan. I am planning my next trip. That doesn't mean that I've given some immediate guarantee to the airlines that I will fly on this particular day. I may change my plan, right? It's a plan. So I have yet to meet a single entity that cannot fit in, once they've been explained, that it is a plan. And I do as much work as Jordi does around the world helping ISP who want to go the v6 way to do so once they understand that it's a plan.

Somehow, the plan seems to be, in English, seems to be translated into some kind of guarantee in the local language and I think explaining that language rather than just trying to break the v6 Internet seems more sensible for me.

JORDI PALET: Philip, the problem is some people may not really have that plan, even if it’s not a guarantee. So what do they do? They cannot provide the service?

RANDY BUSH: If they have no plan to provide the service, they won't provide service, will they?

PHILIP SMITH: As Randy says, if they've no plan to provide the service -

JORDI PALET: No, I mean no plan to provide the service to 200 customers. Because there are ISPs which are smaller and they are doing business.

PHILIP SMITH: I'm struggling to think of a country in the world that's got less than 200 people in it.

RANDY BUSH: You're giving them 200 worth of IP space.

JORDI PALET: I can show you many ISPs in the world, especially in developing countries, which have very few big customers. So that's the reality.

KURT LINDQVIST: I want to make one remark and I've seen this a number of times before. I'm referring to our friend with big numbers. I keep seeing this proposal over and over again but I have yet to see a single provider stand up at a microphone and say, "I didn't get my allocation."

TOSHIYUKI HOSAKA: Izumi, this is probably the last.

IZUMI OKUTANI: I believe one of your motivations to have some consistency among the regions and I'm wondering what the criteria is in other regions. Is the criteria in the APNIC region very different from others?

JORDI PALET: Right now, basically, we have not this requirement in AfriNIC, not this requirement in LACNIC. It's being discussed in RIPE and it's being discussed in ARIN and here. I really believe that in other regions it may happen that this is changed. That's my belief.

IZUMI OKUTANI: Okay, thanks.

JORDI PALET: So that will mean that instead of just AfriNIC and LACNIC, other regions will be without this requirement.

IZUMI OKUTANI: Okay. Thanks.

TOSHIYUKI HOSAKA: Thank you. Since this is the policy proposal, we should seek whether we have reached a consensus or not. I will ask three questions regarding this proposal.

First, I will ask whether you can support of this proposal and second I will ask whether you oppose - you are opposed to the proposal, against the proposal. And thirdly and finally, I will ask if you have no opinion this is based on option 1 or 2. I think you have already agreed option 2. So based on option 2.

Please raise your hand who can support this proposal based on option 2. Please raise your hand.

(Pause)

And those who oppose this proposal please raise your hand.

(Pause)

Okay. Thank you.

Those who have no opinions or who don't care. Please raise your hand.

(Pause)

No? Well, um, I can't say this is the consensus of this SIG so I am reluctant to say - sorry.

KURT LINDQVIST: Of those who supported the proposal, how many of you have an IPv6 block?

How many of you have tried to get an IPv6 block?

There we go.

TOSHIYUKI HOSAKA: Thank you.

I think consensus has not reached regarding this proposal.

Thank you.


JORDI PALET: Okay. The next proposal is a very, very minor change to the existing policy. Basically the policy suggests, I think in the introduction, that this policy an interim one and I believe it's not the case and actually, if you look at the policy process, all the policies are somehow always subjected to change. If we want to keep something so specific as this is an interim policy, we should have the same text in all the policies. Otherwise, I think we are making a difference between some policies and others. So that's the main reason.

Basically the change is just to remove the statement saying that this policy is an interim one. I think also there is one more reason is we have much more experience now with IPv6 than when this policy was originally decided and that's the reason probably this statement is still there because it has been changed in some parts in the policy but not a complete review of the policy.

TOSHIYUKI HOSAKA: Leo, you have been waiting.

LEO VEGODA: Leo Vegoda, ICANN. I can't remember if there are four or five active proposals to modify the IPv6 policy, but in any case it's clearly under revision right now. So in that sense, it is an interim policy. I would suggest that, if you want equality between the IPv6 policy and the IPv4 policy maybe it would be better to propose putting this text into the IPv4 policy because that is also modified on a regular basis.

JORDI PALET: It's another option. But I think if you look to the policy development process it's clear that any policy is subjected to modification. Saying it's in every policy is going to say all the policy development process in every policy again. I think it's no sense. I think the policies need to be kept simple and those things that are common to the different policies should be and they are already in the process itself.

TOSHIYUKI HOSAKA: Any other?

IZUMI OKUTANI: I agree that policies need to constantly change anyways, but since this was initially clearly defined as interim policy, maybe we should first do a review on the issues that has been raised and the policy changes that have been made and then after reviewing that, if we feel it's ready to remove this 'interim' word, maybe we can do that but it's just, we just have policy changes without, you know, an overall big picture of, you know, how the policy should be so I think we should first do this before we move the word 'interim'.

JORDI PALET: But if - I am not sure if that was the same with the policy. When we created the policy, it was interim and then when we review it, we will remove the interim. If that's the case I will agree but I don't think that was the case. Probably we want to be fair across all the development process of the policies, we need to say, "Okay, any policy is subjected to change so we don't need to remind inside the text of the policy and moreover in the introduction that when somebody comes in as a new policy may think this is still not stable." And it may be taken as a negative thing against that, that people may be considering that they want to apply for IPv6. So it may be giving a negative implication compared with the rest of the policies. That's my point.

IZUMI OKUTANI: OK. I understand your motivation but I'm not sure if we are still out of this interim phase.

TOSHIYUKI HOSAKA: Any more comments or questions?

Okay, again, this is the policy proposal so I will ask you whether you can support or you are opposed to this proposal. Those who support this policy proposal, please raise your hand.

(Pause)

RANDY BUSH: Support or oppose?

TOSHIYUKI HOSAKA: Support.

JORDI PALET: I was surprised.

TOSHIYUKI HOSAKA: I'm sorry if I am not clear. But those who support this proposal, please raise your hand.

(Pause)

Okay. Thank you. Those who are opposed to this proposal, please raise your hand. Please raise up your hand higher.

Thank you.

Those who are not sure or have no idea, please raise your hand.

Thank you very much. It is hard to say this is a consensus again so I suggest this should be a continued discussion on the mailing list, rather than abolishing this proposal.

JORDI PALET: Okay. Next one?

TOSHIYUKI HOSAKA: Yes, please.


JORDI PALET: This proposal is to remove the requirement that we have in the existing IPv6 allocation policy to document the need for multiple /48s assigned to a single end site.

The problem is the text suggests that the reason for this is the lack of experience. It is not really clear if it's referring to the lack of experience assigning multiple prefixes to a single site or if it's lack of experience in IPv6 in general. But even if it's referring to multiple prefixes in a single site, this is something that has been tested many times and it should not be targeted as no experience on this.

Furthermore, I think it's not reasonable to ask the LIR to justify in a case-by-case basis, in the sense that it's an LIR decision and the LIR already knows that this has impact in their own prefix utilisation. So they will already ask for a justification to the customer or they will take the decision on that basis and when they come back to APNIC to ask for more space they know that, if they are doing this, and it is not correct, that will be their problem. So in that sense, I think it is creating an unnecessary overload of work for APNIC. If they have to justify every little thing for the LIRs, they will spend time in this.

As I said, this is probably not a real problem in the sense of time from the staff but I think that - I really think the concept is broken. There's no need to ask for this kind of justification. It will be the same if we ask for AS numbers or IPv4 and so on and I think it's not being done that way.

This proposal has been also submitted to the rest of the regions and well, basically, what I am proposing is to not require this any more as a justification in the existing policy.

TOSHIYUKI HOSAKA: Thank you. Any comments or questions regarding this proposal?

RANDY BUSH: Randy Bush, IIJ, again. Sorry to bore you with that. Jordi we know you have submitted all ninth 95 of your proposals to all 63 regions and we know they get the same results.

Does anybody here run an LIR, have this problem? Does APNIC have this problem?

Then can we do some useful work please?

TOSHIYUKI HOSAKA: Are you approaching to the mic?

GEOFF HUSTON: No. Running away.

LAUGHTER

TOSHIYUKI HOSAKA: Any other comments or questions?

DONG YAN: This is Dong Yan from CNNIC and besides the discussion of the multiple /48 IPv6 to the end sites, I would like to say that I think probably our role is similar to APNIC so I think probably LIR has the right to do the decision for our member. That is what I want to say. Okay, thanks.

TOSHIYUKI HOSAKA: Any other comments or questions?

So, again, this is the policy proposal. I will ask whether you can support the proposal or not.

Those who can support this proposal, please raise your hand.

(Pause)

Thank you. Those who are opposed to this proposal, please raise your hand. Higher.

(Pause)

Thank you.

Those who have no opinions.

Many? Many.

Thank you very much. You get no supporters to this proposal, so this policy proposal is abandoned.

JORDI PALET: Okay. Next one.


This proposal is intended to provide a solution for portable assignments required by entities which are not multihomed.

There are some organisations that need to make internal assignments. They have a number of sites, even they may have their own layer-2 infrastructure. Even with a small number of sites, not necessarily a big number of sites, and they need to avoid future renumbering if they change their upstream provider or if they become multihomed in the future.

An example may be a university with several campuses and several buildings and they have right now a single upstream provider but they may decide in the next year to change to a better provider. They don't want to renumber all the university or may decide to add a second upstream provider and again they don't want to renumber. Existing policy 035 I think is the number of the policy, only solved the problem in the case they are actually multihomed.

A similar proposal has been already sent to other regions. So how we achieve this? If we broadened the definition of the end site to include a wider range of end-users, to include end-users that have a legal relationship with the service provider. For example, the different campuses or faculties will be considered as end sites.

So the initial allocation criteria changes will be to allow end sites to apply for an allocation and expand the criteria of the type of sites an organisation can provide IPv6 connective to include sites within its own organisations or sites at related organisations. That's the change basically. Right now, in the existing policy it's restricted to other organisations and what I am proposing is to grow them to include end-users related to the organisation, legally or by other means.

TOSHIYUKI HOSAKA: Again, you are waiting for the mic.

LEO VEGODA: Leo Vegoda, ICANN. I know some universities, which is the example you've given, already have IPv6 allocations, so I'm wondering how there is a strong difference between the universities that have and the universities that don't have already. Why is there a set of universities that are unable to qualify under the current policy?

JORDI PALET: Okay. I think that's not the case in APNIC region. Believe. APNIC region, universities cannot qualify directly for the allocation.

LEO VEGODA: They cannot?

JORDI PALET: Maybe someone from the staff? I think they cannot. I don't think there is any university that has an allocation. In other regions that's true. For example, in LACNIC, the hostmasters decide, regardless of what it specifically says in the policy and I know at least 12 or 14 universities in LACNIC that got the allocation following the criteria that are suggesting. But I think in this region that is not the case. Maybe somebody from the staff can confirm?

GUANGLIANG PAN: I'm APNIC's resources manager. In APNIC region we do not allocate IPv6 to a single university at the moment because it's considered as an end site. But universities, like CERNET, it has a lot of universities to get IPv6 allocation. But if some universities have customers assigned to different purpose, different group of customers, then they get the allocation. But not for a single university at this stage.

TOSHIYUKI HOSAKA: Can I clarify, Guangliang? Do you mean that you refused the allocation to the universities or there has not been any request from universities?

GUANGLIANG PAN: So far, we haven't received a request from a single university.

TOSHIYUKI HOSAKA: Okay. Thank you.

RANDY BUSH: Randy Bush, IIJ. Once again, we're solving a problem that doesn't exist. But in the interest of marketing IPv6 by giving it away to everybody who asks, why don't we define a computer as an end site? Because we can really see that, you know, deciding how big the institution is or what shape they are or separate buildings is very difficult. But we really can isolate an IP interface and we know every one of those is very clearly defined. So we give each one a /32. After all, IPv6 space is infinite, and it solves the problem.

JORDI PALET: Randy, if I am a university, I read the policy, I know I cannot get an allocation, I am not going to go come to request it.

RANDY BUSH: It is not a problem!

JORDI PALET: So not getting requests don't mean that there is not a need.

RANDY BUSH: Jordi, we can hypothesise there are 1 million cases out there of people who are afraid to submit - "Oh, my God! I might get denied." They're all the people who have black hair and they cannot see in the policy that if you have black hair you can get IPv6, so they've never asked and there's 3 billion of them in this region. Oh, my God! We should fix that.

TOSHIYUKI HOSAKA: Leo? You have a comment?

LEO VEGODA: I can see Philip standing there and I've already spoken so let me wait for Philip.

PHILIP SMITH: Philip Smith, Cisco. I was only going to add my voice to what Randy has said to what particular problem we are trying to solve. Yes, the problem has been put up but I haven't come across it and I do travel quite a bit and I do speak to quite a lot of people. I would suggest it's wasting our time.

LEO VEGODA: The other point I want to make is irrespective of the proposal, I think the way it's structured makes the policy difficult and cumbersome.

I think the proposal could be structured in a way that makes it easy for people to read and understand the intent and change it to something like, "We want to allow IPv6 allocations to enterprise networks," or something like that.

Because I think the way the text is written at the moment, it talks about changing the meaning of end sites so that end sites can have customers which is sort of odd because then you're not an end site and I just think that's sort of an ugly use of language and so I'd like to, if everyone supports the proposal, I'd like to at least make it as simple and easy as possible to read.

KURT LINDQVIST: Many years ago, when I started going to policy discussions, what we did then was people brought real-life problems with the policy that described the problem and described what to fix it. I think when we try to come up with hypothetical problems of what might or might not occur and then build the policy for its own sake. The policies are there to preserve the resources. Have you forgotten that?

KURT LINDQVIST: Actually, to me, this looks like an open-ended invitation to provide space to anyone because who is it to decide who is worthy enough to get space or who isn't if they may or may not be multihomed in the future? A subset of this that may be more valid would be to come up with a solution to end systems who are not carriers but who already are multihomed. Let's first solve the problem for people who are already multihomed and don't fit the requirements. Then people who may some day in the future in the next 1,000 years be multihomed.

JORDI PALET: That's already solved. I already mentioned that policy - I think - 35 solved that problem. I was trying to they precisely to those who are not multihomed. I put the example that they may become multihomed. But maybe that's not the reason. The reason is they don't want to renumber if they change their provider and they may change every year.

KURT LINDQVIST: Then change v6.

TOSHIYUKI HOSAKA: Please use microphone.

BILL WOODCOCK: Wasn't renumbering the problem that v6 was supposed to fix in the first place?

JORDI PALET: Facilitate, not solve.

BILL WOODCOCK: Oh, Okay.

TOSHIYUKI HOSAKA: I will accept one more comment or question due to the time limitation. Is there any other question or comments? No?

Okay. So, again, this is the policy proposal so I will ask you whether you can support this proposal or not.

Those who support this proposal please raise your hand.

(Pause)

Okay, those who are opposed to this proposal, please raise your hand.

Right. Thank you.

RANDY BUSH: Randy Bush, IIJ. Jordi, with all due respect, I am beginning to feel that this is a denial of service attack on our process and a lack of respect for the members, our time, and our work. I really hope I do not come back to the next meeting and find 20 more proposals to change the little words for IPv6 marketing.

JORDI PALET: Randy, this has nothing to be with marketing and the only reason it's four proposals instead of one is to make it simple to the people to evaluate each part of the proposal. For me it's easy to make a single document but people don't read a very large document. That's the only reason. With all the respect.

RANDY BUSH: The results are the same every time. Learn from them.

TOSHIYUKI HOSAKA: Thank you. So you didn't have the support to this proposal so this proposal will be abandoned. Thank you, Jordi.

The next speaker is Mr Fukushima.

We may have five or six minutes after the presentation, so I hope I can give the time to CNNIC to present their information or presentation.


NAO FUKUSHIMA: Hello. My name is Nao Fukushima from the IPv6 Promotion Council of Japan. I would like to report on our update. This item, we have updates, the result of the session. We are now in the second phase of this trial. It started from the top of 2006 and will continue until the end of 2008. All participants need to agree to at least three, the trial will be over on the end of 2008 with no extension. They have two sets of calls. Start IPv6 service before the end of the trial. They have to submit the schedule.

These are the content of the session that we are doing twice per year, generally. We have current active participants, nationwide ADSL/VoIP service provider, nationwide FTTH service provider, L3 connectivity provider, and public wireless LAN access service provider. The IP innovative dual connectivity service, the IPv6 L3 service. This is the list of the trial. We used 43/8s now.

The most participants are going okay. It seems they can get their goal. The IPv6 service has already provided IPv6. Nationwide ADSL/VoIP serve provider and it starts the service. They are technically alright to provide the service but more participants think to provide the service is too early because of consumer's environment and understanding. Most of the applications rely on an IPv4 environment and most users still demand IPv4. The second reason, they are now strongly expecting Windows VISTA. I think the biggest point they want to make focus on is service to, telling us to provide service in the point of view with Vista.

This consideration, for participants to achieve the goal, we continuously check their status to be in schedule. There is nothing in the schedule, the renumbering the address. We report regularly, twice a year. We will announce the schedule until the end of 2008 in APNIC 24. We will report in the New Delhi meeting. We will report to the open policy meeting. May we see you in New Delhi, thank you very much.

TOSHIYUKI HOSAKA: Thank you. Any questions or comments on this presentation? Okay. Thank you very much.

NAO FUKUSHIMA: Thank you very much.

TOSHIYUKI HOSAKA: So the next presentation is from Mei Wang. You are going to present? Tao Chen is going to present.


TAO CHEN: Good afternoon, I'm from CNNIC. Our title is Evaluations of Growth-Based Address Partitioning Algorithm with Real Data. At first, we will introduce the algorithm method and show you the demo system.

MEI WANG: Briefly, talk about background of the problem and then the key focus is to show you performance results. We will show the allocation results.

We all know the allocations are a key for the routing table structure and size. This it dramatically impacts the scalability and efficiency of the network. The key criteria for a good allocation algorithm is to reduce fragmentation, decrease routing table size and increase scalability. There are many variables that play a role, like total address available, each customer's size and frequency. So we like to find a systematic way to more efficiently allocate addresses. Online optimal is hard. We are trying to reach a balance to being close to optimal and being simple. We proposed a new algorithm called growth-based address partitioning about more than a year here. It turns out at the same time Geoff Huston also proposed similar in his IETF draft.

The one key idea about this algorithm is instead of allocating anybody who is requesting an address to a fixed position in GAP, we look at all the possible address slots and consider the new incoming customer size and growth rate and to find a slot that will give you the longest time before anybody runs out of space, which is called collision. Collision causes fragmentation.

Here is an example that you can choose from multiple address lots and find optimal one. We have shown theoretical analysis and assimilations before that all shows the performance enhancement of this algorithm. Now the key question is does it work in real data. What we did was to ask the question: what if - because IPv6, we still don't have lots of data in the real world yet so we took IPv4 data and the question what if we used the algorithm say 10 years ago or half a year go, what would the results be compared to the current allocation?

Here is just a brief review of the assimilation results we did before which shows the improvement on the total number of customer served and the total amount of address space are used without collision.

It shows this new algorithm can serve a lot more customers compared to the one without considering the growth rate.

This is looking at it from a different angle, consider the total number of fragmentations, this new algorithm has reduced compared to the algorithm without considering the growth rate.

This is the latest results we got, using APNIC IPv4 data. It shows - we got the data from allocation from June last year to December last year. Because APNIC has lots of data, it was 2 /7, it is 122 /7 is just one block and it shows the total number of fragmentations reduced from 100 to 16 using GAP compared to the existing customer.

So what we did was we didn't use any additional information other than the requesting sequence as the customer request comes in. We believe if every customer comes in gives us a relatively accurate estimation, this enhancement can be further, larger enhancement can be accomplished.

We also did some statistics, studied the APNIC data, including all the APNIC data and the data specifically to generate this graph. This is actually an example of this one block we are looking at, they are totally 21 customers and this one shows the frequency of the customers coming in. The one that comes in most frequently had 39 requests during this six-month period of time. Some customers only requested once. The right-hand side is an example of one of the customer's requesting pattern. The X axis is the time, the Y axis is the whole lot of address block is requesting time.

Similar methods were used using CNNIC IP data. This is a smaller log of addresses. It is 213. Another key result from this development is to show we developed a software too, to give visualisation of the address allocation. Right now in this software, gap algorithm is developed but any other algorithms or newly proposal algorithms can be easily plugged in. We think it will be helpful for further studies or even using the real allocation in the future.

Tao will show you a demonstration of the software right after this presentation. Here is a brief summary of all the key allocation methods right now. One is very commonly used in paths is sequential, is basically allocate one address block after another, almost right next to the other. It turns out this algorithm is optimal, given that nobody is growing, every time the request comes in you know for sure how large you need forever.

The second one is by section. This one actually gives each customer uniformly, maximum amount of space to grow. It treats every customer equally but also gives everybody the maximum opportunity.

But we consider in the real world, all customers are not identical. They have different sizes and different growth rates so we propose growth-based address partitioning to leverage more growth for the customer and reach a balance between performance and simplicity. We hope to get more feedback and participation from everybody here. We hope we can work together, jointly to search for a good solution for the future address allocation, both in terms of performance and easy to use.

There are certainly more studies and verifications need to be done and also we hope eventually can provide software too that can be used at all different levels to make the address allocation more systematic and easier for everybody and more efficient. Thank you. Now Tao will show you a demo, quickly, of the software, and at the same time I can entertain some questions.

TAO CHEN: You can notice the customer, if the new customer applies, it is 19 and you can input the size of the block in the system, into the system. The customer ID, the program will automatically select - for existing customer and have different growth rate. Then the new customer applied /19 IP block and programmed automatically. The third customer has slower growth rate and if we put the new customer IP block into the third position and the time of connection will be longer and your connection will kill, the connection we have more fragmentation. If the same customer applies, another /19 IP block, it is -let me call primary allocation first.

The other IP block allocation, and you know, although they apply the IP block twice, but they can get a continuous IP block.

There is enough IP space for the customer, for the growth of the customer. That is our demo. You can recognise the GAP. That is the end to experience it now. You can access http://gap.asrc.cn.

TOSHIYUKI HOSAKA: Thank you, I suggest you can send the presentation to APNIC Secretariat. Thank you very much. This is the end of first session of the policy SIG. You can now go to the coffee break, thank you very much.

APPLAUSE

(End of session)
KENNY HUANG: Okay. Good afternoon. Here we come to the second session of the Policy SIG. Start from a very interesting proposal - IPv4 countdown policy proposal, presented by Toshiyuki Hosaka, also the chair of the Policy SIG.


TOSHIYUKI HOSAKA: Okay. Thank you, Kenny. My name is Toshiyuki Hosaka. I am presenting IPv4 countdown policy proposal. I'm sorry - I am wearing the hat of JPNIC, not of Policy SIG chair.

Okay, so this is the proposal to respond in an orderly way to the upcoming exhaustion in the IPv4 address space.

So how much IPv4 addresses are left? This is Geoff Huston's graph showing that on past consumption of IPv4 and the projected consumption rate, the IPv4 addresses, according to this chart, we have only 49 of /8 block are left. And the consumption rate in the past is almost 10 of /8 block per year and the current projected IANA pool exhaustion is coming in July 2011, which is 4.5 years later.

So current problems - we have no specific policy or plan defined to prepare for the IPv4 exhaustion in any RIRs, including APNIC, so far. So we have only 4.5 years to IPv4 address exhaustion and we will need one or two years to make global coordinated policy to manage IPv4 address exhaustion. And, in addition to that, industry players plan their business or investment for a two- or three-year span so, considering these factors, I can say now is the time to start discussion. We are running out of time.

So, if we do not have any policy or plan for the IPv4 address exhaustion, the termination date of allocations is remaining ambiguous and which could cause these problems:

First, LIRs do not consider IPv4 address exhaustion as an imminent issue. They know that this is very important problems but not considering very serious at this time.

And second, LIRs are likely to face with very large confusions, such as re-addressing their network or rushing for the subsequent allocation request at the last minute within a very limited time frame, probably within a few months before the IPv4 address exhaustion.

And thirdly, some end-users may be left behind to prepare for IPv6 or other IPv6-ready network. This is the problem.

So these are proposal principles. The first - global synchronisation and, second, some blocks to be left and, third, keeping current practices until the last allocation and, fourth, separate discussions on recycle issue. I will explain these items each by each.

So global synchronisation means that all five RIRs should proceed at the same time for taking measures for the IPv4 address exhaustion to ensure fairness across the regions.

And second, some blocks to be left. This is to define the date and this is a very important point. This is to define the date to terminate the new allocation. And to do this, we can ensure all LIRs can receive allocation until that day. And some blocks left will be used for some critical infrastructure such as - this is just an example but we have no IPv4/IPv6 translater. And address policy should be proposed and discussed separately.

Third point - keeping current practices until the last moment. This does not mean freezing the policy as it is, but this means that making large changes in the current policy towards conservation is very difficult, so we should not do that.

And the last point - separate discussions on recycle issue. Recovery or reclaiming of unused address space is very important. We all know that. And it should be addressed. But it should not be tied with this proposed policy, because it takes time to reclaim or recycle the other space.

So this is our proposal.

The first point is that we should announce the day in which the IANA pool becomes less than 30 of a /8. We define this date as A-Date. And terminate new allocation or assignment - this is IPv4 addresses of course - from RIR on the day exactly two years after A-Date. This date we call it as T-Date.

Okay, so this is now and we have almost four or five years until the IPv4 address exhaustion and in advance of the IPv4 address exhaustion, we should have almost two years to get ready for the address exhaustion. And this A-Date is defined as the date in which IANA pool becomes less than 30 of /8 blocks. To do this, according to our estimation, 30 of the /8 pool will be left.

So what is the benefit of this proposal? The benefit is final date of allocations is clearly demonstrated well in advance of it, that is two years before the final allocation. So to do this, LIR can receive IPv4 allocation until that specific date so we can ensure that every LIR can receive IPv4 allocation until this date. And LIRs and users can prepare for the exhaustion and they can request subsequent allocation, they can renumber their network, they can revise their business plan or they can plan for the IPv6-ready network and so on and so forth. And from RIR point of view, RIRs can make the last allocation and avoid causing feelings of unfairness among LIRs. This is implementation schedule. This policy proposal requires global implementation so not implemented until all RIRs adopt this policy proposal. And if this policy is implemented, LIRs should also terminate allocation in line with APNIC.

So in summary, I have four principles for this proposal. One is global synchronisation, some blocks to be left, keeping current practices until the last allocation and separate discussions on the recycle issue. At detail of the proposal is like this - terminate new IPv4 allocation two years after the date in which IANA pool becomes less than 30 of a /8.

And we already have quite a few discussions in the mailing list and we have some questions or comments on this proposal. There was a comment we should change the current policy towards conservation but I think I doubt this is efficient or acceptable to all LIRs because, in reality, IPv4 or the Internet itself is becoming more and more important to people's life

And another comment is we should allocate all addresses rather than keeping some blocks for the reservation because there is some fighting for that allocation or addresses. But if we distribute all the addresses, we can't ensure the final allocation. We cannot define the final allocation of dates. So everybody is assured of the final allocation date, when is the IPv4 exhaustion.

And the other comment was that, our policy artificially accelerates address exhaustion. But I think this is not the case because, according to our estimation, only two or three /8 blocks will be left so if we take only two or three /8 blocks into consideration, the difference would be only one or two months. And there were comments today that there could be some antitrust implications but, I'm sorry, I do not have a good answer to this. Maybe we need some further discussion on this matter.

So we really need your feedback to this proposal. Do you prefer a globally coordinated policy which tackles IPv4 exhaustion or do you leave that decision to each RIR's discretion?

You want to define the last date of allocation or you want all blocks to be allocated. And the date of the final allocation remains ambiguous.

And third point is that you want to keep current policy framework rather than changing the policy towards extreme conservation, like 80%, if you do not reach the 95% usage, you can't receive the allocation or something. And whether you want separate discussion on recycle or marketisation rather than setting the policy for the recycle/marketisation and whether you want to tie it with this discussion, with this particular policy proposal.

Thank you.

PAUL WILSON: Can I make a contribution?

KENNY HUANG: Any questions or suggestions?

PAUL WILSON: I'd just like to make a contribution.

KUSUMBA SRIDHAR: I feel that this requires a lot of discussion and probably any exercise to identify the unused spaces with the members, any exercise earlier? Any indication? Probably that would be also important to probably somewhere understand whether we need this or not. Some kind of survey that is done on a couple of members to understand who might have not even filled up their allocation windows. I know quite many windows have not even opened up their MyAPNIC even to fill up their allocation windows and I guess they will not be using them also. So maybe some kind of first survey to understand the choice of service providers and come to a discussion of how much we need to go into this if unused space is too much, and requires recycle. So recycle and the discussion on the policy. I believe both should be separated and discussed independently.

RANDY BUSH: That's what we're doing.

KUSUMBA SRIDHAR: I was saying we need to separate them and discuss them instead of combining them.

RANDY BUSH: That's what we're doing. We're not discussing recycling.

PAUL WILSON: Paul Wilson from APNIC. I've been asked to read a comment, which was just posted to the SIG Policy list this morning. From Ray Plzak, the President of ARIN, who was unable to be here and he asked me to specifically introduce these comments.

He says, "This policy proposal has now been introduced into the ARIN region. I will not speak to the merits of this proposal but will ask the question that the ARIN General Counsel is now taking up: What is the liability exposure to ARIN if this policy is adopted? What are the antitrust implications if this is adopted by ARIN? And additionally the attorneys of all RIRs should consider what is the antitrust implication of this proposal if adopted globally? I do not intend for this to start a legal discussion on this list by a bunch of people who are not attorneys, but rather to say that this proposal like any proposal can have consequences that the authors of the proposal do not intend. In the case of the antitrust implications, this could be extremely harmful to any RIR that adopts it, and therefore this should be carefully scrutinised by competent attorneys before the community adopts it.

KENNY HUANG: Any questions or comments?

RANDY BUSH: Randy Bush IIJ, as usual. Sorry. Yes, Arano-san, this is mine. I have questions and feelings about lots of details but there is one that very, very seriously worries me and it is similar to the one that Paul just raised that Ray raised, which is - when you hold back and you have the last 30 /8s, the war that will develop over those is unbelievable. And you will immediately have - not immediately; it will take them six months - but you will have the governments, the UN, and every lawyer and George Bush and his bombs trying to get control of those last 30 /8s. Either don't do this or give it away towards the end. That is my biggest worry. I have lots of things about details, etc, etc, I don't understand enough some of the implications but that one scares the hell out of me. You know, if we want the governments to take over our job instantly, do that.

KENNY HUANG: Thank you. Any questions?

RICARDO PATARA: Ricardo from LACNIC. I just have a comment. Generally I think it is a nice time to start to discuss this at least. But we have some concerns in our region so I have to bring them up. I'm not speaking by myself but trying to bring the concerns that the community in our region have.

This policy is stipulating establishing the T-Date might create a rush for IPv4 addresses. What we cannot avoid, even if we thought it was, but this can happen. Each RIR has different consumption rates so, while LACNIC, for instance, will not be able to access new /8 from IANA, others might have received more allocations in this period and there might be a case when T-Date, as you propose, arrive, LACNIC will not have any address space in its own pool while other RIRs might have some and, as pointed out by other people, members in these RIRs might have other ways to access this free pool in their internal RIR pool.
So it's a concern our community have.

KENNY HUANG: Thank you. Question.

LEO VEGODA: Leo Vegoda from ICANN. I've just got a question asking for clarification about the proposal. When I read the text, one of the things the proposal says is that there should be involvement of the ASO AC, I think, and the NRO. And I'm not sure, it sounds like maybe it's a proposal that it should become a global proposal and go through the whole ICANN process. And maybe it shouldn't. And I'm not entirely sure if that is the case or not. Is there an intention that this should eventually be a proposal, a policy, that the IANA is not allowed to allocate address space to RIRs or is the intention that this is RIRs restraining themselves?

TOSHIYUKI HOSAKA: My answer is that we have no intention to involve IANA of this policy. This is a RIR-coordinated policy.

KENNY HUANG: Geoff?

GEOFF HUSTON: Geoff Huston, APNIC. I'd like to answer the question from LACNIC.

By the time you get to the last 30 /8s and you're looking at that last two years, if the current relativities continue, APNIC will get allocated 10 /8s. AfriNIC will get allocated one. ARIN will get allocated six, LACNIC two, and RIPE ten.

What's your concept of fairness? What is fairness? What are you trying to do here? That's a very, very big question about diminishing resources and the amount of time you've got left. Where is demand? Why is demand? What happens after this exhausts anyway?

If we were going to have these discussions, it would have been good to have started them a decade ago, unfortunately, because time is really running out and even, even trying to get this policy through and still have time to get there in two years before it finishes is going to be a practical issue of some challenge.

All of these numbers, by the way, assume business as usual. We're assuming an industry behaving, which I must admit no other industry has ever, ever seen before.

One of the first runs on the bank happened in 1723 in Paris. Two people were killed in the rush. Scarcity is a very strange phenomenon when it gets close to the end and the behaviours that happen as a result of very, very overt scarcity are impossible to model.

I have not modelled that here. What I'm saying here is that, if we're all nice to each other and orderly, that's the outcome. I cannot give you any data from the data that I have that would say what happens if industry believes that the last-chance shop has just opened up. I have no idea. I'm not sure any of us can model that, but that's the best answer I can provide you if that's any help at all.

KENNY HUANG: Thank you. I hope the numbers you provide is credible. OK, switch to Randy.

RANDY BUSH: This is Geoff Huston.

LAUGHTER

And I want to continue to predict the future that we are fooling ourselves. There's a little problem which is there's an assumption here that says when people really realise that they're going to be out of IPv4 space, they're going to seriously move to IPv6. But there is no IPv6-to-IPv4 translater.

So I cannot be on an IPv6 network and access the majority of the Internet. When that happens, there will be years before that technology is developed. What is going to happen in those years is heavy buying and selling of IPv4 address space and massive deployment of IPv4 NATS and that's the real physics and whether we make it two years and a T-Date and a Q-Date and all these magic numbers and theories makes no difference. That's what people are going to do. Yes, Randy. You wanted to speak.

GEOFF HUSTON: I was just going to say thank you, Geoff.

LAUGHTER

PAUL WILSON: This is Paul. I never pretend to be either of these guys.

LAUGHTER

I think Geoff pointed out one possible alternative scenario, which is that there's a rush that actually exhausts the address space before the date at which you're hoping that there would still be some addresses left. But another scenario is actually that address space consumption could be slower than that and in fact we might have more time than we're looking at here.

That could happen by bringing unused IPv4 addresses back into circulation. Because at the moment, what is it Geoff, 40% of all addresses allocated are not routed? Something like that.

GEOFF HUSTON: Interestingly enough, 18 months ago, 50 /8s or the equivalent were not routed. Today, it's 46. The previously historically dormant pool is actually coming back into play in the routing space. So by the time we get to this point, Paul, I have some suspicion that we might be down as low as 25 in that historically unadvertised space. It's an interesting space.

RANDY BUSH: Geoff, were those four advertised by the original owners? Have they sold them and new people advertised them?

GEOFF HUSTON: This is the equivalent of four /8s. 64 million /32s.

RANDY BUSH: But do you think it was the original 'owners' who woke up and announced them? Or do you think people went and found them and hijacked them or do you think that the people who held them said, "I'm not using it. I'll sell it for $1 million"?

GEOFF HUSTON: All of that space bar a small amount predates the RIR system, so it's pre-'97 most of the time. The records about those allocations are amazingly furry and it's almost impossible, Randy, to actually trawl backwards from the data we have about other people's actions and correlate that to routing as we see it but it's a really good question and if I can't answer it I hope someone else does the research but I'll have a look for you. I don't have the data as to who is readvertising it and why it came back. I'm just saying that the equivalent of 64 million /32s have actually reappeared recently.

PAUL WILSON: That's interesting and I promise that Geoff and I didn't set each other up for this, because that's exactly what I'm getting to. There will be increasing amounts of that space brought back into circulation. Now the communities through some policy changes could provide some encouragement to bring that address space back into circulation through all sorts of possible options that I won't go into.

But, in general, the encouragement is likely to be financial and to provide some incentive for that address space to come back into circulation. When we start talking about that sort of financial incentive, then people get sensitive about benefits to historical address space holders, which is a real issue. But I point out that to provide the opportunity for those windfall benefits and the opportunity for those addresses to come back into circulation sooner rather than later would certainly moderate the types of benefits and market, strange market behaviours that would happen if we waited till the exhaustion of the IANA pool and then try and recover that address space and so I point out, although - back to the proposal - that although Toshi has suggested that there be some small, lower rate of policy change or policy development towards conservation, I don't know if you'd regard this as a conservation measure but the type of policy changes that would bring unused address space back into circulation I think would be well worth looking at seriously and doing that fairly urgently because to bring that in while there is a remaining IANA pool would create a much more harmonious and navigable set of changes than to wait until later.

KENNY HUANG: Thank you. Does anyone want to comment on this proposal?

BRAJESH CHANDRA JAIN: I am B.C. Jain, from India. I just want to raise one thing with reference to APNIC versus other bodies. Which agency is likely to have a shortage of space first or whether APNIC is as good as anybody else in this respect. Thank you. Can somebody answer this.

GEOFF HUSTON: If the question is which of the RIRs will exhaust first?

BRAJESH CHANDRA JAIN: Yes.

GEOFF HUSTON: OK. Under the current system, with the current demands - and there's no run - right now, APNIC and RIPE are the much more intensive or busiest IPv4 allocators and both APNIC and RIPE do about 35%, 33% of the total global allocations. ARIN does less. AfriNIC does very small and LACNIC does relatively small. Even over the four years between now and sort of the end, AfriNIC's growth rate is higher but it won't change much. It's coming from a very low base. Depending on the day of the wake and the data I've got, APNIC or RIPE run out first, right? And there's I believe some changes on the way they're going to interact with IANA but subtly I believe make APNIC the first victim by about a month or two. I'm sure RIPE will find that very much relieving news.

KENNY HUANG: Does that answer your question?

BRAJESH CHANDRA JAIN: Yes. Thank you.

KENNY HUANG: Okay. Actually the discussion regarding the proposal already appeared in the mailing list, even here. So Toshi-san, would you like to rephrase your proposal?

TOSHIYUKI HOSAKA: Okay, so this slide summarised my proposal - announce the day in which the IANA pool becomes less than 30 of /8. This is A-Date. And terminate new allocation or assignment from RIR on the day exactly two years after A-Date. This is T-Date. This is my proposal.

KENNY HUANG: Okay. Thank you. I suppose that's clear enough. Okay, since this one is policy proposal, we still need to finish the process. Is there a last question? Anyone want to raise a question? Last chaps? Randy?

RANDY BUSH: Could I ask that, if we're going to take a straw poll of this the room on this that one of the questions asked is that - "Should planning for the end of IPv4 space be done?" What I'm worried about is a negative reaction because of the details here when really the intent and the effort, at least in my opinion, is directed well. But I would have to vote against it because of the details but I think the work is good work and needs to continue. I would appreciate if that was an option you offered.

KENNY HUANG: I leave the option to proposer.

TOSHIYUKI HOSAKA: Actually, I would like to have feedback of these general feelings regarding this proposal and I need feedback like this - you want globally coordinated policy for the IPv4 exhaustion or at each RIR's discretion? Something like this, each by each, rather than seeking consensus of this detailed proposal.

KENNY HUANG: You plan to do that?

TOSHIYUKI HOSAKA: Yeah, yeah.

KENNY HUANG: Can you phrase that.

TOSHIYUKI HOSAKA: This is not seeking consensus.

KENNY HUANG: Just to make sure everybody understand - we are going to discuss.

TOSHIYUKI HOSAKA: The first item I would like to hear whether you want global coordinated policy which tackles this issue - I mean IPv4 address exhaustion. Or you want to leave that decision at each RIR's discretion.

JORDI PALET: I have a question here. When you say globally coordinated, you mean a global policy so you are involving IANA?

TOSHIYUKI HOSAKA: No, no.

JORDI PALET: Because I have the same point when I use sometimes in the mailing list 'global' and maybe you want to say 'common' to differentiate from a global policy. So the idea is to ask if we should have a policy which is the same in all the registries or not. That's right? That's the point of your question?

TOSHIYUKI HOSAKA: Yes, that's the point.

KENNY HUANG: Okay, so we go to the process. For those who are in favour for the first proposal, please raise your hand.

SPEAKER FROM THE FLOOR: The first point?

KENNY HUANG: Yes, the first point of the proposal.

Okay, thank you.

For those of you who oppose the first point, please raise your hand.

Okay. Those who are not clear about the first point of the proposal, please raise your hand.

Okay. I can conclude the first point of the proposal we reach a consensus in the policy SIG. You want to go to the second point?

TOSHIYUKI HOSAKA: Yes. My second point is whether we should define the last date of allocation, I mean flag date, that we should have some blocks for the reserve. Or you want to distribute all of the addresses to the LIRs and remain the date of the final allocation ambiguous.

KENNY HUANG: Yes? Yes.

BRAJESH CHANDRA JAIN: It will be useful that some blocks should be left, but there should be clear policy that what will happen to those blocks and how they will be used and not put in the same situation as reserved for dollar selling or something.

TOSHIYUKI HOSAKA: We should discuss and set different policy for those blocks.

KENNY HUANG: Okay, that would be separate. I suppose that's clear. Sorry, Paul?

PAUL WILSON: I think there are two questions being combined into one here. One is whether or not there should be a last date established - yes or no. The other is whether or not there should be a reserve established, yes or no.

TOSHIYUKI HOSAKA: That's clearer. I agree with that.

TAKASHI ARANO: I want to make a question to Paul. Is there any way to achieve both options?

PAUL WILSON: I guess so, yes. The answer to both could be yes. I think.

TAKASHI ARANO: I don't think so.

GEOFF HUSTON: I agree there should be two but the third one, should we define the last date of allocation, actually makes no sense. As soon as you say the last chance is two years' time, you're wrong. There's a positive feedback loop here about giving information out to a market that reacts to it. So the real issue is not really about defining a date of allocation. Your question, as far as I can see, which is quite a fundamental question is whether the RIRs should have some remaining resource held in 'reserve' for some specified policy that somehow we get an unambiguous idea of how to allocate that, who's the deserving cause. That's really what you're asking. The allocation just makes no sense until you - you only know when it happened when it happened yesterday.

PAUL WILSON: That said, I understand the point of the proposal is actually, to the extent possible, to set a date that is publicly recognised and is and known in advance. Is that correct, Toshi? That's one of your primary motivations is to provide as much advance notice of some particular point.

BILL WOODCOCK: One reason for preserving a reserve block of addresses would be because most of the RIRs have experimental use policies, which are for temporary use and handback for the research community. If we allocate all the way out to the end and everything goes out to permanent recipients, those policies will no longer be of any use and I think we might want to retain them.

KENNY HUANG: Okay. Any questions? Toshi-san, do you want to restate the second point of your proposal, so make sure everybody understands what you're talking about?

TOSHIYUKI HOSAKA: So I will split this question into two questions. Whether you want to define the last date of allocation in advance?

KENNY HUANG: That's the first question. Can I seek a consensus?

TOSHIYUKI HOSAKA: Yes.

KENNY HUANG: For those who are in favour of the second point - first part of the proposal. Please raise your hand.

BRAJESH CHANDRA JAIN: Last date of allocation?

KENNY HUANG: Yes, last date of allocation.

Okay, thank you. For those who oppose the second point, first part, of the proposal please raise your hand. Okay. Thank you. So I conclude we didn't reach consensus for the second point first part of the proposal. Can you mention the second part?

TOSHIYUKI HOSAKA: Okay. We should have some blocks for the reserve.

KENNY HUANG: Okay, for those who are in favour of this point of the proposal, please raise your hand.

Okay, thank you.

For those who oppose the point of the proposal, please raise your hand. Higher please.

Okay, I conclude this point of the proposal didn't reach a consensus.

Okay, do you want to move further?

TOSHIYUKI HOSAKA: Sure, yeah.

The third point is whether we should keep current policy framework rather than changing policy towards conservation?

KENNY HUANG: Any questions?

Okay, for those - sorry.

TOM VEST: Wouldn't this seem to pre-empt potential future decision-making one way or another? I guess it's a general statement of orientation. But it's not clear to me how you would operationalise something like that without pre-empting decisions you might make or not make in future. I think - I guess this is all by way of saying that I think Randy's previous suggestion of, you know, in favour of additional research and careful study of these issues is certainly warranted but it's not agreed what form it should take.

KENNY HUANG: Any other questions? Okay.

TOSHIYUKI HOSAKA: If I am answering that question, I'm not going to intend to - how can I say? This part of the policy proposal is not proposing anything but rather than that I want to know whether people want a conservation policy or not. This is my point.

KENNY HUANG: Can I move forward?

TOSHIYUKI HOSAKA: Yes.

KENNY HUANG: Okay, for those who are in favour of this point of the proposal, please raise your hand higher.

Okay. Thank you.

For those of you who oppose this point of the proposal, please raise your hand.

TOSHIYUKI HOSAKA: My fourth point is whether we should separate discussion on this IPv4 exhaustion policy and with recycle or marketisation, black market policy or something. My point is that policy discussion is very important but we should move forward to create some policy, which tackles IPv4 address exhaustion.

KENNY HUANG: Okay.

TINA BRAMLEY: I wanted to clarify for the record whether consensus was reached on the previous point.

KENNY HUANG: The proposal try to explain more about this point of the proposal.

TINA BRAMLEY: So we're still on "keep current practice"?

KENNY HUANG: Yes. Please raise your hand if the question is clearly answered. Sorry. Maybe I didn't make it clear - for those who oppose this point of the proposal please raise your hand higher.

TOSHIYUKI HOSAKA: Which part?

KENNY HUANG: The third part.

TOSHIYUKI HOSAKA: Third part?

KENNY HUANG: Yeah.

RANDY BUSH: Didn't we just do that?

TOSHIYUKI HOSAKA: We did that already.

KENNY HUANG: Sorry, sorry.

RANDY BUSH: Are you doing it again until we get it right?

LAUGHTER

KENNY HUANG: Sorry.

TOSHIYUKI HOSAKA: Then, if it is not clear, please repeat the third.

KENNY HUANG: Sorry. I'll do the third again because I didn't memorise the correct number. Third point, can we - for those in favour, please raise your hand higher. Okay. Thank you. For those who oppose the third point of the proposal, please raise your hand higher.

KAPIL CHAWLA: Excuse me. Can we have the count again?

RANDY BUSH: Those of you who raised your right hand last time, use your left hand this time!

LAUGHTER

KENNY HUANG: Sorry. This is quite labour intensive. Sorry.

Okay, again, for those who are in favour of the third point of the proposal, please raise your hand higher, a little bit longer.

When you're finished, let me know.

EUGENE LI: Why don't we stand up?

KENNY HUANG: Don't stand up.

For those of you who oppose the third point of the proposal, please raise your hand higher.

So I can conclude we have consensus for the third point of the proposal, so we move to the next one.

TOSHIYUKI HOSAKA: So my fourth point is we should separate discussion on - we should have separate discussion on recycle/marketisation other than this particular proposal for the IPv4 address exhaustion.

KENNY HUANG: Any question regarding the last point of the proposal? Any questions you want to clarify?

IZUMI OKUTANI: Just to clarify - so are you saying that these things should be discussed but just as a separate discussion? It doesn't mean that recycling or marketising is not an issue. Is that correct?

TOSHIYUKI HOSAKA: That is an issue.

IZUMI OKUTANI: Yes but it should be a separate issue. That's your point?

TOSHIYUKI HOSAKA: That's correct. Thank you for your clarification.

KENNY HUANG: Okay. Is that clear? Any questions to the final point of the proposal? Okay. Let's move forward.

For those of you who are in favour of the last point of the proposal please raise your hand higher.

For those of you who oppose the last point of the proposal, please raise your hand higher.

RANDY BUSH: Does it mean that you think the discussion should be together or do you think it shouldn't be discussed?

TOSHIYUKI HOSAKA: Should be discussed...

KENNY HUANG: I can speak loudly. Again, for the last point of the proposal, who opposed the last point of the proposal, please raise your hand higher.

TOSHIYUKI HOSAKA: Opposed.

KENNY HUANG: Against the last point of proposal, raise your hand higher.

GERARD ROSS: Can you use the microphone.

KENNY HUANG: It doesn't work.

JORDI PALET: There's another mic over there.

KENNY HUANG: It's not working.

So I conclude we have consensus for the last point of the proposal.

Okay, right. Thank you.

TOSHIYUKI HOSAKA: So we are moving on to the mailing list to continue discussion.

KENNY HUANG: Thank you, Toshi-san. So we'll move to the next agenda item. That will be resource management Working Group update presented by Shin from JPNIC.

PAUL WILSON: I would suggest since the power keeps flicking off you would disconnect you power supplies, it could well cause a spike and a problem.

JORDI PALET: It seems to be back on again now.


SHIN YAMASAKI: Okay, I guess I can start. Since lots of remote participants interested in the topic so I'm glad the network is back. The reason the working group was made is the last APNIC meeting in Taiwan, is it stated in this action the APNIC resource management system working group was made and I took chair position as a volunteer.

So my name is Shin Yamasaki from JPNIC. Let me to report the result of the resource management system working group update.

So, our working group was made at APNIC 22, as I said, in this SIG I am reporting the result.

Unfortunately, the past participants of the working group were not very many, just four active participants and the 27 mailing list subscribers. The next one is the draft charter. Actually, we have done only No.1 - give recommendation to policy SIG, this SIG.

For the policy proposal by APNIC Secretariat to give e-mail support for the resource registration.

The recommendation is policy SIG should discuss the updated schedule, shown in the next section in my presentation as well as Terry, I believe will propose in the next presentation.

Not only the, that schedule, I like to discuss people with the considerations proposed in the mailing list discussions.

So the proposed schedule from the APNIC Secretariat is as follows. So after six months, then prototype available for the all objects, via non-e-mail method but still, people can do registration via e-mail. After 10 months, then the current system will stop accepting domain objects, via e-mail and only the new method allowed to be used. After 14 months, current system stop accepting Inetnum and start accepting those objects via new method. After 18 months, the production system stops accepting all objects via e-mail and start accepting via the new method.

After posting this schedule, no comments have been made from the working group members in the mailing list.

The next consideration from member side. The first one is the cost and resource impact. APNIC's proposal affects automated e-mail based inhouse system in some LIRs or NIRs. Cost and resource impact for such organisations would be significant so it should be considered.

The second consideration is the securing e-mail. Secure e-mail interface should be considered. The third one is the tools for migration and compatibility. APNIC should consider refers tools for migration for backward compatibility. From the next consideration, those are raised by APNIC Secretariat, basically motivation to propose this proposal.

The first one is the load of spam, and the second one is the maintenance impact of the Whois software and the third one is cost impact for securing secure e-mail development.

After I submit by presentation to the APRICOT website, APNIC Secretariat submitted preliminary results from the membership survey. According to the survey, people more thoughts to the strongly agree to the proposal.

So, I think the working group has been accomplished original purpose but should we keep it open for other topics or closed? Since this is policy proposal, I guess I need to keep this question open and then collect opinions in the working group mailing list.

So any questions or comments?

TOSHIYUKI HOSAKA: Okay, thank you. Next presentation is from Terry Manderson.


TERRY MANDERSON: Okay, introduce an old friend to you, proposal-037 to deprecate e-mail updates for APNIC registry Whois data. The proposal and this is the updated proposal is for the Secretariat to phase up e-mail updates of registry Whois using more suitable methods. The history of the proposal was indeed presented at APNIC 22, it did not reach consensus and the working group was requested to discuss this proposal.

Indeed, the working group formed, the proposal has been updated after discussion and will be presented here.

Just to go back on history here, the basic motivations for this proposal was to firstly improve security so considering confidentiality, availability and integrity which are well-known terms in the IT security arena. I won't go into those now, I will assume that many of you understand these. It certainly lessens to impact of unsolicited commercial e-mail or spam and viruses on the Secretariat operation and the general operation of members updating their data with APNIC.

The other aspect of this is due to UCE many members themselves reject autobdm emails, so the mail robot. They will send in an object to be updated and we reply it has been failed or is successful, the mail is rejected. We are also trying to improve APNIC in a customer-focus view. We are looking at more fully functioned registry services and also privacy of data concerns.

What is it really going to look like? Well, have a web interface, we will have a command line and automation tools going into both the public data of Whois and private data. A command line is something that APNIC has never had before, this is a new thing. It is going to give benefits to the APNIC members.

We established a trial service in September 2006, which was demonstrated in Taiwan which was a demand line for domain objects. It has been available to members for testing since September 2006. That URL will allow you to download these tools and if you need assistance, please e-mail the helpdesk at APNICnet.

We have encrypted transactions, covering confidentiality, offered under a certificate of authorisation, so we have integrity of source, data consistency and integrity using XML. Immediate feedback that something is not covered at the moment, providing a great level of service consistency and provides an automatable interface so it becomes very customer focused and easier to use.

This is the new section after feedback from the working group discussion. It was to change the schedule of implementation. So after EC endorsement, six months' time, tools and prototype environment is available for all object types, in 10 months' time, we would stop accepting domain objects in e-mail and only accept them via the new mechanism, XML/REST. In 14 months' time, stop accepting inetnum, inet6num and aut-num in email. Similarly, 18 months' time stop accepting remaining RPSL objects in e-mail. Shin has covered this.

So essentially, the summary is to seek consensus from the community to phase out e-mail updates of registry and Whois data in favour of more suitable and responsible methods.

TOSHIYUKI HOSAKA: Thank you, Terry. Any questions or comments?

KUSUMBA SRIDHAR: It is not a question, it is a small observation that I have right now. The account I hold with APNIC, you know, you put our e-mail address, especially our tech service on the website and most of the spam crawlers pick it up and keep on sending. Is it not possible when you publish the mail address because it is the reason why my techs don't even bother to check, because when they open it they have thousands of spam. It is difficult to make out mail. If possible, maybe you can publish the e-mail address as an image without e-mailing or a kind of, even if Whois already happens on the APNIC site you probably publish it as an image or thing that can not be bothered by spam. It would help us more because, to date, most of us check the e-mail addresses that we have given to the APNIC database because we know there is regular spam coming in there.

Maybe it is the only solution. I know APNIC website is using CMS and any CMS should have something like this and who Whois results could probably use the capture before the information is actually published. Probably this two or three small things may help.

TERRY MANDERSON: Paul?

PAUL WILSON: I think it is important to clarify something before we seek consensus on this. Maybe just me, maybe I missed something but I think the previous presentation called on the APNIC Secretariat to develop some gateway tools that would allow the e-mail updates to continue, is that understanding correct? I mean, I think it is important to know if we are deprecating one thing here, we need to know what we are being asked to replicate it through a gateway or interface.

TERRY MANDERSON: That wasn't my understanding, no. Perhaps Shin can clarify?

PAUL WILSON: It was definitely something about the Secretariat providing gateway or interface tools. We need to be clear.

SHIN YAMASAKI: Yes, I did just please consider. So it is I'm sure if it is either taken or not. To fulfil the request from the working group, consideration or discussion will be necessary. That is what I thought.

PAUL WILSON: So you are asking us to consider implementing, after the deprecation of e-mail still implementing some kind of e-mail interface?

SHIN YAMASAKI: Not after deprecation, before.

PAUL WILSON: Before. So there actually would be then no loss of that service facility for e-mail updates?

SHIN YAMASAKI: Right. There is other factors so I guess I cannot say, consideration, asking implementation.

PAUL WILSON: I'm not quite sure what that means to the Secretariat, to be honest, so I think we might find ourselves in a strange position if we are deprecating something and then considering implementing something else that replaces it with an unclear answer about whether we are or are not going to actually implement that.

TERRY MANDERSON: My interpretation of the discussion in the RMS working group was that APNIC would create tools to aid in migration, not so much in backward compatibility.

RANDY BUSH: Not what I read on the foils.

TERRY MANDERSON: Maybe we can clarify the foils? Maybe my interpretation is wrong.

RANDY BUSH: I didn't write them, I only look.

TERRY MANDERSON: Shin, can you clarify if it was to provide backwards compatibility or to provide backwards migration?

SHIN YAMASAKI: Either, which APNIC can do, if providing backward compatibility is very difficult for various reasons, I don't intend APNIC to do the work, but as I said, just consideration. So if APNIC can afford that, that would be great. That is my position.

PAUL WILSON: Could I suggest, I still am concerned what it means for the Secretariat. Could I suggest that Terry's question here concerns about phasing up e-mail updates and the registry could really be applied to the primary mechanism, the fundamental mechanism we have for e-mail which relies on e-mail updates at the moment, the question is whether we should change the fundamental mechanism to something other than email.

There may be a second question about whether or not we need to provide a bridging mechanism of some kind which will allow e-mail updates to be handled as an add on, a compatibility mechanism. I think there are two questions here. I need to be clear about what APNIC wants to do.

RANDY BUSH: Randy Bush, IIJ. I think we had the second discussion and straw poll in Taiwan and I believe the consensus was not to drop e-mail. I would note, by the way, if I have read correctly, Shin's next, to his last foil, where he polled the membership, the one membership poll, if I read it correctly, was not whether it should be dropped or used or anything like that but whether the e-mail interface, as it stands, is easy to use. And useful and he got 77% yes. Am I correct?

TERRY MANDERSON: The clarification should be that people were asked whether the interface was easy to use and reliable. They were given a rating out of 1 to 10. That rating received an average of 7.33, which actually constitutes the second-lowest rating for that section.

RANDY BUSH: Did see not what the foil shows.

TERRY MANDERSON: Correct, it is indeed, there needs to be a clarification on that. If you would like to read the archives of the RMS working group you will see the entire e-mail, which was the contents of which was kindly given over by John Ells of KPMG who was the facilitator of that survey. I think taking Paul's note to break this into two questions, do we change the fundamental mechanism of people updating data objects with APNIC or do we, sorry, and/or, do we create some bridging mechanism for some period of time between e-mail and the new mechanism?

PAUL WILSON: If I could say the reason I'm suggesting is that Terry argued effectively the current system based on an e-mail update system has got various problems. We have shown a very specific improvement to that system that can be utilised by any member who wishes to do that that will provide numerous benefits. That is something that we can implement to make part of the fundamental system. Then, we can, as a separate question, if it is still required as it seemed to be in Taiwan we provide continuity of the e-mail update system which will give Terry ongoing headaches, no doubt, because some of the e-mail issues about spam and so forth will not go away, but it will be a separate question. For continuity of service for those who wish to use it. I'm just trying to help you, Mr Chair, perhaps I should leave it there.

TOSHIYUKI HOSAKA: Can you once again summarise your questions?

TERRY MANDERSON: Okay, so now to resummarise with comments from the floor, seeking consensus from the community to phase out e-mail updates of registry Whois data in favour of more suitable and responsible methods for APNIC to have bridging time to allow migration and backward compatibility.

TOSHIYUKI HOSAKA: You are not splitting two?

TERRY MANDERSON: The comments from the floor show fairly directly that splitting probably won't go there completely.

TOSHIYUKI HOSAKA: So then, we have seeking consensus of this proposal. Okay. Those who support this proposal, please raise your hand.

Thank you. Those who are opposed to this proposal, please raise your hand.

Thank you. Those who have no opinion or unsure, please raise your hand.

Thank you. So we may require further discussion.

TERRY MANDERSON: Okay, I'll take it back to the working group and it seems like there were more confused people than people who actually had an opinion. I'll take it back to the working group. Shin, sorry, you don't get out of the working group just yet, it looks like it lives on, thank you.

TOSHIYUKI HOSAKA: Thank you very much, Terry. So next presentation is from Marshall regarding the multicast address assignments. This is actually a policy proposal but submission of the policy proposal text is after the deadline so this is the informational presentation and the decision will be made at the next APNIC meeting in India.

MARSHALL EUBANKS: This should be in September, right?

TOSHIYUKI HOSAKA: Yes.


MARSHALL EUBANKS: Excellent. Good afternoon, everyone. Happy to be here. Here to talk about multicast addresses. And why I think they should be, proposal-047, according to the list, about a proposal about eGLOP and Dave Meyer, he has been instrumental for this too. Multicasting and addressing, for a minute, I'm going to assume what everybody knows multicasting is, it is a technology for sending data across the Internet from one source to many receivers or from many sources to many receivers.

It is, the description is in multicasting you have to stand on your head. In Unicast you usually sent to an IP address, I put it in the two part and send it to you. In multicasting the source sends two multicast class D address, which is an address of the broadcast, let's say it is a broadcast. Receivers request data from that address. The network takes care of the rest. The reason the network has to take care of the rest because the receiver requests data from the address, the receiver has no idea where the source actually is in general.

Multicasting is about 15 years old now, the address assignments have never been turned over to the RIRs for various reasons which we will describe in a bit and I think it has to be changed. In case you need an animation.

The advantage of multicasting is, in Unicasting, if you are going to send one source to three receivers you send out three copies of everything, through the network, in multicasting, you send out one copy and it gets replicated as needed in the network.

Use for multicast, video, is a big one, financial information was the original, so-called killer Ap. Two service models, actually there is more, but for our purposes you only need to worry about these two, ASM and SSM.

ASM is the original service model, the term was coined after SSM described what we were doing already. It is traditional, it has been around for 15 years.

Everything is, is something called a rendezvous point, basically the receivers get everything that is sent to the multicast group address, particular group of addresses, the receiver says I want to receive from the group of address, the receivers get everything from the group address. If more than one source sends then the receivers get more than one source. It would be video conference, for example.

If I pick a multicast group address and you do, we set up something, broadcast or whatever and it is not intended they work together, we have just denial serviced each other. There has been some sort of multicast group assignment. The first thing was something called SDR. It is quite obsolete by now. But basically, SDR was a program you ran on your work station 10 years ago and it would listen to all the multicasts that ran SDR. As long as everybody ran SDR, it would know the distribution and know all the group addresses in use, if you needed a new one it would pick it at random and as long as somebody else didn't pick the same one during the propagation of the network you were fine.

That's not used anymore. The three that are used are, you go to IANA and ask for addresses, there is no other way to describe this, it is not publicised that I know of. You have an unfairness to the system. If you are big, knowledgeable, you know or you just assume I can go to IANA. If you are not, you don't know that, you, this is inevitable. Some people can go to IANA. They tend to be large corporations, small people, individuals or small companies, as far as I know have never done this.

There is something called GLOP, which I will describe. There is the ever popular, if there is no mechanism you make it up and a bunch of people just make it up, just pick addresses at random. The trouble is if they pick addresses at random and hard-coated to an application now you have an application that uses an address at random, you better not use the same address or their denial of servicing you and of course, there is no central registry or anything so how do you know not to use the same address? Let's just hope it doesn't happen.

There is something called Norton Ghost, which probably a lot of you have heard of. Norton Ghost uses two public addresses, not in the private scoping, domain, they just pick them at random. That was not a good idea.

Sort of like two addresses that you can never use because Norton Ghost has them. It is not publicised anywhere. There is source specific multicasting, SSM. It is simpler, has a lot of advantages and one of the reasons why I'm here now instead of, let's say 2000, is because people thought SSM was going to take over the world and SSM was going to do all of this. And I think people didn't really appreciate how slow it is to change things on the Internet. SSM finalised in Adelaide in 2000, the IETF in the Southern Hemisphere and it is still not really deployed. It has been seven years. There is a whole list of new deployments in the video world and what not that are going in that, video IP deployment, set-top boxes, edge switches, edge routers, a lot of stuff going out into the field and into the ground right now, it will be another decade before it is changed.
We are stuck with it.

Multicasting addressing. Quite some time ago, I think this is dead, Okay. They assigned 224 /4 multicasting. You remember ABC, which is now used for Unicast, D for multicast, E for, I don't know, anything. It is experimental.

There is some blocks that have been assigned to things, 232/8 has been assigned to SSM. 233 /8 has been assigned to GLOP, I'll get back to that. 239 /8 has been assigned to the administration, it is like 10 /8 and 100 /16 in 239, it is assumed to be within your domain and you can just pick one.

Then, what addresses have been assigned by IANA? When I go to a lecture, or tutorial or something, I don't want to say it is intended for protocols, all RIP routers, and so on. Ordinary multicasts shouldn't go the IANA route but they do.

For a long time, like I said, there was, this was a sore spot. To solve that there was a temporary thing created called GLOP. It is a pretty interesting idea.

233 was assigned to that, /24, RFC 277. Basically the idea is if you have antonymous system number you get 233 /4, whereas 233 /24, you stick them in, it is /24. There are some calculators on line. GLOP. Well, accept now starting at the beginning of this year, there are 4-byte ASM. Four bytes do not go into two bytes so it will not work anymore. This is now broken. You get away with it for right now because, to my knowledge, not anymore 4-byte ASNs assigned, but they are clearly coming. Of course, all you get is a /24. If you need more, you are stuck.

You don't have an ASN you are stuck. A 4-byte ASN - you are stuck. People, large institutions, they are going to IANA. It is not equipped to do this. I know Dave Meyers is the expert multicasting expert to IANA, they don't have the mechanisms to handle it. They say, "What do we do?" and decide at random, based on what Dave says, they take on the matter and give it out or not.

I counted them, there are 24 approved applications in 276, I don't know if there were more not approved. There may still be some in the pipeline, I'm not entirely sure. There is not good recording keeping. I had to go through the list and count them up but there is a mechanism for getting more multicast address space. /38, extended GLOP but it has never been substantiated.

We did it to RIPE, LACNIC, and do the same speech to all of them I guess and that is why I'm here. Basic idea is very simple. Those of you who know how numbers are assigned, there is a block up here reserved for private RSN numbers. Just like the private Unicast addresses and 239 private multicast addresses you have private ASNs.

You are not supposed to use them on the network, therefore nobody is going to use these for GLOP, therefore they are available. So that is a /14, 200 233.252 /14. That is a fair number that should hold us for a while. What we are proposing from 233.252 /14, this is the address block. The proposal, of course, this is certainly subject to debate and if the routing registers want to do it different it is fine, it seemed like /20 would be a reasonable additional block, but they allocated a default /28, what you will find is a lot of people want a few addresses have a few people who want a lot of addresses, so note multicast isn't subject to CIDR rule. You can assign a /32, that is fine, not the lowest order bit and the highest order bit you can't use, no you can use any address you assign.

I wanted one address, then maybe a /32 would be a useful assignment. The routing registers may differ but it seems reasonable to me. According to the RFC, an applicant must show, as you might have expected, this address can't be specified using other mechanisms. They can't use scoped addresses or GLOP addresses. They have a 4.ASN or need too many addresses and they can't do it with SSM. Of course, it could be the routing register is wanting to put in additional constraints there.

Pros and cons. I don't actually see any con to this, except we have to substantiate it. Somebody has to do some work. I get to fly around the world.

I think the pros are fairly numerous, it is going to facilitate multicast deployment, going to get the deployment out of IANA which is not suited for, not happy with the situation, the current situation is inequitable, because it is not publicised anywhere, which means now you will fill out a form and make your justification. It will give us a 2-by-4 to hit people who do rogue assignments over the head. Right now, I don't have a mechanism to say, "Don't do it." Except you shouldn't do it in general. They could say, "What is the mechanism for doing the address block?" And it is bad, it is not good to have no legitimate way of getting assignments.

The only thing I can see is bad is a bit of work. It doesn't seem like a lot of work to me. But that is one of the reasons I'm here to get feedback, questions or comments.

TOSHIYUKI HOSAKA: Thank you.

GEORGE MICHAELSON: Are you heading to a mic, Leo?

LEO VEGODA: I just wanted to mention that I have got - because of this proposal - a slide in my presentation tomorrow showing the general improvement in service levies on multicast requests handled by the IANA. I have more statistics, if people want more statistics on this and breakdowns, then we can make it available, not a problem, but I just wanted to let you know there is a slide about this in my presentation tomorrow.

TOSHIYUKI HOSAKA: Thank you, that is helpful.

GEORGE MICHAELSON: George Michaelson from APNIC. I'm not talking pros or cons, I'm just trying to get understanding. For conferencing use, temporary transient conferencing use, you are saying there is nothing wrong with the semi random algorithm people are using. You are not saying there is anything wrong?

MARSHALL EUBANKS: That is not a particular problem, there is an address block that was assigned for that,

GEORGE MICHAELSON: It still works but there is a class of people who want to have a persistent address. It is multicasting by protocol but it is analogous to broadcasting. Like TV broadcasting, constant media streaming from an address.

MARSHALL EUBANKS: That is one of them. I know of several entities that are chomping at the bit for this.

GEORGE MICHAELSON: The cascading ifs are if you can't get a GLOP or can't fit inside the SNN, I can't remember three things at once.

MARSHALL EUBANKS: You don't have the right economies, you are not in a good place and financial institutions and Stock Exchanges, my understanding is there is some Stock Exchanges who want to use multicasting, they use it right now extensively inside the Stock Exchange, NASDAQ and so on, they like to push the financial data out and they want a permanent address.

GEORGE MICHAELSON: It is a large community, it is not just TV companies, it is 150 000 stock brokers.

MARSHALL EUBANKS: Exactly.

TOSHIYUKI HOSAKA: One more person to speak.

JORDI PALET: I have two small questions. Either I misunderstand or I doubt that IANA is locating without an IFC to locate addresses when somebody comes from them and I don't see there is anything bad from that.

MARSHALL EUBANKS: I don't think there is, Sir.

JORDI PALET: It should be one, otherwise IANA could not, I guess.

MARSHALL EUBANKS: There is the multicast.

LEO VEGODA: Jordi, just to clarify, there is an RFC, the administrative procedures or whatever, I can't remember the number. What happens is someone sends in a request to us through the form on the web page, we go and put it into the ticketing system and send it to the designated expert, ISG give us a designated expert and then we assign addresses, or not, as per the designated expert. We don't actually make any judgments on the quality of the request ourselves. We just check that it has got all the fields filled in and send it on. When it comes back, if it is yes, then we will have been told where to assign for them. We go and update the registry and inform the requester, and that is it, really. Pretty much like all the other IETF stuff.

JORDI PALET: Anything wrong with that pursuit. I don't see the reason for doing that if it is working. You say small companies cannot do it. There should be no difference in a request coming from a smaller company or a big company. Just an open request. I'm not forming an opinion, just saying it is not necessary. On the other hand, if IANA need to locate to /20, I think it will need a global policy or I'm wrong?

LEO VEGODA: I don't know, I would take advice on that from someone else.

JORDI PALET: In that case, there will be a need for a global policy to do that?

MARSHALL EUBANKS: You mean between the RIRs?

JORDI PALET: And for the text to be the same. It can take long unless you reach consensus quickly, just so you know it.

MARSHALL EUBANKS: That is what we are expecting.

JORDI PALET: You need to get the consensus in the same text and then written.

MARSHALL EUBANKS: Yes.

TOSHIYUKI HOSAKA: Thank you. Since we are running out of time, we have run out of time. So thank you very much, please come back.

MARSHALL EUBANKS: My pleasure.

TOSHIYUKI HOSAKA: If you can. Okay. Finally we get to the final presentation from Geoff Huston.


GEOFF HUSTON: You know, I've done these kinds of presentations so many times that I'm wondering if you just want to look at the slides, ask any questions and I'll let you all go.

MARSHALL EUBANKS: Let's see the slides.

GEOFF HUSTON: Okay. That's the slide.

Okay, I'll run through this really quickly. I've done these reports pretty often now. I think most of you have seen them before, so keep reading your mail.

It's all about a robust framework for validation of assertions relating to IP addresses and trying to make it easy to see if someone is lying about address space, one way or the other.

The kind of usage we envisage for this is wherever you talk about addresses in a public way, like making entries in Internet Routing Registries. If we ever get into secure BGP, which is moving along there, you would need routing origination, or even just very simple message between you and your upstream - "Please route this address" - signing it digitally with a signature that allows people to see that, yes, you own this resource, that address is in play and you are the current right-of-use controller of that address.

The work we're doing uses standard available technologies and resources, so allocation database and a whole bunch of public/private key technologies, X.509 technologies and so forth.

Our overall objective - to complement the existing information we publish, to complement what we publish in terms of existing resource allocations that match the existing certificate, which in APNIC's case says we really did it, here's a certificate and the public key of the recipient. And this allows you to make signed assertions about addresses and the use.

Very busy slide - we've been working, we're very busy. As you've seen from the presentations as we've moved on here, a number of things have been done. Resource certificate profile, repositories have been tested. You can read as well as I can. And we're still doing testing and further development.

Where are we trying to do now for this at this particular junction, first quarter of 2007, we'd like this to be automated as much as possible to mirror this. So certificates don't do something new, they simply follow what we already do. Tool sets to allow various Internet registries, including NIRs, to manage certificate issuance if they want and tool sets to also allow, allow an option for you to say, "Look, I don't want to run this stuff. I'm an ISP but can someone do this for me? Can I outsource this operation?" What kind of tools are required to do that?

We're doing lots of PowerPoint, lots of colours. Aren't we good? And the kinds of things we expect out of that - tools that we're working on in automated certificate issuance, client-side tools and looking at the considerations we have to cope with, including splits, mergers and transfers that happen right now when companies start to move their resources around and things change across memberships already.

Work continues. Work now continues across a number of RIRs. ARIN is supporting some work. RIPE is working on it, as well as APNIC and the steps we're looking at in terms of technology as distinct from policy are areas around development of the engine, end entity certificates and so on.

If you're interested in the work as it goes on and this is very much not a formal reporting mechanism, these are the working pages from the various folk who are working on it, have a look there and you will see where we are, what we're doing and you will see where we are as we beaver away at this. Five minutes.

Any questions or are we just there? We're just there. It's party time, right?

Thank you.

TOSHIYUKI HOSAKA: Thank you very much, Geoff.

So we have covered all the presentations. And I would like to say something at the end of this Policy SIG. Since Kenny is stepping down from his chair position, and he has contributed a lot to the Policy SIG for many years actually, so can we have a big hand, your big hands to Kenny, please?

APPLAUSE

KENNY HUANG: Thank you.

TOSHIYUKI HOSAKA: Thank you. This concludes our Policy SIG at APNIC 23. Thank you very much.

APPLAUSE

(End of session)