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

From: Otmar Lendl <[email-masked]>
Date: Mon, 6 Nov 2006 21:36:27 +0100

On 2006/10/05 16:10, Otmar Lendl <[email-masked]> wrote:
> 
> [There seems to be a problem with [email-masked], an earlier mail
> from me didn't make it back to my mailbox.]

Both authors of the ENUM bis / URI RR drafts don't recall receiving
this message. There _were_ problems with the mailing list, thus
yet another try to get this list of questions through to everybody.

I'll pose these in the WG session later today as well.

/ol

> 
> 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?
> 
> 
> 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:[email-masked]!"   ; 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:[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.
> 
> >    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?
> 
> -----------------------------
> 
> 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 ... "!(.*)!\\[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?
> 
> /ol
> -- 
> < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum

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

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum