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