October 2006 - enum-wg - mailman.ripe.net

Re: [Enum] draft-ietf-enum-uri-00.txt
by Otmar Lendl 08 Nov '06

08 Nov '06

The IETF enum list seems to be broken, but as Paf explained his proposal at the RIPE meeting in A'dam this week, here is a copy of my reply: ----- Forwarded message from Otmar Lendl <lendl(a)nic.at> ----- Date: Thu, 5 Oct 2006 16:21:40 +0200 From: Otmar Lendl <lendl(a)nic.at> To: Patrik Fältström <paf(a)cisco.com> Cc: IETF ENUM WG <enum(a)ietf.org> Subject: Re: [Enum] draft-ietf-enum-uri-00.txt On 2006/09/28 11:09, Patrik Fältström <paf(a)cisco.com> wrote: > This document was requested to be published the other day, but > publication seems to take some time. Thanks for the document, here are some question: > > 1. > Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Applicability > Statement . . . . . . . . . . . . . . . . . . . 3 The formatting is a bit off (not only here, but also in the rfc-editor repository), could you please submit a version without unwanted line-breaks, and with page breaks? Concerning this example: > 6.2. Different providers for services for the same E.164 > > An organisation have the E.164 +442079460148, but different > organisations handle routing of calls for the number on the Internet > (with the help of SIP) and traditional PSTN. More specifically, the > two providers want to run DNS for the record(s) that refer to the > services they provide. I think I understand the pure DNS mechanics you propose. What I can't see right now is how this proposal fits into the Tier0/Tier1/ITSP/end-user scheme of actors. Where are the zone cuts and who is operating which zone? > The ENUM provider for the +44 country code in this case not only do > delegations on the full E.164 number, but delegations on the service > parameter values, as can be seen below: > > In this example we also include the NAPTR records that with the help > of the 'D' flag refer to the URI records. We also include NAPTR > records according to RFC 3761 [RFC3761] that give backward > compatibility. > > In zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.: Who do you propose should run that zone? > $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. > > ;; NAPTR records that refer to URI records > IN NAPTR 1 1 "D" "E2U:sip" ( ; service > "" ; regexp > _sip._e2u ; replacement > ) > > IN NAPTR 1 1 "D" "E2U:tel" ( ;service > "" ;regexp > _tel._e2u ;replacement > ) This record is *important* to the telco running the phone service for this number. They won't want to live with the possibility that users can mess up the telco internal routing. > > ;; NAPTR records for RFC 3761 compatibility > IN NAPTR 1 1 "U" "E2U:sip" ( ;service > "!.*!sip:+442079460148@sipprovider.net!" ; regexp > . ; replacement > ) In the current model, this record is supposed to be hosted on a user-controlled server. This puts us into a bind: > IN NAPTR 1 1 "U" "E2U:tel" ( ;service > "!.*!sip:+442079460148@sipprovider.net!" ; regexp > . ; replacement > ) > > ;; Delegations to child zones > _sip._e2u IN NS ns1.example.net. > _tel._e2u IN NS ns1.example.com. Once again, the I-ENUM records are dependent on the management of the pure ENUM zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. > In zone _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa: > > > $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. > _sip._e2u IN URI "sip:+442079460148@example.net" Shouldn't that be $ORIGIN _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. @ IN URI "sip:+442079460148@example.net" to indicate where the zone-cut is? ----------------------------- To summarize: If I were to start an ENUM deployment from scratch, this proposal is fine (except, see below). In this case, I'd put the IN NAPTR 1 1 "D" records in the Tier1 zone (autocreated based on *._e2u entries) and just delegate (optionally) the _sip._e2u subdomains to subscribers or ITSPs. That way, the DNS infrastructure of one application can be kept independent from the one of another application. The problem is the legacy 3761 support: For all the delegated domains out there, it is not acceptable for the carriers to go to their subscribers and asks them for a delegation of _tel._e2u. That ain't going to fly. In order to make the transition, current ENUM users need to provision their existing NAPTRs into the registry. That's going to be a headache for everybody who managed to get a 3761-based system up and running. ----------------------------- The showstopper: And then there is the issue of open numbering plans. I can't see how this scheme is supposed to work in a country where PBX operators are free to define their own variable-length dialplan behind their pilot number. Consider the example of enum.at's Vienna office: Our pilot number is +43 1 5056416. That's a normal (i.e. not shortened) Vienna number. We use 2-digit extension, e.g. -33 is my phone. A common scheme is to use prefixes for FAX to Email services. In our case -933 is supposed to deliver an incoming FAX to my mailbox. Our carrier (Telekom Austria) doesn't know or even care about these arrangements. In ENUM terms, right now we have a delegation for 6.1.4.5.0.5.1.3.4.e164.arpa and simply add new extensions to our zone file and be done with it. In I-ENUM, Telekom Austria (were they to take part in our trial) would use wildcards to direct calls to their ingress point, e.g. by 6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1(a)sip.telekom.at! *.6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1(a)sip.telekom.at! Which records should Telekom Austria provision under your scheme? /ol -- < Otmar Lendl (lendl(a)nic.at) | nic.at Systems Engineer > ----- End forwarded message ----- -- < Otmar Lendl (lendl(a)nic.at) | nic.at Systems Engineer >

