Re: [enum-wg] New Documents available: RIPE-384, RIPE-385]
Dear Antoin, It is certainly possible to add a new organisation object type, like "ENUM", to be specifically used by the ENUM registries. This would involve the changes to the RIPE Database. I suggest you to contact ENUM-WG and DB-WG working group chairs to check first whether this change would require only a mailing list consensus or PDP, and then maybe put together a proposal for ENUM-WG and DB-WG and submit it to the appropriate mailing lists. -- Katie Petrusha RIPE NCC
From: "Antoin Verschuren" <Antoin.Verschuren@sidn.nl> Date: 4 September 2006 2:26:40PM GMT+02:00 To: <enum-wg@ripe.net> Cc: <ncc-services-wg@ripe.net> Subject: [enum-wg] New Documents available: RIPE-384, RIPE-385 Message-Id: <B33086268D53A0429A3AA2774C83892CDC5850@KAEVS1.SIDN.local>
Guys,
I have some sentimental issues with the new ENUM request forms as I found out when I had to use them last week.
The new ENUM registrations ask to register an Organisation holding the registration.
This "Organisation" template, has a "org-type:" field. RIPE tells me to fill in "NON-REGISTRY" in this field.
I'm aware that we are not an RIR, LIR or NIR as in the RIR world, but I do feel the term "NON-REGISTRY" a bit degrading as we are the registry for .nl and soon hopefully for ENUM.
Can we invent a new term to use for official ENUM tier-1 registries here ?
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 6 Sep 2006, at 15:52, Katie Petrusha wrote:
It is certainly possible to add a new organisation object type, like "ENUM", to be specifically used by the ENUM registries. This would involve the changes to the RIPE Database.
I suggest you to contact ENUM-WG and DB-WG working group chairs to check first whether this change would require only a mailing list consensus or PDP, and then maybe put together a proposal for ENUM-WG and DB-WG and submit it to the appropriate mailing lists.
I'm leaving my wg-co-chair hat off, for now. I'm disappointed that the RIPE-NCC hasn't seen fit to make a more pro-active response in this case. In agreeing to become the ENUM Tier-0 DNS Operator, the RIPE-NCC deliberately (if perhaps implicitly) created a new service and a new category of customer. The RIPE-NCC appears to have assumed (and, if so, quite reasonably) that existing tools and procedures would be adequate to support the (formally, if subtly) different business processes involved in dealing appropriately with customers belonging to this new category. Only recently are some of these customers beginning to need to deal rather formally with the RIPE-NCC. Consequently, they are starting to drive the corresponding business processes. So far, a single trivial, but significant, example has come to light of a mismatch between what is currently possible using existing tools and procedures and what is appropriate in dealing with a customer belonging to this category. This should come as no great surprise; the unexpected will happen in any new activity. It seems to me that having appropriate processes, including appropriate language, in place for dealing with each category of customer is an operational imperative for the RIPE-NCC, and that the RIPE-NCC should take the initiative to deal with any inadequacy in this area. Consider the following parable. The first customer arrives in a new data-centre to rack some equipment, only to find that the air- conditioning plant has not yet been switched on, and brings this to the attention of the escorting data-centre employee. What should the data-centre employee do: reach for the switch, or rather ask the customer to prepare a proposal for agreement among the other interested parties which would provide a policy framework within which the switch could be moved from its existing position? I see this as an operational matter for the ENUM Tier-0 DNS Operator. It's not technical; customer relations are part of operations, too. 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
Dear Niall, Antoin, Niall O'Reilly wrote:
On 6 Sep 2006, at 15:52, Katie Petrusha wrote:
It is certainly possible to add a new organisation object type, like "ENUM", to be specifically used by the ENUM registries. This would involve the changes to the RIPE Database.
I suggest you to contact ENUM-WG and DB-WG working group chairs to check first whether this change would require only a mailing list consensus or PDP, and then maybe put together a proposal for ENUM-WG and DB-WG and submit it to the appropriate mailing lists.
I'm leaving my wg-co-chair hat off, for now.
I'm disappointed that the RIPE-NCC hasn't seen fit to make a more pro-active response in this case.
In agreeing to become the ENUM Tier-0 DNS Operator, the RIPE-NCC deliberately (if perhaps implicitly) created a new service and a new category of customer. The RIPE-NCC appears to have assumed (and, if so, quite reasonably) that existing tools and procedures would be adequate to support the (formally, if subtly) different business processes involved in dealing appropriately with customers belonging to this new category.
Only recently are some of these customers beginning to need to deal rather formally with the RIPE-NCC. Consequently, they are starting to drive the corresponding business processes. So far, a single trivial, but significant, example has come to light of a mismatch between what is currently possible using existing tools and procedures and what is appropriate in dealing with a customer belonging to this category. This should come as no great surprise; the unexpected will happen in any new activity.
It seems to me that having appropriate processes, including appropriate language, in place for dealing with each category of customer is an operational imperative for the RIPE-NCC, and that the RIPE-NCC should take the initiative to deal with any inadequacy in this area.
Thank you very much for your feedback and the valid points you brought up. I think we simply were not sure what would be the best way to have such discussion and to better understand the requirements, which may clarify or exceed a simple request for a new org type. That's why we suggested to ask wg-chairs for advice. You are right in saying that we should have been more proactive in asking this advice or preparing a proposal ourselves, which we can certainly do based on yours and probably upcoming feedback.
Consider the following parable. The first customer arrives in a new data-centre to rack some equipment, only to find that the air-conditioning plant has not yet been switched on, and brings this to the attention of the escorting data-centre employee. What should the data-centre employee do: reach for the switch, or rather ask the customer to prepare a proposal for agreement among the other interested parties which would provide a policy framework within which the switch could be moved from its existing position?
I see this as an operational matter for the ENUM Tier-0 DNS Operator. It's not technical; customer relations are part of operations, too.
Yes, but in the case of the RIPE Database we'd rather err to be more formal because of high visibility of changes and dependencies.
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
Regards, Andrei Robachevsky RIPE NCC
On Sep 08, Andrei Robachevsky <andrei@ripe.net> wrote:
Yes, but in the case of the RIPE Database we'd rather err to be more formal because of high visibility of changes and dependencies. I agree, thank you for bringing this issue to the appropriate WG.
FWIW, I really cannot see a valid reason for such a change. It should be obvious that in the context of org-type attributes the words "NON-REGISTRY" have a specific meaning, which does not need to be the same (and cannot be the same!) of the semantic of the word "registry" in every other possible context. I would appreciate if RIPE NCC would not waste resources implementing and documenting new attribute values for every tiny group that feels to not be described in a sufficiently excruciating level of detail by the available choices. But maybe it's just me, and Mr. Verschuren should explain more clearly why he believes that the status of his organization as an ENUM registry should be relevant in the context of org-type attributes, possibly without resorting to "sentimental issues". -- ciao, Marco
participants (4)
-
Andrei Robachevsky -
Katie Petrusha -
md＠Linux.IT -
Niall O'Reilly