[enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt
Patrik Fältström patrik at frobbit.se
Mon Nov 6 22:58:21 CET 2006
On 6 okt 2006, at 00.06, Otmar Lendl wrote: > 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: And here is my response... > 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? Yes, because I sent the draft inline instead of as an attachment... > 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? This is the key question of course. >> 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? A neutral party. Wherever we do the zone cut to "the user", "some service provider" or whoever, the delegation have to be made from a neutral party. Just like the management of the number portability database. >> $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. Yes, and they will unless under very specific circumstances accept the delegation FROM anyone else than a neutral party. I personally see similar issues with *ALL* services. This is why the ie164.arpa, or i.6.4.e164.arpa ideas from my point of view can not be the ONLY special delegations as "the telco" is only one of the service providers that think their service is special. I.e. I think we have one statement and a few questions to answer: Statement: Delegation must at some location in the tree be from a neutral party. Question 1: Where in the tree are we breaking out from neutral party delegation to special delegation? Question 2: When should "non-User ENUM" in reality NOT be in the e164.arpa tree? >> ;; 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. Yes. > > 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. You have pointed out a very good thing. We can not mix these things. That the user is responsible for the zone from which delegations are made. >> 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? Maybe that is a better example? It is still "just" a syntax to make the zone content easier to read. It in reality have nothing to do with where the cut is. BUT, you suggest this is made clearer. I should say "In the zone _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. we have the following data". > ----------------------------- > > 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. I agree. > ----------------------------- > > 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? If I understand you correctly, Telekom Austria is running telephony for the number +43 1 5056416, but then you as a user of that number can add whatever digits you want as "extensions" as the routing is prefix based. I presume as long as the number of digits totally is fewer than 15 :-) Can you "port" that prefix from Telekom Austria to someone else? Today, as you point out, there should be a zone 6.1.4.5.0.5.1.3.4.e164.arpa in which you instead of "just" having NAPTR records for the name of the zone, you have NAPTR for the extensions you have. Example (not open numbering plan): 6.1.4.5.0.5.1.3.4.e164.arpa. IN SOA ... 6.1.4.5.0.5.1.3.4.e164.arpa. IN NS ... 6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... With open numbering plan: 6.1.4.5.0.5.1.3.4.e164.arpa. IN SOA ... 6.1.4.5.0.5.1.3.4.e164.arpa. IN NS ... 3.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... 4.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... 5.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... How do you handle number portability for these numbers (that end with 33, 34 and 35)? Can they be ported one at a time, or just the whole block at the same time? On the other hand, I see problems when the email provider want to run the DNS for the NAPTR that refer to the email services they run, and further, that the delegation should be from a neutral party? I do not have an answer to your question. I think the solution will violate many of the requirements we have. Regardless of what the solution is. Good discussion, lets continue. Patrik
[ enum-wg Archives ]