3 4

Request for trial delegation of the 2.5.e164.arpa
by Carsten Schiefner 24 Oct '06

24 Oct '06

Francisco, first of all, let me express my happiness to see that also Mexico intends to join in ENUM. I have a question though, regarding your application - in the "SUPPLEMENTAL COMMENTS" section you state: === This is a trial delegation for the +52 code, for the purpose of conducting technical tests. [...] === What kind of technical tests would you think of, where do you see a need for further testing? I specifically ask that question having in mind that both, Netherlands and the Czech Republic, recently revealed plans to go into commercial operations directly, basically leaving out any trial phase as they seem to see no need for further trials. Best, Carsten -------- Original Message -------- Subject: [enum-announce] Fw: NCC#2006103092 [Request for trial delegation of the 2.5.e164.arpa] Date: Tue, 24 Oct 2006 11:19:34 +0200 From: RIPE NCC Staff <enum-request(a)ripe.net> Reply-To: RIPE NCC Staff <enum-request(a)ripe.net> To: enum-announce(a)ripe.net, richard.hill(a)itu.int ----- Begin forwarded message ----- Date: Mon, 23 Oct 2006 11:50:52 -0500 From: Francisco Arias <farias(a)nic.mx> To: enum-request(a)ripe.net Subject: NCC#2006103092 Request for trial delegation of the 2.5.e164.arpa Message-Id: <20061023165052.918B9182C2E(a)mail.nic.mx> ENUM Request Form RIPE NCC Doc-ID: ripe-384 Date: August 2006 % ENUM Request Form % You can use this form to request ENUM delegation of an E.164 country code. % Submit the completed form to <enum-request(a)ripe.net>. % Please see ripe-385 for instructions on how to complete this form. #[GENERAL INFORMATION]# % % Please do not change the value of the two fields below. request-type: enum form-version: 1.0 #[REQUESTER DETAILS]# % % Please add your contact details. name: Francisco Arias phone: +52 81 8387 5346 fax-no: +52 81 8387 5346 e-mail: farias(a)nic.mx #[ORGANISATION DETAILS]# % % Which organisation is requesting the delegation? legal-organisation-name: Network Information Center Mexico, S.C. organisation-location: Av. Eugenio Garza Sada 427 Sur. Locales 4, 5 y 6 organisation-location: Col. Altavisa, C.P. 64840 organisation-location: Monterrey, Nuevo Leon, Mexico website: http://www.nic.mx #[DATABASE TEMPLATE]# % % Please complete all of the fields below. domain: 2.5.e164.arpa descr: Network Information Center Mexico, S.C. org: ORG-NICM1-RIPE admin-c: OARG tech-c: FJAC zone-c: GLI nserver: a.ns.mx nserver: b.ns.mx nserver: c.ns.mx nserver: d.ns.mx mnt-by: NICMX-MNT changed: hostmaster(a)ripe.net source: RIPE #[SUPPLEMENTAL COMMENTS]# % % Please add more information if you think it will help us understand % this request. This is a trial delegation for the +52 code, for the purpose of conducting technical tests. This delegation is given by the CFT authority in Mexico. #[END of REQUEST]# ------------------------------------------------ Francisco J. Arias IT Director Network Information Center México Phone & Fax: +52 81 8387 5346 http://www.nic.mx .MX is the new way to say Mexico The content of this data transmission is confidential, therefore, it shall not be modified, distributed and/or disclosed through any mean without the original sender's previous authorization. Any information, offer or agreement made by the sender of this data transmission, should be consider as personal and not binding for NIC Mexico. ------ End forwarded message ------

1 0

ENUM Day Australia
by Kewin Stoeckigt 24 Oct '06

24 Oct '06

Hi all, Please find attached a flyer for the upcoming ENUM Day seminar, which will be held in Sydney on 15 November 2006. The FREE seminar will be jointly conducted by ACMA, AusRegistry International, AARNet and Instra Corporation. More detailed information and links to the ENUM Day website are contained in the flyer. See you on the 15th of November. Kewin P.S. Hope this is not considered to be Spam :-)

1 0

Proposal for new org-type
by Antoin Verschuren 19 Oct '06

19 Oct '06

Hi all, In order for ENUM registries to be correctly distinguished in the RIPE NCC database, I want to propose a new organization type to be used in the organization object. Current organization types are: IANA RIR NIR LIR NON-REGISTRY I would like this list to be extended with the term REGISTRY. I will note the issue tomorow in the ENUM WG, but need consensus to take place here, so please comment either here or tomorrow in the ENUM WG session. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

5 6

RE: [enum-wg] Concerning Wildcards and I-ENUM
by Antoin Verschuren 13 Oct '06

13 Oct '06

