These are unedited transcripts and may contain errors.

---

Notice: Use of undefined constant steno - assumed 'steno' in /var/www/html/ripe-60/steno-transcripts.php on line 24
ADDRESS POLICY SESSION RESUMED AT 11 A.M. ON THE 5TH OF MAY, 2010:

CHAIR: Welcome back everyone. This is the second session of the Address Policy Working Group. The agenda for the session, we start with Filiz giving a presentation on the cosmetic surgery project on the RIPE documents. Then they have authorship of the RIPE policy documents. Point M, the ITU plans has been moved to the Cooperation Working Group later today. If you want to see that, it's at ?? just after lunch.

Then we are going to have a discussion about the differences between IPv4 PI space and IPv6 PI space. I think that's going to take up most of our time. The last ten minutes are for Rob, who has a presentation on the need for registration policy.

So that's the schedule. And then I want to give the floor to Filiz.

FILIZ YILMAZ: Hello again, this is me again. First of all, I want to start with with apologies for my existence today, I know I already talked and you have one more presentation to go, it really ?? it just happened, all right. Bear with me. And for good and I will keep it short. The cosmetic surgery project, I want to give a status update and ask some questions to you by the end of this presentation. What happened so far for those who do not know what this is about: During RIPE 58, we announced a plan to do some clean?up within our RIPE policy documents. The reason for that was that, as policy proposals are accepted, those are documented or integrated in the current RIPE documents. So especially, for example, IPv4 and IPv6 and ASN documents has been incrementably updated, so?called patched, so far, and different wording coming from different proposals, the flow of documents are, at times, lost. So, we wanted to make some wording cleanup, beautification, that's why it's called cosmetic. And the project plan was announced to you guys, and, during RIPE 58, this was agreed, and the plan, the agreed plan was, basically, we would draft new updated documents without any policy changes in it, just wording, textual updates. We would get confirmation from the Address Policy Working Group chairs, publish the draft to you guys for your review, and then, after one month of review, we would either go on with the new RIPE document, so the draft would be the new RIPE document, or we would iterate all these steps before, according to the feedback received. Within the programme, within this project, we are talking about 6 policy documents.

So, what we have done, with we have done that. We created a web page where we explained the project, we have updated the first document within the batch of these six documents, which was the ASN document in our region, and then we also met with other Working Group Chairs, we had a meeting with them face?to?face. We got their confirmation, we made the final refinements, we published this document, draft document in the project site.

And then what happened since then, it stayed in review for a month, as we agreed. There were ?? there was feedback coming back, not many, but that happens in the RIPE community, I realise. The quantity can be sometimes low, but we consider the quality, I guess, and mostly, positive feedback was received. However, there was one concern about the validity of ASNs injection. Now, what is that? All the Internet resources generally are benefiting from that general idea that an assignment is valid as long as the original criteria for that assignment is still valid. Now, this applies and this is explicitly written down in IPv4 and IPv6 documents. But ASN document was missing that and while we were realising update, we considered that this may be just there unintentionally because AS numbers are not special Internet resources that would not benefit from that general understanding. So with with that assumption, we injected that within the document with the realisation that this was a new thing; it wasn't there within the original ASN policy document. And the Working Group Chair also confirmed that, but this concern obviously came apparent and it is found beyond textual and this was considered as this is a policy change over the document. This is beyond the remits and the goal of the project.

So what do we do in that situation? We consulted with the Address Policy Working Group chairs and their advice was to run the full PDP because this was creating policy proposals situation at the time, which is all fine. However, since this is not the agreed methodology, this is why I am here now to have contact with you and this is a bit difficult to explain over the mailing list, so we waited until the ?? this RIPE meeting, so I can do this in face?to?face through a presentation which is much easier to get to the points.

I don't want to go off and change our methodology that you agreed and then come back, okay, this is what we are doing now, and it is all news to you. So, I want to get some feedback here. There are two options now in this situation, as far as I can see.

First one is, omit that change, we don't consider that change, we don't take into account that change within the realm of our project, which is just literally textually updating the documents. And then if the community sees it necessary, you know, maybe we can make ?? have another policy proposal to inject that to the ASN policy document. And that part can run in full PDP while the project can go on, as we all agreed, with the agreed methodology, or we can start running the full PDP over all the projects. Now, why I don't want to give a third option with ASN number we run the full PDP because that was the feedback we received and we still go on with the agreed methodology for the rest of the documents is because (A) I think we need to keep a consistent method for all documents, because it's the same activity at the end of the day; and (B) I believe, at the end of the day, maybe there will be other, you know, other points in the ?? as we go through the project in the other documents, maybe you will, again, find yourselves hoping, or requesting, a full PDP over one of the documents. So I would rather do it from the start instead of, you know, waiting for that feedback to come and then come back.

So, this is why I am standing here and I will be, you know, really, really happy if you can go to the mike and say your word, it may not be much of an interest to you. I realise it is quite operational. It is housekeeping, but RIPE documents are important. You live on them. The documents are the set of policies that you interact with the RIPE NCC through as well and with each other how things are run in RIPE community. So I think ?? if you can ask for that effort from you guys. All I am actually looking for answers here, so I change my questions slightly for that.

Is this pleading enough?

CHAIR: Any comments?

