From Niall.oReilly at ucd.ie Mon Apr 10 22:16:15 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Mon, 10 Apr 2006 21:16:15 +0100 Subject: [enum-wg] Revised draft agenda for ENUM WG at RIPE 52 Message-ID: <8A478118-FE10-4F55-90F6-9E21E652C659@ucd.ie> Dear ENUM-WG Colleagues, Please find below the revised draft agenda for the ENUM WG at RIPE 52. Tu 25 Apr 15:00 (Plenary): Gerhard Schroeder: Security issues in ENUM Th 27 Apr 14:00 (ENUM WG slot): Start Duration Led by Description 14:00 3' Chair A: Administrivia: Welcome, Scribe, Jabberwok 14:03 2' Chair B: Minutes ENUM-WG at RIPE 51 14:05 3' Chair C: Review Action List (see notes below) 14:08 2' Chair D: Short News (if any) 14:10 8' LV E: RIPE NCC ENUM Report 14:18 10' GS/Chair F: Follow-up on Plenary: ENUM and Security G: Presentations 14:28 20' KM G1: +1 Trial 14:48 4' JR G2: +44 Update 14:52 4' JR G3: Testbed numbers 14:56 10' AB G4: +49 Commercial Operations 15:06 5' [TBA] G5: +353 Commercial Operations X: Interaction with other RIPE WGs 15:11 10' PK X1: Walking E164.ARPA 15:21 4' CS X2: DNS-WG-AP-51.5 15:25 3' Chair Y: AOB 15:28 2' Chair Z: Close: summarize actions, thanks 90' Your co-chairs are striving to minimize the proportion of the meeting given over to administrative items. Please help by sending corrections to the RIPE 51 ENUM WG minutes by e-mail to to arrive no later than 12:00 UTC on Wednesday, 26 April. Notes for item C: Review action list 51.1 (RIPE NCC): Statistics from all e164.arpa servers. Report from NCC (Leo Vegoda?) at agenda item E 51.2 (Carsten Schiefner): Let NCC know details of missing links. Done? Carsten, please confirm to list in advance of meeting 51.3 (RIPE NCC): To check whether quarterly ENUM reports to IAB would still be necessary and asked for. Done. Changes are publicised on the enum-announce list. Report duplicates these. 51.4 (Peter Koch): Continue walking e164.arpa and report at RIPE 52. Report/presentation from PK at agenda item X 51.5 (Jim Reid): Stimulate discussion on testbed numbers/ranges. Presentation from JR at agenda item G3 51.6 (Carsten Schiefner): Cross-check on DNS-WG-AP-51.5. Mention at agenda item X 51.7 (All): Test reachability of non-geo +43 780 numbers. Done? Many people responded. Do the +43 ppl need anything more? Please will someone from +43 confirm in advance of the meeting. On Carsten's behalf as well as for myself, I hope to see all of you in Istanbul! Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group From alexander.mayrhofer at enum.at Tue Apr 11 12:11:56 2006 From: alexander.mayrhofer at enum.at (Alexander Mayrhofer) Date: Tue, 11 Apr 2006 12:11:56 +0200 Subject: [enum-wg] Re: Revised draft agenda for ENUM WG at RIPE 52 Message-ID: <443B80EC.5090700@enum.at> > 51.7 (All): Test reachability of non-geo +43 780 numbers. > Done? > Many people responded. Do the +43 ppl need anything more? > Please will someone from +43 confirm in advance of the meeting. Hi, we have a lot of data points already collected, and more and more of them are positive - so there's no urgent need for more testing. However, if anybody happens to be in an area which is still not covered, performing the test is still appreciated. The current test results are available at: http://www.voip-info.org/wiki/view/43780 Many thanks to all who participated - those tests really helped us a lot, including debugging/proofing a routing bug at a local important telco. cheers Alex From Niall.oReilly at ucd.ie Sat Apr 15 14:55:41 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Sat, 15 Apr 2006 13:55:41 +0100 Subject: [enum-wg] Speakers for ENUM WG at RIPE 52 In-Reply-To: <8A478118-FE10-4F55-90F6-9E21E652C659@ucd.ie> References: <8A478118-FE10-4F55-90F6-9E21E652C659@ucd.ie> Message-ID: <882480C6-8ABC-4E48-AAF1-2CEE05838FA9@ucd.ie> On 10 Apr 2006, at 21:16, Niall O'Reilly wrote: > Dear ENUM-WG Colleagues, > > Please find below the revised draft agenda for the ENUM WG at RIPE 52. I've had some feedback which suggests that people's initials don't tell enough of the story. I hope you'll find the list below less cryptic. Tu 25 Apr 15:00 (Plenary): Gerhard Schroeder (T-com) Security issues in ENUM Th 27 Apr 14:00 (ENUM WG slot): Leo Vegoda (RIPE NCC) E: RIPE NCC ENUM Report Gerhard Schroeder (T-com) F: Follow-up on Plenary: ENUM and Security Karen Mulberry (Neustar) G1: +1 Trial Jim Reid G2: +44 Update G3: Testbed numbers Andreas Baess (DENIC) G4: +49 Commercial Operations [TBA] G5: +353 Commercial Operations Peter Koch (DENIC) X1: Walking E164.ARPA Carsten Schiefner (T-com) X2: DNS-WG-AP-51.5 Best wishes for Easter. See you in Istanbul. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group From fw at deneb.enyo.de Sun Apr 16 11:55:10 2006 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 16 Apr 2006 11:55:10 +0200 Subject: [enum-wg] e164.arpa delegations with actual zone contents Message-ID: <87fykdsv41.fsf@mid.deneb.enyo.de> Maybe this is slightly off-topic, but which of the existing e164.arpa delegations have actual subdelegations (or in-zone NAPTR entries)? I know that +43 and +49 have already got a few delegations, and +353 has some entries as well, but what about the others? The status page at is unfortunately out of date (or reflects a very strange definition of "trial"). From fw at deneb.enyo.de Sun Apr 16 17:12:38 2006 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 16 Apr 2006 17:12:38 +0200 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: <8988D32ED5F0A02490440AE7@scan.jck.com> (John C. Klensin's message of "Tue, 18 Oct 2005 13:29:20 -0400") References: <434671EA.1050105@schiefner.de> <87k6gcxpfj.fsf@mid.deneb.enyo.de> <87ach8ukg2.fsf@mid.deneb.enyo.de> <877jcadhey.fsf@mid.deneb.enyo.de> <8988D32ED5F0A02490440AE7@scan.jck.com> Message-ID: <8764l9pna1.fsf@mid.deneb.enyo.de> * John C. Klensin: > We seem to be misunderstanding each other, and I don't why. In > particular, I don't know what you mean by "weak on > local-part-based routing" since any MTA, other than a final > delivery one, that does _any_ routing on the content of the > local part is in clear violation of the SMTP standard. I don't > know if you think an MTA is weak because it follows the standard > or weak because it violates it. RFC 2476 (SMTP Submission) does in fact allow rewriting local-parts. 8-) But I can understand that there are conceptual problems if you do this potentially on each hop. But at the time of message injection -- why not? I can assure that this is the way ENUM-based client-side mail routing will be implemented on UNIX platforms. It belongs into the local MTA, not the MUA. However, I have some doubt whether it's a good idea to promote E.164-based addressing beyond VoIP. For example, if I obtained an ENUM delegation and started hosting a copyright-infringing web site on , how would the copyright holder be able to track me down? From enumvoipsip.cs at schiefner.de Wed Apr 19 20:21:27 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 19 Apr 2006 20:21:27 +0200 Subject: [enum-wg] Revised draft agenda for ENUM WG at RIPE 52 In-Reply-To: <8A478118-FE10-4F55-90F6-9E21E652C659@ucd.ie> References: <8A478118-FE10-4F55-90F6-9E21E652C659@ucd.ie> Message-ID: <44467FA7.5050209@schiefner.de> Niall, all - Niall O'Reilly wrote: > 51.2 (Carsten Schiefner): Let NCC know details of missing links. > Done? Carsten, please confirm to list in advance of meeting I have just managed to send those details eventually. Of course, the RIPE NCC cannot be expected to have them all - or even only a single one - completely addressed before the session. Sorry for my very late "picking up my AP" - best regards and hope to see you all next week: -C. From enumvoipsip.cs at schiefner.de Thu Apr 20 10:22:12 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Thu, 20 Apr 2006 10:22:12 +0200 Subject: [enum-wg] Delegation of +359/9.5.3.e164.arpa completed Message-ID: <444744B4.6090905@schiefner.de> Dear colleagues, the ENUM delegation request for 9.5.3.e164.arpa - +359 is Bulgaria's E.164 CC - was confirmed by ITU-T TSB on 12 Apr 2006. As per yesterday, 9.5.3.e164.arpa is delegated to ns.bol.bg. [193.200.15.129] ns.bolbg.com. [193.200.15.133] Welcome, Bulgaria! :-) Best, Carsten Schiefner From veni at veni.com Thu Apr 20 12:18:29 2006 From: veni at veni.com (Veni Markovski) Date: Thu, 20 Apr 2006 06:18:29 -0400 Subject: [enum-wg] Delegation of +359/9.5.3.e164.arpa completed In-Reply-To: <444744B4.6090905@schiefner.de> References: <444744B4.6090905@schiefner.de> Message-ID: <7.0.1.0.2.20060420061702.037fccb8@veni.com> Thank you! I just found out that my first request on this list about the ENUM trial was in 2003. It took us some time :-) Best, Veni At 10:22 AM 20.4.2006 '?.' +0200, Carsten Schiefner wrote: >Dear colleagues, > >the ENUM delegation request for 9.5.3.e164.arpa - +359 is Bulgaria's >E.164 CC - was confirmed by ITU-T TSB on 12 Apr 2006. > >As per yesterday, 9.5.3.e164.arpa is delegated to > >ns.bol.bg. [193.200.15.129] >ns.bolbg.com. [193.200.15.133] > >Welcome, Bulgaria! :-) > >Best, > > Carsten Schiefner From enumvoipsip.cs at schiefner.de Thu Apr 20 16:00:35 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Thu, 20 Apr 2006 16:00:35 +0200 Subject: [enum-wg] Delegation of +359/9.5.3.e164.arpa completed In-Reply-To: <7.0.1.0.2.20060420061702.037fccb8@veni.com> References: <444744B4.6090905@schiefner.de> <7.0.1.0.2.20060420061702.037fccb8@veni.com> Message-ID: <44479403.4030405@schiefner.de> [Apologies to all other subscribers, but as it seems there currently isn't any possibility for me to take that up with Veni directly] Hi Veni, Veni Markovski wrote: > Thank you! my pleasure! :-) > I just found out that my first request on this list about the ENUM trial > was in 2003. It took us some time :-) Well, it's the result that counts, isn't it? Having said that, I'd like to ask you to look into your RBL stuff - my attempt to send you (and Dimitar) a private email, failed with: === Reporting-MTA: dns; saturn.time-travellers.org X-Postfix-Queue-ID: 1B9861471BF X-Postfix-Sender: rfc822; enumvoipsip.cs at schiefner.de Arrival-Date: Thu, 20 Apr 2006 11:18:58 +0200 (CEST) Final-Recipient: rfc822; veni at veni.com Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host mxr.isoc.bg[193.200.15.187] said: 550 5.7.1 Mail from 193.0.0.176 refused by spam.dnsrbl.net, see http://bol.bg/cgi-bin/osirusoft?193.0.0.176 (in reply to MAIL FROM command) Final-Recipient: rfc822; mitko at mitko.com Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host mx.bol.bg[193.200.15.129] said: 550 5.7.1 Mail from 193.0.0.176 refused by spam.dnsrbl.net, see http://bol.bg/cgi-bin/osirusoft?193.0.0.176 (in reply to MAIL FROM command) === Best, Carsten From Niall.oReilly at ucd.ie Wed Apr 26 09:39:15 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 26 Apr 2006 10:39:15 +0300 Subject: [enum-wg] Action list update for ENUM WG at RIPE 52 In-Reply-To: <8A478118-FE10-4F55-90F6-9E21E652C659@ucd.ie> References: <8A478118-FE10-4F55-90F6-9E21E652C659@ucd.ie> Message-ID: <311893E3-76A7-4F10-A642-5D6A58887D11@ucd.ie> Dear ENUM-WG colleagues, WVT reducing "administrative overhead" at the WG session, here is an update to the action list. Please let me know of any further details. Action points already closed: 51.2 (Carsten Schiefner): Let NCC know details of missing links. Done. NCC following up with Carsten. New action point 52.1: RIPE-NCC to complete follow-up. Thanks to Carsten and Leo Vegoda. 51.3 (RIPE NCC): To check whether quarterly ENUM reports to IAB would still be necessary and asked for. Done. Closed. Changes are publicised on the enum-announce list. Report duplicates these. Thanks to Patrik F?ltstr?m for clarifying requirement. 51.7 (All): Test reachability of non-geo +43 780 numbers. Done. Closed. Thanks from +43 ppl to all who made tests and recorded their results. Action points to be covered in ENUM WG at RIPE 52: 51.1 (RIPE NCC): Statistics from all e164.arpa servers. Report from NCC (Leo Vegoda?) at agenda item E 51.4 (Peter Koch): Continue walking e164.arpa and report at RIPE 52. Report/presentation from PK at agenda item X 51.5 (Jim Reid): Stimulate discussion on testbed numbers/ranges. Presentation from JR at agenda item G3 51.6 (Carsten Schiefner): Cross-check on DNS-WG-AP-51.5 (e164.arpa zone maintenance procedures) Mention at agenda item X. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group From paf at cisco.com Thu Apr 27 13:21:30 2006 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Thu, 27 Apr 2006 14:21:30 +0300 Subject: [enum-wg] Issues with RFC 3761 so far Message-ID: It was mentioned in the plenary this morning the ticket system I use for creation of RFC 3761bis. The issues are so far: [Please don't respond to this email, respond to the original email that describes the ticket that was sent to the ENUM wg in the IETF, or add issues to the ticket system directly...instructions I can send on request] What I have in the tracker are the following issues: #838 ORDER/PRIORITY locality ORDER and PRIORITY is significant only within the current domain. This is not clear in RFC 3761. #861 Fast lane for Enumservice IANA registration It is proposed to establish a fast lane for rIANA egistration of non- essential Enumservices using only expert review and not the full RFC cycle. #870 DDDS - RFC3404 reserves ALL flag characters RFC 3404 specifies that all flag characters are reserved "for future versions of this document". #873 Character Set, Case Sensitivity, and NAPTR fields Character Set, Case Sensitivity, and NAPTR fields. NOTE - This is really three inter-related topics. As they are so closely tied together I have requested a single ticket. #874 REGEXP 'i' flag considered harmful RFC 3402 specifies an 'i' flag that can be applied to the REGEXP field. This flag is intended to make AUS matching case insensitive. For ENUM, this is not appropriate, as the allowed characters within an AUS are all case insensitive. #875 Only one Enumservice per NAPTR the syntax for Enumservices given in RFC3761 allows for more then one Enumservice to be given, by addiing them with a '+' #878 experimental ENUM services - clash prevention ecause of the cumbersome process of ENUMservice registration, more and more experimental services are popping up. Contrary to it's intended purpose, more and more of those services are used "de facto" not only internally, but between different parties. This increases the risk of collisions between several different implementations of "experimental" ENUMservices, hence creating the need for preventing collisions between those services. Patrik From enumvoipsip.cs at schiefner.de Thu Apr 27 16:34:52 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Thu, 27 Apr 2006 17:34:52 +0300 Subject: [enum-wg] Follow up on Jim Reid's presentation today Message-ID: <4450D68C.9040100@schiefner.de> [Background: Jim Reid gave a presentation on "UK ENUM News" this afternoon during the ENUM WG session, currently available at: http://www.ripe.net/ripe/meetings/ripe-52/presentations/uploads/Thursday/reid-uk_enum_news.pdf - the following question relates to that presentation] Jim, I have a question in relation to your presentation: on the second slide it reads "Tier-1 registry appointed around October" - so my understanding is that UKEC, UKEG's successor, will not have any operational business, but will act as the delegee for 4.4.e164.arpa and have operations outsourced. Is that correct? Best, -C. From enumvoipsip.cs at schiefner.de Thu Apr 27 16:49:47 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Thu, 27 Apr 2006 17:49:47 +0300 Subject: [enum-wg] Follow up on Karen Mulberry's presentation today Message-ID: <4450DA0B.5050401@schiefner.de> [Background: Karen Mulberry gave a presentation on "Country Code 1 and the US ENUM Trial" this afternoon during the ENUM WG session, currently available at: http://www.ripe.net/ripe/meetings/ripe-52/presentations/uploads/Thursday/mulberry-country_code_1_and_the_us_enum_trial.pps - the following questions relate to that presentation] Karen, I have two questions in relation to your presentation: Q1: The number resources the FCC is meant to set aside for the ENUM trial - will they cover all US geographic area codes or is that somehow limited? If so, what will be the limits or restrictions? Q2: In slide 5, 9 and 10 you mention the "Trial Participants Advisory Committee (TPAC)", what roles will be involved when in the trial and what documentation TPAC is meant to produce. I just wonder to what extent the users - aka. number holders, aka. ENUM domain name registrants - will be involved, as they seem to not be mentioned explicitly? Thanks, Carsten From jay at nominet.org.uk Thu Apr 27 23:41:31 2006 From: jay at nominet.org.uk (Jay Daley) Date: Thu, 27 Apr 2006 22:41:31 +0100 Subject: [enum-wg] Follow up on Jim Reid's presentation today In-Reply-To: <4450D68C.9040100@schiefner.de> Message-ID: Carsten > I have a question in relation to your presentation: on the second slide > it reads "Tier-1 registry appointed around October" - so my > understanding is that UKEC, UKEG's successor, will not have any > operational business, but will act as the delegee for 4.4.e164.arpa and > have operations outsourced. Is that correct? Given the perilous potential for the whisky BoF I will get the answer in on Jim's behalf. UKEC will be the delegee for 4.4.e164.arpa, it will outsource the registry operation but will maintain the policy function for UK ENUM. It may also have a role to play in accreditation of some parties (AA?) and code of conduct issues by those players. Jay From jim at rfc1035.com Fri Apr 28 02:46:15 2006 From: jim at rfc1035.com (Jim Reid) Date: Fri, 28 Apr 2006 01:46:15 +0100 Subject: [enum-wg] Follow up on Jim Reid's presentation today In-Reply-To: <4450D68C.9040100@schiefner.de> References: <4450D68C.9040100@schiefner.de> Message-ID: <4CF6292C-B9AA-42C9-B11C-ABAB203ECE61@rfc1035.com> On Apr 27, 2006, at 15:34, Carsten Schiefner wrote: > I have a question in relation to your presentation: on the second > slide it reads "Tier-1 registry appointed around October" - so my > understanding is that UKEC, UKEG's successor, will not have any > operational business, but will act as the delegee for 4.4.e164.arpa > and have operations outsourced. Is that correct? Not quite though that's the general idea. The government's attitude is ENUM is an industry matter and it's best run by industry. It should be self-regulating too: codes of conduct, accreditation, broad stakeholder participation, that sort of thing. The government's role is to be a facilitator and to make sure ENUM operates in the UK in the broad public interest with appropriate safeguards for fair competition, consumer protection and the like. The government will delegate (not in a DNS sense) UK ENUM oversight to UKEC. UKEG will develop policy, codes of conduct, handle accreditation, deal with complaints and so forth. Its major task will be to select a Tier1 registry operator and to decide how that contract is awarded. The general concept for UKEC will be comparable to how ICSTIS, a self-regulating industry body, oversees the provision of premium-rate telephone services in the UK. It's conceivable, but probably unlikely, that the Tier 1 registry contract could be awarded to an organisation that then chooses to outsource registry operations to a company providing that service. If UKEC fails to exercise proper oversight, the government could decide that some other entity should take charge of ENUM in the UK. Of course these are my personal opinions and must not be viewed as an official statement by UKEG/UKEC or Her Majesty's Government or anyone else. From jim at rfc1035.com Fri Apr 28 10:26:30 2006 From: jim at rfc1035.com (Jim Reid) Date: Fri, 28 Apr 2006 09:26:30 +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.20060428083810.04f00410@inode.at> References: <4450D68C.9040100@schiefner.de> <7.0.1.0.2.20060428083810.04f00410@inode.at> Message-ID: <3B3DCAE1-C0BC-4F77-AA5C-4476FF518C5F@rfc1035.com> On Apr 28, 2006, at 07:58, Michael Haberler wrote: > I'm a bit puzzled though about your slides where you mention > "CRUE" (Carrier Registration in User ENUM) and its potential > international interoperability aspects. > > currently the IETF work on Infrastructure ENUM is progressing > nicely - I expect the long-run solution to be a separate apex (like > ie164.arpa for instance) and http://www.enum.at/ietf/draft-haberler- > carrier-enum-02.html will be the backwards-compatible interim > solution until ITU and friends have their act together. Looks like > all this is done this year. This will provide a easy manageable > home for carrier-related information. Michael, CRUE has no bearing whatsoever on Infrastructure ENUM. This will be apparent when the CRUE document is published on the new UK ENUM web site. [I'll make an announcement about that when it goes on- line.] The object of CRUE is to get lots of meaningful data into the UK ENUM tree so that ENUM-aware applications can be encouraged because there's a better chance of getting a successful ENUM lookup. The scheme is simple. Communications Service Providers register a block of numbers. This gets verified against the regulator's public database of block allocations to CSPs. The registry enters 2 NAPTRs for these numbers: a tel: URI and a sip: URI. The only "control" the CSP has here is the name of the SIP server: ie how non-PSTN calls can be terminated on their network. Now there's a lot of detail about ported numbers, allocation to end users and so forth. But that still doesn't make CRUE a replacement for "Infrastructure ENUM" whatever that happens to mean today. BTW I don't share your optimism that standardisation of Carrier ENUM can be completed this year. But let's not jump down that rat-hole. > I'm a bit concernced about diverging developments - maybe you can > enlighten us where you're heading and how this will interoperate > with the rest of us. CRUE is not a "standard". Or a protocol. It's just a means to get lots of NAPTRs populating the 4.4.e164.arpa name space. So there are no interoperability issues. From Richard.Stastny at oefeg.at Fri Apr 28 10:51:02 2006 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Fri, 28 Apr 2006 10:51:02 +0200 Subject: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work Message-ID: <32755D354E6B65498C3BD9FD496C7D462C49C6@oefeg-s04.oefeg.loc> Hi Jim, >BTW I don't share your optimism that standardisation of Carrier ENUM >can be completed this year. But let's not jump down that rat-hole. For terminolgy: Carrier ENUM needs not to be standardized, it is Infrastructure ENUM. I agree that the long-term soltution cannot be standardized this year, because the earliest (optimistic) possible date is January 2007 JWhat Michael wanted to say is that the temporary solution defined in the Dallas treaty can be nationally implemented soon (as you will see) and could be ready for publication request this fall, so it could be used also internationally in a standadized way. Another question for clarification about CRUE: You mention that for each number a tel and an sip URI is entered. this requires each operator to provide a ingress element to their network How can this be done? Richard ________________________________ Von: enum-wg-admin at ripe.net im Auftrag von Jim Reid Gesendet: Fr 28.04.2006 10:26 An: Michael Haberler Cc: enum-wg at ripe.net Betreff: Re: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work On Apr 28, 2006, at 07:58, Michael Haberler wrote: > I'm a bit puzzled though about your slides where you mention > "CRUE" (Carrier Registration in User ENUM) and its potential > international interoperability aspects. > > currently the IETF work on Infrastructure ENUM is progressing > nicely - I expect the long-run solution to be a separate apex (like > ie164.arpa for instance) and http://www.enum.at/ietf/draft-haberler- > carrier-enum-02.html will be the backwards-compatible interim > solution until ITU and friends have their act together. Looks like > all this is done this year. This will provide a easy manageable > home for carrier-related information. Michael, CRUE has no bearing whatsoever on Infrastructure ENUM. This will be apparent when the CRUE document is published on the new UK ENUM web site. [I'll make an announcement about that when it goes on- line.] The object of CRUE is to get lots of meaningful data into the UK ENUM tree so that ENUM-aware applications can be encouraged because there's a better chance of getting a successful ENUM lookup. The scheme is simple. Communications Service Providers register a block of numbers. This gets verified against the regulator's public database of block allocations to CSPs. The registry enters 2 NAPTRs for these numbers: a tel: URI and a sip: URI. The only "control" the CSP has here is the name of the SIP server: ie how non-PSTN calls can be terminated on their network. Now there's a lot of detail about ported numbers, allocation to end users and so forth. But that still doesn't make CRUE a replacement for "Infrastructure ENUM" whatever that happens to mean today. BTW I don't share your optimism that standardisation of Carrier ENUM can be completed this year. But let's not jump down that rat-hole. > I'm a bit concernced about diverging developments - maybe you can > enlighten us where you're heading and how this will interoperate > with the rest of us. CRUE is not a "standard". Or a protocol. It's just a means to get lots of NAPTRs populating the 4.4.e164.arpa name space. So there are no interoperability issues. From mah at inode.at Fri Apr 28 11:29:02 2006 From: mah at inode.at (Michael Haberler) Date: Fri, 28 Apr 2006 11:29:02 +0200 Subject: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work In-Reply-To: <3B3DCAE1-C0BC-4F77-AA5C-4476FF518C5F@rfc1035.com> References: <4450D68C.9040100@schiefner.de> <7.0.1.0.2.20060428083810.04f00410@inode.at> <3B3DCAE1-C0BC-4F77-AA5C-4476FF518C5F@rfc1035.com> Message-ID: <7.0.1.0.2.20060428105008.03959610@inode.at> At 10:26 28.04.2006, Jim Reid wrote: >Michael, CRUE has no bearing whatsoever on Infrastructure ENUM. This >will be apparent when the CRUE document is published on the new UK >ENUM web site. [I'll make an announcement about that when it goes >on- line.] The object of CRUE is to get lots of meaningful data into the >UK ENUM tree so that ENUM-aware applications can be encouraged >because there's a better chance of getting a successful ENUM lookup. > >The scheme is simple. Communications Service Providers register a >block of numbers. This gets verified against the regulator's public >database of block allocations to CSPs. The registry enters 2 NAPTRs >for these numbers: a tel: URI and a sip: URI. The only "control" the >CSP has here is the name of the SIP server: ie how non-PSTN calls can >be terminated on their network. Now there's a lot of detail about >ported numbers, allocation to end users and so forth. But that still >doesn't make CRUE a replacement for "Infrastructure ENUM" whatever >that happens to mean today. Jim - 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? That would mean basically that a NXDOMAIN in UE can be used for "no such number" (SIT) signaling immediately (that is - before bouncing it to the PSTN to have that figure it out later), right? Is it just blocks or can do you plan to add portability-corrected NAPTR's as well, like npd:tel URI's? I agree that populating the tree helps resolution rates, and we're following a similar route publishing block allocation information, but in the Infrastructure ENUM tree where I think it belongs more naturally - plus it retains full operator control over the type of information they publish (which we've learned to be a key issue). If this is a first step to a DNS-based NPD directory, I'm unsure wether the UE tree is the right place to base that information. 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?). But let's assume that happens - what is the semantics of such a SIP URI for a) an end user and b) an operator - can I bounce a call to sip:number at bt.com if I find in 4.4.e164.arpa and it returns such a registry-entered sip URI? Can I (do I need to?), as a end-user, distinguish who entered which record? What if I have a IP Interconnect agreement with BT / what if not? I would assume BT might have an opinion here.. Tony? >CRUE is not a "standard". Or a protocol. It's just a means to get >lots of NAPTRs populating the 4.4.e164.arpa name space. So there are >no interoperability issues. I think publishing blocks for real-time lookup is a potentially useful idea and it looks like it is more of a "best current practice" topic. BUT - the way you describe it: you're setting the rule on who enters what and if there is more than one way to publish this information I still think there is a interoperability issue because semantics of different public trees diverge. Let me encourage you to bring this idea forward beyond the UK ENUM group and work on consensus on how to do this - -Michael From Richard.Stastny at oefeg.at Fri Apr 28 12:35:27 2006 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Fri, 28 Apr 2006 12:35:27 +0200 Subject: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4F19@oefeg-s04.oefeg.loc> > But let's assume that happens - what is the semantics of such a SIP > URI for a) an end user and b) an operator - can I bounce a call to > sip:number at bt.com if I find in 4.4.e164.arpa and it returns > such a registry-entered sip URI? Can I (do I need to?), as a > end-user, distinguish who entered which record? What if I have a IP > Interconnect agreement with BT / what if not? I would assume BT might > have an opinion here.. Tony? IMHO this could only work, especially in User ENUM, if this Sip?:number at bt.com;user=phone is used purely to indicate a Service Provider ID (SPID). The domain name given is not resolvable in the public DNS, only within the providers DNS (as proposed yesterday by GSMA with the Local Routing Tables (LRT). One way to clearly distinguish from routable SIP entries would be to use an new enumservice called e.g. SPID to indicate that the domain name has to be resolved by other means. In this case the users may simply ignore enumservice spid because they cannot use it. This enumservise may also be useful in Infrastructure ENUM to distinguish between ENUM entries routable on the public Internet and pure SPID entries (e.g. gsmaworld.com) Richard From enumvoipsip.cs at schiefner.de Sun Apr 30 18:35:31 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Sun, 30 Apr 2006 19:35:31 +0300 Subject: [enum-wg] +43 Infrastructure ENUM - contract concluded Message-ID: <4454E753.1040708@schiefner.de> All, I am not entirely sure why Michael's mail did not yet show up here, but anyways: here is another attempt to spread the news. Best, Carsten -------- Original Message -------- Subject: [Enum] +43 Infrastructure ENUM - contract concluded Date: Fri, 28 Apr 2006 09:37:48 +0200 From: Michael Haberler To: enum-wg at ripe.net,enum at ietf.org,ga at centr.org enum.at GmbH, operator of the +43 User ENUM registry, and RTR GmbH, the Austrian regulator,have concluded and signed a contract extension to the +43 ENUM operating contract on April 20, 2006, enabling enum.at GmbH to provide Infrastructure ENUM as currently standardized in the IETF. Service is scheduled to start next month. press releases (in german - english to follow:) http://www.portel.de/news/view_redsys_artikel.asp?id=10293 RTR: ?sterreich baut weltweite Vorreiterrolle bei ENUM aus ... Portel.de - Germany Wien, 27.04.06-11:45 Mit der Vertragserweiterung, die ie enum.at GmbH und RTR-GmbH am 18. April 2006 unterzeichnet haben, ist... http://www.ots.at/presseaussendung.php?schluessel=OTS_20060427_OTS0163&ch=technologie ?sterreich baut weltweite Vorreiterrolle bei ENUM aus APA OTS (Pressemitteilung) - Austria Wien (OTS) - "Mit der Vertragserweiterung, die enum.at GmbH und RTR-GmbH am 18. April 2006 unterzeichnet haben, ist es in ?sterreich ... the contract addendum (also german, english translation to follow as well:) http://www.rtr.at/web.nsf/deutsch/Telekommunikation_Nummerierung_ENUM/$file/ENUM_Vertragsnachtrag.pdf Richard Stastny blog comment: http://voipandenum.blogspot.com/2006/04/infrastructure-enum-in-austria-on-its.html Michael Haberler Internet Foundation Austria From enumvoipsip.cs at schiefner.de Sun Apr 30 18:42:08 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Sun, 30 Apr 2006 19:42:08 +0300 Subject: [enum-wg] Follow up on Jim Reid's presentation today In-Reply-To: <4CF6292C-B9AA-42C9-B11C-ABAB203ECE61@rfc1035.com> References: <4450D68C.9040100@schiefner.de> <4CF6292C-B9AA-42C9-B11C-ABAB203ECE61@rfc1035.com> Message-ID: <4454E8E0.9060506@schiefner.de> Jim, Jay - thanks for your answers. Jim Reid wrote: > [...] > > The government will delegate (not in a DNS sense) UK ENUM oversight to > UKEC. UKEG... That should read "UKEC" both times, right? > ...will develop policy, codes of conduct, handle accreditation, > deal with complaints and so forth. [...] Best, -C. From jim at rfc1035.com Sun Apr 30 18:56:34 2006 From: jim at rfc1035.com (Jim Reid) Date: Sun, 30 Apr 2006 17:56:34 +0100 Subject: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C49C6@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C49C6@oefeg-s04.oefeg.loc> Message-ID: <52B3F22B-05E1-44AD-9E00-4E3BAD6F1CF7@rfc1035.com> On Apr 28, 2006, at 09:51, Stastny Richard wrote: >> BTW I don't share your optimism that standardisation of Carrier ENUM >> can be completed this year. But let's not jump down that rat-hole. > > For terminolgy: Carrier ENUM needs not to be standardized, > it is Infrastructure ENUM. For some definition of these terms. Maybe. :-) No matter what is meant by Carrier ENUM or Infrastructure ENUM, these two things presumably must agree on a name space. Though not necessarily with each other. That choice of name space or zone apex surely must entail standardisation somewhere. Or have I missed something? > JWhat Michael wanted to say is that the temporary solution defined > in the Dallas treaty can be nationally implemented soon (as you > will see) > and could be ready for publication request this fall, so it could > be used > also internationally in a standadized way. If you're referring to draft-haberler-carrier-enum-02.txt, I think you are being far, far too optimistic. This draft is badly flawed in too many ways to elaborate here. A discussion on that belongs in another thread and I'll be happy to initiate this debate. > Another question for clarification about CRUE: > > You mention that for each number a tel and an sip URI is entered. > this requires each operator to provide a ingress element to their > network > > How can this be done? I imagine the hostname lurking in the sip: URI would do that. No? From jim at rfc1035.com Sun Apr 30 19:33:38 2006 From: jim at rfc1035.com (Jim Reid) Date: Sun, 30 Apr 2006 18:33:38 +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.20060428105008.03959610@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> Message-ID: <763F6687-AE33-49E5-9148-4A7BFF11F27C@rfc1035.com> > 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. > That would mean basically that a NXDOMAIN in UE can be used for "no > such number" (SIT) signaling immediately (that is - before bouncing > it to the PSTN to have that figure it out later), right? Nope. All that can be inferred from an NXDOMAIN for a number in this scheme is it's not in the DNS. A number could have been ported to another provider and the end user for that number hasn't done anything about entering it into the public DNS. The number could still be in use even if it's not in the DNS. Or it might be in the twilight world between "not allocated to a customer" and "ready for re-use". IIRC Lawrence and Richard made a compelling case for the void: service type NAPTR to be used to indicate whenever a number was not in use. I see no justification for disagreeing with that point of view. > Is it just blocks or can do you plan to add portability-corrected > NAPTR's as well, like npd:tel URI's? The idea is that if a number is ported, it drops out of the CRUE block. The end user for that number could still register it using the standard User ENUM registration process and have its ENUM zone delegated to them. End user registrations will always supersede a CRUE entry. This was the detail I alluded to earlier. And now wish to postpone further discussion about until the new web site is up with all of the UK ENUM documents. > 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. :-) > But let's assume that happens - what is the semantics of such a SIP > URI for a) an end user and b) an operator - can I bounce a call to > sip:number at bt.com if I find in 4.4.e164.arpa and it > returns such a registry-entered sip URI? Can I (do I need to?), as > a end-user, distinguish who entered which record? Michael, you're looking for complexity and scenarios that simply don't exist. The client just does a lookup in the public 4.4.e164.arpa tree. If that returns a sip: URI, the client may (or may not) -- it's the client's choice -- try to speak SIP to the named SIP server. It neither knows or cares about how that SIP URI was entered or who put it there. And it doesn't matter whether that client is an end-user or an "operator" is irrelevant. They're just clients on the public internet doing regular DNS lookups. > What if I have a IP Interconnect agreement with BT / what if not? I > would assume BT might have an opinion here.. Tony? 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. > I think publishing blocks for real-time lookup is a potentially > useful idea and it looks like it is more of a "best current > practice" topic. BUT - the way you describe it: you're setting the > rule on who enters what and if there is more than one way to > publish this information I still think there is a interoperability > issue because semantics of different public trees diverge. Michael, I'm trying not to get angry with you. :-) There is only one public tree: e164.arpa. Anything else is not ENUM and not worthy of consideration here. CRUE only uses the UK public ENUM tree. 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. 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. From jim at rfc1035.com Sun Apr 30 19:40:52 2006 From: jim at rfc1035.com (Jim Reid) Date: Sun, 30 Apr 2006 18:40:52 +0100 Subject: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4F19@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D463C4F19@oefeg-s04.oefeg.loc> Message-ID: <499A6FEC-D9AB-4F86-A576-7B49CC6B86E2@rfc1035.com> On Apr 28, 2006, at 11:35, Stastny Richard wrote: > IMHO this could only work, especially in User ENUM, if this > Sip?:number at bt.com;user=phone is used purely to indicate a > Service Provider ID (SPID). The domain name given is not resolvable > in the public DNS, only within > the providers DNS (as proposed yesterday by GSMA with the Local > Routing Tables (LRT). Richard, your assumption is wrong. Any SIP URI's entered through CRUE live in the PUBLIC 4.4.e164.arpa tree. They should be resolvable on the public internet. If they're not, there's no point in those SIP URIs existing or being visible in the public DNS. If a provider wants to put unresolvable names on the internet, then that's their funeral. I wouldn't recommend that because it's bad for the operational health of the internet. It would be as dumb as publishing hostnames with unreachable RFC1918 addresses on the public internet. From mah at inode.at Sun Apr 30 19:56:00 2006 From: mah at inode.at (mah at inode.at) Date: Sun, 30 Apr 2006 19:56:00 +0200 (CEST) Subject: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work In-Reply-To: <52B3F22B-05E1-44AD-9E00-4E3BAD6F1CF7@rfc1035.com> References: <32755D354E6B65498C3BD9FD496C7D462C49C6@oefeg-s04.oefeg.loc> <52B3F22B-05E1-44AD-9E00-4E3BAD6F1CF7@rfc1035.com> Message-ID: <81.223.16.194.1146419760.wm@webmail.inode.at> > On Apr 28, 2006, at 09:51, Stastny Richard wrote: ... >> JWhat Michael wanted to say is that the temporary solution defined in ... > > If you're referring to draft-haberler-carrier-enum-02.txt, I think you > are being far, far too optimistic. This draft is badly flawed in too > many ways to elaborate here. A discussion on that belongs in another Jim - we're all very very eager to hear and discuss your most helpful contributions. Help make the world a better place and stamp out such badly flawed drafts. To do so, please: a) detail your concerns on the IETF ENUM WG list (that's where this stuff is being discussed) b) in time (that is, like half a year ago, but late adopters welcome) c) including facts, so you actually convince people d) [optional] make a better proposal (those which yield a really loud hum). I'll support you on your superior superior proposal. -Michael From jim at rfc1035.com Sun Apr 30 21:23:40 2006 From: jim at rfc1035.com (Jim Reid) Date: Sun, 30 Apr 2006 20:23:40 +0100 Subject: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work In-Reply-To: <81.223.16.194.1146419760.wm@webmail.inode.at> References: <32755D354E6B65498C3BD9FD496C7D462C49C6@oefeg-s04.oefeg.loc> <52B3F22B-05E1-44AD-9E00-4E3BAD6F1CF7@rfc1035.com> <81.223.16.194.1146419760.wm@webmail.inode.at> Message-ID: > we're all very very eager to hear and discuss your most helpful > contributions. > > Help make the world a better place and stamp out such badly flawed > drafts. > > To do so, please: > > a) detail your concerns on the IETF ENUM WG list (that's where this > stuff > is being discussed) > b) in time (that is, like half a year ago, but late adopters welcome) > c) including facts, so you actually convince people > d) [optional] make a better proposal (those which yield a really > loud hum). I have done a, b, and c already on the IETF mailing list and will be happy to do so again. > I'll support you on your superior superior proposal. You'll have a very long wait because it's not clear to me what the actual problem is or what its requirements are. And yes, I know you have a list of requirements in the draft. But they don't define what problem space(s) fit them. That said, it is clear that your draft can't be the answer because it combines two mutually exclusive concepts -- User ENUM and Infrastructure ENUM -- on the same infrastructure. From Karen.Mulberry at neustar.biz Sun Apr 30 23:02:21 2006 From: Karen.Mulberry at neustar.biz (Mulberry, Karen) Date: Sun, 30 Apr 2006 17:02:21 -0400 Subject: [enum-wg] Follow up on Karen Mulberry's presentation today Message-ID: Carsten, My responses Q1: The number resources the FCC is meant to set aside for the ENUM trial - will they cover all US geographic area codes or is that somehow limited? If so, what will be the limits or restrictions? The US trial committee participants are identifying the geographic areas (NPAs) and the amount of numbers they require to conduct their ENUM test cases. Since the FCC has not responded to the wavier request with any restrictions or limits, there are none that I am aware of at this time. Trial participants do not expect to have limits placed on them beyond what the USG terms and conditions called for - that all numbers to be used in the US ENUM trial must be allocated under wavier by the FCC. Q2: In slide 5, 9 and 10 you mention the "Trial Participants Advisory Committee (TPAC)", what roles will be involved when in the trial and what documentation TPAC is meant to produce. I just wonder to what extent the users - aka. number holders, aka. ENUM domain name registrants - will be involved, as they seem to not be mentioned explicitly? The trial MOU calls for trial participants to identify what role or roles they intend to play in the US trial. The ones that I outlined in my presentation are the options that a trail participant can choose from. Such as number holders are identified as End Users and ENUM Domain Name Registrants once they have been authenticated and verified. There are several parties that have indicated that they intend to be End Users for the trial. Also the TPAC will produce reports on its trial activities on a monthly basis for the CC1 ENUM LLC. Initially these reports should contain the organizational plans (who is playing what role(s)) and test case development associated with the three phases of the trial. Once the trial starts, I expect that the monthly reports will contain the results of the tests that have been run during that month. Once the trial has ended, a final report that summarizes all activities and results will be complied for the LLC. Karen Mulberry Neustar Inc. -----Original Message----- From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] On Behalf Of Carsten Schiefner Sent: Thursday, April 27, 2006 8:50 AM To: enum-wg at ripe.net Subject: [enum-wg] Follow up on Karen Mulberry's presentation today [Background: Karen Mulberry gave a presentation on "Country Code 1 and the US ENUM Trial" this afternoon during the ENUM WG session, currently available at: http://www.ripe.net/ripe/meetings/ripe-52/presentations/uploads/Thursday /mulberry-country_code_1_and_the_us_enum_trial.pps - the following questions relate to that presentation] Karen, I have two questions in relation to your presentation: Q1: The number resources the FCC is meant to set aside for the ENUM trial - will they cover all US geographic area codes or is that somehow limited? If so, what will be the limits or restrictions? Q2: In slide 5, 9 and 10 you mention the "Trial Participants Advisory Committee (TPAC)", what roles will be involved when in the trial and what documentation TPAC is meant to produce. I just wonder to what extent the users - aka. number holders, aka. ENUM domain name registrants - will be involved, as they seem to not be mentioned explicitly? Thanks, Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: