From enumvoipsip.cs at schiefner.de Wed May 2 12:46:00 2007 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 02 May 2007 12:46:00 +0200 Subject: [enum-wg] RIPE 53 draft minutes - Last reminder! In-Reply-To: <440EEB98.4020104@schiefner.de> References: <6F570226-3750-4C95-BFC2-C460341907A6@ucd.ie> <440EEB98.4020104@schiefner.de> Message-ID: <46386BE8.9000904@schiefner.de> Dear colleagues - the still first draft is available at: http://www.ripe.net/ripe/wg/enum/minutes/r53-minutes.html For your convenience you can also find it below as plain TXT. Please send in any comments and/or corrections you may have to this list directly and/or to . Please note that we have set the deadline for such contributions by email to Wednesday, 9 May 2007, 12:00 UTC/15:00 Tallinn local time. Further objections will be acceped in person at the WG session, with immediate decision on dealing with them at the meeting; they could need more time on list. In the absence of any objections, the minutes will be declared "final" as a direct result of the completion of this agenda item. Best, Carsten (on behalf of the ENUM WG Co-Chairs) = - = - = Draft ENUM Working Group Minutes from RIPE 53 RIPE Meeting: 53 Working Group: ENUM Status: Draft Revision Number: 1 * content to enum-wg-chair at ripe.net * format to webmaster at ripe.net RIPE 53 - Hotel Krasnapolsky - St. Johns II - 2006-10-04 - 14:00-15:30 Meeting Chair: Niall O'Reilly (UCD - University College Dublin) Scribe: Alex Le Heux (RIPE NCC) Jabber: Catherine Carr (RIPE NCC) Webcast and Feedback Archives: http://www.ripe.net/ripe/meetings/ripe-53/sessions-archive.html Start: 14:00 Administrative matters The Chair welcomes everyone, the scribe and the jabberwock. There are no additional agenda points to add to the agenda although the order will be different: http://www.ripe.net/ripe/meetings/ripe-53/agendas/enum.html There were no comments on the minutes from the RIPE52 meeting, so the minutes are approved. Review of RIPE52 action items: 52.2 - Carsten Schiefner (Deutsche Telekom) There has been some discussion with the RIPE NCC. A .zip file has the advantages of making it easy to add more files and it is a single download. Separate files give a good overview, can be well structured and are the same as the old concept. A downside is that it will produce many hits while searching. Carsten Schiefner will once more put this matter to the WG Mailing List. [ ENUM-AP-52.2 remains open ] The other action items will be dealt with in other agenda items. Presentation: Operations Update - Brett Carr (RIPE NCC) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-bc-upd.pdf Questions: Patrick Faltstrom (Cisco): Are you doing lameness checks on DNS servers? Brett Carr (RIPE NCC): Not yet. Patrick Faltstrom (Cisco): Will the RIPE NCC take the initiative for that? Brett Carr (RIPE NCC): Yes. Peter Koch (DENIC): You had a slide about strange queries, starting with a plus. Have you considered they could be a misimplementation of the DDDS algorithm? Have you looked into from how many different sources these queries originated? Brett Carr (RIPE NCC): No, but I have all the stats. But we can. => Action item on the RIPE NCC [ ENUM-AP-53.1: RIPE NCC to examine and report on "strange queries" ] Carsten Schiefner (Deutsche Telekom): The NCC is able to get stats from all servers. Will there be a further effort to break them down by country code? Brett Carr (RIPE NCC): We tried, but not all providers have the resources to run the stats on their machines and some are very wary from a privacy point of view. Otmar Lendl (NIC.AT, via Jabber): Please get the DNS performance of the Chinese server up to speed (or provide glue for them). Resolving e164-arpa.cnnic.net.cn is quite broken. Brett Carr (RIPE NCC): Chinese are working on moving their service to a different server. We are already in contact with them. Presentation: Quality Task Force - Carsten Schiefner (Deutsche Telekom) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-cs-qtf.pdf Niall O'Reilly (University College Dublin): Will you follow up on the Quality Task Force and follow up on the lameness checks by the NCC as an action item? Carsten Schiefner (Deutsche Telekom): Yes. [ ENUM-AP-53.2: Carsten Schiefner to follow up on Quality TF ] Andrei Robachevsky (RIPE NCC): Why do you think it's impossible to tell an ENUM Tier-1 registry to be compliant? Jim Reid (RIPE NCC Exec Board): The answer to that is not technical, it's political. It's run by the country according to that country's rules. So it's a matter of national sovereignty, so I don't think it's the business of the NCC or anybody else to tell them how to run their name servers. Andrei Robachevsky (RIPE NCC): Can this issue be brought into the technical plane rather than the political plane? I understand that delegation to a particular entity is a political issue, but running DNS servers is probably more technical. Jim Reid (RIPE NCC Exec Board): It is a technical issue, but from a government perspective, they feel entitled to do it they way they want to. Patrik Faltstrom (Cisco): That's why I asked who took the initiative for doing the checks. There is a very, very big difference between whether a country asks the RIPE NCC directly or indirectly to do these lameness checks and notify them when something is broken and having someone tell a country that they're doing the wrong thing. Carsten Schiefner (Deutsche Telekom): The original initiative by the RIPE NCC for the lameness checks was for the reverse mapping space only. Jim Reid (RIPE NCC Exec Board): It's not an issue of DNS, it's an issue of phone numbers and telephone numbers being an item of national sovereignty. Daniel Karrenberg (RIPE NCC): I fully agree with Patrik and what Carsten said. What you want to see is a best common practice written up. That's not telling a country on how they should run their DNS. Being from the NCC I am slightly uncomfortable with the hands off approach that is suggested by Patrik and Jim. In any other constellation I can think of; the parent registry has some rules actually. I'm uneasy about this because the RIPE NCC runs at Tier-0 and any really bad quality falls back on the RIPE NCC. We were getting flak for things not working, so I think the NCC is entitled to make strong suggestions. Niall O'Reilly (University College Dublin): (taking chair hat off) There is a delicate balancing act here. If there isn't a safety net that's a bad thing, if the safety net interferes with national sovereignty, that is a bad thing too. Jim Reid (RIPE NCC Exec Board): I agree with what Daniel says. The RIPE NCC must be careful though with it's role as Tier-0 registry. The instructions to the NCC didn't mention lame delegation checking. If the NCC is perceived to exceed its authority, there could be trouble. Olaf Kolkman (NLnet Labs): About the BCP that Daniel mentioned, I think it's more important to provide a set of minimum requirements. Not "this is the bar you should reach" but "this is the bar you should step over" to at least be good. Field Reports Presentation - Ondrej Filip (NIC.CZ) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-of-czr.pdf Carsten Schiefner (Deutsche Telekom): I would be surprised if a premium rate number holder would actually register it. Ondrej Filip (NIC.CZ): It's an option. Carsten Schiefner (Deutsche Telekom): If you go commercial in 2007, will you clean the trial database? Ondrej Filip (NIC.CZ): No, we will continue on the same platform. Jim Reid (RIPE NCC Exec Board): What are your plans to incorporate this WG's thoughts on DNS quality and incorporate monitoring into the platform? Ondrej Filip (NIC.CZ): No plans. Sungwoo Shin (KRNIC): You will use trial user data when you move to the commercial phase. Will there be any validation of that data? Ondrej Filip (NIC.CZ): Yes, the trial phase is the same as commercial, except without payment. So there is normal validation. Sungwoo Shin (KRNIC): The trial users can use it freely and make a free call without charge? Ondrej Filip (NIC.CZ): Yes, you can use it to make a free call. Presentation - Jim Reid (UKEG) http://www.ripe.net/ripe/meetings/ripe-53/presentations/ukeg.pdf Carsten Schiefner (Deutsche Telekom): Is external DNS monitoring part of the RFP? Jim Reid (UKEG): Yes. Otmar Lendl (NIC.AT, via Jabber): Are the SIP URIs in the CRUE records supposed to point to open SIP server, and thus reachable by any caller on the Internet? Jim Reid (UKEG): The SIP server address can point to wherever the carrier chooses, we don't care. Bernie Hoeneisen (SWITCH, via Jabber): In case a user overrides his ENUM entry as populated by the carrier: what will appear in the zone file you are directly providing/selling to the carriers? User provided NS RRs or original carrier populated NAPTR RRs? Jim Reid (UKEG): There will be two NAPTR records, if there is a delegation request, they will be replaced with NS records. Presentation - Sungwoo Shin (KRNIC) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-ss-kor.pdf Niall O'Reilly (University College Dublin): Will monitoring be built into the requirements for the service? Sungwoo Shin (KRNIC): I don't disagree with Jim's idea. Presentation - Antoin Verschuren (SIDN) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-av-nl.pdf Antoin Verschuren (SIDN): To answer Jim's question: Yes, we will be happy to do so! Jim Reid (RIPE NCC Exec Board): This is about the consultation you are doing. There are two things: One for redelegation and two, a future meeting where people can comment on the general plan. Is that only for Dutch people? Antoin Verschuren (SIDN): It's an open platform. Presentation - Robert Schischka (NIC.AT): http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-rs-aus.pdf Wolfgang Tremmel (DE-CIX): Is it possible that different carriers querying get different views? Robert Schischka (NIC.AT): No, it's a single public tree. Some carriers might have a different view internally, but not from the outside. Jim Reid (RIPE NCC Exec Board): Are you using wildcards? Robert Schischka (NIC.AT): Yes, we have to, we have an open numbering plan. Olaf Kolkman (NLnet Labs): From a DNS client perspective, if I were to query the tree would I need to know the country number plan? Robert Schischka (NIC.AT): Yes, you need to know where the 'i' is so you need to know how long the country code is. It's a dirty solution but the only way to go now. Olaf Kolkman (NLnet Labs): There may be other alternatives. Robert Schischka (NIC.AT): Everybody agrees that in the end it needs to be a separate tree. There was a lengthy discussion in the IETF, the "Dallas treaty" was an interim solution, and will be easy to change. Peter Koch (DENIC): This kind of infrastructure stuff is kind of broken. For years we have been hearing that it would take years to convince the ITU. Has there been any effort so far to actually talk to the ITU and start this? Robert Schischka (NIC.AT): I don't think the issue has been going on for years, but I don't think anyone is talking to the ITU about this very much. Maybe we should see several countries interested in this, to give more power to the discussion. The tech community wants a neat solution, but the key is buy-in from the telcos, not how the tree is named. Peter Koch (DENIC): One of the problems is that the specification is a bit brittle. Robert Schischka (NIC.AT): No one in carrier land really cares about this. Presentation: ENUM Next Generation - Patrik Faltstrom (Cisco) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-pf-nge.pdf Antoin Verschuren (SIDN): How are you going to split authority if you do a delegation on for example a path for a number block: if you want to redelegate, for open number plans for instance? Patrik Faltstrom (Cisco): There are two possibilities: 1. A neutral party similar to the portability database administrator operates a database. 2. Do delegations higher up in the tree, but those parties must be neutral as well. There is no portability in DNS. Daniel Karrenberg (RIPE NCC): How are applications supposed to make use of this? Patrik Faltstrom (Cisco): Two ways: 1. Look up the NAPTR records for the phone numbers. 2. If you understand SIP, you can look up _sip._e2u.[phone number] and use that. Daniel Karrenberg (RIPE NCC): And the _h323 and _message labels are found in some lists? Patrik Faltstrom (Cisco): In the existing ENUM specification there is a IANA registry for those labels, including a registration mechanism. Issues for other working groups: Niall O'Reilly will alert the DB WG and the NCC SERVICES WG as action item 53.3 that we expect to have consensus soon on the NON-REGISTRY issue. [ ENUM-AP-53.3: Niall O'Reilly to alert other WGs re NON-REGISTRY ] AOB The graphic of the T-Shirt will be on Rosie. Meeting Ends 15:55 From enumvoipsip.cs at schiefner.de Mon May 7 12:07:17 2007 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Mon, 07 May 2007 13:07:17 +0300 Subject: [enum-wg] Delegation of +84/4.8.e164.arpa completed Message-ID: <463EFA55.2050306@schiefner.de> Dear colleagues, the ENUM delegation request for 2.6.e164.arpa - +62 is Indonesia's E.164 CC - was confirmed by ITU-T TSB on 26 Mar 2007. As per 2 May 2007, 2.6.e164.arpa is delegated to ns1.cbn.net.id. [202.158.20.1, 2001:D10:2:53::53] ns2.cbn.net.id. [202.158.40.1, 2001:D10:A:53::53] ns.enum.postel.go.id. [203.119.54.6] ns1.indosat.net.id. [202.155.0.20] 2.6.e164.arpa becomes the 43rd ENUM delegation. Welcome, Indonesia! :-) Best, Carsten Schiefner (RIPE ENUM WG Co-Chair) From enumvoipsip.cs at schiefner.de Mon May 7 13:47:44 2007 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Mon, 07 May 2007 14:47:44 +0300 Subject: [enum-wg] Delegation of +62/2.6.e164.arpa completed Message-ID: <463F11E0.3070504@schiefner.de> Dear colleagues, "There still is a mistake in your email"... This time is has successfully hidden in the subject - my apologies. It is Indonesia/+62/2.6.e164.arpa, not Vietnam/+84/4.8.e164.arpa. Best regards, Carsten Schiefner -------- Original Message -------- Subject: [enum-wg] Delegation of +84/4.8.e164.arpa completed Date: Mon, 07 May 2007 13:07:17 +0300 From: Carsten Schiefner To: enum-wg at ripe.net Dear colleagues, the ENUM delegation request for 2.6.e164.arpa - +62 is Indonesia's E.164 CC - was confirmed by ITU-T TSB on 26 Mar 2007. As per 2 May 2007, 2.6.e164.arpa is delegated to ns1.cbn.net.id. [202.158.20.1, 2001:D10:2:53::53] ns2.cbn.net.id. [202.158.40.1, 2001:D10:A:53::53] ns.enum.postel.go.id. [203.119.54.6] ns1.indosat.net.id. [202.155.0.20] 2.6.e164.arpa becomes the 43rd ENUM delegation. Welcome, Indonesia! :-) Best, Carsten Schiefner (RIPE ENUM WG Co-Chair) From ondrej.sury at nic.cz Wed May 9 10:54:12 2007 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Wed, 09 May 2007 11:54:12 +0300 Subject: [enum-wg] DNSMON for enum zones Message-ID: <1178700852.10924.5.camel@yuna> Hi, I was trying to RIPE NCC DNSMON service for our 0.2.4.e164.arpa and it was suggested to open this issue on enum-wg, since DNSMON is available only for TLDs according to current policies. I think it would be good idea to change that policy to include ENUM zones as well. Ondrej. -- Ond?ej Sur? technick? ?editel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americk? 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From andy at nosignal.org Wed May 9 11:44:07 2007 From: andy at nosignal.org (Andy Davidson) Date: Wed, 9 May 2007 10:44:07 +0100 Subject: [enum-wg] DNSMON for enum zones In-Reply-To: <1178700852.10924.5.camel@yuna> References: <1178700852.10924.5.camel@yuna> Message-ID: <1F2D7904-6D97-45F3-8361-EF24F393387E@nosignal.org> On 9 May 2007, at 09:54, Ond?ej Sur? wrote: > I was trying to RIPE NCC DNSMON service for our 0.2.4.e164.arpa and it > was suggested to open this issue on enum-wg, since DNSMON is available > only for TLDs according to current policies. > I think it would be good idea to change that policy to include ENUM > zones as well. A good idea, though the policy may need to state that this is only offered for at the country code level, otherwise the policy may be loose enough to allow end-user zone monitoring through dnsmon. -- Andy Davidson - ( http://www.andyd.net/ ) From ondrej.sury at nic.cz Wed May 9 13:17:24 2007 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Wed, 09 May 2007 14:17:24 +0300 Subject: [enum-wg] DNSMON for enum zones In-Reply-To: <1F2D7904-6D97-45F3-8361-EF24F393387E@nosignal.org> References: <1178700852.10924.5.camel@yuna> <1F2D7904-6D97-45F3-8361-EF24F393387E@nosignal.org> Message-ID: <1178709444.10077.8.camel@yuna> Andy Davidson p??e v St 09. 05. 2007 v 10:44 +0100: > On 9 May 2007, at 09:54, Ond?ej Sur? wrote: > > > I was trying to RIPE NCC DNSMON service for our 0.2.4.e164.arpa and it > > was suggested to open this issue on enum-wg, since DNSMON is available > > only for TLDs according to current policies. > > I think it would be good idea to change that policy to include ENUM > > zones as well. > > A good idea, though the policy may need to state that this is only > offered for at the country code level, otherwise the policy may be > loose enough to allow end-user zone monitoring through dnsmon. My formal proposal for change in agreement was: """ I propose to rephrase that term to "ccTLD and/or ENUM" and add "ccTLD" and "ENUM" definitions to 1.1.: ccTLD: A Top Level Domain as defined by IANA. ENUM: A delegated subdomain of e164.arpa as delegated by RIPE NCC. and change TLD Administrator to: The organisation(s) responsible for registry of a Top Level Domain, as recorded by IANA, or a ENUM Domain, as recorded by RIPE NCC. """ or something like that. These need to be changed in whole ripe-342. Just to note... there could be ENUM operator for country who is not TLD operator at the same time. One nice example (I can think of) is .AT and +43 - both are separated legal entities. Ondrej. -- Ond?ej Sur? technick? ?editel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americk? 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From jim at rfc1035.com Wed May 9 13:58:46 2007 From: jim at rfc1035.com (Jim Reid) Date: Wed, 9 May 2007 12:58:46 +0100 Subject: [enum-wg] DNSMON for enum zones In-Reply-To: <1178709444.10077.8.camel@yuna> References: <1178700852.10924.5.camel@yuna> <1F2D7904-6D97-45F3-8361-EF24F393387E@nosignal.org> <1178709444.10077.8.camel@yuna> Message-ID: <1CA0436C-02EC-45E8-AD08-DD95D0891AFB@rfc1035.com> IMO, this issue straddles two WGs. The ENUM WG can (should?) look into operating requirements and recommendations for monitoring Tier-1 DNS infrastructure. But it should not make policy in this area as it encroaches on National Matters. ISTR the WG already has an open action item on this topic. Changing the DNSMON service -- or extending its scope -- is something for the NCC Services working group. Wearing my Board hat, I am extremely uncomfortable with the NCC straying from its core function (running an IP registry) by offering non-core services that could and should be provided by others. I hope DNSMON doesn't turn into a repeat of the current layer-9 issues with DNS hosting at the NCC. From ondrej.sury at nic.cz Wed May 9 14:25:29 2007 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Wed, 09 May 2007 15:25:29 +0300 Subject: [enum-wg] DNSMON for enum zones In-Reply-To: <1CA0436C-02EC-45E8-AD08-DD95D0891AFB@rfc1035.com> References: <1178700852.10924.5.camel@yuna> <1F2D7904-6D97-45F3-8361-EF24F393387E@nosignal.org> <1178709444.10077.8.camel@yuna> <1CA0436C-02EC-45E8-AD08-DD95D0891AFB@rfc1035.com> Message-ID: <1178713529.10077.33.camel@yuna> Jim Reid p??e v St 09. 05. 2007 v 12:58 +0100: > IMO, this issue straddles two WGs. The ENUM WG can (should?) look > into operating requirements and recommendations for monitoring Tier-1 > DNS infrastructure. But it should not make policy in this area as it > encroaches on National Matters. ISTR the WG already has an open > action item on this topic. Changing the DNSMON service -- or > extending its scope -- is something for the NCC Services working group. Shall we switch ml then to ncc-services-wg? (Just wait for my subscription to be approved). > Wearing my Board hat, I am extremely uncomfortable with the NCC > straying from its core function (running an IP registry) by offering > non-core services that could and should be provided by others. I hope > DNSMON doesn't turn into a repeat of the current layer-9 issues with > DNS hosting at the NCC. If RIPE NCC provides DNSMON already for TLD and root operators, then it should provide same service for ENUM operators. I don't see difference in those two groups (which are heavily overlaped anyway). Ondrej. -- Ond?ej Sur? technick? ?editel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americk? 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From jim at rfc1035.com Wed May 9 14:45:55 2007 From: jim at rfc1035.com (Jim Reid) Date: Wed, 9 May 2007 13:45:55 +0100 Subject: [enum-wg] DNSMON for enum zones In-Reply-To: References: Message-ID: <4D4CEBA7-A188-4285-812E-EFDA4381B03F@rfc1035.com> On May 9, 2007, at 13:18, Antoin Verschuren wrote: > Then you're also uncomfortable with RIPE being tier-0 ENUM registry. I was not on the Board when this activity started. However, this is a very different service from DNS monitoring. There can only be one Tier-0 registry and it needs to be at a stable, neutral venue. There is no technical or operational reason for there to be exactly one entity offering DNS monitoring services: if anything the opposite is true. > If RIPE offers services outside their IP registry task, it should > accomodate for it. I am sorry to violently disagree with you Antoin. The NCC should stick to its core (monopoly) role and keep away from other activities. The further the NCC deviates from its core function, the more likely the authorities are going to start asking awkward questions about cross-subsidies and potential abuse of the NCC's monopoly position. Or mumbling about regulating the NCC in the way that incumbent telcos get regulated. It's fairly straightforward to defend those sorts of questions in the context of running a Tier-0 registry for the general public benefit. Answers when those sorts of questions are raised about providing things like DNS monitoring services (for a fee) are much, much harder to find. More so when the NCC competes with its members. FYI one NCC member was forced to abandon its plans for a commercial DNS monitoring service because the NCC started doing this "for free" (at first) and cherry-picked all the best customers. Bad. Very very bad. BTW, please note there's a difference between RIPE (the open meetings that get held twice a year) and RIPE NCC (the legal entity that co- ordinates Internet number resources in Europe and the Middle East). From Antoin.Verschuren at sidn.nl Wed May 9 14:18:01 2007 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Wed, 9 May 2007 14:18:01 +0200 Subject: [enum-wg] DNSMON for enum zones Message-ID: Jim Reid wrote: > > Wearing my Board hat, I am extremely uncomfortable with the NCC > straying from its core function (running an IP registry) by offering > non-core services that could and should be provided by others. I hope > DNSMON doesn't turn into a repeat of the current layer-9 issues with > DNS hosting at the NCC. Then you're also uncomfortable with RIPE being tier-0 ENUM registry. This keeps popping up. If RIPE offers services outside their IP registry task, it should accomodate for it. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 680 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren at sidn.nl W http://www.sidn.nl/ From jim at rfc1035.com Wed May 9 14:50:56 2007 From: jim at rfc1035.com (Jim Reid) Date: Wed, 9 May 2007 13:50:56 +0100 Subject: [enum-wg] DNSMON for enum zones In-Reply-To: <1178713529.10077.33.camel@yuna> References: <1178700852.10924.5.camel@yuna> <1F2D7904-6D97-45F3-8361-EF24F393387E@nosignal.org> <1178709444.10077.8.camel@yuna> <1CA0436C-02EC-45E8-AD08-DD95D0891AFB@rfc1035.com> <1178713529.10077.33.camel@yuna> Message-ID: On May 9, 2007, at 13:25, Ond?ej Sur? wrote: > Shall we switch ml then to ncc-services-wg? (Just wait for my > subscription to be approved). I think you will need to pursue this in both WGs. You'll need to use the policy development process in the NCC services WG to get a change in a service. But if DNSMON is to be extended to the Tier-1 infrastructure, the NCC would probably need to get something from the ENUM WG about what it is they're expected to monitor. Which could be as simple as "do whatever it is you do for ccTLDs". From Elisabeth.Porteneuve at cetp.ipsl.fr Wed May 9 19:16:12 2007 From: Elisabeth.Porteneuve at cetp.ipsl.fr (Elisabeth Porteneuve) Date: Wed, 9 May 2007 19:16:12 +0200 Subject: [enum-wg] DNSMON for enum zones References: <1178700852.10924.5.camel@yuna> <1F2D7904-6D97-45F3-8361-EF24F393387E@nosignal.org> <1178709444.10077.8.camel@yuna> Message-ID: <001e01c7925d$be6ac2b0$b4ad34c1@win.cetp.ipsl.fr> ----- Original Message ----- From: "Ond?ej Sur?" Sent: Wednesday, May 09, 2007 1:17 PM Subject: Re: [enum-wg] DNSMON for enum zones > ccTLD: A Top Level Domain as defined by IANA. Not exactly, as RECORDED by IANA. Kind regards, Elisabeth Porteneuve From ondrej.sury at nic.cz Thu May 10 08:05:20 2007 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 10 May 2007 09:05:20 +0300 Subject: [enum-wg] DNSMON for enum zones In-Reply-To: <4D4CEBA7-A188-4285-812E-EFDA4381B03F@rfc1035.com> References: <4D4CEBA7-A188-4285-812E-EFDA4381B03F@rfc1035.com> Message-ID: <1178777120.10748.8.camel@yuna> Jim Reid p??e v St 09. 05. 2007 v 13:45 +0100: > > If RIPE offers services outside their IP registry task, it should > > accomodate for it. > > Answers when those sorts of questions are raised about providing > things like DNS monitoring services (for a fee) are much, much harder > to find. More so when the NCC competes with its members. FYI one NCC > member was forced to abandon its plans for a commercial DNS monitoring > service because the NCC started doing this "for free" (at first) and > cherry-picked all the best customers. Bad. Very very bad. I seems to me that you are mixing "DNS monitoring" (in general) and "DNS monitoring for TLD operators". Here we are speaking about "monopoly for monopoly". Speaking for .cz I would very much doubt that we would buy such commercial DNS monitoring if it wasn't from RIPE NCC. We would rather build some platform ourselves and offer it to other TLD operators (on CENTR, OARSI or whatever grounds). Ondrej. -- Ond?ej Sur? technick? ?editel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americk? 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From paf at cisco.com Thu May 10 13:12:18 2007 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Thu, 10 May 2007 14:12:18 +0300 Subject: [enum-wg] 52.2 NCC Correspondance Archive Message-ID: <0E4356D2-6574-4732-BA45-D193188C5E8F@cisco.com> I did not see the microphone that was the closest to me, so I walked around to find one. When I found one, Carsten had already moved to the next point on the agenda :-) Mea culpa. I just want to have it said that I find the archive extremely valuable. To some degree it is more important for me to have the archive available than in any specific format. I have already tried to get information about some delegation, and have not found it... That said, I rather see one webpage per countrycode, and then one link per "document" than a zip file, archive or whatever. Given all those files exists, one could have a link to a zip file as well. But, most important, make the detailed communication available. "Just do it" Patrik From jim at rfc1035.com Thu May 10 13:45:44 2007 From: jim at rfc1035.com (Jim Reid) Date: Thu, 10 May 2007 12:45:44 +0100 Subject: [enum-wg] DNSMON for enum zones In-Reply-To: <1178777120.10748.8.camel@yuna> References: <4D4CEBA7-A188-4285-812E-EFDA4381B03F@rfc1035.com> <1178777120.10748.8.camel@yuna> Message-ID: On May 10, 2007, at 07:05, Ond?ej Sur? wrote: > I seems to me that you are mixing "DNS monitoring" (in general) and > "DNS > monitoring for TLD operators". Here we are speaking about > "monopoly for > monopoly". I'm not mixing these things. From my perspective there's no difference. I'm looking at non-core services that the NCC provide which could and should be offered by others, not by the NCC. DNS monitoring in any form (except for the NCC's internal operations) is such a service IMO. The de facto monopoly in DNS monitoring that the NCC enjoys is regrettable. The fact the NCC is in this business distorts the market and has deterred others, including NCC members, from entering that market. What worries me is an official complaint to the competition authorities which results in them reviewing every aspect of the NCC operations, introducing regulation because it's a monopoly, etc, etc. > Speaking for .cz I would very much doubt that we would buy such > commercial DNS monitoring if it wasn't from RIPE NCC. We would rather > build some platform ourselves and offer it to other TLD operators (on > CENTR, OARSI or whatever grounds). I think that proves my point. There would be more diversity and competition in DNS monitoring services in the marketplace (such as it is) if the NCC would leave it alone to develop naturally. From lendl at nic.at Thu May 10 13:32:07 2007 From: lendl at nic.at (Otmar Lendl) Date: Thu, 10 May 2007 13:32:07 +0200 Subject: [enum-wg] 52.2 NCC Correspondance Archive In-Reply-To: <0E4356D2-6574-4732-BA45-D193188C5E8F@cisco.com> References: <0E4356D2-6574-4732-BA45-D193188C5E8F@cisco.com> Message-ID: <20070510113207.GC15995@nic.at> On 2007/05/10 13:05, Patrik F?ltstr?m wrote: > > But, most important, make the detailed communication available. > > "Just do it" Agreed. I don't think it's appropriate for the WG to micromanage this. Just implement whatever you think is a sensible way to publish the communication by country-code. /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / From paf at cisco.com Thu May 10 14:08:28 2007 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Thu, 10 May 2007 15:08:28 +0300 Subject: [enum-wg] DNSMON for enum zones In-Reply-To: References: <4D4CEBA7-A188-4285-812E-EFDA4381B03F@rfc1035.com> <1178777120.10748.8.camel@yuna> Message-ID: <7067E703-5C90-4977-91D1-7A103400928A@cisco.com> I see a number of different questions being discussed here, and I think we should try to separate them: 1. RIPE NCC is running DNS for e164.arpa 2. RIPE NCC should "protect their skin" and monitor the e164.arpa zone, so they can show their service is up to current standards 3. Registry operators run DNS for zones delegated from e164.arpa, and the delegation itself should be of some quality for ENUM to work -- who has responsible for this? 4. Registry operators have interest in being monitored, should they be monitored, or (via opt-in) on request? 5. If there is a need for monitoring of DNS operation, is RIPE-NCC to do that monitoring (they already do in the case of dnsmon)? One can probably slice and dice this in different ways and different layers, but still, different questions. Mixed up, a mess. Patrik From jim at rfc1035.com Thu May 10 14:37:26 2007 From: jim at rfc1035.com (Jim Reid) Date: Thu, 10 May 2007 13:37:26 +0100 Subject: [enum-wg] Radio URL Message-ID: <5EC90C0D-B468-4FAF-8F28-D3F6B7278971@rfc1035.com> You can listen to an excellent business programme about internet/ telephony convergence at: http://www.bbc.co.uk/radio4/news/inbusiness/inbusiness_20040930.shtml This is the kind of thing that makes me proud to pay for the BBC. :-) From ondrej.sury at nic.cz Fri May 11 08:20:08 2007 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Fri, 11 May 2007 09:20:08 +0300 Subject: [enum-wg] DNSMON for enum zones In-Reply-To: References: <4D4CEBA7-A188-4285-812E-EFDA4381B03F@rfc1035.com> <1178777120.10748.8.camel@yuna> Message-ID: <1178864408.9478.14.camel@yuna> Jim Reid p??e v ?t 10. 05. 2007 v 12:45 +0100: > On May 10, 2007, at 07:05, Ond?ej Sur? wrote: > > > I seems to me that you are mixing "DNS monitoring" (in general) and > > "DNS > > monitoring for TLD operators". Here we are speaking about > > "monopoly for > > monopoly". > > I'm not mixing these things. From my perspective there's no > difference. I'm looking at non-core services that the NCC provide > which could and should be offered by others, not by the NCC. DNS > monitoring in any form (except for the NCC's internal operations) is > such a service IMO. The de facto monopoly in DNS monitoring that the > NCC enjoys is regrettable. The fact the NCC is in this business > distorts the market and has deterred others, including NCC members, > from entering that market. I am not sure if that market is so wide. (Still with my TLD hat on.) See my comment bellow. > What worries me is an official complaint to the competition > authorities which results in them reviewing every aspect of the NCC > operations, introducing regulation because it's a monopoly, etc, etc. Ok, I understand your worries. > > Speaking for .cz I would very much doubt that we would buy such > > commercial DNS monitoring if it wasn't from RIPE NCC. We would rather > > build some platform ourselves and offer it to other TLD operators (on > > CENTR, OARSI or whatever grounds). > > I think that proves my point. There would be more diversity and > competition in DNS monitoring services in the marketplace (such as it > is) if the NCC would leave it alone to develop naturally. Sorry, but no. You may have little bit twisted my argument to fit your needs, but my point was that: 1. there is a need to monitor TLDs 2. there is a need to save costs 3. TLD operators are very cautious when it come to outsourcing So my point was that sooner or later something like DNSMON would be created in exactly same way as it is now. Ie. joint project of TLD operators. NCC already had nice infrastructure due TTM, so it allowed to save little bit of money to create such infrastructure on green field. I don't think that DNSMON (as is done by RIPE NCC) is deforming the market, because this market is already so much deformed. Market where customers are monopoly with big share of them being not-for-profit couldn't behave normally. But that's just my opinion and it could heavily differ from "authorities" view. But I would suggest to wrap up this discussion and continue with separate points as Patrik F?ltstr?m suggested. Ondrej. -- Ond?ej Sur? technick? ?editel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americk? 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From ondrej.sury at nic.cz Fri May 11 08:36:44 2007 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Fri, 11 May 2007 09:36:44 +0300 Subject: [enum-wg] DNSMON for enum zones In-Reply-To: <7067E703-5C90-4977-91D1-7A103400928A@cisco.com> References: <4D4CEBA7-A188-4285-812E-EFDA4381B03F@rfc1035.com> <1178777120.10748.8.camel@yuna> <7067E703-5C90-4977-91D1-7A103400928A@cisco.com> Message-ID: <1178865404.9478.31.camel@yuna> Ccing to ncc-services-wg. Short summary: Discussion started on enum-wg whether DNSMON service should be extended to ENUM registry operators as well. Patrik summarized discussion so far in several points in mail I am replying at. You can find start of the thread at: http://www.ripe.net/ripe/maillists/archives/enum-wg/2007/msg00024.html Patrik F?ltstr?m p??e v ?t 10. 05. 2007 v 15:08 +0300: > I see a number of different questions being discussed here, and I > think we should try to separate them: > > 1. RIPE NCC is running DNS for e164.arpa > 2. RIPE NCC should "protect their skin" and monitor the e164.arpa > zone, so they can show their service is up to current standards Shouldn't RIPE NCC do the same for all its delegations. I would broaden scope of this point to monitoring reverse delegations as well. > 3. Registry operators run DNS for zones delegated from e164.arpa, and > the delegation itself should be of some quality for ENUM to work -- > who has responsible for this? I think that responsibility lies in registry operators hands, but NCC should do monitoring and step-in if quality is too low. I don't have idea right now what "step-in" and "quality is too low" definition is. > 4. Registry operators have interest in being monitored, should they > be monitored, or (via opt-in) on request? You probably already know my opinion on that point :-), but together with previous points it gets more complicated. If answer to 2 and 3 is YES, then I think that they should be monitored and on opt-in request they could receive results/warnings/etc. Without opt-in it would be only from RIPE NCC internal needs. > 5. If there is a need for monitoring of DNS operation, is RIPE-NCC to > do that monitoring (they already do in the case of dnsmon)? Let's put another POV in play. If DNSMON was outsourced to let's say commercial service, who will ensure quality of such monitoring? I don't think that niche in this market is so big, that it will self-regulate, because of competition. Then there would be need to _monitor_ monitoring to ensure 2 and 3. Ondrej -- Ond?ej Sur? technick? ?editel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americk? 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From brettcarr at ripe.net Mon May 21 11:30:04 2007 From: brettcarr at ripe.net (Brett Carr) Date: Mon, 21 May 2007 11:30:04 +0200 Subject: [enum-wg] ENUM-AP-53.1: RIPE NCC to examine and report on "strange queries" Message-ID: <80446E5F-6210-4798-B19A-BBA98C2C13B7@ripe.net> At RIPE 54 in Tallinn we commited to providing more detail on the queries prepended with a + in statistics generated last year: In the time period measured (April-November 2006) There were 13797 queries prepended with a + 10081 came from a single source. 2738 came from two further sources. The rest came from 100 different sources. We hope that this level of data satisfies this action point. Regards Brett -- Brett Carr Manager -- DNS Services Group RIPE Network Coordination Centre Amsterdam From pk at DENIC.DE Tue May 22 10:01:05 2007 From: pk at DENIC.DE (Peter Koch) Date: Tue, 22 May 2007 10:01:05 +0200 Subject: [enum-wg] ENUM-AP-53.1: RIPE NCC to examine and report on "strange queries" In-Reply-To: <80446E5F-6210-4798-B19A-BBA98C2C13B7@ripe.net> References: <80446E5F-6210-4798-B19A-BBA98C2C13B7@ripe.net> Message-ID: <20070522080105.GA3879@unknown.office.denic.de> On Mon, May 21, 2007 at 11:30:04AM +0200, Brett Carr wrote: > There were 13797 queries prepended with a + > 10081 came from a single source. > 2738 came from two further sources. > The rest came from 100 different sources. > > We hope that this level of data satisfies this action point. under the assumption that 60 q/day are only a tiny fraction of the traffic, it appears to me the '+' phenomenon is less prevalent than I feared after your presentation. Thanks for digging this out. -Peter From enumvoipsip.cs at schiefner.de Tue May 22 15:16:24 2007 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 22 May 2007 15:16:24 +0200 Subject: [enum-wg] ENUM status page at enumdata.org Message-ID: <4652ED28.3@schiefner.de> Dear ENUM colleagues, I have mentioned it under agenda item C. of the last ENUM WG session (cf. http://www.ripe.net/ripe/meetings/ripe-54/agendas/enum.html) already, but would like to repeat it here: If you represent an ENUM Tier 1 registry or have good contacts to one, please visit - or make them visiting, respectively - http://www.enumdata.org/ to check whether the data for that very registry provided is still correct - or not yet filled in at all. Please send any updates you may have to . Thank you for your cooperation. Best regards, Carsten Schiefner (on behalf of the ENUM WG Co-Chairs) From enumvoipsip.cs at schiefner.de Tue May 22 15:20:50 2007 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 22 May 2007 15:20:50 +0200 Subject: [enum-wg] ENUM-AP-53.1: RIPE NCC to examine and report on "strange queries" In-Reply-To: <80446E5F-6210-4798-B19A-BBA98C2C13B7@ripe.net> References: <80446E5F-6210-4798-B19A-BBA98C2C13B7@ripe.net> Message-ID: <4652EE32.7020407@schiefner.de> Brett Carr wrote: > At RIPE 54 in Tallinn we commited to providing more detail on the > queries prepended with a + in statistics generated last year: Thanks, Brett. > In the time period measured (April-November 2006) > > There were 13797 queries prepended with a + > 10081 came from a single source. Has that stopped in the meantime? > 2738 came from two further sources. > The rest came from 100 different sources. > > We hope that this level of data satisfies this action point. I recall a total of some 26,000 invalid queries - shall I take it that the remaining 12,000 ones are equally spread over all sorts of pathological queries? Thanks and best regards, Carsten From messemer at denic.de Wed May 23 17:57:48 2007 From: messemer at denic.de (Volker Messemer/Denic) Date: Wed, 23 May 2007 17:57:48 +0200 Subject: [enum-wg] Re: Status info for enumdata.org Message-ID: Dear colleagues, here is the update from Germany for the information shown on http://enumdata.org/: 1. What is the country and E.164 code? Germany, +49 2. Who is the delegate for the E.164 code? DENIC eG Wiesenh?ttenplatz 26 60329 Frankfurt Germany 3. The status of deployment (notdelegated>applied>delegated/objected>trial>hiatus>production) production 4. ENUM Project contact details (telephone, email, web) DENIC eG Wiesenh?ttenplatz 26 60329 Frankfurt Germany Tel: +49 69 27235 0 Email: enum at denic.de Web: http://www.denic.de/en/enum 5. Is a trial being, or going to be, conducted? A Trial was conducted from September 2002 to January 2006 6. What type of numbers are being used in the trial? - geographical numbers - mobile numbers - free-phone numbers - personal numbers - national numbers - service numbers 7. Is there work or plans toward full permanent deployment? Full permanent deployment has been launched in January 2006. 8. What type of numbers are to be used in full deployment? In the full deployment, the same number ranges are used as in the trial: - geographical numbers - mobile numbers - free-phone numbers - personal numbers - national numbers - service numbers 9. Who is leading the ENUM project? (government, industry working group, etc.) Industry (DENIC eG) 10. Who operates the ccTLD for that country at present? DENIC eG Wiesenh?ttenplatz 26 60329 Frankfurt Germany 11. What type of organisation runs the ccTLD? (state, private, academic, etc.) private 12. What is the ccTLD legal regulation, if any? None 13. Who is the current Tier 1 registry? DENIC eG Wiesenh?ttenplatz 26 60329 Frankfurt Germany 14. Who is, or will be, the permanent Tier 1 registry? DENIC eG Wiesenh?ttenplatz 26 60329 Frankfurt Germany 15. How will the Tier 1 registry selection be made? (i.e. decision, license, concession, agreement, public procurement, etc.) Initiative of the industry concerned 16. How will the method of cost recovery for the Tier 1 registry's operations? Charging of Domains 17. Will there be more than one Tier 1 provider for the country? No 18. Will there be ENUM registrars? Yes 19. What will be the ENUM validation technique? Various techniques were developed by the registrars during the trial phase and are used now in the production phase. 20. Is there/will there be a special number block for ENUM and/or IP Telephony? The number block for national numbers (+49 32) was intended for VoIP telephony but it is not widely used. 21. Is there special treatment for unlisted numbers? No 22. Are there any plans for infrastructure ENUM? The discussion on infrastructure ENUM has started in Q4 2006. 23. What is your ENUM WHOIS address? http://www.denic.de/en/enum-whois/index.jsp 24. Please provide the history of ENUM trials, projects etc., if any. See http://www.denic.de/en/enum/index.html 25. What are your future plans? (and dates if available) See http://www.denic.de/en/enum/index.html Kind Regards Volker Messemer -- +---------------------------------+--------------------------------+ | Volker Messemer | Tel: +49 69 27235 421 | | DENICoperations | Fax: +49 69 27235 234 | | DENIC eG | E-Mail: messemer at denic.de | | Wiesenh?ttenplatz 26 | http://www.denic.de | | 60329 Frankfurt am Main | | | DE | | +---------------------------------+--------------------------------+ | Sitz: Frankfurt am Main | | Eingetragen unter Nr. 770 im Genossenschaftsregister beim | | Amtsgericht Frankfurt am Main | | Vorstand: Andreas B??, Stephan Deutsch, Marcus Sch?fer, | | Carsten Schiefner | | Vorsitzender des Aufsichtsrats: Elmar Knipp | +---------------------------------+--------------------------------+ | PGP-KeyID: 0xDCA306E4 | | Fingerprint: FD9C 7B19 816D 59D6 33FE 2665 10F5 AB5C DCA3 06E4 | +---------------------------------+--------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6630 bytes Desc: S/MIME Cryptographic Signature URL: From Antoin.Verschuren at sidn.nl Thu May 24 10:43:37 2007 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Thu, 24 May 2007 10:43:37 +0200 Subject: [enum-wg] ENUM status page at enumdata.org Message-ID: 1. What is the country and E.164 code? The Netherlands, +31 2. Who is the delegate for the E.164 code? Stichting Enum Nederland Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands 3. The status of deployment (notdelegated>applied>delegated/objected>trial>hiatus>production) delegated 4. ENUM Project contact details (telephone, email, web) Tier-1 registry: Stichting Enum Nederland Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands Phone: +31 26 3525576 Fax: +31 26 3525577 Web: http://www.enum.nl Email: info at enum.nl Public ENUM platform: Starting June 18 2007: Web: http://www.enuminnederland.nl The public platform will discuss and advice the registry about policy. 5. Is a trial being, or going to be, conducted? No 1. What type of numbers are being used in the trial? None 6. Is there work or plans toward full permanent deployment? Yes, end of 2007 1. What type of numbers are to be used in full deployment? Will be advised by the Public ENUM platform. 7. Who is leading the ENUM project? (government, industry working group, etc.) The tier-1 registry is Stichting Enum Nederland The public ENUM platform will be industry working groups, led by ecp.nl and isoc.nl 8. Who operates the ccTLD for that country at present? SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands 9. What type of organisation runs the ccTLD? (state, private, academic, etc.) Not-for-profit 10. What is the ccTLD legal regulation, if any? None 11. Who is the current Tier 1 registry? Stichting Enum Nederland 12. Who is, or will be, the permanent Tier 1 registry? Stichting Enum Nederland 13. How will the Tier 1 registry selection be made? (i.e. decision, license, concession, agreement, public procurement, etc.) Has been done. Agreement with governament after market consultation. 14. How will the method of cost recovery for the Tier 1 registry's operations? TBD 15. Will there be more than one Tier 1 provider for the country? No 16. Will there be ENUM registrars? Yes 17. What will be the ENUM validation technique? Will be advised by the Public ENUM platform. 18. Is there/will there be a special number block for ENUM and/or IP Telephony? Yes, there are 2 numberblocks (+3185 and +3191) for VoIP services. 19. Is there special treatment for unlisted numbers? No, see also 21. 20. Are there any plans for infrastructure ENUM? TBD 21. What is your ENUM WHOIS address? ENUM does not need whois. 22. Please provide the history of ENUM trials, projects etc., if any. 2001-2002 NLEG report (see www.enuminnederland.nl) 2002 Delegation of 1.3.e164.arpa to governament (Ministry Economic Affairs) 2002-2005 No interest from market 2005 VoIP boom, sudden interest 2006 SIDN starts ENUM initiative, founds Stichting ENUM Nederland (ENUM NL) 2006 Market consultation 31-09-2006 Redelegation of 1.3.e164.arpa to Stichting ENUM Nederland 22-03-2007 Governament and ENUM NL sign agreement on terms for tier-1 registry 18-06-2007 ECP and ISOC NL launch Public ENUM platform 23. What are your future plans? (and dates if available) Operational end 2007 24. What is your date estimate on a production ENUM registry launch? See 23. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren at sidn.nl W http://www.sidn.nl/