New object

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 at sc.vu.lt
LT-2024 Vilnius           
   Lithuania              fax/phone:	+370 2 687188
______________________________________________________________________