- enum-wg - mailman.ripe.net

NEWS: Live Trial At APRICOT2005
by Carsten Schiefner 08 Mar '05

08 Mar '05

All, some news from APEET's recent ENUM/WiFi/VoIP trial during APRICOT 05: <http://www.apenum.org/Press_Releases/Live_Trial_At_APRICOT2005> Best, Carsten Schiefner

1 0

NEWS: +49 ENUM to "Go Live" before End of 2005
by Carsten Schiefner 04 Mar '05

04 Mar '05

All, some ENUM related news from Germany: <http://www.denic.de/en/denic/presse/press_69.html> Best, Carsten Schiefner

1 0

RE: [enum-wg] FYI: ComReg issues proposal for VoIP numbers
by Lupton, Ronan 22 Feb '05

22 Feb '05

Carsten et al. For full text of the ComReg nomadic VoIP numbering proposal please visit this link: http://www.comreg.ie/_fileupload/publications/ComReg0512.pdf You will note treatment of ENUM service is not specifically within the scope of this consultation but dealt with in http://www.comreg.ie/_fileupload/publications/ComReg04103.pdf pages 19 and 20. We are working with the ENUM forum via ComReg and the government separately. Thanks, Ronan P.S. apologies for the HTML. Ronan Lupton Senior Regulatory Manager & EMEA Interconnect Policy MCI International Affairs MCI Lower Erne St. Dublin 2. Ireland Tel: +353-1-2474525 Fax: +353-1-2474545 GSM: +353-87-2053215 Vnet: +451-4525 ENUM: 8.8.8.9.6.0.5.1.3.5.3.e164.arpa mailto:ronan.lupton@ie.mci.com -----Original Message----- From: enum-wg-admin(a)ripe.net [mailto:enum-wg-admin@ripe.net] On Behalf Of Carsten Schiefner Sent: 22 February 2005 13:45 To: enum-wg(a)ripe.net Subject: [enum-wg] FYI: ComReg issues proposal for VoIP numbers All, Friday last week, Telecom.paper reported on a draft direction by Irish ComReg to allow access to the new '076' number range for VoIP services: http://www.telecompaper.com/index.asp?t=a&i=68293&n=730 === Ireland's Commission for Communications Regulation (ComReg) has issued draft Directions to allow access to the new '076' number range for VoIP services. Last October, ComReg made the 076 phone number range available to telecoms providers. To date, telecoms providers have not succeeded in negotiating terms that would allow 076 numbers to be connected to the wider telecoms network. ComReg is intervening to assist industry put in place, a preliminary framework for prices and settlements. Specifically, ComReg's draft directions propose two price points to facilitate telephone calls to VoIP numbers. ComReg will accept responses to the draft directions from interested parties up until the 3 March. === It wasn't possible to get that confirmed by ComReg's website, though. Best regards, Carsten Schiefner

2 1

FYI: ComReg issues proposal for VoIP numbers
by Carsten Schiefner 22 Feb '05

22 Feb '05

All, Friday last week, Telecom.paper reported on a draft direction by Irish ComReg to allow access to the new ’076’ number range for VoIP services: http://www.telecompaper.com/index.asp?t=a&i=68293&n=730 === Ireland’s Commission for Communications Regulation (ComReg) has issued draft Directions to allow access to the new ’076’ number range for VoIP services. Last October, ComReg made the 076 phone number range available to telecoms providers. To date, telecoms providers have not succeeded in negotiating terms that would allow 076 numbers to be connected to the wider telecoms network. ComReg is intervening to assist industry put in place, a preliminary framework for prices and settlements. Specifically, ComReg’s draft directions propose two price points to facilitate telephone calls to VoIP numbers. ComReg will accept responses to the draft directions from interested parties up until the 3 March. === It wasn't possible to get that confirmed by ComReg's website, though. Best regards, Carsten Schiefner

1 0

Re: [enum-wg] ITU: debate over User-ENUM administration
by Jim Reid 14 Feb '05

14 Feb '05

>>>>> "Niall" == Niall O'Reilly <niall.oreilly(a)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".

7 8

RE: [enum-wg] ITU: debate over User-ENUM administration
by Stastny Richard 14 Feb '05

14 Feb '05

> > "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." BTW, "holders" is IETF speak, ITU speak should is "assignees" Andrzey wrote: > In Poland, only TSP may apply for the ENUM domain names. Ok, Poland is infrastructure/carrier ENUM in disguise of User ENUM and therefore a special case ;-) Richard > -----Original Message----- > From: enum-wg-admin(a)ripe.net [mailto:enum-wg-admin@ripe.net] On Behalf Of > Andrzej Bartosiewicz > Sent: Wednesday, February 09, 2005 2:05 PM > To: 'Alexander Mayrhofer'; enum-wg(a)ripe.net > Cc: 'Niall O'Reilly'; 'Jim Reid' > Subject: RE: [enum-wg] ITU: debate over User-ENUM administration > > > "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.

2 1

ERG to discuss VoIP
by Carsten Schiefner 13 Feb '05

13 Feb '05

All, FYI: during its upcoming meeting, the ERG - the European Regulators Group - will also discuss VoIP related issues to come to a common position eventually. Although not 100% ENUM related, this nonetheless might be of some interest to the Working Group. Best, Carsten -------- Original Message -------- Subject: ERG's eleventh plenary meeting - agenda and debriefing session Date: Thu, 25 Nov 2004 13:04:20 +0100 From: erg(a)cec.eu.int Agenda for the eleventh plenary meeting of the European Regulators Group The agenda for the eleventh plenary meeting ("ERG11") in Brussels 2 - 3 December is now available at http://www.erg.eu.int/meetings/index_en.htm. Highlights include o New action plan and timetable for intensified work with international roaming o Draft Common Position on Voice over IP o Decision on the draft 2005 Work Programme for public consultation The ERG11 debriefing will be held on Monday, 6 December in Brussels at 10 AM. If you wish to attend this, please e-mail to erg-secretariat(a)cec.eu.int <mailto:erg@cec.eu.int> no later than close of business on Wednesday, 1 December. ________________________ European Regulators Group www.erg.eu.int

1 1

Re: [enum-wg] ITU: debate over User-ENUM administration
by Jim Reid 10 Feb '05

10 Feb '05

>>>>> "Christian" == Christian de Larrinaga <cdel(a)firsthand.net> writes: Christian> The scenario suggested by the Mr. Kisrawi has the DoC Christian> striking off .arpa or replacing the IAB authority over Christian> .arpa and the existing delegations in .arpa not being Christian> inherited by any successor "owner". This is a Christian> remarkable plot. Perhaps it could happen Whether it could or couldn't happen is not the point. The problem is some governments are very uneasy that they do not have an understood legal framework for the internet -- contracts, treaties, etc -- as they do for other forms of communication like post and telephone. Without that framework, they feel their national interests are not adequately safeguarded. This hasn't been helped by seeing some countries lose control over their TLDs. The next problem is that ICANN is a US company subject to US jurisdiction, not an offshoot of an international organisation. A fundamental principle of international law is the national resources of one state cannot be under the control of another. The wrangling over e164.arpa at SG2 is a scale model of that larger concern. Please note too that SG2 is largely a forum for governments and regulators. They're used to dealing with regulations, laws and contracts. The culture of the internet -- benign anarchy, liaison statements with organisations that legally do not exist, etc -- is alien to them. And perhaps frightening for some. The point Mr. Kiswari and others is making is not that DoC could pull the plug on .arpa. It's that if this happened, what redress do governments have? Who do they complain to and what power does that body have to resolve the issue? Since there are no contracts or treaties... BTW Christian, the mail server you're using is broken. It's gratuitously mangling email addresses: "enum-wg(a)ripe.net"@smtp.nildram.co.uk <"sob(a)harvard.edu"@smtp.nildram.co.uk> Could you please get this fixed?

1 0

RE: [enum-wg] ITU: debate over User-ENUM administration
by Stastny Richard 10 Feb '05

10 Feb '05

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 > -----Original Message----- > From: enum-wg-admin(a)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(a)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). > > 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

2 1

RE: [enum-wg] ITU: debate over User-ENUM administration
by Christian de Larrinaga 09 Feb '05

09 Feb '05

Richard Stastny wrote.. > Christian writes: > > If he is referring to e164.arpa then that is one thing if he is > referring > > to .arpa itself then that is quite another (I think!) > > Not really. > I disagree it is a really distinctive change because .arpa has other delegations and constituencies to consider apart from ENUM. For instance every reverse DNS entry in the world! This is why escalating up the tree from e164.arpa to .arpa has enormous implications for Internet users well beyond the very limited scope of ENUM itself. > The legal mess in the root and .arpa is (was) not of ITU-T's concern, > although they want to get in helpful to solve the problem ;-) > Well it is perhaps byzantine.:-) There may well be room for improvement :-) but there are as Jim noted plenty of voices that believe the current "structure" gives strength through diversity and it works! Some credit is due for that. The scenario suggested by the Mr. Kisrawi has the DoC striking off .arpa or replacing the IAB authority over .arpa and the existing delegations in .arpa not being inherited by any successor "owner". This is a remarkable plot. Perhaps it could happen but the whole Internet from root operators down the delegation trees would have to take up the changes and the DoC and the ITU will have to recognise that if people down the delegation trees don't like the changes they can do their own thing. Particularly if they are not US based. Also I hesitate to think of the reaction from countries around the world if the DoC behaved in such an arbitrary and overbearing way. So the scenario that is being raised by Mr. Kisrawi to justify the logic of the argument is apocalyptic. It does not seem reasonable as it is not based on experience of Internet management to date. We may internationally believe that the DoC as a national regulator for the US should step away from having final sayso over Internet resources that are considered international but the US has been a good responsible mothership for internetworking as has the role played by the IAB. > Now with ENUM suddenly e164.arpa IS of ITU-T's concern, and it is > only logical that they want to have a sound legal basis here. > Logic is not the issue! The issue is whether you cut or unravel the DNS knot and having done that how do you put it back together again in a way that does at least as good a job as we have today. Humpty dumpty sat on a wall, Humpty Dumpty had a great fall, all the kings horses and all the kings men couldn't put Humpty together again! (to quote an ancient British verse). > But since the question of the legal basis of e164.arpa leads > to the question of the legal basis of .arpa and this leads > finally to the question of the legal basic of the root itself. > > Nabil's chain of thought is only logical. but it misses the point that the higher up to the root you go the greater the number of constituencies implicated in any changes. There is significant impact in reverse engineering populated hierarchical structures. In particular when these are self governing and independent of each other organisationally. That is why it is sensible for ITU-T as the good netizen it is to clearly demarcate between operational measures to get services established today and the longer range (and genuine) governance issues concerning internationalisation and accountability over Internet resources. Christian

