These are unedited transcripts and may contain errors.

Plenary session on 17 April 2012, 4 p.m. to 6 p.m.:

FILIZ YILMAZ: All right people, hello, good afternoon. Let's get settled. We have a busy afternoon session starting with two lightening talks, then two regular talks and then a panel, which will then be followed by a BoF and then a social and everything is back to back, so let's get the coffees, sit down and I will call for our first presenter, Sandra Brown. Shell be talking on an IPv4 transaction.

SANDRA BROWN: Good afternoon. I am from the IPv4 market group and before I forget, I have a few fliers on the topic I am going to speak to so if anybody wants to come and get one after I speak, feel free to grab me either right after the presentations or any time you see me in the hallway.

I have to admit I am feeling a little bit like the odd person here because all I hear is have you put IPv6 on something today, or are you ready for IPv6? And I am talking to you about here is where you can get some IPv4 addresses, so I am a little bit different.

So, what I am going to talk about is the IPv4 transfer process, how to obtain more IPv4 addresses. So I guess first of all, if you don't feel the need for IPv4 addresses you can probably tune me out. If you have excess IPv4 addresses you probably want to listen because I will tell you how you can monetise them.

So I think that is probably a good intro.

I thought what I'd do is start off by showing some interesting statistics on where the IPv4 addresses are, and why, in my opinion, at least, RIPE needs an Inter?RIR transfer policy, and this slide clearly shows that in the ARIN region, they hold the highest concentration of IPv4 addresses per capita, at almost five, and you can see this compares to about .8 in the RIPE region. And the rest of the world trails dramatically from these two.

This slide shows that in response to the question: Why do we need transfer policies? The simple answer, and it's because the RIRs have run out. As you probably know in February of 2011 IANA allocated the last of the five /8s to the regional RIRs, including RIPE, and RIPE down to its last /8 and the last I rid is projected to be out this summer, I heard August but probably people know far better the exact date. I think the point is once RIPE runs out where are you going to get the IPv4 when you need it, and with only .8 IPs per user in the RIPE region and five in northern America, many of which are dormant, by the way, it makes sense to allow transfers from the ARIN region and between regions.

So, what is the current RIPE transfer policy? As you may know, I am one of the people working to update the RIPE transfer policies, and tomorrow morning at 9 o'clock, beginning with proposal 2012?01 we have an Inter?RIR transfer policy that I am going to speak to tomorrow morning, and a couple of other people are going to join me, and the current intra RIR transfer policy, it's documented in Section 5 .5 of the RIPE IPv4 address policy, and the core pieces of this policy are the recipient must demonstrate need and you can't reallocate the blocks to another LIR for a 24 month period and most importantly, the transfer blocks are treated no differently than a block assigned directly by RIPE, so I think that is an important point, and I think it's something we need to talk about within RIPE in the future, because when a company pays for a block and that is what is going to happen when you do a transfer, and you don't obtain it for free any more the company might like it to be treated a little differently, so that is not the point of my talk but I just want to mention that point.

And the next slide is the core of my presentation, and it's the steps to a successful IPv4 transfer. So first, for whatever reason the transactions are usually under a nondisclosure agreement. I think that sellers don't like it to be known they are selling their IPs. I have seen some of the companies are under financial trouble, the early companies cog it, and buyers don't like it to be known that they are buying, for other companies to start buying too and push the prices up. I think it's a scarce resource and therefore there is a lot of secrecy around it right now, and I know that makes people nervous because then people say it should be more open because I know there is a lot of openness in the Internet world but the reality is that people tend to be very closed about it and I think that is just because they want it to be kept quiet.

After your under NDA the buyer receives information so you can see the chain of custody and feel comfortable that the blog is registered to who they say it is to, and also that it's not blacklisted. Then the buyer prepares an offer, usually at the price they are prepared to pay, and the offer may be verbal but often is formally presented in a document called an Asset Purchase Agreement, and in the APA, the Asset Purchase Agreement, you also document other negotiation points, something like when do you want the transaction to close, what are the payment terms, will there be a deposit, how the transaction will be taken through the RIRs, and how the transaction will be registered to what company and so on. So IPv4 market group, we require all our transactions to go through escrow and that is for the safety of all the parties involved, the buyer deposits the funds at the beginning of the transaction and upon close the funds are released to the seller. This guarantees the funds are available and also ensures the funds are released only if the IPs are correctly transferred and useable. All the RIRs we deal with currently have a needs justification step and that means ARIN, APNIC and RIPE.

The seller's required to provide an affidavit to declare that the block is being transferred to the buyer and after all this Administravia, the registry transfer happens so we have done lots of intra within the RIR transfers within North America. It's quite straightforward. For an Inter?RIR transfer I am told they are going to mimic the ERX where the sending registry points to the receiving registry.

The IPs are then routed and announced by the ISP of the receiving company. The funds are released from escrow and the seller is paid.

So my final point, I thought that you'd be interested just in prices a little bit; I can say that this is a view of US pricing only since we have done transactions in the US and a couple in Asia and I think the demand equation may flip when you start to see Inter?RIR transfers so we will see. I want to mention too that this north tell Microsoft transaction is kind of personal for me, my history was I worked at nor tell for 15 years and orchestrated and led the project that brought about this first transaction so that is how I came to be in this business. With with that, I will take any questions.

FILIZ YILMAZ: Any questions for Sandra? This is not controversial at all any more?

DANIEL KARRENBERG: RIPE NCC. I have been waiting for ten years for this kind of presentation here, I am actually quite happy that it only happens now, that we are almost run out of the unallocated pool. My question: What kind of databases and other information are you usually using when finding out, I don't quite recall how you call it, whether a block is good in the sense of useable and whether the seller actually has the title to it, if we can call it title, and how important are the RIR registries in that process?


DANIEL KARRENBERG: Yes, for you, and of course, since you are sort of a matchmaker also for the seller and the buyer.

SANDRA BROWN: For us the RIR registries are very important. We look at how the block was initially registered in the RIR. If the company which currently claims to hold the block does not still exist or there is a downstream company holding the block then we go through what we call the chain of custody and do a lot of legal research through the court system, the merger and acquisition system looking at certificates of merger and acquisition and so on.

DANIEL KARRENBERG: What other sources are you using sort of to make it ?? to check the bona fides and the usability of the address block or is that for the buyer to do?

SANDRA BROWN: No, it's not for the buyer to do; it's for the seller to prove, and as broker with a seller under contract, we work with each seller individually fending on the circumstances to be able to prove certifiably that they are owner, and they weren't able to prove and we walked away from them.

DANIEL KARRENBERG: OK. And other than title, you mention black lists and things like that; how are you doing that? Other than title, I mean usability,

SANDRA BROWN: To say ifs on a black list

DANIEL KARRENBERG: Black list and routable ??

SANDRA BROWN: For black?listing you can do scans.


FILIZ YILMAZ: Before the next question, can I just mention that we are really running out of time so I will just close the queues for the mike, the three people here. Thank you.