NIGEL TITLEY: I do feel quite strongly that the cosmetic surgery project shouldn't be making substantive changes to any documents, and that where there is a proposal to make a substantive change, that we should actually go and rerun the full PDP. So I would say that in this case ?? in which case I would be going for option A in all cases, so if there is concern about a proposed change, then we should omit the change, go forward with the cosmetic beautification of the document and then, if necessary, run the full PDP afterwards.

FILIZ YILMAZ: For the necessary, or if it is seen necessary for that change?

AUDIENCE SPEAKER: Yes, indeed.

FILIZ YILMAZ: Thank you.

KURTIS LINDQVIST: Kurtis. I actually agree with Nigel. I think we have a process that was followed, we got through the substance of the document, then final in clearing up the cosmetics, but we can't make substantial changes in it, then just go for option A. If we want to do the change, then rerun it later.

CHAIR: Okay. I have heard two people speaking up for option A. Nobody for option B. That's a clear answer then.

FILIZ YILMAZ: Thank you. This is really nice. I have just one more thing to say about this part, about validity. If there are any volunteers to propose that, as, you know, a parallel site, so please come and talk to me and we can sort it out and we can make the necessary information announcement at the mailing list, if you believe in that change, obviously.

NICK HILLIARD: Nick Hilliard from INEX. I am quite happy to be the guinea pig in this particular circumstance.

FILIZ YILMAZ: Thank you.

CHAIR: Thank you, Filiz. I think we can continue with your second presentation then.

FILIZ YILMAZ: All right. This is the last one, and this is about authorship of RIPE documents. This is very related to the previous activity. These talks came while we were dealing with the other activity and trying to, you know, make the RIPE documents repository look good and useful, be useful for the readers.

And one of the things we have noticed, as well, is the consistency in the references, so, at the moment, we all know RIPE community develops policies and these policies are developed via proposals, so, an individual makes a proposal and given that proposal, that specific proposal is accepted, that becomes injected into the relevant RIPE document, all right? So it is realised the proposed idea will be documented within a RIPE document at the end if the proposal gets accepted.

So when it comes to documenting, we all ?? sorry, we all name and ask who the proposer is, proposers are published, together on their proposals as the proposer, but in that second stage when we are actually documenting an accepted proposal, we are not very consistent there, as far as we can see. What happens is proposers are set, are written as authors in RIPE documents, but not always to start with. B) I am thinking, during the development of a proposal, so somebody makes a proposal, it goes through to the discussion phase and then the review phase and the last phase, last call phase. Throughout the whole PDP, every RIPE citizen makes comments too and they make wording suggestions and sometimes the original proposed text by that particular proposer is changed and happens to be different in the resulting RIPE document by the contribution of you guys here, and this is not really done, and my question is how far the authorshipness of a document goes? You know, where do we draw the line? And I want to do the right thing and I want to make sure that our RIPE documents are documented properly and consistently among each other.

One other problem I see with this kind of, you know, what we are doing now, we are putting the names of the proposers at the top of the resulting RIPE documents and this list is really growing. Soon, on the next GMI page, which are our convenient way of looking at RIPE documents, you will click on it and the first page on your browsers will be a list of names. Is this relevant to you when you are looking at a RIPE document about IPv4 policies within RIPE region, or do you just want to get to the point where you want to see what you are looking for?

So, one other slight problem that I see, and it's not maybe very big, but it is also important to mention, is that policies change. So ten years ago, some Internet citizen here made a proposal, it was documented in some policy document, but, today, Nick comes along and changes that proposal, or proposed policy at the time. And now, that particular policy is not even in the RIPE policy document, but the proposer's name is still there as the author. I don't know how that person from ten years ago feel about that, but it just doesn't feel right to me that, you know, that person still looks like the author of this set of policies at a given time while there has been a lot of changes in between.

So I feel we need to find a solution, a working solution for this, again mostly for housekeeping but also to make sure that we are doing the right thing here. So, my suggestion is to defer to RIPE, only RIPE at the top of the RIPE policy documents, and I am only talking about the policy documents here. IPv4, IPv6, ASN policy, address policy related documents. I am not talking about all the other RIPE documents that are best common practices, recommendations, etc.

And what we do, because this is the basic ?? this is because of the basic principle that RIPE, as a forum, you develop the policies. And then we acknowledge and credit the proposers at the end of the policy document saying that this compilation of document has been realised as it is today through all these proposers which were made by these individuals. So we give the names of the ?? point the names of the proposers at the end of the document, which also helps for each reader to go to a link and, if they are interested, they see those names at the end, not at the first thing in the document.

Now, there is one other thing that I would like to mention, and this is more about protecting the rights of the RIPE community and the RIPE documents.

What we realise at the moment, and I am not saying this is happening, but there is a potential there, it is a possibility in another world, but at the moment when we keep up with with this authorship thing with regard to policy documents, there is ?? there might be a situation where we may find ourselves that individuals feel responsible for these documents, or is this the right way of looking at it? Or, are RIPE documents there for the benefit of the RIPE and I believe the proposers can be warned about this and make sure that the RIPE policy documents stay available and accessible by the entire RIPE community and the Internet community.

So I would like to give some kind of warning at the stage we receive a proposal that will affect ?? that may have a potential effect on a particular RIPE document. So the proposers know their proposals will be published on the RIPE website ?? the proposers will be published on the RIPE website and their prior permission is not needed to make those proposals available as soon as they publish it within the domain of the RIPE community.