1 0

Re: [enum-wg] ITU: debate over User-ENUM administration
by Jim Reid 09 Feb '05

09 Feb '05

>>>>> "Alexander" == Alexander Mayrhofer <axelm(a)nic.at> writes: >> ..... 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. Alexander> slightly OT, but since i'm currently looking for this Alexander> in the scope of validation - Which document does Alexander> formally specify this tie between E.164 and ENUM? There isn't one as far as I know. This is a self-evident truth that shouldn't need to be documented. However there is usually a requirement from the regulator that ENUM registrations are authenticated and validated. If that applies, it follows that ENUM entries in that country have to be for assigned numbers that conform to the national numbering plan. Alexander> So, where's the place to look for (or add) this requirement? I've no idea. It shouldn't be in an update to RFC3761 IMO. That would take the IETF into the rathole of defining what "ownership" of an E.164 number meant. I'm not sure this requirement should be globally documented since it concerns a National Matter. Perhaps the regulator should issue something?

1 0

RE: [enum-wg] ITU: debate over User-ENUM administration
by Stastny Richard 09 Feb '05

09 Feb '05

Alex 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." Which in Austria is the RTR. In the agreement between RIPE, ITU-T and RIPE (the interim procedures) the ITU-T takes care that this is only the relevant national body ... > 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. ... in principle yes, because the rest is national matter and also the relevant ITU-T recommendations are only what the name says: recommendations, but no country having his senses together would do it that way - with one exception, but here Jim may provide you an answer ;-) richard > -----Original Message----- > From: enum-wg-admin(a)ripe.net [mailto:enum-wg-admin@ripe.net] On Behalf Of > Alexander Mayrhofer > Sent: Wednesday, February 09, 2005 12:39 PM > To: Jim Reid > Cc: Niall O'Reilly; enum-wg(a)ripe.net > Subject: Re: [enum-wg] ITU: debate over User-ENUM administration > > 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

1 0

Re: [enum-wg] ITU: debate over User-ENUM administration
by Jim Reid 09 Feb '05

09 Feb '05

>>>>> "Richard" == Stastny Richard <Richard.Stastny(a)oefeg.at> writes: Richard> Authenticating free-phone and premium rate numbers is not Richard> harder then authenticating any other number. That might be true in Austria. It isn't in the UK.

1 0

RE: [enum-wg] ITU: debate over User-ENUM administration
by Stastny Richard 09 Feb '05

09 Feb '05

Jim wrote: > 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. Authenticating free-phone and premium rate numbers is not harder then authenticating any other number. Freephone numbers in ENUM are not a problem at all, beside the fact Telcos do not like the idea. It is ideal for the customers = call centers migrating to VoIP anyway. In Austria freephone numbers are allowed in ENUM and the US enum-forum is also going this way. Another issue is premium rate numbers: since a customer must be crazy providing an ENUM entry with no termination charge there is no need and business case. Regards Richard

1 0

Re: [enum-wg] ITU: debate over User-ENUM administration
by Jim Reid 08 Feb '05

08 Feb '05

>>>>> "Christian" == Christian de Larrinaga <cdel(a)firsthand.net> writes: Christian> I don't see a contract between ITU and US as resolving Christian> the issues raised as it remains debatable that IETF and Christian> IAB are US entities. It's more than debatable. The IAB and IETF don't exist because they have no legal personality. This gives governments and organisations like the ITU a bit of a problem. They are used to contracts and treaties: legally binding documents between recognised entities. So since there's no contract that says ITU have administrative control over e164.arpa, that makes some ITU members very anxious. The liaison statements and MoUs between ITU and RIPE NCC and IAB give effective administrative control. However these are not the watertight contracts -- which jurisdiction(s)? -- that some people in SG2 want. Christian> I'm curious that Mr. Kisrawi appears not to have any Christian> operational concerns for management of 3.6.9.e164.arpa Christian> as things stand but of political control over .arpa and Christian> the root. Syria's country code has not been delegated, so there are no operational concerns. And for all we know, the Syrians might have decided not to get it delegated until there's sufficient ITU control over e164.arpa -- for some definition of control. They could have decided that it's not in their national interest to get the delegation until the administrative safeguards they seem to want are in place. That's a perfectly reasonable position. Some countries are content with the current arrangements -- if they weren't, they would not have allowed the delegation of their country code -- others aren't. This is one reason why the ENUM discussions inside SG2 are continuing. Christian> ITU has agreed a procedure with the IAB and RIPE over Christian> ENUM. It seems a bit late for ITU to start questioning Christian> the legal ownership of .arpa now and totally out of Christian> context to do so citing ENUM which represents a tiny Christian> amount of Internet traffic and is only one protocol to Christian> extend reachability for E.164 numbers. Christian, that's beside the point quite frankly. If ITU SG2 wants to discuss ownership of .arpa or the planet Tharg, they are free to do so. Please note too that the current process for handling delegation requests by ITU is governed by interim procedures. They're temporary. A permanent solution is pretty much guaranteed to require clarification of the administrative control over e164.arpa and .arpa. ie SG2 members need to be sure that if ITU comes to an understanding over e164.arpa, IAB won't choose a different domain name or pick a new Tier-0 registry or someone takes .arpa away from IAB. And this understanding should be formalised in some sort of contract. Mr. Kaswari's contribution is the next step down that road. Christian> So maybe this group could make some representation into Christian> the ITU debate on ENUM to focus on what ENUM is and Christian> what it is not in particular in regard to regulatory Christian> issues (e.g., ENUM has nothing to do with assignment of Christian> E.164 numbers or national number plans) might be Christian> helpful to steer ENUM out of these waters. Is this Christian> something RIPE could do? 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? :-) There is a need to explain to SG2 how things like the DNS work and how the internet is governed. [I did some of that when I attended SG2.] RIPE NCC could do this if they were willing and able to commit the time and resources. However they're not Sector Members of ITU, so they can't participate in SG2 meetings. I think the same would be true for most other internet people that could take on this educational role. I believe ITU can invite external experts to attend SG2 as observers, though SG2 would probably be more comfortable having that dialogue between Sector Members rather than with an outsider. Christian> Having said this these top level arguments are not Christian> going away and so the IAB as others in the Internet Christian> world need to establish its rights over .arpa and Christian> assert them but this is not an ENUM issue. Indeed. And it's not a topic for this list.

3 2

FW: [enum-wg] ITU: debate over User-ENUM administration
by Stastny Richard 08 Feb '05

08 Feb '05

Christian writes: > If he is referring to e164.arpa then that is one thing if he is referring > to .arpa itself then that is quite another (I think!) Not really. The legal mess in the root and .arpa is (was) not of ITU-T's concern, although they want to get in helpful to solve the problem ;-) Now with ENUM suddenly e164.arpa IS of ITU-T's concern, and it is only logical that they want to have a sound legal basis here. But since the question of the legal basis of e164.arpa leads to the question of the legal basis of .arpa and this leads finally to the question of the legal basic of the root itself. Nabil's chain of thought is only logical. Regards Richard PS: regarding your other statement: >I hope my explanation elsewhere clarifies what I mean. ... >I am simply saying that from the top down ENUM >delegation does not confer >with it authority to create and manage E.164 >number plans. >That still remains with the existing E.164 delegations e.g., >in UK Ofcom. ie., ENUM is not competing with the existing ITU E.164 number >process. Agreed

1 0

Re: [enum-wg] ITU: debate over User-ENUM administration
by Christian de Larrinaga 08 Feb '05

08 Feb '05

--------- Original Message -------- From: Jim Reid <jim(a)rfc1035.com> > >>>>> "Christian" == Christian de Larrinaga <cdel(a)firsthand.net> writes: > > Christian> I don't see a contract between ITU and US as resolving > Christian> the issues raised as it remains debatable that IETF and > Christian> IAB are US entities. > > It's more than debatable. The IAB and IETF don't exist because they > have no legal personality. This gives governments and organisations > like the ITU a bit of a problem. The point I was trying to make is that the arguments given in the Syrian document are less about ENUM as about the entire ediface. I think it is important to keep clean air on this. ENUM is not about changing what ITU and national number authorities for E.164 do. ENUM is ancillary to this. >The liaison > statements and MoUs between ITU and RIPE NCC and IAB give effective > administrative control. However these are not the watertight contracts > -- which jurisdiction(s)? -- that some people in SG2 want. > indeed. But this issue is far broader than a protocol called ENUM. > Christian> I'm curious that Mr. Kisrawi appears not to have any > Christian> operational concerns for management of 3.6.9.e164.arpa > Christian> as things stand but of political control over .arpa and > Christian> the root. > > Syria's country code has not been delegated, so there are no > operational concerns. And for all we know, the Syrians might have > decided not to get it delegated until there's sufficient ITU control > over e164.arpa -- for some definition of control. ok but my point is that this is no different for a national enum delegation .sy or any domain. The delegation tree is shorter for a .com zone (normally) but you still come up with the same basic issues of internet structures that Mr. Kisrawi mentions. These are very old and wel known and debated issues that he raises. If he is referring to e164.arpa then that is one thing if he is referring to .arpa itself then that is quite another (I think!) snip > > Christian> So maybe this group could make some representation into > Christian> the ITU debate on ENUM to focus on what ENUM is and > Christian> what it is not in particular in regard to regulatory > Christian> issues (e.g., ENUM has nothing to do with assignment of > Christian> E.164 numbers or national number plans) might be > Christian> helpful to steer ENUM out of these waters. Is this > Christian> something RIPE could do? > > 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? :-) OK how does an ENUM delegation (as currently defined) provide authority to create a number plan, delegate that number plan to operators to create further numbers within their number blocks? This is what I mean by authority and delegation. I don't mean a protocol that some script kiddie uses to create his own hack telphone service. I am talking about the official line of authority. ENUM maps E.164 into DNS but only once E.164 numbers are allocated (through the ITU process) and only then into the official ENUM tree through a procedure that involves the ITU E.164 delegation tree. As we know from uk group the process is far from perfect and there is plenty of room for improving clarity and as you quite rightly point out moving from interim status. > > There is a need to explain to SG2 how things like the DNS work and how > the internet is governed. [I did some of that when I attended SG2.] > RIPE NCC could do this if they were willing and able to commit the > time and resources. However they're not Sector Members of ITU, so they > can't participate in SG2 meetings. I think the same would be true for > most other internet people that could take on this educational role. I > believe ITU can invite external experts to attend SG2 as observers, > though SG2 would probably be more comfortable having that dialogue > between Sector Members rather than with an outsider. we need to get away from them and us, > > Christian> Having said this these top level arguments are not > Christian> going away and so the IAB as others in the Internet > Christian> world need to establish its rights over .arpa and > Christian> assert them but this is not an ENUM issue. > > Indeed. And it's not a topic for this list. > my point exactly. It is not about ENUM per se. Christian ________________________________________________ Message sent using UebiMiau 2.7.2

1 0

RE: [enum-wg] ITU: debate over User-ENUM administration
by Christian de Larrinaga 08 Feb '05

08 Feb '05

--------- Original Message -------- From: Andrzej Bartosiewicz <andrzejb(a)nask.pl> Date: 08/02/05 10:10 > > > regulatory issues (e.g., ENUM has nothing to do with assignment of E.164 > > numbers or national number plans) might be helpful to steer ENUM out of > > these waters. Is this something RIPE could do? > > That's interesting... Don't you think that User-ENUM maps the national > numbering plans into DNS. > > Andrzej. > of course ENUM does. But only once E.164 numbers have been assigned. And they are assigned through the ITU to national regulatory processes. ENUM does not change any of the delegation issues for E.164 itself. ENUM is a protocol to support applications that use E.164 numbers (largely) it applies E.164 after the effect. Christian ________________________________________________ Message sent using UebiMiau 2.7.2

1 0

RE: [enum-wg] ITU: debate over User-ENUM administration
by Stastny Richard 08 Feb '05

08 Feb '05

I think the confusion in this discussion comes from the clash of two cultures and some misunderstandings. e164.arpa is not a "normal" domain like .com/.net. It is more like a sponsored domain. In .com the domain name holder is the owner of his domain. In E.164 there is NEVER an ownership. Nobody OWNS an E.164 number (maybe the ITU). E.164 numbers are assigned and the subscriber has the right-to-use according to certain rules he has to obey. The associated domain in e164.arpa is linked 1:1 to this right-to-use of the E.164 number. If he is loosing this right to use, he is also loosing the right-to-use of the e164.arpa domain. On the other hand, he is the ONLY ONE who has this right-to-use, e.g. there is no first- come, first serve, etc. There is another difference (which I try to formulate here as a non-laywer). A normal domain name holder in .com/.net and also the ccTLDs has a direct contract with the Registry and the whole thing has in most cases only two "tiers" (+ 1: the root) In e164.arpa this is more complicated (and this seems also be part of the current discussion) - there are more registries. 1. there is the root (ICANN and the DoC) 2. there is arpa (+ the IAB) 3. there is e164.arpa (+ RIPE and ITU-T) 3a. there is the group of countries (e.g. in CC+1) 4. there is the CC-level (the NRA and the "tier1" Registry) 5. there are the Registrars, the validation entities and the telcos 6. there is the end-user This is a legal nightmare and a land of milk and honey for lawyers ;-) BTW, I am wondering that especially people from the US are not caring so much about and wondering that somebody wants sound legal constructs? Richard > -----Original Message----- > From: enum-wg-admin(a)ripe.net [mailto:enum-wg-admin@ripe.net] On Behalf Of > Jim Reid > Sent: Tuesday, February 08, 2005 12:48 PM > To: Thilo Salmon > Cc: enum-wg(a)ripe.net > Subject: Re: [enum-wg] ITU: debate over User-ENUM administration > > >>>>> "Thilo" == Thilo Salmon <salmon(a)sipgate.de> writes: > > Thilo> I read that as "yes, it is a mapping", but "no, it is not > Thilo> (necessarily) an assignment". With few exceptions E.164 > Thilo> numbers have already been assigned and the e164.arpa domain > Thilo> merely functions as a directory. > > First of all Thilo, DNS is NOT a directory. Please don't confuse it > with one. Secondly, an entry under e164.arpa *is* an assignment. The > only way to get a number entered in the public tree is if (a) the > country code has been delegated; (b) the registry for that country > code delegates the number concerned. If that doesn't constitute an > assignment, I don't know what does. Of course, whether that E.164 > number has been assigned by the regulator or a telco is another > matter.

1 0

Re: [enum-wg] ITU: debate over User-ENUM administration
by Jim Reid 08 Feb '05

08 Feb '05

>>>>> "Thilo" == Thilo Salmon <salmon(a)sipgate.de> writes: Thilo> I read that as "yes, it is a mapping", but "no, it is not Thilo> (necessarily) an assignment". With few exceptions E.164 Thilo> numbers have already been assigned and the e164.arpa domain Thilo> merely functions as a directory. First of all Thilo, DNS is NOT a directory. Please don't confuse it with one. Secondly, an entry under e164.arpa *is* an assignment. The only way to get a number entered in the public tree is if (a) the country code has been delegated; (b) the registry for that country code delegates the number concerned. If that doesn't constitute an assignment, I don't know what does. Of course, whether that E.164 number has been assigned by the regulator or a telco is another matter.

1 0

Re: [enum-wg] ITU: debate over User-ENUM administration
by Stastny Richard 08 Feb '05

08 Feb '05

John writes: >there is a case to be made that the SG2 >management becomes part of the problem when they put these >things on the agenda rather than ruling them out of order. I think you do not know how ITU-T works (maybe having in mind some other bodies) I can only fully agree here with Andrzej: . >Delegate of Syria submitted his contributions. It's his right. Every >government (Member State) or Sector Member can submit his contributions, and >the discussion can go forward. In addition, Mr. Kisrawi is not questioning ENUM or e164.arpa in his contribution, he is only questioning the legal status of the domain name holder of e164.arpa, namely: Internet Architecture Board (IAB) c/o IETF Secretariat Corporation for National Research Initiatives (CNRI) 1895 Preston White Drive Suite 100 Reston, Virginia 20191-5434 He is also questioning the legal status of .arpa and finally the root servers, which is IMHO a valid question. He is also fully aware of the de-facto role of the DoC and he is also proposing a feasible way forward: "The final problem is more serious. ICANN cannot, on its own, make changes in the root server system. ICANN proposes changes, which are approved by the United States Department of Commerce (DoC). Once the change is approved, DoC transmits it to Verisign, who implements the change in what is commonly called the "hidden root server" (located within the United States and under US jurisdiction). The change is then automatically propagated to all other root servers around the world. Thus, DoC could change the entity to whom "arpa" is delegated, and this could result in loss of ITU's administrative control. A possible solution could be a formal bilateral agreement between the USA, a Sovereign State, and the ITU." So Mr. Kisrawi raises a valid question in asking the ITU-T to make sound legal contracts for important infrastructure issues best regards Richard Stastny ________________________________ Von: enum-wg-admin(a)ripe.net im Auftrag von John C Klensin Gesendet: Sa 05.02.2005 20:45 An: Richard Shockey; Andrzej Bartosiewicz; enum-wg(a)ripe.net Cc: paf(a)cisco.com; Leslie Daigle; sob(a)harvard.edu; swinehart(a)icann.org Betreff: Re: [enum-wg] ITU: debate over User-ENUM administration Richard, I agree with everything you say, with two qualifications... (1) I'm not sure the world revolves around North America and the NANP. Indeed, I consider that attitude to be harmful to the Internet and the IETF, regardless of what things look like from the vicinity of the beltway. (2) Since said permanent delegate of Syria submits these things to SG2 and then uses the fact that they have been put on the agenda as motivation for arguing in other forums that this is an area under ITU control, there is a case to be made that the SG2 management becomes part of the problem when they put these things on the agenda rather than ruling them out of order. I understand at least some of the constraints under which they operate, but you should understand why, given that and the behavior patterns of the last several years, I don't completely share your confidence. john --On Saturday, 05 February, 2005 14:28 -0500 Richard Shockey <richard(a)shockey.us> wrote: > >> >> Hi. >> >> I wonder how you (or we) should define "progress"? We start >> with an area that was originally agreed to be an IETF >> responsibility with TSB participation on >> authorization/validation issues. It then "evolves", at SG2 >> insistence, to something that is assumed to involve at least >> some topics we should discuss together. And now we have >> attained the pinnacle of a discussion within SG2, >> apparently-secret from the outside world, based on documents >> that are not generally available to the IETF and the ENUM user >> community. >> >> And, of course, unless ITU-T SG2 is planning to disrupt the >> Internet by setting up an alternate root, their deciding on an >> ENUM TLD is only slightly more likely to be relevant than >> their passing a Recommendation that changes the speed of >> light. >> >> Leslie, Scott, can these documents be obtained and released to >> the IETF ENUM WG and interested members of the community so >> that we can further evaluate the level of progress? > > Attached ... > > However considering the source of these documents ..the well > known Permanant Delegate of Syria to the ITU I'm not overly > concerned about their impact, but this requires careful > monitoring. John I'm in total agreement the principle that > the price of the Internet freedom is eternal vigilance . > > I have some ... some ..confidence in SG-2 management to "do > the right thing" here and in any event. IMHO the most > important task for the global ENUM community to accomplish is > getting the delegation for 1.e164.arpa to North America ASAP > and commence short lived trials that will lead to commercial > deployment. > > Once that is done I think we would have sent a message that > e164.apra is real and that further discussions on the matter > of a different root are futile. > > That process is well underway.. discussions over how the ENUM > LLC management entity will act are taking place almost weekly > . I'm also very confident that there well be responsible,open > ,and competitive bidding processes for both the US and > Canadian portions of the NANP within the late 2005 very early > 2006 time frame. > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

4 4

RE: [enum-wg] ITU: debate over User-ENUM administration
by Stastny Richard 08 Feb '05

08 Feb '05

Christian wrote: > (e.g., ENUM has nothing to do with assignment of E.164 > numbers or national number plans) Huh? On which planet are you living on? Richard

1 0

Re: [enum-wg] ITU: debate over User-ENUM administration
by Jim Reid 07 Feb '05

07 Feb '05

