Transcript - Policy SIG Session 1 (PDP Discussion: Wednesday 11:00 - 12:30)

Andy Linton: While people are finding their seat, I have a couple of housekeeping announcements, the usual drill about mobile phones to silent and you can buy us all a drink if your phone goes off. I think that's probably the best reminder to people.

The lightning talks are still open, so there are still some -- if people are interested in doing those, they will be on tomorrow at 9.00 to 10.30, I think, in Island, whichever one of the ballrooms Island is.

SSID and password, APRICOT, APRICOT 464XLATs, B6 only. Please use the APRICOT B one only as a back-up, and the password for these is APRICOT 2013.

Just the usual rule, usual stuff about when we get to any questions or comments at the microphone, please give us your name and affiliation. Our two excellent scribes at the front need to have that so they can put it on the transcript so our remote participants have some idea what's happening.

There's a reminder here about the social event, that the tickets for that are sort of limited and on a first-come-first-serve basis, but please don't rush off now to try and get one, you can do it at the end of the session. That's the housekeeping.

Our introduction, Policy SIG agenda. The session this morning is the SIG administration stuff, what we're doing right now. Then we're going to have an implementation report from Adam and we're also going to have something from Tomohiro-san. We're also going to have a discussion paper or an information paper from George Michaelson about creation of route objects in the database and Whois, and a discussion on policy options for encouraging membership of an NIR. That will be our session this morning.

Tomorrow, our first session will be an update on documentation from Adam. Dean Pemberton has an informational session on the role of APNIC Secretariat and the PDP and then Masato has been looking at some of the items that are in the PDP and the SIG Policy guidelines. There's just some questions for clarification and I also have some comments at the end of that as well.

Then tomorrow afternoon we're going to have our discussion on the actual proposals. We have two, prop-105 and prop-106 and we'll bring those up tomorrow afternoon.

We have a couple of action items, there's three here. There was pol-34-01 and 34-02 which were the two policies that went through last time. We were pending approval of the remaining stage of that process. APNIC Secretariat is going to implement that proposal and it was implemented on 18 February.

Similarly for 34-02, removing multihoming requirement for IPv6 portable assignments. Adam is going to give us a brief report on the implementation of that.

Then the global policy proposal that went through to IANA some time ago is still in progress and Tomohiro is going to tell us about that and he's going to come and do that right now.

Tomohiro Fukisaki: As ASO member, I introduce the current status of global policy briefly.

This global policy for post-exhaustion IPv4 allocation mechanism is discussed in APNIC region as prop-097 and globally it is known as GPP-IPv4-2011. This global policy discussed in the region and reached consensus and SOC asked ICANN board to ratify this global policy.

ICANN board ratified this global policy in May last year. After ratification, ICANN have the discussion with the RIR engineering team and ICANN decided to conduct public comment about this global policy.

This public comment say need to include how to manage returned data space and this included how the details of the policy should be published and how IANA should select which address to allocate to which region.

The report for this public comment can be found from this URL and now the implementation is ongoing, and after this global policy is activated, all regions will receive about /10 IPv4 address. That's all.

Andy Linton: Thanks for that. I believe that Elise Gerich in the reports she gave yesterday sort of said -- certainly I had a conversation with her, the last piece of this is sort of work in progress and we'll hear some more about that in due course.

I have already done the little bit of housekeeping which says switch your phones off. This next part always feels like that part where you are sitting on the plane, "We realise you're frequent flyers and you have heard all this before, but here is the safety announcement," and so on.

Many of you will have heard the information about the Policy SIG charter and so on, but I will go through it, because for some people in the room, this is perhaps their first time or they're not that familiar with it.

Our charter and our job here is to develop policies and procedures relating to the management and use of Internet address space and resources so it's address pace and AS numbers and associated stuff.

We have a couple of mailing lists where that work proceeds. There's one SIG Policy, which is the one that many or most of you will be members of, and it's where the discussions happen and then the Chairs, myself and Masato and Skeeve Stevens -- who unfortunately can't be here for this meeting in Singapore -- we have our discussions, along with the Secretariat who support us so well.

When we have a proposal come in front of us, there are a number of steps to implementation. We have a proposal submission which comes to the Chairs and sometimes there's a little bit of discussion with the author about, "Have you thought about this and have you got all the pieces in place?"

It then goes to the mailing list for four weeks before the meeting, or at least four weeks before the meeting. We then strive to seek consensus at the Policy SIG meeting. We come and we talk about the proposals and people have their say on whether they think it's a good idea or a bad idea and so on.

One of our tasks -- our principal task there as the Chairs is to gauge that consensus process and see if people actually agree that this is a good idea or not, and then we go forward.