Paul: Paul Wilson head of APNIC. I don't so much have a question as information I would like to provide to the audience here from APNIC's point of view on transfers if that is all right. We ran out of our conventional supply of v4 for infrastructure space just over a year ago. The anniversary was the day before yesterday. Over the last year we have been gearing up towards more and more transfers and having just come to this meeting from China, which is still booming in a way you wouldn't believe, I could see a lot more activity coming up so I think it's a very timely presentation here.

There are two things that we have done at APNIC over the last year in preparing for an increase in transfer activity. The first of those is actually about the request process because we did change our IPv6 transfer policy to require demonstrated need to be fulfilled before a transfer could be approved, but looking at the timing aspect this is something interestingly you didn't touch on here, Sandra, is that the request process can be a long process and it's an indeterminate process and we have expected that people with addresses to sell would not want to be committed to a particular buyer who then had to go through a long justification process, so what we have got is what is called a pre approval for transfer and what someone who is seeking address space needs to do is simply come to APNIC and go through a process which is exactly like the old address request process of providing the information that justifies their need. Once that has been assessed and the host masters have come to a conclusion then what the applicant gets is a pre approval for a transfer rather than an allocation of a certain amount of addresses, and then that is something that we expect the buyer can then use to go out and sort of demonstrate that they are really ready to actually receive the address space in the short?term and that pre approval will be valid for up to a year and then need to be refreshed in order to be extended. And we expect a listing service to actually be available to provide a list of all pre approved transfers and the ability to contact without providing details, the ability to contact the holder of that pre approval for anyone who wants to look at what the pre approvals are that APNIC has got. How we have planned the request process. The other one is look at an agreement, a binding agreement, a contract or MoU with brokers in which we will seek the brokers' agreement to comply in every respect with APNIC policies to ensure that the people they deal with on the buying and selling side also are complying with APNIC policies to conduct themselves in every respect in compliance and providing they do that, then APNIC will have happy to deal with them in terms of referrals and listing. So that is something in the the pipeline at the moment. So that is just an update from APNIC. I am not going to give any figures right now, but I do have the red eye slot on Friday morning and so all of you can come along at 9 a.m. on Friday morning and here my report from APNIC.

FILIZ YILMAZ: Thanks, Paul. If anyone is interested into the details, please go and find Paul and talk further on this.

AUDIENCE SPEAKER: I understood that the buyer needs to justify his needs for the RIR in his region in order to actually get the transfer completed, and those two public sales are in the ARIN region, and ARIN still has addresses, I cannot comprehend why would they buy addresses when they anyway need to justify their need and presumably could just get them for almost free from ARIN? I don't understand. I can understand that the buyer would want to buy in the APNIC region but why do these things happen in the ARIN region?

SANDRA BROWN: If I answer that question it will go on public record. My opinion is there anyone from ARIN here who wants to comment? I have an opinion which is that when a transaction is under bankruptcy ARIN knows it has jurisdiction and the companies know as well and therefore, the companies bought them knowing that ARIN could stop them from buying and not going through the justification process and ARIN didn't blink. That is my opinion.

AUDIENCE SPEAKER: Leslie Nobile with ARIN. There is a couple of reasons why people are not coming to ARIN. ARIN's policy has changed and ISPs can get a three month supply of addresses from ARIN directly when they come and apply and through the transfer market it's right now, through the transfer poll seats a 12 month policy so that is attractive to big businesses who are looking for space to grow their business. That is one of the reasons. As far as coming to ARIN directly from out of the region, ARIN is a regional Internet registry, we issue space to organisations located within the ARIN region who are using space within the ARIN region, so if someone from China came in and didn't have a legal presence didn't run a networking, we would not issue space to them.

AUDIENCE SPEAKER: Nigel Titley, speaking as one of the authors of the transfer policy in the RIPE region. A couple of points that you may not have considered: One is that we can only transfer PA space within the RIPE region so legacy space is specifically excluded. And secondly, all transferred space must be certified. So that that actually makes your process a little bit easier because certificates will have to have been issued for spaces being transferred. You may wish to speak to me about this afterwards.

SANDRA BROWN: We will cover that tomorrow morning in the transfer policy discussion.

NIGEL TITLEY: Yes, I am describing the policy as it stands.

FILIZ YILMAZ: Thank you, Sandra. And I understand you are around and further questions can be carried out address policy Working Group or maybe even Friday.


FILIZ YILMAZ: We have Matjaz.

MATJAZ STRAUS ISTENIC: I work for Slovenian national research and educational network and I will give you another IPv4 talk, I guess. Have you been DOSed recently? Because we were. And we want ?? we dislike the idea to buy expensive DOS mitigation and DOS detection equipment, we all have routers, so we decided to use these routers to DOS detection, at least to limit the traffic of DOSes. So most of the traffic in Internet is green. I would believe that Randy will dislike this because it's pink, yes, Randy. Most of the traffic is green but there is also some red traffic inside of it. Most of this is a very important but it's much less in volume, yes? But some of the typical DOS attacks actually uses the red traffic. Take as an example that the DOS red traffic arrives to your network and you can easily separate this into a green part and then the red part you classify. How do you classify this red traffic? You might take, for example, the last ten bits from the destination address and these ten bits will make an index into the bin that you will put this red traffic into. So, for example, the address 1932166, which is the most famous address in Slovenia, goes to bin number 322. And each of the bins ?? you classify this and put into the bins. Each of the bins runs its own policer and you police each traffic inside of a bin. So then you combine all of this, the DOS traffic becomes pink. Sorry, sorry about that. So policing and combining and it goes pink.

What is typical red traffic? It is TCP SYN packets, RST, mostly UDP you can find in most DOS attacks, tiny packets only UDP header, maybe one byte more. You can find also huge packets like MTU sized and some other UDP packets, tunnels and some uncommon protocols. Most of the traffic is TCP established anyway. You can find fragments inside of it and ICMP and also use this technique to protect campuses, for example a major networks with lots of individual users like student campuses.

There is example on, for a Juniper, it's called prefix specific policing. It's a very rather easy to configure. For the bottom left, you define the policer, you defined the bandwidth limit, the burst size and use this policer in the site of a prefix action policer and use all that have inside of a firewall filter. So this can be efficiently used to prevent the impact of DOS attacks and routers can do many more things than just route packets. That is all from my side. Any questions? And it's IPv4 only, sorry, guys.

Alex: How you divide traffic in classes? This is clearly, may be exploited by attackers. I understand protection but still, if you want to destroy your protected service for, say, Slovenia, just select ranges and destroy it. So target is destroyed, mission accomplished for attacker.

Second thing: If it's not traffic and according to our statistics and for Q1?2012 we have seen around 3606 plus attacks, less than were more than one gigabit per second and there is a reason for that; you don't have to do a lot of bandwidth to destroy an application. Low rate attacks is ?? so your protection doesn't help with annual rate attacks.

MATJAZ STRAUS ISTENIC: The second one that is true, it's high volume attacks, about a first one, the first question, the classification ??

AUDIENCE SPEAKER: Where you classify, create classes for your class fire.

MATJAZ STRAUS ISTENIC: It's done automatically on Juniper route. This works on M series, MX and T series.

AUDIENCE SPEAKER: Lots of packet with appropriate source AP addresses and specific class and destroy your application, mission accomplished, protection doesn't work.

MATJAZ STRAUS ISTENIC: No, no, OK, it will ?? it will destroy the victim, yeah, that is true, but it won't destroy all the others because the attacks stream will be limited to a certain degree, for example to 10 meg.

AUDIENCE SPEAKER: Let's take a look, Russian elections 2012 and, yes, you can just create volumes of traffic with Russian network source addresses and destroy the application, point proved.

MATJAZ STRAUS ISTENIC: Probably run on TCP 80, yes, and PCP SYN packets 80, attackers typically don't use. They will attack your server via UDP.

AUDIENCE SPEAKER: Quite opposite according to our statistics. Let me say again, more than 97% of attacks in Russia nowadays are level 7 ?? fully compliant http level attacks ??

FILIZ YILMAZ: Can I suggest that you respond to that and then ?? and the ??

MATJAZ STRAUS ISTENIC: This technique doesn't help you with this kind of attacks. Sorry, it's poor men's technique.


FILIZ YILMAZ: So with apologies, with a little delay, a talk on content delivery in Europe.

DAVID TEMKIN: I am the principal network architect for Netflix. Some of you may know we launched in the UK and Ireland back in January of 2012. We offer an unlimited streaming service that is available on all sorts of different devices, some of you may use it, some from the US are very familiar with it. Those of you from Western Europe have probably heard about it by now. In the US, this is an info graphic from mid?last year, from San Vine that shows the representation of how much traffic we are responsible for. Now, this is clearly going to be different depending on market, so we have been established in the US for many years now, we are new in Europe, there will be expansion within Europe, you know, we expect to see traffic volumes grow with that expansion.

Outside of the US, we are present in Canada, most of LatAm and then as I mentioned, UK and Ireland.

Some of you may have seen this chart before, and I am going to try to go quickly through this, but people are welcome to ask questions. Some of you have seen this before. I know it's dined kind of hard to read. This chart is available on?line although this is the newest version of it which has not been published yet. The interesting thing about this is that you see that the maximum that you see within the US is about 26100 kilobits per second. We refer to that as time waited bit rate so we remove all standard Def titles. This is an average bit rate serving high Def titles. Within this, we have titles that are encoded anywhere between 1 megabit and five megabit. So you are going to see an average somewhere in the middle there. The key range to look at, though, interestingly enough, is kind of what you see in the middle of the soup of 2150 to 2450 which is where a large majority of the cable providers are in the US. Up top you see which clearly out performs cable. What you see down towards the bottom, ignoring Clearwire at the very bottom which is wi?max/LTE you see all of DSL providers lumped together so there is not a huge difference between the individual providers within a technology but there is a huge difference between the technologies.

Now, what gets really interesting is, if you look at US networks, you sees a little more jagged here. The timescale, slightly different but not by much, but the interesting thing is that the ?? they are all more or less together, and that includes the major MSO in the UK, which is virgin, so they are all somewhere maxing out around 2,400, which is, if I flip back here really particular, the top end of cable in the US, and so in the UK, we are seeing DSL performance equivalent to what cable performance is in the US.

As you can see here, included this for completeness, in Ireland not all that surprising, again UPC top MSO within that location, leading at the top but not a huge difference underneath of that. With the exception at the bottom which is again mobile. We do include mobile in some instances when it's considered high speed mobile and so that is why that is in there.

One other interesting may trick that we keep track of is the market share by bits, and so which networks get the most amount of traffic. So, unsurprisingly, virgin ?? I shouldn't say unsurprisingly. Surprisingly, virgin gets the most amount, however they are not the market reader in the UK as far as total number of subscribers. This is almost inverse from the subscriber count although BT being right near the top does make sense.

Ireland, again not overly surprising, do you see, although ?? you do see UPC way up top, again market shares by bits, the correlation we can make is the better the network quality the more bits we are serving to that network. There is nothing all that surprising within that.

So the question that we ask is: Why? So why is there such a huge difference between what we see in the UK and what we see in the US, is it differences in technology? And I will invite questions on this and a little bit of dialogue within time constraints. Differences in technology or differences in geography, configuration, network management protocols, why do we see these differences? We know that most of the providers in the US are providing plain vanilla basically first generation and second generation E DSL products are whereas in the UK most rolled out DSL 2 and starting to see VDSL.

What we are doing is we have started delivering some of our traffic from AS 2906 and some of you that see ?? that operate networks in Western Europe and also in the US for that matter are starting to see some traffic coming from 2906. Otherwise you are going to see traffic coming from CDNs. Now, within those CDNs and even AS 2906 we don't see a huge difference in delivering quality between users. So, if we go back to those charts which I won't bother to flip back, they don't change significantly between whether we are delivering them or any of these three CDNs are. So again, that is just to show that, hey, this is certainly probably more than likely something to do with downstream network management or downstream network technologies. People ask us pretty often, hey, do you just spray traffic around from CDNs and from our own network and how does that work? We have a very elaborate system by which we use to direct traffic to different CDNs. We've put a lot of development work into our own adaptive client, so we are not doing anything crazy as far as the protocol goes, protocol is plain vanilla, it looks no different than anything else, but our clients actively measure network performance so that is how we get all those great statistics and I could add 50 more slides that show you all kindses of great graphs and we do publish some of that on a regular basis. Because of the wide distribution of titles, there is certain reasons why we may direct you to one cache location versus another but aside from that everything is generally performance?based.

So, for those of you that operate networks, what we want to do is make sure that you know that we are here to help scale traffic within that so we are happy to share performance statistics like I showed you before, in very detailed per format of traffic forecast. We can talk about embedded caching and peering. One of the things that we have done that is a little different from the way that most other CDNs function is that we give networks direct control over how our traffic flows into the network. We don't see DNS, we use an IP address and so because of that, it gives you flexibility in how you advertise your network to us, that it allows you to establish tiering and failover and redundancy and however else you want to control traffic. And we use BGP methods to do that.

Really quick. This is just a quick info graphic that shows how we direct clients to servers. So a client comes in to not necessarily a localised control server; we get their IP address, we make a complex decision based on that IP address, including what I just mentioned as far as using BGP information that a network sends to us, and if we are not peered or embedded within a network using other information we have about that network, to then send back a URL including an IP or host name to the client and that allows us to hyper localise without running into issues or use some other third party caching source.

Netflix cache: As I mentioned we do offer embed cache products. We can offload over 80% from that cache, it's completely integrated into that system that I just mentioned, we use it exclusively for our content, and only upstream usage out of peak times. This is what the inside that have box like like, some of you may have seen the black blaze presentation from a year?and?a?half ago may recognise this chassis slightly, it's a little different, we don't oversubscribe the black plain so the disks have 100 percent throughput to the bus. It's specifically optimised for power consumption so this is over 100 terabits of storage at about 500 watts of power.

This is what one of these operating looks like. It's ?? I grabbed this graph earlier today ?? you are seeing basically 94% offload versus if you were just fetching the content from upstream in realtime, so we are serving 8 gig peak here and downstream the max you are seeing there is significantly less, about 5 gigabits during a very, very small window of time. That is in the middle of the night, basically.

And that is it.

SPEAKER: Thank you, David. Are there questions?

AUDIENCE SPEAKER: Will from, LONAP here. Where do you actually fill the caches from? Because obviously if I was a provider I would want to get that.

DAVID TEMKIN: We are offering that over peering in certain markets and will expand that over the next couple of quarters so today when that cache fills first from limb light level 3. We don't ?? we see a day where that is not necessary any more.


CHAIR: No more questions? Thank you very much.


CHAIR: Now I'd like to invite Edward Lewis with his presentation on look at TLD DNSSEC practices.

EDWARD LEWIS: Developers versus operators is the sub title I have here. So the premise of the talk today is DNSSEC was designed for incremental deployment and for changes to the technology as the years go by. We rely on triptography and can't rely on any one algorithm, so things are supposed to change. The operators were handed a protocol extension that has a lot of things not, they have to twist and turn as it goes on from year to year. Now that we have had about a year or two of some deployments since the route was signed a while ago. What have operatives done to date and how have they configured DNSSEC and use to what was expected to happen in the year before that.

Now, the study that I am referring to, the work underlying all this was done for concrete reasons at work. We are a TLD operator and we also run and manage DNS services. What should our primers be and how should the knobs be twisted. Besides knowing what they should be, one of the checks was to look at TLD operator club and see what have they done to date. This is one of the outcomes, what is the average, what is being done, but now with some of this information we look back at what is the path of DNSSEC going forward?

Only because we talk about DNSSEC and this is not a DNS crowd, I am going to ?? there is a bit of terminology, KSK and ZSK, don't worry what they means. Different ways of using keys and they pop up a lot in the analysis work. Key management parameters are going to be talked about, the algorithm use of cryptography, the length of keys, operation cycles including how long you use a key and so on. Negative answer style is another choice made in DNSSEC which is not cryptography or key related but how you go about deploying the extension. What I do is hourly get a copy of the root zone and go through all the TLDs and ask them for the records at the top of the zone and I am able from that to derive how they are doing DNSSEC, having known the way the protocol works. So far, people have asked me for visuals, I don't have visual data because there are not that many, the numbers aren't very big and they don't change much.

So... and a summary of what I found in one slide is that there are about 303 root zone plus TLDs that are operational. I couldn't count 11 experimental TLDs out there because they just scew the numbers. 82 right now are signed. That is about a quarter of the way there to the whole thing. It's interesting to look at where we are today, things like that. What is also interesting to see the pattern and since June of last year 19 TLDs have started DNSSEC and one has stopped doing DNSSEC. I mentioned KSK and ZSK, they all do that. There was some question whether that was needed but they all do that for similar reasons. One zone didn't do it for a while and they converted while I was watching. Of other key elements, 90 percent use one of two different cryptographic algorithms, use the same set of key sizes and 90 percent all are linked up to the root complete hey and I won't ?? they have DNS records, those that don't know it just means they are done.

So, expectations are crypto. Crypto is a key element and probably the least understood part of it. The protocol developers didn't have a lot of expertise in that area but we knew to use it certain ways. So we assumed that operators would use multiple algorithms to cover all the user base out there, not everyone would have the same verifier software but we thought they'd you will be able to verify somehow. We always assumed there would be two kind of keys, KSK and ZSK, and we figured things like the key things were beyond our ability to know what that would be. We trust that had would be found out eventually. And we also assumed that key changes were going to be a very important part of the entire operations and that is what made a lot of people scared about DNSSEC.

So looking at the study about cryptographic algorithms, the first two are trying to say that initially we had one set of algorithms design, RSA?SHA one and DSA. Eventually we added 256, it's about half RSA?SHA one and half 56. What is looking a little bit deeper in that though, you notice almost all the newer once that have signed have been adding RSA?SHA 256 so the newer algorithm is ?? if you are coming on?line today you would want the newer stuff which is an accepted practice.

What was surprising to me was that no operator uses multiple algorithms. Every picks one and sticks with that because it actually makes sense when you think about as an operator to have just one. One TLD did change algorithms, they went from RSA?SHA one to 256 but only one did that, it was possible to do that but only one has bothered to make the change.

What is interesting here is that we see the operators pick what is the best thing to do. They don't go back and say why do I have all these choices, let me do the protocol the way the engineers want it to be done. They pick the a the best available one. That what I was asked, what is the best and let's go with it. It's rare that we have an extension coming along or protocol come where we have key elements that are open to change. We know at tech refresh is hard, it's hard to updating software that is in our operational system. Much as having to change the elements within the protocol itself.

The adage of liberal and what you accept, conserving what you send doesn't apply here. I felt I needed to have that there but it really doesn't apply because it's not so much what you are saying and hearing but what you are deploying. And last is very important: The capability of the other side of the network is something you can't control and DNS is really unmanageable.

Looking at key lengths, RFC 4641 is an IETF document that codified a lot of what the project engineers thought. It's a discussion document. It's postulated that these two key bits, 1024 and 2048 would work. Today, 90 percent of all signed zones use exactly those two numbers. 96% sign with 1024s as ZSK and any size KSK and so on. Only one zone uses neither so every everyone is pretty much following the power of suggestion. They were in a document. I was back ?? involved back then, I don't know where we picked those numbers from but they seemed like good numbers at the time.

When it comes to changing keys, which is the scariest part about DNSSEC, we make this the smallest part of operations, operators like steady state. There are three factors to look at here: Frequency of the changes, how long the change takes to happen, and how you approach it. The expectation is that protocol developers were key changes would be required. We felt cryptography was going to be something that meant it to be changed over time, and keys had to be changed and we would try to do this in a way that minimises disruption to performance in the sense of large messages and shortened so they don't take a lot of time. As far as frequency, we anticipated or the developers anticipated a one year KSK, one month ZSK duration. To the surprise of us when ?? I've been on both sides of the fence ?? as an operator I was surprised the day came out that crypto experts emerged that you should never have to change the keys, the total shock to anyone who have been working object the protocol for any years. Only need to be changed when broken and not useful any more, which is true. However it doesn't really work in operations. Operators like to have apparent actions that are set up at a time and looking at it right now, about one?third of all the signed zones changed a key every month. 10 percent every two months and 18 percent every three months. Part of the ?? of the rest of them it's hard to say. Some haven't got around to it they are too new but a lot of the zones do change keys, emanating from the fact you like to make sure you have routine actions and don't want to do things in an emergency that you haven't tried before. The thing I want to adhere is cryptography is a good thing, operations predictability is much more important.

When it comes to duration, the duration of the, how long it takes to change the keys, one of the challenges in DNS is we have caches and that changes how long it takes to make any kind of a change, if you change something in the source the end user may not see that because the middle of cache still has your old information. There are a couple of parameters that determines how long this is going to take. A couple of years ago a few of the protocol engineers did a good document on how to predict how long it would take to change a key. I read the documents with an operator mindset and it was incredibly detailed and lots of good information but hopelessly complex to an operator, we wouldn't think of all the steps involved; we simplified a lot of things. If I tried to apply some of the optimisation techniques, keys appear too soon, show up, are out there for a while and they get used eventually and they go away but also with a long retirement period.

I will come back to the keys coming in another slide. The style was one place the protocol engineers got right, different ways to go about changing something when caches involved. The predictions were at least two ways, ZSKs would be one way and KSKs the other way and so far that seems to be right on track. The question about keys appearing early because operators are sloppy about this, it's because operators are looking at some other aspect here and it has to do with how many keys do I want to show. For bare minimum I have to have one ZSK and one KSK but some operators say I would like to have a second key always available on?line in case I have to fall back. So they will have two and some operators will bring the key on and make it back up for some time and make it the live one so that is why they appear early. They are doing nothing roll on the way there.

For counting for KSKs, about half the zones have one, half have two so they have split on that and the same thing for KSKs.

Another parameter which is interesting to look at, in hashes, I have two kinds, one and two. The RFC, the protocol engineer said you should have both of those available for backwards compatibility. Today just under half the zones do that. Just as many only have the new hash and there are a few only have the old hash. And asking around what has been happening, do a software availability they can only have one or the other out there. Also, one group said they follow with the root zone has and that only has the new one.

NSEC 3 is a style of negative answers, 70 percent of the signed TLD use that for various reasons. There is a recommendation there in there from the engineers to change the salt; every time you sign. One problem is, operators don't sign any more, we use continuously sign the zone, we don't have bad operations every more. That have recommendation 4 percent of the TLDs are done, they change the salt just about every two, two do it every day and a third almost every day. 75 percent have never bothered changing at all over nine months so that is a wide range of how operators think of this salt parameter. The consequence of changes ?? a lot of changes between servers.

What is emergeing from all of this is that it's obvious that the protocol engineers are looking in one direction and the operators in another direction. Operators want simplicity because it's a lot easier to run something you know how it's going to look, you have staff turn over, you don't want to have people understand the mathematics of cryptography behind this. Other factors that have popped up in talking to operators over the last couple of months, availability of software limits what operators do. They don't want to write new for every little thing to optimise, they want to get something off?the?shelf and use it. It takes about a year or two to DNSSEC to roll out so some of the zones come out there with some of the old technology because it's take answer while to get this point and they are not going to change at the last minute and also the term what the root does is important to the TLD operators.

The gap here, and I have mentioned it already. I will say this is what is needed by the operators. The gap is not because the operate remembers not doing their job but it's an existing gap. We need help with cryptography, we don't always know what we are doing and there are some improvements out there. Now we have all these things we can change over time but we don't have any triggers for that and we don't know when to change, so we immediate help to say put in the protocol, some way of telling when is the off the wear out there we can control change that we can go ahead and make our thing, it would help to have a BCP document, the operators could do that, compliance is asked for in a lot of RFCs and are not good for compliance. I would have to say ?? of the TLD crud together doesn't comply with the RFCs out there even though we are asked to. DNSSEC is being done and correctly but the documents are not CRISP enough to say why you comply with the document. So need a clearer set of requirements for the legal requirements of purchase and service. And performance questions there has been some more recent questions about some of the choices we have made, what is the exponent of key? You know, things that were never considered that, makes a difference to validators, the operators have never spent time studying that and we need to look at that.

And tracking client capability. There is a document in the IETF which gives us some hint on to that algorithms, good start. We need more though. Find out, one can change all the other knobs that we have been given by the engineers. And so summary: The gap I was talking about is not a problem, it's not ?? he said, she said so to speak but it's there and we are identifying more information needed by the operations group to make sure we are going in the right direction and hopefully I have identified at least so. Things that are needed, if not all of them.

I have given a few presentations on this already. These are the pointers and places I have talked and I go through different parts of the study, so background, the APRICOT has more what I am looking at, ICANN summary, and comparison to ?? if you want links to them ask me, if you can find these with Google, all the better.

So, questions? It's all I prepared to speak and hopefully we are doing OK.

CHAIR: Thank you, Ed. We have sometime for questions, so please, are there any questions?

AUDIENCE SPEAKER: Dimitry Kolmanyuk from Hostmaster. Just a quick note, when you mentioned algorithm support, even IANA route zone update system doesn't accept GHOST algorithm, I know that for a fact and the new algorithm for adopted this year I think there were two, aren't there either. So if IANA run by ICANN does not identify algorithm numbers assigned by ICANN ?? sorry, by IANA ??

EDWARD LEWIS: Yes, that is a good point ??

AUDIENCE SPEAKER: Algorithm as I say, I send a message to ICANN, one of their senior people and got no reply.

EDWARD LEWIS: Unfortunately, I can't help with that, but that is true, trying to get this in the institutional system is important.

CHAIR: If there are no more questions, thank you, Ed. Thank you.


CHAIR: I would like to remind you once again, don't forget to read the talks, and now, I am inviting Andy Davidson so he can invite his panel to discuss proposed regulations from the French regulator.

ANDY DAVIDSON: Thank you very much. Is Malcolm in the room as well? Perfect, Malcolm is going to come to the stage and we are actually going to have two other panelists dialing in remotely. I regret that is the case, but when I introduce the topic to you and explain their role, you are agree they are the far most ideal people to present on these topics. We are going to have now have a panel and a discussion on a proposal that a French regulator who will introduce themselves in a moment, Pascal from ARCEP in France will introduce a proposal or a discussion that they are having about peering registration, and then Raphael, an operator from France will introduce or will discuss a reaction and then Malcolm will also present the London Internet Exchange's response to the consultation as well or a response.

So I will hand over first of all to Pascal, the first set of slides, I will drive the slides for you, Pascal, and do it, it will all become clear very, very soon.

Pascal: Thank you very much. So I understand that you will explain the slides for the presentation and I propose to talk about them to ?? the decision that ?? adopted at end of March about the connection and data conveyance on Internet.

So, first of all, I am Pascal, working for ARCEP, French data for ?? and so I am part of ?? on the team that is working on every topic related with ?? that connection is what the topic that is should ?? on the four bit ?? first of all on slide number 2, just a few words about ARCEP. Electronic communication regulatory authority. One very basic point of importance is that ARCEP is ?? and its independence ?? which means that ARCEP know and the power every taxations we regulate first point of the decision or institution have nothing to do ?? one of the ?? by some of the ?? of the decision. So then ARCEP is used confidential, for instance we collect ?? about ?? slide number 3 about, so perhaps some of you have recommendations in September 2010, which is kind of ?? and so why do we relate to connection. It's mostly because interconnection in terms of dispute ?? circumstances ?? it's ?? it's not a connection issue that might be issues of discrimination, discrimination on ?? there might be issues that want to look at and might want to understand.

So, for these reasons I would say it's important for people really to ?? our connection is working with France, but nonetheless, ARCEP does not intend regulate markets and it's stated a decision that was adopted very much, so this is very important, this decision that was adopted on 9th of March IP connection market. Making it possible for ?? to get good information from that market. And I would, one step further: That is to market is working properly, that it doesn't regulating, that it gets some precise fact that prove that it ?? and I would ?? this arose out of ?? objectives among others.  ?? sometimes some of them in France with France Telecom and perhaps some of you ?? refusing ?? financial dispute. Basically ARCEP may be ?? may be asked to settle disputes, to give conclusion on disputes ?? if one ?? asks ARCEP to pool dispute between two operators, to impose financial conditions. For that reason ARCEP has a deep understanding of what connection market, for disputes that capacity to take a good decision.

