[ncc-services-wg] LIR association with number resources
- Previous message (by thread): [ncc-services-wg] LIR association with number resources
- Next message (by thread): [ncc-services-wg] LIR association with number resources
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nick Hilliard
nick at netability.ie
Sat Aug 4 19:25:29 CEST 2012
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
- Previous message (by thread): [ncc-services-wg] LIR association with number resources
- Next message (by thread): [ncc-services-wg] LIR association with number resources
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]