And those proposals are for the benefit of the community. There is no economic rights attached to making a proposal, so you can't ask, you know, I would like to be paid for that proposal I made. I am sorry, there is nobody to pay you. And there is no right of the proposer to restrict excess the proposals published. Once it is there, it is there. Because the transparency and the documentation, the basic principles of RIPE community are requiring that kind of storage, we archive everything. Once something is published with your name, it is there, you can't, you know, take it back, let me put it that way.

And what is accepted at a time can change later. You can't go and say, "Yeah, ten years ago I made that proposal and you accepted it and where is it now?" Well, it may have changed because this is the part of the deal. This is what policy development process is.

But, for sure, the contribution will be noted in the RIPE documentation, as I pointed out in my suggestion in the previous slide. So, this is what I would like to be doing, applying from now on. And I would really appreciate your feedback, because then I can realise it and if you see any faults, please let us know, guide us.

KURTIS: Starting with your last proposal, I think it should be in some way or form stated that the moment you submit the proposal, the international problem ?? RIPE NCC and it documented the RIPE NCC and you have no rights to it. I trust the RIPE NCC more than I trust most of the other stuff. And that's just a simple way to deal with all the issues you said. I don't think that's very controversial, or I hope it's not.

For your first question, I am a bit curious as to why you don't want to have the same policy applied to all documents, because, to be honest, I never quite understood this ownership. I guess it served a purpose at one point in time. In relation to Internet drafts and the editorialship is done by the people who are listed there, while, in the case of RIPE policies, most of the editorial policy are done by the RIPE NCC staff. It would be fair to have them at authors, but I actually don't think, in the case of the RIPE policy documents or any other RIPE documents, that the authorship has any meaning except some vanity recognition for the people who wrote it. But in the proposals stage, I can understand why you want to have a name of who is the proposer when it first goes out, but, after that, it serves no purpose. I don't see that you need to have the acknowledgement, I don't see that you need to have the name of anyone on the documents. They are RIPE policies. They are accepted by the RIPE community and most of the work is done by the RIPE NCC.

HANS: I have been involved in this for a while so I looked back into RIPE 140, which was actually the address policy when it was revised some years back, we did exactly that then. Then, the author of that policy is, at that time, local Internet registry Working Group. Of course, there is some credit down there to a committee which I happen to be part of, but the thinking back then was that this was actually the community effort, so there shouldn't be individual authors listed on this. So I think it's a very welcome proposal to go back to that, and since with we, today, have a much better tracking of the actual policy proposals in the PDP, the sort of credit for authorship or for the proposal actually comes in there, so you could still put it on your CV if publication is important to you for your future career, which it could be for somebody. So I think we can get best of both worlds with that proposal.

KURTIS: Just what Hans says, I realised. I mean, as opposed to many other documents, the authorship here, when you list them on documents, you can contact the author for clarification, but, in this case, the authors have nothing to do with the implementation or the use of these documents, so they are purely there for some sort of recognition and, you know, if you put it in the footnotes when the general RIPE recognition website, I don't really care.

FILIZ YILMAZ: Can I just ?? yeah, and regarding this last comment that there is nothing to do about the authorship directly, maybe, and that is the reason I want to focus this, or our initial suggestion is to focus this only to the policy documents, because with the other kind of RIPE documents, best practices, recommendations, maybe there is a need to know who the author is and, you know, for contact details and for operational matters. But for the policy bits, yes.

SANDER STEFFANN: My feeling, my personal feeling is that the exact author is not as important as the Working Group that wrote it, so I would put the name of the Working Group there as the author because that's the group that wrote the document, or at least approved the document, because that is a useful pointer because then you know where it has been discussed, but...

FILIZ YILMAZ: Sure, can we just ?? the authorship, yeah, it's an interesting thing. If that is going to be the case, can we just conclude, if this is the suggestion, we will refer to RIPE at the top of the document, because, yeah, RIPE is not a person, and in really definitional things and niggle words, RIPE can't be an author, really, because simply RIPE is not an individual, but we want to make sure that RIPE governs the document. So there is a very direct reference to RIPE there.

WILFRED: I agree with all the stuff that was already said. Just a procedural suggestion, as we, yesterday, talked about having another look, maybe, at the PDP process and documenting the PDP process with regard to sort of not having ?? not owning any rights to authorships, that might be just a small paragraph in the description of the PDP process. Whenever anyone suggests to start a PDP, then this is the point in time to point it out and this is the document and you agree to that one.

FILIZ YILMAZ: Thank you. Yeah. I see Nick walking up to the microphone.

NICK: This is beginning to turn into a little bit of a colour?of?the?bike?shed discussion where everybody jumps to the microphone because they have an opinion on something that they can really understand.

I do have an opinion on this, which is to say that most other Internet documents specifically list an author such as the RFCs, you know, even stuff like I?triply documents, they are all have authors, there is nothing wrong with it, I don't see why it should go.

But certainly as regards assignment of copyright, I do feel it would be a good idea if the RIPE NCC had an assignment of copyright form which all authors would be required to sign before their document submissions were accepted.

FILIZ YILMAZ: We can do that, yeah.

SANDER STEFFANN: Any others comments? Thank you, Filiz.

FILIZ YILMAZ: Thank you so much.

(Applause)

