From enumvoipsip.cs at schiefner.de Fri Dec 10 20:38:40 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Fri, 10 Dec 2004 20:38:40 +0100 Subject: [enum-wg] COCOM & ENUM Message-ID: <41B9FB40.8000001@schiefner.de> All, Andrzej Bartosiewicz from NASK, the registry for .pl, mentioned the agenda of the upcoming COCOM meeting on 15 Dec that may be of some interest to you as also ENUM is on it. If you happen to have any further information what may be meant by "Presentations from Member States" - Just the staus quo? (Planned) regulatory framework? ...? - please feel free to share it. Best, Carsten From andrzejb at nask.pl Fri Dec 10 21:00:49 2004 From: andrzejb at nask.pl (Andrzej Bartosiewicz) Date: Fri, 10 Dec 2004 21:00:49 +0100 (CET) Subject: [enum-wg] COCOM & ENUM ... Message-ID: Carsten, I have been invited to have a presentation on the User ENUM deployment in Poland. After discussion with Peter Scott from DG Information Society, I have prepared the following presentation on "Current status of User ENUM deployment in Poland": www.bartosiewicz.pl/2004_12_14_COCOM_BARTOSIEWICZ.pdf Regards, Andrzej. From enumvoipsip.cs at schiefner.de Fri Dec 10 21:59:10 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Fri, 10 Dec 2004 21:59:10 +0100 Subject: [enum-wg] COCOM & ENUM ... In-Reply-To: References: Message-ID: <41BA0E1E.6020506@schiefner.de> Hi Andrzej, Andrzej Bartosiewicz wrote: > After discussion with Peter Scott from DG Information Society, I have > prepared the following presentation on "Current status of User ENUM > deployment in Poland": > www.bartosiewicz.pl/2004_12_14_COCOM_BARTOSIEWICZ.pdf 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. From Joakim.Stralmark at pts.se Sat Dec 11 14:54:47 2004 From: Joakim.Stralmark at pts.se (Joakim.Stralmark at pts.se) Date: Sat, 11 Dec 2004 14:54:47 +0100 Subject: SV: [enum-wg] COCOM & ENUM Message-ID: <1050E7CDAF4ED042BA2096CC187A79A71C7D5B@safir.pts.ad> Hello I shall do a presentation about the status of ENUM in Sweden and the next steps. Sincerely Joakim Str?lmark Swedish NRA -----Ursprungligt meddelande----- Fr?n: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] F?r Carsten Schiefner Skickat: den 10 december 2004 20:39 Till: enum-wg at ripe.net ?mne: [enum-wg] COCOM & ENUM All, Andrzej Bartosiewicz from NASK, the registry for .pl, mentioned the agenda of the upcoming COCOM meeting on 15 Dec that may be of some interest to you as also ENUM is on it. If you happen to have any further information what may be meant by "Presentations from Member States" - Just the staus quo? (Planned) regulatory framework? ...? - please feel free to share it. Best, Carsten From andrzejb at nask.pl Sat Dec 11 16:55:04 2004 From: andrzejb at nask.pl (Andrzej Bartosiewicz) Date: Sat, 11 Dec 2004 16:55:04 +0100 (CET) Subject: [enum-wg] COCOM & ENUM ... In-Reply-To: <41BA0E1E.6020506@schiefner.de> References: <41BA0E1E.6020506@schiefner.de> Message-ID: 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. > > From Richard.Stastny at oefeg.at Sat Dec 11 18:28:24 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Sat, 11 Dec 2004 18:28:24 +0100 Subject: [enum-wg] COCOM & ENUM ... Message-ID: <32755D354E6B65498C3BD9FD496C7D46FA5E@oefeg-s04.oefeg.loc> >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 at ripe.net im Auftrag von Andrzej Bartosiewicz Gesendet: Sa 11.12.2004 16:55 An: Carsten Schiefner Cc: enum-wg at 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. > > From jim at rfc1035.com Sun Dec 12 10:03:24 2004 From: jim at rfc1035.com (Jim Reid) Date: Sun, 12 Dec 2004 09:03:24 +0000 Subject: [enum-wg] COCOM & ENUM ... In-Reply-To: Message from "Stastny Richard" of "Sat, 11 Dec 2004 18:28:24 +0100." <32755D354E6B65498C3BD9FD496C7D46FA5E@oefeg-s04.oefeg.loc> Message-ID: <15464.1102842204@gromit.rfc1035.com> >>>>> "Richard" == Stastny Richard 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. From lwc at roke.co.uk Sun Dec 12 10:41:28 2004 From: lwc at roke.co.uk (Conroy, Lawrence (SMTP)) Date: Sun, 12 Dec 2004 09:41:28 +0000 Subject: [enum-wg] COCOM & ENUM ... In-Reply-To: <15464.1102842204@gromit.rfc1035.com> References: <15464.1102842204@gromit.rfc1035.com> Message-ID: Hi Jim, Richard, Andrzej, Carsten, Folks, Andrzej does have a production system up and running, which is a heck of a lot faster than some countries. It's a shame if an end user (you know, the person who pays for all these high quality services) can't choose their own ENUM entries. However, that's no change from the current situation, so maybe this is no big deal. Poland has also avoided the hoops over Authentication that have hypnotised other Countries. I am a little concerned that any TSP can register any number, but that's something for them to argue about amongst themselves. The only way we could have a more efficient system is to de-couple telephone number service provision from eligibility for registration entirely - say, if some named person or organisation had the delegation for a CC, and then chose their own policy on who got what. At least we would be saved from the endless discussions on industry self-regulation and policy advisory groups (plus their membership, whether or not they are representative, and the powers of the groups). At present, I can't officially register "my" ENUM in a production system. If someone else registers it (or a TSP registers it) I can't either. What's the difference (apart from years of fruitful discussion on the interpretation of the framework directives and whether they apply to a DNS system or IP addresses)? all the best, Lawrence On 12 Dec 2004, at 09:03, Jim Reid wrote: >>>>>> "Richard" == Stastny Richard 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. > From richard at shockey.us Sun Dec 12 18:00:50 2004 From: richard at shockey.us (Richard Shockey) Date: Sun, 12 Dec 2004 12:00:50 -0500 Subject: [enum-wg] COCOM & ENUM ... In-Reply-To: <15464.1102842204@gromit.rfc1035.com> References: <15464.1102842204@gromit.rfc1035.com> Message-ID: <6.2.0.14.2.20041212120000.053b4c40@sb7.songbird.com> At 04:03 AM 12/12/2004, Jim Reid wrote: > >>>>> "Richard" == Stastny Richard 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 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From richard at shockey.us Sun Dec 12 18:38:39 2004 From: richard at shockey.us (Richard Shockey) Date: Sun, 12 Dec 2004 12:38:39 -0500 Subject: [enum-wg] COCOM & ENUM ... In-Reply-To: References: <15464.1102842204@gromit.rfc1035.com> Message-ID: <6.2.0.14.2.20041212120306.053b0310@sb7.songbird.com> At 04:41 AM 12/12/2004, Conroy, Lawrence (SMTP) wrote: >Hi Jim, Richard, Andrzej, Carsten, Folks, > > Andrzej does have a production system up and running, which is a >heck of a lot faster than some countries. Its easy when you can start from scratch and have intelligent and sympathetic regulators. >It's a shame if an end user (you know, the person who pays for all these >high quality services) can't choose their own ENUM entries. However, that's >no change from the current situation, so maybe this is no big deal. 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. >Poland has also avoided the hoops over Authentication that have hypnotised >other Countries. I am a little concerned that any TSP can register any number, >but that's something for them to argue about amongst themselves. Authentication is not hard if your country has independent databases that can confirm the number holder. North America will not have that problem. >The only way we could have a more efficient system is to de-couple telephone >number service provision from eligibility for registration entirely - say, if >some named person or organisation had the delegation for a CC, and then chose >their own policy on who got what. Or make all the service providers all go back to the ITU and get e164.int so they can do their own thing and not bother the rest of us. Or they could use existing LNP databases ... ( ok that sounds really self serving ) Its my intention to have some sort of ID on Infrastructure TN2URI issues available shortly but I've been completely tied up here with US service providers who have begun to wake up to the fact that the lights they see in the distance really is a freight train. [news item below] Note here 70% of US consumers who switch to Cable Based VoIP telephony actually port their primary number. IFrom: "Bourkoff, Aryeh" To: "Bourkoff, Aryeh" Cc: X-OriginalArrivalTime: 09 Dec 2004 15:02:28.0767 (UTC) FILETIME=[19D062F0:01C4DE00] Sender: owner-ml-stm-Aryeh-Telecom-ext at sldn0846pmh.ldn.swissbank.com Precedence: bulk X-UBS-Disclaimer: Version $Revision: 1.26 $ X-IMAPbase: 1100136599 4982 Status: O X-UID: 4977 Content-Length: 80823 X-Keywords: Time Warner Cable: Takeaways - 32nd Annual UBS Global Media Week Conf * Time Warner Cable: Presentation at Media Week Today, Time Warner Cable Chairman & CEO Glenn Britt, presented at UBS' 32nd Annual Media Week Conference. * VoIP Rollout On Track, Anticipate 200K YE Subs VoIP has been launched in 30 of 31 systems & remains on track for YE04 full rollout, with est'd cap investment ~50% lower vs. circuit switched. Mgmt expects 200K YE subs, & is approaching 10K weekly adds. 75% of new phone customers are porting numbers, indicating a switch of primary lines. >At least we would be saved from the endless discussions on industry >self-regulation >and policy advisory groups (plus their membership, whether or not they are >representative, and the powers of the groups). > >At present, I can't officially register "my" ENUM in a production system. >If someone else registers it (or a TSP registers it) I can't either. >What's the >difference (apart from years of fruitful discussion on the interpretation >of the >framework directives and whether they apply to a DNS system or IP addresses)? > >all the best, > Lawrence > >On 12 Dec 2004, at 09:03, Jim Reid wrote: >>>>>>>"Richard" == Stastny Richard 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. > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Senior Manager, Strategic Technology Initiatives >NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com >ENUM +87810-13313-31331 >PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 >815.333.1237 > or > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From lothar.reith at nortelnetworks.com Mon Dec 13 09:55:18 2004 From: lothar.reith at nortelnetworks.com (Lothar Reith) Date: Mon, 13 Dec 2004 09:55:18 +0100 Subject: AW: [enum-wg] COCOM & ENUM ... Message-ID: <7D410981F5D6214FA120DD2CF6E7546201AF345B@zfrac103-int2.europe.nortel.com> 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 at ripe.net [mailto:enum-wg-admin at ripe.net] Gesendet: Samstag, 11. Dezember 2004 18:28 An: Andrzej Bartosiewicz; Carsten Schiefner Cc: enum-wg at 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 at ripe.net im Auftrag von Andrzej Bartosiewicz Gesendet: Sa 11.12.2004 16:55 An: Carsten Schiefner Cc: enum-wg at 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Richard.Stastny at oefeg.at Mon Dec 13 09:59:33 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Mon, 13 Dec 2004 09:59:33 +0100 Subject: [enum-wg] COCOM & ENUM ... Message-ID: <32755D354E6B65498C3BD9FD496C7D4601D771@oefeg-s04.oefeg.loc> 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 at nortelnetworks.com] Sent: Monday, December 13, 2004 9:55 AM To: Stastny Richard; 'Andrzej Bartosiewicz'; 'Carsten Schiefner' Cc: 'enum-wg at 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 at ripe.net [mailto:enum-wg-admin at ripe.net] Gesendet: Samstag, 11. Dezember 2004 18:28 An: Andrzej Bartosiewicz; Carsten Schiefner Cc: enum-wg at 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 at ripe.net im Auftrag von Andrzej Bartosiewicz Gesendet: Sa 11.12.2004 16:55 An: Carsten Schiefner Cc: enum-wg at 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrzejb at nask.pl Mon Dec 13 10:01:15 2004 From: andrzejb at nask.pl (Andrzej Bartosiewicz) Date: Mon, 13 Dec 2004 10:01:15 +0100 (CET) Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: <7D410981F5D6214FA120DD2CF6E7546201AF345B@zfrac103-int2.europe.nortel.com> References: <7D410981F5D6214FA120DD2CF6E7546201AF345B@zfrac103-int2.europe.nortel.com> Message-ID: Lothar, > A problem may be in the formulation: "Every TSP in Poland". > Is that in compliance with EU regulations for fair cross-border competition Better wording: "every TSP with numbering block in +48" Andrzej From lothar.reith at nortelnetworks.com Mon Dec 13 10:12:48 2004 From: lothar.reith at nortelnetworks.com (Lothar Reith) Date: Mon, 13 Dec 2004 10:12:48 +0100 Subject: [enum-wg] COCOM & ENUM ... Message-ID: <7D410981F5D6214FA120DD2CF6E7546201AF3480@zfrac103-int2.europe.nortel.com> 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 at oefeg.at] Gesendet: Montag, 13. Dezember 2004 10:00 An: Reith, Lothar [HAHN:NGD:EXCH]; Andrzej Bartosiewicz; Carsten Schiefner Cc: enum-wg at 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 at nortelnetworks.com] Sent: Monday, December 13, 2004 9:55 AM To: Stastny Richard; 'Andrzej Bartosiewicz'; 'Carsten Schiefner' Cc: 'enum-wg at 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 at ripe.net [mailto:enum-wg-admin at ripe.net ] Gesendet: Samstag, 11. Dezember 2004 18:28 An: Andrzej Bartosiewicz; Carsten Schiefner Cc: enum-wg at 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 at ripe.net im Auftrag von Andrzej Bartosiewicz Gesendet: Sa 11.12.2004 16:55 An: Carsten Schiefner Cc: enum-wg at 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrzejb at nask.pl Mon Dec 13 10:18:24 2004 From: andrzejb at nask.pl (Andrzej Bartosiewicz) Date: Mon, 13 Dec 2004 10:18:24 +0100 (CET) Subject: [enum-wg] COCOM & ENUM ... In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FA5E@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D46FA5E@oefeg-s04.oefeg.loc> Message-ID: It's not the Carrier ENUM. The entries are in the 8.4.e164.arpa tree in the _public_ DNS. Andrzej On Sat, 11 Dec 2004, Stastny Richard wrote: > >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 From andrzejb at nask.pl Mon Dec 13 10:29:44 2004 From: andrzejb at nask.pl (Andrzej Bartosiewicz) Date: Mon, 13 Dec 2004 10:29:44 +0100 (CET) Subject: [enum-wg] COCOM & ENUM ... In-Reply-To: References: <15464.1102842204@gromit.rfc1035.com> Message-ID: Conroy, > Poland has also avoided the hoops over Authentication that have > hypnotised > other Countries. I am a little concerned that any TSP can register any > number, > but that's something for them to argue about amongst themselves. Yes. TSP can register ANY number in 8.4.e164.arpa. We don't need to Authenticate requests from TSP because TSP can not (theoretically) register the number which doesn't belong to this TSP (from his numbering block or ported to him from another TSP). Our Regulator has declared that if there is a problem with "false" registrations, they have the legal power (Telecommunication Act) to force TSPs to use proper numbers. Andrzej. From andrzejb at nask.pl Mon Dec 13 10:53:52 2004 From: andrzejb at nask.pl (Andrzej Bartosiewicz) Date: Mon, 13 Dec 2004 10:53:52 +0100 (CET) Subject: [enum-wg] COCOM & ENUM ... In-Reply-To: <6.2.0.14.2.20041212120306.053b0310@sb7.songbird.com> References: <15464.1102842204@gromit.rfc1035.com> <6.2.0.14.2.20041212120306.053b0310@sb7.songbird.com> Message-ID: 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. From andrzejb at nask.pl Mon Dec 13 11:11:26 2004 From: andrzejb at nask.pl (Andrzej Bartosiewicz) Date: Mon, 13 Dec 2004 11:11:26 +0100 (CET) Subject: [enum-wg] COCOM & ENUM ... In-Reply-To: <7D410981F5D6214FA120DD2CF6E7546201AF3480@zfrac103-int2.europe.nortel.com> References: <7D410981F5D6214FA120DD2CF6E7546201AF3480@zfrac103-int2.europe.nortel.com> Message-ID: Lothar, > Question to the friends in Poland - does "Access to the production system" > mean read access or write access or both ? It's for sure "User ENUM", 8.4.e164.arpa. You can see, it's "public" DNS. Access to the ENUM Registry database (I have called this "production system") for ENUM domains registration/maintenance using EPP is ONLY for TSPs. End-user MUST go (unfortuanately) through his/her telco to register ENUM domain name under 8.4.e164.arpa to register ENUM domain. Andrzej. From Richard.Stastny at oefeg.at Mon Dec 13 11:17:15 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Mon, 13 Dec 2004 11:17:15 +0100 Subject: AW: [enum-wg] COCOM & ENUM ... Message-ID: <32755D354E6B65498C3BD9FD496C7D46FA5F@oefeg-s04.oefeg.loc> >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 at nask.pl] Gesendet: Mo 13.12.2004 10:53 An: Richard Shockey Cc: Conroy, Lawrence (SMTP); Jim Reid; Stastny Richard; Carsten Schiefner; enum-wg at 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. From Richard.Stastny at oefeg.at Mon Dec 13 11:23:46 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Mon, 13 Dec 2004 11:23:46 +0100 Subject: [enum-wg] COCOM & ENUM ... Message-ID: <32755D354E6B65498C3BD9FD496C7D46FA60@oefeg-s04.oefeg.loc> >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 at rfc1035.com] Gesendet: So 12.12.2004 10:03 An: Stastny Richard Cc: Andrzej Bartosiewicz; Carsten Schiefner; enum-wg at ripe.net Betreff: Re: [enum-wg] COCOM & ENUM ... >>>>> "Richard" == Stastny Richard 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. From andrzejb at nask.pl Mon Dec 13 11:37:30 2004 From: andrzejb at nask.pl (Andrzej Bartosiewicz) Date: Mon, 13 Dec 2004 11:37:30 +0100 (CET) Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FA5F@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D46FA5F@oefeg-s04.oefeg.loc> Message-ID: Richard, > 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. You are right. It's hard to say but we are in quite difficult situation with User ENUM in Poland, regardless of NASK's readiness for ENUM domains registration and Regulator consent to the solution. -End-user MUST go throug the telco to get the ENUM domain -Telco can reject the number porting request because of "lack of technical ability to port the number" (we have 24 million mobile and 14 million fix numbers and... not a single one has been ported) -Regulator is not willing to assign the numbering blocks for VoIP Andrzej. From lendl at nic.at Mon Dec 13 12:27:16 2004 From: lendl at nic.at (Otmar Lendl) Date: Mon, 13 Dec 2004 12:27:16 +0100 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: References: <32755D354E6B65498C3BD9FD496C7D46FA5F@oefeg-s04.oefeg.loc> Message-ID: <20041213112715.GA25215@nic.at> On 2004/12/13 11:12, Andrzej Bartosiewicz wrote: > Richard, > > > 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. > > You are right. > > It's hard to say but we are in quite difficult situation with User ENUM in > Poland, regardless of NASK's readiness for ENUM domains registration and > Regulator consent to the solution. > > -End-user MUST go throug the telco to get the ENUM domain _The_ telco, or just _any_ telco? For your previous mail, I got the impression than any telco can get (in the technical sense) the ENUM domain for any number. >From the policy point of view, it seems clear to me that any TSP is allowed to register the ENUM domain for any of his own numbers. But: Is TSP A allowed to register the ENUM domain of a number belonging to TSP B if the subscriber (= customer of TSP B) explicitly asks TSP A to do it? ----- Can you share a few statistics? Number of domains, number of TSPs who are actually registering domains, etc. ? Thanks, /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > From Richard.Stastny at oefeg.at Mon Dec 13 13:15:16 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Mon, 13 Dec 2004 13:15:16 +0100 Subject: [enum-wg] WG: Telephone Number assined to IP telephony in Italy? Message-ID: <32755D354E6B65498C3BD9FD496C7D46FA61@oefeg-s04.oefeg.loc> Hi folks, anybody out there who could help answer Ichiro's question? -richard ________________________________ Von: Ichiro SEKI [mailto:i.seki at 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 at hco.ntt.co.jp From andrzejb at nask.pl Mon Dec 13 13:19:04 2004 From: andrzejb at nask.pl (Andrzej Bartosiewicz) Date: Mon, 13 Dec 2004 13:19:04 +0100 (CET) Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: <20041213112715.GA25215@nic.at> References: <32755D354E6B65498C3BD9FD496C7D46FA5F@oefeg-s04.oefeg.loc> <20041213112715.GA25215@nic.at> Message-ID: > _The_ telco, or just _any_ telco? Any telco which is officially recognized by Regulator as Telco Operator according to Telecommunication Law. It means also that such a company has been assigned the numbering block. > For your previous mail, I got the impression than any telco can get > (in the technical sense) the ENUM domain for any number. Any telco (according to previous definition) can get any number and Regulator (not NASK as the Registry)has the legal power to react if problem occurs. > >From the policy point of view, it seems clear to me that any TSP is > allowed to register the ENUM domain for any of his own numbers. Yes. But we don't know which numbers belong to which TSP: -Telco can use the numbering block assigned directly by the Regulator (the numbering plan is available on-line: http://www.urtip.gov.pl/bip/a/tekst.jsp?place=bip_text_list&news_cat_id=122&news_id=70 -Telco A can use the numbers (blocks) belonging to Telco B (based on the contract between Telco A and Telco B; neither Regulator nor NASK know the details) -Number can be ported (in the near future) from Telco A to Telco B; it's currently under discussion: http://www.urtip.gov.pl/urtip/c/tekst.jsp?place=urtip=ln=sc=lewa&news_cat_id=66&news_id=745 > But: Is TSP A allowed to register the ENUM domain of a number belonging > to TSP B if the subscriber (= customer of TSP B) explicitly asks > TSP A to do it? No. TSP A is not allowed formally (it's against the Law) to register the ENUM domain of number belonging to TSP B, but technically it's possible - NASK doesn't verify this. Andrzej. From f.bernabei at agcom.it Mon Dec 13 15:21:01 2004 From: f.bernabei at agcom.it (Francesco Bernabei) Date: Mon, 13 Dec 2004 15:21:01 +0100 Subject: [enum-wg] WG: Telephone Number assined to IP telephony in Italy? References: <32755D354E6B65498C3BD9FD496C7D46FA61@oefeg-s04.oefeg.loc> Message-ID: <004c01c4e11f$1064be10$a10a10ac@portatile10> 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 at agcom.it ----- Original Message ----- From: "Stastny Richard" To: Cc: 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 at 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 at hco.ntt.co.jp From Richard.Stastny at oefeg.at Mon Dec 13 19:05:21 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Mon, 13 Dec 2004 19:05:21 +0100 Subject: [enum-wg] WG: Telephone Number assined to IP telephony in Italy? Message-ID: <32755D354E6B65498C3BD9FD496C7D46FA63@oefeg-s04.oefeg.loc> Francesco Thank you very much for the quick response -richard ________________________________ Von: Francesco Bernabei [mailto:f.bernabei at agcom.it] Gesendet: Mo 13.12.2004 15:21 An: Stastny Richard; enum-wg at ripe.net; i.seki at 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 at agcom.it ----- Original Message ----- From: "Stastny Richard" To: Cc: 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 at 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 at hco.ntt.co.jp From richard at shockey.us Mon Dec 13 22:05:47 2004 From: richard at shockey.us (Richard Shockey) Date: Mon, 13 Dec 2004 16:05:47 -0500 Subject: [enum-wg] COCOM & ENUM ... In-Reply-To: References: <15464.1102842204@gromit.rfc1035.com> <6.2.0.14.2.20041212120306.053b0310@sb7.songbird.com> Message-ID: <6.2.0.14.2.20041213160345.04ab78b0@sb7.songbird.com> At 04:53 AM 12/13/2004, Andrzej Bartosiewicz wrote: >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). another Capt. Louis Renault magic moment "I'm shocked shocked .. telecos do not want to enable VoIP or LNP! :-) " >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Mon Dec 13 23:18:18 2004 From: jim at rfc1035.com (Jim Reid) Date: Mon, 13 Dec 2004 22:18:18 +0000 Subject: [enum-wg] COCOM & ENUM ... In-Reply-To: Message from Richard Shockey of "Mon, 13 Dec 2004 16:05:47 EST." <6.2.0.14.2.20041213160345.04ab78b0@sb7.songbird.com> Message-ID: <17614.1102976298@gromit.rfc1035.com> >>>>> "Richard" == Richard Shockey 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. From enumvoipsip.cs at schiefner.de Fri Dec 10 20:49:07 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Fri, 10 Dec 2004 20:49:07 +0100 Subject: [enum-wg] COCOM & ENUM Message-ID: <41B9FDB3.6090006@schiefner.de> Sorry, I forgot to attach the agenda - here it is: EUROPEAN COMMISSIONDirectorate-General Information Society Communications ServicesImplementation/Committees Brussels, 1 December 2004 DG INFSO/B2 COCOM04-67 COMMUNICATIONS COMMITTEE 15th MEETING ? 15 DECEMBER 2004 AGENDA (1) Opening of the meeting and adoption of the agenda* COCOM04-67 (2) Minutes of the 14th COCOM meeting of 13 October 2004 COCOM04-66 Minutes of the extraordinary meeting of 28 September 2004 COCOM04-63REV1 (3) New regulatory framework : follow-up* (4) Notification requirements under the new framework* (5) Article 7 state of play* COCOM04-68 Commission paper (6) Transitional regime (Article 27 Framework Directive)* COCOM04-69 Commission paper (7) Draft Recommendation on cost accounting* COCOM04-70 Commission paper (8) ENUM* Presentations from Member States (9) Pan-European space for freephone services using 116 as access code* COCOM04-71 Commission paper (10) 10th Implementation Report* (11) Leased lines Report 2003* COCOM04-72 Commission paper (12) Subgroups* COCOM04-74 Commission paper (13) Any other business* MHP Implementation Group 112 questionnaire Commission response to the USTR/FCC report Recent case law Provisional schedule for 2005 COCOM04-73 (*) Agenda points with an asterisk are open to participation of all European associations listed in document COCOM02-24REV1 On Fri, Dec 10, 2004 at 08:38:40PM +0100, Carsten Schiefner wrote: > All, > > Andrzej Bartosiewicz from NASK, the registry for .pl, mentioned the > agenda of the upcoming COCOM meeting on 15 Dec that may be of some > interest to you as also ENUM is on it. > > If you happen to have any further information what may be meant by > "Presentations from Member States" - Just the staus quo? (Planned) > regulatory framework? ...? - please feel free to share it. > > Best, > > Carsten -------------- next part -------------- A non-text attachment was scrubbed... Name: COCOM04-67 Agenda 15th meeting.doc Type: application/msword Size: 99840 bytes Desc: not available URL: From horn at toplink.de Sun Dec 12 14:24:07 2004 From: horn at toplink.de (John-Erik Horn) Date: Sun, 12 Dec 2004 14:24:07 +0100 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FA5E@oefeg-s04.oefeg.loc> Message-ID: I wouldn't consider that to be a problem but a benefit. Just because the TSPs registerthe ENUM domains and administer the zone data, does not mean that will keep them from offering a front-end for users/customers. They will be forced to do that for reasons of rationality. Think of the workload if a TSP had a call center up and running just to get everybody's data into the DNS/ENUM-system. Carrier-based ENUM is probably the easiest (maybe not the best) way to protect the privacy of customer data. Greetings John-Erik Horn VoIP Project Manager toplink-plannet GmbH Sch?nfeldstra?e 8 76131 Karlsruhe Tel: +49-721-663-6450 Fax: +49-721-663-6199 > -----Urspr?ngliche Nachricht----- > Von: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] > Im Auftrag von Stastny Richard > Gesendet: Samstag, 11. Dezember 2004 18:28 > An: Andrzej Bartosiewicz; Carsten Schiefner > Cc: enum-wg at 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 at ripe.net im Auftrag von Andrzej Bartosiewicz > Gesendet: Sa 11.12.2004 16:55 > An: Carsten Schiefner > Cc: enum-wg at 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. > > > > > > > From marco.bernardi at neustar.biz Mon Dec 13 08:38:30 2004 From: marco.bernardi at neustar.biz (Marco bernardi) Date: Mon, 13 Dec 2004 07:38:30 -0000 Subject: [enum-wg] COCOM & ENUM ... References: <15464.1102842204@gromit.rfc1035.com> <6.2.0.14.2.20041212120000.053b4c40@sb7.songbird.com> Message-ID: <003101c4e0e6$bf230620$79cb7ad5@cis.neustar.com> 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" To: "Jim Reid" ; "Stastny Richard" Cc: "Andrzej Bartosiewicz" ; "Carsten Schiefner" ; 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 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 at fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > From Richard.Stastny at oefeg.at Tue Dec 14 10:08:23 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Tue, 14 Dec 2004 10:08:23 +0100 Subject: AW: [enum-wg] COCOM & ENUM ... Message-ID: <32755D354E6B65498C3BD9FD496C7D46FA65@oefeg-s04.oefeg.loc> 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 at 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 at 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" To: "Jim Reid" ; "Stastny Richard" Cc: "Andrzej Bartosiewicz" ; "Carsten Schiefner" ; 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 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 at fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > From jim at rfc1035.com Tue Dec 14 11:15:03 2004 From: jim at rfc1035.com (Jim Reid) Date: Tue, 14 Dec 2004 10:15:03 +0000 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: Message from "Stastny Richard" of "Tue, 14 Dec 2004 10:08:23 +0100." <32755D354E6B65498C3BD9FD496C7D46FA65@oefeg-s04.oefeg.loc> Message-ID: <18665.1103019303@gromit.rfc1035.com> >>>>> "Richard" == Stastny Richard 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. From lwc at roke.co.uk Tue Dec 14 11:40:34 2004 From: lwc at roke.co.uk (Conroy, Lawrence (SMTP)) Date: Tue, 14 Dec 2004 10:40:34 +0000 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: <18665.1103019303@gromit.rfc1035.com> References: <18665.1103019303@gromit.rfc1035.com> Message-ID: <95BF1958-4DBC-11D9-AF3A-000393A70BB2@roke.co.uk> Hi Jim, Richard, folks, I beg to differ with my esteemed colleague Jim. I would be very surprised if an end user's terminal queried carrier anything, and would be even more surprised if it received a response. This is akin to suggesting that if my phone fired off an INAP query it would receive a response. With SCTP it might be theoretically possible, but I don't expect anyone would be listening. In the "new wine in old skins" world of NGNs, the infrastructure might make queries as part of a routing process, and one service provider would almost certainly get a different answer from the one responsible for the target resource (i.e. the "destination" service provider will probably be running a split horizon system), but would my SIP phone get ANY such information? Private and Public are the wrong terms - if service providers share some information to facilitate routing of communications sessions, this does not make that information public (e.g. available to anyone anywhere on the Internet). It's shared between carriers. I sure hope that their infrastructure doesn't roam - the bean counters would not be happy. all the best, Lawrence On 14 Dec 2004, at 10:15, Jim Reid wrote: >>>>>> "Richard" == Stastny Richard 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. > From Richard.Stastny at oefeg.at Tue Dec 14 12:33:44 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Tue, 14 Dec 2004 12:33:44 +0100 Subject: AW: AW: [enum-wg] COCOM & ENUM ... Message-ID: <32755D354E6B65498C3BD9FD496C7D46FA67@oefeg-s04.oefeg.loc> 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 at rfc1035.com] Gesendet: Di 14.12.2004 11:15 An: Stastny Richard Cc: Marco bernardi; Richard Shockey; Andrzej Bartosiewicz; Carsten Schiefner; enum-wg at ripe.net Betreff: Re: AW: [enum-wg] COCOM & ENUM ... >>>>> "Richard" == Stastny Richard 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. From jim at rfc1035.com Tue Dec 14 15:22:45 2004 From: jim at rfc1035.com (Jim Reid) Date: Tue, 14 Dec 2004 14:22:45 +0000 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: Message from "Conroy, Lawrence (SMTP)" of "Tue, 14 Dec 2004 10:40:34 GMT." <95BF1958-4DBC-11D9-AF3A-000393A70BB2@roke.co.uk> Message-ID: <19009.1103034165@gromit.rfc1035.com> >>>>> "lwc" == Conroy, Lawrence (SMTP) 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. :-) From richard at shockey.us Tue Dec 14 19:31:21 2004 From: richard at shockey.us (Richard Shockey) Date: Tue, 14 Dec 2004 13:31:21 -0500 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: References: <32755D354E6B65498C3BD9FD496C7D46FA5E@oefeg-s04.oefeg.loc> Message-ID: <6.2.0.14.2.20041214133009.05205eb0@sb7.songbird.com> At 08:24 AM 12/12/2004, John-Erik Horn wrote: >I wouldn't consider that to be a problem >but a benefit. Just because the TSPs registerthe ENUM domains and >administer the zone data, does not mean that will keep them from >offering a front-end for users/customers. They will be forced to >do that for reasons of rationality. Think of the workload if a TSP had >a call center up and running just to get everybody's data into the >DNS/ENUM-system. > >Carrier-based ENUM is probably the easiest (maybe not the best) >way to protect the privacy of customer data. Which BTW is why it is a good idea to keep it out of e164.arpa Now since our ICANN folks have just approved .MOBI ..maybe the carriers will go back to the ITU and get e164.int and we can end this issue once and for all. >Greetings > >John-Erik Horn >VoIP Project Manager >toplink-plannet GmbH >Sch?nfeldstra?e 8 >76131 Karlsruhe >Tel: +49-721-663-6450 >Fax: +49-721-663-6199 > > -----Urspr?ngliche Nachricht----- > > Von: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] > > Im Auftrag von Stastny Richard > > Gesendet: Samstag, 11. Dezember 2004 18:28 > > An: Andrzej Bartosiewicz; Carsten Schiefner > > Cc: enum-wg at 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 at ripe.net im Auftrag von Andrzej Bartosiewicz > > Gesendet: Sa 11.12.2004 16:55 > > An: Carsten Schiefner > > Cc: enum-wg at 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. > > > > > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From richard at shockey.us Tue Dec 14 19:48:05 2004 From: richard at shockey.us (Richard Shockey) Date: Tue, 14 Dec 2004 13:48:05 -0500 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: <18665.1103019303@gromit.rfc1035.com> References: <18665.1103019303@gromit.rfc1035.com> Message-ID: <6.2.0.14.2.20041214133240.05204370@sb7.songbird.com> At 05:15 AM 12/14/2004, Jim Reid wrote: > >>>>> "Richard" == Stastny Richard 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. HUH are you kidding ... its is because of the basic and orthogonal conflict between what carriers need and want and what end users need and want. The problem is administrative how do two occasionally diametrically opposed entities share a single name space. I perfectly understand the technical dilemma service providers have but if you look a what it will take to actually implement such a policy you are left with 3 basic options. Either bifurcate the tree at Tier one into two non terminal NAPTR records (public & carrier)..which BTW will break SIP applications since there is no standards any where on how to deal with this. Two merge T1 and T2 into the national registry which makes the registry operator the central repository for ALL SIP routing data for both the carriers and end users...which at least preserves the existing model of the DNS responds with an "answer" ..the carriers can still use non terminal records but normal SIP CUA's would simply ignore them. Three have two entirely separate trees ..e164.arpa for number holders e164.int for carriers. The .int tree could be designed to look into apra for answers it is not authoritative for. Problem solved. >[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. oh no we're not going down that rat hole of split DNS >What *is* important is that there's a single domain name and a single, >consistent name space. I dont agree the applications are sufficiently orthogonal enough to argue that the administrative policies and procedures are different enough to justify two separated trees. > 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... you forget the basic consumer or PBX edge ENUM resolver has no need to see the carrier data. > 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. Oh that is real simple ... the carrier of record of the TN will immediately know how to fund and manage that namesapce for their respective portions of the .int tree for instance or they will use totall out of band methods of exchanging TN to URI data like LNP data bases that push the data into carrier networks. And BTW most all the carriers I talk to these days want the data presented to them via SIP redirect/location servers not DNS. >A centralised database could well mean telcos expose >their customer and call routing data to each other. Which is unlikely >to get much acceptance. Well then you have argued that LNP databases dont work and I have it on good authority that they do :-) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From jim at rfc1035.com Tue Dec 14 20:57:08 2004 From: jim at rfc1035.com (Jim Reid) Date: Tue, 14 Dec 2004 19:57:08 +0000 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: Message from Richard Shockey of "Tue, 14 Dec 2004 13:31:21 EST." <6.2.0.14.2.20041214133009.05205eb0@sb7.songbird.com> Message-ID: <19337.1103054228@gromit.rfc1035.com> >>>>> "Richard" == Richard Shockey 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. From richard at shockey.us Tue Dec 14 21:26:44 2004 From: richard at shockey.us (Richard Shockey) Date: Tue, 14 Dec 2004 15:26:44 -0500 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: <19337.1103054228@gromit.rfc1035.com> References: <19337.1103054228@gromit.rfc1035.com> Message-ID: <6.2.0.14.2.20041214150847.053bd500@sb7.songbird.com> At 02:57 PM 12/14/2004, Jim Reid wrote: > >>>>> "Richard" == Richard Shockey 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). Yes but that is not the issue here ..none of this is about the DNS. This all about policies and procedures of who can write authoritative records that represent mappings from TN's to URI's and why. Its all political not technical but we've known that from the beginning. Its just now carriers have switched to caffinated coffee and realized VoIP is no toy but a real and direct threat to their revenue steams and more importantly its important to their customers. 1/2 of all PBX's sold in North America were VoIP enabled. The must act or their land line businesses will be rendered useless. How many times has Skype been downloaded? Again I'm very sympathetic to the problem and would like to help design solutions for carriers that address their needs but at the same time I dont want the fundamental technical architecture of 3761 to be corrupted by requirements that place the square pegs of carrier network needs in the round holes of e164.arpa. > 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. Well the arpa issue as far as I can see is essentially over. No one in North America aka CC1 is going to countence to ITU control here unless they want to do something seperately for the carriers. and how long would it take to set something up ... Oh the ITU is definitely looking for work these days and I'm constantly amazed at the speed the ITU will act if ..if they set their minds to something. If the ITU proposed setting up e164.int for global service provider needs I'd be the first to support the proposition. >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. That too can be fixed .. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From john+ietf at jck.com Tue Dec 14 21:33:20 2004 From: john+ietf at jck.com (John C Klensin) Date: Tue, 14 Dec 2004 15:33:20 -0500 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: <19337.1103054228@gromit.rfc1035.com> References: <19337.1103054228@gromit.rfc1035.com> Message-ID: --On Tuesday, 14 December, 2004 19:57 +0000 Jim Reid wrote: > 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. Richard, independent of any other issues, e164.int would violate the narrow reading of "international organization" that ITU itself has been advocating for .INT. Whatever "e164" might be, it is not an international organization under that, or any sensible other, definition. > 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. Assuming ITU could get such a new TLD, which raises a whole group of additional questions. To summarize them, don't hold your breath. > 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. It is perhaps not an accident that .ARPA was chosen ;-/ john (one of the guilty parties) From jim at rfc1035.com Tue Dec 14 21:48:14 2004 From: jim at rfc1035.com (Jim Reid) Date: Tue, 14 Dec 2004 20:48:14 +0000 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: Your message of "Tue, 14 Dec 2004 13:48:05 EST." <6.2.0.14.2.20041214133240.05204370@sb7.songbird.com> Message-ID: <19417.1103057294@gromit.rfc1035.com> >>>>> "Richard" == Richard Shockey 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? From richard at shockey.us Tue Dec 14 22:24:27 2004 From: richard at shockey.us (Richard Shockey) Date: Tue, 14 Dec 2004 16:24:27 -0500 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: References: <19337.1103054228@gromit.rfc1035.com> Message-ID: <6.2.0.14.2.20041214161528.056d3bd0@sb7.songbird.com> At 03:33 PM 12/14/2004, John C Klensin wrote: >--On Tuesday, 14 December, 2004 19:57 +0000 Jim Reid > wrote: > > > 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. > >Richard, independent of any other issues, e164.int would violate >the narrow reading of "international organization" that ITU >itself has been advocating for .INT. Whatever "e164" might be, >it is not an international organization under that, or any >sensible other, definition. Fair enough John .. but you understand the basic problem here. The pressure to force the architecture of 3761 into doing things it was not generally intended to do is creating yet another barrier to adoption. At the request of the AD's I'm working on a draft right now that is trying to at least scope the problem and I'd be personally delighted if you'd take a look at it and add your thoughts and or comments. You certainly have a unique insight into the historical problem statement. > > 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. > >Assuming ITU could get such a new TLD, which raises a whole >group of additional questions. To summarize them, don't hold >your breath. I wont I'm hoping to live a bit longer . :-) I'm just thrashing around looking for a solution that meets the carrier requirements but at the same time does not break SIP behavior or 3761. > > 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. > >It is perhaps not an accident that .ARPA was chosen ;-/ > > john (one of the guilty parties) yes indeed ...present at the creation so to speak .. :-) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From richard at shockey.us Tue Dec 14 22:59:20 2004 From: richard at shockey.us (Richard Shockey) Date: Tue, 14 Dec 2004 16:59:20 -0500 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: <19417.1103057294@gromit.rfc1035.com> References: <19417.1103057294@gromit.rfc1035.com> Message-ID: <6.2.0.14.2.20041214162449.056d5d30@sb7.songbird.com> At 03:48 PM 12/14/2004, Jim Reid wrote: > >>>>> "Richard" == Richard Shockey 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? a great deal .. network operators do not generally or historically expose internal network architectures or border ingress elements into something as public as the DNS. the general requirement I have been constantly told is that the result of the carrier TN2URI translation must not be publicly exposed or amenable to MiM attack and is generally hidden behind some AA which is why all the discussion on non terminal NAPTR records. >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? Of course not that is why the carrier record would be non terminal and require out AA in fact most of the architectures I see nearly have only 1 URI for the entire network. A huge wall of SBC's surrounding the VoIP network. >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. I do not agree on either point. SIP CUA's would all have to be redesigned to accept the new DNS structure ..I dont think that is acceptable. > 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. not if the URI is non terminal it only increases the requirements on the registry. The Tier 1 Tier 2 constructs were artificial in the first place to more balance the loads on the DNS and give end user more flexible options on controlling their NAPTR records. > 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. what are you talking about ..it would work perfectly well. End user CUA's do not need to see carrier data so they would never look into carrier.foo but John is entirely right here the chances of carrier.foo getting off the ground are problematic though .MOBI did get through ICANN for some reason. > 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? only one ..if the software is edge based in the case of IP-PBX's or end user devices, two if the proxy is licensed carrier based ( aka they issue phone numbers ) the definition of a carrier here is do you or do you not issue phone numbers..if you do not you will not have access to the carrier data and BTW that will not guarantee that the network provider will even give you access to the network .. the two carriers will have presumed to have a bi-lateral agreement in place covering inter network transactions. > 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? no only the destination endpoint or LRN in the case of the US and Canada. The carrier TN2URI scheme would not expose internal network archichecture either under the current designs I've seen ..only the location of the network Session Border Element or Controller. The terminating carrier network would still need to look up into its own routing tables ..and this is where I see SIP redirect all over the place..to find the actual end point routing data. There is no doubt in my mind BTW that SIP redirect servers are being used to replicate the functionality of Service Control Points (SCP's) in the IN and that SIP is becoming the new NGN equivalent of TCAP. But even exposing the LRN does permit the originating carrier to deduce a great deal about the called party network provider...in the first case you know the number has been ported and from the LRN tables you can find out who that carrier is. In the US and Canada LIDB will give you everything else you want to know about the customer. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From lwc at roke.co.uk Wed Dec 15 01:55:35 2004 From: lwc at roke.co.uk (Conroy, Lawrence (SMTP)) Date: Wed, 15 Dec 2004 00:55:35 +0000 Subject: AW: [enum-wg] COCOM & ENUM ... In-Reply-To: <6.2.0.14.2.20041214162449.056d5d30@sb7.songbird.com> References: <19417.1103057294@gromit.rfc1035.com> <6.2.0.14.2.20041214162449.056d5d30@sb7.songbird.com> Message-ID: <079E85EC-4E34-11D9-A9E9-000393A70BB2@roke.co.uk> Hi Richard, Jim, folks, OK - now I'm unhappy. I think Jim raises the point that the distinction between a carrier and an end user is going to get blurred. True and an interesting nugget, but... (i) The developer doesn't have to do anything they aren't doing already. If anyone makes an ENUM client with a hard coded #define for e164.arpa then they are dumb - everyone needs to debug the stuff as it isn't all in place yet (at least in other parts of the world :). Hence pretty much every client has some way of selecting the apex, and often the DNS server that it will query. Thus this argument is puff (and I suspect that everyone here knows it is :( (ii) Every carrier (and maybe even end users if we don't get our act together) is going to have to select the servers they query and the net address from which they will accept a request and return data - true whether its a split or they just accept queries only from "anointed" network addresses. There *is* going to be carrier configuration of the servers *AND* clients in the same way that there is now (if only to set the resolver to set/send EDNS0 queries). Thus the idea that one size fits all is just not going to play with any Ops guys in any carrier (at least I hope not any who provide ME with service). In short, a developer that doesn't allow change to the apex is even less proficient than I am at programming, and that's saying something. Similarly, each carrier is going to do configuration in any real situation; NGNs don't work out of the box [of course, this is not an official position of any vendor, but... ] Richard has managed to confuse me over the term "non-terminal NAPTR". (iii) This use of the term "non-terminal NAPTRs" is starting to grate. I suspect that the mail below doesn't talk about non-terminal NAPTRs (according to RFC3403) but instead implies a link to some kind of Service Resolution Service is triggered, or else I need the AA side of this explained in a lot more detail. If this *is* the [names deleted to protect the alleged perpetrators] idea of using non-terminals at T1/T0 then I stand corrected, but I may well be sick. Please don't use the term Non-Terminal NAPTR (i.e. one with an empty flags field) if you don't mean such a construct. 'u' with E2U+sip or sip+E2U is a kosher terminal NAPTR. If the result of sending an INVITE to the server mentioned in the URI isn't the end of the story, that's a purely non-ENUM problem - blame the cult, but not the ENUM design - 340x and 3761 are at least crystal clear on this topic. Forgive the rant, but I believe that there's nothing in the experiences draft that won't be applicable for *any* flavour of ENUM, and do not want to change it to say that non-terminal NAPTRs are nice friendly creatures that we should all grow to know and love after all. If you feel that this is necessary, I'll let you explain it in detail (just give me due warning so I can duck :) all the best, Lawrence On 14 Dec 2004, at 21:59, Richard Shockey wrote: > At 03:48 PM 12/14/2004, Jim Reid wrote: >> >>>>> "Richard" == Richard Shockey 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? > > a great deal .. network operators do not generally or historically > expose internal network architectures or border ingress elements into > something as public as the DNS. > > the general requirement I have been constantly told is that the result > of the carrier TN2URI translation must not be publicly exposed or > amenable to MiM attack and is generally hidden behind some AA which > is why all the discussion on non terminal NAPTR records. > >> 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? > > Of course not that is why the carrier record would be non terminal and > require out AA in fact most of the architectures I see nearly have > only 1 URI for the entire network. A huge wall of SBC's surrounding > the VoIP network. > >> 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. > > I do not agree on either point. SIP CUA's would all have to be > redesigned to accept the new DNS structure ..I dont think that is > acceptable. > > >> 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. > > not if the URI is non terminal it only increases the requirements on > the registry. The Tier 1 Tier 2 constructs were artificial in the > first place to more balance the loads on the DNS and give end user > more flexible options on controlling their NAPTR records. > > >> 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. > > what are you talking about ..it would work perfectly well. End user > CUA's do not need to see carrier data so they would never look into > carrier.foo > > but John is entirely right here the chances of carrier.foo getting off > the ground are problematic though .MOBI did get through ICANN for some > reason. > > >> 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? > > only one ..if the software is edge based in the case of IP-PBX's or > end user devices, two if the proxy is licensed carrier based ( aka > they issue phone numbers ) > > the definition of a carrier here is do you or do you not issue phone > numbers..if you do not you will not have access to the carrier data > and BTW that will not guarantee that the network provider will even > give you access to the network .. the two carriers will have presumed > to have a bi-lateral agreement in place covering inter network > transactions. > >> 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? > > no only the destination endpoint or LRN in the case of the US and > Canada. The carrier TN2URI scheme would not expose internal network > archichecture either under the current designs I've seen ..only the > location of the network Session Border Element or Controller. The > terminating carrier network would still need to look up into its own > routing tables ..and this is where I see SIP redirect all over the > place..to find the actual end point routing data. > > There is no doubt in my mind BTW that SIP redirect servers are being > used to replicate the functionality of Service Control Points (SCP's) > in the IN and that SIP is becoming the new NGN equivalent of TCAP. > > But even exposing the LRN does permit the originating carrier to > deduce a great deal about the called party network provider...in the > first case you know the number has been ported and from the LRN tables > you can find out who that carrier is. In the US and Canada LIDB will > give you everything else you want to know about the customer. > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 > 815.333.1237 > or > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > From Richard.Stastny at oefeg.at Wed Dec 15 10:19:10 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Wed, 15 Dec 2004 10:19:10 +0100 Subject: : [enum-wg] COCOM & ENUM ... Message-ID: <32755D354E6B65498C3BD9FD496C7D4601D772@oefeg-s04.oefeg.loc> 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 at 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 at rfc1035.com] > Sent: Tuesday, December 14, 2004 9:48 PM > To: Richard Shockey > Cc: Stastny Richard; Marco bernardi; Andrzej Bartosiewicz; > Carsten Schiefner; enum-wg at ripe.net > Subject: Re: AW: [enum-wg] COCOM & ENUM ... > > >>>>> "Richard" == Richard Shockey 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? > From Richard.Stastny at oefeg.at Wed Dec 15 12:30:54 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Wed, 15 Dec 2004 12:30:54 +0100 Subject: : [enum-wg] COCOM & ENUM ... Message-ID: <32755D354E6B65498C3BD9FD496C7D4601D774@oefeg-s04.oefeg.loc> 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" > To: "Jim Reid" ; "Richard Shockey" > > Cc: "Marco bernardi" ; "Andrzej > Bartosiewicz" > ; "Carsten Schiefner" > ; > 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 at 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 > > > > From marco.bernardi at neustar.biz Wed Dec 15 12:06:52 2004 From: marco.bernardi at neustar.biz (Marco bernardi) Date: Wed, 15 Dec 2004 11:06:52 -0000 Subject: : [enum-wg] COCOM & ENUM ... References: <32755D354E6B65498C3BD9FD496C7D4601D772@oefeg-s04.oefeg.loc> Message-ID: <000801c4e296$304e8300$605f7ad5@cis.neustar.com> Richard, 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. 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? marco ----- Original Message ----- From: "Stastny Richard" To: "Jim Reid" ; "Richard Shockey" Cc: "Marco bernardi" ; "Andrzej Bartosiewicz" ; "Carsten Schiefner" ; 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 at 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 From niall.oreilly at ucd.ie Tue Dec 21 10:58:24 2004 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Tue, 21 Dec 2004 09:58:24 +0000 Subject: [enum-wg] ENUM Status for Ireland (+353) Message-ID: -----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----- From k13 at nikhef.nl Tue Dec 21 14:44:13 2004 From: k13 at nikhef.nl (Rob Blokzijl) Date: Tue, 21 Dec 2004 14:44:13 +0100 (MET) Subject: [enum-wg] Announcement: Policy Development Process in RIPE Message-ID: 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 at ripe.net - if you are not subscribed to ripe-list at ripe.net yet, go to http://www.ripe.net/mailman/listinfo/ripe-list#subscribers - for any questions, don't hesitate to contact chair at ripe.net As always, apologies for receiving multiple copies of this announcement. Best regards, Rob Blokzijl RIPE Chairman From randy at psg.com Tue Dec 21 18:05:57 2004 From: randy at psg.com (Randy Bush) Date: Tue, 21 Dec 2004 12:05:57 -0500 Subject: [enum-wg] Re: [eix-wg] Announcement: Policy Development Process in RIPE References: Message-ID: <16840.22517.647024.632059@roam.psg.com> > later today I will publish a draft document that describes the policy > making process in RIPE. this is the product of the small working group on the subject? randy