These are unedited transcripts and may contain errors.

Database Working Group, 5 May 2011 at 4:00pm:

CHAIR: Ladies and gentlemen, welcome to the Working Group session of the database Working Group. My name is Wilifried Woeber, I'm working for Vienna University and the Austrian national reserve and education network. I'm one of the three co?chairs. We've got the other co?chair, Nigel Titley there in the first row, in case you want to get in touch with us for any reason, grab us in the hallways or on the email. As usual, couple of logistic things. As you can hear I'm using the microphone. If you want to contribute in the discussion, please walk up to the microphones, state your name and if you want to, your affiliation. The whole session is being recorded and being made available afterwards on the network. That's the preliminaries, the logistics things.

Secondly, I'd like to extend my thank you to Nigel Titley for doing the scribe function just once again. The next thing to take care of is deciding about the agenda for today. On the screen here, to the left of me as seen from your end, there is the most recent draft agenda for this afternoon. We're going to swap a couple of things in sequence for eternal reasons, but you are going to find why and where we are.

In particular this applies to the action list. We are going to do the review of the action list right after the update presentation by the RIPE NCC. So for item A, administrative matters the only thing that's left is asking you whether there are any comments or any modification requests to the draft minutes from the previous meeting? No, I don't see anyone raising his or her hand or going to the microphone. So the draft minutes will be moved formally to status final minutes.

And the next thing which is sort of at the border between formalisms and content I'd like to invite Brian Nisbet to give a concise and brief report of the status of the abuse contact management task force and afterwards ?? and we're doing that now because Brian has to move to the other room as soon as possible. Please excuse this out of sequence. And we're going to continue with the RIPE NCC colleagues to give us the database update.

Brian, please.

SPEAKER: Thanks. I shall be short, concise and brief.

So those of you who are in anti?abuse have already heard this. I won't belabour the point but to update. After a number of proposals, particularly 2010?08, 09 and 010, we decided the best idea was to draw those proper pole ass and address the things. There were a number of details and things like that which we wanted to have a task force, intersection with the NCC database group and do it the right way. So to develop one or more policy proposals, how to collect, maintain relevant information in the database. It has been decided that the way this task force will report back to the community is through the anti?abuse Working Group. This is the last time you'll hear this in database. But I want it on this first report just to briefly give database the report as well and from then on you'll see it in anti?abuse. These are the participants. Wilfred and I played rock, paper, scissors. I lost. There are other people who will be drawn in as required, but they're the main participants of the task force.

We've had two meetings so far, one on the 10th of March, had a meeting early on Monday morning here and we're planning on another conference in June. And in fact I just realised I don't think I have the time lines. I don't. The aim is to have something to produce at RIPE 63. So I should have told the anti?abuse Working Group that. I'm sure they'll figure it out. Basic requirements to have a simple point of contact, to return a single point of information easily configured and referenced by others, and presentation of the information. Wooer's exploring bunch of options at the moment. Feedback or input still welcome. And myself and Tobias, are on the task force. We decided rather than creating another email address we'd use the anti?abuse Working Group chair's email address.

So any questions? In which case I shall not take up anymore of your time and return you to your previously?scheduled agenda.

CHAIR: Thank you very much, Brian, and enjoy the parallel session.

May I just ask the RIPE NCC folks to start with their presentation, to give us the database update thing. Thanks.

KAVEH RANIBAR: Hello. I'm the manager for the database group at RIPE NCC. As you might have noticed on the mailing list, it's also the tenth anniversary of the RIPE database software, which is a nice thing. The software has served us nicely of the. Also we were able to implement anything that was wanted. That's just as a note.

I will try to keep this short and this is the outline. This presentation will be given to you by three of us. So you'll see the change.

So I'm sure everybody here knows the RIPE database service, but it's a public Internet resource for RIPE information service. Also Internet Routing Registry and is a repository for resource information. We also have global resource information in RIPE RPSL format, so input data from other database's to RIPE database. All the tools and everything can be accessed through DB.ripe.net. And all the prototypes and ideas are on the lab database.

Okay. That's the six of us in the database group. These are my colleagues. All of them are here today in the room. If you have any questions or anything, please contact us by email or directly get us.

I'm proud to be able to work with this very sharp and intelligent engineers.

I'm not going to bore you with the small detail on stats but all the operational stats can be found on the URL here. Business as usual. Our op time ?? the query op time is close to 100 percent. We're proud of that. As you can see this is from last week. I think the average is 14,000 queries per minute. Now, I will give you to Mr. Dennis Walker who is business analyst and he will give you update on progress action points and ongoing projects.



SPEAKER: I'm Dennis Walker. It's also my tenth anniversary of working with the RIPE database software.

(Applause)

SPEAKER: This is a list of action points since the last RIPE meeting and some projects we've worked on and going to work on. The domain objects, we started at the last RIPE meetings there were 43 it woulds, most of them weren't active, just data left over from years ago that no one touched. We've cleared out 40 of them now. That's the it would object itself and all the subdomains. Three are still activetyly used in the RIPE database. There were four till this week. One cleared out this week. There are three left. They're all working on their own solutions and we hope in the next few months they'll move out and we'll close this action point down and it will all be gone. Once we deleted it no one can create the it would object again in the database without our over write protection and you can't get a subdomain so no more forward domain created. Once the last three are gone we'll change the syntax because it will only be used for reverse delegations, so things like sub?dom, DOM net will be deleted and we'll look at other attributes and see if they're still right for the reverse delegations.

Another action point, safeguard checks before reverse delegations. We did this in December last year. It's no longer possible to create hierarchies of reverse delegations. So if there was also a reverse domain object in the database for a more or less specific you can't create a second one. We did a bit ?? when we implement we did a clean up where there were existing hierarchies we deleted more specific objects. It was confusing because some people may have thought that was delegating something but in effect the delegation software completely ignored them. Now it's clean and there's only one object in the entry.

Pingable attribute we did this in February of this year. There was an RFC which asked for pingable and it wasn't ping C which it should have been. We've implemented as it it said. These can be used in route and route 6 objects. Follow the link if you want to refer to the RFC.

