- enum-wg - mailman.ripe.net

9.3.e164.arpa down
by Klaus Darilion 23 Nov '06

23 Nov '06

Hi! The Italian ENUM name servers are down/broken. This will cause lots of trouble (long call setups) for ITSPs which perform ENUM lookups. How should we handle such situations? By RIPE (deleting the delegation), by monitoring registries and skipping ENUM lookup for certain countries? AFAIR this is not the first problem with 9.3.e164.arpa regards Klaus -- Klaus Darilion nic.at

9 13

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