Niall O'Reilly wrote: > % dig @ns-pri.ripe.net e164.arpa axfr \ > | awk '($4 == "NS") && (/^[0-9]/) { print $1 }' \ > | sort | uniq > > Perhaps it's worth considering desirable administrative constraints > on the Tier-0 zone, in order to make some such method fornmally > (rather than accidentally) possible? This was sort of what I was thinking about, but not sure if it's a good idea. It would build further on the EBL record which was supposed to be a temporary solution. But now that we see that a demand for more ENUM space might arise, I wonder if it's the right path to do that in the countrycode's zone, or in the e164.arpa zone to allow separation of registries and their authorisation independent of the User ENUM registry, or perhaps in a complete different zone per ENUM application. The latter would require only one lookup, where the first needs 3. Cashing for countrycode discovery could be quite long, as it rarely changes, but NS records in e164.arpa could change more often. I wonder if countrycode discovery could have another benefit for applications besides branche discovery. Perhaps billing (dirty word), legal regime, specific numberplan properties, distance calculation or whatever gadget they might come up with might need countrycode awareness anyway. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

2 1

RE: [enum-wg] 1.3.e164.arpa consultations
by Antoin Verschuren 13 Oct '06

13 Oct '06

Carsten Schiefner wrote: > Antoin, > > in your presentation last week you mentioned the deadline of 9 Oct for > the consultation on the 1.3.e164.arpa re-delegation to Stichting ENUM > Nederland. > > Any outcome you could already share? No, not yet. Our ministry is now evaluating the responses they got. Some responses might need an official statement from the government so they need some time to prepare that. They will come with an official statement on October 25th, which will also be the approval or non-approval for the redelegation request. >From what I hear unofficially in the market from people that responded, there are no real showstoppers, just some recommendations for the legal entity, some binding rules regarding validation, and no automatic approval for infrastructure ENUM without market consultation. We are happy to discuss these recommendations. I did not hear about oppositions to our plan, but then again I don't know all the responses. We'll see in 12 days. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

1 0

1.3.e164.arpa consultations
by Carsten Schiefner 12 Oct '06

12 Oct '06

Antoin, in your presentation last week you mentioned the deadline of 9 Oct for the consultation on the 1.3.e164.arpa re-delegation to Stichting ENUM Nederland. Any outcome you could already share? Best, -C.

1 0

RE: [enum-wg] Concerning Wildcards and I-ENUM
by Antoin Verschuren 11 Oct '06

11 Oct '06

Otmar Lendl wrote: > draft-ietf-enum-branch-location-record-00 does solve this, as it > provides a mechanism how new ENUM application can be directed to > their own trees. But it forces the application to know all countrycodes in a static list, and do an extra lookup. If it would be a queryable dynamic list, it would need an extra lookup too, but at least the application does not need to be countrycode aware, it could just look it up. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

3 2

RE: [enum-wg] Proposal for new org-type
by Antoin Verschuren 09 Oct '06

09 Oct '06

Jim Reid wrote: > On Oct 3, 2006, at 09:35, Antoin Verschuren wrote: > >> I would like this list to be extended with the term REGISTRY. >> >> I will note the issue tomorow in the ENUM WG, but need consensus to >> take place here, so please comment either here or tomorrow in the >> ENUM WG session. > > I strongly support the idea of having a new organisation type to > describe ENUM "registries". I was actually going to sugest ENUM-REGISTRY as org type. But RIPE NCC told me they'd favoured the term REGISTRY, probably so they could also use it for other registries not active in the RIR world. Perhaps they have the intention to sell their database to registration organisation for car license plates or whatever. Would thy then need to introduce another org-type ? (License-plate-REGISTRY). So should I change the proposal to be ENUM-REGISTRY ? Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

8 11

RIPE 52 draft minutes
by Carsten Schiefner 09 Oct '06

09 Oct '06