These addresses are now active on the RIS /PWAOEBG /OPBs. So if you want to see how one works you can look at this RIPE object, ping it and see what happens. A little more information, a link there you can follow.

We were asked to look at alternative harsh options for pass words in the RIPE database. We put a little proposal together. We had a look in. Yes, if you really want SHA 2 we can do it. We got a bit of a storm on the mailing list. People think this is probably the least problematic part of using pass words in the RIPE database. So probably we'll have a discussion on it today but if you want it we can do it. If you don't want it, we don't mind. It's your choice.

(Policy 201006. It was mentioned in the IPv6 Working Group. This is basically the registration requirements for putting IPv6 assignments into the RIPE database. We implemented this again in February. You can now use the aggregate by LAR status value and if you use that, the assignment signs all those optional becomes required. Either you have them both or you don't have either. There's again URL there which shows you the policy if you want to check up on what it does. Currently we have about 53,000 INET 6 NUMs. So this feature is in use. And as you heard this week it will be used more and more.

2007?01 has been mentioned a few times this week. It's progressing nicely. One of the actions required for this policy is the RIPE NCC monitors end user resources. The way we monitor is have our maintainer as an additional maintained by these objects. So we're going to do this update very soon. If you notice your ace number or PI space gets edited, we're adding this additional maintainer to monitor this data. We'll be adding the RIPE NCC end MNT to all the AUT numb objects. A. We're replaguing a new MNT and those that don't have either will get the new maintainer. When you see an update on that, /EUG more it, it's just us watching you.

Dash notation in reverse domains, it's been mentioned already this week. We sent a proposal to the mailing list. The idea is to drop the dash notation in the syntax for the third octet. This causes some problems with DNSSEC. When you enter that we expand it in the database itself into 100 different objects. If you're using the DNR that has to be and there's no way of passing it in through the mechanism. We're looking at introducing the dash in the fourth octet. It has to be handled manually. We want to ought mate this process. In this case we won't expand it in the database. It will be stored with the dash and the delegation software will do the expansion.

I'll given you back to KAVEH.

KAVEH RANIBAR: Geolocation has been a hot topic for quite a while and in this Working Group and other Working Groups we did look into that. So generally the problem is right now there's no mechanism to link IP addresses to a location and. So the thing is even if you can find an address for an IP address or an Internet resource, translating address to a location which is more useful is hard, and there is a problem of the content language. And this results in other problems for the end user because access to certain services might be blocked. Some providers, provide content based on geographic location of the user or content could be delivered in the wrong language.

As a solution, we have location and internationalization details. They can be linked to the IP addresses and also ?? I mean there's no need to pinpoint the user. We can provide a mechanism that the resolution can be selected by the person who is recording this data so they cancy in a radius of one or five or ten kilometres this address exists. The holder of the IP address block from our point of view is the best person to provide this data. They should know the preferred language and they're the maintainer of that Internet resource.

RIPE NCC can provide this mechanism through the database.

I mean, what we thought that, yeah, this can be completely optional but if someone wants to opt in, there are benefits for this service. End users, they can receive content in the language of their preference. And also content related to their location. For the LIRs, they will have more control over the location based services and less end user complaints. We had some issues with accessing Google for IPv6 for some reason we were being forbided to Google Italy for quite some days. And content providers, for them it will be easier to address their target audience and RIPE database will hold more accurate data.

So the way forward. We already had interest expressed from Google, Maxmind and IP 2 location. And they have said if the location data is added to the RIPE database it can be automatic /KHREU queried and included in the data sets. It will have higher priority than the other data they might have. Some of these companies, they collect geographical location from various resources. But since this is the authoritative point, this could be the data that they'll rely on mostly. So we thought we can develop a simple prototype on RIPE Labs.

Now for the development and invasion highlights. He will give you a brief demo on that.

SPEAKER: Hi. I work as software engineer in the database department inside RIPE NCC. I'm going to talk a little bit about prototypes and new services our department worked on in the last period of time.

First, a project called Global Resource Services. Most of the details for this new service are available on the RIPE Labs website. This is a reimplementation of the old alternate resources that we had in the RIPE database. We did them better this time with the data is always up to date and we included most of the LIRs and RIDB. The data that these sources provide contains no personal information and no query limits when querying this data. We also included the RIPE source in global resource service or GRS format. We plan to officially announce this in the near future. In the mean time there's still some issues that we would like to solve, first we'd like to get AfriNIC because that would mean we have all the RIRs and we'd also like to sign service agreements with our data providers.

Next the RIPE database API is a project we've been working on for a bigger period of time. This provides you 92 interfaces with interaction with the RIPE database, correcting, reading, updating and deleting objects from the RIPE database. This API is reusable building block for other service and tools and it is already used in RIPE NCC by the other software development departments. Again, all the details about this on are available on the RIPE lab's website.

We've also worked on search forms and tools. We're reimplementing all our services in JAVA and I'm going to give a short presentation after this slide. As a work in progress, we're building a new update forms, and new interface for maintainer authorization form. All of these are close to being finished. Also working on extending our RIPE database rest API, new services for power users.

So now I'm going to go to the demo.

First I'm going to show the search forms. These are available on a public server and will be very soon officially announced.

Here is the search form that replaced the current search form that is available on the ripe.net website and I'm just going to go quickly through it, I'm going to search for an IP, click on search. And here we see the results directly from the RIPE database server. As you can see, recursive results are included. If we want to filter this we can go to the flags tab and select the well known lower case R flag and it will only give us direct results on recursive. There's an INET NUM and a route object. So if you want to filter this further you can go to the types tab, and it will only give us the INET result. There's an inverse look up tab, at the attributes that can be included and you can select which source you'd like to search, we have of course RIPE, APNIC, AfriNIC and also global resource services.

Next, a new service called look up. This provides look up based on primary key and it will always return a single object. If I search for a primary key, I can select the source. We again offer different sources. I select the type of this object,:on search. It will show me the result. And this data is available in different formats, and this can be parsed by script, for example.

Next tool is in my opinion pretty useful for people that want to search abuse contacts. So this tool will search all the live databases, one at a time if you select it. For abuse contacts associated with the resource. So if we search for AS 3333, it will do a lot of queries in the background and only give us the results that have associated abuse remarks in them. So, for example, we have of course the SA 3333 but also 3% objects. If you click on them, you will see these have abuse?related remarks.

Last but not least we have reimplemented the old glimpse system, this search is the GRS, the global resource service RIPE, the RIPE GRS source for privacy reasons. And, for example, if you search for Samsung, you can search, it will give us all the results that have Samsung anywhere in any of the fields that are not private. We can see that it found 242 resources, thee can be drilled down. We can select domain. But also from the start clicking on advance search click on object and select the fields in which we want the search to be searched. If I click on search now it will return all the INET NUMs that have Samsung in the description attribute. There are still 208. These are the new search forms. I'm going to show you a tool that is currently a work in progress. It will replace all the web up dates ToolSet. We have reimplemented it from scratch. I'm going to show you quickly the work flow, the new work flow. We'll first create an object, a person object in the RIPE test database. And it will give us all the fields that are mandatory to be filled in for this person to be successfully created. I'm going to create a person object. Something that hasn't been used before. Use my maintainer, my email address. And here in this tab I can store the pass words associated ?? a pass word associated. I can store more than one pass word and these pass words will be stored for the duration of the session, 30 minutes in this case. When I press submit, the object was successfully created. I see the confirmation message and also the message. I can now modify this object. So I can add another address field under this. This address I'm going to say Amsterdam here and under the phone, for example, I can add a field of type fax. And I can also delete the first address field which I filled in. The pass word as I said is saved so I don't have to input that again, then I say update. The object was successfully updated. The last action we can do is delete. We have to enter a reason. The pass word is again stored and press delete.

It's slower than usual. The person object was successfully deleted.

One last thing I want to show you is the ?? we call it the paste object. It's just a text area where you can fill in your object in RPSL format and submit it to RIPE database directly if you don't want to use the interface. So this, for example, will allow you to add template for the person object then you can fill in here all the attributes, the pass word and click update and it will create the object.

So this was it for our RIPE NCC presentation. If you have any questions related to the demo or presentation?

CHAIR: First of all, thank you very much to all the three of you.

(Applause.)
Are there any comments or questions from the participants?

AUDIENCE SPEAKER: I want to go back to geolocation. Maybe I missed previous discussions on this topic, on the mailing list or other forums and maybe I don't understand who's supposed to do what, but I noticed on the slide it said that there's interest from Google, et cetera. Are there LIRs interested in this?

CHAIR: Well, a little bit of background. In Rome we had a presentation towards this topic and ideas and obviously there was a lot of or at least a recently number of discussions behind the scenes. I personally have to admit that I was a little bit surprised during this week that there were already half?cooked or three?quarters or five?sixths proposed ideas floating around. So I think before we go ahead with the particular implementation we need to do it's a bit more of brushing up the surface and finding out what the real goals are. And after the gentleman here I'm going to add a question from my end as well how this supposed to work.

KAVEH RANIBAR: So, no. They didn't approach us as well. Because we heard the requests for implementing such a thing, we started to actually contact people who we thought might be interested in using this data because assume we provide a place order for this data, if there is a place order but nobody uses it, at the back end side it's useless. So we recontacted these guys to make such a thing is useful for the content provider, yes, if such data is provided, we can use it. That's how they expressed ?? their interest.

AUDIENCE SPEAKER: The question is who is supposed to be providing that data and also the development, are LIRs paying for that

KAVEH RANIBAR: Nothing happened this was just an idea.

AUDIENCE SPEAKER: You are doing a prototype

KAVEH RANIBAR: We want to start a prototype if it is accepted but we also don't have any implementation, we don't know how we want to store it. This is supposed to go to the mailing list, discuss if accepted and also the format. We don't know anything about the format, how or where we want to store it. We know RIPE NCC can provide such a platform. We wanted to open a discussion that RIPE NCC can be such a platform, but that's all. We're not going to push anything.

AUDIENCE SPEAKER: My personal view and this is not /SRE rise /OPB Europe yet this is a problem between the end user and content provider and not the ISP. Thank you.

CHAIR: If I may add a little comment to this particular exchange. It's also, to some degree, obviously, an issue for some operators for some ISPs because always now and then we have something popping up like, well, I was doing some reserve for my ISP environments and for whatever reason and I was looking at the country code attribute for some registration entries and there seems to be pretty much confusion about not the syntax of that but the semantics of that. So it's definitely related to content providers. It's definitely related to someone who wants to find out which language to use. But obviously there's also within the operator's community some folks who want to do something with this geographic information. Could we move on.

AUDIENCE SPEAKER: My question is about the whiz and new tools. You mentioned about the IRS: Are these intended to run in parallel to the whiz protocol or replacement of the whiz protocol? Is there any level of support

KAVEH RANIBAR: They are going to run in parallel, and right now they're in stages, but as soon as they graduate from labs, they will be is ported.

AUDIENCE SPEAKER: You wouldn't be recommending tools like IRR ToolSets to migrate

KAVEH RANIBAR: Generally it's processing XML data personally is always preferred.

AUDIENCE SPEAKER: As long as the information is the same

KAVEH RANIBAR: Yes but formatted in the fields, nicely formatted in XML.

AUDIENCE SPEAKER: I have one additional. Alex Band from the RIPE NCC. I have a comment about the geolocation project. This is actually something that came out of the RIPE NCC internally because our registration services department actually get quite a number of complaints from LIRs contacting them saying we just got this address block and I start handing out IP addresses to my end users and they get Google in Germany, but I'm in the UK that happens frequently. For example, a block of PI space that was returned to the RIPE NCC put into quarantine and hand it out to a new LIR. This happens very very regularly and all these different databases like Maxmind, the frequency with which their databases are updated is lacking behind quite a bit. So we looked for ways to solve that, and that is one of the reasons why we've built such a prototype. Actually just from an internal amount of support and registration department.

CHAIR: Okay, thank you.

AUDIENCE SPEAKER: Peter Koch and now concern is my second name which means I'm going back to geolocation. I appreciate the comments so far but I think there's a potential level of governance or liability and I would like to see this explored and explained a bit more when it comes to who is liable for the location contents, who can rely upon this, how far, does it touch upon licencing issues and so on and so forth. So we really need that

KAVEH RANIBAR: I definitely agree. The only thing that was ?? that's also what I mentioned before. We saw an opportunity. We saw possibility for a platform but we're not going to implement anything without discussing all the logistics, not only technical, but also process wise and liability and lots of other things. It should be discussed in detail. That's obvious.

CHAIR: Comment.

AUDIENCE SPEAKER: A comment from the web chat: This is from James Blessing from Limelight. He says related to geolocation we would be very interested in the data even if it was just generic. And then he adds: But since the RIPE NCC can't even cope with the idea of LIRs having multiple locations.

KAVEH RANIBAR: I think it's more about the LIR locator, if I'm not mistaken. If that's about the LIR locator ?? this one is geolocation and that's what we thought is location per resource or object per the database but that's for organization. The issue is we only keep one official address for LIRs and that's what we visualize. I think that's separate, if I'm not mistaken.

AUDIENCE SPEAKER: Anders from Danish Research Network. This is speaking as an ordinary user on an ordinary soft net trying to use Google. It keeps asking me if I'd not rather have it in Italian and I think that's geolocation. That's not funny.

AUDIENCE SPEAKER: We were in Rome last time we used this subnet, right?

CHAIR: As the queue is empty at the microphones I might add another one and it's asking as a plain user. If you go back to this one slide where you said that the owner or the holder or user of the address space is responsible for the data, what does that mean? Does that mean that my provider has to ?? has to create a maintainer which allows me to collectively collaborate tiffly with the LIR manage my assignment entry in the database or what is the line of thinking?

KAVEH RANIBAR: Again, we didn't plan any detailed thing, but what we had as a general idea is that it's not going to pinpoint a single user, generally for an IP address range. A good example would be NCC's own IP range, we have a slash 21 or something, I don't know is it /24, and that range is in the Netherlands but the language spoke enin RIPE NCC is English.

CHAIR: I have an individual assignment for more than one address. I'm having an assignment entry in the thing but I'm not the maintainer and of course I would want to have control over the geolocation information because I might do sort of wireless transmission to, I don't know, to somewhere.

KAVEH RANIBAR: I think it's good if we have this discussion over the mailing list. There's lots of opportunities with this. I had a chat with other chairs and also presentation that was presented in Rome, it seems one of the good ideas is to have this location data in an indirected format so your provider can dynamically provide it to us and we aggregate it. Then mobile users they can provide it, 911 emergency users can use it. There's lots of possibilities. We wanted to say, yeah, we can do this with RIPE NCC, with the database and there's also interest from the people who really use this.

CHAIR: Thank you for that. There's another comment.

AUDIENCE SPEAKER: I think there's one question, is this a good thing to have this information? Yes, it might be. But the other question is who is using it and third, who is going to pay for it who is going to do the work? Those are different people, broadcasting companies that want this data. But we have to do the work. And shouldn't those people wanting the data pay us to do it or?

CHAIR: Interesting idea.

KAVEH RANIBAR: That's another legitimate concern.

CHAIR: So I think with a view at the clock, I think thank you very much. Thank you again and also for replying to our questions. I'd like to ask Nigel as the next one to walk us through the current status of action items because some of them, most of them might have been taken care of already. Thank you.

NIGEL TITLEY: Right, this will be very quick because we have already dealt with most of these. Okay, so 60.1 is actually closed. That's the provision of the pingable attribute.

60.2 appears to have got lost in the washing somewhere. I think the RIPE NCC ?? it was a rather vague sort of action point. It was associated with the suggestion that the pingable attribute should be provided and there was an action for them to think about what other sort of things might be useful, which is extremely vague and really shouldn't be on the RIPE NCC, it ought to be on all of us. Perhaps people could make suggestions to the mailing list if they think there's other useful trouble shooting attributes that could be provided.

And then from the last RIPE meeting, 61.1 has been done. 61.2, that's ongoing because ?? actually, no, it's actually cleared because the RIPE NCC has looked at the sort of thing, sort of pass word harsh that could be provided and put a note out to the mailing list so I would suggest that one's cleared. There was also an action on all of us to think about where we should go from here, after pass word authentication, if we wish to do so. And I haven't actually seen anything about that on the mailing list. So that one, I think, is still open.

And I think, yeah, that's it. So we're actually got very few open action points at the moment, which is rather nice. Any questions? Good. Thank you.

CHAIR: Which is a good thing to have very few open ones because we're either lazy or doing the job. Next is Peter Koch with a brief thing as well.

Peter Koch: Good afternoon everyone. I guess I'm wearing the hat of DNS Working Group co?hair at the moment but this is not an official DNS Working Group item. By the way, this spotlight is a bit making me feel in a public interrogation so I will expect some questions after. Nigel kindly complained that they're running out of action items and I thought we maybe could do something about that. And also we haven't been deprecating anything in the recent past, so that's some tradition that we could take up again.

So what happened? Dennis already mentioned that forward domain objects have been removed or almost removed from the database. And also he mentioned that there are no longer any children of reverse delegation objects in the database anymore and I call them shadow objects here but you know what I mean. With that the RIPE database domain objects have the sole purpose of provisioning the reverse tree. And of course you all would miss ENUM. These two purposes are fulfilled by this. It might be time now to look at what the domain object provides and it was mentioned after the final removal of the forward domain objects there might be the opportunity to get rid of some of the attributes. This is it. Read it quite quickly. I'll not go through every line. There's lots of attributes. Some of of them are generic, notify change, so on and so forth, as well as the different context. But then there's some rather specific for domain and I'll mention a few of them and Dennis gave you a sneak pre?view of what might be in this presentation. Sub?dom is an additional attribute that was supposed to give you the opportunity to list the subdomains of a particular domain name. Actually the syntax description says that these subdomains are not supposed to be given in a fully qualified domain name manner, but if you look at the database and occasionally I do read the database for fun and profit. If you have a look at that and see there's funny stuff people do. There might be some use but either we should change the documentation or find out what they were really up to and give them the opportunity to do it in a more appropriate manner. So for some reason it looked like some people were actually repeating the country code in there as a subdomain, even in the reverse tree. I'm not sure that was intentional but there's lot of objects in there that have this property. There is a group of objects in the reverse tree that is v4 in other objects in the database that kind of cross reference each other, like 256 sibling objects basically with 256 pointers each just pointing across. And some random stuff. I couldn't really glance what it was. And of course some get it right, there's real subdomains in there. But what's the perceived need if this is only used for the reverse tree in the future? Would this attribute be of any use that can definitely be questioned.

Next one is dom?net, that is a very ancient attribute, the description says it should be a list. Actually it's written in real English and I had a problem with copy and paste. Networks in a domain, whatever that means. I wasn't sure what the original purpose was. Luckily less than 1% of the domain objects, not counting the forward ones, use this attribute and what sense would that make in the reverse tree at all? So something to potentially get rid of. And then that's with credits to Denis because we had a short hallway chat about this already. The N server attribute is still optionable but now that we know the object's purpose is no longer random documentation but provisions for the reverse tree, it might be advised to make this attribute mandatory for a variety of reasons, unless we find some good use to document reverse objects in there that don't have name servers.

And related to that there's MNT lower. Now that we don't have shadow objects and children and so on and so forth and authorization is done via INET 6 NUM, you don't have any INET, everybody has v6 objects. This is true for both v6 and v4, MNT might not be useful anymore. What can we do? Instead of deprecating stuff that people desperately and deliberately use, maybe we could examine what's happening there, which is hint hint this is potentially ending up as a new action item for someone hiding.

After examining the use, what are the figures, what are the numbers, maybe talk to people who use these and ask their motives and if there might be a better way, discuss these things between our two Working Groups and in the end, where appropriate, do some clean up and get the documentation straight. And I guess that's basically it.

CHAIR: Thank you very much. Comments? Questions? We are getting one. Shane.

SHANE KERRY: I think it's a great idea. I would advise not to be too cautious, just move forward as quickly as possible.

Peter Koch: I can't read it or hear it.

SHANE KERRY: I would advise not too be too cautious. I don't think there's much advantage in getting a lot of feedback, I think it's better to move forward, specially some of these attributes which have no defined purpose at all.

CHAIR: That would also be my feeling. I think those things which are definitely out of scope because the purpose is no longer there, I think they are easy. Some others may require a little bit, warrant a little bit of discussion and this leads me to the question are you going to take the lead in DNS to ?? or are we going to have this discussion on on the DNS list or are we going to have the discussion on the database

SPEAKER: Maybe we should have this discussion over beer and whoever loses makes the Lee /SWROPB part.

CHAIR: Okay. Sounds like a plan. Thank you, Peter.

(Applause.)

CHAIR: I'd like to ask Shane to briefly walk up through the current state of affairs to move data to and from the registered database.

SHANE KERRY: I'm Shane Kerr. This is actually not my proposal, I'm proxying this on behalf of Martin Millnett. He raised it on the database Working Group, I think last week, but relatively recently in any case.

So the proposal is TLS for Whois data, so TLS is transport layer security, basically SSL, the next generation of it. And the idea is that it will give us a few benefits if you use this instead of just raw TCP to do your Whois look ups. The first benefit is confident alternate of queries, people can't snoop to see who you're looking up in the Whois. Second benefit is you know the answers you get back are the correct answers to the questions that you asked. And the final benefit is you can be sure that it came from the Whois server and no man in the middle attack. In order for this to work you have to have a server certificate with all the complications and problems that that brings. But it requires really no additional changes to the RIPE database itself.

So another possibility is to use this restful API for this kind of stuff. Martin addressed this. He says several RIRs have new database API's. We see the beta data stuff from the RIPE Labs. ARIN also have a similar thing on their side. The reason not to use it is TLS is simple and it offers compatibility with the existing Whois protocol. If you have scripts and tools that you have ?? that you've written already for doing various monitoring and checks of your updates, you don't have to change them very much.

So these are the full details of what would actually be required for this new functionality. The first is the normal port 43 Whois look ups would have to be done on a different port and that would be secured via TLS. It's also important to secure the FTP. This is the way to do bulk transfers of Whois data. There's currently no way to get that in an authenticated way. The suggestion was made to use FTP address and map to ?? that's an example of how you would use that from your browser.

So I want ahead and whipped up a sample implementation. This is a simple Whois client written in Python 3. You get the query from the command line, connect using a socket, IPv6 of course. Send your query, read the answer and print that out. In order to upgrade this to our secure method, you import the SSL library, use that when you create your socket and make sure you connect to a different port. This is to illustrate it's quite a simple change from the client's side. This ?? to be fair I cheated a little bit here. Using this code you don't use certificates to confirm that it's correct. But ?? but that would ?? doing certificate work would be longer than the rest of the program so I left that out because I'm lazy. That's it

As I said I'm just proxying this idea. I'm doing that because I think it's a good idea. Yeah, that's it.

CHAIR: Thank you, Shane. Can we have some feedback from the community? We had a couple of comments on the mailing list, but I think it's a good idea to ask here in this environment. Does anyone have a point of view with regards to this proposal? Yes? No? Useful? Potentially useful? With my security hat on for a second, I usually like things that protect stuff, even if I don't know what against.

AUDIENCE SPEAKER: Peter Koch, random whatever. Shane, you gave me ?? just gave me the comment don't be too cautious and I would like to echo that to the extent that yes, getting authenticity and confident alternate for the queries there might be a desire, but if I remember correctly, if we have that then in the context of contact and registration and assignment objects, we have a protocol that would deliver this in a more structured marijuana than adding TLS in a report and I'll wait for Marcus to get up and say IRIS because I'm not brave enough. If there's enough demand for this, wouldn't it be time to reconsider there tiny nice little protocol which might be a better fit than this one?

AUDIENCE SPEAKER: Now since you mentioned the unmentionable, I actually like this proposal, I like Whois, it might not be perfect, XML isn't in there but this is why I like it, easily handled, easily written, and I have lots of scripts that connect to the Whois server and path the results. I don't see Whois going away any time soon. And this is not very much overhead to add TLS to that. The script is easily extended and I think it could be useful.

CHAIR: Okay. Thank you.

AUDIENCE SPEAKER: Marco's, nickname is IRIS, but I'm not going to talk about IRIS. What I see is there is a necessity, and the reason for not moving to the rest API, if I understand Gert correctly or understand that the person pushing this thing forward is, you already have an base of script and you don't want to change anything. So I think it would be a very good idea for RIPE to provide some kind of style sheets that easily trance form the XML from the rest API into the existing syntax of the Whois. So that's really ?? it's work for a Friday evening and you have a very easy: That delivers the same format as before and those people have a similar conversion of their scripts and use the rest API

CHAIR: Okay. Comment from the community.

AUDIENCE SPEAKER: I have another comment on the web chat from Charles who says: Security while searching the DBS is critical, isn't it? It's a fantastic idea.

AUDIENCE SPEAKER: RIPE NCC, so regarding mark's comment, we offer an RPSL version, so this is not publicly advertised, but it is available.

CHAIR: Okay. So listening to the discussion ?? do you want to add something?

SHANE KERRY: I'd like to respond to the suggestion to use IRIS. I was involved with the IRIS protocol definition and also the prototypes the NCC put together. To be understand I consider it a failed protocol. I think there's no harm in trying to push that forward, but I think the vast wait of install base, the simplicity of Whois it's very very difficult to unseed it, this is a small incremental improvement over what we have now.

CHAIR: Okay. With that discussion and that background, I think we could put an action on to the RIPE NCC to do an investigation what the effort would be to implement that, how big the effort is. We do have an expectation already, but sort of to put it through the reasonable format.

AUDIENCE SPEAKER: So one change is to change the RIPE Whois server, but before that you need to establish a port, so you need to personally or not to define the Whois S protocol or whoever you want to call it and then get an assigned port to be standard instead of randomly choose one

SHANE KERRY: Could do that.

CHAIR: I think this is all aspects that could be sort of wrapped into this assessment like what the effort is. Any objection against this action on the RIPE NCC? No? Okay. So thank you, Shane.

(Applause.))