Several ?? is not the first step we did on interconnection.

A few words about the ?? so this decision is part implementation of the proposals of gathering information and ?? data and ?? so interconnection ?? and data conveyance ?? interconnection on the one hand, providers of on?line computation services on the other but both of those are ?? mostly.

ANDY DAVIDSON: May I just interrupt you for a second. The sound is breaking up badly if I summarise some of your point and if you have something to follow up on we can move to Raphael. So, essentially the regulator is very concerned about interconnections being interrupted and the impact of interconnections being interrupted on end users so if end users suffer poor Internet service or poor service, then the regulator would like to understand the causes behind that and they may consider it a market failure and, therefore, would like a questionnaire to be completed by operators within France describing interconnections with all other parties in France or interconnections of ?? that are outside of trance but with French networks, is that a summary that you'd be happy with?

Pascal: I wouldn't say that, I mentioned the risk that might ?? might be block in very specific circumstance, kind of division ?? divide Internet in several sections. This is basically one nightmare is ?? that has not been observed, that has not been ?? that is the scope of the ?? ARCEP believes today the market is working properly but needs to get precise information to ensure that the market got ?? and also the capacity ?? provider of service asks ?? ARCEP competence more than just about this very ?? two sections. I was too long on the first slides but faster on the last ones.


Pascal: On slide 4, one important point this was not adapted, I would say from scratch. It is ?? and we ask operators and providers of services to provide us information about ?? of their interconnections.

ANDY DAVIDSON: The point of the questionnaire is an information gathering exercise that you are interested in. Whilst we are having the technical problems which didn't take place in the technical test, I propose that we next do Malcolm's presentation, the response to that, and then we try and get Raphael back. So if Pascal could listen to this response and then we may have to take questions from the room at that point or not. But Malcolm, if we can have Malcolm Hutty's slides.

MALCOLM HUTTY: Thank you. I was expecting this to be mainly a panel discussion rather than a presentation, so my slide deck is very limited, and I hope it's not going to put too much stress on what was actually only intended to be a very brief summary, before we got into the main cut and thrust of the debate which I am not quite sure how well that is going to work in the light of the technical problems with the sound, but we will do what we can. Essentially, everybody here really knows what LINX is, one of the big Internet Exchanges, constitute as a membership social and we also do some public policy work for the members, which was why we were involved in this big issue with ARCEP. It's got a large membership at LINX, and most importantly for this issue, members from a large number of countries, from 51 countries, are members of LINX.

So the ARCEP proposal was essentially to introduce a legal requirement in France that network operators should be required to answer a questionnaire on their peering agreements and that the proposal as introduced in December that responses to this questionnaire were going to be required, as a matter of law, four times a year, and this questionnaire would cover a variety of technical aspects such as things like the capacity and the actual amount of data transferred in flow sizes and so forth and essentially what you might call commercial aspects such as was this paid peering and if so, what were the commercial terms of that paid peering relationship, what was the price and so forth. Was essentially the original proposal summarised as simplistically as I can and with great respect to a much more detailed presentation we have just had from ARCEP.

Crucially, was the scope that was being proposed at the time. It was proposed that not only would French network operators be required to complete this questionnaire, but that, also, that networks that were outside France, not French networks, and not even networks that operated inside France or provided services inside France but any network that interconnected, that peered with a French network would be required, by French law, to complete this questionnaire, and so that would include, and that brings LINX's interest into it. Our members, when peering at LINX in London with French networks, would, as a result of the proposed ARCEP regulation, be required to fill out this quite detailed questionnaire four times a year.

It also extended to cover on?line communication services, actually essentially content services, that were providing services in France and I am not quite sure exactly how far this definition indeed would extend, but on a very loose and casual reading, and use of ?? using the English translation that ARCEP very helpfully provided, I couldn't see anything that would take this away from any website operators that was also an ASN operator.

And it would also extend to content service providers outside France who in our English translation have actively taken steps to have their services or content accessed by French users. What does that mean? Well, ARCEP gave a list of things that it would consider to be indicative of if you were providing content services deliberately to be accessed by French users and one of the things was providing content in the French language.

So in summary French networks required to provide ?? to complete this questionnaire. Networks that interconnect with French networks required. Website operators and other on?line content services established in France, if you have got an ASN. And also, anyone outside France who has fallen into that if you are publishing information in French ? in Canada or other countries could be potentially included in this requirement according to the expectations.

Now, an organisation like LINX understands that regulators that have their requirements, ARCEP has legal requirements, for example, to hear complains from operators about anti?abuse ?? about anti?competitive allegations and so forth, to investigate them and regulator will have requirements to seek information so they can adjudicate those complaints fairly and so as to be able to develop its own national policy within the framework of European law. We understand that. And it's, therefore, quite understandable that ARCEP would want to understand the peering market. However, there were two basic problems that we had with the way that ARCEP was going about this. Jurisdiction and the way that this kind of burden, the impact that this could have on peering behaviour.

Jurisdiction, essentially our belief that one national authority should not be able to impose rules on people outside their jurisdiction all around the world merely because you happen to be interconnecting with a network from that country, shouldn't be, in our view, sufficient to bring you in the scope of a foreign national authority. If we were to take the view that that is sufficient to form a Nexus with that country that you are within the scope, then potentially networks would be subject to many, many national jurisdictions simultaneously, including in countries in which they do not operate themselves and that would be a very significant burden for the network operators. And why it might be said that this is only an information gathering exercise, this was being proposed as a legal requirement, and so, in principle, if we accept that the regulator like ARCEP is able to extend its authority beyond the French jurisdiction to anyone that happens to interconnect with a French operator even though that happens outside France, not only would ARCEP in principle have the authority to impose information gathering obligation, but also any other things that French law would provide for. And that would be somewhat worrying, especially when you start multiplying that up if not only France was to follow that route but many other regulators were to follow the same approach.

The other things that concerned us was the thought that this kind of detailed information gathering on a routine basis across the entire market could have the potential to change peering behaviour, and this is based on our understanding that most peering agreements are conducted on a handshake pretty informally, no written contract and essentially even internal record?keeping can be a bit shoddy. Essentially, the concern is that if you start requiring operators at that take any kind of steps on a per peering agreement basis, then an operator would have to establish internal procedures so as to make sure it was complying with, in this case, the French regulator's requirements or if, this became an established practice for many jurisdictions, through regulators' requirements all over, and do that repeatedly. So we were concerned that the, that expecting network operators to comply with this, might cause peering decisions to be made in a much more formalistic way with a reduced delegation of authority ?? network operators as compared with what happens at the moment, and ultimately this could result in a significant reduction in the propensity to peer especially those that peer widely and freely with fairly relaxed criteria for accepting peering decisions, so two concerns: One, in principle, we should not be submitting to extra territorial regulation, it's difficult enough complying with the legal authorities within the countries in which you do operate without having to comply in countries in which you do not operate.

And secondly, this isn't necessarily a good idea if the unintended consequence of it is to reduce the very thing that ARCEP is actually as a matter of policy seeking to promote.

So, what happened? Well, ARCEP, on 30th of March, published its revised proposal or revised decision, I should say, I am afraid this hasn't yet been published in English so I am not entirely clear on how it will apply. The presentation we have just heard will be helpful and I will certainly go back and study the slide deck for more clarity, ARCEP have promised to publish their proposal ?? their decision in English later.

But thanks to Google translate, I have basically got the idea that if you are an operator registered in France with the French authority, you will have to comply with this requirement ?? with this information gathering requirement, and if you are not, you might be sent a questionnaire if they are particularly interested in you. One thing that it's not clear about is whether or not, in ARCEP's opinion, there would be a legal obligation to complete that questionnaire or whether you would be free to disregard it if you so choose.

That is something I will be looking to understand better possibly in the discussion that follows. One thing that ARCEP have done in their revised proposal to address the concerns that we and some other network operators raised in response to the consultation, is to introduce new gaiting criterion for filling out these which is you will not be required to fill out such questionnaire in respect of peering agreements which is not capable of producing significant effects on the provision of communication services at public ?? to on?line users located in France so essentially a de minimis requirement, unless you are going to have a substantial effect on connect in France then you should be able to say we shouldn't have to do this. And secondly they reduce the burden simply by reducing it from four times a year to twice a year obligation.

So, to that extent, I am not entirely sure ?? I am not entirely persuaded that all our objections were fully answered that but ARCEP did make some progress towards meeting us somewhat in the middle. And to that ?? to that extent would he obviously be well ?? we would welcome that. Anyway, that was really the short introductory summary that I was going to give prior to the discussion. Andy, I will hand back to you and let you say how you take things forward.

ANDY DAVIDSON: Let's ?? can we have the audio. I am going to feed you back in Pascal and attempt to let have you a response on that, hopefully the audio is improved now. Let's try.

Pascal: So first of all, we did a translation of the decision that was in March, where we did it in December and the translated version of the decision should be published very soon, we hope actually that it will be published today, or in worst case, tomorrow, so I apologise if we couldn't have this document already published but it will be done very soon.

Second point, without taking too much time, I support some important evolutions were made in comparison with the document that was published in December of the consultation, and so this was ?? to highlight, first of all, only the operators that asked to have aired in front of the ARCEP French operators have to answer to the data collection two times a year. For all the operators that have not ?? they don't have answer to the questionnaire at all, unless ARCEP asks ?? one of them ?? second point ?? smaller than it was before because ?? French operators ??

ANDY DAVIDSON: Pascal, the sound is going again. Raphael, could I ask if you have any comments, rather than do your presentation which I think won't work very well, could you have some response and maybe introduce your arguments to the discussion, Raphael.

RAPHAEL MAUNIER: Yes, can you all hear me?

ANDY DAVIDSON: Yes, that is good.

RAPHAEL MAUNIER: So regarding the RIPE presentation about regulation, what we have done in France last year, we ?? I think ten of the biggest ISPs in France was asked by ARCEP about giving information about connectivity and how do we price concepts, how do we price connections, and after some discussion with the French authority, the ARCEP and also the French regulation like in US it's ?? so we decided not respond to the French offer because it was not how we see peering in France.

We tried to speak to them last year, it's not something that we would like to voice because it was most of the discussion we had last year, the difference between peering and voice. So, I think the first step we have in France is to try to explain to the French regulation what really is peering and why we peer and how we decided to peer or not with someone because I don't understand how it was with peering but we are doing in NANOG and RIPE and everything, like people just talk to each other and decide to set up some peering session or not. So it's mainly because they want some ?? let's say, the short information we had last year, it was about the French IRS to get the money ?? and it tended after speaking with people at ARCEP, it's not the case. But today in France we are not confident about that and we just want to be sure about ?? it's real intention of ARCEP.

ANDY DAVIDSON: Great. Does anybody in the room have some questions that they'd like to voice on the subject of questionnaires about interconnection in France on this particular topic? Randy, is this a question?

RANDY BUSH: Randy Bush, IIJ. I think what is going on is France has protectionist peering by overstuffed incumbents. We have seen this all over the world. But what we are seeing is those who complain are being punished by the regulator by the regulator asking to get in their underpants, OK? But the French have ?? we cannot deny their expertise in bureaucracy and applying it in this situation would be cheering if there was any hope that they would actually do anything about it, but I believe the English term for this, I know, is white wash; I am not sure what it is in French. I tried with Google and didn't come up with anything very good. But they are not going to fix the unfair and ridiculous peering in France and so demanding to know what people are doing is silly.

ANDY DAVIDSON: Maybe we will take a question from Dave and then give you an opportunity respond to all points. So, Dave...

Dave: David Freedman from Claranet, not so much a question per se but more I'd like to see two sorts of things answered here, the first of which is has anything like this been done before, does anybody remember where regulators in their country started to verge into this space. And the second is do we have any regulators here in the room. I have seen quite a few. Do any want to stand up and comment on whether this would be appropriate in their countries.

ANDY DAVIDSON: So maybe ??

RAPHAEL MAUNIER: So I think it started last year or 18 months ago because not ?? not because of France Telecom, because of Cogent asking France Telecom to open the peering, because France Telecom asks to do some regulation on peering, it's because cogent ?? two years ago so I think the big point is that ?? on network and ?? defend France Telecom but at some point can use network of people without anything in return but I think it started because someone was not ?? asking to regulate peering in France. This is my point.

ANDY DAVIDSON: OK. Pascal, any comments on the questions that you have heard? Are you aware of other jurisdictions and is this something that is based on the history of peering in France can't be fixed by questionnaire, which is the claim that Randy was making.

Pascal: So first point, just to conclude on who is concerned by the questionnaire. I would say important to read the rest of the presentation and in slide 6 where we stated clearly who is ?? then I would like to come back on the other points raised by person from LINX. So first of all, about ?? make it simpler. We target first of all, operators that are in France, that are under the jurisdiction of ARCEP. These people send us information about all their peering and transit agreements, also with operators that are not located in France and that are not French operators. So if we look at one peering agreements, between one French ISP and one, let's say, American content provider, we might get it from the French ISP and what we plan to do is simply ask the American content provider, well, French ISP told us that such a relationship with him, could you tell us or need to confirm the technical and financial terms of this ?? of the contract are ?? so, we don't expect to get some more information from operators and application providers that are not in France. Give them a chance to give the story and if they don't give it, possibility ?? clearly stated. If they don't say it then only a possibility to rely on what ISP told us. So this is the ?? we are very, very focused on French ?? from that under ARCEP and for all the other that are Europe it's more kind of data control.

ANDY DAVIDSON: OK. Malcolm, there is a question on the floor as well but Malcolm signalled to me first that he had a reply to this.

MALCOLM HUTTY: I think that we need to remember that a regulator like ARCEP has legal duties and that if someone makes a complaint to it it has to respond and be able to deal with that in a certain way and it's inevitable that it's going to seek to understand in some way what it is that it's been asked to deal on a complaint about and so it's not terribly surprising that it might come up with a proposal like this, if you are asked to adjudicate a complaint in an area you don't know much about it you try to find out some more and the way to do that is seeking to gather information from the market that it's asked to adjudicate complaints on.

Where we believe that that might ?? that information gathering might have adverse consequences in and of itself, I think it really falls to us, the industry, the operator community, to engage as productively as possible with regulators like ARCEP to explain why that might be the case, and maybe to ?? where we can, to seek to suggest other routes for satisfying what their legitimate requirement is that don't have those adverse consequences. It's easy to throw rocks, I do it enough from time to time with my own government, public authorities when they do things which we disapproval ?? which we are disappointed but I think that the ?? our community has accepted an obligation in the whole enhanced cooperation thing and the Cooperation Working Group and within our own domestic communities through organisations like LINX and many others, that engage with public authorities, to help them to act better and more in line with how we understand would be feasible in our context and sympathetically within the context of the Internet technical community. And so we do need to work more productively like that rather than just simply saying, oh, well, they won't do anything useful so they are fools which is not necessarily the most constructive way to approach a regulator that you are seeking to persuade to act differently.

There is a question that I would like to ask ARCEP concerning one specific aspect of the change that they made. Originally, it was proposed that operators outside France that interconnected with French networks would be required to fill out the questionnaire and it's now that the questionnaire will only be sent to selected operators outside France where ARCEP decides it would like to gather information from them. My question relates to how ARCEP views its jurisdictional authority on this; does it believe that a foreign operator, not established in France and not operating in France, to which it chooses to send a questionnaire, is obliged as a matter of French law to complete that questionnaire and return it or is this a matter of voluntary compliance in ARCEP's view?

Pascal: So on that question and then the other question, I would like to ?? I didn't get time to answer before. Is it obliged to answer? We believe our lawyer believes we have the capacity to ask this information and that is operate on that ?? actually what happens, when an operator doesn't answer. Basically, if this operator is not in the jurisdiction and ?? there is there is ?? for that the obligation I would say, if you like but as I mentioned before, of feeling that it is in the fairest that we would select answer because we really get the information from the point of view of French ?? from the point of view of French ?? as consequence it's, I would say we basically give ?? French operators to give their version of this story. There is no ??

ANDY DAVIDSON: We only have a few minutes left and I see two questions on the floor. Randy was first and then Todd.

RANDY BUSH: IIJ again. First, the reaction when cogent complaints about peering is supposed to be laughter. Cogent has made a farce of peering around the world. Secondly, when I do research and collect data, I have a hypothesis, and I know how I will evaluate those data and what conclusions I believe I will come to based on results of the measurements. I do not see that here. What I see is phrased as data collection but is otherwise known as a fishing expedition and the problem is that the data that are being asked for are sensitive, non?disclosed business data, if they were just mild ?? if they were just mild, easy data that were not confidential, it would not be a problem, but without saying how the data will be used, how they will be evaluated and what will be the benefits to the providers of the data from the conclusions reached, of course people are going to take offence at it, and quite reasonably.

ANDY DAVIDSON: And then I will take ?? take the question from Todd and then we can maybe have some remarks from everybody on both statements.

Todd Underwood: My question was Malcolm's question because I don't think I am smart enough to understand the answer. Was that yes or no, yes providers outside of the French jurisdiction are obliged to provide answers to the questionnaire or no they are not? I am sorry, I just was not able to understand the answer.

ANDY DAVIDSON: Pascal, could you answer that?

MALCOLM HUTTY: Pascal, I think there are a number of operators in this room that think that they have ?? that do interconnection with French networks that are not registered with a French authority or operate in France that suspect that they might in the future receive a questionnaire from you as a matter of targeted selection. They would like to know whether, in your view, filling out that questionnaire is compulsory if they do receive it, and really a yes ?? given sound problems a yes or no answer would be very appreciated.

Pascal: In our view they are to answer every question that they will receive.

RAPHAEL MAUNIER: I would like to respond to Malcolm. I think in France ?? so you talk about the community and everything, I think in France why we are ?? from ARCEP in France we didn't take time to speak with the regulator, so it's mainly because of the French community that it's not strong in France that we have this today. I think because of the French community from both peering and everything, we don't talk to the regulator.

ANDY DAVIDSON: And that is something that you are trying to change through the, for example, FRNOG process, you are coming together to respond as a group of operators, that's correct, is it?

RAPHAEL MAUNIER: Yes, I think we will speak with France IX ?? I think people like LINX is ?? I think we have to do the same in France with France IX and I think I would spend time and also other people in France who are, in France, to speak with ARCEP and spend some time to train them on peering so I try to get them to come and connect ?? also maybe to April now ?? so extend ARCEP call me back last week and they are upbeat ?? I think they are on a good way to solve this problem.

ANDY DAVIDSON: Maybe I can offer a closing question then to the panelists, and it's a question that a few people in the room have spoken to me when I have been talking about the panel, some of those concerns. Do each of the panelists consider that there is a risk that this work, even the threat ?? the process of talking about questionnaires, let alone the presence of questionnaires, the existence of questionnaires may result in less peering in France, less dense interconnection in France and a therefore, possibly a less richly connected Internet in France. Do you consider that to be a risk? Let's say Pascal first.

Pascal: This is the point I wanted to develop further because it was also mentioned in questions before. When you talk about peering, private peering and public private peering. We want to collect information about private peering. Private peering, as you will see it in the version of the questionnaire that will be published very soon, what we only simply ask is the total capacity of the public peering on Internet Exchange point. We don't ask each of the AS, to AS relationship under one public peering agreement, which has the capacity to one side and not the other side. So information as ?? I would say a lot less precisely developed as some might thinking but peering ??

ANDY DAVIDSON: We are running out of time. Malcolm, just the last second on this.

MALCOLM HUTTY: I think those assurances that Pascal has given will be of some comfort but certainly in our experience at LINX quite a lot of people conclude peering agreements at the LINX social but in the middle of the LINX meeting in a party over beer and I am not sure that ARCEP fully appreciates just how informal some of these decisions are, and therefore, the potential for that to be deterred at the margins by any level of bureaucratic compliance that is imposed whatsoever.

ANDY DAVIDSON: We are now out of time. I appreciate the hard work that not only has Malcolm Pascal and Raphael put in, but the Ops team who have done really well to bring in the main experts on the subject, whilst they couldn't be with us today, the RIPE Ops team helped make sure that the topic could at least be discussed and I know that at some point I was following by reading the stenography through the back of the screen because the stenography was so clear considering the audio quality, thank you.

So thank you to each the panelists and the operational team and everybody involved. Thank you again and I will hand back to Filiz. Thanks.

CHAIR: Before we close this session, let me make two announcements; so after ?? well, once again, re the talks please, that is very useful for the quality, improving the quality of the conference. There will be BoF upstairs and as the BoF on Quagga software, round table and then the social, the buses leave at quarter to 7 till quarter past 7, I believe from the hotel entrance or somewhere around. It's a small city. Thank you.