[ncc-services-wg] LIR association with number resources

Hi Alex,

many thanks for your detailed response.

On 03/08/2012 10:30, Alex Band wrote:
> 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. 

It appears and is used in a variety of other places, e.g. the LIR index
listing, board related stuff (voting, etc), meeting registration,
lirportal, and so forth.

> 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

org-ids certainly exist as an entity in the RIPEDB.  However, there is not
a 1:1 mapping to LIRs.  It's certainly true that each LIR is assigned a
unique org-id, but not every org-id is associated with a LIR.

e.g. ORG-INEX1-RIPE refers to INEX, but INEX is not a LIR.

> 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.

There are certainly some advantages associated with this idea, although
there is information noted in the regid listing which is not listed in the
org-id object.  A more complete database view would include both a resource
id -> orgid and lirinfo -> orgid mapping.

> 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.

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?

Nick