Archives

These are unedited transcripts and may contain errors.

Database Working Group session:
19 April 2012:
2:00?3:30 p.m..
Number is NU M B, not number. Thanks. Num is NU M.

CHAIRMAN: Let's get started. Ladies and gentlemen, friends, welcome to the database Working Group meeting. As usual, the first things are to introduce myself and my co?chair or co?chairs. I am Wilfred Woeber, I am employed I by Vienna university and my main job is in the group for the Austrian research and education network.

I am co?chair with Nigel Titley, we tried to keep this Working Group on track. Still nothing.

To begin with the administrative things, first of all, this session is recorded. So, first of all if you want to contribute and you are very welcome to do so please move up to the microphones and state your name and if you want to, your affiliation. During this week already, I have heard so many names which could I not make out what they were. So, for the benefit of the stenographers, please state your name in a volume and in a speed which makes it possible to actually understand. I am always mixing up ??

NIALL O'REILLY: This is Niall Reilly from University College Dublin, giving an example of what Wilfred is asking for.

CHAIRMAN: The next thing is that I have submitted a draft agenda and we have to move from the proposed agenda to the final one. Is there anything you want to have added or removed or modified? Yeah, it's not Daniel, but for the benefit of the RIPE NCC web people, I didn't want to submit a version 4 within a quarter of an hour or less ever after I was submitting version 3. Just like a mine minor correction on the subject line on this slide, it should actually be version 3 instead of version 3, but with my clumsy fingers, I didn't manage to get that right.

So, yes, noted, it's not going to be Daniel to give the presentation about RIPE Stat, but it's going to be Robert. Other than that... no? So I think we can proposed this proposed agenda to the active agenda.

Next thing is to approve the minutes from the previous meeting, RIPE 63 in Vienna. Nigel Titley has taken the notes and circulated the minutes, I suppose, so any comments? Any amendments? No, okay. So they are considered to be final. And the next logistic stuff is a review of the open action items, and I'd like to ask Nigel Titley to walk us through the action list.

NIGEL TITLEY: We have actually got very few actions and pretty well all of them have been covered, will be covered by the RIPE NCC in subseuqent presentations, but I'll just give a quick run through so that we know where we are.

I can remember what the first one is, it's 57.1, which was clean up of forward domain objects, which I guess is now complete, right?

57.2, sorry. So that is now complete I think between the last meeting. The remaining action points all just date from the last meeting. This first one is on Wilfred to take up the issue of the RIPE NCC providing a geolocation proxy with the RIPE Chairman. I see whether this needs to go to the services Working Group or not. I have a suspicion that Wilfred didn't know he had this action.

WILIFRIED WOEBER: First of all, I do not recollect that I was supposed to take it to the RIPE Chairman.

NIGEL TITLEY: That's what the minutes say and I received no comments on the minutes, so I assume they're correct.

WILIFRIED WOEBER: My fault. This whole aspect of geolocation is going to come up again during the RIPE NCC presentation, I suppose, and briefly at least, and we can take it from there. But, I had some private conversations with some folks previous this week and I think we need a little bit more discussion on the mailing list before we, sort of, push it up to either the RIPE Chair or something like that.

NIGEL TITLEY: As the action says, you were supposed to ask the mailing list as well. So shall we keep the action list open?

WILIFRIED WOEBER: Yes, I think it's useful. Thank you.

NIGEL TITLEY: No problem. This is an action RIPE NCC to come back with a statement on making the RIPE database UTF 8 safe, which I gather they'll be talking about later. Dave Friedman, is Dave here? He isn't. Okay. He had an action to raise the issue of the reverse look up methods for autonomous number objects in the rape database, to find out if there was a required feature to actually make a reverse lookup method. Has he contacted either the mailing list or the RIPE NCC? No. Okay. So in which case I'll leave this one open and prod him with a sharp stick.

That's the last one. Okay. So we are finished.

CHAIRMAN: Thank you very much. And the next thing is, as usual, the RIPE NCC's update regarding database activities, and instead of cafe who has a slight problem with his voice, we are going to have Alex giving this presentation.

SPEAKER: Because Alex never has a problem with his views, much to many people's disappointment. I just continuously keep talking, it's what I do. My name is Alex. What are we going to talk about first? Yes, it's operational ?? RIPE database statistics over the last six months, 99.99% uptime for all of our services. If you just look at queries, we actually had close to 100% uptimes, I think we are getting half a billion RIPE database queries per month. It's an astonishing amount and for that we need a really good framework, which we are going to talk about soon. But first, we are going to go through the action points as presented to you by Dennis. And I'll be back.

DENNIS WALKER: Hi, I am Dennis Walker, the business analysis for the database group. My voice isn't quite as bad at the moment but it's also not brilliant.

So, we will quickly move through the action points. We understood there were four action points but maybe we had a different four to what Nigel was talking about, but the four that we thought we had we have completed them all.

The four domain up, this is a very, very old action point from RIPE 57. We finally finished it. All 43 TLD operators ?? it took a few years but we got there in the end. So all 43 TLD operators that did have forward domain objects left in the RIPE database have now all moved them out. They also were asked they last RIPE meeting to now look at the syntax of the domain object and see if we can now revise that in light of getting rid of the four domain data. We put a proposal to both the DNS and the database Working Groups to drop four attributes, refer subdom, Domnet, maintain lower. We have put this several times to the mailing list and got very, very little response, so I guess these attributes really don't mean much to most people. They are obviously not important. The last message we put out was, had a deadline for comments. We received one saying yes, go ahead. So I think Wilfried is going to ask for a final check if there is any comment and then give us go ahead to do this later on. We also suggested that you sign just into the syntax of the domain object. Now we have got rid of the four domain objects. Every domain object should at least end the .arpa. Either the ENUM or the reverse delegation, we'll tighten up on the syntax of the primary key and make it impossible to create forward domain objects again in the RIPE database.

We were also asked to investigate UTF 8 compliance with the RIPE database. We did and published a review on RIPE Labs. The two main points that came out of it, technically the database will accept and will return UTF 8, it always has done. But it's not been tried and tested. So, occasionally people do put weird characters that are not US ASCII into the database, most of the time that character they thought they were putting in ends up in the database, but the results are not guaranteed to be what you expect. We don't recommend at the moment you do it. You won't break the database if you try it. But you may not get the data you thought you were putting in the database. And you can get into loops where you manage to get the data into the database but you can't delete it again because the delete it, the path goes into a different path in the code, uses different libraries and somewhere along the line it doesn't like the UTF 8. But technically it will work. However, there is no policy at the moment defining how, when, where, why you would actually use UTF 8. If people start putting in all sorts of non US ASCII characters in there, most of the RIPE community won't be able to read it. So, we actually, the first step we need the community to discuss what they want, where they would like to use UTF 8, how they would like to use it, whether it an alternative, a replacement, and addition, and you need to decide what you want. When you have done that, we can then implement it. I mean, obviously they can't put in the primary key, there are many other attributes that have very strict syntax rules which won't allow it. But there are many other attributes like description, address, which are free?text format, remarks attributes where you could use it but you need a policy on how to use it. So that's the next step and then we'll look and how we're going to implement it and fully test it.

Geolocation. We announced this week on the mailing list, it's now available as a sort of beta service. It's an optional attribute in the INETnum, there is two new optional attributes. One for the geolocation data and one for the choice of language. The current ?? the which wave actually implement this had is quite generic so, we can easily change it when the community decides and discusses it, you think you would prefer it to be in a different way, that's not a problem for us, it is only a beta service. But we would like to you try it and see what you think and see what experiences you have. At the moment, the geolocation, the location is actually the centre of the circle that you see on the map, so it's pretty precisely defined. You might want some fuzziness supplied to that, but these are things you need to look at, try and give us the feedback.

So, the next step is we need further discussion and the feedback passing on to us.

Hiding the MD5 hashes. This was actually a point it's also an item on the agenda, but I'll go through quickly what we have done so far.

At the last RIPE Meeting there was a lot of discussion about the fact that the MD5 hashes were public and that made them easier to crack. We implemented a kind of mid?term solution, we haven't got it perfect yet, but it solved the immediate problem, it got them out of the public domain. There is some discussion now about whether certain auth lines should be shown if the object only as PGP, if there is no password maybe we should show them, maybe we shouldn't. So we need a little bit more discussion on that and see what users experiences are and see where we go from there.

Following on from hiding MD5 hashes, we did the first ever mass mailing of all the maintainers of the user data in the RIPE database. We thought considering the amount of discussion that had happened on various mailing lists, not just the RIPE mailing lists and even news articles about the vulnerability of our passwords, maybe this would be a good moment for people to actually change their passwords. Particularly some of them have probably been unchanged for ten years. So, we sent mails out to 32,000 e?mail addresses. These were update to, which is a mandatory attribute to the maintainer object, the they maintain notify in the notify in the maintainer objects. We got back 8,000 bounces. Now, I'd add a couple of caveats to that. First of all, all we did was a very simplistic count. We didn't compare the e?mail addresses that bounced with the ones we sent out. So obviously some them could be mail alias that was split up into the multiple e?mail addresses. So one of the 32,000 could have generated a lot of bounces. There is a largerer margin on this, in effect we did get 8,000 bounced mails back.

Out of the 38,000 passwords that exist in all the maintainer objects, we didn't have a very high response to the changes. In two months since we sent the mails out, 875 have been changed. Now, there is a certain background level of requests that customer services on a daily basis to reset passwords where people have lost them. That accounts for quite a few of these, so maybe the e?mails resulted in about 700 passwords actually being changed out of 38,000. I will also add that this doesn't have any impact on the RIPE NCC's maintenance of the registry data. These are the maintainers of all the user data in the RIPE database, where we have passwords we change them but it's not a very high response rate.

We were also asked about the issue of sending plain text e?mails in ?? sorry plain text passwords in E had a mail updates. This is still a very wide open issue. Some of the things that have been discussed in the past are perhaps making e?mail updates only usable for PGP and signed with a proper BGP key or dropping e?mails completely. We are open to idea so we basically would like some feedback from the community to give us some indications as to how you want to move forward on this. Hiding the hashes is one thing, but if you send your password in plain text and e?mail in a very unsecure method. It kind of makes it pointless.

So, I'll now hand you back to cafe, mark 2, to talk about the projects.

AUDIENCE SPEAKER: Can I make a comment? Could you please go back a few slides. So, from what I understand from you, you are waiting forth policy, yes? Be prepared, I'll be back.

DENNIS WALKER: Okay.

AUDIENCE SPEAKER: Nick Hilliard here, the new geolocation and language attributes, can you confirm that they are optional, single?

DENNIS WALKER: The geolocation one is optional and single. The language is optional and multiple.

NICK HILLIARD: The reason I want to know is because I want to plug this into IRR tool sets so that it doesn't barf whenever it sees them. That will be done later on today and hopefully we'll get a new version of the distribution release fairly shortly. That's cool. Thank you very much. I have a question for Kaveh Ranjbar.

Can I ask it now or do you want to wait until the end of the presentation? It's just about your uptime measurements where you said you had 99.99% uptime over the last six months. Can you explain the 14 hour IPv6 outage on the 5 it April and also several hour FTP outage on the 17 it Jan? I don't mean to be confrontational, there is no good way of sort of saying this, if your uptime measurements are saying 99.99%, they are wrong.

KAVEH RANJBAR: You are right. The thing is what we measure is service uptime, and there was IPv6 connectivity problems for the RIPE NCC network, not globally from two or three of the connections so we still had IPv6 connectivity but from, let's say, 70, 80% of traffic was not reachable. But from our system it was still up, so you are right, I mean, it's how we defined the measurements. But as we measure it, the service was up and it was reachable also for IPv4, but, yes, for a period of time, the RIPE NCC has IPv6 connectivity problem.

NICK HILLIARD: Could you, maybe, plug an external monitoring into Atlas?

KAVEH RANJBAR: We are internally thinking about that, because ?? and we had, you know, we had a short chat with Atlas team as well. We have the same issue for certification, we want to have monitoring of the services we provide from different locations, not only from the internal network, so we are thinking about that to add measurements based from different locations.

NICK HILLIARD: Thanks very much. The reason I ask is again not to be antsy about it but purely because it does cause us operational problems, but I do WHOIS look?ups using IPv6 and my browser isn't happy eyeballs aware and you know that sort of thing. So when there is a problem with IPv6, it actually causes direct problems for me.

KAVEH RANJBAR: You are right.

ALEX BAND: Let me just struggle through the rest of it. The projects that we're working on. So, the main focus is implementing a brand new WHOIS application, essentially. The current application that we use for WHOIS is currently eleven years old. It was very, very hard to maintain, so very hard to fix bugs, very hard to implement new features. So, the way we tried to tackle that is put a brand new WHOIS application next to the old one, and in front of it we put a proxy and every incoming query would be sent, it would be decided whether to send it to the old service or the new service. That's essentially how it works.

It's completely backwards compatible. And the way we work is with continuous integration, this means that we work in sprints, and all of the developers they have a two week time period in which to get certain functionality done. After that, it is immediately implemented. So that means that all of the changes that you see happening in the database are really incremental. It's nice because that, for you, means that if you have a request or there is a bug reported, it can actually be resolved in a fairly quick time. Also the code is very, very efficient, so queries are handled more faster. Code is much more flexible and easier to maintain. It's actually really nice.

Here is a diagram of how everything is put together. As I explained the incoming inquiry is sent to a proxy. After which it is either replied to by the old or the new service and I am happy to tell that you currently 94% of all queries are handled by the new service, so it's just a couple of kinds of queries that still need to go to the old one, and that is going to be one of the focuses for the next couple of weeks to get resolved.

So that's the first point.

Access lists are very clean and easy to understand. They all adhere to the AUP.

Sorting output was fairly easy to do. Option handling had some complex behaviour. We needed to do a lot of work in order to get that result. But ultimately that also worked fine. I mean, that is all implemented now and it isn't causing any issues. And as I said it's faster, simpler, a lot more flexible, so if you have wishes for new functionality or you would like things to work differently, it is something that we can tackle in an easier way now. And the great thing of course is that everything that we have written in Java will open source it and make it available to the other RIRs they will benefit from the work we have invested in this.

So, as for the plan, as I said, 94 percent of all queries were handled by the new service so what we are focusing on is now get that remaining 6% and after that the old service will be decommissioned and every update, every query will be handled by the new service and then of course we'll move to updates. Updating the RIPE database will undergo the exact same process, so we'll put something next to it in order to handle all of the updates and slowly incrementally we'll work words to a full service.

So, we'll have concentrated modules for the business rules, syntax checking, for authentification and making sure that air handling is properly done.

We have have we done in 2012? We have done small improvements to the user interface and now for a couple of objects, there is a little button, you are used to the buttons that say update or delete, there is now an additional button that says more information in RIPE Stat. So, for example, if you have looked for anality number, it will take you to RIPE Stat website and give you all the information about that particular AS number so you can see BGP announcements, how you are traffic is routed, like a wealth of information within the RIPE Stat interface, so it's easily linked and very easily accessible.

We have much simpler password generation as well. And we have some other things that we will announce over the course of the year. And lastly, we are working on an API. The restful queries is something we have been working in the IETF. The way that that will work is once a query comes in, if the RIPE database can actually reply to the query, it will do it immediately but it if it turns out that the RIPE database itself doesn't have the response, so it doesn't have that particular resources listed in the database, it will either use the IANA delegations file, or what it knows, to forward that query to another database of the respective RIR and that RIR will then send back a response immediately so. The user is forwarded using an HTTP forward and then they will go to the next database automatically. In the RIPE database you could in the end enter any IP address for thinking in any RIR following under any RIR and you will always get a response, you are automatically forwarded everywhere.

Is that all I want to say about that? Probably.

