Archives

ADDRESS POLICY WORKING GROUP ON THE 18TH NOVEMBER 2010 AT 9 A.M.:

CHAIR: Good morning everybody. I am not sure why the room is so empty. Maybe EIX is too strong a competition going on at the same time. This is Address Policy, by the way. If you want to learn about exchange points, please go to the other room. You were in the EIX room, you can't hear me anyway.

So, what are we going to do today? This is the agenda for today. It's pretty short actually. Welcome back. This is what I am doing.

Then we have three formal policy proposals in the PDP right now that we need to discuss, the presenters will present their ideas and then we'll get feedback from you. Then we have the Open Policy Hour with Marie Hannigan and Jason Schiller about global transfers which is going to be quite an interesting discussion, I would guess. And then we have a few small things in AOB that came up and want to be out in the open.

I think all of you that are here know this slide anyway. So I am not going into detail here.

And it's pretty much over to Jason Schiller on the global IPv4 policy for IANA after runout. So where is he?

JASON SCHILLER: Good morning. My name is Jason Schiller. I am with UUNET Verizon and the NRO NC and presenting on behalf of myself, Martin Hannigan and various authors that have contributed to this proposal.

What is the problem that we are talking about? Well, we are all headed towards depletion and IPv4 allocation and assignments as we know it are going to change. It's going to become more difficult to get IP addresses. There is going to be austerity measures. You may only be able to get IPv4 addresses for transition technologies. And you may have to get IP addresses on the open market which may be much more expensive than the conditions we are operating under today. So our goal here is to try to ensure that unused IPv4 addresses can be returned and reused by people who need them.

So, what is this global policy provide for? Well, what it does is it allows IANA to make allocations post IPv4 depletion. Today, as it stands under current policy, IANA can make allocation and assignments of /8 size only and they can do that only until they get down to the last five /8s. At that time the normal allocation policy ends and they move to what I like to call the N=1 policy where each RIR gets one /8. So those last five /8s will immediately be gone. At that point there is no policy by which the IANA can make allocations or assignments. So what we wanted to do is we wanted to write a policy that would cover with the IANA could do after that point in time if it finds that that is space.

So, what it does is it allows for the IANA to make those allocations in an open and transparent way. It defines how RIRs are eligible to get that space. The distribution method is published, so it's going to be transparent. We have required IANA reporting so that it will be open and public. And our attempt here is to try to maintain the value of RFC 2050 in a modern form. And finally, the goal here is to remove road blocks so that RIRs can comfortably return space to the IANA as well as legacy holders return space to the IANA and know that those addresses are not going to get stuck in limbo, that they can be used. It creates a reclamation pool. Immediately upon IANA ?? ICANN ratification of this policy, reclamation pool will be set up and the IANA will accept returns to at that pool. If someone tries to return something smaller than a /8, that will immediately go into the reclamation pool. If an RIR returns a whole /8, that will go into the normal general pool and used as it is currently used today until depletion happens. Post?depletion, even whole /8s would go into the reclamation pool. And once depletion happens, IANA can allocate space out of that reclamation pool to the RIRs and the way that works is, every quarter the pool opens up, all of the eligible RIRs, those are the ones that are noted to be in depleted status, get an equal sized chunk. Currently those addresses that come out of the reclamation pool are not available for transfers. However, if there is a general purpose global transfer policy or a general purpose global co?ordinated transfer policy, that will apply to those blocks as well. And this process is open and transparent.

So, I want to talk for a moment for RIPE policy 2009?01, which is the previous global policy in order to allow this to occur. Why don't we just move forward with that? There are two contentious issues in that policy. The first is the ability to transfer IPv4 space to other regions. This tends to be a roadblock in some regions, at the least at the very least the ARIN region because there is some concern that address space might move out of a region that has IPv4 stewardship into a region that has dissimilar values in terms of stewardship. And that's been a roadblock to global consensus. The other roadblock it the mandatory return for the same reason.

So let's take a look at the two proposals.

RIPE 2009?01 and RIPE 2010?05, both allow the IANA to reallocate and return addresses. They both split the addresses evenly between RIRs, but the older policy gave every hour an equal sized chunk. The newer policy only gives it to RIRs that are in a depleted status. 2009?01 had mandatory returns. 2010?05, does not. 2010?05 does have a hook to allow inter RIR transfers once there is a policy for that. And it also prides for a total of a /10 reservation of space that can be set aside for special use such as austerity measures.

So global feedback that we got. If you look at RIPE 2009?01 we had consensus in all five regions. You will note that in the ARIN region that the transfer and the mandatory return prevented consensus. And that the ARIN AC did a rewrite. So the language that previously said must return space to the IANA was changed to may return to the IANA. That has prevented us from getting global consensus.

RIPE 2010?05, there seems to be support in the AfriNIC community. We have got a meeting coming up there soon where we will discuss it in more detail. When this was presented at APNIC, we heard some comments about this policy was both needed and not needed so the community seemed split on that. Some people thinking that nothing will ever get returned, that will just be on the transfer market. There is come considerations about the distribution method being unfair. The concern here was that the way the policy was previously written as soon as an RIR becomes depleted, the pool would open up, because that was the only RIR that was deplete it had would take everything out of the pool. We have taken some advice from APNIC and we have rewritten the language. It now opens up on a quarterly basis. So that's no longer an issue. There was some discussion about the the CIDR language. There is some language in the policy that talks about the size of space that can be given out or what can be asked for and it's related to any RIRs minimum and there is some language about longer and shorter and I guess some of the people that do number policy aren't router engineers and they don't understand this longer, shorter language. So they said why not just make it a flat /24. We did not take their advice on this account because we wanted that number to be able to change with RIR minimums because that gives the RIR community some flexibility to have this policy works.

And the last comment from APNIC was that the transfer policy was too restrictive and it was meddling in local policy and that was why we rewrote it to put in the policy hook for transfer. So, if there is a global or globally co?ordinated policy for transfer, then this space would be capable to be transferred as well.

In the ARIN region, there was some concern raised about various registry space. I think those concerns have been addressed now that if you look in the IANA allocations there is no longer any space that's labelled as various registry. It's all held by the particular RIRs with which it's in. The ARIN community gain consensus and the ARIN advisory counsel did do a rewrite for clarity, I have some slides to talk about that as well and it's been sent to last call.

In LACNIC this policy was not discussed. The LACNIC community felt that they had a perfectly good global policy for which the community had already reached consensus on, and they felt that due to procedural reasons, they could not discuss this policy because this policy did not officially declare the older previous policy as null and void. And then finally we are here in the RIPE community.

So, why does mandatory return fail? So the problem is things are changing very quickly as we approach depletion and it's very hard to write a mandatory return clause into a global policy knowing that it takes a long time for global policy to change. It's unclear how things will change as we reach depletion as we pass depletion, and what IPv6 adoption looks like, and a lot of people felt it was very risky to have a mandatory return in the policy. And they are very concerned about redistributing address space from their own community where there is need to another community where the stewardship might be more open, less restrictive. So they want to make sure that the addresses get used in a way that makes the most sense.

Why has transfers been a problem? Well, it's very similar reasons. We have been doing needs based allocations and assignments since the history of the Internet. That seems to be fair. If you want to do something different, that are needs based there needs to be a good argument for why that's more fair than what we have been doing so it doesn't appear we are changing the ruse of the game so close to the finish line. And the problem is without having an agreement that all the RIRs will continue to uphold needs based policy, it could be changed at any moment. And again people are concerned that resources could get transferred to a region that they are not needs?based any more. And that's kept us from getting global consensus on the previous policy.

So the transfer hook basically allows anyone in the community to write a global or globally co?ordinated policy to allow inter RIR transfers. Feel free to go ahead and write a policy to do such. There are a few of us, Martin Hannigan, myself and Chris Grunderban who have written such a policy and we will talk about that in the Open Policy Hour. But go ahead and put forward one or more global transfer, or globally co?ordinated transfer policies and if those get passed, then these addresses will also be capable to be transferred as well.

So, our approach with this policy was to try to remove the hot button issues. We really want to pave the way to allow RIRs and legacy holders to feel comfortable returning space to the IANA. And we want to make sure there is a mechanism that the IANA has to make allocations going forwards, and they don't get stuck in limbo. RIRs have returned address space in the past. We expect them to continue to return address space in the future, so long as it's not going to make an issue. So long as they can get those addresses reallocated to RIRs. And the concern is a lack of a policy to allow IANA to do something post?depletion may prevent people from returning space, because they have concerns that are either A) will get stuck in limbo or B) the IANA will do something that's unpredictable because we haven't told them what policy to operate under.

It's also important to point out that Interop returned slightly less than a /8 and there was an ARIN press release that said ARIN will accept the return space and not re?issue it for a short period existing operational period. After that whole period ARIN will follow the global policy at that time and return it to the global free pool or distribute the space to those organisations in the ARIN region with documented need, as appropriate."

So we have a real case here of the majority of a /8 being returned. I would feel uncomfortable returning 90 or 99% of a /8 to the IANA if they don't have a policy that allows them to allocate less than a /8 or to do it post?depletion. And I would certainly say that inside the ARIN community.

So in summary, it's conceptually the same as 2009?1. It compromises on the transfer issue. It removes the mandatory return. We have taken out the two contentious points that have been roadblocks to adoption and it insures that the IANA has a policy that they can operate in post?depletion.

Which brings me to the ARIN Advisory Council rewrite. What we see on the slide here it is the extent of the rewrite. You will notice the sentence does begin differently. The original text is "Exhaustion is defined as and the ARIN rewrite says "An RIR is considered at exhaustion when" I don't think that's significant but the words in red are significant. So let me go ahead and read the ARIN rewrite.

"An RIR is considered at exhaustion when the inventory is less than the equivalent of a single /8 and is unable to further assign address space to its customers in units equal to or shorter than the longest of that RIR he is policy defined minimal allocation unit."

The original text said: "Any RIRs" and the ARIN Advisory Council was concerned that if, say, for example, APNIC had a minimal allocation of a /28 and ARIN had a minimal allocation of a /24, and ARIN had less than a /8 that it was holding and the largest block that ARIN was holding was a /25. If somebody came in and asked for a /25, which ARIN does not assign under their policies, ARIN would not be considered in an exhaustion position. That would only continue so long as somebody is not asking for a block larger than that. As soon as somebody comes in and asks for a /24 or a /20, ARIN would have a request that they could not fulfil, in which case they considered exhausted.

The way that the ARIN rewrite says is that somebody would have to come in and ask for the /24 for them to be exhausted. It's kind of a bizarre case. I am not sure why somebody asking for a smaller than the minimal allocation is a problem, but I guess the concern is that that creates precedent that maybe people should ask for smaller blocks.

AUDIENCE SPEAKER: Owen DeLong, ARIN AC. The concern wasn't if somebody asked for a /25. The concern was if somebody asks for a /24, we don't have a 24 to give them. We have got something smaller because it's a fragment from whatever cause, but it's larger than some other RIR's minimum, we would not be considered exhausted under the wording in the original text. Whether that was your intent or not, that's what the words say.

SPEAKER: So the intention of the original text was that if there is a request that can not be fulfilled, then they would be considered exhausted. So if ARIN was holding /25s, and someone came in and asked for a /24 and ARIN had to turn them away, that would be an inability to further assign address space to its customers in units equal to or shorter than the longest of any RIR's policy defined minimum. Because they are turning them away, they are unable per local regional policy.

AUDIENCE SPEAKER: Yeah, that isn't how we interpreted that. So, it's very, very ambiguous the way it was worded. We interpreted it to mean any request equal to or shorter than ?? we would not be able to satisfy any request equal to or shorter than in order to qualify as exhausted not we would not be able to satisfy an existing request.

SPEAKER: Okay, that was certainly not the intention of the policy.

AUDIENCE SPEAKER: But it is what it said. Martin Hannigan.

AUDIENCE SPEAKER: Martin Hannigan. An RIR in that situation theoretically could also lower their allocation unit to address that problem.

SPEAKER: So at either rate it would be important to know how this community feels about both texts because we have some procedural issues and one of the things that will happen is if this community passes different text, than the ARIN community, then the NRO EC and the RIR staffs will have to do a rewrite and they'll have to decide if this issue substantially changes the policy or if it's just for editorial clarity. So it certainly would be important to discuss that here or on the list and make sure that your NRO NC members are aware of how this community feels about the rewrite.

So, for those of you following along on your own slides, this is the text of the policy proposal. There is some URLs in here with references to various things including the ICANN announcement that the RIPE 2009?01 policy has been officially abandoned.

And I'll open it up for discussion.

AUDIENCE SPEAKER: Hans Petter Holen. So address your last bullet first with the two texts. As a non?native English reader, I am not sure if I find any of these texts clear to understand. So, to me it wouldn't be a concern on which one of these ?? I mean, the clarification is quite okay, but the language is fairly complicated and it takes a while to understand what is actually written there. So that could actually be an issue with these global policies as we discussed yesterday with the region policies, that we need to make sure that the language is very clear.

SPEAKER: Thank you.