>>>>> "Andrzej" == Andrzej Bartosiewicz <andrzejb(a)nask.pl> writes: Andrzej> Unfortunately that's true that ICANN has no legal power Andrzej> over Root Server administrators (ICANN failed in signing Andrzej> the agreements with root servers administrators)... That's actually a good thing IMO. The root server operators are very careful to avoid single points of failure. That applies to procedural, contractual and financial aspects of the running root server system as well as the technical and operational ones. If all the root server operators signed the same contract with ICANN, that contract would be a single point of failure. This thread is getting off topic for this list.

1 0

ITU: debate over User-ENUM administration
by Andrzej Bartosiewicz 07 Feb '05

07 Feb '05

ITU is making progress in debate on ENUM: Group : itu-t updated : 2005-02-01 23:58:06 title : [ D 20 ] Administrative control for ENUM url : http://www.itu.int/md/meetingdoc.asp?lang=e <http://www.itu.int/md/meetingdoc.asp?lang=e&parent=T05-SG02-050216-D-0020&t ype=mitems> &parent=T05-SG02-050216-D-0020&type=mitems Group : itu-t updated : 2005-02-03 23:58:05 title : [ TD 32-WP1 ] Evaluation of a new gTLD exclusively for Global ENUM implementation url : http://www.itu.int/md/meetingdoc.asp?lang=e <http://www.itu.int/md/meetingdoc.asp?lang=e&parent=T05-SG02-050216-TD-WP1-0 032&type=mitems> &parent=T05-SG02-050216-TD-WP1-0032&type=mitems Documents available only for TIES (ITU) users. Andrzej.

3 6

Re: [enum-wg] ITU: debate over User-ENUM administration
by Stastny Richard 04 Feb '05

04 Feb '05

Progress? Richard ________________________________ Von: enum-wg-admin(a)ripe.net im Auftrag von Andrzej Bartosiewicz Gesendet: Fr 04.02.2005 12:35 An: enum-wg(a)ripe.net Betreff: [enum-wg] ITU: debate over User-ENUM administration ITU is making progress in debate on ENUM: Group : itu-t updated : 2005-02-01 23:58:06 title : [ D 20 ] Administrative control for ENUM url : http://www.itu.int/md/meetingdoc.asp?lang=e&parent=T05-SG02-050216-D-0020&t… Group : itu-t updated : 2005-02-03 23:58:05 title : [ TD 32-WP1 ] Evaluation of a new gTLD exclusively for Global ENUM implementation url : http://www.itu.int/md/meetingdoc.asp?lang=e&parent=T05-SG02-050216-TD-WP1-0… Documents available only for TIES (ITU) users. Andrzej.

1 0

WG: [Iptel] I-D ACTION:draft-ietf-iptel-tel-enumdi-00.txt
by Stastny Richard 03 Feb '05

03 Feb '05

FYI ________________________________ Von: iptel-bounces(a)ietf.org im Auftrag von Internet-Drafts(a)ietf.org Gesendet: Do 03.02.2005 21:56 An: i-d-announce(a)ietf.org Cc: iptel(a)ietf.org Betreff: [Iptel] I-D ACTION:draft-ietf-iptel-tel-enumdi-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : The ENUM Dip Indicator parameter for the "tel" URI Author(s) : R. Stastny, L. Conroy Filename : draft-ietf-iptel-tel-enumdi-00.txt Pages : 12 Date : 2005-2-3 This document defines a new parameter "enumdi" in the "tel" Uniform Resource Identifier (URI) as defined in RFC3966 to support the handling of ENUM queries in SIP proxies, H.323 gatekeepers and other VoIP network elements. The presence of the "enumdi" parameter indicates to the VoIP network element receiving an URI containing an E.164 number that an ENUM query as defined in RFC3761 has already been performed on the E.164 number indicated by the previous VoIP network element. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-enumdi-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request(a)ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-tel-enumdi-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-tel-enumdi-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

1 0

WG: [Enum] Working Group Last Call on Enumservice Registration VOID
by Stastny Richard 03 Feb '05

03 Feb '05

FYI Richard ________________________________ Von: enum-bounces(a)ietf.org im Auftrag von Richard Shockey Gesendet: Do 03.02.2005 17:33 An: enum(a)ietf.org Cc: paf(a)cisco.com; Jon Peterson; mankin(a)psg.org Betreff: [Enum] Working Group Last Call on Enumservice Registration VOID This draft is sufficiently easy to understand that this can proceed immediately to last call. I've noted no substantive issues with it. The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 2 weeks or so from today Feb 3 to at least Feb 21 though we can modify that if new issues come up. Title : IANA Registration for Enumservice VOID Author(s) : R. Stastny, L. Conroy Filename : draft-ietf-enum-void-00.txt Pages : 0 Date : 2004-10-12 This document registers the Enumservice 'void' using the URI schemes 'mailto:' and 'http:' as per the IANA registration process defined in the ENUM specification, RFC3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-void-00.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum(a)ietf.org https://www1.ietf.org/mailman/listinfo/enum

1 0

ITU-T/ENUM/NP
by Andrzej Bartosiewicz 26 Jan '05

26 Jan '05

Dear All, I would like to draw your attention to the ITU SG-2 activities regarding Number Portability. It seems that SG2 (thanks to Marco Bernardi from NeuStar) of ITU-T will be considering Infrastructure-ENUM as potential solution for Number Portability Database. I'm very glad because this is the idea I have been promoting in Poland for the last year... :) Group : itu-t title : [ D 9 ] Draft Number Portability Supplement url : http://www.itu.int/md/meetingdoc.asp?lang=e&parent=T05-SG02-050216-D-0009&ty pe=mitems Best, Andrzej.

1 0

Two ETSI drafts on ENUM approved today
by Stastny Richard 21 Jan '05

21 Jan '05

Dear all, http://voipandenum.blogspot.com/2005/01/two-etsi-drafts-on-enum-approved-to… ETSI <http://portal.etsi.org> TISPAN WG4 finished 2 drafts on User ENUM <http://enum.nic.at/documents/ETSI/Drafts/05TD142r3%20DTS_102172v020006.pdf> and on Infrastructure ENUM <http://enum.nic.at/documents/ETSI/Drafts/05TD143r4%20Draft%20TR_102055v008.…> (Carrier ENUM) this week and got workgroup and TISPAN plenary approval today. ETSI DTS 102 172 V2 <http://enum.nic.at/documents/ETSI/Drafts/05TD142r3%20DTS_102172v020006.pdf> "Minimum requirements for interoperability of ENUM implementations" contains general guidance on (User) ENUM implementations as defined in RFC3761 and in ETSI TS 102 051 "ENUM Administration in Europe" and the specification for: * The format, contents and meaning of the information in the NAPTR records that are held by the ENUM Tier 2 Nameserver providers and accessible by DNS. * The ways in which ENUM client software should interpret and act upon information obtained from NAPTR records. The document is intended to enable interoperability between ENUM implementations that are organized in different countries. This interoperability enables: * The same ENUM client software to work with NAPTR records generated by different national implementations and this in turn will enable applications that use ENUM to access details of ENUM subscribers in more than one country without additional modifications. * Organizations to function as ENUM Registrars and ENUM Tier 2 Nameserver Provider in more than one national implementation. The document will therefore add economies of scope to the ENUM implementations that will benefit ENUM subscribers, providers, application service providers and ENUM users. The present document is Version 2 of the Technical Specification (TS) and incorporates already some results obtained from trials performed in some countries. It may serve therefore also as a basis for first commercial deployments, keeping in mind that still not all enumservices are available as IETF RFCs and registered with IANA. The intention is to review this document based on the experience gained from future implementations and if necessary. ETSI DTR 102 055 <http://enum.nic.at/documents/ETSI/Drafts/05TD143r4%20Draft%20TR_102055v008.…> "Infrastructure ENUM" This document identifies a range of issues which occur if providers of communication services and networks (called Communication Service Providers (CSP) within this document) consider using the concepts developed in RFC 3761 (ENUM) for infrastructure purposes. Such an approach would result in the application of the ENUM concept to the provision of information for routeing (both internally and for the interconnection of networks - also called peering), including information for number portability, freephone and other number or address translation capabilities, SMS and MMS, etc. It considers the likely steps along the way and where possible, identifies alternative options and approaches. It will specifically identify: * issues which occur if providers of IMS-based NGNs consider peering traffic with each other via Points-of-Interconnect based on IP technology, by using E.164 numbers to address end-points they are hosting for their subscribers, * issues which occur if providers of IMS-based NGNs consider peering traffic with other providers e.g. IMS-based PLMNs and also with providers on the Internet. Out-of-scope are requirements for using Infrastructure ENUM for peering of transit traffic not targeted for end-points within the providers control. regards Richard Stastny

1 0

Re: [enum-wg] Kim's document
by Stastny Richard 21 Jan '05

21 Jan '05

