Subject: [Enum] Rough Consensus or time to revist the charter?

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Fri, 14 Jul 2000 14:08:56 -0500

With the posting of the latest ENUM draft and the lack of consideration in
it for other non-NAPTR DNS resource record types, it is now clear we have a
process issue to discuss.

The discussion list concerning whether NAPTR is the only DNS resource record
that could be used in the ENUM service apparently was not resolved.  After
several strong statements and growing support for the support of multiple
DNS resource record types, and no opposition except from the document
author, the discussion ended with a well written summary statement from
Christian Huitema.  I personally interpreted that message as a summary of
concensus.  However, the latest revision of the draft does not reflect any
consideration for that discussion and it appears the author has now ruled
that view as incompatable with the current working group charter.

The central question appears to be over the meaning of the following
introductory sentence from the ENUM charter.  The charter states:

	This working group will define a DNS-based architecture and
protocols for 
	mapping a telephone number to a set of attributes (e.g. URLs) which
can be 
	used to contact a resource associated with that number.

The charter goes on to describe a key deliverable:

 	The system must enable resolving input telephone numbers into a set
of URLs 
	which represent different ways to start communication with a device
associated 
	to the input phone number.

What is not clear to many long-time participants in this working group is
that the requirement "must be able to resolve", was to be interpreted so
narrowly as to be exclusive of other non-URL resource identifiers.  There
are several people with the strong opinion that this was never intended to
be so limiting.  They believe that other DNS records may be more suitable
for an arbitary given service offered in the context of ENUM.  While that
and other points are grounds for spirited technical debate, at this point
this central question appears to have been ruled unnecessarily out-of-scope!

I suggest that we begin the ENUM working group session with a half-step
backward and revisit the charter.  We need to reach clarity on whether the
group as a whole believes the charter effectively limits the solution to
only DNS records that can resolve a telephone number to a set of URLs or
whether other useful record types such as SRV and MX may be used as
appropriate`for a particular well-defined service.

Greg V.

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Jul 2000 12:53:46 -0700

> author

bzzzzt!

the support for the author's position may not have been as noisy and
strident as others', but it was clear.  to be clear, i and many others
support patrik.  very strongly.

randy

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 14 Jul 2000 13:35:04 -0700

>support patrik.  very strongly.

(1) NAPTRs are not the only RRs that can be bound to a certain owner 
in DNS. Not at all.

(2) One might want to use E.164 numbers for other things than 
resolving them to a URI.

(3) The current charter of ENUM is about solving the tiny piece of 
the puzzle which have to do with "given an E.164, what URIs can I get 
back".

And, regarding other resource record types, I have still to see the 
need for other RRs to be used in the resolution process which named 
in (3) above. I do not see any need for new RRs and I don't see the 
need for use of for example overloading TXTs.

If Greg is thinking about use of CNAME and DNAME, those are exactly 
like NS records part of the resolution process of a random RR with a 
random owner, and what I have been opposing is having any kind of 
description on the DNS resolution process in this document. Reason is 
that it will (not even might, will(!)) be updated at uneven 
intervals, and this document have nothing to do with that resolution 
process.

Other groups (maybe including a rechartered ENUM) can do other 
things, and I think they should. One reason I heard for the stringent 
charter (I happen to be on the IESG aswell as being a document 
author) was that this are is so large that people need to think about 
one thing at a time. Because of this, ENUM is now working on what 
will be needed regardless of the big picture, namely a mapping from 
E.164 to URIs using DNS, a requirements document which can be applied 
to various services -- which might or might not use the DNS 
resolution process described in the document I am an author of.

I hope that clearified things a bit.

   paf

---

From: "David P. Peek" <[email-masked]>
Date: Fri, 14 Jul 2000 17:48:44 -0400

There is a concern for the scalability when you are retrieving information
for a specific service.  When an application would like to know what
services are available then querying for NAPTR will return all the services
with the respective information. Such as:

vpim
sip
h323
smtp
fax
tel
http
ftp
(and others I can't think of that some of you may already be thinking about)
....(some of the above services may even repeat possibly based on quality of
service levels....)

If an application such as IP telephony queries this directory trying to
locate a SIP address, potentially on every call, then the application will
receive X number of times the amount of data then it requires to find the
SIP server or address.  Multiply this by thousands of queries per given time
period a service provider or large enterprise will make and you find that
not everyone can overlook the amount of data this represents.

I'm not saying to abandon NAPTR but to simply recognize what it will be used
for.  NAPTR will return the services available for an E164 number.  However,
it might not be the optimal method to use when the application making a
query already knowns the service that it needs information for.

The benefits of supporting an application specific query is that the
application will only receive the specific information for the service it
has requested thereby limiting the amount of data returned during critical
paths.
Dave.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Patrik Fältström
Sent: Friday, July 14, 2000 4:35 PM
To: Randy Bush; Vaudreuil, Greg M (Greg)
Cc: [email-masked]
Subject: Re: [Enum] Rough Consensus or time to revist the charter?

   paf

---

From: Michael Mealling <[email-masked]>
Date: Fri, 14 Jul 2000 17:57:18 -0400

> ....(some of the above services may even repeat possibly based on quality of

ftp? Still that's the most complete list I've ever seen and it has 7 (I'm
just not going to count ftp, sorry. ;-). More below...

> SIP server or address.  

Wrong. If the application does that on every service request then it 
is violating the rules about listening to TTLs in the DNS RR records.
It should only requery if the TTLs are shorter than the last time the
query was done (in seconds, not timestamp so it works if your unit doesn't
have a clock). If the administrator creates TTLs that are to short they'll
get the respective hit on their quality of service. Its a standard
DNS solution to the problem....

> Multiply this by thousands of queries per given time

hehe...we do it on a daily basis and its on some pretty reasonable hardware...
If you can't overlook this amount of data then I claim that you're not
even doing IP anymore and your in some bizaro constrained environment that
has other more serious problems than this....

> query already knowns the service that it needs information for.

The application may know what it wants but it doesn't know whats available.
If you're application hopefuly has some kind of fallback then it has to
query, fail, then requery for a fallback, possibly fail again. A larger
packet sent once is always better than two possibly failed requests...

> has requested thereby limiting the amount of data returned during critical

If your comminications path or unit is that limited then you're going 
to be gatewaying/filtering this information through a proxy anyway.

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

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 14 Jul 2000 19:12:57 -0400

But, this is a much more general problem than just for phone
number-based services -- I would argue it is the problem that
RESCAP should be solving.  I think it would be wrong to attempt to
solve it only for phonenumber-based services.

So, leave ENUM focused on E.164->DNS->URL, and solve the general
problem elsewhere.

> has requested thereby limiting the amount of data returned during critical

Leslie.

-- 

-------------------------------------------------------------------
"My body obeys Aristotelian laws of physics."
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------