Dear colleagues - First of all, our sincerest apologies for not having posted the minutes earlier - we definitely see room for improvement here... Secondly, a warm "Thank you!" to Alex Le Heux of the RIPE NCC for taking the minutes. The first draft is available at: http://www.ripe.net/ripe/wg/enum/minutes/r52-minutes.html Please send in any comments and/or corrections you may have to this list directly and/or to <enum-wg-chair(a)ripe.net>, the deadline for this is Tuesday, 3 Oct 2006, 12:00 UTC/14:00 Amsterdam local time. Further objections acceped in person at WG session, with immediate decision on dealing with them at the meeting (could need more time on list). In the absence of any objections, the minutes will be declared "final" Monday, 9 Oct 2006. Best, Carsten (on behalf of the ENUM WG Co-Chairs) === ENUM Working Group Minutes from RIPE 52 RIPE Meeting: 52 Working Group: ENUM Status: Draft Revision Number: 1 * content to enum-wg-chair(a)ripe.net * format to webmaster(a)ripe.net RIPE 52 - Ceylon Intercontinental Hotel - Bosphorus II - 20060427 - 14:00-15:30 Session Chair: Niall O’Reilly Scribe: Alex Le Heux (RIPE NCC) Jabber: Catherine Carr (RIPE NCC) Webcast and Feedback Archives: http://www.ripe.net/ripe/meetings/ripe-52/sessions-archive.html A: Chair - Start: 14:04 Administrivia: Welcome, Scribe, Jabberwok Niall O'Reilly: Welcome everyone. B: Chair - Start: 14:05 Minutes ENUM-WG at RIPE 51 Niall O'Reilly: There were no extra comments. Any objections? Silence. Minutes RIPE 51 approved. C: Chair - Start: 14:06 Review Action List Niall O'Reilly: 51.2: Carsten has let the RIPE NCC know the missing links and the RIPE NCC is following up -> Action Item 52.1 51.3: Not needed. Done. Niall O'Reilly: Please do boring stuff in between the meetings, so we can do interesting stuff at the meetings. 51.7: Thanks to everyone who helped the Austrians with testing the +43780, lots of people did. They couldn't come, but sent apologies. D: Chair - Start: 14:07 Short News (if any) Carsten Schiefner: No short news really. There is some news about IETF ENUM WG about standardisation. IETF takes infrastructure ENUM into account as well now. Two ideas: 1. Separate .arpa domain; 2. Follow the Austrian approach, branch location register in the normal e164.arpa tree. The problem is that there is only public user ENUM in e164.arpa, which isn't very helpful for infrastructure providers because in public user ENUM it is the user who decides first of all if he or she wants to be part of ENUM and register the phone number as ENUM domain, and secondly, the Infrastructure provider has no control over what the user puts there. For peering purposes there needs to be some infrastructure ENUM in place. The Dallas treaty solved this in Dallas: Short term: Follow branch location register approach. Long term: Separate 2nd level domain in .arpa. E: Leo Vegoda - Start: 14:10 RIPE NCC ENUM Report Presentation is at: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-ncc-upd… Daniel Karrenberg: A comment: Total queries we get at the e164.arpa service is not the total ENUM queries. We should probably add a sentence saying so, before we see strange things in the media. Jim Reid: Are the statistics for the RIPE NCC's e164.arpa servers? Leo Vegoda: Yes, only the NCC's servers. Carsten Schiefner: Intention to gather other statistics from the other e164.arpa operators? Leo Vegoda: We didn't do that this time. From the minutes of RIPE 51 I thought just the RIPE NCC's statistics were enough. If there is demand, we can try to put something together. Niall O'Reilly: That's what you were asked for this meeting. It would be good maybe for RIPE 53. Action item 52.2 -> Widen the stats. Carsten Schiefner: Documentation of communications in a zip file proposal is fine for me. Is that fine with the group? Niall O'Reilly: To the list. Action item 52.3 -> Stimulate that on the list. F: Gerhard Schröder - Start: 14:22 Follow-up on the Plenary presentation: ENUM and Security Presentation is at: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-enum… Niall O'Reilly: Are there questions from the group? Gerhard Schröder: Introduction to his plenary presentation. Maybe the presentation was at the wrong place. When we made the transit from classic telephony to SIP+ENUM, we wanted to know what the risks were. We have a lot of experience in ISDN telephony in security and misuse. Patrik Fältström, Cisco: A comment: You talked about infrastructure ENUM. In the IETF people think infrastructure ENUM are records that are visible in the public DNS. That's not the same definition as you use. PRESENTATIONS Karen Mulberry - Start: 14:26 G1: +1 Trial Presentation is at: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-1.pdf Carsten Schiefner on Slide 4: Does the trial have an end date set already? Karen Mulberry: the idea is to have the trial run for 6 months, we need a waiver and numbers from the FCC. After that it takes 30 days. So we don't know when it begins and when it ends. Canada is also looking at starting a trial. Niall O'Reilly: Will you come often to the RIPE Meetings? Your timing is very good! Karen Mulberry: I'd love to! Martin Felt: Carriers are interested in interconnecting in North America, that needs to be solved and how ENUM will be used. The US Government guidelines state that there won't be infrastructure ENUM. In your mind, will that prevent everyone to come together? Karen Mulberry: The value is in the infrastructure ENUM, not really in the user ENUM today. Maybe in the future, but not right now. In essence what the USG said is that we authorised a delegation and we'll take it away if you don't do what we say. There will be an industry discussion about how to proceed, but first we will proceed with the e164.arpa trial as that will educate the government organisations and satisfy them. Daniel Karrenberg: In your trial there's not a lot of info about verification. Are you trialling that as well? Karen Mulberry: Two providers that are authentication/verification agents. We have lot of different databases that drive the public network. They are looking at what process to use, but we will work through it. Daniel Karrenberg: It will be in the trial? Karen Mulberry: Yes is will. It's also the concern of the FTC. Daniel Karrenberg: Two organisations that see business in this? Karen Mulberry: Yes, two ISPs that see opportunity in this. Gerhard Schröder: Thank you Karen. One slide shows privacy/security! Thank you for this! I'd like to propose to add this security feature to the working list. Niall O'Reilly: I'm not sure what you have in mind. Gerhard Schröder: It would be worthwhile to discuss security and privacy Issues in the WG. Niall O'Reilly: This is a problem of telco and data protection regulators. But it would be interesting to hear what is developing. We won't put this on our WG action list, but we will be making a call for the agenda at RIPE 53 with some interesting people. The privacy experts are not in the room, we're all technical people. Gerhard Schröder: It's also a feature of a product. Karen Mulberry: In the US we're talking about contact info and DNSsec. We're not sure if we're going forward with that. Patrik Fältström, Cisco: When I hear people talk about privacy and ENUM, I feel that no fingerpointing is important. There are people in this room that mix up the ability of one organisation to find out what customers that a competitor has with the ability of organisation to know information about individuals. Gerhard Schröder: Will DNSsec able to solve all sec features for ENUM? With DNSsec we can't make a trusted tree, just a trusted chain. We need to deal with the security for each user. Niall O'Reilly interrupts: We are out of time, let's move this to the mailing list. We don't have time to explore these questions in any meaningful way. Thank you Karen. Jim Reid - Start: 14:56 G3: Test bed numbers Presentation is at: URL: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-testbed… Jim Reid: Does the WG care about a test bed, should we try to progress it? Working Group hums: <not really> Niall O'Reilly: Action Item 51.5 stays open for now. Niall O'Reilly: Would it help to have some allocations from other regulators? Jim Reid: Yes, it doesn't matter which numbers we get, just where they terminate. Niall O'Reilly: From the point of diversity? Jim Reid: I don't know. Niall O'Reilly: Let's move this to the mailing list. Jim Reid - Start: 15:01 G2: +44 Update Presentation is at: URL: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-44.pdf Martin Felt: Is CRUE temporary? Jim Reid: I'm not sure. Peter Koch: Are the specifications for CRUE are available? Are there wildcards? Jim Reid: No wildcards, the specifications will be available, it's not yet as the website isn't up yet. Jay Daley, Nominum: It will be available in 4 weeks. Jim Reid: If you want a copy, let me know, I'll send it. Andreas Bäß - Start: 15:07 G4: +49 Commercial Operations Presentation is at: URL: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-49.pdf Niall O'Reilly: 5600 domains? Are those multiblocks or all the same? Andreas Bäß: I've not checked, so there are blocks in there too. Niall O'Reilly: Validation is for a year. Coupling the timers for validation with quarantining between number holder before reassigning to customers? Andreas Bäß: No idea how the quarantining is done, so no. Daniel Karrenberg: I'm a happy +49 customer. I had several calls of people who had used ENUM to find the sip gateway. Any idea how many complaints about authentication? Andreas Bäß: So far none. Conor Daly - Start: 15:20 G5: +353 Commercial Operations Presentation is at: URL: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-353.pdf No questions. Interaction with other WGs Peter Koch - Start: 15:23 X1: Walking E164.ARPA Presentation is at: URL: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-still-c… Daniel Karrenberg: Why the short TTLs on NAPTR records? Peter Koch: Probably for follow me services. Ed Lewis: Low TTLs are a disaster. All: <agree> Daniel Karrenberg: A comment: NAPTR records for non-leaf nodes can be real and useful. Some people have shorter numbers. Niall O'Reilly: Do you want Leo to talk to Andrei about DNS quality, the availability of servers? Peter Koch: It was a customer server, not a Tier1 server. It had 5000 delegations though. Niall O'Reilly: Let's move this to the list. Carsten Schiefner - Start: 15:34 X2: DNS-WG-AP-51.5 Niall O'Reilly: This was action 51.6 in this WG, 51.5 in DNS WG Carsten Schiefner: The RIPE NCC will put e164.arpa under the reverse delegation checker regime. Still need discussion about what to do when a lame delegation is detected. Niall O'Reilly: Close action? Or keep open? Carsten Schiefner: Close it. AOB None Action Items Number Who Item 51.5 Jim Reid Stimulate discussion on testbed numbers/ranges. 52.1 RIPE NCC Follow up on the missing links reported by Carsten, pending the discussion in 52.3. 52.2 RIPE NCC Widen the e164.arpa server statistics to include other servers than just those of the RIPE NCC. 52.3 Carsten Schiefner Stimulate discussion on the list about the format of the communications documentation on the site (currently .zip). [Meeting closed.]

