RE: [enum-wg] ITU: debate over User-ENUM administration
-----Original Message----- From: enum-wg-admin@ripe.net [mailto:enum-wg-admin@ripe.net] On Behalf Of Alexander Mayrhofer Sent: Thursday, February 10, 2005 10:08 AM To: Conroy, Lawrence (SMTP) Cc: <enum-wg@ripe.net>; Christian de Larrinaga Subject: Re: [enum-wg] ITU: debate over User-ENUM administration
Conroy, Lawrence (SMTP) wrote:
Intiguing - Axel asked the quite reasonable question that it isn't clear to the 3.4.e164.arpa. Registry all of the specifics of the policy
were required to execute, who gets to set these, and/or whether or not any general policies apply to all such registries.
Lawrence,
it's perfectly clear to us what the requirements are on a local level
our regulator did specify that pretty comprehensive. Integrity between the local numering plan and ENUM is one of the fundamental requirements in the contract signed between RTR and enum.at. So, locally, we're all set.
However, i'm trying to look at the validation issues on a more global level (imho it doesn't make sense to reinvent the wheel in every country [again], especially since policy wise i consider E.164/ENUM less "entropy-burdened" than eg. ccTLD's).
I asked myself what that basis for validation is, and came to the conclusion that insuring the integrity between E.164 and ENUM is what validation is really about.
In most countries, the Government or its anointed agency decides on
delegation policy to be applied for delegations in ->their<- zone.
It's their zone because the E.164.arpa. delegation policies as executed by RIPE-NCC and the TSB reflect in the IAB/ITU agreements and the ITU's interim procedures. The interim procedures in turn reflect the E.164 assignment process.
Does each country have a right to choose the specifics of its delegation policies? Of course. My chosen delegation policy for my domain is not reflected in RFC1034/1035. Likewise for the holder of 3.4.e164.arpa., which Richard points out is RTR.
Now... coming back to the original thread -
The reasonable legal concerns are over whether the ITU is sure that
interim agreement will continue to be executed, without a formal agreement with the legal entity that controls the parent zone from which the ENUM apex was/is delegated.
Well, i'm still an engineer, so i'm not so much concerned about legal aspects [yet] ;). I'm just asking myself if it makes any sense to bring up documents about ENUM Validation at the IETF if (and that's how i interpret the previous posts) the WG has concerns about even noting
this strict relationship between E.164 and ENUM exists. What should i base my document on? Who would support it, when it talks about something which the IETF doesn't care about?
If we exclude the whole "administrative" stuff about validation from
Axel, you are right at the spot, and here is the problem: IETF is a protocol making body, so the data format/message exchange is an IETF issue. To do so, they need requirements for validation, but the requirements are NOT an IETF issue. The question is now, who can come up with the requirements and if there are some, will they be accepted by IETF. There is some possibilities to come up with (global) requirements: either from a regulators club or somebody near (ITU-T?) or from a club of Registries and Registrars dealing with ENUM in practice, bringing in and harmonizing their national requirements. Richard they - the the that the
IETF, it essentially boils down to a data format / message exchange standard for validation information (for which already 2 I-D's exist). If i remember it correctly, there has not been much interest in those two drafts, because they presented solutions to a problem of which most of the attendees were unaware - the conclusion was the recommendation that we should provide a "requirements" draft for validation.
Now that i'm working on this requirements stuff, it turns out that there's no fundamental basis for that (IETF-wise) because the IETF does not want/ cannot make clear what the relation ENUM/E.164 is all about. What should we do? Drop the "validation" topic in IETF completely, and take it to a local level (wheel reinventing in every country...)? I don't consider that a good solution...
comments appreciated.
cheers
axelm
Hi Axel, Richard, folks, Short answer is Yes, No. If you're talking about a set of policies to be applied by Registries and Registrars, then Registries and Registrars SHOULD to be involved, so that the policies specified are feasible. Regulators do have "off days", so it's useful for Registries/Registrars to point out that a policy that "potential registrants must come to Poitiers in person to register, but only on the first Wednesday of each month" isn't a good idea. Likewise, in effect requiring TSP validation whilst not requiring TSPs to set up such a validation system has a few problems. However, the Regulator's club are the guys who decide on any policy framework that they are going to specify, so they have to be "in charge". The IETF is the *wrong* place for any such work, unless you intend to develop a protocol to be used. We have all sorts of protocols already for this, so unless it's an XML schema that is used as a medium of exchange to embody a policy, they're not it. They're just bit pushers, and as Harald pointed out in his recent presentation in Vienna, a key feature of getting an RFC is waiting. So... find me a Regulator's club! all the best, Lawrence On 10 Feb 2005, at 09:22, Stastny Richard wrote:
Axel,
you are right at the spot, and here is the problem:
IETF is a protocol making body, so the data format/message exchange is an IETF issue. To do so, they need requirements for validation, but the requirements are NOT an IETF issue.
The question is now, who can come up with the requirements and if there are some, will they be accepted by IETF.
There is some possibilities to come up with (global) requirements: either from a regulators club or somebody near (ITU-T?) or from a club of Registries and Registrars dealing with ENUM in practice, bringing in and harmonizing their national requirements.
<snip - Axel said>
Now that i'm working on this requirements stuff, it turns out that there's no fundamental basis for that (IETF-wise) because the IETF does not want/ cannot make clear what the relation ENUM/E.164 is all about. What should we do? Drop the "validation" topic in IETF completely, and take it to a local level (wheel reinventing in every country...)? I don't consider that a good solution...
comments appreciated.
cheers
participants (2)
-
Conroy, Lawrence (SMTP) -
Stastny Richard