[There seems to be a problem with enum@ietf.org, an earlier mail
from me didn't make it back to my mailbox.]

On 2006/09/28 11:09, Patrik Fältström <paf@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 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@sip.telekom.at!
*.6.1.4.5.0.5.1.3.4.e164.arpa  NAPTR ... "!(.*)!\\1@sip.telekom.at!

Which records should Telekom Austria provision under your scheme?

/ol
-- 
< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum