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@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@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@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