Re: [enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt
-
To: Otmar Lendl lendl@localhost
-
From: Patrik Fältström patrik@localhost
-
Date: Mon, 6 Nov 2006 13:58:21 -0800
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@localhost 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@localhost" ; 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@localhost" ; 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@localhost"
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@localhost"
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@localhost
*.6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1@localhost
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
|
you are here: RIPE -> RIPE Maillists > Archives