AUDIENCE SPEAKER: This is Alex from the RIPE NCC, I have a question from the chat, from Votner Hugen. He wants to know how to return address space from no longer existing address blocks. He gave the example of the Unido address block.

JASON SCHILLER: Is that a legacy space?

CHAIR: I think the address space is UREX space, to pre?RIR space. I would readdress that question to ?? do we have procedures to handle if somebody comes up saying there is a /16 lying around?

AUDIENCE SPEAKER: We do have procedures for that without nothing more about the specific address block and everything, I can't say exactly what path through these procedures will take, so I think it's best to contact RIPE NCC or if they are not in the RIPE region, their RIR.

GERT DOERING: They are in the RIPE region, so if they want to return ?? the interesting bit about that is it's not been assigned by the RIPE NCC because it's earlier registrations and stuff. But this is basically I think out of scope of this policy because this is more like RIRs giving back to IANA. I see Wilifred standing there. I have a question of my own.

What are the chances that LACNIC are, is actually going forward with this? Because, if LACNIC says we don't want to have this, we don't need to spend time on this in the RIPE region, because global policy means global policy and if LACNIC is just abandoning it, it's not going to fly.

JASON SCHILLER: So, unfortunately at the last LACNIC meeting they didn't discuss the policy, so it's really hard to tell. The reasons that they gave for not discussing the policy was procedural. They felt this they could not pass that policy because they already had consensus on the previous policy. And this new policy did not update the previous policy. However, the previous policy is now officially abandoned by the NRO EC, so that roadblock should be removed. So they should be able to discuss it now.

GERT DOERING: Okay, thanks. Wilifred.

AUDIENCE SPEAKER: Wilifred, following up on Gert's comment on question. During the most recent tele conference, I was really puzzled by the line of argument from this region that they seemed to be, or seemed to feel that they are not able to modify any consensus they have reached in their region looking at the RIPE region, I would ?? and as I said on the tele conference, I would actually regard that as a local problem. I mean every, each and every region is free to come up with their procedures, how to handle sort of consensus stuff to update at to move with, overtaken by events. Or to whatever. I don't ?? I do see the technical problem that we will maybe not make that much progress within the time frame we have left but I still consider that to be a regional problem of the LACNIC region, very much so, because if this is not going to be resolved regionally, then in my opinion, the whole global policy development process falls apart. Because there will always be situations where we have to modify things because we have to react to the modified reality, and the region has to have some way or another to deal with that. But it's a regional problem, that's my point of view. Just as a comment.

The second thing that was also the original reason why I went to the microphone. Just to clarify terminology you used the term of globally co?ordinated policy very much as a synonym to a global policy. I was involved in one of the first of those globally co?ordinated policies about ten years ago relating to IPv6. I think we should be very careful because a globally co?ordinated policy is none better than any regional one, because it is not rubber stamped, it's not channelled through the global policy process. It is not rubber stamped by the ICANN Board of Directors. So, it is definitely not equivalent to a global policy. And looking back in history to the IPv6 situation, we had this globally co?ordinated policy, how to deal with IPv6 addresses, but later on the regions still had the freedom and did use that freedom to modify the individual components. So, just a clarification. It is not going into the meat on the bones. It's just sort of to avoid confusion here with the terminology. Thank you, Jason.

JASON SCHILLER: Wilifred, I would urge you to bring up that topic again in open mike when we discuss the globally co?ordinated transfer policy. Thank you.

GERT DOERING: I see Hans Petter coming up again.

HANS PETTER HOLEN: I just read the policy again and I was just free thinking about this is does really the policy for returning address space to IANA and the policy for handing out address space from IANA need to be in the same policy document? And are these two actually both regional, both global? Because maybe the return policy could be viewed as a regional aspect and handing out again could be viewed as a global policy. If I follow that line of thought, then your latest proposal is actually in align with that because there is no mandatory return so that's actually up to the region to decide, so it's within the scope of the regional policy, but what needs to be in place and I really support that we need to get that in place as soon as possible, is some way for IANA to actually be able to hand out address space if something is returned. And I haven't really figured out what is the best approach for an RIR when they get back address space to sort of sit on it and hand it out again, or to put it into the global pool and then get something back, because that sort of depends on the speed of requests that comes in. And I can also see that we certainly don't want to have a region ?? one region that sits with a lot of address space reclaimed and we will be able to live with IPv4 for the next 10 or 20 years, well that's farfetched. While the rest of the world is moving to v6. I mean that would actually break the Internet to some extent. So therefore, I think it's more important than we actually get this policy through as soon as possible than to focus on the small regional differences that might be here.

JASON SCHILLER: Thank you.

AUDIENCE SPEAKER: John Curran, CEO of ARIN. What Hans said, the specific question was: Does the policy of returning space to IANA and the policy for issuing space that's returned from the IANA back to the RIRs, do those need to be tied and obviously they don't, but in the past the communities in some regions have specifically tied them together in fact the policy in the ARIN region 2009?3, we suggested breaking them and it was said that this was sort of one whole matter to be considered. I think at the end of the day, each RIR needs to decide whether it needs one policy or multiple policies for this, but it is true that if we don't get a global policy for the IANA to be able to issue fragments of space, then any space returned to the IANA is effectively lost. And that's the thing that we probably want to avoid right now.

GERT DOERING: Okay, so I have heard good arguments why we want to go forward with this. Though there was concern on the mailing list and there was some support on the mailing list, so some wording changes are definitely needed also to ?? we'll make our region happy. I should point out for the record that the version shown up here is not word?for?word identical with the latest version on our web page, but we are at the end of the first phase of the PDP, so we can do wording changes now and then rerun the phases. So, well that's what we need to do now. Figure out what the next version of the text should look like, get it published, and then get it discussed on the mailing list again and try to reach CONS suss on it. Thanks to you and martey to actually taking the trouble to go to the five regions and try to get the regional folks to agree on something global. I have seen this in the past and it's not an easy undertaking.

JASON SCHILLER: Thank you for your comments about the rewrite. Thank you.

(Applause)

GERT DOERING: So, the next one on our agenda is Nigel Titley. On the certification stuff. This has been on the agenda quite a while and so it acquired a nickname.

NIGEL TITLEY: Good morning. This one's been around for some considerable while. I did suggest that maybe we could do it in Limerick format, but it's really more like an Icelandic saga by now. Anyway.

This is the initial certification policy for providing certificates, basically, for PA address space. And we had a number of issues with the previous version, mostly related to the fact that it ties the issuing of certificates to the commercial status of LIR with the RIPE NCC. So, we have actually done a rewrite of the policy to remove this connection and I am just quickly running through version 2.