SANDER STEFFANN: Like I said, we go from L to N because the presentation on the ITU has been moved to the Cooperation Working Group. Now, we are going to talk about the differences between IPv4 PI and IPv6 PI. Alex is the one who brought this to our attention. Filiz has this view that document highlighting some important points in there. We ?? well, I think I'll just let Alex do the talking now.

ALEX LE HEUX: Okay. This is just going to be a short introduction to the discussion because I presented on this at the last RIPE meeting, Hertz mailed the summary to the mailing list, and, last but not least, I'd like to thank Filiz for writing and distributing this article which explains it all in great detail.

Okay. So, there is a difference in the policy texts between IPv4 and IPv6 PI policies. The v4 policy text defines IPs used to connect customers to an ISP network and ISP infrastructure and the IPv6 policy does not. The result of this is that, in some cases, access providers and hosting providers can use IPv4 PI, but they cannot use IPv6 PI space, which might seem like a small difference, but, in reality, it can actually be quite significant, because we ran a few numbers, and, as you can see, actually the large bulk of PI assignments that we make in IPv4 go to either hosting providers or access providers or a combination of the two. Of the actual assignments, about one?third of the assignments go to classic end user, end site networks, while in terms of address space, it's even less than 20%.

And while, at the moment, we don't actually get many IPv6 requests from such ISP organisations, we can expect this number to go up as more and more of these networks start deploying IPv6.

There is also quite a difference in the distribution of the sizes of the requests. The end site networks tend to request smaller assignments, mostly /24s, while the ISP networks tend to request larger and larger sizes. Over the last few years, these sizes have actually been growing quite a bit as well.

That said, the total amount of PI space in terms of addresses that we hand out is still only a very small percentage of the total amount of space that we hand out. It's about 4%.

So what we are looking for is some confirmation, either if this is the right thing to do, should this difference exist? And, if not, how should it be solved? Should the v4 policy be changed? Should the v6 policy be changed or should both of them maybe be changed?

Please discuss...

Unless there are any specific questions about the slides? Okay.

SANDER STEFFANN: Thank you, Alex.

KURTIS: I did have a question. I don't know, but maybe I am getting old and confused, I actually thought the v6 policy, that this was actually a feature, not a bug. This is, I remember, it was supposed to be, that you denied more v6 than v4 PIs.

ALEX LE HEUX: That could be, but I am not sure at the time it was known that such a large number of v4 PI requests were for these organisations.

AUDIENCE SPEAKER: I don't know that mattered. I think we actually wanted them to use up the v4 space.

ALEX LE HEUX: Okay.

WILFRED: I very much support Kurtis' concerns. The systems are different. The problems that are being addressed by the policies are different. And while, okay, also the time, the point in time when things were decided were different, so actually it's different circumstances, but for v6 PI is quite deliberately restrictive. (Applause)

SANDER STEFFANN: Thank you, Alex. I think ?? I would like to have some more discussion on this PI subject, because there are some real cases where people ?? I have talked to say, oh, but I am not going to do anything with IPv6 because in IPv4 I have my PI block, I have my access customers and I can run my whole network, and now, with v6, I suddenly have to become an LIR, I have to become an NCC member. So this is not interesting for me. I hear that argument from some of the providers.

We also have the issue where there is IPv6 in data centres, where is the border between allowing IPv6 PI to be used to connect servers that belong to a customer or multiple servers that belong to a customer? And I think there is a really grey area there. Do we want those colour providers to use PI space? Do we want to say to them, no, you have to become an LIR and you have to use PA space? What are the feelings about that?

RUEDIGER: And the answer specifically, well, okay, I don't care, I don't care who are the owners of the systems sitting behind a colocation provider. If it's one network, I am not requesting any special treatment there, and, well, okay, kind of a provider independence there would be probably that the single host, the single host owners would like to be independent of their colocation provider, and that's simply not doable.

The first question, I don't remember right now, but I think the question came up to my mind: Do we have at least some numbers of how many requests, how many problems we are dealing with, so that we can have an idea what the impact actually is?

ALEX LE HEUX: As of now, we have denied around 10% of the IPv6 PI requests for this particular reason, and as we have around 160 PI requests received total, it's about 16 requests that we have denied so far, but we do expect the number of requests for PI space for this kind of hosting or access users to go up, and I think, in 2010, so far, we have made, I think, about 800 IPv4 assignments and two?thirds of those would not be approved under the current IPv6 policy.

RUEDIGER: Again, the hosting doesn't seem to have really a conflict with PI. If it's co?located, if it's just a number of hosts sitting on a common LAN, well, okay, it really doesn't make sense to discriminate for small access providers. Well, okay, I am kind of confused. I am not really aware of that kind of business model and there seems to be kind of the question: Well, okay, if those are service providers, why don't they show up as service providers?

MARCO: First of all, I am wearing my operational hat, network citizen. I do agree with Kurtis, this was by design. Now putting on my IPv6 Working Group hat, I do believe we have an issue with people trying to deploy IPv6 who are running into trouble and maybe we should fix this. But, as Ruediger said, I think this is basically a clear distinction on sub?net. I mean, technically, if you get a whatever, /24 PI, and you put this in sub?nets and you server up, it's glare, its infrastructure and you should connect up and I guess that if you do it the same way with IPv6, you get a /48, for instance, PI space, and you distribute that across sub?nets which contain /64 and people with can put a server in. My personal opinion in this would be an infrastructure assignment, as well. So this should be a future parity there. But what I do see is that what people deploying IPv6 on colocation, they assign more than a /64. It's not only about the sub?net, but they push out additional static routes words to that server and I think the distinction should be made that, at that point, you are actually making set assignments and you should start using provider equitable address space instead of PI.

