Subject: AW: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt

From: "Martin Streller" <[email-masked]>
Date: Tue, 8 Jul 2003 14:22:58 +0200

Hello, please see below,
Btw, with customers I also include institutions, like Marian.
Martin

    >>>>> "Marian" == Marian Durkovic <[email-masked]> writes:

        Marian> The approach of having one record per every PBX extension
        Marian> is perhaps usable in trials, but it does not scale. Our
        Marian> institutions typically have 3-digit extensions, the larger
        Marian> ones 4-digit extensions. Having this in mind you can
        Marian> easily find yourself in the situation, where e.g. 300
        Marian> customers generate as much as 1 million records. If
        Marian> there's 1 million records in top-level domain, you have 1
        Marian> milion customers to cover the costs. But what will be the
        Marian> cost per customer, if the number of customers is 300 ?

    I don't understand the point you're trying to make here. You seem to
    be saying something "won't scale" for 300 names but somehow scales
    just fine for 1 million names. I'm confused. And you've still to
    explain why provisioning NAPTRs for each number -- something you said
    was trivial -- couldn't be done and why a wildcard RR was the only
    possible solution to the problem you're trying to solve. Despite what
    you said earlier, this still looks to me that the wildcard has been
    suggested as a kludge to work around a provisioning problem. And a
    straightforward one at that.

        Marian> The approach with wildcards generates only 300 records per
        Marian> 300 customers.  This is huge difference certainly worth
        Marian> inverstigating.

    It has even bigger implications which you don't seem to appreciate.
    You've not given any convincing explanation why a wildcard RR is the
    only solution and why alternatives are not viable. Please provide that
    explanation. 

        >> Patrik Faltstrom wrote: The only place they are used is when
        >> the MX record refer to a gateway (to X.400 or UUCP) where the
        >> other side of the gateway is managing a number of (sub-)
        >> domains, and it is impossible to point all these domains in DNS
        >> with individual MX records to the media gateway.

        Marian> You hit the nail. We need to do similar thing - redirect
        Marian> all voice traffic to a VoIP gateway connected to PBX with
        Marian> many many extensions.

    Well this is a perfect example of why DNS wildcards provide the wrong
    answer to the wrong question. You're assuming that the only use of
    ENUM for some range of numbers would be to contact a VoIP gateway. 
[Martin]
Within our customer range, eventually interested in ENUM, the VoIP gateway
centric view is the only that makes sense. ENUM is for them interesting as
a kind of Least-Cost-Routing. Firstly try to call by means of ENUM/H.323, secondly
call via the costly PSTN. All this is handled within the VoIP gateway and applies 
for outbound calls. 
Of course do they want to be reachable inbound via ENUM/H.323, as well. 
Without devoting man-power, without bearing additional costs. 
Such customers typically do already have a VoIP gateway and a dial-up connection
to the Internet. They typically do not have a DNS server. So, what's more elegant
than submitting a single NAPTR RR that is hosted elsewhere and covers the PSTN root number of 
this company ?

    This
    cannot be guaranteed. What happens when the owners of (some of) those
    numbers want additional NAPTRs for other services? 
[Martin]
Our customer community did not wait for ENUM in its entirety. They're interested in
telephone-related aspects. So, no additional NAPTRs wanted here.
    
    What if they *don't*
    want to use this default VoIP gateway? 
[Martin]
They want, because they typically have a single one.

    Or can't use it. What happens
    with numbers that are not in service? 
[Martin]
A call attempt is being made and the call cannot be established. Very much like in the
PSTN world.
    
    Should applications which look
    these up be pointed at the VoIP gateway regardless? 
[Martin]
Yes.

    That's what you'd
    get with a wildcard. 
[Martin]
And exactly this is welcome.

    Maybe it would be better to get an NXDOMAIN
    response from the DNS. Which of course you can't get if there's a
    wildcard RR. The same goes for numbers that are invalid because they
    don't have the correct number of digits. 
[Martin]
As I stated earlier, there is no problem with numbers that are incomplete 
or "overdialled". If e.g. a call with an incomplete number arrives at a VoIP gateway,
the gateway accepts the call but does not send back an ALERT. Through the, from now on,
established call signalling session the call originator gets the opportunity to submit
further digits without consulting the ENUM track anymore. This is called 
overlapped-dialling.

    What if some of the active
    numbers must not be used for VoIP because they're bound to things like
    a fax machine or a modem? 
[Martin]
Fax over IP (FoIP) is already happening today. Everything that applies for VoIP can
be taken into account for FoIP. Again no problem here. Modem over IP may be not that
widespread, however the same point of view here.

    What if you need to introduce additional
    VoIP gateways for some or all of the numbers?
