On Mon, 10 Jul 2000, Stephen Burley wrote:
IMHO, this is the same feature as "netname:" attribute should do. Even netname has "user unfriendly" format and possibility assign same ID to different organizations. Maybe the problem could be solved by adding new attribute to inetnum: object?
OK i understand what you are saying here but the problem is the network does not exist until it is assigned or is approved meaning if a customer comes to use for more space without admitting to the fact they already have space, an engineer not aware of previous assignments make a further assignemt under a differant netname. I agree the netname could be used for this feature but how do you find all the address space assigned to a customer by netname alone. If there was a way to tag a netname/inetnum with a customer unique handle ie comapny nic, then an engineer can trace all IP ranges attatched to that company, and can even find the correct customer nic by searching for the company name. I know there would be the same inherrant problems with keeping it up to date, but i think it would be better than nothing.
If customer is requesting address space from ISP, ripe-141 "European IP Address Space Request Form" is used and customer has an obligation provide ISP with information about current used address space. If they act as stated above, I do not foresee any problems with search. :) If customer do not follows ripe-185 "European Internet Registry Policies and Procedures" (2.3, 3.2.1.2) it's a bit complicated. Previous IP assignments could be verified by crosss checking contact person: whois -h whois.ripe.net -r -T inetnum -i admin-c,tech-c <nic-hdl|person/role name> If this search fails, using raw text search engine (http://www.ripe.net/cgi-bin/ripedbsearch) will give you all objects with mentioned company name, and IP assignments among them. I expect 3 problems comming with "organization" object: 1. Introducing new object, which could be covered by inetnum:, only duplicates records for organizations with single assignment (maybe Joao could count aprox. number of objects?) 2. If accept your proposal, "organization" attribute with unique handle like person/role MUST substitute inetnum(s), which became [mandatory] [multiple] [look-up key] attribute? I'm not sure that RIPE community is ready for such significant changes... 3. You know, if not kept up to date the object will not work. Who will be responsible for it - customer or ISP? Good point to start/close discussion? ;-) Rimas Janusauskas, Vilnius University Hostmaster ______________________________________________________________________ P.O.Box 543 e-mail: rimas.janusauskas@sc.vu.lt LT-2024 Vilnius Lithuania fax/phone: +370 2 687188 ______________________________________________________________________