CHAIR: The next thing on our agenda is the follow?up on the discussion regarding replacement of MD 5 by SHA 2. So do you want to give us a very very brief report about what your point of view of the current discussion is?

SPEAKER: Hello. So the original idea was to replace the MD 5 by some modest ?? some newer algorithm, SHA 2 was the original idea. And after the presentation during the database Working Group meeting in Rome, I felt is that I've got support for that. But something like two weeks ago, there was a discussion on the mailing list and I realised that there is a stronger position to that. I was even pointed out that the current MD 5 implementation is good enough, and we shouldn't be worried about it.

Okay, I have noted that. But right now, if there's such a strong position to move from MD 5 to SHA 2 or another algorithm, I think that there is no way to make a consensus in that. So we should abandon that idea. Then we basically have to think about just forgetting pass words, just removing them and so on and so on and go to the public key infrastructure or BGP, whatever, as the only kind of authorization. But I'm personally very sure that there will be at least as strong a position to that idea, and we will not make any step for that, because there's a lot of opponents to /KHAEUFRPGing the pass word to something different and a lot of opponents from the other side. I don't know if that was brief enough.

CHAIR: Thank you. So we are stuck, more or less. I don't know does the RIPE NCC, the database group, have some sort of feeling or data, what the usage rate of clear text pass words is? I think I saw some data, some figures a while ago in one of these wrap ups

SPEAKER: About 50:50

CHAIR: About first 50 of plain text pass words as opposed to some damage /TAL technology. /AOPs. This sounds more like an education problem than a technical problem. Where are we going to take it from there? Any ideas? We just go on with life and carry the pain or is there anything we should be doing? I think Shane.

SHANE KERRY: Shane Kerr. Yeah, I don't know, people like pass words. There's not much you can do. I think it would be ?? I don't know if it's ?? if the NCC would be authorized to do this, but it might be nice if they did some pass word cracking on the contents of the database. It's not hard to do, and you could at least find people with really short or pass words that are the same as their maintainer name or pass words that are English words and things like that.

CHAIR: That's part of the problem because the harsh is publicly available whoever grabs the split files can do that as a past time.

SHANE KERR: Right. What could happen is the NCC could do this on behalf of the crackers.

CHAIR: And publish the results

SPEAKER: And either contact the maintainers or lock the objects. It would be kind of a very low bar, but it would help a little bit.

SPEAKER: The problem is that leaving these empty files in the database opens us up to misuse of resources if it becomes crackable. I think we've got to take a position on this because we can't just term ?? I don't think we can turn around and say this is a matter of education. If we don't do something about it now, somebody with malicious intent will.

AUDIENCE SPEAKER: That's better again. I have one more idea which we have been talking about in the break about removing the pass word from the Whois out put. But everybody should remember that there's the possibility of the source scan right now and the guttering of the pass words and I'm pretty much sure that when we remove that from the Whois out put a lot of the pass words will still remain the same and that will lead us to probably nowhere. So that's not the solution. We should remove the pass words in general, educate people to forget about pass words. You said in that discussion about possibilities there is always a last chance when you lose your key, forgot your pass phrase and during that discussion I remember that we have invented the idea that the LIR out put or direct content could be a last chance of recovering the power over the maintainer.

