Subject: [Enum] draft-vaudreuil-enum-e164dir-00.txt

From: Patrik Fältström <[email-masked]>
Date: Mon, 20 Mar 2000 15:06:36 -0800

--On 2000-03-20 10.18 -0600, "Vaudreuil, Greg M (Greg)" <[email-masked]>
wrote:

> The differences in
> goals underlying this document and Patrik's should be fodder for
> interesting debate.

:-)

There are immediately some comments I have to your draft.

First two general ones:

(1) There is not much difference between your and mine paper. I only talk
about how to translate from E.164 into a DNS name. How that DNS name is out
of scope for my paper, and I will if people want to, remove examples from
the paper. I am though of the view that one can not forbid use of any
existing service which is based on DNS names to also use these DNS names
which are created by doing this translation. I.e. if I am putting an
explicit SRV for SIP or SMTP in the tree where the E.164 PTR is in your
case, I don't see why it should not work.

(2) I would like you to remove some generic talk about DNS from your paper.
Several issues are discussed in the DNSOP wg, and "guesses" about when and
why TTL of zero is needed etc is probably not needed in your paper.

Now more specifics about section 5:

> 5.1 Telephone Number to Domain Name Mapping
> 
>    For the purposes of discussion and example, this document assumes
>    the e164.int domain as the root for the telephone numbering
>    hierarchy.  In operation, it can be something else to be determined
>    later.

It might be the case that the domain will be different than this, but I'll
be back on this.

>    Example:
> 
>    1.e164.int
>       1.1.1.1.3.3.7.2.7.9 PTR ServiceProvider.net ; for +1 972 733 1111
>       1.1.1.1.3.2.8.4.1.2 PTR ServiceProvider.net ; for +1 214 823 1111

As I said above, I don't want to exclude of putting other record types
where the PTR RR is. It is also the case that I am not really sure if PTR
is the correct RR type to use. I need to think about this, and talk with
some DNS people.

> 5.1.1 Example: Simple Service Requiring Only First Level Query
>
>    One example is a hypothetical
>    service that uses SMTP for the transport mechanism and well
>    understood rules for the construction of an SMTP address.  For
>    example, using a telephone number in the local-part and using the
>    domain name from the first level query in the domain-part (e.g.,
>    service-abc=[email-masked]. The separate Mail Exchange (MX)
>    service record provides adequate information to route the message
>    once the email address has been constructed.  This scenario would be
>    useful in services such as the above, if additional information and
>    capabilities were not required in order to send a message.

I definitely we should minimize the number of ways we given a DNS name,
turn that DNS name + wishes on services, turn that into an identifier which
is used by the specific service. Because of this, I don't like the idea
having several applications each inventing their own way of doing this.

So, I don't like the example. (The generic case is though ok, see below,
but should be done via NAPTRs like in my paper, and not by out-of-band
communication aka specifications per service.)

>    Note that there can be only a single instance of a service for each
>    telephone number.

Nope. The SRV record explicitely allows multiple instances of services for
each name in DNS. So this statement above is not correct. Not even in the
case of generic telephony.
 
>    Sample configuration for numbers sub-delegated from
>    ServiceProviderA.net:
> 
>         *.2.1.5.5.5.3.1.6.1.e164.int.    PTR Zcorporation.com.
>                                                    ;for 613 555 12XX

Wildcards in DNS should be avoided at all costs. DNSSEC and other things
will not be able to handle it. So, the wildcard is from my perspective here
made so it is easier to configure the DNS server, and that can be done by
other means.

>    Sample service-specific queries and responses:
> 
>         Query:   _reachme._tcp. 2.1.2.1.5.5.5.3.1.6.1.Zcorporation.com
>         Response: SRV=ldap.Zcorporation.net weight=10
>                 preference=10  port=389
> 
>    The client can then use LDAP with the reachme schema to determine
>    the set of communications technologies available for +1 613 555
>    1212.

This is NOT a good idea. The problem is that you then can get different
responses depending on in what DNS hierarchy you are looking up the SRV
record. In this case, you query the DNS server for zcorporation.com, and in
some other cases you query the DNS server for tele2.se.

I think the goal of you example would be to have the _reachme._tcp SRV
record for the given E.164 number refer to an authoritative LDAP service
which is the reachme service? Can you explain why each ISP should
(potentially) be able to have SRV records for the _same_ E.164 record
refering to different LDAP servers in this case?

IF different ISPs should have different view on how to route the call, then
this is the wrong place in the hierarchy to handle the redirection.

It is also the case that the lookup process in DNS will be much more
expensive, and you have to go to a different place in the DNS tree before
getting the "referral" from DNS into LDAP. It is much more effective to put
the SRV in the correct space in the tree immediately.

>    SIPphonecall service-specific queries and responses:
> 
>         Query:
> 
>         _sipphonecall._tcp.3.1.3.1.5.5.5.2.7.9.1.ServiceProviderB.net
>         Response:    SRV=sipgw1.ServiceProviderB.net weight=1
>                               preference=10  port=100
> 
>    The client can now use the SIP protocols to contact the SIP gateway
>    to initiate a phone call.

This is something I also don't like, as a different ISP might refer the
number somewhere else. As ServiceProviderB.net is already authoritative for
that number, I don't see why you have to suffix the E.164 number with the
domain of the serviceprovider? You could aswell put the SRV in the
hierarchy of the E.164 directly.

What have I not understood?

    Patrik

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