Hello Nick, Gert, All of this information is in the RIPE Database, which is what it's for; it's just not in this bulk representation. What you're requesting is not really straight forward to implement, and would require quite some resources to get done. Could you give us some context how you would want to use this data, and what you currently are not capable of doing using for example the RIPE Database? Thanks, Alex Band On 1 Aug 2012, at 15:43, Gert Doering <gert@space.net> wrote:

Hi,

On Wed, Aug 01, 2012 at 02:19:20PM +0100, Nick Hilliard wrote:

...

The RIPE NCC maintains a list of what allocations are associated with what LIR in the following file:

ftp.ripe.net:/ripe/stats/membership/alloclist.txt

However, this file is limited to v4/v6 allocations only. There are no direct assignments (PI addresses), no ASNs or other number resources (e.g. ERX under contract, and so forth).

Would it be possible for the NCC to examine whether they could publish what LIR is associated with what number resource, for all the number resources they handle, not just allocations?

Yes, that would be nice.

Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

Dear Gert Well almost and in a round about way. All ALLOCATION objects are required to have a reference to the LIR's ORGANISATION object. All ASSIGNED PA objects are more specific to an ALLOCATION with this reference. So it is possible to get this part of the information with an inverse query on the ORGANISATION object and then a more specific query on the returned ALLOCATION objects. Beyond that is tricky as the reference to ORGANISATION is optional everywhere except the ALLOCATION objects. What you are asking for would be possible if the reference to ORGANISATION was mandatory on all allocated resources. regards Denis Walker Business Analyst RIPE NCC Database Group On 01/08/2012 16:56, Gert Doering wrote:

Hi,

On Wed, Aug 01, 2012 at 04:46:23PM +0200, Alex Band wrote:

...

All of this information is in the RIPE Database, which is what it's for;

It is?

So which LIR is AS5539 attached to, if I may pose a random example, and how do I find that out from the RIPE-DB?

Actually, from the RIPE DB the relationship between a certain object and a certain regID is very hard to find (if possible at all), while nicely straightforward from the alloclist.

Gert Doering -- NetMaster

On 01/08/2012 16:42, Denis Walker wrote:

Beyond that is tricky as the reference to ORGANISATION is optional everywhere except the ALLOCATION objects. What you are asking for would be possible if the reference to ORGANISATION was mandatory on all allocated resources.

Hi Denis, Thanks for your reply. Somehow or another, alloclist.txt is built from information which is held by the RIPE NCC. This information includes the LIR regid, which means that you have a pretty much direct mapping internally between allocations and regid. Separately, there is another file maintained on the RIPE ftp site called delegated-ripencc-latest. This includes all direct assignments, all ASNs and all allocations. What I was looking for was something along the lines of delegated-ripencc-latest, except with an extra field to include the regid if it exists for that particular object. I don't see any particular need to include this information in objects in the ripe database, because it would probably be difficult to do due to backwards compatibility reasons. But it should be pretty easy to augment delegated-ripencc-latest with an extra field, no? Nick

Hi, On Wed, Aug 01, 2012 at 05:42:47PM +0200, Alex Band wrote:

I see what you mean now.

You can find out who the holder of the resources is just like this: https://apps.db.ripe.net/whois/lookup/ripe/aut-num/AS5539.html

So to answer your question, AS5539 is attached to: as-name: SPACENET descr: SpaceNET AG, Munich descr: Internet provider in southern germany descr: Joseph-Dollinger-Bogen 14, D-80807 Muenchen descr: Germany

But of course you know this.

Actually, I don't. I now know who is using AS5539, but I do not know who gets billed for it, and who takes responsibility (by means of the 2007-01 contract) for it. For AS5539 that was not a particulary good example as "holder" and "LIR" is both SpaceNet/de.space - but let's look at a more interesting case, AS196611...

The only thing you can't easily find out is the reg-id, although it is available information here: https://www.ripe.net/membership/indices/data/de.space.html <-- it's in the URL! :)

Hmmm. This gives me mapping from "I know the regid to the contact data", but if I don't know the regid yet - how do I get there?

So I apologise for the confusion, it seems with "which LIR" you don't mean their name and contact details, but (just) their reg-id. Why would you like to know that specifically, if I may ask?

Actually, it would be interesting to learn how to find out LIR name and contact details for AS196611... "org:" points to "the holder", and so do admin-c: and tech-c: - I could do some guesses based on the mnt-by: used, but that could be changed to something arbitrary as well. The regID would be a convenient key to be able to map "I know one object" to "what other objects does that LIR have?" - which I mostly use for statistical stuff based on routing table and stats files, to add the mapping "these all belong to the same LIR" that the stats files do not have. OTOH, since you need the regid to get the membership info, that is another quite obvious use :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

