Rimas Janusauskas wrote:

Hi,

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. Nice to hear the DB group is thinking ahead Joao ;) Ragards,

Best regards,

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 ______________________________________________________________________

On Thu, 6 Jul 2000, Joao Luis Silva Damas wrote:

...

Hi,

yes, we called it the "organization" object. We decided to postpone bringing it up for a little while, to make sure the reimplementation would be closer to the end and it could be incorporated within a reasonable time.

This would be during the next RIPE meeting (September).

We can release it (I can't access it right now) as a starting point for discussion.

Is that OK?

Joao

On Thu, 6 Jul 2000, Stephen Burley wrote:

...

Hi I have a quick question has any ever thought of creating a company object, which is much the same as a person object but it means that any range of IP's assigned to a company will easily be traced. Making it easier to find the total amount IP space assigned to a company/org , which frankly at the moment is impossable.

Regards

-- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life Stephenb@uk.uu.net if you're stupid and willing to wait" ------------------------------------------------------------------------

-- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life [SB855-RIPE] if you're stupid and willing to wait" ------------------------------------------------------------------------

On Mon, 10 Jul 2000, Rimas Janusauskas wrote: [skip] RJ> 2. If accept your proposal, "organization" attribute with unique handle RJ> like person/role MUST substitute inetnum(s), which became RJ> [mandatory] [multiple] [look-up key] RJ> attribute? I'm not sure that RIPE community is ready for such significant RJ> changes... I'm very much surprized by 'multiple' status of proposed attribute. How can netblock belong to more than one company (provided they are in compliance with RIPE-185) ? Yes, there is also some possible problems with either renaming (e.g., by splitting/merging) organization or other ways of changing the "owner" of netblock. RJ> 3. You know, if not kept up to date the object will not work. Who will RJ> be responsible for it - customer or ISP? Yeah, and this is next good and in no way easy-to-answer question... RJ> Good point to start/close discussion? ;-) Definitely :) Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------

The problem as i see it:

Ip addresses do not change a /24 today will be a /24 tomorrow (ok unless its aggregated) the only differance is which network they are on. People come and go, some people have a RIPE oject for every job the have held in this industry, netnames change from one request to another, and so on. What this object is designed to do is give as best we can a fixed point from which all IP's assigned to a customer (organization/company) can be grouped to provide an easy stable place to see all assignments made to a single customer at differant times. We have some really old customers going back to 1993, our engineers have changed several times and differant assignments have been made by differant people with both the admin and tech contact changing in both the customers network and our own. There is no common point of referance apart from it is still the same company. I agree with all the arguments about keeping it up to date but that goes for all objects. and i think it should be the ISP who keeps up to date after all its in our interest to keep it up to date. Bottom line is we can assign addresses to a company and track how much we have assigned easily and reliably (more). I know how to make raw text searches and inverse lookups but i am not doing the assignment of our address space our less skilled highly pressured engineers are, and if we can help them to help me and the NCC track addresses more accuratly all the better. Regards, -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life [SB855-RIPE] if you're stupid and willing to wait" ------------------------------------------------------------------------