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

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 21 Mar 2000 10:43:51 -0600

Thanks for the review.  I will try to address your points.

1) The ENUM service needs to be sufficiently defined for a client to
retreive the necessary information to initiate a communications session.
Because this information varies by communication medium, it is not possible
to define a fully general scheme that provides sufficient information.  The
approach in this submission is to issolate the telephone number to domain
name service such that any client for any communciations medium can use this
service with a high likelihood of interoperability.  

It is our assertion that communication medium specific services need to be
defined in separate work items that address the specific needs of that
meduim.  Further, this service-specific definition needs to be sufficiently
independent that the basic ENUM service does not need to be upgraded for
each new service that is created.

Use of the NAPTR records in the telephone number tree provides excessive
flexiblity without providing any clear advantage for clients wishing to
initiate a communication. Further, such a construct requires the entity
providing telephone number to responsible domain to provide many anticilary
services such as service registration and dispute resolution without
explicit administative support.  We have chosen to separarate the
service-specific information into another DNS branch under the direct
administative responsibility of the responsible domain.

What may fundamentally underly our differing approaches is the administative
model.  We note that that telephone number hierarchy is a top-down
delegation hierarchy with clear administative procedures and explicit
authentication to ensure that numbers are not duplicately assigned or
falsely asserted by hostite entities. Similarly, domain names are
hierarchically assigned with clear procedures.  We assert that the ENUM
service conceptually links the phone number to the domain name.  As such,
the ENUM service should be an adjunct to the existing telphone number
management infrastructure.  I believe Patrick's proposal reflects a
bottoms-up, or domain-name centric view.  In this view the domain name
holder registers the telephone number with one or more registration
services.  In this bottoms-up model, it makes sense for the end-user to
specify their service-specific information to the registration entity at the
time the phone number is registered.  In our model, the phone number
management infrastrucure has no basis to accept or manage this service
specific information beyond simply mapping the phone number to the domain
name of the responsible entity.

2) The operational constraints and TTL discussion should move someplace
else.  There is a bit of confusion in the sequencing of documents.  Much of
this discussion is in support of requirements not currently in the
requirements document.  From my vantage point, the ENUM service is a core
infrastructural component for many important services and should TARGET
performance, reliability, and anti-looping parity with the existing phone
network.  Designs inconsisent with this goal should be rejected.  The
discussion of TTL and caching is my justification of the design relative to
these requirements. If individual services can be substantially slower and
less reliable, so be it.

3) The PTR record meets the specific need and is widely deployed in clients
and servers.  SIP and NAPTR records require more information than a
top-level phone number to domain name mapping service is likely to have.
Supporting multiple record types for the same function makes client
development much harder and less likely to be interoperable.

4) I believe each service should define for itself how it will use the ENUM
service.  The services vary widely in their requirements for information.
The first messaging example illustrates a possible use of ENUM where
service-specific configuration information combined with the ENUM returned
data is sufficient.  This is unlikely to be the case for many other
services.  I don't see how NAPTR is general enough to be used for all
services without this per-service definition.

5) While you can have multiple instances of SRV records for a given service
per a given domain name, I believe the semantics are such that they are
assumed to be functionality identical services.  The idea of multiple SRV
records of a given service type is to provide redundancy and
load-ballancing, not act as a capabilities negotiation mechanism between the
sender and recipient.  

6) Wildcards in DNS... I don't get it.  I need to learn more to address this
issue.  My guess is that this is a error in my example writing.

7) Telephone number in second level query:  The intent of using the
telephone number in the second query is to permit individualized responses
without requiring the first level ENUM to return separate domains for each
telephone number.   This was a late addition to the proposal and is
inadequately explained.

Thanks,

Greg V.

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Monday, March 20, 2000 5:07 PM
To: Vaudreuil, Greg M (Greg); Richard Shockey; [email-masked];
[email-masked]
Subject: [Enum] draft-vaudreuil-enum-e164dir-00.txt

--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:

3) 

> 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.

4) 

> 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.

5) 

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

6) 

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.

7) 

>    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

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