<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello Nick, Gert,<br><br>I have done some research on this topic yesterday. Based on my findings, there are two aspects that I would like to cover. <br><br>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:<br><br><a href="https://apps.db.ripe.net/whois/lookup/ripe/organisation/ORG-INEX1-RIPE.html">https://apps.db.ripe.net/whois/lookup/ripe/organisation/ORG-INEX1-RIPE.html</a><br><a href="https://apps.db.ripe.net/whois/lookup/ripe/organisation/ORG-SA17-RIPE.html">https://apps.db.ripe.net/whois/lookup/ripe/organisation/ORG-SA17-RIPE.html</a><br><br>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.<br><br>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.<br><br>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.<br><br>Kind regards,<br><br>Alex<div><br></div><div>P.S. I will be on holiday next week, so I may not be able to respond promptly at all times</div><div><br></div><div><br></div><div><div>On 1 Aug 2012, at 19:10, Nick Hilliard <<a href="mailto:nick@netability.ie">nick@netability.ie</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On 01/08/2012 16:42, Alex Band wrote:<br><blockquote type="cite">Why would you like to know that specifically, if I may ask?<br></blockquote><br>Hi Alex,<br><br>I'm interested in seeing the regid formally linked to the allocation /<br>direct assignments lists for several reasons:<br><br>1. because the RIPE NCC has put very substantial time and resources into<br>linking resource assignment to the end user via a LIR, and as a<br>representative of a RIPE NCC member, I'd like to see this particular<br>information set published.<br><br>2. it makes handling abuse issues easier. As you're well aware, network<br>resource abusers often hide behind several layers of indirection to conceal<br>their tracks. By publishing a token which can provide a link between the<br>end user and their contractual support provider, this makes it<br>substantially easier to deal with abuse related issues.<br><br>3. it makes it possible for members to independently verify the current<br>charging scheme.<br><br>Nick<br><br><br></blockquote></div><br></body></html>