RE: [db-wg] Re: [enum-wg] Proposal for new org-type
leo vegoda wrote:
Do people find org-type values like IANA, RIR, LIR and so on useful? If not, maybe we just need two values: REGISTRY for IANA, RIRs, LIRs, TLDs and Tier 1 ENUM operators and NON-REGISTRY for everyone else. However, if people really find the hierarchical distinctions in the current org-type values useful, maybe we need some additional granularity for the different kinds of domain registries?
If the extra granularity is useful, perhaps we need to allow organisations to have multiple org-type values? That's probably preferable to having multiple objects for a single organisation.
It depends on what is is supposed to be used for in the DB. If is is needed to distinguish types of organisations when making queries, the types makes sense. But if it's only there to give a label and it is never used, it doesn't. I wouldn't mind changing the "NON-REGISTRY" into "OTHER", like I now have to apply for a RIPE meeting. But on the other hand, if RIPE wants to use it as a differentiation of their customers, and this would be expressed in the RIPE DB, I think ENUM-REGISTRY would be appropriate, and I would also find it logical I can register at a RIPE meeting as "ENUM-REGISTRY". It's then just a customer type. I can see a reason for the term "REGISTRY" if RIPE intends to expand heir services to more than IP network services, and doesn't feel to create a long list of different marketing terms for different organisations. I work for a ccTLD registry that is not an LIR, and even though that is a clear Internet registry function like IANA, RIR or LIR, RIPE currently does not supply a service for that function that requires an entry in the DB. Conclusion: I can live with ENUM-REGISTRY, REGISTRY, OTHER or no org-type at all. I cannot live with the org-type NON-REGISTRY. My prefference would be the ENUM-REGISTRY org-type. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren@sidn.nl W http://www.sidn.nl/
On Wed, 2006-10-04 at 09:47 +0200, Antoin Verschuren wrote: [snip]
I can see a reason for the term "REGISTRY" if RIPE intends to expand heir services to more than IP network services, and doesn't feel to create a long list of different marketing terms for different organisations. I work for a ccTLD registry that is not an LIR, and even though that is a clear Internet registry function like IANA, RIR or LIR, RIPE currently does not supply a service for that function that requires an entry in the DB.
Conclusion: I can live with ENUM-REGISTRY, REGISTRY, OTHER or no org-type at all. I cannot live with the org-type NON-REGISTRY.
My prefference would be the ENUM-REGISTRY org-type.
This proposal is taking things out of context. The word REGISTRY in RIPE-terms means an IP-address registry. Nothing more, nothing less. That your organisation is categorised as NON-REGISTRY by RIPE doesn't mean that RIPE does not acknowledge your role as a registry in some other context, just that you're not an ip-addr registry. Should the database contain exceptions for all kinds of registries which happen to deal with something else than ip-addresses? //per -- Per Heldal - http://heldal.eml.cc/
I think we should recognize the fact that the network, and thus the NCC's functions, is changing over time. For quite a while the central activity was the IP(v4) Registry. With the agreement to support e164, we start to support a different registry. Thus I agree that NON-REGISTRY - as in the "old" enivironment, is no longer adequate. "I would like this NON-REGISTRY to be changed to OTHER." seems to be a very easonable way forward! Wilfried. Per Heldal wrote:
On Wed, 2006-10-04 at 09:47 +0200, Antoin Verschuren wrote: [snip]
I can see a reason for the term "REGISTRY" if RIPE intends to expand heir services to more than IP network services, and doesn't feel to create a long list of different marketing terms for different organisations. I work for a ccTLD registry that is not an LIR, and even though that is a clear Internet registry function like IANA, RIR or LIR, RIPE currently does not supply a service for that function that requires an entry in the DB.
Conclusion: I can live with ENUM-REGISTRY, REGISTRY, OTHER or no org-type at all. I cannot live with the org-type NON-REGISTRY.
My prefference would be the ENUM-REGISTRY org-type.
This proposal is taking things out of context. The word REGISTRY in RIPE-terms means an IP-address registry. Nothing more, nothing less. That your organisation is categorised as NON-REGISTRY by RIPE doesn't mean that RIPE does not acknowledge your role as a registry in some other context, just that you're not an ip-addr registry. Should the database contain exceptions for all kinds of registries which happen to deal with something else than ip-addresses?
//per
<hat position="off"> On 5 Oct 2006, at 11:05, Per Heldal wrote:
This proposal is taking things out of context.
Per, I think the context has changed since Antoin posted the text you commented on. 8-)
Should the database contain exceptions for all kinds of registries which happen to deal with something else than ip-addresses?
Antoin's final proposal to use "OTHER" seems to address this difficulty, no? Best regards, Niall O'Reilly University College Dublin Computing Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9
participants (4)
-
Antoin Verschuren -
Niall O'Reilly -
Per Heldal -
Wilfried Woeber, UniVie/ACOnet