If a proposal reaches consensus at the Policy SIG meeting, then we take it to the AMM the next day and say, "Here is what we talked about, here is what we discussed, and we seek the permission of the member meeting to proceed with this." They go for consensus there.

We then have a further comment period on the mailing list, so that people who haven't been able to come to the open policy meeting can actually take part in that final discussion, and then at the end of that whole period the Chairs will actually decide whether the discussion that went on on the mailing list before the meeting, the discussion and sort of consensus seeking at the meeting and the final part on the mailing list, actually means that everybody is happy and content with the decision. At that point, we pass that to the EC, the Executive Council, for endorsement, and then it goes back to the Secretariat, who will look and say, "Yes, that's okay, but there's some" -- we get a draft put together and the draft goes forward. They do the drafting for us and then we implement.

This idea of consensus, I always think it's useful for us to think just a little bit about this consensus. We don't have a voting system here. We don't put our hands up and say, "51 per cent of people say this is a good idea, 49 per cent don't, therefore it's passing." We seek to make sure that everyone is comfortable, if not happy, at least content to let the thing go forward. When we put hands up during the meetings, it's not a vote, it's a way of the Chairs looking to see whether people feel comfortable. It's broadly gauging opinion.

We will take opinions that come in via Jabber, as part of that. There are some example definitions from a document, the Tao of the IETF, which is sort of where we inherit this process from. A very large majority of those who care must agree. Where people sit and don't put their hand up, then the only option I have and the only option Masato and Skeeve, when he's here, have, is to think you don't care. One thing to do is make sure your hand goes up.

Strongly held objections: we should debate those until most people are satisfied that these objections are wrong. That means that someone who strongly objects but the majority of people in the room think their objection isn't reasonable or whatever, can't actually block the process completely. So that's our loose definition. It's sort of not very precise, but it's the one that we have and that's the way we work and that's our job to help you reach a decision.

Just again I'll echo this. Minor objections are where we have some problems for some members of the group. Major objections are where major problems will occur for parts of the community.

Sometimes when people bring a proposal, they think about the situation that they're in, but they haven't actually thought through the implications for other people, and this is to make sure we don't pass policy that works really well for some people and breaks things for other people.

Our job here is to work together to resolve any issues.

There are some references. There's the APNIC PDP, the policy development process; there's the SIG guidelines; there's stuff in the archive you can go back and look at previous stuff; and if you want to subscribe to the list, of course you can do that.

That's my boilerplates. This is the bit where I put the life jacket on and say, "The emergency exits are over here." We have to do this, we cover that piece off in every session.

Our next item on the agenda is Adam is going to give us an implementation report. Those two policy proposals that I covered in the action items, Adam is going to give us some information about those.

Adam Gosling: Thanks very much, Andy.

Good morning, everyone. The purpose of this presentation is just -- it's a new presentation that we're doing to the Policy SIG and the intention is pretty much to close the loop on the end of the policy development process, I guess. In the past we come to a consensus and it goes to the EC and then it's implemented and a notice might go up on the website, but we don't talk about the policy that we did last time so much. So this is just very quickly -- and a lot of the information is on there.

At APNIC 34 there were two proposals that reached consensus. Removing multihoming requirement for IPv6 portable assignments: this proposal said, for IPv6, some people may want to use provider independent, basically, assignments and not be multihomed and that that requirement should be taken out as an explicit requirement. That's still in there if you are multihomed, then that's still a valid reason to get an assignment in IPv6, but it's not a requirement.

The other policy proposal was prop-104, which was clarifying demonstrated needs requirement in IPv4 transfer policy. The purpose of this proposal was to make it absolutely explicit in the policy what the needs assessment period was. It wasn't in the policy and it was based on IPv4 policy rather than transfer policy. The Secretariat was using 12 months. This has now been formalized to be 24 months.

The next couple of slides are really just what's on the website, on the status page for each of the policy proposals, so I'm not going to go through them. They document the history of the proposal and provide links to kind of verify that this is what happened. I guess the interesting thing is that it was implemented on 18 February.

Again, same slide, different proposal, it was implemented on 18 February.

Once those proposals were passed to the Secretariat for implementation, there's a couple of things that we need to do. One is to change the documents; the other is to change the procedures and possibly change software systems, other systems. Part of that is to go through the editorial comment period which is controlled by the editorial policy. Those draft policy documents, the changes are made, they are posted to the website for a period of a month.

The multihoming requirement was drafted into policy using two different possibilities. One is the actual IPv6 address policy document, but we put a little bit more detail in the guidelines. So, rather than bulking up the policy, the criteria in the address policy itself, we put it in the guidelines. These are both numbered documents, both need to go through the editorial process.

With prop-104, that was a slightly easier change, just to insert the 24 months into the one policy.

As I say, these are links for the presentation. If you want to go through it and see those new documents, they're there.

That was the documentation part of it. The other is the actual implementation into the operation systems at APNIC. Prop-101 required a couple of changes to the IPv6 application form and, as I say, we retained multihoming as an option, so it wasn't removed from the form. We didn't want to cause confusion, so that people thought this is no longer a way to justify your need. It's kind of an additional option.

As you can see at the bottom there, provider independent networks, so if you have a good justification for having a provider independent network, then you can just apply on that basis.

The transfer document, there's a couple of changes to that. We have a pre-approval process and pre-approval online form for people who are intending to transfer or to be the recipient of a transfer and they can demonstrate their need before they find the addresses. That form was updated and the Secretariat took the decision in changing that policy, that the pre-approval used to last for 12 months, so if you got your pre-approval, then that was valid for 12 months. You had 12 months to find your addresses, as it were. We have changed that to 24 months, in line with the change in the demonstrated need.

Again, here is how it looks in real life. Top right-hand corner, you can now put something in the 24 month prediction. That's about it. Thanks very much.

Andy Linton: Thanks for that, Adam. Any questions about that?

I have a question that maybe I can ask. This was implemented on 18 February, so just over a week ago. So we don't really have any sort of experience of --

Adam Gosling: It's very early days.

Andy Linton: -- what the implication of this is. Sometimes policies go through much quicker and we have three months experience of what's happened.

Would it be possible that next time around, we have a brief look back at this and say, "Here is what happened because of this"?

Adam Gosling: Sure, yes.

Andy Linton: I think it's useful for us to understand if we make policy, that's not the end of it, it has an implication on what's happened.

Adam Gosling: Absolutely.

Andy Linton: Next time you have a report. Obviously, with a week, you can't tell us very much.

Adam Gosling: No. We would be happy to do that. I will report on some data or something from these, how much they are being used and some interpretation. That's fine.

Andy Linton: Thank you. Thanks, Adam, for that.

Our next piece is an informational session. George Michaelson is going to talk to us about creation of route objects in the APNIC Whois. This isn't a question of policy change or anything like that, but this is sort of an implication of some of the things that are going on inside there. But George can explain better than I can, I think.

George Michaelson: Thank you, Andy.

Hello, everyone. Thanks for the opportunity to talk to you. I want to repeat what Andy just said: this is not a policy related activity, so we are not looking for invocation of the policy process or consensus process, although I would actually welcome a sense from the SIG chair of the reaction of the room. It's more that we felt there was a situation in operations and information management emerging and, rather than just making changes, we felt it would be nice to talk with you, as the resource holders and the people who care about the information management, to understand how you felt about this situation.

This is the template of an RPSL route object. This is the information that typically has to be registered by an address holder if they want to inform the rest of the global Internet about the existence of their prefix behind an origin AS in order to have route filters lifted.

If you look at this template, you're going to see that there's really only a small set of data which is mandatory, that you have to put in this object if you want to put this in Whois. There's the three things at the top: the route field is the prefix that you are attempting to announce; the description is a descriptive field; and the origin is the AS number that you are giving permission to originate the prefix. The three down the bottom, "mnt-by", "changed" and "source". They are more artifacts of the process management in Whois, the information management rules that make it trust that the update is acceptable.

If you imagine a simple case where you don't use any of the optional fields, there's really only two pieces of information that directly relate to the prefix and the AS and they are the route and the origin.

There's a more complex use of this template, which is to specify a whole bunch of other optional components to do with exports and aggregation of AS parts. But we have gone and looked in our data and, out of around 80,000 route objects, there are only two of them that are using any of those features.

We also looked in JPNIC's routing information and we looked in RADb from Merit and out of 450,000 objects, there are only 16 that are using this more complicated form of information management, the overwhelming majority of route objects are really just a statement: please originate this prefix with this origin AS or for the receiving side: please adjust your filters to permit origination of this prefix from this origin AS.

This, in a totally different notation, is the RPKI ROA object, the basic cryptographically signed statement that is being used in RPKI to say, "Here are the prefixes which I would like to originate from this origin AS." Although it's in a slightly different notation, it only has one extra piece of information. It has this field which is the AS identifier and it has a field which is a list of prefixes rather than just a prefix and it has a field that allows you to specify a maximum length. Apart from that, it's really performing the same job, it's providing the same kind of information.

We come to this observation that route objects in their simple use really just specify a relationship between an origin AS and a prefix. There is a more complicated use. It is not practically being deployed. The simple use is very, very similar to the ROA, but then this thing emerges that the ROA, the permission to make a ROA, is solely in the hands of the prefix holder, the only person who provides any authentication is the prefix holder. But in the route object, if the AS is not the same as the prefix holder in terms of its maintenance, both signatures, both identifiers are required to submit this object.