[Martin]
Hmhh, not sure what you mean, do you refer to load balancing of inbound calls ?
If yes, this would mean a totally different thread.

    BTW, what you're proposing is NOT similar to the scenario Patrik
    outlined at all. You're talking about a known, well-defined, if large,
    name space: a range of telephone numbers. It is possible to enumerate
    all the domain names that exist there. In fact, it's trivial. In the
    scenario Patrik explains the wildcard MX record covers a name space
    that is not known and cannot be enumerated because it is somewhat
    unstructured and dynamic.
[Martin]
If I could go to my NAPTR RR hoster's website and could enter:
- my root number as +49 703173009 
- my desired number range like: from 10 to 99 
- my h323 URI
then I'd be happy. I wouldn't insist on wildcards.
In other words I want to to be able to do it one time for my whole
number range within 10 minutes and then forget it.

        >> Michael Haberler wrote: Or do you propose to have a wildcard in
        >> the zone, and have the server interpret it differently - i.e
        >> giving a matching non-wildcard response?

        Marian> This is how wildcards work _now_ with standard DNS - they
        Marian> are internal to the host running the DNS daemon. The
        Marian> end-user's resolver has no way to tell, if the response is
        Marian> based on wildcard or exact record, since the response is
        Marian> formulated as exact match in both cases. We can certaintly
        Marian> improve the default wildcard behaviour with more
        Marian> sophisticated record synthesizing, in order to get rid of
        Marian> common problems with classic wildcards,

    Sorry, you can't change the semantics of DNS wildcarding without a
    wholesale protocol rewrite. And somehow keeping backwards
    compatibility with the installed base. Please show how you intend to
    do this. For bonus points, get the DNS WGs to adopt your proposal. :-)

        Marian> but I think we really need the capability for one-to-many
        Marian> conversion in ENUM DNS.

    I've not seen any justification for this so far though I accept it
    might be useful. Perhaps you could provide some examples?

[Martin]
You been getting the examples from Marian and me.

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

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 08 Jul 2003 15:47:58 +0200

No, I'm saying that 300 PBX customers might create as much 1
    million records.  Operating DNS servers with millions of records
    is not a trivial task at least not for commonly available DNS
    software and just this is IMHO a good reason to look for
    alternatives which make more decent use of resources.

Did you ever try? I'm running a zone with about 3.7 Million records
om a standard PC with standard DNS software. No sweat. In case you
want to know, that is the signed .nl zone (DNSSEC). The normal zone
has about 1.9 records and runs also on commonly known DNS implementations
(Bind 8 & 9, nsd).

The DNS server is not a problem. As said the provisioning is. A
proper registriation system which keeps track of all the (differenvt)
records is the problem. If the (sets of) records are the same, you
can easely generate these in some automatic fashion.

	jaap

---

From: Jim Reid <[email-masked]>
Date: Mon, 07 Jul 2003 07:20:06 -0700

>>>>> "Marian" == Marian Durkovic <[email-masked]> writes:

    Marian> OK, but all this still translates to me as "use with care"
    Marian> and not as "don't use at all". Sure the DNS admins should
    Marian> be aware of the issues described in RFC!912. Regarding the
    Marian> DNSSEC, ENUM could perhaps apply the attitude described in
    Marian> draft-ietf-dnsext-dns-threats-03.txt:

I strongly disagree with you. DNS wildcards are at best a last
resort. They should only be considered when it is proven there is no
other viable alternative. That's my take on what Patrik has said. Most
clueful DNS people share that perspective. [Or, like me, they take a
more extreme position and say wildcard RRs are evil and to be avoided
at all costs.] So far, it's not been demonstrated why this proposed
wildcard RR is essential or why there are no other viable options.

The issues surrounding DNSSEC are just one part of the wildcarding
problem. Until these are fully understood, it would be prudent not to
advocate or deploy ENUM solutions/specifications that depended on
wildcard RRs. We know DNSSEC *is* going to figure in ENUM one day.
Having to cope with the signing (or non-signing) of wildcards is too
much of a leap into the dark. This needs to be worked out and
documented.

It also looks to me like the wildcard NAPTR RR has been proposed here
to kludge around name server provisioning issues. If that's the case,
wouldn't it be better to solve the underlying problem?

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 08 Jul 2003 10:58:46 +0200

Use of wildcards in ENUM is not a provisioning issue. If it was, I'd spend
    a couple of minutes writing the script to generate the zone files instead 
    of opening the topic here.
    
    The approach of having one record per every PBX extension is
    perhaps usable in trials, but it does not scale. Our institutions
    typically have 3-digit extensions, the larger ones 4-digit
    extensions. Having this in mind you can easily find yourself
    in the situation, where e.g. 300 customers generate as much as
    1 million records. If there's 1 million records in top-level
    domain, you have 1 milion customers to cover the costs. But
    what will be the cost per customer, if the number of customers
    is 300 ?