Okay. And lastly, it's also a bit of a personal thing, this, when I started at the RIPE NCC I started out as a trainer, and one of the courses that we gave was the LIR course where new members get to learn how to interact with the RIPE NCC. And an enormous chunk of that is dedicated to teaching people how to use the RIPE database. I think most of you will agree that for an absolute newcomer, the RIPE database is maybe not the most intuitive tool to use, we would like to work words to a more user friendly way of dealing with it. But we shouldn't forget that there are so many current user of the RIPE database that we have to take into account, so everything needs to have backwards compatability in regards to scripting but also in regard to user interface, what people are used to. What I hear from a lot of people when I talk to them is they say well I have taken such landing time to master the RIPE database, to understand how to interact with it, any change that you make to it, I sort of have to relearn it and I'd rather not have to. But on the other hand, you need to think of methods to make the RIPE database easier to interact with with regards to updates. So once you see that we are start to go work on a new platform for doing updates in the RIPE database, we need to have a good look and how we can interact with the RIPE database and how we like the users to interact with the RIPE database without breaking everything that everyone has been used to and has been doing for the last couple of years. So, for that, we would like active participation from you from the mailing list. From the RIPE NCC, in a lot of cases, we'll be proactive and ask you, like, okay, this is what we have heard from the membership, this is what we get tickets on, this is what our customer services department deals with in terms of requests, in terms of problems, and in a lot of cases we'll try to address those problems by making a proposal to the database Working Group and to be frank, the number of responses and the type of discussion that usually unfolds to these kinds of questions don't really result in something constructive that the RIPE NCC can work with. And that is why I really urge all of you in the RIPE database Working Group to participate in a discussion to make the database as easy to use and as flexible as possible for every possible user. So please help us with more active participation.

There are some things on the slide that maybe I skipped. No, I think I covered it.

That's it. Hi Nick, you have a question?

NICK HILLIARD: Hi, I have a question. AS used?

SPEAKER: Yes, working on that,

NICK HILLIARD: Do you have a timetable?

SPEAKER: Currently, the guys in business applications are further developing the IP analyser which ultimately, I hope, will provide the functionality that AS?used provides so that will cater to a large portion of the needs that you may have. It's reimplementing AS?used from scratch as a command line tool or fixing the problems that currently exist within it is really quite a large project that go difficult to tackle. I don't know whether this is also in the scope of what we are talking about here in the RIPE database Working Group, is it?

NICK HILLIARD: I am ?? I don't know.

WILIFRIED WOEBER: It could be either in this framework or it could be in the services. Anyway, it's going to end up ??

First of all, Alex, thank you.

(Applause)

CHAIRMAN: We promised that we would not roase or kill or whatever you. As we already are having a little bit of discussion about some aspects here while Robert gets set up, just two comments. One of them is regarding the UTF 8 thing. There is quite a bit of activity going on at the moment in the names world and in the ICANN environment, and unfortunately I was not able to be at the most recent IETF meeting in Paris, so I don't know whether anyone here in the room actually had a chance to be in Paris, because ?? one of the questions to be asked there, as I was told in San Jose, was whether there is actually an IETF activity dealing with something like WHOIS MG, and internationalisation and that sort of things. No, it wasn't, or ?? no? Peter? May I ask you to do a brain dump, as deep and as wide as you can.

AUDIENCE SPEAKER: Peter Koch, DE?NIC. I am not sure what that question referred to. There is a WEIRDS effort in the IETF, is that you are you were referring to?

WILIFRIED WOEBER: This is one aspect of it definitely.

PETER KOCH: So the acronym is WEIRDS and I must admit I can't really expand that, the W stands for WHOIS and it's all going to be much better. That's the basic idea and there are two things to note: One is, this is still in discussion, and it's driven by the RIRs to some extent, so Kaveh Ranjbar or somebody else might be able to explain, or expand on the details. Ality ex mentioned the restful approach already there on his slides. There is a couple of motivations, one of which is internationalisation, restful approach, assuming that, and the older people in the room will remember that there was another effort to improve WHOIS called IRIS, or the Working Group was named KRIS back then that, kind of failed and there was a very, very postmortem that that found out that yes, SOAP and XML was so bad back then it would all be much better with restful this time. And all we can hope is yeah, maybe. I may sound a bit ?? I'm not sarcastic and I am not sceptic. So this is the one thing. The discussion there, and that's kind of an IETF process discussion right now, which has concluded almost I would say, is since there are only five RIRs that so well interact and also interact with the IANA, this is ?? the numbering space can be easy to cover probably, so now the name side, which is probably posting the most interesting parts or aspects of the WHOIS problem in ICANN, and I guess the stenographer did not see the quotes here, so, this is like keeping the discussion going, whether or not the names issue should be allowed to interfere with, or defer the work of a to be set up Working Group in the IETF. That's it. And my recollection of the current state of the charter discussion there is, yeah, we are trying kind of a unified approach, but should the group management determine that, yes, the names issues are so complicated they will block the process for the rest. That would be kind of a stopgap. And then the names issues can ?? sorry, the number issues can be addressed first. The idea is to have a unified approach to both in terms of the frameworking protocol, like the restful or what kind of queries there are and so on and so forth. Of course, I think we know that there is much, much policy involved to some extent and finding that boundary between protocol and policy is also a delicate issue there, so there is interesting stuff going on. There is a mailing list, WEIRDS at IETF.org, I assume that become an IETF Working Group and anybody interested in this should go there and contribute to the discussion.

WILIFRIED WOEBER: Thank you Peter. Kaveh Ranjbar.

KAVEH RANJBAR: Peter gave a complete overview of what's happening. From the technical side, we RIRs, we sat down together and found the common area for the numbers, because as, you know, ARIN, for example has a different format than us. For that common range which is make the Internet number resources and contact persons, we have defined an output format, a very simple one, and a query format, again very simple and straightforward queries, all of us an agreed that we implement protocol, so someone can do a query over http restful and then get their response. There are also two drafts. We also had another recommendation as Alex mentioned to run an experimental service between different RIRs so, we forwarded queries because we already have the delegations file, either for reverse DNS or for IANNA. So comes in we forward it to another RIR so a user can get a response. That said, about the UTF 8, in short, that article is there. But since you ask, in short, technically it's almost everything is possible. It's all lacking policies, so what we should not allow in the database we should allow as Denis also mentioned.

WILIFRIED WOEBER: I got that from the summary presentation. We definitely should take it up on the mailing list to get more people involved, yeah. Thank you. And the other thing I defer for the segment on any other business, and Robert, the stage is yours.