This policy was actually circulated on the mailing list sometime ago and got almost exactly no comment. So, whether that's an indication of consensus or not I am not sure, or maybe it's just the fact that it's been running for so long that people have lost interest. Anyway. Let's go.

As I said, this explains, this lays out guidelines how LIRs can receive certificates over their PI address space holdings and how they can maintain the certificates. The main points of the policy, and I am not going to go through the actual wording, that this only applies to PA space, nothing else, at least not at the moment. You get certificates issued on request. So we won't force certificates down your throats. You have to actually request them and you'll get them on request. It's done by a secure channel, which is initially the RIPE NCC portal, whatever your views about the security of that particular portal are. They are issued with an 18 month validity. They reflect the registration status. Now, this is the major change between version 2 and version 1. And I'll go into that a bit later.

And if you lose your certificate down the back of the sofa, then you can actually get a replacement, which is nice.

So, let's go through what this registration status means. Basically, a certificate will reflect the registration status of the resource in the registry. Now, because Rob hasn't finished writing his registration status document yet, for the purposes of this policy, registration status is defined as if the resource appears in the RIPE database, then it is registered, and you are entitled to a certificate for it.

So, what that additionally implies is that withdrawal of the record, of that holding from the RIPE database automatically results in that certificate being with withdrawn and that's the only condition under which the certificate will be withdrawn.

So, summary: If there is a record for it in the RIPE database, you can get a certificate for it. And that is basically all that the policy says. And I would be interested in questions, comments in particular, from the room, and let's try and either get this policy killed or get it through to the, to approval. Ruediger?

RUDIGER VOLK: Rudiger Volk, well, okay, seeing no responses in the mailing list, yes well, okay, it may mean consensus; it may mean desperation; it may be just exhaustion.

NIGEL TITLEY: This is IPv4 exhaustion of course.

RUDIGER VOLK: Well, okay, I certainly want to see something going forward here. There is no question about that. And, well, okay, kind of desperation of how long this takes certainly is with me and many parts of the whole picture that we are dealing with with here are lagging behind and are not really satisfying, producing satisfying results. But, when we actually do a thing here, I really want to have the details right and even with this short version, there are a few clauses where looking a little bit closer, I think probably need to be fixed. A very simple thing and probably very uncontroversial is looking in there, well, okay, there is a clause that says this is for LIRs in the RIPE NCC service region. Well, damn it, why? I would say ?? I would think well, okay, why isn't it a RIPE member LIR in good standing?

NIGEL TITLEY: That sounds fine.

RUDIGER VOLK: If it's located in Anartica, well, okay, it doesn't matter.

NIGEL TITLEY: Sound absolutely fine. No problems.

RUDIGER VOLK: Easy example. I have something uncontroversial. For the wordings and details in other parts, well, okay, there probably is more room for controversy, so let me first point out that well, okay, we are actually dealing here in a space where a couple of other documents actually are really important, and you are not to blame for coming up with this text, not citing the appropriate papers because essentially none of the papers have been finalised so far. Applicable papers include the certificate policy that is pending in IETF damned. Building on the CP, there is supposed to be the CPS, well, okay, we have RIPE NCC has been working on and essentially after you put out your proposal, we got a draft that is actually looking nice but still requires looking into the nasty details, and in fact there are some details in the policy proposal which are kind of overlapping what is properly done in the CPS, and we need to ?? well, okay, ?? deal with that properly and well, okay, then I also was extremely happy yesterday to see Athina tell us about the cleaned up clarifications and unified rules for closure of LIRs and essentially the revocation of resources and well, okay, kind of I would really love to see us progressing things quickly and in sync so that we actually can refer to exactly that document if that can be finalised for the revocation thing, and in fact to me, that looks kind of currently the most relevant and well, okay, the reference to a capital letter registry mentioned in the proposal, that's kind of one forward pointer that is not yet satisfied, and I feel the discussions that need to happen there, we should not be waiting on. We rather should reference and see the finalisation of Athina's unified thing from yesterday.

NIGEL TITLEY: Okay. Basically what you are saying is that there is one easy fix, which is to fix the LIR reference. We need to refer out to the CPS and we need also to refer out ?? well we need to refer out to the CPS once it's finalised and we also need to refer out to Athina's revocation and wind up document. Apart from that you are reasonably happy. Rob?

ROB BLOKZIJL: I think if your policy, as it stands now, basically says certification follows registration, then you don't need, in my opinion, to have referrals to bits and pieces of documents that define registration policies. You say: We follow registration. And Athina's document is part of the whole registration clout, which you follow with your certification thing.

NIGEL TITLEY: That was my intention.

ROB BLOKZIJL: In my opinion, you don't have to refer to this document and that document which basically describes registration policy if you say ??

NIGEL TITLEY: That was the hope. The hope was to bundle up registration policy and put it over here and just do a procedure call to it.

RUDIGER VOLK: Direct response. With exactly that wording, I would agree. Which essentially says: Registration, and we actually remove the referral to the not yet fully specified registry thing, and also given the reference to the RIPE database, yeah, okay.

NIGEL TITLEY: I think that's what the policy actually says. If you look at the wording.

RUDIGER VOLK: Well, okay. Remove those references and, well, okay, we may need up a little bit of cleanup where we have overlap with documents that are relevant.

NIGEL TITLEY: Okay, so we are quite close.

GERT DOERING: The policy actually talks about the database. So...

NIGEL TITLEY: The policy says that in the absence of a registration document, then ?? well at least as I envisaged it, I can't remember ?? it's no long ago I wrote it.

GERT DOERING: The says the status of the results in the registry as reflected by the RIPE database. So... maybe... Rudiger's argument has some value.

NIGEL TITLEY: We can tidy that up.

GERT DOERING: Either simplify it all the way down to reflects the status of the registration, period. As Rob worded it. So we might take this from the transcript. Or, make it wait for the complete set of documents and actually refer to the documents. There have been concerns by the members that sort of if we tie it to a closure document that doesn't exist or is not very specific yet, that is danger lurking here.

NIGEL TITLEY: Exactly.

GERT DOERING: If we say it's tied to the registration status, period. It might be wide enough to ??

NIGEL TITLEY: If the Working Group is happy with that, then I am happy with that.

GERT DOERING: I can't say whether the Working Group is happy, because there haven't been enough comments yet. But I think we need to do some wording changes in any ways. There is people lining up.

AUDIENCE SPEAKER: Alex, I want to give some perspective on this. We have been talking about this since 2008 and now we are at the next RIPE meeting and we are arguing over some commas and some wording and what exactly should be in there. I understand that the policy should be very solid and very sound. But right now it's already really limited in scope and pretty restrictive. I mean we are already, as it says now in the policy, certifying a lot less than we could because what we intended to do was have something incremental. Have a small system with a limited feature set and sort of evolve it over time. And expand it with features. Right now the only thing we can certify is if you are an LIR, if you are a RIPE NCC member and you have provider aggregatable address space, then you can get a certificate over that. We could do a lot more. We could do for example AS numbers or provider independent space that has the end user document approved status. We could do all of that. But all that we are trying to do is get a system going where we can get some experience, get some traction where people can actually live on the actual Internet use the system and give us feedback on how to ?? how can it be used in real life? How it shouldey over over time? How the tooling should be implemented within their organisation. If we don't actually move forward with this quickly, we are going to end up in a situation where we have an infrastructure in place, but we are not capable of issuing any certificates at all. There is no possibility to do anything, and I am afraid, I am very afraid that we are going to argue now over detailed phrasing within the policy and we'll be having the same discussion six months from now and then we still won't be able to issue any certificates.

GERT DOERING: I can fully see your point and there is lots of good arguments. The problem is that we, as the Working Group chairs, have ?? if we publish something on the failing list and there is zero comment and we say we extend the review comment and again there is zero comments on it, we just cannot declare consensus, even if we personally like the proposal. We need feedback from the audience, from the community that says go forward or drop it. If there is no feedback we are hanging in limbo. Basically let me repeat this to the audience. If you think this is useful, please say so, say so on the mailing list if we ask for your comments ??

AUDIENCE SPEAKER: This is an excellent summary of the first point.

GERT DOERING: Give us arguments to move forward.

AUDIENCE SPEAKER: Because the system as it stands, when I talk about LIRs, when I do presentations about this, the amount of feedback that I am getting and everybody else who is involved in this project, all of the feedback we are getting on doing this, on having, securing the BGP, the system itself, there is so much positive feedback on it, it's just that people don't respond to the actual policy text, which makes it seem that there is no interest at all, but there is a lot of interest in the system. And people ?? a lot of people are chomping at the bit to start using it. We are going to end up in a situation where we can't because of this discussion. So, I really want to have something simple, something basic out there that is maybe a little bit restrictive, but we can expand it over time.

GERT DOERING: If you are speaking to people and they say we want to have that, please send them to the list so to say so in public.

AUDIENCE SPEAKER: I have done a lot of work on the CPS that is referred to, the Certificate Practice Statement. I just want to respond to the suggestion that we should refer to that in the policy that you say, that you need to say that, because the thing is this is a very technical and mostly operational document that is very hard to read for people who are not experts in this field. And in my belief, this operational document should reflect whatever policies apply. So, in my opinion, the referrals should be the other way around. There is also a section in the CPS that defines how this things evolves. And that clearly states that, well I don't remember the exact wording from the top of my head, but I am happy to go over that with you how this is done.
So, I am afraid that if we send this complete CPS to everybody to review, it would be kind of difficult and not move forward very quickly, although of course the thing has to reflect what policies are agreeable, if you understand what I mean.

GEOFF HUSTON: If I could offer some helpful advice from somewhere else in the world.

NIGEL TITLEY: Please.

GEOFF HUSTON: There are a number of documents around to assist various players in this framework and you can assume, I think quite fairly, that those other documents are written responsibly and maintained by other people, and that's a fine thing and you don't have to worry about it. The certificate policy statement is actually about when I get this certificate and I am anybody and I see one of these artefacts, what does it mean? What can I use it for? Can I use it to do my banking or not? Can I use ??, you know, what does it actually say? Not our problem per se in this room. There is a practice statement, every single CA, or a certification authority, someone who issues certificates, should maintain that practice statement. That's an operating statement about what do we do when we issue one of these certificates? How do we go to the vault? How many people have the key? From a policy perspective, not our problem, per se. It's the folk who actually run the machinery and you can leave that to the NCC to describe what they actually do operationally. And then there is this other area that we are grappling with, what are we trying to do here? And I think what we are trying to do here is say to the NCC, you should certify stuff. In fact, what you should do is certify what's in the registry, certificates follow registry. So, if the essence of what I heard there were those three words Nigel, then those three words encapsulate precisely an adequately what you need to say. So, my humble suggestion is don't try and incorporate things by reference. Leave other folk do whatever they need to do as well and come up with a very simple guidance to the NCC to say, on the whole what we are talking about here is please, certificates follow registry, do the right thing.

NIGEL TITLEY: Thank you, Geoff. Rudiger?

RUDIGER VOLK: Well, okay, let me start with Tim. Well, okay, Tim, my main point, my main point when reference can the CPS with regard to the policy proposal was that there are things that are in fact overlapping. The validity period actually is in the CPS and it's here.

NIGEL TITLEY: So we can take it out?

RUDIGER VOLK: Well, okay, kind of one has to be aware, at least, that it is overlapping, and that's actually a nice and simple thing where kind of I can point Geoff to, well, okay, actually in the CPS there are things that probably are of concerns that, concerns of people who should be looking into the policy and agree to it. Yes, indeed, there are lots of tedious details in the CPS that nobody really wants to look into, and I am very happy that the NCC takes away the pain of dealing with the details. Nevertheless, the CPS in fact has a large part that defines the service of this certification authority and as such, I think it actually, some members scrutiny is justified there. So, well, okay, I would ?? I certainly would not want to see a big discussion as a prerequisite for passing the policy, but being aware of what's around I think is important and going forward, someone within RIPE or within the RIPE NCC membership actually needs to look into it and ask the details, okay we actually haven't done that right. For getting forward, getting back to Alex, yes well, okay, again, I am ?? I really want this progressed. It needs to be right. I think with this proposal, only really minor details need to be fixed, in particular after we even have ?? we even have agreement on some wording with Rob, and there is lots of other work and Alex, yes, I am damned aware that this is a bare minimum of what we can do and two years ago this would have been kind of a great thing to pass through and get started. At this time this is an absolute minimum and I seem to remember that some people have been standing up within RIPE meetings for a couple of times and asking well, okay, what's the road map for getting the other things done? Well, okay, right now, we are really focused on getting the simple first step done and getting it done right. And there is not really that much missing and to be fixed, and I would hope to see this pass through pretty quickly now.

NIGEL TITLEY: Could I just make a comment please? Could people watch the mailing list please and if they have comments to make when new versions of the policy are proposed, please can they make them on the mailing list. Because nobody made any comment, Rudiger you did not make a comment. And now you have derailed this proposal again. No offence meant, okay. And we have got additional time to wait. So, can people please make comments on the mailing list. I am fed up to the back teeth with this policy to be quite frank. I would really like it to get through. Thank you.

