Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Wed, 28 Jun 2000 10:13:27 -0500

I am sorry to continue such a militaristic theme, but once started...

I already carry a knife, a handgun, and a can of pepper spray.  I am simply
saying that for my personal self-defense, I have what I need.  Carrying a
bazooka is too much trouble for my needs.  It is heavy, unweildy, and hard
to check as luggage.  However, if you have an challenging assignment, by all
means carry one.

I am not arguing that NAPTRs are not useful, nor that they are unnecessary
for certian applications.  I just don't buy the argument that we need a
"biggest-size fits all" solution.... especially when I have a several
solutions that may do just fine.

The latest posted version NAPTR is defined in 26 dense pages of
specification not including referenced specifications.  The rule-sets
require additional configuration files and substantial processing logic on
the resolver or client.  The client must deal with a wide-variety of
responses from an arbitary server including indefinite levels of recursion.
Given that NAPTR logic is not supported in any deployed resolvers, that
means any application developed for the next few years should implement this
logic.  

However, NAPTR is very expensive overkill for many (most) initial
applications.  My experience with other standards suggest that most
application developers will take short-cuts when they work and do not
initially hinder the product.  Few initial applications need the power or
flexibility of NAPTR. The DNS client is not the core-value of most
telephone-number based applications. If required to use NAPTR, most
developers will take short-cuts that may have the effect of blocking general
use of the best parts of NAPTR.  This is likely because servers will have to
be conservatively configured to not break the installed base of popular
clients implemented with the obvious short-cuts.)

Just a few more thoughts..

Greg V.

-----Original Message-----
From: Michael Mealling [mailto:[email-masked]]
Sent: Wednesday, June 28, 2000 9:30 AM
To: Vaudreuil, Greg M (Greg)
Cc: Patrik Fältström; Anne Brown; 'ENUM'; Scott Bradner
Subject: Re: FW: [Enum] NAPTR is not as an ENUM Requirement

On Wed, Jun 28, 2000 at 09:19:57AM -0500, Vaudreuil, Greg M (Greg) wrote:
> >What can you not express as a URI?
> 
> What can't you kill with a bazooka?  NAPTR and URI is simply not necessary
> for many important services!  DNS resource records are a perfectly
adequate
> way to identify a resource!

True. But if I can only carry one weapon, I'd rather it be a bazooka
since I know it handles nearly every situation I'll encounter. 

I.e.  DNS records may be adequate for your very limited applications but
are you willing to handicap everyeone elses possibly slightly more
ambitious applications simply because yours don't need a particular feature?

-MM

-- 
----------------------------------------------------------------------------
----
Michael Mealling	|      Vote Libertarian!       |
www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:
14198821
Network Solutions	|          www.lp.org          |
[email-masked]

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

---

From: Christian Huitema <[email-masked]>
Date: Wed, 28 Jun 2000 12:03:30 -0700

Reality check here. Enum is defining a way to build DNS names out of E164
numbers. We can use any standard DNS tool to delegate management of a
subtree (NS, SOA), to map some of the number space to a subtree managed in
another SOA (DNAME), or to map a terminal name to another terminal name
(CNAME). Given the operational constraints, CNAME or DNAME look like the
solution of choice for terminals; in fact, DNAME are preferable, since we
will most probably want at some point to use SRV records, and for that we
will need to build a subtree under the number-derived name. We can make the
point that this is obvious, since there is just no way this WG could prevent
the use of zone delegation or DNAME aliasing in the number derived tree. At
mist, this belongs to the operation guidleines, or to the IANA consideration
section.
 
Once we have a DNS name, we ought to be able to stick in it pretty much
every type of record we want, e.g. MX records to define how to send mail,
SRV records for arbitrary applications, etc. NAPTR are useful for some
specific applications; when these applications are enabled, the records
should be present, and that is pretty much the end of it. So, what are we
exactly bickering for?

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jun 2000 21:48:33 +0200

At 12.03 -0700 00-06-28, Christian Huitema wrote:
>CNAME or DNAME look like the
>solution of choice for terminals;

Neither of these are terminals, or do I misunderstand the use of the term?

>  in fact, DNAME are preferable, since we
>will most probably want at some point to use SRV records

I thought what was needed was:

(1) Output be a URI

(2) The ability to do redirections and rewrites, like in

$ORIGIN 6.4.se.

* IN NAPTR 100 10 "u" "sip+N2R" "!^+46(.*)$!ldap://ldap.pts.se/cn=$1,c=SE!" .

...or something like that...

How are you going to use the SRV?

   paf

---

From: Christian Huitema <[email-masked]>
Date: Wed, 28 Jun 2000 13:13:12 -0700

> How are you going to use the SRV?

Classic VOIP example. I want to contact +1 234 567 8901. I will look for the
corresponding SIP/SRV record under _sip.udp.1.0.9.8.7.6.5.4.3.2.1.ipv6.int