[enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt
Otmar Lendl lendl at nic.at
Fri Oct 6 09:06:56 CEST 2006
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 at nic.at> ----- Date: Thu, 5 Oct 2006 16:21:40 +0200 From: Otmar Lendl <lendl at nic.at> To: Patrik Fältström <paf at cisco.com> Cc: IETF ENUM WG <enum at ietf.org> Subject: Re: [Enum] draft-ietf-enum-uri-00.txt On 2006/09/28 11:09, Patrik Fältström <paf at 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 at 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 at 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 at 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 at 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 at sip.telekom.at! *.6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1 at sip.telekom.at! Which records should Telekom Austria provision under your scheme? /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > ----- End forwarded message ----- -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer >
[ enum-wg Archives ]