Hello Nick, Gert, I have done some research on this topic yesterday. Based on my findings, there are two aspects that I would like to cover. First, there is the matter of the reg-id itself. The reg-id is an identifier that the RIPE NCC uses internally for maintaining records in the Registry. The fact that it is referenced in the alloclist file is essentially an anomaly, which is the reason it doesn't appear in any other place such as the RIPE Database. However, there actually is a public identifier which has a one-to-one mapping to an LIR. This is the LIR's org-id, such as "ORG-INEX1-RIPE" and "ORG-SA17-RIPE", as referenced here: https://apps.db.ripe.net/whois/lookup/ripe/organisation/ORG-INEX1-RIPE.html https://apps.db.ripe.net/whois/lookup/ripe/organisation/ORG-SA17-RIPE.html The information associated with this identifier is directly maintainable by the member from the LIR Portal, and should be preferred for public records. In short, if we are going to maintain an exhaustive list of all resources associated with an LIR, it should reference the org-id of the LIR and not the reg-id. Secondly, there is the addition of all resource information to the existing allocations list in bulk format. The request that you have has actually been brought up and discussed before on several occasions, even at the RIPE 63 in Vienna. The reason why it never came to an implementation is because of the the privacy issues that were raised, specifically about exposing commercial relationships such as revealing the sponsoring LIR for a particular End User resource. If you feel that the technical reasons for publishing all resource information associated with an LIR in bulk format outweigh the privacy concerns surrounding this, then we would suggest that you write a technical proposal, detailing your exact requirements and possible benefits. Then the Community should decide if this is desired. If there is consensus, then naturally we will make this information available as requested. Kind regards, Alex P.S. I will be on holiday next week, so I may not be able to respond promptly at all times On 1 Aug 2012, at 19:10, Nick Hilliard <nick@netability.ie> wrote:

On 01/08/2012 16:42, Alex Band wrote:

...

Why would you like to know that specifically, if I may ask?

Hi Alex,

I'm interested in seeing the regid formally linked to the allocation / direct assignments lists for several reasons:

1. because the RIPE NCC has put very substantial time and resources into linking resource assignment to the end user via a LIR, and as a representative of a RIPE NCC member, I'd like to see this particular information set published.

2. it makes handling abuse issues easier. As you're well aware, network resource abusers often hide behind several layers of indirection to conceal their tracks. By publishing a token which can provide a link between the end user and their contractual support provider, this makes it substantially easier to deal with abuse related issues.

3. it makes it possible for members to independently verify the current charging scheme.

Nick

On 4 Aug 2012, at 19:25, Nick Hilliard <nick@netability.ie> wrote:

It's certainly been discussed before without any particular conclusion, but I didn't gather from the various WG discussions - either at RIPE meetings or on the mailing lists - that it stalled due to privacy concerns. Do you have a reference for this?

First thing I could find is a message by David Freedman from July last year: http://www.ripe.net/ripe/mail/archives/db-wg/2011-July/003745.html

...

After the feedback from the DB-WG Meeting in Vienna last week, I'd like to = bring this back to the list.

I'd like to see the RegID (or equivalent) displayed for all resources in th= e database, this will help us identify the holder of:

* PA Allocations (currently found in alloclist , currently attached Org-= ID) * PA Assignments (only found through less specific aggregate inetnum an= d as per above) * PI Assignments (not found at all) * Autonomous systems (not found at all?)

The privacy issues concerning publishing are currently being investigated b= y the NCC and a number of people have expressed concern about revealing com= mercial relationships, especially with regards to revealing the sponsoring LIR for a particular en= d-user resource (though, I did make the point that you can ask the NCC a di= rect question about who the sponsoring LIR is and lack of policy means they reveal this).

The technical issue concerning publishing , is that using the RegID may not= be the best idea, the NCC say "It is for internal use" (but it is the only= thing I see in my LIR portal?), why not use the OrgID (but this doesn't relate to the RegID , how do I link this to a bone = fide LIR?) , one issue with using the regID over the orgID may be that the = regID would simply be represented in the database as a string , since there is no related object to tie it to (which= may be an undesirable outcome).

Dave.

* Alex Band

Could you give us some context how you would want to use this data, and what you currently are not capable of doing using for example the RIPE Database?

Hi, Take a look at proposal 2012-05 in apwg. One of its goals is to ensure that the origin and recipient of allocation transfers are public information. I agree with this goal, and will likely find it very interesting to follow transfers happening in the coming months. Much of this information is already easily available on the FTP, however. The name and reg-id of the holding LIR are available in alloclist.txt, while the prefix and date of allocation is available in both alloclist.txt and delegated-ripencc-extended-latest. The only thing I cannot easily find, is the historic information of which LIR held an allocation previously. (If I have simply missed it, please point me to it and stop reading.) It occurs to me that by adding a LIR/reg-id column in delegated-ripencc-extended-latest, and/or to publish historic versions of alloclist.txt, the information sought by 2012-05 (and as an added bonus, information about the origin of returned resources) would be easily obtainable from the FTP. To avoid any privacy issues, the LIR/reg-id column in the delegated file could be left empty for assigned resources - I believe that would mean that no previously unpublished information would need to be made public. Is this doable, you think? Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com

Hi guys, Why would you like to have a list per LIR that specifies which administrative cost are billed through it? The registration office doesn't need to have a network relation with the holder of the resource. For example, we register PI or AS objects for others, but we don't require them to use them in our network. I fail to see why that relation should be published publicly. Erik Bais