1 1

RE: [enum-wg] Concerning Wildcards and I-ENUM
by Antoin Verschuren 09 Oct '06

09 Oct '06

Otmar Lendl wrote: > Corrolary: The ENUM v2 scheme that Patrick and Olof came up with will > neither solve User-ENUM vs. I-ENUM branching, nor will it be suitable > for an I-ENUM deployment in a country with an open numbering plan. > > Please convince me that I'm wrong about this one. Hi Otmar, I have expressed the same worries about it, and Patrick and Olaf considder this a layer nine issue rather than something they're trying to solve. Not only for open numbering plans, but also for block allocations, ENUM v2 offers no solution for the authority over the delegation problem. I considder this the real issue, and even though ENUM v2 will solve direct querying for specific records, the increase in delegation points will not have any value for non fixed length numbers, and might even confuse people even more. But they do have a valid point when they say that any (new) type of operator might claim their own tree to control their ENUM space, and we need a solution for that. I think that differentiating should take place as close to the root as possible to make sure that implementation is the same around the world, and applications know where to query. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

2 1

Concerning Wildcards and I-ENUM
by Otmar Lendl 09 Oct '06

09 Oct '06

During Robert's talk on Infrastructure ENUM in Austria I heard some harrumphes on the mentioning of us using wildcard records. While I can see that wildcards are a dangerous issue, I really doubt that we can avoid them in our setting. I've explained the issue recently to the Denic ENUM list; here is an English version of the argument: The basic premise on the Denic list was that end-users should roll out their ENUM zones instead of using wildcards (especially as the new wildcard behavior as defined by RFC4592 can lead to unexpected result due to "empty non-terminals"). In order to roll out a wildcard into individual entries you need to know the number length used within that PBX or more generally, that prefix. This is certainly a non-issue in all countries which have fixed length telephone numbers. Germany and Austria use open numbering plans, though, where e.g. PBX operators are free to devise their own schemes behind their pilot number. For user-ENUM this is not a problem, as the PBX maintainer is also the DNS admin for the ENUM zone: he knows what numbering-plan he has implemented on the PBX, he thus can generate the appropriate (non-wildcard) NAPTR records in his own ENUM zone file. Infrastructure ENUM is different, though: We (as the Registry) see only the number blocks as given from the NRA to the carriers, and not a) the length of numbers assigned to subscribers b) whatever extensions the subscribers themselves add to those numbers. Right now, PBX operators do not have to tell their carriers about extension they provision on their PBXs. They don't even have to be constant length, schemes where -9XX is the FAX box of -XX are common. The same is true for direct calls to voice-mail. In other words, the carriers themselves often don't know the length of telephone numbers within their own blocks. They just know the length of the pilot number they have give out to their customers. This, too can vary quite a bit: Consider Vienna (+43 1), where the current rules say: * "normal" number length is 7 digit. (e.g. +43 1 5056416) * Carriers usually get blocks of 10000 numbers, e.g. +43 1 236* * Customers connected via ISDN PRIs can apply for shorter number, down to 5 digits, e.g. +43 1 59966) * There are two legacy 4 digit numbers, +43 1 4177 and +43 1 4000 (University and City Hall). * In all cases customer are free to define their own extension numbers up to a total number length of 14 digits (under certain circumstances, 15 is legit as well). For the default number length in Vienna, this means e.g. +43 1 5056416 ABCD. There are now two issues: 1) Is there a way for us to learn about the length of numbers in use? 2) If not, can't we just roll out the zone anyway? ad 1): For that to happen, all PBX operators (That need not be an enterprise. A simple ISDN BRI in P2P mode is enough) need to tell their carriers about their installation and the carriers need forward that information (plus all their normal assignment info (which also can vary within a block) to us so that we can generate the proper non-wildcard records. This is extremely unlikely to happen. ad 2) consider e.g. the record *.6.3.2.1.i.3.4.e164.arpa. NAPTR 10 10 "u" "E2U+sip" "!^(.*)$!sip:\\1@enum.sil.at!" . which corresponds to +43 1 236, which is a block owned by Silverserver. This one is provisioned in our I-ENUM database as one single record. Let's assume we roll that out to cover all possible assignement: there are 4 digits Silverserver can assign and 4 more that the customer can add. This means 8 digits, thus 10^8 possible records. Shorter numbers are of course also possible, so we have to add another 10^4 + 10^5 + 10^6 + 10^7 records. A full roll-out of this one single block add thus 111 million NAPTR records to our zonefile. This is not a viable option for us. -------------- Thus: For I-ENUM in Austria, we need wildcards. Corrolary: The ENUM v2 scheme that Patrick and Olof came up with will neither solve User-ENUM vs. I-ENUM branching, nor will it be suitable for an I-ENUM deployment in a country with an open numbering plan. Please convince me that I'm wrong about this one. /ol -- < Otmar Lendl (lendl(a)nic.at) | nic.at Systems Engineer >

2 1

Questions concerning CRUE
by Otmar Lendl 09 Oct '06

09 Oct '06

Jim, yesterday's session was bit tight in terms of time for questions, thus here they come on the list. There are a few points where I'm not sure I understand the CRUE proposal, so please correct me if I got this wrong: * The registry will not provision any CRUE records just by themselves. * The main difference between CRUE entries and normal delegations are: + CRUE records are requested by the carrier, and not the end-user. + CRUE records are validated by public Ofcom block allocation data, vs. whatever you do for normal user-enum + CRUE records use NAPTRs in the registry vs. normal delegations based on NS records in the Tier1 zone * From the point of the ENUM client which just cares about NAPTR records, there is no difference between Numern->URI mappings provided by CRUE records and normal user-enum NAPTR records. Some more questions: * You said that the registry makes no assumptions on the reachability of the SIP URIs contained in the CRUE record. What about the carriers interested in CRUE? Did you talk to them about their plans? One of the reasons we started the I-ENUM trial here was the fact that some of the operators refused to run open servers and wanted detailed control on whom they peer with. * What about ported numbers? From what I know about the .uk system, Ofcom doesn't hold information about those. * CRUE entries will be provisioned by the number-owning carrier: Will they have to send a CRUE request for every single number, or will there be a block-provisioning interface? If yes, will that make use of the NAPTR regexp feature to have identical NAPTR records for whole blocks? Thanks, /ol -- < Otmar Lendl (lendl(a)nic.at) | nic.at Systems Engineer >