GERT DOERING: Okay. So what I propose to do is the following: You two get together in the coffee break, agree on the text. Send the new text to Emelio for 2.1, we do a quick two?week review phase. Rudiger actually speaks up on the mailing list and says he is going to agree with the proposal, and certainly I would welcome somebody else to actually stand up and agree or disagree or at least comment on it so we have some guidance to how to go on. But well, if somebody agrees and everybody else is silent, I tend to see this as a ?? if nobody says anything, we can not go anywhere. One last quick comment and then we need to go ahead.

AUDIENCE SPEAKER: I just want to support Nigel here fully. Once upon a time this was Working Group. That meant we had to do some work if we were here.

GERT DOERING: Then you installed the formal process and since then we just shuffle documents. Thanks for appearing with us.

I am not sure whether you have seen the fine print under this. It says also known as the Iceland I can saga. So this is something that goes goes on for ages. So now we are at the next Icelandic saga, but I think we are seeing light on this and Sander is going to just wrap?up what the status of affairs is on the last /8 and how /O move forward.

SANDER STEFFANN: Well this is, and it has been a kind of a saga, but it seems we are getting there. This is ?? I'll wrap?up the history. First we had one proposal on the last /8. Then we got another one. They both didn't get consensus. Finally, after a lot of work, all the authors cooperated and came up with this final one. And we had some ?? a lot of discussion about this on the mailing list. So it was not an easy one. The most of the points have been addressed and one of the things that we still had some worries about were the comments from Martin Hannigan, so, Martin, would you please give your standpoint on this proposal?

AUDIENCE SPEAKER: Martin Hannigan: So, I think as you saw on the mailing list, I have opposed this proposal on multiple grounds. I think that it's a marketing proposal for the most part in that it does more damage than good. Eventually, small networks are going to pay. These addresses are going to be turned around and sold to the bigger networks at a height err cost and it's disruptive. But, if the room really wants to go forward with this proposal, that's fine, I am not going to stand and jump up and down. If this is really what you want, I think that you should go ahead and do it. Thank you.

SANDER STEFFANN: Okay. Thank you Martin. So, based on the other comments on the mailing list, it seems like people do want to go forward with this. So, I suggest we move it to a last call and see if there really are no strong objections. So, I don't know if it will successfully pass last wall, but that's what last call is for. I suggest we just move forward and try to get this in place.

GERT DOERING: Yeah, well that's basically what we agreed on before. We said we had support, we had a voice that could be read as opposition, so we asked Martin to clarify his position, which he did, thank you. We put it to last call now. And send a mail to the list explaining why we are doing it this way. Thanks for summarising and wrapping up. So now it's Jason and martey again on the transfer thing, so we are in the AOB section ?? well open policy actually, not AOB yet. This is not a formal policy proposal yet, it's just trying to get some feedback. I see the two proposers haggling on who is supposed to be up here. Okay. Martin.

MARTIN HANNIGAN: Good morning everyone, or bon giorno, grazie, per a vini. But that's about the extent of my Italian, so I'll stop mutilating that language.

So, ARIN proposition 11, globally co?ordinated transfer policy. Basically in the ARIN region we submitted a globally co?ordinated proposal that will allow RIRs to transfer address space between them. Why globally co?ordinated versus global policy? Global policy is one from our experience with the presentation that Jason made in the proposal that's been submitted in all five regions is extremely difficult to navigate, we found. Two, it's also really difficult to make changes, so if something transpires a long the way that we may need to make a rapid adjustment, global policy through ikit is not the way to do it.

So, a small bit of housekeeping. It was submitted in the ARIN region 11 October. It was revised by the authors on the 27th. It's on the ARIN AC's docket. Chris Grunderman, myself and Jason Schiller are authoring this. The text is straightforward and simple and deliberate. Any RIRs... addresses to the resource registrant of another RIR as long as the two RIRs agree and exercise Internet stewardship an the volumes expressed in RFC 2050. The ration it also makes sense to be able to transfer between the regions as well. If this was adopted, the timetable for implementation would be upon the ratification of all five regions. A little twist here. The timetable for deimplementation would be as soon as any RIRs changes its text in another region.

There is an URL to the policy text itself. But that's it right there on the screen.

So, the direction: And why we are here at other business.

Wanted to support the ability to transfer addresss from those who do not need them to those who do, even if it is across across RIRs. This should add liquidity and allow us to do things like rejoin disjointed blocks in other benefits that can be economic or technical. We wanted to keep the proposal simple. We just wanted to allow the RIRs to be flexible in what they need to get done and we think that this could be a proposal that's so complex we could write epic novels about how to do this. And we think that the staff at the RIRs are probably best suited to take care of this and make it work in the interests of our communities. And we also wanted to uphold the principles of Internet stewardship and specifically that is not the right RFC, and we up loaded the slide to fix that and I do not know why that's there. So I apologise. But it is RFC 2050 and I think you probably all know that.

So, we don't have anything to sell you. We don't have a pitch. This is not a global proposal. It's a suggestion for a globally co?ordinated proposal. Will it work? Do you have any benefits that you can tell us about that may make us rethink this proposal? Is it needed in the region? Is it not needed? We plan to take all your feedback and review it and submit a policy proposal. It's already submitted in the ARIN region. We'd be happy to work with someone locally and if someone in this region is interested, we would much prefer that someone local actually submit this and work with the community to get this done.

And that's it. Any thoughts?

GERT DOERING: Thanks for bringing this forward early so we have sort of like early influence before we go into specific text and. This is already foreseen according to your presentation.

WILIFRED: But one of questions here structurally would be it was too quick on the screen, I didn't think to the bottom of it. Was this provision that it gets deimplemented, or whatever the proper English word is, it gets de? implemented as soon as one region changes their regional stuff. Do you also, or is this to be interpreted that if out of the five or maybe more than five in the future, one of the five regions changes their local version of this thing, that this particular region would be excluded from this mesh, but the remaining ones could still continue to play that game? Or do you propose to actually sort of cancel the whole thing and go back to square one?

SPEAKER: It depends.

AUDIENCE SPEAKER: Because my personal preference would be I think it would be a much stronger incentive not to mess around if we would have the situation that the region which starts to do silly things just gets separated from the rest, which is still working, according to that.

SPEAKER: So with respect to changes, Wilifred, minor changes like adopting language and cultural performance of the text itself would not be a reason to deimplement. For example, if a region changed the proposal to say something like "As long as two RIRs agree to sell all their address to the highest bidder" of course, you know, any region that would choose to, should deimplement the policy, the proposal. Jason, would you like to say something?