Most instances of this idea with customers with n-bit extensions
PBX I'm familar with, are actually maintaining such a PBX themselves.
If theu want top do ENUM, the obvious solution is to delegate to
that customer.
    
    The approach with wildcards generates only 300 records per 300 customers.
    This is huge difference certainly worth inverstigating. 
    
    > Patrik Faltstrom wrote:
    > The only place they are used is when the MX record refer to a gateway
    > (to X.400 or UUCP) where the other side of the gateway is managing a
    > number of (sub-) domains, and it is impossible to point all these
    > domains in DNS with individual MX records to the media gateway.
    
    You hit the nail. We need to do similar thing - redirect all voice traffic
    to a VoIP gateway connected to PBX with many many extensions.

No, that is different. You can delegate to a nameserver which
maintains that part of the name space for that particular PBX.
There is no need to populate the toplevel with all the nitty gritty
details of that PBX.

	jaap

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 8 Jul 2003 16:29:44 +0200

On tisdag, jul 8, 2003, at 15:54 Europe/Stockholm, Peterson, Jon wrote:

> Without speaking to the DNS wildcarding issue as a whole, I suppose 
> that
> given the public outcry we should pass over this whole greedy regexp 
> issue
> in silence in sipping-e164. Though ultimately I believe that the use of
> non-greedy regexps in ENUM encourages NAPTR records for partial numbers
> (which in turn encourage wildcarding, etc), I certainly don't feel 
> strongly
> enough about this that I think we need to mandate against it, and I 
> guess I
> could just drop the current RECOMMENDation.

Personally, I would appreciate you dropping it. People implementing 
things should not "just implement what they need" (which often is a 
partial solution). I (and many  with me) remember when MIME was started 
to be adopted where text/plain messages could have a charset parameter. 
Many many implementations didn't implement the 
Content-Transfer-Encoding mechanism, and only took for granted ISO 
8859-1 was in use. When they later launched services and had customers 
in for example Japan, they didn't understand what was wrong...

You have probably seen similar things with SIP...

Better write implementation guidelines which are written so people can 
not cheat. If they do anyway, they must definitely know what they are 
doing (and why they are cheating).

And, I agree with you that the ones doing the provisioning are not the 
same writing the code. BUT, writing the code and get it to work is a 
one-time-thing, although difficult.

With experience from Cisco implementing the whole-nine-yards I can tell 
you the problem is not the regexp engine. The problem is to get the 
configuration tool working correctly so the _selection_ of NAPTR 
records is correct, and possible to understand for the one which 
configure whatever the programmer is creating.

     paf

> Some other notes below.
>
> Jon Peterson
> NeuStar, Inc.
>
>>>
>>> I'm not suggesting that clients refuse to process records with more
> complex
>>> regexp antecedents if they happen to receive them - this is in a 
>>> section
> of
>>> advice for authors of NAPTR records, not a specification of resolver
>>> behavior. Nothing (I hope) in our document breaks DDDS or RFC2916bis
>>> compliance in any way.
>>
>> Why should they ignore it? They still have to _implement_ it.
>
> The people or systems that create the NAPTR records which are 
> provisioned in
> the DNS do not have to 'implement' resolvers.
>
> [snip]
>>
>>> The restriction in the sipping-e164 document basically
>>> reinforces this (at a RECOMMENDED level, not as a mandatory 
>>> statement),
> but
>>> given that this seems to be a controversial matter, perhaps it would 
>>> be
> best
>>> if we passed over this in silence in the SIPPING document as well.
>>>
> [snip]
>>
>> This has _nothing_ to do with partial numbers.
>>
>> Let's then change the example to:
>>
>> 1.2.3.4.e164.arpa. IN CNAME foo.bar.example.com.
>> 2.2.3.4.e164.arpa. IN CNAME foo.bar.example.com.
>> 3.2.3.4.e164.arpa. IN CNAME foo.bar.example.com.
>>
>> foo.bar.example.com. IN NAPTR ....
>> "!^+4(.*)$!sip:9876\[email-masked]!"
>>
>
> Well, all right, given this clever example, I agree that authors of 
> records
> don't necessarily have to use partial E.164 numbers in order to use a
> non-greedy regexp antecedent in NAPTRs. But, authors of records don't 
> really
> have any incentive to make records structured like this, in which you 
> have
> to enumerate every number in the numbering plan in a CNAME record. 
> Rather,
> they want to have a single NAPTR record for a partial number (as in the
> other examples aired on the list have suggested).
>
>>           paf
>