CHAIR: Right but what we don't know at the moment is how much of those clear text passage users are done by human\beings and how much of that is hard wired into some automatic mechanism.

AUDIENCE SPEAKER: Denis Walker, RIPE NCC Working Group. If you wanted us to do some pass word cracking, I think we'd have to check our legal position on that first and see whether we would get into trouble for doing it. As you said, it's not actually our data or pass words. Secondly, if it would help, we could look at hiding the encrypted strings. We don't actually provide bulk access to maintain objects to grab the things, but obviously you can individually query each one with no limits on querying them. If you think it would help to hide them, we could look at that as a possible option.

CHAIR: Actually I think this ?? as a technical approach I'm pretty sure it's possible, but we made that attempt already once and it failed miserable with hiding some other stuff from the object. And this has hurt us in the framework of the automatic mechanisms in the host masters and it's probably going to break a couple of things if you want to delete an object. It's probably going to be tricky. It's probably not just hiding it but doing lots of other minor things to make sure the rest of the machine still works if you get the object, but it is not complete. And you submit it again for deletion.

AUDIENCE SPEAKER: I think technology has moved on since we last looked at this. There are solutions to a lot of these issues now.

CHAIR: Okay. Shane, you want to finish up?

AUDIENCE SPEAKER: This is Shane again. I think we want to be sure that we look at ?? do some cost?benefit analysis here. I'd like to know if we could actually ?? have there been reports or problems with this? Has the RIPE NCC say my objects have been compromised because people have ?? someone has stolen my password or something like that