JASON SCHILLER: So, the idea behind this was that the friendly way to change it would be with another globally coordinating policy, so that the text changes are the same across the board. The idea here is if one RIR decides to not play by the rules of Internet stewardship in 2050, that the text would get yanked from all the other regions as well. They would be free to pursue bilateral agreements and we establish relations that way. But because this plays into the global policy for redistributing space through the IANA and the IANA making allocations post?depletion, it's important that this policy text get removed across the board, because if it doesn't, if it only gets removed by the one that opts out, then we are still going to return ?? we are still going to try to return stuff to the IANA and that could still get redistributed to the one that has opted out. So if this becomes linked to that global policy, the intention would be that when one RIR vetoes the policy stops everywhere.

SPEAKER: Thing in short what we are really saying, to kind of give that a summary is we expect that the community will work together to make this work if they think that we need it.

RUDIGER VOLK: Thank you. The last slide, the lodgistic thing or the wording thing, we should probably not expect that RFC 2050 will be there until the end of times. So we might want to think about some minor phrase like "Or a successor of 250 which describes the same goals or contains the same ?? you know what I am at? Because RFCs can be superseded by newer ones. It's probably not going to happen quickly with this one, but it might.

SPEAKER: I am going to point out out than gets RFC 2050 and we did upload the right slides. These are the old ones that we deleted. I think what this text says Wilifred is ?? even if RFC 2050 is depricated, the principals would not be depricated. Just because the IETF says let's get rid of 2050, it's old and outdated which I think to some extent, 2050 is aged, but I think that the interpretation could be updated with how we decide to implement this proposal and, you know, things change and that's the idea behind having a globally co?ordinated if something changes significantly with the way that people want to interpret 2050, we can either update 2050 through the process of the IETF or we can just update the interpretation. Hans Petter?

HANS PETTER: Hans Petter speaking as a member of the address Council since 1999. The first task of the address Council was actually to write a replacement to RFC 2050. We had a Working Group that worked on that for years. In 2003, I think, I found the minutes from the address Council meetings at the time, we had a discussion on how to proceed with that work and we decided to stop it. One of the things that had also happened at the time that there had been an exchange of opinion with the IETF and the IETF at the time did not think that they were the proper place to have address policy documents posed.

SPEAKER: They think it's the proper place today, that's for sure.

AUDIENCE SPEAKER: There is documentation from from that then that that was not the place. If we then look at other things, there are significant parts of RFC 2050 that has been replaced by global policy and by regional policy. So, while I like the formulation to keep with the values of 2050, I think because that's important and I think we can identify those values and we can sort of put them up in a separate document, so that we keep those values, I think that's important. But, as far as when I started to read through old documentation, there has been a lot of discussion on this and what we are probably also touching here is some key points that the regions does not agree upon. So, if you push this too hard, you would actually identify the disagreements in the basic principles of stewardship of Internet address space and the question is: Do we want to have that in the open or do we want to have that discussion later? I don't know.

SPEAKER: Thank you very much. I appreciate your comments and I want to be sure that one of the things that we don't do is get too hung up in RFC 2050 specifically. It's more about the idea of 2050 than the actual content of it. The 2050 gives us the foundation of a framework to work together and that's really what we intend to say with with our reference to 2050 is that the system has been open and transparent and that we have worked together for many years. John?

GERT DOERING: I just want to interrupt. We are running a bit short on time. Two more comments. I see John standing here and George Michaelson was up on the other microphone. Maybe one last comment from the two other regions would be appreciated and then we go ahead and take this to the list.

AUDIENCE SPEAKER: I just want to say with respect to 2050 it's RFC 2050 and it's also ICANN global policy I C 2 which was the policy for recognition of a regional Internet registry, both call for address conservation, so, while it is possible that RFC 2050 would be revised to have new principles, it's actually revising that and then revising what we tell ICANN is the nature of a regional Internet registry.

SPEAKER: So just to be clear, we have no intention of changing 2050 but if the five communities told us to go do that, wee would probably go ahead and do it.

GERT DOERING: George, are you going to comment or is it just ??

Okay, then we have nicely ended the discussion anyway due to lack of more comments. And I have some doubts on whether this is going to smooth but we should try. So thanks for bringing this up. We'll bring it to the mailing list and see how it goes.
(Applause)

GERT DOERING: Okay. We have AOB on the agenda next item. And this time we actually have two small things here.

In discussion with people two things popped up, and one of that is confusion about the way the NCC does PI requests when there is potential for aggregation. The issues you have a /24 PI, you go to the NCC, fill in a new form say, okay, I have enough demand for another /24, and since aggregation is useful, I return my old 24 and get a 23 from the NCC. This sounds sort of like logical and useful and the NCC doesn't actually do this. Since this came as a surprise, it was brought to me. I talked to Alex, they have a very good explanation and we just want to make this publicly documented which is why we are bringing this up.

SPEAKER: Okay. I can see how it can be surprising that we don't want to take the old /24 and give you an aggregatable block. It's in fact what we used to do. We didn't often get requests like that because usually people did not want to give back their old /24 because they have PI space for a reason. And then over time it was being noticed we saw more and more and more and more of these requests and then something else happened. We take back these /24,, they call go in quarantine for three months and then we give them out again and those people came back to us and said I can't use this block, it is on every spam block list in the world. And then we started to look into it and we looked into all these blocks that they wanted to return for a while and we saw that practically all of them turned out to be used by spamers and Fisher's and lots of people like that, and they just thought oh, this block, it distinction now, I need to give it back, okay. They often tend to have some money as well, so they can usually buy more equipment justify a larger assignment, so they request their /23, they give back the /24 and they have a brand new block and it's even twice as big. As we looked into it, we actually saw that they came back and then they came back again and then they tried to come back again. And because it's actually quite a lot of work to really investigated what's going on when we get such a request to return, to swap a block for a larger one and because the actual legitimate guys were very far and few in between, we decided that to just not do this any more for PI space. Because it's just operationally investigating every single one of these and then in 90% of the cases go, no you are a spammer we are not going to do that. That it's a lot of work operationally difficult, so, we decided okay, let's do it just the same across the board.

GERT DOERING: Thank you for the explanation. I see one comment coming from Owen.

AUDIENCE SPEAKER: Owen DeLong. It occurs to me that it might be relatively easy when somebody offers to return one of these blocks to look and see if it's on a blacklist, not for the purpose of determining whether you want to take the block back or not but perhaps this leads to wanting to reconsider whether you give them a larger block or another block to add to the block they just polluted.

SPEAKER: Well, this comes up once in a while, and I have gone through all our policy documents and if somebody comes to me and tells me I have a bunch of servers and I use them to send lots of e?mail and my servers need address space, there is no basis in policy to deny them an assignment.

GERT DOERING: Okay, two more comments and then we have another issue, otherwise I will run into coffee break.

