- enum-wg - mailman.ripe.net

Kim's document
by Andrzej Bartosiewicz 21 Jan '05

21 Jan '05

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

2 2

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

21 Dec '04

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

2 1

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

21 Dec '04

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

1 0

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

15 Dec '04

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

1 0

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

15 Dec '04

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

2 1

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

15 Dec '04

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

3 5

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

14 Dec '04

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

3 3

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

14 Dec '04

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

4 3

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

14 Dec '04

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

1 0

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

14 Dec '04

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

1 0