Internet Registry Object

I have an action to propose a "registry" object for the RIPE database.

Defining such an object is not so much of a problem. In fact
we already have the information needed in tagged format.

Look at the Irish Internet registries as an example:

org:       EUnet IE
status:	   Provider
person:    Michael Nowlan
address:   O'Reilly Institute
address:   Trinity College
address:   Dublin 2
country:   Ireland (ie)
phone:     +353 1 671 9361
phone:     +353 1 702 1787
fax-no:    +353 1 677 2204
e-mail:    mn at dec4ie.ieunet.ie

org:       HEAnet
status:    Provider  
person:    Mike Norris
address:   21 Fitzwilliam Square
address:   Dublin 2
country:   Ireland (ie)
phone:     +353 1 6612748  
fax:       +353 1 6610492 
e-mail:    mnorris at hea.ie 

org:       IE EUnet 
status:	   Registry of Last Resort 
person:    Michael Nowlan
address:   O'Reilly Institute
address:   Trinity College
address:   Dublin 2
country:   Ireland (ie)
phone:     +353 1 671 9361
phone:     +353 1 702 1787
fax-no:    +353 1 677 2204
e-mail:    mn at dec4ie.ieunet.ie


However putting this in the database is not all. We need to define
a querying mechanism. This is where the problem starts. 

Options: 

1) Return all the regsitries on queries for the country code together
with the toplevel domain object.

2) Return all registries on queries for "cc-reg" or some such magic.

3) Add a special flag to whois to query for registries.

All these options are not very applealing because all of them
have a big potential for user confusion. Also I am convinced
that this information should always be presented together with
some information about what a local registry is and what it is
not.

What did we want to achieve by putting this information in the database?

- easy updates via the normal means

- access to up to date information at all times between publications
  of the local registry list

We can achieve the -more important- second goal by making this information
available via the RIPE document store together with the explanatory
information. This could be implemented quickly (before the RIPE meeting).

The first goal cannot be achieved that way. But since the amount of info
and changes is expected to be small, the NCC can process update requests
manually.

So my conclusion is not to include this in the database but in the
document store.

If I have not considered some important argument, please let me know
pricately or via a discussion on these lists. 

If there is consensus we will implement it that way.

Daniel