AUDIENCE SPEAKER: I am going to be short. You might want to look at a presentation that was done at the last RIPE meeting about some statistics on what we see with these address blocks. So, you can hook up the presentation

RUDIGER VOLK: Alex, when someone comes in with such a request for changing to a new block, even if there is no policy defined yet, I would think you could actually ask them if you want to have a new block, if you want to move, please give us some statement that, well, okay, you haven't been causing trouble, and if it turns out they have been causing trouble, well, okay, they will be revoked, the LIR will be closed because of breach of contract.

SPEAKER: This is PI space so usually we are not talking to LIRs. And I guess we could look into it.

AUDIENCE SPEAKER: Generally I agree with these comments words to going after the bad guys and making life hard for them, but let's be careful here. There are many circumstances under which you can show up on one of these lists. Some lists are a bit better than others. Also doing the cleanup, maybe you show up in a list because someone hacked the server and then getting off the list, have had experiences that is nearly impossible because the list generateers have their own view of the world. So, let's ?? I agree with the general principle, let's go after the bad guys but let's be careful about after you go after the bad guys.

SPEAKER: Let me just make it straight. We don't deny them any new address space because they happen to be on the list. That can happen by accident, etc. It's just because it happens so much, we don't take back a PI block and give them an aggregated block for anyone. So...

Can I make one small announcement. There was a discussion by the IXP, interpretation of the IXP policy in IPv6 yesterday. I just got confirmation from Amsterdam all our procedures have been updated to reflect what was decided yesterday.

GERT DOERING: Thank you very much.

It's actually Joao with another thing that we might want to think about.

JOAO DAMAS: This is more a get a sense of the room because policies are written in terms of human languages and human languages are not universe, so there is room for interpretation. I just put up a little drawing to try to explain what this is about.

The box outside that defines the realm of ownership of equipment. What's inside is equipment. The pentagon is the infrastructure that you use to run your network. The circle are the PCs next door in the office next door, and there is a network box in the middle. This is a typical IT scenario and you can see if you get PI space for this. Giving addresses, that depending on people give addresses to the circle people is not (the pentagon) ?? the pentagon and circle don't need to be pointed out really. There is no splitting of the address space of the PI address space, right.

Now, the employees are in the same organisation. It's a switch. What if we start changing the colour of the cables? The office is a little bit further away, so beyond 100 metres that UTP 5 gives you and you need to put DSL router or a met owe Ethernet. Does giving the addresses to the circle (metro) become a circle or not, I think not. What have what the organisation is doing as an IP services company is doing is actually installing this stuff for people outside the services company to use? So basically, my customers are small companies that don't want to run, have the burden of running their IT equipment, so I bring my network to them. I give them PCs, printers, blah, blah, blah, I retain ownership of everything. The network is mine. I am using long distance equipment to provide access to them. Is this a subassignment or not? In my view it's not. In other people's views it seems to be. I would like to have a sense of the room.

GERT DOERING: Well Joao brought this up to me. I said this is somewhere in the middle between policy and procedure, and well, the NCC disagrees with him on well what sort of addresses should go where. Andrea has mentioned yesterday in the NCC Services Working Group that the NCC is going to publish very detailed checklists, how they evaluate such requests. So, Working Group see for our own ?? what the rules, or why something is considered your own network and why it is considered a customer network. But we still decided to just bring it up to raise it. I don't think you are going to have a big discussion now.

JOAO DAMAS: The reason I brought this up actually was because this thing actually happened in conjunction with the previous point. And I was being told, never mind, I'll not give you the /23 or two /24s, which was the address space that was enough to provide a service in a region all the time. If you come in the LIR I'll give you a /20. I am like okay. So, I just need a /23, you are not giving me these, but if I give you money, you give me more addresses that I don't need, and when I say ?? when I couple this with I actually want to give you the /24 and you get a /23, not only do I try to conserve addresses and I try to conserve aggregation, you told me no. I think, this is kind of odd. I perfectly understand the explanation that Alex just gave for the non return. I wasn't aware of the sort of problems. So that's just totally fine. It was a surprise. But putting the two things together, it seems that the ?? asking me to use up for addresses than break aggregation and those two things together just made me ask for space in AOB, because it's like, I can't understand what's going on here.

WILFRED: I think this is one of the very nice examples where we made a big mistake in the past when we wired abbreviations, technology, particular configuration situations into the policies which actually got translated into procedures. These times, this day it's just funny, but a while ago I triggered the host?masters to apply the DSL stuff handling of an address space request because I was stupid enough to tell them that the link, the physical implementation of a link between the backbone and a sizable piece of domitories was actually DSL. Do you know? It could have been metro Ethernet T could have been messenger pigeons, it would not have triggered the handling of this request as a DSL mass market end user request. I think there are ?? these things happen. And in the future, we should be very careful also with regard to the surgery project, we should be very careful not to perpetuate these things because weigh want to have the host masters to adhere to the rules and to implement the policy but we don't want to have them tied down doing stupid or silly things because we have written it one way or another. Thanks.

GERT DOERING: So this is why I actually think that the NCC going forward and going to publish the evaluation guidelines in a very transparent way, this is how we do it and if you don't like it, come and talk to us. I think this is going to really help.

Make this confusion understandable and maybe give you folks a chance to point there and say no you are reading this wrong. This is not really a DSL request, even if it has the words DSL in there, it's not DSL.

So, I think I am really looking forward to see these guidelines appear and then we can see whether this cleans up everything.

Alex: I'd just like to add there is the is it an end site, is it not an end site. It's a very difficult sometimes to figure out exactly what it is, because it's about how the technology works, it's about the organisational structure of something, it's about the economic structure of something. Everything comes into it. So, we are going to publish how we look at this, at these things. I can't really give it to you now because I could talk about it for half a day. And then I am definitely looking forward to feedback from the community about, you know, how we should approach this, because I think when the policy was written, there was quite a bit less virtualisation going on and all these things. So technology has changed quite a bit.

GERT DOERING: Thank you. That's the end of the Working Group.

JOAO DAMAS: Just an apology. The reason this slide is not showing up in the session slides for to you download is not that the RIPE NCC is trying to hide it from you, is that I made a mistake. I put a question mark because I titled it as a question and obviously I should have been known better but question marks have a meaning in UNIX system so it broke the upload system. It's not their fault, it's mine.
(Applause)

GERT DOERING: Okay. Thanks for bringing this up. Thanks for being, all of you being open about things. Thanks for your feedbackment thanks for good discussions, even on Thursday morning at nine o'clock and enjoy your coffee. That's it for today.

(Coffee break)

LIVE CAPTIONING BY MARY McKEON RPR

DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.

WWW.DCR.IE