ROBERT KISTELEKI: I am Robert Kisteleki from the RIPE. I am not Daniel, as you may have noticed, and I would like to give you an update on two new things that we have got in RIPE Stat that actually exposes database information we believe in a useful format, for you, the users of the RIPE database.

Before going there, I will also want to mention, or have back reference to what Alex already said. A couple of weeks ago the RIPE database guys started linking different objects from the RIPE database to RIPE Stat, in particular these were A altNums and Inet six nums. As of yesterday they also connect the INET NUMs. So v4 works as well. As you can see it on the illustration, there is another button, if you click it you get the explanation from RIPE Stat, which, as you probably heard before, it actually contains a whole lot of information about geolocation, blacklists, routing information and all that. And ever since yesterday, our usage in RIPE Stat went up considerably, which is a good thing. But more to the point.

We would like to show you two of these new widgets and in our concept the RIPE Stat widgets are small entities that you can embed in your own page if you want to that show you different kinds of information about Internet number resources in general. And inside RIPE Stat, a huge contributor to these widgets is actually the RIPE database. So, when they were thinking about how to present the RIPE database data better to you in a more useful form. We were thinking about visualtisation and we were thinking about how to make the data more understandable and maybe even for interactive so that you can actually interact with this database.

As you have heard from Alex, many users are actually struggling with the basic concept, the understanding how the structure is fit together inside the RIPE database. So, first I am going to talk about the object browser.

The object browser starting point is actually training. Inside the RIPE NCC training, we have a RIPE database course as well, and this is, I believe, one of the slides that we are actually using. This tries to visualise that these objects relate to each other, so maintainers are maintaining other objects, those objects in turn refer to yet other objects. You can think about the RIPE database as a huge graph where the nodes are actually the objects in the database and the links between the nodes are actually referrals from an object to another object. So, we had the idea that this is actually a good thing. So why don't we try to visualise the RIPE database like this. And so we did. I'll try to do this live and see what happens. If you fire off RIPE Stat, there is now this object browser widget that you can see, which, in the middle, or at the top middle, always he is shows the object that you are actually looking at. So in this particular instance, I was querying for AS3333. On the left?hand side we can see objects that refer to this particular object and on the right?hand side we see other objects which refer, which this object, the main object, is referring to. What you can see is that we are also using colour coding to make it easier to comprehend the different types of objects.

So, the whole idea here is that these widget is actually interactive. So I can just browse around inside the RIPE database and say okay, what is this route? Well, that's some details it have and it actually refers back ?? there is nothing referring to the route but the route object itself refers back toality number, the maintainer and INET NUM and so on. So just by clicking around you can get a feel of okay, so, who is maintaining this object? This is so?called item Jochem from the RIPE NCC, there is a whole bunch of objects referring to this guy. You can also see that we do not know personal details on this visualisation and that's very conscious. I will go into the privacy details a bit later. But what you can see is that for each of these objects, if you click around them, if you click on them it becomes the main object and the whole graph actually refocuses on the object that you clicked on.

For each of these objects we have a short view an an extended view so that you are not overloaded immediately are too much information.

There are some protection mechanisms here in terms of not overloading your browser, so if there are too many objects that will be returned in such a query, then we just limit the amount there that is shown here. I encourage you to go and click around and see what you can see with this object browser.

Right. Having said that, it is entirely possible for us to actually include history of these objects inside this widget. Technically, it is possible. We believe that for non?personal data objects, this is both useful and not private sensitive, so we could just do it, the question is would you agree that such a service to the community would be useful. At the moment, if I go back ?? at the moment we do not show history at all to anonymous users who are just browsing around on RIPE Stat. If you are an authenticated user of RIPE NCC access, then we give you an indication of by the way there are other versions of these objects and I think we give the number of objects. And if you have an NCC member, we also give you the exact times of when the object changes but we don't give you the historical objects because at the moment there is no guidance on that one. We believe that, again, we should show this object because they can provide tremendous value to the users of the RIPE database.

We are going back to this. About personal data: Query limits are applied so we are in line with the acceptable use policy. But we are doing this accounting at the moment via the RIPE NCC single sign on mechanism. So depending on whether you are logged in in single sign on, and if you are, who you are, are you a representative of an LIR or not, you get more or less permission to look for personal objects.

This is actually the set of limits that we apply at the moment. So, if you are not logged in, you are an anonymous user you don't get to see personal data. That's it. If you are an authenticated user but you are not an RIPE NCC member, we ?? if you have a RIPE NCC member it's 1,000 objects per day recollect it's the same amount in setting the acceptable use policy.

Now, combining these two things. History and personal objects, it would be very interesting to see the history of personal objects, but I think we all understand that that is not an easy task, so we didn't even want to tackle that at the moment. Definitely needs more thinking, needs input from you and obviously legal input as well. How can we do it? Can we do this and so on and so forth? So we are not doing it.

The other widget that we have deployed recently is the hierarchy browser. What it does is focusing on INET NUMs and INET?6NUMS, it tries to visualise how the particular object that you are asking for fits into the big scheme of things into the hierarchy itself. Again I will try to do this live.

What you see here is in the middle, there is the object that I am looking for. That's my main focus. On the level above, it's the parent object, or you can call it the first level, less specific. And under the main object you can see the first level more specifics. All of them, if possible. Now, many many times of course there are just way too many objects, as more specifics, so we have to do something smart in order to prevent the information over load here but we are trying to do our best. So for each object you see the basic information inside here and if you want to double click on it you get back to RIPE Stat and get a full explanation about all aspects of that particular resource. So, in the interest of being interactive, this widget is also clickable so you can just browse around and say what are the objects below this one? Well, let's look at this one. I click on it. Then the whole widget refocuses on the object that I actually clicked on, so therefore, it becomes the one in the middle, and its parent, which is just one layer above, just moves up. You can also see that we have tried to visualise where this block is physically or logically, if you wish, inside the parent range and how much it is, as compared to the parent range. So this particular one is one?third and on the left?hand side of the parent.

You can also see that there are no more specifics here so the hierarchy ends. So, this is very interactive. You can just browse around and say well let's look at the 16, who are under it. We are trying to visualise what are the objects that are maintained by the RIPE NCC. So in that sense, the expected data quality for these objects is, well, can be higher and should be higher than any other objects.

So looking at at the 16 I can see it that it is hosted inside a, 3 times /8 block and under it, there are a whole bunch of objects, well it's 39 at the moment. But, you can just browse around and say oh, that's my favourite one. You get the tool tape and if you click on it the whole thing refocuses. We are using colour codes as well here to make it very visible how these objects relate to each other. So, you know that the RIPE database better than I do and you know what kind of constellations are expected and not expected. Allocations and assignments, assignments should be under allocations and not the other way around. I try not to make a judgement call here, but we are trying to visualise with colours in this case, what is in the database, and if you believe that, that's a good thing. That's okay. If you believe that, oh, that actually helps you spot the problem, that's actually better, or at least it's simpler to notice.

It also works for IPv6, obviously. Because logically there is no difference between those two. So I just started with this particular object for no particular reason. This is a /23 as you can see, and under is that, there are 60 something other v6 objects. Okay, and I could just click around. There is a 32 for someone, and we can see what kind of allocations, assignments and other objects they have here.

Now, if I do this the other way around, I actually go up in the chain, then it's very, very simple to see how tiny we are in the universe, because we can also look at the top level objects of v6, so this is 0/0 in v6 space and if I zoom in a bit you will see that's where you are, okay. It's very powerful in terms of visualisations. And browsing around here one can find interesting examples of how the address space is actually structured and son. I clicked on a /12, so that's more likely I will have a whole lot of objects on there.

So, as I said, the ?? this particular widget works for IPv4 and IPv6. We are trying to voice train in your browser, we are in the process of putting in limits just to protect your own client because otherwise, if we give you 60,000 objects and your browser tries to render them recollect that's not a good idea. And we are trying to mitigate that. Again, it would be possible to show the history of these objects, so, we can provide a, let's call it time machine view or time travel view, where if you are focusing on a particular object, we can give you the versions that ever existed about that particular object. Since these are INET NUMs and I?Net 6nums there is no privacy concern, at least as perceived by us at the moment. But it could, again, be very, very helpful to see how it changed over time. We should, we believe, limit this to RIPE NCC members, in other words, if we apply the RIPE NCC access accounts here, then we could make a difference between RIPE NCC members and non?members and provide this history only to members, so, you can call this an added value for members or you can say that this is actually, it just makes sense to not provide this data to anyone but RIPE NCC members. The question is: Would you agree with this? We believe that this is the way to go.

Okay. Other aspects, as you may have seen ?? the /12 is still there ?? it's 25100 objects are under it and they are somewhere here.

As you may have seen, our current definition of latest, the version that is live in the database, is actually a bit tweaked. At the moment we are using last midnight as the latest object. If your object has changed today, that is not immediately reflected in these widgets. That has just purely technical reasons, if you would like it so, then we can make it happen that it is actually realtime and queries the RIPE database right away.

We would like to believe that these are actually useful visualisations and they allow people to understand how the objects relate to each other and how the address space is structured and used. The colour coding also helps to spot problems. It also could help our own IPRAs when communicating with external members to say, hey, look here is the visualisation of your space, what do you think about it? But that is more into the area of the IP analyser, so we are trying to stay away from that. That's an LIR portal feature.

We would like to hear what you think, because, based on feedback from the training courses, it seems that these kind of visualisations are very powerful and they help people understand the relations and the hierarchy, we would like to keep them on and because we believe they are useful. But, we would like to have your feedback as well on that one.

And finally, it seems like single sign I don't know is a very good method to make a distinction between what kind of objects could be shown and should be shown to different classes of people. Anonymous browsers, signed on members, or signed on users and finally RIPE NCC members. It seems like that could be the way to go as opposed to IP based limiting, which has its own problems. But then again, we would like to hear what you think about this.

And with that, I would like to conclude.

CHAIRMAN: Thank you very much for the presentation. I presume there is quite a few ideas for comments on the microphone. Go ahead please.

AUDIENCE SPEAKER: Will Hargrave. I have just been having a look at this and it looks very good and I think I can use this tool quite usefully. One of the problems is, that it's kind of fixed size and maybe there is some kind of button you can put to make it become bigger, because I have a very large monitor at home and this would be useful.

ROBERT KISTELEKI: Two answers to that; actually one, but two aspects: Both of them are widgets, which means that you can embed them in any page you want to, and the mechanism that we are using to embed them into different pages has a flag that says "Show yourself in micro size or normal size or big size" so it's really, if you embed it into your page it's really up to you.

The other respect is that now we have almost finished digitizing all of the views that we have in RIPE Stat and the next step is going to be exactly that, allow people to have a bit more control like on Windows, saying, maximise this particular view, minimise the view, make it disappear, rearrange. Part of this is already there, so if you are a signed on user, you can already say this widget is interesting, that widget is not interesting, you can personalise the page, but you will be able to say, enlarge this. And that's just works.