AUDIENCE SPEAKER: I can actually recall an incident where a customer had misplaced their maintainer password and sat there and cracked it and got it back.

CHAIR: So it was not malicious, it was just ??

AUDIENCE SPEAKER: No, but it's possible.

CHAIR: An out of band access technology. What's the proposal, how to move forward? Should we go back to the mailing list and try to find out what the general feeling is? I don't want to have it lingering around in this state.

AUDIENCE SPEAKER: Peter Koch. I think I'd like to see some more numbers on the usage. I'm not sure I understood what Denis and his colleagues were trying to convey here, like to convey as in not to false the message, but anyway, is it the number of objects, 50:50 percent? Is it the number of up dates? And if it's the number of up dates, how much of the address space is actually affected by this? If people are using the passwords as a safeguard like these clever mechanisms where you can reclaim a password by knowledge of your mother's maiden name, this might be an aspect of user education. So I think we need to better understand what the problem space is here. Most people would probably agree that pass word are probably as ancient as v4 addresses.

SPEAKER: We can do some analysis, which maintainers have passwords only and other options and how much of our resources are covered or maintained by these maintainers by only passwords.

AUDIENCE SPEAKER: It might be a good idea once you collected that information to go and do some targeted mailings to some of these people, by the way you're using an old form of protecting your maintainer and recommend to see what sort of up take you get. It might be quite a lot of the problem solves itself in the first run. Don't know.