Previously, before we had final /8, the world seemed to be that the people who acquired address resources were ISPs and LIRs that were using the address and asserting it behind their own AS number. But we have entered a situation where under final /8, providers who have AS and who have an investment in routing can't acquire more address.

So a customer that wishes to host a secure website or content provision or route a complex network on public addresses is told, "Apply for some address under final /8 and we will announce this for you." But that immediately creates the situation that the address holder is not the same maintainer as the AS holder of the origin AS which means that to create a route object, two people have to be engaged in the process.

Unfortunately, the processes of commissioning a new customer and bringing them on line appear to be somewhat divorced from the processes of information management inside the ISP.

We have observed that there is an increasing volume, perhaps three or four a month, but rising, of address holders who are coming to the Hostmaster section and saying, "I can't get the origin AS to countersign my route object."

While this means that their route is accepted within local horizons close to where it's being announced, because of various factors to do with exchanging and default, there are places in the global Internet that rely on route filters specified from the route object that simply won't accept their address. APNIC Hostmaster are then having to engage in a process of contacting the AS holder, seeking their permission to create the object, possibly re-communicating because staff have moved on, and they have to re-establish permission in Whois, and this adds a huge amount of delay, which means injection of new addressing into global routing is not happening efficiently.

We'd like to try and simplify that process. We think, having observed that there is this similarity between the ROA object that only needs the prefix permission and the route object in terms of their information, maybe we could change this process.

We wanted to talk to you to see how you would feel, as the information holders, the people that have the responsibility of maintaining Whois data, if we were to investigate a process that said, "We are prepared to create these objects without the AS holder's engagement."

We could even investigate the possibility of making this fully automated. We have had the idea that if the RPKI system is the future of a strong cryptographic statement of routing intent and if we have a very high trust in the processes that create a ROA object, maybe we could automatically inject a route object into the Internet Routing Registry.

It would obviously be clearly stated, "This is an automatic object, this has been created as a result of the creation of a ROA." But it would mean that there was an alignment of two competing systems, and during that time that a large number of people are relying on route registries to define their filter logic, it would mean that, as people create ROA, they are able to see the same filters being adjusted based on the IRR.

So we're interested whether people would like that kind of activity done for them.

But we are also interested in this other question: could we modify our processes to respect ownership of routing information vesting with the prefix holder and not require the permission of the AS holder in making these objects?

The intention in coming here was to present this idea to you and see if there's an interest in discussion in the room, and then possibly also take this to the policy list to give people in the wider community a chance to discuss.

But I stress it's not a policy process. It's about an operational reality and a chance for us to reconnect with you and understand how you feel as address holders and AS holders about this kind of process.

Andy Linton: Thanks for that, George. Any questions or comments from the room?

If you can tell us who you are and affiliation, for the scribes.

Aaron Hughes (6connect and ARIN BoT): Do you have any feedback from people who are actually creating ROAs on why they wouldn't just use their existing object creation process for creating the entry?

George Michaelson: No, but that's an interesting question, and maybe part of talking with people would be actually going out and soliciting that and finding out.

I observe that the number of people who have made ROA is really very disjoint from people who are interacting in IRR. So it's possible that this has moved into a situation where it's two different communities of engagement in routing.

Aaron Hughes (6connect and ARIN BoT): Thank you. The only other feedback I would have is that if we're going to go down a path of an automatic object creation based on ROA, to make sure to address when it expires, to remove that object.

George Michaelson: Yes, I think that's a very good question, and it raises the question how long is it acceptable to leave something in an IRR after you see a ROA potentially go stale? It invokes more process overheads that have to be thought about. It's a good point.

Kurt Erik Lindqvist (Netnod): Unfortunately, I missed the beginning, because I had to take a call. Somewhere in the middle you said something about that you will take the Whois data away and just rely on RPKI?

George Michaelson: No. I have a sense that there is a community who believe secure routing will be defined almost exclusively in mechanisms like RPKI, but the observation is that IRR performs a dual function. It both specifies, "I am giving active permission for these routes to be seen" and it also is used to say, "I like to configure my filter set and my router behaviour and my peering and my communities and all these other transitive properties that are not in RPKI," and in no sense is that going to go away.

Kurt Erik Lindqvist (Netnod): Good. Because that was the point I was going to make, that it might be other data for this. For that purpose, I think that copying the ROA is probably good enough. I mean, I don't see a ...

George Michaelson: Thank you.

Izumi Okutani (JPNIC): I agree with George's observation that, at least in the Japanese community, a majority of the routing operators do use IRR, so we need good collaboration with the information in IRR and what's going to be registered as ROA.

Since I'm not an operator myself, I can't give you immediate feedback on what would be good, but I would certainly be interested to share your presentation within our operational community. Some of the people actually are here at the meeting and I would be interested in continuing to explore this idea in discussions.

George Michaelson: To give you some background, this is actually an operational issue that arose inside the Hostmaster group in APNIC, and George Kuo came to me to discuss if there was anything that we could do. A small group of people in APNIC caucus -- Geoff Huston was involved, Phil Smith was involved, Adam was involved, Sanjaya was involved -- and we kind of decided, this is an opportunity to reconnect and discuss.

So, although there is a problem and it is a continuing problem, I have gained a sense from George Kuo that he isn't looking for a rapid fix and, rather than doing something quickly that potentially has issues, he'd really like to see a discussion.

If you're saying you would like to go and caucus with the Japanese routing community and people interested in IRR in Japan, I think that would be fine, and this could potentially resurface on the list or it could come up in the next meeting.

We don't have to take an urgent action here. It's more a sense, how do you feel about what we're thinking of doing, and if we explored automatic objects, would that interest you?

We might be in the same place.

Izumi Okutani (JPNIC): Okay, great. I'll keep you updated about our discussions in Japan.

George Michaelson: Thank you.

Masato Yamanishi: There is a question on chatroom. Nick on chat says, if you check only prefix but not AS number when you create route object, how you will secure YouTube? You understand?

George Michaelson: Yes. I think it has to be understood that the ability of any of these mechanisms to prevent incidents like YouTube probably doesn't vest with only one technique. A ROA, because it has the max length, is able to say, "I do not permit more specifics." So a ROA is able to say, "Here is the origin AS that I am accepting from my prefix and I will not permit more specifics to exist." A route object can't exclude the more specifics. It can provide for some of the behaviour, but I'm not convinced route objects alone could fix the YouTube incident.

I'm not trying to say they will always fix all problems in routing; it's more an observation that filters that exist relate to prefixes and their origin. The prefix holder appears to be the emerging person who authorizes their statements of origination, and the Whois, in requiring the AS to be included, appears to have gone to a step of information consistency in Whois that doesn't reflect behaviour in routing.

But I agree, it may not necessarily solve the YouTube problem.

Geoff Huston (APNIC): Yes, it would.

George Michaelson: That's a good thing. I'm not a routing expert, by the way, which will be immediately clear.

Geoff Huston (APNIC): The reason why is that the YouTube incident was basically the unauthorised use of a prefix.

George Michaelson: Not the AS, it was the prefix that was unauthorised.

Geoff Huston (APNIC): Correct. So it's not the AS. So the issue is here: do you need, strictly -- and there's two parts to what George was saying here. One is: do you need the permission or authorization of an autonomous system holder to talk about the origination of a prefix? In the ROA model, the answer is no. In the traditional route registry model, the answer was yes. The issue was why did you need the permission of the AS holder? It doesn't actually matter.

When you create these automatic objects without the explicit permission of the AS holder, are you doing anything bad? My view would be no, you're not. And the previous routing incidents wouldn't become possible by having that lack of permission. So, as far as I can see, this proposal, this non-proposal --

George Michaelson: Thank you.

Geoff Huston (APNIC): -- doesn't alter the underlying permissions in the route registry.

The other question which you raise, which is equally interesting, is: if you tie route registry objects to some other thing, so you get automatic appearance and automatic disappearance, again, have we gone down a path that somehow admits other problems?

As far as I can see, again, it seems pretty innocuous. The ROAs and the route objects actually have a very similar semantic in routing.

George Michaelson: Thanks, Geoff.

Andy Linton: Anybody else got anything?

George, I have a question for you, just in some of the mechanics of this. You talked about the automatic -- if you create a ROA, then if you went ahead with the process like this, that the route object would get created automatically, would that be an opt-in or an opt-out process as well?

George Michaelson: We really hadn't thought about that. It's certainly possible. It could be a check box in your portal into MyAPNIC. If you're using our facilities, do you want to be included in automatic creation of matching objects? We can do that. This is early stage stuff.

Andy Linton: Sure. These are the sort of questions that will probably come up.

George Michaelson: Where we have gone is this thing has two halves. There is the "can we make the route object without the AS holder's permission," and that has a strand that says, yes, but maybe we should inform the AS holder, maybe we should give them a mail to say, "You may like to know that this route object now references your origin AS." But that's one strand.

The other strand is make them automatically, if they exist as ROA, and it has that quality of how quickly after a ROA do you make -- how quickly after a ROA goes stale do you withdraw and do people always get it or do you opt in? But those are the right kinds of questions.

Andy Linton: I think the other one that comes to me would be, if that happens and you automatically create the route object, does that preclude you from going to the route object and doing a manual override on it?

George Michaelson: No, I think probably it would be okay to do that. I had this sort of shower conversation with myself about whether you could have override in the system if you have permission to edit in the system. It does get to a rather odd place, because the maintainer in the automatic ones would probably be an APNIC special maintainer; so where would your permissions be to delete and modify that by hand has to be thought about. But I am sure we can come up with some sensible process to deal with it.

Andy Linton: I don't want to get into a lot of detail.

George Michaelson: Andy, would your sense as a kind of consensus building person be that I have a soft permit to pursue this maybe on the policy list and see it discussed at future meetings?

Andy Linton: I think the question for the room here is -- well, George has asked the question. Does it make sense to take this a little bit further and explore it and do people think that's a reasonable thing for us to do? Yes.

So is there anybody who thinks this would be a terrible disaster if we proceeded and looked at this and looked at it further? Is this a reasonable thing to do? Should we not do this? Should we not look at this further, is the question.

I'm sensing, George, you can take it further.

George Michaelson: Thank you very much. I'll try to get something sent to the policy list to inform the wider community and we'll give this some traction to put forward at the next meeting. Thank you.

APPLAUSE

Andy Linton: Thank you, George, for that.

Our final session here informational policy options for encouraging membership of NIR. Sanjeev Gupta is going to talk about that.

This is one of those areas where you could look at this and some people -- when we talked about this, would this be discussed at the NIR, but it also has some implications for stuff that the Policy SIG might get involved in. Again, this isn't a proposal, this is just Sanjeev wants to put some ideas in front of people and see whether this is worth exploring further.

Sanjeev Gupta: Sorry, this is my first physical APRICOT and I'm also having my first sore throat of the year which happened to coincide.

First, my name is Sanjeev and currently I run a small datacentre operation and I have a lot of free time and -- it's a very small operation. I have a lot of free time, so we sit around and discuss everything, from why the US should have a mask space program and why IPv7 would be better than v6, if only somebody had bothered to ask us.

About a year ago, some of my colleagues who work in academia at the University Science Malaysia, in Penang, were discussing Internet policy and they asked for assistance from the technical team. So my guys sort of started talking to them and one of the issues was that they were seeing a situation where, from a purely policy point of view, which I don't have a background in, they were seeing a situation where control of the Internet, in their terms, would be national governments would ask for greater control and one of the issues was, as we have more NIRs, what would be the implication?

We put together some slides on this, we talked about it for some time. There are no conclusions in this. This is something that is for maybe new NIRs to consider and APNIC to consider. There are absolutely no conclusions or recommendations in this process.

You all know the standard picture. It's been used for the last 15, 16 years. The standard picture of how the Internet is structured is a very nice clean picture, but it's quite messy in real life, especially with a lot of end users and LIRs directly under the RIRs.

The structure of this has not actually been well used, but in recent years, as the NIRs are being formed, APNIC has NIRs; at some point, in Latin America and Africa, we will have NIRs as well, which are more active and growing. So the entire T structure will populate over time. Currently it's much flatter and messier.

Especially in APNIC we see a case -- when I say "we", I refer to my team, not affiliated -- we see a case where there will be more requests from national organizations to form NIRs.

For a number of reasons. The first is, as IP growth occurs, and we have been hearing about this for many years, but as we move to v6 and we finally have a boom in IP growth, we will have networks and countries which currently cannot run an NIR or do not wish to run an NIR because of size, will be running very large IPv6 networks and the regulators there might ask, "Why don't we run this in-house?"

The second issue is that -- and this is the sense especially in south-east Asia, talking to people -- there is some resistance in people who are not aware of APNIC's role. I keep coming across people telling me, "APNIC is Australian, right? Why are they telling us what to do?" You just have to point out they happen to be headquartered in Brisbane. There's nothing particularly Australian about APNIC. This is one issue that people have pointed out to me as I have talked to them.

The last thing is that repeatedly, governments control the ITU telephone numbering system, why should they not control IP numbering within their own countries? Without naming names, practically every ASEAN country -- I have talked to at least one regulator in each of the 10 ASEAN countries who has mentioned this. I'm not saying this is a popular view, but it is a common view that the same way we manage -- "we", as in our country -- our telephone numbering plan, we should be managing our IP address plan and not have it fragmented and out of control.

All of this I think at some point we will see more NIRs occurring.

If we see more NIRs occurring, one of the things that's going to happen is competitions. Currently, APNIC and ARIN do not compete. It is trivial to game the system if APNIC does not give me a /22 or a /21, to apply for ARIN. All I need is a post office box address in the US and lie enough. It's not really difficult. I know end user organizations which have applied to RIPE, got rejected, applied to ARIN, got an IP address system. They got an IP address space. It's an honour based system.

The reverse side of it is that APNIC and ARIN and RIPE are not competing for members. It is not a situation where the RIRs meet and say, "Hey, we got a 17 per cent growth and you got only a 4 per cent growth, so there!" But as we see more NIRs form, it is feasible that the NIRs themselves may be under pressure to increase growth and attract memberships, either by new memberships which is a good thing, or in a zero sum game where they will try to attract APNIC members to come over and re-affiliate with the NIR.

Specifically, please concentrate on the second line first. There is no "should" in this statement. Assuming that an NIR is formed, and assuming that an NIR wishes to measure its success by number of members, how can it convince APNIC members to re-affiliate with it, with the NIR? I'm not saying this is a good thing. I'm not saying this is going to happen. I'm just exploring, suppose it wanted to do this, how would it do this? How could it do it?

Although this has been bouncing around for over a year, it has received very limited review from a number of government regulators I have talked to, number of people at the Internet Society, but it has not had peer review properly.

So we see four simple options, that we can see; there are probably many more. These are not ranked in any particular order. The options are that NIR could just follow APNIC policies and let LIRs or end user organizations decide which to do. You could have a different set of policies which are more attractive and convince APNIC members that, "Hey, I'm based in Singapore, if I switch to the SG NIR, which doesn't exist yet, but if I was to switch to that, it's more attractive, because they don't ask me all the questions or they already have a route object automatically created for me or whatever."

There could be a lower pricing, NIRs could compete on lower pricing.

Or there could be the final district option where I get told by my local telco regulator, that if you wish to be an ISP in this territory, you must be a member of the local NIR. That option has been mentioned to me by a number of staff in regulatory organizations.

Okay, so we just go through the form. The first is let LIRs use the APNIC's policy on NIR operational policies require an NIR to fully implement APNIC policies for address management. That is a critical thing, because that's the only reason I really go to APNIC, for addresses.

An NIR can compete by saying, "We'll lower your transactions costs. I'm in your time zone. I speak your language. You don't have to pay in Australian dollars and not know what the final bill will be." This is one way. But apart from that, the policies we implement will be the same as what APNIC is implementing.

I do not see this as sufficient to encourage current APNIC members to switch over, and larger members, typically larger ISPs, will not. They can speak different languages, they are used to different time zones, they work in US dollars or multiple currencies anyway. But it would encourage new members who are currently not APNIC members to join the NIR, which is a good thing.

You could set up a set of different policies. There is a little leeway here in how you would stay honest to the letter of the APNIC requirements for NIRs that you should have similar policies, but you could still have some leeway. Then this would encourage members to trade play-offs against each other.

Remember, as I pointed out, I know it's a very common thing for people to try to get address allocation especially in the last year from multiple RIRs. It was extremely -- not the large ISPs, but the smaller ones did it. We see a situation where I would go to the Viet Nam NIC and the Cambodia NIC -- the Viet Nam NIR and the Cambodia NIR and the Laos NIR and the Thailand NIR and basically play them all off against each other and see, "Hmm, this is the nicest guy and this guy is willing to give me an allocation which is much larger than what I need now", for example. These are all made up examples, but it's possible that LIRs and end users would play off NIRs. It doesn't cost much to set up one postbox address in a country and claim that's a new company, a new legal entity.

As I said, the current system is very much honour based. When I write to the Hostmaster, it's very much. He asks, "Are you sure you will use this?" I say, "Yes." It works. I do not see NIRs as having the resources to actually come down to my office and see whether I actually have an IPv6 implementation before they give me address space.

So here it is possible that NIRs may end up competing with each other and it does happen with RIRs currently. But the v4 issue is now anyway over.

The third option is that an NIR could attract members and this will enable them to attract existing members as well, by effectively lowering pricing. The current pricing model is based on -- it's if you double your allocation, your price goes up by 30 per cent. So if you and I both have a /18 -- I'll use the example, both have a /17, resource fee from APNIC is $7,400 each. But if you pretend to APNIC that we are the same organization, we can save $3,000 each every single year.

For a large ISP, this is peanuts and they will not do it. Or they are unlikely to do it. But for smaller end users, it might make sense for them to do this.

Why does it not happen so often currently? APNIC members typically tend to be natural competitors of each other. Right? We are both in the same address space, I'm willing to lie to APNIC if we will lie under my name, so that I have control. But you are willing to agree with me if I would lie under your name. So in the end, it's like -- there is no honour among thieves, so to speak.

There is also a little amount of prestige in APNIC membership -- or a lot of prestige in APNIC membership and so I would like the membership document to reflect my name. As I said, for large ISPs, APNIC membership costs $10,000, $15,000, $20,000 a year, not deal breakers. IP addresses are not that expensive. Neither v4 nor v6 and paying $10 for an IP address if you buy it on the open market is still not a big issue. It doesn't depreciate or get worn out. There is advantage to having the registration in your name.

However, if an NIR was to act as a confederation using the APNIC terminology, it would be possible for me to retain some of the advantages of this. An NIR membership in my name would still have some prestige value. I will not be an APNIC member, but I would be an NIR member and it would still have some value.

The fact that the NIR is neutral and aggregating for the purpose of getting a volume discount, so to speak from APNIC, means that my competitor cannot hold me hostage, because the NIR would be hopefully neutral. This would be really useful for smaller ISPs. They would have other advantages, local currency payment -- not lower payment, but definitely a local currency payment.

Fourth option, this is the stick. Assume a case hypothetically where an NIR is associated with the government or with the telco regulator and the telco regulator wishes that the NIR do well for various values of "do well". It is conceivable that regulatory capture may enable an NIR to effectively tell a regulator -- where the regulator tells an organization, "If you wish to get an ISP licence in this territory, in this economy, you must be a member of the NIR and you must draw resources from the NIR", effectively giving up your APNIC resources and your membership.

In particular, we see this as the worst possible scenario, but it is not very unlikely. I know there are multiple negatives in that sentence. It is not very unlikely that regulators will act to encourage NIR membership if necessary by holding a stick. The APNIC member relationship agreement -- NIR member membership agreements starts off with, "To the extent permitted by the laws of the NIR member country ..." which enables the NIR operator to effectively be the good cop. So when I go to the NIR and I say, "But remember, your agreement with APNIC says you will not forbid local organizations from joining APNIC." He can say, "Well, I didn't forbid them, the regulator did." So I'm the good guy. I remain in the good books of APNIC. I'm not in violation, because it is to the extent permitted by local laws.

This is highly hypothetical, but in at least two countries which do not currently have NIRs in Southeast Asia, I have talked to staff at regulators which have independently, I believe, come up with this idea.

I do not think this is widespread or will have approval, but it is a feasible thing.

Two last points. Firstly, even if these issues occur and these are the four possible solutions, there are probably a dozen more, remember that every NIR will have its own local issues. There are some NIRs which are very focused on membership activities and there are some NIRs which may focus purely on a resource management, resource allocation point of view.

Every NIR will have unique problems and unique solutions. None of these four would actually fit them. The second thing is that the -- there's a paper which goes deeper into the background of this and that, I think, also will be up soon on the website. These slides are just a five-minute overview, although I believe I have taken more than that, but I would appreciate it if you could go and read that and if you are interested, you could find poke holes in the reasoning behind the four options there. So that will be really appreciated.

Andy Linton: Thanks, Sanjeev. Are there any comments or questions from anyone in the room here?

I suspect they probably need to read the paper and think about it a little bit.

Sanjeev Gupta: Of course. Thank you.

APPLAUSE

Andy Linton: That's actually all the topics we have for this session. I think we will just wind up, because we could sort of go into the next part, but I won't do that, because some people may have actually scheduled to come to the sessions tomorrow.

So you can go early to lunch or you can sit and type here some more or whatever, you know. Hopefully we'll see you at tomorrow morning's session which starts at 11 o'clock in the same room. So back here at 11.00 and another session after lunch tomorrow.

So thank you all for coming.

Before you go, Masato has a comment here.

Masato Yamanishi: Yes, regarding what Adam presented about implementation status of proposed policy, after implementing these policies, APNIC have received one IPv6 assignment request using prop-101 and also regarding prop-104, three pre-approved requests provided with 24 months requirement, based on a new prop-104. That's the current statistics after implementing new policy.

Andy Linton: So just to clarify that, that's after about less than two weeks.

Masato Yamanishi: Within one week.

Andy Linton: Just over a week, yes.

Okay, we'll get Adam to perhaps give us some more detail of what happens at the next meeting, you know, sort of a bigger picture, because we are very wary of small sample statistics.

Sunny has reminded me that the tickets for the APNIC social, the ticket looks like this, it's a small ticket, there was a flyer, which is a little bit bigger, in your registration pack. That is not your ticket. This is the ticket. There are a few of them left at the registration desk and if you're interested in going and haven't got a ticket now would be a very good time to go and ask, because you have half an hour's start on everybody else, I think.

So see you tomorrow. Thank you very much.

APPLAUSE