I would say change the policy but actually be clear on what an infrastructure assignment is. And as a last thing, there has been a lot of discussion here and it's been thrown up several times, but I never, ever seen a role proposal here and that's why I am wondering, apparently a lot of people have an issue there but nobody cares to actually write a real proposal. Every time this thing is brought up and please fix this, but nobody comes up with a solution, so I wonder does the community actually want us to fix this or is the original comment by Kurtis, this was by design, actually still intended and can we stop it here?

SANDER STEFFANN: Our third option: Are the people who hit this problem not too involved in this community actually, and don't know they can fix this? So, that's... I think there is no way to find that out.

One thing I want to comment on. You were talking about infrastructure in relation to the IPv6 policy. I don't think there actually is any infrastructure mentioned in that policy. That's in the v4 policy, so what I hear is that, from you, is that we should bring that to the same level and mention the infrastructure part also in the v6 policy. That will still leave the access providers, because an access provider actually ?? well, we expect them to delegate a block of addresses to their customer, so that won't be infrastructure. But that would at least be a way to solve the data centre problem.

MARCO: Well, I guess ?? Marco again ?? I guess, like I said, we have to be clear what infrastructure is. If you are an access provider, you put down a /64 on basically what is your extra infrastructure and give all customers one address in that /64, than it's an infrastructure assignment. If you start handing out 56, 48, whatever, per customers, then you are making sub?assignments. Policy is clear, go for PA.

SANDER STEFFANN: I just got a message that Gert has something to say, so, Gert, please...

GERT: Hi, Working Group. Gert Doering speaking. We have ?? we seem to have two different kinds of denied requests here. We have the access providers that are currently assigning single IPv4 addresses to, well DSL, cable, modem, whatever customers, and force them to use v4 and we have the hosting providers and both sort of providers cannot get v6 PI for what they want to do.

We had a discussion on the Working Group mailing list since yesterday evening, and I think we need to be careful with wording the policy to make sure that we don't send the wrong signal, because one of the things about v6 policy regarding access customers has always been you get a complete network and not a single IP address, so if we tell the access networks, yes, it's okay to use PI for access customers, give them a single IP address because that's infrastructure, we will see this business model, and I personally don't want to see that.

Regarding the hosting providers, this is really a different way to run the network, and I think, personally, I am fine with them using PI space, especially for a small shop, it might be just more convenient or more straightforward, until they grow to a point where they might want to become a RIPE member for whatever reason.

So I have sent some text that could tackle the hosting provider problem to the list, and that should take care of Marco's complaint about there is no proposal. So, I welcome feedback on that. It's definitely not going to be the single solution because it doesn't get to take care of access networks and so feedback welcome.

KURTIS: I am a bit worried of the message here, because we always assume that, in v6, if you were doing any form of service, be it access networks or even data centres, you were going to do sub?assignments to your customers, you were not going to do individual address assignments. So I would actually assume that a data centre provider were doing sub?allocations to the customers, no matter if they are small or large, if they are service providing industry. My position is, if they did not do the PI policy for this purpose, it was for enterprise line networks, that that was argued that couldn't get v6 space and wanted to do multihoming or couldn't get addresses from the upstream provider. It doesn't seem to me that either of the cases are what was originally intended what the PI policy was. It was supposed to be restrictive.

GERT: It was supposed to be restricted to just grab the microphone again. But, that was ?? well, I seem to remember that the main focus for being restrictive was protect the routing table. So, for a data centre business, it doesn't really matter whether they have one slot in the routing table for a PI block or one slot in the routing table for a PA block. But ?? well, joining sides with Marco, if we have content out there that would like to go to v6 and it's really because our PI policy doesn't permit them to, I could understand the wish to amend the policies here. I am not saying that we have to. So if the room says, go away, PI is evil, they should use PA space.

AUDIENCE SPEAKER: Hi. Jamie. Wearing my citizen's hat for this question.

Is there value in looking at a mechanism whereby space can be allocated to an end user or organisation from PA and then, on payment of the appropriate fees and if the sub?net is of a suitable size for routing, a mechanism to convert it to PI?

KURTIS: Well, to answer that question, would that be to break the routing table permanently because you'd have loads and loads ?? we have been there. I think that's a really bad idea.

But if I can jump in and answer to what Gert said, I do think there is other difference in PI and PA space. If you are a service provider providing services and you couldn't afford the fee to get real addresses that are documented in the RIPE database, with sub?assignments to your customers, then maybe you should do some other business, because it's easy to become an LIR and I don't think there is any barrier to getting v6 space. If you want to provide v6 addresses to your services, just become an LIR and get the PA block, it's that cheap and that easy.

SANDER STEFFANN: Gert, do you want to comment?

GERT: I didn't actually want to directly comment on that. I have heard Kurtis, and, well, it's the community voice that we need to hear, not the Working Group chairs to decide on this. So really, if the community says, we don't want this, then the current PI policy is fine.

WILFRED: I'd like to come back a little bit to your reasoning about the size of the routing table. I think this is one aspect. It's an interesting and important one, but I do see a more important one structurally and that's actually Internet governance. If you really have a service provider to customer relationship and you are redistributing resources, then my feeling is you should be part of the group of service providers and you should actually go for PA and you should, by doing so, you are implicitly becoming a member of the RIPE NCC. If we open up this side door, like I am doing the same stuff like you are doing but I don't want to show up, I don't want to be involved, I don't want to pay the fees; I want to just sort of hide between some other friendly local IR which gives me a subcontract to get PI space and then I go on, I don't feel that this is the right message to send, and I don't feel this is the right way to go.

GERT: Well, now, I have to comment again on this, of course.

The problem with the hosting data centre stuff is that the boundaries sort of floating. If you have an enterprise that's hosting service only for their own purpose, it's clear that PI is a viable approach to that. If you have them then sort of do http 1.1 virtual hosting without using IP addresses for other domains, it's sort of still okay. If they then give a dedicated machine to one of their customers and use one IP address for a different machine in their network, is it, all of a sudden, not okay any more to use PI? So the question really is: Where do we want to draw the line and say, you are running a data centre, you are giving single IP addresses, networks, blocks of networks to your customers, this is the border where you have to become an LIR, and, up to that border, PI is fine. So, this is tricky business, and I think this is the reason why we are discussing this again and again on the mailing list, because, well, right now, the border is, if you give a single IP address to a machine that's not belonging to you, PI is not fine and people might not be really fine with that.

AUDIENCE SPEAKER: Hello. Gert, University of Technology. Two things: First, a comment I think to Kurt, who said if you can afford the real, you should change the business. I think it's not fair. There are some countries in the RIPE region which are not wealthy enough, I should say, and sometimes the LIRs ?? they are small networks who can not afford paying LIR fee year?by?year, and simply PI space is more cheaper, it was even free of charge 'til last year. That's the reason why people are trying to get the PA space, and, believe me or not, it is something of a problem. €50 versus 2,000, I think, that's the smallest fee ?? 1,200, sorry, it's still a few times bigger. And believe it or not, it's sometimes the case, and it's not about the ?? it's not about the going into a different business; it's about the competition, about the prices in the country, even like mine, and there are some regions in which there is a problem with such an amount per year because the business is run out of the border ?? how you say in English? ?? of the income, on the border of the income. That's the first thing.

And the second thing is, we should promote IPv6, I think, and because I am pretty much sure that with PI space in v4, a lot of users are relying to RIPE NCC about the real purpose of the usage of that space. I think they started doing that in v6. They will be doing ?? they will be trying to sneak out around the policy, and I am pretty much sure that that's the future. If we do not make that policy stupid simple, they will try to do that because they are doing that in v4. I am pretty much sure about that. I do not have any proof, of course.

And if we try to complicate it, start thinking what is and what is not the infrastructure, if we make a complicated definitions, there will be always some case which will not be covered by the policy. So my message is: Make it stupid simple. There is plenty of v6 out there, space, and yeah, 20 years ago guys were talking that there is plenty of v4 address space. But who cares? In 20 years, we will be probably somewhere on the Bahamas, not here, and yeah... The third thing is, let's make a RIPE meeting in the Bahamas. Thank you.

SANDER STEFFANN: I think we heard some different opinions here. I think the clear case is service providers who provide DSL services like that to their customers just have to be to PA space. I don't think I have heard anybody opposing that.

With only the comment from Gert that we don't want the situation where they just give out one IP address to a customer and then try to force net on them in the v6 world.

There were more different opinions on the hosting data centre in that area, and I think Gert has raised a good issue, like, where is the border? So, what is providing a service to a customer? And I know these are very difficult questions. So I am looking for a way to go forward. We can, at least, state that to the NCC for the registration services that PI is not okay for the DSL providers. I think that message is clear. And I suspect we need some follow?up discussion on the mailing lists on the remaining issues. Gert, you are on screen, do you agree?

SANDER STEFFANN: I see a big thumb, so... Okay, well, we are quite ahead of schedule now, because all we have left is the presentation from Rob Blokzijl, I don't know if he is already in the room. I see him coming there. So, thank you for your input. This brought us one step further. And now I would like to give the floor to Rob.

ROB BLOKZJIL: Good morning. No slides so you have to listen and pay attention, a whole new concept.

What I intend to do in the next five or ten minutes is to share some thoughts Daniel and I developed on the role of the registry, triggered by the fact that, in two years from now, or so, or maybe even a little bit shorter period, the pool of IPv4 addresses that are available for distribution will be empty and what is left is a registry where the history of these IPv4 addresses has been kept.

What do we do with that registry? Well, we keep it, I suppose, and I hope we will keep it up to date, because we use this registry for various purposes. This registry, if you go through our collection of policy documents, this registry is ?? has never been the subject of a policy. It is hidden in various policies, various aspects of the memory source registry which we maintain, described in various, mainly IPv4?oriented policy documents. These policy documents, in a few years from now, will be of historical value only, because there are no more addresses that can be distributed following those policies.

However, the bits and pieces that deal with the registry and various functions of the registry, remain valid, of course. So I think that we should work on a separate document that describes the registry and the policies surrounding the maintenance of the registry. By doing that, I think it's also the right moment in time to reflect on the definition of this registry to give, to the best of our knowledge, a good description of this registry.