CHAIR: Okay. So that's the RIPE NCC have any clue what we expect them to do? Yes? Okay. So together with Nigel's help, I think we can put together a reasonable detailed wish list. Thanks to everyone for the discussion regarding this topic. And as we are pretty far down the time line in this Working Group, and there is a BoF starting in about 20 to 30 minutes, 25 minutes, I'll try to be a little bit quicker and to again rearrange stuff.

Do we have to cover the DNS dash notation, just once again? It was extensively presented in the DNS Working Group. It was part of the RIPE NCC's update here. Is there anything you want to add regarding this one or can we just tick it off from the point of view of the database Working Group? With the bottom line good idea has been discussed, please implement? I guess the DNS Working Group is at that stage, correct?

SPEAKER: Yes.

CHAIR: Okay. As I don't see any contribution or any objection, Nigel could we please have an action on the RIPE NCC to go ahead with everything that's needed to implement the dash A to dash B functionality with regard to reverse delegations.

I'll skip forward. I would like to apologise that I missed the fact that Peter had brought this up in the first place. I got it wrong by receiving an email message from another gentleman, and that's the idea to one way or another record the information for PI resources, which one is the sponsoring LIR. Being at the ACM task force on Monday and looking at the mandate, I don't see that one implicitly or explicitly included in the mandate, that's the reason why it's's here as a separate item. And I'd like to collect points of view like it's a good idea, it's a bad idea. Personally I think it is a pretty good idea from the point of view of house?keeping because for PA resources, in a very implicit way, you can find out which LIR is the responsible party. For PI space or independent user resources, this is no longer possible, no longer easily possible.

So I think the original proposer should get the first word.

SPEAKER: I'm pretty much sure that last time in Rome when I was speaking with Brian we agreed that this proposal will be ?? because that was 2010 dash ten, I think, the proposal will be postponed for a while and that will be under the mandate of that task force. But I could be wrong.

CHAIR: Well, 50:50. I think originally the thing was brought up in the context of sort of abuse stuff management. And with that regard, I think it is definitely part of the ACMTF's activity, but on the other hand this is also, from my point of view, this is also house?keeping and sort of resource record keeping and that's the reason why it's an also here. I don't mind when we stall it in the moment in this framework and wait for the results in the ACMTF.

SPEAKER: I spoke to Brian about this earlier, to ask him whether he felt that this as a general idea was in scope, for the TF, and he had a think about it and I believe he spoke to yourself and the conclusion is it isn't because it's a bigger concept than just ACM. From my perspective I would like to see where an LIR has some sort of resource, I'd like to see that LIR noted in the database against that resource. Whenever I've asked before I've had feedback, can't get that, it's only PI, anything to be difficult, why is it any use to you? To be fair I can't imagine this is complicated. If you look outside the scope of abuse, specially RIPE 452 and who the sponsoring LIR is for end user resource, there's an organization that's attached that may not be accurate or the organization may be the resource holder but may want to know who the LIR is not from an abuse perspective but just to understand where that resource is being used or which country ?? where the LIR has registered it. I don't see why it should be kept secret or if there's any need to protect it. I'd be interested to know if there's any privacy implications considering all the PA stuff is published

CHAIR: My feeling is it's more or less the same problem as some organisations perceive it being a problem to use the routing registry, because they are giving away sort of what they perceive as internal business stuff. That would be my wild guess. If you do it by way of the organization object it becomes very very easy to just push the button and get everything that hangs off. If you come from the other end and you want to get information about a particular block of addresses or an ASN and you get the reference or point, okay, this is the folks who had the contract with them

AUDIENCE SPEAKER: I can't imagine as an LIR why you would want to hide the list of resources that you provide or sponsor. I think that's a crazy idea why you would want to do that? Can anybody give me a counterer argument? Is there any LIR here who really feels they wouldn't want this information published about them?

AUDIENCE SPEAKER: If you want an argument why an LIR would like to hide that list of source that they are providing as a sponsor, that was the point on the original proposal in Rome, and it's a simple thing, it's a business. If I am telling everyone in the whole world that those are my customers, my sponsoring LIR customers, I am facing the fact that someone wants to change their mind to change the sponsoring LIR because maybe my fee is too much and someone else could do that with 1 euro or something like that.

AUDIENCE SPEAKER: Not only is there a market to be a sponsoring LIR but that market could be highly competitive and it could be considered a trade secret, wow?

AUDIENCE SPEAKER: There's a lot of independent resources as far as I remember so that market is quite competitive, I think, in some regions at least.

AUDIENCE SPEAKER: I think information about who sponsoring LIR for PI resources is competitive information. I would not be happy if that was displayed.

AUDIENCE SPEAKER: Okay, but I could have a look in the routing table, I could see if they're attached. They may not be you could just be sponsoring.

AUDIENCE SPEAKER: But you're not a normal user or my competitor. If somebody who is my competitor in Norway and starts digging around I'm sure they could find out lots of stuff, but I don't want to give it to them easily.

CHAIR: Shane.

AUDIENCE SPEAKER: Yeah, this is Shane. I'm not ?? I don't represent an LIR so my opinion doesn't mean too much here I guess. I'm not really sure what the written definition of the responsibilities of the sponsoring LIR ?? are they written down exactly? Or does it just say you have a contract that says something?

CHAIR: It's pretty well defined. And there is a sort of a requirements document which is on the website. And whatever I try to provide independent end user resources to any one of my ?? we don't call them customers, but participants in the network, I have to enter a legal contract with them. And at that time both parties assume the responsibility to do a couple of things. And one of these couple of things is actually to keep the contact data up to date and to make sure that the contract remains in place, as long as the resource is available to this entity, and also to make sure that whenever that contract expires or gets cancelled or whatever, sort of goes away to do the right thing, and ultimately if you don't do the right thing, this is a reason for the RIPE NCC to reclaim the resources. So from my point of view, I think it's pretty well defined.

AUDIENCE SPEAKER: From what you described it sounds to me like presenting the sponsoring LIR information fits in with the idea of the database quite well. It's a place where you're supposed to find out who to go to for any kind of thing associated with the resource and with PI space we don't have that. So reflecting this information ?? it seems to fit the spirit of the database quite well.

AUDIENCE SPEAKER: Seems to fit the spirit of 2007?01 as well.

AUDIENCE SPEAKER: Also. I can also understood why LIRs don't want that, doesn't mean we shouldn't do it necessarily

CHAIR: We have to develop a rough consensus and we can try to do it in this framework or if this is not easy or felt appropriate, we can push it over to the address policy because it's related to that.

AUDIENCE SPEAKER: Yes.

AUDIENCE SPEAKER: I've been missing this information in the database, at the same time I can see why everybody doesn't want it to be outside. But maybe the major is what the status is sort of unclear. If you have the contractual relationship, et cetera, then probably the parts involved in this stuff ?? I mean, sometimes the end user doesn't know who is the sponsoring LIR and sometimes ?? we had a couple of AS numbers that we were using and we didn't know who is the sponsoring LIR for these AS numbers and we had to ask RIPE and they said, yeah, okay, you get them. But there should be an easy way to find this information when it's relevant.

AUDIENCE SPEAKER: I'm sorry, Dave Friedman again. That is a challenge in the transmission when 452 is fully adopted and all the contracts are in, there shouldn't be a case of ambiguity, unless the LIR is in a state of transition or being acquired or something like that. I agree with you. If I'm given a resource to reachability to root prefix, AS number, I would be asking as ?? I will ask, who is your sponsoring LIR, show me who your sponsoring LIR is and show me you have a contract in place and how long that lasts for. I don't want that contract to expire and have to wait the delay time with the NCC doing something but me continuing to root it because it's a valid resource. I'm not suggesting we publish that, but I'll ask the resource holder what sort of relationship do the have with the LIR.

CHAIR: Thank you for this lively discussion. My feeling is we should take it to the mailing list and think a little bit more and try to get more people involved in this discussion. And maybe even involve the Address Policy folks because it's more than just a database scheme thing.

This gets me to the last open thing. We are one minute from the closing of this Working Group. So I just want to give you the idea that was behind the ideas G and H, the report from the Whois within ICANN and the item of do we need Whois next generation protocol? We have been working pretty hard since San Francisco with quite a few groups within the community with regard to capabilities, functionalities, mandate and history of Whois in all shapes and all colours and all sizes. And it turns out that there are quite a few groups, quite a few organisations at the moment pushing ideas from the left?hand side of their brain to the right?hand side of their brain and back again, like do we have to start over from scratch? Do we want to make the Whois the historical Whois infrastructure capable to deal with the up to date modern requirements? Like think about internationalization, think about international character sets, think about Peter's presentation about Polish language and script issues with funfully characters, there's lots of stuff in there for which there is no specification in the Whois, neither from transport nor how to store or access that stuff. And as we are out of time I'm not going any deeper into that one. But I'd like to invite you, if you have any interest in that, to read up on that stuff and to maybe sort of have a discussion on the mailing list whether there is a need to do something. And if the answer is yes, then let's try to find out what we want to do and how we may be get there. Of course there was this acronym mentioned already today which has this funny smell to some of us. But even if we would revive or dig out of the ground this corpse of IRIS, my personal point of view I'm of the opinion it still wouldn't be the solution to the issues we have on the table today. It might be a starting point but not necessarily the solution.

Okay, with that it's the question any of other business, which is not from my end? No? Thank you for being here. Thank you for participating. Thanks for the discussion. Enjoy the rest of the evening or some of us enjoy the AMT BoF in the other room next to this one. Thank you and see you in Vienna.

(Applause.)