Subject: Re: [enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt

From: Patrik Fältström <[email-masked]>
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 <[email-masked]> 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:[email-masked]!"   ; 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:[email-masked]!"   ; 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:[email-masked]"
>
> Shouldn't that be
>
> $ORIGIN _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
> @ IN URI "sip:[email-masked]"
>
> 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 ... "!(.*)!\\[email-masked]!
> *.6.1.4.5.0.5.1.3.4.e164.arpa  NAPTR ... "!(.*)!\\[email-masked]!
>
> 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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 6 Nov 2006 23:17:35 +0100

[quick reply to just answer some question on open numbering plans.]

> prefix based. I presume as long as the number of digits totally is  

Correct. 

Yes.

> 5.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ...

Correct. This actually quite efficient as you just have to maintain
a single zone for the full PBX and not one per extension.

(On the other hand, this s*cks for us as the ENUM registry as 
we can only sell a single delegation to big corporate PBXs.)

> 33, 34 and 35)? Can they be ported one at a time, or just the whole  

Porting is only possible at the number level, not on the extension
level. For that example, we can take +43 1 5056416 plus all
existing extensions to a different operator, but we can't port
out individual extensions like +43 1 5056416 33.

(This is similar to the email/domain porting question that
came up here at the ietf meeting just now: Domains can be "ported",
and take all email addresses with them.)

> Good discussion, lets continue.

Indeed.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 07 Nov 2006 09:57:52 +0100

On 6 okt 2006, at 00.06, Otmar Lendl wrote:
    > The IETF enum list seems to be broken,

This is not the first time I've seen this claim. However, how this
list seems to be broken is never specified. Did you checked the
archives whether it really didn't make the list? What was the
response of the list software when you send something that didn't
make the list? When did "the list" broke? Your list maintainers
want to know what is going on so they can correct this. Just repeating
that the list is broken is unproductive.

	jaap

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 8 Nov 2006 00:00:13 +0100

On 2006/11/07 09:11, Jaap Akkerhuis <[email-masked]> wrote:
> Just repeating that the list is broken is unproductive.

Just for the record here: This was an issue about one month ago.
There was enough off-list diagnosing and communication which got the
problem to be resolved.

I mentioned the issue on the list only to explain why I resent
mails (some people might have received some mails multiple times).

/ol