2 1

Thank you
by Niall O'Reilly 05 Oct '06

05 Oct '06

On behalf of both co-chairs, I'ld like to say a warm "thank you" to all who made the RIPE 53 ENUM WG session so interesting by presenting material, and especially to the NCC staff who delivered support services for the meeting: minute-taking, jabber monitoring, and technical support. For myself, I'ld like to thank my co-chair, Carsten Schiefner, for all his work in preparation for the meeting. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group

2 1

RE: [db-wg] Re: [enum-wg] Proposal for new org-type
by Antoin Verschuren 05 Oct '06

05 Oct '06

Per Heldal wrote: > On Wed, 2006-10-04 at 09:47 +0200, Antoin Verschuren wrote: > [snip] >> I can see a reason for the term "REGISTRY" if RIPE intends to expand >> heir services to more than IP network services, and doesn't feel to >> create a long list of different marketing terms for different >> organisations. I work for a ccTLD registry that is not an LIR, and >> even though that is a clear Internet registry function like IANA, >> RIR or LIR, RIPE currently does not supply a service for that >> function that requires an entry in the DB. >> >> Conclusion: >> I can live with ENUM-REGISTRY, REGISTRY, OTHER or no org-type at all. >> I cannot live with the org-type NON-REGISTRY. >> >> My prefference would be the ENUM-REGISTRY org-type. > > > This proposal is taking things out of context. The word REGISTRY in > RIPE-terms means an IP-address registry. Nothing more, nothing less. > That your organisation is categorised as NON-REGISTRY by RIPE doesn't > mean that RIPE does not acknowledge your role as a registry in some > other context, just that you're not an ip-addr registry. Should the > database contain exceptions for all kinds of registries which happen > to deal with something else than ip-addresses? That's why we changed the proposal to change the NON-REGISTRY into OTHER. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

2 1

RE: [db-wg] Re: [enum-wg] Proposal for new org-type
by Antoin Verschuren 05 Oct '06

05 Oct '06

leo vegoda wrote: > Do people find org-type values like IANA, RIR, LIR and so on useful? > If not, maybe we just need two values: REGISTRY for IANA, RIRs, LIRs, > TLDs and Tier 1 ENUM operators and NON-REGISTRY for everyone else. > However, if people really find the hierarchical distinctions in the > current org-type values useful, maybe we need some additional > granularity for the different kinds of domain registries? > > If the extra granularity is useful, perhaps we need to allow > organisations to have multiple org-type values? That's probably > preferable to having multiple objects for a single organisation. It depends on what is is supposed to be used for in the DB. If is is needed to distinguish types of organisations when making queries, the types makes sense. But if it's only there to give a label and it is never used, it doesn't. I wouldn't mind changing the "NON-REGISTRY" into "OTHER", like I now have to apply for a RIPE meeting. But on the other hand, if RIPE wants to use it as a differentiation of their customers, and this would be expressed in the RIPE DB, I think ENUM-REGISTRY would be appropriate, and I would also find it logical I can register at a RIPE meeting as "ENUM-REGISTRY". It's then just a customer type. I can see a reason for the term "REGISTRY" if RIPE intends to expand heir services to more than IP network services, and doesn't feel to create a long list of different marketing terms for different organisations. I work for a ccTLD registry that is not an LIR, and even though that is a clear Internet registry function like IANA, RIR or LIR, RIPE currently does not supply a service for that function that requires an entry in the DB. Conclusion: I can live with ENUM-REGISTRY, REGISTRY, OTHER or no org-type at all. I cannot live with the org-type NON-REGISTRY. My prefference would be the ENUM-REGISTRY org-type. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

4 3

RE: [enum-wg] Proposal for new org-type
by Antoin Verschuren 05 Oct '06

05 Oct '06

Marco d'Itri wrote: > On Oct 03, leo vegoda <leo(a)ripe.net> wrote: > >> Do people find org-type values like IANA, RIR, LIR and so on useful? >> No. What would be the point? As Leo pointed out: Looking back into the mail archives for 2003 and 2004 I think the original purpose was to let people know how close to the End User the registration on a block of IP addresses was. If my memory is correct, the org-type was introduced after it was felt that status attribute values like "ALLOCATED-BY-IANA" or "ALLOCATED-BY-RIR" would overburden the status attribute syntax unnecessarily. One of the possible functionality could be that you'd not like to contact certain organisations holding numberblocks when abuse comes from them since you will know these numbers are distributed in a specific fashon, and you'll probably be not reaching an end user. Don't know if such routines are used. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

