From Niall.oReilly at ucd.ie Mon May 1 11:35:01 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Mon, 01 May 2006 10:35:01 +0100 Subject: [enum-wg] Follow up on Karen Mulberry's presentation today In-Reply-To: References: Message-ID: <073F625A-52DE-4392-8547-4B5FFEBAE719@ucd.ie> On 30 Apr 2006, at 22:02, Mulberry, Karen wrote: > Also the TPAC will produce reports on its trial activities on a > monthly > basis for the CC1 ENUM LLC. Is it planned to publish these monthly as they are produced, or will they be kept internal to the CC1 ENUM LLC? /Niall From Karen.Mulberry at neustar.biz Mon May 1 11:54:08 2006 From: Karen.Mulberry at neustar.biz (Mulberry, Karen) Date: Mon, 1 May 2006 05:54:08 -0400 Subject: [enum-wg] Follow up on Karen Mulberry's presentation today Message-ID: Niall, The TPAC will send their reports to the CC1 ENUM LLC. It will be up to the LLC to make those reports public. I suspect that since the LLC has an obligation to send those reports to all the CC1 North American Numbering Plan countries that they will be made public and accessible to everyone who is interested in the US trial's progress. Karen Mulberry Neustar Inc. -----Original Message----- From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] On Behalf Of Niall O'Reilly Sent: Monday, May 01, 2006 3:35 AM To: Mulberry, Karen Cc: Niall O'Reilly; Carsten Schiefner; enum-wg at ripe.net Subject: Re: [enum-wg] Follow up on Karen Mulberry's presentation today On 30 Apr 2006, at 22:02, Mulberry, Karen wrote: > Also the TPAC will produce reports on its trial activities on a > monthly > basis for the CC1 ENUM LLC. Is it planned to publish these monthly as they are produced, or will they be kept internal to the CC1 ENUM LLC? /Niall From mah at inode.at Mon May 1 13:27:15 2006 From: mah at inode.at (Michael Haberler) Date: Mon, 01 May 2006 13:27:15 +0200 Subject: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work In-Reply-To: <763F6687-AE33-49E5-9148-4A7BFF11F27C@rfc1035.com> References: <4450D68C.9040100@schiefner.de> <7.0.1.0.2.20060428083810.04f00410@inode.at> <3B3DCAE1-C0BC-4F77-AA5C-4476FF518C5F@rfc1035.com> <7.0.1.0.2.20060428105008.03959610@inode.at> <763F6687-AE33-49E5-9148-4A7BFF11F27C@rfc1035.com> Message-ID: <7.0.1.0.2.20060501123453.05e02ee0@inode.at> At 19:33 30.04.2006, Jim Reid wrote: >>so it's really NRA block allocations which you're preloading in >>User ENUM - a hit in a block will really tell you that the block is >>allocated to some operator but nothing else, right? > >Yup, pretty much. Though a hit would presumably tell the client how >to terminate some sort of service for that number via SIP or the PSTN. great, lets look at what that buys us WRT to tel: uri's: I take the call processig logic of an average sip provider or customer, which looks as follows if (destination number in user ENUM) { if (SIP URI present) { bounce call to dest URI and hope it gets accepted; } if (tel URI present) { bounce call to your default PSTN gateway a) } } else { bounce call to your default PSTN gateway b) } The only difference I can spot is that I bounce the call to my default pstn gateway through branch a) instead of branch b) since the default (NXDOMAIN) is to bounce to the PSTN anyway - customer experience ist identical. sip: >>I have some doubts that telcos will come forward and have the >>registry publish *for them* what is essentially a Point-of- >>Interconnect information in the User ENUM tree (right?). > >Well we have (mainly VoIP) providers queuing up to try this. They >don't appear to share your doubts. :-) So you're basically assuming providers will publish an openly contactable SIP URI *for their customers*... that doesnt quite match our experience of provider belief systems.. these guys ARE concerned about being taken out of business by a script kiddie which discovers sipsak .. but some might not have discovered that aspect yet.. which is why I am sure that none of the bigger fish in the VoIP pond will bite on the SIP uri CRUE entry >You seem to be confused Michael. CRUE has NOTHING WHATSOEVER to do >with Infastructure or Carrier ENUM. Or interconnect agreements >between carriers. That subject has never even cropped up while the >CRUE proposal was being worked on. Well yes it does, and its in your policy assumption WRT sip, which is: Providers/Carriers (that's the 'C' in 'CRUE'..) will a) publish an open URI (which means "anybody may 'interconnect' with said provider) and b) it is a 'sender keeps all' settlement regime c) said provider is "willing to go away" if the user opts into User ENUM - which is only going to happen if he cant make any money on the user in the first place with said entry d) any sad idiot may bounce a SIP INVITE at 3:30AM to this sip URI (d) which is why we're engaging in SPEERMINT - this NEEDS to be resolved before public SIP goes the route SMTP mail did - see http://www.enum.at/ietf/ - draft-lendl* which applies to User ENUM just as well) >Michael, I'm trying not to get angry with you. :-) There is only one >public tree: e164.arpa. that's ok.. it's a 'discourse', not a case of parental guidance as far as I'm concerned.. The only difference between CRUE >and the classical User ENUM model is that a provider gets the ability >to register say 1 million numbers in one operation instead of >numbers being registered and delegated one at a time by the >individuals owning each number. a million tel: entries is great provided they convey meaningful information meaningful IMV could be for instance: number exists; number hosted by carrier X/through routing number Y; number does definitely not exist >If anything, CRUE provides a means of eliminating some of the >existing alternate trees. [None of the UK providers who are about to >use CRUE use alternate trees AFAICT.] Instead of each (UK based) VoIP >provider running their own ENUM-like name space uknown to anyone else >and being unable to talk to each other, they could in principle enter >their Ofcom-assigned blocks into CRUE and all share a common, >consistent tree. can you come forward with sensible *use cases* for tel: and sip: ? the fact that a well formed E.164 number may or may not resolve to a tel: URI will not change the call processing logic of any SIP user/provider wrt numbers reachable on the pstn, which is pretty much all of them as of today on the "public default SIP URI for customers" use case I wish the registry operator and providers good luck and deep pockets -Michael From jim at rfc1035.com Mon May 1 14:51:41 2006 From: jim at rfc1035.com (Jim Reid) Date: Mon, 1 May 2006 13:51:41 +0100 Subject: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work In-Reply-To: <7.0.1.0.2.20060501123453.05e02ee0@inode.at> References: <4450D68C.9040100@schiefner.de> <7.0.1.0.2.20060428083810.04f00410@inode.at> <3B3DCAE1-C0BC-4F77-AA5C-4476FF518C5F@rfc1035.com> <7.0.1.0.2.20060428105008.03959610@inode.at> <763F6687-AE33-49E5-9148-4A7BFF11F27C@rfc1035.com> <7.0.1.0.2.20060501123453.05e02ee0@inode.at> Message-ID: <9B2E0848-5652-4CCA-B64B-26F547430FF0@rfc1035.com> This is my final posting on this thread. I'm fed up explaining this and clearing up Michael's misconceptions. I suggest we defer further discussion until UKEG publishes the CRUE document in a couple of weeks. By which time we will have operational experience of how it works in reality. On May 1, 2006, at 12:27, Michael Haberler wrote: > great, lets look at what that buys us WRT to tel: uri's: > I take the call processig logic of an average sip provider or > customer, which looks as follows > > if (destination number in user ENUM) { > if (SIP URI present) { > bounce call to dest URI and hope it gets accepted; > } > if (tel URI present) { > bounce call to your default PSTN gateway a) > } > } else { > bounce call to your default PSTN gateway b) > } > > The only difference I can spot is that I bounce the call to my > default pstn gateway through branch a) instead of branch b) since > the default (NXDOMAIN) is to bounce to the PSTN anyway - customer > experience ist identical. Yes but you miss the point. You're assuming that ENUM-aware applications only care about sip: URIs. Which is probably true, but not the whole truth. The tel: URI in CRUE is a default for applications that need to route the "call" when they're not interested in SIP. Now you might assume that all applications will have a default action of "dump to PSTN" but this can't be guaranteed or assumed: hence this tel: URI as a safety net. This also ties in with some aspects of the UK ENUM Code of Conduct about "higher rate calls". Users are expected to give consent -- or explictly configure their software -- before they "make calls" that might incur charges that are higher than they reasonably expect. eg Dumping to the PSTN when the end user was expecting a free SIP or Skype call. > So you're basically assuming providers will publish an openly > contactable SIP URI *for their customers*... that doesnt quite > match our experience of provider belief systems.. Fine. We don't live in the same countries Michael. We shouldn't expect the Austrian environment to be identical to the UK's or vice versa. I can assure you some UK VoIP providers (and others) are very interested in CRUE. For them it's a no-brainer. They can publish internet-reachable SIP addresses so callers don't need to contact their customers via the PSTN. That means not having to pay termination charges to a "regular" telco for inbound PSTN calls to those numbers. Please remember that the key objective of CRUE is to get loads of meaningful data -- for some definition of meaningful -- into 4.4.e164.arpa. If that data can be used for other purposes, that's a side effect. Some of them could be good: eg encouraging the uptake of ENUM by providers and pump-priming the UK market. Others could be bad: new vectors for SPIT and suchlike. Providers can weigh up these advantages and disadvantages before choosing to participate in CRUE. > Well yes it does, and its in your policy assumption WRT sip, which is: No, that's *your* assumption Michael. > Providers/Carriers (that's the 'C' in 'CRUE'..) will > a) publish an open URI (which means "anybody may 'interconnect' > with said provider) True. Though I don't consider that to be "interconnect" in the way a telco does. It doesn't involve contracts, tarrifs or settlements for instance. > b) it is a 'sender keeps all' settlement regime What "settlement regime"? If calls to a number come in over the internet to some SIP gateway (or whatever), there are no cross- operator tarrifs to settle. > c) said provider is "willing to go away" if the user opts into User > ENUM - which is only going to happen if he cant make any money on > the user in the first place with said entry Nope. Here's a likely use scenario. Provider sells VoIP over broadband (say) for a fixed fee to an end user. This comes with CRUE. The provider can now up-sell customer to an ENUM delegation and extract more money for DNS hosting, NAPTR management & provisioning, presence services, integrated messaging, value-added services on top of additional NAPTRs, etc, etc. > d) any sad idiot may bounce a SIP INVITE at 3:30AM to this sip URI Any sad idiot can call any phone number at any time. So what? Maybe these providers could offer add-on services to filter inbound SIP traffic? For a fee of course. :-) > (d) which is why we're engaging in SPEERMINT - this NEEDS to be > resolved before public SIP goes the route SMTP mail did - see > http://www.enum.at/ietf/ - draft-lendl* which applies to User ENUM > just as well) We are in violent agreement. However the problems of SPIT and suchlike are completely orthogonal to CRUE. They exist whether or not a number is entered into ENUM using CRUE of the classical delegation model. > a million tel: entries is great provided they convey meaningful > information Which is why UKEG came up with CRUE. > meaningful IMV could be for instance: number exists; number hosted > by carrier X/through routing number Y; number does definitely not > exist Well if CRUE grows legs, in principle it could be extended to add more (non-SIP?) NAPTRs to the block registrations: say a void: service type or something like that. > can you come forward with sensible *use cases* for tel: and sip: ? I did. See above. > the fact that a well formed E.164 number may or may not resolve to > a tel: URI will not change the call processing logic of any SIP > user/provider wrt numbers reachable on the pstn, which is pretty > much all of them as of today CRUE says nothing about SIP gateway call processing logic, far less wanting to change that. If it did, that would be an egregious layering violation. However you seem to have assumed that the only thing that will do an ENUM lookup is a SIP gateway. That can't be guaranteed. Even if most ENUM lookups do come from SIP gateways. From lendl at nic.at Wed May 3 14:34:54 2006 From: lendl at nic.at (Otmar Lendl) Date: Wed, 3 May 2006 14:34:54 +0200 Subject: [enum-wg] Delegation of 9.3.e164.arpa / ENUM DNS Quality Message-ID: <20060503123454.GA23523@nic.at> Folks, domain: 9.3.e164.arpa descr: Italy ENUM Mapping nserver: dns.istsupcti.it nserver: dns2.istsupcti.it remarks: Ministero delle Comunicazioni - http://www.comunicazioni.it remarks: Istituto Superiore delle Comunicazioni e delle tecnologie dell'Informazione remarks: http://www.iscom.gov.it but: ; <<>> DiG 9.2.4 <<>> 9.3.e164.arpa ns @dns.istsupcti.it ;; global options: printcmd ;; connection timed out; no servers could be reached and ; <<>> DiG 9.2.4 <<>> 9.3.e164.arpa ns @dns2.istsupcti.it ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4925 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;9.3.e164.arpa. IN NS ;; AUTHORITY SECTION: arpa. 3600 IN SOA ns1.istsupcti.it. administrator.istsupcti.it. 2006022816 900 600 86400 3600 -------------- Some people seem to view that as they only run a trial (if at all) on their ENUM country-code delegation, nameserver performance and reliability does not matter. This is wrong. ENUM is in production in other countries. A lot of SIP proxies query e164.arpa for all calls to E.164 numbers. That includes calls to countries where ENUM is not in production yet. Calls to Italy are thus running into a DNS timeout. This is not good. So please: Even if you are not in production with your country-code: PLEASE MAKE SURE THAT YOUR NAMESERVERS ANSWER. EVEN IF ALL THEY EVER SEND IS NXDOMAIN. Thank you. /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > From enumvoipsip.cs at schiefner.de Wed May 3 14:51:39 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 03 May 2006 14:51:39 +0200 Subject: [enum-wg] Delegation of 9.3.e164.arpa / ENUM DNS Quality In-Reply-To: <20060503123454.GA23523@nic.at> References: <20060503123454.GA23523@nic.at> Message-ID: <4458A75B.90409@schiefner.de> Hi Otmar, this has been raised with the RIPE NCC already last week. They investitage the issue, together with the relevant people from Italy as we speak. Cheers, -C. Otmar Lendl wrote: > Folks, > > domain: 9.3.e164.arpa > descr: Italy ENUM Mapping > nserver: dns.istsupcti.it > nserver: dns2.istsupcti.it > remarks: Ministero delle Comunicazioni - http://www.comunicazioni.it > remarks: Istituto Superiore delle Comunicazioni e delle tecnologie dell'Informazione > remarks: http://www.iscom.gov.it > > but: > > ; <<>> DiG 9.2.4 <<>> 9.3.e164.arpa ns @dns.istsupcti.it > ;; global options: printcmd > ;; connection timed out; no servers could be reached > > and > > ; <<>> DiG 9.2.4 <<>> 9.3.e164.arpa ns @dns2.istsupcti.it > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4925 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;9.3.e164.arpa. IN NS > > ;; AUTHORITY SECTION: > arpa. 3600 IN SOA ns1.istsupcti.it. administrator.istsupcti.it. 2006022816 900 600 86400 3600 > > -------------- > > Some people seem to view that as they only run a trial (if at all) on > their ENUM country-code delegation, nameserver performance and > reliability does not matter. > > This is wrong. ENUM is in production in other countries. A lot of > SIP proxies query e164.arpa for all calls to E.164 numbers. > That includes calls to countries where ENUM is not in production yet. > > Calls to Italy are thus running into a DNS timeout. > > This is not good. > > So please: Even if you are not in production with your country-code: > > PLEASE MAKE SURE THAT YOUR NAMESERVERS ANSWER. > EVEN IF ALL THEY EVER SEND IS NXDOMAIN. > > Thank you. > > /ol From me1-telecoms at marcusevansuk.com Thu May 4 09:33:38 2006 From: me1-telecoms at marcusevansuk.com (me1-telecoms) Date: Thu, 4 May 2006 08:33:38 +0100 Subject: [enum-wg] European ENUM in London Message-ID: <0D73FF77291E904185AE870DA29A55D101D2FE3F@lon-s04.menetwork.com> FOR YOUR NEXT OPPORTUNITY TO CATCH UP WITH ENUM DEVELOPMENTS IN EUROPE AND TO LEARN AND SHARE WITH YOUR PEERS.........COME TO LONDON IN JUNE. You should join the Marcus Evans ENUM AND VOIP PEERING FORUM in London, UK. 19-21 June. This is an outstanding event regarding ENUM and related questions such as VoIP Peering and IP Interconnect. Many of the key European players in this arena will be present. The two days are really packed with information, so if you are really interested, read the Programme PDF attached and contact our Sales Hotline if you want to register. Sales Hotline: 0044 (0)207 647 2333 Contact Email: me1-telecoms at marcusevansuk.com Programme PDF <> -------------- next part -------------- A non-text attachment was scrubbed... Name: ENUM ME LONDON 2006.pdf Type: application/octet-stream Size: 72741 bytes Desc: ENUM ME LONDON 2006.pdf URL: From Niall.oReilly at ucd.ie Thu May 4 13:34:16 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 04 May 2006 12:34:16 +0100 Subject: [enum-wg] European ENUM in London In-Reply-To: <0D73FF77291E904185AE870DA29A55D101D2FE3F@lon-s04.menetwork.com> References: <0D73FF77291E904185AE870DA29A55D101D2FE3F@lon-s04.menetwork.com> Message-ID: <409B9DD7-EE5A-49D3-8485-B76F6CD8C1C6@ucd.ie> On 4 May 2006, at 08:33, me1-telecoms wrote: > FOR YOUR NEXT OPPORTUNITY TO CATCH UP WITH ENUM DEVELOPMENTS IN > EUROPE AND TO LEARN AND SHARE WITH YOUR PEERS.........COME TO > LONDON IN JUNE. [ rest deleted ] Please note that the following condition applies generally to RIPE working group mailing lists: "Postings are accepted only from subscribed members, but the lists may only be used for purposes covered by the charter of each RIPE Working Group," and that dissemination of marketing material does not fall within the charter of the RIPE ENUM WG. Please refrain from sending postings of this kind to this list. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group From me1-telecoms at marcusevansuk.com Thu May 4 09:28:18 2006 From: me1-telecoms at marcusevansuk.com (me1-telecoms) Date: Thu, 4 May 2006 08:28:18 +0100 Subject: [enum-wg] European ENUM in London Message-ID: <0D73FF77291E904185AE870DA29A55D101D2FE3D@lon-s04.menetwork.com> FOR YOUR NEXT OPPORTUNITY TO CATCH UP WITH ENUM DEVELOPMENTS IN EUROPE AND TO LEARN AND SHARE WITH YOUR PEERS.........COME TO LONDON IN JUNE. You should join the Marcus Evans ENUM AND VOIP PEERING FORUM in London, UK. 19-21 June. This is an outstanding event regarding ENUM and related questions such as VoIP Peering and IP Interconnect. Many of the key European players in this arena will be present. The two days are really packed with information, so if you are really interested, read the Programme PDF attached and contact our Sales Hotline if you want to register. Sales Hotline: 0044 (0)207 647 2333 Contact Email: me1-telecoms at marcusevansuk.com Programme PDF <> -------------- next part -------------- A non-text attachment was scrubbed... Name: ENUM ME LONDON 2006.pdf Type: application/octet-stream Size: 72741 bytes Desc: ENUM ME LONDON 2006.pdf URL: From enumvoipsip.cs at schiefner.de Fri May 5 14:32:13 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Fri, 05 May 2006 14:32:13 +0200 Subject: [enum-wg] Delegation of 9.3.e164.arpa / ENUM DNS Quality In-Reply-To: <20060503123454.GA23523@nic.at> References: <20060503123454.GA23523@nic.at> Message-ID: <445B45CD.6090207@schiefner.de> All, this has been fixed on Wednesday, 3 May 06. Thanks to all who have taken care of the issue. Best, Carsten Otmar Lendl wrote: > Folks, > > domain: 9.3.e164.arpa > descr: Italy ENUM Mapping > nserver: dns.istsupcti.it > nserver: dns2.istsupcti.it > remarks: Ministero delle Comunicazioni - http://www.comunicazioni.it > remarks: Istituto Superiore delle Comunicazioni e delle tecnologie dell'Informazione > remarks: http://www.iscom.gov.it > > but: > > ; <<>> DiG 9.2.4 <<>> 9.3.e164.arpa ns @dns.istsupcti.it > ;; global options: printcmd > ;; connection timed out; no servers could be reached > > and > > ; <<>> DiG 9.2.4 <<>> 9.3.e164.arpa ns @dns2.istsupcti.it > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4925 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;9.3.e164.arpa. IN NS > > ;; AUTHORITY SECTION: > arpa. 3600 IN SOA ns1.istsupcti.it. administrator.istsupcti.it. 2006022816 900 600 86400 3600 > > -------------- > > Some people seem to view that as they only run a trial (if at all) on > their ENUM country-code delegation, nameserver performance and > reliability does not matter. > > This is wrong. ENUM is in production in other countries. A lot of > SIP proxies query e164.arpa for all calls to E.164 numbers. > That includes calls to countries where ENUM is not in production yet. > > Calls to Italy are thus running into a DNS timeout. > > This is not good. > > So please: Even if you are not in production with your country-code: > > PLEASE MAKE SURE THAT YOUR NAMESERVERS ANSWER. > EVEN IF ALL THEY EVER SEND IS NXDOMAIN. > > Thank you. > > /ol From enumvoipsip.cs at schiefner.de Fri May 5 14:57:35 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Fri, 05 May 2006 14:57:35 +0200 Subject: [enum-wg] Delegation of 9.3.e164.arpa / ENUM DNS Quality In-Reply-To: <445B45CD.6090207@schiefner.de> References: <20060503123454.GA23523@nic.at> <445B45CD.6090207@schiefner.de> Message-ID: <445B4BBF.7060407@schiefner.de> Addendum: it seems that there is a similar issue with another delegation right now - I have just raised that with the NCC as well. Best, -C. Carsten Schiefner wrote: > All, > > this has been fixed on Wednesday, 3 May 06. > > Thanks to all who have taken care of the issue. > > Best, > > Carsten > > Otmar Lendl wrote: >> Folks, >> >> domain: 9.3.e164.arpa >> descr: Italy ENUM Mapping >> nserver: dns.istsupcti.it >> nserver: dns2.istsupcti.it >> remarks: Ministero delle Comunicazioni - >> http://www.comunicazioni.it >> remarks: Istituto Superiore delle Comunicazioni e delle >> tecnologie dell'Informazione >> remarks: http://www.iscom.gov.it >> >> but: >> >> ; <<>> DiG 9.2.4 <<>> 9.3.e164.arpa ns @dns.istsupcti.it >> ;; global options: printcmd >> ;; connection timed out; no servers could be reached >> >> and >> ; <<>> DiG 9.2.4 <<>> 9.3.e164.arpa ns @dns2.istsupcti.it >> ;; global options: printcmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4925 >> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;9.3.e164.arpa. IN NS >> >> ;; AUTHORITY SECTION: >> arpa. 3600 IN SOA ns1.istsupcti.it. >> administrator.istsupcti.it. 2006022816 900 600 86400 3600 >> >> -------------- >> >> Some people seem to view that as they only run a trial (if at all) on >> their ENUM country-code delegation, nameserver performance and >> reliability does not matter. >> >> This is wrong. ENUM is in production in other countries. A lot of >> SIP proxies query e164.arpa for all calls to E.164 numbers. >> That includes calls to countries where ENUM is not in production yet. >> >> Calls to Italy are thus running into a DNS timeout. >> This is not good. >> >> So please: Even if you are not in production with your country-code: >> >> PLEASE MAKE SURE THAT YOUR NAMESERVERS ANSWER. EVEN IF ALL >> THEY EVER SEND IS NXDOMAIN. >> >> Thank you. >> >> /ol From martin.koenig at toplink.de Fri May 5 10:45:28 2006 From: martin.koenig at toplink.de (Martin Koenig) Date: Fri, 5 May 2006 10:45:28 +0200 Subject: [enum-wg] European ENUM in London In-Reply-To: <0D73FF77291E904185AE870DA29A55D101D2FE3D@lon-s04.menetwork.com> Message-ID: <003e01c67020$42b943e0$eb2aa8c0@mklaptop> Could somebody official please warn this enum-wg membership not to send spam to the list? Regards, Martin > -----Original Message----- > From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] > On Behalf Of me1-telecoms > Sent: Thursday, May 04, 2006 9:28 AM > To: enum-wg at ripe.net > Subject: [enum-wg] European ENUM in London > > > > FOR YOUR NEXT OPPORTUNITY TO CATCH UP WITH ENUM DEVELOPMENTS > IN EUROPE AND TO LEARN AND SHARE WITH YOUR PEERS.........COME > TO LONDON IN JUNE. > > You should join the Marcus Evans ENUM AND VOIP PEERING FORUM > in London, UK. 19-21 June. > > This is an outstanding event regarding ENUM and related > questions such as VoIP Peering and IP Interconnect. Many of > the key European players in this arena will be present. > > The two days are really packed with information, so if you > are really interested, read the Programme PDF attached and > contact our Sales Hotline if you want to register. > > Sales Hotline: 0044 (0)207 647 2333 > Contact Email: me1-telecoms at marcusevansuk.com > > Programme PDF > > <> > > From ag at ag-projects.com Fri May 12 16:54:25 2006 From: ag at ag-projects.com (Adrian Georgescu) Date: Fri, 12 May 2006 16:54:25 +0200 Subject: [enum-wg] ENUM provisioning platform for 0.4.e164.arpa top level domain Message-ID: <2D9B4F6D-3C28-470E-AA32-B4882431B852@ag-projects.com> ANISP, the Romanian Internet Service Provider Association http:// www.anisp.ro representing more than 40 service providers (http:// www.anisp.ro/?c=membri) will build a provisioning system for the ENUM tree 0.4.e164.arpa. The Romanian ENUM exchange will be hosted in two RoNIX locations (Romanian Network for Internet eXchange) and will be backed up by an infrastructure hosted within the European backbone. The 0.4.e164.arpa is under the authority of the Romanian regulatory body ANRC, which by end of this year planned to define the final procedures of delegation and administration of the public ENUM tree 0.4.e164.arpa. A press release is available at: http://www.sipcenter.com/sip.nsf/newsview? open&type=News&docid=WEBB6PNKZT Adrian Georgescu AG Projects From enumvoipsip.cs at schiefner.de Mon May 15 20:12:08 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Mon, 15 May 2006 20:12:08 +0200 Subject: [enum-wg] ENUM provisioning platform for 0.4.e164.arpa top level domain In-Reply-To: <2D9B4F6D-3C28-470E-AA32-B4882431B852@ag-projects.com> References: <2D9B4F6D-3C28-470E-AA32-B4882431B852@ag-projects.com> Message-ID: <4468C478.6040705@schiefner.de> Hi Adrian, Adrian Georgescu wrote: > ANISP, the Romanian Internet Service Provider Association > http://www.anisp.ro representing more than 40 service providers > (http://www.anisp.ro/?c=membri) will build a provisioning system for the > ENUM tree 0.4.e164.arpa. > > The Romanian ENUM exchange will be hosted in two RoNIX locations > (Romanian Network for Internet eXchange) and will be backed up by an > infrastructure hosted within the European backbone. The 0.4.e164.arpa is > under the authority of the Romanian regulatory body ANRC, which by end > of this year planned to define the final procedures of delegation and > administration of the public ENUM tree 0.4.e164.arpa. > > A press release is available at: > > http://www.sipcenter.com/sip.nsf/newsview?open&type=News&docid=WEBB6PNKZT it just doesn't come entirely clear to me: is this User or Infrastructure ENUM? Or something in between? And if it is Infrastructure ENUM: what implementation model will be used? Thanks and best - enjoy Stockholm: -C. From Niall.oReilly at ucd.ie Thu May 18 23:08:34 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 18 May 2006 22:08:34 +0100 Subject: [enum-wg] Re: U.S. Provider ENUM Trial Announced In-Reply-To: References: Message-ID: On 18 May 2006, at 18:39, Mulberry, Karen wrote: > I thought you might find the following US ENUM LLC Press Release > of interest for future ENUM discussions at RIPE. Thanks, Karen. Exciting news! I expect that people on the RIPE WG mailing list will find it more convenient to have a pointer to the announcement (if I'm not mistaken, this would be http://enumllc.com/ProviderTrial.htm) rather than a fancy mail with attachments. Whenever you have more news to share with us, please feel free to post directly to the list. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group