CHAIRMAN: Okay. Then, another comment from my end with regard to the access control and to the sort of linkage or the proposed linkage to the membership. As we had the anti?abuse meeting before the lunch break, I can easily imagine that there would be some the of organisations being interested in that sort of data but not being involved in IP address resource management. So, this might be, sort of, another minor aspect to keep in the back of the head for new charging schemes of what new member structure or member categories or member types.

ROBERT KISTELEKI: Indeed. As I said it's a mechanism to make a distinction between different classes of users. It is entirely possible to make different classes of members as well. Those who have resources, those who don't have resources. I guess that the point here is that the mechanism that we are using, the RIPE NCC access mechanism, the single sign?on, it is used throughout virtually all of our services now and it makes it possible to do these kind of differentials, whereas before we didn't have that chance. So we can link back and forth between the database, LIR port, RIPE Stat, RIPE Atlas and so on and so forth so that's beneficial. It's definitely up to the membership to come up with these kind of ??

CHAIRMAN: The I like the idea to link the limits and restriction to say identity instead of IP address, because in particular, in the IPv6 world you can play funny games with IPv6 addresses.

ROBERT KISTELEKI: If you allow me. In SSO we already know who you are to a certain extent. And obviously we cannot or ?? well, I wouldn't say cannot, but it's really difficult to stop someone from creating as many as they want but at least you have an e?mail address, you have something to get on. And for non?RIPE NCC members, we can just disable this kind of functionality. With NCC members, if someone really wants to stretch their limits, we know they are there, we can talk to them and if there is a legitimate reason for this, which is okay with the community, we can change these kind of limits. So it's possible.

CHAIRMAN: Thank you. Any other comments or questions? No. Thanks again. An interesting presentation.

(Applause)

CHAIRMAN: So, may I ask to have the agenda put up on the main screen please? In the meantime, the other follow?up I wanted to make for the RIPE NCC presentation was regarding the geolocation thing. There was a couple of days ago, I think I created a little bit of a misunderstanding by one of my replies. I had tried to sort that out privately already, and to state it here in this Working Group, I think what the RIPE NCC has implemented right now is in line with what we asked them to do. And this is really definitely very useful to be played with. From my personal point of view and it's taking off my hat as the Working Group Chair, from my personal point of view, we still have a couple of major issues to discuss ahead of us and one of those issues, and I think it should be one of the action points on me to take to the mailing list, is sort of who is actually the party which is expected to maintain that data? Because, right now this is directly tied to the maintenance mechanisms, so the entity controlling update rights to the IP address blocks is actually the only party, unless you do some other stuff, is the only party which may modify or register geolocation information. And thinking about, sort of, cross country big ISPs, I am not sure whether this granularity is actually useful to say well in the centre of Europe, or somewhere in The Netherlands and this is one aspect. And the other aspect I am worried about and that's sort of an oversight on my end as well, there are geolocation service providers out there at the moment and they are being used on a daily basis, they are widely used. And I have got no idea what they would think about, sort of, the service we are building in the RIPE database, so, I think we should try to get them into either coax them to join in with the discussion, or maybe actively try to reach out to them. Because I could also imagine that some parties would like to be able to modify their country code location which might not be what the intellectual property rights holders would love to see. So if BBC restricts TV content for the UK and I claim to be somewhere in the outskirts of London, that's probably not what they want to see happening. There are a couple of things, I think, which would need further discussion. So that's regarding the geolocation stuff.

And now let's move on to the aspect that was already briefly touched on, the filtering of authentication information. I was consciously aware that we would want to hide MD5 hashes, but I think, correct me if I am wrong, it turns out that it was not only the MD5 hashes that got filtered or that get filtered but also BGP public key information. I'm not sure whether this is actually sort of helpful. That was something that Wolfe brought up in the coffee break discussion and I don't know whether he wants to add to my introduction.

AUDIENCE SPEAKER: Wolf Kieber. The filtering of the auth attributes basically breaks all mail updates and some of us have scripted and automized their update procedure. So, what I would have expected and hoped for would have been to leave the attributes there and just cut out the value for them, if I have passwords.

AUDIENCE SPEAKER: We knew that this might come up before doing the changes. We published an article on labs we actually mentioned also this. We ?? but no one, no one said this solution is wrong or right. We went for the solution that we implemented mainly because this is much more easier for newcomers. The thing is a lot of people get an object, copy and paste it to send an update. And if we only filter out BGP lines and keep the password lines they can automatically update their object when they don't want to and automatically get rid of their BGP keys or password keys, because they are filtered and they don't know. They just remove the filter and the object. So, we thought that there was a trade?off, it will be for advanced user. There will be a little bit more problem because they have to go to a web updates page to get the object but it saves a lot of work for newcomers but we can always reverse it. There was a Chair proposal to hide, to show outlines for BGP keys only when there is no password involved. If the object only as BGP show the outlines because there is nothing to be miss staining but if there is a mix of pass or the of BGP, do not show the outline. We can do all the solutions. The implementation is, there is really no problem. We also mentioned to the list but there was no further discussion.

The committee makes the decision we can quickly implement this.

CHAIRMAN: So it would make sense to re?open this issue and to have a discussion on the mailing list. Okay.

AUDIENCE SPEAKER: The reason behind cutting out the value, I mean, you can leave the PGPKEY value but you cut out the MD5 value. So basically if you pull an object out of the database, you see there is a value, there is a PGPKEY and there is an MD5 key that you don't see. So, if you know the value, you can just paste it in. If you don't know the value you know you just can't mail it back because you don't have the value. You have to use web updates. So the ?? just cutting the value of the hash gives you more flexibility in the whole process.

AUDIENCE SPEAKER: This is another solution which might work, so it's just as the committee decides we can implement also this.

CHAIRMAN: Okay. Another comment?

AUDIENCE SPEAKER: I am pretty much agree with what was said by Wolf, this idea of cutting only the value gives less problems to the users because you are absolutely sure that these objects is fulfilled with those methods and showing them once and don't show them on other occasions. That makes a confusion, I think. This idea about showing the PGP and if there is no password, so, on one occasion you are showing there is something in the object and another there is not. There is confusion to people.

AUDIENCE SPEAKER: You are right. But the only thing is if you cut something off, it won't be valued RPSL any more, which shouldn't matter but I'm just saying, there is down sides and up sides with all of these solutions but it's just, if the community is aware of all the downsides and upsides and makes a decision, we are all open to implementing very quickly.

AUDIENCE SPEAKER: This one sounds better for me.

CHAIRMAN: Let's take it to the mailing list. Next comment.

AUDIENCE SPEAKER: The thing I would like to comment is again the choice that you made. The choice was: Let's do something that helps the newcomers, and at that time what you did was actually ditching, is a hard Word, so please do not be offended, but you were ditching the people who have themselves automated a lot and broke our tools and forced us with a lot of resources to go to the web updates. I know and I do understand that is also my own fault that I did not pay attention on the mailing list when you announced the change and I could have raised my voice there. So that point is taken and I will not make the mistake again. But this just adds onto the comment I did yesterday in the services group, that you need to balance out the target, is the target the newcomers with the new space that we want to teach stuff and make it easy for, don't forget the old guys with a shit load of space that rely heavily on home?grown automated stuff. Thank you.

AUDIENCE SPEAKER: Thank you, but I agree we shouldn't forget but normally it is our commitment, all our e?mails I sent, I think we had a recent transaction ?? so, but ?? this is actually an open issue, because we want to reach out to as many users as possible. Obviously we use the mailing list, we use the labs, we use all the tools that are as our hands. We are also trying to get into rooms and other places. I see this as an issue which we have to address, but please help us if you have any solutions as well. We know some of you will try to be in touch for some of the issues, but in general, if there are solutions, we are always open to them.

CHAIRMAN: I think we heard your message as well, that we should speak up we should contribute to finding the best solution. And just procedure wise and I am guilty for that one as well, I have to admit that I, more or less, don't pay any attention to pointers to RIPE Labs because it just takes too much time to do the pull thing. I am still sort of living in this old mindset of when there is anything of importance, it comes in through the mailing list and I can read it directly in the screen instead of ?? so, I think we have to find a reasonable compromise between modern technology which is sexy and juicy and whatever, and sort of the die?hards, like us, with a little bit more around our bellies, some of us, not all of us. Okay. So I think we can wrap?up this issue here, and I have got another request yesterday pretty late from the address space Working Group Chair, one of the co?chairs, has input from other Working Groups, and this is related to the discussions that are going on regarding the inter RIR address block transfers. And one of the discussions going on at the moment is whether this should be handled sort of keeping track of that and registering those transfers, that should be done on the plain of the five RIRs without getting the IANA involved or whether this should actually get IANA and ICANN involved. And one of the inputs to that discussion and to that decision is whether we would have a mechanism available, like we had in the past for domain top level country code domain object, the referrals thing, whether we do have a mechanism in place at the moment to do referrals for INET NUM objects and INET?6NUM objects and the request is whether or not we have something on implemented on top of http redirect, that sort of things, but whether we have something which actually can be integrated into, like, a WHOIS client or into some other script. So, I don't know, whether anyone from the RIPE NCC is prepared to have an opinion on that. Kaveh Ranjbar, please?

KAVEH RANJBAR: There are two sides to this, I think one of the parts is actually not technically redirects but if we have to also document this transfer somewhere in the object. I think that's something for committee, maybe if, for example, this object used to be at RIPE NCC but now it's at AfriNIC and then afterwards transferred to LACNIC or... so we might, with the new IPv4 situation, we might need to have that, but that is up for discussion.

For the referrals, as a technical WHOIS referral method, again, I think the work in IETF but that's http, that would resolve that and Denis also ?? ARIN has a prototype which actually works on top of the WHOIS port 43 on top of the API so actually simply we or others can run that and users get normal WHOIS but on the back it runs. So that system also works.

CHAIRMAN: One of the suggestions or one of the answers is well we did that already was the address blocks that were moved to AfriNIC, and it still, this information about this transfer is still in the RIPE database, but I think I got it right when I checked, this is just human readable remarks. And that's obviously difficult to automate or to automatically pause and do something. So, yeah... but I guess, it would not be too difficult to sort of re?establish the capability of the database software that we had for the domain referrals.

AUDIENCE SPEAKER: No it won't be. The only thing we have to decide on which level, if it's only RIR levels because folks LACNIC have this policy that they also forward requests to underneath. And then you might get into a loop which never ends. Then operationally the service ?? the quality of service will be questionable. So there are operational questions, but in theory and technically it's all possible.

CHAIRMAN: So the answer is. Let me try to get an answer to the APWK. It can be pretty easily done but it needs safeguards and it needs sort of planning for implementation. Okay. Thank you.

So, this gets us to the last item on the agenda, the item Z. Any other business? Is there any other business? If there is no other input, no other questions, no other tomatoes, eggs or bricks flying, then I am happy to close this meeting almost 17 or 18 minutes before the allotted time frame ends, which is not a common situation, I guess. Usually we run into the coffee break. Thank you very much for the folks from the RIPE NCC with regard to their reports and being sort of remaining within their time frames. Thanks for the helpful comments and thanks for the activity participation in the discussion. And see you in Amsterdam in the autumn.