1 0

Documentation of ENUM requests
by Carsten Schiefner 05 Oct '06

05 Oct '06

Dear colleagues, on 3 Sep I have sent the email quoted below to the list. Other than stated in the last sentence, we felt it necessary - in particular in the absence of any so far - to solicit for more input and therefore to extend the discussion period. I have just given a short, one slide presentation in the ENUM WG session which is (temporarily only?) available at: https://www.ripe.net/ripe/meetings/ripe-53/presentations/uploads/Wednesday/… (PPS, no PDF yet). Please find a TXT version here: Advantages Disadvantages ZIP file containing Less hits when searching, Potentially large ZIP all documents concept of a „single file file to download for per case“, easy just a small piece maintenance: just put of information additional stuff in the ZIP file Separate files, all Good overview, well Many hits when linked on a structured filing, concept searching, per-country basis we had already potentially confusing – maybe still not all relevant documents returned Please be invited to comment at to let the WG know about your preferrences. Regards, Carsten Schiefner (for the ENUM WG Co-Chairs) -------- Original Message -------- Subject: [enum-wg] Documentation of ENUM requests Date: Sun, 03 Sep 2006 15:38:21 +0200 From: Carsten Schiefner <enumvoipsip.cs(a)schiefner.de> To: enum-wg(a)ripe.net Dear colleagues, this is to start a discussion - if necessary - on how the RIPE NCC is supposed to document ENUM requests. As a short recap: 1.6 of the "IAB Instructions to the RIPE NCC Regarding operation of the domain e164.arpa ("ENUM")" [http://www.ripe.net/enum/instructions.html] mandates that "all communication regarding the application for a specific delegation is to be publicly archived". That used to be done from the overview page at: http://www.ripe.net/enum/request-archives/ by a link to the respective E.164 CC specific page, eg. Germany at: http://www.ripe.net/enum/request-archives/enum-request-arch+49/ An archived snapshot of the overview page is available at: http://web.archive.org/web/20030826073846/http://www.ripe.net/enum/request-… The RIPE NCC has now proposed a way of documentation where - instead of having a separate page per E.164 CC request - the overview page links to ZIP archives that would contain all sorts of communication like emails, scanned letters and faxes etc. pp. I intend to set the deadline for this discussion to the WG session at RIPE 53 - please be invited to voice any concerns, suggenstions etc. here on the list until then. Best, Carsten Schiefner

2 1

RE: [enum-wg] Proposal for new org-type
by Antoin Verschuren 04 Oct '06

04 Oct '06

Niall O'Reilly wrote: > This message has two purposes. > > It is addressed to the ENUM WG with the purpose of determining > consensus in this WG on the proposal from Antoin Verschuren. To let there be no misunderstanding, the final proposal with most consensus so far is: >> In order for ENUM registries to not be misinterpreted in the RIPE >> NCC database, I want to propose to change an organization type to be >> used in the organization object. >> Current organization types are: >> >> IANA >> RIR >> NIR >> LIR >> NON-REGISTRY >> >> I would like this NON-REGISTRY to be changed to OTHER. > > I will declare consensus in the ENUM WG unless objections to Antoin's > proposal are posted on the ENUM WG mailing list before 12:00 UTC on > Thursday, 18 October 2006. Regards, Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

1 0

.8.5.3.e164.arpa launched commercially
by Carsten Schiefner 03 Oct '06

03 Oct '06

Dear ENUM WGers, it was with great pleasure when I read Juhani's email quoted below. Congratulations to FICORA and a prospering future to all coming ENUM efforts in Finland! Best, Carsten (on behalf of the ENUM WG Co-Chairs) -------- Original Message -------- Subject: [centr-ga] .8.5.3.e164.arpa launched commercially Date: Tue, 3 Oct 2006 12:35:05 +0300 From: Juselius Juhani <juhani.juselius(a)ficora.fi> To: <ga(a)centr.org> Dear Colleagues, Ficora launched .8.5.3.e164.arpa user ENUM into public commercial operation yesterday after succesfull pilot phase that started in 2003. The database was cleared between the pilot phase and commercial operation and thus there are no delegations at the moment. Our next aim is to get as much support from telcos and registrars for ENUM as possible. Currently I'm optimistic for their support since we are having good discussions with all major Finnish telcos. Kind Regards, Juhani

1 0

ENUM WG Agenda at RIPE 53
by Niall O'Reilly 03 Oct '06

03 Oct '06

The current version of the agenda is available at https://www.ripe.net/ripe/meetings/ripe-53/presentations/uploads/ Wednesday/oreilly-enum_wg_agenda.pdf Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group

1 0