This registry started a little bit over 20 years ago when, basically, RIPE started, first on a voluntary basis, has been trying to document the use of IPv4 addresses in our area. Those addresses were not distributed by the RIPE NCC because the RIPE NCC had not been created. People got their addresses by whatever mechanisms were in existence 20?odd years ago. And this community, 20 years ago, decided it would be worthwhile to exchange knowledge about the use of these addresses in Europe.

Later, when the RIPE NCC was created and started allocating IPv4 address space, this work was taken over by the RIPE NCC. This work, meaning the RIPE NCC kept a record of its dealing with IPv4 address space. The old address blocks, to a certain extent, were kept in the registry. And then a couple of years later, when the ?? when ARIN was created and later ?? no, when we reached a system of five regional Internet registries, we had this big operation of moving administrative control of legacy IPv4 space into the various Internet registries, regional registries, where we thought those had the more natural home. It has never been clear actually who has, who was responsible for the maintenance of these records. That is the grey area between the RIPE NCC today and the early users of the Internet 20?odd years ago, 25 years ago.

Those addresses went to organisations like universities, research institutes, bits and pieces of governments, organisations that were not really the right type of organisations to join the RIPE NCC as an Internet service provider because they were not Internet service providers, so we had no grip on the way these addresses have been kept in the database.

So I think we should now start thinking of our situation a couple of years from now. IPv4 will be heavily used. There will still be a great demand for IPv4 space. We don't have it any more, I mean the NCC, but there are other ways and means of acquiring IPv4 address space.

What I think we should define is, what the role of the IPv4 registry is in that new environment like which addresses should be registered? My personal opinion is we should try and keep a registry that is complete in the sense that all IPv4 address space in use in our community, in our geographical area, should be kept in our registry, because I think it will be a challenge five or ten years from now explaining to people that this IPv4 address is completely different in nature from that IPv4 address. Only historians will understand what you are talking about. And the operational community, I think they will see IPv4 address space and they want to have one well?defined place where they can find documentation about that space.

So, Daniel and I wrote some of these thoughts up in a short paper which, this morning, I distributed to the Address Policy Working Group list and to the larger RIPE list. What we hope to achieve is that we, as a community, can agree on a definition of the registry and what we expect it to be, and, once that is clear, we will have to translate that into policies. So that's why, in my announcement, I said this is not a policy proposal. First, we should define the object we want to make policy on.

So, I suggest in my mail this morning that the Address Policy Working Group mailing list would be the place where we discuss this, and Daniel and I will be active there in reading your comments and working to the best of our knowledge on a new version of this document which will incorporate all your comments. And then, once we have agreed on that, we know what we are talking about, we know the role of the registry. We should develop policies.

That's it. I have received at least one comment from Nigel Titley already saying do I smell certificates? I have not used the word "certificate" in this short presentation. But my personal opinion is, if you want to certify things, you'd better be sure what you are certifying. I think it will be very difficult to issue certificates based on data which you know is of a dubious quality.

SANDER STEFFANN: Sounds sensible.

AUDIENCE SPEAKER: Rob, kind of the key word I think for that is, and I didn't hear that in your talk so far, is, well, okay, is the goal of the data held in the registry to have that registry data to be authoritative, complete, you said; complete and authoritative are slightly different things.

ROB BLOKZJIL: I don't know how we ?? you would define "authoritative" in this respect. It will be clear, in my view, but maybe the community has other thoughts, that there should be a sort of quality statement there in the sense that, (A) do the RIPE NCC publish this data? And to the best of their knowledge, it is correct, which, in some cases, is an easy thing to accomplish because it deals with address spaces that has been handed out by the RIPE NCC to an organisation, a member of the RIPE NCC with which the RIPE NCC has a contractual relationship. That's the easy case.

And the most difficult case is this small university department somewhere far away which, in 1986 or so, got a small address block.

So, I think ?? but the published data should have an indication on how well it could be checked.

AUDIENCE SPEAKER: So you are saying you might have flags on the data that says well, okay, this entry is authoritative and this is just for the record?

ROB BLOKZJIL: I think this is a question we should think, discuss and decide. Randy? Daniel is first.

DANIEL: This is Daniel, co?author of this little memo. People should read it. It says, actually, what Rob and I think the registry should be, and it's a registry that serves two purposes: First of all, to have a comprehensive public recording of the address space that the RIPE NCC is administratively responsible for, by whatever mechanism, either that we allocated it or that we received it via ERX or by whatever other arrangement; and the second is the comprehensive public recording of the current holders of the address space, and ?? so that's what we think is a good definition to start with, to start the discussion. And then about the properties of the registry, there are actually three Cs, comprehensive or complete is only one of them. It should be comprehensive so it has to cover all the address space that the RIPE NCC is responsible for without exception, but also it must be current, so it must be kept up to date; your last year, it might be interesting for historians, as Rob said, but not properly operational. Third one which is very important is the third C, is correctness. So it must be right data that's in there. And those are, I think, the places we should start from.

