Re: [enum-wg] ITU: debate over User-ENUM administration
"Niall" == Niall O'Reilly <niall.oreilly@ucd.ie> writes:
>> So "ENUM has nothing to do with assignment of E.164 numbers or >> national number plans", does it? What drugs are you on and >> where can I get some? :-) Niall> It seems it's time for me to have a 'booster-shot' of clue. Niall> I may not be the only one on the list who would benefit. Niall> As I understood things, Christian's statement is _formally_ Niall> correct, since ENUM is for embedding _already-assigned_ Niall> E.164 numbers in the DNS. That's not what he said. It may have been what he meant. Christian said "ENUM has nothing to do with assignment of E.164 numbers or national number plans". True, ENUM has no bearing on how E.164 numbers are assigned. Or how national numbering plans are administered. But since entries under e164.arpa should correspond to assigned E.164 numbers according to the national numbering plan, ENUM does reflect how assignment of E.164 numbers are done. ENUM is not the expression in the DNS of some random digit strings. Christian's remarks can be read as implying ENUM has no relationship to E.164 assignments or numbering plans. Even so, ENUM does have something to do with national numbering plans. Obviously the registrations under <CC>.e164.arpa should correspond to the national numbering plan. For example in the UK context, it's not (yet) possible to register premium-rate and free phone numbers under 4.4.e164.arpa because authenticating them is too hard. These numbers live in ranges that have been set aside for those purposes in the national numbering plan. Similar problems could arise with DDI blocks, number ranges set aside for VoIP or DSL, etc etc. Thus ENUM is a representation of the national (and international) numbering plan. That's hardly "nothing to do with it".
Jim Reid wrote:
..... But since entries under e164.arpa should correspond to assigned E.164 numbers according to the national numbering plan, ENUM does reflect how assignment of E.164 numbers are done.
slightly OT, but since i'm currently looking for this in the scope of validation - Which document does formally specify this tie between E.164 and ENUM? Don't misunderstand me, i'm fully convinced (as probably the majority of the fellow list members) that this is a requirement for ENUM, but i'm still searching where this is specified, because this requirement is where all validation related work boils down to. What i've found out so far is that RFC3671 says: "Holders of E.164 numbers which want to be listed in DNS should contact the appropriate zone administrator according to the policy which is attached to the zone." One could interpret that as "only holders may apply". Well, it becomes more complicated with number ranges where the ENUM domain is a prerequisite for the assignment of the corresponding E.164 number (eg. +43 780), so YMMV. However, this is the only place in the RFC which talks about the formal relation between E.164 and ENUM (I'm not talking about the technical relations, the whole string conversion etc.) Currently, a country deciding to _not_ have any strict ties between E.164 and ENUM (assigning the ENUM to another party than the E.164) would imho pretty much satisfy RFC3761 - which i consider dangerous. So, where's the place to look for (or add) this requirement? cheers -- Alex Mayrhofer nic.at/enum.at
"Holders of E.164 numbers which want to be listed in DNS should contact the appropriate zone administrator according to the policy which is attached to the zone."
One could interpret that as "only holders may apply".
In Poland, only TSP may apply for the ENUM domain names. E164 number is not the "product" or stand-alone "service", but the part of agreement between TSP and Subscriber. Andrzej.
At 08:04 AM 2/9/2005, Andrzej Bartosiewicz wrote:
"Holders of E.164 numbers which want to be listed in DNS should contact the appropriate zone administrator according to the policy which is attached to the zone."
One could interpret that as "only holders may apply".
In Poland, only TSP may apply for the ENUM domain names.
does simplify the validation problem :-)
E164 number is not the "product" or stand-alone "service", but the part of agreement between TSP and Subscriber.
Andrzej.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 <mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz> <http://www.neustar.biz> ; <http://www.enum.org> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Alex, Alexander Mayrhofer wrote:
slightly OT, but since i'm currently looking for this in the scope of validation - Which document does formally specify this tie between E.164 and ENUM?
from what I recall, ETSI TS 102 051 V1.1.1 (2002-07) "ENUM Administration in Europe" covers that a bit - although not formally binding. The extent of tying E.164 and ENUM together after all is essentially a local matter, then again. Best, -C.
-----Original Message----- From: enum-wg-admin@ripe.net [mailto:enum-wg-admin@ripe.net]On Behalf Of Jim Reid Sent: 09 February 2005 10:54 To: Niall O'Reilly Cc: enum-wg@ripe.net Subject: Re: [enum-wg] ITU: debate over User-ENUM administration
"Niall" == Niall O'Reilly <niall.oreilly@ucd.ie> writes:
>> So "ENUM has nothing to do with assignment of E.164 numbers or >> national number plans", does it? What drugs are you on and >> where can I get some? :-)
Niall> It seems it's time for me to have a 'booster-shot' of clue. Niall> I may not be the only one on the list who would benefit.
Niall> As I understood things, Christian's statement is _formally_ Niall> correct, since ENUM is for embedding _already-assigned_ Niall> E.164 numbers in the DNS.
That's not what he said. It may have been what he meant. Christian said "ENUM has nothing to do with assignment of E.164 numbers or national number plans". True, ENUM has no bearing on how E.164 numbers are assigned. Or how national numbering plans are administered.
That is what I wrote (with or without drugs. :-)) But
since entries under e164.arpa should correspond to assigned E.164 numbers according to the national numbering plan, ENUM does reflect how assignment of E.164 numbers are done.
No it doesn't. ENUM simply records E.164 numbers once assigned. it does not reflect the process of assignment. ENUM is not the expression
in the DNS of some random digit strings. Christian's remarks can be read as implying ENUM has no relationship to E.164 assignments or numbering plans.
I am talking very specifically about the authority behind assignment of E.164 and that is not through the ENUM tree but the E.164 national delegations.
Even so, ENUM does have something to do with national numbering plans. Obviously the registrations under <CC>.e164.arpa should correspond to the national numbering plan. For example in the UK context, it's not (yet) possible to register premium-rate and free phone numbers under 4.4.e164.arpa because authenticating them is too hard. These numbers live in ranges that have been set aside for those purposes in the national numbering plan. Similar problems could arise with DDI blocks, number ranges set aside for VoIP or DSL, etc etc. Thus ENUM is a representation of the national (and international) numbering plan. That's hardly "nothing to do with it".
see above. Christian
Hi Christian, folks, 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 they were required to execute, who gets to set these, and/or whether or not any general policies apply to all such registries. What followed seems to be a discussion in Medieval Philosophy. "ENUM - What's in a word?" In most countries, the Government or its anointed agency decides on the 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 the 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. ---------------------------------- As an aside... Some people** who had assumed that they had a valid domain registration in a certain gTLD were surprised to find that this situation had changed, someone else was the registrant, and they were being asked for money to transfer it back again. It happens - often with the Registrar denying any knowledge of the original registrant, up to an including receiving a copy of their own invoice and the payment taken for the service which included renewal, with dates. Are you surprised that any Country's representatives at the ITU are concerned, with such antics going on under what might appear to be ICANN's purview? **[I point out here - not to me, but to a colleague in the same office who registered a DotCom domain, or rather registered it for a while :] ---------------------------------- all the best, Lawrence On 9 Feb 2005, at 20:21, Christian de Larrinaga wrote:
-----Original Message----- From: enum-wg-admin@ripe.net [mailto:enum-wg-admin@ripe.net]On Behalf Of Jim Reid Sent: 09 February 2005 10:54 To: Niall O'Reilly Cc: enum-wg@ripe.net Subject: Re: [enum-wg] ITU: debate over User-ENUM administration
> Niall writes in response to jim's request for a dealer: So "ENUM has nothing to do with assignment of E.164 numbers or national number plans", does it? What drugs are you on and where can I get some? :-)
Niall> It seems it's time for me to have a 'booster-shot' of clue. Niall> I may not be the only one on the list who would benefit.
Niall> As I understood things, Christian's statement is _formally_ Niall> correct, since ENUM is for embedding _already-assigned_ Niall> E.164 numbers in the DNS. To which jim in turn ripostes: That's not what he said. It may have been what he meant. Christian said "ENUM has nothing to do with assignment of E.164 numbers or national number plans". True, ENUM has no bearing on how E.164 numbers are assigned. Or how national numbering plans are administered.
That is what I wrote (with or without drugs. :-))
But
since entries under e164.arpa should correspond to assigned E.164 numbers according to the national numbering plan, ENUM does reflect how assignment of E.164 numbers are done.
No it doesn't. ENUM simply records E.164 numbers once assigned. it does not reflect the process of assignment.
ENUM is not the expression
in the DNS of some random digit strings. Christian's remarks can be read as implying ENUM has no relationship to E.164 assignments or numbering plans. I am talking very specifically about the authority behind assignment of E.164 and that is not through the ENUM tree but the E.164 national delegations.
Even so, ENUM does have something to do with national numbering plans. Obviously the registrations under <CC>.e164.arpa should correspond to the national numbering plan. For example in the UK context, it's not (yet) possible to register premium-rate and free phone numbers under 4.4.e164.arpa because authenticating them is too hard. These numbers live in ranges that have been set aside for those purposes in the national numbering plan. Similar problems could arise with DDI blocks, number ranges set aside for VoIP or DSL, etc etc. Thus ENUM is a representation of the national (and international) numbering plan. That's hardly "nothing to do with it".
see above.
Christian
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 they 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 the 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 the 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 that 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 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
I don't believe there is any issue of whether there is linkage between ENUM and E.164. The issue (if one exists at all) is to keep the flow clear so that you first get E.164 and only then might you delegate this into an ENUM tree (at a national level). An RFC that offers workable validatation frameworks for national ENUM trees to reflect their E.164 numbering plan should be welcomed. But as a BCP perhaps at this point rather than a Standard, as I agree with Richard here that there are other interested parties who need to dip into this and we have to accept that NRA's can take different views. Christian
-----Original Message----- From: enum-wg-admin@ripe.net [mailto:enum-wg-admin@ripe.net]On Behalf Of Alexander Mayrhofer Sent: 10 February 2005 09:08 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 they 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).
snip
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. snip 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
Christian
participants (7)
-
Alexander Mayrhofer -
Andrzej Bartosiewicz -
Carsten Schiefner -
Christian de Larrinaga -
Conroy, Lawrence (SMTP) -
Jim Reid -
Richard Shockey