Hi Kim, may I point BTW to two major errors 1. Austria is in production since Dezenber 2004 2. The request from Australia is not objected (this is also wrong on the RIPE page: http://www.ripe.net/enum/request-archives/index.html see http://www.ripe.net/maillists/ncc-archives/enum-announce/2005/msg00001.html regards Richard ________________________________ Von: enum-wg-admin(a)ripe.net im Auftrag von Andrzej Bartosiewicz Gesendet: Fr 21.01.2005 15:06 An: 'Kim Davies' Cc: enum-wg(a)ripe.net Betreff: RE: [enum-wg] Kim's document Thanks Kim. > -----Original Message----- > From: enum-wg-admin(a)ripe.net [mailto:enum-wg-admin@ripe.net] On Behalf Of > Kim Davies > Sent: Friday, January 21, 2005 2:52 PM > To: Andrzej Bartosiewicz > Cc: enum-wg(a)ripe.net > Subject: Re: [enum-wg] Kim's document > > Andrzej Bartosiewicz wrote: > > The link http://www.centr.org/kim/enum/index.html is broken. > > > > Is there anybody who has the copy of this document? > > This page is working again. Had some server difficulties a few weeks > back and didn't think to check it. > > kim

1 0

Kim's document
by Andrzej Bartosiewicz 21 Jan '05

21 Jan '05

The link http://www.centr.org/kim/enum/index.html is broken. Is there anybody who has the copy of this document? Andrzej.

2 2

Announcement: Policy Development Process in RIPE
by Rob Blokzijl 21 Dec '04

21 Dec '04

To the RIPE Community, later today I will publish a draft document that describes the policy making process in RIPE. It is draft, so your input is requested in order to come to a generally accepted final document. Logistics: - deadline for comments on the first draft: 1 Februari 2005 - discussion takes place on ripe-list(a)ripe.net - if you are not subscribed to ripe-list(a)ripe.net yet, go to http://www.ripe.net/mailman/listinfo/ripe-list#subscribers - for any questions, don't hesitate to contact chair(a)ripe.net As always, apologies for receiving multiple copies of this announcement. Best regards, Rob Blokzijl RIPE Chairman

2 1

ENUM Status for Ireland (+353)
by Niall O'Reilly 21 Dec '04

21 Dec '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Q1.What is the country and E.164 code Ireland, +353 Q2. Who is the delegate for the E.164 code The E.164 code +353 is delegated to ComReg, the Commission for Communications Regulation, acting on behalf of the Department of Communications, Marine and Natural Resources. Q3. The Status of Deployment The trial is being conducted. First phase (Technical and organisational set-up) is finished since early October 2004. Phase 2 (test with UCD and MCI customers) will be conducted between October 2004 and March 2005. Q4. ENUM Project contact details: ComReg (Commission for Communications Regulation) Irish Life Centre Abbey Street Dublin 1 Ireland Pat Walsh: pat.dot.walsh.at.comreg.dot.ie Oonagh O'Reilly: oonagh.dot.oreilly.at.comreg.dot.ie Q5. The trial is being conducted Q6. Is there work or plans toward full deployment? Commercialisation is in the books but no detailed plans have been done so far. Q7. Who is leading the ENUM Project? ComReg Q8. Who operates the ccTLD for that country at present? IE Domain Registry Limited (IEDR) Q9. What type of organisation runs the ccTLD? The IEDR is a private, independent, not-for-profit company Q10. What is the ccTLD legal regulation? The E-Commerce Act of 2000 empowers the relevant Minister to introduce regulations which may "authorise, prohibit or regulate the registration and use of the ie domain name in the State." (http://www.oireachtas.ie/documents/bills28/acts/2000/a2700.pdf) To date, this power has not been exercised. Q11. Who is it the current Tier 1 registry? Afilias (for the duration of the trial) Q12. Who is, or will be the permanent Tier 1 registry? To be defined before commercialisation stage Q13. How will be the Tier 1 registry selection be made? According to the Irish ENUM Forum's report, this will be by standard European public procurement process. (http://www.comreg.ie/_fileupload/publications/ComReg04105a.pdf) Q14. Method of cost recovery? To be defined Q15. Will there be more than one Tier 1 provider? Very unlikely Q16. Will there be ENUM registrars? To be defined (Registrar roles could be merged with Tier 2 Name Server Providers) Q17. What will be the ENUM validation technique? Several techniques from checking a phone bill to sending a SMS, making a telephone call to the registrant ... Trial experience is expected to identify which techniques are operationally feasible. Q18. Is there/will be a special number block for ENUM? A special range has been defined for VoIP, but ENUM is not restriced to this range. Q19. Is there special treatment for unlisted numbers? To be defined. Q20. Are there any plan for infrastructure ENUM? To be defined Q21. What is the ENUM WHOIS address? To be defined Q22. Please provide the history for ENUM trials, projects etc... The Irish ENUM Forum was created in October 2003. The approach within the Irish ENUM Forum was to advance the thinking and understanding of ENUM within the Irish communications industry, to develop a clear understanding of how the framework for the operation of ENUM can take place and to define an Engineering Trial that would derive some additional learning, leading to conclusions that can provide guidance to Irish organisations on how to respond to ENUM. An engineering trial was launched in July 2004 and will end in March 2005. Phase 1: Technical and organisational set-up (July-October 2004) Phase 2: test with customers (Oct 2004 to March 2005) Q23. What are the future plans? Phase 2 of trial from October to March next year. Possible commercialisation process (TO BE CONFIRMED) from Q2-Q3 2005. Q24. What is your date estimate on a production ENUM...? Q2-Q3 2005 (TO BE CONFIRMED) Best regards, Niall O'Reilly PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBx/PGeYfkja6ZXtkRAhPvAJ9HjI56g6AwuIpxpV8/c5J9Nws7YACeIix8 2IIx5axtlu6tgzjgSCt0LDQ= =/9CF -----END PGP SIGNATURE-----

1 0

RE: RE:: [enum-wg] COCOM & ENUM ...
by Stastny Richard 15 Dec '04

15 Dec '04

Marco writes: > > Very, very unlikely we have a single tree for operator ENUM. > Operators will never be able to agree. And perhaps it is > right - different trees may serve different applications, > different operators' communities with different policies. This may work for some time and if there is a PSTN for default routing But what if the PSTN is gone? Your customers will expect that they may call all numbers, so a provider needs to interconnect with all others (some way or the other). > > Not sure how we can enforce across different > communities/trees the rule that an operator can only insert > his numbers - A job for ITU-T? I do not think this is necessary. In crime one of the basic questions is the motivation. What is the motivation for a provider to enter numbers he is not terminating, if you do not get termination charges? What is the meaning of transit on the Internet? - Transit of signalling messages = proxying - Transit of media stream? If the meadia stream does not even touch the origination and terminating proxy? It simply does not make sense. What makes sense if you have more than one tree may be a clearing house proxy with access to multiple trees, but they will not get charged per call minute. -richard > > marco > ----- Original Message ----- > From: "Stastny Richard" <Richard.Stastny(a)oefeg.at> > To: "Jim Reid" <jim(a)rfc1035.com>; "Richard Shockey" > <richard(a)shockey.us> > Cc: "Marco bernardi" <marco.bernardi(a)neustar.biz>; "Andrzej > Bartosiewicz" > <andrzejb(a)nask.pl>; "Carsten Schiefner" > <enumvoipsip.cs(a)schiefner.de>; <enum-wg(a)ripe.net> > Sent: Wednesday, December 15, 2004 9:19 AM > Subject: RE:: [enum-wg] COCOM & ENUM ... > > > Jim writes: > > I think there's general > > consensus that end users should not see core telco routing data. > > Here we are at the point: why should they? > > The basic question discussed here is VoIP (aka SIP) on the public > Internet > and VoIP (aka NGN - or NWOS - new wine in ols skins - Lawrence) in > walled gardens. > > If you implement VoIP on the Internet you basically need SIP > URIs (AoRs) > and proxies > (SVR records in the DNS) to reach this SIP AoRs. If you do not have > these ENUM in e164.arpa > Is completely useless. If you have these, you basically do not need > telcos for routing > E.164 numbers. > > If you implement VoIP in NGN walled gardens you basically have two > choices: > a - they use an extranet (e.g. GRX from GSM-A) to interconnect between > the walled gardens > the choice of the routing mechanism (ENUM or something else) > in this case is purely a decision of the extranet provider > (e.g. GSM-A) > and also limited to the club. End-user will not have access to these > data. > What you need here is a mapping E.164 number to operator. > > b - they use the public Internet to interconnect, so they > need some kind > of > public AoRs (URIs) (e.g. +xxx(a)be.prov.net )to address the > ingress border > elements > (these finally have public IP-adresses). So they may use some kind of > ENUM in a > commonly agreed upon tree, which could be any root e.g. > e164.stastny.com) > Subscribers may may be able to query the tree or not, but it will be > useless > because they cannot access the border elements directly. > > The bsaic question here is: do the carriers agree on ONE tree or will > there be a wood > of trees? But this is not a big issue if all con-federations have a > basic rule: any > participating carrier is obliged to enter only E.164 numbers he is > serving. Then > automatically not overlaps exist between the trees (expect carriers > participating > in more then one tree) and therefor the trees could be merged easily > later. > > Back to the original question: > > I think there's general > > consensus that end users should not see core telco routing data. > > Normal end-users give a s**t anyway about technical details if making > a call, so why should the be prevented to see core telco routing > data. They real problem of telcos is to prevent OTHER TELCOS to see > their data, primarily to see how many subscribers they really have ;-) > > They funny thing here is that competitors know these facts anyway, but > it's nice to pretend to have secrets. > > Now we are at the basic problem: > Is there a way to feed data into a database > used by competitors to find out which numbers a given telco hosts > without > disclosing to the competitors which numbers this telco hosts? > > A cretan says: all cretans are liars. True or false? > > This is the problem we have to solve ;-) > > -richard > > > >

1 0

RE:: [enum-wg] COCOM & ENUM ...
by Stastny Richard 15 Dec '04

15 Dec '04

Jim writes: > I think there's general > consensus that end users should not see core telco routing data. Here we are at the point: why should they? The basic question discussed here is VoIP (aka SIP) on the public Internet and VoIP (aka NGN - or NWOS - new wine in ols skins - Lawrence) in walled gardens. If you implement VoIP on the Internet you basically need SIP URIs (AoRs) and proxies (SVR records in the DNS) to reach this SIP AoRs. If you do not have these ENUM in e164.arpa Is completely useless. If you have these, you basically do not need telcos for routing E.164 numbers. If you implement VoIP in NGN walled gardens you basically have two choices: a - they use an extranet (e.g. GRX from GSM-A) to interconnect between the walled gardens the choice of the routing mechanism (ENUM or something else) in this case is purely a decision of the extranet provider (e.g. GSM-A) and also limited to the club. End-user will not have access to these data. What you need here is a mapping E.164 number to operator. b - they use the public Internet to interconnect, so they need some kind of public AoRs (URIs) (e.g. +xxx(a)be.prov.net )to address the ingress border elements (these finally have public IP-adresses). So they may use some kind of ENUM in a commonly agreed upon tree, which could be any root e.g. e164.stastny.com) Subscribers may may be able to query the tree or not, but it will be useless because they cannot access the border elements directly. The bsaic question here is: do the carriers agree on ONE tree or will there be a wood of trees? But this is not a big issue if all con-federations have a basic rule: any participating carrier is obliged to enter only E.164 numbers he is serving. Then automatically not overlaps exist between the trees (expect carriers participating in more then one tree) and therefor the trees could be merged easily later. Back to the original question: > I think there's general > consensus that end users should not see core telco routing data. Normal end-users give a s**t anyway about technical details if making a call, so why should the be prevented to see core telco routing data. They real problem of telcos is to prevent OTHER TELCOS to see their data, primarily to see how many subscribers they really have ;-) They funny thing here is that competitors know these facts anyway, but it's nice to pretend to have secrets. Now we are at the basic problem: Is there a way to feed data into a database used by competitors to find out which numbers a given telco hosts without disclosing to the competitors which numbers this telco hosts? A cretan says: all cretans are liars. True or false? This is the problem we have to solve ;-) -richard > -----Original Message----- > From: Jim Reid [mailto:jim@rfc1035.com] > Sent: Tuesday, December 14, 2004 9:48 PM > To: Richard Shockey > Cc: Stastny Richard; Marco bernardi; Andrzej Bartosiewicz; > Carsten Schiefner; enum-wg(a)ripe.net > Subject: Re: AW: [enum-wg] COCOM & ENUM ... > > >>>>> "Richard" == Richard Shockey <richard(a)shockey.us> writes: > > Richard> HUH are you kidding ... its is because of the basic and > Richard> orthogonal conflict between what carriers need and want > Richard> and what end users need and want. > > I'm not convinced that really is (or will be) the case. Alice > is an end user with SIP applications that lookup E.164 > numbers in public e164.arpa tree to find SIP gateways. > Fast-forward a few years. Bob's a telco doing VoIP and SIP > and using DNS lookups of E.164 numbers to route calls in his > net and to other operators. What's the difference? > The applications are both using the DNS to figure out how to > find the right SIP server for some VoIP session (or > whatever). Carol sells SIP server and client software. Will > she want to develop, sell and support different versions of > the same thing to Alice and Bob? Meantime, what if Bob wants > to dump calls from his network to Alice on Alice's internet > SIP server so that he doesn't have to pay termination charges > to Alice's telco? > > Richard> Either bifurcate the tree at Tier one into two non > Richard> terminal NAPTR records (public & carrier)..which BTW will > Richard> break SIP applications since there is no standards any > Richard> where on how to deal with this. > > Maybe there should be a standard on this? :-) Though the > bifurcation could also be realised with split DNS. > > Richard> Two merge T1 and T2 into the national registry which > Richard> makes the registry operator the central repository for > Richard> ALL SIP routing data for both the carriers and end > Richard> users...which at least preserves the existing model of > Richard> the DNS responds with an "answer" ..the carriers can > Richard> still use non terminal records but normal SIP CUA's would > Richard> simply ignore them. > > This is too awful for words. I think there's general > consensus that end users should not see core telco routing data. > > Richard> Three have two entirely separate trees ..e164.arpa for > Richard> number holders e164.int for carriers. The .int tree > Richard> could be designed to look into apra for answers it is not > Richard> authoritative for. Problem solved. > > This gets very ugly very quickly IMO. Operationally such > setups would be very brittle and near-impossible to debug. > > Richard> oh no we're not going down that rat hole of split DNS > > It's no more of a rat hole than having yet another domain > name with funky forwarding/fallback on failure modes between > the 2 (or more?) domain names that you seem to favour. I > suspect these could be much, much worse to administer and > operate than a split DNS solution. It would be good to get > hard data on the pros and cons of both approaches. And any > others for that matter. Even better would be to get that data > before a lasting decision is made. :-) > > Richard> you forget the basic consumer or PBX edge ENUM resolver > Richard> has no need to see the carrier data. > > I've not forgotten that at all. I think you have > misunderstood me. Well, I have an accent.... :-) > > Suppose some company is writing ENUM-aware telephony software > that needs to figure out which SIP server to use when > terminating a call for some E.164 number. [Note the > deliberate hand-waving about where that software lives or > which net the device is on.] How many DNS lookups and domain > names is it going to need to do that? From a developer's > perspective, how will the software know which net it's in so > it knows which domain names to try (and in what order)? > > >> A centralised database could well mean telcos expose their > >> customer and call routing data to each other. Which is unlikely > >> to get much acceptance. > > Richard> Well then you have argued that LNP databases dont work > Richard> and I have it on good authority that they do :-) > > You would say that, wouldn't you? :-) > > Does a number portability database disclose to TelcoA how > TelcoB routes calls around its networK? >

2 1

Re: AW: [enum-wg] COCOM & ENUM ...
by Jim Reid 15 Dec '04

15 Dec '04

>>>>> "Richard" == Stastny Richard <Richard.Stastny(a)oefeg.at> writes: Richard> I fully agree and this is one of the problems I see by Richard> introducing carrier E**M via a backdoor in e164.arpa. If Richard> I am a carrier, especially a carrier acting on an Richard> international basis, I want to implement routing Richard> mechanisms within my network and with other networks Richard> (peers) without having to go to a NRA begging first to Richard> opt-in in e164.arpa and second to behave according to Richard> various and different national rules. Richard, these points are undoubtedly true. However they have nothing whatsoever to do with the choice of domain name for carrier ENUM. So far, nobody has presented any compelling reason why another domain name is needed for carrier ENUM. [Perhaps that discussion is going on behind closed doors at ETSI or somewhere like that.] Sure, carrier ENUM shouldn't be in the public e164.arpa tree. This doesn't stop an operator from creating their own private e164.arpa tree, populating that with whatever it likes and then making sure the applications on the operator's net queries the private tree rather than the public one. This setup is known as split DNS and is very common. Most large companies do this. What we see on the internet for bt.com (say) will be very different from what someone inside the BT network sees. What *is* important is that there's a single domain name and a single, consistent name space. Many of the applications and services -- eg VoIP and SIP -- that will be used by telcos will also be used on the public internet. Suppose I'm developing or selling and supporting some ENUM-aware SIP application. I don't want to have the complexity and expense of needing to configure it to do ENUM-like lookups in foobar.at if the box lives in Telekom Austria's net today or vf.enum.egpp.net if that's where Vodafone's chosen to anchor its carrier ENUM tree this week. And as for an ENUM-aware SIP client in a mobile phone that roams between operators... Or flips between 802.11 and GPRS nets... Richard> A carrier E**M implementation does not need a tier 0 and Richard> tier 1, and it is questionable if it needs a tier 2. It Richard> needs a centralisized database operated by someone, and Richard> who this is will be decided by the community as will be Richard> the other rules. The Tier-N jargon is probably inappropriate. However the roles might not be. And I'm not sure a centralised database for carrier ENUM is viable. It has obvious attractions: carriers sharing a common infrastructure for example. OTOH, it brings problems too. Figuring out who operates that infrastructure and how it gets paid for will be entertaining. A centralised database could well mean telcos expose their customer and call routing data to each other. Which is unlikely to get much acceptance.

3 5

Re: AW: [enum-wg] COCOM & ENUM ...
by Jim Reid 14 Dec '04

14 Dec '04

>>>>> "Richard" == Richard Shockey <richard(a)shockey.us> writes: >> Carrier-based ENUM is probably the easiest (maybe not the best) >> way to protect the privacy of customer data. Richard> Which BTW is why it is a good idea to keep it out of Richard> e164.arpa EH? The choice of domain name has no impact on whether that bit of the name space is public. Or private. It's all down to what data goes on what name servers and where those name servers are located (or accept queries from). Richard> ..maybe the carriers will go back to the ITU and get Richard> e164.int and we can end this issue once and for all. Hmm... How long do you think it would take ITU to set up processes and cost-recovery mechanisms for this? IIUC ITU has still not decided whether ENUM should be anchored in the public e164.arpa infrastructure or a new TLD owned and operated by ITU. According to IANA, it's the IANA registry that manages .int, not the ITU. BTW the DNS infrastructure for .int is nowhere near the levels of robustness and global presence that .arpa has.

3 3

Re: [enum-wg] COCOM & ENUM ...
by Stastny Richard 14 Dec '04

14 Dec '04

>BTW: Access to the production system is restricted to the TSPs with >officially assigned numering blocks by "Office of Telecommunications and Post >Regulation" in Poland. There is only one "minor" problem with the implementation in Poland: It is Carrier E**M in e164.arpa -richard ________________________________ Von: enum-wg-admin(a)ripe.net im Auftrag von Andrzej Bartosiewicz Gesendet: Sa 11.12.2004 16:55 An: Carsten Schiefner Cc: enum-wg(a)ripe.net Betreff: Re: [enum-wg] COCOM & ENUM ... Carsten, The answer is: Yes. We have switched over to production 6 months ago. You missed my presentation in Sophia Antipolis... :) Every TSP in Poland with assigned numbering block may sign the contract with NASK and start the registration of ENUM domain names in 8.4.e164.arpa (5 EURO/year). BTW: Access to the production system is restricted to the TSPs with officially assigned numering blocks by "Office of Telecommunications and Post Regulation" in Poland. We also have the "testing" system, so everybody (not only TSPs) can test the full functionality. The only difference is that we do not export domain names to zone file from the "testing" system. Andrzej. On Fri, 10 Dec 2004, Carsten Schiefner wrote: > Hi Andrzej, > > thanks for the link - on p. 4 it reads: "Production registry launch: May > 19, 2004". > > Did I completely miss a according announcement on all of my ENUM related > lists (and there are some! ;-) or did NASK switch over to production in > absolute silence? > > Best, > > -C. > >

4 3

Re: AW: [enum-wg] COCOM & ENUM ...
by Jim Reid 14 Dec '04

14 Dec '04

>>>>> "lwc" == Conroy, Lawrence (SMTP) <lwc(a)roke.co.uk> writes: lwc> Hi Jim, Richard, folks, I beg to differ with my esteemed lwc> colleague Jim. I would be very surprised if an end user's lwc> terminal queried carrier anything, and would be even more lwc> surprised if it received a response. This is akin to lwc> suggesting that if my phone fired off an INAP query it would lwc> receive a response. With SCTP it might be theoretically lwc> possible, but I don't expect anyone would be listening. This is undoubtedly true in the current telephony world. Something I remain in a state of blissful ignorance about. However the trend is towards smarter edge devices -- mobile phones that double as PDAs, video phones (over broadband?), soft phones on laptops with GPRS or 802.11 cards, etc. Going forward, there may well be a lot more interaction between edge devices and the core network. Maybe in 5-10 years my deal old mum will buy a shiny new "steam" phone that has a SIP client under the bonnet which talks to her telco provider's core net. lwc> In the "new wine in old skins" world of NGNs, the lwc> infrastructure might make queries as part of a routing lwc> process, and one service provider would almost certainly get lwc> a different answer from the one responsible for the target lwc> resource (i.e. the "destination" service provider will lwc> probably be running a split horizon system), but would my SIP lwc> phone get ANY such information? That would obviously depend on what net your SIP phone is connected to. Maybe we end up with a forest of e164.arpa trees, one on the internet and one internal to each operator? lwc> I sure hope that their infrastructure doesn't roam - the bean lwc> counters would not be happy. Well the core network had better not move about. Satellites excepted of course. :-)

1 0

AW: AW: [enum-wg] COCOM & ENUM ...
by Stastny Richard 14 Dec '04

14 Dec '04

Jim, I fully agree what you said about "private" (intranet) trees and that ONE public "silver" tree makes sense (and this is BTW also what ETSI is after) - but I just cannot believe that it will happen. At least not at the beginning, considering the mistrust between operators - maybe later when they have learned a lesson - and then it may be too late. I also agree with Lawrence in the other e-mail that an end-user device will never be able to query the carrier ENUM trees, and if then they will not be able to use the information they get, you just need to point to a border element requiring authentication. -richard ________________________________ Von: Jim Reid [mailto:jim@rfc1035.com] Gesendet: Di 14.12.2004 11:15 An: Stastny Richard Cc: Marco bernardi; Richard Shockey; Andrzej Bartosiewicz; Carsten Schiefner; enum-wg(a)ripe.net Betreff: Re: AW: [enum-wg] COCOM & ENUM ... >>>>> "Richard" == Stastny Richard <Richard.Stastny(a)oefeg.at> writes: Richard> I fully agree and this is one of the problems I see by Richard> introducing carrier E**M via a backdoor in e164.arpa. If Richard> I am a carrier, especially a carrier acting on an Richard> international basis, I want to implement routing Richard> mechanisms within my network and with other networks Richard> (peers) without having to go to a NRA begging first to Richard> opt-in in e164.arpa and second to behave according to Richard> various and different national rules. Richard, these points are undoubtedly true. However they have nothing whatsoever to do with the choice of domain name for carrier ENUM. So far, nobody has presented any compelling reason why another domain name is needed for carrier ENUM. [Perhaps that discussion is going on behind closed doors at ETSI or somewhere like that.] Sure, carrier ENUM shouldn't be in the public e164.arpa tree. This doesn't stop an operator from creating their own private e164.arpa tree, populating that with whatever it likes and then making sure the applications on the operator's net queries the private tree rather than the public one. This setup is known as split DNS and is very common. Most large companies do this. What we see on the internet for bt.com (say) will be very different from what someone inside the BT network sees. What *is* important is that there's a single domain name and a single, consistent name space. Many of the applications and services -- eg VoIP and SIP -- that will be used by telcos will also be used on the public internet. Suppose I'm developing or selling and supporting some ENUM-aware SIP application. I don't want to have the complexity and expense of needing to configure it to do ENUM-like lookups in foobar.at if the box lives in Telekom Austria's net today or vf.enum.egpp.net if that's where Vodafone's chosen to anchor its carrier ENUM tree this week. And as for an ENUM-aware SIP client in a mobile phone that roams between operators... Or flips between 802.11 and GPRS nets... Richard> A carrier E**M implementation does not need a tier 0 and Richard> tier 1, and it is questionable if it needs a tier 2. It Richard> needs a centralisized database operated by someone, and Richard> who this is will be decided by the community as will be Richard> the other rules. The Tier-N jargon is probably inappropriate. However the roles might not be. And I'm not sure a centralised database for carrier ENUM is viable. It has obvious attractions: carriers sharing a common infrastructure for example. OTOH, it brings problems too. Figuring out who operates that infrastructure and how it gets paid for will be entertaining. A centralised database could well mean telcos expose their customer and call routing data to each other. Which is unlikely to get much acceptance.

1 0

AW: [enum-wg] COCOM & ENUM ...
by Stastny Richard 14 Dec '04

14 Dec '04

I fully agree and this is one of the problems I see by introducing carrier E**M via a backdoor in e164.arpa. If I am a carrier, especially a carrier acting on an international basis, I want to implement routing mechanisms within my network and with other networks (peers) without having to go to a NRA begging first to opt-in in e164.arpa and second to behave according to various and different national rules. A carrier E**M implementation does not need a tier 0 and tier 1, and it is questionable if it needs a tier 2. It needs a centralisized database operated by someone, and who this is will be decided by the community as will be the other rules. This is exactly the reason why no silver tree will exist in the near future -richard ________________________________ Von: enum-wg-admin(a)ripe.net im Auftrag von Marco bernardi Gesendet: Mo 13.12.2004 08:38 An: Jim Reid; Stastny Richard; Richard Shockey Cc: Andrzej Bartosiewicz; Carsten Schiefner; enum-wg(a)ripe.net Betreff: Re: [enum-wg] COCOM & ENUM ... The probem I see is that COCOM should be not involved in any Carrier ENUM discussion. This may create some "dangerous" confusion on the role of EC and governments on carrier ENUM marco ----- Original Message ----- From: "Richard Shockey" <richard(a)shockey.us> To: "Jim Reid" <jim(a)rfc1035.com>; "Stastny Richard" <Richard.Stastny(a)oefeg.at> Cc: "Andrzej Bartosiewicz" <andrzejb(a)nask.pl>; "Carsten Schiefner" <enumvoipsip.cs(a)schiefner.de>; <enum-wg(a)ripe.net> Sent: Sunday, December 12, 2004 5:00 PM Subject: Re: [enum-wg] COCOM & ENUM ... > At 04:03 AM 12/12/2004, Jim Reid wrote: > > > >>>>> "Richard" == Stastny Richard <Richard.Stastny(a)oefeg.at> writes: > > > > Richard> There is only one "minor" problem with the implementation > > Richard> in Poland: It is Carrier E**M in e164.arpa > > > >And the problem is......? IMO the only potential problem with this is > >that private data could be made public through the DNS. > > exactly .. and BTW this is now the #1 topic of discussion within CC 1 > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >

1 0

Re: [enum-wg] COCOM & ENUM ...
by Jim Reid 13 Dec '04

13 Dec '04

>>>>> "Richard" == Richard Shockey <richard(a)shockey.us> writes: Richard> "I'm shocked shocked .. telecos do not want to enable Richard> VoIP or LNP! :-) " Other earth-shattering revelations: Investigators have proven the Pope is definitely a Catholic. Bears defecate in the woods. Elvis is dead. Though I'm not too sure about the last of these: it was announced on some web site.

1 0

Re: [enum-wg] WG: Telephone Number assined to IP telephony in Italy?
by Stastny Richard 13 Dec '04

13 Dec '04

Francesco Thank you very much for the quick response -richard ________________________________ Von: Francesco Bernabei [mailto:f.bernabei@agcom.it] Gesendet: Mo 13.12.2004 15:21 An: Stastny Richard; enum-wg(a)ripe.net; i.seki(a)hco.ntt.co.jp Betreff: Re: [enum-wg] WG: Telephone Number assined to IP telephony in Italy? Hi, The Italian numbering plan (in Italian) is contained in http://www.agcom.it/provv/d_09_03_CIR.htm. There in not any number range reserved for IP Telephony. The Italian NRA has established a group to study the VoIP issues and the work is going on. Best Regards Francesco Bernabei Autorità per le Garanzie nelle Comunicazioni Servizio per le Tecnologie Centro Direzionale, Isola B5 80143 Napoli Tel.: 081.7507.450 Fax.: 081.7507.621 e-mail: f.bernabei(a)agcom.it ----- Original Message ----- From: "Stastny Richard" <Richard.Stastny(a)oefeg.at> To: <enum-wg(a)ripe.net> Cc: <i.seki(a)hco.ntt.co.jp> Sent: Monday, December 13, 2004 1:15 PM Subject: [enum-wg] WG: Telephone Number assined to IP telephony in Italy? Hi folks, anybody out there who could help answer Ichiro's question? -richard ________________________________ Von: Ichiro SEKI [mailto:i.seki@hco.ntt.co.jp] Gesendet: Mo 13.12.2004 09:38 An: Stastny Richard Betreff: Telephone Number assined to IP telephony in Italy? Dear Mr.Stastny Richard, Hi. This is Ichiro SEKI of NTT from Tokyo, Japan. I hope you are doing fine. Today I am emailing you if you have any information about numbering scheme in Italy. I have heard that there are a sort of numbers that are(/will be) assigned to IP telephony there, but we do not have any information about it. (We found Italian Administration Home Page, but we could not find any definition of those numbers.) If time allows, would you please let us know if you have any information (or location(URL) of number, a person of contact, etc.) about the number. Thank you very much in advance, Ichiro SEKI, NTT i.seki(a)hco.ntt.co.jp

1 0

WG: Telephone Number assined to IP telephony in Italy?
by Stastny Richard 13 Dec '04

13 Dec '04

Hi folks, anybody out there who could help answer Ichiro's question? -richard ________________________________ Von: Ichiro SEKI [mailto:i.seki@hco.ntt.co.jp] Gesendet: Mo 13.12.2004 09:38 An: Stastny Richard Betreff: Telephone Number assined to IP telephony in Italy? Dear Mr.Stastny Richard, Hi. This is Ichiro SEKI of NTT from Tokyo, Japan. I hope you are doing fine. Today I am emailing you if you have any information about numbering scheme in Italy. I have heard that there are a sort of numbers that are(/will be) assigned to IP telephony there, but we do not have any information about it. (We found Italian Administration Home Page, but we could not find any definition of those numbers.) If time allows, would you please let us know if you have any information (or location(URL) of number, a person of contact, etc.) about the number. Thank you very much in advance, Ichiro SEKI, NTT i.seki(a)hco.ntt.co.jp

2 1

AW: [enum-wg] COCOM & ENUM ...
by Stastny Richard 13 Dec '04

13 Dec '04

>For example some of our ISP (and acting as ".pl" Registrars too) are >interested in ENUM domains registration (for VoIP services) but they MUST go >through TSPs. And telcos are not interested to start ENUM domains >registration... (they are also slowing down the NP implementation, so nobody >expects special interest in ENUM). Ha! This was exactly the reason why ETSI decided two years ago in ETSI TS 102 051 "ENUM Administration in Europe" that there should be an alternative way to get ENUM delegations if your TSP will not do it. The possibility to port your number to a TSP providing ENUM was NOT considered a proper alternative. One does not need to be a fortune teller to anticipate this problem ;-) -richard ________________________________ Von: Andrzej Bartosiewicz [mailto:andrzejb@nask.pl] Gesendet: Mo 13.12.2004 10:53 An: Richard Shockey Cc: Conroy, Lawrence (SMTP); Jim Reid; Stastny Richard; Carsten Schiefner; enum-wg(a)ripe.net Betreff: Re: [enum-wg] COCOM & ENUM ... Richard, > This IMHO will cause Poland a problem over time as ISP who want to sell > advanced services then realize they have to go through the incumbent to get > registrations processed. But this is as we all know is a national matter > and seeing how Poland deals with this will be very interesting to watch. Are you a fortune-teller? We already have this problem! For example some of our ISP (and acting as ".pl" Registrars too) are interested in ENUM domains registration (for VoIP services) but they MUST go through TSPs. And telcos are not interested to start ENUM domains registration... (they are also slowing down the NP implementation, so nobody expects special interest in ENUM). > Authentication is not hard if your country has independent databases that > can confirm the number holder. North America will not have that problem. We do not have the independent database in Poland. > Or they could use existing LNP databases ... ( ok that sounds really self > serving ) > > Note here 70% of US consumers who switch to Cable Based VoIP telephony > actually port their primary number. In Poland we have NP only in the Law (since July 2004), not in operation :( Andrzej.

3 3

Re: [enum-wg] COCOM & ENUM ...
by Stastny Richard 13 Dec '04

13 Dec '04

>IMO the only potential problem with this is >that private data could be made public through the DNS. He Jim, not again this one. This is exactly the reason why ENUM is end-user opt-in. BTW, in some countries there exists already a database (in this case opt-out) where even the names and addresses of telephone subscribers are stored - it is called the "public phone directory" Of course, because of the opt-in/opt-out feature you may not use these directories for call routing -richard ________________________________ Von: Jim Reid [mailto:jim@rfc1035.com] Gesendet: So 12.12.2004 10:03 An: Stastny Richard Cc: Andrzej Bartosiewicz; Carsten Schiefner; enum-wg(a)ripe.net Betreff: Re: [enum-wg] COCOM & ENUM ... >>>>> "Richard" == Stastny Richard <Richard.Stastny(a)oefeg.at> writes: Richard> There is only one "minor" problem with the implementation Richard> in Poland: It is Carrier E**M in e164.arpa And the problem is......? IMO the only potential problem with this is that private data could be made public through the DNS.

1 0

RE: [enum-wg] COCOM & ENUM ...
by Lothar Reith 13 Dec '04

13 Dec '04

Question to the friends in Poland - does "Access to the production system" mean read access or write access or both ? My question was related to my assumption and initial understanding, that all access was restricted to polish TSPs, like in a Carrier-E**M System my understanding is that ALL ACCESS is limited to participating Carriers. I would definitely question compliance to EU regulation if ALL ACCESS (incl. READ access) was limited to polish TSPs. To the further reaching question raised by Richard: no comment Lothar -----Ursprüngliche Nachricht----- Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Gesendet: Montag, 13. Dezember 2004 10:00 An: Reith, Lothar [HAHN:NGD:EXCH]; Andrzej Bartosiewicz; Carsten Schiefner Cc: enum-wg(a)ripe.net Betreff: RE: [enum-wg] COCOM & ENUM ... Good question. BTW: I ask myself the same question regarding the recent regulations in Germany that only providers in located in Germany may get numbers ;-) -richard _____ From: Lothar Reith [mailto:lothar.reith@nortelnetworks.com] Sent: Monday, December 13, 2004 9:55 AM To: Stastny Richard; 'Andrzej Bartosiewicz'; 'Carsten Schiefner' Cc: 'enum-wg(a)ripe.net' Subject: AW: [enum-wg] COCOM & ENUM ... A problem may be in the formulation: "Every TSP in Poland". Is that in compliance with EU regulations for fair cross-border competition ? Lothar -----Ursprüngliche Nachricht----- Von: enum-wg-admin(a)ripe.net [mailto:enum-wg-admin@ripe.net <mailto:enum-wg-admin@ripe.net> ] Gesendet: Samstag, 11. Dezember 2004 18:28 An: Andrzej Bartosiewicz; Carsten Schiefner Cc: enum-wg(a)ripe.net Betreff: Re: [enum-wg] COCOM & ENUM ... >BTW: Access to the production system is restricted to the TSPs with >officially assigned numering blocks by "Office of Telecommunications >and Post Regulation" in Poland. There is only one "minor" problem with the implementation in Poland: It is Carrier E**M in e164.arpa -richard ________________________________ Von: enum-wg-admin(a)ripe.net im Auftrag von Andrzej Bartosiewicz Gesendet: Sa 11.12.2004 16:55 An: Carsten Schiefner Cc: enum-wg(a)ripe.net Betreff: Re: [enum-wg] COCOM & ENUM ... Carsten, The answer is: Yes. We have switched over to production 6 months ago. You missed my presentation in Sophia Antipolis... :) Every TSP in Poland with assigned numbering block may sign the contract with NASK and start the registration of ENUM domain names in 8.4.e164.arpa (5 EURO/year). BTW: Access to the production system is restricted to the TSPs with officially assigned numering blocks by "Office of Telecommunications and Post Regulation" in Poland. We also have the "testing" system, so everybody (not only TSPs) can test the full functionality. The only difference is that we do not export domain names to zone file from the "testing" system. Andrzej. On Fri, 10 Dec 2004, Carsten Schiefner wrote: > Hi Andrzej, > > thanks for the link - on p. 4 it reads: "Production registry launch: > May 19, 2004". > > Did I completely miss a according announcement on all of my ENUM > related lists (and there are some! ;-) or did NASK switch over to > production in absolute silence? > > Best, > > -C. > >

2 1

AW: [enum-wg] COCOM & ENUM ...
by Lothar Reith 13 Dec '04

13 Dec '04

A problem may be in the formulation: "Every TSP in Poland". Is that in compliance with EU regulations for fair cross-border competition ? Lothar -----Ursprüngliche Nachricht----- Von: enum-wg-admin(a)ripe.net [mailto:enum-wg-admin@ripe.net] Gesendet: Samstag, 11. Dezember 2004 18:28 An: Andrzej Bartosiewicz; Carsten Schiefner Cc: enum-wg(a)ripe.net Betreff: Re: [enum-wg] COCOM & ENUM ... >BTW: Access to the production system is restricted to the TSPs with >officially assigned numering blocks by "Office of Telecommunications >and Post Regulation" in Poland. There is only one "minor" problem with the implementation in Poland: It is Carrier E**M in e164.arpa -richard ________________________________ Von: enum-wg-admin(a)ripe.net im Auftrag von Andrzej Bartosiewicz Gesendet: Sa 11.12.2004 16:55 An: Carsten Schiefner Cc: enum-wg(a)ripe.net Betreff: Re: [enum-wg] COCOM & ENUM ... Carsten, The answer is: Yes. We have switched over to production 6 months ago. You missed my presentation in Sophia Antipolis... :) Every TSP in Poland with assigned numbering block may sign the contract with NASK and start the registration of ENUM domain names in 8.4.e164.arpa (5 EURO/year). BTW: Access to the production system is restricted to the TSPs with officially assigned numering blocks by "Office of Telecommunications and Post Regulation" in Poland. We also have the "testing" system, so everybody (not only TSPs) can test the full functionality. The only difference is that we do not export domain names to zone file from the "testing" system. Andrzej. On Fri, 10 Dec 2004, Carsten Schiefner wrote: > Hi Andrzej, > > thanks for the link - on p. 4 it reads: "Production registry launch: > May 19, 2004". > > Did I completely miss a according announcement on all of my ENUM > related lists (and there are some! ;-) or did NASK switch over to > production in absolute silence? > > Best, > > -C. > >

2 1

RE: [enum-wg] COCOM & ENUM ...
by Stastny Richard 13 Dec '04

13 Dec '04

Good question. BTW: I ask myself the same question regarding the recent regulations in Germany that only providers in located in Germany may get numbers ;-) -richard ________________________________ From: Lothar Reith [mailto:lothar.reith@nortelnetworks.com] Sent: Monday, December 13, 2004 9:55 AM To: Stastny Richard; 'Andrzej Bartosiewicz'; 'Carsten Schiefner' Cc: 'enum-wg(a)ripe.net' Subject: AW: [enum-wg] COCOM & ENUM ... A problem may be in the formulation: "Every TSP in Poland". Is that in compliance with EU regulations for fair cross-border competition ? Lothar -----Ursprüngliche Nachricht----- Von: enum-wg-admin(a)ripe.net [mailto:enum-wg-admin@ripe.net] Gesendet: Samstag, 11. Dezember 2004 18:28 An: Andrzej Bartosiewicz; Carsten Schiefner Cc: enum-wg(a)ripe.net Betreff: Re: [enum-wg] COCOM & ENUM ... >BTW: Access to the production system is restricted to the TSPs with >officially assigned numering blocks by "Office of Telecommunications >and Post Regulation" in Poland. There is only one "minor" problem with the implementation in Poland: It is Carrier E**M in e164.arpa -richard ________________________________ Von: enum-wg-admin(a)ripe.net im Auftrag von Andrzej Bartosiewicz Gesendet: Sa 11.12.2004 16:55 An: Carsten Schiefner Cc: enum-wg(a)ripe.net Betreff: Re: [enum-wg] COCOM & ENUM ... Carsten, The answer is: Yes. We have switched over to production 6 months ago. You missed my presentation in Sophia Antipolis... :) Every TSP in Poland with assigned numbering block may sign the contract with NASK and start the registration of ENUM domain names in 8.4.e164.arpa (5 EURO/year). BTW: Access to the production system is restricted to the TSPs with officially assigned numering blocks by "Office of Telecommunications and Post Regulation" in Poland. We also have the "testing" system, so everybody (not only TSPs) can test the full functionality. The only difference is that we do not export domain names to zone file from the "testing" system. Andrzej. On Fri, 10 Dec 2004, Carsten Schiefner wrote: > Hi Andrzej, > > thanks for the link - on p. 4 it reads: "Production registry launch: > May 19, 2004". > > Did I completely miss a according announcement on all of my ENUM > related lists (and there are some! ;-) or did NASK switch over to > production in absolute silence? > > Best, > > -C. > >

1 0

Re: [enum-wg] COCOM & ENUM ...
by Jim Reid 13 Dec '04

13 Dec '04

>>>>> "Richard" == Stastny Richard <Richard.Stastny(a)oefeg.at> writes: Richard> There is only one "minor" problem with the implementation Richard> in Poland: It is Carrier E**M in e164.arpa And the problem is......? IMO the only potential problem with this is that private data could be made public through the DNS.

5 7