I also think ?? agree with Rob, obviously, that if we are talking about certification, I think it's much better to have a good definition and agreement about what the registry is and then certify what's in that registry, rather than starting, you know, the other way around and discuss policies for certification without actually knowing what we are certifying and what the underlying truth is, what the underlying registry is. But that's only a side remark. And actually, this was not primarily, at least not for me, not primarily motivated by the whole certification discussion. It's motivated by the need for a strong and well?defined registry and the policy for the registry, in the absence of the distribution part of those policies, like Rob has said. This is the main motivation. And I think if we don't have a strong registry, our whole industry, self?regulation and self?administration becomes weaker. Okay, enough said...

ROB BLOKZJIL: Thank you, Daniel. Randy?

RANDY BUSH: Just one side note. We already heard one need earlier today for Whowas, and so I think keeping an historical record is probably useful.

Back in '97, I was one of the four people who had to go to, you know, for these kinds of things, we wanted ?? we needed federal approval because they had the legal contracts, the formation of ARIN and four of us went to the Federal Networking Addressing Council, actually two of us are still in this room, one is wandering, wherever Scott is, and the fourth is dead. And I actually made the 'preso', so I just went back and looked at it, we committed ?? and this is just, for you, an idea of what's the original view in ARIN, and, of course, it's contentious since then because ARIN is contentious, that's our middle name ?? is we committed to maintain what we now call the legacy data with no changes in policy, and that was one of the conditions that we ?? ARIN got formed and separated from network solutions at that time. And I still have that 'preso' on my laptop if you are interested.

ROB BLOKZJIL: Keep it. We might need it in the not?too?far future to ?? at least for educational purposes, that people know the various flavours of IPv4 address space are. Thank you, Randy.

And, yeah, I think this whole exercise is very valuable to do, but it becomes incredibly more valuable if the RIRs would sort of take the same effort on board, and informal talks with ARIN people gave me good hope that, one way or the other, we might achieve a global well?maintained registry. Bill.

BILL MANNING: Bill Manning, currently unaffiliated. I appreciate you putting this together. There was some discussion about this in the ARIN region a few years ago. What you call correctness, we called accuracy. The accuracy of the data in a timely manner is important for the credibility of the registry. And I think RIPE does that now with the resources that it is under ?? that are under its administration, and maintaining that, going forward, is a recommitment of the RIPE principle. So that's a good thing. I will echo Randy's suggestion about the very helpful nature of a historical view about who had what, when. That's something that hasn't been done, as well, and it would be appropriate, I think, also to ensure that the other registries are aware of the fact that you are starting on this path and this is something that you would like to see done across the entire IPv4 pool, not just what's under the RIPE administration.

DANIEL: Just about the Whowas. Actually, we have that. It's just what I meant to say and maybe I wasn't quite clear is, that we shouldn't make policies about the Whowas, because those were the policies of the past. We have Whowas. If you go to riex.ripe.net you actually have an interface for a big part of that information, there is RIPE database information there and stats files information as far backwards as we could find it and I believe the RIPE database information starts in the last century. So it's there, you can query it. So just that there is to mistake about that.

The other small witty remark is that we didn't call it accuracy because accuracy doesn't start with a C.

Niall O'Reilly: At the risk of being trite, because I am trying to be brief and stay away from getting sucked into the detail which will inevitably have to be addressed, I applaud this initiative from Daniel and Rob. I think it's certainly timely, perhaps even overdue, to think about registration services as distinct from address distribution services, and I'd emphasise that the need for this kind of resource to underpin and coordinate, and that's what the middle C in NCC stands for, the Internet in the RIPE area hasn't gone away since it was recognised as useful before the NCC was started.

ROB BLOKZJIL: Remco?

REMCO: Private Internet citizen. I think the registration policy and the need for it is very clear to me, not just as a result of ?? well, the first time we call it a registration policy was when we were talking about transfer policies, and keeping a record, even, for any sort of movement of IP address space, whether that's within or through the RIPE NCC or outside, or whatever, I think is a very valid idea. At the same time, I do have to ?? or people are eager to put certification on top of this. I think that's a fully separate story indeed.

AUDIENCE SPEAKER: Hi, Jamie [Stalwood] again. I think the registration policy is very important, and ?? but I think it's fundamentally tied to what NCC does with IPv4 after there are no more addresses to allocate, and how it keeps track of the sort of under the table transfers that are likely to happen.

ROB BLOKZJIL: Yes, I think so, too. Transfers are not mentioned in this document, and I think ?? I hope that the policy we develop will be one that makes it as easy and as simple for people who have the need to register their use of IPv4 space. People should be encouraged to keep this up to date and that means that the registration functions should not be a stumbling block for things like transfers, issuing certificates and God knows what other applications people might think of of this registry.

REMCO: I think that one of the key concerns that we, as a community, would have to address is that, whatever comes out of a registration policy, how that would relate to some sort of title office. If it's going to be authoritative, I think that has all sorts of legal implications, and I think, as a community, we have to realise that ourselves and see how we would deal with that.

ROB BLOKZJIL: Right. If that's it. Once again, to repeat what Daniel said: Please read the document. It's short, so that hopefully encourages you to read it. Read it. Think it over. And remarks, comments, suggestions, please to the Address Policy Working Group, and then when the two authors have a feeling that no more things are coming in, we'll make a next version and that will then be the starting point for potential authors to write a policy proposal. Thank you.

SANDER STEFFANN: Thank you, Rob. (Applause)

And now it's time for lunch. We will continue tomorrow at 2 o'clock in this room. So I hope to see